10 mrt '23
In het kader van best practices hieronder een korte opsomming van de fouten die wij vaak zien bij IT-contracten en een aantal tips en tricks om dit te voorkomen.
Iedere onderneming heeft er tegenwoordig wel mee te maken: IT-contracten. Het kan daarbij gaan om een softwarelicentieovereenkomst, een onderhoudsovereenkomst of bijvoorbeeld om een koopovereenkomst voor allerlei verschillende soorten hardware, etc. Wat zijn veelgemaakte fouten bij dit soort contracten en hoe kunnen deze worden 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.
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.
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.
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.)
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.
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.
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.
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).
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.
Contact
04 dec 24
29 nov 24
25 nov 24
19 nov 24
13 nov 24
11 nov 24
07 nov 24
01 nov 24
21 okt 24
14 okt 24
13 okt 24
09 okt 24
Met uw inschrijving blijft u op de hoogte van de laatste juridische ontwikkelingen op dit gebied. Vul hieronder uw gegevens in om per e-mail op te hoogte te blijven.
Blijf op de hoogte van de laatste juridische ontwikkelingen in uw sector. Vul hieronder uw gegevens in om op maat gesneden juridische updates en uitnodigingen voor evenementen te ontvangen.
Volgen wat u interessant vindt
Krijg aanbevelingen op basis van uw interesses
{phrase:advantage_3}
{phrase:advantage_4}
We vragen u om uw voor- en achternaam zodat wij die kunnen gebruiken als u zich bijvoorbeeld inschrijft op een Ploum Kennisevent.
Er wordt automatisch een wachtwoord voor u aangemaakt. Zodra uw account is aangemaakt ontvangt u dit wachtwoord in een welkomstmail. U kunt er direct mee inloggen. Dit wachtwoord kunt u indien gewenst ook zelf aanpassen via de wachtwoord vergeten functie.