Återigen får jag be om ursäkt för ”svengelskan”. Drifting kan naturligtvis översättas med ”drift” och det kommer jag att göra i texten nedan men samtidigt är ”drifting” ett begrepp som är mer etablerat i sin engelska version.

Drifting bygger ju på det som jag varit inne på tidigare i min serie om flygsäkerhet. Vi måste anpassa vårt sätt att arbeta efter hur verkligheten ser ut och utifrån det vi vill åstadkomma. De beskrivningar vi har av arbetet är aldrig heltäckande. Dels är det inte möjligt att förutse allt som kan hända, dels finns det för många variabler. En tredje faktor är att världen förändras så att beskrivningar och regelverk tenderar att alltid ligga lite efter det som faktiskt sker. De brister som finns i beskrivningar och regelverk är en av förklaringarna till att vi måste anpassa vårt arbete och denna anpassning kan orsaka en drift där sättet vi utför arbetet långsamt förändras. Efter en tid kan saker ha förändrats på ett avgörande sätt – positivt genom innovationer eller negativt med ökade risker.

En av de som tog upp detta tidigt var dansken Jens Rasmussen. Han menade att arbetet generellt har en generell, långsam och nästan omärkbar drift mot osäkerhet. Detta illustrerades så här:

Rasmussen menade att det finns ett ekonomiskt tryck på att öka produktionen eller minska kostnaderna. En annan press kommer från en önskan att inte få alltför hög arbetsbelastning. Tillsammans skapar dessa en ”drift towards failure”. Det finns många exempel på hur organisationer med gott rykte om att vara säkra ändå råkar ut för olyckor, I efterhand har man då kunnat se en lång period av små förändringar – drift – mot den situation som till slut ledde till en olycka.

En beskrivning av drift finns i den fantastiska boken ”Friendly Fire” av Scott A. Snook. Den handlar om hur två amerikanska F-15 sköt ner två amerikanska Hawk-helikoptrar i norra Irak 1994. Snook ledde en omfattande utredning av denna tragiska händelse men fann ingen som kunde pekas ut som skyldig. Han förklarar istället hur systemet som fanns på plats i Irak var reglerat till viss överdrift, med en önskan att vara säker på att kontrollera alla risker till det yttersta. Systemet konstruerades som ett centraliserat system och var på många sätt ”tightly coupled” (se tidigare blogg-inlägg). När systemet driftsattes upptäckte man efter ett tag att allt inte fungerade som det var tänkt. Det fanns sådant som personalbrist, utrustning som saknades eller inte fungerade, brister i utbildning osv. Det fanns ändå ett jobb att sköta och metoder utvecklades och anpassades för att lösa uppgiften trots bristerna. Det innebar samtidigt en drift. Situationen utvecklades också så att delar av systemet inte längre var ”tightly coupled” vilket innebar att vissa delar kunde utsättas för drift utan att påverka andra delar.

Bland exemplen på detta var att F-15 normalt verkade på högre höjd. Man fokuserade på att kunna identifiera flygplan som fanns på de höjderna. Radioutrustning och kommunikation med AWACS var anpassad för att lösa uppgifter på hög höjd. Helikoptrar å sin sida opererade på låg höjd, med dålig radiotäckning, inget behov av samverkan med AWACS osv. Till slut kom då dagen då två ”loosely coupled” system blev ”tightly coupled”. Två F-15 skulle identifiera två misstänkta helikoptrar som saknade ”IFF” (”transponder”), felidentifiering orsakad av bland annat brister i utbildning och till slut nedskjutning där orsakerna var många men där ”drifting” av ”loosely coupled” system spelade en roll.

Drift innebär också att skillnaden mellan beskrivningen av våra system (work-as-imagined) och den verkliga funktionen hos våra system (work-as-done) ökar. Det är ofrånkomligt att det alltid kommer att finnas en skillnad men blir den för stor skapar det problem.

Skulle något sådant här kunna hända i våra organisationer? Det är säkert möjligt men det är också väldigt svårt att upptäcka. I synnerhet om man enbart tittar på regelverk och procedurer och missar att följa upp den anpassning och drift som hela tiden finns och sker. Fortsättning följer.