J

Operator shift 2 mencatat "hasil agak beda" di buku log. Dia tidak menghentikan mesin, karena tidak ada instruksi untuk berhenti atas dasar "agak beda".

Jam 11.00 besoknya, QA menemukannya saat inspeksi rutin lot.

Tiga belas jam. Mesin itu jalan 1.150 pcs per jam, jadi ada 14.950 pcs yang harus dipilah, sebagian sudah masuk lot yang dikemas.

Laporan produksi harian pabrik yang baru lengkap besok siang bukan masalah administrasi. Itu lubang informasi dengan harga yang bisa dihitung per jam, dan di kasus ini harganya Rp 67.275.000 untuk satu kejadian.

Perhitungannya nanti. Yang lebih dulu perlu dikatakan: bukan berarti semua angka di pabrikmu harus real time. Sebagian besar tidak perlu, dan menjual real time untuk semuanya adalah cara paling rapi membuang uang.

Berapa harga 13 jam tanpa informasi?

Dari 14.950 pcs yang keluar di luar toleransi, hasil pemilahan di pabrik itu terbagi dua.

Enam puluh persen masih bisa dikerjakan ulang, karena penyimpangannya di bagian yang bisa dirapikan. 14.950 × 60% = 8.970 pcs, biaya rework Rp 1.900 per pcs. Itu Rp 17.043.000.

Empat puluh persen tidak bisa diselamatkan. 14.950 × 40% = 5.980 pcs, dan nilai yang hilang per pcs adalah bahan ditambah biaya konversi yang sudah terpakai, Rp 8.400. Itu Rp 50.232.000.

Rp 17.043.000 + Rp 50.232.000 = Rp 67.275.000.

Sekarang hitung versi kalau penyimpangan itu terdeteksi dalam satu jam. Satu jam berarti 1.150 pcs. Dengan proporsi yang sama, 690 pcs rework dan 460 pcs scrap. Rp 1.311.000 + Rp 3.864.000 = Rp 5.175.000.

Selisihnya Rp 62.100.000 untuk satu kejadian, dan itulah nilai dari dua belas jam informasi yang lebih cepat.

Kejadian seperti ini lima kali setahun di pabrik itu. Rp 62.100.000 × 5 = Rp 310.500.000 per tahun.

Ada satu detail yang membuat kasus ini lebih buruk dari sekadar angka. Batch rework yang sama dijalankan dua kali di shift 2 malam berikutnya, karena tidak ada catatan bahwa batch itu sudah pernah dikerjakan. Dua kali biaya rework untuk satu batch, dan sekarang ada dua entri di kartu stok untuk barang yang sama.

Angka mana yang benar-benar harus real time, dan mana yang tidak?

Bagian ini merugikan kami untuk tulis, karena kami menjual pekerjaan yang membuat angka jadi real time. Tapi menyarankan real time untuk semua hal akan membuat kamu membayar sesuatu yang tidak dipakai, dan itu jenis proyek yang gagal di bulan kesembilan.

Patokannya satu pertanyaan: kalau angka ini terlambat satu hari, apakah ada keputusan yang jadi salah? Kalau tidak ada, harian sudah cukup.

Tiga baris pertama itu yang bikin kamu bisa bertindak sebelum kerugiannya jadi besar. Sisanya bisa diisi di hari yang sama tanpa ada yang dirugikan.

Kalau ada vendor yang menawarkan dashboard real time untuk delapan baris itu sekaligus, kamu sedang dijual layar, bukan penyelesaian masalah.

Kenapa serah terima shift selalu gagal walaupun sudah ada formulirnya?

Karena ini biasanya diperlakukan sebagai masalah kedisiplinan, dan selama diperlakukan begitu, tidak akan pernah membaik.

Lihat susunan waktunya di pabrik tadi. Shift 2 berakhir jam 06.00. Shift 3 masuk jam 06.00. Overlap-nya nol menit di atas kertas, dan di lapangan negatif, karena operator shift 2 berangkat jam 05.45 untuk mengejar angkutan yang cuma lewat sekali.

Jadi serah terima terjadi lewat buku log yang ditinggal di meja. Bukan karena orangnya tidak mau bicara. Karena secara fisik dua orang itu tidak pernah berada di ruangan yang sama.

Buku log itu ditulis dalam kondisi terburuk untuk menulis: menit-menit terakhir shift, setelah dua belas jam kerja, saat pikirannya sudah di angkutan. Yang tercatat adalah hal yang paling menonjol, bukan hal yang paling penting. "Hasil agak beda" adalah catatan yang jujur dan sama sekali tidak bisa ditindaklanjuti.

Perbaikannya bukan menambah kolom di formulir, dan bukan training. Ada tiga hal yang benar-benar mengubah keadaan.

Catatan dibuat saat kejadian, bukan saat shift berakhir. Kalau nozzle mulai aus jam 22.10, entri itu harus ada jam 22.10, bukan jam 05.45.

Ada ambang batas yang jelas, bukan penilaian rasa. "Hasil agak beda" bukan data. "Dimensi 0,3 mm di atas batas atas" adalah data, dan itu butuh alat ukur di lini, bukan mata.

Ada satu tindakan default yang jelas untuk setiap ambang yang terlewati. Operator tidak boleh disuruh memutuskan apakah mesin harus berhenti. Aturannya sudah harus ditulis sebelum shift dimulai.

Kenapa sistem lantai produksi gagal di layar input, bukan di dashboard?

Ini yang paling sering kami temui, dan ini kegagalan yang paling mahal karena baru kelihatan setelah sistemnya dibayar penuh.

Dashboard-nya bagus. Grafiknya benar, warnanya jelas, angkanya terhitung dengan rumus yang tepat. Yang salah data yang masuk ke dalamnya, karena data itu diketik di akhir shift dari ingatan, bukan dicatat saat kejadian.

Sebabnya bisa diukur. Formulir entri di sistem itu punya sebelas kolom. Kalau satu kolom butuh empat detik untuk diisi dengan mengetik, satu entri butuh 44 detik. Operator itu punya delapan belas entri per shift. 18 × 44 detik = 792 detik, hampir 13 menit per shift, sementara target output-nya tetap 1.150 pcs per jam dan tidak ada yang mengurangi target itu.

Yang terjadi bisa diduga. Entri dikumpulkan ke akhir shift dan diisi sekaligus dari catatan kasar atau dari ingatan. Datanya rapi, konsisten, dan sebagian karangan.

Batas praktisnya sekitar 15 detik per entri. Di atas itu, operator akan menunda, dan tidak ada pelatihan yang mengubahnya karena ini bukan soal kemauan. Yang bisa diubah cuma bentuk layarnya.

Entri yang sama bisa dibuat jadi tujuh detik. Barcode work order satu detik, barcode kartu operator satu detik, jumlah lewat keypad angka besar tiga detik, penyebab reject dari lima tombol yang sudah tersedia dua detik. Delapan belas entri jadi sekitar dua menit per shift.

Sebelas kolom itu tidak dihapus. Sembilan di antaranya diisi sendiri oleh sistem, karena informasinya sudah ada di work order, di jadwal shift, dan di jam sistem.

Kategori sistem ini dijual dengan nama ERP, dan bagian yang mengerjakan hal ini ada di modul manufacturing, biasanya disebut work order atau shop floor control. Yang perlu kamu tanyakan ke vendor bukan seperti apa dashboard-nya, tapi berapa detik satu entri di layar operator, dan minta ditunjukkan dengan alat yang akan benar-benar dipakai di lantai. Biaya sistem semacam ini untuk pabrik di Indonesia sudah kami hitung terbuka di rincian biaya sistem untuk pabrik Indonesia.

Keterlambatan informasi di lantai punya saudara di sisi keuangan, dan mekanismenya sama: angka yang datang setelah keputusannya diambil. Kalau laporan produksimu terlambat sehari, laporan keuanganmu biasanya terlambat dua minggu, dan penyebabnya berada di rantai yang sama.

Kalau kamu mau melihat gejala ini bersama sebelas gejala lain dengan harganya masing-masing, semuanya berakar di pabrik yang sistem produksinya masih manual.

Pertanyaan yang sering masuk

Apakah pabrik butuh monitoring produksi real time? Untuk tiga angka saja: output per mesin, mesin berhenti, dan reject dengan penyebabnya. Angka-angka itu dipakai untuk bertindak di dalam shift yang sedang berjalan. Pemakaian bahan, jam kerja, dan biaya per unit cukup diisi di hari yang sama atau lebih longgar.

Kenapa laporan produksi harian selalu telat? Biasanya karena entri dikumpulkan ke akhir shift, dan itu terjadi karena mengisinya di saat kejadian butuh waktu yang tidak tersedia. Periksa berapa detik satu entri di layar operator sebelum menyalahkan orangnya.

Berapa lama waktu wajar untuk laporan produksi shift? Data output, downtime, dan reject sebaiknya sudah ada di sistem sebelum shift berakhir, bukan setelahnya. Laporan lengkap yang sudah diperiksa supervisor wajar keluar dalam dua sampai tiga jam setelah shift selesai.

Bagaimana cara memperbaiki serah terima antar shift? Kurangi ketergantungan pada percakapan yang secara fisik tidak pernah terjadi. Catatan dibuat saat kejadian, ambang batas ditulis dalam angka dan bukan dalam rasa, dan setiap ambang punya satu tindakan default yang sudah diputuskan sebelum shift dimulai.

Kenapa dashboard produksi sudah ada tapi angkanya tidak dipercaya? Karena masalahnya di layar input, bukan di layar laporan. Kalau entri diisi di akhir shift dari ingatan, dashboard-nya akan menampilkan angka yang rapi dari data yang tidak pernah diukur.

Besok, ambil stopwatch dan ukur berapa detik yang dibutuhkan operator untuk menyelesaikan satu entri di sistem yang kamu punya sekarang. Kalau angkanya di atas 15 detik, kamu sudah tahu kenapa laporannya baru sampai besok siang.