Service Level Agreement opstellen, hoe werkt het?

Wat is een Service Level Agreement?

Veel mensen leven in de veronderstelling dat een dienstverleningsovereenkomst hetzelfde is als een Service Level Agreement. Dat is echter een misverstand.

In een dienstverleningsovereenkomst staat de beschrijving van welke dienst verleend wordt, onder welke voorwaarden en wat de dienstverlening gaat kosten.

Een Service Level Agreement, ofwel SLA, kan een optionele toevoeging zijn op de dienstverleningsovereenkomst tussen de betrokken partijen. Meestal is het er een bijlage bij.

De juridische status van een SLA is dus eigenlijk helemaal niet die van een opzichzelfstaand contract. In de Service Level Agreement – de naam verraadt het eigenlijk al – staan alleen maar de “service levels” die behaald zouden moeten worden. Het gaat dus om het niveau van de service, gemeten aan prestatie-indicatoren, ook wel key performance indicators (KPI's) genoemd.

Waar worden SLA's gebruikt?

Een belangrijke sector waarin SLA's heel serieus worden genomen, is in de telecommunicatiesector. Waar veel ondernemers ze het meeste tegenkomen, is in de IT-sector, en dan in het bijzonder cloud diensten. Ook voor complexere IT-diensten, zoals IT-outsourcing en managed services worden ze veel gebruikt. Met IT-outsourcing wordt bedoeld het volledig uitbesteden van alle IT aan een externe leverancier.

Managed services houdt in dat een leverancier de IT-activiteiten verzorgt, maar dat de IT-systemen wel van de klant zijn; niet alleen diensten leveren, maar ook het management van die diensten leveren.

Waarvoor worden SLA's gebruikt?

Service levels kunnen betrekking hebben op beschikbaarheid van een dienst, maar kan ook betrekking hebben op de reactiesnelheden in een dienst. Bij telecomdiensten en clouddiensten gaat het vaak vooral om beschikbaarheid, hoewel responstijden daarbij ook relevant kunnen zijn. Bij de complexe diensten als outsourcing en managed services zijn beiden soorten van belang. En ook nog reactiesnelheden bij het helpen van gebruikers en oplossen van problemen. Bij de helpdesk van een softwareleverancier gaat het alleen om responstijden.

Is een Service Level Agreement eenvoudig?

Nee. SLA's zijn bij uitstek ingewikkelde overeenkomsten. En ze moeten heel specifiek toegesneden zijn op de dienst in kwestie: geen 'one size fits all'.

Beschikbaarheid

Bijvoorbeeld bij ICT-diensten is beschikbaarheid vaak alleen met veel moeite meetbaar. Als afnemer wil je graag dat de dienst beschikbaar is op momenten dat je hem nodig hebt. Dus, wat nu als de dienst niet beschikbaar is?

Is het wel de dienst die niet werkt?

Een lastige vraag als de dienst niet werkt, is of het echt de dienst is, die niet werkt, of dat er verbindingsproblemen zijn. En aan wie dat dan ligt? Het kan veel metingen vergen om dit te weten te komen, zoals schematisch in onderstaande is weergegeven:

Moet de dienst wel altijd 100% beschikbaar zijn?

Een andere lastige is, op welk moment is het nu echt een probleem dat de dienst niet werkt en op welk moment niet zozeer? Deze laatste vraag goed beantwoorden, kan enorme kosten voorkomen bij het nutteloos permanent beschikbaar hebben van de dienst. Op verschillende momenten kunnen verschillende niveaus gewenst zijn.

Hoe meet je 'beschikbaarheid'?

Als dat allemaal duidelijk is, dan moet je afspreken hoe je precies het begrip ‘beschikbaarheid’ gaat meten. Hoe dat moet gaan gebeuren blijkt vaak verbazingwekkend lastig te beantwoorden zijn, als je er echt over nadenkt.

Andere relevante vragen.

Als je deze vragen beantwoord hebt, zijn er de volgende belangrijke aspecten:

Wie meet het?
Wat voor bewijsvoering is vereist?
Wie rapporteert aan wie, wanneer en op welke wijze?
Wat zijn de controlemogelijkheden van de ander?
Moeten er audits komen?

Financiële effecten van de SLA?

Pas als dat allemaal duidelijk is, er meetsystemen zijn ingebouwd in de keten die als geheel de dienst verricht en de rapportagesystemen die vereist zijn, ook echt bestaan, dan heeft het zin afspraken te maken over het wellicht niet halen van die service levels. Kortom, een service level agreement voor beschikbaarheid vereist een forse hoeveelheid denkwerk en voorbereiding.

Responstijden

Dezelfde problemen doen zich voor als het gaat om responstijden, waarmee ik hier bedoel de tijd tussen een toetsaanslag en het gewenste resultaat van die aanslag:

Hoe meet je dat?
Moet het altijd even goed zijn, of verschilt dat in de tijd en misschien ook naar locatie?
Voor welke soort actie komt dit er op aan en voor welk soort actie eigenlijk niet?

Ook hier loop je tegen ingewikkelde metingen aan, met daarbij horende rapportages en controles.

Menselijke responstijden

Voor responstijden van mensen, zoals bij helpdesks, is het ook al ingewikkeld. Wat vind je belangrijk: Hoe snel de telefoon opgenomen wordt? Hoe snel het probleem geregistreerd staat? Hoe snel gestart wordt me een zoeken van een oplossing of hoe snel het echt wordt opgelost.

Uiteindelijk wil je als klant eigenlijk alleen maar het laatste, maar dat krijg je nooit van een ICT-leverancier van IT-diensten of van software, omdat ze dat gewoon niet kunnen garanderen. Het hangt op zo’n moment van zo veel factoren af hoe lang het realiseren van een oplossing kost, dat dit niet vooraf te garanderen valt. Je krijgt meestal alleen iets voor de voorgaande vragen, maar de vraag is dan weer of je daarmee als klant wel geholpen bent.

Wat als de SLA niet volledig helder is op wat er behaald moet worden?

Als er geen duidelijke afspraken zijn over de te behalen niveaus, dan zullen die in beginsel altijd gehaald worden. In dat geval is de dienstverlener eigenlijk altijd wel veilig. De klant kan door de onduidelijkheid nergens echt een beroep op doen, ook al lijkt dat bij oppervlakkige lezing anders. In de IT-dienstverlening zie je dan ook vaak dat de service level agreements werken als een garantie-uitsluiting in plaats te bieden wat de naam suggereert. Veel SLA's zijn in werkelijkheid: ‘No warranted service level agreements’.

Wie heeft belang bij de inhoud van een SLA?

Zoals hierboven al blijkt, heeft de dienstverlener belang bij SLA's zolang de afspraken gemaakt daarin niet 100% duidelijk zijn, wat dus erg vaak zo is bij IT diensten in de cloud.

In de Telecom zie je het vaakst dienstenniveau-overeenkomsten de klant wel echt beschermen. Telecomsystemen bevatten vaak allerlei meetpunten en rapportagesystemen daarop. Dat is in het ontwerp van die systemen al direct meegenomen. De service level agreement dient uitgekristalliseerd te zijn om waarde voor de afnemer te hebben.

Hoe omgaan met geplande downtime?

De meeste SLA's bevatten uitsluitingen van geplande downtime. Dus: tijden waarop de dienst niet beschikbaar zal zijn. Dat is een goede zaak, want het voorkomt kosten ten opzichte van 24/7 service.

Het vereist samenwerking om te bepalen hoe onderhoud gepland wordt. Ook dit is een onderwerp waarover heel makkelijk onduidelijke afspraken opgeschreven kunnen worden, meestal met als gevolg dat de klant weinig meer aan de service level agreement heeft.

Wat als de diensten niveaus niet gehaald worden?

Het idee is dat de klant gecompenseerd wordt voor gebreken in de dienstverlening en dat de dienstverlener – als spiegelbeeld daarvan - gestimuleerd wordt de dienst op een goed niveau te blijven verlenen. Een heel gebruikelijke compensatie is, dat korting verleend wordt op een volgende betaling. Vaak zijn die kortingen beperkt. Maar, vaak staat in de SLA wel dat dit de enige actie is die de klant heeft, wat wil zeggen dat schadeverhaal naast die korting uitgesloten is. Door dit soort beperkingen, werken de meeste service level agreements dus eigenlijk als effectieve aansprakelijkheidsbeperkingen voor de leverancier.

Uiteraard kunnen er ook serieuze boetes in een service level agreement staan. Of, beter nog, de beloning wordt gekoppeld aan de mate waarin doelen gehaald worden. Op een of andere manier moeten er dus echte incentives zijn op die doelen.

Wat als de SLA wel volledig helder is en er staan ook serieuze incentives in?

Voor deze vraag, gaan we ervan uit dat we een echt werkende SLA hebben, ondersteund met meetsystemen en rapportagesystemen op de overeengekomen prestatie-eisen. We hebben ook nog financiële afspraken die uitdrukkelijk voelbaar zijn voor de leverancier en afhangen van die KPI’s.

Teveel nadruk op de KPI's

Het gevolg is nu dat de leverancier zich volledig op de overeengekomen prestatie-indicatoren gaat richten. Dat is mooi, als deze diensten verlenen ook echt het enige is wat je verlangt van de dienstverlener. In de praktijk blijkt het echter lastig te zijn om dat echt goed te bepalen. Bovendien kan wat belangrijk is voor de afnemer in de tijd veranderen. Naarmate diensten complexer van aard zijn, wordt dit een lastiger probleem.

Bij outsourcing is dit een klassiek dilemma. Als je alles operationeel afmeet, dan komt er nooit innovatie. Maar wil je innovatie-bevorderende KPI’s, wat werkt dan? En hoe kan je op nu nog onbekende, toekomstige, innovaties anticiperen? Met andere woorden, hoe complexer de dienst is, hoe groter het risico dat KPI's niet sporen met je feitelijke verwachtingen. Eventuele wijzigingen van KPI's voor bestaande diensten, plaatst de dienstverlener in een sterke onderhandelingspositie, wat niet bepaald tot kostenbesparingen zal leiden.

Wat zijn de gevolgen van een gemankeerde SLA?

Een voor de klant waardevolle SLA is in de meeste gevallen heel lastig op te stellen. Onduidelijkheden in de te halen niveaus werken voor de leverancier feitelijk als garantie-uitsluitingen. Als de financiële gevolgen beperkt zijn van het niet halen van die KPI’s en er staat in de SLA dat dit de enige remedies zijn, dan werkt het ook nog als een effectieve aansprakelijkheidsbeperking voor de dienstverlener. Een goede SLA opstellen vereist veel ervaring en inzicht. Zonder dat, kom je niet tot een zinvolle SLA.

Als een goede SLA niet haalbaar is, wat dan?

Dit is vaak de kern waarom het gaat. Het is verstandig om als afnemer alleen een SLA te accepteren als je de invulling ervan 100% begrijpt en er serieuze consequenties zijn als het niet werkt. Vaak is dat niet haalbaar. Ook niet voor bedrijfskritische clouddiensten. Laten we even aannemen dat je als afnemer de SLA weigert, omdat het alleen maar in je nadeel werkt. Wat kan je dan wel doen als de geleverde diensten niet aan je verwachtingen voldoet? Het algemene antwoord hierop is: “snel afscheid kunnen nemen van de dienstverlener.”

Dat betekent dat je contractueel zeker geen langlopende verplichtingen moet aangaan. Maar daarnaast, en vooral ook, dat je de dienst zo inricht en opzet dat je mogelijkheden creëert waardoor je ook feitelijk binnen een redelijke termijn over kunt schakelen op een andere oplossing. Ook de wijze waarop je dit vormgeeft en uit onderhandelt, vereist de nodige ervaring en inzicht, die bij experts ingehuurd moet worden.

Deskundig advies is belangrijk

Heb je na het lezen van die artikel vragen of heb je nu te maken met bovengenoemde zaken laat het weten. Onze IT-advocaten hebben jarenlange ervaring en die brengen die mee. Vraag vandaag nog een gesprek aan