Het onderscheid en de verschillen tussen contracten voor systeemontwikkeling en quasi-delegatiecontracten

Bij het aannemen en plaatsen van systeemontwikkelingsopdrachten worden verschillende contracten met verschillende titels uitgewisseld, zoals de overeenkomst van opdracht, de overeenkomst van dienstverlening en de overeenkomst van systeemontwikkeling.

In de wet wordt een onderscheid gemaakt tussen contracten waarbij de ene partij een dienst (zoals ontwikkelingswerk) op zich neemt en de andere partij daarvoor een vergoeding betaalt. Deze contracten worden onderscheiden als aannemingsovereenkomsten en quasi-mandaatovereenkomsten.

Om het simpel te zeggen,

• Aannemingsovereenkomst: een contract waarbij je betaald krijgt als je levert wat beloofd is

• Quasi-mandaatovereenkomst: een contract waarbij je betaald krijgt en je best doet in overeenstemming met die vergoeding

is het.

Is systeemontwikkeling een contractwerk of een quasi-mandaat?

Systeemontwikkeling heeft als doel het creëren van een ‘beloofd’ systeem, en volgens het bovenstaande onderscheid zou het een contractwerk kunnen zijn, maar het is niet zo eenvoudig. Dit komt omdat systeemontwikkeling enigszins verschilt van een typisch contractwerk zoals de wet dat voorstelt.

Een typisch contractwerk is bijvoorbeeld een op maat gemaakt pak. In het geval van een pak, zodra de maten zijn bepaald, is het gemakkelijk voor de partijen om een beeld te hebben van het voltooide product, en het is ook gemakkelijk om te beoordelen of het voltooide product overeenkomt met de bestelling. Daarentegen bestaat er bij systeemontwikkeling meestal geen documentatie die een gemakkelijk begrip van het totaalbeeld van het systeem mogelijk maakt, en het kan moeilijk zijn voor de opdrachtgever om een volledig beeld te krijgen. Bovendien heeft het systeem dat wordt ontwikkeld de bijzonderheid dat het geleidelijk concreter wordt door verschillende processen van verschillende aard.

Daarom is het vaak een probleem om te onderscheiden of de aard van het contract in een bepaalde fase van de systeemontwikkeling, met name in de beginfase, een ‘contractwerk’ is dat de voltooiing van het werk belooft, of een ‘quasi-mandaat’ dat het beste belooft. Afhankelijk van dit onderscheid kan het gebeuren dat als het werk niet wordt voltooid, de vergoeding die het systeemontwikkelingsbedrijf kan krijgen nul wordt, wat leidt tot een situatie waarin een van de partijen een onevenredig en groot financieel last moet dragen. Daarom is het belangrijk om te onderscheiden welk type contract het is.

In dit verband zal ik uitleggen wat het verschil is tussen een contractwerk en een quasi-mandaat, welk contract moet worden aangegaan, en de criteria voor het onderscheiden van de twee.

Verschillen tussen contracten voor aanneming van werk en quasi-mandaatcontracten

Allereerst zullen we de verschillen in bepalingen tussen contracten voor aanneming van werk en quasi-mandaatcontracten volgens het Japanse Burgerlijk Wetboek uitleggen, evenals de behandeling in het geval van speciale overeenkomsten.

Ontvangst van vergoeding, beëindiging, garantieaansprakelijkheid voor gebreken, heruitbesteding en speciale overeenkomsten in contracten voor werkzaamheden

Een contract voor werkzaamheden is een overeenkomst waarbij de ene partij (de aannemer/leverancier) belooft een bepaalde taak te voltooien en de andere partij (de opdrachtgever/gebruiker) belooft een vergoeding (het contractbedrag) te betalen voor het resultaat van die taak.

Met “voltooiing van de taak” wordt bijvoorbeeld bedoeld de creatie van output waarover beide partijen het eens zijn, zoals een ‘projectplan’, ‘requirements document’, ‘basisontwerpdocument’, ‘programma’, ‘systeem’, enzovoort.

Ontvangst van vergoeding

Als de taak niet wordt voltooid, kan de aannemer/leverancier geen vergoeding ontvangen. Als u wilt worden betaald voordat de taak is voltooid, moet u een speciale overeenkomst voor vooruitbetaling sluiten. In projecten voor systeemontwikkeling op basis van contracten voor werkzaamheden is “voltooiing van de taak” een zeer belangrijk concept. Dit wordt in detail uitgelegd in het volgende artikel.

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

Bovendien wordt in het geval van systeemontwikkeling de “voltooiing van de taak” meestal erkend na een ‘acceptatietest’.

Zelfs als er een speciale overeenkomst is gesloten, moet de aannemer/leverancier, als de taak niet wordt voltooid vanwege de stopzetting van het project, de reeds ontvangen vergoeding terugbetalen aan de opdrachtgever/gebruiker als ongerechtvaardigde verrijking. Dit is het grootste verschil met een quasi-mandaatovereenkomst.

Beëindiging

Als er geen wanprestatie (contractbreuk) is van beide partijen, kan de opdrachtgever/gebruiker de overeenkomst beëindigen door schadevergoeding te betalen tot de taak is voltooid. In dit geval is de “schade” het bedrag dat de aannemer/leverancier heeft uitgegeven en de vergoeding die hij zou hebben ontvangen, minus de kosten die hij heeft kunnen besparen door vrijgesteld te worden van de verplichting om de taak te voltooien. Aan de andere kant kan de aannemer/leverancier niet beëindigen.

Als er een speciale overeenkomst wordt gesloten dat er niet kan worden beëindigd tenzij er wanprestatie is van de andere partij, loopt de aannemer/leverancier niet het risico dat hij op elk moment kan worden beëindigd, zelfs als er geen contractbreuk is.

Garantieaansprakelijkheid voor gebreken

Als er gebreken zijn in het doel van de taak, kan de opdrachtgever verzoeken om herstel van de gebreken, schadevergoeding eisen, en de overeenkomst beëindigen als het doel van de overeenkomst niet kan worden bereikt.

Gebreken betekenen tekortkomingen of defecten, en worden erkend als de kwaliteit of prestaties die het doel van de overeenkomst zou moeten hebben, ontbreken in het licht van het doel van de overeenkomst. Als het systeem niet voldoet aan de beloofde specificaties of prestaties nadat de laatste geplande fase van de overeenkomst is voltooid en voltooid, wordt dit beschouwd als een “gebrek”.

In een rechtszaak werd geoordeeld dat bugs met betrekking tot persoonlijke informatie lekken in de systeemopbouw van een universiteit geen gebreken waren, maar dat het ontbreken van noodzakelijke exclusieve controle in het betreffende systeem een “gebrek” was. U kunt een speciale overeenkomst sluiten om geen garantieaansprakelijkheid voor gebreken te dragen, of om de periode waarin u garantieaansprakelijkheid draagt te verkorten.

Over garantieaansprakelijkheid voor gebreken wordt in detail uitgelegd in het volgende artikel.

https://monolith.law/corporate/defect-warranty-liability[ja]

Heruitbesteding

De aannemer/leverancier kan vrij heruitbesteden. Als er een speciale overeenkomst wordt gesloten dat heruitbesteding verboden is, kan er niet worden heruitbesteed.

Vergoeding, beëindiging, garantieaansprakelijkheid en herbenoeming in quasi-mandaatcontracten

Een quasi-mandaatcontract is een contract waarbij iemand (de aannemer/leverancier) wordt aangesteld door een ander (de opdrachtgever/gebruiker) om administratieve taken uit te voeren. De aannemer heeft de plicht om zijn capaciteiten te benutten en zijn taken op een redelijke manier uit te voeren, in overeenstemming met de zorgplicht van een goede beheerder. In wezen betekent dit “het beste doen”.

Een typisch voorbeeld is medische behandeling, waarbij de verantwoordelijkheid niet ligt bij het genezingsresultaat, maar bij het leveren van een behandeling die boven de standaard ligt.

Het grote verschil met een aannemingsovereenkomst is dat je niet verantwoordelijk hoeft te zijn voor het resultaat van het werk.

Vergoeding

In tegenstelling tot een aannemingsovereenkomst, kan de aannemer/leverancier een vergoeding ontvangen, zelfs als het werk niet is voltooid, zolang de administratieve taken correct zijn uitgevoerd. Bovendien, als de opdracht halverwege wordt beëindigd door omstandigheden die niet aan de aannemer kunnen worden toegeschreven, kan de aannemer een vergoeding vragen in verhouding tot het reeds uitgevoerde werk.

In de herziening van de Wet op de Schuldvorderingen, die in 2017 werd afgekondigd en in april 2020 (Japanse Heisei 32) in werking trad, is bepaald dat zelfs in het geval van een quasi-mandaat, er een vergoeding kan worden betaald voor de bereikte resultaten, en dat in dat geval de vergoeding in principe kan worden geëist na voltooiing van de resultaten.

Of het mogelijk is om de eenmaal vastgestelde vergoeding te verhogen op basis van de voortgang van de systeemontwikkeling, wordt in detail uitgelegd in een apart artikel.

Beëindiging

Zelfs als de andere partij niet in gebreke is, kan niet alleen de opdrachtgever/gebruiker, maar ook de aannemer/leverancier, in tegenstelling tot een aannemingsovereenkomst, het contract op elk moment beëindigen.

Als er een speciale overeenkomst wordt gesloten waarin staat dat het contract niet kan worden beëindigd tenzij de andere partij in gebreke is, is er geen risico dat het contract zonder reden op elk moment wordt beëindigd.

De juridische problemen die zich voordoen wanneer de systeemontwikkeling wordt onderbroken omwille van de gebruiker worden in detail uitgelegd in het volgende artikel.

Garantieaansprakelijkheid

Er is geen bepaling voor garantieaansprakelijkheid, in tegenstelling tot een aannemingsovereenkomst. “Garantieaansprakelijkheid” en de eerder genoemde “acceptatie” zijn enigszins bekende juridische termen in verband met systeemontwikkeling, maar deze concepten komen alleen voor in het geval van een aannemingsovereenkomst. Echter, de aannemer heeft de plicht om “zijn best te doen” en als hij zijn taken niet op een redelijke manier uitvoert, kan hij aansprakelijk worden gesteld voor schadevergoeding of beëindiging op basis van wanprestatie.

Met name de verplichtingen die de leverancier in systeemontwikkeling op zich neemt, omvatten projectmanagementverplichtingen.

Herbenoeming

In tegenstelling tot een aannemingsovereenkomst, kan de aannemer/leverancier in principe geen herbenoeming doen. Als je een herbenoeming wilt doen, sluit je een speciale overeenkomst daarvoor.

Dit punt is vaak een probleem in de praktijk en vereist aandacht. Als je een contract aangaat voor een quasi-mandaatontwikkelingsproject zonder een speciale overeenkomst voor herbenoeming, op basis van het oordeel dat “aangezien het systeemontwikkeling is, zou herbenoeming mogelijk moeten zijn tenzij anders vermeld”, kun je in een situatie terechtkomen waarin je wordt beschuldigd van contractbreuk omdat je een herbenoeming hebt gedaan.

Er zijn ook verplichtingen die de gebruiker als opdrachtgever moet nakomen

Hoewel de discussie tot nu toe voornamelijk betrekking heeft gehad op de verplichtingen van de leverancier als opdrachtnemer, wordt er in het geval van systeemontwikkeling, waar veel mankracht en tijd nodig is, ook een bepaalde ‘samenwerkingsplicht’ opgelegd aan de gebruiker als opdrachtgever. We bespreken dit punt in detail in een apart artikel.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Welke te kiezen: een aannemingsovereenkomst of een quasi-mandaatovereenkomst?

Voor- en nadelen voor ontwikkelingsbedrijven/leveranciers

Voor ontwikkelingsbedrijven/leveranciers is het voordeel van het kiezen voor een ‘aannemingsovereenkomst’ dat als ze het goed doen met minder mensen, ze meer kunnen verdienen dan met een quasi-mandaat. In tegenstelling tot een quasi-mandaat, is het bij een aanneming de plicht om het werk ‘af te maken’. Met andere woorden, hoeveel kosten je ook bespaart door minder mensen in te zetten of het werk efficiënter te maken, zolang je het werk maar afmaakt, heb je aan je plicht voldaan.

De nadelen zijn:

• Je kunt geen vergoeding krijgen tot het werk is voltooid
• Als er onverwachte werkuren ontstaan om aan de eisen te voldoen, kunnen de kosten van extra werk leiden tot een mogelijk verlies
• Je draagt de verantwoordelijkheid voor gebreken
• Als er onverwachte werkuren ontstaan om aan de eisen te voldoen, kunnen de kosten van extra werk en andere onverwachte kosten leiden tot een mogelijk verlies
• Je draagt de verantwoordelijkheid voor gebreken

De voordelen van het kiezen voor een ‘quasi-mandaatovereenkomst’ zijn:

• Je kunt betaald krijgen, zelfs als het werk nog niet is voltooid
• Je kunt vergoed worden voor extra werkuren
• Je hoeft niet de zware verantwoordelijkheid te dragen om het werk af te maken en een product zonder gebreken te leveren
• In tegenstelling tot een aanneming, is het bij een quasi-mandaat de plicht om ‘een inspanning te leveren die overeenkomt met de vergoeding’, waardoor het gemakkelijker is om de kosten voor het nakomen van die plicht vooraf in te schatten

Voor- en nadelen voor opdrachtgevers/gebruikers

Voor opdrachtgevers/gebruikers zijn de voordelen van het kiezen voor een ‘aannemingsovereenkomst’ als volgt:

• Je hoeft geen vergoeding te betalen tot het werk is voltooid (je kunt vooruitbetaalde vergoedingen terugkrijgen)
• De te betalen vergoeding is vast, dus er zijn geen extra kosten voor extra werkuren

Het nadeel is dat je mogelijk een hoge offerte krijgt om het risico op verlies te vermijden.

De voordelen van het kiezen voor een ‘quasi-mandaatovereenkomst’ zijn dat je een lagere offerte kunt verwachten dan bij een aanneming. Het nadeel is dat je de verantwoordelijkheid om het werk af te maken niet volledig aan de opdrachtnemer/leverancier kunt overdragen, en dat als er onverwachte werkuren ontstaan, je extra kosten kunt maken voor extra werk en andere onverwachte kosten.

Rechtspraak

In de rechtspraak zijn er gevallen waarin een quasi-mandaatovereenkomst werd geacht te bestaan tot de bevestiging van de systeemvereisten en het basisontwerp, en gevallen waarin een aannemingsovereenkomst werd geacht te bestaan voor werkzaamheden vanaf het basisontwerp tot en met de eenheidstest.

Moet je een aannemingsovereenkomst of een quasi-mandaatovereenkomst sluiten?

Hoewel je zou kunnen overwegen om een standaardcontract te sluiten afhankelijk van de fase van het project, hangt de beslissing af van de moeilijkheidsgraad en inhoud van het te ontwikkelen product, het bedrag dat je wilt ontvangen/kunt voorbereiden, de intentie van de andere partij, de machtsverhouding tussen beide partijen, en of je in staat bent om een duidelijk beeld van het eindproduct in het contract te beschrijven. Dit moet worden besloten en onderhandeld op basis van individuele omstandigheden in elk bedrijf, vanuit zowel een zakelijk als een juridisch perspectief.

Voor juridische problemen en zaken die moeten worden overwogen in geval van niet-betaling van de vergoeding, zie het volgende artikel voor een gedetailleerde uitleg.

Criteria voor het onderscheid tussen een aannemingsovereenkomst en een quasi-mandaatovereenkomst

Wat is de bepaling van de aard van een contract?

“Het bepalen of de aard van een contract valt onder een aannemingsovereenkomst of een quasi-mandaatovereenkomst” komt aan de orde in welke situaties en wat voor soort problemen dit zijn.

Als er geen specifieke overeenkomst is tussen de partijen over of de betreffende dienst (of het contract daarvoor) een aannemingsovereenkomst of een quasi-mandaatovereenkomst is, dat wil zeggen, als er geen speciale overeenkomst is gesloten en deze clausule niet in het contract is opgenomen, dan wordt bepaald welke van de contracttypes die in het Burgerlijk Wetboek zijn vastgelegd van toepassing is op basis van een achteraf gemaakte beoordeling van “welk type contract het is”, en deze beoordeling wordt gemaakt op basis van bepaalde criteria.

Dit is wat het betekent.

Overigens, dit is een probleem vanuit het perspectief van:

1. Er is een overeenkomst gesloten voor systeemontwikkeling
2. Of die overeenkomst een aannemingsovereenkomst of een quasi-mandaatovereenkomst is

Maar voordat we dit probleem aanpakken, is er de vraag of er überhaupt een overeenkomst voor systeemontwikkeling is gesloten. Dit punt wordt in detail uitgelegd in een apart artikel.

En, zoals hierboven vermeld, ervan uitgaande dat er een overeenkomst voor systeemontwikkeling is gesloten, wordt de vraag welk type overeenkomst het is een groot probleem dat bepaalt welke partij een onevenredig groot bedrag aan geld moet betalen.

Het is niet ongebruikelijk dat er geen expliciete vermelding van “aanneming” of “quasi-mandaat” in het contract staat, of dat de werkelijke situatie anders is dan de expliciete vermelding, of dat er een verschil in perceptie is tussen de partijen. Daarom zal ik uitleggen wat de criteria zijn voor het onderscheid tussen een aannemingsovereenkomst en een quasi-mandaatovereenkomst.

De aard van het contract wordt bepaald door een algehele overweging van verschillende elementen

Om de aard van een contract te bepalen, moet je naar het geheel van het contract kijken en overwegen of het doel ervan is om “een voltooid product te leveren” of dat de leverancier “redelijk zijn taken uitvoert”. Het is belangrijk of de inhoud van het te voltooien product tot op zekere hoogte concreet is vastgesteld en of het project daarop gericht is voortgezet.

De volgende elementen worden in overweging genomen om de aard van het contract te bepalen:

Track record van het ontwikkelingsbedrijf

Als er een geschiedenis is van het creëren van systemen van dezelfde of hogere kwaliteit, wordt er vaak geoordeeld dat “het vanzelfsprekend was dat het zou worden voltooid, dat het een verplichting was om het te voltooien, en dat er een overeenkomst was dat de betaling zou worden gedaan bij voltooiing”, wat neigt naar een aannemingsovereenkomst.

Of het doel op de planning “voltooiing” is

Als het voltooiing is, wordt er vaak geoordeeld dat “het een verplichting was om het te voltooien”, wat neigt naar een aannemingsovereenkomst.

De duidelijkheid van de inhoud van het product in de contractinhoud en de vermeldingen in het contract

Hoe duidelijker, hoe meer het wordt geoordeeld dat “het was gepland om iets met duidelijke eisen te voltooien”, wat neigt naar een aannemingsovereenkomst.

Of de vergoeding op basis van een eenheidsprijs is

Als het ja is, wordt er vaak geoordeeld dat “het was opgezet om de vergoeding te genereren bij voltooiing, en het was een verplichting om het te voltooien”, wat neigt naar een aannemingsovereenkomst.

Of de vergoeding wordt betaald na voltooiing

Als het ja is, wordt er vaak geoordeeld dat “het een verplichting was om het te voltooien”, wat neigt naar een aannemingsovereenkomst.

De aanwezigheid van clausules voor acceptatie, defectgarantieaansprakelijkheid, en garantie

Als ze aanwezig zijn, wordt er vaak geoordeeld dat “het een verplichting was om het te voltooien” en “op basis daarvan waren er clausules voor acceptatie, defectgarantieaansprakelijkheid, en garantie voorbereid”, wat neigt naar een aannemingsovereenkomst.

De aanwezigheid van termen als “aanneming” of “quasi-mandaat”

Natuurlijk is de terminologie ook een belangrijk overwegingspunt. Echter, het wordt niet simpelweg beoordeeld op basis van de termen “aanneming” of “quasi-mandaat” alleen, dus je moet voorzichtig zijn met hoe je het contract schrijft.

Bovendien worden dergelijke beoordelingen niet alleen gemaakt op basis van het contract, maar ook op basis van bewijsmateriaal zoals de notulen die tijdens het proces van systeemontwikkeling zijn opgesteld. Het belang van de notulen wordt in detail uitgelegd in het volgende artikel.

Samenvatting

“Aanneming van werk” en “quasi-opdracht” lijken op elkaar, maar de juridische effecten zijn totaal verschillend. Het is veiliger om bij het aangaan van een contract de mening van een expert te raadplegen. Ons kantoor heeft uitgebreide expertise in zaken zoals systeemontwikkeling op contractbasis. Aarzel niet om vrijblijvend contact met ons op te nemen.