Geçiş projesinin ilk toplantısında kalite müdürü klasörünü masaya koydu ve "Bizim TS sistemimiz on yıldır çalışıyor, aslında her şey burada var" dedi. Klasör gerçekten doluydu; prosedürler, formlar, kayıtlar yerli yerindeydi. Ama IATF 16949 maddelerini yan yana koyup satır satır karşılaştırmaya başladığımızda tablo değişti. Risk temelli düşünme bir yaklaşım olarak dokümanlarda yoktu, tedarikçi geliştirme planı yüzeyseldi, güvenlikle ilgili parçaların ayrı ele alındığı bir yapı görünmüyordu. ISO/TS 16949'dan IATF 16949'a geçiş, işte bu türden bir farkı ortaya çıkarır: eski sistem yanlış değildir, eksiktir. Bu yazıda geçişin neyi değiştirdiğini ve projeyi nasıl kuracağınızı sahadan anlatıyoruz.
Neden değişti? Kısa arka plan
ISO/TS 16949, uzun yıllar otomotiv kalite yönetiminin ortak diliydi. Ancak ISO 9001'in 2015 sürümüyle birlikte tüm ISO yönetim standartları ortak bir üst yapıya, yani Annex SL'ye taşındı. Bu yeni yapı, bağlam analizi, risk temelli düşünme ve liderlik gibi kavramları öne çıkardı. IATF, otomotiv standardını bu yeni temele oturtmak ve son on yılın saha derslerini eklemek için ISO/TS 16949'u emekliye ayırdı; yerine IATF 16949'u getirdi. Yani geçiş bir moda değil, standardın temelinin değişmesiydi.
Bu, önemli bir sonucu beraberinde getirir: eski TS belgeleri geçerliliğini yitirdi. Bugün otomotiv tedarik zincirinde belge dediğinizde kastedilen tek şey IATF 16949'dur. Standardın genel çerçevesini IATF 16949 nedir rehberimizde bulabilirsiniz.
Geçişte neler değişti?
Değişiklikleri tek tek saymak yerine, projeyi en çok etkileyen başlıkları toplayalım. Aşağıdaki tablo, eski TS mantığıyla yeni IATF beklentisini yan yana koyuyor:
| Konu | ISO/TS 16949 mantığı | IATF 16949 beklentisi |
|---|---|---|
| Yapı | ISO 9001:2008 temelli | ISO 9001:2015 / Annex SL temelli |
| Risk | Önleyici faaliyet | Risk temelli düşünme, bağlam analizi |
| Tedarikçi | Değerlendirme ağırlıklı | Geliştirme, izleme ve ikinci taraf denetim |
| Güvenlik parçaları | Genel ele alış | Ayrı tanım, izlenebilirlik, özel kontrol |
| Gömülü yazılım | Kapsam dışı sayılırdı | Yazılım kalitesi için ayrı şart |
| Garanti / saha | Sınırlı | Garanti yönetimi ve NTF analizi şartı |
Bu satırların her biri, geçiş projenizde bir "iş paketi" olur. Şimdi en çok emek isteyen üçüne yakından bakalım.
Risk temelli düşünme artık merkezde
Eski standartta "önleyici faaliyet" başlığı vardı; bir olay olmadan önce tedbir almayı teşvik ederdi ama pratikte çoğu firmada kâğıt üstünde kalırdı. IATF 16949, önleyici faaliyeti kaldırıp yerine sistemin geneline yayılmış bir risk temelli düşünme yaklaşımı koydu. Artık her proses, kendi riskini ve fırsatını tanımlamak, bunları izlemek ve aksiyona bağlamak zorunda.
Pratikte bu, bir risk değerlendirme matrisi ile FMEA'nın birbirine bağlandığı, kurumsal riskin de proses riskinin de aynı mantıkla yönetildiği bir yapı demektir. Geçiş projesinde en sık atlanan nokta budur: firmalar FMEA'ları güncelleyip risk bölümünü boş bırakır. Denetçi ise "prosesinizin riskini nasıl belirlediniz, hangi aksiyonu aldınız" diye sorduğunda cevap alamaz.
Geçiş projelerinde en tehlikeli tuzak, eski TS dokümanlarının başlıklarını yenileyip içeriği aynı bırakmaktır. Bir firmanın "risk yönetimi prosedürü" adında yeni bir doküman açtığını ama içinde eski önleyici faaliyet formunu koyduğunu gördük. Denetimde bu hemen fark edilir. Yeni şart yeni bir düşünme biçimi ister, kapak değişikliği değil.
Tedarikçi yönetimi güçlendi
IATF 16949, tedarik zincirini eski standarttan çok daha ciddiye alır. Artık tedarikçiyi yılda bir puanlayıp rafa kaldırmak yetmez; bir tedarikçi geliştirme yaklaşımı beklenir. Riskli gördüğünüz tedarikçiye ikinci taraf denetimi yapmak, performansını sürekli izlemek, onların da IATF yolculuğunda ilerlemesini teşvik etmek şartların içindedir.
Bu değişiklik geçiş projesinin en çok direnç gören kısmıdır, çünkü işi firma dışına taşır. Kendi sisteminizi düzeltmek görece kolaydır; onlarca tedarikçinizi de belli bir olgunluğa çekmek zaman ister. Bu yüzden tedarikçi iş paketini projenin başında açmak, sona bırakmamak gerekir.
Yeni başlıklar: güvenlik, yazılım, garanti
Eski TS mantığında gölgede kalan üç konu, IATF 16949 ile net şartlara kavuştu. Güvenlikle ilgili parçalar (safety related) artık ayrı tanımlanır, izlenebilirlikleri güçlendirilir ve özel kontrollere tabi tutulur. Ürüne gömülü yazılım varsa, yazılım geliştirme kalitesi için ayrı bir öz değerlendirme beklenir. Sahadan dönen garanti parçaları için ise garanti yönetimi ve "arıza bulunamadı" (NTF) analizi devreye girer.
Firmanızda bu üç konudan hangileri varsa, geçiş projenize ayrı iş paketi olarak girmelidir. Yoksa denetimde beklenmedik bulgularla karşılaşırsınız; çünkü bunlar eski sistemde çoğu zaman hiç ele alınmamıştır.
Geçiş projesini adım adım kurmak
Deneyimimize göre iyi işleyen bir geçiş şu sırayı izler:
- Fark analizi: mevcut TS sisteminizi IATF 16949 maddeleriyle satır satır karşılaştırın.
- Boşluk listesi: eksik ya da zayıf şartları önceliklendirin, sorumlu ve termin atayın.
- Risk ve bağlam: kurumsal ve proses risklerini yeni yaklaşımla yeniden kurun.
- Çekirdek araçlar: APQP, PPAP, FMEA, MSA, SPC bağlarını gözden geçirin.
- Tedarikçi ve yeni başlıklar: geliştirme planı, güvenlik, yazılım, garanti iş paketleri.
- İç denetim ve YGG: yeni sistemi kendi iç denetiminizle test edin.
- Belgelendirme denetimi: eksikleri kapattıktan sonra IATF onaylı kuruluşa geçin.
Belgelendirme aşamasının işleyişini merak ediyorsanız IATF 16949 belgelendirme süreci rehberimiz denetim aşamalarını ayrıntılandırıyor.
Geçiş denetiminde ilk baktığım şey, fark analizinin gerçekten yapılıp yapılmadığıdır. İyi bir firma bana maddeleri tek tek gezdiren, her birinde "eski durumumuz buydu, şöyle güncelledik" diyebilen bir kayıt gösterir. Böyle bir iz yoksa, ne kadar yeni doküman açılmış olursa olsun geçişin yüzeysel kaldığını anlarım.
Geçişte en çok zorlanılan noktalar
Onlarca geçiş projesinde tekrar eden birkaç sıkıntı vardır. Bunları önceden bilmek, projenizin gereksiz yere uzamasını önler:
- Fark analizini yüzeysel yapmak: Maddeleri hızlıca "var/yok" diye işaretleyip geçmek, en büyük tuzaktır. Her maddede "bizde bu şart nasıl karşılanıyor, kanıtı nerede" sorusunu sormak gerekir. Yüzeysel fark analizi, eksikleri denetim gününe erteler.
- Üst yönetimi projeye katmamak: IATF 16949, liderlik ve bağlam maddeleriyle üst yönetimden aktif katılım bekler. Geçişi tek başına kalite bölümünün sırtına yüklerseniz, YGG ve kaynak kararlarında tıkanırsınız.
- Tedarikçi iş paketini sona bırakmak: Kendi sisteminizi düzeltmek görece hızlıdır; tedarik zincirini olgunlaştırmak zaman ister. Bu paketi projenin sonuna bırakan firmalar, belgelendirme takvimini kaçırır.
- Yeni başlıkları görmezden gelmek: Güvenlik parçaları, gömülü yazılım ve garanti yönetimi eski sistemde çoğu zaman hiç ele alınmadığı için gözden kaçar ve denetimde beklenmedik bulgulara yol açar.
Bu noktaların ortak dersi şudur: geçiş bir doküman yenileme işi değil, bir düşünme biçimi değişikliğidir. Yeni yaklaşımın kalbindeki risk bazlı düşünmeyi gerçekten içselleştiren firmalar, geçişi bir yük değil bir olgunlaşma fırsatı olarak yaşar.
Dokümantasyonu tek yerde tutmanın değeri
Geçiş sırasında en çok zaman kaybettiren şey, eski ve yeni dokümanların iç içe geçmesidir. Hangi prosedürün güncel sürümü hangisi, fark analizi nerede, hangi tedarikçinin denetimi ne durumda — bunlar dağınık dosyalarda takip edilirken proje kolayca yavaşlar. Merkezî bir platformda doküman yönetimi, versiyonları tek elden kontrol etmenizi, fark analizini ve aksiyon takibini aynı yerde yürütmenizi sağlar. Böylece geçiş, klasör taşımaktan çıkıp yapılandırılmış bir projeye dönüşür.