Flowchart for incident management-processen

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.