Hvilke målbare serviceniveauer bør en SLA indeholde?

Målbare serviceniveauer: Det bør en SLA indeholde

En SLA (Service Level Agreement) er en formel aftale mellem tjenesteudbyder og kunde om, hvilke serviceniveauer der skal leveres. Evidis teknologiordbog angiver, at en SLA specificerer målbare kriterier som oppetid (uptime), responstid (response time), løsningstid (resolution time), supportniveauer og konsekvenser ved afvigelser. SLA'er bruges både internt i IT-organisationer og i eksterne outsourcingaftaler og dækker fx cloudtjenester, drift, integration, applikationsstyring og managed services.

Faste komponenter er tilgængelighed, responstid, løsningstid, prioritetsniveauer (P1–P4), måling og rapportering samt sanktioner/servicekreditter. Hvert tal skal have en defineret målemetode: hvornår uret starter og stopper, hvilken periode der måles over, og hvem der registrerer hændelsen. Ellers er et procent- eller minutantal ikke et serviceniveau, men et løfte, som parterne kan læse forskelligt. Nordic Computer formulerer samme udgangspunkt: en SLA opstiller klare forventninger og målbare målsætninger for begge parter.

Komponenter i en målbare SLA

Tilgængelighed og oppetid

Tilgængelighed (availability/uptime) er den andel af tiden, hvor tjenesten skal være tilgængelig. Microsoft offentliggør standardiserede SLA'er for sine cloudtjenester, ofte som tilgængelighed i procent pr. måned.

Den afgørende detalje er definitionen af nedetid. Aftal, hvad der tæller som nedetid – er hele tjenesten utilgængelig, eller er det enkelte funktioner? – hvor tilgængeligheden måles fra (et eksternt målepunkt eller leverandørens egen overvågning?), og om planlagt vedligeholdelse og aftalte vedligeholdelsesvinduer undtages. Omsæt procentsatsen til minutter i måleperioden, så begge parter kan se, hvad en afvigelse betyder i praksis, og aftal, hvor hurtigt nedetid skal registreres og dokumenteres. Består tjenesten af flere komponenter, bør aftalen beskrive, hvilke der indgår i opgørelsen.

Responstid: første respons ved en hændelse

Responstid er tiden til første respons ved en hændelse. Den måler ikke, hvornår problemet er løst, men hvor hurtigt kunden hører fra leverandøren; den kan opgøres pr. hændelse eller pr. prioritetsniveau.

I praksis bør I aftale, hvornår uret starter (typisk ved registrering i ticketsystemet), om responstiden gælder døgnet rundt eller kun inden for åbningstiden, og hvad der tæller som en respons – en automatisk kvittering bør ikke tælle. For sikkerhedsovervågning viser et eksempel fra en administreret SOC-tjeneste en tabelstruktur, hvor hver metrik har klare, målbare mål: sværhedsgrad, svartid, nødvendige handlinger og eskaleringstærskel. Eskaleringstærskel er et af felterne i metrikken.

Responstid vs. løsningstid

Løsningstid: tid til afhjælpning

Løsningstid er tiden, indtil hændelsen er afhjulpet. Det er den metrik, kunden reelt oplever, og den skal holdes skarpt adskilt fra responstiden i aftaleteksten: en leverandør kan svare inden for få minutter og alligevel bruge dage på at afhjælpe problemet.

Definer, hvornår uret stopper: Lukker leverandøren sagen, eller kræves kundens bekræftelse? Tæller en midlertidig omgåelsesløsning som afhjælpning, eller skal den permanente rettelse være på plads? Sættes uret på pause, mens man venter på oplysninger fra kunden, og hvordan dokumenteres det? I Microsoft-miljøer kan svartider og løsningstider ved sagsbehandling overvåges og rapporteres automatisk, fx i Dynamics 365, og den slags systemdata er et bedre grundlag for afregning end manuelle opgørelser.

Fra hændelse til lukket sag

P1–P4: Prioritetsniveauer med hver deres mål

SLA'er opererer typisk med flere prioritetsniveauer, oftest P1–P4, og hvert niveau bør have egne målbare mål for både responstid og løsningstid. Niveauerne gør aftalen operationel: uden prioritering kan en leverandør overholde et gennemsnitligt løfte, mens kritiske hændelser ligger stille.

Fastlæg kriterierne for hvert niveau, før aftalen underskrives. Prioritet bør afledes af konsekvensen for forretningen og af, hvor mange brugere der er ramt – ikke af, hvem der ringer først. Skriv konkrete eksempler ind på, hvilke hændelser der er P1 i jeres opsætning, hvem der kan opgradere en sag, og hvordan uenighed om prioritet afgøres. Eskaleringstrappen – hvornår og til hvem en sag eskaleres – hører sammen med det enkelte niveau, som SOC-eksemplet viser med sværhedsgrad, svartid, nødvendige handlinger og eskaleringstærskel.

Fastlæg P1–P4 før underskrift

Måling, rapportering og supplerende måltal

Opfølgningen bør dække svartid, løsningstid, ticketvolumen pr. team eller medarbejder, SLA-overholdelse og kundetilfredshed. Det er standardrapporterne i HubSpot Service Hub, og kundetilfredshed måles typisk med CSAT, NPS og CES – supplerende mål for oplevet kvalitet, der ikke i sig selv siger, om responstiden blev holdt.

Ifølge HubSpot kommer reel værdi fra 3–5 rigtige KPI'er pr. team og en fast review-rytme. Hent tallene fra ticketsystemet frem for fra leverandørens egen månedsrapport, og opgør SLA-overholdelsen pr. prioritetsniveau, så P1-mål ikke drukner i et samlet gennemsnit. I feltarbejde og drift kan SLA hit rate følges sammen med fx rejseminutter pr. job og førstebesøg reparationer.

KPI'er til SLA-opfølgning

Konsekvenser ved afvigelser: Servicekreditter og sanktioner

En SLA bør indeholde aftalte konsekvenser, når de målbare niveauer ikke overholdes, fx servicekreditter eller kompensation ved manglende levering.

Aftal i detaljer: hvilke niveauer der udløser en kredit, hvad kreditten beregnes ud fra, om der er et loft, hvordan man gør krav gældende, og om kreditten er den eneste kompensation, eller om andre rettigheder består. Gentagne afvigelser bør have deres egen konsekvens, fx ret til eskalering til et højere ledelsesniveau eller til at opsige aftalen. Skriv samtidig, hvordan overskridelser dokumenteres – gerne med udtræk fra ticketsystemet som bilag.

Konsekvenser ved afvigelser

Sådan vælger I de rigtige niveauer for jeres virksomhed

Vælg niveauerne ud fra forretningskritikalitet: hvilke systemer og processer kan virksomheden ikke køre uden, og hvor kort må en afbrydelse vare? Derefter vælger I SLA-model. Nordic Computer beskriver tre: servicebaserede SLA'er med en standardiseret servicepakke til alle kunder, kundebaserede SLA'er, der samler de tjenester, kunden har behov for, i én aftale, og multi-level SLA'er opdelt i virksomheds-, kunde- og serviceniveau. SLA'er bruges både internt og eksternt, og kravene bør følge tjenestens betydning frem for hvem, der leverer den.

Et IT-servicekatalog gør arbejdet lettere, fordi niveauet defineres pr. service. Gräf Gruppe anbefaler, at der pr. service mindst beskrives: servicebeskrivelse i forståeligt sprog (formål, nytte, omfang), serviceowner og ansvar efter RACI-logik med eskalationsvej, service levels i form af fx reaktionstider og genopretningstider, bestillings- og fulfilmentproces (kanaler, godkendelser, gennemløbstid), prismodel og afregning (chargeback/showback) samt afhængigheder. En konkret SLA fra Aarhus Universitetsbibliotek viser samme princip i det små: hver ydelse beskrives med feltet “Ydelse”, betegnelsen for den pågældende ydelse, og en “Kort beskrivelse” med fokus på formålet. Gräf Gruppe henviser desuden til HDI Practices & Salary Report for, at organisationer med modne ITSM-praksisser oftere rapporterer højere kundetilfredshed og mere stabile driftsnøgletal.

Tre SLA-modeller

Indhold i IT-servicekatalog pr. service