Hvad er en SLA i IT-support?
SLA står for Service Level Agreement, på dansk en serviceniveauaftale. Det er den del af IT-kontrakten, der beskriver, hvor hurtigt og hvor godt leverandøren skal levere, og hvad der sker, hvis det ikke lykkes. Uden en SLA har I en leverandør, der lover at hjælpe. Med en SLA har I en leverandør, der har forpligtet sig til målbare tider.
Mange virksomheder skriver under på en SLA uden at læse den grundigt, fordi tallene ser pæne ud. Problemet opstår først, når serveren står stille en mandag morgen, og det viser sig, at »svartid 1 time« kun betyder, at nogen har svaret på mailen.
Svartid og løsningstid er to forskellige ting
Den vigtigste skelnen i enhver SLA er forskellen mellem svartid og løsningstid.
| Begreb | Hvad det betyder | Typisk faldgrube |
|---|---|---|
| Svartid | Tiden fra sagen er oprettet, til en tekniker begynder at arbejde på den | Et automatisk kvitteringssvar tæller ikke som svar |
| Løsningstid | Tiden fra sagen er oprettet, til problemet er løst eller omgået | Ofte kun en målsætning, ikke en forpligtelse |
| Servicevindue | De timer, hvor tiderne gælder | Tiden står stille uden for vinduet |
| Tilgængelighed | Hvor stor en del af tiden en tjeneste skal virke | Planlagt vedligehold er ofte trukket fra |
Svartiden er nem for en leverandør at love, fordi den kun kræver, at nogen tager sagen. Løsningstiden er sværere, fordi den afhænger af problemets art, af tredjepart som Microsoft eller internetudbyderen, og af, om I selv er tilgængelige. Derfor er løsningstid ofte formuleret som et mål og ikke som en garanti. Det er i orden, så længe I ved det.
Læg også mærke til, hvornår uret starter. Starter det, når I sender en mail, når sagen er registreret, eller når den er kategoriseret? Og stopper det, når leverandøren mener, at sagen er løst, eller når I har bekræftet det?
Prioriteter: ikke alle sager er lige vigtige
En god SLA skelner mellem sager efter, hvor hårdt de rammer forretningen. En almindelig model har fire niveauer:
- Kritisk: hele virksomheden eller en kritisk funktion står stille, fx mailen er nede for alle, eller webshoppen kan ikke tage imod ordrer.
- Høj: en afdeling eller en vigtig funktion er ramt, men der findes en midlertidig udvej.
- Normal: en enkelt bruger har et problem, der hindrer arbejdet.
- Lav: ønsker, spørgsmål og ændringer, der kan planlægges.
Det vigtige er, hvem der afgør prioriteten. Står det i aftalen, at leverandøren alene bestemmer, kan en kritisk sag ende som »normal«. Bed om klare eksempler for hvert niveau i aftalen og en ret til at eskalere, hvis I er uenige.
Hvad I bør kræve i en SLA
Når I læser et udkast, så gå efter disse punkter:
- Klare definitioner af svartid og løsningstid, og hvornår uret starter og stopper.
- Et servicevindue, der passer til jeres arbejdstid. Arbejder I fra kl. 6, hjælper en aftale fra kl. 8 ikke meget.
- Hvordan sager oprettes: telefon, mail, portal, og om alle kanaler tæller ens.
- En eskaleringsvej med navne eller roller, hvis en sag går i stå.
- Månedlig rapportering, så I kan se, om tiderne faktisk holdes.
- Hvad der sker ved brud: kreditering, ret til opsigelse eller en fast opfølgning.
- Undtagelser, fx fejl hos tredjepart eller ændringer, I selv har lavet uden at spørge.
Bed om tallene, ikke kun løftet. En leverandør, der kan vise en månedlig rapport over svartider fordelt på prioritet, har som regel styr på sin drift. En leverandør, der ikke kan, ved måske ikke selv, om aftalen holdes.
Hvilket niveau har I brug for?
Kortere svartid koster mere, fordi leverandøren skal have flere folk klar. Det rigtige niveau afhænger af, hvad en times nedetid koster jer. For et revisionskontor med 10 medarbejdere, der arbejder i dagtimerne, er en svartid på en time i åbningstiden ofte rigeligt. For en webshop eller en produktionsvirksomhed med nathold kan det være nødvendigt med døgnsupport og en vagt, der kan tage kritiske sager uden for normal arbejdstid.
Som eksempel arbejder vi selv med tre niveauer: 15 minutters svartid på Premium, en time på Standard og fire timer på Basis. Hvordan niveauerne adskiller sig, og hvad der er med i hvert, kan I se under supportniveauer og SLA.
Et realistisk eksempel
En logistikvirksomhed med 40 ansatte har en aftale med »svartid 2 timer«. En torsdag kl. 16.30 holder terminalerne på lageret op med at printe fragtsedler. Sagen oprettes via mail. Kl. 17 lukker leverandørens servicevindue, og uret stopper. Næste morgen kl. 8 starter det igen, og en tekniker ringer kl. 9.15. Ifølge aftalen er svartiden holdt, men lageret har mistet en hel aftens forsendelser.
Ved genforhandlingen får virksomheden skrevet ind, at printning af fragtsedler er en kritisk funktion, at kritiske sager kan oprettes via telefon døgnet rundt, og at der rapporteres månedligt på svartider pr. prioritet. Prisen stiger, men nu passer aftalen til den måde, virksomheden faktisk arbejder på.
Typiske faldgruber
- Gennemsnit i stedet for grænser. »Gennemsnitlig svartid 30 minutter« kan dække over enkelte sager, der venter en hel dag.
- Tider, der kun gælder mail. Tjek, om en opringning registreres som en sag med det samme.
- Ingen konsekvens. En SLA uden opfølgning ved brud er en hensigtserklæring.
- Glemte afhængigheder. Er jeres internetforbindelse eller regnskabssystem leveret af en anden, gælder IT-partnerens SLA ikke for dem.
Næste skridt
Tag jeres nuværende aftale frem, og læs den med listen ovenfor ved siden af. Er I i tvivl om, hvad jeres SLA faktisk dækker, eller vil I sammenligne med en ny aftale, kan I sende os aftalen, så gennemgår vi den og peger på de punkter, der bør afklares.
Apply-redaktionen
Drift og support