Wat te doen als er een systeemfout wordt ontdekt na acceptatie?

In algemene termen gaat systeemontwikkeling als volgt: de implementatie van het programma wordt uitgevoerd volgens de inhoud die is bepaald in de vereisten definitiefase, en uiteindelijk wordt gecontroleerd of het resultaat overeenkomt met de specificaties, zowel door de gebruiker als de leverancier. Het project wordt afgerond met de goedkeuring van de acceptatietest.

Maar in de praktijk kunnen er bugs of problemen optreden die niet ontdekt konden worden tijdens de testfase of bij de goedkeuring van de acceptatietest, zoals tijdens de latere operationele fase. Als u eenmaal een levering heeft geaccepteerd, wat kunt u dan wettelijk gezien vragen?

Het is niet verrassend dat er bugs achterblijven na acceptatietests of testprocessen

Vanuit een technisch oogpunt is het niet ongewoon dat er na de voltooiing van verschillende testprocessen aan de kant van de leverancier en na de acceptatie door de gebruiker, verschillende bugs en defecten aan het licht komen. Wat de gebruiker normaal gesproken doet tijdens het acceptatieproces, is voornamelijk het controleren van de invoer en uitvoer die vanaf het scherm kan worden bevestigd. Echter, IT-systemen hebben vaak een complexe en gedetailleerde structuur in de achterliggende database en in de delen van het programma die verantwoordelijk zijn voor verschillende berekeningen en controles, meer dan wat kan worden bevestigd vanaf het scherm door de gebruiker. Daarom zijn er vanaf het begin beperkingen aan wat kan worden onderzocht vanuit de controle van de invoer en uitvoer op het scherm vanuit het perspectief van de gebruiker. Daarom is het niet realistisch om tijdens de controle alle mogelijke defecten die kunnen optreden in de latere operationele fase uitputtend te verifiëren.

De bovenstaande omstandigheden gelden ook vanuit het perspectief van de leverancier die verantwoordelijk is voor de ontwikkelingswerkzaamheden. Bijvoorbeeld, het controleren of er bugs of defecten zijn in de inhoud van het geïmplementeerde programma is het “testproces”. Maar zelfs in het testproces, is het niet noodzakelijkerwijs mogelijk om alle mogelijke bugs en defecten uitputtend te verifiëren. Zelfs nadat het ontwikkelde systeem volledig operationeel is geworden, vereist het maken van een systeem dat nog steeds zonder problemen blijft werken, zelfs als er operaties worden uitgevoerd die de leverancier niet had verwacht, of als er daadwerkelijk een grote hoeveelheid gegevens wordt geregistreerd, of als meerdere gebruikers tegelijkertijd toegang krijgen, in wezen uitstekende technische vaardigheden.

Het is belangrijk om te begrijpen dat het niet realistisch is om alle mogelijke bugs en defecten te ontdekken tijdens fasen zoals acceptatie en testen, en dat er verschillende problemen aan het licht kunnen komen nadat men daadwerkelijk begonnen is met het gebruik van IT-systemen.

De schuld wordt normaal gesproken als voldaan beschouwd

Maar hoe moet je omgaan met dergelijke problemen als ze daadwerkelijk aan het licht komen? We zullen dit in juridische volgorde uitleggen.

Eerst en vooral, als er achteraf verschillende bugs of problemen aan het licht komen, zou de gebruiker de leverancier, aan wie hij tot nu toe het werk heeft toevertrouwd, verantwoordelijk willen stellen. Maar normaal gesproken, als de levering al is voltooid en de acceptatie is geslaagd, is het vaak moeilijk om de verantwoordelijkheid op basis van niet-nakoming van de schuld na te streven.

In de eerste plaats, tenzij er een speciale regeling is getroffen, gelden de bepalingen van het Japanse Burgerlijk Wetboek over contracten voor de implementatie van programma’s in systeemontwikkeling. Wat een contract is, wordt in detail uitgelegd in het volgende artikel.

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

En in een contract is “voltooiing van het werk” de vereiste voor de uitvoering van de schuld. Wat “voltooiing van het werk” concreet betekent, wordt in detail uitgelegd in het volgende artikel.

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

Hier leggen we uit dat “voltooiing van het werk” in een contract, in de context van systeemontwikkeling, betekent dat het hele ontwikkelingsproces is voltooid. En we leggen uit dat problemen zoals bugs en defecten na het einde van het hele ontwikkelingsproces een kwestie van garantie van gebreken in het contract zijn.

Samengevat, als de levering eenmaal is geaccepteerd en de acceptatie is voltooid, wordt ervan uitgegaan dat de schuld al is voldaan, en de vraag of de garantie van gebreken kan worden nagestreefd, dat wil zeggen de kwestie van de garantie van gebreken, is normaal gesproken het probleem.

De weg naar aansprakelijkheidsvervolging op basis van garantie voor gebreken

Dus, als u de leverancier wilt vragen om actie te ondernemen op basis van de garantie voor gebreken, wat moet u dan in welke volgorde overwegen? Laten we het hieronder bekijken.

Controleer eerst de ernst en de ernst van bugs en storingen

Als bugs en storingen achteraf aan het licht komen en u om een soort garantie vraagt omdat ze juridisch gezien ‘gebreken’ zijn, dan wordt de ernst van de bugs en storingen een probleem. Juridische kwesties met betrekking tot gebreken zijn in de eerste plaats

1. Zelfs als het een bug of storing is, is het slechts een klein probleem en kan het niet als een juridisch ‘gebrek’ worden beschouwd
2. Het komt overeen met een juridisch ‘gebrek’, maar het is nog steeds mogelijk om het doel van het contract te bereiken
3. Het komt overeen met een juridisch ‘gebrek’ en het is ook onmogelijk om het doel van het contract te bereiken

Er zijn drie patronen. Wat bepaalt of aansprakelijkheidsvervolging op basis van garantie voor gebreken mogelijk is, is de grens tussen 1 en 2, en wat bepaalt of het mogelijk is om het contract te ontbinden op basis van garantie voor gebreken, is de grens tussen 2 en 3.

Artikel 634

1. Als er een gebrek is in het doel van het werk, kan de opdrachtgever de aannemer vragen om het gebrek te herstellen binnen een redelijke termijn. Dit geldt echter niet als het gebrek niet significant is en het herstel ervan buitensporige kosten met zich meebrengt.

2. De opdrachtgever kan in plaats van of naast het herstel van het gebrek, een verzoek om schadevergoeding indienen. In dit geval is artikel 533 van toepassing

Artikel 635

Als er een gebrek is in het doel van het werk en het daardoor onmogelijk is om het doel van het contract te bereiken, kan de opdrachtgever het contract ontbinden. Dit geldt echter niet voor gebouwen of andere bouwwerken op het land.

Overigens, voor een gedetailleerde uitleg over deze graduele onderscheiding van ‘gebreken’, zie het volgende artikel.

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

Maak vervolgens duidelijk wat u van de leverancier moet eisen

Daarnaast moet u duidelijk maken wat u van de andere partij eist. Als u het contract wilt ontbinden, is het niet voldoende om alleen te bewijzen dat het een gebrek is, het moet ook ‘onmogelijk zijn om het doel van het contract te bereiken’. Bij het beoordelen van het ‘doel’ hier, zijn de notulen van de vergaderingen die aan het begin van het systeemontwikkelingsproject zijn gehouden en de inhoud van de specificaties belangrijke aanwijzingen. Omdat er situaties kunnen zijn waarin bugs en storingen achteraf aan het licht komen, zelfs na de acceptatie, moet u ervoor zorgen dat u alle documenten bewaart, zelfs na het einde van het ontwikkelingsproject.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Naast ontbinding, zijn er andere dingen die u kunt vragen op basis van de inhoud van de garantie voor gebreken, zoals een verzoek om schadevergoeding of een verzoek om herstel van gebreken.

Overige aandachtspunten

Wees voorzichtig met de manier waarop je juridische handelingen uitvoert, zoals het beëindigen van contracten

Als je van plan bent om een contract te beëindigen als onderdeel van de garantie voor gebreken, is het belangrijk om ook kennis te hebben van de manier waarop je juridische procedures moet uitvoeren om de beëindiging te bewerkstelligen. We hebben gedetailleerde uitleg gegeven over de effecten van contractbeëindiging, hoe je effectieve intentieverklaringen kunt doen en hoe je meldingen kunt doen om toekomstige problemen te voorkomen in het volgende artikel.

https://monolith.law/corporate/cancellation-of-contracts-in-system-development[ja]

Het is beter om conflicten op te lossen door middel van onderhandelingen in plaats van geschillen

Deze reeks juridische argumenten is niet alleen van belang als er een rechtszaak plaatsvindt. Geschillenbeslechting door middel van rechtszaken kan een grote last zijn voor beide partijen. In plaats daarvan is het belangrijk om deze kennis te gebruiken in de onderhandelingsfase voorafgaand aan een rechtszaak. We hebben uitgelegd hoe belangrijk deze juridische inzichten kunnen zijn in onderhandelingen buiten de rechtbank in het volgende artikel.

https://monolith.law/corporate/disputes-related-to-system-development[ja]

Je moet onderscheid maken tussen bugs en defecten, en het ontbreken van functies

De discussie zal verschillen afhankelijk van of er bugs of defecten zijn in de geïmplementeerde functies en specificaties, of dat de benodigde functies in de eerste plaats ontbreken. Als de benodigde functies niet aanwezig zijn, kan het zijn dat de “voltooiing van het werk” in het contract voor het werk niet wordt erkend, en dat de uitvoering van de verplichting niet wordt erkend.

Zelfs als de benodigde functies en specificaties niet aanwezig zijn, als het resultaat is dat de gebruiker niet de juiste informatie heeft verstrekt in de fase van de eisen specificatie, kan het ongepast zijn om dit als een deel van de contractinhoud te beschouwen.

Samenvatting

Problemen die zich voordoen tijdens de fasen van een project kunnen zowel tijdens de voortgang van het project aan het licht komen als achteraf, bijvoorbeeld tijdens de operationele fase. Het kenmerk van IT-systeemontwikkelingsprojecten dat je niet noodzakelijk op je gemak kunt zijn, zelfs als alle fasen succesvol zijn afgerond, lijkt te worden gesymboliseerd door het systeem van ‘garantie voor gebreken’. Het wordt als belangrijk beschouwd om een grondig documentbeheer te implementeren met het oog op de periode na de voltooiing van het IT-systeemontwikkelingsproject, en om een goed begrip te hebben van deze opeenvolgende stroom van gebeurtenissen.