Vad är Service Level Management (SLM)?

Service Level Management (SLM) är den process som skapar, följer upp och förbättrar de avtal om servicenivå som en IT-organisation eller annan stödfunktion ingår med sina kunder och interna leverantörer. Kort sagt: det är sättet att definiera vad som är ”tillräckligt bra” och sedan bevisa att man levererar det.

I praktiken handlar SLM om att formalisera en dialog som annars sker informellt och ofta leder till missförstånd. Verksamheten förväntar sig att IT ska lösa ärenden snabbt. IT vet inte hur snabbt det förväntas gå. Resultatet är konflikter som hade kunnat förebyggas med ett tydligt serviceavtal och en systematisk uppföljning.

Den här guiden förklarar vad Service Level Management är, hur begrepp som SLA, OLA och uppföljning fungerar i praktiken och vad du behöver tänka på för att arbeta strukturerat med SLM i din organisation.

Vad innebär Service Level Management i praktiken?

Service Level Management är en av de centrala processerna i ITIL-ramverket och används i de flesta ITSM-system. Men det är viktigt att förstå att SLM inte är detsamma som att skriva ett avtal och sedan glömma det.

En fungerande SLM-process innehåller tre delar:

Definiera: Vad lovar vi, till vem och under vilka förutsättningar? Det kan handla om att incidenter med hög prioritet ska börja hanteras inom 15 minuter, att normala servicefrågor besvaras inom en arbetsdag eller att systemet ska ha en drifttid på 99,5 procent.

Leverera: Organisationen arbetar aktivt för att hålla de överenskomna nivåerna. Det kräver rätt processer, rätt verktyg och tydlig ansvarsfördelning.

Följ upp: Regelbundna rapporter och möten visar om servicenivåerna hålls. Om de inte gör det analyseras orsaken och korrigerande åtgärder vidtas. Utan uppföljning är ett SLA värdelöst.

Vad är ett SLA och hur skiljer det sig från ett OLA?

SLA, Service Level Agreement, är ett avtal om servicenivå mellan IT-organisationen (eller en annan stödfunktion) och kunden. Kunden kan vara en extern kund, en intern verksamhet eller en hel organisation. SLA:t definierar vad som ska levereras, hur snabbt och hur tillgängligt.

OLA, Operating Level Agreement, är ett internt avtal mellan olika team eller avdelningar inom IT-organisationen. Om en serviceavdelning lovar kunden att incidenter löses inom fyra timmar behöver de säkerställa att nätverksteamet, driftteamet och applikationsteamet var och en levererar sin del av lösningen inom den tidsramen. Det är just det som ett OLA reglerar.

Skillnaden är enkel: ett SLA är en yttre överenskommelse med kunden, ett OLA är en inre överenskommelse som ser till att organisationen faktiskt kan uppfylla SLA:t. Utan fungerande OLA:er är ett ambitiöst SLA bara ett dokument med fina löften.

Underpinning contracts

Det finns ett tredje begrepp som ofta nämns i sammanhanget: underpinning contracts, eller UC. Det är externa avtal med leverantörer, exempelvis ett driftsavtal med ett datacenter eller ett supportavtal med en mjukvaruleverantör. Precis som OLA:er stödjer SLA:er, stödjer UC:er OLA:er.

Kedjan ser alltså ut så här: UC stödjer OLA, OLA stödjer SLA. SLM-processen ansvarar för att hela kedjan fungerar och att organisationen kan leverera det man lovat.

Hur fungerar SLA-uppföljning i praktiken?

SLA-uppföljning är kärnan i Service Level Management. Det räcker inte att ha skrivit ett avtal. Du behöver kunna mäta om du håller det och, om du inte gör det, förstå varför.

I ett modernt ärendehanteringssystem eller ITSM-verktyg är SLA-uppföljning ett inbyggt flöde. Varje ärende kopplas till ett serviceavtal som definierar tidsramar. Systemet räknar automatiskt ut om ärendet riskerar att bryta mot SLA:t, skickar notiser till handläggare och team och loggar varje händelse med tidsstämpel.

Det gör att du i efterhand kan se hur stor andel av incidenterna som löstes inom avtalad tid, vilka typer av ärenden som orsakar flest SLA-brott och vilka team eller handläggare som har svårast att hålla tiderna.

Det är den informationen som gör SLA-uppföljning till ett verktyg för förbättring, inte bara ett sätt att mäta om man lyckats eller misslyckats.

SLA-brott och eskalering

När ett ärende riskerar att bryta mot ett SLA behöver systemet agera. Det kan handla om en automatisk notis till handläggaren, en eskalering till teamledarens kö eller en varning till IT-chefen. Exakt vad som händer och vid vilken tidsgräns definieras i systemets eskaleringsregler.

En viktig detalj: många organisationer mäter responstid och lösningstid var för sig. Responstiden är hur lång tid det tar från att ärendet registreras tills någon börjar arbeta med det. Lösningstiden är tiden från registrering till att ärendet stängs. Båda kan täckas av separata SLA-krav.

Vilka typer av SLA finns det?

Det finns tre vanliga varianter av serviceavtal som en SLM-process behöver hantera.

Kundbaserat SLA

Ett SLA som täcker alla tjänster som levereras till en specifik kund eller verksamhetsenhet. Om IT-avdelningen betjänar exempelvis ekonomiavdelningen, HR och verksamhetsstöd kan varje avdelning ha ett eget kundbaserat SLA med de servicenivåer som speglar deras behov och kritikalitet.

Tjänstebaserat SLA

Ett SLA som är knutet till en specifik tjänst och gäller alla som använder den, oavsett vilken verksamhetsdel de tillhör. Exempelvis kan e-posttjänsten ha en definierad tillgänglighet på 99,9 procent som gäller hela organisationen.

Flernivå-SLA

En kombination av de ovanstående. I en komplex organisation med många tjänster och många kunder är det vanligt att ha ett övergripande SLA för hela organisationen, sedan tjänstespecifika nivåer och kundspecifika tillägg ovanpå. Det kräver ett system som kan hantera hierarkier av serviceavtal utan att det blir ogenomskådligt.

Varför behöver svenska organisationer arbeta med SLM?

Frågan är egentligen den omvända: vad händer om man inte arbetar med Service Level Management?

Utan SLM saknas tydlighet. Verksamheten vet inte vad den kan förvänta sig av IT. IT vet inte vad den ska prioritera. Ärenden hanteras utifrån vem som skriker högst eller vems chef har mest inflytande, inte utifrån faktisk kritikalitet eller avtalade nivåer.

För kommuner och regioner är det extra tydligt. Offentlig sektor levererar tjänster till medborgare och medarbetare under krav på likabehandling och transparens. En strukturerad SLM-process är ett sätt att leva upp till de kraven internt, och att kunna visa att man gör det.

Dessutom kräver NIS2-direktivet och DORA (för finanssektorn) att organisationer kan dokumentera och följa upp sin förmåga att upprätthålla kritiska tjänster. SLM ger en naturlig struktur för det arbetet.

SLM och ITIL

Service Level Management är en av de väldefinierade processerna i ITIL-ramverket och har funnits med sedan de tidiga versionerna. I ITIL 4 beskrivs SLM som en praktik snarare än en process, med tonvikt på att skapa värde i samarbete med kunden, inte bara att administrera avtal.

Det praktiska arbetet är detsamma: definiera, leverera, följ upp och förbättra. Men ITIL 4 betonar att SLA:t i sig inte är målet. Målet är att kunden upplever att IT-organisationen bidrar till verksamheten på ett förutsägbart och tillförlitligt sätt.

Vill du veta mer om ITIL-ramverket och hur det förhåller sig till ITSM-arbetet? Läs vår guide om vad ITIL-processer är och hur de används i praktiken.

Service Level Management i Easit GO

Easit GO har inbyggt stöd för Service Level Management som en central del av ärendehanteringen. Du definierar serviceavtal och kopplar dem till ärendetyper, kunder eller tjänster. Systemet räknar sedan automatiskt svarstider, lösningstider och eskaleringsregler utifrån de avtal du konfigurerat.

SLA-uppföljningen sker i realtid: du ser direkt hur stor andel av ärendena som hålls inom avtalad tid, vilka som riskerar att bryta mot SLA:t och hur historiken ser ut för ett specifikt avtal eller ett specifikt team.

Du kan också konfigurera OLA:er för interna team, vilket gör det möjligt att spåra om ett visst teams bidrag är det som orsakar SLA-brott uppströms. Det ger en detaljerad bild av var i kedjan förbättringsarbetet behöver sättas in.

Rapporter och dashboardvyer för SLA-statistik ingår i standardleveransen och kan anpassas för att spegla de nyckeltal som är relevanta för din organisation.

Kom igång med Service Level Management

Det vanligaste misstaget när organisationer börjar med SLM är att de formulerar ambitiösa SLA:er utan att ha kartlagt om de faktiskt kan hålla dem. Resultatet är avtal som bryts regelbundet och som skapar mer frustration än de löser.

En bättre utgångspunkt är att börja med att mäta verkligheten. Hur lång tid tar det faktiskt att lösa incidenter i dag? Vad är den realistiska kapaciteten hos teamet? Utifrån den bilden kan du sätta servicenivåer som är ambitiösa men möjliga, och sedan arbeta systematiskt för att förbättra dem. Hur ett sådant införande går till steg för steg beskriver vi i e-guiden Att införa Service Level Management.

Nästa steg är att säkerställa att systemet du använder kan automatisera uppföljningen. Manuell SLA-uppföljning i kalkylblad fungerar möjligtvis i en liten organisation med ett fåtal avtal. I en organisation med hundratals ärenden per vecka och flera olika servicenivåer krävs ett system som hanterar det automatiskt.

Vill du förstå hur ärendehanteringssystemet fungerar som grund för SLM-arbetet? Läs vår guide om vad ett ärendehanteringssystem är.

Sammanfattning

Service Level Management (SLM) är processen för att definiera, leverera och följa upp servicenivåer i en IT-organisation eller annan stödfunktion. SLA (Service Level Agreement) är avtalet med kunden, OLA (Operating Level Agreement) är det interna avtalet som ser till att SLA:t kan hållas, och underpinning contracts reglerar externa leverantörers åtaganden.

En fungerande SLM-process kräver tre saker: tydliga avtal, ett system som kan automatisera uppföljningen och en kultur av kontinuerlig förbättring baserad på faktiska mätvärden.

Easit GO har inbyggt stöd för hela SLM-processen och låter dig konfigurera, följa upp och rapportera på servicenivåer direkt i det dagliga ärendearbetet.