Is het mogelijk om de geschatte kosten voor systeemontwikkeling achteraf te verhogen?

Het werk van systeemontwikkeling, waarbij zowel de opdrachtgevende gebruikerskant als de opdrachtnemende leverancierskant veel mensen betrekt, is niet eenvoudig om als een groep in harmonie te laten verlopen. Het is vanzelfsprekend dat planning uiterst belangrijk is, maar tegelijkertijd is het niet altijd het geval dat de opdrachtgever, de gebruiker, in staat is om de juiste informatie samen te vatten en deze duidelijk aan de leverancier over te brengen. Als de ontwikkelingsfase tot op zekere hoogte is gevorderd en er wordt gevraagd om specificaties te wijzigen of functies toe te voegen, is het een grote vraag of het mogelijk is om extra kosten bovenop de oorspronkelijke schatting in rekening te brengen vanuit het perspectief van de partij die het werk aanneemt.

Hoe worden dergelijke rechten wettelijk erkend? En hoe wordt het bedrag van de vergoeding voor de extra ontwikkeling en functiecorrectie bepaald? In dit artikel zullen we deze en andere vragen behandelen.

Wanneer spreken we eigenlijk van aanvullende ontwikkeling of functiecorrectie?

In projecten voor systeemontwikkeling zijn de contracttypes die je normaal gesproken accepteert meestal aannemingsovereenkomsten of quasi-mandaatovereenkomsten. In beide gevallen worden de taken (verplichtingen) die de accepterende partij moet uitvoeren en de bijbehorende vergoeding (rechten) als een paar in het contract aangegeven. Daarom, als er taken worden toegevoegd die niet onder de voorwaarden van de oorspronkelijke vergoeding vallen, kan dit worden beschouwd als aanvullende ontwikkeling of functiecorrectie. Aan de andere kant, als taken worden opgenomen die wel onder de voorwaarden vallen, worden deze behandeld als onderdeel van de oorspronkelijke specificaties (binnen het kader van het bestaande contract).

Overigens wordt het verschil tussen aannemingsovereenkomsten en quasi-mandaatovereenkomsten in detail uitgelegd in een apart artikel.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Echter, als je zou beweren dat zelfs de kleinste aanpassingen aan de lettertypen die op het scherm worden weergegeven als aanvullende ontwikkeling worden beschouwd als ze niet vooraf in de specificaties zijn vastgelegd, zou dit de vlotte handel aanzienlijk kunnen belemmeren. Daarom is het niet eenvoudig om een uniforme grens te trekken, rekening houdend met discussies over de details van deze specificaties. Maar als algemene richtlijn kunnen we zeggen dat:

• Als je na de definitieve specificatie nog meer aanvullende functies krijgt opgedragen
• Als je na de voltooiing van de programmatuurimplementatie wordt opgedragen deze te wijzigen

In dergelijke gevallen is het waarschijnlijk dat je argumenten een zekere mate van juridische geldigheid hebben.

Rechtszaak waarin het punt van discussie was of er sprake was van aanvullende ontwikkeling of functiecorrectie

Bevestigend voorbeeld: Geval van specificatiewijziging na basisontwerp

Het volgende voorbeeld betreft een geval waarin de specificaties achteraf zijn gewijzigd.

Softwareontwikkeling gaat door de ontwikkelingsfasen van ① vereistenbepaling, ② extern ontwerp, ③ intern ontwerp, ④ het maken van bronprogramma’s (programma-ontwerp, codering), ⑤ verschillende tests (eenheidstests, combinatietests, systeemtests) (weglating) Het is om de oorspronkelijke specificaties (weglating) te realiseren door middel van werk na intern ontwerp, en het wordt begrepen dat dit het bereik van het werk is dat in verband staat met het recht op vergoeding op basis van het ontwikkelingscontract. Het aanbod om de specificaties te wijzigen wordt juridisch gezien opgevat als een nieuwe opdracht voor werk die buiten het bereik van het werk valt op basis van het oorspronkelijke contract door de opdrachtgever, en als de aannemer de extra werkvergoeding niet aangeeft en het werk met betrekking tot de extra opdracht voltooit zonder overeenstemming over de extra vergoeding, wordt het begrepen dat een nieuw contract zonder vastgestelde vergoeding is gesloten tussen de opdrachtgever en de aannemer, en dat het redelijk is om te begrijpen dat er een verplichting ontstaat om redelijke extra ontwikkelingskosten te betalen.

Osaka District Court, 29 augustus 2002 (Heisei 14)

Het is belangrijk om sleutelwoorden zoals “prijsrelatie” en “nieuw contract” te onthouden om dit vonnis beter te begrijpen.

Overigens, in het bovengenoemde vonnis werd nog een zeer interessant punt aangegeven. Dat is dat zeer gedetailleerde aanpassingen, zoals de plaatsing van knoppen en het lettertype van teksten, niet als specificatiewijzigingen worden beschouwd. Het relevante deel is als volgt.

Echter, in softwareontwikkeling, gezien het feit dat het normaal is dat enige aanpassing wordt gemaakt aan de details door overleg tussen de partijen, zelfs na de specificatiebevestiging, zoals het lettertype voor het weergeven van teksten op het scherm en de plaatsing van knoppen, zijn niet bepaald in de fase van extern ontwerp, het zou niet redelijk zijn om te zeggen dat het verzoek om specificatiedetails ook een specificatiewijziging is.

Osaka District Court, 29 augustus 2002 (Heisei 14)

In het vonnis werd het interessante woord “specificatieverfijning” gebruikt.

• Het geval waarin iets dat al besloten had moeten zijn, later werd omgekeerd
• Het geval waarin men doorging zonder iets te beslissen dat men kon beslissen terwijl men bezig was

Het kan ook worden gezegd dat het een idee toont dat de juridische behandeling in deze gevallen verschillend zou moeten zijn.

Andere bevestigende voorbeelden

Daarnaast zijn er gevallen waarin aanvullende ontwikkeling en functiecorrectie zijn erkend, zoals:

• Het geval waarin het aantal geleverde programma’s ongeveer verdubbeld is ten opzichte van het oorspronkelijke plan (Uitspraak van de rechtbank van Tokyo op 22 april 2009 (Heisei 17))
• Het geval waarin de werkperiode ongeveer drie keer zo lang is geworden (Uitspraak van de rechtbank van Tokyo op 22 januari 2010 (Heisei 22))

Zoals u kunt zien uit deze samenvatting, is het duidelijk dat het concept van het verlengen van de werkperiode wordt aangenomen als een vorm van aanvullende ontwikkeling in de ruime zin, en dat het een bepaalde juridische bescherming geniet.

“Overeenkomst over aanvullende ontwikkeling en verhoging van de beloning” en “totstandkoming van het oorspronkelijke contract” zijn verschillende kwesties

Een belangrijk punt met betrekking tot deze problemen is dat,

1. het scenario “Of er in de eerste plaats een formeel contract (het oorspronkelijke contract) is gesloten tussen de twee bedrijven met betrekking tot systeemontwikkeling”
2. het scenario “Of er een aanvullend contract is gesloten voor aanvullende ontwikkeling van het systeem dat eenmaal formeel is vastgesteld”

de beoordelingscriteria van de rechtbank verschillen. Om het simpel te zeggen, de rechtbank heeft de neiging om,

• streng te zijn met betrekking tot 1 (het is moeilijk om de totstandkoming van een contract te erkennen in situaties zonder contract)
• relatief mild te zijn met betrekking tot 2 (zelfs zonder een contract voor aanvullende ontwikkeling, erkent het flexibel verhogingen in beloning)

te zijn. Ik leg 1 in detail uit in een ander artikel.

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

Ontkenning: Gevallen waarin het werd behandeld als inbegrepen in vergelijkbare contractinhoud volgens de wet

Echter, er zijn ook rechtszaken waarin een verhoging van de vergoeding niet werd toegestaan. In het vonnis dat hieronder wordt geciteerd, werd betwist of een verhoging van de vergoeding kon worden toegestaan vanwege een wijziging in de inhoud van het werk na het sluiten van een contract voor systeemontwikkeling.

Het geschil in deze zaak betreft (1) wat de inhoud van het werk was dat de eiser onder dit contract heeft aangenomen, (2) of er een overeenkomst is bereikt tussen de eiser en de verweerder om de omvang uit te breiden en de prijs te verhogen voor het aangenomen werk, (weglating), enzovoort. (weglating)

Ten eerste is dit contract een aannemingsovereenkomst waarbij is overeengekomen dat de prijs het definitieve tegenprestatie is voor het werk dat de eiser heeft aangenomen, en het aantal stappen en de eenheidsprijs met betrekking tot het aangenomen werk zijn slechts interne documenten die worden gebruikt om het bedrag van de aannemingsprijs te berekenen binnen de eiser, en de toename van het aantal stappen en dergelijke omstandigheden hebben niets te maken met de aannemingsprijs. (weglating)

Zoals hierboven erkend, werd het werk dat de eiser had aangenomen gewijzigd op 25 februari 1987 (Showa 62), en werd beperkt tot systeembeheer, berekening van contractwerk kosten en een deel van de nutsvoorzieningen, en de rest werd overgenomen door de verweerder. De veranderde taken van de eiser blijven binnen het bereik van de oorspronkelijke contractontwikkelingstaken, en de vergoeding voor deze taken wordt volledig gedekt door de vergoeding die is overeengekomen als de definitieve prijs bij het begin van dit contract.

Vonnis van de districtsrechtbank van Tokio, 12 juni 1995 (Heisei 7)

In dit vonnis werd geoordeeld dat zelfs als de inhoud van het werk dat aan de leverancier is uitbesteed, is gewijzigd, de ontwikkelingsinhoud binnen het bereik van de oorspronkelijke contractinhoud valt en moet worden gedekt binnen de oorspronkelijk overeengekomen vergoeding.

Uiteindelijk wordt aangenomen dat de houding is om extra vergoedingen toe te staan voor werk dat niet is inbegrepen, rekening houdend met op welke taken de vergoeding is gebaseerd.

En wat de vergoeding was voor welk werk is niet noodzakelijkerwijs alleen gebaseerd op het contract, maar wordt ook bepaald op basis van bewijs zoals notulen. De belangrijkheid van notulen wordt in detail uitgelegd in het onderstaande artikel.

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

Hoe wordt de vergoeding voor extra ontwikkeling en functiecorrecties bepaald?

In de wereld van systeemontwikkeling is het niet ongewoon dat specificaties die eenmaal vastgesteld leken te zijn, later veranderen. Elke keer dat dit gebeurt, is het niet realistisch om een nieuw schriftelijk contract voor te bereiden en de contractprocedures voort te zetten. Wat betreft zaken die moeten worden toegevoegd of gecorrigeerd, is het een ding als je de specificaties opnieuw kunt bevestigen en een memorandum of iets dergelijks kunt opstellen, maar hoe moet je de vergoeding berekenen als het project stagneert zonder deze procedures te kunnen uitvoeren?

Een artikel dat als referentie kan dienen in dergelijke gevallen is artikel 512 van het Japanse Handelswetboek (de onderstreepte delen zijn door de auteur aangehaald).

Artikel 512 van het Japanse Handelswetboek: Wanneer een handelaar handelt ten behoeve van een ander binnen het bereik van zijn bedrijf, kan hij een redelijke vergoeding vragen.

Het probleem met de term “redelijke vergoeding” in dit artikel is hoeveel het uiteindelijk zal zijn in concrete situaties. Als we naar eerdere rechtszaken kijken, lijkt het erop dat de benadering is aangenomen dat de kosten moeten worden gedragen in verhouding tot de hoeveelheid werk, de hoeveelheid of de duur. Dit is waarschijnlijk te wijten aan het feit dat systeemontwikkeling van nature een soort dienstverlening is en de kosten in principe personeelskosten zijn.

Daarom, ondanks de abstractie van de term “redelijke vergoeding” in het Handelswetboek, is het niet zo moeilijk om de marktprijs van extra vergoedingen in deze context te schatten. Laten we eens kijken naar enkele rechtszaken hieronder.

Case 1: Een voorbeeld waarin extra vergoeding werd toegekend in verhouding tot de toename van de arbeidsuren

De ontwikkelingsuren gebaseerd op de specificatiewijziging in deze zaak zijn redelijkerwijs 257,5 man/dag in totaal, en als dit wordt omgezet naar de ontwikkelingskosten per persoon/dag, zijn de extra ontwikkelingskosten gebaseerd op het verzoek om specificatiewijziging redelijkerwijs 8.368.750 yen, uitgaande van dezelfde 32.500 yen (in Exhibit 3, de eenheidsprijs is 650.000 yen per persoon/maand, en als het aantal werkdagen in een maand 20 dagen is, zijn de ontwikkelingskosten per persoon/dag 32.500 yen) als in het ontwikkelingscontract van deze zaak.

Uitspraak van de rechtbank van Osaka op 29 augustus 2002 (Heisei 14)

“Per persoon/dag” is het sleutelwoord. Het geeft aan dat arbeidsuren worden gebruikt als basis voor de berekening van de extra vergoeding.

Case 2: Een voorbeeld waarin extra vergoeding werd toegekend in verhouding tot het aantal programma’s

Bij het overwegen van het redelijke bedrag aan vergoeding, inclusief het extra deel in deze zaak, is het merendeel van de kosten van de ontwikkeling van een computersysteem de arbeidskosten van technici, en deze arbeidskosten zijn over het algemeen evenredig met de hoeveelheid programma’s die worden gemaakt. Daarom wordt het bedrag van 46.725.728 yen (23.250.000 ÷ 206 × 414 = 46.725.728), dat is berekend door het oorspronkelijke contractbedrag van 23.250.000 yen te delen door het aantal programma’s dat is voltooid tot de tweede inspectie, 206, en dit te vermenigvuldigen met het aantal programma’s dat de derde inspectie heeft doorstaan, 414, als redelijk beschouwd.

Tokyo District Court ruling, April 22, Heisei 17 (2005)

Er komen veel cijfers voor, maar als je rustig leest, zul je zien dat er geen ingewikkelde berekeningen worden gemaakt. Op basis van de oorspronkelijke contractinhoud wordt bevestigd “hoeveel de eenheidsprijs per programma was geschat” en wordt er simpelweg een eenvoudige vermenigvuldiging gedaan van “eenheidsprijs x hoeveelheid”.

Case 3: Een voorbeeld waarin extra vergoeding werd toegekend in verhouding tot de lengte van de periode

In het geval van het A3-contract, is er een bedrag van 60 miljoen yen vastgesteld als vergoeding voor het werk dat de eiser heeft verricht als een quasi-delegatie gedurende de drie maanden van januari tot maart 2005 (Heisei 17). Aan de andere kant, hoewel het werk dat na april van dat jaar gratis wordt uitgevoerd, is inbegrepen, wordt verwacht dat de hoeveelheid werk na april van dat jaar zal toenemen, net als het voorgaande jaar, in vergelijking met de periode tot maart van dat jaar, vanwege het begin van het nieuwe schooljaar en de activering van het systeem voor cursusregistratie en dergelijke. Gezien deze omstandigheden, zou het redelijk zijn om de vergoeding voor het werk van de eiser van april tot september 2005 (Heisei 17), gebaseerd op de 60 miljoen yen die is vastgesteld als vergoeding voor het werk gedurende de bovengenoemde drie maanden, op 120 miljoen yen te stellen.

Oordeel van de districtsrechtbank van Tokio, 22 januari 2010 (Heisei 22)

Het bovenstaande oordeel geeft aan dat extra vergoedingen voor verlengde perioden worden berekend op basis van een eenvoudige proportionele berekening.

Samenvatting

Zoals hierboven aangegeven, als we een aantal rechtszaken bekijken, lijkt het erop dat er een zekere regelmaat en gemeenschappelijkheid te zien is in de wettelijke behandeling van extra vergoedingen voor het werk van programmeurs en ingenieurs. Dat wil zeggen, in principe lijkt het erop dat er een houding is om zo eenvoudig mogelijk te berekenen op basis van relatief objectieve indicatoren, zoals de bestede tijd, de formele hoeveelheid werk (zoals de geleverde programma’s), en de gewerkte uren en periode.

Als je bedenkt dat extra ontwikkeling en functiecorrecties juist optreden omdat ze falen in strikte procedures en perfecte tijdsschattingen, kan het idee dat extra vergoedingen ontstaan op basis van de hoeveelheid werk die is gedaan, de formele hoeveelheid werk, of de tijd die is besteed, misschien smakeloos en oninteressant lijken. Echter, vanuit het perspectief van de contractant, zelfs als je streeft naar het uitvoeren van taken met prioriteit voor de belangen van de klant, is het feit dat dergelijke rechten waarschijnlijk wettelijk worden erkend, misschien wel zinvol in termen van crisismanagement.