Incident Management

Detta är en förkortad text, du hittar mer utförliga beskrivningar i boken

Det viktigaste vi har i en IT-organisation är vår IT-miljö. Det är med hjälp av den som IT-tjänster produceras och tillför nytta till verksamheten. Om IT-miljön skulle sluta att fungera stannar IT-tjänsten och då har verksamheten ingen nytta av IT-organisationen.

Det är med det perspektivet som IT-organisationen behöver en snabb och väl intrimmad process för att återställa fel som uppstår i IT-miljön. Om något inte fungerar av det IT-organisationen har lovat i överenskommelser med verksamheten så finns det just då ingenting som är viktigare.

En grundförutsättning för att incident management-processen ska fungera är att tydliga överenskommelser finns. Att det är helt klart vad som ska fungera och inte. Risken finns annars att processen fylls med ärenden som inte är direkt kopplade till ett fel i IT-miljön. IT-organisationen vänjer sig då med ett konstant flöde av incidenter och kopplingen till att incidenter är viktiga försvinner.

En incident definieras som:

”En incident är ett oplanerat avbrott eller en försämring i kvaliteten av en IT-tjänst. Ett fel på en komponent i IT-miljön som inte direkt påverkar kvaliteten i leveransen (till exempel en hårddisk med redundans) ska också klassas som en incident.”

Syfte

Huvudsyftet med incident management-processen är återställa överenskommen servicenivå så fort som möjligt och att minska de negativa konsekvenserna för verksamheten. Detta innebär att om IT-organisationen inte har möjlighet att åtgärda felet direkt kan en temporär lösning (Eng. workaround) som återställer funktionaliteten för användaren vara tillräcklig. Syftet innebär även att en incident ska åtgärdas så långt det är möjligt på ett sådant sätt att verksamheten inte ytterligare påverkas negativt.

Syftet med incident managementuppnås genom att:

  • Säkerställa att standardiserade metoder och rutiner används
  • Göra incidenter synliga internt och hos verksamheten
  • Agera professionellt genom att kommunicera och lösa incidenter snabbt när de uppstår
  • Utgå från verksamhetens prioriteringar vid prioritering av incidenter

Omfattning

Ordet incident betyder ”oväntad, störande händelse”. En översättning av incident managementblir då ”hantering av oväntade, störande händelser”. Detta betyder att förväntade, störande händelser inte omfattas av incident management-processen.

För att sätta en tydlig gräns på vilka störningar som kan förväntas och inte så regleras detta av den dokumentation som tas fram i release management-processen. Under testningen av releaser som driftsätts ska fel som upptäcks dokumenteras som kända fel. Denna dokumentation av kända fel används sedan som definition på vad som är oväntat eller förväntat. Det betyder att om ett av en användare anmält fel finns registrerat i listan av kända fel så ska ärendet inte betraktas som en incident. Skillnaden mellan ärendetyper och hur dessa ska hanteras finns beskrivet närmare i kapitlet om service desk-funktionen.

Alla incidenter i IT-miljön, oberoende av vem som upptäcker dem, omfattas av incidentprocessen. Alla incidenter som påverkar leveransen av IT-tjänster, oavsett vem som producerar tjänsten, ska omfattas av incidentprocessen. Det innebär att ett fel som uppstår hos en leverantör, som i sin tur påverkar leveransen av IT-tjänster, ska även det betraktas som en incident.

Prioriteringsmodell

Det är bra att använda en gemensam modell för prioritering oavsett ärendetyp. Det förenklar arbetet för den som ska prioritera och det minskar risken för missförstånd när ärenden skickas mellan olika delar av IT-organisationen.

Oavsett ärende så är första frågan vilken påverkan ärendet har för verksamheten just nu. Frågan besvaras med antingen högsom betyder att verksamheten inte kan fortsätta om ärenden inte hanteras, medel som betyder att verksamheten kan fortsätta med besvär eller lågsom betyder att verksamheten kan försätta utan besvär.

Därefter ställs frågan om vilken påverkan ärendet har för verksamheten inom överskådlig framtid enligt samma kriterier. Svaret på den frågan är ofta ett annat än svaret på frågan om påverkan just nu. Till exempel kan ett ärende som inte är tidskritiskt just nu få verksamheten att stanna om ärendet inte är löst om en månad.

Den tredje parametern är tidsramen för framtida påverkan. Den ska beskrivas som en tidsangivelse då ärendet senast måste påbörjas.

Prioriteringen görs sedan som en sammanlagd bedömning av nuvarande och framtida påverkan.

Prioriteringsnivån baseras med tyngdpunkt på nuläget. Det är därför viktigt att nuvarande och framtida påverkan beskrivs som text i ärendet så att alla ärenden löpande kan omprioriteras efter hand som tiden går. Här kan även tidsramen användas som flagga för omprioritering. Denna modell ger tillräckligt med information för att hantera omprioriteringen och även ett bra underlag om ärendet ska skickas vidare till en annan enhet inom eller utanför IT-organisationen.

Major incident

Service desk-funktionen som huvudsakligen hanterar incidenter är optimerad för genomströmning. Incidenter ska lösas så fort som möjligt och handläggarna i service deskska kunna hantera många ärenden per arbetspass. Därför finns det anledning att ha en separat rutin för incidenter som är av sådan storlek eller har sådan påverkan att de kräver all uppmärksamhet från IT-organisationen under hela incidentens livscykel. Sådana incidenter klassificeras som major incidents.

En major incident ska ha en separat fördefinierad rutin med snabbare eskaleringsvägar och större beslutskraft. Rutinen ska ha en väl definierad trigger som kopplas in i incidentprocessens prioritering. Ett separat team för lösning av incidenten bör sammankallas och innehålla:

  • Incident manager
  • Problem manager
  • Tjänsteansvarig
  • Systemspecialist och/eller tekniker
  • Dokumenterare
  • Kommunikatör

Även om lösningen på incidenten är uppenbar så ska ett problemärende skapas för att förhindra att incidenten återkommer. Ärendet ska hållas avskilt under hela incidentens livscykel så att det inte riskerar att fördröja lösningen. En major incident ska alltid avslutas med en utvärdering av arbetet så att rutinen kontinuerligt förbättras.

Aktiviteter

Incident Management process

KONTAKTA OSS

VI är inte online just nu, men skicka oss ett meddelande så svarar vi dig så fort vi kan.

Sending

©2019 OpenTRIM® a model to ease the adoption of ITIL®, OpenTRIM® is a registered trademark of OpenTRIM AB. All rights reserved. ITIL® is a registered trademark of AXELOS AB. All rights reserved.

Log in with your credentials

Forgot your details?