Ay sonu garanti raporunu açtığınızda genellikle iki şey görürsünüz: bir maliyet rakamı ve o rakamı açıklamaya çalışan birkaç satır yorum. Çoğu firmada garanti yönetimi burada biter; para ödenir, dosya kapanır, aynı parça bir sonraki çeyrekte yine döner. Oysa IATF 16949'un garanti yönetimi maddesi (10.2.5) tam da bu kısır döngüyü kırmak için var. Standart garantiyi bir muhasebe kalemi değil, sahadan gelen en dürüst geri bildirim kaynağı olarak görür. Bu yazıda garanti iadelerini gerçekten öğrenmeye çeviren bir yaklaşımı, bir garanti iadesi analiz toplantısının içinden anlatıyoruz.
IATF 16949 garanti yönetimi maddesi ne ister?
Madde 10.2.5, uygulanabilir olduğu durumda bir garanti yönetimi prosesi kurulmasını ister. Bu prosesin iki temel bileşeni vardır. Birincisi, garanti kapsamında dönen parçaların analizi için tanımlı bir yöntem; ikincisi, müşteriyle mutabık kalınan bir garanti parça analizi yaklaşımının uygulanması. Otomotivde bu yaklaşım çoğu zaman sektörün NTF (No Trouble Found) kılavuzuna dayanır.
Buradaki incelik "analiz" kelimesinde saklı. Standart size parçayı geri alıp raf ömrü dolana kadar depolamayı değil, her iadeden bir sonuç çıkarmayı söyler: parça neden döndü, gerçekten arızalı mıydı, arızanın kök nedeni ne, bu bulgu tasarıma ya da prosese nasıl yansıyacak? Analizsiz toplanan garanti verisi sadece bir gider tablosudur.
Sahadan dönen parça analizi nasıl yapılır?
İyi bir garanti analiz akışı, parça kapıdan girdiği anda başlar. Önce iade doğrulanır: gerçekten sizin parçanız mı, garanti süresi içinde mi, montaj kaynaklı bir hasar mı var? Ardından parça, sahadaki şikâyeti temsil eden koşullarda test edilir. Burada kritik olan, testin müşterinin yaşadığı senaryoyu yeniden üretebilmesidir; masa başında "çalışıyor görünüyor" demek analiz değildir.
| Analiz aşaması | Sorulan soru | Çıktı |
|---|---|---|
| Doğrulama | Bu gerçekten bizim garanti parçamız mı? | Geçerli / geçersiz iade ayrımı |
| Hata teyidi | Şikâyet yeniden üretilebiliyor mu? | Onaylı hata veya NTF |
| Kök neden | Neden oldu, nerede kaçtı? | Tasarım / proses / kullanım nedeni |
| Geri besleme | Bu ders nereye yansımalı? | FMEA, kontrol planı, 8D girdisi |
Bu akışın son satırı en çok atlanan yerdir. Kök nedene ulaşıp o bulguyu PFMEA ve kontrol planına geri beslemezseniz, garanti analizi bir rapor üretir ama hiçbir şeyi değiştirmez.
Bir garanti iadesini test ettiğinizde parça "sağlam" çıkabilir. Bunu hemen NTF diye kapatmak en kolay ama en pahalı hatadır. Parça sizin tezgâhınızda değil, aracın titreşimi, sıcaklığı ve kablo demetiyle birlikte arıza veriyor olabilir. Test koşulunu sahaya benzetemiyorsanız, "hata bulunamadı" demeyin; "henüz üretemedik" deyin.
NTF oranı neden bu kadar önemli?
NTF, garantiyle dönen bir parçada testte hata bulunamaması durumudur. Düşük bir miktar NTF hayatın gerçeğidir; ancak oran yükseldiğinde bu bir uyarıdır. Yüksek NTF genellikle parçanın değil, teşhis mantığının sorunlu olduğunu söyler: servis, gerçek arızalı bileşen yerine yanlış parçayı değiştiriyordur ya da sorun iki parçanın etkileşiminden doğuyordur. Her iki durumda da fatura size gelir ama gerçek problem çözülmeden kalır.
Bu yüzden NTF'yi bir kapatma etiketi değil, bir araştırma tetikleyicisi olarak kullanmak gerekir. NTF oranı belirli bir parçada tırmanıyorsa, bu artık kalite değil teşhis ve tasarım konusudur; müşteriyle ortak bir çalışma başlatmanın zamanı gelmiştir. Otomotiv müşterileri NTF için genellikle ortak bir kılavuz ve raporlama formatı ister; bu formatı takip etmek 10.2.5 uyumunun da doğal parçasıdır.
Garanti verisini kök neden çalışmasına bağlamak
Tek bir garanti iadesi bir olaydır; tekrar eden bir örüntü ise bir sinyaldir. Garanti verisini parça numarası, hata modu, üretim tarihi ve saha kilometresine göre grupladığınızda, gözle görülmeyen kümeler ortaya çıkar. Aynı hata modu belirli bir üretim penceresinde yoğunlaşıyorsa, orada bir proses sapması ya da tedarikçi partisi vardır.
Bu örüntü belirdiğinde iş resmi bir problem çözmeye, tipik olarak bir 8D'ye taşınır. Garanti burada erken uyarı sistemi gibi çalışır: sahadaki sinyali, henüz büyük bir geri çağırmaya dönüşmeden kök neden masasına taşır. Aynı zamanda bu veri saha başarısızlığı analizi ile iç içedir; ikisi birlikte sahadan gelen bilginin tam resmini verir.
Denetçi garanti dosyanıza baktığında maliyet rakamıyla ilgilenmez; izle mekanizmasını arar. Şunu sorar: son çeyrekteki en yüksek garanti hatası hangisiydi, bunun için bir kök neden çalışması açıldı mı, çıkan aksiyon FMEA ve kontrol planına yansıdı mı? Rakamı raporlayan ama hiçbir aksiyon üretmeyen bir garanti süreci, 10.2.5 için yeterli sayılmaz.
Garanti maliyetinden garanti öğrenmesine geçmek
Garanti yönetimini olgunlaştıran firmalarda gözle görülür bir değişim olur: garanti toplantıları "ne kadar ödedik" sorusundan "neyi öğrendik ve neyi değiştirdik" sorusuna kayar. Bunun için de üç şeye ihtiyaç vardır: her iadenin tekil olarak izlendiği bir kayıt, iadeleri hata moduna ve üretim penceresine göre gruplayabilen bir analiz, ve bu analizden çıkan aksiyonların FMEA ile kontrol planına geri döndüğü kapalı bir döngü.
Garanti ve sözleşmesel sorumluluk paylaşımı
Garanti yönetiminin görünmeyen ama çok belirleyici bir yanı, sorumluluğun kimde olduğudur. Bir arıza sizin parçanızdan mı, montaj hattından mı, yoksa başka bir tedarikçinin bileşeninden mi kaynaklandı? Bu sorunun cevabı çoğu zaman doğrudan faturaya dönüşür. Bu yüzden sağlam bir garanti prosesi, teknik analizin yanında sözleşmesel çerçeveyi de dikkate alır: garanti süresi, sorumluluk paylaşımı ve iade koşulları müşteri anlaşmasında nasıl tanımlanmış?
Burada en çok değer, tarafsız ve tekrarlanabilir bir analizden gelir. Parçanın gerçekten arızalı olduğunu ya da olmadığını kanıtlarla gösterebilen bir firma, hem haksız yüklenen garanti maliyetini geri çevirir hem de kendi hatasını dürüstçe kabul edip düzeltir. Zayıf analiz ise ters yönde çalışır: ne kendi hatanızı görürsünüz ne de haksız faturaya itiraz edecek dayanağınız olur. Bu nedenle garanti analizinin metodolojisi, en az saklama kaydı kadar önemlidir; kayıtların ne kadar tutulacağını da kayıt saklama süreleri yazımızda ele alıyoruz.
Süreci bir kalite yazılımıyla yönetmek
Garanti verisini elektronik tablolarda tutmak, iade sayısı arttıkça örüntüyü görmeyi imkânsızlaştırır. Bir IATF 16949 uyumlu kalite yazılımı her garanti iadesini tekil kaydeder, NTF oranını ve hata modu dağılımını otomatik çıkarır, tekrar eden örüntüde bir 8D başlatır ve çıkan dersi ilgili FMEA satırına bağlar. Böylece garanti, ay sonunda bakılan bir gider kalemi olmaktan çıkar; tasarım ve prosesi sürekli besleyen canlı bir öğrenme kaynağına dönüşür. Konunun bütününü IATF 16949 rehberimizde bulabilirsiniz.