Hoe maak je goede ICT-contracten?

Al jaren schommelt het percentage mislukte ICT-projecten rond de 50%. Goed opgestelde contracten kunnen het verschil maken tussen een succesvol en een mislukt ICT-project. Met name voor leveranciers van maatwerk ICT zijn er nog al wat valkuilen. Die valkuilen zijn afhankelijk van de pet die de ICT leverancier op heeft: de pet van leverancier van het ICT systeem of de pet van adviseur over het aan te schaffen systeem.

8 Valkuilen

Een goed ICT-contract is voor 80 procent vergelijkbaar met een ‘gewoon’ contract voor koop/verkoop van zaken of diensten. En daarin zit nu juist het gevaar. Daardoor volstaat men soms met het invullen van een modelletje van internet of knipt en plakt men wat uit andere contracten. Maar die laatste 20 procent maakt nu juist het verschil tussen een goed en een slecht contract. Hieronder bespreek ik acht veel voorkomende valkuilen. Daarbij zet ik als het ware eerst de ‘leverpet’ op, en daarna de ‘adviespet’.

De leverpet

1           Gebrekkige informatie klant

Een bron van veel discussies ontstaat doordat de klant vaak niet of niet goed in staat is om de behoefte van de organisatie aan de leverancier kenbaar te maken. Dat kan komen doordat de klant zelf geen goed beeld heeft van de behoefte binnen de eigen organisatie. Bijvoorbeeld doordat de mensen van de klant die met de leverancier praten vaak niet de eindgebruikers van het ICT-systeem zijn.

Een goede omschrijving van de eigen behoefte door de klant is daarom nodig. Zodat na het sluiten van de overeenkomst geen of weinig aanpassingen nodig zijn of extra functionaliteiten geleverd moeten worden. Met alle kosten en ergernis van dien voor de klant. Hoewel dit voor de leverancier aantrekkelijk lijkt, resulteert dit in veel gevallen in een ontevreden klant.

Door de leverancier voorafgaand aan het sluiten van het ICT-contract onderzoek te laten doen naar de behoefte van de klant en de klant daarover te laten adviseren, kan dit probleem grotendeels ondervangen worden. Het lastige is echter dat klanten in veel gevallen niet bereid zijn om extra te investeren in advies. Voor zover leveranciers in staat zijn om de klant te overtuigen die kosten wel te maken of de leverancier bereid is die kosten voor eigen rekening te nemen, levert dat een aantal andere risico’s op die te maken hebben met de ‘adviespet’. Daarover later meer.

2. Discussies over leveringsomvang

Veel conflicten ontstaan uit discussies over meerwerk. Vaak blijkt onvoldoende duidelijk welke functionaliteit het te leveren systeem precies heeft voor de afgesproken prijs.

Een andere oorzaak is dat de afdeling sales soms te enthousiast is in haar gesprekken met de klant door beloftes te doen die door de technische mensen van de leverancier niet of maar beperkt waargemaakt kunnen worden. Het is nu eenmaal lastiger om ‘nee’ dan om ‘ja’ te verkopen. Hierdoor ontstaat een gat tussen de verwachtingen van de klant en de verwachtingen van de leverancier.

Door in het contract duidelijk te beschrijven wat er wel, maar ook wat er niet of alleen tegen meerprijs geleverd wordt, kan een ‘mismatch’ tussen de verwachtingen tijdig gesignaleerd worden. Hierdoor wordt de kans op een conflict tussen partijen - en dus op het mislukken van het ICT-project - een stuk kleiner.

Het sluitstuk van het vastleggen van de leveringsomvang is, voor wat betreft de dienstverlening van de leverancier, de service level agreement. Een SLA is normaal gesproken een bijlage bij de hoofdovereenkomst en sluit naadloos aan op de definities van de hoofdovereenkomst. Het bevat ‘slechts’ een feitelijke beschrijving van de overeengekomen dienstverlening, de manier waarop het niveau van de dienstverlening gemeten wordt en de consequenties van het (niet) halen van een bepaald niveau dienstverlening. Veel voorkomende valkuilen zijn het opnemen van juridische elementen in de SLA en het hanteren van begrippen die afwijken van de hoofdovereenkomst, met als gevolg dat er discussie kan ontstaan over de uitleg van de SLA. Ook het ontbreken van een objectieve en eenduidige meetmethode en/of (financiële) gevolgen bij het niet halen van de overeengekomen service niveaus kunnen een bron van discussie zijn.

3. Koppeling met andere systemen

Klanten beschikken in veel gevallen over meerdere ICT-systemen die met elkaar dienen samen te werken. Om het te leveren systeem te laten samenwerken met al die aanwezige systemen, zal in veel gevallen de medewerking nodig zijn van de leveranciers van die andere systemen. Daarom is het belangrijk dat in het ICT-contract duidelijke afspraken gemaakt worden over welke koppelingen de leverancier wel en niet voor zijn rekening en verantwoording neemt. En wie de kosten betaalt voor werk dat door andere leveranciers uitgevoerd moet worden om de koppelingen te kunnen realiseren.

Het is daarom raadzaam dat de leverancier vooraf onderzoekt in hoeverre problemen te verwachten zijn bij het realiseren van de koppelingen met andere systemen. Zo wordt zo veel mogelijk voorkomen dat na het ondertekenen van het ICT-contract problemen bij het koppelen of integreren naar voren komen en vervolgens discussie ontstaat over welke partij verantwoordelijk is voor het oplossen van het probleem.

4. Communicatie en geschillen

Mocht tijdens de implementatie van het ICT-systeem toch een meningsverschil ontstaan, dan is het van groot belang dat dit meningsverschil zo snel mogelijk wordt opgelost. Gebeurt dat niet, dan bestaat het gevaar dat er vertraging optreedt bij de afronding van het project. De extra kosten die hiermee gepaard gaan kunnen op hun beurt weer leiden tot een nieuw meningsverschil. Als partijen niet opletten zullen de standpunten steeds verder uit elkaar lopen en raken de verhoudingen zo bekoeld dat een succesvolle samenwerking en daarmee de succesvolle afronding van het project in gevaar komt.

Om dit te voorkomen is het belangrijk dat in de overeenkomst een procedure wordt opgenomen die partijen moeten volgen indien een meningsverschil aan het licht komt. Als vuistregel geldt dat in eerste instantie geprobeerd moet worden om het probleem op te laten lossen op het niveau waar het zich voordoet. En dat het probleem besproken dient te worden door gelijkwaardige gesprekspartners van partijen. Indien de betrokkenen er niet uitkomen, kan het probleem vervolgens een niveau hoger gebracht worden.

Om de kans op meningsverschillen tussen partijen te verkleinen is het raadzaam afspraken te maken over een overlegstructuur waarbij partijen regelmatig met elkaar overleggen over de voortgang van het project. Daarbij geldt in de regel dat hoe groter en ingewikkelder het project, des te vaker overleg noodzakelijk zal zijn.

Voor het geval partijen er in onderling overleg niet meer uitkomen, dient ook een externe geschillenregeling opgenomen te worden in het ICT-contract. Om de kans op herstel van de relatie zo groot mogelijk te houden is mediation via de Stichting Geschillenoplossing Automatisering (SGOA) een goede optie. Daarna kan gedacht worden aan arbitrage of een gerechtelijke procedure. Voor spoedeisende zaken wordt vaak een uitzondering gemaakt.

5. Staken ondersteuning

Relatief veel discussies betreffen het niet langer ondersteunen van een bepaalde versie van de software door de leverancier. Reden voor het beëindigen van de ondersteuning is vaak dat de leverancier inmiddels een nieuwe versie ontwikkeld heeft en het niet rendabel is om de oude versie te blijven ondersteunen.

De leverancier doet er goed aan om zo vroegtijdig mogelijk aan de klant te communiceren op welk moment de ondersteuning voor de aangeschafte versie zal eindigen. Door zich in de overeenkomst het recht voor te behouden om de ondersteuning te beëindigen op het moment dat de ondersteuning van de gebruikte versie van het platform niet langer wordt ondersteund, zorgt de leverancier dat de klant niet verrast wordt.

De meest extreme vorm van staken van ondersteuning doet zich voor wanneer de leverancier failliet gaat. Voor leveranciers is het in de praktijk weinig aantrekkelijk om na te denken over een mogelijk eigen faillissement. Toch is het van belang dit wel te doen. In deze economisch onzekere tijden vragen steeds meer klanten naar een oplossing voor dit risico in de vorm van een escrow-regeling. Zeker als het om een bedrijfskritisch ICT-systeem gaat. Een escrowregeling kan daarom commercieel gezien aantrekkelijk zijn om de klant over de streep te trekken. Een leverancier dient zich echter wel te realiseren dat een escrow-regeling nadelig kan uitpakken op het moment dat de leverancier vanuit faillissement een doorstart wil maken.

De adviespet

Door de klant te adviseren over het aan te schaffen ICT-systeem heeft de leverancier de kans om aan de juridische kwalificatie van “deskundige” automatiseringsadviseur te voldoen. Daardoor loopt hij het risico om de daarbij behorende verantwoordelijkheden naar zich toe te trekken. Een deskundige heeft een informatieplicht jegens zijn klant. Het gaat dan om een drietal elementen: de onderzoeksplicht, de plicht tot het verstrekken van informatie en de waarschuwingsplicht.

6. Onderzoeksplicht

Een adviseur is in het algemeen pas in staat om goed te adviseren nadat hij onderzoek heeft gedaan naar de organisatie van de klant. Uit rechtspraak volgt dat de adviseur zichzelf daarvoor voldoende tijd moet gunnen, ook als de klant haast heeft. De adviseur heeft in deze namelijk een eigen verantwoordelijkheid en kan zich niet achter de haast van de klant verschuilen. Hoe gedetailleerd het onderzoek van de adviseur dient te zijn, hangt af van de met de automatisering gemoeide (financiële) belangen en de complexiteit van de automatisering.

7. Verplichting tot verstrekken informatie

Na het onderzoek moet de adviseur de klant zo volledig mogelijk adviseren over hoe het automatiseringsproces in elkaar zit. De adviseur dient er bovendien voor te zorgen dat de informatie op zodanige wijze aan de klant wordt gepresenteerd, dat de klant in staat is om de informatie te begrijpen. De adviseur zal daarbij ook aandacht moeten besteden aan de eigen rol als leverancier. Indien er kans is op een belangenconflict – bijvoorbeeld doordat de leverancier een hogere marge heeft op product X – maar product Y voor de klant een goedkopere of snellere oplossing biedt – dient de adviseur daar op te wijzen. Daarbij past wel een nuancering. Van een leverancier van product X kan niet verwacht worden dat hij ook precies op de hoogte is van de producten van leverancier Y. Dus vraagt een klant om advies aan een leverancier van product X, dan mag hij niet verwachten dat deze leverancier een product van leverancier Y zal meenemen in zijn advisering.

8. Waarschuwingsplicht

Op de adviseur rust de verplichting om de klant te wijzen op de risico’s die samenhangen met het voorgestelde systeem of de voorgestelde oplossing. Daarbij dient de adviseur in het bijzonder rekening te houden met door de klant naar voren gebrachte specifieke wensen. De adviseur zal moeten wijzen op alle risico’s die zich redelijkerwijs voor kunnen doen. Onder omstandigheden kan het voor de adviseur zelfs verstandig zijn om de door de leverancier geplande automatisering af te raden of zelfs de opdracht als adviseur terug te geven.

Tips:

Onderzoek de échte klantbehoefte.

Leg duidelijk vast wat er wel, wat er niet en wat er tegen meerprijs geleverd wordt.

Maak duidelijke afspraken over noodzakelijke koppelingen met andere systemen.

Zorg voor een goede interne en externe geschillenregeling.

Benoem de voorwaarden waaronder de ondersteuning kan worden beëindigd.

Wees u bewust van de eventuele adviseursrol van de leverancier en de daarbij behorende verantwoordelijkheden.

Rutger Ketting is ICT-advocaat bij Nysingh advocaten - notarissen