Downtime mesin: cara mencatat, menganalisis, dan menguranginya

Pengertian downtime mesin

Downtime mesin adalah waktu ketika mesin tidak berproduksi padahal menurut rencana seharusnya berproduksi. Mesin injeksi yang berhenti 40 menit karena heater cetakan rusak, lini pengemasan yang menunggu karton, atau kompresor yang mati di tengah shift malam sehingga seluruh lini pneumatik ikut berhenti: semuanya downtime, meskipun penyebabnya sangat berbeda.

Kata kuncinya adalah seharusnya berproduksi. Mesin yang diam karena tidak ada pesanan, atau karena pabrik libur, tidak sedang mengalami downtime dalam pengertian ini. Karena itu pengukuran downtime selalu dimulai dari satu acuan: waktu produksi terencana, yaitu waktu yang memang dialokasikan untuk berproduksi setelah dikurangi istirahat dan penghentian lain yang disengaja.

Downtime terencana dan tidak terencana

Downtime terencana adalah penghentian yang dijadwalkan sebelumnya, misalnya istirahat, rapat awal shift, atau pemeliharaan preventif yang sudah dimasukkan ke jadwal produksi. Downtime tidak terencana adalah penghentian yang terjadi di luar rencana: kerusakan, material habis, menunggu operator, atau masalah mutu yang memaksa mesin dihentikan.

Pergantian produk (changeover) berada di wilayah abu-abu. Ia biasanya direncanakan, tetapi durasinya sangat bergantung pada cara kerja tim, dan dalam kerangka OEE ia tetap dihitung sebagai kerugian ketersediaan^[1]. Tidak ada jawaban tunggal yang benar; yang penting adalah keputusan tertulis yang diterapkan sama di semua mesin dan semua shift. Bila changeover kadang dikeluarkan dari perhitungan dan kadang tidak, angka downtime akan bergerak tanpa ada yang berubah di lantai produksi.

Berhenti singkat (minor stop)

Di antara mesin berjalan dan mesin rusak ada wilayah yang sering terlewat: berhenti singkat atau minor stop. Sensor yang tertutup debu, botol yang terguling di konveyor, atau material yang tersangkut di chute membuat mesin berhenti satu atau dua menit, lalu berjalan lagi setelah operator membereskannya. Satu kejadian tampak remeh. Puluhan kejadian per shift tidak remeh sama sekali. Nakajima memisahkan kerugian ini dari kerusakan peralatan dan menggolongkannya sebagai kerugian kecepatan, bukan kerugian ketersediaan^[1].

Posisi downtime dalam OEE

Downtime adalah bahan baku faktor availability dalam OEE. ISO 22400-2 mendefinisikan availability sebagai perbandingan antara waktu produksi aktual dan waktu yang direncanakan untuk unit produksi tersebut^[2]. Dengan kata lain, setiap menit downtime langsung mengurangi pembilang, sementara penyebutnya tetap.

Dari enam kerugian besar (six big losses) yang dirumuskan Nakajima, dua jatuh ke faktor availability: kerusakan peralatan serta penyetelan dan pergantian produk^[1]. Berhenti singkat dan idle masuk ke faktor performance. Pembagian ini bukan sekadar urusan akuntansi. Kerusakan umumnya ditangani tim pemeliharaan, pergantian produk ditangani tim produksi dan engineering, sedangkan berhenti singkat sering berakar pada desain mesin atau mutu material. Mencampur ketiganya dalam satu angka "downtime" membuat tidak jelas siapa yang harus bertindak.

Hansen menekankan bahwa OEE baru berguna untuk perbaikan bila kerugiannya diuraikan sampai ke penyebab yang dapat ditindaklanjuti^[3]. Untuk faktor availability, penguraian itu sepenuhnya bergantung pada mutu pencatatan downtime.

Cara mencatat downtime dengan benar

Sebagian besar masalah analisis downtime sebenarnya adalah masalah pencatatan. Data yang ditulis dari ingatan di akhir shift, dengan durasi yang dibulatkan dan alasan yang ditebak, tidak akan menjadi lebih baik karena dianalisis dengan cermat. Pencatatan yang baik memisahkan dua pertanyaan: kapan dan berapa lama mesin berhenti, yang sebaiknya dijawab oleh mesin, dan mengapa mesin berhenti, yang harus dijawab oleh manusia.

Deteksi berhenti dan mulai secara otomatis

Waktu berhenti dan waktu mulai kembali paling andal dibaca langsung dari mesin: sinyal status dari PLC, penghitung produksi yang berhenti bertambah, atau arus motor yang turun di bawah ambang beban. Dengan cara ini setiap kejadian tercatat dengan stempel waktu yang tepat, termasuk yang terjadi pukul dua dini hari ketika tidak ada yang sempat menulis. Operator tidak lagi diminta mengingat jam, hanya diminta menjelaskan penyebab.

Batas durasi: kapan sebuah berhenti dihitung downtime

Begitu pencatatan otomatis berjalan, muncul pertanyaan praktis: apakah berhenti selama 20 detik perlu diberi alasan? Umumnya tidak. Banyak pabrik menetapkan batas durasi minimum, misalnya lima menit. Berhenti yang lebih pendek dicatat sebagai berhenti singkat dan dijumlahkan secara otomatis, sedangkan berhenti yang lebih panjang dihitung sebagai downtime dan wajib diberi alasan. Angka batasnya bergantung pada karakter mesin; lini pengemasan cepat mungkin memakai batas yang lebih pendek daripada mesin press besar. Yang penting, batas itu ditetapkan sekali, ditulis, dan tidak diubah diam-diam ketika angkanya kurang enak dilihat.

Daftar kode alasan yang pendek

Kode alasan mengubah daftar kejadian menjadi data yang bisa dikelompokkan. Godaan pertama biasanya adalah membuat daftar yang sangat lengkap, dengan puluhan pilihan. Hasilnya justru sebaliknya: operator yang harus menggulir daftar panjang di tengah masalah akan memilih pilihan pertama yang terlihat masuk akal, atau "lain-lain". Struktur dua tingkat bekerja lebih baik. Tingkat pertama berisi sedikit kategori besar yang mudah dipilih; tingkat kedua merinci penyebab yang paling sering terjadi di mesin tersebut.

Siapa yang mengonfirmasi alasan, dan kapan

Alasan paling akurat diberikan oleh orang yang berada di dekat mesin, saat kejadian atau segera sesudahnya. Dalam praktik, operator memilih alasan ketika mesin berhenti atau ketika mesin dijalankan kembali, dan teknisi melengkapi atau mengoreksinya bila perbaikan ternyata menemukan penyebab lain. Supervisor kemudian meninjau kejadian yang belum diberi alasan sebelum shift berakhir. Semakin jauh jarak antara kejadian dan pengisian alasan, semakin besar porsi tebakan di dalam data.

Ukuran downtime yang perlu dipantau

Total menit downtime saja tidak cukup untuk memilih tindakan. Dua mesin dengan total downtime yang sama bisa memiliki masalah yang sangat berbeda: yang satu berhenti dua kali dengan durasi panjang, yang lain berhenti tiga puluh kali dengan durasi pendek. Karena itu ada tiga ukuran yang sebaiknya dibaca bersama.

MTTR, yang juga termasuk indikator dalam ISO 22400-2^[2], adalah jembatan antara data produksi dan data pemeliharaan. Dari sisi produksi, downtime akibat kerusakan dihitung sejak mesin berhenti sampai berjalan kembali. Dari sisi pemeliharaan, waktu itu terurai menjadi menunggu teknisi, mendiagnosis, menunggu suku cadang, memperbaiki, dan menguji. Bila catatan downtime terhubung dengan work order di CMMS, tim dapat melihat bagian mana yang paling panjang.

Angka-angka berikut adalah ilustrasi, bukan data dari pabrik tertentu. Sebuah lini pengemasan bekerja 26 hari dalam sebulan, dua shift per hari, dengan waktu produksi terencana 450 menit per shift. Waktu produksi terencananya 26 × 2 × 450 = 23.400 menit. Dengan batas lima menit, tercatat 60 kejadian downtime.

1. 1Persentase downtime = 1.200 ÷ 23.400 × 100% = 5,1%.
2. 2Availability = (23.400 − 1.200) ÷ 23.400 = 22.200 ÷ 23.400 = 94,9%.
3. 3Rata-rata durasi = 1.200 ÷ 60 = 20 menit per kejadian.
4. 4Waktu pemulihan rata-rata untuk kerusakan mekanis = 156 ÷ 4 = 39 menit, dihitung dari mesin berhenti sampai berjalan kembali. MTTR dalam arti pemeliharaan akan lebih pendek bila sebagian waktu itu dipakai menunggu teknisi.

Perhatikan bahwa urutan menurut durasi dan urutan menurut frekuensi tidak sama. Material tersangkut di konveyor terjadi paling sering, 25 kali, tetapi setiap kejadiannya pendek. Kerusakan mekanis hanya empat kali, tetapi masing-masing paling lama. Kedua jenis masalah ini membutuhkan pendekatan yang berbeda.

Analisis Pareto: memilih alasan yang paling berpengaruh

Juran mempopulerkan prinsip Pareto dalam manajemen mutu: dalam banyak masalah, sebagian kecil penyebab (the vital few) menyumbang sebagian besar dampak, sementara sisanya tersebar di banyak penyebab kecil^[4]. Diagram Pareto menampilkan hal ini secara langsung: alasan diurutkan dari yang terbesar, sehingga mata langsung tertuju ke beberapa batang pertama.

Pada contoh ini, dua alasan teratas menyumbang 720 dari 1.200 menit, atau 60 persen dari seluruh downtime. Tim yang mengerjakan kedua alasan itu menyentuh sebagian besar masalah, sedangkan tim yang membagi perhatiannya rata ke lima alasan akan bergerak lambat di semuanya.

Ada beberapa hal yang membuat diagram Pareto lebih jujur. Buat Pareto berdasarkan durasi dan berdasarkan frekuensi, lalu bandingkan keduanya. Buat per mesin, bukan hanya per pabrik, karena alasan terbesar di satu mesin bisa tenggelam dalam gabungan. Dan gunakan periode yang cukup panjang, misalnya satu bulan, agar satu kejadian besar yang tidak biasa tidak mendominasi gambaran.

Mencari akar masalah dengan bertanya "mengapa" berulang kali

Pareto menunjukkan di mana harus mencari, bukan apa yang harus diperbaiki. Untuk itu Ohno menggambarkan kebiasaan di Toyota bertanya "mengapa" sampai lima kali terhadap sebuah masalah, sehingga yang ditemukan adalah penyebab yang sebenarnya, bukan gejala yang paling dekat^[5]. Contoh yang ia berikan pun berangkat dari sebuah mesin yang berhenti.

Ambil alasan kedua pada contoh di atas, material tersangkut di konveyor. Mengapa material tersangkut? Karena kemasan miring saat masuk ke pemandu. Mengapa miring? Karena jarak antarkemasan tidak rata. Mengapa tidak rata? Karena sabuk konveyor sebelumnya selip pada kecepatan tinggi. Mengapa selip? Karena tegangan sabuk tidak pernah diperiksa setelah penggantian terakhir. Mengapa tidak diperiksa? Karena pemeriksaan tegangan sabuk tidak ada di daftar pemeliharaan rutin lini itu.

Jawaban terakhir adalah sesuatu yang dapat diubah secara permanen: menambahkan satu butir ke checksheet pemeliharaan. Bandingkan dengan jawaban pertama, yang hanya menghasilkan instruksi "operator harus lebih cepat membereskan kemasan yang tersangkut". Jumlah lima bukan aturan baku. Berhentilah ketika jawaban sudah menunjuk pada sesuatu yang bisa diperbaiki dan, bila diperbaiki, mencegah kejadian yang sama terulang. Verifikasinya ada di data: frekuensi alasan tersebut harus turun pada bulan-bulan berikutnya.

Mempersingkat pergantian produk dengan SMED

Pada banyak pabrik dengan variasi produk tinggi, pergantian produk adalah alasan downtime terbesar, seperti pada contoh di atas. Metode yang paling dikenal untuk menguranginya adalah SMED (Single-Minute Exchange of Die) yang dikembangkan Shingo. Namanya mengacu pada target pergantian dalam hitungan menit satu digit, yaitu kurang dari sepuluh menit^[6].

Inti SMED adalah memisahkan dua jenis pekerjaan setup. Setup internal hanya dapat dilakukan ketika mesin berhenti, misalnya melepas cetakan lama dan memasang yang baru. Setup eksternal dapat dilakukan ketika mesin masih berjalan, misalnya menyiapkan cetakan berikutnya, alat, dan material di samping mesin. Shingo mengamati bahwa banyak pekerjaan yang sebenarnya eksternal justru dikerjakan saat mesin sudah berhenti^[6].

Langkah pertama SMED hampir tidak membutuhkan biaya: merekam satu kali pergantian produk dari awal sampai produk baik pertama keluar, lalu menandai setiap pekerjaan sebagai internal atau eksternal. Data downtime berguna di sini untuk dua hal. Ia menunjukkan mesin dan jenis pergantian mana yang paling banyak memakan waktu, dan sesudahnya ia membuktikan apakah durasi rata-rata pergantian benar-benar turun, bukan hanya pada hari ketika semua orang sedang diamati.

Mempersingkat waktu respons

Tidak semua downtime adalah waktu perbaikan. Sebagian besar kadang habis untuk hal yang lebih sederhana: operator mencari supervisor, supervisor menelepon teknisi, teknisi sedang di gedung lain dan baru tahu dua puluh menit kemudian. Pada contoh di atas, selisih antara waktu pemulihan 39 menit dan waktu perbaikan yang sebenarnya adalah jenis kerugian ini.

Di sinilah andon berperan. Dalam sistem produksi Toyota, andon adalah papan atau lampu yang menunjukkan di mana sebuah lini berhenti, sehingga bantuan dapat segera datang ke titik yang tepat^[5]. Versi modernnya mengirim panggilan ke orang yang tepat menurut jenis masalah, mencatat kapan panggilan dibuat, kapan direspons, dan kapan selesai. Dengan data itu, waktu menunggu dapat dipisahkan dari waktu perbaikan, dan keduanya dapat diperbaiki dengan cara yang berbeda: yang pertama dengan aturan eskalasi dan penempatan orang, yang kedua dengan keterampilan, prosedur, dan ketersediaan suku cadang.

Langkah mengurangi downtime secara bertahap

1. 1Tulis definisinya. Tetapkan apa yang termasuk waktu produksi terencana, bagaimana pergantian produk diperlakukan, dan berapa batas durasi yang memisahkan downtime dari berhenti singkat.
2. 2Catat berhenti dan mulai dari mesin. Mulailah dari beberapa mesin yang paling menentukan output, lalu perluas setelah datanya dipercaya.
3. 3Susun kode alasan dua tingkat. Pakai riwayat kejadian yang ada sebagai dasar, jaga agar tingkat pertama tetap pendek, dan tetapkan siapa yang mengisi serta kapan.
4. 4Tinjau Pareto secara rutin. Bahas per mesin, berdasarkan durasi dan frekuensi, dalam pertemuan singkat mingguan bersama produksi dan pemeliharaan.
5. 5Pilih satu atau dua alasan teratas. Telusuri akar masalahnya dengan bertanya "mengapa" berulang kali, atau terapkan SMED bila alasannya adalah pergantian produk.
6. 6Pisahkan waktu respons dari waktu perbaikan. Bila menunggu teknisi atau material ternyata besar, perbaiki alur panggilan dan eskalasinya lebih dulu.
7. 7Verifikasi dengan data, lalu ulangi. Pastikan alasan yang dikerjakan benar-benar turun, bakukan perubahannya, lalu kembali ke Pareto untuk memilih alasan berikutnya.

Kesalahan umum dalam mengelola downtime

• Mencatat dari ingatan di akhir shift. Durasi dibulatkan, kejadian pendek hilang, dan alasan diisi dengan yang paling mudah diingat. Data seperti ini cenderung menampilkan beberapa kerusakan besar dan menyembunyikan puluhan gangguan kecil.
• Membiarkan "lain-lain" menjadi alasan terbesar. Artinya daftar kode tidak sesuai dengan kenyataan di mesin, atau pengisian alasan tidak ditinjau. Kategori ini perlu diperiksa rutin dan dipecah bila membesar.
• Menyalahkan operator. Bila data downtime dipakai untuk mencari siapa yang salah, alasan akan diisi dengan yang paling aman, bukan yang paling benar. Sebagian besar downtime berulang berakar pada mesin, material, metode, atau organisasi kerja, dan hanya dapat ditemukan bila orang merasa aman melaporkannya.
• Mengubah definisi tanpa mencatatnya. Menaikkan batas durasi atau memindahkan pergantian produk menjadi downtime terencana akan memperbaiki angka seketika, tanpa satu menit pun produksi bertambah.
• Mengumpulkan data tanpa meninjaunya. Pencatatan otomatis yang tidak pernah dibahas dalam pertemuan rutin hanya menghasilkan laporan. Nilainya muncul ketika data dipakai memilih tindakan dan memeriksa hasilnya.

Kesimpulan

Downtime mesin jarang disebabkan oleh satu hal. Ia adalah kumpulan kerusakan, pergantian produk, material yang terlambat, dan menit-menit yang habis untuk menunggu. Pabrik yang berhasil menguranginya biasanya tidak memulai dari teknologi baru, tetapi dari data yang jujur: berhenti dan mulai dicatat oleh mesin, alasan diberikan oleh orang yang melihat kejadiannya, dan definisinya tidak berubah dari bulan ke bulan.

Dari data itu, jalurnya cukup jelas. Pareto menunjukkan beberapa alasan yang paling berpengaruh. Pertanyaan "mengapa" yang berulang menemukan akar masalah kerusakan dan gangguan yang terus kembali. SMED mempersingkat pergantian produk, dan alur respons yang jelas memangkas waktu menunggu. Tidak satu pun dari langkah ini menghapus downtime sepenuhnya, tetapi masing-masing dapat diukur, dan karena itu dapat dibuktikan hasilnya.