Är det möjligt att öka kostnadsförslaget för systemutveckling i efterhand?

Arbetet med systemutveckling involverar många människor, både från beställarens och leverantörens sida. Det är inte lätt att alla ska gå i takt och driva projektet framåt. Det är självklart att planering är extremt viktigt i detta arbete, men det är inte alltid möjligt för beställaren att sammanställa lämplig information och tydligt förmedla den till leverantören. När utvecklingsprocessen har kommit en bit på väg och det begärs ändringar i specifikationer eller tillägg av funktioner i efterhand, är det mycket intressant för den som tar emot arbetet att veta om det är möjligt att lägga till dessa kostnader på den ursprungliga uppskattade kostnaden.

Hur erkänns dessa rättigheter enligt lag och i vilka fall? Hur bestäms ersättningen för ytterligare utveckling och justering av funktioner? I denna artikel kommer vi att reda ut dessa och andra frågor.

När kan man tala om ytterligare utveckling och funktionella ändringar?

I systemutvecklingsprojekt är de vanligaste kontraktstyperna när man tar emot arbete antingen entreprenadkontrakt eller delgivningskontrakt. I båda dessa kontraktstyper kommer det som den mottagande parten ska göra (dvs. skyldigheter) och den ersättning som följer med det (dvs. rättigheter) att visas i kontraktet som ett par. Därför, om arbete som inte ingår i det arbete som ligger till grund för ersättningen läggs till senare, kan det sägas vara ytterligare utveckling eller funktionella ändringar. Å andra sidan, om det ingår, kommer det att behandlas som enligt de ursprungliga specifikationerna (dvs. inom ramen för det befintliga kontraktet).

Observera att skillnaderna mellan entreprenadkontrakt och delgivningskontrakt förklaras mer detaljerat i en separat artikel.

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

Men om man skulle säga att allt, inklusive mindre justeringar av teckensnitt som visas på skärmen, är ytterligare utveckling om det inte definieras i specifikationerna i förväg, kan det också hindra smidiga affärstransaktioner avsevärt. Därför, om man tar hänsyn till dessa diskussioner om detaljer i specifikationerna, är det inte lätt att dra en enhetlig linje. Men om man skulle ge en allmän riktlinje, skulle det vara:

• Ytterligare funktioner beordrades efter att specifikationerna hade fastställts
• Ändringar beordrades efter att programimplementeringen hade slutförts

I sådana fall kan det sägas att argumentet har en viss juridisk giltighet.

Rättsfall där frågan var om det rörde sig om ytterligare utveckling eller korrigering av funktioner

Bekräftande exempel: Fall där grundläggande designspecifikationer ändrades i efterhand

Följande exempel handlar om en situation där specifikationerna ändrades i efterhand.

Programvaruutveckling involverar en process som inkluderar ① kravdefinition, ② extern design, ③ intern design, ④ skapande av källkod (programdesign, kodning), ⑤ olika tester (enhetstester, kombinationstester, systemtester) … Ursprungliga specifikationer … ska realiseras genom arbete från intern design och framåt, och detta anses vara omfattningen av arbete som står i förhållande till rätten att begära betalning enligt detta utvecklingsuppdragsavtal. En begäran om specifikationsändringar tolkas juridiskt som en ny begäran om uppdragsavtal som överstiger arbetsomfånget enligt det ursprungliga avtalet från uppdragsgivaren, och om uppdragstagaren inte presenterar ett extra arbetskostnadsbelopp för detta och arbete relaterat till det extra uppdraget slutförs utan att någon överenskommelse om det extra kostnadsbeloppet har nåtts, anses ett nytt kontrakt utan fastställt kostnadsbelopp ha etablerats mellan uppdragsgivaren och uppdragstagaren, och det är rimligt att tolka detta som att en rimlig skyldighet att betala extra utvecklingskostnader har uppstått.

Osaka District Court ruling, August 29, 2002 (Heisei 14)

Att hålla koll på nyckelord som “betalningsrelation” och “nytt kontrakt” kommer att hjälpa till att fördjupa förståelsen för denna dom.

För övrigt, i ovanstående dom, visades en annan mycket intressant punkt. Det är att mycket detaljerade justeringar, som placeringen av knappar och typsnittet för text, inte räknas som specifikationsändringar i detta sammanhang. Det relevanta avsnittet är som följer.

Emellertid, med tanke på att det i programvaruutveckling, på grund av dess natur, inte är så att detaljer som typsnittet för text som ska visas på skärmen och placeringen av knappar bestäms på stadiet för extern design, och att det är vanligt att vissa justeringar görs på detaljerna genom diskussioner mellan parterna även efter att specifikationerna har fastställts, bör det anses vara olämpligt att betrakta krav på detaljering av specifikationer som specifikationsändringar.

Osaka District Court ruling, August 29, 2002 (Heisei 14)

I domen användes det intressanta uttrycket “detaljering av specifikationer”.

• Fall där något som redan borde ha bestämts ändrades i efterhand
• Fall där man valde att inte bestämma något som kunde ha bestämts under processen

Det kan sägas att detta visar en tanke om att den juridiska behandlingen bör vara annorlunda i dessa fall.

Andra bekräftade exempel

Utöver detta, finns det fall där ytterligare utveckling och funktionskorrigeringar har godkänts, såsom:

• Fallet där antalet levererade program ökade till ungefär det dubbla jämfört med den ursprungliga planen (Domstolsbeslut i Tokyo den 22 april 2009 (Heisei 17))
• Fallet där arbetsperioden förlängdes till ungefär tre gånger den ursprungliga längden (Domstolsbeslut i Tokyo den 22 januari 2010 (Heisei 22))

Genom att organisera på detta sätt, kan vi se att förlängningen av arbetsperioden, som en bredare form av ytterligare utveckling, har antagits för att ge viss juridisk skydd.

“Överenskommelser om ytterligare utveckling och ökade avgifter” och “Ursprungligt kontrakts ingående” är separata frågor

En viktig punkt att notera om dessa frågor är att,

1. Scenariot “Har ett ursprungligt kontrakt om systemutveckling formellt ingåtts mellan de två företagen från början?”
2. Scenariot “Har ett kontrakt om ytterligare utveckling också formellt ingåtts för systemutvecklingen som ursprungligen ingicks?”

Domstolens bedömningskriterier skiljer sig i dessa fall. För att uttrycka det enkelt, domstolen har en tendens att,

• För 1, vara sträng (den erkänner sällan att ett kontrakt har ingåtts i situationer där det inte finns något kontrakt)
• För 2, vara relativt mild (den erkänner flexibelt ökade avgifter etc., även om det inte finns något kontrakt om ytterligare utveckling)

Det kan sägas. En mer detaljerad förklaring om 1 finns i en separat artikel.

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

Negativt exempel: Fall där det behandlades som inkluderat i liknande uppdragsinnehåll enligt lagen

Å andra sidan finns det rättsfall där en ökning av ersättningen inte godkändes. I det domslut som citeras nedan, uppstod en tvist om huruvida en ökning av ersättningen skulle tillåtas på grund av att innehållet i uppdraget ändrades efter att ett uppdragsavtal för systemutveckling hade ingåtts.

Den centrala frågan i detta fall är, (1) vad var innehållet i uppdraget som käranden accepterade i detta avtal, (2) om det fanns en överenskommelse mellan käranden och svaranden om att utöka omfattningen och öka ersättningen för det accepterade uppdraget, (utelämnat), och så vidare. (utelämnat)

Först och främst var detta avtal ett kontrakt där det överenskoms att ersättningen skulle vara ett fast belopp för kärandens accepterade uppdrag (kontrakt), och antalet steg, enhetspriser etc. var bara interna dokument som användes för att beräkna kontraktsbeloppet inom kärandens organisation, och ökningen av antalet steg etc. har inget att göra med kontraktsbeloppet. (utelämnat)

Som fastställt ovan, ändrades kärandens accepterade uppdrag den 25 februari 1987 (Showa 62), och begränsades till endast systemhantering, beräkning av kontraktskostnader och en del av verktygen, och resten skulle svaranden ta hand om. Ändringen av kärandens uppdrag efter ändringen ändrar inte det faktum att det är inom ramen för utvecklingsarbetet enligt det ursprungliga kontraktet, och ersättningen för detta arbete är helt täckt av det kontraktsbelopp som överenskommits som ett fast belopp vid tidpunkten för det ursprungliga kontraktet.

Dom av Tokyo District Court den 12 juni 1995 (Heisei 7)

I detta domslut bedömdes det att även om innehållet i uppdraget som tilldelades leverantören ändrades, var utvecklingsinnehållet inom ramen för det ursprungliga kontraktets innehåll, och det borde täckas inom den ursprungligen överenskomna ersättningen.

I slutändan, med tanke på vad ersättningen bestämdes på grundval av att utföra vilket arbete, kan det antas att det kommer att tillåtas att begära ytterligare ersättning för arbete som inte ingår där.

Och vad ersättningen ursprungligen var för att utföra vilket arbete, kommer inte bara att bedömas på kontraktet, utan också på protokoll etc. som bevis. Vikten av protokoll beskrivs mer detaljerat i artikeln nedan.

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

Hur bestäms ersättningen för ytterligare utveckling och funktionskorrigeringar?

Det är inte ovanligt att specifikationer som en gång verkade fastställda ändras senare inom systemutveckling. Varje gång detta händer, är det inte realistiskt att förbereda ett nytt skriftligt kontrakt och fortsätta med kontraktsarbetet. Om det finns frågor som bör läggas till eller korrigeras, och specifikationerna kan fastställas igen och ett memorandum kan slutas samman, hur ska ersättningen beräknas om projektet misslyckas utan att kunna genomföra sådana förfaranden?

En artikel som bör refereras till i sådana fall är den japanska handelslagen (Japanese Commercial Code) artikel 512, som jag citerar nedan (understrukna delar är mina egna).

Artikel 512 i den japanska handelslagen (Japanese Commercial Code): När en handlare utför en handling för någon annan inom ramen för sin verksamhet, kan han begära en rimlig ersättning.

Frågan med denna “rimliga ersättning” i artikeln är hur mycket det blir i konkreta situationer. Om man tittar på tidigare rättsfall, verkar det som att det har antagits att kostnaden bör bäras i proportion till arbetsbelastningen, mängden arbete eller perioden. Detta beror förmodligen på att systemutveckling är en typ av tjänsteverksamhet, och att huvudkostnaden i grunden är personalomkostnader.

Därför, trots den abstrakta naturen av termen “rimlig ersättning” i handelslagen, är det inte särskilt svårt att uppskatta marknadspriset för ytterligare ersättning i detta sammanhang. Låt oss titta på några rättsfall nedan.

Fall 1: Ett exempel där ytterligare ersättning beviljades i proportion till ökningen av arbetstid

Den totala utvecklingstiden baserad på denna specifikationsändring är rimligt att betrakta som 257,5 persondagar, och om detta omvandlas till en utvecklingskostnad per person och dag på 32 500 yen (i Appendix 3 är enhetspriset 650 000 yen per person och månad, och om man antar att antalet arbetsdagar i en månad är 20, blir utvecklingskostnaden per person och dag 32 500 yen) enligt detta utvecklingsuppdragsavtal, är det rimligt att betrakta den ytterligare utvecklingskostnaden baserad på denna specifikationsändringsbegäran som 8 368 750 yen.

Dom från Osaka District Court den 29 augusti 2002 (Heisei 14)

“Per person och dag” är nyckelordet här. Det indikerar att arbetstiden används som grund för beräkningen av ytterligare ersättning.

Fall 2: Ett exempel där ytterligare ersättning beviljades proportionellt mot antalet program

När vi överväger den lämpliga ersättningssumman i detta fall, inklusive den extra delen, är det viktigt att notera att största delen av utvecklingskostnaden för ett datorsystem består av teknikernas lönekostnader. Dessa lönekostnader korrelerar generellt med mängden program som skapas. Om vi tar det ursprungliga kontraktsbeloppet på 23 250 000 yen, dividerar det med antalet program (206) som slutfördes fram till den andra granskningen, och multiplicerar detta pris per program med antalet program (414) som passerade den tredje granskningen, får vi en summa på 46 725 728 yen (23,250,000 ÷ 206 × 414 = 46,725,728). Detta anses vara ett lämpligt belopp.

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

Det kan verka som att det finns många siffror att hålla reda på, men om du läser lugnt kommer du att se att det inte är några komplicerade beräkningar som görs. Utifrån det ursprungliga kontraktet bekräftas “hur mycket priset per program uppskattades till” och sedan görs en enkel multiplikation av “pris × kvantitet”.

Fall 3: Ett exempel där ytterligare ersättning beviljades proportionellt mot längden på perioden

I kontrakt A3 fastställdes att 60 miljoner yen skulle betalas som ersättning för arbetet som utfördes av käranden som en semi-delegation under perioden från januari till mars 2005 (Heisei 17). Samtidigt ingick obetalt arbete i arbetet som utfördes efter april samma år. Precis som föregående år förväntades arbetsbelastningen öka efter mars, med början av det nya läsåret och driftsättningen av systemet för kursregistrering och liknande. Med tanke på dessa omständigheter, baserat på de 60 miljoner yen som fastställdes som ersättning för arbetet under de tre månaderna, skulle det vara rimligt att ersättningen för arbetet från april till september 2005 (Heisei 17), en period på sex månader, skulle vara 120 miljoner yen.

Dom från Tokyo District Court den 22 januari 2010 (Heisei 22)

Ovanstående dom indikerar att ytterligare ersättning för förlängda perioder också ska beräknas med enkel proportionell beräkning.

Sammanfattning

Som vi har sett i flera rättsfall ovan, verkar det finnas vissa lagar och gemensamma punkter när det gäller hur lagen behandlar extra ersättning för programmerares och ingenjörers arbete. I princip verkar det som om man försöker beräkna detta så enkelt som möjligt, baserat på relativt objektiva indikatorer som den tid som spenderats, den formella arbetsmängden (som levererade program), och den tid och period som arbetats.

Om man tänker på att dessa extra utvecklingar och funktionsändringar uppstår just för att man misslyckats med att exakt beräkna arbetsmängden eller följa en strikt process, kan det verka tråkigt att extra ersättning uppstår bara baserat på den tid som lagts ner, den formella mängden arbete som utförts, eller den tid som spenderats. Men om vi ser det ur leverantörens perspektiv, även om vi strävar efter att prioritera kundens intressen i vårt arbete, är det meningsfullt ur en riskhanteringssynpunkt att det finns en god chans att dessa rättigheter erkänns enligt lagen.