Veel gemaakte fouten bij IT-contracten en hoe ze te voorkomen

Voor het antwoord op die vraag moeten wij eerst uitzoomen en kijken naar de aard van een IT-contract. De meeste IT-contracten zijn namelijk gewoon overeenkomsten van opdracht. In de rechtspraak is evenwel de bijzondere zorgplicht van IT-leveranciers nader uitgewerkt – een IT-leverancier moet zich immers gedragen als een goed opdrachtnemer gedurende de uitvoering van zijn werkzaamheden (artikel 7:401 BW). Als een contract bepaalde leemtes of onduidelijkheden bevat, worden deze ingevuld aan de hand van deze zorgplicht. Wat deze zorgplicht in een concreet geval inhoudt, is sterk afhankelijk van de omstandigheden van het geval. Er zijn over de afgelopen jaren veel uitspraken gedaan die hier meer richting aan geven, maar indien een contract onduidelijk is of leemtes kent ontstaat er veelal een geschil over de reikwijdte van deze zorgplicht.

Hoe voorkom je dit probleem? Het klinkt simpel: zorg dat u goede en duidelijke contracten sluit, zonder leemtes. Dit is overigens niet alleen in het belang van de IT-leverancier, maar ook in het belang van de opdrachtgever. Het sluiten van een goed duidelijk contract met weinig leemtes klinkt misschien wat voor de hand liggend en simpel, maar dan moet u wel weten hoe een goed IT-contract op te stellen en waar u voor moet opletten. Hieronder enkele veel voorkomende fouten en de bijbehorende tips.

1. Verkeerde benaming/onduidelijkheid over de ontwikkelingsmethode

Indien een IT-contract ziet op de ontwikkeling van software gaat het vaak mis als partijen niet duidelijk maken wat voor ontwikkelingsmethode zij kiezen. Is er bijvoorbeeld sprake van een agile ontwikkeling – een flexibele ontwikkeling waarbij de leverancier direct aan de slag gaat en waarbij gebruik wordt gemaakt van sprints en de eisen gedurende de ontwikkeling duidelijk worden en geregeld met scrums wordt gewerkt? Of is er gekozen voor een waterval methode met diverse vooraf gedefinieerde fases? Kader vooraf goed in welke methode of methodes worden gehanteerd, zodat duidelijk is wat partijen van elkaar mogen verwachten.

2. Geen of onduidelijke beschrijvingen van de minimumvereisten van het product

Het kan zo zijn dat partijen vooraf nog niet precies weten wat een product (zoals software) moet kunnen of het kan zo zijn dat de minimumvereisten aan een product veranderen gedurende de ontwikkeling van het product. Om geschillen te voorkomen adviseren wij om, ook indien dat nog niet direct kan, toch zo snel mogelijk Key Performance Indicators (“KPI’s”) vast te leggen waar een product aan moet voldoen. Indien het contract al gesloten is en pas gedurende de ontwikkeling van het product de KPI’s worden vastgelegd, raden wij aan om dit expliciet op te nemen in een addendum. Op deze manier is het voor alle partijen duidelijk wat het product moet kunnen en kunnen partijen zelf (laten) bepalen of het product voldoet aan de eisen.

3. Het niet uitsluiten en/of geen duidelijk onderscheid maken tussen directe en indirecte schade

Als IT-leverancier is het noodzakelijk om onderscheid te maken tussen directe en indirecte schade en de laatstgenoemde soort schade uit te sluiten. Overigens is dit ook branchegebruikelijk. Wij zien alleen vaak dat als indirecte schade is uitgesloten, indirecte schade vervolgens niet gedefinieerd is in het contract. Naar Nederlands recht is indirecte schade echter geen vastomlijnd begrip. Partijen kunnen dan ook een geschil krijgen over de vraag of bepaalde schade gezien moet worden als indirecte schade. Indien een onderneming indirecte schade wil uitsluiten doet de onderneming er dan ook verstandig aan om te verduidelijken wat de partij ziet als indirecte schade (bijvoorbeeld bevat dit winstderving, boetes van autoriteiten, gevolgschade etc.)

4. Onderhoud en beheer

Partijen laten vaak na om duidelijke afspraken te maken over het onderhoud en beheer van de software. Werk daarom met een duidelijke Service Level Agreement (“SLA”) waarin staat beschreven onder welke voorwaarden de IT-leverancier onderhoud en beheersdiensten levert en waarin duidelijk vermeld staat wat voor werkzaamheden vallen onder deze onderhoud en beheersdiensten. Daarbij kan gebruik gemaakt worden van minimale reactietijden voor de IT-leverancier. Een mooi bijkomend voordeel voor de IT-leverancier is dat door een goede SLA ook direct de aansprakelijkheid van de IT-leverancier kan worden beperkt.

5. Gebrekkige acceptatieprocedure

Indien gekozen wordt voor een acceptatieprocedure voor het product, zorg dan dat de voorwaarden voor de acceptatie duidelijk zijn opgenomen in het contract en werk daarbij zoveel mogelijk met meetbare factoren, zoals KPI’s. Daarbij is het van groot belang dat de acceptatieprocedure (in ieder geval gedeeltelijk) in handen ligt van de IT-leverancier – dit voorkomt een gijzeling door een afnemer die onterecht stelt dat het product nog niet aan de (nauwelijks beschreven) eisen voldoet.

6. Inspannings-/resultaatsverplichtingen

Wees u bewust van het verschil tussen een inspanningsverbintenis, waarbij de andere partij zich enkel verplicht tot het leveren van een zekere inspanning, en een resultaatsverbintenis, waarbij de andere partij zich verplicht tot het leveren van een zeker resultaat. Het is immers een stuk lastiger om aan te tonen dat een partij niet voldoet aan een inspanningsverbintenis. Als IT-leverancier kan je hier in het contract mee spelen als je nieuwe software ontwikkeld.

7. Gebruik van garanties, zonder uitleg van de term garantie

Ook voor de term garantie geldt, dat dit geen vastomlijnd begrip is naar Nederlands recht. Indien partijen gebruik willen maken van een garantie, maak dan duidelijk wat deze garantie inhoudt en waar een partij recht op heeft als de andere partij zich niet aan de garantie houdt (bijvoorbeeld op schadevergoeding of indien mogelijk herstel of levering van een vervangend product).

8. Escrow-perikelen

Indien partijen gebruik willen maken van een escrow (het deponeren van de broncode van software bij een aangewezen derde, de escrow-agent) maak dan duidelijk vanaf wanneer de escrow vereist is en zorg ervoor dat er heldere (niet subjectieve!) voorwaarden zijn vastgesteld waaronder deze software vrij wordt gegeven. Spreek ook duidelijk af wie de kosten hiervoor draagt.

Meer weten over IT-contracten, onderstaande tips of wilt u simpelweg sparren over de inhoud van deze blog, neem dan contact op met Matthijs Gardien en Merel van Bunge.