Wat moet er in een ICT-SLA staan?

Een ICT-SLA moet minimaal de volgende onderdelen bevatten: een duidelijke omschrijving van de diensten, meetbare prestatienormen zoals respons- en oplostijden, verantwoordelijkheden van beide partijen, escalatieprocedures en afspraken over rapportage en evaluatie. Een goede service level agreement voor ICT legt de verwachtingen van zowel de klant als de dienstverlener concreet en transparant vast. In dit artikel beantwoorden we de meest gestelde vragen over de inhoud en het opstellen van een ICT-SLA.

Welke onderdelen zijn verplicht in een ICT-SLA?

Een ICT-SLA bevat verplicht de volgende kernelementen: een servicebeschrijving, prestatienormen, verantwoordelijkheden, beschikbaarheidsafspraken, escalatieprocedures en rapportageverplichtingen. Zonder deze onderdelen biedt een SLA onvoldoende houvast bij geschillen of tegenvallende prestaties. De SLA-inhoud bepaalt in grote mate hoe bruikbaar het document is in de praktijk.

• Servicebeschrijving: Wat wordt er precies geleverd? Denk aan beheer van werkplekken, netwerkbeheer of helpdesksupport. Hoe specifieker, hoe beter.
• Prestatienormen: Meetbare normen voor beschikbaarheid (bijvoorbeeld 99,5% uptime), responstijden en oplostijden per prioriteitsniveau.
• Verantwoordelijkheden: Wie doet wat? Leg vast welke taken bij de dienstverlener liggen en welke bij de klant.
• Escalatieprocedure: Wat gebeurt er als een incident niet op tijd wordt opgelost? Wie wordt er wanneer geïnformeerd?
• Rapportage en evaluatie: Hoe vaak wordt er gerapporteerd over de prestaties, en wie is verantwoordelijk voor het aanleveren van die data?
• Uitsluitingen: Wat valt expliciet buiten de scope van de overeenkomst?

Een veelgemaakte fout is het weglaten van uitsluitingen. Als je niet vastlegt wat er niet in de SLA zit, ontstaan er later discussies over verwachtingen die nooit zijn afgesproken. Een volledig ICT-beheercontract maakt dit soort misverstanden vooraf onmogelijk.

Wat is het verschil tussen een SLA, OLA en UC?

Een SLA (Service Level Agreement) is een overeenkomst tussen een dienstverlener en een klant. Een OLA (Operational Level Agreement) is een interne afspraak binnen de dienstverlener zelf, tussen afdelingen. Een UC (Underpinning Contract) is een contract tussen de dienstverlener en een externe leverancier die bijdraagt aan de dienstverlening.

In de praktijk werken deze drie documenten als een keten. De klant ziet alleen de SLA, maar de afspraken daarin zijn alleen haalbaar als de interne teams (OLA) en externe partijen (UC) hun bijdrage leveren. Als een dienstverlener bijvoorbeeld belooft dat een storing binnen vier uur is opgelost, moeten de interne afdeling en eventuele hardwareleveranciers binnen die vier uur hun deel hebben afgerond.

Voor jou als klant is het belangrijk om te weten dat een SLA alleen zo sterk is als de onderliggende OLA’s en UC’s. Vraag bij het opstellen van een SLA gerust door op welke externe partijen de dienstverlener steunt en hoe die afspraken zijn geborgd.

Hoe bepaal je realistische respons- en oplostijden?

Realistische respons- en oplostijden bepaal je door incidenten in te delen naar prioriteit en per prioriteit een haalbare norm te stellen op basis van de complexiteit, de beschikbare capaciteit en de impact op de bedrijfsvoering. Normen die op papier ambitieus klinken maar in de praktijk niet worden gehaald, ondermijnen het vertrouwen in de hele SLA.

Een gangbare indeling werkt met drie of vier prioriteitsniveaus:

1. Kritiek (P1): Volledige uitval van een bedrijfskritisch systeem. Responstijd van 15 tot 30 minuten, oplostijd binnen 4 uur.
2. Hoog (P2): Ernstige verstoring met grote impact. Responstijd binnen 1 uur, oplostijd binnen 8 uur.
3. Normaal (P3): Beperkte impact, werk kan gedeeltelijk doorgaan. Responstijd binnen 4 uur, oplostijd binnen 2 werkdagen.
4. Laag (P4): Kleine vraag of wens. Responstijd binnen 1 werkdag, oplostijd binnen 5 werkdagen.

Houd bij het bepalen van deze tijden rekening met servicevensters. Een responstijd van 1 uur is iets anders als de helpdesk alleen op werkdagen van 08:00 tot 17:00 bereikbaar is. Leg dit soort randvoorwaarden altijd expliciet vast in het ICT-contract.

Welke KPI’s horen thuis in een ICT-SLA?

De meest relevante KPI’s voor een ICT-SLA zijn: beschikbaarheidspercentage, gemiddelde responstijd, gemiddelde oplostijd, percentage incidenten opgelost binnen de afgesproken tijd (SLA-nalevingspercentage) en klanttevredenheid. Deze indicatoren maken prestaties meetbaar en bespreekbaar.

KPI’s zonder goede meetmethode zijn waardeloos. Spreek bij elke KPI ook af hoe en wanneer deze wordt gemeten, wie de data aanlevert en wat de consequentie is als een norm structureel niet wordt gehaald. Overweeg ook de volgende aanvullende KPI’s, afhankelijk van de dienstverlening:

• First-call resolution rate: Percentage meldingen dat direct bij het eerste contact wordt opgelost.
• Uptime van kritieke systemen: Gemeten beschikbaarheid van servers, netwerk of applicaties.
• Aantal herhalende incidenten: Signaleert structurele problemen die om een structurele oplossing vragen.
• Patchnaleving: Percentage systemen dat up-to-date is met beveiligingsupdates, relevant voor Microsoft 365 security.

Wat zijn veelgemaakte fouten bij het opstellen van een SLA?

De meest voorkomende fouten bij het opstellen van een SLA zijn: te vage servicebeschrijvingen, ontbrekende uitsluitingen, onrealistische normen, geen duidelijke escalatieprocedure en het vergeten van afspraken over wijzigingsbeheer. Deze fouten leiden bijna altijd tot discussies en teleurstelling aan beide kanten.

Naast de bovenstaande punten zijn er nog een paar valkuilen die regelmatig terugkomen:

• Geen onderscheid in prioriteiten: Als elk incident dezelfde responstijd heeft, werkt de SLA niet als sturingsinstrument.
• Eenzijdig opgesteld: Een SLA die alleen door de dienstverlener is geschreven zonder input van de klant, sluit zelden aan op de werkelijke behoeften.
• Geen afspraken over communicatie: Wie informeert wie bij een storing, en hoe? Dit wordt vaak vergeten maar is cruciaal bij grote incidenten.
• Geen herzieningsmoment: Een SLA die nooit wordt bijgewerkt, veroudert snel en verliest zijn waarde.

Bij het opstellen van een SLA loont het om de overeenkomst samen met de dienstverlener door te lopen en elk onderdeel te toetsen aan een concrete situatie: “Stel dat dit systeem uitvalt, wat gebeurt er dan precies?”

Wanneer moet je een ICT-SLA herzien of bijwerken?

Een ICT-SLA moet je herzien bij grote organisatorische veranderingen, bij wijzigingen in de dienstverlening, na een ernstig incident dat de tekortkomingen van de huidige afspraken heeft blootgelegd, of minimaal eens per jaar als standaard evaluatiemoment. Een verouderde SLA biedt schijnzekerheid.

Concrete aanleidingen om een SLA te herzien zijn onder andere:

• De organisatie groeit sterk of krimpt, waardoor de schaal van de dienstverlening verandert.
• Er worden nieuwe systemen of cloudoplossingen in gebruik genomen, zoals Microsoft 365 of aanvullende applicaties.
• De dienstverlener breidt zijn aanbod uit of past zijn werkwijze aan.
• KPI’s worden structureel niet gehaald, wat aangeeft dat normen of processen moeten worden bijgesteld.
• Wet- en regelgeving verandert, bijvoorbeeld op het gebied van databeveiliging of privacy.

Plan een vaste evaluatie minimaal eens per jaar in, bij voorkeur gekoppeld aan de jaarlijkse contractverlenging. Zo blijft de SLA een levend document dat aansluit bij de werkelijkheid in plaats van een stuk papier dat in een la verdwijnt.

Hoe Puur ICT helpt bij het opstellen van een ICT-SLA

Een goede ICT-SLA opstellen vraagt om kennis van zowel de techniek als de organisatie. Bij Puur ICT combineren we die twee. We denken met je mee over welke diensten je nodig hebt, welke normen realistisch zijn en hoe je de afspraken zo vastlegt dat ze in de praktijk ook werken. Concreet bieden we:

• Een helder overzicht van alle diensten die we leveren, inclusief scope en uitsluitingen
• Transparante respons- en oplostijden per prioriteitsniveau, afgestemd op jouw organisatie
• Regelmatige rapportages zodat je altijd inzicht hebt in de prestaties
• Persoonlijk contact en korte lijnen, ook bij escalaties
• Jaarlijkse evaluatiemomenten om de SLA actueel en relevant te houden

Of het nu gaat om ICT-ondersteuning voor je medewerkers of om uitgebreider netwerkbeheer, Puur ICT legt alles vast in heldere afspraken zonder kleine lettertjes. Wil je weten hoe een SLA met Puur ICT eruitziet? Neem contact met ons op en we bespreken het graag.

Gerelateerde artikelen

• Wat zijn de normen van de NIS2-richtlijn?
• Hoe pak je een verplichte beveiligingsaudit aan als je geen grote IT-afdeling hebt?
• Wat is de zorgplicht onder de NIS2-richtlijn?
• Hoe houd je vergaderingen efficiënt als een deel van het team op locatie zit en een deel thuis?
• Hoe zorg je dat een nieuwe collega snel toegang heeft tot alle informatie die hij of zij nodig heeft?