Cara Menghitung OEE di Pabrik Anda, Lengkap dengan Contoh Angkanya

Kalau Anda bertanya ke lima pabrik berapa OEE mereka, Anda akan dapat lima angka — dan kemungkinan besar tidak satu pun dihitung dengan cara yang sama.

Cara menghitung OEE sebenarnya sederhana. Yang membuatnya sering salah bukan rumusnya, melainkan keputusan-keputusan kecil di sekitarnya: apa yang dihitung sebagai downtime, kecepatan ideal mana yang dipakai, dan apakah rework masuk kategori produk bagus.

Perbedaan itu bisa menggeser angka dua puluh poin. Dan OEE yang dihitung longgar lebih berbahaya daripada tidak punya OEE sama sekali, karena Anda jadi yakin pada angka yang salah.

Rumusnya

OEE adalah hasil kali tiga hal:

OEE = Availability × Performance × Quality

Availability — berapa lama mesin benar-benar jalan, dibanding waktu yang dijadwalkan untuk produksi.

Performance — seberapa cepat jalannya, dibanding kecepatan idealnya.

Quality — berapa banyak yang keluar bagus pada percobaan pertama.

Ketiganya berupa persentase, dan karena dikalikan, angka akhirnya selalu lebih kecil dari yang orang kira. Tiga komponen yang masing-masing 90% menghasilkan OEE 73%, bukan 90%.

Contoh perhitungan satu shift

Angka samar tidak membantu. Ini satu shift nyata, dihitung sampai selesai.

Waktu

Produksi

Perhitungan

Availability = 335 ÷ 420 = 79,8%

Performance = (0,5 × 520) ÷ 335 = 260 ÷ 335 = 77,6%

Quality = 495 ÷ 520 = 95,2%

OEE = 79,8% × 77,6% × 95,2% = 58,9%

Perhatikan satu hal: tidak ada komponen yang terlihat buruk. Availability hampir 80%, Quality di atas 95%. Tapi hasil kalinya 58,9% — artinya hampir separuh kapasitas shift itu hilang.

Inilah yang membuat OEE berguna. Angka-angka yang terlihat wajar sendiri-sendiri bisa menghasilkan kerugian besar ketika digabung.

Cara memeriksa hitungan Anda

Ada jalan pintas untuk memverifikasi:

OEE = (Unit bagus × Cycle time ideal) ÷ Waktu produksi terjadwal

Dengan angka di atas: (495 × 0,5) ÷ 420 = 247,5 ÷ 420 = 58,9%. Cocok.

Kalau dua cara ini memberi hasil berbeda, ada yang salah di salah satu komponen. Pakai ini setiap kali menyusun perhitungan baru.

Lima kesalahan yang paling sering terjadi

Menghitung berhenti terencana sebagai downtime

Istirahat makan, briefing pagi, dan shift yang memang tidak dijadwalkan produksi tidak masuk perhitungan. Mesin tidak gagal — Anda memang tidak menjadwalkannya jalan.

Kalau 60 menit istirahat di contoh tadi dimasukkan sebagai downtime, Availability turun ke 69,8% dan OEE jadi 51,5%. Angka itu salah, dan membuat Anda mengejar masalah yang tidak ada.

Memakai cycle time dari brosur mesin

Ini kesalahan yang paling halus. Kecepatan di spesifikasi mesin dicapai dalam kondisi ideal pabrikan — material sempurna, tanpa variasi, tanpa operator.

Kalau Anda memakai angka brosur, Performance akan selalu terlihat buruk dan tidak pernah membaik, lalu orang berhenti mempercayai metriknya. Pakai kecepatan terbaik yang pernah benar-benar Anda capai secara berkelanjutan dengan material Anda sendiri.

Menghitung rework sebagai produk bagus

Unit yang perlu diperbaiki bukan produk bagus. Ia sudah memakan waktu mesin dua kali dan tenaga kerja tambahan.

Quality harus mengukur first pass yield — keluar benar pada percobaan pertama. Kalau rework dihitung bagus, Anda menyembunyikan biaya yang paling mudah dihilangkan.

Menghitung per bulan

OEE bulanan adalah rata-rata yang menutupi segalanya. Shift malam yang buruk tertutup shift pagi yang bagus. Satu line bermasalah tertutup line lain.

Hitung per shift, per line. Itu level di mana angkanya bisa ditindaklanjuti. Rata-rata pabrik hanya berguna untuk laporan, bukan untuk perbaikan.

Membandingkan OEE antar line yang berbeda

OEE bagus untuk membandingkan satu line dengan dirinya sendiri dari waktu ke waktu. Ia buruk untuk membandingkan line A dengan line B, karena cycle time ideal, jenis produk, dan frekuensi changeover-nya berbeda.

Line dengan changeover sepuluh kali sehari tidak akan pernah mengalahkan line yang memproduksi satu SKU sepanjang shift. Itu bukan berarti timnya lebih buruk.

Soal angka 85%

Di banyak materi, 85% disebut sebagai standar “world class”. Angka itu benar untuk produksi massal dengan sedikit variasi produk — dan menyesatkan untuk hampir semua orang lain.

Pabrik dengan banyak SKU dan changeover sering akan punya plafon struktural yang lebih rendah, dan itu bukan kegagalan.

Yang penting bukan membandingkan diri Anda dengan 85%, melainkan membandingkan diri Anda dengan diri Anda bulan lalu. Naik dari 59% ke 64% bernilai nyata dalam rupiah. Mengejar 85% yang tidak realistis hanya menghasilkan tim yang mulai memanipulasi cara menghitungnya.

Mulai mengukur tanpa software mahal

Anda tidak perlu sistem untuk mulai. Anda perlu data yang jujur.

Minggu 1–2: kertas. Satu lembar per shift di satu line. Operator mencatat jam berhenti, jam jalan lagi, dan alasannya dari daftar pendek yang sudah dicetak — bukan isian bebas. Catat juga total unit dan reject.

Daftar alasan yang pendek itu penting. Lima sampai delapan kategori sudah cukup: breakdown, changeover, tunggu material, setting/adjustment, masalah kualitas, tidak ada operator, lain-lain.

Minggu 3–4: spreadsheet. Masukkan data mingguan ke satu file. Hitung ketiga komponennya. Anda akan mulai melihat pola — dan hampir selalu, penyebab terbesarnya bukan yang diduga semua orang. Tim maintenance yakin penyebabnya breakdown; datanya sering menunjuk changeover atau menunggu material.

Bulan 2 ke atas: baru pikirkan sistem. Setelah Anda tahu data apa yang benar-benar dipakai dan kategori mana yang berguna, barulah masuk akal mengotomatiskan pengumpulannya. Membangun sistem sebelum tahu ini menghasilkan sistem yang mengumpulkan hal yang salah dengan rapi.

Urutan ini dibahas lebih lengkap di tulisan tentang digitalisasi pabrik.

Yang biasanya ditemukan

Setelah satu bulan data jujur, pola yang muncul hampir selalu mirip.

Changeover lebih mahal dari dugaan. Waktu ganti produk yang “cuma dua puluh menit” ternyata rata-rata empat puluh lima, dan terjadi lebih sering dari yang diingat orang.

Kehilangan terbesar bukan breakdown. Mesin rusak terlihat dan diingat. Berhenti lima menit karena menunggu material, dua belas kali sehari, tidak terlihat — padahal totalnya lebih besar.

Shift malam berbeda. Hampir selalu. Penyebabnya bervariasi dan jarang soal kemalasan — biasanya dukungan yang lebih tipis saat ada masalah.

Sebagian “reject” sebenarnya masalah setting. Terkonsentrasi di awal run, setelah changeover.

Tidak satu pun dari temuan ini butuh investasi besar untuk diperbaiki. Yang dibutuhkan hanyalah mengetahuinya.

Kapan sistem benar-benar diperlukan

Kertas dan spreadsheet cukup untuk satu line selama beberapa bulan. Setelah itu batasnya terasa.

Saat Anda mengukur beberapa line sekaligus, saat datanya mulai telat sehingga tidak bisa ditindaklanjuti, atau saat ada orang yang pekerjaannya mengetik ulang lembar OEE setiap pagi — di titik itu pengumpulan otomatis mulai masuk akal.

Tandanya sederhana: ketika biaya mengumpulkan datanya mulai mendekati nilai yang Anda dapat darinya. Sebelum itu, kertas lebih murah dan sama benarnya.

TechGarage membangun sistem pencatatan produksi untuk pabrik di Cikarang, Karawang, Subang, dan sekitarnya — menangkap downtime dan hitungan di lantai produksi, bisa jalan saat koneksi mati, dan menghitung OEE tanpa ada yang perlu mengetik ulang. Kalau Anda sudah punya data kertasnya dan ingin berhenti merekapnya manual, hubungi kami.