Sådan laver du en incident management-proces
Sådan designer du en incident management-proces, hvor alvorligheden dimensionerer alt nedstrøms: kategorisér før du diagnosticerer, tegn omklassificering som en vej, og send årsagen til en separat problemsag.
Sådan fungerer det
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.
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.
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.
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.
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.
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.
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.