Kutukan 5 Whys: Kenapa Root Cause Analysis Sering Berujung Saling Tuduh
Bayangkan sebuah fitur baru yang tiba-tiba nggak bisa dipakai oleh karyawan baru. Reaksi paling umum: cari siapa yang salah, minta pelatihan tambahan, lalu lanjut kerja. Masalah "kelihatannya" selesai. Tapi dua minggu kemudian, masalah serupa muncul lagi — di tempat berbeda, dengan orang berbeda.
Ini yang ingin dihindari Taiichi Ohno, insinyur Toyota yang mempopulerkan teknik 5 Whys: bertanya "kenapa" secara berulang, biasanya lima kali, sampai menemukan akar masalah yang sesungguhnya — bukan cuma gejala di permukaan.
Bagaimana 5 Whys Bekerja di Lapangan
Eric Ries pernah membagikan pengalamannya sendiri melatih engineer baru. Ketika sebuah fitur tidak bisa digunakan, alih-alih langsung menyalahkan orang atau menjadwalkan pelatihan delapan minggu, ia bertanya "kenapa" sampai lima kali berturut-turut. Hasilnya mengejutkan: ternyata fitur itu gagal karena karyawan baru menggunakan subsistem dengan cara yang salah — bukan karena kurang pelatihan secara umum.
Begitu akar masalahnya ditemukan, solusinya jadi sangat spesifik: bukan delapan minggu pelatihan menyeluruh, tapi cukup satu jam pengajaran tepat sasaran soal hal yang memang belum diketahui karyawan itu. Bandingkan dengan solusi generik yang biasanya dilempar tanpa proses tanya-mengapa — jauh lebih boros waktu dan tenaga, tapi belum tentu menyentuh masalah sebenarnya.
Ketika 5 Whys Berubah Jadi Kutukan
Masalahnya, teknik ini sangat mudah disalahgunakan. Alih-alih mengarah ke perbaikan sistem, sesi "kenapa" berulang ini bisa dengan cepat berubah jadi sesi saling menyalahkan individu. "Kenapa gagal?" — "Karena si A salah input." "Kenapa dia salah input?" — "Karena dia baru dan belum paham." Selesai sampai di situ, dan yang disalahkan tetap satu orang.
Eric Ries menyebut pola ini sebagai kutukan 5 Whys — versi rusak dari teknik yang seharusnya membantu, tapi malah dipakai untuk menuding individu, bukan mencari kelemahan sistem yang memungkinkan kesalahan itu terjadi.
Solusinya bukan berhenti pakai teknik ini, tapi mengubah cara pakainya: bawa semua orang yang terlibat dengan pekerjaan yang bermasalah ke dalam satu ruangan, dan bahas dari kacamata sistem, bukan kacamata personal. Contohnya, ketika karyawan baru diberi akses langsung ke sistem produksi dan melakukan kesalahan, pertanyaannya seharusnya bukan "kenapa dia ceroboh", tapi "kenapa sistem kita membiarkan kesalahan serapuh itu terjadi begitu mudah, dan bagaimana kita perbaiki ke depannya?" Tanggung jawab digeser ke manajemen senior yang membiarkan sistem itu rapuh — bukan ke orang yang kebetulan jadi korban pertama dari kerapuhan tersebut.
Tiga Kunci Menjalankan 5 Whys dengan Benar
- Siap menelan kenyataan pahit. Proses ini akan mengungkap masalah dasar yang mungkin nggak nyaman didengar, dan sering mengarah ke kutukan saling salah kalau tidak dikendalikan. Karena itu, dukungan langsung dari tim eksekutif dan arahan top-down sangat dibutuhkan supaya proses ini benar-benar dijalankan dengan niat memperbaiki sistem, bukan mencari kambing hitam.
- Mulai dari masalah yang spesifik. Jangan langsung membahas masalah besar dan abstrak. Semakin spesifik masalahnya, semakin mudah timnya fokus benar-benar menjalankan pendekatan 5 Whys sampai ke akar.
- Pilih satu "master" diskusi. Perlu ada satu orang yang berperan sebagai mediator dan pemimpin jalannya diskusi, supaya obrolan nggak melenceng dan tetap mengarah ke masalah spesifik yang sedang dibahas.
Contoh Ketika Semuanya Salah: Kasus IGN
Kegagalan menjalankan 5 Whys biasanya bukan karena tekniknya salah, tapi karena persiapannya asal-asalan. Cakupan masalah yang dibahas terlalu besar dan umum, orang-orang yang benar-benar terlibat dengan masalah itu nggak diundang ke diskusi, dan tidak ada satu pun yang berperan sebagai master untuk menjaga arah pembicaraan. Hasilnya, rapat jadi panjang lebar tanpa kesimpulan konkret — persis kebalikan dari tujuan 5 Whys itu sendiri.
Intinya
5 Whys itu alat yang sangat sederhana, tapi efeknya tergantung siapa yang memegangnya dan bagaimana ruangannya dijalankan. Kalau dipakai untuk mencari sistem yang rapuh, hasilnya adalah perbaikan nyata dan pembelajaran yang bisa diakses semua orang. Kalau dipakai untuk mencari siapa yang salah, hasilnya cuma trauma tim dan masalah yang bakal muncul lagi — mungkin dengan wajah yang berbeda.