Aynı müşteriden aynı hata için üçüncü 8D talebi geldiğinde kalite müdürü klasörü açtı: önceki iki dosyanın D4 kök neden kutusunda "operatör dikkatsizliği", D5 kutusunda "operatör eğitildi, tutanak ektedir" yazıyordu. İki dosya da zamanında gönderilmiş, ikisi de kapatılmış, hata ise hiç durmamıştı. Bu tablo bir disiplin sorunu değil, izlenebilirlik sorunudur — kimse geçmiş kaydın ne dediğini görmeden yeni kaydı açmaktadır. Bir kalite yönetim sistemi yazılımı, DÖF ve 8D süreçlerini tam olarak bu noktada işe yarar hale getirir: kaydı hızlandırmakla değil, kök nedene inmeden kapanmasını engelleyerek.
DÖF ve 8D bir kalite yönetim sistemi yazılımında neden aynı çatı altında olmalı?
Sahada DÖF ve 8D çoğu zaman iki ayrı dünya gibi yürütülür. Müşteri şikâyeti gelince Excel'de bir 8D şablonu doldurulur, iç uygunsuzluk çıkınca kâğıt DÖF formu açılır, denetim bulgusu için üçüncü bir liste tutulur. Üçünün de sorduğu soru aynıdır: ne oldu, neden oldu, ne yaptık, tekrar eder mi? Ayrı yürüdüklerinde ise şirket kendi problem geçmişini göremez.
Doğru kurgu, tek bir uygunsuzluk kaydı ve o kaydın kaynağına göre değişen derinliktir. Küçük bir iç uygunsuzluk hızlı DÖF akışıyla ilerler; müşteri kaynaklı ya da güvenlik etkili bir problem otomatik olarak sekiz disiplinli akışa yükselir. Böylece DÖF ve 8D aynı veriyi besler, aynı raporda görünür.
IATF 16949 madde 10.2 ne istiyor?
Standardın düzeltici faaliyet tarafı ISO 9001'de madde 10.2.1 ve 10.2.2 ile tanımlanır: uygunsuzluğa tepki verilecek, kontrol altına alınacak, sonuçlarıyla ilgilenilecek, tekrarını önlemek için neden araştırılacak ve alınan faaliyetin etkinliği gözden geçirilecek. IATF 16949 bunun üzerine otomotiv sektörüne özel dört madde ekler:
- Madde 10.2.3 — Problem çözme: Dokümante edilmiş bir problem çözme prosesi şart. Bu proses problem tipine göre yaklaşımı, kapsamı, kök neden analizini ve sistemik etkilerin değerlendirilmesini içermeli.
- Madde 10.2.4 — Hata önleme: Poka-yoke uygulamalarını belirleme prosesiniz olmalı; hata önleme cihazlarının doğrulama sıklığı ve arıza durumundaki yedek plan tanımlı olmalı.
- Madde 10.2.5 — Garanti yönetimi: Garanti kapsamındaki ürünler için parça analizi dâhil bir proses gerekir.
- Madde 10.2.6 — Müşteri şikâyetleri ve saha hataları: Şikâyetler analiz edilmeli, saha hatası testi yapılmalı ve sonuçlar FMEA ile kontrol planına yansıtılmalı.
Bu maddelerin denetimdeki karşılığını IATF 16949 madde 10.2 düzeltici faaliyet yazımızda ayrıntılandırdık.
8D adımları yazılımda nasıl karşılık buluyor?
Sekiz disiplinin her biri kâğıt üzerinde bir kutu, yazılımda ise bir kapıdır. Kapı geçilmeden sonraki adım açılmaz:
| Adım | İçerik | Yazılımın uyguladığı kural |
|---|---|---|
| D1–D2 | Ekip kurulumu ve problem tanımı | Ekip üyesi ve 5N1K alanları boşsa kayıt ilerlemez |
| D3 | Geçici koruma faaliyeti | 24 saatlik süre sayacı; stok, sevkiyat ve saha kapsamı zorunlu |
| D4 | Kök neden analizi | 5 neden veya balık kılçığı eki olmadan onaya gönderilemez |
| D5–D6 | Kalıcı aksiyon ve uygulama | Her aksiyona sorumlu ve termin; gecikmede otomatik uyarı |
| D7 | Tekrarı önleme | FMEA, kontrol planı ve talimat revizyonu bağlantısı istenir |
| D8 | Kapanış ve ekip takdiri | Etkinlik doğrulama tarihi gelmeden kapanış yapılamaz |
D4 ve D7 en çok atlanan adımlardır. D4'te "dikkatsizlik" yazılıp geçilir; D7'de ise hiçbir dokümana dokunulmaz. Yazılımın buradaki işlevi hatırlatmak değil, engellemektir. Kök neden analizinin yöntemleri için 5 neden analizi ve balık kılçığı diyagramı sayfalarımıza bakabilirsiniz.
Kök neden kutusuna "operatör hatası" yazan her 8D'yi geri çevirin. Operatör hata yaptıysa asıl soru şudur: hata yapmasına izin veren ne? Talimat belirsiz miydi, iki parça birbirine çok mu benziyordu, tezgâh yanlış parçayı kabul mü etti? Kalıcı aksiyonu insana yükleyen 8D'lerde tekrar oranı belirgin biçimde yüksektir; aynı hata genellikle iki ay içinde geri gelir. Madde 10.2.4 hata önleme şartı da tam olarak bunu söyler: çözümü operatörün dikkatine değil, sisteme kurun.
Aksiyonlar nasıl takip edilir, gecikmeler nasıl görünür olur?
DÖF sisteminin gerçek yükü kaydı açmak değil, açılan aksiyonu bitirmektir. Kâğıt düzende bu iş kalite biriminin haftalık telefon turuna kalır. Kalite yönetim sistemi yazılımında ise her aksiyon bir görevdir: sorumlusu, termini, durumu ve kanıt eki vardır. Sorumlunun ekranında kendi açık aksiyonları, yöneticinin ekranında departman bazında geciken aksiyon sayısı görünür.
Ölçmeye değer üç gösterge şunlardır: ortalama kapanış süresi, termini geçen aksiyon oranı ve tekrar eden problem oranı. Üçüncüsü en önemlisidir çünkü ilk ikisi iyileşirken üçüncüsü iyileşmiyorsa sistem hızlı kapatıyor ama çözmüyor demektir. Bu göstergelerin yönetim tarafındaki kullanımını DÖF yönetim yazılımı sayfasında ele aldık.
Denetçi DÖF listesinin uzunluğuna bakmaz; kapanmış bir kaydı seçip geriye doğru yürür. Kök neden ne yazmış, kalıcı aksiyon o kök nedeni gerçekten kesiyor mu, aksiyon sonucunda FMEA ve kontrol planı revize edilmiş mi, etkinlik hangi veriyle doğrulanmış? Ardından madde 10.2.3'ün istediği "sistemik etki" değerlendirmesini sorar: aynı hata benzer proseslerde ya da benzer ürünlerde de mümkün mü, oralara da bakıldı mı? Bu soruya "sadece o hattı düzelttik" cevabı verilen firmalarda bulgu neredeyse kesindir.
Etkinlik doğrulaması nasıl kurgulanır?
Madde 10.2.1 alınan faaliyetin etkinliğinin gözden geçirilmesini ister. Sahadaki yaygın hata, aksiyonun uygulandığı gün "etkin" işaretlenmesidir. Doğru kurgu, aksiyon tipine göre bir doğrulama penceresi tanımlamaktır: proses parametresi değişikliği için 30 gün, kalıp revizyonu için 60 gün, tedarikçi kaynaklı bir düzeltme için üç sevkiyat. Yazılım o tarih geldiğinde sorumluya görev düşürür ve veriyi ister — hurda oranı, şikâyet sayısı, ölçüm sonucu.
Doğrulama verisini üretmenin en sağlam yolu, aksiyon öncesi ve sonrası aynı göstergeyi karşılaştırmaktır. Bir proses değişikliğinin gerçekten işe yarayıp yaramadığını Cp ve Cpk değerlerindeki hareketle görebilirsiniz; müşteri tarafındaki etkiyi ise şikâyet ve PPM eğrisi gösterir.
Tekrar eden problemleri yazılım nasıl ortaya çıkarır?
Bir kalite yönetim sistemi yazılımının en az konuşulan ama en değerli özelliği etiketlemedir. Her kayıt ürün ailesi, proses adımı, hata kodu, müşteri ve tedarikçi alanlarıyla etiketlendiğinde şu sorular birkaç saniyede cevaplanır: son on iki ayda en çok hangi hata kodu tekrar etti, hangi hattan kaç DÖF çıktı, hangi tedarikçi kaç şikâyete sebep oldu? Yeni kayıt açılırken sistem benzer geçmiş kayıtları önerir; ekip "bunu daha önce çözmüştük" diyebilir hale gelir.
Bu birikim, Pareto mantığıyla birleştiğinde iyileştirme bütçesini nereye harcayacağınızı söyler. Yılda 180 DÖF açan bir firmanın hepsine eşit emek harcaması mümkün değildir; ilk beş hata kodu genellikle toplam maliyetin yarısından fazlasını taşır. Pareto analizi bu önceliklendirmenin en pratik aracıdır.
DÖF modülü diğer modüllerle nasıl konuşmalı?
DÖF, bir kalite yönetim sistemi yazılımı içinde en çok bağlantısı olan modüldür. Giriş kalite kontrolde tespit edilen bir uygunsuzluk tedarikçi puanını düşürür; üretimde çıkan bir sapma kontrol planı revizyonunu tetikler; kapanan bir 8D FMEA'daki oluşma derecesini değiştirir; iç tetkik bulgusu doğrudan DÖF olarak açılır. Bu bağlantılar elle kurulduğunda ilk aylarda çalışır, sonra unutulur. Sistem içinde kurulduğunda ise kalite kaydı bir arşiv olmaktan çıkıp gerçekten karar veren bir mekanizmaya dönüşür.