8D formu neden tek başına çalışan bir problem çözme sistemi değildir?

Bir metodoloji ile onun çıktısını karıştırmak

Otomotiv ve havacılık tedarik zincirinde 8D neredeyse ortak bir dildir. Çoğu kurumda prosedür yazılmış, şablon hazırlanmış, ekipler eğitilmiştir. Buna rağmen aynı cümle sık duyulur: “8D yapıyoruz ama aynı problem tekrar ediyor.”

Bu cümle bir metodoloji eleştirisi değildir. 8D, doğru uygulandığında son derece disiplinli bir problem çözme yaklaşımıdır. Sorun genellikle şurada başlar: kurumlar 8D’yi bir belge olarak benimser, oysa 8D bir yürütme sırasıdır. Belge o sıranın çıktısıdır; sıranın kendisi değildir.

D1–D8 aslında ne ister?

Adımlara dikkatle bakıldığında, 8D’nin bir rapordan çok daha fazlasını talep ettiği görülür. Her adım aslında bir kapıdır: önceki kapı gerçekten kapanmadan sonrakine geçilmemelidir.

Bu tablonun sağ sütunundaki hiçbir madde bir form alanı değildir. Hepsi bir davranıştır — ve davranışı yürüten bir mekanizma yoksa, o alan sonunda yalnızca metin olarak doldurulur.

Formun yapabildiği ve yapamadığı

Sağdaki liste, bir yazılım özellik listesi değildir. Bunlar, kurumun bugün insan dikkatiyle yaptığı işlerdir. Birisi hatırlar, birisi kovalar, birisi toplantıda sorar. İş yürür — ta ki o kişi izne çıkana, başka bir krize dalana veya kurumdan ayrılana kadar.

Formun kırıldığı altı nokta

1. D3, saat ölçeğinde bir iştir

Geçici önlem, 8D’nin en zaman baskılı adımıdır: şüpheli stok, sevkiyat durdurma, müşteri bilgilendirmesi. Bu işler günlerce bekleyemez ve genellikle farklı departmanların sorumluluğundadır. Bir belge alanı, “lojistiğin şüpheli stoğu 8 saat içinde bloke etmesi” gerekliliğini işletemez.

2. Oluşum ve kaçış ayrı iki zincirdir

D4, problemin neden oluştuğunu ve neden yakalanamadığını ayrı ayrı sorar. Pratikte formun tek bir “kök neden” alanı olduğunda ikinci soru sessizce düşer. Sonuç şudur: üretim nedeni düzeltilir, kontrol sistemindeki boşluk olduğu gibi kalır — ve bir sonraki farklı problem yine müşteriye kadar gider.

3. Analiz ile aksiyon arasındaki bağ kopar

D4’ün çıktısı D5–D6’nın girdisidir. Ama analiz bir dosyada, aksiyon başka bir listede yaşadığında bu bağ izlenemez hâle gelir. Altı ay sonra “bu aksiyon hangi kök nedene karşı alınmıştı?” sorusunun cevabı yoktur.

4. Müşteri özel terminler tek bir tarih alanına sığmaz

Farklı OEM’ler farklı yanıt süreleri bekler; aynı müşteri bile vakanın kritikliğine göre farklı davranır. Sabit bir “termin” alanı bu gerçeği taşıyamaz. Taşıyamadığı için de terminler bir tablo ya da takvimde, sistemin dışında yaşamaya devam eder.

5. Kanıt, hangi kararın kanıtı olduğu bilinmeden anlamsızdır

8D dosyasına on ek koymak zor değildir. Denetimde sorulan soru ise farklıdır: “Bu adımın kapanmasına hangi kanıtla karar verildi?” Ekleri karara bağlamayan bir yapı, denetim öncesinde her seferinde yeniden derleme işi üretir.

6. D7 pratikte en sık atlanan adımdır

Vakanın müşteriye kapatılması, kurumun öğrenmesi anlamına gelmez. Benzer ürün, benzer proses ve benzer kontrol planlarına yayma adımı zaman baskısında ilk düşen adımdır — çünkü onu talep eden bir mekanizma yoktur.

“Tamamlandı” ile “işe yaradı” aynı şey değildir

8D’nin en kolay kaybedilen ayrımı budur. Bir aksiyonun tamamlanması bir çıktıdır; problemi önlemesi bir sonuçtur. İkisi arasında zaman, ölçüm ve bazen birkaç üretim partisi vardır.

Etkinlik doğrulaması ayrı bir adım olarak tanımlanmadığında, vaka tamamlanma beyanıyla kapanır. Bu, denetimde bir bulgu üretmeyebilir — ama üretim tarafında altı ay sonra aynı hatanın tekrarı olarak geri döner. Kurumsal maliyeti asıl burada oluşur.

Aynı problem neden tekrar eder?

Tekrar eden problemler genellikle kötü kök neden analizine bağlanır. Saha gözlemi çoğu zaman başka bir şey söyler: analiz makuldür, aksiyon mantıklıdır, ama zincirin sonraki halkaları kopmuştur.

• Aksiyon tanımlanmıştır ama gerçek bir göreve, sahibe ve termine dönüşmemiştir.
• Görev tamamlanmıştır ama etkinliği ölçülmemiştir.
• Etkinlik ölçülmüştür ama sonuç yalnızca o vakanın dosyasında kalmıştır.
• Benzer bir problem başka bir hatta açıldığında, önceki öğrenmeyi bulmanın pratik bir yolu yoktur.

Dördü de belge sorunu değil, yürütme sorunudur. Ve dördü de aynı yerden kaynaklanır: metodolojinin adımları arasında çalışan bir mekanizma yoktur.

Form yerine zincir: ne değişir?

8D’yi bir belge yerine bir yürütme zinciri olarak ele almak, adımları değiştirmez — adımların nasıl yaşadığını değiştirir.

Bu tablodaki sağ sütun, 8D’ye yeni bir şey eklemez. Metodolojinin zaten istediği ama bir belgenin yerine getiremeyeceği şeyleri isimlendirir.

Nereden başlanır

Yeni bir 8D şablonu hazırlamak bu boşluğu kapatmaz; genellikle yalnızca doldurma yükünü artırır. Daha işe yarar bir başlangıç, kapanmış tek bir gerçek vakayı alıp şu dört soruyu sormaktır:

1. D3 aksiyonlarının sorumlusu ve süresi nerede yaşıyordu?
2. D4’ün çıktısı hangi aksiyona, izlenebilir biçimde bağlıydı?
3. Hangi adım, hangi kanıtla kapandı?
4. D7 gerçekten yapıldı mı; yapıldıysa çıktısı bugün nerede?

Bu dört sorunun cevabı çoğu kurumda “e-posta, tablo ve birkaç kişinin hafızası” çıkar. Bu kötü bir yönetim işareti değildir; yalnızca metodolojinin yürütme karşılığının henüz kurulmadığını gösterir.

Aradaki farkın kavramsal çerçevesi için kalite kaydı ile kalite operasyonu arasındaki fark yazısına; bu zincirin bir üründe nasıl işletildiğini görmek için Müşteri Şikâyeti Yönetimi sayfasına bakabilirsiniz.