Sådan laver du en incident management-proces

Kort fortalt

• Prioriteten regnes ud fra felterne ved registreringen, ikke fra hvor slem hændelsen føles.
• Én vej for alle hændelser er for tung til de små og for stilfærdig til de alvorlige.
• At hæve eller sænke alvorligheden midt i en hændelse kræver sin egen tegnede vej, som de fleste diagrammer udelader.
• At genoprette servicen og at forklare den er to processer med en overdragelse imellem.
• Lukning kræver anmelderens bekræftelse, ikke teknikerens overbevisning.

Alvorlighed er ikke et felt, det er hele processen

Incident management genopretter en service og gør derefter rede for, hvad der skete. Den version, de fleste organisationer tegner først, er én vej (registrér, diagnosticér, ret, luk), og den fejler i begge retninger på én gang. Den er for ceremoniel til den printer, ingen kan nå, så folk holder op med at oprette sager og ringer til en kollega i stedet, og den er alt for stilfærdig til det nedbrud, der burde have vækket tre mennesker.

Prioriteten sættes ud fra konsekvens og hastende karakter, før nogen ved, hvad der er i stykker, og alt derefter dimensioneres af det ene skøn: hvem der bliver ringet op, hvor ofte interessenter hører fra jer, hvilket ur rettelsen måles imod. Kategoriseringen er derfor det bærende trin, og den træffes på delvis information, så den vil af og til være forkert, og det betyder, at omklassificering hører på kortet som en tegnet vej frem for som en stille rettelse i et felt.

Eksemplet fører en hændelse gennem fem faser og fire baner, og den række, der er værd at stirre på, er »Undersøg og diagnosticer«: en erklæret større hændelse og en sag, første linje ikke kunne løse, lander i samme kasse. Alvorligheden afgør, hvem der bliver kaldt, og hvilket ur der løber, ikke hvem der til sidst diagnosticerer, og det er den ærlige grænse for diagrammets proportionalitet. Bemærk også, at »Er årsagen stadig ukendt?« stilles ét sted for alle alvorligheder, og det er derfor en P1 og en P4 efterlader samme dokumentation.

Ét skøn af alvorlighed, og alt derefter

Hold øje med, hvor meget »Større hændelse?« afgør, før nogen diagnosticerer noget: en krisebro, en orientering af interessenter og et skift af ejerbane.

1. En tynd sag er en forkert prioritet

   Registreringen fylder to rækker: »Hændelse opdaget eller anmeldt« og »Registrer hændelse med konsekvens«. Alt, prioriteten regnes ud fra, opsamles i den anden (berørt service, hvor mange der er ramt, hvornår det begyndte, symptomerne), så en tynd sag forsinker ikke kategoriseringen, den fordrejer den.

2. Alvorligheden dimensionerer det følgende

   Ja-udgangen fra »Større hændelse?« er ikke en højere version af samme vej: »Erklær større hændelse« og »Åbn krisebro og orienter interessenter« sker begge, før nogen diagnosticerer noget, og ejerskabet flytter fra Servicedesk til banen Incident manager. Nej-armen kommer i næste etape.

3. To veje til en genoprettet service

   »Løst i første linje?« holder de små korte: dens ja-udgang går til »Udfør løsning i første linje«. Resten går videre til banen Support niveau 2 / 3, hvor »Løsning inden for SLA-målet?« stilles efter diagnosen, så »Eskaler SLA-brud og orienter interessenter« rapporterer et brud, det er for sent at forhindre.

4. Genåbningen springer kategoriseringen over

   Udgangen »Genåbnet« fra »Bekræfter brugeren løsningen?« træder ind igen ved »Foretag indledende diagnose«, som ligger under skønnet af alvorligheden, så en genåbnet hændelse bliver diagnosticeret igen, men aldrig omklassificeret, uanset hvad den anden fejl har kostet nu. »Opret problemsag« er dér, årsagen forlader forløbet.

Sådan fungerer det

1. Skriv prioritetsmatrixen, før du tegner

   Prioriteten er konsekvens holdt mod hastende karakter, og begge har brug for angivne niveauer: hvor mange brugere, hvilken serviceklasse, om penge eller sikkerhed er involveret, hvor hurtigt skaden vokser, om en midlertidig løsning holder. Aftal dem først, for en matrix opfundet undervejs i kortlægningen beskriver den seneste hændelse frem for den næste.

2. Beslut, hvad en større hændelse reelt ændrer

   List, hvad erklæringen udløser: en navngiven ejer, en krisebro, opdateringer på et fast ur, tilladelse til at omgå den normale ændringsgodkendelse. Ændrer intet sig ud over etiketten, er grenen udsmykning. Eksemplet bruger to hele trin på den, og det er den ærlige mængde arbejde, der ligger i det.

3. Skriv registrering og kategorisering som rækker

   Hver række i QueryChart er en kasse. Skriv udløseren i kolonnen Bokstekst, derefter registreringstrinnet, derefter kategoriseringstrinnet, og peg hver række på den næste i kolonnen Linje til. Tre rækker inde har kortet fremført sit argument: prioriteten i række 3 regnes ud fra det, række 2 opsamlede, og det gør række 2 til et designvalg og ikke en formular.

4. Forgren skønnet af alvorlighed, og navngiv begge udgange

   Skift kategoriseringsrækkens kolonne Figur til Beslutning, list begge destinationer i Linje til, og giv derefter hvert nummer sit svar i Linjetekst. Diagrammet forgrener sig én gang, ved »Større hændelse?«, selv om matrixen har fire eller fem niveauer, og de to tekster gør mere arbejde end noget andet par her, fordi de er det eneste sted, vejen ændrer sig.

5. Peg genåbningsvejen på et lavere rækkenummer

   En rettelse, anmelderen afviser, går tilbage til diagnosen: udgangen »Genåbnet« fra række 15 peger på række 7. En forkert sat alvorlighed har brug for samme behandling, og eksemplet tegner den ikke: tilføj en gren fra diagnoserækkerne tilbage til »Kategoriser og sæt prioritet«. Hver af dem er et lavere nummer i kolonnen Linje til.

6. Kalibrér matrixen, og navngiv så, hvem der erklærer

   Læg matrixen, hvor den, der registrerer sagen, kan læse den, og test den derefter: giv to personer på hver sin vagt de samme tre beskrivelser, og sammenlign, hvad de sætter. Uenighed betyder et manglende niveau, ikke en skødesløs kollega. Navngiv derefter den person på hver vagt, der må svare ja ved »Større hændelse?«, før incident manageren er vågen.

Faldgruber du skal undgå

• Kategorisering efter diagnosen

  Til den tid er den eskalering, der betød noget, ikke sket, og prioritetsfeltet registrerer kun, hvor slemt det endte. Konsekvens og hastende karakter kan besvares, før årsagen kan, og det er derfor kategoriseringsrækken ligger som nummer tre.

• Den alvorlighed, sagen blev født med

  Konsekvensen vokser; det gør prioriteten ikke. Sat én gang i banen Servicedesk fastlåser den opkaldslisten og uret, og diagrammets ene vej bagud træder ind under den. Tegn omklassificering som en vej, og navngiv, hvem der må tage den.

• Genåbning ved at oprette en ny sag

  Den oprindelige lukkes inden for målet, en ny sag starter et frisk ur, og rapporteringen viser to hurtige rettelser i stedet for én mislykket. Tegn genåbningen som en retur til diagnosen på den samme sag.

• Problemsager uden ejer

  »Opret problemsag« er en række, ikke et resultat. En sag uden ejer, uden dato og uden link tilbage til de hændelser, der skabte den, er lukningspapirarbejde, og den bliver lukket ulæst ved næste oprydning. Navngiv begge, når I opretter den.

Lav jeres egen incident-proces

Åbn incident-eksemplet som jeres eget diagram, skriv jeres grænser for alvorlighed på kategoriseringsrækken, og læg jeres vagtroller i banerne.

Lav jeres egen incident-proces

Relaterede guides

• Sådan laver du et SOP-flowchart
• Sådan kortlægger du en godkendelsesproces
• Hvordan man skriver en SOP

Ofte stillede spørgsmål

Hvad er forskellen på en hændelse og et problem?

En hændelse er en afbrydelse af en service; et problem er den underliggende årsag til en eller flere hændelser. De holdes som adskilte processer, fordi de kører på forskellige ure: incident management måles på tid til genoprettelse, problem management på, om årsagen faktisk er fjernet, og det kan tage uger. At lægge dem sammen betyder, at arbejdet med årsagen arver hændelsens hastende karakter og opgives i det øjeblik, servicen er tilbage.

Hvordan fastsætter man prioriteten på en hændelse?

Ud fra konsekvens og hastende karakter i en offentliggjort matrix, ikke ud fra hvem der spørger. Konsekvensen er, hvor stor en del af organisationen der er ramt: brugere, lokationer, serviceklasse, om penge eller sikkerhed er involveret. Hastende karakter er, hvor hurtigt skaden vokser, og om en midlertidig løsning holder. Matrixen gør det par til en prioritet, og den fortjener kun sin plads, hvis tallene bag skønnet registreres sammen med den: en prioritet, ingen kan rekonstruere, kan ikke bestrides, når den viser sig at være forkert.

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

Når den krydser en grænse, der er aftalt på forhånd: en service i topklassen nede, et angivet antal mennesker der ikke kan arbejde, myndighedsmæssig eller sikkerhedsmæssig eksponering, et formodet brud. Erklæringen fortjener kun sin plads, hvis den ændrer adfærd: en navngiven incident manager, en krisebro, opdateringer med fast kadence. At erklære for sent er den almindelige fejl, og prisen for at erklære og så trappe ned er langt lavere end prisen for en time i stilhed.

Skal en genåbnet hændelse være en ny sag?

Nej: genåbn den oprindelige, for de to sager besvarer forskellige spørgsmål. En ny sag nulstiller uret for løsningen og rapporterer én mislykket rettelse som to lykkede, og det er præcis den fordrejning, der skjuler en ustabil service. At genåbne på samme sag holder historikken samlet og gør genåbningsraten målbar, og genåbningsraten er det mest ærlige kvalitetssignal, en incident-proces producerer.