Hoe ver moet je wettelijk gezien gaan met het implementeren van functies die niet in de specificatiedocumenten van systeemontwikkeling staan?

Projecten voor de ontwikkeling van IT-systemen die in bedrijven worden gebruikt, worden in principe gemaakt volgens vooraf gedefinieerde specificaties. Echter, als we nadenken over de betekenis van het feit dat de leverancier als expert in systeemontwikkeling de volledige verantwoordelijkheid voor de ontwikkelingswerkzaamheden heeft, kan het zijn dat de verwachtingen van de gebruikerskant niet zo laag zijn dat het voldoende is om alleen mechanisch te implementeren wat in de specificaties is geschreven. In dit artikel zullen we bespreken tot hoever men verplicht is om te implementeren voor “programma’s die niet in de specificaties zijn opgenomen, maar die noodzakelijk zijn voor de implementatie in het licht van het doel van de ontwikkeling”.

Wettelijke problemen bij de implementatie van niet-gespecificeerde items

Discretie is vereist in de taken van de leverancier

Een groot kenmerk van de contracten en diverse juridische problemen rondom een systeemontwikkelingsproject is dat de leverancier die het werk aanneemt veel discretie heeft.

Gerelateerd artikel: Wat zijn de projectmanagementverplichtingen bij systeemontwikkeling[ja]

Echter, de ‘discretie’ waar we het hier over hebben, is niet noodzakelijkerwijs van toepassing op alle stadia van de systeemontwikkeling. Na het identificeren van elk proces en het verder uitwerken van gedetailleerde taken, kan er veel werk zijn dat dicht bij eenvoudige taken ligt. Maar over het algemeen, hoe meer het werk zich in de vroege stadia van het proces bevindt, hoe moeilijker het wordt om het werk uit te voeren zonder aanzienlijke discretie. Dit is ook de reden waarom contracten in de vroege stadia vaak goed passen bij quasi-mandaat.

Gerelateerd artikel: Het onderscheid en verschil tussen contracten en quasi-mandaat in systeemontwikkeling[ja]

Discretie moet ook worden uitgeoefend binnen strikte ontwikkelingsprocessen

Hoewel de systeemontwikkelaar veel discretie heeft, kan het accepteren van klantverzoeken op een ‘ad-hoc’ basis ernstige schade toebrengen aan latere processen. Een IT-systeem bestaat uit een verzameling van gedetailleerde componenten, en zelfs een kleine verandering in het uiterlijk kan vanuit het oogpunt van de ontwikkelaar een aanzienlijke verandering in de werklast vereisen. Er zijn artikelen die uitleggen hoe je veranderingen in systeemontwikkelingsspecificaties vanuit een juridisch perspectief kunt beheren, zoals hieronder.

Gerelateerd artikel: Hoe veranderingen in systeemontwikkeling te beheren vanuit een juridisch perspectief[ja]

Wat moet er gedaan worden als een expert, zonder vast te houden aan specificaties?

Om een systeemontwikkelingsproject soepel te laten verlopen, is het belangrijk om de ontwikkelingsvereisten vooraf te definiëren en deze planmatig uit te voeren. Aan de andere kant, er zijn momenten waarop je, door alleen te doen wat je is verteld volgens de vooraf gedefinieerde vereisten, niet volledig kunt functioneren als een expert in systeemontwikkeling. In dit dilemma komt het probleem naar voren van “wat moet er geïmplementeerd worden, ook al is het niet gespecificeerd in de specificaties?”

Wettelijke verplichtingen worden bepaald volgens de ‘bedoeling’ van specificaties en contracten

De inhoud van wat geïmplementeerd moet worden, wordt bepaald door de ‘bedoeling’ van de vermelde zaken in de contracten en specificaties, oftewel ‘wat de betekenis of intentie was van de gemaakte afspraken’, zelfs als er geen beschrijving in de contracten of specificaties staat. Laten we hieronder enkele rechtszaken bekijken.

Rechtszaak waarin de implementatieplicht werd ontkend omdat er geen vermelding was

In het onderstaande geciteerde rechtszaak ontwikkelde de leverancier een systeem dat tot aan de proefdraaiing was gevorderd, maar er ontstond een geschil toen de contractbeëindiging werd geëist omdat de benodigde functies ontbraken. De gebruiker beweerde dat de ‘automatische data-updatefunctie’ ontbrak, en het werd beweerd dat dit een belangrijk verkooppunt van het systeem in kwestie was, maar de rechtbank erkende deze implementatieplicht niet.

Zoals hierboven erkend, is er in het contract, het basisontwerpdocument en het gedetailleerde ontwerpdocument geen vermelding die aangeeft dat de ③-functie het onderwerp van ontwikkeling van het systeem in kwestie is.

De eiser beweert dat de ③-functie een belangrijk verkooppunt was van het systeem van de gedaagde aan de eiser, en benadrukt de noodzaak van deze functie, maar als zijn bewering waar is, zou dit in het contract en dergelijke moeten worden vermeld, en het is moeilijk te geloven dat de ontwikkeling van deze functie was overeengekomen zonder dat dit het geval is.

Tokyo District Court, 18 februari 2009 (Heisei 21)

Deze uitspraak kan inderdaad eenvoudig worden samengevat als “als het niet in het ontwerpdocument staat, hoef je het niet te maken”. Maar om preciezer te zijn, het is niet zozeer een formeel feit of het al dan niet in het ontwerpdocument staat, maar eerder een oordeel dat rekening houdt met de ‘bedoeling’ van de vermeldingen in het ontwerpdocument en het contract. Met andere woorden, “als je nadenkt over de reden waarom het niet in het ontwerpdocument of contract is opgenomen, is het redelijk om te denken dat er ook geen overeenstemming was die overeenkomt met die vermelding”.

Rechtszaken waarin de implementatieplicht werd bevestigd, zelfs zonder vermelding

Aan de andere kant zijn er rechtszaken waarin werd geoordeeld dat er een verplichting tot implementatie zou moeten zijn, zelfs als dit niet in het contract of de specificaties is vermeld. Het volgende geciteerde rechtszaak betreft de ontwikkeling van een systeem voor het beheren van medicatiegeschiedenis, waarbij de gebruiker het contract heeft opgezegd omdat hij de gegevens niet kon overdragen van het bestaande systeem naar het nieuwe systeem en het nieuwe systeem niet kon gebruiken. Echter, de leverancier betwistte dit, bewerend dat de gegevensoverdracht buiten de reikwijdte van hun taken viel.

De ontwikkeling van nieuwe systemen gaat vaak gepaard met het afschaffen van bestaande systemen en het overdragen van gegevens. De belangrijkheid van deze taken en de bijbehorende juridische kwesties worden in detail uitgelegd in het volgende artikel.

Gerelateerd artikel: Juridische problemen bij de overgang van het oude systeem bij systeemontwikkeling[ja]

Er waren al meer dan 50.000 patiëntgegevens opgeslagen in het bestaande systeem, en de eiser was van plan om deze gegevens te gebruiken om de administratie efficiënter te maken. Als het niet mogelijk zou zijn om de patiëntgegevens over te dragen van het bestaande systeem naar het nieuwe systeem, zou het duidelijk zijn dat dit problemen zou veroorzaken in de apotheekdiensten, en het kan worden aangenomen dat de vertegenwoordiger van de eiser dit uiteraard zou hebben begrepen. Bovendien, voorafgaand aan de sluiting van het contract, heeft de vertegenwoordiger van de eiser de vertegenwoordiger van de gedaagde gevraagd over de mogelijkheid van gegevensoverdracht, wat de vertegenwoordiger van de gedaagde ook erkent (middelste deel weggelaten), het is onwaarschijnlijk dat de vertegenwoordiger van de eiser, zich bewust van de hoge kans dat hij handmatig meer dan 50.000 patiëntgegevens zou moeten invoeren, toch besloten heeft om het nieuwe systeem te implementeren. Bovendien, zoals hierboven vermeld in (1)I, is het onwaarschijnlijk dat de gedaagde, ondanks het feit dat gegevensoverdracht niet werd verondersteld in het contract, dergelijke tijdrovende taken als service zou hebben uitgevoerd, gezien het feit dat de gedaagde niet in staat was om de medicatiegeschiedenisgegevens van het bestaande systeem over te dragen naar het nieuwe systeem en in plaats daarvan de gegevens afdrukte op papier en deze omzette naar PDF-bestanden.

Tokyo District Court, November 18, 2010 (Heisei 22)

Wat hier ook belangrijk is, is het ‘doel’ van het contract en de ‘bedoeling’ van de bepalingen in het contract. Als beide partijen het contract hebben gesloten met het begrip dat de gegevensoverdracht buiten de reikwijdte van de taken valt, dan wijst de rechtbank erop dat zowel de gebruiker als de leverancier het contract hebben gesloten met een onnatuurlijke intentie. Dat wil zeggen, de gebruiker zou hebben ingestemd met een enorme hoeveelheid handwerk, en de leverancier zou hebben geweten dat dit in de toekomst problemen zou veroorzaken voor de gebruiker, wat een zeer onredelijk verhaal zou zijn.

Wat we kunnen leren van beide uitspraken

Een van de redenen waarom de verplichting tot implementatie werd bevestigd, zelfs als er geen vermelding was van gegevensoverdracht in het contract of de specificaties, is dat het ging om “gegevens”, een kwestie die niet zichtbaar is op het scherm. Het ontbreken van een “essentiële functie” wordt direct weergegeven op het scherm van het systeem. Daarom is het niet zo moeilijk om een weglating in de specificaties te ontdekken, zelfs voor een leek in systeemontwikkeling. Aan de andere kant, het probleem van gegevensoverdracht heeft kenmerken die het moeilijk maken voor een leek in systeemontwikkeling om het belang van het proces, de moeilijkheidsgraad van het werk en de hoeveelheid werk te herkennen. Daarom wordt aangenomen dat er omstandigheden waren waarin het gemakkelijker was om te behandelen als een kwestie die de leverancier soepel zou moeten beheren met expertise.

Vanuit dit perspectief kan worden gezegd dat het weglaten van specificaties en contracten nauw verband houdt met de “verplichting tot samenwerking” van de gebruiker. Met andere woorden, het is de vraag of de gebruiker echt zijn “verplichting tot samenwerking” heeft vervuld bij het sluiten van een contract en het opstellen van specificaties. Een uitgebreide uitleg over de wettelijke verplichtingen die de gebruiker moet nakomen in een systeemontwikkelingsproject wordt in detail behandeld in het volgende artikel.

Gerelateerd artikel: Wat is de verplichting tot samenwerking van de gebruiker, de opdrachtgever van systeemontwikkeling[ja]

Als u ook het bovenstaande artikel controleert, zult u begrijpen dat het verhaal sterk verschilt tussen gebieden waar de vraag naar samenwerking van de gebruiker, zoals het identificeren van schermen en essentiële functies, groot is, en het weglaten van overwegingen voor gegevensoverdracht.

Hoe moeten we denken over vergoedingen voor ontwikkelingen die niet in de specificaties staan?

Een andere vraag die relevant is voor het onderwerp van dit artikel en die u wellicht ook interesseert, is of het wettelijk is toegestaan om een extra vergoeding te vragen voor het maken van iets dat niet in de specificaties staat. De mogelijkheid van een extra vergoeding en de berekeningsmethode voor de geschatte kosten in dergelijke gevallen worden in detail uitgelegd in het volgende artikel.

Gerelateerd artikel: Is het mogelijk om de geschatte kosten van systeemontwikkeling achteraf te verhogen?[ja]

In het bovenstaande artikel wordt uitgelegd dat het belangrijk is of er werkzaamheden waren die het werkgebied dat in verhouding staat tot de vergoeding overschreden. Met andere woorden, in relatie tot dit artikel, als de leverancier instemt met de ontwikkeling van iets dat niet in de oorspronkelijke specificaties is opgenomen (in dit artikel, het negatieve voorbeeld), dan kan er een extra vergoeding worden gevraagd.

Samenvatting

In systeemontwikkeling wordt de rol van de leverancier bepaald door de inhoud van het contract en de specificaties aan de ene kant. Echter, gezien het feit dat zij als experts worden vertrouwd met hoogwaardige taken, is het duidelijk dat de werkelijkheid niet altijd wordt bepaald door formele aspecten. Desalniettemin, bij het begrijpen van deze realiteit, is het belangrijk om te begrijpen dat de wet een grote rol speelt.