Tjekliste: Giver dine incident-kategorier mening?

Dit team bruger sikkert masser af tid på at kategorisere jeres incidents. Men til hvilket formål? Hjælper det teamet med at håndtere incidents hurtigere? Tjek de følgende 6 spørgsmål for at se, om du får mest muligt ud af din kategorisering.

Hvorfor skal man overhovedet kategorisere incidents?

Lad os først og fremmest starte med det mest grundlæggende spørgsmål: Hvorfor skal man overhovedet kategorisere incidents? Er de oplysninger virkelig nødvendige? Kan man ikke bare registrere en sag og så er det det?

Kategoriseringen af incidents tjener to primære mål: at kortlægge og rapportere.

Kategoriseringen hjælper dig med at få sagen hurtigt videre til det rigtige team. I de fleste tilfælde er det en manuel proces, som i nogle tilfælde automatiseres ved hjælp af AI eller baseres på særlige, udløsende ord.

Kategorier hjælper dig også med din root cause-analyse, og du får indsigt i tilbagevendende incidents. Det gør det muligt for dig at løse underliggende problemer, generere relevante vidensartikler eller automatisere processer, som f.eks. nulstilling af adgangskoder.

1. Hvordan skal du organisere dine kategorier?

Vi ser alle mulige løsninger på det i praksis. Jeg anbefaler, at du baserer dine kategorier på dine services og symptomer.

Din primære kategori er de services, du leverer, som f.eks. ‘e-mail’, ‘arbejdsstation’ eller ‘onboarding/offboarding’. For hver kategori, viser du symptomerne vedrørende de services, som f.eks. ‘blokeret e-mail’, ‘forespørgsel om vare til arbejdspladsstation’ eller ‘nyansættelse’.

Et par tips om kategorierne:

Undgå at gøre dine underkategorier for specifikke. Jeg ser en masse organisationer, der definerer servicen (‘e-mail’) i den primære kategori og den mulige årsag i underkategorien (f.eks. ‘mailserver nede’ eller ‘fejl i Outlook’). Pointen er: når du registrerer sagen, ved du endnu ikke, hvad der forårsager problemet. Hvis du foretager et forkert skøn ved starten af incidenthåndteringen, skal du justere kategoriseringen ved sagshåndteringen.
Undgå at fokusere for meget på at matche dine kategorier med din serviceportal. Enhver service kan bestå af en række forskellige opgaver til dine teams. Selv om disse opgaver ligger i flere forskellige kategorier, vil du stadig vise en enkelt, komplet service til dine kunder.

2. Hvor mange niveauer bør dine kategorier have?

To. Det rigtige svar er: ikke flere end strengt nødvendigt. Men i de fleste tilfælde, vil to kategorier være mere end nok. Her er årsagen:

Du ønsker ikke, at dit team skal logge sig selv halvt ihjel. Og du vil heller ikke have, at kategorierne bliver for komplekse for dem, der bruger din serviceportal. Det er fristende at gå i dybden med kategorierne, men det gør bare kategoriseringen mindre gennemsigtig.
Du vil gerne gøre det nemt at vælge en kategori. Hvert ekstra kategoriniveau gør det bare mere komplekst og tidskrævende at vælge den rigtige kategori. Nogle gange ved du hvilken underkategori, du skal bruge. Du kan bare ikke lige huske, hvilken primær kategori den tilhører. Det kan være udfordrende at bruge ‘reverse engineering’ til at finde rundt i de to øverste kategoriniveauer
Det er ikke enhver lille information, der skal være en del af din kategorisering. Du behøver ikke fortsætte med at fordele incidents i mindre kategorier. Hvilket fører os til det næste spørgsmål.

3. Hvilke oplysninger skal så ikke være med i din kategorisering?

Nogle gange ser jeg, at organisationer bruger kategoriseringen til at registrere oplysninger, der bedre kan registreres på en anden måde. Her er to eksempler på information, der ikke hører hjemme i kategoriseringen:

Assets, som problemet vedrører. Hvis du bruger specifikke assets i din kategorisering, som f.eks. en bestemt type bærbar, så skal du justere dine kategorier, når organisationen introducerer en ny bærbar. Det er bedre at nævne det relevante asset i selve sagen og linke til det.
Afdeling eller team. Jeg ser ofte, at kategorier afspejler afdelinger (f.eks. ‘IT-services’, ‘Facility services’) eller teams (f.eks. ‘Databaseteam ‘eller ‘Applikationsstyring’). Problemet er, at når man registrerer sagen, ved man sjældent, hvem der kommer til at håndtere den.

4. Er der et maksimalt antal kategorier?

Ikke rigtigt. Som med antallet af kategoriseringsniveauer, er det rigtige svar her: introducér kun de strengt nødvendige.

Vi plejer at bruge 7×7-reglen som udgangspunkt. Prøv at begrænse det til 7 kategorier plus 7 underkategorier for hver kategori.

Uden at følge det slavisk. Hvis der er en servicedesk, som bedst arbejder med 8, 9 eller 10 kategorier, så er det helt fint. Hvis du pludselig arbejder med mere end 10, skal du nok overveje, om der virkelig er brug for alle de kategorier.

5. Skal vi have en kategori, som hedder 'Andet'?

Spørgsmålet plejer at skabe temmelig intense diskussioner. Min mening: ja, inkluder gerne ‘Andet’ som en kategori. Jeg har talt med fagfolk, der ivrigt raser mod det ubegrænsede rum, som kategorien kan medføre, så hvorfor er jeg for den?

Hvis du ikke har et specifikt sted til de incidents, der er svære at kategorisere, tvinges du til at bruge nogle kategorier, der ikke passer perfekt, hvilket eliminerer formålet med kategorierne fuldstændigt. Enhver kategori kan indeholde et vilkårligt antal incidents, der ikke hører til i den. En ‘Andet’-kategori fortæller dig, at du har incidents, der er svære at klassificere, og den kortlægger omgående de incidents for dig. Og hvis din ‘Andet’-kategori altid er fyldt, kan den endda give nogle nyttige oplysninger, der kan hjælpe dig med at forbedre dine kategorier.

6. Hvad skal du kigge efter, når du gennemgår kategorierne?

Når du har besluttet, hvilke kategorier, der fungerer bedst for dig, skal du fortsætte med at gennemgå og justere systemet, mens du bruger det. Lav en månedlig gennemgang efter implementeringen eller tilpasningen af dine kategorier. Det bør være nok med en kvartalsvis gennemgang efter et par måneder. Hvad er det, du bør kigge efter, når du gennemgår kategorierne?

Tjek kategorien ‘Andet’. Indeholder den en masse sager? Måske bør du introducere en ny kategori. Bruger nogle teammedlemmer kategorien regelmæssigt? Giv dine teammedlemmer en bedre forklaring.
Tjek brugen af alle kategorierne. Indeholder nogle kategorier rigtigt mange eller kun få sager? Del eller fjern en kategori. I dette blogindlæg, giver Julie Mohr følgende retningslinjer: ‘Hvis du har et CTI-element (bucket), der indeholder 25 procent af dine tickets, er strukturen måske ikke detaljeret nok. Hvis din ‘bucket’ rummer mindre end to procent, er den sandsynligvis for specifik. ‘
En af de store fordele ved kategoriseringen af incidents er analysen af de grundlæggende årsager (root cause-analysen). Dine incidents samles, så analysen af grundlæggende årsager, ved hver gennemgang, hjælper dig med at finde og løse de underliggende problemer ift. lignende eller tilbagevendende problemer.

Vil du vide mere om best practice?

Så har du mulighed for at downloade vores best practise service management e-bog, hvor du bl.a. kan lære mere om, hvordan du får en mere kundeorienteret it service management.