Jak zrobić Failure Mode and Effect Analysis FEA
Każde nasze działanie obarczone jest pewnym stopniem niepewności, stąd niesie ze sobą ryzyko. Wspomnieliśmy już, że ryzyko jest efektem niepewności, a efekt ten może być pozytywny (niektórzy nazywają go szansą) lub negatywny.
Istnieje kilka narzędzi do zarządzania ryzykiem, a jednym z nich jest analiza trybów i efektów awarii.
Dzisiaj porozmawiamy o koncepcji metody elementów skończonych, jej zaletach i wadach, jakie istnieją rodzaje metody elementów skończonych i jak jest ona wykonywana, w tym etapy, które się na nią składają. Oczywiście, dołączymy praktyczny przykład, który poprowadzi Cię przez Twoją własną analizę Failure Mode and Effect Analysis.
Zacznijmy!
- Co to jest analiza trybów i efektów awarii
- Wady i zalety analizy FEA
- Typy metody elementów skończonych
- System FEA (SFMEA)
- Design Failure Mode and Effects Analysis (DFMEA)
- Process FEA (PFMEA)
- Jak zrobić PFMEA
- Krok 1: Obiekt zastosowania i wcześniejsze informacje
- Krok 2: Zbierz zespół
- Krok 3: Opis elementów
- Krok 4: Określ tryby awarii
- Krok 5: Określenie skutków trybów awarii
- Krok 6: Ocena dotkliwości
- Krok 7: Określenie przyczyn
- Krok 8: Ocena częstości występowania
- Krok 9: Zidentyfikuj mechanizmy kontrolne
- Krok 10: Ocena stopnia wykrywalności kontroli
- Krok 11: Oblicz priorytetowy numer ryzyka (PRN)
- Krok 12: Podejmowanie działań
- Krok 13: Nowy NPR
- Przykładowy AMEF
- Kiedy przeprowadzić analizę AMEF
- Download format z przykładem FEA
Co to jest analiza trybów i efektów awarii
Znana również pod akronimem FMEA (Failure Mode and Effects Analysis), analiza trybów i efektów awarii jest definiowana jako procedura wykrywania zagrożeń z analizy potencjalnych awarii, pozwalająca na wdrożenie działań zapobiegających wystąpieniu awarii i poprawiających jakość.
A jeśli koncepcja nadal nie jest dla Ciebie jasna, spróbuj rozbić każde słowo:
- Analiza: Szczegółowy przegląd elementów procesu, produktu lub systemu.
- Tryb: Sposób, w jaki powstaje awaria.
- Skutek: Konsekwencja awarii: Błąd lub niedoskonałość, która generuje niepożądany wynik.
FEA odpowiada zatem na pytania: Jak system, produkt lub proces może ulec awarii? Co dzieje się dalej?
Wady i zalety analizy FEA
Jako jedna z wielu technik zarządzania ryzykiem i poprawy jakości, możemy ją rozróżnić ze względu na zalety i wady, które prezentuje w porównaniu z innymi.
Istnieje wiele korzyści i zalet analizy FEA, ale uważam, że wszystkie one mieszczą się w następujących 4:
- Zwiększa efektywność procesu: osiąga cel przy użyciu mniejszej ilości zasobów.
- Zmniejsza koszty utrzymania oraz koszty związane z błędami.
- Poprawia zadowolenie klientów poprzez zapobieganie otrzymywaniu przez nich wadliwych produktów lub usług lub takich, które nie spełniają ich wymagań.
- Utrzymuje wiedzę firmy, ponieważ jest to metoda udokumentowana.
Jak widać, są to dość istotne zalety. Stąd jest ona szeroko stosowana do wdrażania systemów zarządzania ciągłością działania (ISO 22301) czy systemów zarządzania jakością (ISO 9001), by wymienić tylko dwa.
Inni autorzy wskazują na wady metody elementów skończonych, choć ja wolę nazywać je ograniczeniami, niektóre z nich bardzo technicznymi. Hu-Chen w swojej książce podsumowuje wiele z nich, wspominając, że:
- Rankingi oparte na dotkliwości, występowaniu i czynnikach wykrywania są jednakowo ważone, co może prowadzić do tego, że tryb awaryjny, który, na przykład, ma wysoką dotkliwość ma niższy NPR, niezależnie od faktu, że powinien być priorytetem do wykonania działań naprawczych, biorąc pod uwagę dotkliwość awarii.
- Sukces analizy trybu i skutków awarii zależy od doświadczenia i wiedzy członków zespołu na temat analizowanego produktu, procesu lub systemu.
- NPR-y o tej samej wartości mogą być generowane pomimo różnych kombinacji ciężkości, występowania i wykrywania.
- Obliczanie matematyczne NPR-ów jest wrażliwe na zmienność ciężkości, występowania i wykrywania.
- NPR jest ograniczona do ryzyka związanego z bezpieczeństwem i nie uwzględnia innych czynników ryzyka, takich jak czynniki ekonomiczne.
Typy metody elementów skończonych
Zależnie od podejścia do zastosowania analizy modalnej i skutków awarii, istnieją różne rodzaje metody elementów skończonych. Wspomnieliśmy już, że metodologia FEA może być stosowana do procesu, produktu lub systemu.
System FEA (SFMEA)
Software Failure Mode and Effect Analysis. S na początku akronimu jest wymowne. Jest to analiza mająca na celu zapobieganie ewentualnym niepowodzeniom w rozwoju oprogramowania poprzez zapewnienie, że różne komponenty (funkcje, interfejs użytkownika, konserwacja, itp.) są kompatybilne i działają zgodnie z oczekiwaniami.
Design Failure Mode and Effects Analysis (DFMEA)
Design Failure Mode and Effects Analysis. Ja wolę nazywać to FEA produktu. Analiza ma na celu identyfikację ryzyka w nowym projekcie lub modyfikacji produktu lub usługi.
Process FEA (PFMEA)
Process Failure Mode and Effects Analysis. Analizuje każdy etap procesu w celu identyfikacji ryzyka i awarii z różnych źródeł, najbardziej powszechnych, słynnych M (Manpower, materials, machinery, measurement, environment), które już omówiliśmy w Ingenio Empresa tutaj.
Jak zrobić PFMEA
Nie ma zdefiniowanych etapów robienia PFMEA lub określonej liczby kroków. Metodologia różni się w zależności od autora, ale wszystkie są oparte na tym samym i prowadzą do tego samego.
Przedyskutujemy przykładową metodę elementów skończonych w procesie produkcji książki.
Krok 1: Obiekt zastosowania i wcześniejsze informacje
Nie możemy ingerować w system, proces lub produkt bez wcześniejszych informacji, np. diagramów, specyfikacji, rysunków projektowych itp. W tym kroku musimy mieć mapowanie czynności, które są wykonywane w przypadku procesu lub produktu, lub części w przypadku systemu. Ilość informacji różni się w zależności od złożoności przedmiotu zastosowania i etapu, na którym się znajduje.
Na przykład, więcej informacji może być potrzebnych w produkcji nowego modelu pralki niż modyfikacji istniejącego, już stworzonego i wprowadzonego na rynek.
Inny przykład: W już ustanowionym procesie, konieczne będzie mapowanie lub diagramowanie działań, które go tworzą. Już zaimplementowane narzędzia, takie jak flowchart, SIPOC lub kursogram będą bardzo przydatne na początek.
Uwaga: Przez obiekt zastosowania rozumiem system, produkt lub proces, do którego stosuje się metodę elementów skończonych.
Kontynuując nasz przykład procesu produkcji książek:
Krok 2: Zbierz zespół
Nie możemy wykonać analizy FEA bez zespołu, który posiada wiedzę o obiekcie zastosowania.
Nie jest konieczne, aby cały zespół posiadał wiedzę na temat MEA, jeśli jest lider zespołu, co jest zalecane. Lider ten będzie osobą prowadzącą spotkania i dokumentującą analizę, dlatego jego wiedza z zakresu metodyki powinna być dogłębna.
Może zaistnieć konieczność, aby zespół miał różne profile w zależności od etapu przedmiotu aplikacji i doświadczenia z nim. Na przykład pracownicy operacyjni przy wytwarzaniu produktu mlecznego i pracownicy logistyczni przy jego transporcie. Posiadanie pracowników, którzy mają kontakt z klientem może być również przydatne, w zależności od przypadku.
Krok 3: Opis elementów
Opis elementów do analizy może być różny w zależności od tego, z jakiej perspektywy korzystamy. Chociaż, moim zaleceniem jest użycie wszystkich z nich.
- W perspektywie komponentu weźmiemy każdy z komponentów (redundancja) maszyny do naszej analizy FEA.
- W perspektywie czynnika awarii postaramy się wykryć awarie zgodnie z ich klasyfikacją. Na przykład te, które mają wpływ na zdrowie klienta lub pracownika, zostałyby sklasyfikowane jako awarie związane z czynnikiem zdrowia.
- W perspektywie sekwencji działań, używamy mapowania działań, aby zidentyfikować potencjalną awarię w identyfikowalności produktu lub usługi.
Opisywanie przedmiotów odbywa się zazwyczaj za pomocą sekwencji. Zalecane jest również wykorzystanie innych perspektyw. Na przykład, podczas analizy tokarki, używając perspektywy sekwencji działań, można przeoczyć potencjalne awarie związane z jej komponentami.
Dla naszego przykładu, użyjemy sekwencji działań:
Krok 4: Określ tryby awarii
W tego typu analizie, to co otrzymujemy jako pierwsze, to tryby awarii, które już wystąpiły. Jeśli nie są one jeszcze udokumentowane, muszą być udokumentowane.
Kolejnym krokiem jest, z różnych perspektyw kroku 3, identyfikacja potencjalnych trybów awarii. Przez tryby niepowodzenia rozumiem sposoby, w jakie produkt, proces lub usługa nie spełniają wymagań.
Na przykład:
- Niepowodzeniem z perspektywy procesu może być: Skala poza dostosowaniem do wagi materiału.
- Awaria z perspektywy produktu może być: Poplamione krzesło na prawej nodze.
- Usterka z perspektywy systemu to: Awaria oprogramowania spowodowana nadmiernymi żądaniami.
- Usterka z perspektywy systemu to: Awaria oprogramowania spowodowana nadmiernymi żądaniami.
Modele awarii w przykładowym procesie:
Krok 5: Określenie skutków trybów awarii
Dla każdego ze zidentyfikowanych trybów awarii (potencjalnych i już zaistniałych) musimy określić skutki, jakie generuje. Przez skutki rozumiem konsekwencję dla klienta lub procesów niższego rzędu.
Na przykład:
- Potencjalna awaria: Skala bez korekty dla wagi materiału.
- Potencjalny efekt: Waga materiału nie jest zgodna z ustaleniami z klientem.
Ważne jest, aby podczas określania skutków skoncentrować się na skutkach natychmiastowych, a nie na tych niższego rzędu lub katastrofalnych. Niewłaściwe wyważenie może prowadzić do niezadowolenia klienta, jeśli materiał dotrze do jego domu, ale nie jest to bezpośredni efekt. Bezpośrednim skutkiem jest to, że materiał nie będzie ważył zgodnie z ustaleniami z klientem.
Krok 6: Ocena dotkliwości
Znana również jako dotkliwość, dotkliwość jest zwykle oceniana w skali od 1 do 10, gdzie 1 jest nieistotne, a 10 jest katastrofalne.
Przypisując ocenę można kierować się następującą tabelą dotkliwości:
Możliwe jest, aby tryb awaryjny miał więcej niż jeden skutek, dlatego należy brać pod uwagę skutek, który generuje największą dotkliwość.
Dla naszego przykładu:
Krok 7: Określenie przyczyn
Dla każdego trybu awarii musimy określić przyczyny, które go generują. Narzędzia analizy przyczyn, takie jak Diagram Ishikawy, Pareto lub 5 Why będą bardzo przydatne.
Ten krok jest bardzo ważny, ponieważ poprzez znalezienie przyczyny potencjalnych zagrożeń, działanie będzie miało większe szanse na wygenerowanie dobrych wyników.
Przyczyny w omawianym przykładzie FEA:
Krok 8: Ocena częstości występowania
Teraz określamy częstość występowania lub częstotliwość, która jest po prostu szacowanym prawdopodobieństwem wystąpienia awarii dla zauważonej przyczyny. Podobnie jak dotkliwość, występowanie jest zwykle oceniane w skali od 1 do 10, gdzie 1 jest bardzo mało prawdopodobne, a 10 jest nieuniknione.
Przewodnikiem po klasyfikacji zdarzeń jest:
Zdarzenie sprowadzone do przykładu, który omawiamy:
Krok 9: Zidentyfikuj mechanizmy kontrolne
Ze wskazanych już przyczyn identyfikujemy teraz mechanizmy kontrolne. Przez kontrole rozumiem procedury, działania, mechanizmy lub testy obecnie stosowane w celu zapobiegania powstawaniu awarii i docieraniu do klienta lub procesów klienta.
Kontrole mogą mieć na celu 1) wykrycie awarii po jej wystąpieniu, ale zanim dotrze do klienta, 2) zapobieganie powstawaniu przyczyny lub 3) zmniejszenie prawdopodobieństwa wystąpienia przyczyny.
Dla naszego przykładu:
Krok 10: Ocena stopnia wykrywalności kontroli
Teraz przypisujemy stopień wykrywalności do każdej kontroli, tj. zamierzamy oszacować, jak dobrze zidentyfikowane kontrole mogą wykryć przyczynę lub jej tryb awarii po jej wygenerowaniu, ale zanim dotrze ona do klienta. Jest ona również oceniana w skali od 1 do 10, gdzie 1 oznacza kontrolę, w przypadku której istnieje pewność, że awaria zostanie wykryta, a 10 oznacza kontrolę, w przypadku której istnieje pewność, że awaria NIE zostanie wykryta.
Na obrazku:
Na poniższym obrazku załączam stopień wykrywalności kontroli:
Krok 11: Oblicz priorytetowy numer ryzyka (PRN)
Priorytetowy numer ryzyka uzyskuje się przez pomnożenie stopnia dotkliwości, występowania i wykrywalności.
NPR = stopień dotkliwości * stopień występowania * stopień wykrywalności
Numer Priorytetu Ryzyka jest obliczany w celu nadania priorytetu trybom awarii i ich przyczynom. Jeśli spojrzysz na nasz przykład, tryby awarii o najwyższym NPR to błąd maszynopisania i zacięcie papieru.
Krok 12: Podejmowanie działań
Ostatni krok polega na podejmowaniu działań. Działania te mogą mieć na celu zmianę projektu lub procesu w celu zmniejszenia dotkliwości lub częstości występowania. Mogą to być również dodatkowe kontrole mające na celu zwiększenie stopnia wykrywalności. Innymi słowy, działania mogą koncentrować się na niepowodzeniach, przyczynach lub kontrolach.
Skuteczność działań zależy w dużej mierze od ich planowania. W tym miejscu przydają się narzędzia takie jak 5W + 2H. Jako minimum powinniśmy określić:
- Co należy zrobić
- Odpowiedzialne strony
- Czas
- Wymagane zasoby
- Miejsca
Nie jest jednak konieczne wyszczególnianie tego wszystkiego w dokumencie FEA. Wystarczy podać, co należy zrobić.
Krok 13: Nowy NPR
Za każdym razem, gdy działanie jest wdrażane, warto obliczyć nowy NPR, aby określić, czy działanie było skuteczne. Mówimy, że działanie jest skuteczne, gdy osiągnięty zostaje rezultat, dla którego zostało podjęte. Dlatego też, jeśli NPR jest zredukowany, działanie jest skuteczne.
Przykładowy AMEF
Po wykonaniu tych wszystkich czynności proces tworzenia książki, którego używamy jako przykładu analizy trybów i skutków awarii, wygląda następująco:
Kiedy przeprowadzić analizę AMEF
Analiza trybów i skutków awarii wymaga jedynie chęci. Jest to analiza, która jest dynamicznie aktualizowana w miejscu jej zastosowania, więc nie ma określonego czasu na wykonanie metody elementów skończonych.
Jednakże istnieją scenariusze, w których wygodnie jest korzystać z tego narzędzia, na przykład:
- Wdrażanie systemów zarządzania, które wymagają analizy ryzyka.
- Przez wymagania klientów, na przykład, gdy potrzebują oni zagwarantowania ciągłości usługi.
- Projektowanie nowych produktów, usług, procesów lub oprogramowania.
- Powtarzające się błędy w procesie produkcji lub dostarczania usług.
- Programy utrzymania ruchu.
- Dokumentacja procesu.
Download format z przykładem FEA
Kliknij tutaj, aby pobrać format skonstruowany do wykonania przykładu Failure Mode and Effect Analysis
Źródło:
Liu, Hu-Chen. (2016). FMEA: Wykorzystanie teorii niepewności i metod MCDM. Springer SIngapore, ed 1.
Neufelder, A. M. (2010). Software Failure Modes Effects Analysis Overview. Retrieved July 25, 2020, from http://www.softrel.com/fmea%20overview.pdf
Bellovi, M. (2004). NTP 679: Analiza modów i skutków awarii. FMEA. Retrieved July 25, 2020, from https://www.insst.es/documents/94886/326775/ntp_679.pdf/3f2a81e3-531c-4daa-bfc2-2abd3aaba4ba
Zuñiga Rodríguez, A. (January 31, 2018). Failure Mode Analysis and its Effects FMEA: podejście do poprawy priorytetyzacji trybów awarii. Retrieved July 25, 2020, from http://planetrams.iusiani.ulpgc.es/?p=2940&lang=en
.