Een service level agreement (SLA) is een formele overeenkomst tussen een dienstverlener en een afnemer waarin de verwachte kwaliteit, beschikbaarheid en prestaties van een dienst worden vastgelegd. Een SLA definieert concreet wat er geleverd wordt, hoe dat gemeten wordt, en wat er gebeurt als de afgesproken niveaus niet worden gehaald. De afspraken in een SLA gelden voor elke organisatie die IT-diensten afneemt of levert, van interne IT-afdelingen tot externe leveranciers. Dit artikel beantwoordt de meest gestelde vragen over SLA-inhoud, meting, gevolgen en het opstellen van een effectieve SLA in de praktijk.
Welke afspraken horen er verplicht in een SLA thuis?
Een SLA bevat minimaal zes typen afspraken: een nauwkeurige beschrijving van de geleverde dienst, meetbare prestatienormen (zoals beschikbaarheid en responstijden), procedures voor incidentafhandeling, rapportageverplichtingen, escalatieprocedures en de looptijd of herzieningsfrequentie van de overeenkomst. Zonder deze elementen is een SLA geen bruikbaar sturingsinstrument.
De dienstbeschrijving vormt de basis. Hierin staat exact wat de dienst omvat, welke systemen of processen eronder vallen, en wat uitdrukkelijk buiten de scope valt. Vaagheid op dit punt leidt altijd tot discussie.
De prestatienormen zijn het hart van elke SLA. Denk aan:
- Beschikbaarheid uitgedrukt als percentage, bijvoorbeeld 99,5% per maand
- Maximale responstijd bij een incident, afhankelijk van prioriteit
- Maximale hersteltijd (ook wel RTO, Recovery Time Objective)
- Doorlooptijden voor standaardwijzigingen of serviceverzoeken
Daarnaast horen uitsluitingen en uitzonderingen expliciet in de SLA. Geplande onderhoudsmomenten tellen doorgaans niet mee voor de beschikbaarheidsberekening, maar dat moet dan wel worden vastgelegd. Hetzelfde geldt voor situaties buiten de invloedssfeer van de leverancier, zoals storingen bij externe netwerkproviders.
Tot slot zijn contactpersonen en escalatiepaden onmisbaar. Wie belt wie bij een P1-incident om drie uur ’s nachts? Een SLA zonder helder escalatiepad werkt niet in de praktijk.
Wat is het verschil tussen een SLA, OLA en UC?
Een SLA (service level agreement) is een overeenkomst tussen een dienstverlener en een externe klant. Een OLA (operational level agreement) is een interne afspraak tussen afdelingen binnen dezelfde organisatie die samen een dienst leveren. Een UC (underpinning contract) is een contract met een externe leverancier die de dienstverlener ondersteunt bij het nakomen van de SLA.
De drie documenten vormen samen een keten. De SLA beschrijft wat de klant mag verwachten. Om die beloften waar te maken, sluit de IT-afdeling intern OLA’s af met bijvoorbeeld de infrastructuurgroep of de servicedesk. Tegelijkertijd legt de IT-afdeling extern via een UC vast wat een cloudleverancier of datacenterpartij moet leveren.
In de praktijk zien veel organisaties problemen ontstaan doordat de OLA’s en UC’s niet zijn afgestemd op de SLA. Als de interne OLA een responstijd van vier uur toestaat, maar de SLA aan de klant twee uur belooft, is er een structureel probleem dat vroeg of laat zichtbaar wordt. Een goede IT-servicemanager zorgt ervoor dat alle drie de niveaus op elkaar aansluiten.
Hoe worden SLA-prestaties gemeten en gerapporteerd?
SLA-prestaties worden gemeten via monitoringtools die continu data verzamelen over beschikbaarheid, responstijden en afhandelingssnelheid. De resultaten worden periodiek gerapporteerd, doorgaans maandelijks, in een gestructureerd SLA-rapport dat beide partijen bespreken tijdens een service review meeting.
Effectieve meting vereist dat de meetmethode vooraf is vastgelegd in de SLA zelf. Vragen die beantwoord moeten zijn:
- Wie meet? De leverancier, de klant, of een onafhankelijke partij?
- Welk tijdvenster geldt? Alleen kantoortijden of 24 uur per dag, 7 dagen per week?
- Wat is de meetfrequentie en de rapportagefrequentie?
- Hoe wordt een incident geteld als het meerdere systemen raakt?
Een veelgemaakte fout is dat leveranciers hun eigen monitoringdata gebruiken zonder dat de klant inzage heeft in de ruwe gegevens. Een transparante SLA geeft de klant toegang tot dashboards of verplicht de leverancier tot gedetailleerde rapportages. Zo blijft de SLA een levend document in plaats van een papieren tijger.
Bij complexe IT-omgevingen, zoals organisaties die midden in een IT-transformatieproject zitten, is het verstandig om SLA-rapportages te koppelen aan bredere projectrapportages. Zo is direct zichtbaar of een verslechtering in prestaties samenhangt met een lopende migratie of implementatie.
Wat zijn de gevolgen als een SLA niet wordt gehaald?
Als een SLA niet wordt gehaald, treden de in de overeenkomst vastgelegde gevolgen in werking. Dit zijn doorgaans financiële credits of kortingen op de factuur (service credits), maar ook escalatieverplichtingen, verbeterplannen of in ernstige gevallen het recht om de overeenkomst te beëindigen.
Service credits zijn de meest gebruikte sanctie. De leverancier vergoedt een percentage van de maandelijkse vergoeding als de beschikbaarheid onder een drempelwaarde daalt. Hoe lager de beschikbaarheid, hoe hoger de credit. Dit mechanisme prikkelt de leverancier om te presteren, maar dekt zelden de werkelijke schade die de klant lijdt door uitval.
Naast financiële gevolgen zijn er ook procedurele gevolgen. Bij een structurele overschrijding van de SLA-normen kan de leverancier verplicht worden een verbeterplan op te stellen en te presenteren binnen een vastgestelde termijn. Wordt dat verbeterplan niet uitgevoerd of zijn de resultaten onvoldoende, dan kan dat leiden tot een formele contractreview of beëindiging.
Een punt dat in de praktijk vaak wordt onderschat: de SLA regelt de relatie, maar lost het onderliggende probleem niet op. Als een dienst structureel onderpresteert, is een service credit een schrale troost. Organisaties die merken dat hun IT-dienstverlening tekortschiet, zijn vaak gebaat bij externe expertise die het probleem bij de wortel aanpakt in plaats van maandelijks de credits te incasseren.
Wanneer is een SLA zinvol en wanneer niet?
Een SLA is zinvol wanneer er een duidelijke, meetbare dienst wordt geleverd waarvan de continuïteit en kwaliteit direct van invloed zijn op de bedrijfsvoering. Een SLA is minder zinvol bij projectmatige of eenmalige opdrachten, bij diensten die te complex zijn om in normen te vatten, of wanneer de relatie te informeel is om formele sancties te handhaven.
Een SLA werkt het beste in situaties zoals:
- Beheerde IT-diensten met een terugkerend karakter, zoals hosting, netwerkbeheer of servicedesk
- Kritische bedrijfsapplicaties waarbij uitval direct omzetverlies of veiligheidsrisico’s oplevert
- Compliancegevoelige omgevingen waar aantoonbare prestaties vereist zijn, bijvoorbeeld in het kader van NIS2-verplichtingen
- Relaties met externe leveranciers waarbij de organisatie afhankelijk is van hun prestaties
Een SLA is minder effectief wanneer de dienst voortdurend verandert, wanneer de meetbaarheid van prestaties laag is, of wanneer beide partijen niet de capaciteit hebben om de SLA actief te beheren. In dat geval kan een SLA meer bureaucratie opleveren dan waarde. Een goed alternatief is dan een minder formele dienstbeschrijving met periodieke evaluaties.
Hoe stel je een effectieve SLA op in de praktijk?
Een effectieve SLA stel je op door te beginnen bij de bedrijfsbehoefte, niet bij de techniek. Vertaal die behoefte naar meetbare normen, laat beide partijen de normen valideren, en zorg dat de SLA aansluit op de interne OLA’s en eventuele leverancierscontracten. Een SLA die niet wordt beheerd, werkt niet.
Volg bij het opstellen deze stappen:
- Breng de dienst volledig in kaart. Wat wordt er geleverd, aan wie, in welk tijdvenster en met welke afhankelijkheden?
- Stel meetbare normen vast. Gebruik concrete getallen: beschikbaarheidspercentages, responstijden per prioriteitsniveau, maximale hersteltijden.
- Valideer de normen op haalbaarheid. Zijn de normen realistisch gegeven de huidige infrastructuur en capaciteit? Een onhaalbare SLA ondermijnt het vertrouwen.
- Leg de meetmethode vast. Wie meet, hoe wordt gemeten, en hoe worden uitzonderingen behandeld?
- Beschrijf de gevolgen bij niet-nakoming. Zowel financiële als procedurele gevolgen, inclusief escalatiepaden.
- Plan periodieke reviews in. Minimaal jaarlijks, maar bij grote veranderingen in de dienstverlening ook tussentijds.
Een veelgemaakte fout is dat organisaties een SLA kopiëren van een vorige leverancier of een sjabloon gebruiken zonder de normen te toetsen aan de werkelijkheid. Het resultaat is een document dat bij de eerste incidentreview al niet klopt met de praktijk.
Bij organisaties die werken met externe IT-professionals, zoals de IT-specialisten van Ventus, is het verstandig om een servicemanager of IT-consultant te betrekken bij het opstellen van de SLA. Zij kennen de valkuilen uit de praktijk en zorgen dat de afspraken werkbaar zijn voor alle betrokken partijen. Ventus levert professionals met ruime ervaring in servicemanagement die organisaties helpen om SLA’s op te stellen die daadwerkelijk sturen op kwaliteit, niet alleen op papier.
Wil je weten hoe Ventus jouw organisatie kan ondersteunen bij het inrichten van IT-dienstverlening of het versterken van je IT-capaciteit? Neem contact op voor een vrijblijvend gesprek.