Ur en experts perspektiv:
Tänk om informationssystemen inte fungerar som de ska?

Ibland fungerar informationssystemen precis som de ska. En ny version tas i produktion, integrationerna surrar nöjt i bakgrunden och användarna fortsätter sitt arbete i vardagen medan de drar nytta av de nya funktionerna som införts i systemet. Utvecklarna ger varandra high fives och går vidare till nästa leverans.

Störningar uppstår sällan helt utan förvarning. I produktionsmiljön finns olika övervakningsfunktioner, en slags vaktmästare för systemen, som dygnet runt följer hur tjänster, integrationer och processer fungerar. Om något stannar upp, blir långsammare eller beter sig oväntat kan ett larm gå redan innan någon användare hunnit märka något.

Men alla oväntade gäster anmäler sig inte hos vaktmästaren. Vissa smyger in obemärkt och upptäcks först i användningen, när en användare stöter på en situation som inte fungerar som förväntat. Då är det ofta användaren som gör den första observationen.

Och så finns det de där andra dagarna

Ofta börjar en störning inte med en stor smäll. Den börjar med att ett meddelande dyker upp i Teams:
– Vet någon varför det här inte fungerar?
Snart kommer ett svar:
– Samma här!
En tredje person bekräftar att problemet återkommer även för henne, en fjärde berättar att allt fungerar hos honom. Misstankarna väcks: Var ligger felet? I systemet, integrationen eller hos användaren? Snart pågår en livlig diskussion.

Situationen påminner ibland om nyhetsrapportering i medierna. Först kommer en enskild observation, sedan ögonvittnesskildringar och till slut flera konkurrerande teorier om vad som egentligen har hänt. Rubrikerna är nästan färdiga redan innan utredningen har börjat:
Lansering orsakade problem! Integration återigen boven i dramat?Användare förbryllade!
Faktum är att något inte fungerar som det ska. Allt annat klarnar först när saken utreds närmare.

Här finns den viktigaste lärdomen i en störningssituation: En Teams-diskussion, en e-posttråd eller funderingar vid kaffemaskinen kan hjälpa till att dela observationer, men den egentliga störningshanteringen börjar först när en störningsanmälan görs.

Ur produktionens perspektiv är en störningsanmälan ungefär som ett samtal till nödcentralen. Ingen förväntar sig att den som gör anmälan exakt ska veta var felet ligger eller vad som orsakat det. Det räcker att någon berättar vad som hände, var det hände, när det hände och hur problemet visar sig för användaren.

Därefter börjar den del av arbetet som användarna sällan ser. En tät dialog förs med systemleverantören, loggar analyseras, integrationer granskas och beteendet i test- och produktionsmiljöer jämförs. Samtidigt bedöms störningens omfattning: berör problemet en enskild användare eller en hel användargrupp, en funktion eller flera processer, ett system eller flera? Handlar det om en ensam dominobricka som fallit eller om att hela raden redan har börjat rasa? Ju bättre störningens konsekvenser förstås, desto snabbare kan de korrigerande åtgärderna riktas till rätt plats.

På jakt efter ledtrådar

I informationssystemens värld hittas grundorsaken sällan blixtsnabbt. Verkligheten liknar snarare en kriminalroman där den skyldige verkar uppenbar redan på sida 20, men där man på sida 200 inser att hela historien egentligen handlade om något helt annat. Först i de sista kapitlen faller alla ledtrådar på plats.

Ibland verkar en integration ha gått sönder, men grundorsaken finns i källsystemet. Ibland sammanfaller en ny lansering tidsmässigt med en störning utan att ha någon som helst koppling till den. Och ibland hittas problemet precis där man minst hade väntat sig det. Men grundorsaken kan bara fastställas genom utredning. Det viktigaste är trots allt att störningen utreds och åtgärdas så att liknande problem kan undvikas i framtiden.

Den viktigaste uppgiften för den styrmodell som vägleder utvecklingen och den produktionsmodell som styr driften är inte att förhindra att fel uppstår. Det vore förstås fint, men ungefär lika realistiskt som tanken på en finsk sommar utan myggor. Det verkliga målet är att rätt experter snabbt får information när något går fel, att utredningen inleds omedelbart och att de korrigerande åtgärderna kan riktas till rätt plats.

När något går fel

I slutändan är det inte avgörande om fel uppstår i systemen, för det gör de. Det avgörande är hur snabbt de upptäcks, hur väl man kommunicerar om dem och hur effektivt de kan åtgärdas.

Nästa gång du upptäcker något ovanligt, stanna därför upp en stund och bedöm situationen. Om du misstänker att det finns ett fel i systemet, gör en störningsanmälan. Om du däremot är osäker på om det handlar om ett fel eller om systemets avsedda funktion, kontrollera först saken med den instans som ansvarar för användarstödet. Ofta kan användarstödet lösa situationen, men ibland döljer sig något i bakgrunden som kräver en mer ingående utredning.

Ibland känns det som ett extra arbete att göra en störningsanmälan. Särskilt när man redan har en färdig teori om vad som är fel. Men i produktionen är en misstanke ännu inte en observation, och en observation är ännu inte en grundorsak. Störningsanmälan är det första konkreta steget från observation till grundorsak.

Förvånansvärt ofta börjar en berättelse med en störningsanmälan, en berättelse som gör att produktionen fungerar lite bättre i morgon än den gör i dag.

Författare

Mari Voutilainen, UF-centret, enhetschef för Digitaliseringsstöd och produktchef för allmänt bidragssystem (YA)