Många IT-organisationer har svårt att skilja på incidenter och problem. Tekniker och systemspecialister är nyfikna av naturen vilket resulterar i att det underliggande problemet för varje incident utreds och blir löst. Eftersom varje problemutredning kräver resurser, och resurser kostar pengar, så finns det i värsta fall flera problem som inte borde ha lösts på grund av att dessa resurser i ett större perspektiv borde ha prioriterats annorlunda.
Problem som utreds av enskilda individer löses oftast med hjälp av personlig kunskap och erfarenheter. Tyvärr kan dessa kunskaper och erfarenheter bli en begränsning om problemet är komplext och flera olika områden är berörda. Det behövs då en mer omfattande utredning och en beprövad metod för att hitta den grundläggande orsaken. Risken finns annars att problemet blir liggande olöst under en längre tid.
Att använda problem management som en separat process säkerställer att IT-organisationen får kontroll på existerande problem och kan prioritera vilka som ska utredas samt se till att beprövade verktyg och metoder används för komplexa problem.
Ett problem definieras i denna bok som ”den okända underliggande orsaken till att något inträffat”.
Syfte
Huvudsyftet med problem management-processen är att minska antalet återkommande incidenter i IT-miljön och den negativa effekten av dessa.
Syftet med problem management uppnås genom att:
- Förhindra incidenter från att uppstå genom att åtgärda grundorsaken
Minimera verksamhetens negativa påverkan av de incidenter som inte kan förhindras
Omfattning
Ett problem är den okända orsaken till något som hänt. Det finns ingen begränsning till endast IT-miljön. Eftersom processen har de verktyg som krävs kan den även användas för att lösa problem som uppstått någon annanstans i IT-organisationen.
Problem management-processen omfattar de verktyg och aktiviteter som krävs för att hitta den grundläggande orsaken till att något inträffat och definiera vilka åtgärder som krävs för att åtgärda problemet.
Processen omfattar även att implementera lösningen enligt gällande rutiner. Specifikt de som finns i change management– och release management-processerna. I omfattningen ingår även att tillhandahålla en lista med kända fel och temporära lösningar till övriga IT-organisationen.
Värde för verksamheten
Problem management-processen är förmodligen en av de mest lönsamma processerna för verksamheten då den minskar antalet incidenter i IT-miljön. Processen reducerar även tiden för större incidenter och säkerställer att dessa inte uppstår igen vilket ger mindre produktionsbortfall. Listan med kända fel och temporära lösningar ger service desk förutsättningen att lösa ärenden snabbare vilket minskar tiden för störningar i verksamheten. Dessutom ger processen verksamheten möjlighet att prioritera vilka problem som ska utredas och på det viset välja hur resurser prioriteras.
Reaktiva och proaktiva problem
Reaktiva problemärenden är incidenter som inte första eller andra linjens support lyckats lösa. Det finns alltså en pågående störning i IT-miljön vilket innebär att denna typ av problem är brådskande fram till att en temporär lösning hittats och incidenten är löst.
Proaktiva problem är alla övriga problemärenden. Oftast registreras dessa utifrån återkommande incidenter där orsaken är okänd, men det kan även vara enstaka händelser där orsaken behöver identifieras. Proaktiva problem kostar tid och pengar att lösa. Dessa behöver prioriteras tillsammans med alla andra ärenden som finns inom IT-organisationen vilket innebär att de ska hanteras av berörd funktion i kontinuerlig förbättring.
Kända fel och temporära lösningar
Alla problem i IT-miljön ska inte lösas. Det kan finnas olika anledningar, som till exempel att en ny release är planerad inom en snar framtid som kommer att lösa problemet ändå, eller att kostnaden för att utreda eller lösa felet är så hög att verksamheten inte tycker att det är värt det. Oavsett anledning så ska felet beskrivas och lagras i en databas eller i ett dokument så att framtida ärenden som inkommer kan kopplas till det redan kända felet.
För varje känt fel ska en temporär lösning finnas. Oftast består denna av instruktioner som gör att användare kan komma runt felet i IT-miljön och på det viset fortsätta arbetet. I vissa fall kan den temporära lösningen vara att meddela användaren om att felet finns och att kunden beslutat att inte göra något åt det. Exempel på detta kan vara mindre buggar i en applikation som upptäckts vid driftsättning men ändå godkänts av kunden.
Listan med kända fel är i sin optimala användning en komplett förteckning av alla fel som finns i IT-miljön. Listan är ovärderlig hjälp för service desk så att tid inte läggs i onödan på fel som redan identifierats. Listan fungerar även som input till kontinuerlig förbättring av tjänsterna.
Aktiviteter
Följande aktiviteter finns i problem management-processen. Det är i stort sett samma aktiviteter för både proaktiva och reaktiva problemärenden. Skillnaden är att reaktiva problem ska lösas under tidspress fram tills att det finns en temporär lösning som fungerar.
Registrering – Alla ärenden måste registreras med berörd användare, utrustning och en utförlig beskrivning av ärendet. Om ett ärende skickas vidare till en annan grupp/organisation för vidare undersökning underlättas arbetet väsentligt när bra och komplett information är inskriven i ärendet.
Kategorisering – Kategorisera ärendet enligt en fördefinierad lista. Kategoriseringen är samma oavsett ärendetyp och speglar tjänstekatalogens uppbyggnad för att bland annat underlätta ansvarsfrågor och statistik.
Proaktivt eller reaktivt problem – Proaktiva problemärenden skickas till berörd funktion via processen kontinuerlig förbättring där beslut tas om problemet ska lösas eller inte. Reaktiva problem går vidare till problemlösning.
Problemlösning – För reaktiva problem är det primära att hitta en temporär lösning så att incidenten kan stängas. Aktiviteten går sedan ut på att identifiera orsaken till problemet och hitta en lösning. För komplexa problem ska en beprövad modell användas som till exempel Kepner-Tregoe.
Förändring i IT-miljön (RFC) – Lösningar som kräver en förändring i IT-miljön ska hanteras via change management-processen.
Åtgärd – Implementera lösningen för problemet.
Kontrollera åtgärd – Kontrollera att problemet är löst och vidta de åtgärder som krävs för att säkerställa att problemet inte uppstår igen.
Stäng – Kontrollera all dokumentation runt ärendet och avsluta.
Dokumentation
Följande dokumentation ska finnas inom ramen för problem management:
- Kända fel inklusive temporära lösningar
Modell för problemlösning
Relationer till övriga processer och funktioner
Problem management-processen har kopplingar till många andra processer. Här listas de vanligaste:
Trigger
Problem management triggas genom:
- En incident som inte kan lösas av andra linjen med hjälp av dokumentation eller kunskap
- Ett problem som identifieras vid genomgång av trendrapporter och statistik
- En eller flera incidenter som har samma okända grundorsak
- Ett proaktivt problem som identifieras av någon i IT-organisationen
Input
Följande Input behövs för problem management:
- Dokumentation om incidenter
- Information om produkter och komponenter i IT-miljön
- Modell och verktyg för problemlösning
Output
Följande output genereras av problem management:
- Lösta problem
- Ny eller uppdaterad dokumentation
- Förändringsbegäran till change management-processen
- Temporära lösningar för incidenter
- Nya eller uppdaterade kända fel
- Problemrapporter
Mätning
Problem management-processen kan mätas genom:
- Antalet kända fel som läggs till i dokumentationen
- Antal eller procent av:
- Felaktigt registrerade problem
- Felaktigt kategoriserade problem
- Genomsnittlig lösningstid för incidenter kopplade till ett reaktivt problem
- Genomsnittlig kostnad per problem
- Antalet ärenden som löses med hjälp av ett dokumenterat känt fel
- Totala antalet incidenter
Utmaningar
Många IT-organisationer har svårt att skilja på hanteringen av incidenter och hanteringen av problem. Det är dock en stor skillnad i vem som ska driva ärendet. För incidenter sköts detta av service desk och i vissa fall även en incident manager, normalt utan att tjänsteansvarig behöver engagera sig.
För problemärenden är det tvärt om. Ärendet ska ägas och drivas av respektive tjänsteansvarig. Undvik att göra problem management till en operativ funktion som utan tjänsteansvarigs inblandning förväntas driva alla ärenden. Konsekvensen av detta är i värsta fall att hela syftet med en övergripande prioritering försvinner. Dessutom så blir det svårt att finansiera processen om inte kostnaderna kan kopplas till den tjänst som utreds.
Följande moment behöver dessutom särskild uppmärksamhet vid införande av processen:
- En effektiv och väl etablerad incidentprocess
- Förbättra teknikers analytiska förmåga och kunskap rörande felsökning
- Säkerställa att tekniker har åtkomst till all dokumentation, alla verktyg och all information som behövs
- Möjlighet att i verktyget koppla ärenden till kända fel
