Hva er rotårsaken?

Situasjon som illustrerer rotårsaksanalyse – uhell med leiebil

En jobbreise. En ferge. En bom som satt for høyt. Og et fly vi aldri rakk.

Uten struktur i rotårsaksanalysen risikerer du å fikse symptomer i stedet for årsaker.

Bakgrunn

Vi var på kundebesøk i Meløy, omtrent tre timer sør for Bodø.

Normalt kan man kjøre hele veien, men et ras hadde stengt veien. Fergen fra Meløy til Ørnes var eneste vei videre.

Vi dro i god tid, men undervurderte hvor mange som skulle ta samme ferge.

Mens vi sto i køen, ble bilen vår rygget ned av en trailer som sto foran oss. Vi måtte bruke tid på skademelding.

Vi kom ikke med første ferge, og måtte ta ekstra fergen som ble satt opp.

Forsinkelsen var på over én time. Tidsmarginene våre for å rekke flyet ble kritisk små.

Da vi endelig kom med en ferge til Ørnes, fikk vi beskjed om å kjøre av. Men bommen lå 30–40 cm høyere enn innløpsrampen.

Da vi forsøkte å kjøre av, traff bilen kanten og ble sittende fast på understellet.

Flere passasjerer måtte hjelpe til for å dytte bilen løs.

På dette tidspunktet var hele reiseplanen ødelagt. Vi hadde ikke mulighet til å rekke flyet vårt.

Kort oppsummert

Situasjon: En jobbreise som endte med mistet fly og skadet leiebil.

Innsikt: En hendelse kan ha flere underliggende årsaker. Uten strukturert analyse risikerer du å adressere symptomer, ikke problemet.

Tegn du kan se etter: Team som hopper rett til løsninger uten å analysere. Samme problem kommer tilbake fordi rotårsaken aldri ble adressert. Skylder på mennesker i stedet for å se på systemet.

Neste steg: Start med 5 Hvorfor til å grave dypere. Strukturer funnene i et Fiskebein diagram. Test hypotesene før du implementerer løsninger.

Hva dette viser

Hva dette handler om: Forskjellen mellom å se symptomer og finne rotårsaker. Samme prinsipp gjelder enten du analyserer en fergeulykke eller et produksjonsproblem.

Hvorfor det skjer: Det er raskere å peke på én årsak og plassere skyld («fergemannskapet vinket oss ut når det ikke var klart») enn å analysere hele systemet. Men enkle forklaringer gir sjelden varige løsninger.

Hvordan du kjenner det igjen:

• Teamet ditt peker på ÉN årsak («operatøren gjorde feil») i stedet for å se hele bildet.

• Dere implementerer løsninger uten å teste om dere har funnet riktig årsak.

• Samme problem kommer tilbake fordi dere fikset symptomer, ikke rotårsaker.

• Diskusjoner ender med «hvem rotet dette til?» i stedet for «hva forteller systemet oss?»

Strukturerte verktøy hjelper deg å se hele bildet, ikke bare den mest åpenbare forklaringen.

Fiskebein rotårsaksanalyse illustrasjon

Verktøy for rotårsaksanalyse

Hva var den egentlige grunnen til at vi ikke rakk flyet?

En hendelse kan ha flere underliggende årsaker. Uten en god analyse risikerer vi å adressere symptomer og ikke årsaker.

Ved hjelp av 5 Hvorfor kan vi grave dypere i årsakskjeden, og strukturere resultatene i et Fiskebein diagram.

Fiskebein diagrammet kan organiseres i ulike kateogier, eksempelvis: Menneske, Maskin, Miljø, Metode, Måling og Materiale. Det gir en helhetlig forståelse av hva som påvirker et problem.

Bildet viser et forslag til hvordan årsakene i denne hendelsen kan visualiseres. Dette er ikke en fasit, men et godt utgangspunkt for refleksjon og forbedring.

Kjenner du igjen dette?

Kanskje du ikke analyserer fergereiser akkurat nå;-) Men jeg kjenner kanskje igjen dette:

• Teamet stiller spørsmål som «hvem rotet dette til?» i stedet for «hva forteller prosessen oss?»

• Et tiltak implementeres fordi det «alltid har fungert», uten at noen sjekker om det er riktig årsak denne gangen.

• Avvik eskaleres til ledelsen fordi ingen har verktøy til å analysere hva som faktisk skjer.

• Samme problem løses tre ganger på et år, og ingen stiller spørsmålet om hvorfor det dukker opp igjen.

• Prosessen justeres basert på ett avvik, som viser seg å være normal variasjon, og variasjonen øker.

Konsekvensen? Ressurser brukes på tiltak som ikke løser underliggende rotårsaker. De samme brannene slukkes om og om igjen.

Hva du kan gjøre med dette

Steg 1: Start med spørsmålet, ikke løsningen

Neste gang et problem dukker opp, motstå impulsen til å gå rett til tiltak. Skriv ned problemet og still spørsmålet: «Hva vet vi, og hva trenger vi å vite?»

Steg 2: Bygg Fiskebein diagram med hypoteser

Skriv ned mulige årsaker som hypoteser, ikke som fakta. Bruk gule lapper og gråpapir i starten. Involver de som kjenner utfordringen. En operatør som har stått i prosessen i fem år, vet ofte mer enn det som fremgår av avviksrapporten.

Steg 3: Test hypotesene med data

For hver hypotese, spør: «Hva slags data ville bekrefte eller avkrefte dette?» Samle inn data målrettet. Ikke all data, bare det som er relevant for hypotesen du tester.

Steg 4: Iterer til du har rotårsaken

Rotårsaksanalyse er ikke én øvelse. Det er en iterativ prosess hvor du tester, lærer og justerer. Når du finner rotårsaken, vil løsningen ofte være åpenbar.

Ofte stilte spørsmål

Når skal jeg bruke 5 Hvorfor vs Fiskebein diagram?

Bruk 5 Hvorfor når problemet virker enkelt og lineært. Bruk Fiskebein diagram når problemet har flere mulige årsaker eller involverer flere deler av systemet. Ofte er det smart å kombinere dem: 5 Hvorfor for å grave dypere, Fiskebein for å strukturere funnene.

Hvor mange ganger skal jeg spørre «hvorfor»?

Det er ikke magisk med akkurat fem ganger. Noen ganger trenger du tre. Andre ganger syv. Spør til du kommer til en årsak du faktisk kan gjøre noe med. Hvis svaret er «fordi operatøren gjorde feil», spør hvorfor operatøren gjorde feil. Grav til du finner systemårsaken.

Hva hvis vi er uenige om rotårsaken?

Da trenger dere data. Diskusjoner om rotårsaker uten data blir meningsutv ekslinger. Bruk Fiskebein diagrammet til å liste hypoteser, deretter test dem systematisk. La dataene avgjøre, ikke den som roper høyest.

Hvordan unngår jeg å skylde på mennesker?

Spør «hvorfor skjedde dette?» i stedet for «hvem gjorde dette?». Fokuser på systemet, ikke personen. Hvis en operatør gjorde feil, spør hvorfor feilen var mulig å gjøre. Var instruksjonen uklar? Manglet opplæring? Var designet dårlig? Systemet tillot feilen. Det er det du skal fikse.

Kan jeg bruke dette på alle typer problemer?

5 Hvorfor og Fiskebein fungerer best på problemer som skjer sjeldent (spesiell variasjon). Hvis problemet skjer ofte og tilfeldig, trenger du å forstå prosessen. Prosesskartlegging og statistisk prosesskontroll (SPC) hjelper deg å forstå prosessen og bestemme normal variasjon. Les mer om forskjellen i artikkelen « Gulrot eller tre?».