Wat is de juridische betekenis van managementdoelen en numerieke doelen in systeemontwikkelingsprojecten?

Systeemontwikkelingsprojecten zijn vaak nauw verbonden met grootschalige bedrijfsverbeteringen in bedrijven en werkplekken. Het kan zijn dat er een houding wordt verwacht die bijdraagt aan het oplossen van managementproblemen van het gebruikersbedrijf of het bereiken van numerieke doelen. Maar is het echt een wettelijke verplichting om je te committeren aan dergelijke managementdoelen? De juridische betekenis van numerieke doelen en managementdoelen wordt een probleem. In dit artikel zullen we de juridische problemen bespreken die gepaard gaan met verschillende “doelen” en “doelstellingen” in systeemontwikkeling.

Waarom worden de doelen van systeemontwikkeling een bron van conflicten?

Het is een uitdaging die zich bevindt tussen de verplichting tot samenwerking van de gebruiker en de beperkte discretie van de leverancier

Als we kijken naar de manier waarop zakelijke transacties worden uitgevoerd, zijn er enkele kenmerken die specifiek zijn voor systeemontwikkelingsprojecten. Een daarvan is dat een systeemontwikkelingsproject door een leverancier niet alleen kan worden uitgevoerd, maar dat het ook de medewerking van de gebruikerskant vereist. Deze verplichting is duidelijk vastgelegd in de jurisprudentie onder de naam ‘verplichting tot samenwerking’. Voornamelijk in de fasen van ① vereisten definitie ② basisontwerp ③ acceptatie van de resultaten, wordt van de gebruiker verwacht dat hij meewerkt aan de systeemontwikkeling.

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

Een ander kenmerk is dat van de leverancier normaal gesproken wordt verwacht dat hij een grote mate van discretie uitoefent in zijn werk. Er is een juridische term die alles omvat wat de leverancier moet doen in een reeks systeemontwikkelingsprojecten, namelijk ‘projectmanagementverplichting’. Hierover wordt in het volgende artikel in detail uitgelegd.

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

Als we al het bovenstaande samenvatten, kunnen we twee belangrijke punten aanwijzen.

• Van de gebruiker wordt in de praktijk verwacht dat hij de leverancier regelmatig voorziet van de nodige informatie en meewerkt aan de ontwikkelingswerkzaamheden van de leverancier.
• Van de leverancier wordt in de praktijk verwacht dat hij de doelen en doelstellingen van het project voor de gebruiker begrijpt en inspanningen levert die daarmee overeenkomen.

Vanwege deze twee punten wordt de vraag hoe ver de verplichting van de leverancier kan gaan om de zakelijke doelstellingen en numerieke doelstellingen te bereiken die vooraf door de gebruiker zijn uitgelegd, een probleem. Met andere woorden, er is een aspect dat het de plicht van de gebruiker is om te specificeren wat de leverancier moet doen (niet iets vaags zoals doelen) en dit te presenteren als specificaties, terwijl er ook een aspect is dat de leverancier als expert de plicht heeft om te leveren wat de gebruiker in wezen vraagt (niet alleen tevreden zijn met het doen wat de ander heeft gezegd). Het is kenmerkend voor conflicten rond de ‘doelen’ en ‘doelstellingen’ van systeemontwikkeling dat deze tegenstrijdige argumenten van beide partijen met elkaar botsen. Vanuit juridisch oogpunt is het een praktische uitdaging om richtlijnen voor eerlijke geschillenbeslechting voor beide partijen te bieden.

Specifieke situaties waarin de doelen van de gebruiker invloed hebben op het project

Systeemontwikkelingsprojecten zijn vaak gekoppeld aan grootschalige verbeterings- en efficiëntiemaatregelen in bedrijven en werkplekken, en vaak worden er tijdens de plannings- en voorstelfase hoorzittingen gehouden over zakelijke problemen en doelstellingen. Daar kunnen discussies plaatsvinden over de kosten-batenanalyse van systeemontwikkeling en verschillende numerieke doelen.

• Arbeidskostenreductie door automatisering
• Omzet- of winstgroei
• Verkorting van de werktijd

Bijvoorbeeld, als de bovenstaande items het uiteindelijke doel van het project zijn, kan de leverancier van tevoren uitleg geven over het rendement op investering in systeemontwikkeling vanuit een consultant-achtige positie, en kan hij ook overwegen om verkoopactiviteiten uit te voeren.

Wat zijn de rechtszaken waarbij de bedrijfsdoelstellingen van de gebruiker een probleem vormden?

Echter, de leverancier is normaal gesproken slechts een expert in systeemontwikkeling. Als alle verantwoordelijkheid voor de bedrijfsdoelstellingen van de gebruiker op hen zou vallen, zou dat een onredelijke situatie kunnen worden.

Geval waarbij het verbeteren van de bedrijfssnelheid als doel werd gesteld

In verband met deze zaak, in het vonnis dat hieronder wordt geciteerd, waren de doelen en doelstellingen van het opstarten van het systeemontwikkelingsproject opgenomen in het projectplan dat werd gemaakt bij de start van het project. Echter, toen het systeem eenmaal voltooid was en in gebruik werd genomen, kon men deze doelen en doelstellingen niet bereiken, wat leidde tot een geschil. In het oorspronkelijke projectplan stond dat men na de voltooiing van het systeem en het daadwerkelijke gebruik ervan, streefde naar het realiseren van de volgende situaties:

• De tijd voor handmatige invoer door mensen met 50% verminderen
• Administratieve taken met behulp van het betreffende IT-systeem binnen een bepaalde periode voltooien

De gebruiker kon deze uiteindelijk niet realiseren en probeerde de leverancier aansprakelijk te stellen voor wanprestatie en garantieaansprakelijkheid. Echter, de rechtbank erkende deze beweringen niet (onderstreepte en vetgedrukte delen zijn toegevoegd door de auteur).

En, (weglating) volgens de volledige strekking van het argument, ① het doel van deze zaak is “het verbeteren van de bedrijfsefficiëntie”, “het opzetten van een CRM-basis”, “het uitvoeren van zichtbaar management”, enz., wat abstract is, en de doelwaarden zijn ook “het verhogen van de contactpunten met klanten”, “het herverdelen van de inspanningen van administratieve banen naar interne controle en verkoopondersteuning”, “het nauwkeuriger kunnen voorspellen van de verkoop”, “het beperken van overmatige verkoopkortingen”, enz., veel van hen zijn abstract, bovendien, “de invoertijd met 50% verminderen”, “de tijd voor het maken van schattingen met 50% verminderen”, “het kunnen uitvoeren van wettelijke openbaarmaking binnen de wettelijke termijn”, en dergelijke doelwaarden zijn afhankelijk van het management en de bedrijfsmethoden van de gedaagde na de implementatie van SBO, en het is niet de aard van een systeemontwikkelingsbedrijf, dat de eiser is, om de implementatie van pakketsoftware te ondersteunen, om deze te kunnen bereiken, ② in de notulen van de vergadering na de kick-off van dit project, er is geen vermelding van een specifieke discussie over het bereiken van het doel en de doelwaarden van deze zaak, ③ in het projectplan van deze zaak, “om een beursgenoteerd bedrijf te worden”, enz., uitdrukkingen die op zichzelf niet de aard van een contract hebben, worden gebruikt, (weglating) gezien deze omstandigheden, wordt erkend dat de eiser de beschrijving van het doel van deze zaak in het projectplan van deze zaak heeft gemaakt op basis van de uitleg van de gedaagde, om te voorkomen dat dit project mislukt, om een gemeenschappelijk begrip te krijgen van het doel en de resultaten van dit project, en het kan niet worden erkend dat de gedaagde, aan de eiser, het systeemontwikkeling heeft toevertrouwd om het doel van deze zaak te bereiken. (weglating) Daarom, omdat het niet kan worden erkend dat de eiser het systeemontwikkeling van de gedaagde heeft aangenomen om het doel van deze zaak te bereiken, (weglating) er is geen reden voor de beweringen van wanprestatie en garantieaansprakelijkheid.

Tokyo District Court, 28 december 2010 (Heisei 22)

De juridische betekenis van managementdoelstellingen en kwantitatieve doelstellingen zoals geïnterpreteerd uit jurisprudentie

Zoals ook in dit vonnis wordt genoemd, is het normaal dat er verschillende factoren, zoals de managementinspanningen van de gebruikerskant, tussenkomen of de doelstellingen van systeemontwikkeling en kwantitatief gedefinieerde doelstellingen kunnen worden bereikt. Daarom zou men moeten denken dat de drempel om de verantwoordelijkheid aan de kant van de leverancier te leggen zeer hoog is. In de eerste plaats, als de verantwoordelijkheid voor wanprestatie of garantie voor gebreken aan de kant van de leverancier wordt erkend, betekent dit dat het bereiken van het ‘doel’ of de ‘doelstelling’ was opgenomen als onderdeel van de contractinhoud. Echter, in dit geval waren het ‘doel’ en de ‘doelstelling’

• Voor abstracte en vage zaken is het moeilijk om ze te zien als onderdeel van de contractinhoud, omdat ze niet passen bij de aard van een wettelijke verplichting
• Voor zaken die zelfhulpinspanningen van de gebruikerskant, met name het management, vereisen, is het ongepast om de leverancier de schuld te geven, aangezien deze niet onder de controle van de leverancier vallen, en het is moeilijk om ze te zien als onderdeel van de contractuele verplichtingen

Dit is de juridische beoordeling die werd ontvangen.

Wat we verder kunnen afleiden uit dit vonnis

Dit vonnis bevat ook enkele interessante punten.

• Het feit dat het delen van het ‘doel’ en de ‘doelstellingen’ van een systeemontwikkelingsproject slechts een onderdeel kan zijn van de inspanningen om een ‘gemeenschappelijk begrip’ te krijgen tussen de gebruiker en de leverancier, wordt ook door de rechtbank in overweging genomen.
• Bij het overwegen van hoe essentieel deze ‘doelen’ en ‘doelstellingen’ waren in een reeks projecten, heeft de rechtbank ook notulen van vergaderingen als referentie gebruikt.

Overigens, met betrekking tot juridische kwesties die verband houden met systeemontwikkelingsprojecten, vanuit het oogpunt van documentbeheer en het belang van notulen, hebben we uitleg gegeven in het volgende artikel.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Belangrijke juridische kwesties rond managementdoelstellingen en kwantitatieve doelstellingen

Er zijn echter enkele aanvullende punten die we moeten overwegen bij het omgaan met juridische kwesties rond deze “doelen” en “doelstellingen”.

Het maakt uit of consulting betaald of onbetaald is

Als u niet alleen een systeemontwikkelingsproject heeft, maar ook een betaald consultingcontract, kan de situatie aanzienlijk veranderen. Als er omstandigheden zijn waarbij een uitvoeringsplan met weinig haalbaarheid is opgesteld zonder rekening te houden met de managementresources van de gebruiker, kan het mogelijk zijn dat u aansprakelijk wordt gesteld voor contractbreuk in het betaalde consultingcontract.

Defecten in de output, inconsistenties in functies en specificatie-eisen zijn aparte problemen

Als er een defect is in het “ontwikkelings” project zelf, dat wil zeggen, als er bugs of problemen worden geïdentificeerd in de output, moeten we dit probleem apart begrijpen. In dat geval gaat het niet om het bespreken van “doelen” en “doelstellingen” in het management, maar vooral om de consistentie tussen de output en de vereiste functies en specificaties. Bijvoorbeeld, de maatregelen die de gebruiker moet nemen als er achteraf een defect in het systeem wordt ontdekt, worden uitgelegd in het volgende artikel.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Er zijn ook gerelateerde onderwerpen, zoals dingen die niet in de eisen zijn opgenomen, maar waarvan wordt erkend dat de leverancier de verplichting heeft om ze te implementeren. Dit wordt in detail uitgelegd in het volgende artikel.

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

In beide gevallen moeten we begrijpen dat geschillen over “doelen” en “doelstellingen” vergelijkbaar maar verschillend zijn.

Een fundamenteel begrip van thema’s zoals verantwoordelijkheid en contracten wordt ook gevraagd

We hebben zojuist de juridische kwesties rond de ‘doelen’ en ‘doelstellingen’ van systeemontwikkeling besproken. In geschillen over dergelijke kwesties, wordt vaak aangenomen dat rechtbanken begrijpen dat er veel gevallen zijn waarin communicatie wordt gedeeld als een inspanning om de stappen van zowel gebruikers als leveranciers op elkaar af te stemmen. Hoewel de geldigheid van de conclusie zelf voldoende kan worden begrepen door het praktische gevoel van de beoefenaar, wordt in het proces dat daartoe leidt, een fundamenteel begrip van zaken als ‘verantwoordelijkheid’ en ‘contracten’ gevraagd. We bespreken deze punten in het volgende artikel.

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

Het is belangrijk om een dieper begrip te krijgen, rekening houdend met het feit dat de wettelijke verantwoordelijkheid verschilt van een vage morele verantwoordelijkheid, en dat de duidelijke ‘overeenstemming van wil’ tussen beide partijen de contractuele verantwoordelijkheid doet ontstaan.