Fishbone Diagram dalam Continuous Improvement

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.