WEBVTT 00:00:00.000 --> 00:00:02.260 Bayangkan seorang pelanggan menginginkan 100 sepeda bulan depan. 00:00:02.500 --> 00:00:03.300 Pelangganya terlambat datang. 00:00:03.740 --> 00:00:05.120 Rodanya berada di gudang yang berbeda. 00:00:05.360 --> 00:00:07.700 Dan lini perakitan Anda sudah penuh dipesan untuk 2 minggu ke depan. 00:00:07.920 --> 00:00:08.740 Jadi apa yang Anda beli? 00:00:08.940 --> 00:00:09.420 Apa yang Anda buat? 00:00:09.760 --> 00:00:10.360 Apa yang Anda pindahkan? 00:00:10.580 --> 00:00:11.960 Dan kepanan membutuhkan setiap bagian ini. 00:00:12.240 --> 00:00:12.360 Yom. 00:00:12.740 --> 00:00:14.520 Milko Petas dari M365FM. 00:00:15.580 --> 00:00:18.680 Pengetahuan singkat ini tentang Dynamics 365 Master Planning AU. 00:00:19.760 --> 00:00:23.580 Bagian dari manajemen rantai pasokan yang menjawab pertanyaan-pertanyaan itu di balik layar. 00:00:24.140 --> 00:00:26.980 Anggap bisnis Anda seperti gedung kantor dengan ruang stok terlampit. 00:00:27.360 --> 00:00:28.440 Pesanan masuk melalui satu pintu. 00:00:28.440 --> 00:00:29.840 Inventaris tersimpan di rak. 00:00:30.220 --> 00:00:31.840 Pemasok membawa barang gedermagamuat. 00:00:32.220 --> 00:00:34.140 Produksi mengubah suku cadang menjadi produk jaring. 00:00:34.540 --> 00:00:36.840 Perencanaan induk melihat keseluruh bangunan alih-alih. 00:00:37.180 --> 00:00:39.460 Membiarkan setiap tim dengan daftar terpisahnya sendiri. 00:00:40.200 --> 00:00:46.220 Hari ini kami Gertman akan mengikuti satu pesanan sepeda dari permintaan pelanggan hingga tindakan pasokan hingga tindakan pasokan. 00:00:46.220 --> 00:00:50.820 Dynamics 365 menyarankan mengapa bisnis membutuhkan rencana bukan lembar kerja. 00:00:51.560 --> 00:00:55.520 Sebelum alat perencanaan terhubung ada, perusahaan bekerja dari potongan informasi yang terpisah. 00:00:55.800 --> 00:00:57.440 Penjualan memiliki pesanan pelanggan di satu tempat. 00:00:57.440 --> 00:00:59.520 Tim gudang memeriksa stok di sistem lain. 00:00:59.700 --> 00:01:02.240 Pembelian melacak tanggal pemasok dalam email atau lembar kerja. 00:01:02.520 --> 00:01:05.820 Dan produksi menyimpan catatannya sendiri tentang apa yang bisa dibangun pabrik minggu ini. 00:01:06.500 --> 00:01:07.460 Setiap daftar terdengar sendirinya. 00:01:08.100 --> 00:01:10.800 Masalah dimulai ketika seseorang mencoba menjawab satu pertanyaan pelanggan. 00:01:11.140 --> 00:01:13.480 Oh bisakah kita mengirimkan 100 sepeda sesuai tanggal yang kita janjikan? 00:01:13.860 --> 00:01:14.420 Yolah Tavs. 00:01:15.020 --> 00:01:17.080 Bayangkan gudang menyimpan 30 sepeda jadi hari ini. 00:01:17.600 --> 00:01:18.860 Itu terdengar seperti awal yang baik. 00:01:19.040 --> 00:01:21.040 Tetapi pesanan masih membutuhkan 70 sepeda lagi. 00:01:21.040 --> 00:01:28.620 Dan 70 sepeda itu membutuhkan rangka, roda, rantai, kursi, baut, bahan kemasan, orang untuk merakitnya, dan waktu di mesin yang tepat. 00:01:29.200 --> 00:01:32.100 Penghitungan stok sederhana hanya memberitahu Anda apa yang ada di raksa saat ini. 00:01:33.300 --> 00:01:36.640 Itu tidak memberitahu Anda apakah 70 rangka lagi bisa datang sebelum produksi membutuhkannya. 00:01:37.120 --> 00:01:40.140 Itu tidak memberitahu Anda apakah pesanan pembelian terbuka sudah mencakup rodanya. 00:01:40.140 --> 00:01:44.740 Dan itu tidak memberitahu Anda apakah pabrik punya cukup waktu untuk merakit semuanya sebelum tanggal pengiriman. 00:01:45.460 --> 00:01:50.000 Disinilah hal yang membuat perencanaan menjadi lebih dari sekadar menghitung. 00:01:50.800 --> 00:01:53.920 Ketika pelanggan memesan 100 sepeda, sistem melihat permintaan untuk 100 unit. 00:01:54.540 --> 00:01:56.320 Sistem mengurangi 30 sepeda yang sudah tersedia. 00:01:56.760 --> 00:01:59.020 Kemudian melacak apa yang harus terjadi untuk 70 sisanya. 00:01:59.800 --> 00:02:01.600 Sistem memeriksa suku cadang di bawah sepeda jari-jari. 00:02:02.020 --> 00:02:03.600 Sistem memeriksa pasokan yang sudah ada perjalanan. 00:02:03.960 --> 00:02:06.360 Dan sistem memeriksa tanggal yang dilampirkan pada setiap bagian pekerja. 00:02:06.600 --> 00:02:08.480 Satu suku cadang yang hilang dapat mengubah seluruh jauh. 00:02:08.480 --> 00:02:10.220 Anda mungkin memiliki cukup roda dan cukup kursi. 00:02:10.820 --> 00:02:12.020 Namun jika rangka membutuhkan, 00:02:12.260 --> 00:02:15.360 dua minggu dari pemasok membelinya sehari sebelum perakitan tidak akan membantu. 00:02:16.080 --> 00:02:18.160 Pesanan mungkin terlihat bisa dikerjakan di lembar kerja. 00:02:18.320 --> 00:02:20.140 Sampai Anda menempatkan setiap bagian pada kalender. 00:02:20.500 --> 00:02:21.800 Dan kalender itu terus berurus panjang waktu. 00:02:22.240 --> 00:02:24.060 Pemasok mungkin memajukan tanggal pengiriman mereka. 00:02:24.580 --> 00:02:26.840 Pesanan penjualan lain mungkin mengambil stok yang Anda pikir masih tersedia. 00:02:27.220 --> 00:02:28.440 Pekerjaan produksi mungkin selesai terlalu. 00:02:28.800 --> 00:02:30.540 Ketika detail tersebut berada di tempat terpisah, 00:02:30.540 --> 00:02:32.660 orang menghabiskan seluruh waktu mereka untuk menelpon, 00:02:32.660 --> 00:02:35.540 mengirim email, memeriksa, dan memperbarui versi rencana mereka sendiri. 00:02:36.080 --> 00:02:36.680 Dinamik SIGAM 00:02:36.680 --> 00:02:40.360 Perencanaan induk menarik permintaan saat ini dan pasokan saat ini 00:02:40.360 --> 00:02:41.640 ke dalam satu tampilan perencanaan. 00:02:41.820 --> 00:02:43.740 Sistem ini membaca pesanan pelanggan, stok yang ada, 00:02:43.900 --> 00:02:45.960 pasokan masuk, dan informasi produksi secara bersamaan. 00:02:46.440 --> 00:02:48.560 Kemudian sistem menghitung di mana pasokan memenuhi permintaan 00:02:48.560 --> 00:02:49.400 dan di mana kesenjangan tepat. 00:02:49.680 --> 00:02:52.340 Alih-alih meminta setiap tim untuk menghubungkan titik-titik secara manual. 00:02:52.500 --> 00:02:54.880 Sistem membuat saran tindakan berdasarkan informasi yang dapat dilihatnya. 00:02:55.680 --> 00:02:58.300 Namun, itu tidak berarti sistem menjalankan bisnis dengan sendirinya. 00:02:58.960 --> 00:03:00.620 Seorang perencana tetap memberiksa saran, 00:03:00.780 --> 00:03:03.060 mengajukan pertanyaan, dan memutuskan apa yang harus terjadi. 00:03:03.540 --> 00:03:05.540 Tetapi perencana memulai dengan gambaran yang terhubung 00:03:05.540 --> 00:03:06.680 daripada tumpukan daftar tepis. 00:03:07.160 --> 00:03:08.500 Anggap lembar kerja sebagai sebuah foto. 00:03:09.100 --> 00:03:11.700 Lembar kerja menangkap stok pada satu momen dan itu bisa berguna. 00:03:12.320 --> 00:03:15.120 Perencanaan induk lebih dekat ke jadwal yang berorientasi ke depan 00:03:15.120 --> 00:03:17.120 karena menghubungkan jumlah dengan tanggal pasokan masuk 00:03:17.120 --> 00:03:18.280 dan permintaan masa depan. 00:03:18.720 --> 00:03:21.200 Langkah selanjutnya adalah memisahkan berbagai jenis permintaan 00:03:21.200 --> 00:03:22.680 yang dapat dibaca oleh proses perencanaan. 00:03:22.680 --> 00:03:24.980 Tiga mode perencanaan 00:03:24.980 --> 00:03:27.940 Jadi inilah hal tentang Dynamics 365. 00:03:29.420 --> 00:03:31.580 Tidak hanya ada satu cara untuk merencanakan 00:03:31.580 --> 00:03:34.080 mode perencanaan yang Anda gunakan bergantung pada pertanyaan 00:03:34.080 --> 00:03:35.160 yang perlu dijawab oleh bisnis Anda. 00:03:35.880 --> 00:03:38.160 Perusahaan yang menangani pesanan pelanggan minggu ini 00:03:38.160 --> 00:03:40.260 membutuhkan tampilan yang benar-benar berbeda 00:03:40.260 --> 00:03:42.480 dari perusahaan yang menyiapkan material untuk musim berikutnya. 00:03:43.000 --> 00:03:44.480 Mode pertama adalah perencanaan induk. 00:03:44.480 --> 00:03:47.560 Ini adalah rencana harian Anda dan menghitung kebutuhan bersih. 00:03:48.120 --> 00:03:49.800 Ini berarti sistem melihat apa yang Anda butuhkan 00:03:49.800 --> 00:03:52.480 dan mengurangi pasokan yang sudah Anda miliki atau harapkan untuk diterima. 00:03:52.680 --> 00:03:55.820 Sistem membaca aktivitas bisnis nyata atau pesanan penjualan 00:03:55.820 --> 00:03:58.160 dari pelanggan, pesanan pembelian yang sudah dikirim ke pemasok, 00:03:58.320 --> 00:03:59.840 pesanan produksi yang sudah dikirim ke pemasok, 00:04:00.200 --> 00:04:02.560 pesanan produksi yang sudah di lantai pabrik dan inventaris yang ada di gudang. 00:04:02.740 --> 00:04:04.860 Bayangkan pesanan pelanggan untuk 100 unit produk. 00:04:05.360 --> 00:04:08.340 Gudang Anda menampung 30 unit yang dapat digunakan perencanaan untuk pesanan tersebut. 00:04:08.680 --> 00:04:11.440 Sistem tidak mencoba menyarankan untuk membeli atau membuat 100 unit lagi 00:04:11.440 --> 00:04:13.420 karena sistem melihat 3 pasokan, sistem bagi pasokan. 00:04:13.420 --> 00:04:15.740 Jadi sistem menghitung kebutuhan tersisa sebanyak 7 milik. 00:04:16.000 --> 00:04:17.780 70 unit yang tersisa itu adalah kebutuhan bersih. 00:04:17.780 --> 00:04:20.480 Rencana yang nyata dapat mencakup lebih dari sekadar stok di rak. 00:04:21.000 --> 00:04:25.660 Mungkin 20 unit lainnya akan tiba dari pemasok sebelum tanggal yang diminta pelanggan. 00:04:27.160 --> 00:04:29.740 Dalam kasus tersebut, sistem juga memperhitungkan 20 unit itu 00:04:29.740 --> 00:04:31.720 sehingga celah yang perlu ditutupi menjadi lebih kecil. 00:04:32.140 --> 00:04:33.220 Namun tanggal menentukan jawabannya. 00:04:33.620 --> 00:04:36.340 Jika 20 unit tersebut tiba setelah pelanggan mengharapkan pengiriman, 00:04:36.460 --> 00:04:37.560 unit itu tidak terlalu membantu. 00:04:37.560 --> 00:04:41.260 Anda menerimanya secara fisik, tetapi unit tersebut tiba terlambat untuk kebutuhan spesifik ini. 00:04:41.480 --> 00:04:44.000 Perencanaan Induk Master Planning melihat kuantitas dan waktu secara bersamaan. 00:04:44.360 --> 00:04:47.040 Oh, angkat total stok yang sederhana bisa memberikan jawaban yang salah. 00:04:47.040 --> 00:04:50.260 Bagi banyak bisnis, ini adalah rencana yang paling sering mereka jalan. 00:04:50.660 --> 00:04:53.300 Microsoft menyebut perencanaan Induk sebagai proses jangka pendek 00:04:53.300 --> 00:04:55.040 biasanya mencakup 1 minggu hingga 6 bulan. 00:04:55.420 --> 00:04:57.720 Rentang pastinya bergantung pada berapa lama pasokan tiba 00:04:57.720 --> 00:04:59.340 atau berapa lama produksi selesai. 00:05:00.180 --> 00:05:03.600 Perusahaan yang membeli barang lokal sederhana mungkin hanya merencanakan beberapa minggu ke depan. 00:05:04.040 --> 00:05:06.760 Namun, produsen dengan suku cadang yang membutuhkan waktu berbulan-bulan 00:05:06.760 --> 00:05:07.940 perlu melihat lebih jauh ke depan, 00:05:08.060 --> 00:05:10.380 seringkali sejauh total waktu tunggu terlama untuk produknya. 00:05:11.000 --> 00:05:14.560 Jika tidak, perencanaan akan menemukan kekurangan setelah terlambat untuk menghindarinya. 00:05:14.560 --> 00:05:16.820 Mode kedua adalah perencanaan perkiraan forecast planning. 00:05:17.360 --> 00:05:19.620 Alih-alih dimulai dengan pesanan penjualan yang dikonfirmasi, 00:05:19.720 --> 00:05:21.780 perencanaan perkiraan dimulai dengan permintaan yang diharapkan. 00:05:22.140 --> 00:05:25.780 Mungkin tim penjualan mengharapkan penjualan sepeda yang lebih tinggi selama musim panas 00:05:25.780 --> 00:05:28.800 atau pengecar mengharapkan promosi besar untuk menciptakan permintaan di akhir tahun. 00:05:29.060 --> 00:05:32.200 Ini adalah perkiraan berdasarkan ekspektasi tim, bukan pesanan yang dikonfirmasi. 00:05:32.840 --> 00:05:35.920 Ini berguna karena menunggu setiap pesanan pelanggan bisa menyisakan terlalu sedikit waktu 00:05:35.920 --> 00:05:38.100 untuk membeli bahan baku, memesan pekerjaan pabrik, 00:05:38.420 --> 00:05:39.700 atau menyiapkan kapasitas yang cukup. 00:05:39.700 --> 00:05:42.880 Barang dengan waktu tunggu lama memerlukan keputusan lebih awal 00:05:42.880 --> 00:05:44.660 meskipun pesanan pelanggan akhir belum tiba, 00:05:45.140 --> 00:05:47.080 perencanaan perkiraan menghitung kebutuhan kotor gross request. 00:05:47.500 --> 00:05:50.080 Artinya, ini dimulai dengan volume permintaan yang diharapkan. 00:05:50.540 --> 00:05:53.000 Jika perkiraan mengharapkan 500 sepeda pada bulan Juli, 00:05:53.160 --> 00:05:55.860 perencanaan pertama-tama melihat kebutuhan penuh 500 unit 00:05:55.860 --> 00:05:58.140 dan bekerja berdasarkan kebutuhan yang diharapkan tersebut. 00:05:58.660 --> 00:06:01.160 Adap ini sebagai upaya melihat ke depan terhadap beban kerja yang kerja yang kadang. 00:06:01.160 --> 00:06:04.560 Anda kemudian dapat merencanakan bahan dan kapasitas berdasarkan volume yang diharapkan. 00:06:04.560 --> 00:06:06.760 Anda mungkin perlu berbicara dengan pemasok lebih awal, 00:06:06.860 --> 00:06:07.660 menyiapkan ruang gudang, 00:06:07.780 --> 00:06:10.320 atau meniksa apakah produksi dapat menangani beban kerja yang diharapkan. 00:06:10.700 --> 00:06:14.720 Perkiraan bukanlah janji karena bisa berubah dan penjualan aktual mungkin tidak sesuai. 00:06:15.340 --> 00:06:18.640 Tetap saja perkiraan memberikan pandangan yang lebih panjang daripada rencana yang sudah masuk. 00:06:19.200 --> 00:06:21.760 Selanjutnya ada perencanaan induk antar perusahaan intercompany Mr. Brand. 00:06:22.060 --> 00:06:25.020 Ini berperan ketika satu entitas legal membutuhkan pasokan dari entitas lain. 00:06:25.020 --> 00:06:28.040 Misalnya, satu perusahaan dalam grup Anda mungkin memproduksi barang 00:06:28.040 --> 00:06:30.560 sementara perusahaan lain menjuangnya ke pelanggan di negara berbeda. 00:06:31.060 --> 00:06:32.880 Perusahaan penjual melihat permintaan pelanggan. 00:06:32.880 --> 00:06:36.680 Perusahaan produsen perlu melihat kebutuhan pasokan yang diciptakan oleh permintaan tersebut. 00:06:37.240 --> 00:06:41.100 Perencanaan induk antar perusahaan menghubungkan kebutuhan tersebut melintasi batas perusahaan, 00:06:41.160 --> 00:06:44.240 termasuk permintaan dan pasokan terencana yang belum menjadi pesanan tetap. 00:06:44.660 --> 00:06:47.380 Jadi perusahaan tidak merencanakan seolah-olah mereka beroperasi sendiri. 00:06:48.160 --> 00:06:50.860 Perusahaan penjualan dapat merencanakan pasokan dari perusahaan manufaktur, 00:06:50.860 --> 00:06:55.840 sementara perusahaan manufaktur dapat melihat bahwa mereka memerlukan material dan kapasitas untuk mendukung permintaan tersebut. 00:06:56.440 --> 00:06:59.120 Tautan tersebut membawa sinyal perencanaan dari satu entitas lainnya. 00:06:59.640 --> 00:07:00.860 Setiap memuat dengan permintaan. 00:07:00.860 --> 00:07:02.980 Namun permintaan hanyalah sinyal pertama, 00:07:03.200 --> 00:07:06.700 karena satu produk jadi dapat menciptakan rantai kebutuhan untuk banyak komponen tingkat bawah. 00:07:08.200 --> 00:07:09.460 Dari satu pesanan ke rantai pasokan, 00:07:09.600 --> 00:07:13.400 Mari tetap menggunakan sepeda karena disinilah perencanaan induk mulai melakukan pekerjaan aslinya. 00:07:14.160 --> 00:07:18.680 Bayangkan seorang pelanggan memesan 70 sepeda dan meminta pengiriman pada tanggal tertentu. 00:07:19.060 --> 00:07:21.580 Tanggal itu bukan sekadar catatan bagi tim penjualan. 00:07:22.040 --> 00:07:24.500 Oh, itu menjadi titik awal perencanaan yang bekerja mundur 00:07:24.500 --> 00:07:27.800 dengan menanyakan apa yang perlu terjadi sebelum sepeda tersebut dapat meninggalkan gudang. 00:07:27.800 --> 00:07:30.800 Sepeda jadi hanyalah lapisan pertama. 00:07:31.500 --> 00:07:34.680 Dinamik sedaftar material memeriksa daftar material yang sering disebut sebagai BOM. 00:07:35.080 --> 00:07:37.040 Anggaplah BOM sebagai resep untuk satu sepeda. 00:07:37.540 --> 00:07:42.900 Ini mencantumkan rangka, roda, rantai, jok, setang, rem, baut, dan setiap komponen lain yang diperlukan untuk membuatnya. 00:07:42.900 --> 00:07:48.260 Jika pesanan membutuhkan 70 sepeda, perencanaan memperluas pesanan tersebut menjadi komponen yang dibutuhkan untuk ke-70 sepeda tersebut. 00:07:48.700 --> 00:07:50.320 Itu bisa menjadi daftar yang panjang dengan sangat jauh. 00:07:50.760 --> 00:07:54.900 Anda mungkin memerlukan 70 rangka, 140 roda, 70 rejok, dan ratusan baut kecil. 00:07:55.500 --> 00:07:57.940 Seorang perencana tidak perlu menghitung setiap bagian dengan tangan. 00:07:58.440 --> 00:08:04.400 Daftar material memberikan struktur pada Dinamik 365 sehingga sistem dapat melacak permintaan dari sepeda jadi hingga ke setiap komponennya. 00:08:04.400 --> 00:08:07.120 Namun suku cadang saja tidak bisa menghasilkan sepeda. 00:08:07.720 --> 00:08:08.680 Produksi juga membutuhkan ruta. 00:08:09.000 --> 00:08:16.200 Ruta menjelaskan langkah kerja yang diperlukan untuk membuat barang seperti merakit rangka, memasang roda, memeriksa rem, dan mengemas sepeda jadi. 00:08:17.100 --> 00:08:18.400 Setiap langkah bisa memerlukan sumber daya. 00:08:18.740 --> 00:08:24.700 Sumber daya itu bisa berupa jalur perakitan, meja kerja, stand pengecatan, mesin, atau sekelompok orang dengan keahlian yang tepat. 00:08:25.200 --> 00:08:27.840 Perencanaan menggunakan informasi ini untuk menempatkan pekerjaan pada orang. 00:08:27.840 --> 00:08:30.720 Alih-alih menganggap produksi sebagai sesuatu yang terjadi secara instan. 00:08:30.820 --> 00:08:32.220 Disinilah tanggal mulai bergerak mundur. 00:08:32.220 --> 00:08:38.900 Jika pelanggan membutuhkan sepeda pada hari Jumat, pesanan produksi yang sudah jadi mungkin harus selesai pada hari Kamis agar gudang dapat mengemas dan mengirimkannya. 00:08:39.480 --> 00:08:40.980 Perakitan mungkin harus dimulai pada hari Selasa. 00:08:41.420 --> 00:08:43.260 Rangka dan roda mungkin harus tiba pada hari Senin. 00:08:43.720 --> 00:08:48.620 Jika pemasok membutuhkan 10 hari untuk mengirimkan roda, maka pesanan pembelian harus keluar dari bisnis Anda bahkan lebih awal. 00:08:48.940 --> 00:08:50.300 Tanggal pelanggan menciptakan roda yang kena. 00:08:51.020 --> 00:08:55.280 Dynamics 365 bekerja mundur melalui rantai tersebut dengan memperhitungkan waktu tunggu. 00:08:55.800 --> 00:08:58.220 Lead time hanyalah waktu yang dibutuhkan sesuatu, 00:08:58.220 --> 00:09:03.900 baik itu pemasok yang mengirim suku cadang, gudang yang memindahkan, barang atau pabrik yang menyelesaikan pekerjaan. 00:09:04.520 --> 00:09:05.920 Suku cadang yang terlambat dapat nunda segala. 00:09:06.320 --> 00:09:08.540 Misalkan sistem menemukan 70 rangka dalam stok. 00:09:09.140 --> 00:09:14.440 Sistem juga melihat pesanan pembelian terbuka untuk 140 roda dengan jadwal pengiriman sebelum perakitan dimulai. 00:09:15.000 --> 00:09:18.280 Pasokan tersebut memenuhi kebutuhan roda, sementara rangka sudah mencukupi bagiannya. 00:09:18.760 --> 00:09:19.320 Pemeriksa rantai. 00:09:19.900 --> 00:09:23.500 Mungkin hanya ada 40 rantai yang tersedia dan tidak ada pesanan pembelian yang mendatangkan 30 rantai. 00:09:23.500 --> 00:09:26.220 Perencana melihat celah tersebut dan membuat saran untuk menutupinya. 00:09:26.580 --> 00:09:30.680 Pemeriksaan yang sama berlaku untuk sepeda jadi suku cadang di bawahnya dan pekerjaan apapun di antaranya. 00:09:31.120 --> 00:09:32.040 Beberapa pasokan sudah ada. 00:09:32.420 --> 00:09:33.980 Inventaris yang tersedia dapat memenuhi kebutuhan. 00:09:34.300 --> 00:09:36.840 Pesanan pembelian terbuka dapat memenuhinya jika barang tiba tepat waktu. 00:09:37.220 --> 00:09:40.080 Pesanan produksi terbuka dapat memenuhinya jika pabrik selesai tepat waktu. 00:09:40.620 --> 00:09:44.260 Jika tidak ada sumber tersebut yang memenuhi permintaan, rencana tersebut membuat pesanan terencana. 00:09:44.500 --> 00:09:47.260 Pesanan pembelian terencana menyarankan untuk membeli sesuatu dari pemasok. 00:09:47.260 --> 00:09:50.480 Pesanan produksi terencana menyarankan untuk membangun sesuatu di ramai sesuatu. 00:09:50.840 --> 00:09:54.960 Pesanan transfer terencana menyarankan untuk memindahkan stok dari satu lokasi atau gudang ke lokasi lain. 00:09:55.340 --> 00:09:56.960 Ini adalah saran bukan komitmen. 00:09:57.420 --> 00:10:02.460 Dynamics 365 tidak secara diam-diam mengirim pesanan ke pemasok atau memulai pekerjaan di lantai pabrik. 00:10:03.500 --> 00:10:07.060 Sistem ini memberikan perencana jumlah dan tanggal yang diusuhkan berdasarkan data yang dapat dilihatnya. 00:10:07.300 --> 00:10:12.940 Seseorang tetap memeriksa apakah pemasok tersebut tepat, apakah tanggalnya memungkinkan, dan apakah bisnis harus menyetujui tindakan tersebut. 00:10:13.420 --> 00:10:15.100 Bayangkan masalah kecil dengan pesanan sepeda kami. 00:10:15.100 --> 00:10:16.980 Semuanya tampak siap kecuali satu roda. 00:10:17.380 --> 00:10:20.820 Pasokan terencana mencakup rangka, rantai, jok, dan hampir semua roda. 00:10:21.380 --> 00:10:23.500 Namun satu roda tiba sehari setelah perakitan membutuhkannya. 00:10:24.000 --> 00:10:26.100 Tanpa roda itu, satu sepeda tidak bisa diselesaikan. 00:10:26.540 --> 00:10:30.860 Meskipun gudang mungkin terlihat penuh dengan suku cadang, perencanaan induk melacak celah tersebut kembali ke sumbernya. 00:10:31.160 --> 00:10:34.820 Perencanaan dapat melihat bahwa kekurangan tersebut tidak berasal dari pesanan pelanggan itu sendiri. 00:10:35.360 --> 00:10:37.640 Oh, itu berasal dari tanggal pemasok pada pesanan pembelian roda. 00:10:38.300 --> 00:10:40.240 Hal itu memberikan sesuatu yang spesifik bagi perencanaan. 00:10:40.240 --> 00:10:43.800 Minta pengiriman lebih awal, cari sumber lain, atau ubah tanggal produksi. 00:10:44.200 --> 00:10:45.320 Rencana dapat menyarankan pasokan. 00:10:45.620 --> 00:10:47.120 Namun pertanyaan berikutnya sama bergunanya. 00:10:47.580 --> 00:10:50.660 Mengapa Dynamics 365 menghubungkan pasokan ini dengan permintaan tersebut? 00:10:51.160 --> 00:10:53.780 Membaca Kebutuhan Bersih, Percakapan Perencanaan. 00:10:54.300 --> 00:10:57.300 Jadi perencana menggunakan halaman kebutuhan bersih untuk mengalih hubungan tersebut. 00:10:57.780 --> 00:11:01.260 Halaman ini mengumpulkan percakapan perencanaan penuh untuk satu item di satu tempat. 00:11:01.700 --> 00:11:05.260 Ini menampilkan setiap permintaan yang membutuhkan item tersebut dan setiap sumber pasokan yang dapat menuhinya. 00:11:05.440 --> 00:11:07.020 Dengan tanggal yang tertera tepat di samping setiap aris. 00:11:07.020 --> 00:11:08.700 Ambil contoh roda sepeda sebagai gambaran. 00:11:09.240 --> 00:11:12.360 Di bagian atas, Anda memilih lokasi atau gudang tempat roda tersebut beran. 00:11:12.840 --> 00:11:18.980 Lalu di bawahnya, Dynamics 365 menampilkan semua transaksi terkait penjualan, pembelian, inventaris, produksi, semuanya dalam satu daftar. 00:11:19.600 --> 00:11:22.280 Permintaan muncul sebagai angka negatif terhadap stok Anda yang tersedia. 00:11:22.760 --> 00:11:24.420 Permintaan itu bisa datang dari berbagai tempat. 00:11:24.860 --> 00:11:27.380 Pesan penjualan membutuhkan roda karena pelanggan mesan sepeda. 00:11:27.900 --> 00:11:30.040 Peramalan menciptakan permintaan masa depan yang diharapkan. 00:11:30.480 --> 00:11:32.640 Pesanan produksi membutuhkan roda untuk rencana pabrik. 00:11:32.640 --> 00:11:35.860 Dan pesanan transfer menciptakan permintaan ketika gudang lain meminta stok. 00:11:35.860 --> 00:11:37.660 Setiap baris menjawab pertanyaan sederhana. 00:11:38.020 --> 00:11:38.860 Siapa yang membutuhkan item ini? 00:11:39.200 --> 00:11:40.000 Berapa jumlah mereka buat? 00:11:40.240 --> 00:11:40.900 Dan pada tanggal berapa? 00:11:41.100 --> 00:11:43.120 Itu terdengar sederhana tetapi mencegah kesalahan umum. 00:11:43.420 --> 00:11:47.480 Orang sering melihat jumlah total dan menganggapnya milik satu pelanggan atau satu pekerjaan. 00:11:47.580 --> 00:11:51.160 Padahal item yang sama dapat mendukung beberapa pesanan di beberapa pesanan di beberapa tanggal berbeda. 00:11:51.560 --> 00:11:55.100 Di sisi pasokan, Anda memiliki inventaris di tangan atau apa yang sudah ada dalam stok. 00:11:55.720 --> 00:11:59.280 Lalu pesanan pembelian dari vendor, pesanan produksi yang direncanakan bisnis Anda, 00:11:59.560 --> 00:12:03.460 transfer antar gudang, dan pesanan terencana yang disarankan sistem tetapi belum dibuat siapapun. 00:12:03.460 --> 00:12:05.600 Halaman ini mengurutkan semua yang bersahkan tak. 00:12:06.000 --> 00:12:08.960 Saat Anda menggulir daftar ke bawah, Anda dapat melihat perubahan jumlah yang tersedia. 00:12:09.540 --> 00:12:13.320 Stok mungkin terlihat bagus di awal bulan, lalu turun saat pesanan produksi menggunakan suku cadang, 00:12:13.420 --> 00:12:15.360 kemudian naik lagi saat pengiriman pemasok tiba. 00:12:16.300 --> 00:12:17.340 Waktu mengubah hasilnya. 00:12:17.780 --> 00:12:19.900 Misalkan ada 100 roda di satu gudang pada hari Senin, 00:12:20.280 --> 00:12:22.680 tetapi pesanan produksi membutuhkan 80 pada hari Selasa, 00:12:22.880 --> 00:12:25.180 dan kebutuhan pelanggan lain muncul untuk 30 pada hari Rabu. 00:12:25.180 --> 00:12:30.240 Total permintaan melebihi stok meskipun pesanan pembelian masuk untuk 50 roda tiba pada hari Jumat. 00:12:30.680 --> 00:12:33.040 Pengiriman hari Jumat tidak menyelesaikan kekurangan hari Rabu. 00:12:33.160 --> 00:12:35.740 Tampilan berdasarkan tanggal ini menjelaskan mengapa sistem memberikan salah. 00:12:36.160 --> 00:12:38.920 Dynamics 365 tidak sekadar meminta lebih banyak roda secara acak. 00:12:39.500 --> 00:12:43.220 Sistem melihat dengan tepat kapan pasokan yang tersedia turun di bawah permintaan yang harus dipenuhinya. 00:12:43.640 --> 00:12:45.340 Sekarang Anda mungkin mengajukan pertanyaan lebih spesif. 00:12:45.600 --> 00:12:47.320 Baris pasokan mana yang menutupi baris permintaan yang mana? 00:12:47.740 --> 00:12:48.540 Koneksi itu disebut Pegging. 00:12:49.040 --> 00:12:52.680 Pegging adalah tautan perencanaan Dynamics 365 sendiri antara permintaan dan pasokan. 00:12:52.680 --> 00:12:56.760 Ini menghubungkan kebutuhan seperti pesanan produksi untuk sepeda dengan sumber yang diharapkan untuk memenuhinya 00:12:56.760 --> 00:12:59.120 seperti pesanan pembelian untuk roda atau pesanan pembelian terencana. 00:12:59.680 --> 00:13:02.080 Sistem membangun tautan ini selama perhitungan perencanaan. 00:13:02.680 --> 00:13:05.580 Jika permintaan berubah, perencanaan dapat menghitung ulang koneksi tersebut. 00:13:06.060 --> 00:13:09.440 Mungkin pelanggan memindahkan tanggal pengiriman mereka atau pesanan pembelian masuk tertunda. 00:13:10.080 --> 00:13:12.400 Pegging kemudian dapat menunjuk ke sumber pasokan yang berbeda 00:13:12.400 --> 00:13:15.020 atau membuat pesanan terencana baru di tempat menjelaskan celah tersebut. 00:13:15.300 --> 00:13:16.340 Imbantan dan melacak seluruh rantai. 00:13:16.840 --> 00:13:19.500 Mulai dari pesanan penjualan, lihat pesanan produksi yang terhubung dengannya, 00:13:19.500 --> 00:13:22.560 ikuti hingga ke suku cadang yang diperlukan, dan temukan pesanan pembelian yang mencakupnya. 00:13:23.100 --> 00:13:24.380 Terkadang Anda memerlukan kontrol itu. 00:13:24.700 --> 00:13:25.520 Disitulah penandaan marking. 00:13:25.940 --> 00:13:29.440 Penandaan adalah hubungan manual antara transaksi pasokan dan transaksi permintaan. 00:13:29.760 --> 00:13:32.540 Ini memberi tahu sistem bahwa pasokan ini harus menutupi permintaan tersebut 00:13:32.540 --> 00:13:35.160 daripada membiarkan perencana mencocokannya secara bebas di tempat lain. 00:13:35.340 --> 00:13:38.140 Anggap ini seperti menempelkan label pada dua catatan yang saling terkait. 00:13:38.540 --> 00:13:42.940 Anda mungkin menandai pesanan pembelian roda masuk tertentu terhadap pesanan produksi khusus 00:13:42.940 --> 00:13:45.180 karena roda tersebut dibeli untuk pekerjaan itu. 00:13:45.180 --> 00:13:48.660 Perencanaan menghormati hubungan itu dengan lebih tegas daripada tautan pegging normalnya. 00:13:49.040 --> 00:13:51.640 Namun, pasokan yang ditandai bukanlah koneksi terkuat yang tersedia. 00:13:52.140 --> 00:13:53.060 Reservasi lebih kuat. 00:13:53.620 --> 00:13:56.660 Saat Anda memesan inventaris atau pasokan masuk untuk permintaan tertentu, 00:13:56.780 --> 00:13:57.780 Anda membuat tonton permanen. 00:13:58.240 --> 00:14:00.420 Jumlah itu disisihkan untuk pesanan penjualan, pesanan produksi, 00:14:00.520 --> 00:14:01.780 atau permintaan lain yang dipilih. 00:14:01.780 --> 00:14:06.260 Dan perencanaan induk memperlakukan reservasi sebagai prioritas di atas pegging dan penandaan normal. 00:14:06.780 --> 00:14:08.000 Bayangkan 10 roda dalam stok. 00:14:08.300 --> 00:14:10.700 Tetapi roda tersebut dipesan untuk pesanan perbaikan menesak. 00:14:10.700 --> 00:14:13.840 Pesanan pelanggan berikutnya mungkin membutuhkan roda juga, 00:14:14.020 --> 00:14:17.240 tetapi perencanaan tidak bisa menganggap 10 roda yang dipesan itu tersedia secara bebas. 00:14:17.460 --> 00:14:20.180 Perencanaan perlu mencari pasokan lain atau menyarankan lebih banyak pasokan 00:14:20.180 --> 00:14:21.780 karena reservasi sudah mengalokasikannya ke tempat. 00:14:21.940 --> 00:14:24.660 Jadi, pegging, penandaan, dan reservasi memberi Anda tiga tingkat koneksi. 00:14:25.060 --> 00:14:26.620 Packing adalah kecocokan otomatis dari sistem. 00:14:26.920 --> 00:14:28.720 Penandaan adalah tautan manual yang lebih tetap. 00:14:29.060 --> 00:14:31.020 Reservasi mengunci pasokan kekebutuhan tertentu. 00:14:31.260 --> 00:14:32.480 Itu yang terkuat dari ketiganya. 00:14:32.900 --> 00:14:34.540 Setelah Anda dapat membaca tautan tersebut, 00:14:34.640 --> 00:14:37.160 pesanan terencana tidak lagi terlihat seperti instruksi yang tidak jelas. 00:14:37.160 --> 00:14:40.560 Pertanyaan berikutnya adalah seberapa sering tampilan perencanaan ini berubah 00:14:40.560 --> 00:14:42.660 dan seberapa cepat Dynamics 365 dapat menghitungnya. 00:14:43.620 --> 00:14:45.120 Dan optimalisasi perencanaan. 00:14:45.740 --> 00:14:47.660 Halaman kebutuhan bersih menampilkan hasil perencanaan, 00:14:47.720 --> 00:14:49.560 tetapi tidak setiap perencanaan diperbarui dengan cara yang sama. 00:14:49.920 --> 00:14:52.940 Rencana statis hanya berubah ketika seseorang menjalankan pekerjaan perencanaan induk. 00:14:53.400 --> 00:14:56.720 Hal ini memberikan perencana pandangan stabil yang dapat mereka tinjau sepanjang hari 00:14:56.720 --> 00:14:58.840 tanpa setiap transaksi baru mengubah angka di bawahnya. 00:14:59.160 --> 00:15:01.380 Bayangkan pesanan penjualan besar masuk pada pukul 11 pagi. 00:15:01.460 --> 00:15:03.460 Jika rencana statis dijalankan semalam, 00:15:03.460 --> 00:15:06.760 pesanan baru itu tidak akan muncul dalam sarannya sampai proses perencanaan berikutnya. 00:15:07.240 --> 00:15:09.520 Rencana tersebut masih menunjukkan hasil hitungan terakhir 00:15:09.520 --> 00:15:12.360 yang berguna saat tim membutuhkan satu pandangan yang disepakati untuk hari itu. 00:15:12.780 --> 00:15:13.980 Namun stabilitas itu ada harganya. 00:15:14.400 --> 00:15:17.300 Permintaan baru bisa berada di luar rencana statis untuk sementara waktu, 00:15:17.460 --> 00:15:19.880 terutama jika bisnis Anda menjalankan perencanaan sekali setiap minggu. 00:15:19.960 --> 00:15:21.800 Seorang perencana mungkin tahu pesanan pelanggan ada, 00:15:22.060 --> 00:15:24.860 tetapi rencana statis belum menghitung ulang respon sepasokannya. 00:15:25.340 --> 00:15:26.340 Disitulah rencana yang bisa membahas. 00:15:26.720 --> 00:15:28.960 Rencana dinamis menunjukkan permintaan saat ini saat itu juga. 00:15:28.960 --> 00:15:31.960 Perencana dapat melihat efek pesanan penjualan baru dan permintaan lainnya 00:15:31.960 --> 00:15:33.960 tanpa harus menunggu proses perencanaan utama berikutnya. 00:15:34.340 --> 00:15:35.220 Ini adalah pandangan jangkapan. 00:15:35.620 --> 00:15:38.920 Rencana dinamis mengabaikan perakiraan dan berfokus pada apa yang terjadi saat ini. 00:15:39.540 --> 00:15:42.880 Katakanlah seorang pelanggan melakukan pemesanan tak terduga sebanyak 200 sepeda sore ini. 00:15:43.420 --> 00:15:45.240 Sebelum menjanjikan tanggal pengiriman perencana, 00:15:45.600 --> 00:15:47.980 dapat membuka rencana dinamis dan memeriksa dampaknya. 00:15:48.520 --> 00:15:49.840 Apakah pesanan baru menciptakan kurang? 00:15:50.240 --> 00:15:52.200 Apakah pesanan tersebut mendorong kebutuhan yang lebih lambat? 00:15:52.560 --> 00:15:55.540 Apakah pesanan itu memicu saran tindakan pembelian atau produksi yang berhubung? 00:15:55.540 --> 00:15:57.800 Ini memberi tim pandangan bagaimana jika yang praktis. 00:15:58.700 --> 00:16:01.620 Anda tidak mengubah rencana statis hanya untuk memeriksa satu pesanan baru. 00:16:02.040 --> 00:16:03.920 Anda memeriksa kemungkinan dampaknya terlebih dahulu, 00:16:04.100 --> 00:16:06.320 lalu memutuskan apakah pesan tersebut perlu perhatian sekarang 00:16:06.320 --> 00:16:07.880 atau bisa menunggu jadwal perencanaan berikutnya. 00:16:08.620 --> 00:16:11.240 Rencana statis dan dinamis menjawab pertanyaan yang terkait namun berbeda. 00:16:11.640 --> 00:16:12.460 Rencana statis bertanya, 00:16:12.600 --> 00:16:14.960 apa yang diperintahkan oleh perhitungan perencanaan resmi terakhir kita? 00:16:16.320 --> 00:16:17.620 Rencana dinamis bertanya, 00:16:17.620 --> 00:16:19.580 seperti apa permintaan saat ini saat ini? 00:16:20.060 --> 00:16:21.240 Di balik kedua rencana tersebut, 00:16:21.360 --> 00:16:24.460 terdapat mesin perencanaan untuk lingkungan Cloud Dynamics 365. 00:16:24.460 --> 00:16:27.560 Optimasi perencanaan adalah mesin modern yang digunakan Microsoft 00:16:27.560 --> 00:16:28.900 untuk menjalankan perencanaan utama. 00:16:29.300 --> 00:16:31.280 Ini menghitung kebutuhan di luar aplikasi bisnis utama 00:16:31.280 --> 00:16:33.740 yang mengurangi beban pada sistem yang digunakan orang 00:16:33.740 --> 00:16:34.920 untuk pekerjaan sehari-hari. 00:16:35.520 --> 00:16:37.220 Proses perencanaan yang lama bisa memakan waktu yang. 00:16:37.560 --> 00:16:39.900 Laporan dari pelanggan dan mitra menggambarkan pekerjaan perencanaan 00:16:39.900 --> 00:16:41.400 yang dulunya memakan waktu berjam-jam kini 00:16:41.400 --> 00:16:43.040 selesai dan mencungguan menit dengan optimasi perencanaan. 00:16:43.040 --> 00:16:45.440 Proses yang lebih cepat berarti tim dapat memperbaru rencana 00:16:45.440 --> 00:16:47.220 lebih sering daripada menunggu hingga akhir hari 00:16:47.220 --> 00:16:48.620 untuk melihat apakah permintaan berubah. 00:16:48.860 --> 00:16:50.800 Namun jawaban yang lebih cepat tetap bisa menjadi jawaban yang salah. 00:16:50.800 --> 00:16:54.600 Optimasi perencanaan dapat menghitung sejumlah besar data terkait dengan cepat. 00:16:55.120 --> 00:16:57.320 Namun ia bekerja berdasarkan catatan yang diberikan oleh bisnisan. 00:16:57.720 --> 00:16:58.940 Jika waktu tunggu pemasok salah, 00:16:59.220 --> 00:17:00.860 tanggal pesanan yang disarankan juga bisa salah. 00:17:01.340 --> 00:17:03.860 Jika sistem mengira ada 500 roda dalam stok padahal tidak, 00:17:04.060 --> 00:17:06.320 sistem mungkin melewatkan sarang pembelian yang sebenarnya Anda butuhkan. 00:17:06.620 --> 00:17:09.060 Dan jika daftar material BOM melewatkan suatu suku cadang, 00:17:09.060 --> 00:17:11.220 perencanaan tidak dapat membuat permintaan untuk suku cadang yang enak. 00:17:11.480 --> 00:17:13.220 Perhitungan mungkin selesai dalam hitungan menit, 00:17:13.360 --> 00:17:15.960 tetapi pabrik tetap berhenti jika suku cadang tersebut tidak ada. 00:17:16.340 --> 00:17:17.760 Ada juga perubahan dalam cara perencanaan bercerana. 00:17:17.760 --> 00:17:20.040 Dengan optimasi perencanaan, rencana bersifat terkira. 00:17:20.600 --> 00:17:22.860 Itu berarti setiap proses meninjau kembali semua kebutuhan, 00:17:23.020 --> 00:17:24.940 bukan menggunakan pendekatan perubahan bersih lama 00:17:24.940 --> 00:17:27.720 yang hanya memperbarui item dengan kebutuhan baru sejak proses terakhir. 00:17:28.300 --> 00:17:31.200 Anggaplah ini sebagai penghitungan ulang seluruh gambaran perencanaan setiap saat. 00:17:31.560 --> 00:17:35.020 Hal ini menghilangkan keraguan tentang apakah perubahan sebelumnya terlewat dari perhitungan, 00:17:35.080 --> 00:17:38.880 sementara mesin yang lebih cepat membuat penghitungan ulang penuh menjadi lebih praktis baik banyak bisnis. 00:17:39.160 --> 00:17:40.120 Jadi kecepatan memang bantu, 00:17:40.260 --> 00:17:42.480 tapi data yang bersihlah yang menentukan apakah rencana tersebut layak. 00:17:42.720 --> 00:17:44.180 Setelah rencana memberikan sarannya, 00:17:44.180 --> 00:17:47.400 tugas berikutnya adalah memutuskan mana yang perlu ditindaklanjuti terlebih dahulu. 00:17:47.800 --> 00:17:50.260 Namun, apa yang dilakukan Master Planning dan apa yang tidak dilakukannya? 00:17:50.800 --> 00:17:52.040 Jadi inilah definisi paling sederhananya. 00:17:52.660 --> 00:17:55.160 Master Planning mengambil semua data di dalam Dynamics 365 00:17:55.160 --> 00:17:57.500 dan menyarankan apa yang harus dibeli, dibuat, 00:17:57.640 --> 00:17:59.700 atau dipindahkan lengkap dengan tanggal dan jumlahnya. 00:18:00.280 --> 00:18:02.880 Seorang perencana akan meninjau pesanan yang dikencanakan tersebut sebelum bertit. 00:18:03.180 --> 00:18:05.200 Mereka memeriksa vendor, tanggal pengiriman, jumlah, 00:18:05.280 --> 00:18:07.180 dan apakah pabrik dapat menangani pekerjaan tersebut. 00:18:07.480 --> 00:18:09.960 Setelah mereka mengonfirmasi melakukan penetapan atas saran tersebut, 00:18:10.040 --> 00:18:11.440 akan mengubahnya menjadi pesanan pembelian, 00:18:11.440 --> 00:18:12.920 pesanan produksi atau pesanan transfernya. 00:18:13.040 --> 00:18:14.520 Namun, Master Planning tidak bisa melihat masa depan. 00:18:14.940 --> 00:18:17.380 Perakiraan hanyalah perkiraan dan pesanan pelanggan 00:18:17.380 --> 00:18:18.940 yang sebenarnya bisa berubah dalam semangat. 00:18:19.040 --> 00:18:21.300 Dan sistem ini jelas tidak menggantikan perencanaan manusia. 00:18:21.640 --> 00:18:23.120 Orang-orang tetap menangani risiko pemasun. 00:18:23.420 --> 00:18:24.680 Janji kepada pelanggan dan pengecualian. 00:18:25.120 --> 00:18:26.280 Sistem tidak bisa memberikan penilaian. 00:18:27.060 --> 00:18:28.280 Stok saja juga tidak cukup. 00:18:28.640 --> 00:18:29.900 Persediaan itu mungkin tiba-tiba terlambat, 00:18:30.000 --> 00:18:31.020 berada di gudang yang salah, 00:18:31.200 --> 00:18:32.540 atau sudah dipesan untuk pesanan lain. 00:18:33.020 --> 00:18:34.700 Untuk mendapatkan hasil yang baik, 00:18:34.840 --> 00:18:36.220 mulailah dengan data yang bersih, 00:18:36.440 --> 00:18:37.420 catatan item yang bersih, 00:18:37.420 --> 00:18:38.400 waktu tunggu yang akurat, 00:18:38.540 --> 00:18:39.440 tagian material yang benar, 00:18:41.440 --> 00:18:42.760 Untuk pesanan sepeda kita, 00:18:42.860 --> 00:18:44.440 stok yang ada menutupi sebagian dari kebutuhan. 00:18:44.880 --> 00:18:46.740 Perencanaan menyarankan pasokan untuk sisanya 00:18:46.740 --> 00:18:48.180 dan perencana mengonfirmasi tindakan. 00:18:48.440 --> 00:18:49.980 Hal itu membawa kita kembali ke pertanyaan 00:18:49.980 --> 00:18:51.060 yang perlu dijawab oleh setiap tim. 00:18:51.260 --> 00:18:52.240 Apa yang harus dilakukan selanjutnya? 00:18:53.440 --> 00:18:54.960 Kesimpulan satu rencana yang terhubung. 00:18:55.700 --> 00:18:57.800 Master Planning mengambil permintaan tingkat stok, 00:18:58.240 --> 00:18:59.340 tanggal pengiriman pemasok, 00:18:59.520 --> 00:19:01.180 jadwal produksi, dan kapasitas, 00:19:01.520 --> 00:19:02.820 lalu mengubah semuanya menjadi tindakan 00:19:02.820 --> 00:19:04.140 yang dapat ditinjau oleh tim Anda. 00:19:04.760 --> 00:19:06.680 Pesanan yang direncanakan memulai keputusan manusia sekarang. 00:19:06.680 --> 00:19:07.680 Sesetap tidak menyelesaikannya. 00:19:07.680 --> 00:19:09.180 Itulah sebabnya perencana tetap tentu. 00:19:09.500 --> 00:19:11.320 Perlanggananlah di platform podcast favorit Anda. 00:19:11.520 --> 00:19:12.600 Dan bagikan potongan-potongan ini 00:19:12.600 --> 00:19:13.760 kepada seseorang yang sedang mempelajari 00:19:13.760 --> 00:19:15.100 manajemen rantai pasok Dynamics 365.