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

Blog · Mirko Peters

Pelacakan KPI Simulasi Manufaktur: Membandingkan Skenario Secara Adil

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 ·

Pelacakan KPI simulasi manufaktur dimulai dengan beberapa KPI yang didefinisikan sesuai cara pabrik Anda mendefinisikannya. Pelajari cara menjalankan skenario, membaca hasil, dan melaporkannya.

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

Pelacakan KPI simulasi manufaktur berarti memilih sejumlah kecil indikator kinerja sebelum model dibangun, menghitungnya di dalam model persis seperti pabrik menghitungnya, lalu membandingkan skenario berdasarkan angka-angka tersebut. Jika definisi di model dan di pabrik berbeda, hasilnya tidak dapat dipercaya, seindah apa pun dashboard-nya. Artikel ini ditujukan untuk manajer pabrik dan insinyur proses yang menjalankan studi simulasi, atau yang harus membaca hasilnya dan mengambil keputusan berdasarkan hasil tersebut.

Poin Penting

  • Pelacakan KPI simulasi berarti memilih beberapa KPI sebelum model dibangun dan menghitungnya persis seperti pabrik menghitungnya.
  • ISO 22400-2 menunjukkan disiplin yang dimaksud: setiap KPI dijelaskan melalui rumusnya, elemen-elemennya, perilaku waktunya, dan satuannya.
  • Satu run simulasi hanyalah satu sampel, jadi gunakan beberapa replikasi dan laporkan rata-rata beserta selang kepercayaan.
  • Ubah satu hal per skenario, bandingkan skenario menggunakan definisi KPI yang sama, dan periksa baseline terhadap periode historis nyata terlebih dahulu.
  • Hasil simulasi bukan data langsung, sehingga dashboard yang memakainya harus di-refresh setelah setiap kelompok run dan diberi label menurut skenario.

Apa itu pelacakan KPI simulasi manufaktur?

Model simulasi menghasilkan banyak keluaran mentah: setiap part, setiap waktu tunggu, dan setiap status mesin sepanjang waktu simulasi. Pelacakan KPI mengubah keluaran tersebut menjadi sejumlah kecil angka yang dapat dibandingkan. Jika simulasi pabrik menjawab pertanyaan "apa yang terjadi jika kita mengubah ini?", KPI menjelaskan seberapa besar dampaknya, dalam istilah yang sudah digunakan pabrik.

Ada dua cara hal ini bisa salah. Pertama, tim mengukur apa yang paling mudah diambil dari perangkat lunak model dan berakhir dengan angka yang tidak dikenali siapa pun di pabrik. Kedua, tim menyalin daftar KPI panjang dari template dashboard, dan studi tersebut tenggelam dalam angka-angka yang tidak berhubungan dengan keputusan.

Solusinya sama untuk kedua kasus. Mulailah dari keputusan, misalnya "apakah kita menambah shift kedua di lini perakitan atau membeli mesin kedua?", lalu tanyakan angka mana yang membuat Anda memilih satu opsi dibanding yang lain. Itulah KPI Anda.

KPI apa saja yang layak dimasukkan dalam studi simulasi?

Jaga daftarnya tetap singkat. Lima sampai tujuh sudah cukup. Berikut pilihan yang umum, dan mana yang penting bergantung pada pertanyaan Anda:

  1. Throughput. Jumlah unit baik yang keluar per jam, shift, atau minggu.
  2. Lead time. Berapa lama sebuah pesanan atau part membutuhkan waktu dari pelepasan hingga selesai.
  3. Work in process (WIP). Jumlah barang yang berada di dalam sistem pada waktu tertentu. Angka ini sering bergerak bersama lead time.
  4. Pemanfaatan sumber daya. Seberapa besar waktu tersedia yang digunakan mesin dan tenaga kerja untuk bekerja. Perhatikan bottleneck dan sumber daya di sebelahnya.
  5. Waktu tunggu dan panjang antrean di depan bottleneck.
  6. Pengiriman tepat waktu, jika model memasukkan tanggal jatuh tempo.
  7. OEE, jika kerugian peralatan menjadi batasan.

Soal OEE, jadilah spesifik. Lean Enterprise Institute menjelaskan overall equipment effectiveness sebagai metrik total productive maintenance yang mengalikan tingkat ketersediaan, kinerja, dan kualitas. Lembaga tersebut biasanya menetapkan target untuk enam kerugian utama: kegagalan, penyesuaian, henti kecil, penurunan kecepatan, scrap, dan rework. OEE hanya masuk akal dalam simulasi jika model memuat kerugian-kerugian tersebut, misalnya perilaku kerusakan mesin, changeover, dan tingkat scrap. Jika tidak, angka OEE dari model hanyalah tebakan yang diberi koma desimal. Pada lini multi-produk dengan changeover yang panjang, OEE juga bisa menyembunyikan faktor pendorong biaya dan pengiriman, sehingga pasangkanlah dengan lead time atau on-time delivery.

Hindari KPI yang tidak bisa dipengaruhi oleh model. Jika skenario Anda mengubah pola shift, skor kepuasan pelanggan tidak punya tempat dalam studi ini.

Bagaimana Anda mendefinisikan KPI agar model dan pabrik sepakat?

Buatlah lembar KPI satu halaman sebelum run pertama. Untuk setiap KPI, nyatakan:

  • nama dan pertanyaan yang dijawabnya,
  • rumus dan elemen-elemennya,
  • dasar waktunya, misalnya per shift, per minggu kalender, atau per jam produksi terencana,
  • satuannya,
  • dari mana nilai riil di pabrik berasal,
  • siapa yang memiliki definisi tersebut.

Inilah disiplin yang diikuti standar di bidang ini. Halaman ISO untuk ISO 22400-2, yang mendefinisikan key performance indicator untuk manajemen operasi manufaktur, menyebutkan bahwa setiap KPI dijelaskan melalui rumus dan elemennya, perilaku waktunya, satuan atau dimensinya, kelompok penggunanya, serta metodologi produksi tempat KPI tersebut berada. Halaman yang saya baca menggambarkan draf edisi kedua yang akan menggantikan versi 2014, jadi periksa edisi terkini jika Anda berencana mengutip standar ini. Anda tidak harus mengadopsi standar ini untuk mendapat manfaat dari kebiasaannya: satu definisi yang presisi untuk setiap KPI.

Sebagian besar perbedaan pendapat berasal dari waktu. "Availability" berubah tergantung jawaban atas pertanyaan "tersedia dari apa?". Deskripsi LEI tentang OEE mengukur waktu henti akibat kerusakan dan changeover relatif terhadap waktu terjadwal, sehingga waktu terjadwal harus didefinisikan dengan jelas dalam lembar Anda. Apakah termasuk pemeliharaan terencana? Waktu istirahat? Shift yang menurut kalender libur? Selesaikan hal ini sebelum model dibangun, karena hal ini memengaruhi setiap hasil.

Lalu lakukan pemeriksaan yang memberi nilai pada lembar tersebut: hitung KPI yang sama dari suatu periode nyata di masa lalu menggunakan data pabrik, lalu bandingkan dengan hasil model ketika Anda memasukkan periode tersebut.

Bagaimana menjalankan skenario dan membaca hasilnya?

Satu run simulasi adalah sampel acak. Kerusakan, waktu kedatangan, dan waktu proses bervariasi, sehingga dua run dari skenario yang sama memberi dua jawaban berbeda. Anggaplah satu run sebagai anekdot.

  1. Validasi baseline. Jalankan model untuk periode yang Anda ketahui, lalu bandingkan KPI-nya dengan kenyataan. Jika model tidak dapat mereproduksi masa lalu dalam rentang yang dapat Anda terima, perbaiki model sebelum menguji perubahan apa pun.
  2. Gunakan replikasi. Jalankan setiap skenario beberapa kali dengan aliran acak yang independen. Kuliah MIT tentang simulation experiment design menjelaskan penetapan jumlah replikasi berdasarkan target presisi: Anda terus menjalankan replikasi hingga confidence interval cukup sempit relatif terhadap estimasi. Kuliah tersebut juga mencatat bahwa dengan kurang dari 30 replikasi, interval dihitung menggunakan distribusi Student-t.
  3. Tangani warm-up. Untuk pabrik yang beroperasi terus-menerus, model dimulai dalam keadaan kosong dan membutuhkan waktu untuk mencapai operasi normal. Kuliah yang sama menjelaskan pembuangan bagian awal dari setiap replikasi dan menyebutkan metode Welch untuk memilih berapa banyak yang dibuang. Jika pertanyaan Anda menyangkut periode tertentu, misalnya satu batch order, mulailah model dalam kondisi yang dimiliki pabrik pada waktu tersebut.
  4. Ubah satu hal per skenario. Jika skenario B menambah mesin sekaligus mengubah pola shift dan ukuran batch, Anda tidak akan tahu mana yang menghasilkan dampak apa.
  5. Laporkan rentang. "Throughput naik 4% hingga 9%" lebih jujur daripada "naik 6,5%". Jika interval dua skenario saling tumpang tindih secara signifikan, nyatakan bahwa data tidak dapat membedakan keduanya.
  6. Lihat seluruh alur. Peningkatan di satu mesin bisa memindahkan hambatan ke tempat lain. Periksa utilisasi dan antrean di sepanjang alur, bukan hanya di stasiun yang Anda ubah.

Simpan register skenario: daftar yang berisi nama skenario, apa yang diubah, asumsi, jumlah replikasi, dan tanggalnya. Tanpa itu, tidak ada yang akan ingat enam bulan lagi mengapa skenario 7 dipilih.

Bagaimana cara menampilkan KPI simulasi kepada manajer?

Manajer membutuhkan perbandingan, bukan keluaran mentah. Halaman sederhana sudah cukup: baseline dan setiap skenario ditampilkan berdampingan, untuk beberapa KPI yang sama, lengkap dengan rentangnya, serta catatan tentang apa yang diubah pada setiap skenario.

Dalam lingkungan Microsoft, jalur yang umum adalah tabel hasil yang dimuat ke Power BI. Setiap baris memuat skenario, replikasi, nama KPI, dan nilainya, sehingga Anda dapat membangun perbandingan dan memfilter berdasarkan skenario. Dokumentasi Microsoft tentang penyegaran data menjelaskan bahwa data impor dalam model semantik adalah salinan pada titik waktu tertentu, sehingga Anda perlu menyegarkannya untuk melihat data baru. Untuk hasil simulasi, ini sangat sesuai: Anda melakukan penyegaran setelah sekumpulan proses dijalankan, bukan sebelumnya.

Ada dua poin praktis yang mengikuti:

  • Beri tanda pada setiap visual sebagai hasil skenario, beserta tanggal proses terakhir. Angka prakiraan yang berdampingan dengan angka pabrik secara langsung dapat menimbulkan salah tafsir.
  • Tampilkan rencana versus realisasi nanti, saat perubahan sudah diterapkan, dengan menggunakan definisi KPI yang sama. Di situlah lembar KPI memberikan manfaatnya.

Jika Anda ingin tampilan langsung pabrik di samping model, itu adalah pekerjaan terpisah dengan umpan data sendiri. Anggap itu sebagai fase berikutnya, setelah KPI simulasi dipercaya.

Bagaimana cara menjaga model tetap akurat dari waktu ke waktu?

Model yang tepat pada Maret bisa keliru pada September, karena prosesnya sudah berubah.

  • Kalibrasi ulang. Bandingkan KPI model dengan KPI aktual setiap kuartal, atau setelah perubahan besar apa pun, dan sesuaikan input jika terjadi penyimpangan.
  • Pastikan ada pemilik untuk setiap input. Waktu siklus, waktu setup, perilaku kegagalan, dan kalender shift memerlukan pemilik yang jelas untuk memperbaruinya. Perlakukan data simulasi seperti produk yang memiliki pengelola.
  • Sertakan faktor manusia jika relevan. Operator dapat mengubah hasil melalui ketidakhadiran, keterampilan, dan variasi kecepatan kerja. Anda tidak perlu memodelkan kelelahan untuk melihat hal ini: menggunakan variasi waktu siklus yang realistis dan jumlah personel nyata per shift sudah membawa Anda sebagian besar jalan. Tanyakan kepada kepala shift apakah asumsi model tampak tepat.
  • Tinjau kembali target. Jangan membawa tolok ukur dari pabrik lain ke dalam model Anda tanpa memastikan kesesuaiannya dengan bauran produk Anda. Gunakan baseline Anda sendiri terlebih dahulu.

Kesalahan umum

  • Dimulai dari dasbor. Tentukan KPI dan pertanyaannya terlebih dahulu.
  • Terlalu banyak KPI. Halaman dengan dua puluh angka tidak akan dibaca.
  • Definisi berbeda antara model dan pabrik. Dengan begitu, tidak ada perbandingan yang mungkin dilakukan.
  • Satu kali proses per skenario. Faktor acak akan menentukan kesimpulan Anda untuk Anda.
  • Melewatkan pemeriksaan baseline. Jika model tidak dapat mereproduksi masa lalu, prakiraannya tidak memiliki dasar.
  • Mengubah beberapa hal sekaligus dalam setiap skenario. Anda tidak akan mengetahui penyebabnya.
  • Menampilkan prakiraan sebagai data langsung. Beri label yang jelas pada hasil skenario.
  • Tidak ada pemilik untuk input model. Input yang usang menghasilkan jawaban yang salah tetapi terlihat meyakinkan.

Di mana Polaris cocok

Untuk studi semacam ini, iFAKT Polaris menawarkan dua modul yang patut dipertimbangkan. iFAKT menggambarkan Polaris Simulator sebagai alat yang menguji sistem produksi secara virtual sebelum keputusan nyata diambil, dengan skenario kapasitas, personel, dan buffer, serta menampilkan hambatan dan ketidakseimbangan utilisasi dari waktu ke waktu. Polaris Analyzer menyediakan dasbor KPI lintas modul dan membandingkan nilai rencana dengan nilai aktual. Seperti alat lainnya, pastikan definisi KPI di dalamnya sesuai dengan definisi Anda, dan coba terlebih dahulu pada satu lini produksi.

Topik terkait untuk dijelajahi

  • Hierarki KPI. Cara nilai lini, shift, departemen, dan pabrik dijumlahkan ke atas tanpa menghitung ulang di setiap tingkat.
  • Sumber data untuk model. Data ERP, mesin, dan manual mana yang menjadi masukan model, serta cara memeriksa kualitasnya.
  • Normalisasi antarpabrik. Cara membandingkan lokasi dengan tingkat otomatisasi yang berbeda tanpa merugikan pabrik dengan variasi produk yang tinggi.
  • Variasi tenaga kerja dalam model. Efek operator dan shift mana yang layak dimodelkan, dan mana yang hanya menambah kompleksitas tanpa manfaat.
  • Dari rencana ke realisasi. Cara membandingkan skenario yang dipilih dengan KPI nyata setelah perubahan diterapkan.

Langkah berikutnya

Pelacakan KPI simulasi manufaktur membuahkan hasil ketika model dan pabrik berbicara dengan angka yang sama. Ambil pertanyaan simulasi Anda berikutnya, susun lembar KPI satu halaman dengan rumus, dasar waktu, dan satuannya, lalu periksa terhadap periode nyata di masa lalu sebelum Anda menjalankan skenario pertama.

Entities in this article

Factory simulation Overall equipment effectiveness (OEE) Power BI Polaris Simulator Polaris Analyzer iFAKT GmbH

Related articles

RSS

Disponsori

iFAKT GmbH