Spåra en evidensbaserad processorsak utan att skuldbelägga en person
En användbar definition av grundorsak skiljer mellan tre saker: symtomet du observerade, en omständighet som bidrog till att det inträffade och orsaken som stöds av bevis. För en hantverksworkshop i ett lokalsamhälle kan det innebära att två personer får bekräftelser på samma plats, att telefon- och onlinebokningar hanteras i separata register och att en fördröjd uppdatering gör att en plats fortfarande är tillgänglig online efter att den har reserverats per telefon. Det sista påståendet är en orsak endast om registren stöder den mekanismen. Det här är ett praktiskt sätt att dokumentera ett mindre processproblem, inte ett påstående om att varje analys måste använda en fast uppsättning etiketter.
Vad betyder ”grundorsak” i ett litet projekt?
American Society for Quality (ASQ) definierar en grundorsak som en faktor som orsakade en avvikelse och bör åtgärdas genom korrigerande åtgärder. Organisationen beskriver grundorsaksanalys som ett sätt att ta reda på varför ett problem uppstod och noterar att analys av händelser och orsaksfaktorer använder bevis och en tidslinje för att identifiera orsaksfaktorer och bidragande faktorer. De idéerna stöder en enkel arbetsdefinition: en grundorsak är en del av en process som stöds av bevis, förklarar hur det angivna problemet uppstod och kan åtgärdas genom en praktisk förändring. ASQ:s vägledning om grundorsaksanalys
”Grund” kan ge intrycket att det bara finns en orsak. I verkliga processproblem kan flera faktorer samverka. ASQ hänvisar själv till orsaksfaktorer och bidragande faktorer, så en noggrann dokumentation kan identifiera mer än en orsak när bevisen stöder det. Undvik att välja en bekväm förklaring bara för att någon föreslår den först.
Vad är skillnaden mellan ett symtom, en bidragande omständighet och en orsak?
De här etiketterna gör det lättare att formulera ett kort problem tydligt. De är ett skrivhjälpmedel, inte en ersättning för att undersöka vad som hände.
En omständighet kan bidra till problemet utan att förklara hela förloppet. En välbesökt workshop kan till exempel sammanfalla med en fördröjd uppdatering, men ”det var mycket folk” förklarar inte i sig varför en andra bekräftelse kunde skickas. Orsaksbeskrivningen bör koppla processen till resultatet och stödjas av något som går att kontrollera: tidsstämplar, bokningsregister eller en genomgång av reservationsstegen. Om sådana bevis saknas bör du kalla förklaringen en möjlig orsak tills den har kontrollerats.
Del: Symtom; Vad det beskriver: Det observerbara resultat som kräver uppmärksamhet; Exempel från workshopbokningen: Två deltagare får bekräftelser för samma tillfälle och plats.
Del: Bidragande omständighet; Vad det beskriver: En omständighet som gjorde att problemet lättare eller mer sannolikt kunde uppstå; Exempel från workshopbokningen: Telefonbokningar registreras separat från onlinebokningar och uppdateringar sker inte omedelbart.
Del: Orsak som stöds av bevis; Vad det beskriver: Processmekanismen som förklarar hur resultatet uppstod; Exempel från workshopbokningen: En telefonbokning kan bekräftas utan att platsen tas bort från online-listan, så en annan person kan reservera den innan registren stäms av.
En kort frågeserie för att hitta en orsak som stöds av bevis
Börja med händelsen i stället för att bedöma en person. ASQ rekommenderar att man metodiskt fastställer en tidslinje och analyserar orsaker och effekter. Följande frågor tillämpar det arbetssättet på ett mindre bokningsproblem. ASQ:s översikt över grundorsaksanalys
Det här liknar en undersökning med ”fem varför”, men fem är inget obligatoriskt antal. Stanna när du har en specifik och kontrollerbar processförklaring som redogör för händelsen och kan vägleda ett test av en lösning. Om en fråga leder till spekulation snarare än bevis, markera osäkerheten och leta efter ett register eller observera processen innan du behandlar svaret som fastställt.
Vad hände exakt? Beskriv resultatet i observerbara termer: ”Två bekräftelser utfärdades för plats 4 vid lördagens pass klockan 10.” Undvik att ersätta händelsen med slutsatser som ”bokningsprocessen misslyckades”.
Vilka register visar när det hände? Jämför de två bekräftelsetiderna med telefonloggen, online-bokningslistan och eventuella gemensamma reservationsregister. Då fastställer du förloppet i stället för att förlita dig på minnet.
Vad ändrades, eller vad saknades, mellan den första och den andra bekräftelsen? Anta att telefonloggen visar att den första reservationen godkändes, men att plats 4 fortfarande stod som ledig i online-listan när den andra bokningen kom in.
Vad gjorde det möjligt att skicka båda bekräftelserna? Gå igenom stegen. Om telefonbokningar förs in i en papperslogg medan onlinebokningar hanteras i en separat lista, och ingen av kanalerna kontrollerar ett gemensamt, aktuellt register över tillgängliga platser innan bokningen bekräftas, skapar processen en möjlighet till dubbelbokning.
Vilka bevis skulle göra den förklaringen mindre sannolik? Kontrollera om den första reservationen registrerades online innan den andra gjordes, om båda bekräftelserna faktiskt gällde samma plats och tid samt om någon annan regel eller ett systemproblem förklarar dubbelbokningen bättre. Om registren motsäger det föreslagna förloppet ska du revidera förklaringen.
Skriv resultatet utan att överdriva
En kort dokumentation kan följa det här mönstret:
Symtom: [Observerbart resultat.] Bidragande omständighet: [Omständighet som gjorde det mer sannolikt.] Orsak som stöds av bevis: [Processmekanism samt bevisen som stöder den.]
Tillämpat på det illustrativa scenariot ovan:
Exemplet är hypotetiskt; bevisen hör till illustrationen och är inte en rapport om en verklig workshop. I en faktisk undersökning ska du ersätta det antagna förloppet med register som du har kontrollerat. Om du ännu inte kan fastställa att en telefonbokning gjordes före den andra bekräftelsen eller att platsen fortfarande stod som ledig i online-listan, skriv ”möjlig orsak” och ange vad du behöver kontrollera.
Symtom: Två deltagare fick bekräftelser för samma plats och tid i workshopen.
Bidragande omständighet: Telefon- och onlinebokningar registrerades på olika ställen, och det dröjde innan registren stämdes av.
Orsak som stöds av scenariots antagna register: Telefonbokningen bekräftades utan att online-listan över tillgängliga platser uppdaterades eller kontrollerades. Platsen stod fortfarande som ledig när den andra reservationen gjordes.
Välj en lösning som går att återställa och kontrollera om den åtgärdar mekanismen
Som ett försök med låg risk kan workshopen använda ett gemensamt tillgänglighetsregister för alla bokningskanaler. Personalen registrerar reservationen och markerar platsen som upptagen innan den bekräftas, oavsett om förfrågan kommer per telefon eller online. Det riktar in sig på den föreslagna mekanismen – att två kanaler bekräftar bokningar utifrån olika eller inaktuella uppgifter – utan att kräva en permanent systemändring.
Prova rutinen under ett begränsat antal kommande tillfällen, med en tydlig start- och slutpunkt. Jämför varje bekräftelse med det gemensamma registret och fråga personalen som hanterar bokningarna om de kunde följa stegen konsekvent. Om dubbelbekräftelserna fortsätter eller registret inte uppdateras tillförlitligt före bekräftelsen har försöket inte visat att förändringen kontrollerar orsaken. Gå igenom stegen och bevisen igen; anta inte att samma lösning löser problemet om mekanismen är en annan.
En bra definition gör alltså mer än att namnge ett problem. Den låter en annan person se vad som observerades, vilken omständighet som kan ha bidragit, vilken processförklaring bevisen stöder och hur en liten, återställbar förändring kan testa den förklaringen.
Källor och avgränsning
Det ursprungliga exemplet med dubbelbokningen följer bevisen fram till ett återställbart processtest. De angivna källorna stöder de redovisade fakta; exemplen och övningarna är ursprungliga redaktionella tillämpningar.
American Society for Quality, grundorsaksanalys: https://asq.org/quality-resources/root-cause-analysis