Hattın başındaki şeffaf dosyada kontrol planının Rev.04'ü asılı duruyor. Kalite ofisindeki klasörde Rev.06 var. Geçen yıl müşteriye gönderilen PPAP paketinde ise Rev.05 geçiyor. Üçü de aynı parça numarasına ait ve üçü de birbirinden farklı ölçüm sıklığı söylüyor. Operatör hangi kâğıt önündeyse ona göre ölçüyor; kalite mühendisi kendi klasörüne göre denetime hazırlanıyor; müşteri ise onayladığı sürüme göre soruyor. Kontrol planı revizyon takibi denilen iş, aslında bu üç nüshayı tek bir doğru sürüme indirmenin ve her değişikliğin gerekçesini kayda geçirmenin adıdır.
Kontrol planı neden bu kadar sık değişir?
IATF 16949 madde 8.5.1.1 kontrol planının prototip, ön seri ve seri üretim aşamaları için hazırlanmasını ister ve maddenin devamında kontrol planının hangi durumlarda gözden geçirileceğini açıkça sayar: ürün değişikliğinde, proses değişikliğinde, ölçüm yönteminde veya kontrol sıklığında değişiklik olduğunda, kalite başarısızlığı yaşandığında. Yani revizyon istisna değil, normal işleyişin parçasıdır. Bir yıl boyunca hiç revize edilmemiş bir kontrol planı, sabit değil terk edilmiş demektir.
Sahada revizyonu tetikleyen olaylar da genelde aynıdır. Bir müşteri şikâyeti sonrası ek kontrol konur, bir tezgâh değiştiğinde ölçüm noktası kayar, proses yeterliliği düştüğünde numune sıklığı artırılır, PFMEA gözden geçirildiğinde yeni bir kontrol doğar. Bunların hepsi meşru gerekçelerdir; problem gerekçenin yazılmamasıdır. Yılda üç ile altı revizyon, aktif üretilen bir parça için normal bir aralıktır; on beşi geçiyorsa proses kararsızdır, sıfırsa kimse dokümana bakmıyordur. Formun sütunlarını ve kurulumunu kontrol planı sayfamızda ele aldık; burada konu revizyonun kendisi.
Revizyon nedeni yazılmayan revizyon
Kontrol planı formunun sağ üst köşesindeki "Rev." kutusuna 06 yazmak beş saniye sürer. Aynı kutunun yanına "neden 06 oldu?" cevabını yazmak, kalite sisteminizin ömrünü uzatır. Altı ay sonra o satırdaki ölçüm sıklığının neden 100 parçadan 25 parçaya indiğini kimse hatırlamaz; hatırlayan tek kişi de işten ayrılır. Revizyon nedeni yazılmadığında bir sonraki nesil o kontrolü "gereksiz" diye kaldırır ve aynı müşteri şikâyeti geri döner.
Doğru uygulama, her revizyonu tetikleyen kayda bağlamaktır. Aşağıdaki eşleştirme sahada işleyen bir düzendir:
| Revizyon nedeni | Bağlanacak kayıt | Müşteri bildirimi |
|---|---|---|
| Müşteri şikâyeti sonrası ek kontrol | DÖF / 8D numarası | 8D kapanışında bildirilir |
| PFMEA'da yeni yüksek risk | PFMEA revizyon numarası | Genelde gerekmez |
| Tezgâh veya kalıp değişimi | Proses değişiklik talebi | Gerekir, PPAP seviyesine bakılır |
| Ölçüm yöntemi değişikliği | MSA çalışma kaydı | Gerekir |
| Cpk hedefin altına düştü | SPC kayıt / proses çalışması | Müşteri özel şartına göre |
| Tasarım revizyonu | Mühendislik değişiklik bildirimi | Gerekir |
| Yazım hatası düzeltmesi | Doküman revizyon kaydı | Gerekmez |
Bu tablonun üçüncü sütunu, çoğu firmanın ihmal ettiği yerdir. Kontrol planı değişikliğinin müşteri bildirimi gerektirip gerektirmediği, müşterinin PPAP bildirim kurallarına bakılarak belirlenir. Tereddütte kalırsanız bildirin; bildirmemenin bedeli her zaman daha yüksektir.
Revizyon geçmişini okumak: bir kontrol planı örneği
Sağlıklı bir kontrol planı revizyon takibi, dosyanın son sayfasındaki revizyon geçmişi tablosundan okunur. Gerçek bir örnek üzerinden gidelim: bir kapı kilidi braketinin kontrol planı iki yılda beş revizyon görmüş. Rev.02'de kaynak nüfuziyeti ölçümü 100 parçada birden 25 parçada bire çekilmiş, gerekçe olarak müşteri şikâyeti numarası yazılmış. Rev.03'te aynı ölçümün cihazı komparatörden dijital yükseklik mastarına dönmüş ve satırın yanına MSA çalışma numarası düşülmüş. Rev.04'te yeni bir pres devreye alınmış, proses adımı numaraları kaymış. Rev.05'te Cpk üç ay üst üste 1,33'ün üzerinde kaldığı için sıklık 25'ten 50'ye gevşetilmiş ve gerekçeye SPC rapor numarası eklenmiş.
Bu beş satır okunduğunda parçanın hikâyesi ortaya çıkar: sorun yaşandı, sıkılaştırıldı, ölçüm iyileştirildi, proses değişti, kontrol altına alınınca gevşetildi. Revizyon nedeni sütunu boş olsaydı elinizde yalnızca beş tarih olurdu ve sıklığı geri gevşetme kararını hiç kimse savunamazdı. Denetimde de en çok işe yarayan şey bu anlatıdır; denetçi dokümanın kendisinden çok, dokümanın nasıl yaşadığına bakar.
FMEA ile kontrol planı arasındaki bağı canlı tutmak
Kontrol planı, PFMEA'nın çıktısıdır. Risk analizinde bir hata modunun saptama puanını iyileştirmek için "her 50 parçada bir kalınlık ölçümü" kararı verildiyse, bu kararın karşılığı kontrol planında bir satırdır. Tersi de doğru: kontrol planından bir kontrolü çıkarıyorsanız, ilgili FMEA satırının saptama puanı yükselmelidir ve yeni risk seviyesi kabul edilebilir mi diye bakılmalıdır.
Bu iki doküman ayrı dosyalarda tutulduğunda bağ ilk revizyonda kopar. Klasik senaryo şu: PFMEA yılda bir toplu gözden geçirilir, kontrol planına hiç dokunulmaz; ya da tam tersi olur. Denetçi bu kopukluğu bulmak için özel bir yöntem uygulamaz; sadece kontrol planındaki en yeni satırı seçip "bu kontrol hangi hata modu için kondu?" diye sorar. Cevap FMEA'da yoksa iki dokümanın senkron olmadığı anlaşılır.
Revizyon numarasını artırmadan içeriği değiştirmek, kontrol planlarında görülen en tehlikeli alışkanlık. "Küçük bir düzeltme, rev vermeye gerek yok" denilerek yapılan değişiklik, aynı numarayı taşıyan iki farklı dosyanın ortaya çıkmasına yol açar. Bir firmada Rev.03 adını taşıyan üç ayrı kontrol planı bulunmuştu; hangisinin müşteriye gönderildiği hiçbir şekilde tespit edilemedi. Kural basit: içerik değiştiyse sürüm değişir, istisnası yoktur.
Sahadaki nüsha: tek doğru sürüme sabitlemek
ISO 9001 madde 7.5.3 dokümante bilginin (documented information) kullanım noktasında erişilebilir ve uygun olmasını, güncel olmayan sürümlerin istenmeden kullanılmasına karşı önlem alınmasını ister. Kâğıt nüshalarla bunu sağlamak mümkündür ama disiplin gerektirir: dağıtım listesi tutulur, yeni sürüm yayımlandığında eski nüshalar toplanır, toplandığına dair kayıt tutulur. Uygulamada bu zincir çoğu zaman ikinci ayda kopar.
Daha sağlam çözüm, hat başındaki ekrandan sistemin gösterdiği geçerli sürüme bakmaktır. Kâğıt gerekiyorsa çıktının üstüne tarih ve sürüm damgası basılır, dosyanın kapağına da "yalnızca sistemdeki sürüm geçerlidir" notu konur. Doküman yönetimi tarafında yapılacak en somut iyileştirme, kontrolsüz fotokopiyi imkânsız hâle getirmektir. Operatörün elindeki kâğıt ile sistemdeki kayıt aynı olduğu sürece kontrol planı revizyon takibi kendiliğinden çalışır.
Revizyonun sahaya inmesi kâğıdı değiştirmekle bitmez. Ölçüm sıklığı ya da yöntemi değişen bir satır varsa, o istasyondaki operatörlerin yeni uygulamayı öğrendiğine dair kısa bir kayıt gerekir; beş dakikalık bir vardiya başı bilgilendirme ve imzalı katılım listesi bu iş için yeterlidir. İş talimatı da aynı anda güncellenmelidir, çünkü kontrol planı ile talimat farklı şey söylüyorsa operatör talimatı uygular. Uyumsuzlukların çoğu da tam buradan çıkar: plan Rev.06'ya geçmiş, talimat hâlâ Rev.04 mantığını anlatıyor ve denetçi ikisini yan yana koyduğunda uyumsuzluk anında görünüyor.
Onay akışı ve kim neyi onaylar
Kontrol planı çok fonksiyonlu ekibin ürünüdür, dolayısıyla revizyonu da tek imzayla yayımlanmamalıdır. Kontrol planı revizyon takibi açısından oturmuş yetki dağılımı şudur: değişikliği proses mühendisliği önerir, kalite riskin karşılandığını doğrular, üretim uygulanabilirliği onaylar, gerekiyorsa müşteri temsilcisi yazılı kabul verir. Onay sırası ve yetki matrisi prosedürde tanımlıysa, bir revizyonun kim tarafından atlandığı tartışması hiç yaşanmaz.
Onayla yayımlama arasındaki süreye de dikkat edin. Kâğıt sistemlerde onay üç günde alınır, sahaya inmesi bir haftayı bulur ve o hafta boyunca eski sürümle üretim yapılır. Yürürlük tarihi alanı bu yüzden vardır; onay tarihi ile yürürlük tarihi ayrı ayrı yazılmalı ve yürürlük tarihinden önce eski sürüm geçerli sayılmalıdır. Bu ayrım, denetimde "onay 12 Mart, sahadaki kayıt 15 Mart, arada ne oldu?" sorusunu baştan bitirir.
Kaç kontrol planı tutulmalı?
Revizyon karmaşasının bir kaynağı da kontrol planı sayısıdır. Aynı ailedeki 14 parça için 14 ayrı plan tutan bir firma, her değişiklikte 14 dosyayı güncellemek zorunda kalır ve üçüncü dosyada mutlaka birini atlar. AIAG yaklaşımı, aynı prosesten geçen ve aynı kontrol mantığını paylaşan parçalar için aile kontrol planı hazırlanmasına izin verir; parçaya özgü ölçüler ekte listelenir. Bu yaklaşım güncellenecek doküman sayısını belirgin biçimde azaltır.
Buna karşılık aile planı, farklı müşterilere giden ve farklı özel karakteristik tanımları olan parçalarda tuzağa dönüşür; bir müşterinin istediği ek kontrol diğerinin planına da yansır ve gereksiz maliyet doğar. Ayrım şu: proses akışı ve kontrol yöntemi aynıysa aile planı, özel karakteristikler ya da müşteri özel şartları farklıysa ayrı plan. Kararı yazılı bir kriterle verin ki iki yıl sonra "bunlar neden ayrı?" sorusuna cevabınız olsun. Yeni ürün devreye alırken bu kararın APQP üçüncü fazında verilmesi, sonradan bölünme zahmetinden kurtarır.
Denetçinin sahada yaptığı ilk kontrol şudur: hattaki nüshanın revizyon numarasını okur, sonra ofiste sistemdeki numaraya bakar. İkisi farklıysa başka hiçbir şeye bakmasına gerek kalmaz. İkinci kontrolü de PPAP dosyasına gönderilen sürümdür; müşteriye Rev.05 gönderilmişken sahada Rev.06 çalışıyorsa, bu revizyonun müşteriye bildirilip bildirilmediği sorulur ve çoğu zaman cevap alınamaz.
Revizyon takibini QMS üzerinde kurmak
Kontrol planı revizyon takibi bir kontrol planı yazılımı ya da bütünleşik bir kalite yönetim sistemi üzerinde yürütüldüğünde bu işin yükü belirgin biçimde azalır. Sistem her revizyonda eski sürümü otomatik arşivler, yeni sürüme geçmeden revizyon nedeni ve tetikleyen kayıt numarası girilmesini zorunlu tutar, onay akışını sırayla yürütür ve yürürlük tarihinde sahadaki ekranı günceller. FMEA satırı ile kontrol planı satırı aynı veri tabanında bağlıysa, FMEA'da yapılan bir değişiklik kontrol planında ilgili satırı gözden geçirilmek üzere işaretler.
PaKalite'de kontrol planı, FMEA, DÖF ve PPAP modülleri aynı kayıt yapısını paylaştığı için bir revizyonun hangi şikâyetten doğduğu ve hangi PPAP paketiyle müşteriye gittiği geriye dönük izlenebiliyor. PPAP dosyasının hangi sürümü taşıdığını ve gönderim takibinin nasıl kurulduğunu PPAP dosyası hazırlama yazımızda ayrıntılı ele aldık. Kurulum tamamlandığında hattaki dosya ile ofisteki klasör arasındaki fark kapanır; kalan tek soru "hangi sürüm doğru?" değil, "bu değişikliği neden yaptık?" olur ve onun cevabı da kayıtta durur. Bu noktadan sonra denetim hazırlığı da dosya toplamaya değil, revizyon geçmişini birlikte okumaya dönüşür.