Hur man gör en FEA (Failure Mode and Effect Analysis)
Varje åtgärd som vi vidtar är behäftad med en viss grad av osäkerhet, vilket innebär att den medför en risk. Vi har redan nämnt att risk är effekten av osäkerhet och att den effekten antingen kan vara positiv (vissa kallar det möjlighet) eller negativ.
Det finns flera verktyg för riskhantering och ett av dem är analys av felfunktioner och effekter.
I dag kommer vi att prata om begreppet FEA, dess för- och nackdelar, vilka typer av FEA det finns och hur den utförs, inklusive de olika stegen som ingår i den. Naturligtvis kommer vi att inkludera ett praktiskt exempel som sedan kommer att vägleda dig genom din egen analys av feltillstånd och effekter.
Vi sätter igång!
- Vad är analys av felfunktioner och effekter
- FEA-analysens för- och nackdelar
- Typer av FEA
- System FEA (SFMEA)
- Design Failure Mode and Effects Analysis (DFMEA)
- Process FEA (PFMEA)
- Hur man gör en PFMEA
- Steg 1: Applikationsobjekt och tidigare information
- Steg 2: Sätt ihop teamet
- Steg 3: Beskrivning av objekt
- Steg 4: Bestäm felsituationer
- Steg 5: Bestäm effekterna av felmods
- Steg 6: Bedömning av allvarlighetsgrad
- Steg 7: Fastställande av orsaker
- Steg 8: Förekomstklassificering
- Steg 9: Identifiera kontroller
- Steg 10: Bedömning av kontrollens detektionsgrad
- Steg 11: Beräkna det prioriterade risktalet (PRN)
- Steg 12: Vidta åtgärder
- Steg 13: Den nya NPR
- Exempel på AMEF
- När man ska utföra en AMEF-analys
- Download format med exempel på FEA
Vad är analys av felfunktioner och effekter
Också känd under sin akronym FMEA (Failure Mode and Effects Analysis), definieras analys av felfunktioner och effekter som ett förfarande för att upptäcka risker från analysen av potentiella fel, vilket gör det möjligt att genomföra åtgärder för att förhindra att fel inträffar och för att förbättra kvaliteten.
Och om begreppet fortfarande inte är klart för dig kan du försöka bryta ner varje ord:
- Analys: En detaljerad genomgång av elementen i en process, en produkt eller ett system.
- Mode: Det sätt på vilket felet uppstår.
- Effekt: Konsekvensen av felet.
- Failure: Fel eller brister som ger ett oönskat resultat.
FEA svarar därför på frågorna: Hur kan systemet, produkten eller processen misslyckas? Vad händer härnäst?
FEA-analysens för- och nackdelar
Som en av många tekniker för riskhantering och kvalitetsförbättring kan vi särskilja den genom att se vilka för- och nackdelar den har jämfört med andra.
Det finns många fördelar med FEA-analys, men jag tror att de alla passar in i följande 4:
- Ökar processens effektivitet: Målet uppnås med färre resurser.
- Reducerar underhållskostnader och kostnader i samband med fel.
- Förbättrar kundernas tillfredsställelse genom att förhindra att de får defekta produkter eller tjänster eller sådana som inte uppfyller deras krav.
- Behåller företagets kunskap eftersom det är en dokumenterad metod.
Som du kan se är detta ganska viktiga fördelar. Därför används den ofta för att genomföra system för hantering av affärskontinuitet (ISO 22301) eller kvalitetsledningssystem (ISO 9001), för att bara nämna två.
Andra författare har pekat på nackdelar med FEA, även om jag föredrar att kalla dem begränsningar, varav en del är mycket tekniska. Hu-Chen sammanfattar många av dem i sin bok genom att nämna att:
- Rankningar baserade på allvarlighets-, förekomst- och upptäcktsfaktorer är lika viktade, vilket kan leda till att en felsituation som t.ex. har hög allvarlighetsgrad har en lägre NPR, oberoende av att det borde vara en prioritet att utföra korrigerande åtgärder med tanke på felets allvarlighetsgrad.
- För att lyckas med analysen av feltillstånd och effekter krävs att medlemmarna har erfarenhet och kunskap om den produkt, process eller det system som analyseras.
- NPR med samma värde kan genereras trots olika kombinationer av allvarlighetsgrad, förekomst och upptäckt.
- Den matematiska beräkningen av NPR är känslig för variationer i allvarlighetsgrad, förekomst och upptäckt.
- NPR är begränsad till risker som är förknippade med säkerhet och tar inte hänsyn till andra riskfaktorer, t.ex. ekonomiska.
Typer av FEA
Avhängigt av hur man tillämpar Failure Modal and Effects Analysis finns det olika typer av FEA. Vi har redan nämnt att FEA-metodiken kan tillämpas på en process, en produkt eller ett system.
System FEA (SFMEA)
Software Failure Mode and Effect Analysis. S:et i början av akronymen är talande. Det är en analys som syftar till att förebygga eventuella fel i programvaruutvecklingen genom att säkerställa att de olika komponenterna (funktioner, användargränssnitt, underhåll etc.) är kompatibla och fungerar som förväntat.
Design Failure Mode and Effects Analysis (DFMEA)
Design Failure Mode and Effects Analysis. Jag föredrar att kalla det produkt-FEA. Analysen syftar till att identifiera risker i en ny konstruktion eller ändring av en produkt eller tjänst.
Process FEA (PFMEA)
Process Failure Mode and Effects Analysis. Den undersöker varje steg i en process för att identifiera risker och fel från olika källor, de vanligaste är de berömda M:na (Manpower, materials, machinery, measurement, environment) som vi redan har diskuterat i Ingenio Empresa här.
Hur man gör en PFMEA
Det finns inga definierade steg för att göra en PFMEA eller ett specifikt antal steg. Metodiken varierar från författare till författare, men alla bygger på samma sak och leder till samma sak.
Vi kommer att diskutera ett exempel på FEA genom en boktillverkningsprocess.
Steg 1: Applikationsobjekt och tidigare information
Vi kan inte ingripa i ett system, en process eller en produkt utan att ha tillgång till tidigare information, t.ex. diagram, specifikationer, konstruktionsritningar osv. I detta steg måste vi ha en kartläggning av de aktiviteter som utförs när det gäller en process eller produkt, eller av delarna när det gäller ett system. Mängden information varierar beroende på hur komplicerat tillämpningsobjektet är och i vilket skede det befinner sig.
Till exempel kan det behövas mer information för att tillverka en ny modell av tvättmaskin än för att modifiera en befintlig modell som redan har skapats och marknadsförts.
Ett annat exempel: I en redan etablerad process kommer det att vara nödvändigt att kartlägga eller schematisera de aktiviteter som ingår i den. Redan implementerade verktyg som flödesschema, SIPOC eller cursogram är mycket användbara till att börja med.
Anmärkning: Med tillämpningsobjekt menar jag det system, den produkt eller den process som en FEA tillämpas på.
Fortsätt med vårt exempel på boktillverkningsprocessen:
Steg 2: Sätt ihop teamet
Vi kan inte utföra en FEA-analys utan att teamet har kunskap om tillämpningsobjektet.
Det är inte nödvändigt att hela teamet har kunskap om MEA om det finns en teamledare, vilket rekommenderas. Denna ledare kommer att vara den person som leder mötena och dokumenterar analysen, så hans eller hennes kunskaper om metodiken bör vara djupgående.
Det kan vara nödvändigt för teamet att ha olika profiler beroende på vilket stadium tillämpningsobjektet befinner sig i och vilken erfarenhet man har av det. Till exempel driftspersonal för tillverkning av en mejeriprodukt och logistikpersonal för dess transport. Att ha personal som har kontakt med kunden kan också vara användbart, beroende på fallet.
Steg 3: Beskrivning av objekt
Beskrivningen av de objekt som ska analyseras kan vara olika beroende på vilket perspektiv vi använder. Min rekommendation är dock att använda dem alla.
- I komponentperspektivet kommer vi att använda var och en av maskinens komponenter (redundans) för vår FEA-analys.
- I felfaktorperspektivet kommer vi att försöka upptäcka felen enligt deras klassificering. Exempelvis skulle de som påverkar kundens eller arbetstagarens hälsa klassificeras som fel som är kopplade till hälsofaktorn.
- I perspektivet med aktivitetssekvenser använder vi aktivitetskartläggning för att identifiera det potentiella felet i produktens eller tjänstens spårbarhet.
Beskrivningen av objekt görs vanligtvis med hjälp av sekvensen. Det rekommenderas också att använda andra perspektiv. När man till exempel analyserar svarven kan man med hjälp av ett perspektiv med en sekvens av aktiviteter missa potentiella fel som är kopplade till dess komponenter.
För vårt exempel använder vi sekvensen av aktiviteter:
Steg 4: Bestäm felsituationer
I den här typen av analys får man först fram de felsituationer som redan har inträffat. Om de inte redan är dokumenterade måste de dokumenteras.
Nästa steg är att utifrån de olika perspektiven i steg 3 identifiera potentiella felsteg. Med felmodeller menar jag de sätt på vilka en produkt, process eller tjänst misslyckas med att uppfylla kraven.
Till exempel:
- Ett fel ur ett processperspektiv kan vara: Skalan är inte justerad för materialvikt.
- Ett misslyckande ur ett produktperspektiv kan vara: Fläckig stol på höger ben.
- Fel från ett systemperspektiv är: Programvaran kraschar på grund av för många förfrågningar.
- Fel från ett systemperspektiv är: Programvaran kraschar på grund av för många förfrågningar.
Felmods i exempelprocessen:
Steg 5: Bestäm effekterna av felmods
För vart och ett av de identifierade felmods (potentiella och redan inträffade) måste vi bestämma vilka effekter det genererar. Med effekter menar jag konsekvenserna för kunden eller processer i efterföljande led.
Till exempel:
- Potentiellt fel: Skalan är inte justerad för materialvikt.
- Potentiell effekt: Materialvikten är inte den som överenskommits med kunden.
Det är viktigt att när vi fastställer effekterna koncentrerar vi oss på de omedelbara effekterna och inte på de nedströms eller katastrofala effekterna. En feljusterad balans kan leda till missnöje hos kunden om materialet anländer till kundens hem, men det är inte den omedelbara effekten. Den omedelbara effekten är att materialet inte kommer att väga som överenskommet med kunden.
Steg 6: Bedömning av allvarlighetsgrad
Också känd som allvarlighetsgrad, brukar allvarlighetsgraden bedömas på en skala från 1 till 10, där 1 är försumbart och 10 är katastrofalt.
Följande tabell över allvarlighetsgrad kan vägleda dig när du tilldelar ett betyg:
Det är möjligt att ett feltillstånd kan ha mer än en effekt, så ta hänsyn till den effekt som ger upphov till den största allvarlighetsgraden.
För vårt exempel:
Steg 7: Fastställande av orsaker
För varje felsituation måste vi fastställa de orsaker som genererar den. Verktyg för orsaksanalys som Ishikawa-diagram, Pareto eller 5 Why är mycket användbara.
Detta steg är mycket viktigt eftersom det är mer sannolikt att aktiviteten kommer att generera goda resultat om man hittar orsaken till potentiella risker.
Orsakerna i FEA-exemplet som vi har diskuterat:
Steg 8: Förekomstklassificering
Nu bestämmer vi förekomst- eller frekvensfrekvensen, som helt enkelt är den uppskattade sannolikheten för att ett fel ska inträffa för den noterade orsaken. Liksom allvarlighetsgraden rangordnas förekomsten vanligtvis på en skala från 1 till 10, där 1 är mycket osannolikt och 10 är oundvikligt.
En vägledning för klassificering av förekomst är:
Förekomsten fördes till det exempel vi diskuterar:
Steg 9: Identifiera kontroller
Från de orsaker som redan har noterats, identifierar vi nu kontroller. Med kontroller menar jag de förfaranden, åtgärder, mekanismer eller tester som för närvarande används för att förhindra att fel genereras och når kunden eller kundprocesser.
Kontroller kan syfta till att 1) upptäcka felet efter att det har inträffat men innan det når kunden, 2) förhindra att orsaken genereras, eller 3) minska sannolikheten för att orsaken inträffar.
För vårt exempel:
Steg 10: Bedömning av kontrollens detektionsgrad
Nu tilldelar vi varje kontroll en detektionsgrad, dvs. vi uppskattar hur väl de identifierade kontrollerna kan upptäcka en orsak eller en felfunktion efter att den har uppstått, men innan den når kunden. Den bedöms också på en skala från 1 till 10, där 1 är en kontroll där det är säkert att felet kommer att upptäckas och 10 är en kontroll där det är säkert att det INTE kommer att upptäckas.
I en bild:
I följande bild bifogar jag graden av upptäckt av kontrollerna:
Steg 11: Beräkna det prioriterade risktalet (PRN)
Det prioriterade risktalet erhålls genom att multiplicera allvarlighetsgraden, förekomsten och upptäckten.
NPR = Graden av allvarlighetsgrad * Graden av förekomst * Graden av upptäckt
Riskprioritetsnumret beräknas för att prioritera fel och deras orsaker. Om du tittar på vårt exempel är de fel som har högst NPR skrivfel och pappersstopp.
Steg 12: Vidta åtgärder
Det sista steget består av att vidta åtgärder. Dessa åtgärder kan syfta till att ändra konstruktionen eller processen för att minska allvaret eller förekomsten. De kan också vara ytterligare kontroller för att öka graden av upptäckt. Med andra ord kan åtgärderna fokusera på fel, orsaker eller kontroller.
Atgärdernas effektivitet beror till stor del på planeringen av dem. Det är här som verktyg som 5W + 2H kommer till nytta. Som ett minimum bör vi definiera:
- Vad ska göras
- Respektive ansvariga parter
- Tider
- Resurser som krävs
- Ställen
Det är dock inte nödvändigt att beskriva allt detta i detalj i FEA-dokumentet. Det räcker med att bara ange vad som ska göras.
Steg 13: Den nya NPR
Varje gång en åtgärd genomförs är det användbart att beräkna den nya NPR för att avgöra om åtgärden var effektiv. Vi säger att en åtgärd har varit effektiv när det resultat för vilket den inleddes har uppnåtts. Om NPR minskas är åtgärden därför effektiv.
Exempel på AMEF
Med allt detta gjort ser den boktillverkningsprocess som vi använder som exempel på analys av felsätt och effekter ut på följande sätt:
När man ska utföra en AMEF-analys
Felsätts- och effektanalysen kräver bara att man är villig att använda den. Det är en analys som uppdateras dynamiskt där den tillämpas, så det finns ingen specifik tidpunkt för att göra en FEA.
Det finns dock scenarier där det är lämpligt att använda detta verktyg, till exempel:
- Införande av ledningssystem som kräver riskanalys.
- På grund av kundernas krav, till exempel när de vill att kontinuiteten i en tjänst ska garanteras.
- Utformning av nya produkter, tjänster, processer eller programvara.
- Återkommande fel i en produktionsprocess eller tjänsteleverans.
- Underhållsprogram.
- Processdokumentation.
Download format med exempel på FEA
Klicka här för att ladda ner formatet som konstruerats för att utföra exemplet på Failure Mode and Effect Analysis
Källa:
Liu, Hu-Chen. (2016). FMEA: användning av teorier om osäkerhet och MCDM-metoder. Springer SIngapore, ed 1.
Neufelder, A. M. (2010). Översikt över analys av felmodes och effekter av programvara. Hämtad 25 juli 2020 från http://www.softrel.com/fmea%20overview.pdf
Bellovi, M. (2004). NTP 679: Analys av felmodes och effekter. FMEA. Hämtad 25 juli 2020 från https://www.insst.es/documents/94886/326775/ntp_679.pdf/3f2a81e3-531c-4daa-bfc2-2abd3aaba4ba
Zuñiga Rodríguez, A. (31 januari 2018). Failure Mode Analysis and its Effects FMEA: metoder för att förbättra prioriteringen av felsituationer. Hämtad den 25 juli 2020 från http://planetrams.iusiani.ulpgc.es/?p=2940&lang=en
.