OEM müşterisinin tedarikçi denetiminde, öğleden sonraki oturumda soru şöyle geldi: "Müşteri özel şartlarınızın son revizyonu geçen yıl ekimde yayınlandı. Bunu hangi kayıtla, hangi prosedürlerinize yansıttınız?" Kalite şefi dizüstü bilgisayarını çevirdi ve sunucudaki bir klasörü açtı: içinde 14 adet PDF, dosya adlarında müşteri kodu ve tarih. Denetçi tek cümleyle karşılık verdi: "Bu bir arşiv. Ben yansıtma kaydını sordum." Otomotiv için QDMS türü bir yazılım ararken cevaplanması gereken asıl soru işte budur: sistem, şartla kaydı birbirine bağlıyor mu?
Otomotiv için QDMS diye aranan şey çoğu zaman budur: kayıtları birbirine bağlayan bir kalite yazılımı. Otomotiv tedarikçisinin kalite yazılımından beklentisi, genel imalat firmalarınınkinden farklıdır. Sizden istenen yalnızca dokümanı düzenli tutmak değil; her şartın hangi kayıtla karşılandığını, her karakteristiğin hangi kontrolle izlendiğini ve her müşteri talebinin sistemin neresine düştüğünü göstermektir. Bunu satın alma öncesinde nasıl doğrulayacağınıza bakalım.
IATF 16949'un doğrudan yazılıma dokunan şartları
Otomotiv için QDMS değerlendirmesine standardın kendisinden başlamak gerekir. Standardın tamamı bir yazılımı ilgilendirmez; ama birkaç maddesi doğrudan kayıt altyapısıyla ilgilidir. Madde 4.3.2, müşteri özel şartlarının (customer specific requirements) değerlendirilmesini ve kalite yönetim sisteminizin kapsamına dahil edilmesini ister. Madde 7.5.3.2.2, müşteri mühendislik standart ve spesifikasyonlarındaki değişikliklerin gözden geçirilmesini ve bu gözden geçirmenin bildirimden itibaren 10 iş gününü aşmamasını şart koşar.
Madde 8.5.1.1 prototip, ön seri ve seri üretim için kontrol planı ister; madde 9.2.2.3 imalat proses denetimlerinin üç yıllık dönemde tüm vardiyaları kapsamasını, madde 10.2.3 ise problem çözme prosesinin kök nedeni bir metodolojiyle bulmasını ve sistemsel düzeltici faaliyetin FMEA ile kontrol planına yansımasını bekler. Bu dört madde bir araya geldiğinde, birbirine bağlı bir kayıt yapısı olmadan uyum sağlamanın neden zor olduğu görülür.
Burada sık yapılan bir kavram hatasını da düzeltelim: hiçbir yazılım sizi IATF 16949 uyumlu yapmaz. Standart kuruluşları belgelendirir, ürünleri değil; "IATF sertifikalı yazılım" ifadesi teknik olarak yanlıştır. Yazılımın yapabileceği şey, şartı karşıladığınızı gösteren kaydın doğru anda, doğru alanlarla ve elle müdahale gerektirmeden oluşmasını sağlamaktır. Değerlendirme yaparken satıcının sertifika iddiasına değil, bu kaydın nasıl oluştuğuna bakın. Standardın genel çerçevesi için IATF 16949 sayfamıza bakabilirsiniz.
Şart-işlev eşleştirmesi: demoda neye bakılacak?
Aşağıdaki tablo, otomotiv için QDMS teklifi değerlendirirken kullanabileceğiniz bir eşleştirmedir. Sol sütunda standardın şartı, ortada yazılımdan beklenen işlev, sağda ise demo sırasında görmeniz gereken ekran var. Bu tabloyu teklif dosyasına ek yapın; satıcıdan her satır için "var/yok" değil, ekran görüntüsü isteyin.
| IATF şartı | Yazılımdan beklenen işlev | Demoda görülecek ekran |
|---|---|---|
| 4.3.2 Müşteri özel şartları | CSR kaydı ve prosedürlerle bağ | CSR kartı ve bağlı doküman listesi |
| 7.5.3.2.2 Mühendislik spesifikasyonları | Değişiklik bildirimi ve 10 iş günü sayacı | Açık gözden geçirme görevleri |
| 7.5.3.2.1 Kayıt saklama | Kayıt tipine göre saklama süresi | Arşiv ve imha planı ekranı |
| 8.5.1.1 Kontrol planı | Faz bazlı plan ve FMEA bağı | Kontrol planı revizyon geçmişi |
| 9.2.2.3 Proses denetimi | Vardiya bazlı denetim takvimi | Üç yıllık kapsam matrisi |
| 10.2.3 Problem çözme | 8D/5 Neden akışı ve FMEA güncellemesi | DÖF kapanış ekranı |
| 8.4.2.4 Tedarikçi izleme | Performans göstergeleri ve puan kartı | Tedarikçi karnesi |
CSR takibi: klasörden kayda geçmek
Müşteri özel şartları otomotivde işin en zahmetli tarafıdır, çünkü her müşterinin kendi kılavuzu, kendi revizyon takvimi ve kendi portalı vardır. Bir tedarikçi dört OEM'e çalışıyorsa dört ayrı şart setini takip eder ve bunların hepsi yılda bir-iki kez revize olur. PDF'leri bir klasörde tutmak bu yükü taşımaz.
İşleyen model şudur: her müşteri özel şartı sistemde bir kayıt olarak açılır, revizyon numarası ve yayın tarihiyle. Ardından o şartın hangi prosedürlerinizi, hangi kontrol planlarınızı ve hangi talimatlarınızı etkilediği bir kez tanımlanır. Yeni revizyon geldiğinde sistem bu listedeki her doküman sahibine görev açar; sahibi "etkilenmedi" ya da "revizyon başlattım" diye cevap verir ve cevap kayda geçer. Denetçi sorduğunda açacağınız ekran budur — 14 PDF'lik klasör değil.
Bu yapının bir yan faydası daha var: yeni bir müşteri kazandığınızda onun şart setini sisteme eklerken hangi prosedürlerinizi güncellemeniz gerektiğini baştan görürsünüz. Yeni müşteri devreye alma süresi, çoğu tedarikçide bu görünürlük olmadığı için uzar.
CSR'leri yalnızca kalite biriminin takip etmesi, tedarikçilerde sık rastlanan bir açıktır. Müşteri özel şartlarının önemli bir kısmı lojistiği (etiketleme, ambalaj, sevkiyat bildirimi), satın almayı (alt tedarikçi onayı) ve mühendisliği (değişiklik bildirim süresi) ilgilendirir. Kalite şefi bu şartları kendi klasöründe tuttuğunda, lojistik yeni etiket formatından aylar sonra haberdar olur ve ceza faturası gelir. CSR kaydının okuyucu listesine ilgili tüm bölümleri ekleyin.
Müşteri portalları ile kendi sisteminiz arasındaki boşluk
Her OEM'in bir tedarikçi portalı vardır: PPAP yüklemesi oradan yapılır, şikâyet oradan açılır, 8D raporu oraya girilir, tedarikçi karnesi orada yayınlanır. Bu portallar müşterinin sistemidir ve size ait değildir. Tedarikçilerin en çok düştüğü tuzak, portalı kendi kayıt sistemi yerine koymaktır. Müşteri portalında açılan bir şikâyet, sizin DÖF listenizde görünmüyorsa yönetim toplantısındaki rakam eksik kalır.
Doğru kurgu ikisini ayırmaktır: portal müşteriyle iletişim kanalıdır, kendi sisteminiz ise kayıt yeridir. Portala bir şikâyet düştüğünde aynı gün iç sisteminizde bir DÖF açılmalı, portal referans numarası o kayda yazılmalı ve iki tarafın termin tarihleri hizalanmalıdır. Dört farklı müşteriye çalışan bir tedarikçide bu disiplin kurulmadığında, dört portal ile bir Excel arasında sürekli veri kopyalayan bir kişi ortaya çıkar ve o kişi izne çıktığında takip durur. Farklı sektörlerin kayıt beklentilerini sektörler sayfamızda karşılaştırdık.
Kayıt saklama süreleri ve arşiv düzeni
IATF 16949 madde 7.5.3.2.1, üretim parça onayı, takım kayıtları, ürün ve proses tasarım kayıtları, satın alma siparişleri ve sözleşmeler için net bir kural koyar: ürün üretimde ve servis şartlarında aktif olduğu süre boyunca artı bir takvim yılı. Müşteri ya da yasal şart daha uzunsa o geçerlidir. Bu kural pratikte 15 yıla kadar uzayabilir; bir parçanın seri üretimi 8 yıl sürdüyse, servis dönemi 5 yıl daha devam ettiyse ve üzerine bir yıl eklendiyse tablo ortaya çıkar.
Yazılımdan beklenen, saklama süresini kayıt tipine göre otomatik hesaplamasıdır. Her kayıt açıldığında bir saklama sınıfı alır; süresi dolduğunda imha listesine düşer ve imha kararı onaya sunulur. Bunu elle yöneten firmalarda iki uçtan biri görülür: ya hiçbir şey silinmez ve arşiv taşar, ya da bir temizlik sırasında saklanması gereken kayıtlar da gider. İkincisi denetimde çok daha pahalıya patlar.
Arşivin fiziksel tarafını da ihmal etmeyin. Elektronik kayıtlar için yedekleme sıklığı, yedeğin nerede tutulduğu ve geri dönüş testinin ne zaman yapıldığı yazılı olmalıdır. Bir denetimde "yedekleriniz var mı?" sorusundan sonra gelen soru neredeyse her zaman "en son ne zaman geri yükleme denemesi yaptınız?" olur. Yılda bir kez yapılan yarım günlük bir geri yükleme tatbikatı, hem bu soruyu kapatır hem de gerçek bir arıza gününde işe yarar.
Core tools bağı: asıl fark burada
Genel amaçlı bir kalite yazılımı ile otomotiv odaklı bir yazılım arasındaki gerçek fark, çekirdek araçların (core tools) yazılımın içinde mi yoksa dışında mı durduğudur. PPAP, FMEA, kontrol planı, MSA ve SPC ayrı Excel dosyalarında yaşıyorsa, yazılım yalnızca dokümanların kabuğunu yönetiyor demektir. Araçların birbirine nasıl bağlandığını core tools sayfamızda anlattık.
Bağın en kritik halkası özel karakteristiklerdir. Müşteri resminde işaretlenen bir karakteristik, tasarım FMEA'sında görünmeli, proses FMEA'sına taşınmalı, kontrol planında bir ölçüm satırına dönüşmeli, iş talimatında operatöre anlatılmalı ve PPAP dosyasında müşteriye kanıtlanmalıdır. Beş halkanın hepsini tek kayıt üzerinden yürüten bir sistemde, kontrol planı revize edildiğinde bağlı iş talimatının sorumlusuna otomatik uyarı gider. Ayrı dosyalarda ise bu bağ insan hafızasına kalır.
Tedarikçi denetiminde denetçi yazılımınızın markasıyla ilgilenmez; izlenebilirlikle ilgilenir. Rastgele bir parça numarası seçer ve şu zinciri ister: müşteri resmi revizyonu, ilgili PFMEA, kontrol planı, son üretim tarihindeki ölçüm kaydı, o istasyonda çalışan operatörün yetkinlik kaydı ve kullanılan mastarın kalibrasyon sertifikası. Bu altı kaydı beş dakikada çıkaramıyorsanız sorun yazılımda değil, kayıtlar arasındaki bağdadır. Denetçinin ikinci klasik hamlesi, aynı parça için açılmış son müşteri şikâyetini isteyip aksiyonun kontrol planına yansıyıp yansımadığına bakmaktır.
Tedarikçi tarafı: siz de denetleyen taraftasınız
IATF 16949 madde 8.4.2.4 tedarikçi performansının izlenmesini ister ve göstergeleri de sayar: teslim edilen ürünün şartlara uygunluğu, müşteri sahalarındaki kesintiler, teslimat programı performansı ve ek navlun bildirimleri. Yani kendi alt tedarikçilerinizi ölçmekle yükümlüsünüz ve bu ölçümün kaydı denetimde istenir.
Bu yüzden otomotivde kullanılacak bir kalite yazılımının tedarikçi modülü olmadan düşünülmesi zordur. Beklenen işlev şudur: her tedarikçiye bir karne açılır, giriş kalite kontrol sonuçları ve teslimat verileri karneyi besler, puan bir eşiğin altına düştüğünde tedarikçiye otomatik DÖF açılır ve gerekiyorsa denetim planına eklenir. Tedarikçi yönetimi tarafındaki ayrıntıları ayrı bir sayfada topladık.
Demoda sormanız gereken beş soru
Otomotiv için QDMS seçerken satın alma kararını hızlandıran en pratik yöntem, demoyu senaryo üzerinden istemektir. Şu beş isteği sırayla yapın: bir CSR revizyonu yükleyip etkilenen dokümanları listeletin; bir müşteri şikâyetinden DÖF açıp kapanışta kontrol planı revizyonu zorunluluğunu gösterin; bir özel karakteristiği FMEA'dan PPAP'a kadar izletin; bir ölçüm cihazının kalibrasyon süresi dolduğunda hangi kayıtların uyarı verdiğini görün; ve açık DÖF listesini müşteri bazında filtreletin.
Bu beş senaryoyu tek oturumda gösteremeyen bir ürün, otomotivde beklediğiniz izlenebilirliği vermez. Kurulum modelini de sormayı unutmayın: müşteri resimleri ve PPAP dosyaları ticari sır niteliğinde olduğu için pek çok tedarikçi verinin kendi sunucusunda kalmasını ister. PaKalite'nin şirket içi kurulumla çalışması ve arayüzünün tamamen Türkçe olması bu iki beklentiye cevap verir; ama kararı marka adına değil, yukarıdaki beş senaryonun sonucuna göre verin.