Service Level Agreement (SLA): 4 tips voor betere SLA’s

Meeste SLA's louter reactief

Wellicht komt dit bekend voor: in veel SLA’s bij SaaS-diensten die ik ter beoordeling onder ogen krijg wordt de nadruk gelegd op ‘reactieve’ service levels zoals beschikbaarheid (99,9% per maand/jaar) en responstijden (geen oplostijden, stel je voor) bij de melding van incidenten, vaak gekoppeld aan een service level dat inhoudt dat men zich inspant om 90% van de desbetreffende gemelde geprioriteerde incidenten binnen de desbetreffende responstijd op te lossen. Er worden formules gehanteerd hoe beschikbaarheid gemeten moet worden en er worden lange (vaak vage) lijsten gepresenteerd wat allemaal niet als niet-beschikbaarheid mag meetellen in de berekening van het beschikbaarheidspercentage.

Kortom: er wordt vooral achteruit gekeken naar geleverde prestaties en niet preventief geacteerd en er wordt vooral gefocust op wat je niet mag verwachten in plaats van wat je wel mag verwachten.

Waar dient een SLA toe?

Dit roept de vraag op waar een SLA eigenlijk toe dient. Een SLA wordt vaak gepresenteerd als een soort kwaliteitsgarantie, dat het met de dienstverlening allemaal wel goed zit, er geldt immers een SLA. Maar in de praktijk wordt – zeker van uit het perspectief van de afnemer – een SLA gezien als een woud van ondoordringbare obstakels om een leverancier op de kwaliteit van zijn dienstverlening aan te spreken. Of juridisch: een samenstel van afspraken om de zorgplicht uit de inspanningsverbintenis van de opdrachtnemer in te perken.

Is dit onredelijk? Nee, niet per se. Leveranciers hebben doorgaans ook maar beperkte of zelfs geen controle over de keten aan onderdelen die maken dat zijn dienst functioneert. In SLA’s schiet het inperken van de hieruit voortvloeiende risico’s echter vaak door, met als gevolg dat de leverancier ook op de onderdelen waar hij wel controle over heeft niet kan worden aangesproken en dat is niet redelijk. Zeker in een wereld waarin we steeds afhankelijker worden van op afstand ter beschikking gestelde software voor onze dagelijkse werkzaamheden en er dus steeds meer nadruk komt te liggen op goed werkende IT-systemen. En hoe past dit in Business Continuity Plans en Informatiebeveiligingsbeleidsstukken van organisaties?

De essentie van een SLA: continuïteit borgen

Wat mij opvalt is dat SLA’s vaak om de essentie heen draaien. Partijen hebben toch geen behoefte aan het monitoren van beschikbaarheidspercentages en reactietijden? Zeker, een afnemer heeft behoefte aan continuïteit van dienstverlening en moet zicht hebben op de maatregelen die dat moeten borgen. En juist dat krijgt nagenoeg geen aandacht. Het monitoren van beschikbaarheidspercentages is reactief handelen, terwijl in mijn ogen de focus moet liggen op het treffen van proactieve maatregelen om discontinuïteit te voorkomen en daar dan concrete afspraken over te maken (bijvoorbeeld: hoe lang duurt het om een uitwijkomgeving te upspinnen?). Daar zijn vaak kosten aan verbonden, inderdaad. Maar bij bedrijfskritische systemen zijn afnemers best bereid daar een faire prijs voor te betalen. Dus waarom gaat het gesprek daar dan niet over? Als ik dit tijdens contractonderhandelingen aan de orde stel, word ik vaak door leveranciers met grote ogen aangekeken. Alsof ik de eerste ben die hier een vraag over stelt. “Maar wel hebben toch een SLA” is dan vaak het antwoord.

4 tips bij centraal stellen continuïteit

Ik zou willen pleiten voor een hele andere benadering: waarom stellen we de continuïteit van de dienstverlening niet centraal, waarbij nadrukkelijk wordt benoemd wie waarvoor verantwoordelijk is?

1. Voer een risico-inventarisatie uit en breng de risico’s van (onder meer) discontinuïteit in kaart. Daaruit zouden concrete, praktische tegenmaatregelen getroffen kunnen worden tegen de gesignaleerde risico’s. Die tegenmaatregelen zou je vervolgens in de SLA moeten uitwerken.
2. Maak helder bij wie welke verantwoordelijkheid rust. Maak concreet waar de afnemer verantwoordelijk voor is (eigen netwerk, eigen internetverbinding e.d.), waar de leverancier verantwoordelijk voor is (zijn netwerkvoorzieningen, technische inrichting van de software, door hem ingeschakelde hosting partijen) en maak duidelijk waar geen van partijen invloed op heeft (daardoor worden bepaalde overmachtssituaties geobjectiveerd).
3. Houd brandoefeningen! Mooi hoor al die afspraken over het voorkomen van ellende, maar dan gaat het een keer mis en dan blijkt een switch van 35 euro opeens niet te doen wat hij wel moet doen. In de fysieke wereld is het heel normaal om af en toe een brandoefening te doen. Waarom dan niet ook voor onze digitale wereld? Zo komen onvoorzienbare kwetsbaarheden bloot te liggen en die kun je dan weer oplossen. Scherp de afspraken in de SLA daarop aan.
4. Overigens kunnen partijen dan nog steeds afspraken maken over bepaalde bandbreedtes rondom de kwaliteit van dienstverlening die achteraf gemonitord wordt. Dat kan nooit kwaad, zeker niet als je daarmee bepaalde trends bij gaat houden. Maar dan meer als een ondergrens voor evaluatiedoeleinden en eventuele verbetertrajecten.

* Een eerdere versie van deze bijdrage is gepubliceerd in SGOA Signaal.