Zorgplicht van de IT-leverancier telt steeds zwaarder

IT-afnemers doen in IT-geschillen steeds vaker met succes een beroep op de “zorgplicht” die op een IT-leverancier rust. Het gewicht dat rechters aan de zorgplicht toekennen wordt groter en het toepassingsbereik steeds uitgebreider. Regelmatig krijgt een IT-afnemer een schadevergoeding toegewezen, omdat de IT-leverancier zijn zorgplicht niet heeft nageleefd. Het is daarom goed om als IT-leverancier een idee te hebben wat deze zorgplicht inhoudt. Het betreft een zeer veelzijdig en dynamisch onderwerp, dat binnen het bestek van dit artikel niet in de volle omvang kan worden besproken. Echter, vanwege het toenemende belang schetsen wij hieronder toch een beeld van de ontwikkelingen in de rechtspraak op dit gebied.

Zorgplicht

De zorgplicht vindt zijn oorsprong in de wet: de opdrachtnemer moet bij zijn werkzaamheden de zorg van een goed opdrachtnemer in acht nemen. Daarnaast wordt de zorgplicht vaak ook expliciet opgenomen in IT-overeenkomsten. Er staat dan dat de IT-leverancier zijn dienstverlening op zorgvuldige en professionele wijze moet uitvoeren. In de rechtspraak wordt deze plicht neergelegd in de algemene norm dat een IT-leverancier moet handelen in overeenstemming met de zorg die van een redelijk en bekwaam IT-leverancier mag worden verwacht. Welke verplichtingen vloeien hier concreet uit voort?

Wat mogen de klant en de leverancier van elkaar verwachten?

Presales

De zorgplicht van de IT-leverancier berust voor een groot deel op de kennisachterstand die de gemiddelde afnemer ten opzichte van de professionele IT-leverancier heeft. Die kennisachterstand doet zich al voor bij de aanschaf van een IT-systeem en bijbehorende diensten. Het salestraject speelt een grote rol bij de verwachtingen die een afnemer heeft en mag hebben omdat de afnemer op de deskundigheid en de uitlatingen van de IT-leverancier mag vertrouwen.

Een professionele IT-leverancier dient een IT-systeem te adviseren en op te leveren dat voldoet aan de verwachtingen die een gemiddelde afnemer daaraan mag ontlenen. In verband daarmee moet de IT-leverancier vóór het sluiten van een overeenkomst onderzoeken of de IT-oplossing die hij aanbiedt bij de bedrijfsprocessen van de afnemer past en of er functionaliteiten ontbreken die de afnemer nodig heeft. Dat wordt de onderzoeksplicht genoemd. Ontbreken er functionaliteiten in de software die de afnemer waarschijnlijk verwacht of nodig heeft, dan moet de IT-leverancier dit tijdens het salestraject melden. Doet hij dat niet, dan mag de afnemer verwachten dat die functionaliteiten aanwezig zijn, zelfs als die functionaliteiten niet specifiek zijn overeengekomen. Er rust dus ook een informatieplicht op de IT-leverancier.

Vervolgens moet de afnemer bij het uitbrengen van de offerte worden geïnformeerd over de benodigde werkzaamheden en de daarmee gemoeide tijd, wat dan wordt vertaald in een realistische planning en budget. Wanneer een afnemer een bepaalde (fatale) termijn stelt waarvan de IT-leverancier bij voorbaat weet dat deze mogelijk niet haalbaar is, dan is een voorbehoud voor het halen van die termijn op zijn plaats.

Implementatie

De informatieplicht speelt ook een grote rol tijdens het implementatietraject. Denk hierbij aan het adequaat informeren over de voortgang, het bereiken van mijlpalen en de kostenbeheersing. Bij een geschil over de gefactureerde werkzaamheden wordt onder meer gekeken of de facturen overeenstemmen met de kwaliteit en voortgang van het werk. Daarbij worden ook de doelstellingen van de implementatieovereenkomst meegenomen. Ook wil een rechter weten hoe een overschrijding van het budget is ontstaan. Tijdens het implementatietraject moet de vinger aan de pols worden gehouden voor wat betreft meerwerkwensen. Dit houdt meer in dan het volgen van de afgesproken meerwerkprocedure. De afnemer moet namelijk uitdrukkelijk worden gewezen op de gevolgen van meerwerkwensen voor planning, budget en het eindresultaat. De afnemer kan de consequenties van wijzigingsvoorstellen immers niet altijd overzien. Er rust dan ook een waarschuwingsplicht op de IT-leverancier: indien nodig moet de IT-leverancier herhaaldelijk en duidelijk waarschuwen wanneer de afnemer op dit gebied een misstap dreigt te begaan. Als blijkt dat voortzetting van het project alleen maar geld zal kosten en geen direct voordeel meer zal opleveren voor de afnemer, is het zaak de afnemer hierop te wijzen. In uitzonderlijke gevallen moet de IT-leverancier dan zelfs aansturen op opschorting of beëindiging van de samenwerking.

De wet biedt de IT-leverancier een uitweg wanneer sprake is van kennelijk onwerkbare wensen. De IT-leverancier mag de overeenkomst opzeggen wanneer de wensen van de afnemer zo onredelijk zijn dat niet kan worden verwacht dat de IT-leverancier hierin (langer) meegaat. Doorgaans zal het beëindigen van de samenwerking middenin het project geen voor de hand liggende stap zijn. Een IT-leverancier mag zijn dienstverlening ook niet zomaar beëindigen als de software voor de afnemer van wezenlijk belang is. Dit levert een lastig spanningsveld op. Bij een dreigende escalatie kan de afnemer in ieder geval worden gewezen op het feit dat de IT-leverancier niet verplicht is om mee te (blijven) gaan in onwerkbare wensen. Rechters lijken dit in bepaalde gevallen ook van IT-leveranciers te verwachten. Dit geldt temeer als de projectleiding bij de IT-leverancier ligt. Als het projectmanagement (volledig) bij de afnemer zelf berust, ligt dit genuanceerder.

Slecht projectmanagement kan onder omstandigheden ontbinding van de overeenkomst door de afnemer rechtvaardigen. Goed projectmanagement houdt, naast het actief monitoren van de wensen van de afnemer en de gevolgen daarvan, ook in dat de afnemer wordt aangespoord tot voortgang wanneer hij niet voortvarend genoeg te werk gaat. Ook het waarschuwen voor infrastructurele problemen en onjuist gebruik van de software, als die in de weg staan aan het verbeteren van de performance van de software, horen bij de zorgplicht van de IT-leverancier.

Tot slot zal een afnemer, in geval van problemen bij het uitvoeren van testen, adequaat moeten worden begeleid. Het goed uitvoeren van de testen is voor het welslagen van het project immers van groot belang.

Beveiliging

Ook als het op de beveiliging van de software aankomt, rust er een zorgplicht op de IT-leverancier. In een eerder artikel signaleerden we al dat een IT-leverancier indringend en herhaaldelijk moet waarschuwen voor de risico’s wanneer een afnemer niet wil betalen voor beveiligingsmaatregelen en dat hij dan mogelijk zelfs de opdracht moet weigeren. Wel wordt de afnemer zelf verantwoordelijk geacht voor het gebruik van voldoende veilige wachtwoorden, zolang de IT-leverancier maar op het belang hiervan heeft gewezen.

Alleen een verantwoordelijkheid voor de leverancier?

Het lijkt er soms op dat de verantwoordelijkheid volledig bij de IT-leverancier wordt gelegd. Dat is niet helemaal juist. Rechters verwachten ook van afnemers projectdiscipline in die zin dat zij zich houden aan het projectplan en de afspraken die daarin zijn gemaakt inzake de verdeling van verantwoordelijkheden en taken. Daarnaast mag van afnemers worden verwacht dat zij adviezen van de IT-leverancier opvolgen. Verder komt naar voren dat afnemers tijdig aan de bel moeten trekken wanneer zaken niet lopen zoals afgesproken of het project uit de pas dreigt te lopen.

Omstandigheden-mix

Het gewicht dat aan de zorgplicht wordt toegekend is mede afhankelijk van de individuele omstandigheden. Zo speelt onder meer een rol of sprake is van advisering over de te implementeren software en of sprake is van ontwikkeling van software. De zwaarte van de zorgplicht hangt ook af van de omvang van de opdracht en de kans op schade bij het mislukken van het project. De zorgplicht van de IT-leverancier wordt (wat) gerelativeerd wanneer de afnemer wordt bijgestaan door een deskundige, omdat dan minder snel sprake is van kennisachterstand bij de afnemer. Ook in de overeenkomst zelf kunnen afspraken worden gemaakt die de zorgplicht van de IT-leverancier (iets) verlichten. Dit betreft bijvoorbeeld de bepaling dat sprake is van inspanningsverplichtingen en de afspraak dat het projectmanagement en het testen de (volledige) verantwoordelijkheid van de afnemer is. Toch kan daarmee de zorgplicht niet worden weggewuifd. De zorgplicht is er, alleen het gewicht ervan kan door middel van een goed contract worden genuanceerd.

Gevolgen

De gevolgen van de schending van de zorgplicht kunnen groot zijn. Wanneer de zorgplicht niet wordt nageleefd, kan mogelijk de overeenkomst worden ontbonden. Zonder afspraken hierover in de overeenkomst, betekent dit in het slechtste geval dat alle betaalde facturen moeten worden terugbetaald. Daarnaast kan ook een schadevergoeding worden gevorderd, die flink kan oplopen wanneer een (goede) aansprakelijkheidsbeperking ontbreekt.

Conclusie en tips voor de praktijk

Zowel in het voortraject als tijdens het IT-project rust er een zorgplicht op de IT-leverancier. In de rechtspraak zien we vooral de onderzoeksplicht, de informatieplicht en de waarschuwingsplicht in verschillende situaties en gradaties terug. Het gewicht ervan hangt onder meer af van de IT-deskundigheid die een afnemer zelf in huis heeft, de inhoud van de opdracht en de afspraken die tussen partijen zijn gemaakt.

Gezien het toenemende belang van de zorgplicht is het zaak om hier bewust mee om te gaan, maar ook om zorgvuldig te documenteren dat aan de zorgplicht is voldaan:

• Maak in presentaties/demo’s over de software ook duidelijk wat de software niet kan. Leg dit ook vast in de overeenkomst.
• Maak duidelijke afspraken over de rollen en taken van betrokkenen en geef aan wat concreet van de afnemer wordt verwacht.
• Houd de vinger aan de pols voor wat betreft meerwerkwensen en volg de afgesproken procedures.
• Documenteer adviezen en waarschuwingen inzake wensen/beslissingen van de afnemer, de voortgang van het project en beveiligingsmaatregelen. Verzamel deze documentatie op één plek.
• Sta open voor feedback van de afnemer en zie dit als een kans om de processen te evalueren en mogelijk een escalerend project weer op de rails te krijgen.

Dit artikel is geschreven door Annemarie Bolscher en is eerder verschenen als expertbijdrage in het IT-magazine AG Connect.