Müşteri portalı şikâyeti perşembe 16:40'ta açtı. O dakikada sayaç işlemeye başladı ve D3 için geriye yirmi dört saat kaldı. Kalite mühendisi hâlâ sahada, iki paletin arasında parça arıyordu; kimse portalı açmamıştı. Cuma sabahı portal kaydın yanına "gecikmiş" işareti koydu. Parça sorunu birkaç gün içinde çözüldü ama o işaret çeyrek sonuna kadar orada durdu. 8D raporu süresi genelde teknik zorluktan değil, saatin ne zaman başladığının bilinmemesinden kayar.
Sayaç sizin haberiniz olmadan başlar
Bu işin ilk kuralı şu: süre, şikâyetin size ulaştığı an değil, müşterinin kaydı açtığı an başlar. Portal kaydı cuma akşamı açıldıysa hafta sonu size ek süre vermez. Kalite mühendisi kaydı pazartesi sabah gördüğünde iki günü çoktan harcamış olur. Bu yüzden portal kayıtlarının kim tarafından, hangi sıklıkta kontrol edileceği yazılı olmalıdır.
Pratik çözüm basit ve ucuz: portal bildirimlerini tek bir kalite posta kutusuna yönlendirin, o kutuyu iki kişi izlesin ve gelen her kayıt aynı gün sisteme açılsın. Sisteme açılırken müşterinin kayıt tarihi girilsin, sizin gördüğünüz tarih değil. Aradaki farkı da ayrı bir alan olarak tutun; o fark size portal takibinin ne kadar geciktiğini söyler. Bu farkı ilk kez ölçen ekipler genelde sonucu görünce şaşırıyor; portalın kaç gün beklediğini o güne kadar kimse saymamış oluyor.
İkinci bir kural daha var: sayaç tatilde durmaz. Türkiye'de bayram tatilleri ve yıllık izin dönemleri 8D gecikmelerinin yoğunlaştığı haftalardır. Tatil öncesinde açık kayıtları gözden geçirip vekil atamak on dakikalık iştir; yapılmadığında dokuz günlük bir tatil, üç ayrı kayıtta gecikme üretir. Bunu bir kez yaşayan ekipler tatil öncesi kontrolü rutin hâline getiriyor.
8D adımları ve gerçekçi süreler
Otomotivde yaygın olarak kullanılan süreler aşağıdaki gibidir. Buradaki rakamları bağlayıcı kabul etmeyin; bağlayıcı olan sizin sözleşmenizde ve müşteri özel şartlarınızda yazan sürelerdir. Yine de bir düzen kurarken başlangıç noktası olarak işe yarıyor.
| Adım | İçerik | Yaygın süre | Sorumlu |
|---|---|---|---|
| D1 | Ekibin kurulması | 24 saat | Kalite mühendisi |
| D2 | Problemin tanımlanması | 24 saat | Kalite mühendisi |
| D3 | Geçici koruma önlemleri | 24 saat | Kalite + üretim |
| D4 | Kök nedenin belirlenmesi | 10 iş günü | Proses mühendisi |
| D5 | Kalıcı önlemin seçilmesi | 10 iş günü | Çok fonksiyonlu ekip |
| D6 | Önlemin devreye alınması | 2 – 4 hafta | Üretim / bakım |
| D7 | Tekrarın önlenmesi | Önlem sonrası 30 gün | Kalite yöneticisi |
| D8 | Ekibin kapanışı | Etkinlik sonrası | Kalite yöneticisi |
Tablodaki asıl mesaj süreler değil, sürelerin farklı olması. Tek bir "8D termini" koymak en yaygın hata. Müşteri D3'ü yarın, D5'i on gün sonra bekliyorsa, sistemde tek bir kapanış tarihi tutmak hiçbir işe yaramaz. Adımların her biri ayrı termin taşımalı.
D3 neden bu kadar zorlanıyor
Gecikmelerin büyük bölümü D3'te yaşanıyor ve sebebi hep aynı: ekip ilk gün kök neden tartışmasına giriyor. Oysa D3 kök neden bilmeyi gerektirmez, yayılmayı durdurmayı gerektirir. İlk yirmi dört saatte yapılacak üç iş var: müşteri sahasında, yolda ve kendi ambarınızda ne kadar şüpheli ürün olduğunu tespit etmek, bunları bloke etmek ve gerekiyorsa yüzde yüz ayıklamayı başlatmak.
Bu üç iş için hazır bir kontrol listesi bulundurun. Üzerinde şu kalemler olsun: müşteri stoğu (adet, tarih), yoldaki sevkiyat (irsaliye numaraları), mamul ambarı, yarı mamul, hattaki parça ve tedarikçideki bakiye. Miktarları yazın; "kontrol edildi" yazmayın. Karantinaya alınan miktarların kayıt tarafını bloke stok yazımızda ayrıntılı anlattık. Bu liste doldurulduğunda D3 metni kendiliğinden yazılmış olur.
D3 metnini müşteriye gönderirken iki cümleyi mutlaka koyun: bloke edilen toplam miktar ve ayıklamanın başladığı saat. Müşteri kalite mühendisi asıl bunları arıyor. "Konu incelenmektedir" cümlesi ise gecikme sayılmasa bile güven kaybettiriyor ve bir sonraki şikâyette daha sıkı takip getiriyor. Ben D3 metnini elli kelimeyi geçmeyecek şekilde yazmayı tercih ediyorum; uzun metin, eksik bilgiyi gizlemeye çalışıyor gibi duruyor.
D3'te sık yapılan bir hata da geçici önlemin doğrulanmamasıdır. Ayıklama başlatıldı, peki ayıklamanın kendisi ne kadar güvenilir? Yüzde yüz görsel kontrolün yakalama oranı hiçbir zaman yüzde yüz değildir. Kritik bir karakteristikte ayıklamaya güveniyorsanız, ayıklanan parçalardan örnek alıp ikinci bir kontrol yapın ve bunu D3 metnine yazın. Müşteri kalite mühendisi bu cümleyi gördüğünde ayıklamaya güveniyor; görmediğinde kendi sahasında ikinci bir kontrol istiyor ve maliyet size dönüyor.
Termini kim koyar, kim izler
Termin koymak kalitenin işi, terminde durmak sürecin işi. Bu ayrım netleşmezse 8D kalite mühendisinin kişisel takvimine sıkışır. Her adım için bir sorumlu ve bir tarih atayın; sorumlu bölüm değil kişi olsun. "Üretim" sorumlu yazıldığında kimse sahiplenmiyor, "vardiya amiri Ahmet" yazıldığında sahipleniyor.
Gecikme durumunda ne olacağını da önceden yazın. İki iş günü gecikme kalite yöneticisine, beş iş günü gecikme fabrika müdürüne düşsün. Bu eskalasyon kuralı sistemde otomatik çalışmalı; elle yapılan eskalasyon ilk yoğun haftada unutuluyor. Kuralı yazmak yarım saat, kurmak bir saat sürer ve 8D raporu süresi üzerindeki etkisi hemen görülür.
Terminleri koyarken iş günü mü takvim günü mü kullandığınızı da netleştirin. Müşteri portalı takvim günü sayıyorsa siz iş günü hesaplamayın; iki gün fark, hafta sonuna denk gelen her kayıtta gecikme üretir. Bu ayrıntıyı bir kere yazın ve prosedürünüzde saklayın.
Hatırlatmayı doğru zamanlamak
Hatırlatma sistemleri yanlış kurulduğunda gürültü üretir ve kimse okumaz. Kural şu: hatırlatma termin dolduktan sonra değil, terminden önce gelmeli. Aşağıdaki düzen çoğu firmada işe yarıyor.
| Adım | İlk hatırlatma | İkinci hatırlatma | Eskalasyon |
|---|---|---|---|
| D3 (24 saat) | Kayıt açıldıktan 4 saat sonra | Kalan 6 saat | Termin dolunca |
| D4 – D5 (10 gün) | 3. gün | 7. gün | 11. gün |
| D6 (2 – 4 hafta) | Kalan 7 gün | Kalan 2 gün | Termin + 2 gün |
| D7 (30 gün izleme) | Kalan 5 gün | — | Termin + 5 gün |
Hatırlatma sadece sorumluya gitsin, listeye değil. Yirmi kişilik dağıtım listesine giden uyarı hiç kimseye gitmemiş sayılır. Bunu bir kez yanlış kuran firmada üç ay sonra herkes uyarıları posta kutusunda ayrı bir klasöre yönlendirmişti.
Ekip kurarken de dikkat edin. D1 sadece isim listesi değildir; ekipte proses bilgisi olan, ölçüm yapabilen ve karar verebilen kişiler bulunmalıdır. Beş kişilik bir 8D ekibinde üretimden bir vardiya amiri yoksa D6 aşamasında alınan önlem sahada uygulanmıyor. Bunu defalarca gördüm: rapor kapanmış, hatta müşteri kabul etmiş, ama tezgâh başında hiçbir şey değişmemiş.
Gecikmenin karneye yansıması
Müşteri portallarının çoğu cevap süresini ayrı bir kalem olarak ölçüyor. Bu kalem ürün kalitesinden bağımsız çalışır: parça sorunsuz çıksa bile geç cevap puan düşürür. Bir çeyrekte iki üç geç cevap, tedarikçi statüsünü yeşilden sarıya çevirmeye yetebiliyor. Statü değişiminin ne anlama geldiğini ve nasıl toparlandığını scorecard yazımızda ele aldık.
Burada acı olan şu: geciken 8D'lerin çoğunda teknik çözüm zamanında bulunmuş oluyor. Kaybedilen puan çözümsüzlükten değil, çözümün zamanında yazılmamasından geliyor. Bu tamamen idari bir kayıp ve düzeltilmesi de idari.
Bir de şu tuzağa düşmeyin: gecikmeyi engellemek için raporu içi boş göndermek. Erken gönderilmiş ama zayıf bir D5, müşteriden geri döndüğünde saati sıfırlamıyor, aksine güveni aşındırıyor. Zamanında ve eksik yerine, zamanında ve dürüst gönderin; bilinmeyen bir şey varsa ne zaman bileceğinizi yazın.
8D'yi hızlandıran alışkanlıklar
Formu ekip toplantısında birlikte doldurun, sonradan tek kişiye yazdırmayın. Kök nedeni "operatör dikkatsizliği" diye kapatmayın; bu cümle müşteri tarafından neredeyse her zaman reddediliyor ve rapor size geri döndüğünde saat yeniden işliyor. Kök neden analizi için beş neden ya da balık kılçığı kullanın ve kaçış noktasını ayrıca sorun: bu hata neden bizim kontrolümüzden geçti? İki soruya iki ayrı cevap vermeyen 8D'ler geri dönüyor.
Bir de şu var: 8D ile düzeltici faaliyeti ayrı sistemde tutmayın. D6'da alınan kalıcı önlem genelde bir DÖF olarak yürüyor; ikisi ayrı yerdeyse D7 aşamasında etkinlik doğrulaması yapılamıyor. Adımların içeriğini ve formun kendisini 8D sayfamızda ayrıntılı anlattık.
IATF 16949'un 10.2.3 maddesi problem çözme için tanımlı bir süreç ister; süreç, problemin tipine göre yaklaşımı, geçici önlemi, kök neden analizini ve alınan önlemin etkinliğinin doğrulanmasını kapsamalıdır. Müşteri belirli bir problem çözme yöntemi şart koşuyorsa onun kullanılması beklenir. Denetçi burada iki şeye bakar: sürecinizde süreler yazılı mı, ve seçtiği örnek kayıt o sürelere uymuş mu. Gecikme varsa bu tek başına bulgu olmayabilir; bulgu, gecikmeyi fark eden ve yöneten bir mekanizmanın bulunmamasından çıkar. Gecikme oranınızı ölçüyor ve gözden geçiriyorsanız konuşma çok daha rahat ilerliyor.
Formun dilini de baştan kararlaştırın. Müşteri İngilizce istiyorsa raporu Türkçe yazıp son gün çevirmeye kalkmayın; çeviri hem bir gün yer hem de teknik terimleri bozar. Şablonu iki dilli kurun, alan adları sabit kalsın, ekip kendi dilinde doldursun. Bu düzenlemenin tek başına iki güne yakın kazandırdığı bir tesis biliyorum.
QMS'te 8D modülünden beklenecekler
Yılda beş on 8D açan bir firmada Excel listesi gerçekten yeter; bunu açıkça söylemekte fayda var. Ayda beşin üzerine çıkıldığında ise iş elle yürümüyor, çünkü tek bir 8D içinde izlenecek yedi ayrı tarih var. Kırk açık kayıt, iki yüz seksenden fazla tarih demek.
Bu ölçekte bir yazılımdan beklenecekler nettir: adım bazlı termin, otomatik hatırlatma, kural bazlı eskalasyon, müşteri kayıt tarihiyle sistem tarihinin ayrı tutulması ve raporun müşteri formatında dışa aktarılması. PaKalite'de 8D kayıtları karantina, DÖF ve müşteri şikâyeti kayıtlarıyla aynı veritabanında durur; D3'te bloke edilen miktar, D6'da açılan DÖF ve D7'deki etkinlik doğrulaması tek zincirde görünür. Buradaki asıl kazanç ekran değil, 8D raporu süresi üzerindeki kontroldür.
Ölçmeden bitirmeyin: gecikme oranınızı aylık takip edin ve yönetim gözden geçirmesine koyun. Ölçüm şu şekilde olsun: zamanında gönderilen D3 sayısı bölü toplam D3 sayısı. Tek bir sayı, ama tartışmayı bitiriyor. Bu oran altı ay üst üste yükseliyorsa 8D raporu süresi artık sizin kontrolünüzdedir; düşüyorsa sorun kaynak planlamasındadır, yazılımda değil.