Det kan finnas något nästan provocerande i ett barn som frågar varför. Och sedan varför igen. Och igen. Och igen.
Men bakom den där envisa frågan finns också något väldigt viktigt: en genuin vilja att förstå hur saker faktiskt hänger ihop. Inte bara nöja sig med det första svaret, utan fortsätta tills man kommer lite närmare sanningen.
Varför, varför, varför, varför, varför – därför!
På Tripnet använder vi ofta metoden fem varför, eller Five Whys, i vårt riskarbete, när vi analyserar avvikelser, incidenter och andra händelser där vi vill förstå vad som egentligen har hänt. Metoden används ofta inom kvalitet, incidenthantering, förbättringsarbete, Lean, ITIL och informationssäkerhet. Grundidén är enkel: man börjar med ett problem och frågar varför flera gånger, ofta ungefär fem, tills man kommer förbi det uppenbara problemet och hittar en bakomliggande orsak som faktiskt går att åtgärda.
För ofta är det första svaret inte hela sanningen.
Från symptom till rotorsak
Ett enkelt exempel kan se ut så här:
Problem: En kund kunde inte nå en viktig tjänst.
- Varför? För att webbservern inte svarade.
- Varför svarade inte webbservern? För att disken var full.
- Varför var disken full? För att loggfilerna hade vuxit väldigt snabbt.
- Varför hade loggfilerna vuxit så snabbt? För att ett fel i applikationen skapade upprepade felmeddelanden.
- Varför upptäcktes inte detta tidigare? För att övervakningen larmade på serverstatus, men inte på loggtillväxt eller diskanvändning i tid.
Då är den verkliga åtgärden inte bara att rensa disken eller starta om servern. Det behöver man kanske göra akut, men den långsiktiga förbättringen är snarare att rätta applikationsfelet, justera logghanteringen och förbättra övervakningen.
Det är här metoden blir värdefull. Den hjälper oss att skilja på symptom, direkt orsak, bakomliggande orsak och förbättringsåtgärd.
• Symptom: tjänsten låg nere.
• Direkt orsak: disken var full.
• Bakomliggande orsak: bristande logghantering, fel i applikationen och otillräcklig övervakning.
• Förbättringsåtgärd: ändra process, teknik eller ansvar så att samma sak inte händer igen.
Det handlar inte om skuld
En sak som är viktig med fem varför är att metoden inte ska användas för att hitta vem som gjorde fel. Då blir det lätt skuldjakt i stället för förbättringsarbete.
Frågan är inte: Varför gjorde Ulf fel?
Den bättre frågan är: Varför var det möjligt för ett enskilt misstag att slå ut tjänsten?
Då hamnar vi i frågor om rutiner, testning, behörigheter, övervakning, dokumentation, redundans, utbildning och beslutsvägar. Det är där värdet finns. Inte i att peka ut någon, utan i att förstå varför systemet, processen eller organisationen tillät att felet uppstod eller fick den påverkan det fick.
En incident kanske först ser ut att handla om ett tekniskt fel. En tjänst ligger nere. En backup har inte fungerat. Ett larm har missats. En rutin har inte följts. Men när vi fortsätter att fråga varför kan vi upptäcka att det egentligen handlade om något djupare: en otydlig ansvarsfördelning, bristande övervakning, ett beroende vi inte hade förstått fullt ut, en process som inte fungerade i praktiken eller en återställningsförmåga som aldrig hade testats ordentligt.
En enkel metod för bättre lärande
I en analys kan fem varför fungera ungefär så här:
- Beskriv händelsen tydligt.
- Formulera problemet utan skuld.
- Fråga varför problemet uppstod.
- Fortsätt fråga varför tills ni når en orsak som går att påverka.
- Definiera åtgärder som minskar risken för upprepning.
- Följ upp att åtgärderna faktiskt genomförs.
Metoden har också sina begränsningar. Alla problem har inte en enda rotorsak. Vi brukar se den som en bra approach och förhållningssätt. I komplexa IT-miljöer kan en incident bero på flera samverkande faktorer: teknik, process, människor, leverantörer, tidspress och otydliga mandat. Då kan fem varför behöva kombineras med andra metoder.
Som praktiskt verktyg är metoden väldigt användbar, just för att den är enkel. Man behöver inte med ett stort ramverk. Ofta vinner man på att bara stanna kvar i frågan lite längre.
– Varför hände det här?
– Varför upptäckte vi det inte tidigare?
– Varför fick det så stor påverkan?
– Varför fanns ingen spärr eller rutin?
– Varför var vi inte bättre förberedda?
Nyfikenhet som stärker informationssäkerheten
Fem varför handlar därför inte om att vara besvärlig. Det handlar om att vara nyfiken på riktigt.
I vårt arbete med informationssäkerhet, kontinuitet och riskhantering är det en enkel men kraftfull metod för att gå från konstateranden till lärande, från symptom till rotorsak och från enskilda händelser till effektivare arbetssätt.
För Tripnet är fem varför särskilt användbart för risk-, avvikelse- och problemhantering, efter incidenter eller när en tabletop-övning visar att organisationen inte riktigt vet vem som ska göra vad. Då hjälper metoden oss att gå från “det här gick inte bra” till “det här behöver vi förändra”.
När vi vågar fråga varför en gång till blir avvikelser och incidenter inte bara något vi hanterar. De blir också något vi lär oss av.
Och ibland börjar det faktiskt med samma enkla fråga som barn har ställt i alla tider:
Varför?
