Ana içeriğe atla

FMEA (Failure Mode Effect Analysis) – Bölüm 2

İlk makalemizde FMEA’ya genel giriş yapmıştık. Bu makalemizde FMEA türlerine değineceğiz. FMEA temel olarak 4’e ayrılır:
  1. Sistem FMEA
  2. Tasarım FMEA
  3. Proses FMEA
  4. Servis FMEA
1. Sistem FMEA
Sistem ve alt sistemleri analiz ederek, sistemin eksiklerinden doğan sistem fonksiyonları arasındaki potansiyel hata türlerini belirlemeye odaklanır. Hedefi, sistemin kalitesini, güvenirliğini ve korunabilirliğini artırmaktır. Sistem FMEA’nın faydaları şunlardır:
  • Sistemi etkileyen potansiyel problemlerin bulunabileceği alanlar daralır.
  • Sistem içerisinde uygulanacak prosedürler için bir temel oluşturulmasına yardımcı olur.
  • Sistem içerisindeki fazlalıkların tespit edilmesine yardım eder.
  • Optimum sistem tasarım alternatiflerinin seçilmesinde yol gösterir.
2. Tasarım FMEA
Tasarım hatalarından doğan hata türlerine yönelik olarak üretime başlamadan önce ürünlerin analiz edilmesinde kullanılır. Hedefi, tasarım kalitesini, güvenirliğini ve korunabilirliğini artırmaktır. Tasarım FMEA’sının tamamlanmış olarak kabul edilebilmesi ancak üretim için onay ve bir başlangıç tarihinin verilmesi ile olabilir. Tasarım FMEA’nın faydaları şunlardır:
  • Tasarım geliştirme faaliyetleriyle ilgili önceliklerin belirlenmesi,
  • Potansiyel hataların tasarım aşamasında iken belirlenmesinin sağlaması,
  • Potansiyel güvenlik sorunlarının belirlenerek ortadan kaldırılmasına yardım etmesi ve değişiklik için açıklamaların kaydedilmesinin sağlanması,
  • Önemli ve kritik özelliklerin belirlenmesine yardım etmesi,
  • Ürünlerle ilgili tasarım ve doğrulamaların testi sırasında kullanılabilecek bilgilerin sağlanması
Tasarım FMEA’nın uygulanması sonucunda:
  • Potansiyel kritik veya önemli özelliklerin bir listesi ile potansiyel hata türlerinin Risk Öncelik Sayısı tarafından ağırlıklandırılmış bir listesi elde edilir.
  • Test, kontrol veya teşhis yöntemleri kullanılarak potansiyel parametrelerin listesi ile kritik ve önemli özelliklere yönelik, tavsiye edilen potansiyel faaliyetlerin listesi yardımıyla hata türü ve güvenlik sorunlarını ortadan kaldıracak veya hataları azaltacak potansiyel tasarım faaliyetlerini tespit etmek mümkün olacaktır.
Tasarım mühendisi, tasarım için FMEA hazırlığında kullanacağı çok sayıda dokümana sahiptir. Süreç tasarımdan nelerin beklendiği ve nelerin olmamasının umulduğu, örneğin tasarım niyetlerinin bir listesinin geliştirilmesi ile başlar. Olası hata veya başarısızlıkların ve sonuçlarının analizini dokümante etmeyi kolaylaştırmak için FMEA tablosu kullanılır.
3. Süreç FMEA
Analiz, üretim veya kurulum süreçindeki eksiklerden doğabilecek hata türlerini ortadan kaldırmak, üretim ve kurulum süreçini analiz etmek amacına hizmet etmektedir. Süreç FMEA’sının tamamlanmış olarak kabul edilebilmesi için bütün operasyonların belirlenerek değerlendirilmesi ve kontrol planlarında ise kritik olan bazı önemli özelliklerin oluşturulmasıyla mümkün olabilir.
Ürün ve süreçlerdeki var olan potansiyel hatalara ve problemlere karşı önlem almak için oluşturulan bir yöntemdir. Bu yöntem, sürecin fonksiyonu ve güvenilirliği açısından hataların etkisini ve bunları önlemenin adımlarını saptamaya yarayan sistematik bir yaklaşımdır.Farklı fonksiyonların katılımı ile yapılan bir ekip çalışmasıdır
Süreç FMEA, sürecin bir akış diyagramı ile başlatılır. Bu akış diyagramında her operasyonda üretilecek ürün karakteristikleri tanımlanmalıdır. Bazı etkilerin belirlenmesi ve bazı önem sıralamalarının tahsisi, tasarımda sorumlu mühendisten veya mevcut ise ilgili tasarı FMEA’dan elde edilebilir. Analizi kolaylaştırmak için aynı şekilde bir form kullanılır. Bu formda farklı olan hususlar üretim süreci için özel olan konulardır. Rasgele yapılan kalite kontrol denetimleri ve test aktiviteleri  hatanın bir varlığını muhtemelen tespit edemeyecektir. Buna karşılık Test tekniklerine dayanan bir koşullama yöntemi daha doğru bir tespit yöntemidir.
Tasarım mühendisi ve süreç mühendisi tavsiye edilen önlemlerin yerine getirilmesini sağlamak ve bunları duyurmaktan sorumludur. FMEA yaşayan bir dokümandır. Süreç FMEA’nın faydaları şunlardır:
  • Üretim veya kurulum süreçinin analizine yardımcı olması ve düzeltici faaliyetlerin önceliklerini belirlemesi.
  • Kritik veya önemli olan özellikleri tespit etmede ve kontrol planı oluşturmada yardımcı olması.
  • Süreç aşamasında ortaya çıkacak hataları belirlemesi ve düzeltici faaliyetlerle ilgili plan sunması.
Bu tekniğin uygulanmasıyla potansiyel kritik veya önemli özelliklerin bir listesi hazırlanarak, bunlara yönelik öngörülen potansiyel faaliyetlerin listesi yapılır. Potansiyel hata türlerinin risk öncelik sayısı ile belirlenen listesi üzerinde, bu hata türlerinin sebeplerini ortadan kaldıracak, ortaya çıkan hataları azaltacak ve katsayısı yardımıyla süreç yeterliliğinin geliştirilemediği durumlarda, hata nedenlerinin ve belirlenmesinin etkinliğini arttıracak potansiyel bir liste oluşturulur. Süreç FMEA Uygulama adımları aşağıdaki gibidir:
1. Ürün ve süreçin belirlenerek, çalışma ekibinin kurulması. Analize öncelikle, FMEA Değerlendirme Formunun doldurulmasıyla başlanır.
Çalışma ekibi genellikle sorumlu ve deneyimli kişilerden seçilen üç ile yedi kişiden kurulur. Öncelikle Süreç Sorumlusu seçilir. Süreç Sorumlusu öncelikle, İş Akış Diyagramları, İş Emri, Operasyon Onay ve Kontrol Formları, Operasyon Talimatları ve Kontrol Kartlar, Kontrol Planı ve diğer müşteri istekleri olan dökümanların tamamlanmasıyla uğraşır.
2. Ürün ve süreçin belirlenmesi aşamasında önce süreç aşamaları ve fonksiyonları belirlenerek, her bir parçanın fonksiyonunun ve bu fonksiyonu yerine getirecek özelliklerin tanımlanmasına çalışılır. Bu amaçla hazırlanan İş Akış Diyagramı çalışmayı yönlendirir.
3. Hata türlerinin tespitinde bir takım olasılıklardan yararlanılmaya çalışılır. Acaba müşteri hangi hata ve uygunsuzlukları  kabul etmeyip REDDEDEBİLİR. Parça operasyonda niçin RED edilebilir veya bu parça veya süreç istenilen özellikleri karşılamada nasıl bir hata ile karşılaşabilir.
4. Hata etkilerinin tespit edilmesi. Müşteri bir sonraki operasyon ise, operasyon performansı yönünden sonuçlar; uymama, kurulamama, birleştirilememe, takılamama, karşılamama; kurulum ekipmanlarını veya diğer parçaları  hasara uğratma ihtimali yönünden belirlenmeye çalışılır. Ayrıca düşük performans, çalışmama, kötü görünüm, kesintili çalışma yönünden hatanın sonuçların müşteriler tarafından değerlendirilmelidir.
5. Hataların olası sebeplerinin tespiti. Her süreç için hata türüne neden olabilecek sebepler sıralanarak, düzeltilebilir veya kontrol edilebilir süreç parametreleri cinsinden tanımlanmalıdır.
6. Kontrol önlemlerinin tanımlanması. Bunlar çıkması muhtemel hatayı belirleyen veya hata türünün ortaya çıkmasını önleyen işlemlerdir. Bu kontroller genellikle testler ve ana kontrol şeklinde yapılabilir. Süreç kontrolü öncelikle hatanın oluşmasını önlemeyi, hata sebebini bularak düzeltici faaliyeti başlatmayı ve hata türünü ortaya koymayı planlamaktadır.
4. Servis FMEA
Servis FMEA organizasyondaki aksaklıkların analiz edilmesinde yardımcı olur. Bu analizin uygulanmasıyla; organizasyon faaliyetleri arasında önceliklendirme yapılması ve değişiklik için açıklamaların kaydedilmesi sağlanır. İş akışının, sistem ve proses analizinin etkin bir şekilde yapılmasında, işteki hataların ve kritik önemli işlerin belirlenmesinde ve kontrol planlarının oluşturulmasında yol göstermesi gibi avantajlar sağlar. Yapılacak olan bir FMEA tekniği uygulaması aşağıda özetlenmiş olan fonksiyonların gerçekleştirilmesini sağlar;
  • Süreç  ya da hizmette hataların oluşturacağı en küçük bir zararın bile oluşumunun engellenmesini sağlamak için hata türlerini sistematik olarak gözden geçirir.
  • Süreç  ya da hizmeti ya da bunların fonksiyonelliğini etkileyebilecek her türlü hatayı ve bu hatanın etkilerini tanımlar.
  • Tanımlanan bu hatalardan hangilerinin süreç  ya da hizmet operasyonlarında daha kritik etkilerinin olduğunu belirler, bu yüzden meydana gelebilecek en büyük hasarı ve hangi hata türünün bu hasarı üretebileceğini tanımlar.
  • Kurulum ve kurulum, öncesinde, Süreçte  hataların oluşum olasılığını ve bunun nereden kaynaklanabileceğini (dizayn, operasyon, vb.) belirler.
  • Diğer kaynaklardan elde edilmesi mümkün olmayan hata oranlarını ve türlerini tanımlayarak gerekli Test  programlarının kurulmasını sağlar.
  • Güvenilirliğin deneysel olarak test edilebilmesi için gerekli test  programlarının kurulmasını sağlar.
  • Bir ürün için değişikliklerin olabilecek etkilerini tanımlar.
  • Yüksek riskli bileşenlerin nasıl güvenilir hale getirilebileceğini tanımlar.
  • Kurulum  hatalarının olabilecek kötü etkisinin nasıl giderilebileceğini tanımlar.
Müşteriye servis henüz ulaşmadan analiz edilmesinde yardımcı olur. Bu analizin uygulanmasıyla; geliştirme faaliyetleri arasında önceliklendirme yapılması ve değişiklik için açıklamaların kaydedilmesi sağlanır. İş akışının, sistem ve süreç analizinin etkin bir şekilde yapılmasında, işteki hataların ve kritik önemli islerin belirlenmesinde ve kontrol planlarının oluşturulmasında yol göstermesi gibi avantajlar sağlar.
Yalçın ÖZÇELİK

Yorumlar

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Ama

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde ( 1 , 2 ) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki: “Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler , Sistem (Proje kapsamını belirtir) , Use Caseler ve bunlar ara