Problem management - lätt att underskatta

Den svåraste ITIL processen

Av incident, problem och change är problem management den svåraste processen att implementera enligt våra erfarenheter. Detta trots att problem management sannolikt är den viktigaste byggstenen att få på plats. Innan jag utvecklar det påståendet behövs begreppet kanske redas ut.

Det kan tyckas självklart vad problem innebär, men sett ur ett ITIL perspektiv förklaras det som den okända bakomliggande orsaken till en eller flera incidenter. En incident är löst när användaren kan fortsätta sitt arbete, även om den bakomliggande orsaken fortfarande kvarstår.

Målet med problem management är dels att minimera påverkan av ett fel i en IT infrastruktur samt att minimera risken för att samma fel ska uppstå igen. För att uppnå målet är nyckeln att lyckas lösa den bakomliggande orsaken till uppkommen incident. Detta kanske låter avancerat, men jag skulle påstå att mycket av det ramverk som ITIL tillhandahåller bygger på sunt förnuft. Låt säga att en läcka upptäcks i taket (incident). När felet upptäcks åtgärdar man genom placera en hink på golvet (workaround) och man konstaterar att det föreligger ett (problem) som behöver analyseras och lösas. Med andra ord hitta ett sätt att laga hålet och åtgärda (change).

Den kanske vanligaste orsaken till varför organisationer väljer att inte prioritera problem management är att resultaten ofta visar sig på lång sikt. En workaround löser oftast problemet för stunden och därefter är det dags att ta sig an nästa incident. Tiden räcker ofta inte till för att analysera och finna långsiktiga lösningar. På vår tjänstesida IT-styrning kan du läsa om hur vi kan hjälpa er organisation med ITIL och andra ramverk.

Ett exempel

Backupvolymerna växer i en onaturligt hög takt. I ett första skede väljer man att anskaffa mer kapacitet till backupsystemet, vilket går förhållandevis snabbt och är förknippat med låg risk. Problemet kvarstår dock och inom kort är det dags att köpa in ännu mer kapacitet osv, ända tills den som ska betala säger stopp! Bakomliggande orsak till den här typen av fel skulle exempelvis kunna vara felaktigt satta parametrar i backupsystemet, vilket resulterar i dagliga fulla backuper istället för en full backup i veckan och resterande inkrementella.

Om samma fel görs på flera servrar kan kostnaden bli oproportionerligt hög om man väljer den enkla vägen istället för att söka den bakomliggande orsaken. Trivialt kan tyckas för vissa, men listan på liknande situationer kan göras lång.

Om man i detta exempel leker med tanken att change processen vore fullt implementerad så hade felsökningen förmodligen underlättats. Då hade möjlighet funnits att gå tillbaka och se vilka förändringar som gjorts vid tillfället då felet först uppstod.

I den här typen av situationer är ofta ett flertal olika aktörer involverade med olika ansvarsområden som applikationsutveckling, OS, databas och backup osv vilket gör att en hög grad av samordning krävs.

Våra erfarenheter av problem management

Enligt våra erfarenheter är följande punkter viktiga att tänka på för att uppnå en väl fungerade process för problem management:

• Lägg ner stor möda på att hitta rätt resurser för problem management. Rollen som problem manager ställer höga krav på analytisk och metodisk förmåga. Utöver detta behövs god kännedom om befintlig infrastruktur och goda ledaregenskaper.
• Tillåt problem manager att få avsätta nödvändig tid för att ostört fokusera på sin uppgift och se till att det finns goda förutsättningar för samarbete och informationsutbyte mellan incident– och problem processerna.
• Rätt val av verktyg som täcker organisationens behov avseende problem management processen. Verktyget bör åtminstone ha stöd för att registrera och söka incident, request, change, problem och kända fel. Därutöver bör kopplingar gå att göra mellan specifika tickets (incidenter, problem osv) och respektive berörd hård- eller mjukvara.

Trots att det finns många utmaningar att ta sig an på vägen så är jag övertygad om att det är rätt väg för en IT-driftorganisation att investera i vad som krävs att bedriva proaktiv problem management och att inte underskatta behovet av resurser och tid för att nå dit.

Här kan du läsa ett relaterat blogginlägg om change management.