Denetim masasında en sevdikleri hamlelerden biridir: Denetçi kontrol planınızdan bir satır seçer, karşılık gelen proses FMEA'sını ister ve tek soru sorar — "Bu hatayı burada öngörmüşsünüz, kontrolü nerede?" O an FMEA'nızın gerçekten bir risk aracı mı yoksa denetim için doldurulmuş bir tablo mu olduğu ortaya çıkar. IATF 16949, FMEA'nın kendisini anlatmaz; ama FMEA'dan belli davranışlar bekler ve denetçi tam bu beklentileri yoklar. Bu yazıda standardın FMEA'dan ne aradığını maddelerin ardındaki niyetle açıyoruz; yöntemin genel tanımı için FMEA nedir sayfamıza bakabilirsiniz.
Standart FMEA'yı nerede ister?
IATF 16949 "FMEA yapın" cümlesini bir başlık altında yazmaz; beklentiyi maddelere dağıtır. Madde 8.3.3.3 özel karakteristiklerin belirlenmesini, 8.3.5.1 tasarım çıktılarını, 8.5.1.1 ise kontrol planını şart koşar. Bu maddelerin hepsi, arkasında bir risk analizi olmadan sağlıklı işlemez. Denetçi de bu yüzden FMEA'yı adı geçmese bile fiilen zorunlu bir girdi olarak arar.
Otomotiv müşterileri boşluğu kendi özel şartlarıyla doldurur: çoğu OEM AIAG-VDA FMEA kılavuzuna, 7 adımlı yaklaşıma ve AP (Aksiyon Önceliği) mantığına açıkça atıf yapar. Yani standardın "riski öngör ve önle" beklentisi, müşteri şartlarında belirli bir FMEA formatına dönüşür. İkisini ayrı ele almak denetimde açık verir.
DFMEA ve PFMEA: standardın beklediği ikili
Standart, tasarım sorumluluğu olan firmalardan tasarım FMEA'sını, üretim yapan herkesten proses FMEA'sını bekler. İkisi farklı alana bakar ama birbirini beslemek zorundadır. Aşağıdaki tablo bu ilişkiyi özetliyor.
| Tür | Odağı | Standarttaki karşılığı |
|---|---|---|
| DFMEA (Tasarım) | Parçanın tasarım kaynaklı riskleri | Tasarım çıktısı, özel karakteristik kaynağı |
| PFMEA (Proses) | Üretim adımlarındaki riskler | Kontrol planına ve iş talimatına girdi |
Kritik nokta şu: DFMEA'da işaretlenen bir özel karakteristik, PFMEA'da ilgili operasyona bağlanmalı, oradan da kontrol planına taşınmalıdır. Bu iki analiz kopuk yürütülürse, tasarımdan gelen kritik bir özellik prosese hiç yansımaz. Denetçi tam bu kopukluğu arar.
FMEA'da en sık yanılınan yer Saptama puanıdır. "Operatör görür zaten" bir kontrol değildir. Standart, saptama derecesinin arkasında kanıtlanabilir bir yöntem (poka-yoke, otomatik ölçüm, görsel kontrol talimatı) bekler. Kanıt olmadan düşük tutulan Saptama puanı, hem denetçiyi yanıltmaz hem de sahaya kaçan hatanın asıl kaynağı olur.
FMEA-kontrol planı bağı: en çok denetlenen halka
Standardın FMEA'dan en somut beklentisi budur: FMEA'da belirlenen her önemli hata nedeni ve her özel karakteristik, kontrol planında bir kontrol maddesiyle karşılanmalı. Denetçinin klasik yöntemi, FMEA'dan yüksek AP'li bir satır seçip kontrol planında izini sürmektir. Karşılığı yoksa, risk analizi kâğıt üstünde kalmış demektir.
Bu bağ tek yönlü de değildir. Kontrol planındaki bir kontrol, FMEA'da hangi riski azalttığını göstermelidir. Kontrol planına "her ihtimale karşı" eklenmiş, FMEA'da karşılığı olmayan ölçümler de tutarsızlık işaretidir. İki dokümanın aynı dili konuşması beklenir.
Bu bağı zorlaştıran şey, çoğu firmada FMEA ile kontrol planının farklı kişiler tarafından, farklı zamanlarda ve farklı dosyalarda güncellenmesidir. FMEA'da bir hata nedeninin Saptama puanı iyileştiğinde, bunun arkasında yeni bir kontrol vardır ve o kontrol kontrol planına yansımalıdır. Tersi de geçerli: kontrol planındaki bir ölçüm sıklığı değiştiğinde, FMEA'daki ilgili derece de gözden geçirilmelidir. İki doküman birbirinden habersiz yaşadığında, denetçinin seçtiği ilk satırda bu kopukluk ortaya çıkar. Standardın istediği, iki belgenin tek bir mantığın iki yüzü gibi davranmasıdır.
Özel karakteristikler nerede doğar?
Madde 8.3.3.3 özel karakteristiklerin (SC/CC) belirlenmesini ister ve bunların görünürlüğünü tüm zincirde bekler. Bu karakteristiklerin doğduğu yer FMEA'dır: tasarım FMEA'sında ortaya çıkar, proses FMEA'sında operasyona bağlanır, kontrol planında izlenir ve sahada SPC ile takip edilir. FMEA, bu özelliklerin riskinin ilk kez görünür kılındığı noktadır.
Denetçi bir özel karakteristik seçer ve bu zinciri baştan sona okur: tasarım girdisi, FMEA, kontrol planı, ölçüm kaydı. Zincirin bir yerinde karakteristik "kaybolursa", standardın özel karakteristik yönetimi beklentisi karşılanmamış sayılır.
FMEA'yı canlı tutmak: geri besleme beklentisi
Standart FMEA'yı bir kez doldurulup rafa kalkan bir belge olarak görmez. Yeni bir müşteri şikâyeti, sahadan dönen bir hata, proses değişikliği ya da benzer bir üründe yaşanan olay, ilgili FMEA'nın gözden geçirilmesini tetiklemelidir. Bu, APQP'nin beşinci fazındaki geri besleme mantığının FMEA'ya yansımasıdır.
Pratikte en sık düşülen tuzak, bir 8D kapanırken kök nedeni FMEA'ya işlememektir. Sahada yakaladığınız yeni bir hata modunu FMEA'ya eklemezseniz, aynı hata bir sonraki projede yeniden karşınıza çıkar. Denetçi de "en son ne zaman güncellendi, son şikâyet buraya yansıdı mı?" diye tam bu döngüyü sorgular.
Denetçi FMEA'ya baktığında önce yaşayıp yaşamadığını yoklar: revizyon tarihi güncel mi, yüksek AP'li satırların aksiyonu kapanmış mı, sahadaki son hata buraya işlenmiş mi, kontrol planıyla dili tutuyor mu? Tarihi eski, aksiyonu boş, kontrol planıyla kopuk bir FMEA, ne kadar dolu görünürse görünsün bulgu toplar.
AP mantığı: standardın önceliklendirmeden beklediği tutarlılık
Uzun yıllar risk, RÖS = Şiddet × Oluşma × Saptama formülüyle hesaplandı. Bu yaklaşımın zayıf yanı, çok farklı satırların aynı sayıya ulaşabilmesiydi: güvenlikle ilgili ağır bir hata ile önemsiz bir kozmetik kusur aynı RÖS değerini alabiliyordu. AIAG-VDA kılavuzu bu nedenle AP (Aksiyon Önceliği) mantığına geçti. AP, Şiddet-Oluşma-Saptama üçlüsünü bir tabloya göre Yüksek, Orta ve Düşük olarak sınıflandırır ve "önce neye bakmalıyız?" sorusuna daha tutarlı yanıt verir.
Standardın buradan beklentisi, önceliklendirmenin keyfî değil, izlenebilir bir kurala dayanmasıdır. Denetçi yüksek AP'li bir satır seçtiğinde iki şeyi görmek ister: bir aksiyon tanımlanmış mı ve o aksiyon kapanmış mı? Yüksek öncelikli bir satırın aksiyon sütunu boşsa ya da aylardır "açık" durumdaysa, risk analizi yapılmış ama riske karşı bir şey yapılmamış demektir. AP'nin amacı sayı üretmek değil, sınırlı mühendislik zamanını doğru satırlara yönlendirmektir. Bu yüzden yüksek AP'li satırların aksiyon takibi, FMEA'nın canlı olup olmadığının en somut göstergelerinden biridir.
FMEA beklentilerini bir platformla karşılamak
FMEA'nın zorluğu doldurmak değil, standardın istediği bağları canlı tutmaktır: DFMEA ile PFMEA arasındaki ilişki, FMEA ile kontrol planı arasındaki karşılık, özel karakteristiğin uçtan uca izlenmesi ve sahadan gelen her geri beslemenin analize dönmesi. Bunları dağınık Excel dosyalarıyla yürütmek, firma büyüdükçe bir revizyonu kaçırmayı garanti eder. Süreci IATF 16949 mantığıyla tek platformda yönetmek, FMEA-kontrol planı bağını otomatik kurar, AP hesabını yapar, aksiyonları sorumlu ve termin ile izler ve sahadan gelen hatayı ilgili FMEA'ya taşır. Böylece FMEA denetim öncesi doldurulan bir tablo olmaktan çıkar, standardın aradığı canlı risk aracına dönüşür.