Har du fastnat i ITIL mognaden?

Har du fastnat i ITIL mognaden

Även om det kanske låter otroligt har vi på Compose IT jobbat med IT Service Management och Service Operation sedan innan ITIL blev allmänt känt och en de-facto standard på de flesta IT avdelningar och företag för ett gemensamt ramverk kring hur IT skall drivas.

Som alla andra har ni säkert börjat er adaption av ITIL i begränsad omfattning, genom att implementera processerna Incident, Problem och Change. För att understryka just hur vanligt detta tillvägagångssätt är så finns det till och med en egen förkortning för just dessa processer, IPC.

Det som tyvärr blir tydligt är att de flesta är kvar just där. Man är inne på sin 3:e eller 4:e iteration för att få kvalitet och ordning på Incidenter, Change och CMDB. För att komma vidare ger man sig på att köra IT Service Management (ITSM) projekt. Kanske rent av investerat i ett modernare verktyg som ServiceNow eller börjar snegla på andra modeller som DevOps och AIOps. Det blir kostsamt och drar resurser och tid från andra saker och blir i slutändan inte särskilt mycket bättre.
Incidenterna har fortfarande bristande kvalitet, CMDB är fortfarande inte komplett, SLA:er mäts på det som går och inte det man vill och det är en högst manuell process att få fram mätetal som överensstämmer med den verklighet man uppfattar.

En insikt vi på Compose IT har kommit till är att man inte tar i tillräckligt. Det är ett initiativ bland alla andra och man begränsar scoopet.
Att få ordning på ITSM eller ITIL är som att försöka hoppa över ett stup. Kommer du inte hela vägen över så kommer du inte vidare alls!

Med att ’ta i’ menar vi inte att man ska skicka fler på utbildning, ytterligare en Incident Manager eller ha ännu fler fält i servicedeskverktygen. Nej, det handlar om att använda det data som skapas för att styra verksamheten. Att faktiskt ta konsekvenserna av att införa ett ramverk för hur man skall jobba. Att inte slå undan benen på organisationen genom att frångå vad datat säger eller ha helt andra styrmedel.

Så vad är problemet?

Problemen vi ser är att det data Du får från IPC i sig självt inte är tillräckligt. Hur kan du veta när du har rätt mängd Incidenter? Eller vilken ’resolution-time’ för era olika prioriteter är rätt?

För att få rätt data behöver man utöka scoopet. Man behöver titta på två processer till! Det låter kanske konstigt. Om man inte lyckes med 3 hur kan då 5 vara bättre?
Availability Management och Event Management skapar ramen som saknas. Utan dessa två processer så hänger IPC i luften och kommer aldrig att ha något att utgå från eller något mål att nå till.
Förenklat kan man säga att Availability Management handlar om hur säkerställer jag att mina tjänster kommer att ha den tillgängligheten som vi lovat. Ofta förminskas Availability Management till att mäta tillgänglighet. Men det är ju att endast mäta resultatet. Inte jobba med hur man ska nå dit. Det är Availability processen som ger Incident, Problem, Change, Config och Capacity dess existensberättigande. De är för att återställa eller upprätthålla tillgänglig funktion som dessa processer finns till.
I den andra ändan finns Event Management. I ITIL ingår både att mäta, monitorera och att hantera larmen, Eventen i Event Management Processen. Att monitorera och mäta hur mina tjänster levererar och hur den infrastruktur som behövs mår och att sedan definiera hur denna information, dessa händelser skall filtreras, berikas och användas för att skapa rapporter eller generera Incidenter.
Att satsa på och driva Event Management framåt ger flera pusselbitar till att slutligen få ordning på stora delar av ITIL.
Ja, detta är tekniskt, och är ofta förbisett som ett tekniskt hjälpmedel som används av tekniker för att lösa incidenter. Men om Availability är ’moroten’ för Er verksamhet, målet som skall nås så är Monitorering piskan. Det är där man faktiskt kan se hur det går och med rätt verktyg, hur det kommer att gå. Dessutom är monitorering en förutsättning för Availability Management. Vilken är vår faktiska tillgänglighet? Hur väl fungerar IPC för att vi ska leverera det vi lovar?
För att kunna mäta detta behöver du information om vilka tjänster som gör vad, vilka servrar, vilka databaser, nätverk och applikationer är viktiga? Vilka håller på att byggas om? Vilka har tagits bort och vilka används av vilken kund eller vilket system.
När er dokumentation via Asset, CMDB eller på annat sätt används till att föda denna information till din Event Management process kommer den information som finns där att vara nödvändig och man kan inte längre strunta i att lägga ett Change om man ska starta om en server, det blir nämligen ett larm som på grund av saknat Change blir en incident och en otillåten Change. Detta kan följas upp, arbetssätt korrigeras och dokumentation förbättras.

Det är när data används på riktigt som det också blir korrekt.
Med korrekt data kan man börja styra verksamheten baserat på informationen. Man kan se att varje Incident är ett riktigt fel och inte bara brus när någon gör en förändring i miljön. Man kan styra resurser för att upprätthålla den kvalitet och tillgänglighet man beslutat sig för.

När du ser att incidenten hänger ihop med tillgänglighet eller att någon får stå till svars för att man ignorerat en Change. När du kan lösa problemen innan dom påverkat användarna. När du kan jobba med utveckling och att bygga bättre lösningar istället för att släcka bränder. Då ger ITIL ett reellt värde och kommer dessutom att fungera i längden.

Dessutom när kunden märker att ni redan jobbar på problemen innan dom har ringt då kommer ni snart att kunna ha diskussioner om kvalitet, tillgänglighet och prestanda istället för dessa eviga incidentrapporter kring ’vad var det som hände?’.

För att bli bättre behöver man träna. För att komma hela vägen över stupet behövs engagemang och målvetenhet men vi kan ge 4 enkla steg som tar er åt rätt håll.

Börja med att uppifrån, ända från (IT)ledningen. Definiera vad som är viktigt för er ’Tillgänglighet’. Två exempel på definitioner kan vara Availablity – Funktion under definerade tider. 7-18, 24/7 undantaget godkända servicefönster samt godkända Change.
Leveranstid – Tid från inkommen beställning till tillgänglig funktion för beställaren.
Det finns många andra exempel men vad som är viktigt för Er beror på Er verksamhet. Gör det inte för komplicerat. Tänk liknande Er ekonomi. Är omsättning eller vinst viktigt. Definiera vad ni menar när ni säger ’Availability’.

Bryt sedan ner detta per tjänster eller funktioner ni tillhandahåller. Fundera inte till att börja med vad kunderna eller användarna tycker. Er gissning på vad som är bra eller dåligt räcker. Använd detta som Er egen ’Service Level Target’ SLT. Även för att göra detta kan man ta hjälp av ekonomin-teori. Tänk på hur ni gör budgetprocessen. Detta borde vara en liknande process. Men hoppa inte över detta steg! Det är mot dessa värden, dessa SLT ni sedan mäter. Om man inte har ett mål är det svårt att veta vart man ska gå.

Börja mät! Ta Event Management på allvar. När ni börjar mäta kommer allt att vara rött men genom att jobba med ’varför’ det är rött så kommer ni hitta orsaker till problemen. Som att någon startade om en server eller det kommer in larm från testmaskinerna och så vidare. Det är i detta skede det kommer bli tydligt, och viktigt, varför dokumentation, CMDB och Change är nödvändigt. Även Problem kan fylla en viktig roll här. Avsluta varje problem med att fråga, varför såg vi inte detta innan det påverkade vår tillgänglighet och på vilket sätt kommer vi att se det nästa gång?

När detta kommer på plats kan Incidenter prioriteras baserat på vilken tjänst som är påverkad, vilken tillgänglighet och SLT som riskeras och inte hur högt någon skriker i telefonen. Genom detta kan Ni på allvar driva ’Continous Service Improvement Processen’ (CSIP) och jobba med förbättringar istället för brandsläckning.

Med detta data i ryggen kan Ni även föra en dialog med användare och kunder kring pris och prestanda. Det blir konstruktivt och prioriteringar kan göras för att stödja kundens affär och behov och genom meningsfulla SLT mätningar har ni grunden till mätbara SLAer.

Om ni har mätt Incidenter och ’resoultion time’ men känner att ni inte kommer vidare. Att ni har svårt att få till SLA mätningar eller att er CMDB fortfarande inte klar.

Hör av Er till oss så kan vi berätta mer och det kanske är så att det bara behövs lite till för att ni skall komma över stupet.

 

Våra verktyg

Kontakta oss