5 Neden formunun son satırında iki kelime yazıyor: "operatör dikkatsizliği". Toplantıdaki herkes başını sallıyor, aksiyon olarak eğitim yazılıyor, kayıt kapanıyor. Kimse şu soruyu sormuyor: aynı operatör aynı işi 11 aydır hatasız yapıyorsa, dikkatsizlik neden tam o vardiyada ortaya çıktı? Kök neden doğrulama tam olarak bu sorunun sorulduğu adımdır ve çoğu analizde atlanan tek adım da budur.
Analiz bitti sanılan yer
Kök neden analizinin en tehlikeli anı, herkesin ikna olduğu andır. Zincir mantıklı görünür, cümleler düzgündür, toplantı uzamıştır ve ekip bitirmek ister. Oysa mantıklı görünmek doğru olmakla aynı şey değil. Bir neden zinciri, hiçbir kanıtla temas etmeden de baştan sona tutarlı yazılabilir.
Bunu ayırt etmek için tek soru yeterli: bu nedeni ortadan kaldırırsam hata biter mi, geri getirirsem yeniden çıkar mı? Cevabı bilmiyorsanız analiz bitmemiştir. Doğrulama, analizin süsü değil, kendisidir; çünkü yanlış kök nedene harcanan aksiyon bütçesi geri gelmez ve altı ay sonra aynı hatayla yeniden karşılaşırsınız.
Kök neden doğrulama için üç test
Sahada üç testi arka arkaya uyguluyorum. Mantık testiyle başlarım: zinciri sondan başa okuyun, "bu olduğu için şu oldu" dediğinizde her adım bir öncekini gerçekten doğuruyor mu? Aradaki sıçramalar burada ortaya çıkar. Ardından aç-kapa testi gelir; nedeni kontrollü biçimde geri getirip hatanın döndüğünü görme denemesidir ve bir sonraki başlıkta ayrıntısını açıyorum. Son sırada kapsam testi durur: bulduğunuz neden, hatanın neden tam o zamanda, o üründe ve o miktarda çıktığını açıklıyor mu?
Üçüncü test en çok eleyen testtir. "Fikstür aşınmış" cevabı doğru olabilir ama fikstür iki yıldır aşınıyorsa, hatanın neden geçen salı çıktığını açıklamaz. Açıklamayan bir kök neden, en fazla katkı sağlayan bir etkendir. Katkı sağlayan etkenleri de not edin ama aksiyonu kök nedene bağlayın.
Bu üç testi sırayla uygulamak on beş dakika sürer ve toplantının sonunda yapılır. Süre kısa, ama etkisi büyük. Doğrulanmamış bir kök nedene bağlanan aksiyon çoğu zaman bir talimat güncellemesi ya da bir eğitim olur; ikisi de ucuz görünür, oysa asıl maliyet hatanın devam etmesidir. Yanlış kök nedenle kapatılan bir kaydın bedeli, aylar sonra hurdada, iadede ve tekrar açılan bir DÖF'te ödeniyor.
Aç-kapa testi nasıl yapılır?
Klasik ve en güçlü doğrulama yöntemi. Bulduğunuz nedeni kontrollü biçimde geri getirin ve hatanın yeniden oluşup oluşmadığına bakın; sonra nedeni ortadan kaldırıp hatanın kaybolup kaybolmadığını görün. Kaynak parametresi düştüğünde nüfuziyet eksikliği tekrar çıkıyor, parametre düzeltildiğinde kayboluyorsa nedeniniz doğrulanmıştır.
Her problemde uygulanamaz. Güvenlik riski varsa, müşteriye hatalı ürün gitme ihtimali doğuyorsa ya da hattı durdurmak gerekiyorsa denemeyi sahada yapmayın. Alternatifler var: deneme kalıbında çalışmak, laboratuvarda tekrar üretmek, arşivlenmiş parçaları ölçmek ya da geçmiş verideki doğal deneyleri kullanmak. Kök neden doğrulama, testin yapılamadığı durumlarda veriyle yürütülür.
| Yazılan kök neden | Uygulanan test | Sonuç |
|---|---|---|
| Operatör dikkatsizliği | Aynı operatörün 11 aylık kaydı incelendi | Elendi — 11 ay hatasız |
| Fikstür aşınmış | Aşınma ölçüldü, 2 yıllık eğilime bakıldı | Katkı sağlayan etken, tek başına açıklamıyor |
| Yeni tedarikçi partisinde sertlik farkı | Eski parti ile deneme üretimi | Doğrulandı — eski partide hata yok |
| Ayar sonrası ilk parça kontrolü atlanıyor | 3 vardiyada 12 ayar gözlendi | Doğrulandı — 12 ayarın 7'sinde atlanmış |
| Çevrim süresi kısaldı, kontrol sığmıyor | Zaman etüdü, 20 çevrim ölçüldü | Doğrulandı — kontrol için 6 saniye eksik |
| Talimat eski revizyonda | Tezgâh nüshası ile master liste karşılaştırıldı | Elendi — nüsha güncel çıktı |
Tablonun asıl anlattığı şu: doğrulama, kök nedeni onaylamak için değil elemek için yapılır. Elenen satırlar analizin başarısızlığı değil, tam tersine kalitesinin göstergesi.
Tabloyu kendi kayıtlarınızla doldurmayı deneyin. Son altı ayın kapanmış analizlerinden beş tanesini alın, kök neden cümlesini birinci sütuna yazın ve ikinci sütunu doldurmaya çalışın. Doldurulamayan satırlar, o kayıtların aslında doğrulanmamış olduğunu gösterir. Bu yarım saatlik çalışma çoğu firmada bir eğitim programından daha çok şey öğretiyor; çünkü örnekler kendi fabrikanızdan geliyor ve tartışma somut zemine oturuyor.
Ekiplere şunu öneriyorum: analiz toplantısının sonunda kök neden cümlesini yazın ve altına tek satır ekleyin: "Bunu şu şekilde doğrulayacağız." Doğrulama yöntemi yazılamayan kök nedenler o toplantıda kabul edilmesin. Bu kural bir fabrikada uygulanmaya başlandığında ilk hafta üç analiz takıldı ve ekip rahatsız oldu. İkinci ayda ise toplantılar kısaldı, çünkü insanlar doğrulanamayacak cümleleri artık masaya getirmiyordu. Bir de şunu deneyin: doğrulama sonucu ne çıkarsa çıksın kayda yazın. Elenen kök nedenleri gizleyen ekipler, bir yıl sonra aynı yanlış cevabı yeniden yazıyor.
Zaman sorusu: neden tam o gün?
Kök neden doğrulama pratiğinde en verimli soru budur. Sistemde bir şey değişmeden hata genelde çıkmaz. Değişimi arayın: yeni parti, yeni operatör, yeni vardiya düzeni, bakım sonrası ilk çalışma, kalıp değişimi, hava koşulu, yazılım güncellemesi, hız artışı. Hatanın başladığı tarihin etrafındaki iki günü kayıtlarla tarayın.
Bu tarama çoğu zaman analizi tek başına bitiriyor. Bir müşteri iadesinde hatanın yalnızca belirli üç günde üretilen parçalarda olduğunu gördük; o üç günde hattaki ölçüm cihazının kalibrasyona gitmiş ve yerine yedeğinin konmuş olduğu ortaya çıktı. Kimse bunu hatırlamıyordu, kayıt hatırladı. Ölçüm sisteminin kendisinden gelen sapmaları ayırmak için MSA tarafına da bakmakta fayda var.
Kaçış noktası ayrı bir zincirdir
Her problemde iki soru vardır: hata neden oluştu ve neden yakalanamadı? İkincisi kaçış noktasıdır ve 8D'de ayrı bir başlık olarak istenir. İki zinciri ayrı yürütmeyen çalışmalar kontrol sistemindeki boşluğu açık bırakır; kök neden kapatılır ama bir sonraki farklı hata da aynı boşluktan geçer.
Kaçış noktasını ararken kontrol planındaki adımı bulun ve şunu sorun: bu kontrol hatayı yakalayacak biçimde tasarlanmış mıydı, tasarlanmıştı da uygulanmadı mı, yoksa böyle bir kontrol hiç yok muydu? Üç cevap üç farklı aksiyon doğurur ve karıştırıldığında yanlış düzeltme yapılır. Kontrol yoksa eklersiniz; varsa ama uygulanmıyorsa neden uygulanmadığına inersiniz; uygulanıyor ama yakalamıyorsa kontrolün kendisini yeniden tasarlarsınız. Üçüncü durum en pahalısıdır ve en çok atlananıdır; çünkü kayıtlarda kontrol "yapıldı" görünür ve kimse kontrolün yeterliliğini sorgulamaz. Yöntem seçimini 8D mi 5 Neden mi yazımızda, araçların kapsamını ise kök neden analizi sayfamızda ele aldık.
Veriyle sınamak
Testin yapılamadığı durumlarda veri devreye girer. Hatanın oluştuğu ve oluşmadığı dönemler arasında, iddia ettiğiniz nedenin varlığı da değişiyor mu? Bu basit karşılaştırma, karmaşık istatistik gerektirmeden çok şey söyler. Elinizde ölçüm verisi varsa kontrol grafiğine bakın; kaymanın başladığı tarih ile nedenin ortaya çıktığı tarih örtüşüyor mu?
Bir uyarı: birlikte değişmek, birinin diğerini doğurduğu anlamına gelmez. İki değişken aynı anda değişiyorsa üçüncü bir sebep ikisini birden sürüklüyor olabilir. Bu yüzden veri tek başına yeterli sayılmaz; veri sizi doğru yere götürür, doğrulamayı yine de sahada yaparsınız. Proses davranışını izlemek için SPC verinizi bu amaçla kullanabilirsiniz.
QMS'te kök neden kanıtını kayda geçirmek
Yazılımda kök neden alanını serbest metin olarak bırakmak, bu adımı görünmez kılıyor. Üç alan ekleyin: kök neden ifadesi, doğrulama yöntemi, doğrulama sonucu. Üçü de dolmadan kayıt bir sonraki aşamaya geçmesin. Dördüncü olarak kök neden kategorisi seçilsin; kategori olmadan tekrar analizi yapılamaz.
Elenen kök nedenler için de yer bırakın. "Değerlendirilen ve elenen nedenler" alanı, denetimde analizin gerçekten yapıldığını gösteren en güçlü kanıttır. Kategori listesini problem çözme, DÖF ve müşteri şikâyeti kayıtlarında ortak tutarsanız aynı kök nedenin kaç farklı kayıtta göründüğünü sayabilirsiniz; kök neden doğrulama alışkanlığının işe yarayıp yaramadığını da o sayının zaman içindeki seyri gösterir.
Kök neden satırında insan davranışı gördüğümde tek bir soru sorarım: bu kişi aynı işi ne kadar süredir yapıyor? Cevap "üç yıldır" ise analizin orada durmaması gerektiğini birlikte konuşuruz. Sonra doğrulama satırına bakarım; boşsa ya da "toplantıda değerlendirildi" yazıyorsa, kök nedenin bir varsayım olduğunu kabul ederim. Son sorum da şu: bir yılda aynı kök neden kaç kayıtta geçiyor? Aynı cümle beş kayıtta tekrar ediyorsa ya kök neden gerçekten sistemik bir sorunu işaret ediyordur ve hiç ele alınmamıştır, ya da ekip kolay cevabı kopyalıyordur. İkisi de konuşulmaya değer.
Doğrulama başarısız çıkarsa
Yanlış çıkan kök neden kaybedilmiş zaman değil, elenmiş bir seçenektir. Zincirde geriye dönün ve son doğrulanmış adımdan yeniden dallanın. Genelde hata, üçüncü ve dördüncü neden arasında yapılan bir sıçramadan kaynaklanır; oradaki boşluğu doldurunca yeni bir yol açılır. Ekibi yeniden toplamak gerekmeyebilir; çoğu zaman iki kişiyle sahada yarım saat yeterli oluyor.
Bir de şu var: bazı problemlerde tek bir kök neden yoktur. İki bağımsız etken üst üste geldiğinde hata çıkıyor olabilir. Bu durumda ikisini de yazın ve ikisine de aksiyon bağlayın; birini seçip diğerini gözden çıkarmak, hatanın yarı yarıya azalıp tamamen bitmemesine yol açıyor. Denetimde de "iki kök neden yazmışsınız" diye bir itiraz gelmez; gelen itiraz her zaman doğrulanmamış tek bir cümleye olur.
Bu geri dönüşü kayıtta gizlemeyin. Aksiyonların doğrulanması tarafında da aynı ilke geçerli; kapanış kriterini ve etkinlik kontrolünü DÖF etkinlik doğrulama yazımızda anlattık. Kök nedenin doğru bulunmadığı bir sistemde etkinlik doğrulaması yalnızca kötü haberi geciktirir.
Kısa bir öz kontrol
Bir sonraki analizinizde şu beş soruyu sorun. Kök neden cümlesinde insan davranışı var mı? Nedeni kaldırdığımda hata biter mi, bunu nasıl gösterebilirim? Hatanın neden tam o gün çıktığını bu neden açıklıyor mu? Kaçış noktası ayrı yazıldı mı? Elediğim nedenleri kayda geçirdim mi? Beşine de cevap verebiliyorsanız kök neden doğrulama adımınız kurulmuş demektir. Kayıt tipini doğru seçmek içinse düzeltme mi düzeltici faaliyet mi ayrımına bakın; doğru analiz, yanlış kayıt tipinde de kaybolabiliyor.