Analisis Akar Masalah di Produksi: 5 Whys dan Fishbone dalam Praktik

By Mirko Peters · 2026-11-11

Analisis akar masalah di produksi, langkah demi langkah: kapan menggunakan 5 whys atau diagram fishbone, cara memverifikasi penyebab, serta contoh kasus downtime lengkap dengan angka.

Automatically translated with AI from the original post. Read the English original

Analisis akar masalah (root cause analysis/RCA) menemukan penyebab mendasar dari suatu masalah, sehingga perbaikan yang dilakukan dapat menghentikan masalah tersebut agar tidak terulang. Di produksi, alat yang lazim digunakan adalah 5 whys dan diagram fishbone. Artikel ini ditujukan bagi manajer produksi yang harus menyelesaikan masalah lini hari ini dan ingin masalah tersebut tetap teratasi. Anda akan mendapatkan rutinitas yang jelas, panduan untuk memilih di antara kedua alat tersebut, contoh kasus downtime lengkap dengan angka, serta daftar kesalahan umum.

Poin Penting

• Analisis akar masalah menemukan penyebab mendasar dari suatu masalah sehingga perbaikan mencegah terulangnya masalah, bukan hanya mengatasi gejalanya.
• Gunakan 5 whys untuk rantai sebab-akibat yang jelas, dan diagram fishbone terlebih dahulu ketika beberapa penyebab mungkin saling berinteraksi.
• Setiap "mengapa" harus dijawab dengan fakta yang teramati atau data terukur, bukan hipotesis, dan penyebab harus diverifikasi sebelum tindakan diambil.
• Mulailah dari kerugian terbesar dengan menggunakan tampilan Pareto, dan prioritaskan bottleneck, karena waktu yang hilang di sana merugikan seluruh lini.
• Perbaikan baru terbukti berhasil ketika pemeriksaan menunjukkan masalah tidak kembali, sehingga jalankan langkah ini sebagai uji coba PDCA kecil.

Apa itu analisis akar masalah di produksi?

iSixSigma menggambarkan analisis akar masalah sebagai cara untuk mengidentifikasi sumber mendasar dari kegagalan proses atau produk. Lembaga ini merekomendasikan dimulai dari pernyataan masalah yang faktual: produk atau proses yang gagal, observasi, jumlah unit yang gagal, serta deskripsi dari pelanggan. Lihat artikelnya tentang diagram Ishikawa dan 5 whys.

Ada tiga istilah yang mudah tertukar:

• Containment melindungi pelanggan atau lini produksi saat ini, misalnya dengan memilah bagian yang mencurigakan. Langkah ini tidak menghilangkan penyebabnya.
• Tindakan korektif adalah perubahan yang menghilangkan penyebab.
• Akar masalah adalah penyebab yang, ketika dihilangkan, mencegah terulangnya masalah dalam kondisi serupa.

Jika Anda hanya melakukan containment, cacat atau gangguan yang sama akan kembali. Jika Anda langsung melompat ke tindakan korektif tanpa penyebab yang terverifikasi, Anda mungkin memperbaiki hal yang salah. RCA berada di antara keduanya.

Kapan menggunakan 5 whys?

Glosarium ASQ menggambarkan Five Whys sebagai teknik yang melibatkan pengulangan pertanyaan "mengapa?". Teknik ini biasanya dijalankan sekitar lima kali, tetapi lebih sedikit atau lebih banyak juga dapat diterima, dan teknik ini dikaitkan dengan Sakichi Toyoda sebagai pengembangnya. Aturannya bersifat praktis:

1. Tulis pernyataan masalah yang presisi dan didukung data.
2. Tanyakan mengapa masalah terjadi dan catat penyebab terdekat yang dapat diamati.
3. Terus tanyakan mengapa untuk setiap jawaban, dengan tetap berpijak pada fakta.
4. Berhenti pada penyebab yang dapat Anda tindaklanjuti untuk mencegah terulangnya masalah.
5. Verifikasi akar masalah: apakah penyebab itu mengarah pada masalah, dan apakah memperbaikinya akan mencegah masalah tersebut?
6. Terapkan tindakan penanggulangan dan pastikan melalui pengukuran lanjutan bahwa masalah tidak terulang.

Halaman yang sama mencatat bahwa setiap jawaban sebaiknya berupa "fakta yang teramati atau titik data terukur, bukan hipotesis". Halaman itu juga menyebutkan bahwa metode ini paling efektif untuk rantai sebab-akibat yang linear dengan satu akar masalah, dan merekomendasikan diagram fishbone untuk masalah yang kompleks.

Kapan diagram fishbone lebih baik?

Diagram tulang ikan, atau diagram Ishikawa, adalah gambaran hipotesis. Efek, misalnya "short shot pada mesin press 3", berada di kepala diagram, dan cabang-cabangnya menunjukkan kemungkinan penyebab. Tim sering mengelompokkan cabang-cabang tersebut menjadi mesin, metode, material, manusia, pengukuran, dan lingkungan. Diagram ini membantu tim melihat banyak kemungkinan penyebab sekaligus dan menyepakati mana yang perlu diuji.

iSixSigma merekomendasikan cara yang jelas untuk mengombinasikan alat-alat tersebut: tuliskan pernyataan masalah dan kumpulkan data terlebih dahulu, bangun diagram dari hipotesis yang menggambarkan efek yang dapat diamati, terapkan 5 whys pada cabang-cabang yang paling mungkin, lalu lacak setiap hipotesis dengan penanggung jawab dan tenggat waktu. Panduan ini juga mengingatkan bahwa diagram hasil brainstorming sering memuat penyebab yang tidak berkontribusi, dan kategori yang samar, seperti "pencahayaan", jarang menunjukkan jalur menuju kegagalan.

Patokan praktisnya: jika hanya ada satu rantai sebab-akibat yang jelas, 5 whys sudah cukup. Jika ada beberapa faktor penyebab yang mungkin, atau tim tidak sepakat, buatlah diagram tulang ikan terlebih dahulu.

Banyak masalah produksi melibatkan lebih dari satu akar masalah sekaligus. Henti singkat dapat berasal dari suku cadang yang aus, pemeriksaan yang terlewat, dan celah pelatihan secara bersamaan. Saat Anda mengidentifikasi akar masalah, tanyakan apakah Anda menemukan salah satu akar masalah atau seluruhnya. Mendefinisikan masalah dengan baik adalah separuh dari jawaban: pernyataan yang sempit, seperti "berhenti di stasiun 3 pada shift malam", menghasilkan lebih sedikit kemungkinan penyebab dibandingkan pernyataan yang luas. Untuk menentukan akar masalah dari cacat yang berulang, bandingkan proses yang baik dan yang buruk, lalu daftarkan apa yang berbeda. Kemudian terapkan tindakan korektif untuk setiap penyebab yang telah terverifikasi, satu per satu, agar Anda dapat melihat mana yang berhasil. Ini adalah pemecahan masalah yang sederhana: fakta dahulu, hipotesis kedua, tindakan terakhir.

Bagaimana cara menjalankan RCA di lini produksi?

1. Tahan. Lindungi pelanggan dan lini produksi terlebih dahulu. Karantina produk yang dicurigai dan pulihkan kondisi yang aman.
2. Pilih masalahnya. Jangan menganalisis semuanya. Gunakan tampilan Pareto, yaitu peringkat kerugian dari yang terbesar ke yang terkecil, dan ambil yang terbesar. Perhatikan lebih dulu bottleneck, yaitu langkah yang membatasi output. Satu menit yang hilang di sana berarti kehilangan bagi seluruh lini, sedangkan satu menit yang hilang pada langkah dengan kapasitas cadangan mungkin tidak berdampak apa pun.
3. Definisikan dengan data. Apa, di mana, kapan, berapa banyak, dibandingkan dengan apa? Berikan angka pada masalah tersebut.
4. Pergi dan lihat langsung. Amati proses nyata di gemba, kata Jepang yang berarti "tempat yang sebenarnya", yaitu lantai produksi. Bicaralah dengan operator yang berada di sana.
5. Temukan kandidat penyebab. Gunakan 5 whys atau diagram tulang ikan bersama tim lintas fungsi: operator, pemeliharaan, kualitas, dan supervisor.
6. Verifikasi. Uji penyebab yang paling mungkin. Jika itu benar, menghilangkannya seharusnya mengubah hasil, dan mengembalikannya seharusnya memunculkan kembali masalahnya.
7. Tindak dan periksa. Jalankan tindakan penanggulangan sebagai uji coba kecil dan ukur hasilnya. Siklus PDCA memberi bentuk pada langkah ini, dan laporan A3 dapat mencatat seluruh proses dalam satu halaman.

Contoh: waktu henti pada satu lini

Contoh ini menggunakan angka asumsi.

Lini 4 beroperasi dua shift masing-masing 8 jam selama 5 hari, sehingga totalnya 80 jam terjadwal. Minggu lalu lini kehilangan 14 jam akibat henti produksi, yaitu 14 ÷ 80 = 17,5%.

Pareto henti produksi:

• Pembacaan sensor keliru: 6,3 jam (45%)
• Pelebihan waktu pergantian produk: 4,2 jam (30%)
• Menunggu material: 2,1 jam (15%)
• Lainnya: 1,4 jam (10%)

Dua penyebab terbesar menyumbang 75% dari kerugian. Tim memulai dengan pembacaan sensor yang keliru.

Five whys.

1. Mengapa lini berhenti? Sensor salah membaca posisi part.
2. Mengapa? Ada debu pada lensa sensor.
3. Mengapa ada debu? Tidak ada yang membersihkan lensa selama shift berlangsung.
4. Mengapa tidak? Pembersihan bukan bagian dari standard work operator.
5. Mengapa tidak? Standard work ditulis sebelum sensor dipasang.

Akar masalahnya adalah celah pada standard work, bukan sensor yang rusak. Tindakan penanggulangannya adalah menambahkan pemeriksaan lensa ke dalam rutinitas awal shift dan memasang penutup kecil.

Efek yang diharapkan. Jika ini menghilangkan 80% henti akibat sensor: 6,3 × 0,8 = 5,04 jam. Waktu henti baru menjadi 14 − 5,04 = 8,96 jam, atau 8,96 ÷ 80 = 11,2%. Pemeriksaan setelah dua minggu akan menunjukkan apakah hasil nyatanya sesuai. Jika tidak, tim kembali ke diagram.

Bagaimana memastikan penyebabnya memang tepat?

Uji temuan sebelum Anda berinvestasi pada perbaikan. Dua pertanyaan sederhana membantu:

• Jika penyebab yang Anda identifikasi berbeda, apakah hasilnya juga akan berbeda?
• Jika penyebab itu dihilangkan, apakah kegagalan yang sama kemungkinan besar tidak akan terulang dalam kondisi serupa?

Kumpulkan data sebelum dan sesudah. RCA yang baik diakhiri dengan hasil yang terukur dan standar yang diubah, dan dengan cara itulah RCA memberi masukan bagi continuous improvement, bukan sekadar memadamkan api. Catat juga faktor penyumbang yang belum Anda perbaiki, misalnya pelatihan atau perangkat pendukung, agar faktor tersebut tidak terlewat.

Berhati-hatilah dengan "kesalahan manusia". Hal ini jarang menjadi akar penyebab. Jika seorang operator melakukan kesalahan, tanyakan mengapa proses memungkinkan kesalahan itu terjadi: apakah instruksinya jelas, apakah alatnya sesuai, apakah ada waktu yang cukup? Jawabannya hampir selalu ada di dalam sistem.

Kesalahan umum

• Berhenti pada why pertama. Jawaban pertama biasanya hanyalah gejala.
• Menjawab dengan opini. Setiap why memerlukan fakta yang teramati atau pengukuran.
• Menyalahkan orang. Menyalahkan mengakhiri diskusi dan menyembunyikan penyebab yang sebenarnya.
• Menganalisis masalah kecil terlebih dahulu. Gunakan tampilan Pareto dan mulailah dari kerugian terbesar.
• Melewatkan verifikasi. Penyebab yang belum diverifikasi akan menghasilkan perbaikan yang tidak berfungsi.
• Tidak mengubah standar. Jika standar kerja tetap sama, masalah akan kembali muncul.

Bagaimana perangkat lunak dapat membantu

Analisis yang baik membutuhkan data yang baik. Perangkat lunak dapat mencatat alasan setiap henti produksi pada saat kejadian, membuat diagram Pareto secara otomatis, dan menunjukkan apakah masalah kembali muncul setelah perbaikan. Hal ini menghemat waktu pada tahap awal RCA dan memberi tim fakta, bukan sekadar ingatan. Alat tidak berpikir menggantikan Anda. Tetap manusia yang harus turun ke gemba dan bertanya mengapa.

Langkah berikutnya

Ambil kerugian terbesar minggu lalu di lini Anda, tulis pernyataan masalah dengan angka, lalu jalankan 5 whys bersama operator yang bertugas saat itu. Setelah itu, verifikasi penyebabnya dengan uji coba kecil. Itulah cara praktis menerapkan root cause analysis di produksi Anda.