Do’s and Dont’s dalam Penggunaan 5 Why’s dan Fishbone Diagram

Fishbone Diagram (Ishikawa) dan 5 Why termasuk yang paling sering digunakan dalam praktik Quality Management dan Continuous Improvement. Diagram fishbone membantu memetakan berbagai kategori penyebab secara visual, sedangkan 5 Why menggali kedalaman masalah dengan pertanyaan berulang “Mengapa?”. Kombinasi yang baik dari keduanya menolong tim menemukan akar penyebab masalah yang sesungguhnya, sehingga corrective action yang diambil lebih tepat sasaran dan berkelanjutan.

Beberapa do's dan don't yang penting diperhatikan pada saat menggunakan tools ini.

Do’s (Hal yang Harus Dilakukan)

• Definisikan masalah dengan jelas
  Problem statement harus spesifik mencakup what, when, where, magnitude problem
• Libatkan tim lintas fungsi
  Perspektif dari berbagai departemen memperkaya analisis dan mengurangi bias.
• Lakukan breakdown kategori Fishbone secara sistematis
  Pastikan kategori yang digunakan mutually exclusive (tidak tumpang tindih) dan collectively exhausted (mencakup semua kemungkinan). Dengan demikian, analisis lebih terstruktur dan tidak ada penyebab yang terlewat atau bercampur. Umumnya digunakan kategori 5M (Man, Machine, Method, Measurement, Material) yang memenuhi prinsip "tidak tumpang tindih" dan "mencakup semua kemungkinan"
• Gunakan Fishbone untuk brainstorming, lalu 5 Why untuk pendalaman
  Fishbone memetakan kategori penyebab, 5 Why's menggali akar penyebab masalah dari faktor dominan.
• Validasi akar penyebab masalah dengan data atau eksperimen kecil
  Pastikan akar penyebab masalah tervalidasi sebelum corrective action dijalankan.

Don’ts (Hal yang Harus Dihindari)

• Jangan lakukan analisis sendirian
  Tools ini dirancang untuk kolaborasi tim, bukan individu.
• Hindari membuat kesimpulan terlebih dahulu lalu menggunakan Fishbone atau 5 Why's hanya untuk membuktikan kesimpulan tersebut.
  Analisis harus terbuka, objektif, dan berbasis data, bukan sekadar menjustifikasi hipotesis awal
• Jangan lupa menindaklanjuti dengan corrective action yang terukur
  Analisis tanpa aksi hanya menghasilkan dokumen, bukan perbaikan nyata.
• Jangan salah fokus pada gejala, bukan akar penyebab masalah
  Misalnya menyalahkan operator, padahal akar penyebab masalah bisa berupa sistem training atau instruksi kerja.