Vad kan vi dra nytta av från Service Management-ramverk såsom ITIL i dessa tider då Agilitet och lättrörlighet står högt på agendan? Finns det viktiga och vanligt förekommande ITIL Processer som alla organisationer, oavsett grad av agilitet, behöver för sin leverans?  Nedan har jag identifierat 5 vanligt förekommande och välanvända ITIL processer som vi tror att alla IT-organisationer behöver ha för att vara effektiva.

Incident Management

Med ITIL Processen Incident management menas den process som organisationer har på plats för att hantera Incidenter, både stora som små. En incident definieras som ”an unplanned interruption to a service or reduction of the quality of the service” som uppstår. Ofta identifieras dessa incidenter antingen genom att användare hör av sig eller något larm/övervakningssystem hör av sig att någon tjänst/applikation/maskin inte längre fungerar som det är tänkt. Målsättningen med processen är att återställa ”normal service operation” så snabbt det bara går. Antingen genom någon form av work-around eller, om det finns, en lättillgänglig permanent lösning.

Varför Incident Management?

Effektiv Incident Management för med sig flera olika positiva effekter såsom:

• Kortare lösningstider i tid till återställning.
• Tydligare verksamhetsorienterad prioritering av vilka Incidenter (störningar) man ska hantera i vilken ordning.
• Bättre synlighet/visualisering över vilka Incidenter (störningar) som pågår och hur dessa hanteras.
• En massa bra data som hjälper oss att identifiera var vi behöver sätta in förbättringsåtgärder (dvs tjänster där vi har många eller omfattande incidenter) såväl som trendstatistik och annat som vi kan lära oss av.

Utmaningar och mätning Incident Management

Vanligt förekommande utmaningar är att Incidenter hanteras i andra verktyg än vad utvecklarna jobbar i (vanligtvis någon form av ärendehanteringssystem). Att utvecklare inte ser koppling mellan ”buggar” och Incidenter fast de egentligen är samma sak. Samt att på grund av hur man organiserat Servicedeskens arbete så använder man inte prioritetsfunktionen på rätt sätt.

Det finns en mängd olika nyckeltal som ofta används inom denna ITIL process och inte alla är bra. Men minst bör man ha koll på hur många man får in löpande. Hur lång tid det tar att lösa Incidenterna. Samt hur många som ligger olösta vid varje givet tillfälle.

Problem Management

Även om ITIL Processen Problem Management är närbesläktad med Incidentprocessen så är den inte samma sak. Med ITIL Processen Problem management menas den process som organisationer har på plats  för att hitta och åtgärda de underliggande tekniska felen som orsakade Incidenter från början. Ett problem definieras alltså som ”a cause, or potential cause, of one or more incidents”. Detta arbete att hitta det underliggande sker inte alltid genom en strukturerad process men är definitivt vanligt förekommande arbete. Målsättningen med processen är alltså i praktiska termer att reducera mängden incidenter över tid och på det sättet skapa ännu mer stabila och tillförlitliga tjänster i produktion.

Varför Problem Management

 Positiva effekter av Problem Management är framför allt:

• Färre incidenter.
• Färre incidenter.
• Stabilare tjänster.
• Färre incidenter.
• Färre gånger som tekniker måste släppa det de jobbar på för att hantera oplanerat arbete.
• Kortare lösningstider av de incidenter som ändå uppstår.

Utmaningar och mätning Problem Management

Med ITIL Processen Problem Management är utmaningen alltför ofta att den inte hanteras strukturerat utan mest reaktivt. Oftast i samband med en större Incident samt ett krav på varför Incidenten uppstod och vad IT-organisationen gör för att den inte ska uppstå igen. Det är heller inte ovanligt att man inte utvärderar effekten eller värdet av Problemprocessen genom att faktiskt mäta nedgången i mängden Incidenter (för övrigt det viktigaste och kanske enda relevanta nyckeltalet för processen).

Proaktiv Problem management vilar också på att det finns bra data att hämta från Incidentprocessen i syfte att hitta trender, svaga områden etc. Tyvärr saknas ofta kvalitativ Incidentdata för detta. Slutligen så hör vi ofta olika organisationer säga”ingen kund är beredd att betala priset för 100% felfria system/tjänster/produkter” . Problemet (pun intended) med det argumentet är två saker. 1. Det finns ingen kund som någonsin fått den kalkylen för det är ingen som vet/faktiskt gjort beräkningen. 2. Det skapar en kultur där vi vänjer oss vid att fel händer och börjar acceptera dem som något helt naturligt och nästan…. korrekt och riktigt?

Service Request Management

Service Request definieras som avrop från användare mot IT-organisationen. Oftast direkt till support-funktionen/servicedesken. Men de kan också gå direkt till systemförvaltare, agila team eller motsvarande. Avropet kan vara sådant som användarbehörigheter, beställning av konto, dator, utrusting, ad-hoc rapport, en fråga eller egentligen vad som helst (förutom Incidenter).  ITIL Processen Service Request Management är alltså den process som IT-organisationer använder för att hantera just ”Service requests”.  Målsättningen med processen är att på ett effektivt sätt hantera och leverera på dessa avrop och därmed möta förväntningar och överenskomna leveranstider.

Varför Service Request Management

Väl hanterad Service Request management skapar flera fördelar för IT-organisationen och dess kunder/användare:

• Kortare ledtider i leveranser till användare.
• Standardiserade och kanske även automatiserade förfaringssätt som ger högre kvalitet.
• Synlighet för användare över progress i ärendehantering/avrop.
• En enkel kommunikationskanal för alla typer av ärenden som inte är störningar (även om vi inte alltid vet vad det är från början).
• Hanterade förväntningar hos användare som därmed ger bättre servicegrad.
• Enklare onboarding av ny IT-personal med hjälp av tydliga riktlinjer för hur leveranser ska hanteras.

Utmaningar och mätning Service Request Management

Den kanske vanligaste utmaningen för just denna process är att den blandas ihop med Incidentprocessen till en enda stor ”supportprocess”. Därmed tydliggörs inte skillnaden mellan att återställa värde (incidenthantering). Respektive tillföra värde (Requesthantering).  På detta sätt riskerar IT-organisationer att prioritera felaktigt, inte hantera kundförväntningar och helt enkelt leverera sämre service. Ett annat problem som vi ofta ser här är också att man inte identifierat och standardiserat sina olika Requests med följden att hanteringen blir både slumpmässig och med dålig kvalitet.

Från Service Request Management processen får vi många bra nyckeltal. Minst bör vi ha koll på:

• Inflödet respektive utflödet.
• Lösningsgrader vid första, andra, tredje kontakt.
• Ledtider för leveranser.
• Fördelning på typer av Requests/avrop (för övrigt ett bra sätt att hitta automationskandidater på).
• Vid varje givet tillfälle, antalet olösta/ej levererade Requests (eller backlog om man vill).

Change Management

Om det finns en process som kan skapa både oro, irritation, glädje och lättnad så är det nog ITIL Processen Change Management. Historiskt har den ofta varit ett rött skynke för agila organisationer på grund av att den uppfattats som ett hinder för agila team och tekniker generellt.  I senaste versionen av processen har den därför anpassats mer till Agile/Devops såväl bytt namn några gånger på vägen. Ska man vara petig så heter den egentligen ”Change Enablement”. Syftet med processen är att ”maximera mängden framgångsrika förändringar i IT-miljön genom att hantera risker, godkänna förändringar och planera dem” så de inte krockar med varandra.

En Change definieras som varje ”addition, modification or removal of anything that could have a direct or indirect effect on services”. Helt enkelt ”vad som helst som vi ändrar i vår IT-miljö och som kan orsaka en incident av något slag”. I praktiska termer betyder det egentligen att även kodförändringar är ”change-ar”. Men oftast hanteras dessa inte som ITIL-change-ar utan som ”utvecklingsärenden, User stories” eller vad vi nu kallar dem. Den vanligaste tillämpningen av Change är sannolikt bara utifrån perspektivet ”kan vi få produktionssätta X-Y-Z. Vilket är bra men missar delar av potentialen i processen.

Varför Change Management (eller enablement som det heter i ITIL 4)

Några positiva effekter man bör kunna se av processen är:

• Tydligare och visualiserad information om vad som ändras i vår tekniska miljö.
• Färre oplanerade Incidenter (vet inte om det finns planerade eller om vi vill ha sådana?).
• Bättre koordinering av arbetet kring Change-ar.
• Snabbare hantering av förändringar (framför allt genom att identifiera och implementera standardförändringar).
• En effektiv hantering av akuta förändringar.

(historiska) Utmaningar Change Management

Som jag nämnde ovan är det inte ovanligt att man endast använder Change-processen för att godkänna produktionssättningar. Historiskt har detta tyvärr ofta varit vad man framför allt velat uppnå med processen. Hindra tekniker från att göra förändringar i miljön med dålig kvalitet som i sin tur resulterar i oönskade Incidenter. Hanteringen har därför ofta gjorts onödigt byråkratisk och väntetiderna på att få sin förändring godkänd blivit oönskat lång. Detta har lett till att många gjort sitt yttersta för att undvika processen. Bland annat genom att helt enkelt inte dokumentera förändringen alls eller endast till ett absolut minimum.  Den positiva bi-effekten är dock att bidra till nya bättre tekniker för sådant som DevOps pipelines och liknande. Något som också ITIL 4 har mycket fokus på bland annat genom sin nya ”practice Deployment Management”.

 Mätning Change Management

När det gäller nyckeltal så finns det lite olika vägar att gå. Många mäter inte alls, vissa mäter antal genomförda change-ar (och med det oftast godkända komponenter för produktionssättning). Medan andra har mer avancerade nyckeltal. Allt hänger på hur man definierar change-ar i organisationen. Om tillämpningen endast utgår från aspekten ”får vi produktionssätta detta…” så blir det mindre relevant att mäta sådant som ”ledtider”. Då ledtiden inte inkluderar allt förarbete.  

Har vi däremot en mer helhetlig bild av processen så kan det vara aktuellt att mäta sådant som:

• Inflöde och utflöde (färdigställt) per period.
• Ledtider.
• Nedlagt arbete (hur omfattande är förändringarna i arbetstid räknat.
• Andel framgångsrika Change-ar (dvs sådana som inte resulterar i oönskade incidenter)

Release Management

ITIL Processen Release management är nära förbunden med changeprocessen. Releaseprocessens syfte är ”to make new and changed services and features available for use”. Man kan alltså säga att change-processen använder sig av releaseprocessen för själva releasehanteringen. Det här kan tyckas lite som överadministration men tanken är att genom en strukturerad process kan vi utveckla bättre metoder, verktyg och tillämpningar. Som också inkluderar sådant som dokumentation, utbildning, handböcker och liknande.

Numer så är det inte ovanligt att agila team själva kan produktionssätta genom sin ”Delivery Pipeline”. Det har också vuxit fram en mängd olika tekniska stödfunktioner för sådant som A-B tester, toggle switching/feature flags och Blue/Green releases. 

ITIL särskiljer också på sina två olika ”practices” Release respektive Deployment Management, där den senare har fokus på själva den tekniska aspekten av att produktionssätta respektive flytta komponenter mellan olika miljöer. Medan Release har fokus på koordinering, planering och kommunikation.

Varför Release Management

En väl fungerande releaseprocess kan förväntas ge följande positiva effekter:

• Över tid enklare och mindre kostsamma produktionssättningar och releaser.
• Bättre koordination av releaser.
• Stabilare mijöer.
• Kortare ledtider.
• Möjligheter till experimentering för att identifiera bästa lösning framåt (A-B tester bla).

Utmaningar och mätning Release Management

Utmaningarna för Releaseprocessen varierar ganska mycket. Mest för att den ser så olika ut beroende på teknik, organisation etc. En historisk ofh dessvärre fortfarande vanlig utmaning är Releasepolicys som uppmanar till långa releaseperioder.  Oftast drivet av en önskan att sänka omkostnader, minska mängden fel tillika belastning på användare av ständiga avbrott. Men, längre tid mellan releaser innebär alltid längre ledtider från idé till realisering.  (Värt att notera här är att ibland har organisationer inget val, det kan vara yttre regulatoriska krav eller annat som är i vägen för en mer frekvent releasehantering).

Releaseprocessen kan mätas på en mängd sätt som kanske inte alltid skapar tydligt värde. Personligen är jag en anhängare av att mäta standardiserings- och automationsgrader av produktionssättningar tillika sådant som:

• Releasefrekvens (trend över tid som helst bör gå uppåt).
• Change fail rate (trend över tid som helst bör gå nedåt).
• Antal Change-ar/förändringar per release (vilket i önskat läge då ska bli färre och färre med tiden).