Vanliga fallgropar att undvika
Den planering som vi har diskuterat för att hjälpa dig att komma igång med granskningsprocessen efter incident är användbar, men det är även bra att känna till några av de hinder som du kan stöta på under resans gång.
I den här lektionen får du reda på några vanliga fällor som andra har hamnat i under granskningsprocessen efter incidenten och hur du undviker dem.
Trap 1: Tillskrivning till "mänskligt fel"
I den berättelse om B-17 som vi påbörjade i modulens introduktion var ”pilotfel” (som även kallas ”den mänskliga faktorn”) de första utredarnas slutsats. Låt oss gå tillbaka till den historien.
I det introt föreslog vi att de slutsatser som nåddes kan vara missnöjda med dig. De var definitivt en besvikelse för Alphonse Chapanis, en militärpsykolog som fick uppdraget av USA:s flygvapen att undersöka dessa incidenter. Han upptäckte bland annat att incidenterna var unika för B-17 och ett fåtal andra flygplan. Det fanns tusentals transportflygplan av typen C-47 som användes i västra Europa vid samma tidpunkt, men inget C-47 hade drabbats av någon liknande incident.
Så han intervjuade piloter, och baserat på vad han hörde från dem, gick han och tittade på B-17 cockpits. Där såg han två reglage: ett för växlarna och ett för vingklaffarna. Reglagen satt ungefär 7,5 cm från varandra i cockpiten. Deras funktionssätt var identiskt. Det var alltför enkelt att förväxla dessa reglage, vilket var just det som inträffade vid dessa incidenter. Om du precis har landat ett plan, kommer dina klaffar att förlängas, och innan du parkerar, kommer du att dra tillbaka dem. Chapanis provade därför någonting annorlunda.
Han klistrade fast ett litet gummihjul på växelreglaget samt en hård, vinklad ”klaff” vid klaffreglagen, och mycket riktigt upphörde olyckorna.
Han är nu känd som en av grundarna av området ergonomi – studiet av designfaktorer i människans prestanda – och han hade en enkel observation: utformningen av cockpiten kan påverka sannolikheten för mänskliga fel. Den här metoden har därefter används vid utformningen av alla moderna flygplan. De två switcharna i nuvarande flygplan är nu mycket distinkta, enligt federal lag i USA.
Varför berättade vi den här historien?
Människor begår misstag. Men mänskliga fel är inte en orsak, det är ett symptom. När den mänskliga faktorn bedöms vara orsaken till ett fel slutar man resonera där i stället för att analysera incidenten närmare.
Systemdesign, organisationskontext och personlig kontext påverkar alla när, hur och med vilken inverkan människor gör misstag. "Human error" är en etikett som gör att du slutar undersöka just när du är på väg att upptäcka något intressant om systemet.
Problemet med den "mänskliga fel" slutsatsen i undersökningar är att det får dig att förlora ur sikte det faktum att vad människorna gjorde vettigt för dem vid den tiden. Misstag är per definition inte avsiktliga, så de hade inte för avsikt att göra ett misstag.
När vi ser eller hör "mänskliga fel" är det en signal om att vi måste titta djupare. Om vi ska kunna dra lärdomar kan vi inte sluta utreda när vi hittar ett mänskligt fel, som så ofta sker. Som berättelsen om B-17 visar är det steget bortom den mänskliga faktorn där vi lär oss intressanta saker om systemet.
Trap 2: Kontrafaktiskt resonemang
Kontrafaktiska betyder "i strid med fakta" och kontrafaktiska resonemang syftar på att berätta en historia om händelser som inte hände för att förklara de händelser som gjorde det. Detta kan tyckas vara ologiskt men det används väldigt ofta.
Du kan identifiera kontrafaktiska påståenden med hjälp av nyckelfraser:
- Kunde ha
- Borde ha
- Skulle ha
- Misslyckades med att
- Inte
- Om det bara
Här är några exempel på kontrafaktiska påståenden som rör granskningar efter incidenter:
"Övervakningssystemet kunde inte identifiera problemet."
"Teknikern kontrollerade inte konfigurationens giltighet innan den antogs."
"Detta kunde ha plockats upp i kanariemiljön."
Problemet med den här typen av resonemang i en granskning efter incident är att du pratar om saker som inte hände i stället för att ta dig tid att förstå vad som hände, hände. Du lär dig inget av den här spekulationen.
Trap 3: Normativt språk
Normativt språk antyder ofta att det fanns ett "uppenbart korrekt" till handlingsförlopp som operatörerna borde ha vidtagit, och bedömer dessa operatörers handlingar med facit i hand.
Normativt språk kan vanligtvis identifieras av adverb som "otillräckligt", "slarvigt", "hastigt" och så vidare.
Normativt tänkande leder till att beslut bedöms utefter vilka resultat de leder till. Det här sättet att tala är inte logiskt, eftersom resultatet är den enda information som inte var tillgänglig för dem som fattade besluten och domarna.
Normativt språk kan även användas i motsatt bemärkelse. Det går till exempel att berömda operatörer för deras ”lämpliga” agerande. Men återigen, ofta görs denna bedömning med fördelen av information som människorna i fråga inte hade.
Problemet med normativt språk liknar problemet med kontrafaktiska resonemang: om vi gör bedömningar efter det faktum att vi använder information som inte var tillgänglig för de människor som var inblandade under incidenten, försummar vi att förstå hur operatörernas handlingar var meningsfulla för dem vid den tiden.
Trap 4: Mekanistiskt resonemang
Mekanistiskt resonemang är begreppet att ett visst resultat kan härledas från intervention. Det kallas ibland för barnsyndromet (myntat av Jessica DeVita) baserat på premissen att "Vårt system skulle ha fungerat bra ... om det inte hade varit för dem som lägger sig i barn."
När du använder mekanistiska resonemang i din granskning efter incidenten bygger du dina slutsatser på den felaktighet som de system du arbetar med och inom i princip fungerar korrekt, och om bara de "blanda sig i barn" inte hade gjort vad de gjorde, skulle misslyckandet inte ha inträffat.
Men det är inte så system fungerar.
Tänk dig följande scenario för att illustrera den här punkten: Du arbetar med en produktionstjänst. Nu får du veta att du inte får röra eller göra något med den tjänsten. Allt utanför ditt team fortsätter som tidigare: kunder fortsätter att använda tjänsten, externa beroenden fortsätter att ändras, Internetfunktionerna normalt.
Men du kan inte göra några ändringar i koden eller konfigurationen. Det blir alltså inga distributioner, kontrollplansåtgärder eller något annat.
Tror du att tjänsten skulle fortsätta köras som förväntat efter en dag? Eller efter en vecka? Efter en månad? Vad sägs om efter ett år? Hur länge kan man realistiskt förvänta sig att tjänsten fortsätter köras utan mänsklig inblandning? I de allra flesta fall skulle den inte det.
Det här tankeexperimentet leder till en viktig slutsats:
Det krävs mänskligt anpassningsarbete för att våra system ska fortsätta köras.
Den enda anledningen att system hålls igång är de åtgärder som människor vidtar i kontrolloopen. Det är bara genom mänsklig handling och förmåga att anpassa sig till föränderliga omständigheter som systemet fortsätter att fungera.
Därför är det felaktigt att dra slutsatsen att systemet "i princip fungerade... om det inte hade varit för dem som lägger sig i barn." I själva verket är tillförlitligheten för din tjänst inte oberoende av de människor som arbetar med den. Istället är det ett direkt resultat av det arbete som människorna gör på det varje dag.
Problemet med mekanistiskt resonemang är att det leder till föreställningen om att problemlösningen i sig handlar om att hitta den person som gjort fel. Men samma person som begick ett misstag har ju improviserat och gjort anpassningar som hållit systemet igång i veckor eller månader. Den här rollen kan vara viktig nog att beakta under granskning efter incident.
Nu när du känner till vissa saker som bör undvikas under granskning efter incident kan vi gå vidare till nästa lektion, där vi utforskar några användbara metoder för dessa granskningar.