Neden Ishikawa (Balık Kılçığı) Diyagramı Kullanıyoruz?

Analiz toplantılarında "sorun ne?" sorusundan sonra gelen ikinci soru çoğu zaman "kim yapmış?" olur. Oysa doğru ikinci soru şudur: bu sonucu üreten koşullar neler?

Ishikawa diyagramı — yaygın adıyla balık kılçığı — tam olarak bu ikinci soruyu sormaya zorlar. Biz de hem metodolojimizde hem de analiz çalışmalarında onu tercih ediyoruz.

Ishikawa diyagramı nedir?

1960'larda Japon kalite uzmanı Kaoru Ishikawa tarafından kalite yönetimi çalışmalarında yaygınlaştırılmış bir kök neden analizi aracıdır. Sağ tarafta sorun (balığın başı), sola doğru uzanan ana gövde ve gövdeye bağlanan kategoriler (kılçıklar) bulunur:

        İnsan            Yöntem            Sistem
           \                |                /
            \               |               /
             \              |              /
  ───────────────────────────────────────────────►  SORUN
             /              |              \
            /               |               \
           /                |                \
         Veri             Ölçüm             Ortam

Her kılçığın altına o kategoriye ait olası sebepler yazılır. Amaç listeyi uzatmak değil; sebepleri görünür kılıp hangisinin gerçekten etkili olduğunu tartışabilmektir.

Neden bu aracı tercih ediyoruz

Belirtiyi kök sebepten ayırır. "Stok bakiyesi tutmuyor" bir belirtidir. Diyagram bizi sayımın nasıl yapıldığını, hangi hareketin geç girildiğini, kimin hangi ekranı kullandığını konuşmaya zorlar.

Suçlu değil sebep arar. Kategoriler kişiler değil koşullar üzerinden kurulduğu için toplantının dili değişir. Savunmaya geçen bir ekipten bilgi alamazsınız; sebep arayan bir ekipten alırsınız.

Kolektif aklı tek sayfada toplar. Muhasebeden, üretimden ve BT'den gelen bilgi aynı kâğıtta yan yana durur. Çoğu zaman kök sebep, tek bir kişinin değil iki bölümün bildiğinin birleşiminden çıkar.

Unutulan alanı hatırlatır. Boş kalan bir kılçık kendi başına bilgidir. "Ölçüm" kılçığı boşsa, o süreçte muhtemelen hiç ölçüm yapılmıyordur.

Kayıt bırakır. Diyagram, alınan aksiyonların neden alındığını gösteren bir belgedir. Altı ay sonra "bunu neden böyle kurmuştuk?" sorusunun cevabı elinizde olur.

ERP projelerinde kullandığımız kılçıklar

Klasik üretim kaynaklı kategorileri (insan, makine, yöntem, malzeme, ölçüm, ortam) kurumsal yazılım bağlamına uyarlıyoruz:

• İnsan — eğitim eksiği, rol dağılımı, devir, yetkinlik
• Yöntem — süreç adımları, onay akışları, istisnaların nasıl yönetildiği
• Sistem — ekranlar, entegrasyonlar, performans, eksik işlevler
• Veri — ana veri kalitesi, kod yapısı, eksik ya da çelişkili kayıtlar
• Ölçüm — neyin ölçüldüğü, ne sıklıkla bakıldığı, raporun kime gittiği
• Ortam — organizasyon yapısı, önceliklendirme, mevzuat, sezonluk yoğunluk

Bu altı başlık, ERP projelerinde karşılaştığımız sorunların neredeyse tamamını kapsıyor.

Nasıl çalıştırıyoruz

1. Sorunu tek cümleyle yazarız. Ölçülebilir ve tarafsız: "Sevkiyat teyidi ortalama 2 gün gecikiyor" gibi. Sorun cümlesi belirsizse diyagram da belirsiz çıkar.

2. Kılçıkları ekiple doldururuz. İşi yapan kişiler odada olur. Bu aşamada eleme yapmayız, fikir toplarız.

3. Her önemli dalda "neden?" diye ilerleriz. Balık kılçığını beş neden tekniğiyle birlikte kullanırız:

Sistem
  └─ Sipariş ekranı yavaş
       └─ Neden? Rapor sorgusu her açılışta çalışıyor
            └─ Neden? Filtrenin varsayılanı "tüm kayıtlar"
                 └─ Neden? Kurulumda varsayılan değiştirilmedi
                      └─ Neden? Devreye alma kontrol listesinde yok  ← kök sebep

4. Veriyle doğrularız. Diyagram hipotez üretir, kanıt üretmez. Hangi sebebin gerçekten baskın olduğunu sistemdeki veriye bakarak sınarız.

5. Aksiyona bağlarız. Her doğrulanmış kök sebebin bir sahibi, bir tarihi ve bir ölçüsü olur. Olmuyorsa toplantı bir sohbetten ibaret kalır.

Ne zaman yetmez

Dürüst olmak gerekirse balık kılçığı tek başına yeterli değildir.

Hipotezleri doğrulamaz; bunun için veri gerekir. Sebeplerin hangisinin daha ağır bastığını söylemez; orada Pareto analizi devreye girer. Birbirini besleyen karmaşık sistem etkileşimlerinde ise fazla doğrusal kalabilir.

Biz de onu tek başına değil, süreç haritası ve veri analiziyle birlikte kullanıyoruz. Gücü, doğru soruyu doğru sırayla sordurmasında.

Analizden çözüme

Kök sebep netleştikten sonra iş değişir: kimi zaman bir eğitim, kimi zaman bir süreç değişikliği, kimi zaman bir ekran ya da entegrasyon gerekir. Bu aşamada Süreç Danışmanlığı ve ERP Proje Yöneticiliği çalışmalarımız devreye giriyor; sonucun ölçülmesi gerektiğinde ErpwareBI ile takip ediyoruz.

Bu konudaki iki yazımız da ilgili olabilir: Başarısız ERP Projesi ve Başarısız işletmelerin ortak özellikleri.