Micro-Stop di Produksi: Cara Menemukan dan Menguranginya

By Mirko Peters · 2026-11-11

Micro-stop di produksi adalah gangguan singkat yang tidak pernah dicatat, tetapi diam-diam menghabiskan berjam-jam waktu produksi. Pelajari cara menghitungnya, memeringkat penyebabnya, dan menghilangkannya.

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

Micro-stop di produksi adalah gangguan sangat singkat, biasanya diatasi operator dalam satu atau dua menit, dan tidak pernah dicatat. Masing-masing tampak tidak berbahaya. Namun secara kumulatif, dampaknya bisa menghilangkan produktivitas lebih besar daripada kerusakan besar yang selama ini menjadi perhatian semua orang. Panduan ini ditujukan bagi manajer produksi yang mencurigai adanya kerugian tersembunyi di lini mereka. Anda akan mempelajari apa itu micro-stop, cara membuatnya terlihat, cara memeringkat penyebabnya, dan cara menghilangkan penyebab terbesarnya.

Poin Penting

• Micro-stop adalah gangguan sangat singkat yang langsung diatasi operator, sehingga biasanya tidak tercatat meskipun akumulasinya menimbulkan kerugian besar.
• Dalam OEE, micro-stop dihitung sebagai kerugian kinerja, bukan kerugian ketersediaan, sehingga angka ketersediaan yang baik dapat menyembunyikannya.
• Pencatatan downtime secara manual sering kali sangat tidak akurat, dan penghitungan otomatis dari sinyal mesin adalah cara paling andal untuk melihat henti singkat.
• Hitung henti per jam dan per penyebab, peringkatkan dalam diagram Pareto, lalu perbaiki penyebab paling sering yang memiliki ide perbaikan konkret.
• Sebagian besar perbaikan micro-stop bersifat kecil dan fisik, seperti pemandu, posisi sensor, permukaan yang dibersihkan, atau perubahan umpan, dan operator biasanya sudah mengenalinya.

Apa itu micro-stop, dan mengapa tetap tersembunyi?

Micro-stop dikenal dengan beberapa nama: minor stoppages, small stops, brief stops, idling, dan minor stops. Deskripsi OEE.com tentang enam kerugian besar mencantumkan "idling and minor stops" sebagai salah satu dari enam kerugian tersebut. Di sana dijelaskan bahwa kasus tipikalnya berlangsung satu atau dua menit, diselesaikan oleh operator, dan biasanya jauh di bawah lima menit. Disebutkan juga bahwa batas antara small stop dan kegagalan bersifat fleksibel dan sebaiknya mengikuti kebijakan pelacakan alasan Anda.

Contoh tipikal adalah part yang macet di chute, label yang salah umpan, film yang tergelincir, photo-eye yang kotor, atau robot yang menunggu part yang tidak kunjung datang. Pada lini konveyor, efek yang sama muncul sebagai blocking dan starving. Antrean yang penuh menghentikan stasiun di hulu selama beberapa detik, dan antrean yang kosong menghentikan stasiun di hilir. Sensor yang rusak atau part yang miring adalah penyebab lain yang sering terjadi.

Operator memperbaikinya dan lini kembali berjalan. Karena perbaikannya cepat, tidak ada yang memanggil pemeliharaan dan tidak ada yang masuk ke log downtime. Tiga alasan membuat kejadian ini tetap tersembunyi. Operator fokus menjaga lini tetap berjalan, bukan menulis catatan. Formulir kertas tidak memiliki kolom untuk kejadian 20 detik. Sebagian besar laporan juga menetapkan ambang mulai dari beberapa menit, sehingga kejadian yang lebih singkat tidak muncul di grafik.

Sebuah micro-stop oleh karena itu lebih ditentukan oleh ukuran dan sifatnya yang tidak terlihat daripada oleh penyebabnya. Jika berlangsung cukup lama sehingga operator perlu memasukkan alasan, maka itu adalah downtime. Jika lebih singkat, Anda membutuhkan cara lain untuk melihatnya. Beberapa pabrik memperlakukan penghentian 30 detik sebagai henti produksi, dan kemacetan 2 menit sebagai downtime. Batas kelas tersebut kurang penting dibandingkan menggunakan batas yang sama pada setiap shift.

Micro-stop di produksi dan angka OEE Anda

Dalam OEE, henti singkat merupakan kerugian kinerja. Halaman OEE.com tentang faktor OEE mendefinisikan kerugian kinerja sebagai segala hal yang membuat proses berjalan di bawah kecepatan maksimumnya saat sedang berjalan, termasuk siklus lambat dan henti kecil. Ketersediaan, sebaliknya, mencakup henti yang cukup lama sehingga operator dapat mencatat alasannya, biasanya beberapa menit.

Hal ini penting untuk cara Anda membaca hasil OEE Anda. Sebuah lini dapat melaporkan ketersediaan 90 persen dan tetap kehilangan banyak output. Jika faktor kinerja rendah dan tidak ada yang tahu penyebabnya, micro-stop adalah tersangka pertama. Vorne, vendor perangkat lunak OEE, menulis bahwa siklus lambat dan henti kecil sering kali menjadi sumber hilangnya waktu yang lebih besar dibandingkan alasan henti individual. Itu merupakan pernyataan vendor, jadi periksalah terhadap data Anda sendiri. Metode di bawah ini melakukan hal tersebut.

Cara menemukan micro-stop dan memeringkatnya dalam diagram Pareto

Vorne juga menyatakan bahwa pencatatan henti secara manual sering kali sangat tidak akurat, dan lembar manual melewatkan kejadian yang lebih singkat. Panduannya tentang pelacakan henti merekomendasikan pengumpulan data otomatis dan mencatat bahwa otomatisasi menangkap henti yang lebih singkat yang mudah terlewat. Ikuti langkah-langkah berikut.

1. Pilih satu lini yang Anda curigai, biasanya bottleneck atau mesin dengan faktor kinerja rendah.
2. Tentukan kejadiannya. Tuliskan henti terpendek yang Anda hitung, misalnya 10 detik. Tuliskan batas di atas mana henti tersebut dianggap downtime, misalnya 5 menit.
3. Tangkap sinyalnya. Gunakan sinyal run, penghitung part, atau sensor sederhana, misalnya dari PLC (programmable logic controller) yang menjalankan peralatan. Sistem manufacturing execution atau data logger dapat menyimpan setiap kejadian beserta cap waktunya. Tanpa sistem apa pun, gunakan lembar tally operator selama dua minggu sebagai gambaran awal.
4. Tambahkan alasan. Biarkan operator memilih alasan setelah mesin dinyalakan kembali, dari daftar singkat. Vorne menyarankan tidak lebih dari 25 alasan, semuanya dapat ditindaklanjuti, dan menggambarkan gejala, bukan akar penyebab.
5. Hitung frekuensi, bukan hanya menit. Catat jumlah kejadian per jam dan total waktu per penyebab.
6. Urutkan penyebabnya dalam diagram Pareto, yaitu diagram batang yang diurutkan dari yang terbesar ke terkecil dengan garis kumulatif.

Perhatikan waktu dalam sehari, shift, produk, batch material, dan waktu siklus tepat sebelum kejadian. Jika lini melambat sebelum setiap kejadian, kemungkinan ada part yang aus atau sensor yang rusak. Pola akan cepat terlihat: kejadian yang berkelompok setelah changeover, pada satu produk tertentu, atau dengan material dari satu pemasok.

Cara mengurangi henti kecil dan kerugian yang ditimbulkannya

Pilih penyebab yang paling sering atau paling besar dan memiliki ide perbaikan yang konkret. Saran Vorne adalah memusatkan perhatian terlebih dahulu pada kerugian terbesar yang timnya memiliki ide konkret, dengan menggunakan siklus pelacakan, pemilihan, dan perbaikan. Kemudian:

• Tanyakan kepada operator. Mereka menangani gangguan ini setiap hari dan biasanya mengetahui penyebabnya.
• Datangi lantai produksi dan amati. Rekam dengan ponsel jika kejadiannya terlalu cepat untuk dilihat. Tanyakan mengapa itu terjadi, lalu tanyakan lagi mengapa. Inilah analisis akar penyebab dalam bentuk paling sederhana.
• Perbaiki penyebabnya, bukan hanya penanganannya. Pemandu yang lebih lebar, posisi sensor yang lebih baik, permukaan yang dibersihkan, sudut umpan yang diubah, atau alat yang lebih baik adalah perbaikan yang umum. Masing-masing berskala kecil.
• Hilangkan kesalahan dari desainnya. Jika sebuah part dapat macet karena masuk dalam posisi miring, tambahkan pemandu agar hal itu tidak mungkin terjadi. Inilah gagasan di balik poka-yoke, pencegahan kesalahan.
• Tambahkan rutinitas ke daftar periksa. Dalam total productive maintenance, operator membersihkan dan memeriksa peralatan mereka, yang sering kali menghilangkan penyebab henti kecil yang berulang.
• Periksa bottleneck terlebih dahulu. Gangguan di bottleneck mengurangi throughput seluruh lini. Kejadian yang sama di stasiun dengan kapasitas cadangan mungkin hampir tidak berdampak apa pun.
• Ukur ulang. Pastikan jumlah kejadian untuk penyebab tersebut menurun, lalu lihat penyebab berikutnya.

Contoh: berapa biaya 70 henti singkat dalam satu shift

Ini adalah perhitungan ilustratif, bukan hasil pengukuran. Sebuah lini pengemasan berjalan 450 menit per shift. Siklus ideal adalah 20 detik, sehingga output ideal adalah 450 dikali 60 dibagi 20, yaitu 1.350 unit.

Sebuah logger mencatat 70 kejadian per shift, dengan rata-rata 40 detik per kejadian. Itu berarti 70 kali 40, atau 2.800 detik, sekitar 47 menit waktu yang hilang dan tidak tercatat di laporan mana pun, atau 10 persen dari waktu produksi. Dengan waktu 20 detik per unit, 47 menit tersebut setara dengan sekitar 140 unit yang seharusnya bisa dibuat oleh lini produksi.

Tim mengurutkan penyebabnya:

• Film tergelincir di pembungkus: 28 kejadian
• Produk macet di infeed: 21 kejadian
• Salah umpan label: 12 kejadian
• Sensor kotor: 6 kejadian
• Lainnya: 3 kejadian

Film tergelincir dan macet di infeed bersama-sama berjumlah 49 dari 70 kejadian, atau 70 persen. Tim memulai dari dua penyebab tersebut. Jika sebuah pemandu di infeed menghilangkan seluruh 21 kemacetan, lini produksi akan memperoleh tambahan 21 kali 40 detik, yaitu 14 menit per shift. Angkanya hanyalah ilustrasi, tetapi metodenya tetap berlaku dengan data hitungan yang nyata.

Kesalahan umum

• Hanya menghitung henti yang panjang. Jika log baru mulai dari lima menit, Anda sama sekali tidak bisa melihat henti-henti mikro.
• Membiarkan operator mengetik alasan secara manual saat kejadian berlangsung. Memulai kembali mesin adalah prioritas. Tangkap kejadian secara otomatis dan tambahkan alasannya belakangan.
• Daftar alasan yang terlalu panjang. Operator akan memilih "lainnya" ketika daftarnya membingungkan.
• Menyalahkan operator. Henti mikro adalah sinyal tentang peralatan atau material. Perlakukan sebagai data.
• Mengatasi gejala dengan membersihkan lebih cepat. Pembersihan yang lebih cepat memperpendek gangguan, tetapi gangguan itu tetap terjadi.
• Mengejar kejadian terlama alih-alih yang paling sering. Periksa jumlah kejadian sekaligus menitnya.

Bagaimana perangkat lunak dapat membantu

Sistem eksekusi manufaktur atau data logger dapat mencatat setiap gangguan dari sinyal mesin, lengkap dengan cap waktu, sehingga kejadian singkat tidak lagi luput dari perhatian. Sistem ini kemudian dapat meminta operator memasukkan alasan setelah mesin dinyalakan kembali, mengklasifikasikan penyebabnya, dan menampilkan frekuensi serta durasi per shift, produk, dan jam di dasbor. Cara ini menggantikan lembar tally manual dan memberikan gambaran real-time tentang jumlah kejadian per jam. Analitik yang sama nantinya juga dapat menjadi masukan bagi pemeliharaan prediktif. Sistem ini tidak menggantikan kunjungan langsung ke lini produksi, karena data memberi tahu Anda seberapa sering dan kapan, sedangkan hanya lini produksi yang bisa memberi tahu mengapa.

Langkah berikutnya

Pilih lini dengan faktor kinerja terlemah dan catat setiap gangguan yang lebih lama dari beberapa detik selama dua minggu. Setelah itu, urutkan penyebabnya dan mulai dari yang teratas. Ini adalah cara tercepat untuk menangani henti mikro dalam produksi.