Wat zijn de samenwerkingsverplichtingen van de gebruikerskant die de opdrachtgever van systeemontwikkeling op zich neemt?

De taak van systeemontwikkeling vereist, naarmate het te ontwikkelen systeem groter wordt, de inzet van een groot aantal mensen en veel tijd. Daarom is er niet alleen een verplichting voor de leverancier die de ontwikkeling op zich neemt, maar ook voor de gebruiker die de systeemontwikkeling bestelt om een bepaalde mate van medewerking te verlenen.

Dit is anders dan de gebruikelijke bestel- en leveringsrelatie. Bijvoorbeeld, als je een op maat gemaakt pak bestelt bij een kleermaker in plaats van een IT-systeem, heeft de klant (gebruiker) die de bestelling plaatst geen specifieke ‘verplichting’. De ‘verplichting’ ligt voornamelijk bij de kleermaker (leverancier) die de bestelling aanneemt. Het is juist vanwege het IT-systeem, dat veel mankracht en tijd vereist, dat de gebruiker ook moet ‘samenwerken’ met de leverancier.

In dit artikel leggen we uit welke wettelijke verplichtingen er zijn voor de besteller in het geval van systeemontwikkeling, waarbij het niet voldoende is om het alleen aan de leverancier over te laten.

Als het gaat om uw eigen systeem, is het niet genoeg om alles ‘volledig uit handen te geven’

Zelfs in één systeemontwikkelingsproject zijn er vaak veel mensen en organisaties betrokken. Natuurlijk zijn er ingenieurs en programmeurs die bedreven zijn in coderingstechnieken, maar om de output van dergelijk personeel samen te brengen tot één resultaat, is de rol van de projectmanager ook belangrijk.

Maar hoe hoog de technische en organisatorische vaardigheden van de leverancier ook zijn, het systeemontwikkelingsproject kan niet alleen met de kracht van de leverancier worden voltooid. Bijvoorbeeld, er is geen manier voor de leverancier om alleen door eenrichtingsverkeer te weten te komen over bedrijfsspecifieke termen die alleen intern worden gebruikt, of bedrijfsspecifieke zakelijke kennis. Hoe groter de ontwikkeling van het systeem, hoe meer de algemene trend is dat het bedrijf dat het systeem gebruikt zelf ook een groot bedrijf is met veel mensen en taken. Om een systeemontwikkelingsproject succesvol te maken, is het in feite vaak zo dat het ordenen van deze bedrijfslogica een groot gewicht heeft, zelfs voordat er met de computer wordt gewerkt.

Daarom is het niet zo dat de gebruikerskant passief wordt omdat “ik ben geen IT-expert”, maar eerder dat het project soepel verloopt door actief informatie te verstrekken. In deze zin is de rol die de gebruikerskant speelt in een systeemontwikkelingsproject eigenlijk niet klein.

Wat is de verplichting tot samenwerking van de gebruiker, rekening houdend met jurisprudentie?

Wat zijn concreet de verplichtingen tot samenwerking die de gebruiker heeft in een systeemontwikkelingsproject? Er zijn veel aanwijzingen achtergelaten in eerdere jurisprudentie over dit punt.

In de rechtszaak was het punt van geschil of er een verplichting was voor de gebruiker (eiser) om samen te werken met de ontwikkeling, aangezien er vertragingen waren in de besluitvorming van de gebruiker, wat betreft de vertraging in de levering door de leverancier (verweerder). In deze zaak erkende de rechtbank de schending van de verplichting tot samenwerking door de gebruiker en ontkende de aansprakelijkheid voor niet-nakoming van de leverancier. (Hoewel de ontbinding van het contract werd erkend, werd ook een foutvermindering van 60% erkend.)

In dit contract voor de ontwikkeling van een computersysteem, een zogenaamd op maat gemaakt systeemontwikkelingscontract, kan het systeem niet worden voltooid door alleen de contractant (leverancier), en de opdrachtgever (gebruiker) moet tijdens het ontwikkelingsproces interne meningsverschillen nauwkeurig coördineren, een uniforme mening vormen, duidelijk aan de contractant communiceren welke functies hij wenst, samen met de contractant de gewenste functies onderzoeken, uiteindelijk de functies bepalen, verder het scherm en de formulieren bepalen, en de rol van het accepteren van de resultaten, enz. verdelen.

Tokyo District Court, 10 maart 2004 (Heisei 16)

Deze uitspraak is niet alleen indicatief dat systeemontwikkeling op zich een gezamenlijke inspanning is met de gebruiker, maar het lijkt ook zeer suggestief dat het specifiek verklaart “op welke punten we moeten samenwerken”.

Laten we proberen de bovenstaande uitspraak te vertalen naar IT-termen voor systeemontwikkeling.

Op deze manier kunnen we het organiseren. Dit zijn allemaal dingen die niet alleen kunnen worden gedaan, ongeacht hoe geavanceerd de expertise in IT-systemen is, zonder de medewerking van de gebruiker. De functies die worden gevraagd en hoe het schermontwerp eruit moet zien, moeten in principe door de gebruiker worden verduidelijkt, en alleen de gebruiker kan controleren of wat wordt gevraagd daadwerkelijk is gerealiseerd.

Overigens, net zoals de leverancier verplicht is tot projectmanagement, is de gebruiker ook verplicht tot samenwerking. Als de gebruiker in strijd handelt met deze verplichting tot samenwerking in het bovenstaande proces, kan de leverancier mogelijk een claim voor schadevergoeding indienen tegen de gebruiker op basis van niet-nakoming van de verplichting of onrechtmatige daad.

Hoe worden verzoeken om specificatiewijzigingen na het feit geïnterpreteerd?

Als we aannemen dat een systeemontwikkelingsproject een gezamenlijke inspanning is van de gebruiker en de leverancier, dan leidt dit tot een meer geavanceerde discussie. Het gaat om de vraag: “Wie is verantwoordelijk als de gebruiker na het feit om extra functies of correcties vraagt, waardoor het moeilijk wordt om de deadline te halen?”

Systeemontwikkeling begint over het algemeen met het definiëren van de vereisten, gevolgd door basisontwerp, gedetailleerd ontwerp, productie (programma-implementatie) en testen, met als doel om zo min mogelijk terugval te hebben (algemeen bekend als het watervalmodel). Maar in de praktijk gebeurt het vaak dat er terugval optreedt in het proces als gevolg van een of andere omstandigheid waarbij er een tekortkoming is in het voorgaande proces.

Hoe moeten we denken over gevallen waarin de deadline niet wordt gehaald in dergelijke gevallen? Uit de interpretatie van eerdere rechtszaken blijkt dat de conclusie kan variëren afhankelijk van het moment waarop het extra werk plaatsvond.

Als het extra werk plaatsvond vóór de verduidelijking van de specificaties, zoals het externe ontwerp

In het eerder genoemde vonnis wordt tegelijkertijd aangegeven dat het niet noodzakelijkerwijs een schending van de samenwerkingsplicht is als er een verzoek om extra ontwikkeling is ontvangen van de gebruiker tijdens het basisontwerp (vóór de fase van de programma-implementatie).

Het is vanzelfsprekend dat de gebruiker tijdens het basisontwerpwerk verschillende eisen stelt aan het systeem dat wordt gebouwd, en bovendien, voor de gebruiker zonder gespecialiseerde kennis, is het moeilijk om nauwkeurig te beoordelen of dergelijke eisen extra kosten of uitstel van de leveringsdatum vereisen, of dat ze het werkproces belemmeren. Daarom kan niet worden gezegd dat de gebruiker zich had moeten onthouden van eisen die extra kosten of uitstel van de leveringsdatum met zich meebrengen. Integendeel, als de gebruiker eisen stelt die extra kosten of uitstel van de leveringsdatum vereisen, dan had de verweerder, die de verplichting tot projectmanagement heeft, de gebruiker hiervan op de hoogte moeten stellen en overleg moeten vragen over het intrekken van de eisen of het uitstellen van de leveringsdatum, enz., om te voorkomen dat er problemen ontstaan in de ontwikkelingswerkzaamheden.

Vonnis van de districtsrechtbank van Tokio, 10 maart 2004 (Heisei 16)

In dit vonnis werd aangegeven dat de gebruiker ook een zekere plicht tot samenwerking heeft, maar dat rekening moet worden gehouden met het feit dat de gebruiker zelf geen expert is in systeemontwikkeling. Met andere woorden, aangezien de gebruiker die de bestelling plaatst geen expert is in systeemontwikkeling, is het niet vreemd dat hij tijdens de periode tot de inhoud van het te ontwikkelen systeem duidelijk wordt, verschillende bestellingen plaatst, en het is zelfs hard om te zeggen dat hij “zichzelf zou moeten realiseren” dat de inhoud van de bestelling een herziening van de leveringsdatum, enz. vereist.

Echter, de plicht die hier aan de kant van de leverancier wordt opgelegd, is in wezen een inspanning tot communicatie, zoals het verzoeken om uitstel van de deadline (of, als de deadline niet kan worden verschoven, het voorstellen om de extra eis zelf in te trekken). Daarom moet worden opgemerkt dat dit niet betekent dat het ook een plicht is om alle eisen van de gebruiker te accepteren en toch op de oorspronkelijke datum te leveren.

Als het extra werk plaatsvond na de specificatiebevestiging van het productie- of testproces

Als we de inhoud van het bovenstaande vonnis omdraaien, kunnen we tot op zekere hoogte voorspellen wat de conclusie zou zijn geweest als het extra ontwikkelingswerk had plaatsgevonden nadat de specificaties al waren bevestigd. In dat geval zou het moeilijker zijn om aan dergelijke eisen te voldoen. Inderdaad, het verschil in begrip van de ontwikkelingswerkzaamheden tussen de gebruiker en de leverancier verandert niet, of het nu voor of na de specificatiebevestiging is.

Echter, het veranderen of toevoegen van de bestelling na de bevestiging van de specificaties heeft een hoge kans om het werk opnieuw te moeten doen. Het is vaak moeilijk om te verdedigen dat “het is natuurlijk dat de klant allerlei eisen stelt” in het geval van een leveringsvertraging die zelfs onder dergelijke omstandigheden is ontstaan. Bovendien roept de situatie waarin veel specificatiewijzigingen en functietoevoegingen na het feit plaatsvinden, de vraag op of er niet al een schending van de samenwerkingsplicht van de gebruiker was in de stroomopwaartse processen zoals het basisontwerp, die al voltooid hadden moeten zijn.

Vanuit dit oogpunt is het niet realistisch om te denken dat de leverancier verantwoordelijk is voor de leveringsvertraging veroorzaakt door specificatiewijzigingen die zijn gemaakt nadat de specificaties eenmaal zijn bevestigd. Het is redelijk om te zeggen dat de bovengenoemde uitspraak ook deze implicatie heeft.

Bovendien, deze beoordelingen worden vaak gedaan met behulp van bewijsmateriaal zoals notulen die zijn afgestemd op de voortgang van de systeemontwikkeling, niet alleen het contract. Details over de notulen worden uitgelegd in het volgende artikel.

Gerelateerd artikel: Hoe notulen te bewaren in systeemontwikkeling vanuit een juridisch perspectief[ja]

Samenvatting: Het is belangrijk om niet te vergeten dat de definitie van vereisten een proces is aan de kant van de gebruiker

Hoewel de definitie van vereisten een kans is voor de leverancier om zijn vaardigheden te tonen, moet men zich ervan bewust zijn dat het in de eerste plaats een taak is aan de kant van de gebruiker. Aangezien het een systeem is dat binnen het eigen bedrijf wordt gebruikt, zelfs als het wordt opgebouwd met de hulp van externe experts, wordt wettelijk gezien aangenomen dat het een gebied is waarop het eigen bedrijfsgovernance van toepassing moet zijn.

Als de gebruikerskant niet coöperatief is in het ontwikkelingsproces, moet men zich ervan bewust zijn dat er een grote kans is dat de rechtbank een strenge mening zal geven aan de gebruikerskant, zelfs als het project in vlammen opgaat.