Root cause analysis (RCA) di maintenance: 5 Why, fishbone, dan cara menjalankannya

Pengertian root cause analysis

Root cause analysis (RCA), atau analisis akar masalah, adalah penyelidikan terstruktur untuk menemukan penyebab sebenarnya dari sebuah masalah dan tindakan yang diperlukan untuk menghilangkannya^[1]. Kata kuncinya ada di bagian akhir definisi itu. RCA tidak berhenti pada pertanyaan "apa yang rusak", tetapi terus bertanya sampai ditemukan sesuatu yang dapat diubah sehingga kerusakan yang sama tidak terulang.

Di bagian maintenance, perbedaan antara memperbaiki dan menghilangkan penyebab terasa sangat nyata. Ketika drive conveyor berhenti karena bearing macet, tindakan pertama tentu mengganti bearing agar lini kembali berjalan. Itu pekerjaan yang benar. Masalahnya muncul ketika pekerjaan yang sama diulang setiap lima minggu dan tidak ada yang bertanya mengapa bearing itu terus rusak lebih cepat dari umur wajarnya.

Mengganti bearing berulang kali adalah mengobati gejala. Selama penyebabnya tetap ada, entah air yang masuk ke housing, pelumas yang salah, atau poros yang tidak lurus, bearing baru akan mengalami nasib yang sama. Setiap penggantian menambah biaya suku cadang, jam kerja teknisi, dan downtime, sementara catatan di work order membuat masalahnya tampak sudah selesai.

Akar fisik, akar manusia, dan akar laten

Salah satu kerangka yang paling berguna untuk RCA di lingkungan industri berasal dari Latino dan rekan-rekannya. Mereka membedakan tiga lapis akar yang biasanya ditemukan di balik sebuah kegagalan peralatan^[2].

• Akar fisik (physical root): mekanisme nyata yang merusak komponen, misalnya korosi pada lintasan bearing karena air masuk dan merusak lapisan pelumas.
• Akar manusia (human root): keputusan atau tindakan seseorang yang memicu akar fisik, misalnya menyemprotkan air bertekanan tinggi langsung ke housing bearing saat pembersihan.
• Akar laten (latent root): kelemahan pada sistem organisasi yang membuat keputusan itu tampak wajar, misalnya prosedur sanitasi yang diubah tanpa ditinjau bagian maintenance, atau pelatihan yang tidak menjelaskan titik mana yang harus dilindungi.

Ketiga lapis ini penting karena tindakan korektif yang berbeda menyasar lapis yang berbeda. Mengganti seal menangani akar fisik. Menegur operator menyentuh akar manusia, tetapi jarang bertahan lama karena orang berikutnya akan menghadapi situasi yang sama. Tindakan pada akar laten, misalnya mewajibkan setiap perubahan prosedur ditinjau oleh maintenance, adalah yang paling mungkin mencegah masalah serupa di mesin lain. Latino dan rekan-rekannya juga mengingatkan bahwa analisis yang berhenti pada akar manusia cenderung berakhir dengan menyalahkan orang, bukan memperbaiki sistem^[2].

Kapan RCA layak dilakukan

RCA yang sungguh-sungguh memakan waktu beberapa orang selama beberapa hari. Tidak semua kerusakan membenarkan usaha itu. Kerangka reliability-centered maintenance (RCM) mengajarkan bahwa kegagalan dinilai dari konsekuensinya: apakah mengancam keselamatan atau lingkungan, apakah mengganggu operasi, atau hanya menimbulkan biaya perbaikan^[3]. Prinsip yang sama berlaku untuk memutuskan kegagalan mana yang perlu dianalisis sampai ke akarnya.

• Kegagalan berulang. Mode kegagalan yang sama pada aset yang sama muncul lebih dari sekali dalam periode tertentu. Aturan sederhana, misalnya dua kejadian dengan mode yang sama dalam 90 hari, dapat dipakai sebagai pemicu otomatis.
• Biaya downtime tinggi. Satu kejadian menghentikan lini utama cukup lama sehingga kerugian produksinya jauh melampaui biaya analisis.
• Keselamatan dan lingkungan. Setiap kegagalan yang melukai orang, hampir melukai orang, atau menimbulkan pelepasan ke lingkungan layak dianalisis, berapa pun biaya perbaikannya.
• Kegagalan yang tidak dapat dijelaskan. Komponen rusak jauh sebelum umur wajarnya, atau kerusakan muncul setelah perubahan proses, bahan, atau pemasok.

Sebaliknya, RCA formal biasanya tidak diperlukan untuk kegagalan tunggal pada komponen murah yang memang dibiarkan sampai rusak, misalnya lampu indikator atau sekering pada rangkaian yang tidak kritikal. Latino dan rekan-rekannya mencatat bahwa kerugian terbesar sering justru datang dari kegagalan kronis yang kecil tetapi terus berulang, karena kegagalan seperti itu lama-lama diterima sebagai bagian dari biaya operasi^[2]. Menjumlahkan biaya kegagalan berulang membantu membuat kerugian yang tersebar itu terlihat.

Angka berikut adalah ilustrasi, bukan data dari pabrik tertentu. Bearing drive conveyor rusak 4 kali dalam lima bulan. Setiap kejadian menghentikan lini 3 jam, biaya downtime disepakati Rp 4.000.000 per jam, dan biaya perbaikan Rp 1.500.000 per kejadian. Biaya kegagalan berulangnya adalah 4 × (3 × Rp 4.000.000 + Rp 1.500.000) = 4 × Rp 13.500.000 = Rp 54.000.000 dalam lima bulan. Angka seperti ini biasanya cukup untuk meyakinkan manajemen bahwa beberapa hari kerja tim untuk RCA adalah investasi yang wajar.

Alat RCA dan kapan masing-masing cocok

Ada banyak alat RCA, tetapi empat yang paling sering dipakai di maintenance adalah 5 Why, diagram fishbone, fault tree analysis (FTA), dan failure mode and effects analysis (FMEA). 5 Why dipopulerkan oleh Taiichi Ohno di Toyota: bertanya "mengapa" berulang kali, sekitar lima kali, sampai ditemukan penyebab yang dapat diperbaiki^[4]. Diagram fishbone, atau diagram sebab akibat, diperkenalkan Kaoru Ishikawa untuk memetakan semua faktor yang mungkin memengaruhi sebuah akibat^[5]. FTA menelusuri dari sebuah kejadian puncak yang tidak diinginkan ke bawah, melalui gerbang logika DAN dan ATAU, sampai ke kejadian dasar penyebabnya^[6]. FMEA bekerja ke arah sebaliknya: dari setiap komponen, bagaimana ia dapat gagal dan apa efeknya pada sistem^[7].

Dalam praktik, alat-alat ini saling melengkapi. Pola yang banyak dipakai adalah membuka kemungkinan dengan fishbone, memperdalam setiap cabang yang didukung bukti dengan 5 Why, dan beralih ke FTA ketika kegagalannya melibatkan beberapa kondisi yang harus terjadi bersamaan. FMEA lebih cocok ditempatkan di hulu, sebagai cara mencegah kegagalan yang belum terjadi, dan temuan RCA sering menjadi masukan untuk memperbarui FMEA aset sejenis.

Contoh: bearing drive conveyor yang rusak setiap beberapa minggu

Contoh berikut adalah ilustrasi, bukan kasus dari pabrik tertentu, tetapi polanya masuk akal untuk area produksi yang rutin dicuci. Di sebuah lini pembotolan, bearing pada drive conveyor pengantar botol macet 4 kali dalam lima bulan, kira-kira setiap lima sampai enam minggu. Setiap kali, teknisi mengganti bearing, memberi grease baru, dan lini kembali berjalan dalam sekitar 3 jam.

Menelusuri dengan 5 Why

• Mengapa conveyor berhenti? Bearing di sisi drive macet dan motor trip karena beban lebih.
• Mengapa bearing macet? Lintasannya berkarat dan pelumasnya rusak. Grease yang dikeluarkan berwarna putih susu, tanda sudah bercampur air.
• Mengapa ada air di dalam bearing? Seal housing tidak mampu menahan semprotan air bertekanan tinggi yang diarahkan ke area drive saat sanitasi setiap akhir shift.
• Mengapa area drive disemprot air bertekanan tinggi? Beberapa bulan sebelumnya metode sanitasi lini diubah dari lap dan sikat menjadi semprotan bertekanan tinggi, tanpa penutup atau batas area yang harus dihindari.
• Mengapa perubahan itu tidak memperhitungkan bearing? Perubahan prosedur sanitasi diputuskan oleh bagian produksi dan mutu, dan tidak ada mekanisme yang mewajibkan maintenance meninjau perubahan prosedur yang menyentuh peralatan.

Rantai ini menjangkau ketiga lapis akar. Akar fisiknya adalah air yang masuk ke bearing dan merusak pelumasan. Akar manusianya adalah semprotan yang diarahkan langsung ke housing. Akar latennya adalah perubahan metode kerja tanpa tinjauan lintas fungsi, yang dalam bahasa manajemen keselamatan proses dikenal sebagai ketiadaan management of change. Perhatikan bahwa jika analisis berhenti di pertanyaan kedua, kesimpulannya hanya "ganti grease lebih sering", dan bearing tetap akan rusak.

Melebarkan pandangan dengan fishbone

5 Why di atas menghasilkan satu jalur yang meyakinkan, tetapi belum tentu satu-satunya. Tim kemudian menggambar fishbone dengan "bearing drive conveyor rusak prematur" sebagai kepala ikan, dan mengisi setiap tulang dengan kemungkinan penyebab menurut pengelompokan 6M yang lazim dipakai.

• Mesin: seal housing adalah tipe standar, bukan tipe yang dirancang untuk area washdown.
• Metode: metode sanitasi berubah; interval pelumasan ulang tidak disesuaikan dengan kondisi basah.
• Material: grease yang dipakai bukan jenis tahan air.
• Manusia: petugas sanitasi baru belum pernah diberi tahu titik mana yang harus dilindungi dari semprotan.
• Pengukuran: tidak ada pemeriksaan vibrasi atau temperatur, sehingga kerusakan baru diketahui ketika bearing sudah macet.
• Lingkungan: area lini lembap dan sering basah sepanjang shift, bukan hanya saat sanitasi.

Fishbone memperlihatkan bahwa semprotan air bukan satu-satunya faktor. Seal yang tidak sesuai, grease yang tidak tahan air, dan ketiadaan pemantauan kondisi ikut berkontribusi. Setiap kemungkinan itu kemudian diuji dengan bukti: kondisi lintasan bearing, sampel grease, spesifikasi seal, dan catatan kapan metode sanitasi berubah. Kemungkinan yang tidak didukung bukti dicoret; yang didukung masuk ke daftar tindakan.

Kelemahan 5 Why yang perlu disadari

5 Why populer karena sederhana, dan kesederhanaan itu juga sumber kelemahannya. Card mengkritik metode ini dalam konteks keselamatan pasien, tetapi argumennya relevan juga untuk lantai pabrik^[8]. Pertama, 5 Why memaksa kejadian yang kompleks menjadi satu rantai sebab, padahal kebanyakan kegagalan punya beberapa faktor penyebab yang saling berkaitan. Kedua, hasilnya sangat bergantung pada siapa yang bertanya. Tim yang berbeda dapat menganalisis kejadian yang sama dan sampai pada akar masalah yang berbeda, karena setiap orang hanya dapat bertanya "mengapa" sejauh pengetahuannya sendiri.

Ini bukan alasan untuk membuang 5 Why, tetapi alasan untuk tidak memakainya sendirian pada kegagalan yang penting. Karena itu, setiap jawaban perlu diuji. Tiga kebiasaan membantu: menuntut bukti untuk setiap jawaban "karena", memakai fishbone atau FTA agar cabang lain tidak terlewat, dan melibatkan orang dari fungsi berbeda, misalnya operator, teknisi, dan staf produksi, supaya analisis tidak dibatasi sudut pandang satu orang.

Bukti yang perlu dikumpulkan

RCA tanpa bukti hanyalah diskusi opini. Bukti yang paling berguna biasanya paling mudah hilang, karena setelah mesin kembali jalan tidak ada yang merasa perlu menyimpannya. Empat jenis bukti hampir selalu dibutuhkan.

• Komponen yang rusak. Bearing, seal, kopling, atau sikat karbon yang dilepas, lengkap dengan pelumas atau kotoran yang menempel. Pola kerusakan pada permukaannya sering menunjukkan mekanismenya: karat, keausan abrasif, kelelahan material, atau bekas arus listrik.
• Pembacaan sebelum kegagalan. Tren vibrasi, temperatur, arus motor, atau tekanan pada hari dan minggu sebelum kejadian, bila tersedia. Data ini menunjukkan kapan kerusakan mulai berkembang dan apakah ada perubahan yang terlewat. Artikel analisis vibrasi membahas cara membacanya.
• Riwayat work order. Berapa kali aset ini diperbaiki, oleh siapa, dengan tindakan apa, dan berapa jarak antar kejadian. Riwayat inilah yang membedakan kegagalan kronis dari kejadian tunggal.
• Kondisi operasi. Beban, kecepatan, produk yang sedang dijalankan, shift, cuaca, serta perubahan terakhir pada proses, bahan, pemasok, atau prosedur.

Riwayat work order hanya berguna bila isinya dapat dikelompokkan. Catatan bebas seperti "bearing rusak, sudah ganti" tidak bisa dijumlahkan. ISO 14224 memberi struktur untuk data keandalan dan pemeliharaan: setiap kegagalan dicatat dengan peralatan dan komponennya, mode kegagalan (bagaimana fungsi hilang), mekanisme kegagalan (proses fisik yang menyebabkannya), dan penyebab kegagalan, masing-masing dengan daftar kode yang baku^[9]. Standar itu ditulis untuk industri minyak dan gas, tetapi strukturnya dapat dipinjam untuk pabrik mana pun.

Dengan kode seperti itu di CMMS, pertanyaan "aset mana yang mengalami keausan bearing lebih dari sekali dalam tiga bulan terakhir" dapat dijawab dengan satu penyaringan, bukan dengan membaca ratusan catatan satu per satu. Pengodean yang konsisten juga yang membuat pemicu RCA otomatis, seperti aturan dua kejadian dalam 90 hari, dapat dijalankan sama sekali.

Dari temuan ke tindakan korektif

Laporan RCA yang berakhir dengan daftar penyebab belum menyelesaikan apa pun. Setiap akar yang terbukti perlu diterjemahkan menjadi tindakan yang spesifik, dengan satu orang pemilik dan satu tenggat. Andersen dan Fagerhaug menekankan bahwa tindakan harus menyasar penyebab yang ditemukan, bukan sekadar memperbaiki akibat yang terlihat^[1]. Pada contoh conveyor, daftar tindakannya dapat berbentuk seperti ini.

• Akar fisik: ganti seal housing dengan tipe yang dirancang untuk area washdown dan ganti grease dengan jenis tahan air. Pemilik: supervisor maintenance mekanik. Tenggat: dua minggu.
• Akar manusia: revisi instruksi sanitasi dengan foto titik yang tidak boleh disemprot langsung, lalu latih ulang semua petugas sanitasi. Pemilik: supervisor produksi. Tenggat: tiga minggu.
• Akar laten: wajibkan tinjauan maintenance untuk setiap perubahan prosedur yang menyentuh peralatan. Pemilik: plant manager. Tenggat: satu bulan.
• Aset sejenis: periksa conveyor lain di area basah yang memakai seal dan grease yang sama. Pemilik: planner maintenance. Tenggat: satu bulan.

Langkah terakhir yang paling sering terlewat adalah verifikasi. Tindakan dianggap berhasil bukan ketika selesai dikerjakan, tetapi ketika data sesudahnya menunjukkan bahwa kegagalan tidak terulang. Pada contoh ini, bearing sebelumnya rusak kira-kira setiap lima sampai enam minggu, sehingga satu bulan tanpa kerusakan belum membuktikan apa pun. Verifikasi yang wajar memantau aset itu selama beberapa kali interval kegagalan sebelumnya, ditambah pemeriksaan kondisi grease dan tren MTBF aset tersebut. Jika kegagalan tetap terjadi, RCA dibuka kembali, karena berarti ada akar yang belum ditemukan.

Langkah menjalankan RCA

1. 1Rumuskan masalahnya secara spesifik. Aset apa, mode kegagalan apa, kapan, berapa kali, dan berapa dampaknya. "Bearing sisi drive conveyor botol di lini 2 macet 4 kali dalam lima bulan" jauh lebih berguna daripada "conveyor sering rusak".
2. 2Amankan bukti. Simpan komponen yang rusak, ambil sampel pelumas, foto kondisi di lokasi, dan unduh data sensor serta riwayat work order sebelum hilang atau tertimpa.
3. 3Bentuk tim kecil lintas fungsi. Tiga sampai lima orang: operator yang menjalankan mesin, teknisi yang memperbaikinya, perwakilan produksi, dan seorang fasilitator yang tidak terlibat langsung dalam kejadian.
4. 4Susun urutan kejadian. Rekonstruksi apa yang terjadi, kapan, dan dalam kondisi apa, berdasarkan data dan keterangan, termasuk perubahan apa pun dalam beberapa bulan terakhir.
5. 5Analisis dengan alat yang sesuai. Buka kemungkinan dengan fishbone, perdalam dengan 5 Why, dan gunakan FTA bila kegagalan memerlukan beberapa kondisi yang terjadi bersamaan.
6. 6Uji setiap hipotesis dengan bukti. Coret penyebab yang tidak didukung data. Tandai yang belum dapat dibuktikan dan tentukan cara mengujinya.
7. 7Tetapkan tindakan untuk setiap lapis akar. Fisik, manusia, dan laten, masing-masing dengan pemilik dan tenggat, lalu catat sebagai work order agar dapat dilacak.
8. 8Verifikasi dan bagikan hasilnya. Pantau data kegagalan sesudah tindakan, tutup RCA hanya bila kegagalan tidak terulang, dan terapkan pelajarannya ke aset sejenis.

Kesalahan yang sering terjadi

• Mencari siapa yang salah. Begitu analisis menemukan nama orang, diskusi biasanya berhenti. Orang yang takut disalahkan juga berhenti memberi keterangan yang jujur, dan akar laten tidak pernah tersentuh.
• Berhenti terlalu cepat. "Bearing aus" dan "pelumasan kurang" adalah akar fisik, bukan akhir analisis. Bila tindakan yang dihasilkan hanya "ganti komponen" atau "tambah frekuensi pelumasan", kemungkinan besar analisisnya belum selesai.
• Menganalisis tanpa bukti. Kesimpulan yang lahir dari pengalaman satu orang senior, tanpa melihat komponen yang rusak atau data sebelum kejadian, mudah keliru dan sulit diuji.
• Tindakan tanpa pemilik dan tenggat. Rekomendasi seperti "perlu ditingkatkan pelatihan" tanpa nama dan tanggal hampir pasti tidak dikerjakan.
• Tidak ada verifikasi. RCA ditutup ketika laporan selesai, bukan ketika data membuktikan kegagalan berhenti. Akibatnya, kegagalan yang sama muncul lagi dan RCA baru dimulai dari nol.

Kesimpulan

Root cause analysis mengubah pertanyaan tim maintenance dari "apa yang rusak" menjadi "mengapa ini terus rusak". Jawabannya jarang tunggal. Di balik bearing yang macet biasanya ada mekanisme fisik, keputusan seseorang, dan sistem yang membiarkan keputusan itu terjadi. Alat seperti 5 Why dan fishbone membantu menelusurinya, asalkan setiap jawaban diuji dengan bukti dan tidak ada satu alat pun yang dipakai sebagai satu-satunya jalan.

RCA tidak perlu dilakukan untuk setiap kerusakan. Mulailah dari kegagalan yang berulang, mahal, atau menyangkut keselamatan, pastikan riwayat kerusakan tercatat dengan kode yang konsisten, dan jangan menutup analisis sebelum data menunjukkan bahwa kegagalannya benar-benar berhenti. Satu RCA yang tuntas pada satu aset kronis sering memberi pelajaran yang berlaku untuk banyak aset lain.