Flowchart for incident management-processen — Excel

Kort fortalt

• 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

Kildetabellen: Flowchart for incident management-processen

Skriv ét trin pr. række i Excel. Brug en entydig nøgle, en beskrivelse, næste trin og en ansvarlig rolle. 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.

Overfør beskrivelsen til Box text, målet til Line to, grenens navn til Line text og den ansvarlige til Vertical lane. 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. Kontrollér alle grene og ansvarlige i diagrammet mod regnearket. Se også /da/guides/sadan-struktureres-excel-data-til-et-rutediagram.

Sådan fungerer det

1. Omdøb banerne til jeres rigtige roller

   Skriv ét trin pr. række i Excel. Brug en entydig nøgle, en beskrivelse, næste trin og en ansvarlig rolle. 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

   Overfør beskrivelsen til Box text, målet til Line to, grenens navn til Line text og den ansvarlige til Vertical lane. 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

   Følg både normalforløb, afvisninger og tilbagekoblinger i det viste diagram, før du deler det. 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.

Faldgruber du skal undgå

• Manglende forbindelser

  En opgaveliste er ikke et procesdiagram, før hvert trin har en tydelig destination og beslutningerne har navngivne udfald. I skal skrive eller opdatere servicedeskens runbook, så nye medarbejdere kan se, hvor en sag går hen, og hvem der ejer hvert trin

Ofte stillede spørgsmål

Kan jeg bruge min egen Excel-fil?

Ja. Tilpas kolonnerne til QueryCharts arkindtastning, og kontrollér destinationerne, når rækkerne ændres. 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.