Masadaki tabloda 180 satır var. Hepsinin risk öncelik sayısı 100'ün altında, dolayısıyla tek bir aksiyon yok. Aynı ay içinde müşteriden iki kaçak şikâyeti gelmiş. Şikâyete konu olan hata türü ise tabloda hiç yazmıyor. Böyle bir tablo denetimi geçebilir ama hiçbir şeyi korumaz. Aradığınız PFMEA örneği boş bir şablon değil, satırların gerçekten nasıl kurulduğunu gösteren bir metin olmalı.
Neden RÖS'ten AP'ye geçildi
Eski yöntemde şiddet, oluşma ve tespit puanları çarpılır, çıkan risk öncelik sayısı bir eşikle karşılaştırılırdı. İki sorun vardı. Birincisi, çok farklı kombinasyonlar aynı sayıyı verebiliyordu: şiddeti 9 olan bir güvenlik satırı ile şiddeti 2 olan bir görünüm satırı aynı skorda buluşabiliyordu. İkincisi daha can sıkıcıydı — ekipler aksiyondan kaçmak için puanları eşiğin altına ayarlıyordu. Baştaki 180 satırlık tablo tam olarak bunun sonucudur.
AIAG-VDA yaklaşımında yerine Aksiyon Önceliği geldi. Üç puanın kombinasyonuna bakılır ve satır Yüksek, Orta veya Düşük öncelik alır. Tartışma "sayıyı kaça indirelim" olmaktan çıkıp "bu satır için ne yapacağız" hâline gelir. Yöntemin genel çerçevesini FMEA sayfamızda topladık; burada satırların nasıl doldurulduğuna bakıyoruz.
Yedi adım: PFMEA nerede başlar
AIAG-VDA yöntemi çalışmayı yedi adıma ayırır: planlama ve hazırlık, yapı analizi, fonksiyon analizi, hata analizi, risk analizi, optimizasyon ve sonuçların dokümantasyonu. Sahada en çok atlanan adım ilkidir. Kapsamı, ekibi ve sınırları belirlemeden başlayan çalışmalar üçüncü toplantıda dağılır, çünkü nereye kadar gidileceği tartışılır durur.
Yapı ve fonksiyon analizini de geçiştirmeyin. Prosesi adımlarına ayırıp her adımın ne yapması gerektiğini yazmadan hata türü yazmak, aslında tahmin yürütmek demektir. "Op.30 punta kaynak" bir adımdır; "iki parçayı belirlenen dört noktadan, tanımlı çap ve dayanımda birleştirmek" ise o adımın fonksiyonudur. Fonksiyon net yazıldığında hata türü kendiliğinden ortaya çıkar: nokta eksik, çap küçük, dayanım düşük, konum kaymış.
Ekibin kimlerden kurulacağı da bu adımda belirlenir. Masada yalnızca kalite oturuyorsa çalışma iki toplantıda tükenir. Prosesi işleten ustabaşı, kalıbı bilen kalıpçı, bakım ve süreç mühendisi masada olmalı; yeni bir ürün devreye alınıyorsa satın alma da bir oturuma katılsın. Katılım listesini tabloya ekleyin, çünkü bir yıl sonra "bu satırı kim yazdı" sorusunun cevabı gerekiyor.
Hata türü, etki ve neden: üç sütunun ayrımı
Bu üç sütunu karıştırmak, gördüğüm en yaygın hata. Hata türü o adımın kendi çıktısındaki sapmadır. Etki, bu sapmanın bir sonraki istasyonda, montaj hattında ve son kullanıcıda ne yarattığıdır. Neden ise sapmayı doğuran proses koşuludur. Üçünü ayrı ayrı yazmadığınızda şiddet puanı da doğru verilemez.
Etki sütununa "müşteri şikâyeti" yazmak yaygın bir kısayoldur ve puanlamayı imkânsız kılar. Etkiyi üç kademede yazın: kendi tesisimizde ne olur, müşterinin hattında ne olur, son kullanıcıda ne olur. Şiddet puanı en ağır etkiye göre verilir ve bu puan aksiyonla düşürülemez — şiddeti düşürmenin tek yolu tasarımı veya prosesi değiştirmektir.
Neden sütununda ise durma noktasını doğru seçmek gerekiyor. Ortadan kaldırabileceğiniz bir proses koşuluna ulaştığınızda durursunuz: tanımsız bir parametre, hesaplanmamış bir bakım periyodu, ölçülmeyen bir aparat toleransı. Yöntemi derinleştirmek isterseniz kök neden analizi sayfasındaki yaklaşım burada da işe yarar; fark, orada olmuş bir hatayı, burada olabilecek bir hatayı ele almanızdır.
Satır satır doldurulmuş PFMEA örneği
Aşağıdaki tablo punta kaynak istasyonundan iki satır içeriyor. Kolonları sadeleştirdim ama mantık aynı. Kullanışlı bir PFMEA örneği her hücrede tek bir düşünce taşır; birden fazla hata türünü aynı satıra sıkıştırmak analizi bozar.
| Alan | Satır 1 | Satır 2 |
|---|---|---|
| Proses adımı | Op.30 Punta kaynak | Op.30 Punta kaynak |
| Fonksiyon | Braketi 4 noktadan tanımlı dayanımda birleştirmek | Braketi fikstürdeki konumda tutmak |
| Hata türü | Kaynak noktası dayanımı düşük | Braket konumu 1,5 mm kaymış |
| Etki | Müşteri montajında kopma, saha başarısızlığı riski | Montajda cıvata deliği tutmuyor, hat duruşu |
| Şiddet (Ş) | 9 | 7 |
| Neden | Elektrot aşınması; değişim periyodu adede bağlı tanımlı değil | Fikstür dayama pimi gevşemiş; kontrol periyodu yok |
| Oluşma (O) | 4 | 5 |
| Mevcut önleme kontrolü | Elektrot değişimi vardiya başı görsel kontrol | Fikstür ayar talimatı TL-KYN-014 |
| Mevcut tespit kontrolü | Vardiya başı kopma testi (1 adet) | Mastar kontrolü, her 100 adette |
| Tespit (D) | 5 | 4 |
| AP | Yüksek | Orta |
| Aksiyon | Elektrot değişimi 2.000 baskıda zorunlu, sayaç panele tanımlandı | Fikstür pim kontrolü haftalık bakım planına eklendi |
Dikkat edilecek nokta, nedenin "operatör hatası" olarak yazılmamış olması. Neden sütununa insan yazdığınız her satırda aksiyonunuz eğitime dönüşür ve risk azalmaz. Neden, proses koşulu olarak yazıldığında aksiyon da otomatik olarak proses üzerinde olur.
PFMEA çalışmasına başlamadan önce son iki yılın verisini toplayın: iç hurda kodları, yeniden işlem kayıtları, müşteri şikâyetleri ve garanti geri dönüşleri. Toplantıya bu listeyle girin ve ilk saatte tek bir soru sorun — bu hataların kaç tanesi mevcut tabloda yazıyor? Yaptığımız çalışmalarda cevap genellikle yarının altında çıkıyor. O eksik satırlar, ekibin hayal gücüyle bulamayacağı ama sahanın zaten bildiği hatalardır. Tabloyu gerçek yapan da bu liste oluyor.
Puanlamada tutarlılık: Ş, O, D
Puanlama tartışmalarının çoğu, ekibin ortak bir ölçek kullanmamasından çıkar. Kılavuzdaki ölçekleri kendi ürününüze göre örneklendirin ve bu örnekleri bir sayfada tutun: şiddet 9 hangi durumdur, şiddet 5 hangi durumdur, sizde neye karşılık gelir. Bu sayfa olmadan aynı hata türü iki farklı ekipte iki farklı puan alır ve karşılaştırma imkânsızlaşır.
Oluşma puanını verirken tahmin yerine veri kullanın. Kendi hurda oranınız, benzer prosesten gelen geçmiş veri ve proses yeterlilik sonuçları buraya girer. Tespit puanında ise soru şudur: bu kontrol hatayı hangi aşamada yakalar? İstasyonda yakalayan bir kontrol ile sevkiyat öncesinde yakalayan kontrol aynı puanı almaz. Ölçüm sisteminin güvenilirliği şüpheliyse tespit puanını iyimser vermeyin.
AP tablosu nasıl okunur
Aksiyon önceliği üç puanın birlikte değerlendirilmesiyle çıkar. Mantığı kabaca şöyle özetleyebiliriz: şiddet yüksekse tespit iyi olsa bile öncelik yükselir; şiddet düşükse oluşma yüksek olsa dahi öncelik düşük kalabilir. Aşağıdaki tablo bu mantığın nasıl işlediğini birkaç örnek üzerinden gösteriyor.
| Ş | O | D | AP | Ne anlama gelir |
|---|---|---|---|---|
| 9-10 | 4 | 5 | Yüksek | Güvenlik etkisi var; aksiyon zorunlu, gerekçe yazılmadan geçilemez |
| 7 | 5 | 4 | Orta | Aksiyon beklenir; alınmayacaksa gerekçesi kayda geçer |
| 7 | 2 | 2 | Düşük | Mevcut kontroller yeterli kabul edilir, izlemeye alınır |
| 3 | 6 | 6 | Düşük | Etkisi sınırlı; iyileştirme fırsatı olarak değerlendirilir |
Şiddeti 9 ve 10 olan satırlara özel dikkat gerekir; bunlar güvenlik ve yasal uygunluk alanıdır ve genellikle müşteri özel şartlarında ayrıca ele alınır. Bu satırlarda "mevcut kontroller yeterli" demek istiyorsanız gerekçeyi yazın; yazılmamış bir gerekçe, denetimde hiç düşünülmemiş sayılır.
Bir PFMEA örneği incelerken AP sütununun elle değil kuralla dolduruluyor olmasına dikkat edin. Puanları girip önceliği kendi kanaatine göre yazan ekipler, farkında olmadan eski alışkanlığa geri dönüyor. Öncelik bir kuraldan çıkmalı ve o kural bütün çalışmalarda aynı olmalı; ancak o zaman iki farklı hattın tabloları karşılaştırılabilir hâle geliyor.
Mevcut kontroller: önleme mi, tespit mi
Bu iki sütunu ayırmak analizin kalitesini belirler. Önleme kontrolü nedenin oluşmasını engeller: parametre kilidi, hata önleyici aparat, otomatik ayar doğrulaması. Tespit kontrolü ise hata oluştuktan sonra onu yakalar: ölçüm, mastar, görsel kontrol. Bir satırda yalnızca tespit kontrolü varsa risk gerçekte azalmamış, sadece görünür hâle gelmiştir.
Görsel kontrolü önleme sütununa yazmak yaygın bir hata. Görsel kontrol tespit kontrolüdür ve güvenilirliği sınırlıdır; tespit puanını buna göre verin. Otomotivde hata önleme düzeneklerinin doğrulanması ayrıca beklenir — düzeneğin çalıştığını vardiya başında test etmiyorsanız, o düzeneğe güvenerek verilen düşük tespit puanı gerçeği yansıtmaz. Araçların birbiriyle ilişkisini core tools sayfamızda ele aldık.
Optimizasyon: aksiyonu yazmak ve izlemek
Aksiyon yazarken üç şey belirtin: ne yapılacak, kim yapacak, ne zaman bitecek. Sorumlusu birim değil kişi olmalı. Aksiyon tamamlandığında yeni puanları vermeden önce etkiyi doğrulayın; veri görmeden puan düşürmek tabloyu yine kâğıt hâline getirir. Aksiyon sonrası şiddetin genellikle değişmediğini unutmayın, düşen oluşma ve tespit puanlarıdır.
Aksiyonların takibi, PFMEA'nın en sık koptuğu yerdir. Toplantıda yazılan on aksiyon, üç ay sonra kimsenin açmadığı bir dosyada kalır. Kopmayı önleyen şey, aksiyonun tablodan bağımsız bir yaşam kurmasına izin vermemektir: termin yaklaşınca sorumluya hatırlatma gider, geciken aksiyonlar listelenir, kapanan aksiyon doğduğu satıra bağlı kalır. PaKalite'de FMEA satırı ile ondan doğan düzeltici faaliyet ve doküman revizyonu birbirine referansla bağlanır. Tek hatlı bir atölyede bu düzen fazla gelir; PFMEA'sı beş taneyi geçen bir tesiste ise aksiyon listesini elle kovalamak günlük bir işe dönüşüyor.
Tabloyu okumam. Son bir yılın müşteri şikâyetlerinden ikisini alır, o hata türünü PFMEA'da ararım. Yazmıyorsa çalışmanın canlı olmadığı ortaya çıkar. Yazıyorsa aksiyona bakarım: alınmış mı, alınmadıysa gerekçesi var mı. Üçüncü olarak PFMEA'daki tespit kontrolünün kontrol planında karşılığını ararım. Bu üç kontrol, yüz satırlık tabloyu okumaktan daha çok şey söyler.
Kontrol planı ile bağ ve güncelleme disiplini
PFMEA tek başına yaşamaz. Hata türleri ve mevcut kontroller, kontrol planının girdisidir; ikisi karakteristik numarası üzerinden birbirine bağlanır. Numaralar uyuşmuyorsa hangi kontrolün hangi hatayı yakaladığını kimse gösteremez. Sütun sütun doldurmayı kontrol planı örneği yazısında anlattık; iki belgeyi birlikte revize etme alışkanlığı, gördüğüm en etkili tek uygulamadır.
Güncelleme tetikleyicileri de yazılı olmalı: proses değişikliği, yeni ekipman, yeni hata türü, müşteri şikâyeti ve düzeltici faaliyet. Şikâyet tetikleyicisi en çok atlanandır; 8D kapanır, tabloya dokunulmaz. Şikâyet sürecinin nasıl yürütüleceğini 8D raporu örneği yazısında ele aldık. D7 adımındaki yatay yayılım, aslında doğrudan PFMEA güncellemesi demektir.
Tabloyu küçültmekten de korkmayın. Yüz satırlık bir dosya, otuz satırlık gerçek bir analizden daha zayıftır. Ekibi toplayıp her satır için tek soru sorun: bu hata bu hatta gerçekten olabilir mi? Cevap hayırsa satır tabloyu şişirmekten başka işe yaramıyor demektir. Elinizdeki PFMEA örneği kaç satır uzunsa değil, kaç satırı sahada karşılık buluyorsa o kadar değerlidir; kalan satırlar üzerinde geçirilen zaman da doğrudan hatta yansıyor.