De SLA: een ondergeschoven kindje

De Service Level Agreement (SLA) krijgt in de praktijk vaak opvallend weinig aandacht. Dit is opmerkelijk gelet op de toename van dienstverlening op afstand waarbij wezenlijke data of bedrijfskritische software op afstand wordt afgenomen (via bijvoorbeeld Cloud, SaaS constructies). Wat is de SLA eigenlijk voor document: is het een juridisch document of juist niet? Wat moet een SLA in ieder geval aan voldoen? Wat moet daar in staan? Enkele opmerkingen voor de praktijk.

SLA = overeenkomst = juridische document

Laat ik beginnen om een misverstand uit de wereld te helpen: De naam zegt het eigenlijk al (“service level agreement”), maar de SLA is in de kern een overeenkomst en dus een juridisch document. Zo zou een SLA wat mij betreft ook moeten worden behandeld. In de SLA worden afspraken vastgelegd over het kwaliteitsniveau (service level) dat aan bepaalde diensten wordt gekoppeld. Afspraken maak je omdat je wilt dat die worden nagekomen. Denk bijvoorbeeld aan responstijden waarbinnen een vraag moet worden beantwoord door de helpdesk, een oplostijd waarbinnen een probleem moet zijn opgelost of de mate van beschikbaarheid dat je toegang moet hebben tot je data of de software. Dat daarnaast ook een nadere invulling wordt gegeven aan de procedurele regelingen (zoals welk telefoonnummer moet ik bellen, welke prioriteitsniveau’s onderscheiden partijen en wie bepaalt welk prioriteitniveau in een concreet geval van toepassing is?), maakt dit niet anders. Dit zijn ook afspraken die moeten worden nagekomen.

Belang van een goede, passende SLA

Omdat een SLA een nadere invulling geeft aan de (kwaliteit van de) te leveren diensten, moeten de service levels daar goed op aansluiten. In de praktijk gaat het daar nog wel eens fout. Afnemers hebben de neiging om te dicteren hoe de leverancier precies moet handelen, wat op weerstand stuit omdat de leverancier niet zomaar zijn service organisatie kan aanpassen aan elke klant. Aan de andere kant bevatten veel SLA’s van leveranciers slechts beperkte service levels, waarbij je je kunt afvragen wat je precies aan die SLA hebt. Denk aan responstijden bij gebreken die vaak niets anders inhouden dan een verplichting om binnen een bepaalde tijd te bevestigen dat de melding is ontvangen zonder dat er enig zicht is op de oplossing van een gebrek. Het gevaar bestaat hierdoor dat partijen een verkeerd verwachtingspatroon krijgen over het nut van de SLA en er geschillen ontstaan die eventueel zelfs leiden tot het einde van de relatie. Het is dus in het belang van beide partijen om een goede, passende SLA te sluiten.

Risicoanalyse

Een goede SLA adresseert de risico’s die horen bij de specifieke dienstverlening. Er bestaat dus niet een model van een SLA, je zult per type dienst moeten kijken naar de specifieke diensten. Zonder een goede risicoanalyse kun je dus geen goede SLA opstellen of beoordelen. Stel bijvoorbeeld dat een afnemer besluit om zijn kantoorautomatisering via SaaS af te gaan nemen. Een van de meest cruciale risico’s is dan beschikbaarheid van die dienstverlening. Ik de praktijk zien wij vaak genoeg dat partijen dan alleen een beschikbaarheidsgarantie overeenkomen van bijvoorbeeld 99.8% per maand en daar genoegen mee nemen. Is daarmee het risico goed geadresseerd? Voorkomt een dergelijke afspraak dat de software niet-beschikbaar is? Nee. Natuurlijk moet de leverancier ervoor zorgen dat zijn dienstverlening zorgvuldig wordt uitgevoerd. Daar is hij niet alleen contractueel maar ook wettelijk toe verplicht (artikel 7:401 BW). Vergeet ook niet heel praktisch te redeneren: moet er bijvoorbeeld een uitwijkmogelijkheid zijn die inspringt op het moment dat de hoofdlocatie van de afnemer niet beschikbaar is. Zo ja, hoort dit dan onder de hoofdverplichting van de leverancier of is dit een aanvullende dienst waar apart voor moet worden betaald? Hier kun je verschillend over denken. Het is dan ook van belang hier vooraf goede afspraken over te maken zodat zowel de afnemer als de leverancier weten waar zij aan toe zijn. Helaas gebeurt dat vaak niet.

Wel of geen sancties: boete of bonus/malus?

Een terugkerend discussiepunt is het al dan niet toevoegen van sancties (service credits), zoals een contractuele boete, of korting op de onderhoudsvergoeding of dienstverleningsvergoeding. In de meeste SLA’s van leveranciers worden geen boetes vermeld op niet-nakoming van de service levels. Er is dan eigenlijk geen nakomingsprikkel (incentive) aanwezig. Strikt genomen zou de afnemer kunnen betogen dat er sprake is van een tekortkoming en zou hij de SLA kunnen ontbinden, maar zeker is dat niet. Bovendien is het ontbinden van de SLA een enorm paardenmiddel, waar partijen niet snel naar zullen grijpen. SLA’s van leveranciers bevatten doorgaans geen of slechts zeer beperkte boetes, die niet bepaald afschrikken. Een alternatief voor een boete of kortingsregeling is een bonus/malus regeling. De leverancier heeft dan recht op een bonus als hij de overeengekomen norm overtreft en moet een boete betalen als hij daar onder blijft. Bij bonussen moet de afnemer zich echter wel afvragen of dat meerdere dan toegevoegde waarde heeft voor hem. Zo nee, waarom zou je daar dan extra voor moeten betalen? Waar partijen ook aan zouden kunnen denken is om eventueel verbeurde boetes op te potten en de leverancier de kans te geven om die verbeurde boetes in de loop van het jaar weer terug te verdienen, door beter te presteren dan was overeengekomen. Het gaat de afnemer er immers niet om dat hij boetes of kortingen incasseert, hij wil dat de dienstverlening optimaal wordt verleend en dat hij normaal kan werken.

Wat regel je in een goede SLA?

Zoals gezegd adresseert een goede SLA de risico’s van partijen. Daarnaast zal (onder meer) aandacht moeten worden besteed aan de volgende onderwerpen:

• De verplichtingen van de partijen waarop de SLA ziet. - De meetbare en controleerbare service levels (prestatienormen) gekoppeld aan die verplichtingen. 


• Vergeet bij beschikbaarheidsgaranties niet te bepalen over welke periode het systeem of de dienst beschikbaar moet zijn (24*7, tijdens kantoortijden, of iets daar tussenin) en hoe de beschikbaarheid moet worden gemeten (per jaar, per maand of per dag). Daarbij geldt: hoe korter die meetperiode hoe minder lang er sprake mag zijn van niet-beschikbaarheid. 


• Als bij gebreken en storingen een prioritering wordt aangebracht, let er dan op dat de definities van die prioriteiten dan helder en duidelijk afgebakend zijn. Leg ook vast wie de prioriteit van een gebrek bepaalt. 


• Let op het onderscheid tussen respons- en oplostijden (zie ook mijn eerdere bericht over oplostijden).


• Meldingsprocedure (telefoonnummer of e-mailadres). Deze moet niet te omslachtig zijn. Maak er geen bureaucratisch feestje van. 


• Rapportage regeling: wie houdt de nakoming van de service levels bij en wat moet dan worden bijgehouden? De inhoud van de rapportage regeling moet ook controleerbaar zijn, daar zou dus een audit regeling aan kunnen worden gekoppeld. 


• Adequate sanctieregeling. 


• Looptijd, beëindigingsregeling en gevolgen van beëindiging (exit-regeling). 


• Calamiteitenregeling: wat gebeurt er als de dienstverlening wegvalt of (nog veel erger) als de leverancier zijn verplichtingen niet meer kan nakomen (bijvoorbeeld in geval van faillissement)? Kun je nog bij je data, wordt de dienstverlening dan overgenomen door een derde? Kun je de dienstverlening dan snel weer in huis nemen? Het kan in dit soort gevallen verstandig zijn om vooraf afspraken te maken over (data)escrow of een adequate uitwijkregeling. 


• Evaluatie en periodiek overleg: gedurende de looptijd van een SLA kunnen de wensen van partijen bijstelling behoeven. Evalueer de service levels (zijn ze te hoog, zijn ze te laag, kun je genoegen nemen met minder) periodiek en maak eventueel nadere afspraken. Hoe moet met wijzigingsverzoeken worden omgegaan met betrekking tot de dienstverlening? Leidt dit bijvoorbeeld tot meer- of minderwerk?