En incident inträffar när en tjänst inte längre fungerar som den ska. Där kommer incidenthanteringsprocessen in. Den ansvarar för att du så snabbt som möjligt ska hitta en lösning på incidenten, för att återställa tjänstens tillgänglighet.
Här går vi igenom hur du kan utveckla en incidenthanteringsplan. Och en checklista för incidenthanteringsrutin. Bland annat.
Syftet med en incidenthanteringsprocess är att hantera incidenter för att en verksamhet ska påverkas så lite som möjligt och återställa tjänsten till normalt läge så fort som möjligt. Den omfattar alla händelser som på ett eller annat vis stör eller kan störa en tjänst oavsett om det är slutanvändaren som upptäckt och rapporterat incidenten, eller om incidenten upptäcks av en tekniker inom driften.
1. Mottagning och identifiering av incident
Ärendet tas emot och identifieras via en av de etablerade kommunikationsvägarna, till exempel:
2. Loggning av ärende
Incidenten loggas. I loggningen ska det ingå vem som är slutanvändare/kund. En beskrivning av ärendet, samt tidpunkt för när rapporten om incidenten mottagits. Detta gäller oavsett om incidenten rapporterats via er helpdesk eller om den upptäckts inom driften.
Den här information ska finnas med i varje ärende:
3. Kategorisering av ärende
Kategorisering av ärendet ingår i loggningen. Incidenten klassificeras med hjälp av tidigare fastställda kategorier, för att rätt avdelning och handläggare ska kunna tilldelas incidenten. Det är också viktigt med denna kategori-indelning för att kunna få ut olika typer av statistik.
4. Prioritering av ärende
Ärendet prioriteras utifrån vilken påverkan incidenten har på tjänsten. Och hur brådskande det är att lösa den. Prioriteringen av incidenten styrs utifrån era policyer för SLA (Service Level Agreement – Servicenivåavtal) som finns med kunden. Använd en realistisk SLA-definition för att kunden ska ha realistiska förväntningar.
5. Tilldelning och Eskalering av ärende
Antingen tilldelar mottagaren ärendet till sig själv; om denne inte kan lösa incidenten på egen hand tilldelas ärendet till någon annan inom gruppen. Eller andra grupper och avdelningar.
6. Analys av tidigare incidenter och kända fel
Om incidenten mottagits via er helpdesk behöver en inledande analys genomföras för att få en så tydlig bild av incidenten som möjligt. Det är här insamlad information används om tidigare beskrivna incidenter och deras lösning, information om kända fel samt information om en potentiell workaround.
7. Utarbetning, implementering och dokumentering av lösning
En lösning utarbetas för att sedan implementeras och lösa incidenten. Det är viktigt att dokumentera incidenten och vilken åtgärd som togs, för att samla in viktig information. För när nya, liknande incidenter, kommer in som bidrar till att man då snabbt kan lösa dem. Dokumentationen för incidenten och lösningen ska vara utformad på så sätt att den enkelt kan återrapporteras till kund och lätt går att hitta vid ett senare tillfälle.
8. Verifiering av lösning
En verifiering av att ärendet är löst görs. Det kan ibland vara svårt att göra denna verifiering praktiskt vid incidenter initierad av slutanvändaren, då görs det istället ofta med hjälp av automatiserat mail; mailet skickas till användaren där man informerar om att ärendet kommer avslutar inom t.ex. 48 timmar om användaren inte återkommit.
9. Stängning av ärende
Ärenden som initierats av slutanvändaren stängs av helpdesken när en avstämning med användaren gjorts om att det är OK att stänga ärendet och incidenten är löst.
För att stödja er incidenthanteringsprocess och incidenthanteringsteam rekommenderas ni att ta fram en incidenthanteringsplan. Incidenthanteringsplanen ska vara ett stöd för er och underlätta processen; därför tjänar det inget till att skapa ett dokument med tusentals sidor som är jobbig att både använda och uppdatera. En incidenthanteringsplan ska vara konkret och praktiskt användbar.
För att framställa en bra plan rekommenderas ni att utgå från verifierade säkerhetsstandarder, såsom ISO 27000-serien. Det finns mängder med mallar på nätet att använda som utgångspunkt. Är ni osäkra på vad man ska tänka på vilka delar som bör ingå kan det vara en god idé att ta hjälp utifrån från en extern aktör för att underlätta arbetet.
En incidenthanteringsplan bör åtminstone innehålla följande information:
Nöjda kunder är alla supporterande avdelningars mål – vi är väl medvetna om det. Därför har vi teamat upp med TOPdesk. De har stor erfarenhet av ITIL incident management och har utvecklat ett användarvänligt och effektivt verktyg för incidenthantering som hjälper er förbättra kundkommunikation, hantera arbetsflöden och hålla koll på era tillgångar.
Testa TOPdesk incidenthanteringssystem gratis idag.
Lär er allt ni behöver om incidenthantering, vad en incident är, vad ITIL incident management är och dess fördelar samt bästa praxis.
Se vilka skyldigheter ni har gällande hanteringen av personuppgifter i TOPdesk.
Din ITIL certifierade helhetspartner
inom digital förnyelse
Rusta dig för framtiden med digitala systemlösningar och tjänster från oss. Vi finns med dig hela vägen från implementation, support till förvaltning. Tillsammans ser vi till att göra övergången till det digitala så smidigt och framgångsrikt som möjligt.