M365Con 2027 – konferensi online gratis · 11–22 Jan 2027 · 120 sessions→ m365con.net

Blog · Mirko Peters

Mengapa Hitungan Stok Saja Tidak Cukup: Melampaui Inventaris Dasar

By ·

Selamat datang kembali di blog pendamping podcast kami! Jika Anda pernah menjalankan toko ritel, gudang, atau operasi manufaktur berskala besar, Anda mungkin tahu rasa panik yang muncul saat pesanan tak terduga dengan volume tinggi tiba di meja Anda. Anda bergegas membuka perangkat lunak inventaris, menjalankan laporan stok, dan lega karena angkanya tampak cukup. Namun, seperti yang sering disadar

Automatically translated with AI from the original post. Read the English original

Cover: Dynamics 365 Master Planning - Simply Explained

Selamat datang kembali di blog pendamping podcast kami! Jika Anda pernah menjalankan toko ritel, gudang, atau operasi manufaktur berskala besar, Anda mungkin tahu rasa panik yang muncul saat pesanan tak terduga dengan volume tinggi tiba di meja Anda. Anda bergegas membuka perangkat lunak inventaris, menjalankan laporan stok, dan lega karena angkanya tampak cukup. Namun, seperti yang sering disadari para manajer operasional dengan cara yang sulit, mengetahui berapa banyak barang yang ada di rak hanyalah sebagian kecil dari pertempuran. Perdagangan modern bergerak cepat, sangat kompleks, dan terkait erat dengan banyak komponen yang bergerak. Ketika pelanggan meminta konfigurasi khusus atau sejumlah besar produk dengan tenggat waktu yang ketat, hitungan inventaris dasar tidak akan membuat Anda terhindar dari masalah.

Dalam artikel ini, kami akan membahas secara mendalam mengapa hitungan inventaris statis gagal, bagaimana spreadsheet yang terisolasi runtuh di bawah tekanan, dan bagaimana sistem modern menjembatani kesenjangan antara jumlah sederhana, tenggat waktu, dan kapasitas pabrik. Baik Anda sedang memperbesar gudang maupun berupaya merampingkan lini perakitan yang kompleks, memahami konsep-konsep ini sangat penting untuk menepati janji kepada pelanggan tanpa membuat tim Anda kewalahan.

Pendahuluan: Kompleksitas Pesanan Pelanggan Modern

Bayangkan skenario berikut: Klien besar menghubungi Anda dan meminta seratus sepeda dikirim langsung ke pusat distribusinya bulan depan. Sekilas, ini terdengar seperti masalah yang menyenangkan. Pendapatan masuk, dan tim penjualan Anda merayakannya. Namun, ketika Anda mulai melihat realitas operasional dari pesanan tunggal itu, Anda mungkin hanya memiliki beberapa sepeda jadi yang sudah ada di gudang, dan tentu saja belum ada seratus unit yang siap dikirim. Selain itu, roda yang Anda butuhkan saat ini berada di dalam kontainer kapal yang masih berada di tengah samudra, komponen rangka disimpan di gudang kedua di seberang kota, dan lini produksi di lantai pabrik utama sudah sepenuhnya terisi selama dua minggu ke depan.

Di sinilah teori bertemu praktik dalam manajemen rantai pasok. Apa yang harus dibeli? Apa yang harus dibuat sendiri? Apa yang harus dipindahkan dari fasilitas lain? Dan yang paling penting, kapan setiap tindakan tersebut harus dilakukan agar semuanya berjalan lancar? Mengelola ketergantungan yang rumit ini secara manual hampir mustahil. Untuk benar-benar memahami cara mengatur rantai pasok modern, kita harus melampaui angka-angka sederhana dan melihat bagaimana sistem seperti Dynamics 365 menyatukan permintaan, inventaris, pembelian, produksi, daftar material, waktu tunggu, dan kapasitas manufaktur ke dalam satu rencana yang kohesif dan dapat ditindaklanjuti. Untuk mendapatkan ulasan audio lengkap tentang topik ini, pastikan Anda mendengarkan episode terkait kami, Dynamics 365 Master Planning - Simply Explained.

Mengapa Hitungan Stok Dasar Tidak Memadai

Mari kembali ke pesanan sepeda kita. Pelanggan menginginkan seratus unit, dan sistem manajemen gudang Anda memberi tahu bahwa saat ini Anda memiliki tiga puluh sepeda jadi di rak. Hitungan dasar menunjukkan bahwa Anda kekurangan tujuh puluh unit. Pada titik ini, sistem inventaris yang naif mungkin menandai bahwa Anda perlu tujuh puluh rangka lagi, tetapi sistem itu mengabaikan konteks penting yang diperlukan untuk benar-benar mewujudkan rangka tersebut.

Ketujuh puluh sepeda yang kurang itu membutuhkan serangkaian input yang luar biasa banyak: rangka, roda, rantai, jok, baut, bahan kemasan, karyawan khusus, mesin yang tersedia, dan, yang terpenting, waktu produksi yang cukup untuk merakit semuanya. Laporan inventaris sederhana hanya memberi tahu apa yang ada saat ini juga. Laporan itu tidak dapat memberi tahu apakah pemasok Anda dapat mengirimkan bahan baku sebelum tim perakitan membutuhkannya, dan juga tidak menunjukkan apakah pabrik Anda memiliki jam operasional yang cukup untuk menyelesaikan pekerjaan tersebut. Hitungan stok dasar mengabaikan dimensi waktu, dan dalam manajemen rantai pasok, waktu sama pentingnya dengan kuantitas.

Beralih dari Spreadsheet Terisolasi ke Perencanaan Terhubung

Bagaimana sebagian besar perusahaan yang sedang berkembang mengelola persediaan dan produksi mereka sebelum mengadopsi alat perencanaan kelas enterprise? Mereka mengandalkan spreadsheet, email, dan perangkat lunak lama yang tidak terhubung satu sama lain. Dalam lingkungan tradisional ini, departemen penjualan menyimpan pesanan pelanggan di basis data terisolasi, sementara karyawan gudang memeriksa persediaan fisik di sistem yang sama sekali berbeda. Sementara itu, tim pembelian melacak tanggal pengiriman pemasok di dalam spreadsheet yang besar dan sulit dikelola, dan tim produksi memelihara jadwal independen lain yang menjelaskan apa yang seharusnya dibuat oleh lini pabrik hari ini.

Jika Anda memeriksa setiap daftar ini secara terpisah, semuanya mungkin tampak benar. Daftar penjualan cocok dengan email pelanggan, dan lembar pembelian memuat tanggal yang diberikan oleh vendor. Namun, seseorang tetap harus secara manual menghubungkan semua pulau data yang terisolasi ini untuk menjawab pertanyaan utama: Dapatkah kami benar-benar mengirimkan apa yang dipesan pelanggan pada tanggal yang dijanjikan? Tanpa mesin otomatis, menjawab pertanyaan itu membutuhkan waktu berhari-hari untuk rapat, panggilan telepon yang panik, dan berharap semuanya berjalan lancar. Inilah sebabnya organisasi akhirnya beralih dari spreadsheet statis ke alat perencanaan dinamis yang terhubung dan terus saling bertukar informasi.

Master Planning vs. Spreadsheet

Anggap spreadsheet tradisional sebagai sebuah foto. Foto dapat memberikan gambaran yang berguna dan sangat spesifik tentang persediaan Anda pada satu momen tertentu. Namun, bisnis tidak berhenti begitu saja saat Anda melihat foto tersebut. Master Planning, di sisi lain, lebih mirip film real-time yang berorientasi ke depan. Sistem ini mempertimbangkan kuantitas bersama tanggal kalender, permintaan pelanggan di masa depan, pengiriman pemasok yang masuk, hambatan produksi, dan saldo persediaan yang ada. Ketika salah satu elemen ini berubah—misalnya, pemasok menunda pengiriman rem selama tiga hari—keseluruhan gambaran perencanaan ikut bergeser, dan sistem dapat langsung menghitung ulang langkah terbaik berikutnya.

Tiga Mode Perencanaan

Sistem enterprise tidak memaksa Anda untuk berpikir dengan satu cara saja; sistem ini menawarkan berbagai mode perencanaan untuk menangani pertanyaan bisnis yang berbeda. Master planning tradisional biasanya berfokus pada kebutuhan operasional harian dan jangka pendek, memastikan pesanan pelanggan yang mendesak terpenuhi. Sebaliknya, forecast planning melihat jauh ke depan pada perkiraan permintaan di masa mendatang, bahkan sebelum pesanan tetap ditempatkan. Terakhir, intercompany master planning menghubungkan kebutuhan permintaan dan pasokan di beberapa badan hukum dalam payung perusahaan yang sama. Setiap mode ini dimulai dari bentuk permintaan, tetapi menjawab pertanyaan strategis yang sangat berbeda bagi bisnis.

Menghubungkan Kuantitas dengan Waktu dan Kapasitas

Memiliki persediaan yang cukup pada akhirnya sangat berbeda dengan memiliki persediaan yang cukup pada saat benar-benar dibutuhkan oleh pelanggan atau lini perakitan. Bayangkan dua puluh sepeda tambahan dijadwalkan tiba dari pemasok eksternal. Jika sepeda-sepeda tersebut tiba tiga hari sebelum batas waktu pelanggan, sepeda tersebut dapat digunakan untuk memenuhi pesanan. Namun, jika sepeda yang sama tiba tiga hari setelah batas waktu, sepeda itu sama sekali tidak mengatasi kekurangan Anda saat ini. Sepeda itu hanya menumpuk di gudang sebagai stok berlebih.

Inilah alasan mengapa sistem modern menghitung kebutuhan bersih menggunakan rumus sederhana: Permintaan dikurangi persediaan yang tersedia atau yang diperkirakan sama dengan kebutuhan yang tersisa. Misalkan pelanggan memesan seratus unit dan gudang Anda memiliki tiga puluh unit yang tersedia. Kebutuhan Anda yang tersisa adalah tujuh puluh. Namun, jika dua puluh unit lainnya sudah dijadwalkan tiba dari pemasok yang andal sebelum tanggal pengiriman yang diminta pelanggan, kebutuhan yang belum terpenuhi menyusut menjadi lima puluh. Sistem tidak secara membabi buta menyarankan Anda untuk membeli atau memproduksi seluruh kuantitas pelanggan dari awal; sistem secara cerdas mengurangi apa yang sudah dalam perjalanan.

Selain itu, perencanaan harus melihat cukup jauh ke depan. Horizon perencanaan yang tepat sepenuhnya bergantung pada industri spesifik Anda. Distributor ritel lokal yang membeli barang konsumen dengan perputaran cepat mungkin hanya perlu melihat beberapa minggu ke depan. Sebaliknya, produsen berat yang menggunakan komponen khusus dengan waktu tunggu pemasok hingga berbulan-bulan harus merencanakan jauh ke masa depan. Menemukan kekurangan material setelah tanggal pembelian atau produksi yang diperlukan telah lewat adalah resep untuk tenggat waktu yang terlewat dan klien yang kecewa.

Forecast Planning dan Gross Requirements

Saat Anda melampaui pesanan yang sudah dikonfirmasi, Anda masuk ke ranah perencanaan prakiraan. Mode ini dimulai dari perkiraan permintaan, bukan kontrak yang sudah ditandatangani. Sebuah produsen sepeda mungkin meninjau data historis dan memperkirakan permintaan akan melonjak selama bulan-bulan musim panas. Jika menunggu setiap pesanan pelanggan masuk satu per satu, perusahaan bisa kekurangan waktu untuk mengadakan bahan baku atau memesan kapasitas produksi yang krusial. Perencanaan prakiraan memberi organisasi sinyal peringatan dini tentang beban kerja yang akan mereka hadapi.

Dengan menghitung kebutuhan kotor berdasarkan permintaan yang diperkirakan, misalnya memprediksi lima ratus sepeda yang dibutuhkan pada Juli, organisasi dapat mengevaluasi apakah pemasok, ruang gudang, dan mesin pabrik mampu menangani beban tersebut. Prakiraan bukan penjualan yang dijamin, tetapi prakiraan memberikan visibilitas penting yang dibutuhkan untuk mempersiapkan rantai pasok sebelum lonjakan permintaan benar-benar terjadi.

Bagaimana Master Planning Menerjemahkan Permintaan menjadi Langkah yang Dapat Ditindaklanjuti

Ketika satu pesanan pelanggan masuk ke ekosistem Anda, pesanan tersebut memicu reaksi berantai besar di seluruh rantai pasok. Permintaan satu produk jadi dapat berjenjang menjadi puluhan kebutuhan untuk komponen tingkat yang lebih rendah. Jika pelanggan memesan tujuh puluh sepeda, sistem memeriksa resep struktur produk tersebut dan menentukan secara tepat apa yang dibutuhkan untuk membuatnya: tujuh puluh rangka, seratus empat puluh roda, tujuh puluh rantai, tujuh puluh jok, dan ratusan mur, baut, serta kabel berukuran kecil. Di sinilah Bill of Materials (BOM) menjadi pusat mutlak dari dunia manufaktur Anda.

Bill of Materials pada dasarnya adalah resep masakan untuk barang hasil produksi. Alih-alih memaksa perencana menghitung kebutuhan komponen secara manual setiap kali pesanan pelanggan berubah, sistem memperluas permintaan produk jadi menjadi tugas di tingkat komponen secara otomatis. Namun, memiliki setiap komponen mentah di rak tidak serta-merta mengubahnya menjadi produk jadi. Dibutuhkan tenaga kerja dan mesin yang aktif untuk itu.

Di sinilah rute produksi dan waktu tunggu (lead time) berperan. Rute menguraikan urutan langkah yang tepat untuk membangun sebuah barang, misalnya mengelas rangka, memasang roda, menguji rem, dan mengemas unit. Setiap langkah membutuhkan sumber daya tertentu, seperti mesin khusus atau teknisi terlatih. Master Planning bekerja mundur dari tanggal pengiriman yang diminta pelanggan. Jika klien membutuhkan sepeda pada hari Jumat, perakitan mungkin harus selesai pada hari Kamis, komponen harus sudah disiapkan pada hari Senin, dan pesanan pembelian untuk roda mentah harus dikirim beberapa minggu sebelumnya karena waktu tunggu pemasok.

Ketika sistem mengidentifikasi bahwa pasokan yang ada tidak mampu memenuhi permintaan berjenjang ini, sistem akan menghasilkan apa yang kami sebut pesanan terencana. Pesanan ini dapat berupa pesanan pembelian terencana untuk dibeli dari vendor, pesanan produksi terencana untuk dibuat secara internal, atau pesanan transfer terencana untuk memindahkan stok antarfasilitas. Yang penting, pesanan terencana selalu berupa saran, bukan perintah otomatis. Perencana meninjau rekomendasi ini untuk memastikan vendor, tanggal, dan kapasitasnya masuk akal sebelum menyetujui pekerjaan tersebut.

Kesimpulan: Mengendalikan Rantai Pasok Anda

Melampaui penghitungan stok dasar tidak lagi sekadar kemewahan bagi perusahaan multinasional besar; ini adalah kebutuhan operasional mutlak bagi setiap bisnis yang menangani permintaan pelanggan yang kompleks, manufaktur berjenjang, dan tenggat pengiriman yang ketat. Mengandalkan spreadsheet statis dan laporan stok sederhana membuat organisasi Anda rentan terhadap hambatan mendadak, tenggat yang terlewat, dan biaya penyimpanan yang membengkak. Dengan menghubungkan kuantitas dengan tanggal kalender, kapasitas produksi, bill of materials, dan waktu tunggu pemasok, alat perencanaan modern mengubah data mentah menjadi peta jalan yang jelas dan dapat ditindaklanjuti untuk seluruh tim Anda.

Jika Anda ingin mendalami konsep-konsep ini dan mendengar contoh nyata tentang bagaimana perencanaan sumber daya perusahaan (ERP) mengubah rantai pasok modern, pastikan untuk menyimak episode podcast lengkap kami, Dynamics 365 Master Planning - Simply Explained. Menguasai rantai pasok Anda dimulai dengan memahami alat yang tersedia, dan langkah berikutnya akan memastikan bisnis Anda selalu siap menghadapi apa pun yang diminta pelanggan selanjutnya.

Entities in this article

Dynamics 365 Container

Related articles

RSS