5 ITIL incident management best practices

16/07/2020

I sit forrige blogindlæg delte brancheekspert Stephen Mann ti praktiske tips til problem management. I dag skal han tale om ITIL incident management: et vigtigt fundament i enhver it-organisation. 

5 værdifuld ITIL best practices

I alle ITSM-blogs om populære emner som kunstig intelligens, digital transformation og enterprise service management, kan det være let at overse vigtigheden af ​​ITSM-hæfteklammer, såsom ITIL incident management. Men du må ikke undervurdere incident management – specielt fordi medarbejderoplevelsen i høj grad afhænger af kvaliteten af din servicedesk og deres evne til hurtigt at få medarbejderne til at være produktive igen.

Så hvordan kan din it-organisation forbedre sine ITIL incident management-funktioner? Her er fem best practices inden for ITIL incident management, som kan hjælpe dig med at forbedre din servicedesk.

1. Forstå, hvordan din servicedesk skaber værdi

Hvis svaret på spørgsmålet “Hvordan hjælper din servicedesk organisationen?” er “De løser it-problemer”, så har du stadig en masse arbejde at gøre i denne afdeling. Det er længe siden, at servicedesken kun var ”it-support”: de er faktisk ”people support”, da de både hjælper dine kunder og dine medarbejdere.

I dag ligger forretningsinteressenters fokus mere og mere på den værdi, som din it-organisation skaber, og ikke kun på dens omkostninger. Din servicedesk er ingen undtagelse. Så hvordan skaber din servicedesk værdi – eller forhindrer værdilækage for din organisation?

Desværre er der ikke noget konkret svar. Værdien af din servicedesk er i stedet noget, som du har brug for at opdage, ved at have proaktive diskussioner med dine vigtigste forretningsinteressenter. Din servicedesk kan muligvis tilføre værdi ved at løse it-problemer, der hjælper med at minimere produktionstab eller ved at udføre forebyggende vedligeholdelse.

Det er også sandsynligt, at forskellige interessenter har forskellige holdninger til, hvordan din servicedesk skaber værdi for deres drift, team og kunder. Nogle forretningsinteressenter, f.eks. en salgsdirektør, værdsætter måske minimalt medarbejdernes produktivitetstab. I dette tilfælde er det vigtigt at it-problemerne, der forårsager tabt salg, hurtigt bliver løst.

Du kan kun bestemme de forskellige definitioner af værdi ved at have kvalitetssamtaler med dine interessenter om; hvor din servicedesk hjælper, hvor den forårsager problemer og hvad du kan forbedre. Det er vigtigt at værdsætte, at dette skal være flerdimensionelt. Du skal anerkende den samlede påvirkning af din it-organisation, og at dine interessenters værdiopfattelse sandsynligvis vil ændre sig over tid.

Når du har fundet din servicedesks værdi, skal den videreformidles til din servicedesks strategi, mål, politikker, processer, serviceniveauer og metrics og KPI’er.

2. Gennemgå servicedeskens mål for serviceniveauet

Jeg taler ikke nødvendigvis om metrics, men snarere om nogle af de vigtigste serviceniveaumål, som din servicedesk i øjeblikket arbejder mod.

Tænk på følgende spørgsmål:

  • Hvornår satte du målene? (Måske var det, da servicedesken i sin tid blev oprettet?)
  • Var dine vigtigste interessenter enige om målene – og påvirkede de dem?
  • Hvornår opdaterede du sidst målene – i forbindelse med ændringer i forretningskravene, teknologien og medarbejderforventningerne?

Du skal forstå, hvor godt dine mål imødekommer virksomhedens behov. F.eks. hvordan hjælper håndteringen af incidents, der kommunikeres via e-mail inden for 24 timer, virksomheden? Tænk på dette gennem en værdilinse: koster forsinkelsen med at løse et problem mere, end hvis der blev brugt flere it-ressourcer til at sikre en hurtigere løsning?

Du finder kun ud af det, ved at spørge de mennesker, du leverer dine services til: dine medarbejdere og potentielt også dine eksterne kunder. Naturligvis kan eventuelle ændringer i dine mål kun leveres inden for servicedeskens rammer og dine tilgængelige ressourcer.

3. Revurdér dine nuværende ITIL incident management metrics i sammenhæng med værdien

Logisk set burde dette være kommet før den anden best practice. Men hvis du vil tilpasse din it-ydelse til forretningsforventningerne, er det lettere at starte samtalerne med interessenter med et: “Hvordan har vi det?”. Hvorimod “Dette er, hvad vi måler; hvad synes du?” eller “Hvad skal vi måle for at sikre, at vi imødekommer dine behov?”. Begge virker en smule upassende at begynde samtalen med.

Hvad kan der være galt med dine nuværende ITIL incident management metrics og KPI’er? Servicedesken laver mange almindelige metrics fejl, herunder:

  • bruger for mange metrics;
  • misforstår forholdet mellem metrics;
  • ignorerer de adfærdsmæssige aspekter af metrics, og
  • ser metrics som mål, man skal sigte mod, ikke som et springbræt til forbedring.

Derudover er der ofte fokus på, hvad it-support gør, snarere end på, hvad it-support opnår gennem, hvad de gør. Det handler ofte meget om ’operationer’ og ikke om resultater. Og selvom hastigheden, antallet og driftsomkostningerne er vigtige, kan du så være 100% sikker på, at din servicedesk er optimeret ud fra et forretningsværdiperspektiv? Endnu en gang skal du tale med dine vigtigste interessenter om, hvad der virkelig betyder noget for din organisation – og hvor god din servicedesk er til at imødekomme deres forventninger.

4. Antag ikke, at en positiv ændring automatisk er en god ting

Dette er én af ​​de fejl, jeg talte om i den tredje best practice – at forholdet mellem metrics ikke altid er forståeligt. Tag f.eks. antallet af incidents. Naturligvis ønsker ingen at have incidents, men de er ikke til at undgå. Og når antallet af incidents øges eller mindskes, er det vigtigt at forstå, hvad en sådan ændring betyder.

Tag f.eks. en servicedesk, der har et højt antal incidents, som den håndterer hver måned. At have et stort antal incidents er nødvendigvis ikke et godt tegn (eller noget at råbe højt om) fra et overordnet it-organisationsperspektiv.

Og hvad med, når antallet af incidents falder over tid? Dette er heller ikke nødvendigvis en god ting. Især hvis det er et tegn på, at servicedeskens omdømme forværres: der kan faktisk være flere it-problemer, men færre incidents i servicedesken. På den anden side kan en stigning i antallet af incidents også være et tegn på, at servicedesken klarer sig godt – og at medarbejderne derfor er mere tilbøjelige til at kontakte den, når de har problemer.

Når du ser på ændringer i antallet af incidents, så er du også nødt til at forstå, hvad der ellers har ændret sig. Er kundetilfredsheden faldet? Eller er antallet af “simple” eller lavt prioriterede incidents faldet?

Du er samtidig nødt til at forstå metrics-ændringerne, så som omkostninger per ticket eller den gennemsnitlige behandlingstid, bedre, før du råber op om dem. Servicedesken beskæftiger sig muligvis kun med simple incidents, som f.eks. nulstilling af adgangskoden. Og den gennemsnitlige behandlingstid, hvor du ikke inkluderer simple incidents, som f.eks. nulstilling af adgangskoden, kan faktisk være steget. Spørg også dig selv om, hvorfor din organisation ser ud til at have brug for flere nulstillinger af adgangskoder – og hvorfor denne proces ikke allerede er automatiseret?

I sidste ende skal din servicedesk have dette i tankerne: antag ikke automatisk, at det, der ligner en positiv ændring, faktisk er en god ting. Se altid på forholdet mellem forskellige metrics – og hvad det betyder i din organisation.

5. Brug problem management til at reducere dit antal af incidents

Denne best practice for ITIL- incident management er noget kortere. Jeg har allerede skrevet et blogindlæg om, hvorfor implementeringsniveauet af ITIL problem management er så lavt – og et andet med ti tips til ITIL problem management.

Det er klart, at servicedesken er nødt til at forstå forskellen mellem incidents og problemes. Men din it-support skal også gøre en proaktiv indsats for at anvende problem management-værktøjet og dets teknikker til at fjerne alle tidskrævende, tilbagevendende problemer en gang for alle. På den måde er det muligt for dine analytikere i servicedesken at fokusere på de sager, der virkelig har brug for deres opmærksomhed.

Mere om dette emne

Hvorfor du bør bruge ITIL som et framework – ikke som et regelsæt

Når vi besøger organisationer, der har brug for hjælp til at optimere deres processer,...

Hvad skete der med ITIL service livscyklussen i ITIL 4?

Brancheekspert Stephen Mann er tilbage med sit andet blogindlæg. Denne gang vil han tale...