Wat zijn de belangrijke controlepunten in contracten voor systeemontwikkeling op contractbasis?

Het Japanse Ministerie van Economie, Handel en Industrie (METI) heeft modelclausules voor IT-systeemontwikkelingscontracten gepresenteerd in de ‘Richtlijnen voor het verbeteren van de betrouwbaarheid van informatiesystemen’. Door de verspreiding van het internet en dergelijke, wordt de sociale impact van bedrijfs- en serviceonderbrekingen of functionele afnames door informatiesysteemfouten steeds ernstiger. Terwijl het verbeteren van de betrouwbaarheid en veiligheid van systemen een dringende kwestie is geworden, hebben IT-systeemontwikkelingscontracten de neiging om de inhoud van transacties onduidelijk te maken. Deze clausules zijn bedoeld om deze zichtbaar te maken en de rolverdeling en verantwoordelijkheidsrelaties te verduidelijken. In dit artikel zullen we uitleggen wat de controlepunten zijn voor contractdocumenten bij het aangaan van een contract voor IT-systeemontwikkelingswerk, met verwijzing naar de clausules van het METI-modelcontract.

Systeemontwikkeling en aannemingsovereenkomsten

Wat is een aannemingsovereenkomst?

Een aannemingsovereenkomst wordt in het Burgerlijk Wetboek als volgt gedefinieerd:

Artikel 632
Een aannemingsovereenkomst ontstaat wanneer de ene partij belooft een bepaalde taak te voltooien en de andere partij belooft te betalen voor het resultaat van die taak.

In een aannemingsovereenkomst is het een vereiste dat er een belofte is om een taak te voltooien. Bijvoorbeeld, als het doel van de overeenkomst is om een bepaald systeem te ontwikkelen tegen een bepaalde deadline, dan is de verplichting van de leverancier om het systeem tegen die deadline te voltooien. Als het systeem niet op tijd voltooid kan worden, kan de leverancier aansprakelijk worden gesteld voor niet-nakoming van de verplichting wegens vertraging. Echter, als er na de levering van het voltooide systeem gebreken worden gevonden, is de verplichting van de leverancier al nagekomen, dus niet-nakoming is geen probleem, en het wordt een kwestie van garantie voor gebreken. In systeemontwikkeling, wanneer “voltooiing van het werk” wordt erkend, wordt in detail uitgelegd in het volgende artikel.

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

Het verschil met quasi-mandaatovereenkomsten

In een aannemingsovereenkomst heeft de leverancier de verplichting om het werk te voltooien, dus als er gebreken zijn in het geleverde product, is hij verantwoordelijk voor de garantie voor gebreken. Daarentegen, in een quasi-mandaatovereenkomst is er geen verplichting om het werk te voltooien, dus er is geen verantwoordelijkheid voor de garantie voor gebreken zoals in een aannemingsovereenkomst. Echter, als er een zorgplicht wordt erkend in het proces van het afhandelen van zaken, kan er een aparte aansprakelijkheid voor niet-nakoming van de verplichting, zoals schadevergoeding, zijn. Welke verantwoordelijkheden een probleem worden in systeemontwikkelingsovereenkomsten wordt in detail uitgelegd in het volgende artikel.

https://monolith.law/corporate/responsibility-system-development [ja]

Modelclausules en controlepunten voor contractuele overeenkomsten

Ondersteuning bij het opstellen van systeemvereisten

Het definiëren van systeemvereisten is het proces van het samenstellen van de specificaties die een gebruiker nodig heeft voor het systeem dat ze willen bouwen. In de fase van het definiëren van systeemvereisten, wordt de richting van de systeembouw overwogen en wordt besloten welk soort systeem er gebouwd zal worden. Omdat het niet altijd mogelijk is om concreet te voorspellen wat het eindproduct zal zijn, stelt het Japanse Ministerie van Economie, Handel en Industrie (METI) in haar modelcontract dat dit een quasi-mandaat is. Meer details worden uitgelegd in het volgende artikel.

https://monolith.law/corporate/system-development-contract-check-quasi-mandate [ja]

Opstellen van Externe Ontwerpdocumenten

(Uitvoering van de taak om een extern ontwerpdocument te maken)
Artikel ○: De tweede partij zal, na het sluiten van de individuele overeenkomst zoals bepaald in artikel ○, de taak uitvoeren om een extern ontwerpdocument voor de betreffende software te maken, gebaseerd op de vereistendefinitiedocument dat is vastgesteld volgens de bepalingen van artikel ○.

2. Bij de uitvoering van de taak om een extern ontwerpdocument te maken, kan de tweede partij de eerste partij om noodzakelijke medewerking vragen, en de eerste partij zal hierop tijdig reageren als de tweede partij om medewerking vraagt.

Het maken van een extern ontwerpdocument is een taak die het gebruik van interfaces zoals schermen en formulieren regelt. In principe moet alle informatie waarmee de leverancier de software kan ontwikkelen, in het externe ontwerpdocument worden opgenomen. Hoewel het externe ontwerpdocument gedetailleerde informatie over het gebruik van de sjabloon bevat, kan alleen de gebruiker, die de inhoud van de taak bepaalt, de vereiste specificaties wijzigen. Echter, als het vereistendefinitiedocument, dat het resultaat is van de vorige fase van het maken van een extern ontwerpdocument, de behoeften van de gebruiker duidelijk definieert en de inhoud van het werk dat de leverancier moet voltooien duidelijk is, kan de overeenkomst worden gesloten met de leverancier als de hoofdpartij in een contractvorm voor het maken van een extern ontwerpdocument.

Paragraaf 1 bepaalt dat de leverancier de hoofdpartij is in de uitvoering van de taak, omdat dit proces contractueel is. Echter, zelfs in een contractuele overeenkomst, omdat het externe ontwerp sterk gerelateerd is aan de definitie van de inhoud van de taak van de gebruiker, is actieve betrokkenheid van de gebruiker vereist. Daarom bepaalt paragraaf 2 dat de leverancier de gebruiker kan vragen om medewerking die nodig is voor de overweging en beslissing van de systeemspecificaties, en dat de gebruiker hierop tijdig zal reageren, waardoor duidelijk wordt dat de overweging van de systeemspecificaties een gezamenlijke taak is van de leverancier en de gebruiker.

(Het sluiten van een individuele overeenkomst met betrekking tot het opstellen van externe ontwerpdoocumenten)
Artikel ○ Partij A en Partij B zullen, met betrekking tot het opstellen van externe ontwerpdoocumenten, de handelsvoorwaarden zoals vermeld in Artikel ○, Paragraaf ○, bespreken en vaststellen, en een individuele overeenkomst sluiten met betrekking tot het opstellen van externe ontwerpdoocumenten.

De reikwijdte en dergelijke van het opstellen van externe ontwerpdoocumenten zullen worden bepaald in een individuele overeenkomst, in overeenstemming met de handelsvoorwaarden die zijn vastgesteld in de vorige clausule.

(Externe Ontwerpbespreking)
Artikel ○: Partij B zal, naar behoefte en met de nodige frequentie, een overlegvergadering (hierna in deze sectie “Externe Ontwerpbespreking” genoemd) houden om zaken te verduidelijken of te bevestigen die nodig zijn voor het opstellen van het externe ontwerpdocument. Partij A zal aan deze vergadering deelnemen.

2. Partij A kan ook, indien nodig, een Externe Ontwerpbespreking houden voor het opstellen van het externe ontwerpdocument, en Partij B zal hieraan deelnemen.

3. Als Partij A, door de discussies tijdens de Externe Ontwerpbespreking, besluit om de inhoud van het vereisten specificatiedocument te wijzigen en dit leidt tot een wijziging van de voorwaarden van de individuele overeenkomst, zoals de werkperiode en de vergoeding, zal dit gebeuren volgens de procedure van Artikel 33 (Wijziging van de inhoud van deze overeenkomst en de individuele overeenkomst).

Voor het opstellen van een extern ontwerpdocument dat de interfaces zoals schermen en formulieren bepaalt, is samenwerking tussen de gebruiker en de leverancier essentieel. Omdat dit proces op contractbasis is, bepaalt paragraaf 1 dat de leverancier de vergadering organiseert en de gebruiker hieraan deelneemt. De verduidelijking of bevestiging van zaken die nodig zijn voor het opstellen van het externe ontwerpdocument wordt allemaal gedaan tijdens de Externe Ontwerpbespreking, en zowel de leverancier als de gebruiker zijn gebonden aan de resultaten van de bespreking.

Paragraaf 2 bepaalt dat de gebruiker ook een Externe Ontwerpbespreking kan houden indien nodig voor het uitvoeren van het werk om het externe ontwerpdocument op te stellen.
Paragraaf 3 bepaalt dat, als de gebruiker besluit om de inhoud van het vereisten specificatiedocument te wijzigen op basis van de discussies, en dit kan invloed hebben op de werkperiode, vergoeding, enz. zoals bepaald in de individuele overeenkomst, de wijziging van de inhoud van deze overeenkomst en de individuele overeenkomst zal worden uitgevoerd volgens de methode bepaald in een andere clausule.

(Levering van het externe ontwerpdocument)
Artikel ○: De partij B zal het externe ontwerpdocument en het verzoek om acceptatie van het externe ontwerpdocument (tevens leveringsdocument) leveren aan partij A voor de deadline zoals bepaald in de individuele overeenkomst.

Gezien dit project op contractbasis is, zal de leverancier het externe ontwerpdocument en dergelijke als resultaat leveren.

(Goedkeuring en bevestiging van het externe ontwerpdocument)
Artikel ○ De partij A zal binnen de periode vastgesteld in de individuele overeenkomst (hierna te noemen “de inspectieperiode van het externe ontwerpdocument”) controleren of het externe ontwerpdocument overeenkomt met de vereisten die zijn vastgesteld volgens artikel ○ en de beslissingen genomen in de externe ontwerpbespreking zoals bepaald in artikel ○, en of er geen logische fouten zijn. Als bewijs van goedkeuring dat het document overeenkomt en er geen logische fouten zijn, zullen de verantwoordelijken van beide partijen hun handtekening en zegel zetten op het goedkeuringsdocument van het externe ontwerp. Echter, als uit de inspectie blijkt dat er delen van het externe ontwerpdocument zijn die niet overeenkomen met de vastgestelde vereisten of als er logische fouten worden ontdekt, zal partij B een gecorrigeerde versie maken binnen de afgesproken termijn na overleg en deze aan partij A voorleggen, die vervolgens opnieuw de bovengenoemde inspectie en goedkeuringsprocedure zal uitvoeren.

2. Als partij A geen bezwaar maakt met een specifieke reden in een schriftelijk document binnen de inspectieperiode van het externe ontwerpdocument, wordt aangenomen dat partij A het externe ontwerpdocument heeft goedgekeurd bij het verstrijken van de inspectieperiode.

3. Met de goedkeuring van partij A volgens de vorige twee paragrafen, wordt het externe ontwerpdocument als bevestigd beschouwd.

In de externe ontwerpfase worden de vereisten vastgesteld die nodig zijn voor de latere creatie van het interne ontwerpdocument, maar als de bevestiging van de vereisten vaag blijft, kunnen er problemen ontstaan in de latere ontwikkeling. Dit artikel bepaalt de procedure voor het inspecteren van het externe ontwerpdocument, dat de basis vormt voor latere ontwikkelingswerkzaamheden, door de gebruiker en het bevestigen ervan door de goedkeuring van de gebruiker.

Paragraaf 1 bepaalt dat de gebruiker de overeenstemming met de vereisten die zijn vastgesteld in een ander artikel en de resultaten van de discussie in de externe ontwerpbespreking, evenals de afwezigheid van logische fouten, zal controleren. Er kunnen gevallen zijn waarin correcties nodig zijn tijdens de inspectie voor de goedkeuring van het externe ontwerpdocument, en de voorwaarde in deze paragraaf bepaalt de procedure in dergelijke gevallen.
Paragraaf 2 is een bepaling dat, zelfs als de handtekening en zegel voor goedkeuring niet zijn voltooid, als de gebruiker geen bezwaar maakt binnen een bepaalde periode, het wordt beschouwd als goedgekeurd door de gebruiker. Het ingaan op het interne ontwerp terwijl de aanwezigheid of afwezigheid van goedkeuring door de gebruiker vaag blijft, kan later problemen veroorzaken, en deze paragraaf is bedoeld om dergelijke problemen te voorkomen.

En paragraaf 3 bepaalt dat het externe ontwerpdocument wordt bevestigd met de goedkeuring van de gebruiker.

(Gebreken garantie verantwoordelijkheid)
Artikel ○ Na de bevestiging van het vorige artikel, in het geval dat er een discrepantie of logische fout (hierna in dit artikel aangeduid als “gebrek”) wordt ontdekt in het externe ontwerpdoeument in vergelijking met het vereisten specificatiedocument en de beslissingen genomen in de externe ontwerpbespreking zoals bepaald in artikel ○, kan partij A verzoeken dat partij B het genoemde gebrek corrigeert, en partij B zal het genoemde gebrek corrigeren. Echter, partij B is alleen verantwoordelijk voor dergelijke correcties als het verzoek van partij A binnen ○ maanden na de bevestiging van het vorige artikel is gedaan.

2. Ondanks het vorige lid, als het gebrek klein is en de correctie van het externe ontwerpdoeument buitensporige kosten vereist, zal partij B niet verantwoordelijk zijn voor de correctie zoals bepaald in het vorige lid.

3. De bepalingen van lid 1 zijn niet van toepassing wanneer het gebrek is ontstaan door documenten of instructies die door partij A zijn verstrekt. Echter, dit is niet het geval als partij B niet heeft aangegeven dat de documenten of instructies ongeschikt zijn, terwijl zij wisten dat dit het geval was.

Dit artikel bepaalt de garantieverantwoordelijkheid voor gebreken met betrekking tot het externe ontwerpdoeument. De garantieperiode voor gebreken wordt bepaald door een redelijke periode te bepalen door onderhandelingen tussen de partijen, rekening houdend met de omvang van het informatiesysteem en de vergoeding, enz.

Artikel 1 definieert een discrepantie tussen het externe ontwerpdoeument en het vereisten specificatiedocument en de beslissingen genomen in de externe ontwerpbespreking, of een logische fout in het externe ontwerpdoeument, als een gebrek.

Artikel 2 beschermt de leverancier door te stellen dat het onredelijk is om de leverancier te vragen om gratis correcties te maken, zelfs als het gebrek klein is, maar de correctie van de geleverde goederen buitensporige kosten vereist, in overeenstemming met de uitzondering in artikel 634, lid 1, van het Burgerlijk Wetboek.

Artikel 3 bepaalt, in overeenstemming met de uitzondering in artikel 636 van het Burgerlijk Wetboek, dat als het gebrek te wijten is aan instructies of documenten die door de gebruiker zijn verstrekt, de leverancier niet wordt vrijgesteld van de garantieverantwoordelijkheid, tenzij de leverancier aangeeft dat de documenten of instructies van de gebruiker ongeschikt zijn, terwijl zij weten dat dit het geval is.

Let op, de garantieverantwoordelijkheid voor gebreken is een optionele bepaling, dus als er geen dergelijke bepaling is, zal de behandeling volgens de algemene principes van het Burgerlijk Wetboek worden uitgevoerd. De garantieverantwoordelijkheid voor gebreken is sterk beïnvloed door de herziening van het Burgerlijk Wetboek, die in april 2020 (Reiwa 2) in werking is getreden, dus na de inwerkingtreding van de herziene Burgerlijk Wetboek, zal het een gebied zijn waar de behandeling verschilt van de traditionele. De details worden uitgelegd in het volgende artikel.

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

Softwareontwikkelingsdiensten

(Uitvoering van softwareontwikkelingswerkzaamheden)
Artikel 〇: De partij B zal, na het sluiten van de individuele overeenkomst zoals bepaald in artikel 25, softwareontwikkelingswerkzaamheden uitvoeren, variërend van interne ontwerpen tot systeemtests, op basis van de systeemspecificaties die zijn vastgesteld volgens de voorgaande secties.

2. Bij de uitvoering van de softwareontwikkelingswerkzaamheden kan partij B de nodige medewerking van partij A verzoeken, en partij A zal tijdig reageren op dergelijke verzoeken van partij B.

In de volgende artikelen worden de bepalingen uiteengezet voor het geval dat de leverancier de softwareontwikkeling uitvoert op contractbasis. In de fase van het interne systeemontwerp is het gebruikelijk dat het ontwikkelingsdoel en de specificaties al zijn gedefinieerd in de werkzaamheden tot aan de vorige fase, daarom wordt dit in het modelcontract van het Japanse Ministerie van Economie, Handel en Industrie (METI) gedefinieerd als contractbasis.

(Het sluiten van een individuele overeenkomst met betrekking tot softwareontwikkelingswerk)
Artikel X: Partij A en Partij B zullen, met betrekking tot het betreffende softwareontwikkelingswerk, de handelsvoorwaarden zoals vermeld in Artikel X, Paragraaf X, bespreken en vaststellen, en een individuele overeenkomst sluiten met betrekking tot het softwareontwikkelingswerk.

Wat betreft de reikwijdte van het softwareontwikkelingswerk, wordt overeengekomen dat dit zal worden bepaald in een individuele overeenkomst, in overeenstemming met de eerder vastgestelde handelsvoorwaarden.

(Levering van de goederen)
Artikel X: De partij B zal de goederen, zoals gespecificeerd in het individuele contract, leveren aan partij A, samen met het verzoek tot acceptatie (tevens leveringsdocument), voor de deadline zoals vastgesteld in het individuele contract.
2. Partij A zal, in het geval van levering, een inspectie uitvoeren in overeenstemming met de inspectiespecificaties van het volgende artikel en de bepalingen van artikel X (Acceptatie van de betreffende software).
3. Partij B kan, bij de levering van de goederen, verzoeken om noodzakelijke medewerking van partij A, en partij A zal onmiddellijk reageren op dergelijke verzoeken.
4. Het risico van verlies of beschadiging van de goederen zal worden gedragen door partij B voorafgaand aan de levering en door partij A na de levering.

Omdat dit proces contractueel is, wordt de voltooide software en dergelijke geleverd als een product dat onderworpen is aan inspectie. Het eerste lid bepaalt dat de goederen samen met het verzoek tot acceptatie (tevens leveringsdocument) worden geleverd.

Het tweede lid bepaalt de uitvoering van de inspectie door de gebruiker.
Het derde lid bepaalt de verplichting van de gebruiker om medewerking te verlenen, aangezien er gevallen kunnen zijn waarin de medewerking van de gebruiker vereist is voor de levering op de plaats die is vastgesteld in het individuele contract (bijvoorbeeld wanneer de goederen worden geleverd door ze naar het kantoor van de gebruiker te brengen, of wanneer ze worden geleverd in een staat die operationeel is in de daadwerkelijke bedrijfsomgeving van de gebruiker).
Het vierde lid is een clausule over het risico van verlies of beschadiging van de goederen, en verdeelt het moment van overdracht van het risico op basis van de overdracht van fysieke controle.

(Acceptatie van de betreffende software)
Artikel 〇 Voor de betreffende software onder de geleverde items, moet de partij A, binnen de periode gespecificeerd in het individuele contract (hierna “inspectieperiode” genoemd), de inspectie uitvoeren op basis van de inspectiespecificaties van het vorige artikel en controleren of de systeemspecificaties en de betreffende software overeenkomen.

2. Als de betreffende software voldoet aan de inspectie van het vorige lid, zal partij A een inspectiecertificaat ondertekenen en stempelen en dit aan partij B overhandigen. Als de betreffende software niet slaagt voor de inspectie van het vorige lid, zal partij A een document met de specifieke redenen voor de mislukking snel aan partij B overhandigen en om correcties of aanvullingen vragen. Als de redenen voor de mislukking worden erkend, zal partij B, na overleg, de correcties gratis uitvoeren binnen de afgesproken termijn en deze aan partij A leveren. Partij A zal, indien nodig, de inspectie zoals bepaald in het vorige lid opnieuw uitvoeren.

3. Zelfs als er geen inspectiecertificaat wordt uitgegeven, als partij A geen bezwaar maakt met specifieke redenen in een schriftelijk document binnen de inspectieperiode, wordt de betreffende software beschouwd als geslaagd voor de inspectie zoals bepaald in dit artikel.

4. De acceptatie van de betreffende software wordt voltooid met de inspectie-goedkeuring zoals bepaald in dit artikel.

Omdat dit proces contractueel is, bepaalt dit artikel de procedure voor het accepteren van de geleverde software.

De eerste paragraaf bepaalt dat de betreffende software binnen de inspectieperiode moet worden geïnspecteerd op basis van de inspectiespecificaties en dat moet worden gecontroleerd of de systeemspecificaties en de betreffende software overeenkomen.
De tweede paragraaf verplicht de leverancier om de software te corrigeren als blijkt dat deze niet voldoet aan de systeemspecificaties, en om de gecorrigeerde versie aan de gebruiker te leveren.
De derde paragraaf voorkomt dat de acceptatie wordt uitgesteld door de gebruiker door een bepaling voor een veronderstelde inspectie-goedkeuring.
De vierde paragraaf verduidelijkt dat de acceptatie van de betreffende software wordt voltooid met de inspectie-goedkeuring.

(Gebreken garantie verantwoordelijkheid)
Artikel 〇 Na de voltooiing van de inspectie in het vorige artikel, als er een discrepantie (inclusief bugs, hierna “gebreken” genoemd in dit artikel) wordt ontdekt tussen de geleverde goederen en de systeemspecificaties, kan de partij A de partij B verzoeken om de genoemde gebreken te corrigeren, en de partij B zal deze gebreken corrigeren. Echter, de partij B is alleen verantwoordelijk voor dergelijke correcties als ze binnen 〇 maanden na de voltooiing van de inspectie in het vorige artikel worden aangevraagd door de partij A.
2. Ondanks het vorige lid, als het gebrek klein is en de correctie van de geleverde goederen buitensporige kosten vereist, is de partij B niet verplicht om de correctie verantwoordelijkheid zoals bepaald in het vorige lid te dragen.
3. De bepalingen van lid 1 zijn niet van toepassing als het gebrek is ontstaan door documenten of instructies die door de partij A zijn verstrekt. Echter, dit is niet het geval als de partij B niet heeft aangegeven dat dergelijke documenten of instructies ongeschikt zijn, ondanks dat ze dit wisten.

Omdat dit project contractueel is, bepaalt dit artikel de garantieverantwoordelijkheid voor gebreken met betrekking tot de geleverde goederen. Het is moeilijk om in de praktijk te bepalen waar de grens ligt tussen de verantwoordelijkheid voor niet-nakoming van verplichtingen in situaties waarin de prestatie niet is geleverd (het werk is niet voltooid) en de garantieverantwoordelijkheid voor gebreken na de voltooiing van de prestatie (het werk is voltooid). Er is een rechterlijke uitspraak (Tokyo District Court, 22 april 2002 (Heisei 14)) die stelt dat of een systeem als voltooid kan worden beschouwd in systeemontwikkeling, moet worden bepaald op basis van of het werk is voltooid tot de laatste fase die was gepland in het oorspronkelijke contract. Na de voltooiing en inspectie van de software tot de geplande laatste fase, als er gebreken worden ontdekt, wordt in principe de garantieverantwoordelijkheid voor gebreken toegepast.

Artikel 1 definieert “niet-overeenstemming met de systeemspecificaties” als een gebrek dat is ontstaan in softwareontwikkelingswerk. Voor tekortkomingen in functies die zich voordoen in de externe ontwerpfase, wordt de verantwoordelijkheid bepaald door bepalingen zoals de garantieverantwoordelijkheid voor gebreken in de externe ontwerpfase, niet door dit artikel. De garantieperiode voor gebreken wordt bepaald door een periode die redelijk wordt geacht na overleg tussen de partijen, rekening houdend met de omvang van het informatiesysteem en de vergoeding, enz.

Artikel 2 bevat een bepaling die vergelijkbaar is met artikel 634, lid 1, van het Burgerlijk Wetboek, omdat het onredelijk is om de leverancier te vragen om gratis correcties te maken, zelfs als het gebrek klein is en de correctie van de geleverde goederen buitensporige kosten vereist.

Artikel 3 is een bepaling die vergelijkbaar is met artikel 636 van het Burgerlijk Wetboek, waarin staat dat de leverancier geen garantieverantwoordelijkheid draagt als het gebrek te wijten is aan instructies of documenten die door de gebruiker zijn verstrekt, maar dat de leverancier geen garantieverantwoordelijkheid kan ontlopen als hij weet dat dergelijke documenten of instructies van de gebruiker ongeschikt zijn en dit niet aangeeft.

Voor meer informatie over wanneer een gebrek wordt erkend en wat de specifieke verantwoordelijkheden zijn in het geval van erkenning, zie het volgende artikel.

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

Voorbereiding en overgangsondersteuning voor softwaregebruik

In de acceptatie- en implementatiefase van een systeem is het gebruikelijk dat de gebruiker de leiding neemt. In het modelcontract van het Japanse Ministerie van Economie, Handel en Industrie (METI) is dit vastgelegd als een quasi-delegatievorm waarbij de gebruiker de hoofdrol speelt en de leverancier ondersteuning biedt.

Bepaling van de aard van het contract

Om de aard van een contract te bepalen, wordt er gekeken naar het geheel van het contract en het doel ervan. Is het doel om een ‘voltooid product te leveren’, of is het doel dat de leverancier ‘redelijk zijn taken uitvoert’? Een belangrijke indicatie is of de inhoud van het te voltooien product tot op zekere hoogte concreet is vastgesteld en of het project in die richting is voortgezet. Voor meer details over welke aspecten specifiek in overweging worden genomen, zie het volgende artikel.