Simulasi Produksi untuk Gangguan dan Perubahan Bauran Produk

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-12

Simulasi produksi untuk gangguan: uji kerusakan mesin, ketidakhadiran operator, keterlambatan material, dan perubahan bauran produk dalam model sebelum semuanya memengaruhi lini Anda. Panduan praktis.

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

Simulasi produksi memungkinkan Anda memutar ulang sebuah gangguan dalam model: mesin rusak di bottleneck, operator yang tidak hadir, pengiriman yang terlambat, atau pergeseran bauran produk. Anda kemudian melihat dampaknya terhadap output dan lead time tanpa menyentuh lini produksi yang sebenarnya. Artikel ini ditujukan bagi perencana produksi yang ingin tahu gangguan mana yang perlu disimulasikan, data apa yang dibutuhkan, dan cara membaca hasilnya.

Poin Penting

• Simulasi produksi memungkinkan Anda memutar ulang gangguan, seperti kerusakan mesin atau pergeseran bauran produk, dalam model dan melihat dampaknya terhadap output dan lead time sebelum gangguan itu terjadi.
• Pilih gangguan berdasarkan kemungkinan dan dampaknya dari catatan Anda sendiri. Memodelkan setiap kemungkinan kejadian hanya membuat model menjadi lebih lambat dan lebih sulit dipercaya.
• Perubahan bauran produk dapat memindahkan bottleneck meskipun total volume tetap sama, karena setiap varian menggunakan mesin bersama dalam durasi yang berbeda.
• Karena kerusakan bersifat acak, jalankan setiap skenario beberapa kali dan bandingkan rentangnya, bukan satu hasil saja.
• Periksa model terhadap periode yang sudah lewat terlebih dahulu, dan simpan daftar singkat skenario gangguan yang Anda jalankan ulang setiap kali proses berubah.

Apa yang dapat ditunjukkan simulasi tentang sebuah gangguan?

Gangguan adalah apa pun yang membuat rencana menjadi keliru: kapasitas yang lebih kecil dari rencana, material yang tidak tersedia, atau permintaan yang terlihat berbeda dari perkiraan. Rencana menjawab "apa yang seharusnya terjadi." Simulasi pabrik menjawab "apa yang terjadi jika ini salah."

NIST menjelaskan simulasi kejadian diskrit sebagai cara untuk menganalisis sistem produksi di bawah skenario dan kondisi yang berbeda, serta untuk mengukur throughput, kapasitas, dan bottleneck. Halaman NIST yang sama juga menyebutkan hambatan utamanya: sulit mendapatkan data peralatan dan proses yang tepat waktu dan akurat. Ingatlah hal ini, karena hal tersebut menentukan seberapa jauh Anda dapat mempercayai hasil apa pun.

Hal paling berguna yang ditunjukkan simulasi adalah di mana dampak sebenarnya jatuh. Berhentinya satu mesin jarang hanya merugikan mesin itu saja. Pekerjaan menumpuk di depannya, membuat stasiun di belakangnya kekurangan pasokan, dan menunda pesanan yang bahkan tidak melewati mesin tersebut. Model membuat rangkaian dampak ini terlihat dalam hitungan menit, bukan minggu-minggu dalam kondisi darurat.

Simulasi juga membantu Anda melihat bahwa bottleneck dapat berpindah. Pengantar Lean Enterprise Institute tentang teori kendala menyatakan bahwa setelah Anda menindaklanjuti kendala, Anda perlu mengevaluasi ulang apakah kendala tersebut telah berpindah ke bagian lain dari sistem. Gangguan melakukan hal yang sama tanpa meminta izin Anda. Jalankan dulu di dalam model.

Gangguan mana yang layak disimulasikan?

Tidak semuanya. Mulailah dengan daftar singkat dan pilih berdasarkan dua pertanyaan: seberapa sering kejadian itu terjadi, dan seberapa besar biayanya ketika terjadi?

Kandidat yang umum:

• Mesin berhenti. Modelkan seberapa sering mesin berhenti dan berapa lama perbaikan memakan waktu. Rata-rata menyembunyikan perbaikan yang berlangsung lama, dan justru itulah yang paling merugikan. Jika log pemeliharaan Anda mencatat durasi henti yang sebenarnya, gunakan sebarannya, bukan hanya nilai rata-ratanya.
• Tenaga kerja. Ketidakhadiran, keterampilan yang kurang pada satu shift, batas lembur.
• Material. Pengiriman yang terlambat, pengiriman yang kurang, atau penahanan kualitas pada lot masuk.
• Kehilangan kualitas. Scrap atau rework yang membuat part kembali melalui satu stasiun.
• Pesanan mendesak. Pesanan yang mendesak melompati antrean dan memaksa setup tambahan.
• Pergeseran permintaan. Porsi varian yang berbeda, atau lonjakan volume.

Gunakan catatan Anda sendiri untuk memeringkatnya. Lihat log downtime tahun lalu, laporan shift, dan daftar pesanan yang terlambat. Jika suatu gangguan muncul setiap bulan, simulasikan. Jika hanya terjadi sekali dalam lima tahun, catat dan kesampingkan dulu.

Bagaimana cara menyimulasikan perubahan product mix?

Product mix adalah porsi setiap varian dalam aliran pesanan Anda. Ini penting karena varian jarang menggunakan mesin bersama dalam durasi yang sama. Ketika mix berubah, beban pada setiap sumber daya ikut berubah, meskipun total jumlah unit tetap sama.

Sebuah makalah dari Winter Simulation Conference tentang interactive manufacturing simulation menunjukkan efek ini di area batch furnace. Produk hanya bisa berbagi satu batch di bawah aturan kombinasi tertentu, sehingga urutan produk memengaruhi pemakaian furnace, dan bottleneck berpindah seiring berubahnya mix. Makalah ini sudah lama dan kasusnya khusus, tetapi pelajarannya berlaku untuk sebagian besar sumber daya bersama.

Berikut cara menelaahnya:

1. Tetapkan baseline. Gunakan mix saat ini dan pastikan model mereproduksi output dan lead time terkini.
2. Definisikan mix baru. Tuliskan sebagai porsi volume, misalnya "varian B tumbuh dari minoritas menjadi setengah dari pesanan." Tentukan apakah total volume tetap atau bertambah.
3. Periksa data per varian. Setiap varian membutuhkan routing, waktu proses, dan waktu setup sendiri. Changeover antarvarian sering kali lebih berpengaruh daripada waktu run.
4. Jalankan mix baru. Bandingkan utilisasi per sumber daya, panjang antrean, dan lead time per varian.
5. Geser mix secara bertahap. Jangan hanya menguji kondisi akhir. Geser dalam beberapa langkah untuk menemukan titik ketika bottleneck berpindah ke sumber daya lain atau ketika lead time mulai naik dengan cepat.
6. Catat apa yang akan Anda ubah. Shift kedua, buffer, aturan urutan yang berbeda, atau alat tambahan di mesin kedua. Kemudian uji perubahan tersebut dalam model yang sama.

Contoh: pemeriksaan kasar (angka hipotetis)

Contoh ini dibuat untuk menunjukkan logikanya. Ini bukan hasil pengukuran.

Sebuah sel memiliki satu mesin milling. Varian A membutuhkan 6 menit di sana dan varian B membutuhkan 10 menit. Saat ini 70% pesanan adalah A dan 30% adalah B. Rata-rata waktu per unit adalah 0,7 × 6 + 0,3 × 10 = 7,2 menit. Dalam shift 450 menit, mesin milling dapat membuat sekitar 62 unit.

Sekarang mix bergeser menjadi 50% A dan 50% B. Rata-rata menjadi 8 menit, dan shift yang sama menghasilkan sekitar 56 unit. Itu sekitar 10% lebih sedikit output hanya karena mix, tanpa gangguan sama sekali.

Tambahkan henti 45 menit. Mesin kini memiliki 405 menit, dan shift menghasilkan sekitar 50 unit. Dua perubahan yang tampak tidak berbahaya itu memangkas sekitar seperlima output.

Perhitungan ini adalah pemeriksaan awal yang baik, dan sebaiknya Anda lakukan sebelum membangun model apa pun. Yang tidak bisa ditunjukkan adalah antrean, setup, aturan batch, henti acak, dan dampak berantai ke stasiun berikutnya. Di situlah simulasi berperan.

Data apa yang dibutuhkan skenario?

Skenario gangguan membutuhkan beberapa hal yang mungkin tidak ada dalam model normal. Periksa daftar ini sebelum Anda menjanjikan hasil.

• Riwayat henti per mesin: seberapa sering berhenti dan berapa lama setiap henti berlangsung, diambil dari log pemeliharaan atau downtime.
• Kalender kerja dan keterampilan: siapa yang dapat menjalankan stasiun mana, dan apa yang terjadi pada shift yang lebih pendek.
• Waktu setup dan changeover antarvarian, bukan hanya waktu run.
• Data pesanan dan tanggal jatuh tempo, sehingga Anda dapat melihat pesanan mana yang meleset, bukan hanya bahwa sesuatu meleset.
• Aturan yang benar-benar diikuti lini saat ini: aturan urutan, batas lembur, dan kapan sebuah pekerjaan dipindahkan ke mesin lain.

Jika ada baris yang hilang, nyatakan itu dalam deskripsi skenario. Hasil yang dibangun di atas durasi henti yang ditebak hanyalah tebakan yang dibungkus grafik yang rapi. Minta tim lini meninjau angkanya. Mereka sering kali dapat memberi tahu Anda dalam dua menit mana yang salah.

Bagaimana cara menjalankan studi gangguan?

Langkahnya sama seperti untuk proyek simulasi apa pun, dengan beberapa poin yang lebih penting untuk gangguan.

1. Tuliskan pertanyaannya. Misalnya: "Jika mesin produksi berhenti selama satu shift penuh, pesanan mana yang terlambat, dan apa respons termurah?"
2. Validasi baseline. Bandingkan output model dengan periode yang sudah lewat. Jika selisihnya besar, perbaiki datanya sebelum Anda menambahkan satu pun gangguan.
3. Tentukan sejumlah kecil skenario. Tiga sampai lima sudah cukup. Beri nama pada setiap skenario, dan catat apa yang berubah serta berapa lama perubahan itu berlangsung.
4. Jalankan setiap skenario beberapa kali. Kerusakan mesin bersifat acak, sehingga satu kali jalan bisa tampak lebih baik atau lebih buruk dari biasanya. Bandingkan rentang hasilnya, bukan satu angka tunggal.
5. Uji respons. Lembur, memindahkan pekerjaan ke mesin lain, mengubah urutan, atau menggunakan stok. Studi gangguan tanpa opsi respons hanya memberi tahu Anda bahwa segala sesuatu bisa salah.
6. Sepakati aturan keputusan. Sebelum menjalankan model, tentukan hasil seperti apa yang akan membuat Anda bertindak. Jika tidak, angka-angkanya hanya akan terus diperdebatkan.

Simpan skenario dalam daftar singkat yang dapat dijalankan ulang ketika proses berubah. Pustaka skenario lebih berharga daripada studi tunggal mana pun.

Di mana posisi alat Microsoft?

Sistem ERP Anda biasanya menjadi tempat rute produksi (routing), daftar bahan (bill of materials), dan kalender kerja disimpan. Itu sebabnya ERP menjadi sumber alami untuk data dasar model. Modelnya sendiri biasanya merupakan perangkat lunak terpisah.

Untuk menampilkan hasil, Power BI cocok untuk membandingkan skenario secara berdampingan. Microsoft Learn juga mendokumentasikan parameter what-if: variabel yang dapat disesuaikan, yang diubah pembaca laporan dengan slicer sehingga laporan dihitung ulang. Ini berguna untuk perhitungan sederhana seperti contoh di atas, misalnya mengubah porsi bauran produk dan melihat angka kapasitas berubah. Microsoft menyatakan bahwa parameter ini dirancang untuk measure di visual. Parameter ini tidak mensimulasikan antrean, jadi jangan keliru menganggap slider what-if sebagai simulasi.

Kesalahan umum

• Mensimulasikan segalanya. Terlalu banyak skenario membuat model lambat dan hasilnya sulit dijelaskan.
• Hanya menggunakan rata-rata waktu perbaikan. Henti produksi yang panjang justru paling banyak menimbulkan kerugian.
• Hanya menguji kondisi akhir dari perubahan bauran produk. Bottleneck sering kali berpindah di tengah jalan.
• Melewatkan pemeriksaan baseline. Jika model tidak dapat mereproduksi bulan lalu, hasil gangguannya hanyalah tebakan.
• Hanya memercayai satu kali jalan. Dengan kejadian acak, satu kali jalan bisa menyesatkan.
• Melupakan faktor manusia. Ketidakhadiran, keterampilan, dan batas lembur harus dimasukkan ke dalam model ketika gangguannya berkaitan dengan staf.
• Membangun model sekali pakai. Model yang tidak diperbarui setelah perubahan proses berikutnya akan usang dalam hitungan bulan.

Di mana posisi Polaris?

Jika pertanyaan Anda berkaitan dengan kapasitas, staf, buffer, atau bauran produk, iFAKT Polaris bisa menjadi salah satu opsi untuk dipertimbangkan. iFAKT menggambarkan Polaris sebagai AI plus digital twin untuk produksi, yang menggabungkan data ERP dengan digital twin manufaktur. Modul Polaris Simulator menguji sistem produksi secara virtual, termasuk skenario kapasitas, staf, dan buffer serta bauran produk dinamis pada sumber daya bersama. Modul Polaris Optimizer mendeteksi bottleneck dan, saat terjadi gangguan, menganalisis dampaknya serta mengoptimalkan ulang rencana. Apakah cocok atau tidak bergantung pada data dan pertanyaan Anda, jadi cobalah dulu pada satu kasus yang sempit.

Topik terkait untuk dieksplorasi

• Memberi model data langsung. Digital twin menjaga model tetap terhubung dengan pabrik. Tentukan dulu apakah keputusan Anda membutuhkan aliran data langsung atau cukup model yang baik.
• Memodelkan respons manusia. Reaksi yang tertunda dan pergantian shift mengubah lamanya gangguan, jadi tambahkan keduanya ketika staf menjadi bagian dari pertanyaan.
• Pemulihan dan restart. Setelah gangguan berakhir, backlog akan membebani lini produksi. Simulasikan proses restart, termasuk batas lembur.
• Menutup lingkaran dengan perencanaan. Begitu gangguan benar-benar terjadi, jadwal harus berubah. Pikirkan bagaimana hasil simulasi menjadi masukan untuk perencanaan ulang.

Langkah berikutnya

Gangguan produksi lebih mudah ditangani jika Anda memulai dari catatan downtime Anda sendiri. Pilih satu gangguan yang paling merugikan Anda tahun lalu, tuliskan sebagai skenario satu kalimat dengan durasi dan sumber daya yang terdampak, lalu uji dalam sebuah model, meskipun masih kasar, sebelum rapat perencanaan berikutnya.