Flowchart for rodårsagsanalyse

Flowchart for rodårsagsanalyse: problemformulering, indeslutning, indsamling af evidens, 5 Whys og fiskebensdiagram, verifikation af årsagen og overlevering til CAPA.

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.

Brug denne skabelon

Mere i Skabeloner til procesdiagrammer