Vanliga fällor att undvika
Översikten som vi har diskuterat för att hjälpa dig att komma igång med granskningsprocessen efter incidenten är användbar, men det kan också vara användbart att känna till några av de hinder som du kan stöta på på den här resan.
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"
Du kanske kommer ihåg att "pilotfel" (även kallat "mänskligt fel") var slutsatsen som de första utredarna nådde i B-17-artikeln som vi startade i modulintroduktionen. Låt oss gå tillbaka till den historien.
I den inledningen föreslog vi att de slutsatser som nåddes kanske inte är tillfredsställande för dig. De var definitivt missnöjda med Alphonse Chapanis, en militärpsykolog som blev ombedd av det amerikanska flygvapnet att undersöka dessa incidenter. Han märkte bland annat att dessa olyckor var unika för B- 17 och en liten mängd andra flygplan. Det fanns tusentals C-47 transportflygplan i bruk i Västeuropa samtidigt, men ingen C-47 hade någonsin upplevt en liknande incident.
Så han intervjuade piloter, och baserat på vad han hörde från dem, gick han och tittade på B-17 cockpits. Det han såg där var två brytare: växelbrytaren och klaffbrytaren. Strömbrytarna var cirka 3 tum från varandra i förarkabinen. Deras funktionssätt var identiskt. De var helt enkelt för lätta att förvirra för varandra, och det var vad som hade hänt i 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. Så Chapanis försökte något annat.
Han limmade ett litet gummihjul till strömbrytaren för växeln, och en hård kantig "flik" till strömbrytaren för klaffarna, och visst slutade olyckorna inträffa.
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. Detta tillvägagångssätt har fortsatt att ligga till grund för utformningen av alla moderna flygplan. De två strömbrytarna i nuvarande flygplan är nu mycket tydligt åtskilda, som föreskrivs av federal lag i USA.
Varför berättade vi den här historien?
Människor gö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 stannar människor där i stället för att analysera incidenten ytterligare.
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 "mänskligt fel" slutsatsen i undersökningar är att det får dig att tappa bort det faktum att vad människorna gjorde verkade vettigt för dem då. 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 vill lära oss får vi inte sluta undersöka när vi hittar ett mänskligt fel, som vi så ofta gör. Som historien om B-17s visar är det precis bortom det mänskliga felet där vi lär oss intressanta saker om vårt system.
Trap 2: Kontrafaktiskt resonemang
Kontrafaktiska betyder "i strid med fakta" och kontrafaktiska resonemang syftar på berättande om händelser som inte hände för att förklara de händelser som faktiskt inträffade. Detta är inte så meningsfullt, även om människor har en tendens att göra det hela tiden.
Du kan identifiera kontrafaktiska uttalanden med hjälp av nyckelfraser:
- Kunde ha
- Borde ha gjort
- Skulle ha
- Det gick inte att
- Gjorde inte
- Om bara
Några exempel på kontrafaktiska instruktioner som rör granskningar efter incident:
"Ö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 post-incidentgranskning är att du pratar om saker som inte hände istället för att ta dig tid att förstå hur det som hände, hände. Du lär dig inget av den här spekulationen.
Trap 3: Normativt språk
normativt språk ofta antyder att det fanns ett "uppenbart korrekt" handlingsförlopp som operatörerna borde ha vidtagit och bedömer dessa operatörers åtgärder med facit i hand.
Normativt språk kan vanligtvis identifieras av adverb som "otillräckligt", "slarvigt", "hastigt" och så vidare.
Normativt tänkande leder dig att bedöma beslut baserat på deras resultat. Det här sättet att tala är inte logiskt, eftersom resultatet är enda information som inte var tillgänglig för dem som fattade beslut och bedömningar.
Normativt språk kan också användas i motsatt mening. Människor kan berömma operatörer för att de har agerat "på lämpligt sätt", till exempel. 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
mekanistiska resonemang avser begreppet att ett visst resultat kan härledas från intervention. Det kallas ibland de snokande barnens syndrom (myntat av Jessica DeVita) baserat på antagandet att "Vårt system skulle ha fungerat bra ... om det inte hade varit för de snokande barnen."
När du använder mekanistiska resonemang i din granskning efter incidenten bygger du dina slutsatser på den felaktiga uppfattningen att de system du arbetar med och inom i princip fungerar korrekt, och om bara de där nyfikna ungdomarna 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 besked om 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, Internet fungerar normalt.
Men du kan inte göra några ändringar i koden eller konfigurationen. Inga utrullningar, inga kontrollplansåtgärder, ingenting.
Tror du att tjänsten fortfarande skulle köras som förväntat efter en dag? Efter en vecka? Efter en månad? Efter ett år? Hur länge kan du realistiskt förvänta dig att din tjänst fortsätter att köras utan mänsklig inblandning? I de allra flesta fall skulle det inte göra det.
Den här tankeövningen leder oss till en viktig slutsats:
Mänsklig adaptiv kapacitet krävs för att hålla våra system igång.
Den enda anledningen till att dina system förblir igång i första hand är på grund av åtgärder från människor i kontrollloopen. 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 de där snokande ungarna." 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 mekanistiska resonemang är att det leder dig till en väg där du tror att hitta den felaktiga människan är detsamma som att hitta problemet. Den samma felaktiga människan har dock improviserat och anpassat sig för att hålla systemet i gång under veckor och månader. Den här rollen kanske är tillräckligt viktig för att reflektera över i granskningen efter incidenten.
Nu när du vet några saker att undvika under en granskning efter incidenten kan vi gå vidare till nästa enhet där vi utforskar några av de användbara metoderna för dessa granskningar.