5 tips för Incident och Problem Management

Då det (o)lyckligtvis finns en hel del incidenter och problem i vår IT-värld ser vi på Onbird att det idag finns en relativt hög kännedom till Incident Management– och Problem Management-processer.  Och ändå finns såååå mycket utrymme kvar för förbättring.

Ok då, vad är problemet (eller incident)?

Då processerna är så centrala och väsentliga är det förstås viktigt att de fungerar väl.  Får vi snurr på dessa två processer får vi därmed snurr på tjänsteleveransens tillgänglighet.  M.a.o., vi minimerar nertid.

Problemet vi oftast ser är att dessa processer missförstås, får för lite resursfokus och tillämpas felaktigt.  Nedan följer våra fem tips för att maximera effekt av dessa processer i er organisation.

1.  Förstå skillnaden Incident-Problem och bete dig därefter

Incidenter är inte problem och problem är inte incidenter. Incidenter blir inte problem över tid. De blir inte heller problem via eskaleringsmetoder eller annat vis över tid. Ändå vet vi att incidenter och problem har såklart en stark relation som är viktig att både förstå OCH bearbeta parallellt och medvetet.

Återkommande demonstrerar organisationer att de inte förstår skillnaden ovan och då beter de sig fel i hantering. Det är vanligt att man blandar ihop incidenter och problem och godtyckligt väljer hur de skall hanteras. Det innebär ibland att vi tar fram incidenthantering för problem (tänk den frustrationen när teknikern bara lappar ihop med workarounds när användaren söker en fullständig lösning).  Ibland blir det tvärtom, man kör problemhantering för incidenter (igen så frustrerande – användaren behöver en ”quick fix” och teknikern vill borra ner till detaljernas botten).  Denna felaktiga mix i tillämpning gör att det slutliga resultatet blir mindre bra.

”Who cares, låt mig få jobba?!” får jag ofta höra när jag kommit så här långt i dialogen. ”Är det inte bättre att vi bara kommer i gång och löser saken?”

Ja tack, jag älskar angelägenheten. Och min önskan är att vi angeläget tillämpar både Problem- och Incidentprocesserna – parallellt och medvetet – för att maximera våra resultat.

2. Köp mycket silvertejp för Incident Management

Incident Management älskar workarounds (tänk silvertejp ).  Med silvertejp kan vi lösa det mesta snabbt och kortsiktigt. Avseende incidenter är snabbt och kortsiktigt bra – workarounds är BRA. Detta eftersom syftet är att så snabbt som möjligt hjälpa användaren att vara produktiv. Se till att utskriften funkar genom att silvertejpa det till en annan skrivare. Kör ctrl-alt-delete silvertejp för att starta om en klient eller tjänst. Tejpa ihop trasigt data genom att administrera direkt i databasen.

Vår främsta önskan här är att användaren kan vara produktiv – NU! Därmed menar jag att workarounds skall vara en top-of-mind-instinkt när vi arbetar med incidenter. Var kvick, oroa dig inte för grundorsaker och lägg inte för mycket tid på att hitta en perfekt, långsiktig lösning. Ta för all del fram silvertejpen och få i gång din användare.***

3. Dedikera resurser för Problem Management

Välfungerande Incident Management är fantastiskt, men räcker inte.  Vi har alla varit med om frustrationen när workarounds blir för långlivade (permarounds?).  Det kan inte vara meningen?  Vi skall inte leva med en ständig respons av tejpade skrivare, ctrl-alt-deletande och admin-fixar bakom kulisserna.  Således behöver vi OCKSÅ bygga bort dessa fel.

Där kommer Problem Management in i bilden.  I syfte att gå till botten arbetar vi i denna process på ett annat sätt – beteendet är annorlunda.

Tyvärr är det svårt att skapa rätt fokus och rätt mix av dessa två beteenden.  Många organisationer kämpar för att hålla takt med Incident Management och hinner aldrig riktigt med problemlösningar. Ytterligare premierar de att vara ”snabb” med ”mycket på gång” och därmed hinns det inte med de nödvändiga beteendena i Problem Management.

Därför rekommenderar jag separation av dessa processer samt medveten och dedikerad resurs för Problem Management (tänk time-boxing). För att inte slukas av incidentbruset måste vi sätta av explicit tid och resurs för endast problem. Boxa ett antal timmar/personer för Problem Management och ge dem ansvar och rätt att stadigt och envist identifiera grundorsaker och bearbeta problem.

4. Ständig kommunikation mellan Incident och Problem

Då dessa processer har så starka beroenden till varandra är det avgörande att information flödar fritt dem emellan. Följaktligen vill vi säkerställa att maximal medvetenhet om Problemarbete finns i Incident-teamet. Och tvärtom.

Då och då ser jag självständiga Incidentteam som blir lite väl kära i sina workarounds. Silvertejp i all ära, men dessa team lägger ofta för lite tid på samspel med långsiktiga lösningar och problemteamet.

Likaså har vi kaxiga Problemteam som betraktar workarounds som mindre värda. ”Riktiga tekniker går till botten med problemen,” säger de. Varpå de lägger alltför lång tid gömda i sin problemgrotta. Denna grott-tid kanske behövs, men medför samtidigt onödigt mycket incident-downtime och många missnöjda användare.

Låt inte detta uppstå i din organisation. Dela samma ärendehanteringssystem för dessa incidentärenden och problemärenden. Dokumentera lagom med länkar mellan incident- och problemärenden.  Se till att Incidentteamet inte bara stänger incidenter, men också skapar problemärenden när de behövs. Vidare, se till att Problemteamet kommunicerar grundorsaker och tänkbara workarounds till Incidentteamet INNAN de går på den fullständiga lösningen. Inför frekventa ståupp-möten för snabb, muntlig uppdatering mellan teamen och kräv en ständig och öppen kommunikation.

5. Mäta för flöde

När definitioner för distinkta, parallella och medvetna beteenden är aktiverade samt kommunikationen är etablerad skall vi kunna följa och utvärdera vårt arbete genom mätning.  Börja enkelt och hitta ert eget ”lagom” här.

Vanliga mätetal är såklart orienterade mot volym (t.ex. hur många incidenter per vecka?), lösningsgrad (t.ex. hur många problem löser vi per månad?), och tidslängder (t.ex. hur lång genomsnittstid är en incident öppen?). Dessa och många mätetal kan vara intressanta.

Jag har inte för avsikt att lista alla tänkbara mätetal (kontakta mig gärna om du söker input) men att i stället uppmuntra till ett mera generellt syfte med mätning. Oavsett exakta mätetal, se till att ni använder mätning för att demonstrera ett hanterat in- och utflöde av incidenter och problem.  Och vad menar jag med det? Kortfattat behöver vi se till att inflöde inte överstiger utflöde.  Vi behöver hålla takten, dvs lösa ärenden i en takt som gör att vi inte halkar efter. Backloggen av incidenter och problem skall vi hantera så att den inte växer över tid.

Sammanfattning

För att sammanfatta våra fem tips för Incident och Problem Management:

1. Förstå skillnaden och bete dig därefter
2. Köp mycket silvertejp för incidenter
3. Dedikera resurser för Problem Management
4. Ständig kommunikation mellan Incident- och Problem management
5. Mäta för flöde

Kontakta mig och oss på Onbird om vi kan hjälpa till med ytterligare information i detta.

___________________________________________________________________________________________________

OBS – ovanstående förenklar vissa definitioner och syften i viss mån. Det är jag medveten om – min strävan i denna skrift är att enkelt hålla mig till essensen.

*** Tillämpning av workarounds får naturligtvis inte bortse ifrån andra viktiga policybeslut, säkerhetsrutiner, kostnader, andra viktiga beroenden, m.m.  DVS vi ska inte tejpa på ett vilt, farligt eller icke-genomtänkt sätt. 😊 Och om vi har en riktig lösning som är smidig skall vi naturligtvis tillämpa den.