Sådan laver du en FEA (Failure Mode and Effect Analysis)

Alle handlinger, vi foretager, er behæftet med en vis grad af usikkerhed, og de indebærer derfor en risiko. Vi har allerede nævnt, at risiko er virkningen af usikkerhed, og at denne virkning enten kan være positiv (nogle kalder det mulighed) eller negativ.

Der findes flere værktøjer til risikostyring, og et af dem er fejltilstands- og effektanalyse.

I dag vil vi tale om begrebet FEA, dets fordele og ulemper, hvilke typer FEA der findes, og hvordan den udføres, herunder de faser, der indgår i den. Vi vil naturligvis inkludere et praktisk eksempel, som vil guide dig gennem din egen fejltilstands og effektanalyse.

Du er måske interesseret i: Fejltilstands og effektanalyse FEA: Udvikling af FEA trin for trin

Lad os komme i gang!

Hvad er fejltilstands- og effektanalyse

Som også er kendt under akronymet FMEA (Failure Mode and Effects Analysis), defineres fejltilstands- og effektanalyse som en procedure til påvisning af risici fra analysen af potentielle fejl, hvilket gør det muligt at gennemføre foranstaltninger for at forhindre fejl i at opstå og forbedre kvaliteten.

Og hvis begrebet stadig ikke er klart for dig, så prøv at bryde hvert ord ned:

  • Analyse: En detaljeret gennemgang af elementerne i en proces, et produkt eller et system.
  • Mode: Den måde, hvorpå fejlen opstår.
  • Effekt: Konsekvensen af fejlen.
  • Fejl: Fejl eller ufuldkommenhed, der genererer et uønsket resultat.

FEA besvarer derfor spørgsmålene: Hvordan kan systemet, produktet eller processen fejle? Hvad sker der så?

For- og ulemper ved FEA-analyse

Som en af mange teknikker til risikostyring og kvalitetsforbedring kan vi skelne den ud fra de fordele og ulemper, den har i forhold til andre teknikker.

Der er mange fordele ved FEA-analyse, men jeg mener, at de alle passer ind i følgende 4:

  • Forbedrer processens effektivitet: Målet nås med færre ressourcer.
  • Reducerer vedligeholdelsesomkostningerne og omkostningerne i forbindelse med fejl.
  • Gør kunderne mere tilfredse ved at forhindre dem i at modtage defekte produkter eller tjenester eller produkter, der ikke opfylder deres krav.
  • Holder virksomhedens viden, da det er en dokumenteret metode.

Som du kan se, er det ganske vigtige fordele. Derfor anvendes den i vid udstrækning til implementering af systemer til styring af forretningskontinuitet (ISO 22301) eller kvalitetsstyringssystemer (ISO 9001), for blot at nævne to.

Andre forfattere har påpeget ulemper ved FEA, selv om jeg foretrækker at kalde dem begrænsninger, hvoraf nogle er meget tekniske. Hu-Chen opsummerer i sin bog mange af dem ved at nævne, at:

  • Rangeringer baseret på alvorlighed, forekomst og detektionsfaktorer vægtes lige højt, hvilket kan føre til, at en fejltilstand, der f.eks. har en høj alvorlighed, har en lavere NPR, uanset at det burde være en prioritet at udføre korrigerende handlinger i betragtning af fejlens alvorlighed.
  • Succesen af fejlmodus- og effektanalysen afhænger af medlemmernes erfaring og viden om det produkt, den proces eller det system, der analyseres.
  • NPR’er med samme værdi kan genereres på trods af forskellige kombinationer af alvorlighed, forekomst og påvisning.
  • Den matematiske beregning af NPR’er er følsom over for variationer i alvorlighed, forekomst og påvisning.
  • NPR er begrænset til risici i forbindelse med sikkerhed og tager ikke højde for andre risikofaktorer såsom økonomiske faktorer.

Typer af FEA

Afhængigt af anvendelsesmetoden for Failure Modal and Effects Analysis findes der forskellige typer FEA. Vi har allerede nævnt, at FEA-metodologien kan anvendes på en proces, et produkt eller et system.

System FEA (SFMEA)

Software Failure Mode and Effect Analysis. S’et i begyndelsen af akronymet er sigende. Det er en analyse, der har til formål at forebygge mulige fejl i softwareudviklingen ved at sikre, at de forskellige komponenter (funktioner, brugergrænseflade, vedligeholdelse osv.) er kompatible og fungerer som forventet.

Design FEA (DFMEA)

Design Failure Mode and Effects Analysis. Jeg foretrækker at kalde det produkt-FEA. Analysen har til formål at identificere risici i forbindelse med et nyt design eller en ændring af et produkt eller en tjeneste.

Process FEA (PFMEA)

Process Failure Mode and Effects Analysis. Den undersøger hvert trin i en proces for at identificere risici og fejl fra forskellige kilder, de mest almindelige, de berømte M’er (Manpower, materialer, maskiner, måling, miljø), som vi allerede har talt om i Ingenio Empresa her.

Hvordan man laver en PFMEA

Der er ingen definerede trin for at lave en PFMEA eller et specifikt antal trin. Metodologien varierer fra forfatter til forfatter, men de er alle baseret på det samme og fører til det samme.

Vi vil diskutere et eksempel på FEA gennem en bogfremstillingsproces.

Trin 1: Applikationsobjekt og forudgående oplysninger

Vi kan ikke gribe ind i et system, en proces eller et produkt uden forudgående oplysninger, f.eks. diagrammer, specifikationer, konstruktionstegninger osv. I dette trin skal vi have en kortlægning af de aktiviteter, der udføres i tilfælde af en proces eller et produkt, eller af delene i tilfælde af et system. Mængden af oplysninger varierer alt efter kompleksiteten af anvendelsesobjektet og det stadium, det befinder sig i.

For eksempel kan der være behov for flere oplysninger ved fremstilling af en ny vaskemaskine end ved ændring af en eksisterende vaskemaskine, der allerede er udviklet og markedsført.

Et andet eksempel: I en allerede etableret proces vil det være nødvendigt at have kortlagt eller diagrammeret de aktiviteter, der indgår i den. Allerede implementerede værktøjer som flowchart, SIPOC eller flowchart vil være meget nyttige at starte med.

Note: Med anvendelsesobjekt mener jeg det system, produkt eller den proces, som en FEA anvendes på.

Fortsætter med vores eksempel på bogfremstillingsprocessen:

Eksempel på synoptisk flowdiagram
Synoptisk flowdiagram

Stræk 2: Sammensæt teamet

Vi kan ikke udføre en FEA-analyse uden et team, der har kendskab til anvendelsesobjektet.

Det er ikke nødvendigt, at hele teamet har kendskab til MEA, hvis der er en teamleder, hvilket anbefales. Denne leder vil være den person, der styrer møderne og dokumenterer analysen, så hans eller hendes viden om metodologien bør være dybtgående.

Det kan være nødvendigt for teamet at have forskellige profiler afhængigt af anvendelsesobjektets stade og erfaringen med det. F.eks. driftspersonale til fremstilling af et mejeriprodukt og logistikpersonale til transport af det. Det kan også være nyttigt at have medarbejdere, der har kontakt med kunden, afhængigt af sagen.

Strin 3: Beskrivelse af emnerne

Beskrivelsen af de emner, der skal analyseres, kan være forskellig, afhængigt af hvilket perspektiv vi bruger. Selv om min anbefaling er at bruge dem alle.

  • I komponentperspektivet vil vi tage hver enkelt af maskinens komponenter (redundans) med i vores FEA-analyse.
  • I fejlfaktorperspektivet vil vi forsøge at opdage fejlene i henhold til deres klassifikation. F.eks. vil fejl, der påvirker kundens eller arbejdstagerens sundhed, blive klassificeret som fejl i forbindelse med sundhedsfaktoren.
  • I aktivitetssekvensperspektivet bruger vi aktivitetskortlægning til at identificere den potentielle fejl i produktets eller tjenesteydelsens sporbarhed.
Hvis vi f.eks. taler om en drejebænk, kan vi bruge et komponent- eller fejlfaktorperspektiv. I komponentdelen vil vi analysere sengen, bagskinnen eller værktøjsholderen, som er de elementer, der udgør en drejebænk. I fejlfaktor vil vi analysere, hvordan fejl i forbindelse med arbejdstagernes sundhed eller produktkvalitet kan opstå ved brug af drejebænken.

Beskrivelsen af emner sker normalt ved hjælp af sekvensen. Det anbefales også at anvende andre perspektiver. Når man f.eks. analyserer drejebænken, kan man ved at bruge et perspektiv med en rækkefølge af aktiviteter overse potentielle fejl i forbindelse med dens komponenter.

I vores eksempel vil vi bruge rækkefølgen af aktiviteter:

Liste over aktiviteter i fremstillingsprocessen

Stræk 4: Bestem fejltilstande

I denne type analyse får man først de fejltilstande, der allerede er opstået. Hvis de ikke allerede er dokumenteret, skal de dokumenteres.

Det næste trin er, ud fra de forskellige perspektiver fra trin 3, at identificere potentielle fejltilstande. Med fejltilstande mener jeg de måder, hvorpå et produkt, en proces eller en tjeneste ikke opfylder kravene.

For eksempel:

  • En fejl ud fra et procesperspektiv kan være: Vægten er ude af justering for materialevægt.
  • En fejl fra et produktperspektiv kan være: Plettet stol på højre ben.
  • En fejl fra et systemperspektiv er: Software går ned på grund af for mange anmodninger.
  • En fejl fra et systemperspektiv er: Software går ned på grund af for mange anmodninger.

Fejltilstande i eksempelprocessen:

Aktiviteter med fejltilstande Eksempel AMEF

Stræk 5: Bestem virkningerne af fejltilstande

For hver af de identificerede fejltilstande (potentielle og allerede opståede) skal vi bestemme de virkninger, som de genererer. Med virkninger mener jeg konsekvenserne for kunden eller processer i efterfølgende led.

For eksempel:

  • Potentiel fejl: Skala ud af justering for materialevægt.
  • Potentiel virkning: Materialevægt er ikke som aftalt med kunden.

Det er vigtigt, at vi ved bestemmelse af virkninger koncentrerer os om de umiddelbare virkninger og ikke om de efterfølgende eller katastrofale virkninger. En skæv balance kan føre til utilfredshed hos kunden, hvis materialet ankommer til kundens hjem, men det er ikke den umiddelbare virkning. Den umiddelbare virkning er, at materialet ikke vejer som aftalt med kunden.

Diagram med aktiviteter, fejl og virkninger Eksempel FEA

Strin 6: Sværhedsvurdering

Sværhedsgraden, også kendt som alvorlighed, vurderes normalt på en skala fra 1 til 10, hvor 1 er ubetydelig og 10 er katastrofal.

Den følgende tabel over sværhedsgrad kan vejlede dig ved tildeling af en klassifikation:

MEFA-sværhedsskala

Det er muligt for en fejltilstand at have mere end én effekt, så overvej den effekt, der genererer den største sværhedsgrad.

For vores eksempel:

Diagram med sværhedsgrad, fejltilstande og aktivitet FEA EKSEMPEL

Stræk 7: Bestemmelse af årsager

For hver fejltilstand skal vi bestemme de årsager, der genererer den. Årsagsanalyseværktøjer som Ishikawa-diagram, Pareto eller 5 Why vil være meget nyttige.

Dette trin er meget vigtigt, for ved at finde årsagen til de potentielle risici vil det være mere sandsynligt, at aktiviteten vil skabe gode resultater.

Orsagerne i det FEA-eksempel, som vi har diskuteret:

Tabel med årsager og fejltilstande FEA-eksempel

Strin 8: Forekomstvurdering

Nu bestemmer vi forekomsten eller hyppigheden, som simpelthen er den estimerede sandsynlighed for, at en fejl opstår for den angivne årsag. Ligesom alvorligheden klassificeres forekomsten normalt på en skala fra 1 til 10, hvor 1 er meget usandsynligt, og 10 er uundgåeligt.

En vejledning til klassificering af forekomst er:

Forsyningen blev bragt til det eksempel, vi diskuterer:

Tabel med forekomst, årsager og fejltilstande Eksempel FMEA

Stræk 9: Identificer kontroller

Fra de årsager, der allerede er noteret, identificerer vi nu kontroller. Ved kontrol forstås de procedurer, handlinger, mekanismer eller tests, der i øjeblikket anvendes for at forhindre, at fejl genereres og når kunden eller kundeprocesserne.

Kontrol kan sigte mod 1) at opdage fejlen, efter at den er opstået, men før den når kunden, 2) at forhindre årsagen i at blive genereret, eller 3) at reducere sandsynligheden for, at årsagen opstår.

For vores eksempel:

Kontroller, årsager og fejltilstande Eksempel FEA

Strin 10: Vurdering af graden af kontroldetektion

Nu tildeler vi graden af detektion til hver kontrol, dvs. vi vurderer, hvor godt de identificerede kontroller kan opdage en årsag eller fejltilstand, efter at den er opstået, men før den når frem til kunden. Den vurderes også på en skala fra 1 til 10, hvor 1 er en kontrol, hvor der er sikkerhed for, at fejlen vil blive opdaget, og 10 er en kontrol, hvor der er sikkerhed for, at den IKKE vil blive opdaget.

I et billede:

I det følgende billede vedlægger jeg graden af detektion af kontrollerne:

Tabel med Årsager, kontroller og detektion Eksempel FEA

Stræk 11: Beregn det prioriterede risikotal (PRN)

Det prioriterede risikotal fås ved at gange graden af alvorlighed, forekomst og detektion.

NPR = Graden af alvorlighed * Graden af forekomst * Graden af detektion

Risikoprioritetstallet beregnes for at prioritere fejltilstande og deres årsager. Hvis du ser på vores eksempel, er de fejltilstande med den højeste NPR fejl ved indtastning og papirstop.

NPR-diagram Eksempel FEA

Strin 12: Foranstaltninger

Det sidste trin består i at træffe foranstaltninger. Disse foranstaltninger kan tage sigte på at ændre konstruktionen eller processen for at reducere alvorligheden eller forekomsten. De kan også være supplerende kontroller for at øge graden af opdagelse. Med andre ord kan foranstaltningerne fokusere på fejl, årsager eller kontrolforanstaltninger.

Men effektiviteten af foranstaltningerne afhænger i høj grad af deres planlægning. Det er her, at værktøjer som 5W + 2H er nyttige. Som et minimum bør vi definere:

  • Hvad der skal gøres
  • Hvad der skal gøres
  • Samtaler
  • Tidspunkter
  • Nødvendige ressourcer
  • Steder

Det er dog ikke nødvendigt at beskrive alt dette i detaljer i FEA-dokumentet. Det er tilstrækkeligt at inkludere, hvad der skal gøres.

Tabel med NPR-beregning Eksempel MEFA

Strin 13: Den nye NPR

Hver gang en foranstaltning gennemføres, er det nyttigt at beregne den nye NPR for at afgøre, om foranstaltningen har været effektiv. Vi siger, at en handling har været effektiv, når det resultat, som den blev indledt med henblik på, er opnået. Hvis NPR reduceres, er foranstaltningen derfor effektiv.

Ny NPR AMEF

Eksempel på AMEF

Med alt dette gjort, ser den bogføringsproces, som vi bruger som eksempel på fejltilstands og effektanalyse, således ud:

Eksempel på fejltilstands og effektanalyse

Hvornår skal man udføre en AMEF-analyse

Fejltilstands og effektanalyse kræver kun villighed til at blive brugt. Det er en analyse, der opdateres dynamisk, hvor den anvendes, så der er ikke noget bestemt tidspunkt for at lave en FEA.

Der er dog scenarier, hvor det er hensigtsmæssigt at bruge dette værktøj, f.eks.

  • Implementering af ledelsessystemer, der kræver risikoanalyse.
  • På grund af kundernes krav, f.eks. når de har brug for, at kontinuiteten af en tjeneste skal garanteres.
  • Design af nye produkter, tjenester, processer eller software.
  • Opfølgende fejl i en produktionsproces eller levering af tjenester.
  • Vedligeholdelsesprogrammer.
  • Procesdokumentation.

Download format med eksempel på FEA

Klik her for at downloade det format, der er konstrueret til at udføre eksemplet på fejltilstands og effektanalyse

Kilde:

Liu, Hu-Chen. (2016). FMEA: Brug af usikkerhedsteorier og MCDM-metoder. Springer SIngapore, ed 1.

Neufelder, A. M. (2010). Oversigt over analysen af fejlmodes og virkninger af softwarefejl. Hentet den 25. juli 2020 fra http://www.softrel.com/fmea%20overview.pdf

Bellovi, M. (2004). NTP 679: Analyse af fejltilstande og -virkninger. FMEA. Hentet 25. juli 2020, fra https://www.insst.es/documents/94886/326775/ntp_679.pdf/3f2a81e3-531c-4daa-bfc2-2abd3aaba4ba

Zuñiga Rodríguez, A. (31. januar 2018). Failure Mode Analysis and its Effects FMEA: tilgange til at forbedre prioriteringen af fejltilstande. Hentet den 25. juli 2020 fra http://planetrams.iusiani.ulpgc.es/?p=2940&lang=en

.