8D raporu kapalı ama problem çözülmemiş: beş işaret

“Problem çözüldü. Vaka kapandı. İmzalandı. Dosyalandı.”

Dokuz ay sonra aynı hata geri döner.

O raporun arkasındaki arşivi açın: bulduklarınızın çoğu bitmiş görünür. Bu raporların pek azı gerçekten bitmiştir ve bozuk bir raporun beş işareti üretim alanında değildir. Belgelerin içindedir ve bir okuyucu hepsini masasından kalkmadan bulabilir.

Bu neden isteğe bağlı değil

8D, yapılandırılmış problem çözmeye yönelik genel bir tercih değildir. Ford’un kendi IATF müşteriye özel şartları (Customer-Specific Requirements), bir tedarikçi kalite reddi için iki süre koyar: 24 saat içinde yanıt ve aynı süre içinde uygulanmış geçici önlem; ardından kök neden ve düzeltici faaliyet planıyla birlikte tam 8D, 15 takvim günü içinde teslim edilir.

Bu iki süre farklı şeyleri ölçer. 24 saatlik süre müşteriyi bugün korur. 15 günlük raporun ise nedenin yalnızca kontrol altına alınmadığını, gerçekten bulunup giderildiğini kanıtlaması beklenir. D3’ü D5’ten hiç ayırmamış bir rapor iki süreye de takvim üzerinde uyabilir, yine de ikincisini özde karşılamayabilir.

Belgeler bunu zaten söylüyor

Bir 8D raporu iki şeyi kanıtlamak için vardır: ekibin neyin yanlış gittiğini anladığını ve bunun tekrar olmasını engellediğini. Çoğu rapor yalnızca birincisini kanıtlar, o da her zaman değil.

Beş kontrol, kapanmış bir raporu işe yaramış bir rapordan ayırır. Onları sırayla, en son kapattığınız 8D’nin üzerinden geçirin.

Bir: düzeltme kılığına girmiş geçici önlem

D3 geçici önlem planıdır: parçaları ayıklamak, bir kontrol eklemek, kanamayı durdurmak. D5 kalıcı düzeltmeyi, yani nedeni ortadan kaldıran çözümü doğrular ve seçer. D6 ise onu uygular.

D3 ile D5 aynı satırı tekrarlıyorsa, ara çözüm hiçbir zaman kalıcı bir çözüme dönüşmemiştir. D3’teki “operatör eğitimi” ile D5’teki “operatörlerin yeniden eğitilmesi” iki ayrı faaliyet değil, iki kez adı konmuş tek bir faaliyettir.

Kökü Ford’un 1987 tarihli Team Oriented Problem Solving el kitabına dayanan 8D çerçevesi, bunları bilerek ayrı adımlar olarak tutar. Geçici önlem zaman kazandırır. Düzeltme ise geçici önlemi baştan gerekli kılan nedeni ortadan kaldırır. İkisini birbirinden ayıramayan bir rapor, nedenin gerçekten ortadan kalkıp kalkmadığını hiç sınamamıştır.

İki: üç satıra sığan bir tanım

D2, problemi üzerinde arama yapılabilecek kadar somut biçimde tanımlamak için vardır: ne, nerede, ne zaman, ne kadar. Üç satırdan kısa bir tanım çoğu zaman yeniden yazılmış bir belirtidir, tanım değildir.

Bu işaret bir paragrafı değil, kendi vakasını hak ediyor. Tek bir hatayı tanımlamak için iki yıl onu baştan sona anlatıyor: tanımlanması iki yıl süren, istendiği anda yeniden üretilebildiğinde ise birkaç haftada düzeltilen bir hata.

Üç: “Olmayan” alanı boş kalmış

Charles Kepner ve Benjamin Tregoe, çoğu raporun atladığı tek bir sorunun etrafında bir yöntem kurdu: hata nerede hiç görülmüyor? 1965 tarihli kitapları The Rational Manager, her problemi aynı şekilde ele alır: önce problemin nerede olduğunu (Olan), sonra nerede olmadığını (Olmayan) yazın. İki sütun arasındaki mesafe, kök nedenin bulunabileceği tek yerdir.

Alman otomotiv sanayii birliği VDA, Kepner-Tregoe Olan / Olmayan yöntemini özellikle bir 8D raporunun D2 ve D4 adımları için önerir ve onu denetime hazır bir analizin göstergesi sayar. IS alanı dolu, Olmayan alanı boş bir rapor hiçbir şeyi daraltmamıştır. Her teori hâlâ mümkündür.

Dört: hiçbir yerde doğrulama tarihi yok

D6, belirli bir süre sonra düzeltici faaliyetin hatayı gerçekten durdurduğunu teyit etmek için vardır. Bir rapor bir düzeltmeyi uygulayıp işe yarayıp yaramadığını hiç kontrol etmeyebilir.

Doğrulama tarihi olmayan kapalı bir rapor, kontrol etme niyetini kaydetmiştir. Kontrolün kendisini kaydetmemiştir.

Beş: tek kök neden, üç rapor numarası

D7, bilinen bir nedenin fabrikanın başka bir yerinde geri dönmesini önlemek için vardır. Bu ancak biri yeni raporları eskileriyle karşılaştırırsa işe yarar.

Aynı kök neden üç ayrı rapor numarasında görünüyorsa D7 daha başlamadan başarısız olmuştur: kimse raporları yan yana koymamıştır. Ağır sanayi genelinde kullanılan bir kök neden metodolojisi olan TapRooT, burada belirgin bir çizgi çeker. “Yetersiz eğitim” bir nedensel faktördür, yani sürecin hatayı geçirdiği noktadır; kök neden, yani sürecin o boşluğa neden izin verdiği değildir. Nedensel faktörde duran bir rapor kapanır. Hatayı geçiren boşluk ise bir sonraki rapor için açık kalır.

Raporlar neden onaylanır da hatalar gitmez

Manchester Üniversitesi’nden James Reason, İsviçre peyniri modelini 1990’da yayımladı. Bir güvenlik sisteminin her katmanında delikler vardır. Çoğu zaman delikler farklı katmanlarda farklı yerlerdedir ve hiçbir şey geçmez. Delikler aynı hizaya geldiğinde arıza olur.

Bir 8D arşivi de aynı şekilde çalışır. Her rapor kendi deliğini yakalar. Kimse raporları birbirinin hizasına koymaz. Form imzalanmak için tasarlanmıştır; beş ayrı raporun her birinin kendi başına zaten tarif ettiği bir boşluktan geri dönen hatayı yakalamak için değil.

Bir zamanlar üzerinde çalıştığım bir sızıntı on beş yıldır açıktı. Gerçekte ne olduğunu, problemin tamamını ve dokunduğu her proses adımını yazıya döktüğümüzde düzeltme dört gün sürdü ve problem kalıcı olarak çözüldü. Zor kısım hiçbir zaman belgeler olmamıştı. Zor olan, problemin doğru bir tanımını yazmaktı.

Her problem bir 8D’yi hak etmez

8D, müşteri şikâyetleri ve tam bir ekip incelemesini gerektirecek kadar ciddi problemler için tasarlanmıştır. Bir iç sapmayı ya da küçük bir hurda olayını sekiz disiplinin hepsinden geçirmek, bir öğleden sonranın yeteceği bir probleme bir haftalık mühendislik zamanı harcamak demektir.

İç sapmalar için 4-Step vardır. Sürekli iyileştirme için PDCA. Görür görmez düzeltilebilecek kadar basit her şey için Just-Do-It. Yöntem çözüme giden yolu kısaltmalıdır. Yanlış yöntem onu yalnızca uzatır.

Bir raporu gerçekten ne kapatır

İmzalı bir 8D, belgelerin doldurulduğunu kanıtlar. Hiç geri dönmeyen bir hata, düzeltmenin işe yaradığını kanıtlar. Bu iki iddiadan yalnızca biri “kapalı” kelimesini hak eder.

En son kapattığınız 8D’yi açın. Beş işareti sırayla onun üzerinde kontrol edin. Raporların çoğu en az birinde takılır.

galileon.si’de daha fazlası

• Tek bir hatayı tanımlamak için iki yıl: Toyota’nın geri çağırması problem tanımı hakkında ne öğretiyor - ikinci işaretin arkasındaki vakanın tamamı: iki yıllık maliyetin tamamı problem tanımıydı.
• SolveR nasıl çalışır
• Veri işleme

Kaynaklar

• AllAboutLean, “The History of the 8D Problem Solving Process”, erişim tarihi 1. 9. 2026 - 8D’nin kökeni: Ford’un 1987 tarihli Team Oriented Problem Solving (TOPS) el kitabı.
• Ford, IATF Customer-Specific Requirements, bölüm 10.2.2, erişim tarihi 1. 9. 2026 - 24 saat içinde yanıt ve geçici önlem, kök neden ve düzeltici/önleyici faaliyet planı içeren tam 8D için 15 takvim günü.
• Charles H. Kepner, Benjamin B. Tregoe, The Rational Manager, 1965 - Olan / Olmayan problem tanımlamasının kökeni.
• Kepner-Tregoe, “8D Problem Solving: VDA recommends Kepner-Tregoe IS and IS NOT”, erişim tarihi 1. 9. 2026.
• James Reason, “Human Error: Models and Management,” Philosophical Transactions of the Royal Society of London, Series B, vol. 327, 1990, pp. 475-484 - İsviçre peyniri modelinin kökeni.
• TapRooT, “What Is a Causal Factor?”, erişim tarihi 1. 9. 2026.