Monitoring OEE Real-Time di Lini Produksi: Dari Mana Angkanya Bocor

Hampir setiap pabrik yang sudah dewasa punya angka OEE (Overall Equipment Effectiveness) di laporan bulanannya. Masalahnya bukan pada rumusnya — availability × performance × quality sudah standar dan dipahami semua orang produksi. Masalahnya ada pada kapan angka itu dihitung. Kalau baru muncul di rapat mingguan atau laporan akhir shift, angka itu sudah menjadi sejarah, bukan alat kerja.

OEE yang dihitung manual selalu terlambat

Pola yang umum: operator mencatat downtime di kertas atau spreadsheet, admin produksi merekap di akhir shift, dan angka OEE baru terlihat esok hari — kadang seminggu kemudian saat rapat produksi. Tiga masalah muncul dari alur ini:

• Penyebab downtime tercampur atau lupa dicatat. Operator yang sibuk menangani gangguan jarang sempat mencatat detail — durasi dan alasan berhenti sering ditulis perkiraan, bukan angka sebenarnya.
• Tidak ada waktu untuk bereaksi. Ketika laporan baru dibaca esok hari, kesempatan memperbaiki shift yang sedang berjalan sudah lewat. Yang tersisa hanya evaluasi, bukan koreksi.
• Data antar lini tidak sebanding. Format pencatatan manual berbeda-beda antar operator dan shift, membuat perbandingan performa antar lini menjadi tidak akurat.

OEE sebenarnya adalah metrik operasional, bukan metrik pelaporan. Nilainya baru terasa kalau bisa dilihat saat masalah masih berlangsung, bukan setelah shift selesai.

Tiga komponen OEE dan di mana masing-masing bocor

Memantau OEE secara real-time berarti memantau tiga komponennya secara terpisah, karena masing-masing bocor karena sebab yang berbeda:

• Availability — rasio waktu mesin benar-benar berjalan dibanding waktu yang direncanakan. Bocor karena downtime tak terjadwal: mesin macet, ganti alat, menunggu material. Tanpa pencatatan otomatis, alasan berhenti yang paling sering justru yang paling jarang tercatat akurat karena berulang dan dianggap "biasa".
• Performance — kecepatan aktual dibanding kecepatan ideal. Bocor karena mesin berjalan di bawah kapasitas: micro-stop yang tidak sampai dicatat sebagai downtime, atau operator menurunkan kecepatan karena khawatir kualitas.
• Quality — rasio produk baik dibanding total produk yang dihasilkan. Bocor karena reject dan rework, yang sering baru terlihat di akhir proses — jauh dari titik penyebabnya.

Menggabungkan ketiganya menjadi satu angka OEE itu berguna untuk laporan eksekutif. Tapi untuk perbaikan operasional, tim produksi butuh melihat ketiganya terpisah, per lini, dan mendekati waktu nyata.

Cara IncludeApps memantau OEE per lini

IncludeApps adalah platform monitoring AIoT Smart Industry di ekosistem INCLUDE yang mengambil data langsung dari mesin dan menyajikannya sebagai dashboard operasional:

• Deteksi status mesin otomatis. Sinyal dari PLC, sensor arus, atau kontak run/stop mesin dibaca lewat IncludeGateways, sehingga status berjalan/berhenti tercatat otomatis — tanpa operator perlu menekan tombol pencatatan manual.
• Hitung availability dan performance secara berkelanjutan. Selisih antara waktu rencana dan waktu aktual dihitung terus-menerus, bukan sekali di akhir shift, sehingga tren terlihat sejak jam pertama.
• Tandai downtime begitu terjadi. Notifikasi terkirim ke supervisor saat mesin berhenti melewati ambang waktu tertentu — memberi kesempatan bereaksi selagi shift masih berjalan.
• Bandingkan lini secara adil. Karena datanya diambil dari sumber yang sama dengan metode yang sama, perbandingan antar lini dan antar shift menjadi apple-to-apple, bukan bergantung pada siapa yang mencatat.

Membaca dashboard OEE: yang perlu diperhatikan supervisor

Dashboard yang baik bukan sekadar menampilkan angka OEE gabungan. Yang benar-benar mengubah keputusan harian adalah:

• Pareto penyebab downtime. Daftar alasan berhenti yang diurutkan dari yang paling sering, bukan yang paling lama — karena gangguan yang sering terjadi meski singkat sering lebih mahal secara kumulatif daripada satu breakdown besar.
• Tren performance per jam dalam satu shift. Penurunan kecepatan yang konsisten menjelang akhir shift biasanya menunjukkan kelelahan operator atau keausan alat, bukan kebetulan.
• Titik reject muncul di proses mana. Bila quality turun, dashboard perlu menunjukkan pada tahap mana — bukan hanya angka reject di akhir lini.
• Perbandingan shift ke shift pada mesin yang sama. Selisih OEE besar antar shift pada mesin identik hampir selalu berarti selisih praktik kerja, bukan selisih mesin.

Dari angka ke tindakan

OEE yang termonitor real-time baru bernilai kalau mengubah keputusan hari itu juga. Tindakan yang paling sering muncul setelah dashboard OEE berjalan:

• Menyusun ulang jadwal ganti alat di jam dengan permintaan produksi terendah, setelah pola downtime per jam terlihat jelas.
• Menstandarkan SOP start-up pada lini dengan performance rendah di awal shift — sering ditemukan proses pemanasan yang tidak konsisten antar operator.
• Menargetkan pelatihan operator pada shift dengan quality lebih rendah, alih-alih pelatihan umum yang menyasar semua orang.
• Menentukan prioritas maintenance berdasarkan kontribusi riil terhadap downtime, bukan berdasarkan mesin mana yang "terasa" paling sering rusak.

Mulai dari lini yang paling menentukan

Anda tidak perlu memasang monitoring di seluruh pabrik sekaligus. Cara paling efisien adalah memulai dari 1–2 lini bottleneck yang paling menentukan output total pabrik. Begitu pola OEE-nya terbaca dan tindakan pertama terbukti berhasil, perluasan ke lini lain menjadi jauh lebih mudah dijustifikasi karena hasilnya sudah nyata.

Untuk kebutuhan integrasi lebih dalam — menghubungkan data OEE ke sistem ERP, atau menghitung biaya kualitas per batch produksi — tim layanan INCLUDE dapat membangunnya di atas platform yang sama.