Müşteri denetçisi sahaya inince doğrudan pres hattına yürüdü, kontrol planındaki özel karakteristiği buldu ve tezgâhtaki operatöre sordu: "Bu ölçü sınır dışına çıkarsa ne yaparsın?" Operatör reaksiyon planını doğru anlattı. Ardından denetçi kalite ekibine döndü: "Son üç ayda kaç kez çıktı ve her seferinde ne yaptınız?" İşte o soru, kontrol planı ile ölçüm verisinin, ölçüm verisinin de düzeltici faaliyetle bağının kurulup kurulmadığını sınar. Otomotivde bir kalite yönetim sistemi yazılımı tam olarak bu bağları taşımak için seçilir; ayrı ayrı çalışan modüller IATF 16949 denetiminde yetmez. Bu yazıda standardın otomotive özgü şartlarını yazılım karşılığıyla ele alıyoruz.
IATF 16949 kalite yönetim sistemi yazılımı ISO 9001'den nasıl ayrılır?
IATF 16949, ISO 9001:2015'in üzerine otomotiv sektörünün ek şartlarını koyar. Yani temel yapı aynıdır; fark, eklenen başlıkların ağırlığındadır. PPAP dosyası, APQP fazları, kontrol planı, özel karakteristikler, katmanlı proses denetimi, müşteri özel şartları, ürün güvenliği ve tedarikçi geliştirme — bunların hepsi kayıt üretir ve hepsi birbirine bağlıdır. Standardın genel çerçevesi için IATF 16949 nedir yazımıza bakabilirsiniz.
Uygulamada şu ayrımı görürsünüz: ISO 9001 için doküman ve DÖF modülü olan bir kalite yönetim sistemi yazılımı büyük ölçüde yeter. IATF'te ise ürün geliştirme ile üretim arasındaki veri akışı olmadan sistem eksik kalır.
Madde 8.3 tasarım ve geliştirme yazılımda nasıl izlenir?
Madde 8.3.2.1 tasarım ve geliştirme planlamasının çok disiplinli bir yaklaşımla yapılmasını ister; 8.3.3.3 özel karakteristiklerin belirlenmesini, 8.3.5.2 ise proses tasarım çıktılarını (kontrol planı, PFMEA, ambalaj şartları, iş talimatı) tarif eder. Yazılımda karşılığı APQP proje planıdır: fazlar, kapı gözden geçirmeleri, sorumlular ve çıktı dosyaları tek bir proje altında toplanır.
Kritik nokta, tasarımdan çıkan özel karakteristiğin PFMEA'ya, oradan da kontrol planına aynı kodla taşınmasıdır. Üç ayrı Excel'de üç ayrı isimle duran karakteristik, denetimde ilk soru işaretini yaratır. Bir örnek: müşterinin çizimde elmasla işaretlediği bir çap ölçüsü, PFMEA'da "delik çapı sapması" olarak, kontrol planında ise "Ø12 H7" olarak geçiyorsa denetçi bunların aynı karakteristik olduğunu size sorar. Yazılım tek bir karakteristik kaydı tutup üç dokümana da aynı kaydı bağladığında bu soru hiç doğmaz. Ayrıntılar için IATF 16949 madde 8.3 ve özel karakteristikler yazılarımıza göz atın.
Madde 8.5.1 üretim kontrolü için hangi kayıtlar tutulur?
Madde 8.5.1.1 kontrol planının tüm imalat için hazırlanmasını ve müşteri şartlarına uygun olmasını, 8.5.1.2 standart işi ve görsel yardımcıları, 8.5.1.3 tezgâh ayar doğrulamasını (ilk parça / son parça), 8.5.6.1 ise üretim proses değişikliklerinin kontrolünü ister.
- Kontrol planı sürümleri yazılımda tutulur ve proses değişikliğinde otomatik revizyon uyarısı üretir.
- İlk parça onayı tabletten kaydedilir; onay olmadan seri üretim başlatılamaz.
- Talimatlar tezgâh başında güncel sürümle görüntülenir, eski sürüm erişime kapalıdır.
- Proses parametre değişiklikleri gerekçesiyle birlikte kayıt altına alınır.
Kontrol planı yapısını ve madde 8.5 üretim ve hizmet sunumu şartlarını ilgili yazılarımızda ayrıntılandırdık.
Katmanlı proses denetimi (madde 9.2.2.3) yazılıma alınınca en büyük değişim yöneticilerde olur. Kâğıt formda ayın son haftası toplu doldurulan denetimler, sistem tarih damgası tuttuğu anda ortaya çıkar. İlk iki ay tamamlanma oranı düşer, sonra gerçek seviyeye oturur. Bu düşüşü ceza konusu yapmayın; asıl kazanç, gerçek veriyi ilk kez görüyor olmanızdır.
Madde 9.1.1.1 proses yeterliliği yazılımla nasıl izlenir?
Madde 9.1.1.1, imalat proseslerinin istatistiksel çalışmalarla analiz edilmesini ve parça onay sürecinde kabul edilen yeterlilik düzeyinin sürdürülmesini ister. Bu, pratikte SPC verisinin sürekli akması ve eşik altına düşüldüğünde bir reaksiyon planının devreye girmesi demektir. Yalnızca grafik çizen bir modül yetmez.
Sahada en sık gördüğümüz tablo şu: ölçüm verisi tezgâh başında kâğıda yazılıyor, ay sonunda bir mühendis bunları Excel'e giriyor ve Cpk hesaplanıyor. Sonuç iki hafta gecikmeli çıkıyor; eşik altına düşen proses için alınan aksiyon da o kadar gecikiyor. Ölçüm doğrudan sisteme girildiğinde hesap anlık yapılır ve kural ihlali vardiya bitmeden bildirilir. Aradaki fark, hurdaya giden parti sayısında görülür.
| Madde | Otomotiv şartı | Yazılımda karşılığı |
|---|---|---|
| 8.3.3.3 | Özel karakteristiklerin belirlenmesi | Karakteristik kodu, DFMEA-PFMEA-kontrol planı bağı |
| 8.5.1.3 | Tezgâh ayar doğrulaması | İlk parça onay kaydı, onaysız başlatma engeli |
| 8.6.2 | Görünüm ve düzenli kontroller | Periyodik kontrol planı ve hatırlatma |
| 9.1.1.1 | İmalat prosesi istatistiksel analizi | Cp/Cpk, Pp/Ppk hesabı ve reaksiyon tetiği |
| 9.2.2.3 | Katmanlı proses denetimi | Katman planı, mobil form, tarih damgası |
| 10.2.3 | Problem çözme (8D) | 8D adımları, kök neden zorunlu alanı |
| 10.2.4 | Hata önleyici (poka-yoke) | Poka-yoke doğrulama planı ve kaydı |
Yeterlilik hesabı ve eşik yönetimi için Cp Cpk hesaplama ve proses performansı ve Cpk yazılarımız işinizi görür.
Madde 10.2.3 problem çözme ve 8D nasıl yürütülür?
Madde 10.2.3 tanımlanmış bir problem çözme prosesini şart koşar; 10.2.4 hata önleyici yöntemlerin kullanılmasını, 10.2.5 ise garanti yönetimini (uygulanabilir olduğunda) ister. Müşteri şikâyeti geldiğinde beklenen akış nettir: 24 saatte kontrol altına alma, ardından kök neden ve kalıcı aksiyon, sonra doğrulama.
Yazılım burada üç yerde fark yaratır. Birincisi, süre sayacı: kontrol altına alma adımının saatini tutar. İkincisi, kök neden alanını zorunlu yapar ve "operatör dikkatsizliği" gibi kapanışları engelleyecek yöntem seçimi ister. Üçüncüsü, kalıcı aksiyonun kontrol planı ve PFMEA'ya yansıtılmasını takip eder — IATF denetiminde en sık kaçırılan adım budur. Süreci 8D rapor programı ve madde 10.2 düzeltici faaliyet yazılarımızda ele aldık.
IATF denetçisi genelde bir müşteri şikâyetinden başlayıp zinciri geriye doğru yürütür: şikâyet numarası, 8D raporu, kök neden, kalıcı aksiyon, PFMEA revizyonu, kontrol planı revizyonu, iş talimatı revizyonu, operatör eğitimi. Bu yedi halkadan biri kopuksa bulgu yazılır. Yazılım seçerken sorulacak asıl soru budur: bu zinciri tek ekranda gösterebiliyor musunuz?
PPAP ve tedarikçi tarafında yazılım ne sağlar?
Otomotivde PPAP dosyası 18 elemanıyla ayrı bir emek ister. Yazılımın katkısı dosyayı derlemekten çok, elemanların güncelliğini korumasıdır: kontrol planı revize olduğunda PPAP'ta hangi seviyenin yeniden sunulacağını hatırlatır. Madde 8.4.2.4 tedarikçi izlemesini, 8.4.2.5 ise tedarikçi geliştirmeyi şart koşar; PPM, sevkiyat performansı ve şikâyet sayısı otomatik toplanmadığında bu izleme ayda bir gün süren manuel işe döner. Ayrıntılar PPAP takip sistemi ve PPM hesaplama yazılarımızda.
Standardın tamamına yazılım gözüyle bakan ISO 9001 kalite yönetim sistemi yazılımı yazımız, buradaki ek şartların dayandığı temeli anlatıyor.