Flowchart til rodårsagsanalyse (beslutningstræ)

Sådan fungerer det

1. Omdøb banerne til jeres reelle beslutningstagere

   Banerne her er beslutningsmandater, ikke afdelinger: Procesejer, Undersøgelsesleder, Kvalitetsansvarlig, Ledelse. Erstat dem med de roller, der reelt svarer på hvert spørgsmål hos jer, og hold om muligt undersøgelseslederen adskilt fra procesejeren. En undersøgelse ledet af den, der er ansvarlig for processen, har det med at lande på årsager, der er behagelige at sige højt.

2. Skriv reglen for problemformuleringen på den første port

   'Er problemet klart defineret?' virker kun, hvis nogen har sagt, hvad defineret betyder. Den gængse test er, at formuleringen angiver hvad der fejlede, hvor, hvornår og hvor ofte — og slet ikke nævner en årsag. En formulering, der allerede indeholder årsagen, oftest en variant af operatørfejl, gør resten af træet til en bekræftelsesøvelse.

3. Sæt tærsklen for tilstrækkelige data på dataporten

   Beslut, hvad 'Er data tilstrækkelige til analyse?' kræver, før I får brug for det: et tidsforløb, der kan rekonstrueres, henlagte prøver eller logfiler, der stadig er inden for opbevaringsperioden, og mindst én førstehåndsberetning. Markér det, der er flygtigt, for det afgør, hvor hurtigt indsamlingen skal ske. Uden en nedskrevet tærskel bliver grenen Utilstrækkelige aldrig taget, og metoden vælges på det, der lige lå fremme.

4. Ret reglerne for metodevalg til jeres egne

   Routingen i dette diagram — Gentagen til fiskeben, Teknisk til fejltræ, Menneskelig til 5 x hvorfor, Systemisk til fiskeben — er et forsvarligt udgangspunkt, ikke en lov. Tilpas den til de metoder, jeres folk faktisk er trænet i, og tilføj dem, I bruger, for eksempel ændringsanalyse eller barriereanalyse. Det afgørende er, at reglen findes og er synlig på diagrammet, så valget kan udfordres i en gennemgang.

5. Definer stopreglen for 5 x hvorfor og vejen ud

   'Nået en påvirkelig årsag?' er den node, der forhindrer, at 5 x hvorfor ender i vejret eller konjunkturerne. Stop ved den sidste årsag, jeres organisation kan ændre. Løber kæden tør før det, eller deler den sig i flere lige plausible svar, er problemet flerfaktorielt, og Nej-grenen flytter det over på et fiskeben frem for at lukke en tynd kæde igennem.

6. Aftal eskaleringskriteriet, og hold begge diagrammer versionsstyret

   Skriv ned, hvad der tvinger 'Er årsagen inden for lokal kontrol?' over på grenen Uden for lokal: årsager, der ejes af et andet site, en leverandør eller en politik, dette team ikke kan ændre; hændelser, der skal anmeldes til en myndighed eller en kunde; og alt, der involverer sikkerhed eller allerede leverede produkter. Kobl derefter beslutningstræet sammen med proceskortet for hele RCA-forløbet, og hold begge under versionsstyring med godkendelserne registreret, så undersøgere og godkendere arbejder ud fra samme autoriserede version.

Ofte stillede spørgsmål

Er et flowchart til rodårsagsanalyse et proceskort eller et beslutningstræ?

Det kan være begge dele, og de svarer på hver sit spørgsmål. Et proceskort svarer på, hvad der sker bagefter, og hvem der gør det: rejs problemet, indesluk det, indsaml bevismateriale, analysér, verificér, overdrag til CAPA. Et beslutningstræ — som denne side — svarer på, hvilken metode der skal anvendes, og hvem der beslutter, og dets grene ender i forskellige udfald i stedet for at samles i én sti. De fleste organisationer har brug for begge: proceskortet til proceduren og beslutningstræet til de skøn, der ligger inde i den. Har I brug for hele forløbet fra ende til anden, skal I bruge skabelonen for selve rodårsagsanalyse-processen.

Hvordan vælger jeg mellem 5 x hvorfor, fiskeben og fejltræ?

Ud fra problemets form, hvilket er præcis det, de to metodebeslutninger i diagrammet tester. 5 x hvorfor passer til én årsagskæde ejet af ét team, hvor hvert svar bliver til det næste spørgsmål. Et fiskebensdiagram — Ishikawa — passer, når flere kategorier kan være involveret: metode, maskine, materiale, mennesker, måling, miljø. Det tvinger teamet forbi den første plausible gren. Et fejltræ passer til en teknisk fejl med en definerbar tophændelse og komponenter, hvis fejllogik man kan arbejde baglæns gennem. Et gentaget mønster fortjener næsten altid et fiskeben først, for gentagelse betyder som regel betingelser frem for en enkeltstående kæde. Mange undersøgelser bruger to: generér kandidater på et fiskeben, og kør derefter 5 x hvorfor ned ad den gren, bevismaterialet understøtter.

Hvad gør vi, når 5 x hvorfor ikke når frem til en årsag, vi selv kan påvirke?

Det er præcis det, beslutningen 'Nået en påvirkelig årsag?' er til for. Løber kæden forbi alt, jeres organisation kan ændre, eller forgrener den sig i flere lige plausible svar, flytter Nej-grenen problemet over på et fiskeben i stedet for at acceptere det sidste led som rodårsag. Det er den hyppigste fejl i praksis: kæden følges, til den rammer noget uimodsigeligt, men uhåndterbart — markedspres eller menneskets natur — og så skrives der alligevel en handling op imod det.

Hvad skal flowchartet gøre, når bevismaterialet er væk?

Give det et navngivet udfald i stedet for at lade det stå som et hul. Dette træ har to. Før analysen kan 'Er data tilstrækkelige til analyse?' sende sagen til 'Tilbage til indsamling af bevismateriale', som sætter den på pause frem for at fortsætte på tyndt grundlag. Efter analysen, når en årsag stadig kun er en hypotese, fører 'Kan der skaffes flere beviser?' enten tilbage til indsamling eller ender i 'Luk med en databegrænsning'. At lukke med en angivet begrænsning er et legitimt resultat, og det udløser normalt en handling i sig selv: gør de manglende data tilgængelige næste gang.

Kræver nogen standard en bestemt metode til rodårsagsanalyse?

De almindelige ledelsessystemstandarder kræver, at I bestemmer årsagerne til en afvigelse og handler, så den ikke gentager sig, men de foreskriver ikke hvordan. ISO 9001 punkt 10.2 er skrevet sådan, og ISO 13485 griber korrigerende og forebyggende handlinger an på samme måde. Det overlader metodevalget til jer — og netop derfor er det værd at dokumentere. Et beslutningstræ som dette, med testene skrevet på noderne, viser en auditor, at metoden blev valgt ud fra angivne kriterier og ikke ud fra præference, og svaret bliver det samme, uanset hvem der kører undersøgelsen.