ZBC Kennisbank

Tips voor een begrijpelijk SLA of ICT-contract

 

Contracten zijn per definitie saai en redelijk onbegrijpelijk, maar daaruit vloeit zelden bloed. De meeste leveranciers leveren immers gewoon datgene wat de klant wil hebben. Binnen de ICT-wereld ligt dit anders. Klanten willen veelal iets, wat ze nog niet kennen. Voor de leverancier maakt dat het moeilijk om precies aan de vraag te voldoen. Maar veelal heeft hij in elk geval een uitgebreide trukendoos beschikbaar, om niet aansprakelijk te kunnen worden gesteld. Dat is begrijpelijk. Als echter die trukendoos ook wordt gebruikt als de ICT-leverancier een wanprestatie levert, dan is er toch wel iets fout.

In dit artikel geven we u een aantal tips hoe u een goede overeenkomst kunt sluiten met uw ICT-leverancier. We hanteren daarbij een aantal uitgangspunten die gelden voor 90% van alle contracten die afgesloten worden:

  • U heeft geen uitgebreide inkoopvoorwaarden voor het inkopen van ICT-diensten.
  • U heeft niet de inkoopmacht van een marktleider of de centrale overheid.
  • U heeft er geen behoefte aan om geschillen voor de rechtbank uit te vechten.
  • U wilt krijgen waaraan u behoefte heeft, tegen een faire prijs.
  • ICT is voor u geen core-business.

Hoewel deze uitgangspunten dus gelden voor verreweg de meeste contracten, is het toch zo dat u bij de inkoop van ICT-diensten gemakkelijk het kind van de rekening wordt, als u niet uitkijkt. We willen u met deze tips daarom helpen u juridisch de positie van klant te geven. Dit kan voorkomen dat u uitgebreid moet investeren in juridisch advies en ook dat de leverancier u toch weer tot de probleemeigenaar maakt die u niet wilt zijn. (Zie ook ‘Zeven tips voor het inkopen van ICT-projecten’.)

Koop geen product maar een dienst

U weet ongetwijfeld, dat de grootste kostenpost van uw ICT niet de investeringen zijn, maar dat dat juist het beheer is. Neemt u daarom bij voorkeur geen producten af, maar diensten. Die diensten zijn dan vaak SaaS-oplossingen, waarbij u slechts betaalt voor het gebruik. (Zie ook ‘SaaS is voor de gebruiker meer dan alleen stroom uit het stopcontact ’.) De leverancier blijft dan probleemeigenaar, mits u dit contractueel goed regelt. Meestal is dat niet zo complex. In de meeste gevallen echter, levert een leverancier zijn product (al dan niet inclusief de implementatie) en biedt daarbij het beheer aan als add-on. Hij noemt dat waarschijnlijk een managed service. Maar het komt erop neer dat u de probleemeigenaar wordt. Uiteraard moet u dat vermijden. Koop daarom een dienst die past bij uw behoefte en stel de aanbieder verantwoordelijk voor de beschikbaarheid van deze functionaliteit met inbegrip van uw vanzelfsprekende behoeften. Verrassend is, hoe weinig ICT-aanbieders na het sluiten van een deal de mening van hun klant delen over wat vanzelfsprekend is, laat staan dat hun SLA het weergeeft zoals de klant het had verwacht.

Een overeenkomst is een hiërarchie van contracten

Als u een dienst koopt, zult u zich goed moeten realiseren dat het vooral ook gaat om een dienst en niet alleen om een product. De overeenkomst met uw leverancier moet leiden tot een partnership. U besteedt tenslotte het beheer van een belangrijk bedrijfsmiddel uit aan een derde partij. Dit is overigens niet gek, want uw nutsvoorzieningen, uw infrastructurele voorzieningen en uw wagenpark koopt u immers ook op die manier in. Waarom dus ook niet uw ICT? (Zie ook ‘ICT en functioneel beheer steeds meer logistieke processen’.)
In de overeenkomst moeten dus in ieder geval twee zaken worden vastgelegd: de oplossing die u koopt en de wijze waarop deze oplossing na de implementatie beheerd gaat worden. De oplossing legt u vast middels drie reeds bestaande documenten:

  • uw RfP;
  • de definitieve offerte van de leverancier;
  • de algemene voorwaarden van de leverancier.

Algemene voorwaarden

De algemene voorwaarden zijn onvermijdelijk en vormen een bescherming voor de leverancier. Deze algemene voorwaarden voor ICT-bedrijven zijn vaak afgeleid van het modelcontract van de branchevereniging. Dat is de reden dat u er nooit zonder meer mee akkoord moet gaan. Want plat gezegd staat in die voorwaarden dat de leverancier niet hoeft te leveren wat is afgesproken, dat dit ook niet op tijd hoeft te gebeuren en dat de klant altijd moet betalen, ook al is er sprake van een wanprestatie. Daarnaast staan er ook nog een groot aantal redelijke bepalingen in. Ga geen ingewikkeld juridisch proces in door artikelen te schrappen of te wijzigen in deze voorwaarden. In de RfP en de offerte staat immers de afgesloten deal weergegeven. Zet deze deal in de hiërarchie een niveau hoger. Voor alles wat niet in de RfP of de offerte is beschreven gelden dan de algemene voorwaarden.

Offerte

In de offerte staat beschreven wat de leverancier precies levert. Meestal in termen zoals de leverancier deze hanteert en redelijk onbegrijpelijk voor de klant. Dat is niet erg, zolang er in elk geval maar twee zaken goed geformuleerd zijn:

  • de bevestiging dat met de offerte aan alle eisen en wensen uit de RfP van de klant wordt voldaan; eventueel mogen afgesproken uitzonderingen toegevoegd worden;
  • een fixed-price aanbod; dit aanbod is inclusief het werk, dat eventueel uitbesteed wordt aan onderaannemers; de aanbieder is tenslotte uw single-point-of-contact voor de oplossing.

Natuurlijk is het mogelijk, dat via een wijzigingsprocedure afgeweken wordt van de offerte. Deze wijzigingen dienen dan wel te worden geaccordeerd door u als klant. Uitloop van werkzaamheden bij de leverancier die niet veroorzaakt worden door een aanpassing in de eisen en wensen, kunnen dus niet tot meerwerk leiden. Als de leverancier bewijst een goede partner te zijn en met u op de kosten let door vereenvoudigingsvoorstellen te doen en door zijn onderaannemers goed te managen, wees dan niet te kinderachtig als de leverancier aangeeft toch een overschrijding te hebben. In samenwerking kunt u tenslotte meer kosten besparen dan alleen. Bovendien komt dit de relatie ten goede. Leg wijzigingen echter wel vast.

Request for Proposal (RfP)

De RfP gaat vaak ten onder in het meestal door de leverancier gedomineerde traject van contracteren. Dat is echter geheel ten onrechte. In dit document liggen tenslotte uw behoeften vast in termen van eisen en wensen, meest op doelstellingen niveau. Ook liggen hierin de knock-out criteria vast. U eist van de leverancier dat hij in zijn offerte bevestigt, dat hij voldoet aan de eisen en wensen uit de RfP. de RfP hoort dus in de hiërarchie boven de offerte te staan.

Service level agreement (SLA)

In het service level agreement wordt de dienstverlening beschreven, nadat de implementatie heeft plaatsgevonden. Het SLA is dus het tweede deel van de overeenkomst. Ook het SLA is vaak een ellenlange opsomming van procedures en services die niet de moeite waard zijn om serieus te bekijken. In die zin is het document vergelijkbaar met de algemene voorwaarden. Ook het SLA is er weer op gericht, dat u probleemeigenaar wordt. Maar dat wilt u niet. Dus ook nu weer moet u niet trachten allerlei zaken te wijzigen. Eis echter, dat een hoger niveau in de overeenkomst een A4-tje betreft, waarin belangrijke afspraken zijn vastgelegd. U heeft dat uiteraard al gedaan in de Rf. Deze afspraken moeten nu geëffectueerd worden. In het A4-tje worden de afwijkende afspraken vastgelegd, die meestal betrekking hebben op een aantal aandachtspunten. We zullen deze met u doornemen.

Startdatum onderhoudscontract

Softwareleveranciers als Microsoft eisen, dat het onderhoudscontract ingaat zodra de software is aangeschaft. Daar kan uw leverancier weinig aan veranderen. Hij kan echter tijdens de ontwikkeling wel gebruik maken van eigen licenties. Pas na acceptatie van de oplossing schaft u dan formeel de software zelf aan. U hoeft dan dus niet een aantal maanden voor niets te betalen.

Incidentafhandeling

Er is sprake van een incident, als u constateert dat de dienstverlening niet voldoet aan de afspraken. Uiteraard is dat het geval als er storingen zijn. Maar ook wanneer nieuwe versies van de software worden geïmplementeerd. De kosten van de incidentafhandeling horen gedekt te worden door het onderhoudscontract of door de kosten van de dienst bijvoorbeeld bij outsourcing. Vaak worden er in het contract reactietijden genoemd. Daar heeft u echter niets aan. Het kan dan nog steeds dagen duren voordat de dienstverlening is hersteld. Waar het u om gaat, is de beschikbaarheid van de dienst. Een redelijk percentage hiervoor is 99,8% tijdens werkuren (dit betekent een dagdeel downtime per jaar tijdens werkuren) en een percentage van 99,0 tot 99,5 buiten werktijden (dit is 300-600 uur buiten werktijd). Eventueel kunnen er afwijkende afspraken gemaakt worden, als de aard van het incident wordt meegenomen, met bijvoorbeeld classificatie als:

  • 50% of meer van de gebruikers is aanzienlijk minder productief;
  • 5-50% of van de gebruikers is aanzienlijk minder productief;
  • minder dan 5% van de gebruikers is aanzienlijk minder productief.

Additioneel voordeel van een beschikbaarheidsclausule is, dat u in geval van calamiteiten bij de leverancier zelf geen uitwijk hoeft te regelen. Dat is dan het probleem van de leverancier. Eis is wel dat de leverancier u te allen tijde binnen 24 uur over al uw data moet kunnen laten beschikken. (Zie ook ‘Outsourcing contracten dekken zelden de business continuity van de klant af ’.) Spreek dus wel tevoren een boeteclausule af. Ook hierbij geldt, dat deze zo moet worden ingeregeld, dat u er waarschijnlijk nooit gebruik van hoeft te maken.
Het is niet genoeg als de leverancier aangeeft, dat hij ITIL toepast. Juist de zaken die hierboven zijn beschreven, worden niet door ITIL afgedekt.
Als u verandering in de dienstverlening wenst, dan is er sprake van een wijzigingsvoorstel en dat komt uiteraard wel voor uw rekening. Vraag van te voren wel een wijzigingsvoorstel met een prijsopgave.

Service offerings

Als u een dienst afneemt in de vorm van outsourcing, dan is het vaak zinvol om boven het niveau van het statische SLA nog een niveau van dynamische service offerings te hangen. Voordelen hiervan zijn:

  • Als de leverancier additionele diensten ontwikkelt, kunnen deze marktconform toegevoegd worden aan de dienst. Omgekeerd kan de klant per jaar diensten opzeggen, zodat de kosten van het SLA ook daadwerkelijk verminderen.
  • Prijzen worden aangepast aan wat fair is.

A4 met afspraken

Het hoogste niveau in de overeenkomst wordt gevormd door het eerder genoemde A4-tje. Zorg dat dit altijd kort en bondig blijft. Op dit A4-tje staan in ieder geval vermeld:

  • de eisen en wensen uit de RfP, die betrekking hebben op de service na implementatie;
  • de bovengenoemde aanvullingen op het SLA;
  • de geaccepteerde service offerings;
  • de geaccordeerde wijzigingsvoorstellen

Partnership is meer dan een contract

Het genoemde  A4-tje is het belangrijkste document van de overeenkomst. Het is ook de basis voor partnership tussen klant en leverancier. Er kunnen ook afspraken in worden vastgelegd die juridisch niet kunnen, maar die tussen partners wel gemaakt kunnen worden. Want samenwerken betekent ‘met elkaar geld verdienen’ en niet ‘van elkaar geld verdienen’. Van te voren is nog niet alles te voorspellen. Daarom moet de overeenkomst flexibel zijn en fair naar beide partijen, en zodanig dat wederzijds geprofiteerd kan worden van voortschrijdend inzicht.
Waar het omgaat is het spel dat tijdens het inkoopproces wordt gespeeld. Misschien dat uw bedrijfsjuristen er anders over denken, maar dat is belangrijker dan het contract. In het SLA of het contract wordt het speelveld van de samenwerking beschreven, maar dat vormt maar een klein onderdeel daarvan. (Zie ook ‘Zeven tips voor het inkopen van ICT-projecten’.)

DownloadDownload artikel als MS Word document Download artikel als PDF document Print deze pagina Verstuur deze pagina naar een vriend (email)
Auteur(s): Wiebe Zijlstra | 8 april 2011 | Copyright: ZBC


5 Responses to “Tips voor een begrijpelijk SLA of ICT-contract”

  1. […] Een dergelijke contractopbouw is fair voor u, maar ook voor de leverancier, en voorkomt dat uw project uiteindelijk mogelijk in de rechtszaal eindigt. Geef wel direct in uw RfP aan, dat u deze hiërarchie eist en controleer in de aanbieding van de leverancier, dat hij hiermee akkoord gaat. (Zie ook ‘Tips voor een begrijpelijk SLA of ICT-contract’.) […]

  2. pjw9779 schreef:

    Terechte constatering van Wiebe.

    In de praktijk heerst nogal eens de houding van ‘Zoveel mogelijk waar voor mijn geld’ bij de Opdrachtgever, en ‘Zo min mogelijk leveren voor het geld’ bij de Leverancier.
    Onnodig te zeggen dat dit afbreuk doet aan een oplossingsgerichte klant/leverancier-relatie. Om niet te zeggen dat het de bijl aan de wortel is. Want dan gaat het van kwaad tot erger en ontstaat al snel afweergedrag. Met alle kostbare consequenties van dien.
    Een een oplossingsgerichte klant/leverancier-relatie moet al duidelijk neergelegd zijn in de management-intentieverklaring voorafgaand aan de uitbestedingsonderhandelingen. Een duidelijke businessrisico-inventarisatie dient vertrekpunt te zijn.

    ‘Overmacht’ is in dat kader dan ook een te gejuridificeerde term.
    Het ontslaat de leverancier in hoge mate van zijn verplichtingen, terwijl de klant in de kou staat.
    Anderzijds heeft de klant doorgaans ook niet voor een oplossing van overmachtssituaties betaald.

    Ik zou 4 dingen adviseren:
    1. begin zo vroeg mogelijk met het opstellen van een Business Risk Plan (BRP)
    2. neem óók de oplossing van overmachtsgevallen mee; bedenk dat dit een kostbare aangelegenheid kan worden (iets dat in het BRP o.a. als ‘risk appetite’ is verwerkt).
    3. hanteer een oplossingsgerichte klant/leverancier-relatie; éérst oplossen, dan pas discussiëren
    4. een SLA dekt in beginsel de Day-to-Day dienstverlening. Ook overmachtsgevallen (BCM, uitwijk, backup, excrow, recovery) regelen in het SLA maakt de SLA moelijker te hanteren. Beter afspreken dat er een specifiek afwijkend SLA is dat in specifieke gevallen in werking treedt en dan de reguliere SLA overruled.

    En zoals altijd : KISS!
    De simpelste oplossing is doorgaans de beste en verzin geen oplossing voor niet bestaande gevallen.

  3. Ronald van Zoomeren schreef:

    In het kader van de BCM, wat nu bij DJI (en de overige Overheidsdiensten) erg speelt (Pandemie, stroomuitval) worden diverse SLA’s tegen het licht gehouden. We missen de vermelding/duiding hiervan in de SLA’s (wat kan en mag ik verwachten).

    • wiebe schreef:

      Ronald

      Het ontbreken van dit soort zaken is inderdaad meestal het geval. Natuurlijk geen goede zaak. Erger nog, vaak staat vermeld, dat de leverancier in geval van overmacht niet gehouden is aan de overeenkomst. En overmacht betekent dus pandemie, brand etc. Dan heb je dus echt een probleem. Uitsluitingen via overmacht moeten beperkt worden tot oorlog, terreur en vergelijkbare calamiteiten. In alle andere situaties garandeert de leverancier beschikbaarheid en een maximale downtijd.

  4. PJ Westerhof schreef:

    Ik kan bovenstaande grotendeels onderschrijven.

    Als één van de eerste IT-juristen van Nederland heb ik begin jaren 90 ITIL Service Level Management ontworpen en geïmplementeerd binnen de Nederlandse Politie.
    Mijn kreet daarbij was ‘een SLA is een werkdocument en moet dus in je binnenzak passen en moet dus op een A4tje passen’. Oók bij de directeur.

    Contracten kunnen overigens heel goed leesbaar zijn.
    In de dienstverlening moet je contracten echter niet nodig hebben. Als je de contracten weer gaat lezen is er blijkbaar al iets fout gegaan. Dat wordt er niet beter van als je terugvalt op contracten.
    Leveranciers die dat doen raken doorgaans hun klant kwijt.

    De beste aanpak is volgens ‘een ijzeren vuist in een fluwelen handschoen’. Maak keiharde afspraken, maar ga daar soepel mee om. Een helpdesk die om één minuut voor vijf geen calls mee aanneemt doet het niet goed. Een klant die er een gewoonte van maakt om één minuut voor vijf te bellen ook niet. Eérst het probleem oplossen, dan pas kijken of er kosten verrekend moeten worden.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *