Sådan vælger du den rigtige IT-serviceaftale, KPI’er, svartider og hvad der bør stå i SLA’en

Når IT’en driller, er en IT serviceaftale lidt som en reservedunk i bilen. Du håber, du ikke får brug for den, men hvis motoren går i stå, vil du være glad for, at den er der, og at den faktisk passer til bilen.

Mange SMV’er køber support “som en pakke” og opdager først senere, at forventningerne ikke var fælles. Hvad betyder “hurtig hjælp”, hvordan måles kvaliteten, og hvem tager ansvar, når “produktionen er nede”?

Her får du en praktisk guide til at vælge den rigtige aftale, opstille KPI’er, aftale realistiske svartider og få en SLA (Service Level Agreement), som er tydelig nok til at holde i en travl hverdag.

Start med at definere servicen, ikke bare prisen

En IT serviceaftale bør starte med det konkrete: Hvilke services skal leveres, til hvem, og i hvilke tidsrum. Hvis du kun sammenligner pris, risikerer du at sammenligne æbler og pærer. Den billigste aftale kan være fin, hvis jeres behov er simple, men dyr, hvis der mangler drift, sikkerhed eller tydelige rammer.

Sørg for, at SLA’en beskriver servicekataloget i almindeligt sprog. Eksempler:

• Support til brugere (mail, Teams, printere, pc’er)

• Drift og overvågning (servere, netværk, Microsoft 365)

• Backup og restore (hvad testes, og hvor ofte)

• Sikkerhed (patching, endpoint protection, awareness)

Vær også skarp på servicevindue og tilgængelighed. Er support kun hverdage 8-16, eller inkluderer aftalen aften og weekend ved P1-hændelser? Hvis I har produktion, lager eller butikker, kan “åbningstid” være et reelt risikopunkt.

Dernæst, afklar ansvarsgrænser. Hvem gør hvad, hvis en internetlinje er nede, eller hvis en cloud-leverandør har fejl? Her er det vigtigt at skelne mellem jeres leverandør, jeres egne interne opgaver og tredjepartsleverandører.

Til sidst bør SLA’en tage højde for compliance og hændelser. Hvis der behandles persondata, skal roller og pligter hænge sammen med GDPR, se fx Datatilsynets vejledning og myndighedsside. Og hvis jeres branche eller kunder er omfattet af NIS2-krav, er det smart at få krav til hændelseshåndtering og rapportering ind tidligt, se den officielle NIS2-tekst i EUR-Lex.

KPI’er der kan måles, og som giver mening i hverdagen

KPI’er i en IT serviceaftale er som instrumentbrættet i bilen. De skal vise det, der betyder noget, ikke alt det, der er nemt at måle. En klassisk fejl er at fokusere på antal lukkede tickets, fordi det ser pænt ud, mens den reelle oplevelse hos brugerne falder.

Start med 6-10 KPI’er, som I faktisk kan følge månedligt. Aftal også, hvordan de måles: Hvad tæller med som “svartid”, gælder det kun i servicevindue, og hvad sker der ved manglende data?

Her er et konkret eksempel på KPI’er, der ofte giver værdi i SMV’er:

KPI’er bør kobles til en fast governance-rytme. En god, enkel model er:

Roller hos kunden: en kundeansvarlig (beslutninger og prioriteringer) og en daglig kontakt (koordinering). Roller hos leverandøren: en service manager (SLA, rapporter, forbedringer) og en teknisk ansvarlig (drift og ændringer).

Rytme: månedlig rapport (KPI’er, større hændelser, backlog) og kvartalsmøde (trend, risici, plan for forbedringer).

Hvis du vil læne dig op ad kendte rammer, kan du bruge ISO 20000 som pejlemærke for service management, se ISO/IEC 20000-1:2018 hos ISO.

Svartider, prioriteringer og eskalation, så der ikke opstår tvivl

Svartider lyder simple, men det er her, mange SLA’er knækker. Årsagen er næsten altid uklar prioritet, uklare “stopure” eller en forventning om, at alt er akut. Løsningen er at aftale et fælles sprog for prioritet og konsekvens.

Brug prioritet ud fra impact og urgency, ikke hvem der råber højest. Her er et eksempel på en praktisk prioriteringsmodel:

Nøglen er at skrive, hvornår tiden tæller. Gælder tiderne kun i servicevindue? Pauser “klokken”, hvis I venter på svar fra en tredjepart? Og hvad er en acceptabel workaround, hvis en endelig løsning kræver ændringer?

SLA-tjekliste (hurtig at gennemgå)

• Servicevindue og kontaktveje (portal, mail, telefon)

• Prioriteter, definitioner og konkrete eksempler (P1-P4)

• Svarstid, løsningstid og krav til statusopdateringer

• Eskalationsvej, hvem kontaktes hvornår

• Hvad er inkluderet, og hvad er “tilkøb” (projekter, større changes)

• Sikkerhed og hændelser (patching, EDR, logning, rapportering)

• Backup, restore og testfrekvens

• Rapportering (KPI’er, format, deadline) og møderytme

• Ændringshåndtering (godkendelse, tidsplan, rollback)

• Exit og overdragelse (dokumentation, adgang, data)

Korte eksempler på SLA-formuleringer (til inspiration)

Servicevindue: “Support leveres hverdage 08.00-16.00. P1 kan håndteres uden for servicevindue efter aftalt beredskab.” Rapportering: “Leverandøren sender månedlig rapport senest den 5. arbejdsdag med KPI’er, hændelser og anbefalede forbedringer.” Eskalation: “Ved P1 eskaleres til vagtansvarlig inden for 30 minutter, hvis der ikke er igangsat afhjælpning.”

For flere praktiske SLA-greb kan du sammenligne med SLA best practices fra TOPdesk, især omkring prioritering og forventningsafstemning.

Konklusion: En god SLA gør hverdagen roligere

En IT serviceaftale virker bedst, når den gør det nemt at være enige, også når noget går galt. Definér servicen tydeligt, vælg KPI’er der kan styres på, og aftal prioritet og svartider med konkrete eksempler som P1 “produktion nede”. Få roller og møderytme på plads, så aftalen bliver brugt, ikke gemt.

Kort disclaimer: Indholdet her er praktisk vejledning og ikke juridisk rådgivning. Hvis du er i tvivl om kontraktvilkår, så få dem gennemgået.