Tek bir hatayı tanımlamak için iki yıl: Toyota'nın geri çağırması problem tanımı hakkında ne öğretiyor
Toyota bir yazılım hatasını tanımlamak için iki yıl harcadı, düzeltme haftalar sürdü. 8D problem çözmede doğru problem tanımı için dersler.
Ağustos 2026’da Toyota, ABD’de 508.354 Camry Hybrid’i geri çağırdı. Hata iki yıl önce bildirilmişti.
ABD düzenleyici kurumuna sunulan geri çağırma dosyası, hikâyenin tamamını adım adım anlatıyor. Acele etmeden okuyun.
Temmuz 2024: sahadan ilk bildirimler. Gösterge paneli çalıştırma sırasında boş kalıyor. Saha testlerinde hata yeniden oluşturulamıyor.
Ekim 2025: şüphe yazılıma yöneliyor. Toyota ve tedarikçisi bu iş için özel teşhis ekipmanı kuruyor.
2025 sonu: test tezgâhında ilk kez yeniden oluşturuluyor. Nisan 2026: açma-kapama döngüsü testleri hatayı tetikleyemiyor. Temmuz 2026: tam araç testi sonunda arızayı ortaya çıkarıyor.
Hatayı istedikleri anda yeniden oluşturabilmeleri iki yıl sürdü. Düzeltme ise haftalar aldı - gösterge paneli yazılımına bir güncelleme.
Bunu nereden biliyoruz
Bu hikâyeyi yalnızca ABD yasaları zorunlu kıldığı için biliyoruz. 49 CFR 573.6’ya göre üretici, her geri çağırmayla birlikte incelemesinin yazılı bir kronolojisini sunmak zorundadır.
AB’de bunun karşılığı olan bir belge yok. Safety Gate uyarıyı ve riski yayımlar, nedene giden yolu değil. Bu yıl 278 motorlu taşıt uyarısı listeleniyor, bunların 8’i yazılımdan söz ediyor; ama hiçbirinde inceleme kronolojisi yok.
Her şey için bir formun olduğu Avrupa’dan gelen biri olarak bunu hâlâ şaşırtıcı buluyorum.
Bir kalite mühendisi için bu yazılı kronoloji bir armağandır. İki yılın gerçekte nereye gittiğini gösterir.
İki yıl boyunca analiz yapmadılar
İşin rahatsız edici kısmı şu. O iki yılın büyük bölümünde kimse kök nedeni analiz etmiyordu. Daha temel bir soruya cevap arıyorlardı: hata nerede ortaya çıkıyor, nerede hiç çıkmıyor?
Şimdi kendi işimden tanıdığım bir örüntüye bakın.
8D’de problem tanımı D2 adımıdır. Çoğu zaman üç satırla geçiştirilir. O zaman kök neden analizinin tutunacağı bir şey kalmaz. Her toplantı yeni bir teori üretir ve hiçbiri doğrulanmaz.
Bu analiz değildir. Ayakta durmayan bir tanımın üzerine kurulmuş bir tahmindir.
İyi tanımlanmış bir problem
Charles Kettering, General Motors’ta 27 yıl boyunca araştırmayı yönetti. Şu söz ona atfedilir: “İyi tanımlanmış bir problem, yarı yarıya çözülmüş bir problemdir.” Kepner ve Tregoe bunu bir yönteme dönüştürdü: problemin her boyutu için nerede OLDUĞUNU ve nerede OLMADIĞINI kaydedin.
Eksiksiz bir tanım, sonuna kadar doldurulmuş bir 5W2H’dir - her satırda iki cevap vardır:
Ne yanlış - tek cümle, açıklama yok, suçlu yok. Nerede ortaya çıkıyor ve nerede hiç çıkmıyor - hangi makinede evet, hangisinde hayır; hangi vardiyada evet, hangisinde hayır. Ne zaman başladı - ve o sırada ne değişti. Kim etkileniyor - ve kim etkilenmiyor. Neden oluyor gibi görünüyor - gerçeklerden açıkça ayrılmış bir şüphe olarak. Nasıl kendini gösteriyor - ve nasıl göstermiyor. Ne kadar - parça, yüzde, şikâyet.
İki sütun arasındaki fark, kök nedenin bulunabileceği tek yerdir.
Tanımın bittiğini size tek bir dürüst test söyler: hatayı istediğiniz anda yeniden oluşturabiliyorsunuz. Toyota bu testi geçtikten sonra düzeltme haftalar sürdü. Testi geçmek ise iki yıl sürdü.
Benim yedi yılım
Üretimde kalite alanında on yıldan fazla çalıştım. Bir problem bu yılların yedisinde peşimi bırakmadı. Onu hiç sonuna kadar tanımlamadan çözmeye devam ettik.
Sonunda oturup tanımın tamamını yazdığımızda başka bir şey ortaya çıktı. Karşımızdaki tek bir problem değildi. Birbiriyle örtüşen ve her birinin kendi nedeni olan birkaç problemdi.
Sonraki üç ayda nedenleri bulduk ve her biri için ayrı ayrı faaliyetler tanımladık.
Derslerimden biri: bir problemi sonuna kadar tanımlayamıyorsanız, büyük ihtimalle aynı anda birkaç problemi çözmeye çalışıyorsunuz.
Her problem bir 8D’yi hak etmez
Bir çekince. Yukarıdaki her şey 8D için geçerli, yani müşteri şikâyetleri ve zor problemler için kullanılan yöntem için. İç hurdayı ya da küçük bir sapmayı tam bir 8D’den geçirmek, bir haftalık mühendislik zamanını boşa harcar. Daha hafif yöntemler bunun için var: iç sapmalar için 4-Step, sürekli iyileştirme için PDCA, basit işler için Just-Do-It. SolveR’da 8D, 4-Step, PDCA aynı bilgi bankası üzerinde çalışır; bu yüzden daha hafif yöntemi seçmek hiçbir zaman kaydı kaybetmek anlamına gelmez.
Doğru yöntem yolu kısaltır. Yanlış yöntem uzatır.
Bundan sonrası
Her problemin etrafındaki veri miktarının kat kat artacağına inanıyorum. Yapay zekâ ajanları bu veriyi bugün insanların topladığı gibi toplayacak: her adım yazıya geçirilmiş, kurallar açık. Gürültü sinyalden daha hızlı artacak.
O zaman asıl iş ayıklamak olacak: neyin probleme ait olduğu, neyin gürültü olduğu, hangi yorumun yanlış olduğu, hangi verinin daha büyük bir örneklemde yeniden toplanması gerektiği. Son adım her zaman insanın olacak.
Kök nedeni en hızlı analiz eden bulmaz. Hatayı istediği anda yeniden oluşturabilen bulur.
galileon.si’de daha fazlası
Kaynaklar
- NHTSA, Part 573 Safety Recall Report 26V511, 2026-08-06. 508.354 adet, inceleme kronolojisi, yazılımla çözüm.
- 49 CFR § 573.6 - ABD’nin yazılı inceleme kronolojisi şartı.
- EU Safety Gate, motor-vehicle alerts - kontrol tarihi 2026-08-17. 2026’da 278 uyarı, 8’i yazılımdan söz ediyor, yayımlanmış kronoloji yok.
- Charles F. Kettering’e atfedilir - “A problem well stated is a problem half solved”.
- Kepner, Tregoe, The Rational Manager, 1965 - Olan / Olmayan problem tanımlaması.