Waar moet je op letten bij het aangaan van een contract voor systeemontwikkeling?

De contracten die worden afgesloten in projecten voor de ontwikkeling van IT-systemen zijn voornamelijk aannemingsovereenkomsten en quasi-mandaatovereenkomsten. Zowel voor de gebruiker als voor de leverancier zijn er verschillende voor- en nadelen aan het aannemen van elk type contract, maar het is belangrijk om de kenmerken en aandachtspunten bij het afsluiten ervan te begrijpen. In dit artikel zullen we de aannemingsovereenkomst in de IT-systeemontwikkelingssector bespreken.

Systeemontwikkeling en aannemingsovereenkomsten

Wat is een aannemingsovereenkomst?

Om te begrijpen wat een aannemingsovereenkomst is, is het allereerst belangrijk om de vereisten voor het tot stand komen van een aannemingsovereenkomst direct vanuit de wettekst te controleren.

Artikel 632

Een aannemingsovereenkomst ontstaat wanneer een partij overeenkomt om een bepaalde taak te voltooien en de andere partij overeenkomt om voor het resultaat van die taak een vergoeding te betalen.

“Het voltooien van een taak” is de belangrijkste sleutelterm. Een typisch voorbeeld van een aannemingsovereenkomst is de bouw van een gebouw dat bouwwerkzaamheden vereist. Bijvoorbeeld, het bouwen van een huis of gebouw tegen een bepaalde deadline wordt beschouwd als “het voltooien van een taak”, en de verplichting wordt beschouwd als vervuld. Als de bouw niet vordert en de deadline wordt overschreden, kan er onder bepaalde voorwaarden sprake zijn van een verzuim van de verplichting. Maar als eenmaal “het voltooien van een taak” is erkend, is er geen probleem meer met het niet nakomen van de verplichting, en wordt het een kwestie van garantie voor gebreken. In deze zin is het kenmerk van een aannemingsovereenkomst dat het resultaat van “het voltooien van een taak” zeer belangrijk is. Wat wordt beschouwd als “het voltooien van een taak” wordt in detail uitgelegd in het volgende artikel.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Aannemingsovereenkomsten worden niet alleen gebruikt in de bouw, maar ook vaak in systeemontwikkelingsprojecten die een groot concept en gedetailleerde planning vereisen.

Het verschil tussen aannemingsovereenkomsten en quasi-mandaatovereenkomsten

Als je eenmaal begrijpt dat een aannemingsovereenkomst een contracttype is dat zich richt op het resultaat van “het voltooien van een taak”, dan begrijp je ook de kenmerken van een quasi-mandaatovereenkomst. Deze richt zich niet op het resultaat van “voltooiing”, maar op het proces. Bijvoorbeeld, als de administratieve verwerking op zich correct is uitgevoerd, ongeacht het resultaat, is het mogelijk om een vergoeding te vragen (artikel 648, lid 2), en als de uitvoering halverwege is beëindigd om redenen die niet aan de opdrachtnemer kunnen worden toegeschreven, is het mogelijk om een vergoeding te vragen in verhouding tot dat deel (artikel 648, lid 3).

Voor een vergelijking tussen mandaatovereenkomsten en quasi-mandaatovereenkomsten, zie het volgende artikel.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Waarom aannemingsovereenkomsten de voorkeur hebben bij systeemontwikkeling

In contracten voor systeemontwikkeling worden aannemingsovereenkomsten zeer vaak gebruikt. De reden waarom aannemingsovereenkomsten vaak worden gebruikt, is dat er bepaalde voordelen zijn voor zowel de gebruiker die de opdracht geeft als de leverancier die de opdracht aanneemt.

Een van de voordelen voor de gebruiker om werk uit te besteden via een aannemingsovereenkomst is dat de vereisten voor het nakomen van de verplichting gemakkelijk kunnen worden verduidelijkt in de vorm van “het voltooien van een taak”. Met andere woorden, er is een duidelijkheid dat je in principe niet hoeft te betalen tenzij het in een staat is die als “voltooid” kan worden beschouwd (zelfs als er later problemen ontstaan met de garantie voor gebreken, zoals het vinden van bugs). Dit kan zeer aantrekkelijk zijn voor gebruikers die niet het risico willen lopen dat de vergoeding die ze moeten betalen oploopt als het werk meer tijd kost dan verwacht of als de deadline wordt overschreden. Het betalen van een vast bedrag voor het “voltooide” product in ruil voor een gelijkwaardige uitwisseling heeft grote voordelen vanuit het oogpunt van budgetbeheer.

Aan de andere kant kan er ook een bepaald voordeel zijn voor de leverancier die het werk aanneemt via een aannemingsovereenkomst. Een aannemingsovereenkomst kan een hogere winstmarge opleveren dan een quasi-mandaatovereenkomst, als het werk goed verloopt.

Omdat “het voltooien van een taak” een vereiste is voor het nakomen van de verplichting, kan de partij die het werk aanneemt, ongeacht het proces tot “voltooiing”, de kosten van het product (in het geval van systeemontwikkeling, voornamelijk personeelskosten) negeren. Op deze manier, met de wensen van zowel de leverancier die de winstmarge wil verhogen als de gebruiker die het budgetbeheer gemakkelijker wil maken, hebben aannemingsovereenkomsten de neiging om zeer de voorkeur te hebben in systeemontwikkeling.

Aandachtspunten bij het aangaan van een contract

Hoewel er voordelen zijn aan contracten voor zowel gebruikers als leveranciers, brengt het aangaan van een contract zonder de nodige voorzichtigheid, vooral voor de leverancier, ook risico’s met zich mee. Het feit dat ‘voltooiing van het werk’ nodig is voor de uitvoering van de verplichting betekent dat men in principe niet wordt vrijgesteld van aansprakelijkheid voor niet-nakoming zonder dat het eindproduct is voltooid. Dit is ook de reden waarom er vaak problemen ontstaan, zoals het moeten besteden van tijd aan levering, zelfs als er verlies wordt geleden door fouten in de schatting van de leverancier.

Dus, wat moet er in acht worden genomen in de contracttekst bij het aangaan van een contract? Laten we hieronder elk punt bekijken.

Maak de systeemvereisten en acceptatiecriteria van tevoren duidelijk

Het is vanzelfsprekend dat het belangrijk is om de voorwaarden voor ‘voltooiing van het werk’ duidelijk te maken in een contract. Normaal gesproken verwijzen de ‘voltooiingsvereisten’ hier naar de inhoud van de afspraken gemaakt tijdens de vereistendefinitiefase. Echter, in de praktijk kan het voorkomen dat men gedwongen wordt om wijzigingen aan te brengen naarmate het ontwikkelingsproces vordert, waardoor de ‘voltooiingsvereisten’ ook flexibel kunnen worden. Het is belangrijk om ook deze wijzigingen in de specificaties te documenteren. In het volgende artikel wordt uitgelegd hoe u wijzigingsbeheer in systeemontwikkelingsprojecten kunt uitvoeren vanuit een juridisch perspectief.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Daarnaast is het effectief om van tevoren afspraken te maken over de ‘acceptatie’ die de gebruiker zal uitvoeren om latere problemen te voorkomen. Het is vanzelfsprekend dat situaties kunnen ontstaan waarin het eindproduct wordt geleverd, maar de verantwoordelijke persoon aan de kant van de gebruiker niet kan worden bereikt of er geen antwoord komt. Om te voorkomen dat de acceptatie onbepaald blijft, is het nuttig om een bepaalde deadline voor de acceptatie in te stellen. Dit wordt een ‘veronderstelde acceptatieclausule’ genoemd, en wordt uitgelegd in het volgende artikel.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Maak van tevoren afspraken over de overdracht van auteursrechten

Een ander veelvoorkomend probleem is de overdracht van auteursrechten. Hoewel het principe is dat de ‘maker’, oftewel de leverancier in het geval van systeemontwikkeling, de auteursrechten verkrijgt, is het mogelijk om deze rechten over te dragen of over te dragen vanwege de aard van de rechten. Daarom kan het voorkomen van problemen na het feit worden voorkomen door van tevoren afspraken te maken over of de auteursrechten al dan niet aan de gebruiker worden overgedragen. Auteursrechten en overdracht worden in detail uitgelegd in het volgende artikel.

https://monolith.law/corporate/copyright-for-the-program-source-code[ja]

Andere aandachtspunten

Daarnaast, als u een contract wilt aangaan als een contract zonder enige quasi-delegatie-elementen, moet u zich bewust zijn van de volgende punten:

• Zorg ervoor dat de vergoeding onafhankelijk is van de hoeveelheid werk
• Verduidelijk in de titel van het contract dat het een ‘contract’ is
• Maak de clausule voor garantieaansprakelijkheid duidelijk
• Zorg ervoor dat de betaling van de vergoeding een gelijkwaardige uitwisseling is voor het resultaat of de prestatie

Het is belangrijk om deze punten in gedachten te houden.

Daarnaast is het een vergissing om te denken dat alles een contract wordt als je ‘contract’ in de titel van het contract schrijft. In de praktijk worden sjablonen van contracten van andere bedrijven vaak hergebruikt zonder aandacht te besteden aan of de inhoud van de notities een contract of quasi-delegatie is. In het geval van een rechtszaak, worden meer substantiële zaken, zoals de algehele inhoud van de contractuele bepalingen en eerdere handelsgebruiken, belangrijker dan oppervlakkige elementen zoals de woorden in de titel. Het is belangrijk om ook hier aandacht aan te besteden.

Samenvatting

Met inachtneming van de bovenstaande punten, wordt de contractuele administratie door middel van aanneming gemakkelijker te verwerken. Het woord “opdracht” wordt zowel in aannemingscontracten als in quasi-mandaatcontracten gebruikt. Bovendien wordt de term “opdracht van werk” doorgaans gebruikt wanneer er een intentie is tussen de partijen om een quasi-mandaatcontract aan te gaan. Het is raadzaam om ook aandacht te besteden aan deze subtiele verschillen in terminologie.