ITIL: vad det är och varför det spelar roll för din IT-leverantör

ITIL är ett av de ord som dyker upp i offerter och på leverantörers webbplatser utan att någon förklarar vad det betyder för dig. Den här sidan gör det, utan kursmaterialet. Den ingår i guiden om IT-drift och managed services, och den är skriven av någon som själv säljer IT-drift. Väg in det, och fråga gärna oss samma saker som du frågar alla andra.

Vad är ITIL?

ITIL är en samling vägledning för hur en IT-organisation planerar, levererar och förbättrar sina tjänster. Namnet var från början en förkortning av Information Technology Infrastructure Library. Ramverket togs fram av en brittisk myndighet under 1980-talet och gavs ut första gången 1989. I dag ägs det av det privata utbildningsföretaget PeopleCert.

Tanken är enkel. I stället för att varje IT-avdelning uppfinner sina egna rutiner för att ta emot felanmälningar, laga fel och göra ändringar, finns det en gemensam beskrivning av vad som brukar fungera. ITIL säger vad du ska uppnå och varför, inte exakt hur. Därför ser två leverantörer som båda "arbetar efter ITIL" ofta olika ut i praktiken.

Den version de flesta arbetar efter är ITIL 4 från 2019. I januari 2026 presenterade PeopleCert ITIL version 5, som införs stegvis under året och lever parallellt med ITIL 4 en tid. För dig som köpare ändrar det ingenting i sak. Incident, problem och förändring finns kvar, och det är dem du har nytta av att förstå.

Vilka processer är viktigast?

De tre du märker av som kund är incidenthantering, problemhantering och förändringshantering. ITIL 4 beskriver 34 så kallade praktiker, men de flesta av dem är leverantörens interna maskineri. De här tre är de som avgör hur det känns att vara kund.

Incident: något har slutat fungera

En incident är ett oplanerat avbrott eller en försämring av en tjänst. Målet med incidenthantering är enligt ITIL att begränsa skadan genom att få igång normal drift så snabbt som möjligt. Det betyder att en tillfällig lösning är helt okej, bara verksamheten rullar igen.

Säg att du driver ett åkeri med 30 anställda och att trafikledarna inte kan logga in i affärssystemet en måndagsmorgon. Det är en incident. Leverantören startar om tjänsten, alla kommer in och ärendet stängs. Hur incidenter prioriteras och vem som gör vad beskrivs i detalj i incidenthantering.

Problem: varför händer det igen?

Ett problem är i ITIL:s mening orsaken bakom en eller flera incidenter. Problemhantering handlar om att hitta den orsaken och minska risken att samma sak händer igen. Medan orsaken utreds dokumenteras en tillfällig väg runt, en så kallad workaround.

Fortsätt exemplet. Samma inloggningsfel kommer tillbaka tre måndagar i rad. Varje gång löses incidenten på tio minuter, och varje gång ser det bra ut i statistiken. Först när någon kopplar ihop de tre ärendena och hittar orsaken, kanske ett certifikat som går ut eller ett schemalagt jobb som krockar, försvinner felet på riktigt. Det är skillnaden mellan en leverantör som stänger ärenden och en som löser problem.

Förändring: ändra utan att förstöra

En förändring är att lägga till, ändra eller ta bort något som kan påverka IT-tjänsterna. I ITIL 4 kallas praktiken change enablement, och syftet är att så många förändringar som möjligt ska lyckas genom att risken bedöms innan någon trycker på knappen.

ITIL skiljer på tre typer. Standardändringar är vanliga och riskfria, som att lägga till en ny användare, och är godkända i förväg. Normala ändringar, som att flytta e-posten till ny plattform eller byta brandvägg, bedöms och planeras. Akuta ändringar görs direkt för att stoppa en allvarlig incident eller täppa till ett säkerhetshål, ofta en kritisk patch.

Du märker förändringshanteringen mest när den saknas. Någon uppdaterar brandväggen en tisdag förmiddag, lagret tappar kontakten med affärssystemet och ingen vet vad som ändrades. En leverantör med ordning kan svara på vad som ändrades, när, av vem och hur det backas.

ITIL för små och medelstora bolag

Ett litet bolag behöver inte införa ITIL, och det behöver inte ITIL-certifiering. Här är det ärliga svaret: ITIL-certifiering finns bara för personer, inte för organisationer. Ett företag kan alltså inte bli ITIL-certifierat, oavsett vad det står på en webbplats. Det som finns för organisationer är standarden ISO/IEC 20000, och den är sällan relevant för ett bolag med 20 anställda.

Det betyder inte att ITIL är ointressant för dig. Det betyder att det är din leverantörs verktygslåda, inte din. Du behöver inte kunna skillnaden mellan en normal och en standardändring. Du behöver veta att din leverantör kan den och att du ser resultatet, i form av ärendenummer, uppföljning och färre fel som kommer tillbaka.

Det finns också en risk åt andra hållet. Processer kan bli ett självändamål, där ett enkelt önskemål ska igenom tre godkännanden och en blankett. ITIL 4 och version 5 betonar själva att praktikerna ska anpassas efter verksamheten. Kräver din leverantör mer byråkrati av dig än du får nytta tillbaka, är det inte ITIL som är problemet.

Om du har egen IT-personal kan en grundkurs vara värd pengarna så att IT-personalen och leverantören pratar samma språk. För en vd eller ekonomichef räcker den här sidan.

Vad ska du fråga din leverantör?

Fråga efter hur arbetet syns, inte efter certifikat. En logga eller ett "vi arbetar enligt ITIL" i en offert säger lite. Svaren på de här frågorna säger mer.

1. Hur anmäler vi ett fel, och vad händer sedan? Du ska få ett ärendenummer och kunna följa ärendet. Läs mer om ärendets väg i IT service desk.
2. Hur prioriterar ni? Be om prioriteringsmodellen i klartext, och kontrollera att den stämmer med avtalet. Vad som ska stå i avtalet går vi igenom i SLA och serviceavtal.
3. Vad händer när samma fel kommer tillbaka? Fråga när ett ärende blir ett problemärende och vem som äger utredningen. Ett tydligt svar är ett gott tecken.
4. Mäter ni svarstid eller åtgärdstid? Ett automatiskt svar inom fem minuter är en svarstid. Det som spelar roll för dig är när felet är löst.
5. Hur gör ni ändringar i vår miljö? Vem godkänner, när görs de, och får vi veta i förväg? Fråga efter en ändringslogg.
6. Vad rapporterar ni till oss, och hur ofta? Antal ärenden, återkommande fel och ändringar är ett minimum.
7. Vad kostar det som ligger utanför avtalet? Ändringar och problemutredning faktureras ibland per timme, även när incidenterna ingår. Be om det skriftligt.

Den sista frågan är den som oftast glöms bort. En leverantör kan ha fasta priser på support och ändå ta betalt varje gång ett återkommande fel ska utredas. Då tjänar leverantören på att problemet finns kvar, och det är en dålig konstruktion för dig.

Det är beteendet du köper

ITIL är en beskrivning av god ordning, och god ordning syns i vardagen, inte i ett certifikat. Du behöver inte lära dig ramverket. Du behöver ställa frågorna ovan och lyssna efter konkreta svar. En leverantör som arbetar på riktigt kan visa ett ärende, ett problemärende och en ändringslogg på fem minuter. Be om att få se dem.

Så hjälper Nod till

Nod arbetar efter ITIL:s grundtankar för incidenter, problem och förändringar i de miljöer vi driftar. [FYLL I: hur Nods ärendeflöde ser ut, vad kunden ser i form av ärendenummer, rapportering och ändringslogg, och vad som ingår i avtalet respektive faktureras separat] I en kostnadsfri rådgivning visar vi hur ett ärende hanteras hos oss, och vi går gärna igenom frågorna ovan mot din nuvarande leverantör. Läs mer om IT-support hos Nod.