Aynı tedarikçiden üçüncü kez hatalı bir parti geldiğinde, çoğu kalite müdürünün aklına önce "bu tedarikçiyi listeden çıkaralım" düşüncesi gelir. Ama masaya oturup baktığınızda iş o kadar kolay değildir: o parça tek kaynaklı, müşteri onaylı ve yerine yenisini bulmak PPAP'ıyla birlikte en az altı ay. İşte tam bu noktada devreye tedarikçi geliştirme girer. IATF 16949'un beklediği de kapıyı kapatmak değil, zayıf tedarikçiyi ölçülebilir bir programla ayağa kaldırmaktır. Bu yazıda, denetimde de sahada da işe yarayan bir geliştirme programını, kâğıt üstünde kalan bir prosedür gibi değil, gerçekten uygulanan bir süreç gibi anlatıyoruz.
Tedarikçi geliştirme nedir, neyi hedefler?
Tedarikçi geliştirme, performansı ya da yeterliliği beklentinin altında kalan bir tedarikçinin kalite, teslimat ve süreç olgunluğunu planlı bir çalışmayla yükseltme faaliyetidir. Amaç tedarikçiyi cezalandırmak değil, sizin hattınıza gelen riski kaynağında azaltmaktır. Bir hata tedarikçinin kapısından çıktıktan sonra sizin hattınızda yakalanırsa maliyet katlanır; sahaya kaçarsa çok daha pahalıya patlar. Geliştirme, bu maliyeti tedarikçinin prosesinin içinde, en ucuz olduğu yerde durdurmaya çalışır.
IATF 16949 bu beklentiyi madde 8.4.2.4 ve tedarikçi yönetimi maddeleri üzerinden kurar. Standart, tedarikçinizin performansını izlemenizi, izleme sonucuna göre önceliklendirme yapmanızı ve gerektiğinde geliştirme başlatmanızı ister. Yani sistem "her tedarikçiye aynı şeyi yap" demez; "verinin gösterdiği yere odaklan" der. Bu risk temelli mantığı kavramak, geliştirme programının belkemiğidir.
Hangi tedarikçi geliştirme adayı olur?
Herkesle aynı anda çalışamazsınız; kaynağınız da sabrınız da sınırlı. Bu yüzden geliştirme her zaman bir önceliklendirmeyle başlar. Sahada işe yarayan sınıflama genellikle şu üç girdiyi birleştirir: kalite performansı, teslimat performansı ve o tedarikçinin sizin için taşıdığı risk (tek kaynak mı, güvenlik parçası mı, kritik karakteristik içeriyor mu).
| Sınıf | Tipik durum | Aksiyon |
|---|---|---|
| A — İyi | Düşük PPM, zamanında teslim | İzlemeye devam, yıllık gözden geçir |
| B — İzlemede | Dalgalı performans, ara sıra hata | Uyarı, hedefli aksiyon planı |
| C — Geliştirmede | Yüksek PPM, tekrar eden hata, geç teslim | Resmi geliştirme programı |
C sınıfına düşen bir tedarikçi için mesele artık "hoşnutsuzuz" demek değil; net bir başlangıç noktası, ölçülebilir bir hedef ve bir takvim koymaktır. Bu sınıflamayı nasıl kurduğunuzu tedarikçi yönetimi yaklaşımınızla bütünleştirmeniz, denetimde de tutarlı bir hikâye anlatmanızı sağlar.
Bir tedarikçiyi 250 PPM ile geliştirmeye aldığımızda ilk yaptığımız şey hedefi tek adımda 50 PPM'e çekmek değildi. Üç aşamalı bir merdiven kurduk: önce 250'den 120'ye, sonra 80'e, sonra 40'a. Tedarikçi ilk basamağı görebildiği için sürece inandı. Ulaşılmaz tek bir hedef koysaydınız, karşı taraf daha ilk ayda pes ederdi.
Geliştirme programı adım adım nasıl kurulur?
İyi bir program bir toplantıyla değil, bir akışla yürür. Sahada oturmuş hâli kabaca şöyledir:
- Temel çizgiyi belirleyin: son 6-12 ayın PPM, teslim ve şikâyet verisini masaya koyun.
- Kök nedeni birlikte bulun: sorunun tedarikçinin prosesinde mi, sizin şartnamenizde mi, yoksa iletişimde mi olduğunu ayırın.
- Ölçülebilir hedef ve termin koyun: "kaliteyi artır" değil, "üç ayda 250 PPM'den 80 PPM'e".
- Aksiyonları sahiplendirin: her maddenin bir sorumlusu ve tarihi olsun; iki tarafta da.
- Doğrulayın: değişen prosesi yerinde ya da ilk partilerle teyit edin, sözle yetinmeyin.
- Kapatın ve sınıfı güncelleyin: hedefe ulaşıldıysa tedarikçiyi bir üst sınıfa taşıyın.
Bu adımların en çok atlananı üçüncüsüdür. Ölçülebilir hedef ve termin olmadan başlayan "geliştirme" toplantıları, birkaç hafta sonra kimsenin ne söz verdiğini hatırlamadığı bir sohbete dönüşür. Hedefi rakama bağlamak, hem tedarikçiye yön verir hem size denetimde kanıt sağlar.
Kök neden olmadan geliştirme olmaz
Geliştirmenin en sık yapılan hatası, semptomu tedavi etmektir. Tedarikçi bir hatalı parti gönderdi diye "%100 kontrol yapın" demek, hatayı durdurmaz; sadece kontrol maliyetini artırır ve bir süre sonra o kontrol de gevşer. Kalıcı sonuç için hatanın gerçekten neden çıktığını bulmak gerekir: kalıp aşınması mı, hammadde değişimi mi, operatör eğitimi mi, yoksa sizin resimdeki bir toleransın gerçekçi olmaması mı?
Bu yüzden ciddi bir geliştirme programı, tedarikçiden düzgün bir 8D ya da eşdeğer bir kök neden analizi ister ve bu analizi yüzeysel geçmez. "Operatör dikkatsizdi" cümlesi kök neden değildir; neden o operatörün hata yapmasına izin veren bir proses vardı, asıl soru budur. Kök neden doğru konursa, geliştirme hedefine birkaç ayda ulaşır; yanlış konursa aynı hata altı ay sonra başka bir partide geri gelir.
Bir denetçi tedarikçi geliştirme dosyanıza baktığında önce "bu program yaşıyor mu?" diye sorar. Başlangıç verisi var mı, hedef net mi, aksiyonların sorumlusu ve tarihi belli mi, sonuç ölçülmüş mü? Sadece "tedarikçiyle görüştük" yazan, öncesi ve sonrası olmayan bir kayıt, ne kadar iyi niyetli olursa olsun bulgu toplar. Denetçi hikâyeyi değil, kanıtı arar.
Geliştirme ve ikinci taraf denetimi ilişkisi
Geliştirme ile denetim çoğu zaman aynı zincirin halkalarıdır. Bir tedarikçiyi C sınıfına düşüren veri, genellikle bir yerinde denetimi tetikler; o denetimin bulguları da geliştirme planının maddelerine dönüşür. Tersine, geliştirme sonunda ulaştığınız durumu doğrulamak için yeniden bir yerinde ziyaret gerekebilir. İki süreci birbirinden kopuk yürütürseniz, denetimde bulunan bir eksiğin geliştirme planına hiç yansımadığını fark edersiniz. Bu bağı kurmak için ikinci taraf tedarikçi denetimi yaklaşımınızı geliştirme akışının bir girdisi olarak tasarlamak gerekir.
Aynı şekilde, geliştirmenin başarısını rakamla görmek istiyorsanız düzenli bir tedarikçi izleme ve PPM takibi olmadan olmaz. Geliştirme "iyi hissettiren" bir faaliyet değil, eğrisi aşağı inen bir metriktir.
Geliştirmede iletişimi doğru kurmak
Tedarikçi geliştirme teknik bir konu gibi görünse de, işin yarısı ilişkiyi doğru yönetmektir. Karşı tarafa "sizi geliştirmeye aldık" cümlesini bir tehdit gibi kurarsanız, tedarikçi savunmaya geçer, veriyi saklamaya başlar ve gerçek kök nedeni sizden gizler. Aynı mesajı "birlikte bu hattı düzeltelim, ikimizin de yararına" çerçevesiyle verdiğinizde, sahadaki mühendis size kalıp raporunu, proses parametrelerini ve gerçek fire verisini açar. Geliştirmenin hızını çoğu zaman teknik zorluk değil, bu güven belirler.
İletişimi düzenli tutmak da önemlidir. Ayda bir kısa bir gözden geçirme, altı ayda bir yapılan dev bir toplantıdan çok daha etkilidir; çünkü aksiyonlar tazeyken konuşulur, sapmalar küçükken düzeltilir. Bu toplantıların bir tutanağı, bir aksiyon listesi ve bir sonraki adımı olmalı; "iyi gidiyor" temennisiyle bitmemeli. Tedarikçiye ilerlemesini kendi karnesi üzerinden göstermek, sürece sahip çıkmasını sağlar. İnsan, eğrisinin düştüğünü kendi gözüyle gördüğünde programa inanır. Kötü haberi de iyi haberi de aynı sakinlikle konuşabildiğiniz bir ilişki, bir sonraki hata çıktığında tedarikçinin sizden kaçmak yerine ilk sizi aramasını sağlar; asıl kazanç budur.
Süreci tek platformda yönetmek
Tedarikçi geliştirmenin en yorucu yanı analiz değil, takiptir. Onlarca tedarikçinin PPM eğrisini, açık düzeltici faaliyetlerini, denetim bulgularını ve söz verilen terminleri ayrı Excel dosyalarında izlemek firma büyüdükçe imkânsızlaşır. Bir kalite yönetim yazılımı bu parçaları tek yerde toplar: her tedarikçinin performans kartı, açık aksiyonları, geçmiş denetimleri ve geliştirme hedefleri aynı ekranda görünür. Böylece geliştirme programı, yılda bir açılıp kapanan bir klasör olmaktan çıkar; her ay bakılan, sorumlusu belli, sonucu ölçülen canlı bir sürece dönüşür. IATF 16949'un istediği risk temelli tedarikçi yönetimini de en kolay bu şekilde, dağınık dosyalar yerine tek bir IATF 16949 uyumlu sistemle kurarsınız.