Kaynak hattının kenarındaki pano üç kâğıt taşıyor. Aynı parça ailesi için üç müşteri üç farklı ilk parça onayı sıklığı istemiş: biri her vardiya başında, biri her 500 adette bir, biri sadece kalıp değişiminde. Operatör hangi kâğıda bakacağını vardiya amirine soruyor, amir de emin değil. Çok müşterili tedarikçi kalite yönetimi tam olarak burada çöker; sistemin kâğıt sayısı arttıkça sahadaki belirsizlik de artar.
Müşteriye özel şart nereden geliyor
CSR (customer specific requirements, müşteriye özel şartlar) müşterinin kendi tedarikçi el kitabında, kalite anlaşmasında ve parçaya özel şartnamelerde tarif ettiği ek beklentilerdir. Standardın üstüne binerler; standardı geçersiz kılmazlar. IATF 16949'un 4.3.2 maddesi müşteriye özel şartların değerlendirilmesini ve kalite yönetim sisteminin kapsamına dâhil edilmesini ister. Yani "biz IATF belgeliyiz, yeter" diyemezsiniz; CSR'ı sisteme almadıysanız kapsam eksik sayılır.
Bu şartlar dört tipik yerde toplanır: PPAP sunum seviyesi ve formatı, kontrol ve ölçüm sıklıkları, etiket ve ambalaj kuralları, şikâyet cevap süreleri. Beşinci bir grup daha var, hep sonra akla gelen: raporlama şartları. Aylık hangi verinin hangi portala hangi tarihte girileceği de bir CSR'dır ve karşılanmadığında karneye yansır.
Yanlış çözüm: her müşteriye bir prosedür
Beş müşterisi olan bir firmada gördüğüm en kötü kurgu şuydu: aynı süreç için beş ayrı prosedür yazılmış, her biri müşteri adıyla kodlanmıştı. Prosedürlerin gövdesi neredeyse birebir aynıydı, sadece iki üç cümle farklıydı. Süreç değiştiğinde beş dokümanı birden revize etmek gerekiyordu ve doğal olarak hiçbiri aynı anda revize edilmiyordu. Denetimde bulgu, şartın karşılanmamasından değil, beş dokümanın birbiriyle çelişmesinden çıktı.
Bu yolun sonu hep aynı: doküman sayısı ikiye üçe katlanır, revizyon yükü kalite birimini boğar ve sahadaki insan hangisinin geçerli olduğunu bilemez. Doküman sayısının kontrolden çıkması başlı başına bir risk; doküman yönetimi tarafında bu birikmenin nasıl yönetileceğini ayrıca anlattık.
Doğru kurgu: ortak omurga, müşteri katmanı
Çok müşterili tedarikçi kalite yönetimi için işleyen model iki katmanlıdır. Alt katman ortak omurgadır: süreci anlatan tek prosedür. Kimin ne yaptığı, adımların sırası, kayıtların nereye tutulduğu burada yazar ve müşteriden bağımsızdır. Üst katman müşteri katmanıdır: parametreleri taşıyan bir tablo. Kontrol sıklığı, örneklem büyüklüğü, cevap süresi, etiket formatı gibi değerler burada müşteri bazında durur.
Kural şu: akış aynıysa prosedür tektir, sadece parametre değişir. Akışın kendisi değişiyorsa, yani bir adım ekleniyor ya da sorumlu rol farklılaşıyorsa, o zaman ayrı bir talimat gerekir. Uygulamada müşteri farklarının büyük çoğunluğu parametre farkıdır. Gerçekten ayrı akış gerektiren şartlar bir elin parmaklarını geçmez.
Bu ayrımı yaparken kendinize tek bir soru sorun: bu şart karşılanmadığında hangi kayıt eksik kalır? Cevap "aynı kayıt, farklı değerle" ise parametredir. Cevap "bambaşka bir kayıt" ise akış farkıdır. Örnek vereyim. Bir müşteri ölçüm raporunu kendi formatında istiyorsa bu bir parametredir; çıktının biçimi değişir, süreç değişmez. Başka bir müşteri sevkiyat öncesi bağımsız bir laboratuvar raporu istiyorsa bu akış farkıdır; sürece yeni bir adım ve yeni bir kayıt girer. Birinciyi tabloya yazarsınız, ikinciye talimat açarsınız.
Hangi şart ortak, hangi şart müşteriye özel
Aşağıdaki tablo, orta ölçekli bir presli parça tedarikçisinde yaptığımız ayrıştırmanın özeti. Sol sütun süreci, ortadaki ortak omurgada ne yazdığını, sağdaki ise müşteri katmanında hangi alanın tutulduğunu gösteriyor. Bu tabloyu bir kez kurduğunuzda yeni müşteri geldiğinde yapılacak iş, prosedür yazmak değil bir satır doldurmak olur.
| Süreç | Ortak omurgada (tek prosedür) | Müşteri katmanında (parametre) |
|---|---|---|
| İlk parça onayı | Kim onaylar, kayıt nereye tutulur | Sıklık, imza sayısı, saklama süresi |
| PPAP sunumu | Dosya hazırlama ve iç onay akışı | Seviye (2/3/4), portal, dosya formatı |
| Şikâyet cevabı | 8D adımları, kök neden yöntemi | 24/48 saatlik ilk cevap, portal, dil |
| Etiketleme | Etiket basma ve doğrulama adımı | Barkod standardı, alan sırası, renk |
| Kayıt saklama | Arşiv yeri ve erişim yetkisi | Süre (ör. 3 yıl / ömür + 1 yıl) |
| Değişiklik bildirimi | Değişiklik talebi ve iç değerlendirme | Bildirim eşiği, ön onay gerekliliği |
Tabloyu doldururken en zor kolon sağdakidir, çünkü değerleri müşterinin el kitabından tek tek çıkarmak gerekir. Bir müşteri için ortalama yarım gün ayırın. Bir kez yapılır ve sonrasında yalnızca güncellenir.
Müşteri katmanı tablosunu doldururken her satıra kaynak yazın: hangi dokümanın hangi sürümünün kaçıncı sayfasından geldiğini. Bu tek kolon iki işi birden çözüyor. Denetçi "bu sıklığı nereden aldınız" diye sorduğunda cevap tabloda hazır oluyor. Müşteri el kitabı revize olduğunda da hangi satırların etkilendiğini aramadan görüyorsunuz. Kaynak kolonu olmayan CSR tabloları iki yıl içinde güvenilirliğini kaybediyor.
Sahaya inen kâğıt tek olmalı
İki katmanlı kurgunun asıl faydası hat kenarında ortaya çıkar. Operatörün önünde müşteri bazlı üç talimat değil, o an ürettiği parça numarasına ait tek talimat durur. Müşteri farkı arka planda çözülmüştür; çünkü kontrol planı parça bazında hazırlanır ve o parçanın müşterisi bellidir. Parça numarası müşteriyi zaten belirlediği için, sahada müşteri adı geçmesine gerek kalmaz.
Aynı parçayı iki müşteriye satıyorsanız durum değişir. O zaman iki seçenek var: ya en sıkı şartı ikisine birden uygularsınız, ya da iki ayrı parça numarası açarsınız. Birincisi maliyetlidir ama basittir; ikincisi ucuzdur ama stok karışma riski taşır. Kararı verirken sıkı şartın maliyetini bir hesaplayın, çoğu zaman düşündüğünüzden küçük çıkıyor. En sıkı şartı uygulamayı seçtiyseniz bunu bir yerde yazılı hâle getirin, yoksa iki yıl sonra kimse o kontrolün neden yapıldığını bilemez ve iyileştirme adı altında kaldırılır.
CSR'ı QMS'te nerede tutarsınız
CSR verisi üç yerde yaşamalı ve üçü birbirine bağlı olmalı. Birincisi müşteri kartı: el kitabı sürümü, kalite anlaşması, sorumlu kalite mühendisi, portal bilgisi. İkincisi şart tablosu: yukarıdaki matrisin doldurulmuş hâli, kaynak referanslarıyla. Üçüncüsü etkilenen kayıtlar: hangi prosedür, hangi kontrol planı, hangi form bu şarttan etkileniyor. Üçüncüsü olmadan değişiklik yönetimi yapılamaz.
Bunları tek bir sistemde tutmanın pratik faydası şu: müşteri denetime geldiğinde onun şartlarını filtreleyip tek ekranda gösterebilirsiniz. Denetçi kendi el kitabındaki maddeyi okur, siz karşılığında hangi dokümanla karşıladığınızı gösterirsiniz. PaKalite'de bu bağ müşteri kaydı üzerinden kurulur; şart satırından ilgili dokümana ve kontrol planına doğrudan gidilir. Hangi sistemi kullanırsanız kullanın aradığınız özellik budur: şart ile onu karşılayan kayıt arasında tıklanabilir bir bağ.
El kitabı revize olduğunda ne yaparsınız
Müşteri el kitapları sessizce revize olur. Portalda bir bildirim çıkar, tek kişinin gelen kutusuna düşer, o kişi izindedir ve konu orada kalır. Altı ay sonra denetimde eski sürüme göre çalıştığınız ortaya çıkar. Bunu önlemenin tek yolu takibi kişiye değil sisteme bağlamak: her müşteri için üç ayda bir tekrarlayan bir görev açın, görevin çıktısı "portaldaki sürüm numarası ile bizdeki sürüm aynı mı" sorusunun cevabı olsun.
Sürüm değişmişse fark analizi yapın. Yeni sürümü baştan sona okumak zorunda değilsiniz; müşteriler genelde değişiklik özeti yayımlar. Değişen maddeyi CSR tablonuzdaki kaynak kolonuyla eşleştirin, etkilenen satırları güncelleyin, etkilenen doküman ve PPAP dosyalarını revizyon listesine alın. Bu iş bir müşteri için genelde yarım gün sürer ve yılda birkaç kez tekrarlanır.
Takibi görünür kılmak için basit bir tablo yeter. Aşağıdaki örnek, dört müşterili bir tedarikçide tuttuğumuz kontrol takviminin sadeleştirilmiş hâli. Denetimde de birebir bu tablo gösteriliyor; ayrı bir sunum hazırlanmıyor.
| Müşteri | El kitabı sürümü | Son kontrol | Sorumlu | Açık aksiyon |
|---|---|---|---|---|
| Müşteri A | Rev 07 (Ocak 2026) | 02.03.2026 | Kalite Müh. 1 | Yok |
| Müşteri B | Rev 12 (Kasım 2025) | 02.03.2026 | Kalite Müh. 1 | Etiket formatı — 2 form revizyonu |
| Müşteri C | Rev 03 (Haziran 2025) | 27.02.2026 | Kalite Müh. 2 | Yok |
| Müşteri D | Rev 09 (Şubat 2026) | 05.03.2026 | Kalite Müh. 2 | Kayıt saklama süresi 3 → 5 yıl |
Tablonun beşinci kolonu en kıymetlisi. Açık aksiyon kolonu boş kalmıyorsa fark analizi yapılmış ama iş bitirilmemiş demektir; bu da denetimde en az eski sürümle çalışmak kadar sorun yaratır. Aksiyonu düzeltici faaliyet kaydına bağlarsanız takip kendiliğinden yürür.
Müşteriye özel şartlar denetimde iki soruyla yoklanır. Birincisi: bu müşterinin şartlarını nereden görüyorsunuz? Cevap bir klasör yolu ya da "kalite müdürü biliyor" olursa devamı gelir. İkincisi ve daha keskini: şu maddeyi hangi dokümanla karşılıyorsunuz? Şart ile dokümanı bağlayan bir tablonuz yoksa bu soruyu cevaplamak zaman alır; denetçi de o gecikmeyi not eder. Şartın karşılanıyor olması yetmiyor, karşılandığının gösterilebilir olması gerekiyor.
Yeni müşteri geldiğinde işleyen sıra
Yeni bir müşteriyle çalışmaya başladığınızda sırayı şöyle kurun. El kitabını ve kalite anlaşmasını edinin, sürüm numarasını kaydedin. CSR tablosunda o müşteri için bir sütun açın ve altı süreç satırını doldurun. Ortak prosedürlerde karşılığı olmayan bir şart çıkarsa, önce prosedürü genişletmeyi deneyin; ancak akış gerçekten farklıysa ayrı talimat yazın. Son adımda sorumlu kalite mühendisini atayın ve üç aylık kontrol görevini açın.
Bu sıra bir müşteri için iki günü geçmez ve çok müşterili tedarikçi kalite yönetimi düzeninizi bozmadan büyümenizi sağlar. Alternatifi, her yeni müşteride sistemin bir kat daha kalınlaşmasıdır. Otomotivde büyümenin önündeki engel genelde kapasite değil, sistemin taşıyabildiği karmaşıklıktır. Karmaşıklığı prosedür sayısıyla değil parametre tablosuyla taşıyan firmalar beşinci müşteride de rahat ediyor.
Ölçekle uyumlu davranın
İki müşterisi ve on beş parça numarası olan bir atölyede bu kurguyu yazılımla kurmaya gerek yok; iyi hazırlanmış tek bir tablo işi görür. Eşik, müşteri sayısı dördü ve aktif parça numarası sayısı ellisi geçtiğinde geliyor. O noktadan sonra şart ile dokümanı elle eşleştirmek mümkün olmuyor, çünkü tek bir prosedür revizyonu onlarca satırı etkiliyor. Kendi eşiğinizi ölçmek isterseniz basit bir test var: son prosedür revizyonunda hangi müşterilerin etkilendiğini bulmanız ne kadar sürdü? Yarım günü geçtiyse tabloyu sistemleştirme vakti gelmiştir. Karar verirken skor kartı takibi ve şikâyet yönetimini de aynı çatı altında düşünmenizi öneririm; müşteri verisinin dağılması, çok müşterili tedarikçi kalite yönetimi kurgusunun en zayıf halkası.