Varför brinner det?

Där incidenthantering återställer driften söker problemhantering svaret på varför den gick sönder.

Skillnaden är inte akademisk. En organisation som bara har incidenthantering löser samma fel om och om igen, och blir med tiden mycket skicklig på att lösa just det felet. Volymen sjunker aldrig.

Reaktivt och proaktivt

Reaktiv problemhantering utgår från något som redan hänt. Efter en storstörning, eller när samma ärendetyp dykt upp för fjärde gången på en månad.

Proaktiv problemhantering letar i ärendedatan efter mönster innan de blir störningar. Den förutsätter att ärenden kategoriseras konsekvent – vilket är ett av de starkaste skälen till att hålla kategorilistan kort och användbar.

Kända fel är processens viktigaste produkt

När orsaken är identifierad men åtgärden dröjer – för att den kräver en leverantörsuppdatering, ett projekt eller en budget – dokumenteras problemet som ett känt fel med en tillfällig lösning.

Effekten är omedelbar. Nästa gång ärendet kommer in behöver ingen utreda något. Första linjen löser det direkt, och lösningstiden går från timmar till minuter.

Kända fel bör ligga i kunskapsbasen och vara sökbara där teknikerna redan arbetar.

Så kommer ni igång utan en formell process

Ta fram de fem vanligaste ärendekategorierna från förra kvartalet. Fråga för varje: varför återkommer det här?

Ofta räcker den frågan för att hitta något åtgärdbart – en felaktig standardkonfiguration, en utbildningslucka, ett system som beter sig annorlunda än användarna förväntar sig.

Ni behöver ingen formell metod för att börja. Att fråga varför några gånger i rad tar er längre än de flesta tror.

Någon måste äga det

Det här är den ITIL-praktik som oftast hoppas över, och orsaken är strukturell snarare än att någon är lat.

Ett problem har ingen otålig användare som väntar. Det finns aldrig ett akut skäl att arbeta med det i dag, vilket gör att det skjuts upp varje dag.

Lösningen är att avsätta tid, inte att uppmana till det. Några timmar i veckan för någon som inte samtidigt sitter i ärendekön räcker långt.

Kopplingen till förändringar och beroenden

Många grundorsaker leder tillbaka till något som ändrades. En väl förd förändringslogg är därför ett av de mest användbara underlagen i en utredning.

Samma sak gäller beroenden. Utan en CMDB är det svårt att se att tre till synes obesläktade incidenter delar en gemensam komponent.

Nyckeltalet

Antalet återkommande incidenter per kategori över tid. Det är det enda måttet som visar om processen faktiskt tar bort arbete i stället för att lägga till det.

Hur processen förhåller sig till övriga delar av leveransen går vi igenom under ITSM.