Flowchart for rodårsagsanalyse

Hvad er flowchart for rodårsagsanalyse?

Rodårsagsanalyse er det, der sker mellem at et problem bliver opdaget, og at en korrigerende handling bliver aftalt. Hele værdien ligger i midten: en problemformulering skrevet, før nogen har en teori, evidens indsamlet mens den stadig findes, et hændelsesforløb der viser, hvad der faktisk skete i hvilken rækkefølge, og en årsag, der har overlevet at blive testet, ikke en, der bare lød rigtig i mødelokalet.

De fleste undersøgelser fejler på en af tre måder. Problemformuleringen indeholder allerede en årsag, som regel en variant af operatørfejl, så analysen bekræfter blot den. Indeslutningen forveksles med løsningen, symptomet forsvinder, og ingen vender tilbage. Eller teamet stopper ved det første plausible svar, fordi den evidens, der skulle udelukke alternativerne, aldrig blev indsamlet, og når nogen endelig spørger, er loggene rullet, og de berørte enheder afsendt.

Diagrammet herunder løber fra et rejst problem til en lukket analysesag overleveret til CAPA, fordelt på fem baner og fem faser. Det bevarer de to veje, de fleste procesdiagrammer udelader: grenen for utilstrækkelige data, hvor undersøgelsen enten udvider indsamlingen eller lukker med en dokumenteret databegrænsning i stedet for at opfinde en årsag, og sløjfen tilbage fra verifikationsbeslutningen, når hypotesen ikke holder mod evidensen.

Hvad dette flowchart dækker

I denne skabelon

• Fem swimlanes (Facilitator, Procesejer, Undersøgelsesteam, Kvalitet og Ledelse) fordelt på fem faser: Problem og indeslutning, Evidens, Årsagsanalyse, Verifikation og Korrigerende handling
• Problemdefinitionen i første fase: procesejeren beskriver problemet som observeret, facilitatoren får aftalt en skriftlig problemformulering, der iværksættes straks indeslutning registreret adskilt fra løsningen, og først derefter sammensættes undersøgelsesteamet
• En beslutning, 'Er evidensen tilstrækkelig?', med tre grene: fortsæt til hændelsesforløbet, udvid stikprøver og interviews og vurder igen, eller luk undersøgelsen med en dokumenteret databegrænsning, når evidensen reelt er væk
• Analysesekvensen i banen Undersøgelsesteam: rekonstruer hændelsesforløbet, opstil årsagshypoteser med 5 Whys eller et fiskebensdiagram, og test derefter hver hypotese mod den evidens, der faktisk blev indsamlet
• En beslutning, 'Er årsagen verificeret af evidens?', der kun går videre på en verificeret årsag og ellers løber tilbage (enten til fornyet analyse af hypoteserne eller til flere data), før rodårsag og medvirkende faktorer adskilles som et eksplicit trin
• Afslutningsvejen: Kvalitet gennemgår og udfordrer konklusionen, facilitatoren registrerer analysens resultater, procesejeren foreslår korrigerende handlinger, ledelsen godkender og ressourcesætter dem eller sender dem til omarbejdning, og Kvalitet opretter CAPA-sagen, før analysesagen lukkes

Hvornår du skal bruge skabelonen

• Et problem bliver løst igen og igen og kommer igen og igen, og I har brug for, at undersøgelsen når frem til en årsag i stedet for endnu en nødløsning
• I skal skrive eller revidere en procedure for rodårsagsanalyse eller problemhåndtering og har brug for ét billede af, hvem der faciliterer, hvem der undersøger, hvem der gennemgår, og hvem der godkender handlingerne
• Undersøgelser ser forskellige ud alt efter hvem der kører dem, og I vil have de samme trin for evidens, verifikation og gennemgang anvendt hver gang
• En kunde, en myndighed eller en certificeringsauditor har spurgt, hvordan I fastlægger årsagerne til afvigelser, og hvilken evidens der understøtter konklusionen
• Jeres CAPA-liste er fuld af handlinger uden en sporbar årsag bag sig, og I har brug for et defineret overleveringspunkt mellem analysen og handlingen

Sådan fungerer det

1. Omdøb banerne til jeres reelle roller

   Erstat Facilitator, Procesejer, Undersøgelsesteam, Kvalitet og Ledelse med de funktioner, I faktisk har. Hold facilitatoren adskilt fra procesejeren, hvor I kan: en undersøgelse kørt af den, der er ansvarlig for processen, har det med at stoppe ved årsager, der er behagelige at sige højt. Slå baner sammen frem for at lade en bane stå, der kun optræder én gang.

2. Fastlæg udløseren og tærsklen

   Skriv ned, hvad der udløser en rodårsagsanalyse hos jer (en afvigelse, en gentagen hændelse, en kundeklage over en vis alvorlighed, en fejlet audit), og lige så vigtigt, hvad der ikke gør. En rodårsagsanalyse på alt betyder en rigtig én på ingenting. Sæt tærsklen ved siden af startnoden, så adgangskriterierne følger med diagrammet.

3. Definér hvad tilstrækkelig evidens er

   Beslutningen 'Er evidensen tilstrækkelig?' virker kun, hvis nogen har skrevet ned, hvilken evidens der forventes: henlagte prøver, logfiler og deres opbevaringstid, batch- eller skifteregistreringer, interviewnotater, fotos. Markér det, der forsvinder hurtigt, for det sætter tempoet for, hvor hurtigt indeslutning og indsamling skal ske.

4. Vælg analysemetoden bevidst

   Erstat 'Opstil årsagshypoteser' med de metoder, jeres team faktisk bruger, og notér hvornår hver enkelt gælder: 5 Whys til en lineær kæde, et fiskebensdiagram til et problem med flere plausible kategorier, fejltræsanalyse hvor flere fejl skal optræde samtidig. At nævne dem på noden forhindrer, at valget som standard bliver det, facilitatoren brugte sidst.

5. Sig hvad verifikation betyder, og hvem der udfordrer den

   Definér testen bag 'Er årsagen verificeret af evidens?': årsagen forklarer hele hændelsesforløbet, evidensen er forenelig med den, og hvis den var fjernet, var problemet ikke opstået. Udpeg derefter den, der gennemgår i banen Kvalitet. Uafhængig modstand er det, der skiller en verificeret konklusion fra en fælles antagelse.

6. Definér overleveringen til CAPA, og hold diagrammet versioneret

   Vær eksplicit om, hvor denne proces slutter, og CAPA begynder, typisk ved en godkendt handling med en ansvarlig, en frist og en defineret effektivitetskontrol. Arbejder I efter ISO 9001, er det grænsen mellem punkt 10.2's krav om at fastlægge årsagerne til en afvigelse og den korrigerende handling, der følger; standarden foreskriver ikke en analysemetode, så den, I vælger, skal I selv dokumentere. Hold diagrammet versioneret og registrer godkendelsen, så undersøgere og reviewere arbejder ud fra samme version.

Ofte stillede spørgsmål

Hvilke trin indgår i en rodårsagsanalyse?

Definér problemet, indeslut det, indsaml evidens, rekonstruer hændelsesforløbet, opstil årsagshypoteser, test dem mod evidensen, verificer årsagen, adskil den fra medvirkende faktorer, og foreslå til sidst korrigerende handlinger, der overleveres til CAPA. Rækkefølgen betyder mere end metoden: indeslutning før analyse, så problemet ikke breder sig; evidens før hypoteser, så teamet ikke forsvarer en teori dannet på dag ét; og verifikation før nogen overhovedet skriver en korrigerende handling.

Hvad er forskellen på en rodårsag og en medvirkende faktor?

En rodårsag er en, du kan fjerne, så netop dette problem ikke kan opstå igen. En medvirkende faktor gjorde problemet mere sandsynligt, sværere at opdage eller værre, da det skete, men en fjernelse af den alene ville ikke have forhindret det. De fleste virkelige undersøgelser giver en eller to rodårsager og flere medvirkende faktorer, og de kan alle udløse handlinger, men kun rodårsagen berettiger, at undersøgelsen lukkes. Det er et selvstændigt trin i diagrammet, fordi teams, der springer det over, har det med at skrive handlinger mod den faktor, der er lettest at rette.

Skal jeg bruge 5 Whys eller et fiskebensdiagram?

5 Whys passer til en lineær årsagskæde ejet af ét team: hvert svar bliver det næste spørgsmål, og man stopper, når man går ud over det, man selv kan styre. Et fiskebensdiagram (Ishikawa) er bedre, når flere kategorier kan være i spil (metode, maskine, materiale, mennesker, måling, miljø), fordi det tvinger teamet til at overveje grene, det ellers ville gå forbi. Mange undersøgelser bruger begge: kandidaterne genereres på fiskebenet, hvorefter 5 Whys køres ned ad den gren, evidensen understøtter. Ingen af dem er en verifikationsmetode, og derfor er hypotesetest et selvstændigt trin her.

Hvad skal der ske, når der ikke er data nok til at finde årsagen?

Træf beslutningen eksplicit, og registrer den. Denne skabelon lægger tre grene på 'Er evidensen tilstrækkelig?': fortsæt, udvid stikprøver og interviews og vurder igen, eller luk med en dokumenteret databegrænsning. Den tredje gren er den, de fleste procedurer udelader, og fraværet af den er grunden til, at teams skriver en spekulativ årsag i stedet for at konstatere, at evidensen var væk. At lukke med en angivet begrænsning er et legitimt udfald, og det udløser normalt en handling i sig selv: gør de manglende data tilgængelige næste gang.