Wat zijn de ondersteuningsverplichtingen van de leverancier na de voltooiing van systeemontwikkeling?

Het is algemeen bekend dat in systeemontwikkeling, de gespecialiseerde systeemontwikkelingsleverancier, oftewel de ‘vendor’, een ‘Projectmanagementverplichting’ heeft. Echter, er is een vergelijkbaar maar verschillend concept in de wet, namelijk de ‘Ondersteuningsverplichting’. In dit artikel zullen we de ‘Ondersteuningsverplichting’ bespreken, rekening houdend met eerdere rechtszaken en dergelijke.

Wat is de verplichting tot ondersteuning?

Overzicht van de verplichting tot ondersteuning

In het gesprek over de verplichtingen die een leverancier aan een gebruiker heeft, is de projectmanagementverplichting een van de meest voorkomende. Dit is een concept dat is gevestigd door herhaalde verwijzingen in eerdere rechtszaken, en het omvat de verplichtingen die de leverancier, als expert in systeemontwikkeling, heeft ten opzichte van een reeks projecten.

De projectmanagementverplichting is een zeer bekende juridische term in systeemontwikkeling, en er is geen twijfel dat het een van de belangrijkste verplichtingen is die de leverancier op zich neemt. Echter, sommige rechtszaken erkennen het bestaan van een ‘ondersteuningsverplichting’, een verplichting die verschilt van de projectmanagementverplichting.

De ondersteuningsverplichting wordt een probleem bij operationele ondersteuning voor gebruikers

Wat is dan de ondersteuningsverplichting? En waarom wordt het met een andere naam genoemd dan de projectmanagementverplichting? De ondersteuningsverplichting wordt meestal een probleem na de voltooiing van de systeemontwikkeling. Een systeemontwikkelingsproject eindigt in principe wanneer het te ontwikkelen systeem is voltooid, omdat het project ‘ontwikkeling’ is. Dat wil zeggen, het begint met het verduidelijken van wat het te maken systeem moet zijn (= eisen specificatie) en eindigt met de bevestiging of het daadwerkelijk is voltooid (= testen of acceptatie). Dit is wat een systeemontwikkelingsproject is. Over de acceptatiefase, die een belangrijke betekenis heeft als ‘het einde van het systeemontwikkelingsproject’, worden de juridische problemen die vaak op dit punt ontstaan, in detail behandeld in het volgende artikel.

Echter, zelfs als we aannemen dat een systeemontwikkelingsproject de ontwikkelingsfase zelf is waarin een nieuw systeem wordt gemaakt, is het vanzelfsprekend dat het ontwikkelde systeem daarna in de bedrijfsvoering zal worden gebruikt. Met andere woorden, het zou onredelijk zijn om te zeggen dat “zolang we alleen de ontwikkelingswerkzaamheden op ons nemen, we alleen maar hoeven te maken” zonder enige vraag over hoe het systeem na de ontwikkeling zal worden gebruikt. Met dit in gedachten, is in eerdere rechtszaken de vraag gerezen of het mogelijk is om een bepaalde operationele ondersteuningsverplichting op te leggen aan de leverancier die verantwoordelijk is voor de systeemontwikkeling. Dat wil zeggen, de vraag is of we moeten denken dat de verplichtingen die de leverancier heeft in een systeemontwikkelingsovereenkomst ook de verplichtingen met betrekking tot operationele ondersteuning na de ontwikkeling omvatten. Omdat operationele ondersteuning geen deel uitmaakt van het ontwikkelingsproces zelf, wordt aangenomen dat de term ‘ondersteuningsverplichting’ is gebruikt om het te onderscheiden van de projectmanagementverplichting.

Wat zijn de rechtszaken waarbij de ondersteuningsplicht een probleem werd?

Een geval waarbij de bedrijfsvoering van de gebruiker werd belemmerd tijdens de systeemtestfase

In het vonnis dat hieronder wordt geciteerd, kon de gebruiker het systeem niet gebruiken zoals oorspronkelijk gepland tijdens de systeemtest die werd uitgevoerd voorafgaand aan de werking van het systeem, met als resultaat dat de gebruiker de werking van het systeem zelf opgaf. Dit was een probleem bij de start van de operatie door de gebruiker, en de vraag was hoe de verantwoordelijkheid van de leverancier kon worden gerechtvaardigd op basis van het vooraf gesloten contract voor systeemontwikkeling. De conclusie was dat de schadevergoedingsclaim van de gebruiker werd erkend, en de “schending van de ondersteuningsplicht” werd aangehaald als de basis daarvoor.

I Schending van de ondersteuningsplicht
(A) De vertegenwoordiger van de eiser heeft op 14 juli 1997 (Heisei 9) aan de gedaagde verzocht “Niet alleen het systeem maken, maar ook zorgen dat het goed werkt tot het einde.“, “We zijn amateurs, dus we betalen veel geld, dus we willen dat het tot het einde werkt.“. In reactie hierop legde de gedaagde uit dat het mogelijk was om een systeem te bouwen dat het doel van de eiser kon bereiken, en beloofde te ondersteunen tot het goed werkte. Hierdoor werd er tussen de eiser en de gedaagde een overeenkomst gesloten dat de gedaagde zou ondersteunen tot de eiser het systeem goed kon gebruiken.
Het is duidelijk dat de gedaagde een ondersteuningsplicht heeft jegens de eiser, omdat hij een bedrag van 1.726.000 yen heeft opgenomen als “pakketintroductieondersteuning” in de prijs van het contract, en in de offerte staat dat de maandelijkse onderhoudskosten “gratis onderhoud voor zes maanden na introductie” zijn, en in een document getiteld “Over toekomstige SE-ondersteuning (interne vergaderdocumenten)” is bevestigd dat SE-ondersteuning kan worden ontvangen voor “het maken van een introductieprocedure (plan)” en “data/operationele verificatiewerkzaamheden” met betrekking tot verse bestellingen.

(B) De ondersteuningsplicht die de gedaagde jegens de eiser heeft, is concreet, ten minste tot de eiser het systeem volledig in werking heeft, de gedaagde, jegens de eiser, ① het verstrekken van passend advies over de werking van het systeem, ② het reageren op problemen met het systeem die zich voordoen tijdens de operationele test, ③ het verbeteren van het systeem op basis van de resultaten van de operationele test, ④ het geven van introductietraining aan de operator.
Echter, de gedaagde, ondanks de vele problemen tijdens de operationele test, probeerde deze niet serieus aan te pakken, bewerend dat het een kwestie van bekwaamheid van de operator was, en vroeg alleen om de kosten van de introductietraining van de operator, en bood de eiser geen enkele passende ondersteuning voor de volledige werking.

Vonnis van de Hachioji-tak van de rechtbank van Tokio, 5 november 2003 (Heisei 15)

In dit vonnis verschijnt het woord “ondersteuning” ongeveer 30 keer in het hele vonnis, inclusief de inhoudsopgave. Het is duidelijk dat de stem van de gebruiker die om passende ondersteuning vraagt, direct in het vonnis is opgenomen, en dat de conclusie is bereikt na een zorgvuldige overweging van de omstandigheden van de zaak en met het oog op een eerlijke oplossing. Bijzondere aandachtspunten voor het begrijpen van deze zaak zijn:

• De schending van de ondersteuningsplicht wordt behandeld als “niet-nakoming van de verplichting”, en als gevolg daarvan werd schadevergoeding bevolen.
• De term “projectmanagementplicht” wordt niet eenmaal gebruikt in het hele vonnis.

Dit toont een houding aan die probeert het te behandelen als een contractuele verplichting die is opgenomen in het contract voor systeemontwikkeling, hoewel het een ander concept is dan projectmanagement.

Hoe moeten we de aard van de ondersteuningsplicht interpreteren?

De ondersteuningsplicht is nog geen duidelijk concept

Zoals eerder vermeld, suggereren de rechtszaken dat de leverancier die de systeemontwikkeling heeft uitgevoerd, ook de nodige ondersteuning moet bieden om de gebruiker te laten beginnen met de werking. Echter, de ondersteuningsplicht heeft niet zoveel precedenten als de projectmanagementplicht, en er zijn niet veel aanwijzingen om de werkelijkheid te kennen. Vooral het begrip “ondersteuning” zelf bevat het probleem dat het niet duidelijk is wat concreet moet worden gedaan.

De ondersteuningsplicht wordt niet onbeperkt erkend

Bovendien heeft het vonnis dat de schending van de ondersteuningsplicht door de leverancier erkende, ook een zeer belangrijk punt aangegeven.

De gedaagde wordt geacht op basis van het contract een bepaalde ondersteuning te bieden die nodig is voor de eiser om het systeem dat aan de eiser is geleverd en geïnstalleerd te bedienen. Echter, de inhoud daarvan wordt niet geacht te zijn zoals de eiser beweert, dat wil zeggen, het bieden van alle soorten ondersteuning gratis tot de eiser daadwerkelijk in staat is om het systeem te bedienen, ongeacht de periode.

Vonnis van de Hachioji-tak van de Tokyo District Court op 5 november 2003 (Heisei 15)

Als de belangrijkste taak die is aangenomen de “ontwikkeling” van het systeem is, dan is er ook een beperking op wat moet worden gedaan als ondersteuning voor de daaropvolgende “werking”. Dit vonnis wijst ook op verschillende kenmerken, zoals het citeren van de stem van de gebruiker die om ondersteuning vraagt in de tekst van het vonnis, verwijzend naar de inhoud van de voorafgaande schatting, en het aanraken van de aanwezigheid van een speciale overeenkomst om ondersteuning te bieden. Met andere woorden, gezien het feit dat als het concept van de ondersteuningsplicht onbeperkt wordt uitgebreid, het een grote last zal leggen op de leverancier, wordt aangenomen dat de erkenning van de plichtsschending zelf enigszins voorzichtig werd gedaan.

De inhoud van de ondersteuningsplicht moet worden overwogen in combinatie met de medewerkingsplicht van de gebruiker

Wat tot nu toe is besproken, kan ook worden gezegd dat het gaat om “hoe de gebruiker en de leverancier de werklast delen in de beginfase van de werking in systeemontwikkeling”. Daarin is zeker een enigszins ingewikkeld probleem opgenomen, namelijk hoeveel wettelijke verplichting de leverancier heeft om te beginnen met de werking vanuit het contract met betrekking tot “ontwikkeling”. Tegelijkertijd is het onvermijdelijk om te zeggen dat er een sterke neiging is om een oordeel te vragen op basis van individuele omstandigheden.

Echter, wat de inhoud van de ondersteuningsplicht die de leverancier draagt is, wordt gedacht dat het zekerder zal worden door het begrijpen van de medewerkingsplicht die de gebruiker draagt.

De inspanning om de bedrijfsvoering te verbeteren met een nieuw systeem is in de eerste plaats een gezamenlijke inspanning van de leverancier, die een technische expert is, en de gebruiker, die kennis heeft van de interne bedrijfsvoering. Daarom wordt gedacht dat er veel gevallen zijn waarin het bereik vanzelf wordt bepaald door duidelijk te maken wat de gebruiker moet oplossen met zelfhulpinspanningen als onderdeel van de “uitvoering van de medewerkingsplicht” met betrekking tot de zogenaamde ondersteuningsplicht.

Samenvatting

In dit artikel hebben we een overzicht gemaakt van de ‘ondersteuningsplicht’, die kan worden beschouwd als een afgeleide van de basisprincipes van projectmanagement. Hoewel er nog veel onduidelijkheden zijn over het concept van de ondersteuningsplicht, wordt aangenomen dat de basisprincipes zoals de ‘plicht tot projectmanagement’ en de ‘plicht tot samenwerking’ nog steeds belangrijk zijn voor het begrip ervan.