De relatie tussen vertraging in de oplevering van systeemontwikkeling en wettelijke vertraging in de uitvoering

Een project zoals systeemontwikkeling is in zekere zin altijd een strijd tegen de deadline. Vanuit een juridisch perspectief kan men de ‘risico’s die zich voordoen als de deadline niet wordt gehaald’ in systeemontwikkeling overwegen.

In dit artikel zullen we uitleggen wanneer dergelijke ‘vertragingen in de deadline’ worden behandeld als vertraging in de uitvoering en wanneer ze juridische verantwoordelijkheden zoals contractbreuk veroorzaken.

Wat is de leveringsdatum bij systeemontwikkeling?

De leveringsdatum in algemene termen

In algemene zin verwijst de ‘leveringsdatum’ naar de deadline voor het leveren van een product dat door de klant is gevraagd. Zelfs in de ontwikkelingsomgeving, waar onverwachte problemen kunnen optreden, is het vaak noodzakelijk om strikt aan de leveringsdatum te houden. Als er een machtsverschil is tussen de opdrachtgever en de opdrachtnemer, is de neiging om de leveringsdatum strikt na te leven vaak nog duidelijker. Of, als de leveringsdatum wordt overschreden, kan er een korting worden gegeven op basis van het overschot, of kan het extra werk gratis worden gedaan. Hoe dan ook, de leveringsdatum wordt over het algemeen benadrukt om de vertrouwensrelatie met de klant te behouden.

We hebben ook een apart artikel dat het concept van ‘voltooiing van het werk’ en de leveringsdatum vanuit een juridisch perspectief uitlegt.

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

De leveringsdatum vanuit een juridisch perspectief

Vanuit een juridisch perspectief ontstaat er een verplichting (schuld) voor de leverancier om het systeem te leveren zodra er een contract is gesloten tussen de leverancier en de gebruiker. De leveringsdatum kan worden gezien als een beperking op het moment waarop deze schuld moet worden nagekomen. Met andere woorden, een vertraging in de leveringsdatum kan worden beschouwd als een vorm van wanprestatie, namelijk vertraging in de uitvoering. Dat wil zeggen, als de leveringsdatum wordt vertraagd door opzet of nalatigheid van de leverancier, zal deze aansprakelijk zijn voor wanprestatie door vertraging in de uitvoering (Artikel 412 van het Japanse Burgerlijk Wetboek).

1. Wanneer er een vaste termijn is voor de nakoming van een schuld, is de schuldenaar verantwoordelijk voor de vertraging vanaf het moment dat de termijn is verstreken.
2. Wanneer er een onzekere termijn is voor de nakoming van een schuld, is de schuldenaar verantwoordelijk voor de vertraging vanaf het moment dat hij weet dat de termijn is verstreken.
3. Wanneer er geen termijn is gesteld voor de nakoming van een schuld, is de schuldenaar verantwoordelijk voor de vertraging vanaf het moment dat hij wordt gevraagd om na te komen.

Artikel 412 van het Japanse Burgerlijk Wetboek

Wat in dit artikel wordt bedoeld met ‘verantwoordelijkheid nemen’ is in feite aansprakelijkheid voor schadevergoeding.

Wanneer de schuldenaar niet voldoet aan de hoofdverplichting van zijn schuld, kan de schuldeiser schadevergoeding eisen voor de schade die hierdoor is ontstaan. Hetzelfde geldt wanneer de schuldenaar niet in staat is om na te komen door een reden die aan hem te wijten is.

Artikel 415 van het Japanse Burgerlijk Wetboek

Bovendien, als de gebruiker de leverancier een ‘redelijke termijn’ geeft om te leveren en de leverancier niet levert binnen die termijn, kan de gebruiker het contract ook ontbinden.

Wanneer een van de partijen zijn schuld niet nakomt, kan de andere partij, na het geven van een redelijke termijn voor nakoming, het contract ontbinden als er binnen die termijn geen nakoming is.

Artikel 541 van het Japanse Burgerlijk Wetboek

Voor een algemene uitleg over de optie ‘ontbinding’ in dergelijke gevallen, zie het volgende artikel.

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

Niet alle leveringsvertragingen zijn wettelijk in gebreke

Het is echter niet zo dat het oppervlakkige feit van “niet op tijd geleverd” altijd betekent dat er sprake is van een verzuim in de uitvoering van een verplichting. Voor een eenvoudige leveringsvertraging om een wettelijke vertraging in de uitvoering te worden, moeten aan een aantal voorwaarden worden voldaan, zoals hieronder aangegeven.

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

Gezien het feit dat systeemontwikkeling normaal gesproken een project is waarbij zowel de gebruiker als de leverancier verplichtingen hebben, kan het zijn dat beide partijen in gebreke worden gesteld en dat de schadevergoeding wordt gecompenseerd.

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

Om verder op dit onderwerp in te gaan, is de “acceptatie” van de resultaten meestal iets dat vlak voor de leveringsdatum plaatsvindt. Over acceptatie wordt in detail gesproken in het volgende artikel. Hier wordt uitgelegd over gevallen waarin de levering niet wordt voltooid omdat de gebruiker niet meewerkt aan de acceptatie.

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

Het punt van het verhaal is dat “niet op tijd leveren = in gebreke blijven” niet zo eenvoudig is. Hoewel we het hebben over vertraging in de levering, kunnen de redenen variëren van de schuld van de leverancier tot de schuld van de gebruiker. Er is een groot verschil tussen het formele feit van “vertraging in de deadline” en de substantiële schending van de verplichting die “vertraging in de uitvoering” vormt.

Rechtszaken rondom vertraging in de uitvoering

Laten we eens kijken naar rechtszaken waarin werd betwist of het mogelijk was om aansprakelijkheid voor niet-nakoming van verplichtingen na te streven op basis van vertraging in de uitvoering, veroorzaakt door vertraging in de levering. Hoewel het een geschil is over de leveringstermijn, is het essentieel om de zaken te organiseren op basis van de fundamenten van systeemontwikkeling, zoals de “plicht tot samenwerking van de gebruiker” en de “plicht tot projectmanagement”. Dit verschilt niet van andere geschillen.

Voorbeeld van een geval waarin vertraging in de uitvoering werd gecompenseerd door schending van de samenwerkingsplicht en nalatigheid van de gebruiker

In het vonnis dat hieronder wordt geciteerd, heeft de gebruiker een rechtszaak aangespannen omdat de leveringstermijn van de leverancier was vertraagd. Deze claim werd gedeeltelijk geaccepteerd in de rechtbank, maar tegelijkertijd werd aangegeven dat het gebrek aan passende samenwerking van de gebruiker ook een factor was, en dat veertig procent van de schade veroorzaakt door de vertraging in de levering de verantwoordelijkheid van de gebruiker was.

Op basis van het bovenstaande kan worden gesteld dat de eisende gebruiker niet de juiste samenwerking heeft verleend, omdat hij geen tijdige en passende beslissingen heeft genomen, zoals het niet oplossen van hangende kwesties waarvoor de verweerder om een oplossing heeft gevraagd voor de streefdatum.
Echter, met betrekking tot de bewering van de verweerder over de schending van de samenwerkingsplicht van de eisende gebruiker met betrekking tot het toevoegen of wijzigen van functies, hoewel het een feit is dat de eisende gebruiker uiteindelijk een verzoek heeft gedaan dat leidde tot de toevoeging of wijziging van de ontwikkelingsinhoud die werd voorzien in het basisontwerpdocument van dit geval, kan dit niet worden beschouwd als een schending van de samenwerkingsplicht van de eisende gebruiker, en de bewering van de verweerder is ongegrond.
Ook met betrekking tot de bewering van de verweerder over de schending van de samenwerkingsplicht van de eisende gebruiker door overmatige eisen, kan niet worden erkend dat de eisende gebruiker overmatige eisen heeft gesteld in het licht van de vergoeding voor de opdracht voor de ontwikkeling van het computersysteem van dit geval, en er is geen reden.
Integendeel, het kan worden gezegd dat er ongepaste punten waren in het projectmanagement van de verweerder, zoals het feit dat de verweerder het aantal transacties (het aantal “transacties” op het moment van juli of augustus van hetzelfde jaar) pas na januari van het jaar Heisei 11 (1999) heeft begrepen, en dat hij na 31 mei van hetzelfde jaar een onredelijke extra vergoeding voor de opdracht en een vermindering van de transacties heeft voorgesteld.

Tokyo District Court, 10 maart Heisei 16 (2004)

Het bovenstaande vonnis erkende de vertraging in de uitvoering van de leverancier, maar stelde dat een deel van de oorzaak ook lag in het feit dat de gebruiker de zorgen die door de leverancier waren geuit niet had opgelost, en erkende de schade die de gebruiker had geclaimd door 60% te ‘knippen’. Dit is dezelfde behandeling als ‘nalatigheidscompensatie’ in gevallen zoals verkeersongevallen waarbij ook de slachtoffers schuld hebben.

In dit vonnis verschijnt de term ‘samenwerkingsplicht’ meer dan 40 keer in de volledige tekst, inclusief de inhoudsopgave. Vanuit een juridisch oogpunt kan men zeggen dat de essentie eerder de scheiding was tussen de projectmanagementplicht van de leverancier en de samenwerkingsplicht van de gebruiker.

Rechtszaak waarin volledige vertraging in de uitvoering werd erkend

Wat we hieronder citeren is het vonnis van een zaak waarin de verantwoordelijkheid van de leverancier volledig werd bewezen met betrekking tot de vertraging in de levering, en de niet-nakoming van de verplichting als gevolg van vertraging in de uitvoering werd erkend. In dit geval werd de overeenkomst door de gebruiker ontbonden vlak voor de voltooiing van het systeem, wat leidde tot een rechtszaak door de leverancier, maar de gebruiker betwistte dat de vertraging in de levering de oorzaak was.

Het kan niet worden ontkend dat de verweerder verschillende wijzigingen heeft aangebracht in het ontwerpsysteem, waardoor de voltooiing enigszins is vertraagd. In het bijzonder heeft de verweerder op 23 juni 2005 (Heisei 17) een definitieve wijzigingsinstructie gegeven, dus het feit dat de functie van “automatische berekening van details van stoepranden” op basis van deze instructie niet is voltooid, kan niet worden toegeschreven aan de eiser.
Echter, de andere wijzigingsinstructies van de verweerder werden gegeven tot begin april van hetzelfde jaar, en er is geen reden om te geloven dat de planning voor de voltooiing van het ontwerpsysteem is gewijzigd (met uitzondering van het deel dat te wijten is aan de wijzigingsinstructie van de verweerder op 23 juni van hetzelfde jaar).
Het kan niet worden erkend dat de eiser aan het einde van juni 2005, met uitzondering van het deel dat te wijten is aan de wijzigingsinstructie van 23 juni van dezelfde maand, het ontwerpsysteem had voltooid tot een niveau waarop het daadwerkelijk operationeel kon zijn, en het wordt erkend dat belangrijke delen van het systeem, zoals het onvermogen om afbeeldingen weer te geven of de zoekfunctie niet werkt, onvoltooid waren.
(Omissie) Het kan worden afgeleid dat de eiser niet voldoende heeft gezorgd voor het beheer van de werkprocedures in verband met de systeemontwikkeling.
Daarom kan niet worden erkend dat de belangrijkste reden waarom de eiser de leveringsdatum niet kon naleven, te wijten was aan de instructies van de verweerder, en het kan niet worden erkend dat er geen reden is om de eiser de schuld te geven.

Tokyo District Court, 16 februari 2007 (Heisei 19)

In dit vonnis werd aangegeven dat het feit dat de functie onvoltooid was, zoals het feit dat er een instructie voor specificatiewijziging was gegeven ongeveer een week voor de leveringsdatum, niet kon worden toegeschreven aan de leverancier. Echter, rekening houdend met:

• Het feit dat er nog steeds niet is gereageerd op wijzigingsinstructies die enkele maanden geleden zijn gegeven
• Het feit dat er na de bovengenoemde instructies e-mails zijn verzonden door de leverancier met de verwachte voltooiingsdatum
• Het feit dat de onvoltooide delen belangrijke delen van het systeem zijn, zoals de implementatie van beeldweergave en zoekfuncties, en het feit dat hier niet aan is voldaan, ondersteunt de schending van de projectmanagementverplichting

werd de niet-nakoming van de verplichting op basis van vertraging in de uitvoering erkend.

Wat we kunnen leren van beide uitspraken

Op basis van beide uitspraken kunnen we stellen dat het probleem van ‘deadlines’ in systeemontwikkeling uiteindelijk neerkomt op de vraag hoe de grens te trekken tussen de samenwerkingsplicht van de gebruiker en de projectmanagementplicht van de leverancier. Met andere woorden, juridische vertraging in de uitvoering wordt een punt van discussie, aangezien het een vorm van contractbreuk is, of er al dan niet een schending van de plicht aan de kant van de leverancier is geweest. En om te beoordelen of de schade die als resultaat is ontstaan (d.w.z. het verlies aan de kant van de gebruiker als gevolg van de vertraging in de levering) kan worden toegeschreven aan de leverancier, is het ook noodzakelijk om te kijken hoe de samenwerkingsplicht van de gebruiker wordt geïnterpreteerd.

Samenvatting

De term “vertraging in de uitvoering” kan op het eerste gezicht lijken op een andere manier om te zeggen “vertraging in de levering”, gezien de betekenis van de woorden. Echter, vertraging in de uitvoering is een vorm van contractbreuk. Daarom is het juister om het te begrijpen als een “schending van de projectmanagementverplichting”.

Bij problemen met de “leveringstermijn” in systeemontwikkelingsprojecten, is het belangrijk om niet alleen te focussen op de oppervlakkige timing van de levering, maar om het te herformuleren als een kwestie van de projectmanagementverplichting van de leverancier en de medewerkingsplicht van de gebruiker.