Flowchart for incident management-processen

Hvad er flowchart for incident management?

Incident management er processen, der genopretter normal drift hurtigst muligt, når noget går i stykker. Formålet er bevidst snævert: få brugeren i gang igen. At finde og fjerne den bagvedliggende årsag permanent er problem management, som denne proces overleverer til frem for at rumme. Netop den grænse er det, der forhindrer en servicedesk i at holde sager åbne i ugevis, mens en tekniker jagter en rodårsag.

De fleste incident-processer knækker i overleveringerne, ikke i det tekniske arbejde. En sag registreres uden nok oplysninger om konsekvensen til, at den kan prioriteres. En større hændelse opdages tyve minutter for sent, fordi ingen på forhånd har aftalt triggeren. En eskalering til 2. linje ligger og venter uden ejer. Et SLA-mål overskrides, og kunden hører om det bagefter i stedet for inden. En sag lukkes på teknikerens ord, uden at brugeren har bekræftet, at servicen faktisk virker. Når processen tegnes som swimlanes, bliver hver af de overleveringer synlig og får en navngiven ansvarlig.

Denne skabelon tegner forløbet i fire baner: Anmelder / bruger, Servicedesk, Incident manager og Support niveau 2 / 3. Den indeholder de to grene, teams oftest udelader af deres dokumentation (erklæringen af en større hændelse og eskaleringen ved SLA-brud), plus en genåbningsløkke til, når brugeren siger, at problemet stadig er der, og en gren ved lukning, der opretter en problemsag, når årsagen stadig er ukendt.

Hvad dette flowchart dækker

I denne skabelon

• Fire swimlanes med en navngiven ejer på hvert trin (Anmelder / bruger, Servicedesk, Incident manager og Support niveau 2 / 3) fordelt på fem faser fra opdagelse til lukning
• Opdagelse og registrering, hvor 'Hændelse opdaget eller anmeldt' fører videre til 'Registrer hændelse med konsekvens', før nogen triagerer, så sagen bærer berørt service, omfang og symptomer
• Kategorisering og prioritering efterfulgt af beslutningen 'Større hændelse?', hvis ja-gren kører 'Erklær større hændelse' og 'Åbn krisebro og orienter interessenter' i incident manager-banen, før den kobler sig på det tekniske arbejde igen
• Opdelingen mellem første linje og eskalering: 'Løst i første linje?' fører enten til 'Udfør løsning i første linje' eller sender sagen videre til niveau 2 / 3 for 'Undersøg og diagnosticer'
• Vejen ved SLA-brud: 'Løsning inden for SLA-målet?' sender et nej til 'Eskaler SLA-brud og orienter interessenter', så kunden får besked, før uret løber ud, og vender derefter tilbage til 'Udfør løsning og genopret service'
• Brugerens bekræftelse og lukning, inklusive en genåbningsløkke fra 'Bekræfter brugeren løsningen?' tilbage til den indledende diagnose, og grenen 'Er årsagen stadig ukendt?', der opretter en problemsag før 'Hændelsen er lukket'

Hvornår du skal bruge skabelonen

• I skal skrive eller opdatere servicedeskens runbook, så nye medarbejdere kan se, hvor en sag går hen, og hvem der ejer hvert trin
• I vil aftale triggeren for en større hændelse og eskaleringstiderne på forhånd i stedet for at improvisere dem midt i et nedbrud
• I skal konfigurere et ITSM-værktøj: kategorier, prioritetsmatrix, SLA-ure og eskaleringsregler i diagrammet svarer direkte til de felter, I skal sætte op
• I vil bringe et lille team på linje med ITIL-praksis uden at overtage hele begrebsapparatet, med trinnavne, folk faktisk siger højt
• I holder en evaluering af selve processen efter en hændelse og vil følge, hvor en konkret sag gik i stå i forhold til det tiltænkte forløb

Sådan fungerer det

1. Omdøb banerne til jeres rigtige roller

   Erstat Anmelder / bruger, Servicedesk, Incident manager og Support niveau 2 / 3 med de roller, der findes hos jer. Små teams lægger ofte incident manageren ind i servicedeskbanen, mens teams med en NOC tilføjer en overvågningsbane over anmelderen.

2. Definer jeres prioritetsmatrix

   Hæng jeres definitioner af konsekvens og hastende karakter på trinnet 'Kategoriser og sæt prioritet'. Skriv ned, hvad P1 til P4 betyder i antal berørte brugere og forretningsmæssig konsekvens, så prioriteten udledes frem for at blive forhandlet sag for sag.

3. Fastlæg triggeren for en større hændelse

   Beslut, hvad der gør beslutningen 'Større hændelse?' til et ja: en omsætningskritisk service nede, et navngivet kritisk system, en grænse for antal berørte kunder. Angiv, hvem der må erklære den, og hvad der sker umiddelbart efter: for eksempel at åbne en krisebro og starte en fast opdateringskadence.

4. Sæt jeres SLA-mål og eskalering ved brud ind

   Skriv jeres svar- og løsningsmål på beslutningen 'Løsning inden for SLA-målet?', og angiv, hvem der får besked på grenen for SLA-brud, og hvor lang tid før fristen. Grenens formål er tidlig varsling: ikke rapportering bagefter.

5. Aftal reglerne for lukning og problem management

   Definer, hvad der tæller som bekræftet af brugeren, hvor længe en sag står som løst, før den lukkes automatisk, og kriterierne i 'Er årsagen stadig ukendt?', der skubber en hændelse videre til problem management. Gentagne symptomer og alle større hændelser er de sædvanlige triggere.

6. Gennemgå den med hver bane, og udgiv en versioneret kopi

   Gennemgå diagrammet med folkene i hver bane, og ret trinnene til det, de faktisk udfører. Når det er aftalt, så udgiv det som den gældende version med en godkendelse, så enhver, der læser det senere, ved, hvilken revision der var i kraft.

Ofte stillede spørgsmål

Hvad er forskellen på incident management og problem management?

Incident management genopretter servicen. Problem management fjerner årsagen, så hændelsen ikke gentager sig. De kører på hver sit ur: en hændelse måles mod en SLA i minutter eller timer, mens en problemsag kan stå åben gennem ugers undersøgelse. I dette diagram mødes de to ved lukningen, hvor 'Er årsagen stadig ukendt?' opretter en problemsag uden at holde hændelsen åben. At blande dem sammen er den mest udbredte fejl, og den viser sig som sager, der står åbne længe efter, at brugeren er i gang igen.

Hvornår skal en hændelse erklæres som en større hændelse?

Når konsekvensen retfærdiggør at bryde den normale kø: en forretningskritisk service er utilgængelig, en stor gruppe brugere er blokeret, eller der er en sikkerhedsmæssig, økonomisk eller omdømmemæssig risiko. Triggeren skal være skrevet ned, før I får brug for den, og være objektiv nok til, at en førstelinjemedarbejder kan bruge den klokken to om natten. Når erklæringen først er sket, skifter processen form frem for bare at køre hurtigere: en navngiven incident manager overtager ejerskabet, en krisebro åbnes, og interessenterne opdateres på faste tidspunkter, uanset om der er nyt.

Hvad sker der, når en hændelse er på vej til at bryde sin SLA?

Grenen for SLA-brud er en hierarkisk eskalering, ikke en teknisk. Arbejdet fortsætter, men incident manageren trækkes ind for at justere forventningerne over for kunden, omfordele ressourcer om nødvendigt og notere, hvorfor målet ikke holder. Det vigtige er timingen: grenen skal udløses, før fristen er passeret (for eksempel ved 75 procent af den resterende tid), så samtalen med kunden ligger før bruddet i stedet for at være en undskyldning bagefter.

Hvem lukker hændelsen, og hvornår er den løst?

Løst og lukket er to forskellige tilstande. En tekniker markerer en hændelse som løst, når rettelsen er udført, og servicen er tilbage. Den er først lukket, når anmelderen bekræfter, at servicen virker for vedkommende: derfor går dette diagram gennem 'Bekræft at servicen virker' i anmelderbanen og beslutningen 'Bekræfter brugeren løsningen?' før lukning. Siger brugeren, at problemet stadig er der, genåbnes sagen til den indledende diagnose i stedet for at starte en ny. De fleste teams sætter også et vindue for automatisk lukning, typisk tre til fem arbejdsdage uden svar.