5 Whys: Metode Analisis Akar Masalah (Dengan Contoh)

Teknik 5 Whys adalah salah satu alat paling sederhana namun paling kuat dalam perbaikan proses. Anda menyatakan sebuah masalah, bertanya "mengapa" hal itu terjadi, lalu bertanya "mengapa" lagi tentang jawaban pertama Anda, dan terus begitu sampai Anda mencapai penyebab sebenarnya, bukan sekadar gejalanya. Sebagian besar tim mencapainya dalam lima iterasi. Sebagian mencapainya dalam tiga. Sedikit yang benar-benar membutuhkan enam atau tujuh.

Yang membuatnya luar biasa bukan jumlah angkanya. Melainkan disiplin untuk tidak berhenti pada jawaban pertama yang terasa nyaman.

Apa itu 5 Whys?

5 Whys adalah teknik analisis akar masalah yang menggunakan pertanyaan berulang untuk melacak sebuah masalah kembali ke asalnya. Anda mulai dengan pernyataan masalah yang jelas dan bertanya "mengapa ini terjadi?" secara berulang sampai Anda menemukan kegagalan sistemik yang mendasarinya, bukan sekadar gejala di permukaan.

Metode ini diciptakan oleh Sakichi Toyoda, pendiri Toyota Industries, pada awal abad ke-20. Metode ini menjadi bagian formal dari Toyota Production System (TPS) di bawah Taiichi Ohno pada tahun 1950-an dan 1960-an. Ohno menganggap 5 Whys sebagai salah satu praktik inti yang memungkinkan Toyota membangun kualitas ke dalam proses manufakturnya, alih-alih memeriksa defect setelah kejadian. Saat ini metode ini menjadi alat standar dalam metodologi Lean, kerangka DMAIC Six Sigma, dan hampir semua sistem perbaikan berkelanjutan.

Teknik ini tidak memerlukan software, pelatihan statistik, atau sertifikasi khusus. Kemudahan akses itulah yang membuatnya bertahan lebih dari 70 tahun, baik di lantai pabrik maupun di ruang rapat direksi.

Fakta kunci

• Taiichi Ohno, bapak Toyota Production System, menulis dalam bukunya tahun 1988 Toyota Production System: Beyond Large-Scale Production bahwa "dengan mengulangi mengapa lima kali, sifat masalah serta solusinya menjadi jelas." Kerangka ini masih menjadi deskripsi baku dari teknik ini yang digunakan oleh Lean Enterprise Institute hingga sekarang.
• American Society for Quality (ASQ) memasukkan 5 Whys dalam Body of Knowledge untuk Certified Quality Engineers dan mencantumkannya sebagai salah satu alat utama untuk fase Analyze, bersama fishbone diagram dan analisis Pareto.
• Survei tahun 2021 oleh Lean Enterprise Institute menemukan bahwa 5 Whys digunakan oleh lebih dari 65% organisasi yang telah mengadopsi praktik lean, menjadikannya alat akar masalah tunggal yang paling banyak digunakan dalam manajemen operasi.

5 Whys vs Fishbone Diagram vs 8D

Ketiga alat ini sering disebut bersamaan. Mereka saling berkaitan tetapi tidak bisa saling menggantikan. Memilih alat yang salah membuang waktu dan menghasilkan kesimpulan yang dangkal.

Gunakan 5 Whys ketika Anda membutuhkan jawaban dengan cepat dan masalahnya terbatas. Gunakan fishbone diagram ketika Anda tidak yakin kategori penyebab mana yang mendorong masalah dan membutuhkan struktur brainstorming. Gunakan 8D problem solving ketika masalah membutuhkan dokumentasi formal, tindakan penahanan, dan verifikasi lintas batas organisasi.

5 Whys dan fishbone diagram sebenarnya bekerja dengan baik bersama-sama. Banyak tim menggunakan fishbone terlebih dahulu untuk memetakan ruang kemungkinan, lalu menerapkan 5 Whys pada cabang yang paling mungkin.

Manfaat 5 Whys

Kecepatan. Tim kecil dapat menyelesaikan analisis 5 Whys dalam waktu kurang dari satu jam. Untuk masalah operasional yang secara aktif merugikan biaya atau menyebabkan penundaan, kecepatan itu penting.

Kemudahan akses. Anda tidak memerlukan ahli statistik atau black belt bersertifikat untuk memfasilitasi sesi 5 Whys. Setiap team lead yang memahami masalahnya dapat menjalankannya.

Fokus pada sistem, bukan orang. Jika dilakukan dengan benar, 5 Whys mengarahkan investigasi menjauh dari kesalahan manusia sebagai akar masalah dan menuju proses, sistem, atau kebijakan yang memungkinkan kesalahan itu terjadi. Menyalahkan seseorang tidak mencegah kejadian berulang. Memperbaiki proses yang rusak, ya.

Integrasi dengan alat lain. 5 Whys masuk secara alami ke dalam fase Analyze DMAIC, tahap Plan PDCA, dan acara Kaizen. Ini adalah teknik modular, bukan metodologi yang berdiri sendiri.

Kejelasan tindakan penanggulangan. Karena 5 Whys berakhir pada akar masalah yang spesifik, tindakan korektifnya biasanya jelas. Itulah inti dari metode ini. Jika jawaban Anda masih samar, Anda belum menggali cukup dalam.

Kesalahan umum dan keterbatasan

5 Whys itu sederhana. Kesederhanaan itu juga menjadi kelemahan utamanya.

Berhenti terlalu cepat. Kesalahan paling umum adalah menerima gejala sebagai penyebab. "Mesin rusak" adalah gejala. "Mesin rusak karena jadwal perawatan dipangkas untuk menghemat biaya" adalah akar masalah. Tim yang tertekan waktu menerima jawaban pertama yang masuk akal dan melanjutkan. Masalahnya kembali muncul.

Hanya mengikuti satu jalur. Masalah nyata sering memiliki banyak penyebab yang bercabang di setiap tingkat. Analisis rantai tunggal yang kaku melewatkan kegagalan paralel. Untuk masalah kompleks, gambarkan rantainya sebagai pohon, bukan garis.

Menyalahkan orang, bukan proses. Jika jawaban why kelima Anda adalah "karena Bob tidak memeriksa laporannya," Anda belum menemukan akar masalah. Anda hanya menemukan orang untuk disalahkan. Teruslah bertanya. Mengapa tidak ada sistem yang membuat pemeriksaan itu otomatis? Mengapa Bob tidak dilatih? Mengapa Bob menjadi satu-satunya titik kegagalan?

Mengandalkan ingatan dan asumsi. 5 Whys bekerja paling baik dengan data, bukan ingatan. Ketika tim merekonstruksi kejadian dari ingatan, mereka memasukkan bias dan melewatkan apa yang sebenarnya terjadi. Padukan dengan observasi, log data, atau penelusuran proses bila memungkinkan.

Menggunakannya untuk kegagalan multi-sistem yang kompleks. Ketika sebuah masalah menyentuh lima departemen, tiga sistem software, dan dua badan regulasi, sesi 5 Whys di ruang rapat tidak akan menangkapnya. Itu adalah pekerjaan untuk fishbone diagram yang diikuti analisis statistik, bukan pertanyaan berulang.

Cara menggunakan 5 Whys (langkah demi langkah)

Langkah 1: Definisikan masalah dengan jelas

Tuliskan masalah sebagai pernyataan yang spesifik dan dapat diamati. Pernyataan masalah yang samar menghasilkan akar masalah yang samar. "Penjualan menurun" bukan pernyataan masalah. "Kesalahan pemenuhan pesanan meningkat 23% di Q2, menyebabkan 48 keluhan pelanggan" adalah pernyataan masalah yang tepat.

Sertakan apa yang terjadi, di mana itu terjadi, kapan pertama kali disadari, dan apa dampak yang dapat diukur. Langkah ini layak menghabiskan lima menit. Itu menghemat berjam-jam waktu di kemudian hari.

Langkah 2: Tanyakan "Mengapa ini terjadi?" (Why 1)

Fokus pada pernyataan masalah. Tuliskan penyebab langsungnya, penjelasan tingkat pertama untuk apa yang Anda amati. Tetap berdasarkan fakta. Jawaban ini harus dapat diverifikasi, bukan diasumsikan.

Langkah 3: Tanyakan "Mengapa?" tentang jawaban pertama Anda (Why 2)

Ambil penyebab yang baru saja Anda dokumentasikan dan tanyakan mengapa itu terjadi. Anda tidak lagi bertanya tentang masalah aslinya. Anda bertanya tentang penyebab yang Anda identifikasi di Langkah 2. Tuliskan jawabannya.

Langkah 4: Lanjutkan bertanya "Mengapa?" (Why 3-5)

Ulangi proses ini dengan setiap jawaban baru. Di setiap tingkat, tanyakan: apakah ini benar-benar penyebabnya, atau masih gejala? Teruslah sampai salah satu kondisi berikut terpenuhi. Pertama, jawabannya mengungkapkan kegagalan proses, kebijakan, atau sistem yang benar-benar bisa diperbaiki. Kedua, Anda mencapai titik di mana Anda tidak lagi memiliki kendali atas penyebabnya (regulasi eksternal, fisika, batasan tetap). Ketiga, jawabannya mengungkapkan kesenjangan sumber daya atau pengetahuan yang membutuhkan investigasi terpisah.

Jangan memaksakan tepat lima iterasi. Berhentilah ketika Anda telah mencapai asal masalah yang sebenarnya. Lanjutkan melewati lima jika Anda masih menggambarkan gejala.

Langkah 5: Identifikasi akar masalah

"Why" terakhir yang disepakati tim Anda sebagai dapat ditindaklanjuti dan sistemik adalah akar masalah Anda. Tuliskan secara eksplisit. Tinjau rantai dari masalah hingga akar masalah dengan menyuarakannya untuk memastikan masuk akal secara logis di setiap langkah.

Langkah 6: Tentukan tindakan penanggulangan dan verifikasi

Tetapkan tindakan korektif yang spesifik untuk akar masalahnya, bukan untuk gejala di tengah rantai. Tetapkan tanggal target. Tunjuk penanggung jawab. Setelah implementasi, verifikasi bahwa masalah aslinya tidak lagi terjadi. Jika muncul kembali, rantai akar masalah Anda belum lengkap. Gali lebih dalam.

Contoh 5 Whys

Manufaktur: downtime mesin

Berikut contoh perhitungan lengkap dari lingkungan produksi.

Mengganti motor (gejalanya) akan menghabiskan biaya $1.200 dan waktu tunggu dua minggu. Memperbarui checklist hanya membutuhkan waktu 20 menit.

Rekayasa software: gangguan sistem

Sebuah platform SaaS mengalami gangguan kritis yang memengaruhi 2.000 pelanggan.

• Why 1: Server database utama kehabisan ruang disk.
• Why 2: Sebuah batch job menulis file log yang tidak terkompresi ke volume database.
• Why 3: Batch job dikonfigurasi seperti itu secara default dan tidak ada yang mengubahnya.
• Why 4: Tidak ada persyaratan code review untuk konfigurasi batch job.
• Why 5: Proses deployment tidak menandai file konfigurasi non-aplikasi untuk review wajib.

Akar masalah: Kesenjangan dalam proses deployment. File konfigurasi tidak melalui gerbang review yang sama dengan kode aplikasi. Tindakan penanggulangan: Perbarui pipeline deployment agar mewajibkan review engineering untuk semua perubahan konfigurasi. Tambahkan alert ruang disk pada ambang batas 70%.

Layanan pelanggan: lonjakan keluhan

Sebuah perusahaan software berlangganan mengalami lonjakan 30% pada tiket dukungan terkait billing di minggu pertama bulan tersebut.

• Why 1: Pelanggan bingung dengan biaya tak terduga pada invoice mereka.
• Why 2: Perubahan tingkatan harga diluncurkan tanpa memperbarui deskripsi billing di dalam aplikasi.
• Why 3: Tim product dan finance memperbarui pricing engine tetapi tidak memberi tahu tim UX.
• Why 4: Tidak ada checklist lintas fungsi untuk perubahan harga yang menyertakan review UX.

Akar masalah: Langkah yang hilang dalam proses perubahan harga. Tindakan penanggulangan: Buat runbook perubahan harga yang mewajibkan persetujuan dari UX, finance, dan customer success sebelum perubahan apa pun diluncurkan.

Praktik terbaik untuk memaksimalkan 5 Whys

Libatkan orang yang tepat. Sertakan orang yang paling dekat dengan kegagalan dan orang yang memahami sistem hulu. Jangan jalankan 5 Whys hanya dengan manajer yang tidak hadir saat kejadian.

Gunakan fasilitator. Seseorang perlu menjaga tim tetap jujur, menantang jawaban yang samar, dan memastikan setiap "why" mengikuti secara logis dari yang sebelumnya. Fasilitator sebaiknya bukan orang yang paling berkepentingan dengan hasil tertentu.

Dokumentasikan rantainya secara visual. Tuliskan setiap langkah di papan tulis atau dokumen bersama sehingga seluruh rantai terlihat. Tim membuat keputusan lebih baik ketika mereka bisa melihat alur logika dari masalah hingga akar masalah.

Tantang setiap jawaban. Tanyakan "bagaimana kita tahu ini benar?" di setiap langkah. Dugaan yang masuk akal bukanlah penyebab yang terverifikasi. Jika Anda tidak bisa mengonfirmasi jawaban dengan data atau observasi langsung, tandai sebagai asumsi dan validasi sebelum menyelesaikan rantainya.

Kaitkan tindakan penanggulangan dengan akar masalah, bukan gejala. Jika tindakan penanggulangan Anda menangani Why 2 alih-alih Why 5, Anda telah membangun solusi sementara, bukan perbaikan. Solusi sementara menutupi masalah. Perbaikan akar masalah menghilangkannya.

Lakukan tindak lanjut. 5 Whys hanya berguna jika tindakan penanggulangannya diimplementasikan dan diverifikasi. Jadwalkan tinjauan tindak lanjut 30 hari setelah implementasi untuk memastikan masalahnya tidak muncul kembali.

Bacaan terkait

• Analisis Akar Masalah: Panduan yang lebih luas tentang metode RCA, kapan menggunakan masing-masing, dan bagaimana metode ini cocok dengan sistem manajemen kualitas.
• Analisis Pareto: Prioritaskan masalah mana yang perlu diselidiki lebih dulu menggunakan prinsip 80/20.
• Fishbone Diagram: Pelengkap visual untuk 5 Whys dalam memetakan kategori penyebab.
• DMAIC: Kerangka Six Sigma yang menggunakan 5 Whys dalam fase Analyze-nya.
• SIPOC Diagram: Petakan proses Anda sebelum memulai 5 Whys untuk memastikan pernyataan masalah Anda memiliki cakupan yang tepat.

Pertanyaan yang sering diajukan

Mengapa lima, tidak lebih atau kurang?

Angka lima adalah panduan, bukan aturan. Wawasan asli Sakichi Toyoda adalah bahwa sebagian besar masalah operasional memiliki akar masalah yang dapat diakses dalam lima iterasi pertanyaan. Dalam praktiknya, sebagian masalah terselesaikan pada "why" ketiga dan sebagian lainnya benar-benar membutuhkan tujuh. Angka yang penting adalah angka di mana Anda mencapai penyebab yang sistemik dan dapat ditindaklanjuti. Berhentilah ketika Anda sampai di sana, dorong lebih keras jika belum.

Apakah 5 Whys sama dengan analisis akar masalah?

Tidak, tetapi 5 Whys adalah salah satu teknik analisis akar masalah. Analisis akar masalah (RCA) adalah praktik yang lebih luas untuk mengidentifikasi asal yang mendasari sebuah masalah. 5 Whys adalah salah satu alat dalam praktik tersebut. Alat RCA lainnya termasuk fishbone diagram, fault tree analysis, dan failure mode and effects analysis (FMEA). Banyak praktisi RCA menggunakan 5 Whys sebagai titik awal sebelum menambahkan metode statistik yang lebih ketat.

Bisakah Anda menggabungkan 5 Whys dengan fishbone diagram?

Ya, dan itu benar-benar kombinasi yang berguna. Fishbone diagram membantu Anda mengidentifikasi kategori penyebab mana yang paling mungkin (People, Process, Equipment, Materials, Environment, Measurement). Setelah Anda mempersempit ke cabang tertentu, terapkan 5 Whys untuk menggali cabang tersebut dan mengonfirmasi akar masalahnya. Fishbone memperluas; 5 Whys memperdalam.

Kapan sebaiknya Anda tidak menggunakan 5 Whys?

Lewati 5 Whys untuk masalah yang kompleks secara statistik, yang mencakup banyak sistem yang saling terhubung, atau yang membutuhkan dokumentasi formal untuk kepentingan regulasi atau pelanggan. Ini juga bukan alat yang tepat ketika tim tidak memiliki akses ke orang dan data yang paling dekat dengan kegagalan. Dalam kasus tersebut, gunakan fishbone diagram, 8D problem solving, atau failure mode and effects analysis yang lengkap.

Apakah 5 Whys bekerja di lingkungan layanan dan pekerjaan berbasis pengetahuan, tidak hanya manufaktur?

Tentu saja. Metode ini berasal dari manufaktur tetapi bekerja di mana pun sebuah proses dapat didefinisikan dan kegagalan dapat diamati. Tim software menggunakannya dalam post-mortem. Tim customer success menggunakannya untuk mendiagnosis churn. Tim HR menggunakannya dalam tinjauan akar masalah setelah lonjakan turnover. Logika yang sama berlaku: berhenti pada penjelasan pertama yang masuk akal dan masalahnya akan berulang; teruslah bertanya dan Anda akan menemukan apa yang sebenarnya perlu diubah.

5 Whys tidak memerlukan alat khusus atau pelatihan mahal. Yang dibutuhkan adalah kejujuran tentang apa yang tidak Anda ketahui, kesabaran untuk terus mengajukan pertanyaan yang tidak nyaman, dan komitmen organisasi untuk memperbaiki sistem setelah Anda menemukannya. Tim yang membangun kebiasaan itu berhenti memadamkan kebakaran yang sama berulang kali. Itulah hasil nyatanya.