Aansprakelijkheid bij IT-contracten beperken: tips van een expert

In dit artikel vertelt Sari van Grondelle, zelfstandig advocaat Technology, Data & Cyber én docent bij de training verdieping van de IT-contractspraktijk, meer over de aansprakelijkheidsrisico’s rondom IT-contracten. Dat doet ze aan de hand van een aantal heldere vragen die je ongetwijfeld triggeren omdat ze zómaar aan jou gesteld kunnen worden in je dagelijkse praktijk. En, als je kritisch naar jezelf bent, hoe goed ben je dan écht op de hoogte?

Aan welke knoppen je kunt draaien om aansprakelijkheid te beperken

Sari van Grondelle: ‘In de praktijk wordt in veel gevallen behoorlijk veel tijd geïnvesteerd in de uitonderhandeling van de aansprakelijkheidsbepaling in een overeenkomst. Daar is op zich niets mis mee, maar een goede aansprakelijkheidsbepaling is slechts een van de manieren om aansprakelijkheid binnen een IT-project te beperken. Daarbij moet je bedenken dat een aansprakelijkheidsbeperking pas om de hoek komt kijken wanneer aan de wettelijke eisen voor aansprakelijkheid is voldaan. Aan het daadwerkelijk aansprakelijk stellen van je wederpartij gaat dus vaak een heleboel vooraf. En in die tijd vooraf kan ook al een groot aantal acties ondernomen worden om eventuele aansprakelijkheid te voorkomen dan wel te beperken. Ook de rest van de overeenkomst kan daarbij helpen.’

‘Het begint al bij het opnemen van een duidelijke omschrijving van wat over en weer gepresteerd zal worden. Wat voor IT-oplossing moet er precies komen, wat moet het allemaal kunnen en aan welke technische specificaties moet het voldoen? Welke verplichtingen heeft de leverancier ten aanzien van implementatie, onderhoud, continuïteit van die oplossing en de te leveren service levels? Een onduidelijke omschrijving van de prestaties levert niet alleen een lastige bewijspositie op wanneer een van de partijen moet aantonen dat de ander is tekortgeschoten, het kan ook leiden tot aansprakelijkheid voor het niet voldoen aan verplichtingen die door een rechter op een later moment worden ingelezen en daardoor misschien wel onvoldoende zijn afgedekt in de overeenkomst.

Duidelijkheid is daarom geen overbodige luxe, je wilt voorkomen dat je in een grijs gebied terecht komt en afhankelijk wordt van de uitleg van een rechter (mocht het zover komen). Bovendien is toch meestal het uitgangspunt dat je, als leverancier, iets goeds wilt opleveren en je, als opdrachtgever, blij wilt zijn met het resultaat.’

Over draagvlak en aansprakelijkheidsrisico’s bij IT-contracten

‘Naast een duidelijke omschrijving van de wederzijdse prestaties, bevat een overeenkomst verscheidende bepalingen die inhaken op aansprakelijkheid. Daarbij moet je bijvoorbeeld denken aan afspraken rondom de klachttermijn, vervaltermijnen, het intreden van verzuim, garanties en vrijwaringen. Goede afspraken rondom deze onderwerpen kunnen eventuele aansprakelijkheidsrisico’s verder mitigeren’.

‘Kortom, en het lijkt een inkoppertje, aansprakelijkheid staat niet los van de rest van de inhoud van de overeenkomst. Alle onderdelen communiceren met elkaar. In de basis gaat het erom dat je goed in beeld brengt wat je aansprakelijkheidsrisico’s zijn en welke bepalingen in de overeenkomst daar op inhaken. Houdt voor ogen dat er dus meer knoppen zijn om aan te draaien wanneer je aansprakelijkheid wilt voorkomen of beperken. Een heldere, uitgebalanceerde overeenkomst kan daar heel goed bij helpen’, aldus Sari.

‘Het kan soms wat vervelend voelen voor partijen, omdat je aan de start van een veelbelovende samenwerking al bezig bent met de situatie waarin het mis kan gaan. Daar wil je eigenlijk niet mee bezig zijn. Ik zie de overeenkomst daarom liever als een hulpmiddel om het juiste gesprek te voeren.’

Zó creëer je draagvlak binnen je organisatie om een IT-project te laten slagen

‘Je ziet soms dat IT-projecten mislukken omdat er niet genoeg draagvlak is binnen een organisatie om een bepaald systeem in gebruik te nemen,’ vervolgt Sari. ‘Er is geregeld gesteggeld over de vraag wie daar dan verantwoordelijk voor is. Heeft de leverancier iets beloofd wat uiteindelijk niet de functionaliteit had om in gebruik genomen te kunnen worden óf wilden de mensen aan de zijde van de opdrachtgever gewoonweg niet werken met het nieuwe systeem? Hoe het ook zij, het is in ieder geval een aandachtspunt.

Zowel voor de opdrachtgever als de leverancier. Voor de leverancier is het van belang om na te gaan of de opdrachtgever voldoende meewerkt om te zorgen dat het project van diens zijde kans van slagen heeft, en als hij opmerkt dat dit niet het geval is dat op tijd op te zien. Er rust een bijzondere zorgplicht op de leverancier die maakt dat een afnemer bepaalde inspanningen mag verwachten naast de afspraken in de overeenkomst’, vervolgt Sari.

‘Ook voor opdrachtgevers is het belangrijk om te zorgen voor voldoende draagvlak binnen de organisatie voor een nieuw te introduceren IT-systeem. Vertragingen en aanpassingen gaan gepaard met bijkomende kosten, en dat wil je voorkomen. Draagvlak creëer je vaak niet door top-down een nieuw systeem op te leggen. Je stuit al snel op weerstand wanneer een systeem werkprocessen bemoeilijkt. Het betrekken van de mensen die moeten gaan werken met een nieuw systeem is daarom aan te raden. Naarmate een IT-systeem belangrijker is en de impact van de introductie ervan op de manier van werken van mensen groter, is het des te belangrijker om mensen te betrekken in de keuze en het bepalen van de functionaliteit en specificaties. Dat is natuurlijk niet altijd even eenvoudig.

IT-contracten en nieuwe systemen

De rol van de jurist daarin kan zijn om na te vragen hoe de keuze voor een bepaald systeem tot stand is gekomen en of er nagedacht is over de manier waarop mensen betrokken kunnen worden bij de implementatie ervan. Processen daaromtrent kunnen in de overeenkomst worden vastgelegd, denk aan regelmatige bijeenkomsten waarin met elkaar gesproken kan worden over de voortgang van een project en beslissingen genomen kunnen worden.’

IT-systemen voor IT-contracten

‘Soms vraagt een nieuw IT-systeem een nieuwe manier van werken. Het is bijvoorbeeld niet mogelijk of heel erg duur om al bestaande werkprocessen te vertalen naar het nieuwe systeem. In zo’n geval moeten de werkprocessen aangepast worden. Dit is een project op zich dat risico’s kan hebben voor de voortgang en het succes van het IT-project. Zorg er daarom tijdens de transitie voor dat iedereen on board is en blijft, en dat mensen ook écht intrinsiek gemotiveerd zijn op een andere manier te gaan werken. Anders krijg je gegarandeerd situaties waarin allerlei ‘workarounds’ bedacht worden, en daarmee saboteer je dus eigenlijk het uiteindelijke succes van het project.

Als een project om die reden mislukt, dan is het nog maar de vraag of je de leverancier daarvoor aansprakelijk kan houden. Dus, als je een IT-project start, kijk dan niet alleen technisch, maar ook praktisch. Wie zijn er aan de zijde van de opdrachtgever nodig om een project te laten slagen, wie worden door het project geraakt, hoe worden en blijven zij gedurende het project betrokken en wat moet daarover in de overeenkomst worden opgenomen?’

‘Samenvattend, het is belangrijk om de onderliggende overeenkomst niet als een soort drempel te zien. Kijk er veel meer naar als een hulpmiddel voor een goede samenwerking met heldere afspraken. Alle stappen die je neemt in een samenwerking hebben juridische consequenties. Als je dat beseft kun je een eerlijk gesprek met elkaar te voeren en er veel meer uit halen. Dat is juist voor IT-projecten heel belangrijk, want als je de cijfers mag geloven dan mislukken er behoorlijk wat projecten.’

Opstellen en beoordelen van IT-contracten

Sari besluit: ‘De training Verdieping van de IT-contractspraktijk bundelt alle kennis en vaardigheden om de meest complexe IT-contracten te kunnen opstellen en beoordelen. Daarnaast ontvang je veel concrete tips & tricks waarmee je direct verder kunt. Zo ben je in staat om de beste voorwaarden te bedingen én houd je risico’s binnen de perken.’