Incident Management (IM) är den mest spridda processen av alla inom ITIL. IM har till syfte att återställa IT-tjänster/system så snabbt som möjligt och i enlighet med överenskommen SLA (Service Level Agreement). I denna artikel beskriver vi mer om vad IM innebär och varför det behövs.
Incident Management är den mest spridda processen av alla inom ITIL. I denna artikel beskriver vi vad det är och varför det behövs.
För att förstå Incident Management är det bra om vi först definierar vad som menas med en incident. En incident är i det här sammanhanget en oplanerad störning eller en kvalitetsförsämring i en IT-tjänst eller ett fel på ett konfigurationsobjekt som ännu inte har påverkat en IT-tjänst.
Incident Management (IM) har till syfte att återställa IT-tjänster/system så snabbt som möjligt och enligt överenskommen SLA (Service Level Agreement). Primära aktiviteter i incidentprocessen är att upptäcka, registrera, analysera, identifiera åtgärd och att införa åtgärd. För att minimera riskerna för att liknande incidenter ska uppstå i framtiden krävs det också att man åtgärdar den underliggande orsaken till incidenten.
Målet med Incident Management är att minimera negativa effekter på verksamheten och återställa fel utan dröjsmål. Processen triggar också Problem Management, som genomför en grundorsaksanalys.
Incident Management-processen hanterar alla incidenter genom ett strukturerat arbetsflöde. Huvudaktiviteterna i incidentprocessen är att upptäcka, registrera, analysera, identifiera åtgärd, införa åtgärd, stänga incidenter samt förfrågningar och larm. Arbetet i incidentprocessen utförs främst med hjälp av olika ärendehanteringsverktyg.
En incident som inkommer till servicedesk följer ett flöde med olika aktiviteter:
Funktionen servicedesk är användarens/kundens centrala kontaktyta, en så kallad Single Point Of Contact (SPOC) mot verksamheten. Funktionen äger ansvaret för att snabbt och effektivt hantera incidenter, förfrågningar (service requests) och infrastrukturella larm (d.v.s. events).
En servicedesk, med stöd av ett lämpligt verktyg, är utrustad så att den kan leverera Incident Management på bästa möjliga sätt. En servicedesk organiseras i team med följande ansvarsområden:
First Level Support har till uppgift att registrera och klassificera incidenter. Den är kontaktytan mot verksamheten och användarna och saknar ofta tekniska förkunskaper. Här görs ett första försök att återställa en incident så fort som möjligt. Om ärendet inte kan åtgärdas skickas det vidare till Second Level Support-gruppen.
First Level Support är också ansvarig för att meddela användaren om incidentstatus.
Second Level Support övertar incidenter som inte kan åtgärdas av First Level support. Om ytterligare kunskap behövs för att åtgärda incidenten, till exempel en workaround, kontaktas aktuell mjukvaruleverantör. En incident som fortfarande inte kan åtgärdas vidarebefordras till Third Level Support och Problem Management.
Third Level Support finns vanligen hos externa hårdvaru- och mjukvaruleverantörer. Tjänsterna begärs av Second Level Support då deras tekniska expertis inte är tillräcklig eller om ytterligare kompetens krävs för att lösa en incident eller ett problem. Även här är målet att återställa en IT-tjänst så snabbt som möjligt. Third Level Support behöver oftast implementera en mjukvaruändring vilket också involverar Change Management-processen.
En Incident Manager bevakar och analyserar incidentprocessen samt ansvarar för att rutiner för eskalering, larm och informationsspridning samt andra processer följs.
Processägaren styr Incident Manager processen
Äger, övervakar och eskalerar
Identifierar och klassificerar (t.ex. hårdvara, bugg, applikation eller system)
Prioriterar enligt SLA
Levererar känd lösning och/eller workaround
Kommunicerar till användare eller Problem Management
Nedan följer några praktiska råd för införande av en Incident Management-process med verktygsstöd.
Vid implementering av Incident Management är det viktigt att ha målet i fokus och endast använda det som behövs från ITIL Best Practise.
Ett vanligt misstag är en implementation som genomförs i ett enda stort steg och med väldigt högt uppsatta mål. Vårt råd är att först genomföra en förstudie på den aktuella organisationens mognadsgrad och sedan följa en steg för steg process, och planera efter det. Om mognadsgraden för att hantera incidenter inte är speciellt hög kan man exempelvis förbättra First Level Support genom en Self Service-portal. Är däremot mognadsgraden hög kan en nollincidentstolerans vara ett realistiskt mål.
Ett annat vanligt misstag är att komplicera verktygsimplementationen. De verktyg som införs bör automatisera processer och minimera tidsåtgången för att åtgärda en incident och all data i en dashboard ska ge viktig information och insikt om incidenter. Samlad data ska kunna användas till utvalda KPI:er.
Några exempel på användbara KPI:er är:
Resolution within SLA, -procent åtgärdade incidenter enligt SLA (Service Level Agreement)
Number of repeated incidents: Antal upprepade incidenter
Number of escalations: Antalet eskaleringar för incidenter som inte åtgärdas inom överenskommen tid
Incidenter triggas ofta av ändringar och vid flera upprepade incidenter behövs problem management. Ett annat vanligt misstag är att det problem management som genomförs istället saktar ned processen. Se därför till att incidenten inte hanteras i en isolerad silo.
Hur hänger Incident Management ihop med övriga ITIL-processer?
Incident Management är nära förknippat med Problem Management och Change Management. Se skillnad med hjälp av följande exempel:
Vid en husbrand kommer brandbilar från två stationer samtidigt till branden. Det ena manskapet släcker både elden och ser till att minimera skadorna på infrastrukturen. Det andra manskapet fokuserar bara på att det ska gå snabbt att släcka elden, utan att undersöka orsaken till problemen.
Om man överför detta till incidenthantering så är det visserligen nödvändigt att den ger snabba resultat. Dock bör vi också ta reda på vad som i slutändan gick fel och varför det var ett problem från början.
Det är här Problem Management kommer in i bilden. Problemhantering är i detta exemplet undersökningsteknikerna som inte var på plats för att bekämpa branden utan kom först när den väl var släckt. Deras uppgift är att undersöka vad som gick fel, ta reda på hur elden började och utbilda människor att förebygga att något liknande händer igen.
Utan att ta sig tid att granska avslutade incidenter så kommer dem fortsätta att uppstå, kanske till och med öka i allvarlighetsgrad. En följd av en effektiv Problem Management insats kan vara att åtgärda mjukvara med en ändring som i sin tur kan involvera Change Management.
En viktig anledning till att införa Incident Management är att lista de problem som kan uppstå om man inte har Incident Management.
Bristande insyn i biljettstatus och förväntad åtgärdstid för slutanvändare
Ingen korrekt registrering av tidigare incidenter
Ingen möjlighet att dokumentera lösningar för upprepade eller kända problem
Högre risk för verksamhetsavbrott, särskilt vid större incidenter
Brist på rapporteringsförmåga
Minskad kundnöjdhet
I dag stannar många verksamheter utan ett fungerande IT och kostnaderna blir stora. Omsättningen minskar när en affärskritisk applikation drabbas av en incident. Incident Management omfattar hela incidenten, från upptäckt till åtgärd, och bör åtgärdas så snabbt som möjligt inom ramen för den Service Level Agreement man har för verksamheten.
Dessutom skapas en transparens inom Ticket Management genom att varje incident loggas så att man kan sammanställa rapporter.
Har du frågor om IT-styrning inom din organisation? Kontakta Midagon här så hjälper vi dig.
Det första intrycket är viktigt. Både när vi möter nya människor och när vi kommer in på vår nya arbetsplats ...
Läs bloggen
Som IT-ansvarig är en allt viktigare uppgift att onboarding och offboarding fungerar smidigt och effektivt. Det är inte bara en ...
Läs bloggen
Vad kan myndigheter och verksamheter göra för att minimera säkerhetsriskerna och att information kommer i fel händer? Att säkra upp ...
Läs bloggen
