Varje månad hanterar din servicedesk ett antal ärenden som den hanterat förut. VPN som krånglar. Specifika applikationer som kraschar. Nätverksproblem i ett visst kontorsrum.
Handläggarna vet lösningen utantill – för de har gjort den tjugo gånger. Det är inte ett resursproblem. Det är ett problemhanteringsproblem. Och det är lösbart med rätt konfiguration i Easit GO.
Incident vs problem – en distinktion som förändrar allt
I ITIL-terminologin är skillnaden tydlig. En incident är ett avbrott, ett problem är den underliggande orsaken till avbrottet.
I praktiken hanterar de flesta servicedeskar enbart incidenter. Användaren rapporterar att VPN inte fungerar. Handläggaren återstartar anslutningen och stänger ärendet. Nästa vecka rapporterar en annan användare samma sak.
Incidenten är löst. Problemet existerar fortfarande.
Problemhantering är processen för att ta sig från “vi löser det varje gång det händer” till “det händer inte längre”. Det kräver att man identifierar mönster i incidentdata, isolerar grundorsaken och implementerar en permanent lösning.
Det är en av de processer som ger mest långsiktig effekt i en servicedesk och en av de som implementeras minst.
Varför det inte implementeras och varför det är fel prioritering
Det vanligaste argumentet mot att starta med problemhantering är att det verkar tidskrävande. Man ska analysera grundorsaker, hålla utredningar, dokumentera allt.
Det argumentet missar ett faktum. Du betalar redan för problemet.
Varje gång en handläggare löser samma incident för tionde gången spenderas tid som kunde ha lagts på något annat. Om tjugo liknande incidenter per månad tar 30 minuter var, betalar du varje månad tio timmars arbete för ett problem du aldrig åtgärdar.
En grundorsaksanalys som tar fyra timmar och eliminerar tjugo incidenter per månad betalar sig på tre veckor.
Problemhanteringsprocessen i Easit GO
I Easit GO problemhantering som standard och som en separat ärendetyp – Problem – med egna statusflöden, fält och tilldelningsregler. Det gör att problem kan hanteras parallellt med den dagliga incidentströmmen utan att de konkurrerar om prioritet.
Steg 1: Identifiera problemkandidater. Kör en rapport på incidenter per kategori och sortera på frekvens. Incidenttyper som återkommer mer än tre gånger per månad är problemkandidater. I Easit GO kan du filtrera på kategori, handläggargrupp och tidsperiod, analysen tar minuter.
Steg 2: Skapa ett Problemärende och koppla incidenter. När en problemkandidat identifierats skapas ett problemärende i Easit GO. Befintliga och framtida incidenter av samma typ kopplas till problemet via relationshantering. Det innebär att handläggare som tar emot en ny incident ser direkt: “detta är ett känt problem, här är workaround.”
Steg 3: Grundorsaksanalys. Problemärendet dokumenterar analysarbetet: vad är den underliggande orsaken? Vad krävs för att eliminera den permanent? Vem ansvarar för åtgärden? Tidsplan?
Steg 4: Känt fel och workaround. Medan den permanenta lösningen utarbetas dokumenteras ärendet som ett känt fel med tillhörande workaround. Den informationen finns tillgänglig för alla handläggare och kan exponeras i självserviceportalen så att användare hittar workaround utan att kontakta servicedesken alls.
Steg 5: Stäng problemet när grundorsaken är eliminerad. När den permanenta lösningen är implementerad stängs problemärendet. Incidenter av den typen ska nu upphöra. Om de fortsätter finns ett nytt problem att undersöka.
Vad det ger på sikt
Effekten av en fungerande problemhanteringsprocess är kumulativ. Varje problem som elimineras minskar ärendevolymen permanent. Handläggarna frigörs från repetitivt arbete. Kunskapsbasen växer med varje Known Error som dokumenteras.
Organisationer som arbetar systematiskt med problemhantering ser typiskt 15–25 % lägre incidentvolym per år. Inte som en engångsinsats, utan som en kontinuerlig trend.
Det frigör kapacitet för proaktivt arbete, systemförbättringar, automation, implementering av ny teknik. Det är skillnaden mellan en IT-avdelning som springer efter problemen och en som förebygger dem.
Var börjar man?
Starta inte med att försöka täcka allt. Välj de fem vanligaste incidentkategorierna ur Easit GO och välj en av dem att göra grundorsaksanalys på.
Kör analysen, dokumentera fynden, implementera lösningen och mät utfallet. Om incidentfrekvensen sjunker i den kategorin har du bevis för att processen fungerar i er miljö. Lägg sedan till ytterligare kategorier successivt.
Det är en iterativ start, inte en storskalig implementation.
Vanliga frågor
Vad är skillnaden mellan incident och problem i ITIL? En incident är ett avbrott. Ett problem är den underliggande orsaken till en eller flera incidenter. Incidenthantering återställer tjänsten snabbt. Problemhantering eliminerar grundorsaken.
Hur konfigurerar man problemhantering i Easit GO? Problem finns som standard som en separat ärendetyp med egna statusflöden. Incidenter kopplas till problem via relationshantering. Known errors dokumenteras med workarounds och exponeras i kunskapsbasen.
Vad är en known error database? En samling dokumenterade problem där grundorsaken är identifierad men permanent lösning saknas. Innehåller workarounds som handläggare kan använda direkt, och som kan exponeras i självserviceportalen.
Behöver man ITIL-certifiering för att arbeta med problemhantering? Nej. ITIL-certifiering är frivillig. Problemhantering är ett pragmatiskt arbetssätt som vilken IT-avdelning kan tillämpa oavsett formell certifieringsnivå.
Varje minut som läggs på att lösa samma incident igen är en minut som inte läggs på att förhindra nästa. Problemhantering i Easit GO ger IT-avdelningen verktyget att bryta det mönstret systematiskt.
Vill du se hur problemhantering ser ut i Easit GO? Boka en demo
Läs också: ITIL i Easit GO: Vad det faktiskt innebär – och vad det inte behöver innebära
Henrik Resare
Commercial Product Manager
henrik.resare@easit.com
070-249 36 06