Er det muligt at øge det estimerede beløb for systemudvikling efterfølgende?

Arbejdet med systemudvikling involverer mange mennesker, både fra kundens og leverandørens side, hvilket gør det svært at koordinere projektet effektivt. Det er selvfølgelig afgørende at have en god planlægning, men det er ikke altid, at kunden er i stand til at formidle præcis og relevant information til leverandøren. Når udviklingsprocessen er nået til et vist punkt, kan det være uklart, om det er muligt at opkræve ekstra omkostninger for ændringer i specifikationer eller tilføjelse af funktioner, hvilket er en stor bekymring for dem, der tager imod arbejdet.

Hvornår er det juridisk tilladt at opkræve for sådanne rettigheder? Og hvordan fastsættes beløbet for kompensation for yderligere udvikling og funktionelle ændringer? I denne artikel vil vi forsøge at afklare disse og andre spørgsmål.

Hvornår kan man tale om yderligere udvikling eller funktionelle ændringer?

I systemudviklingsprojekter er den type kontrakt, man normalt indgår, enten en entreprisekontrakt eller en quasi-fuldmagt kontrakt. Uanset hvilken type kontrakt, vil det, der skal gøres af den part, der modtager arbejdet (dvs. forpligtelsen), og den tilhørende betaling (dvs. rettigheden), blive angivet i kontrakten som et par. Derfor, hvis der tilføjes arbejde, der ikke er inkluderet i det arbejde, der danner grundlag for betalingen, kan det siges at være yderligere udvikling eller funktionelle ændringer. Omvendt, hvis det er inkluderet, vil det blive behandlet som om det er i overensstemmelse med de oprindelige specifikationer (dvs. inden for rammerne af den eksisterende kontrakt).

For øvrigt, forskellene mellem entreprisekontrakter og quasi-fuldmagt kontrakter er forklaret i detaljer i en separat artikel.

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

Men hvis man siger, at alt, lige fra mindre justeringer af skrifttyper, der vises på skærmen, skal defineres i specifikationerne på forhånd, ellers vil de alle blive betragtet som yderligere udvikling, kan det også hindre glatte forretningsforbindelser betydeligt. Derfor, når man tager højde for disse diskussioner om detaljerne i specifikationerne, er det ikke let at trække en ensartet linje. Men hvis man skulle give en generel retningslinje, ville det være:

• Specifikationerne er blevet bekræftet, og yderligere funktioner er blevet beordret
• Programimplementeringen er allerede afsluttet, og ændringer er blevet beordret

I sådanne tilfælde kan det siges, at der er en høj sandsynlighed for, at argumentet har en vis juridisk gyldighed.

Retssager, hvor spørgsmålet om yderligere udvikling og funktionelle ændringer blev diskuteret

Bekræftende eksempel: Tilfælde, hvor specifikationerne for grunddesignet blev ændret efterfølgende

Følgende eksempel involverer efterfølgende ændringer i specifikationerne.

Softwareudvikling involverer ① kravspecifikation, ② eksternt design, ③ internt design, ④ oprettelse af kildeprogram (programdesign, kodning), ⑤ forskellige tests (enhedstest, kombinationstest, systemtest) (udeladelse) Oprindelige specifikationer (udeladelse) realiseres gennem arbejde efter internt design, og det forstås, at dette er omfanget af arbejdet, der står i forhold til retten til at anmode om betaling baseret på den nuværende udviklingskontrakt.
En anmodning om ændring af specifikationerne er juridisk set en anmodning om en ny kontrakt der overstiger omfanget af det oprindelige arbejde baseret på kontrakten, og hvis entreprenøren fuldfører arbejdet relateret til den ekstra kontrakt uden at præsentere et ekstra konstruktionsgebyr og uden enighed om det ekstra gebyr, er det rimeligt at forstå, at en ny kontrakt uden en fast pris er etableret mellem klienten og entreprenøren, og at en rimelig forpligtelse til at betale for yderligere udviklingsomkostninger opstår.

Osaka District Court, August 29, 2002 (2002)

At holde nøgleord som “prisrelation” og “ny kontrakt” i tankerne vil hjælpe med at forstå denne dom bedre.

Desuden blev der i den ovennævnte dom vist en anden meget interessant pointe. Det er, at meget detaljerede justeringer, såsom placeringen af knapper og skrifttypen af tegn, ikke falder ind under specifikationsændringerne, der nævnes her. Det relevante afsnit er som følger.

Imidlertid, i softwareudvikling, er det ikke tilfældet, at detaljer som skrifttypen og placeringen af knapper på skærmen bestemmes på det eksterne designstadium, og det er normalt, at detaljer justeres efter specifikationsbekræftelse gennem møder mellem parterne. I betragtning af dette, bør det ikke være rimeligt at betragte krav om detaljering af specifikationer som en ændring af specifikationerne.

Osaka District Court, August 29, 2002 (2002)

I dommen blev det interessante udtryk “detaljering af specifikationer” brugt.

• Tilfælde, hvor noget, der skulle have været besluttet, blev ændret efterfølgende
• Tilfælde, hvor man fortsatte uden at beslutte noget, der kunne have været besluttet undervejs

Det kan siges, at det viser en tankegang, hvor den juridiske behandling skal være forskellig i disse tilfælde.

Andre bekræftende eksempler

Andre sager, hvor yderligere udvikling og funktionelle ændringer blev anerkendt, inkluderer:

• Tilfælde, hvor antallet af programmer, der blev leveret, var omkring det dobbelte af det oprindelige antal (Tokyo District Court, April 22, 2009 (2009))
• Tilfælde, hvor arbejdsperioden blev forlænget til omkring tre gange (Tokyo District Court, January 22, 2010 (2010))

Når man ser på det på denne måde, kan man se, at ideen om at give en vis juridisk beskyttelse til forlængelsen af arbejdsperioden, som er en bredere udvikling, er blevet vedtaget.

“Aftale om yderligere udvikling og øget betaling” og “etablering af den oprindelige kontrakt” er separate spørgsmål

En vigtig pointe i forbindelse med disse spørgsmål er, at:

1. “Hvorvidt en kontrakt om systemudvikling (den oprindelige kontrakt) officielt blev etableret mellem de to virksomheder i første omgang”
2. “Hvorvidt en kontrakt om yderligere udvikling (også) blev etableret yderligere, efter at systemudviklingen officielt blev etableret”

Domstolens bedømmelseskriterier er forskellige i disse situationer. For at sige det kort, har domstolene tendens til at være:

• Streng i forhold til 1 (de anerkender sjældent etableringen af en kontrakt i situationer uden en kontrakt)
• Ret fleksible i forhold til 2 (selv uden en kontrakt om yderligere udvikling, anerkender de fleksibelt øget betaling)

For 1 er der en detaljeret forklaring i en anden artikel.

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

Negativt eksempel: Tilfælde, hvor det blev behandlet som inkluderet i samme kontraktindhold juridisk

Men på den anden side er der også retssager, hvor en øget betaling ikke blev anerkendt. I den dom, der citeres nedenfor, blev det diskuteret, om en øget betaling skulle anerkendes, fordi indholdet af arbejdet ændrede sig efter at en kontrakt om systemudvikling var blevet indgået.

Spørgsmålet i denne sag er, (1) hvad var indholdet af det arbejde, som sagsøgeren påtog sig i denne kontrakt, (2) om der blev indgået en aftale om at udvide omfanget og øge betalingen for det pågældende arbejde mellem sagsøgeren og sagsøgte, (udeladelse), og så videre. (udeladelse)

Først og fremmest er denne kontrakt en kontrakt, der aftaler at betragte betalingen som en fast pris for sagsøgerens arbejde (kontrakt), og antal trin, enhedspris osv. er kun interne dokumenter, der bruges til at beregne kontraktprisen internt hos sagsøgeren, og antallet af trin osv. har intet at gøre med kontraktprisen. (udeladelse)

Som anerkendt ovenfor blev sagsøgerens arbejde ændret den 25. februar 1987, og systemstyring, kontraktbygningsomkostninger og en del af nytteværdien blev begrænset, og resten blev håndteret af sagsøgte. Uanset dette, er sagsøgerens arbejde efter ændringen inden for rammerne af det oprindelige kontraktarbejde, og betalingen for dette arbejde er dækket af kontraktbeløbet, der blev aftalt som en fast pris ved kontraktens begyndelse.

Tokyo District Court, June 12, 1995 (1995)

I denne dom blev det afgjort, at selvom indholdet af arbejdet, der blev pålagt leverandøren, blev ændret, var udviklingsindholdet inden for rammerne af den oprindelige kontrakt, og det skulle dækkes af den oprindeligt aftalte betaling.

I sidste ende, når man overvejer, hvilket arbejde betalingen blev bestemt på baggrund af, bør arbejde, der ikke er inkluderet deri, anerkendes for at anmode om yderligere betaling.

Og hvad betalingen var for det arbejde, der skulle udføres, vil blive afgjort ikke kun på baggrund af kontrakten, men også på baggrund af beviser som mødereferater. Vigtigheden af mødereferater er detaljeret forklaret i følgende artikel.

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

Hvordan bestemmes beløbet for yderligere udvikling og funktionelle ændringer?

I systemudviklingsfeltet er det ikke usædvanligt, at specifikationer, der synes at være fastlagt, ændres senere. Hver gang dette sker, er det ikke realistisk at forberede en ny skriftlig kontrakt og fortsætte med kontraktforretningerne. Hvordan skal man beregne beløbet, hvis projektet falder igennem uden at kunne gennemføre disse procedurer, uanset om man kan indgå en aftale som en note, efter at have bekræftet specifikationerne igen for de ting, der skal tilføjes eller ændres?

Den artikel, der skal henvises til i sådanne tilfælde, er den følgende citerede artikel 512 i den japanske handelslov (understreget af forfatteren).

Artikel 512 i den japanske handelslov: Når en erhvervsdrivende handler på vegne af en anden inden for sit forretningsområde, kan han kræve en rimelig betaling.

Spørgsmålet er, hvor meget denne “rimelige betaling” i artiklen bliver i konkrete situationer. Når man ser på tidligere retssager, synes det at være antaget, at man skal bære omkostningerne i forhold til arbejdstid, mængde eller periode. Dette skyldes sandsynligvis, at systemudviklingsarbejde er en form for serviceindustri, og at omkostningerne hovedsageligt er personaleomkostninger.

Derfor, på trods af den abstrakte natur af udtrykket “rimelig betaling” i handelsloven, er det ikke nødvendigt med komplicerede beregninger for at estimere markedsprisen for yderligere betaling i denne sammenhæng. Lad os se på nogle retssager nedenfor.

Sag 1: Et eksempel, hvor yderligere betaling blev anerkendt i forhold til stigningen i arbejdstid

Det er rimeligt at antage, at udviklingsarbejdstiden baseret på denne specifikationsændring er i alt 257,5 mand/dage, og hvis dette konverteres til udviklingsomkostninger pr. mand/dag på samme måde som i den oprindelige udviklingskontrakt, nemlig 32.500 yen (i kontrakten er enhedsprisen 650.000 yen pr. mand/måned, og hvis man antager, at der er 20 arbejdsdage om måneden, bliver udviklingsomkostningerne pr. mand/dag 32.500 yen), så er det rimeligt at antage, at de yderligere udviklingsomkostninger baseret på denne specifikationsændringsanmodning er 8.368.750 yen.

Dom afsagt af Osaka District Court den 29. august 2002 (Heisei 14)

Nøgleordet her er “pr. mand/dag”. Det viser, at arbejdstid er brugt som grundlag for beregning af yderligere betaling.

Sag 2: Et eksempel, hvor yderligere betaling blev anerkendt i forhold til antallet af programmer

Når man overvejer det rimelige beløb for betaling, inklusive den ekstra del i denne sag, skal man tage højde for, at størstedelen af omkostningerne ved udvikling af et computersystem er teknikerens personaleomkostninger, og at disse personaleomkostninger generelt er proportionale med mængden af programmer, der skal oprettes. Derfor er det rimeligt at antage, at det rimelige beløb er 46.725.728 yen, som er det beløb, der opnås ved at dividere det oprindelige kontraktbeløb på 23.250.000 yen med antallet af programmer, der blev afsluttet inden den anden inspektion, og multiplicere denne enhedspris pr. program med antallet af programmer, der gennemgik den tredje inspektion, 414 programmer.

Dom afsagt af Tokyo District Court den 22. april 2005 (Heisei 17)

Der er mange tal, men hvis du læser roligt, vil du se, at der ikke er nogen komplicerede beregninger. Baseret på den oprindelige kontrakt bekræfter de, “hvor meget de estimerede prisen pr. program til at være”, og laver derefter en simpel multiplikation af “enhedspris x mængde”.

Sag 3: Et eksempel, hvor yderligere betaling blev anerkendt i forhold til længden af perioden

Da det i kontrakten er fastlagt, at der skal betales 60 millioner yen for arbejdet som en semi-delegation i perioden fra januar til marts 2005, og da det kan forventes, at arbejdsmængden vil stige efter april samme år på grund af starten af det nye skoleår og drift af systemet for kursusregistrering osv., er det rimeligt at antage, at betalingen for arbejdet i perioden fra april til september 2005 er 120 millioner yen, baseret på de 60 millioner yen, der er fastlagt for arbejdet i de tre måneder.

Dom afsagt af Tokyo District Court den 22. januar 2010 (Heisei 22)

Den ovenstående dom viser, at yderligere betaling beregnes ved en simpel proportional beregning også for den forlængede periode.

Opsummering

Som det fremgår af ovenstående retssager, synes der at være en vis grad af regelmæssighed og fælles træk i den juridiske behandling af ekstra kompensation for programmører og ingeniørers arbejde. Det vil sige, at der generelt synes at være en tilgang til at beregne dette så simpelt som muligt, baseret på relativt objektive indikatorer som den tid, der er brugt, den formelle mængde arbejde (som det leverede program), og den tid og periode, der er arbejdet.

Det kan virke som en kedelig historie, at der opstår ekstra kompensation baseret på mængden af arbejde, den formelle mængde arbejde, eller den tid, der er brugt, især når man tænker på, at disse ekstra udviklings- og funktionsrettelser opstår netop fordi man har fejlet i at estimere det perfekte arbejdsomfang eller at formalisere processen nøjagtigt. Men selv fra leverandørens synspunkt, selvom målet er at prioritere kundens fordele, er det meningsfuldt at have en vis grad af risikostyring, hvis disse rettigheder sandsynligvis vil blive anerkendt juridisk.