Jangan Terburu-buru Mencari Solusi Sebelum Memahami Penyebab Masalah
Dalam Continuous Improvement, ada satu kebiasaan yang sering dilakukan banyak perusahaan.
Ketika masalah muncul, kita langsung mencari solusi.
Picking error meningkat? Training operator.
Delivery terlambat? Tambah armada.
Produktivitas turun? Tambah manpower.
Mesin sering berhenti? Beli mesin baru.
Stock discrepancy? Perketat stock opname.
Semua terdengar masuk akal.
Tetapi ada satu pertanyaan yang sering terlupakan:
"Apakah kita sudah benar-benar memahami penyebab masalahnya?"
Karena masalah yang terlihat belum tentu merupakan akar masalah.
Dan di sinilah Fishbone Diagram menjadi salah satu tools penting dalam Continuous Improvement.
Apa Itu Fishbone Diagram?
Fishbone Diagram dikenal juga sebagai:
Ishikawa Diagram
Cause-and-Effect Diagram
Cause & Effect Analysis
Disebut Fishbone karena bentuk diagramnya menyerupai tulang ikan.
Di bagian kepala ikan terdapat masalah atau effect.
Kemudian dari garis utama muncul beberapa "tulang" yang mewakili berbagai kelompok kemungkinan penyebab.
Secara sederhana:
CAUSE → CAUSE → CAUSE → EFFECT
Tujuannya bukan langsung menemukan satu jawaban.
Tujuannya adalah:
Membantu tim melihat masalah dari berbagai sudut pandang dan mengidentifikasi kemungkinan penyebab secara sistematis.
Mengapa Tidak Langsung Menggunakan 5 Why?
Ini pertanyaan yang menarik.
Kalau kita sudah memiliki 5 Why, mengapa masih membutuhkan Fishbone?
Karena keduanya memiliki fungsi yang berbeda.
Fishbone digunakan untuk memetakan kemungkinan penyebab.
Sedangkan 5 Why digunakan untuk menggali lebih dalam salah satu penyebab tersebut.
Jadi keduanya bukan kompetitor.
Justru saling melengkapi.
Contohnya:
Problem: Picking Error
Fishbone membantu kita melihat:
Man
Method
Machine
Material
Measurement
Environment
Setelah itu kita menemukan bahwa Material: SKU memiliki kemasan yang sangat mirip merupakan salah satu penyebab potensial.
Kemudian kita lakukan 5 Why terhadap penyebab tersebut.
Fishbone Tidak Mencari Siapa yang Salah
Ini salah satu filosofi terpenting.
Ketika terjadi kesalahan, organisasi sering mencari:
"Siapa yang melakukan kesalahan?"
Continuous Improvement justru bertanya:
"Mengapa sistem memungkinkan kesalahan itu terjadi?"
Misalnya terjadi salah picking.
Cara berpikir tradisional:
Operator tidak teliti.
Selesai.
Tetapi Fishbone memaksa kita melihat lebih luas.
Mungkin:
Man
Operator belum cukup familiar dengan SKU.
Method
SOP picking tidak memberikan metode verifikasi yang memadai.
Machine
Scanner tidak selalu digunakan.
Material
Dua SKU memiliki kemasan yang hampir identik.
Measurement
Tidak ada monitoring picking error secara real-time.
Environment
Lokasi kedua SKU terlalu berdekatan.
Sekarang masalah terlihat jauh lebih kompleks.
Dan justru dari sinilah improvement yang sebenarnya bisa dimulai.
Menggunakan 6M
Salah satu pendekatan paling populer dalam Fishbone adalah 6M.
1. Man
Berkaitan dengan manusia.
Contohnya:
skill,
knowledge,
training,
experience,
fatigue,
workload,
manpower,
human error.
Tetapi hati-hati.
"Operator tidak teliti" bukan otomatis root cause.
Itu baru sebuah kemungkinan.
Kita tetap harus bertanya:
Mengapa operator bisa melakukan kesalahan tersebut?
2. Method
Berkaitan dengan cara kerja.
Misalnya:
SOP,
Work Instruction,
Standard Work,
workflow,
sequence,
approval,
inspection procedure.
Kadang masalah bukan karena orang tidak mengikuti SOP.
Masalahnya justru:
SOP-nya sendiri tidak efektif.
3. Machine
Berkaitan dengan mesin, equipment, dan teknologi.
Misalnya:
forklift,
conveyor,
barcode scanner,
weighing scale,
WMS,
printer,
automation,
sensor.
Contohnya:
Picking error terjadi karena barcode scanner sering gagal membaca barcode.
Jika kita hanya melakukan training operator, masalah tidak akan selesai.
4. Material
Berkaitan dengan material atau produk.
Misalnya:
ukuran,
bentuk,
packaging,
kualitas,
labeling,
SKU similarity,
material handling characteristics.
Dalam warehouse, kategori ini sangat penting.
Dua SKU yang memiliki bentuk dan kemasan hampir sama dapat meningkatkan risiko salah picking.
5. Measurement
Berkaitan dengan pengukuran dan data.
Misalnya:
KPI,
accuracy,
measurement method,
frequency,
calibration,
data accuracy,
reporting system.
Kadang perusahaan sebenarnya memiliki masalah, tetapi tidak menyadarinya karena cara mengukurnya salah.
6. Mother Nature / Environment
Berkaitan dengan lingkungan kerja.
Misalnya:
layout,
lighting,
temperature,
noise,
humidity,
space,
ergonomics,
congestion.
Dalam warehouse, layout bisa sangat menentukan.
Jarak yang terlalu jauh.
Aisle terlalu sempit.
SKU yang mirip diletakkan berdekatan.
Pencahayaan kurang.
Semua bisa menjadi penyebab.
Contoh Fishbone di Warehouse
Mari kita ambil sebuah kasus:
Picking Error meningkat.
Kemudian kita lakukan brainstorming menggunakan 6M.
MAN
Operator baru
Training belum cukup
Fatigue
Manpower kurang
Kurang familiar dengan SKU
METHOD
SOP tidak jelas
Tidak ada double check
Tidak ada standard scanning
Picking sequence tidak optimal
MACHINE
Scanner error
Printer label bermasalah
WMS lambat
Battery scanner habis
MATERIAL
SKU mirip
Packaging sama
Barcode sulit dibaca
Label mudah rusak
MEASUREMENT
KPI hanya melihat quantity
Error tidak dikategorikan
Tidak ada real-time monitoring
Data error tidak akurat
ENVIRONMENT
Lighting kurang
Lokasi SKU terlalu dekat
Layout tidak optimal
Area terlalu padat
Sekarang kita mempunyai peta kemungkinan penyebab.
Dan inilah kekuatan Fishbone.
Tetapi Fishbone Bukan Bukti
Ini bagian yang sangat penting.
Ketika tim membuat Fishbone, biasanya akan muncul banyak kemungkinan penyebab.
Tetapi:
Kemungkinan penyebab ≠ akar masalah.
Misalnya tim menulis:
Training operator kurang.
Apakah benar?
Belum tentu.
Harus dibuktikan dengan data.
Misalnya setelah dianalisis:
Operator yang sudah mengikuti training:
Error = 1,2%
Operator yang belum mengikuti training:
Error = 1,3%
Ternyata perbedaannya kecil.
Berarti training mungkin bukan faktor utama.
Sebaliknya:
SKU yang memiliki packaging mirip:
Error = 7,5%
SKU dengan packaging berbeda:
Error = 0,8%
Sekarang kita mempunyai indikasi yang lebih kuat.
Fishbone membantu kita membuat hipotesis.
Data membantu kita menguji hipotesis tersebut.
Di Sini Gemba Menjadi Penting
Fishbone sebaiknya tidak dibuat hanya di ruang meeting.
Jangan hanya:
Manager + Supervisor + PPT + Whiteboard.
Kemudian semua orang menebak-nebak penyebab.
Lebih baik:
Go to Gemba.
Pergi ke tempat masalah terjadi.
Lihat prosesnya.
Amati operator.
Lihat material.
Periksa sistem.
Tanyakan kepada orang yang melakukan pekerjaan.
Kadang operator justru mengetahui masalah yang tidak terlihat dalam laporan management.
Misalnya:
"Pak, sebenarnya scanner ini sering error. Tetapi kalau kami laporkan, biasanya dianggap masalah operator."
Kalimat seperti itu bisa membuka mata.
Karena itu:
Data tells you where to look. Gemba tells you what is actually happening.
Fishbone Harus Menghindari "Blaming"
Bayangkan sebuah perusahaan memiliki masalah:
Delivery terlambat.
Fishbone pertama:
Man → Driver tidak disiplin.
Selesai?
Belum.
Coba kita gali.
Man
→ Driver terlambat.
Method
→ Scheduling belum optimal.
Machine
→ Kendaraan sering breakdown.
Material
→ Loading preparation terlambat.
Measurement
→ KPI hanya mengukur delivery, bukan loading lead time.
Environment
→ Kemacetan di jalur tertentu.
Sekarang kita melihat bahwa masalah delivery bukan hanya masalah driver.
Bisa jadi driver hanya berada di ujung proses yang menghasilkan keterlambatan.
Fishbone Membantu Mengubah Cara Berpikir
Tanpa Fishbone:
Problem → Blame → Solution
Dengan Fishbone:
Problem → Possible Causes → Data → Root Cause → Countermeasure
Ini perubahan yang sangat besar.
Karena Continuous Improvement bukan bertujuan mencari orang yang salah.
Continuous Improvement bertujuan:
membuat proses menjadi lebih baik.
Fishbone dan Pareto
Fishbone akan semakin kuat ketika digunakan bersama Pareto.
Keduanya memiliki fungsi berbeda.
Pareto
Menjawab:
"Masalah mana yang paling dominan?"
Fishbone
Menjawab:
"Apa saja kemungkinan penyebab masalah tersebut?"
Contoh:
Data menunjukkan ada 1.000 warehouse errors.
Pareto menunjukkan:
Wrong SKU = 420
Maka kita fokus pada Wrong SKU.
Kemudian Fishbone digunakan:
Wrong SKU
→ Man
→ Method
→ Machine
→ Material
→ Measurement
→ Environment
Setelah itu kita validasi penyebab dengan data.
Jadi alurnya:
Data
↓
Pareto
↓
Fishbone
↓
Validation
↓
5 Why
↓
Root Cause
Ini jauh lebih kuat daripada sekadar membuat Fishbone tanpa data.
Fishbone dan 5 Why
Setelah Fishbone dibuat, kita dapat memilih penyebab yang paling signifikan untuk dianalisis lebih lanjut menggunakan 5 Why.
Misalnya:
Problem: Wrong SKU
Fishbone menunjukkan:
Material → SKU memiliki packaging yang mirip.
Kemudian 5 Why:
Why 1
Mengapa operator mengambil SKU yang salah?
→ Karena SKU A dan B memiliki packaging yang mirip.
Why 2
Mengapa SKU tersebut dapat tertukar?
→ Karena lokasinya berdekatan.
Why 3
Mengapa lokasinya berdekatan?
→ Karena slotting hanya berdasarkan movement.
Why 4
Mengapa slotting hanya berdasarkan movement?
→ Karena similarity SKU belum menjadi parameter slotting.
Why 5
Mengapa similarity SKU belum menjadi parameter?
→ Karena belum ada standard untuk mengidentifikasi dan mengendalikan similar SKU.
Sekarang kita mulai mendekati root cause.
Jangan Berhenti pada "Human Error"
Ini mungkin salah satu pelajaran terbesar dari Fishbone.
Human Error sering kali merupakan akibat, bukan akar masalah.
Jika seseorang salah memasukkan data, tanyakan:
Apakah sistem memberikan warning?
Apakah interface-nya membingungkan?
Apakah prosesnya terlalu manual?
Apakah SOP jelas?
Apakah workload terlalu tinggi?
Apakah data yang diberikan benar?
Apakah orang tersebut sudah dilatih?
Dengan demikian kita menggeser perspektif:
Human Error
menjadi:
Human + Process + System + Environment
Dan ini membuat improvement menjadi lebih sustainable.
Fishbone dalam Manufacturing
Fishbone sangat populer dalam manufacturing.
Misalnya:
Defect Rate meningkat.
Kemungkinan penyebab:
Man
Skill operator.
Machine
Machine setting.
Method
Work instruction.
Material
Raw material variation.
Measurement
Inspection method.
Environment
Temperature atau humidity.
Kemudian setiap kemungkinan penyebab diuji.
Bukan berdasarkan opini.
Tetapi berdasarkan:
data + observation + experiment.
Fishbone dalam Warehouse
Dalam warehouse, Fishbone bisa digunakan untuk menganalisis:
Picking Error
Putaway Error
Inventory Discrepancy
Damaged Goods
Late Shipment
Loading Delay
Receiving Delay
Productivity Drop
Excessive Overtime
Space Utilization
Stock Accuracy
Delivery Error
Jadi Fishbone bukan hanya tool manufacturing.
Ia sangat relevan untuk:
Warehouse
Logistics
Supply Chain
Procurement
Quality
Production
bahkan office process.
Kesalahan Umum dalam Membuat Fishbone
1. Terlalu cepat menyimpulkan
"Operator tidak teliti."
Padahal belum ada bukti.
2. Semua kemungkinan dianggap root cause
Fishbone hanya menghasilkan potential causes.
3. Tidak menggunakan data
Brainstorming saja tidak cukup.
4. Tidak melakukan Gemba
Masalah bisa berbeda antara laporan dan kondisi lapangan.
5. Terlalu banyak penyebab
Fishbone bukan tempat untuk memasukkan semua kemungkinan tanpa prioritas.
6. Berhenti setelah Fishbone
Setelah Fishbone harus ada validation dan root cause analysis.
Fishbone Bukan Sekadar Diagram
Kalau hanya menggambar tulang ikan di whiteboard, Fishbone tidak akan menghasilkan improvement.
Nilai sebenarnya ada pada proses berpikir di baliknya:
Observe
↓
Question
↓
Analyze
↓
Validate
↓
Improve
Fishbone membantu tim untuk tidak terjebak pada satu asumsi.
Dari "Siapa yang Salah?" Menjadi "Apa yang Salah dalam Sistem?"
Inilah perubahan mindset yang paling penting.
Organisasi yang masih menggunakan pendekatan lama bertanya:
"Siapa yang melakukan kesalahan?"
Organisasi yang mulai menerapkan Continuous Improvement bertanya:
"Proses apa yang memungkinkan kesalahan tersebut terjadi?"
Dan organisasi yang sudah matang bertanya lebih jauh:
"Bagaimana kita mendesain proses agar kesalahan tersebut sulit terjadi kembali?"
Inilah yang kemudian membawa kita menuju konsep:
Poka-Yoke.
Bukan hanya memperbaiki manusia.
Tetapi memperbaiki sistem agar manusia lebih sulit melakukan kesalahan.
Penutup
Fishbone Diagram pada dasarnya adalah sebuah alat sederhana.
Gambarnya hanya seperti tulang ikan.
Tetapi cara berpikir di baliknya sangat penting.
Karena ketika masalah terjadi, kita sering tergoda untuk mencari jawaban tercepat.
Operator salah.
Mesin rusak.
Supplier terlambat.
Sistem bermasalah.
Padahal jawaban pertama belum tentu jawaban yang benar.
Fishbone mengajarkan kita untuk berhenti sejenak dan berkata:
"Mari kita lihat masalah ini dari berbagai sisi."
Man.
Method.
Machine.
Material.
Measurement.
Environment.
Kemudian setiap kemungkinan penyebab diuji dengan data.
Karena dalam Continuous Improvement:
Kita tidak memperbaiki apa yang kita asumsikan sebagai masalah. Kita memperbaiki apa yang benar-benar terbukti menjadi penyebab masalah.
Dan pada akhirnya, tujuan Fishbone bukan menghasilkan diagram yang indah.
Tujuannya adalah menemukan root cause sehingga kita tidak hanya memadamkan api.
Tetapi menemukan mengapa api terus muncul.
Karena Continuous Improvement bukan tentang memperbaiki masalah yang sama berulang kali.
Continuous Improvement adalah membuat masalah yang sama tidak perlu terjadi lagi.
.png)
.png)
.png)
.png)
.png)

.png)