Müşteri kalite mühendisinin e-postası sabah 09:04'te düştü: montaj hattında 3 parça geçmemiş, 1.400 adetlik sevkiyat bloke edilmiş, 24 saat içinde geçici önlem, 10 gün içinde tam rapor isteniyor. Böyle bir sabahta en kötü senaryo, birinin masasında boş bir 8D şablonu açıp doldurmaya başlamasıdır; çünkü o dosya iki gün sonra üç farklı sürümle dolaşmaya başlar. 8D raporu nasıl hazırlanır sorusunun sahadaki cevabı şudur: rapor bir Word dosyası olarak değil, sistemde tek bir kayıt olarak yürür ve her adım kanıtıyla birlikte oraya yazılır. Aşağıda D1'den D8'e kadar hangi ekranda neyin doldurulacağını, saat baskısı altında nasıl ilerleneceğini anlatıyorum.
İlk 24 saatte ne olur?
Saat baskısı altında sıra karışır; ekipler çoğu zaman kök nedeni bulmadan müşteriye bir cevap yetiştirmeye çalışır ve iki gün orada kaybolur. Oysa ilk gün yapılacak iş üçtür ve hiçbiri kök neden değildir: ekibi kurmak, problemi verilerle tanımlamak, ürünü akıştan çekmek. Bunları sistemde tek bir kayıt açarak başlatın; kaydın numarası müşteri şikâyet numarasıyla ilişkilendirilsin.
Kayıt açıldığı anda müşteri bilgileri, parça numarası, sevkiyat tarihleri ve şikâyet adedi girilir. Kayda müşterinin gönderdiği fotoğraf ve rapor eklenir. Bu bir dakikalık iş, on gün boyunca herkesin aynı veriye bakmasını sağlar. Sistemde açılan kayıt aynı zamanda DÖF sürecinizle aynı akışı kullanır; 8D, müşteri kaynaklı kayıtlarda o akışın genişletilmiş hâlidir.
D1: Ekibi kurmak
Ekip alanına isim listesi yazmak yetmez; her ismin yanında rol ve birim olmalıdır. Tipik bir ekip şöyledir: ekip lideri (kalite mühendisi), proses sahibi (üretim şefi), bakım temsilcisi, ürün mühendisi ve gerekirse tedarikçi temsilcisi. Müşteri raporda ekip listesini görmek ister, çünkü tek kişilik 8D'lerin kök nedene ulaşmadığını o da bilir.
Ekip üyelerini sistemde kayda eklemenin bir faydası daha var: her üye kendi aksiyonunu kendi ekranında görür. Bakımın yapacağı iş kalite mühendisinin takip listesinde beklemez, bakım sorumlusunun listesine düşer. Bu ayrım on günlük süreçte birkaç gün kazandırır.
Ekip liderini müşteriyle yazışan kişi olarak da tanımlayın. On günlük süreçte üç farklı kişinin müşteriye ayrı ayrı bilgi vermesi, birbirini tutmayan cevaplar doğurur ve güveni zedeler. Tek ağız, tek kayıt: yazışmalar da aynı kaydın ek alanında birikmelidir.
D2: Problemi tanımlamak
D2, raporun kaderini belirleyen adımdır. Tanım "yüzey hatası" değil, ölçülebilir olmalıdır: hangi parça numarası, hangi özellik, hangi sınır dışına çıkmış, kaç adette, hangi tarih aralığında, hangi vardiyada. Sistemde bu alan için ne-nerede-ne zaman-ne kadar yapısını zorunlu tutun; serbest metin bırakıldığında herkes farklı derinlikte yazar.
Bu adımda izlenebilirlik verisi de kayda bağlanır: ilgili parti numaraları, sevkiyat irsaliyeleri, üretim tarihleri. Şüpheli aralığı doğru belirlemek, D3'te kaç parçayı ayıracağınızı belirler. Aralığı dar tutmak müşteride ikinci bir şikâyet, geniş tutmak gereksiz maliyet demektir; bu yüzden veriye dayanmalıdır.
D2'yi yazarken sık düşülen bir tuzak da nedeni tanımın içine karıştırmaktır. "Kalıp aşınması nedeniyle çapak oluşmuş" bir tanım değil, doğrulanmamış bir varsayımdır. Tanımda yalnızca gözlenen durum bulunur; neden D4'te, kanıtıyla birlikte yazılır. Bu ayrımı baştan kurmayan bir 8D raporu, ekip daha ilk toplantıda yanlış hipoteze kilitlendiği için kök nedene hiç ulaşamaz.
D3: Geçici önlem
Geçici önlem (containment), hatanın müşteriye ulaşmasını durdurma adımıdır ve 24 saat içinde bildirilir. Sistemde D3 alanı üç soruyu içermelidir: nerede kaç parça bulundu ve ne yapıldı (müşteri stoğu, yoldaki mal, kendi stoğunuz, hattaki ürün), hangi ilave kontrol devreye alındı, bu kontrolü kim ne zamana kadar yapacak. Her satırın karşısına adet ve tarih yazılmalı.
D3 pahalıdır ve geçicidir. Yüzde yüz gözle kontrol ya da ilave ölçüm istasyonu, kalıcı aksiyon devreye girene kadar sürer. Bu yüzden kayda bir de "kaldırma tarihi" alanı ekleyin. Sahada en çok görülen tuhaflıklardan biri, iki yıl önce açılan bir 8D için konmuş ilave kontrolün hâlâ yapılıyor olmasıdır; kimse kaldırma kararını vermemiştir.
| Adım | Sistemde doldurulan | İstenen kanıt | Süre |
|---|---|---|---|
| D1 Ekip | Üye, rol, birim | Ekip listesi | Aynı gün |
| D2 Problem tanımı | Ne, nerede, ne zaman, ne kadar | Ölçüm ve fotoğraf | Aynı gün |
| D3 Geçici önlem | Stok/yol/müşteri adetleri, ilave kontrol | Ayırma kaydı | 24 saat |
| D4 Kök neden | Oluşma ve kaçma nedeni, yöntem | 5 neden zinciri, veri | 10 gün |
| D5 Kalıcı aksiyon seçimi | Aksiyon, sorumlu, termin | Doğrulama denemesi | 10 gün |
| D6 Uygulama | Devreye alma tarihi, seri no | Ölçüm sonucu, Cpk | 30 gün |
| D7 Tekrarın önlenmesi | FMEA, kontrol planı, talimat revizyonu | Revizyon kayıtları | 30-60 gün |
| D8 Kapanış | Onay, ekip takdiri, kazanılmış ders | Etkinlik kanıtı | 60-90 gün |
Raporların çoğu D3'ü D5 gibi yazdığı için geri döner. "Operatöre eğitim verildi, kontrol sıklığı artırıldı" cümlesi geçici önlemdir; kalıcı aksiyon değildir. Müşteri kalite mühendisi bu ayrımı bilir ve raporu geri gönderir. Kalıcı aksiyon, hatanın oluşmasını ya da fark edilmeden geçmesini fiziksel olarak engelleyen bir değişiklik olmalıdır. Raporunuzda D5 satırında bir eğitim kaydı görüyorsanız, o rapor henüz bitmemiştir.
D4: Kök neden
Kök neden adımında iki ayrı zincir kurulur: hata neden oluştu ve neden yakalanamadı? İkinci zinciri atlayan raporlar, aynı hatanın bir dahaki sefere de kontrolden geçmesine izin verir. Sistemde bu iki zincir için ayrı alanlar açın; her "neden" satırı ayrı girilebilsin ve her satıra kanıt eklenebilsin.
Kanıt burada belirleyicidir. 5 neden zincirinin her halkası ya bir ölçümle, ya bir proses kaydıyla, ya bir denemeyle desteklenmeli. Doğrulanmamış bir zincir, kulağa mantıklı gelen bir tahmindir. Yöntem seçimini de kayda yazın; kök neden analizinde 5 neden, balık kılçığı ve veri analizini birlikte kullanmak çoğu vakada en hızlı sonucu verir.
D5 ve D6: Kalıcı aksiyon ve uygulama
D5'te seçilen kalıcı aksiyon, kök neden zincirinin en üst halkasını ortadan kaldırmalıdır. Birden fazla aday varsa hepsini yazın, seçtiğinizi gerekçesiyle işaretleyin. Müşteri, alternatiflerin değerlendirildiğini görmek ister. Aksiyonun devreye alınmadan önce doğrulanması da bu adımdadır: deneme partisi, ölçüm sonuçları, gerekirse kısa süreli yeterlilik çalışması.
D6 uygulamadır ve tarih ister. Aksiyonun hangi tarihte, hangi seri numarasından itibaren geçerli olduğu kayda yazılır; müşteri bu bilgiyi kendi sisteminde işaretler. Aynı adımda D3'te konan ilave kontrolün kaldırılma kararı verilir. Kalıcı aksiyon devredeyken ilave kontrolü de sürdürmek, ne kadar maliyetliyse o kadar da gereksizdir; ancak kaldırma kararı ölçüm sonuçlarına dayanmalıdır.
Bu iki adımda maliyet takibi de yapın. Ayırma, yeniden işleme, ilave kontrol ve sevkiyat masraflarını kayda yazmak, hem kalitesizlik maliyetini görünür kılar hem de bir sonraki yatırım talebini savunurken elinizde rakam bulundurur. Çoğu ekip bu alanı boş bırakır ve yıl sonunda "bu hata bize ne kadara mal oldu" sorusuna cevap veremez.
Raporun dili ve kanıt düzeni
8D raporu nasıl hazırlanır sorusunun yarısı içerikle, yarısı okunabilirlikle ilgilidir. Bir 8D raporu okuyan müşteri mühendisi, sizin fabrikanızı tanımaz. Bu yüzden iç jargonu ayıklayın: "3 numaralı tezgâh" yerine prosesin adını, "abinin aparatı" yerine aparat kodunu yazın. Cümleler kısa ve edilgen olmayan biçimde kurulmalı; kim ne yaptı belli olmalıdır. İngilizce isteniyorsa çeviriyi son adımda değil, alanları doldururken yapın; sonradan çevrilen raporlarda teknik terimler kayar.
Kanıtları da düzenli ekleyin. Her D adımının altına yalnızca o adımı destekleyen dosyayı koyun; on beş fotoğrafın hepsini D2'ye yığmak, okuyanı yorar ve önemli olanı gizler. Dosya adlarını adım koduyla başlatın: D3_ayirma_kaydi.pdf, D6_olcum_sonuclari.xlsx gibi. Rapor müşteri portalına yüklendiğinde, karşı taraftaki mühendisin aradığı kanıtı ilk bakışta bulması bu küçük düzene bağlıdır.
D7: Tekrarın önlenmesi ve yatay yayılım
Raporun en çok atlanan adımı budur ve denetimde en çok soru alan yer de burasıdır. D7'de üç iş yapılır. Birincisi FMEA güncellemesidir; bu hata modu FMEA'da var mıydı, varsa neden riski düşük değerlendirilmişti? İkincisi kontrol planına yeni kontrolün işlenmesi, üçüncüsü iş talimatının revize edilmesidir.
Yatay yayılım da bu adımda yapılır: aynı hata benzer parçalarda, benzer kalıplarda ya da diğer hatlarda olabilir mi? Kontrol edilen benzer ürünlerin listesi ve sonuçları kayda eklenir. Sistem üzerinde çalışmanın en somut faydası burada görülür; kayıttan doğrudan ilgili FMEA ve kontrol planı revizyonu başlatılabildiğinde, D7 bir cümle olmaktan çıkıp kanıtlanabilir bir zincire dönüşür.
Denetçi bir 8D raporunu okurken üç bağa bakar: D2'deki tanım ile D4'teki kök neden uyumlu mu, D4 ile D5'teki aksiyon birbirini karşılıyor mu, D7'deki revizyonlar gerçekten yapılmış mı? Üçüncüsü en kolay yakalanandır: raporda "kontrol planı güncellendi" yazarken kontrol planının revizyon tarihi 8D'den önceyse bulgu kaçınılmazdır. Kayıtları tek sistemde tutmanın en büyük getirisi, bu tarihlerin kendiliğinden tutarlı olmasıdır.
D8: Kapanış ve müşteri formatı
D8 kapanış adımıdır; etkinlik doğrulandıktan sonra imzalanır. Kapanış için üç kanıt aranır: kalıcı aksiyonun devrede olduğu, belirlenen süre boyunca aynı hatanın tekrar etmediği ve doküman güncellemelerinin tamamlandığı. Ekip takdiri de bu adımın parçasıdır ve süslü bir formalite değildir; bir dahaki sefere o ekibin toplanmasını kolaylaştırır. Kapanışı da müşteri onayına bağlayın; sizin kapattığınız ama müşterinin hâlâ açık gördüğü kayıtlar, bir sonraki denetimde karşınıza çıkar.
Müşteriler genelde kendi 8D formatlarını ister. Sistemde tutulan kayıt, müşteri şablonuna aktarılabilir olmalı; alan adları farklı olsa bile içerik aynı sırayla taşınabilmelidir. Sahada en pratik yol, kaydın PDF çıktısını alıp müşterinin portalına yüklemektir. PaKalite'de 8D kaydı DÖF akışıyla aynı yapıda tutulduğu için D1-D8 alanları tek ekrandan doldurulup çıktı olarak alınabiliyor; ayrı bir Word şablonuna kopyalama ihtiyacı ortadan kalkıyor.
Baştan beri anlatılan şeyi tek cümleye indirelim: 8D raporu nasıl hazırlanır sorusunun cevabı formu doldurmak değil, zinciri kurmaktır. Tanım, kök neden, aksiyon ve doküman revizyonu birbirini tutmuyorsa rapor sekiz adımdan oluşsa da işini yapmaz. Yöntemin genel çerçevesini 8D metodolojisi sayfasında bulabilirsiniz; buradaki adımlar ise onu sistemde nasıl yaşatacağınızla ilgili.
Bir de kapanmış raporları ayda bir birlikte okuyun. Aynı hattan üç ay içinde çıkan iki 8D varsa, ikisinin kök nedeni büyük ihtimalle aynı yere bakıyordur ve o yer henüz düzeltilmemiştir. 8D raporu nasıl hazırlanır sorusunun sahadaki karşılığı da tam olarak budur: tek tek raporları değil, raporların birbirine ne söylediğini görebilmek. Kayıtlar tek sistemde durduğunda bu okuma yarım saat sürer; klasörlere dağılmışsa hiç yapılmaz.