Het draaiende houden van de ICT is voor organisaties van levensbelang. Daartoe worden Service Level Agreements (SLA’s) afgesloten. In de praktijk kom ik echter regelmatig tegen dat de aandachtspunten en valkuilen bij dergelijke SLA’s niet altijd worden gezien. In deze blog geef ik daarom acht SLA-tips mee voor afnemers van ICT (en een bonustip).
- Zorg ervoor dat de SLA gericht is op uw behoeften.
Afnemers storten zich vaak op het analyseren van de details van een SLA zonder zichzelf eerst de vraag te stellen in welke behoeftes de samenwerking en daarmee de SLA moet voorzien.
Die behoeften kunnen per ondernemer sterk uiteenlopen. Enkele voorbeelden hiervan zijn:
- bedrijfscontinuïteit / een hoge beschikbaarheid van de ICT-voorziening;
- voortdurende koppeling van/uitwisseling met andere ICT-voorzieningen;
- hoge klanttevredenheid of hoge medewerkerstevredenheid;
- tijdig voldoen aan gewijzigde wet- en regelgeving;
- het voortdurend bijwerken van de ICT tot het “state-of-the-art” niveau.
De SLA richt zicht echter op concrete diensten. Denk hierbij aan:
- helpdesk;
- herstel gebreken;
- toevoegen nieuwe functionaliteiten;
- realiseren van bepaalde mate van beschikbaarheid;
- coördinatie met derde partijen.
Het is dus zaak kritisch te toetsen of het type dienstverlening dat geboden wordt onder de SLA de behoeften volledig afdekt.
Wat wij in de praktijk wel zien, is dat een SLA bijvoorbeeld beperkt is tot de helpdesk (vragen kunnen stellen), terwijl de organisatie behoefte heeft aan gegarandeerde oplossingen bij problemen. In dat geval zal gebrekenherstel als dienst moeten worden toegevoegd.
Ook zien we regelmatig dat de SLA hooguit vermeldt dat er updates worden uitgerold en daarbij in het midden laat wat die updates dan bieden. Dit terwijl de organisatie behoefte heeft aan het tijdig volgen van wijzigingen in wet- en regelgeving of het volgen van wijzigingen in standaarden die door derde partijen worden voorgeschreven.
- Kies de service levels die passen bij deze behoefte.
Veel leveranciers bieden SLA’s in verschillende varianten en tegen verschillende prijzen aan, waarbij zowel de geboden diensten als het niveau (level) waarop die diensten worden geboden verschilt. Het is zaak kritisch te toetsen of die levels aansluiten bij de behoefte.
Wanneer de levels te laag liggen, dan wordt de dienstverlening niet op het gewenst niveau aangeboden. Dat betekent bijvoorbeeld dat vragen niet snel genoeg worden beantwoord of dat de gegarandeerde beschikbaarheid te laag ligt.
Levels die te hoog liggen zijn echter evengoed niet wenselijk. U betaalt dan immers vermoedelijk meer dan noodzakelijk. Zo heeft u bijvoorbeeld niet zo veel aan een 24/7 helpdesk voor een applicatie die alleen tijdens kantooruren wordt gebruikt. Evenmin is het heel zinvol om te betalen voor een hele hoge beschikbaarheid van een applicatie indien de applicatie niet kritiek is en kortdurende uitval nog wel aanvaardbaar is.
- Let op de juiste meetperiode voor de service levels
Let ook op de meetperiode die wordt gehanteerd voor de service levels. Het maakt een wereld van verschil of een systeem 99% per week of per jaar beschikbaar moet zijn.
Bij het meten per week mag het systeem namelijk ruim anderhalf uur aaneengesloten niet beschikbaar zijn, bij het meten per jaar bijna 4 dagen. Op de Engelstalige wikipedia is een mooie tabel te vinden wat het effect is van een bepaalde meetfrequentie bij een bepaald beschikbaarheidspercentage. Zoals u daar kunt zien doen de verschillen er echt toe.
Denk in dit kader ook aan het hanteren van kantoortijden of juist klokuren bij de vraag of een incident conform overeengekomen level is afgehandeld. Bij het meten conform kantooruren staat de spreekwoordelijke teller buiten kantooruren stil. Dat is ook de reden waarom – anders dan veel mensen denken – het level van een oplossing binnen acht kantooruren niet betekent dat incidenten dezelfde werkdag zullen zijn opgelost. Sterker nog, een dergelijk level betekent in de praktijk vaak dat het wel twee werkdagen kan duren voor iets opgelost is (o.a. vanwege uitzonderingen, zie hierna).
- Let op de uitzonderingen
Het is verder van belang kritisch te toetsen of er onwenselijke uitzonderingen op de service levels van toepassing zijn.
Zo is het in bepaalde branches populair om te bepalen dat de geboden levels slechts in 80% of 90% van de situaties zullen worden gehaald. De paradox daarvan is dat u zult zien dat alle ‘moeilijke gevallen’ onder die resterende 10% of 20% vallen, terwijl u nu juist een SLA afsloot om van dergelijke ellende verlost te zijn.
Het is dus zaak dergelijke uitzonderingen te voorkomen of tot een minimum te beperken. En als er dan toch uitzonderingen worden geaccepteerd, zorg er dan ook voor dat helder is welk level er dan voor die uitzonderingssituaties geldt (anders mist u iedere zekerheid). Neem dus geen genoegen met open eindes.
Eén specifieke uitzondering verdient hierbij bijzondere aandacht. Dit is de uitzondering dat de tijd die de leverancier wacht op de klant voor meer informatie niet meetelt bij de meting van de reactie- en oplostijden (en soms ook andere levels). De teller staat in de tussentijd dus stil. In de kern is die uitzondering namelijk logisch en billijk: van een leverancier kan niet worden verlangd om een incident snel op te lossen als de daarvoor noodzakelijke informatie ontbreekt. De valkuil hierbij is echter dat de leverancier te gemakkelijk om nadere informatie mag vragen.
Zorg er daarom ten eerst voor dat scherp is afgebakend wat het stilzetten van de teller rechtvaardigt. Eventueel zou u, bijvoorbeeld op basis van de periodieke rapportages (zie volgende punt), regelmatig kunnen evalueren of het verzoek om meer informatie, en daarmee het stilzetten van de teller, achteraf gezien rechtvaardig was (en zo nodig met terugwerkende kracht de sancties kunnen corrigeren, zie punt 6).
- Zorg voor goede rapportages
Een goede SLA bevat heldere afspraken over periodieke rapportage door de leverancier over het al dan niet behalen van de service levels en de wijze waarop met incidenten is omgesprongen.
Goede rapportage is om meerdere redenen van belang:
- het is vaak de enige mogelijkheid om te kunnen toetsen of de SLA daadwerkelijk wordt nageleefd;
- het dwingt de leverancier om op gestructureerde wijze te werken;
- externe belanghebbende (zoals toezichthouders, aandeelhouders) kan worden getoond dat alles onder controle is.
Het is daarbij ook van belang dat het recht bestaat de rapportage door een externe derde op juistheid te laten controleren. Dit als stok achter de deur om te voorkomen dat de rapportages niet op waarheid zijn berust.
- Zorg voor goede prikkels tot naleving
Ook is het van belang dat er duidelijke sancties staan op het niet naleven van de SLA. Anders bestaat er voor de leverancier immers maar weinig prikkel tot nakoming.
Let er bij het bepalen van deze sancties altijd op dat u naast deze boete ook het recht behoudt om de overigens geleden schade te verhalen, anders geldt de malus vermoedelijk op grond van de wet als een contractuele boete en daarmee als een gefixeerde schadevergoeding.
De enige andere (nog enigszins) reële prikkel voor de leverancier vanuit juridisch perspectief is dat de afnemer eventueel de SLA kan ontbinden (en dan in theorie ook schade kan claimen). Een afnemer zal echter pas ontbinden als de situatie echt niet meer houdbaar is, niet als het net niet helemaal lekker loopt. Als afnemer sloot je echter nu juist een SLA af om te voorkomen dat het net niet lekker zou lopen.
Of wat informeler gezegd: juist omdat ontbinding een ‘paardenmiddel’ is, waarvan beide partijen weten dat het niet snel zal worden ingezet, is het zaak te zoeken naar een alternatief gebalanceerd incentive-systeem om elkaar scherp te houden.
In de praktijk zien wij dat leveranciers naast sancties ook voorstellen te werken met bonussen, een bonus/malus systeem dus. Dit raden wij om twee redenen af:
- Soms wordt de bonus gezet op normaal presteren, wat in feite bijbetalen betekent voor de normale service.
- Een bonus op exceptioneel presteren klinkt mooi. Maar als die betere prestaties meerwaarde voor de afnemer hebben; waarom neem u dat dan niet als niveau voor de standaard SLA?
- Borg de samenhang met de andere SLA’s.
Het geheel van ICT-systemen, ook wel het ‘applicatielandschap’ genoemd, dat bij organisaties in gebruik is wordt vaak in de loop der jaren steeds complexer.
Het applicatielandschap bestaat vaak uit onderdelen die van verschillende leveranciers afkomstig zijn. En die verschillende leveranciers hanteren, voor het beheer van hun onderdeel van het applicatielandschap, allemaal hun eigen SLA’s.
De verschillende onderdelen van het applicatielandschap zijn echter veelal wel aan elkaar gekoppeld. Er bestaat daarmee vaak interactie tussen en wederzijdse afhankelijkheid van die onderdelen van het landschap. Denk hierbij aan een salarisadministratie die wordt gekoppeld met de boekhouding of een printerpark dat via printmanagementsoftware aan diverse besturingssystemen is gekoppeld.
In menig SLA staat vaak dat deze niet van toepassing is op incidenten die zijn veroorzaakt door niet door de leverancier verrichte aanpassingen in dat applicatielandschap. Op zichzelf is die uitsluiting logisch, een leverancier voelt er begrijpelijkerwijs weinig voor incidenten op te lossen die niet door hem veroorzaakt zijn.
Het effect van die – op zich dus logische uitsluiting – kan echter zijn dat bij een incident dat veroorzaakt is door een aanpassing in het applicatielandschap de verschillende leveranciers naar elkaar wijzen voor de oplossing.
Voorbeeld. Stel dat het applicatielandschap bestaat uit de systemen X en Y die aan elkaar gekoppeld zijn. Leverancier A voert een wijziging door op systeem X op grond van de met hem afgesloten SLA. Hierdoor functioneert het daaraan gekoppelde systeem Y van leverancier B opeens niet meer goed, nu dankzij de wijziging de koppeling van X gegevens in een iets ander formaat aan systeem Y aanlevert (waar systeem Y niet op is ingericht). Indien afstemming tussen A en B geen onderdeel was van de SLA’s met A en B, dan hebben in een dergelijke situatie A noch B vermoedelijk fouten gemaakt. Het herstel van deze situatie is dan meerwerk, dat door de klant moet worden betaald.
Het is dus zaak om het applicatielandschap in zijn geheel te bezien en te toetsen of SLA’s goed op elkaar aansluiten (niet kunnen leiden tot vingerwijzen).
Voeg bij twijfel als extra service in de SLA’s van één van de leverancier toe dat deze samenhang moet bewaken en zo nodig de werkzaamheden tussen de verschillende betrokken leveranciers moet coördineren. Spreek in dat geval ook met de andere leveranciers af dat deze naar deze coördinerend leverancier zullen luisteren, of geef die coördinerend leverancier een volmacht.
- Juridisch-technische tips
Ten slotte in staccato nog een paar juridisch-technische tips:
- Definities. Veel SLA’s werken met een definitie- of begrippenlijst. Onderschat het belang van die lijst niet. Vaak staan in begrippen allerlei scherpe afbakeningen. Zo wordt vaak in de begrippenlijst afgebakend wat eigenlijk een ‘Gebrek’ of ‘Incident’ is en daarmee ook wat er wel/niet onder de SLA valt.
- Resultaatsverbintenissen. Service levels moeten resultaatsverbintenissen zijn, geen inspanningsverbintenissen. Je wilt immers de garantie dat de dienstverlening op het overeengekomen level is, niet (slechts) dat de leverancier zijn best doet (zich inspant) om dat level te halen.
- Aansprakelijkheidsregime. Beding een aansprakelijkheidsregime dat past bij de geboden diensten. Zo is het opmerkelijk dat een SLA veelal wordt gesloten vanwege bedrijfscontinuïteit, terwijl veel leveranciers geen aansprakelijkheid aanvaarden voor de gevolgen van bedrijfsuitval. Een vergelijkbaar voorbeeld zijn SLA’s die gaan over de verwerking van data door de leverancier in combinatie met voorwaarden die aansprakelijkheid voor dataverlies uitsluiten.
Bonustip: zijn de levenscycli van het ICT-systeem afgedekt?
Ten slotte een extra (bonus) tip. Ik vermeld deze afzonderlijk omdat deze soms wel en soms niet in een SLA wordt verwerkt.
Voor veel ICT-voorzieningen geldt dat deze op een gegeven moment worden vervangen door iets anders. Het is zaak op voorhand alvast enkele afspraken met de leverancier te maken over die afbouw-/exitfase. Vaak is voor de overstap naar een alternatief namelijk de medewerking van de leverancier nodig, terwijl bij gebreke van afspraken daarover de leverancier hiertoe niet te dwingen is.
Het is dus zaak die afspraken nog tijdens de looptijd van de overeenkomst ergens vast te leggen. Dat kan gebeuren in de SLA, maar kan evengoed in een ander document (zoals een exitplan). Denk hierbij aan afspraken over bijvoorbeeld dataconversie, het aanleveren van informatie en documentatie (bijvoorbeeld over gemaakte instellingen) en het ondersteunen van de opvolgend leverancier bij diens werkzaamheden.
Vragen over SLA’s? Geschil over SLA’s?
Heeft u een concept SLA die u graag vooraf wilt laten toetsen? Of heeft u vragen of een geschil over een reeds afgesloten SLA? Neem gerust contact op, ik kan u hiermee verder helpen.
Gerelateerd
IT
