Wat te doen als systeemontwikkelingswerk wordt onderbroken vanwege gebruikersomstandigheden?

Werkzaamheden zoals systeemontwikkeling nemen vaak de vorm aan van langdurige projecten. Maar wat als de gebruiker eenzijdig zegt: “We hebben dat systeem niet meer nodig, dus je hoeft het niet te maken”, nadat je al begonnen bent met de ontwikkeling van het systeem? Wat kan de leverancier, die de opdracht heeft aangenomen, dan doen?

In dit artikel zullen we de kenmerken van een contract voor systeemontwikkeling uiteenzetten en uitleggen welke maatregelen er in zo’n geval genomen kunnen worden.

Het belang van nadenken over onderbrekingen door gebruikersomstandigheden

Er zijn enkele kenmerkende aspecten als we kijken naar een contract voor systeemontwikkeling. Een daarvan is dat de looptijd van het project meestal lang is en dat de leverancier, als onderdeel van zijn projectmanagementverplichtingen, een grote mate van discretie en aanzienlijke verplichtingen heeft. Een uitgebreide uitleg over de algemene inhoud van de projectmanagementverplichtingen die de leverancier heeft, is te vinden in het volgende artikel.

https://monolith.law/corporate/project-management-duties[ja]

Een ander aspect is dat de gebruiker, hoewel hij een klant is, een brede verplichting heeft om mee te werken aan de taken van de leverancier. Omdat het een systeem is dat intern wordt gebruikt, kan het niet gewoon worden ‘overgelaten’ aan de leverancier. Er is een verplichting om van binnenuit de organisatie passende medewerking te verlenen, zodat de leverancier zijn expertise kan inzetten en zijn taken kan uitvoeren. Een gedetailleerde uitleg hierover is te vinden in het volgende artikel.

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

Als we de bovenstaande inhoud kort samenvatten, is er tussen de leverancier en de gebruiker een relatie van ‘externe dienstverlener’ die het systeem ontwikkelt en ‘klant’ die de vergoeding betaalt, maar tegelijkertijd is er ook een aspect van ‘partners’ die samen moeten werken om het gemeenschappelijke doel van het project te bereiken. Deze complexiteit van relaties is meestal niet aanwezig bij bijvoorbeeld een kleermaker die een op maat gemaakt pak maakt, en is een groot kenmerk van contracten rond systeemontwikkeling. Geschillen rond systeemontwikkeling zijn vanwege deze complexiteit van relaties vaak ingewikkeld en moeilijk op te lossen als ze eenmaal verstrikt zijn geraakt.

Het is belangrijk om na te denken over hoe de rechten en plichten van beide partijen moeten worden begrepen als de gebruiker van gedachten verandert en plotseling zegt: “We hebben dat systeem uiteindelijk niet nodig, dus je hoeft het project niet verder te ontwikkelen”. Dit biedt een voorbeeld van juridisch denken in het licht van deze complexe contractuele relaties. Hieronder zullen we de zaken die overwogen moeten worden in zo’n situatie verder uitwerken.

Eerst de reden voor de opzegging ordenen

Vanuit het perspectief van de leverancier kan het lijken alsof “de gebruiker eenzijdig het project wil stopzetten”, maar dit begrip wordt niet noodzakelijkerwijs gedeeld met de gebruiker. Als voorbeeld, stel je een project voor dat is opgezet om een systeem te ontwikkelen voor het beheren van personeelszaken voor medewerkers die in buitenlandse vestigingen werken. Later wordt het plan voor de buitenlandse expansie zelf ingetrokken, waardoor de ontwikkeling van het systeem overbodig wordt. Inderdaad, op basis van deze uitleg alleen, zou je kunnen concluderen dat het een eenzijdige verandering van gedachten is van de kant van de gebruiker.

Echter, wat als er, in de aanloop naar deze beslissing, feitelijke schendingen van de projectmanagementverplichtingen waren aan de kant van de leverancier, zoals vertragingen in verschillende stadia, en de moeilijkheden in de voortgang van de ontwikkeling zelf ook een factor waren in de verandering van bedrijfsbeleid?

Zoals eerder vermeld, is systeemontwikkeling iets waarbij zowel de leverancier als de gebruiker grote verantwoordelijkheden op zich nemen en nauw samenwerken. Daarom, zelfs als de gebruiker degene is die wil stoppen en de leverancier denkt dat het een opzegging is om persoonlijke redenen, moet de leverancier zich ervan bewust zijn dat er een kans is dat ze worden tegengesproken met argumenten zoals het aanwijzen van redenen voor de leverancier om de schuld op zich te nemen, en beweringen dat het een beëindiging of een wederzijdse opzegging is op basis van contractbreuk.

Of het nu een opzegging is om persoonlijke redenen, een beëindiging op basis van contractbreuk, of een wederzijdse opzegging, het onderscheid tussen deze punten wordt vaak individueel beoordeeld per geval, afhankelijk van de voortgang van het project en de geschiedenis van de onderhandelingen. Daarom, als de leverancier doorgaat met de afhandeling na de opzegging, ervan uitgaande dat het een opzegging is om persoonlijke redenen van de gebruiker, is het belangrijk om duidelijke verslagen te bewaren, zoals notulen van vergaderingen, om ervoor te zorgen dat er later geen geschillen ontstaan over dit punt.

Controleer vervolgens de wettelijke basis voor vergoeding en schadevergoeding

Met inachtneming van het bovenstaande, als het gesprek kan worden voortgezet als een annulering door de gebruiker om persoonlijke redenen, wordt vervolgens overwogen of de leverancier de gebruiker een vergoeding kan vragen op basis van het voltooiingspercentage, of een schadevergoeding kan vragen.

De clausules die in dergelijke gevallen moeten worden geraadpleegd, verschillen afhankelijk van het type contract. Dit komt omdat contracten met betrekking tot systeemontwikkeling grofweg kunnen worden onderscheiden in contracten voor werk en quasi-mandaatcontracten.

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

En in het geval van quasi-mandaatcontracten en contracten voor werk, stelt het Burgerlijk Wetboek (Japanse Burgerlijk Wetboek) de volgende bepalingen:

a.) In het geval van een quasi-mandaatcontract
Vergoedingseis: Artikel 648, lid 3, van het Burgerlijk Wetboek
Als de uitvoering halverwege wordt beëindigd door een oorzaak die niet aan de gedelegeerde kan worden toegeschreven, kan de gedelegeerde een vergoeding vragen in verhouding tot het percentage van de uitvoering dat al is voltooid.
Schadevergoedingseis: Artikel 651 van het Burgerlijk Wetboek
1. Het mandaat kan te allen tijde door elke partij worden beëindigd.
2. Als een van de partijen het mandaat beëindigt op een moment dat nadelig is voor de andere partij, moet die partij de schade van de andere partij vergoeden. Dit geldt echter niet als er een onvermijdelijke reden is.

b.) In het geval van een contract voor werk
Schadevergoedingseis: Artikel 641 van het Burgerlijk Wetboek
Zolang de aannemer het werk niet heeft voltooid, kan de opdrachtgever te allen tijde het contract beëindigen door de schade te vergoeden.

Overigens wordt aangenomen dat het bereik van de schadevergoeding op basis van artikel 641 van het Burgerlijk Wetboek niet alleen de reeds gemaakte kosten omvat, maar ook de “winst die zou zijn behaald als het contract niet was beëindigd”. Dit komt omdat het zinloos is voor de wet om de voltooiing van het werk te eisen, zelfs als het niet langer nodig is vanuit het oogpunt van de opdrachtgever. In dergelijke gevallen is het rationeler om de winst van de aannemer te garanderen door het betalen van een gelijkwaardige vergoeding.

Let echter op dat in individuele contracten tussen de leverancier en de gebruiker, schadevergoeding op basis van artikel 641 van het Burgerlijk Wetboek vaak wordt uitgesloten. In dergelijke gevallen prevaleert de individuele overeenkomst tussen de partijen (= het contract) en is het mogelijk dat de bepalingen van het Burgerlijk Wetboek niet van toepassing zijn, dus wees voorzichtig.

Verdere bewijsvoering van volume en schade

In het geval van een annulering door de gebruiker om persoonlijke redenen, is het gebruikelijk in contracten dat er een claim kan worden ingediend voor de vergoeding van het volume (oftewel het voltooide deel) en voor schadevergoeding. Daarom is het meestal noodzakelijk voor de leverancier om bewijs te leveren van het volume en de schade om een claim voor schadevergoeding in te dienen.

Echter, het bewijzen van dit volume, oftewel het percentage van voltooiing, kan een zeer moeilijke taak zijn als het daadwerkelijk wordt uitgevoerd. Dit komt omdat het houden van interviews om de voortgang te controleren, vooral als er meerdere onderaannemers zijn, kan leiden tot een aanzienlijke hoeveelheid werk. Bovendien, als je ook documenten moet maken om de resultaten van deze interviews te ondersteunen, en de inhoud van de interviews zelf moet documenteren, kan de hoeveelheid werk enorm zijn. Er zijn ook veel problemen, zoals het risico dat je uiteindelijk te horen krijgt dat je bewijs onvoldoende is, waardoor al het werk dat je in de voorbereiding van je bewijs hebt gestoken, tevergeefs kan zijn.

Gezien deze punten, kunnen maatregelen worden overwogen zoals het vanaf het begin van het contractstadium duidelijk vermelden dat in het geval van een tussentijdse annulering, de berekening zal worden gedaan op een pro-rata basis op basis van het aantal dagen tot het moment van annulering, om de berekening eenvoudig te houden. Daarnaast, gezien de moeite die het kost om bewijs te leveren voor het volume, kan men overwegen om af te zien van claims op het volume zelf en in plaats daarvan claims in te dienen voor de “kosten die al zijn gemaakt voor de ontwikkeling van het voltooide deel”. Dit is vaak een realistische remedie, vooral als de ontwikkelingskosten intern zijn, omdat ze gemakkelijk kunnen worden berekend met een eenvoudige formule van “arbeidsuren x tarief”. Vooral bij projecten met een lage winstmarge kan het prioriteren van claims op basis van kosten in plaats van volume, terwijl de gemakkelijke inning van vorderingen wordt benadrukt, leiden tot een verwachte compensatie voor verliezen, waardoor het een meer realistische remedie wordt.

Wat moet er vanuit de gebruikerskant worden overwogen?

Overigens zijn er ook punten die de gebruiker, die op eigen initiatief wil opzeggen, van tevoren moet overwegen. Dit is het controleren van een geschat bedrag, zoals hoeveel de te betalen schadevergoeding ongeveer zal zijn tussen de gebruiker en de leverancier. Het woord “geschat” wordt hier gebruikt om een algemene richtlijn te geven voor de stroom van onderhandelingen die volgen. Het is voldoende als het geen exact bedrag is, omdat het uitdrukken van de intentie om te annuleren op zichzelf zou worden vertraagd, wat een omkering van doel en middelen zou zijn.

Als het gecontroleerde geschatte bedrag onredelijk hoog lijkt, moet u om een uitleg vragen. Echter, als u probeert te onderhandelen op een onredelijke manier om het betalingsbedrag te verlagen, kan dit leiden tot zinloze rechtszaken en andere complicaties. Als onderhandelingen tussen de twee partijen moeilijk lijken, kan het raadzaam zijn om een advocaat te raadplegen.

In dit artikel hebben we uitgelegd op basis van de veronderstelling dat er een contract is gesloten met betrekking tot systeemontwikkeling. In de realiteit van systeemontwikkeling is er echter vaak een geschil over de vraag of er überhaupt een geldig contract is gesloten. We hebben dit in detail uitgelegd in het onderstaande artikel.

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

Samenvatting

In dit artikel hebben we de stappen besproken voor het omgaan met gevallen waarin een project wordt onderbroken vanwege de omstandigheden van de gebruiker. Echter, het belangrijkste punt van dit artikel is de noodzaak om te overwegen of het echt kan worden gezegd dat het te wijten is aan de omstandigheden van de gebruiker, en of er echt geen fouten waren aan de kant van de leverancier.

Het kenmerk van een systeemontwikkelingsproject is dat zowel de leverancier als de gebruiker grote verantwoordelijkheden op zich nemen. Daarom is het belangrijk om vooraf goed te overwegen of het echt mogelijk is om de verantwoordelijkheid eenzijdig bij de andere partij te leggen. Als dit niet wordt gedaan, kan dit leiden tot een situatie waarin olie op het vuur wordt gegooid, en dit moet in gedachten worden gehouden.