Hur man hanterar när systemutvecklingsarbetet avbryts på grund av användarens omständigheter

Systemutveckling är ofta en process som sträcker sig över en längre tid i form av ett projekt. Men vad kan leverantören göra om de, efter att ha påbörjat systemutvecklingen, ensidigt får höra från användaren att “det systemet behövs inte längre, så du behöver inte skapa det”?

I denna artikel kommer vi att organisera de unika egenskaperna hos ett systemutvecklingskontrakt och förklara vilka åtgärder som kan vidtas i sådana fall.

Betydelsen av att överväga avbrott på grund av användarens omständigheter

I ett systemutvecklingskontrakt finns det flera särdrag att notera när man ser det ur ett kontraktsmässigt perspektiv. Ett av dessa är att projektets varaktighet vanligtvis sträcker sig över en längre tid, och att leverantören, tillsammans med stor diskretion, bär ett stort ansvar för att hantera projektet. En detaljerad förklaring av det övergripande innehållet i leverantörens projektledningsansvar finns i följande artikel.

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

En annan punkt är att användaren, trots att de är en kund, har ett omfattande ansvar att samarbeta med leverantörens arbete. Eftersom det är ett system som används internt i företaget, kan det inte helt och hållet överlämnas till leverantören. Det finns en skyldighet att samarbeta lämpligt från företagets inre så att leverantören kan utöva sin expertis i sitt arbete. En detaljerad förklaring av detta finns i följande artikel.

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

Om vi sammanfattar ovanstående innehåll kortfattat, finns det mellan leverantören och användaren en relation av “externa operatörer” som utvecklar systemet och “kunder” som betalar för det, men samtidigt finns det också en aspekt av att vara “kollegor” som bör samarbeta mot det gemensamma målet att uppnå projektet. Denna komplexitet i relationen är inte vanligt förekommande hos en skräddare som bara gör skräddarsydda kostymer, och det är en stor egenskap hos kontrakt relaterade till systemutveckling. Konflikter relaterade till systemutveckling är på grund av denna komplexitet i relationen, och om de en gång blir invecklade, blir det ofta komplicerat att juridiskt organisera relationen mellan parterna.

Att överväga frågan om hur man ska förstå rättigheter och skyldigheter mellan parterna när användaren ändrar sig och plötsligt säger “Vi behöver inte det systemet längre, så du behöver inte fortsätta med projektet” har en innebörd av att presentera ett praktiskt exempel på att tillämpa juridiskt tänkande inför denna komplexa kontraktsrelation. Nedan kommer vi att organisera de frågor som bör övervägas efter att ha antagit ett sådant scenario.

Först, organisera skälen till att uppsägningen föreslogs

Från leverantörens perspektiv kan det finnas fall där “användaren ensidigt vill avbryta projektet”, men det är inte alltid att denna uppfattning delas med användaren. Ett exempel kan vara ett projekt för att utveckla ett system för att hantera personal på utländska kontor. Senare drogs planerna för utländsk expansion tillbaka, vilket gjorde utvecklingen av systemet onödigt. Visst, utifrån denna förklaring kan det tolkas som en ensidig förändring av åsikt från användarens sida.

Men vad händer om det, i bakgrunden till detta beslut, fanns faktiska brott mot projektledningsförpliktelser från leverantörens sida, såsom förseningar i olika steg, och att utvecklingen i sig var svår att genomföra, vilket också bidrog till företagets policyändring?

Som nämnt tidigare är systemutveckling något som både leverantören och användaren tar på sig stora skyldigheter för och går framåt i nära samarbete. Därför, även om det var användaren som först ville avbryta och leverantören trodde att det var en uppsägning på grund av användarens personliga omständigheter, bör man vara medveten om att det finns en möjlighet att leverantörens ansvar pekas ut och att det kan hävdas att det är en upplösning baserad på kontraktsbrott eller en överenskommen uppsägning.

Om det är en uppsägning på grund av personliga skäl, en upplösning baserad på kontraktsbrott, eller en överenskommen uppsägning, tenderar dessa punkter att bedömas individuellt beroende på projektets framsteg och historiken för tidigare förhandlingar. Därför, om leverantören fortsätter med efterbehandlingen under antagandet att det är en uppsägning på grund av användarens personliga skäl, är det viktigt att tydligt dokumentera detta i mötesprotokoll och liknande för att undvika framtida tvister om denna punkt.

Nästa steg: Bekräfta lagparagraferna för ersättningskrav och skadestånd

Med ovanstående i åtanke, om vi kan fortsätta diskussionen som en uppsägning på grund av användarens egen bekvämlighet, kommer vi nästa att överväga om det är möjligt för leverantören att begära ersättning från användaren baserat på arbetsframsteg, eller begära skadestånd.

Den lagparagraf som bör refereras till i dessa fall varierar beroende på kontraktstyp. Kontrakt relaterade till systemutveckling kan grovt indelas i entreprenadkontrakt och kvasi-ombudskontrakt.

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

Och i fallet med kvasi-ombudskontrakt och entreprenadkontrakt, har den japanska civilrätten (Japanska Civil Code) följande bestämmelser:

a.) I fallet med kvasi-ombudskontrakt
Ersättningskrav: Japanska Civil Code Artikel 648, Paragraf 3
När uppdraget avslutas mitt i utförandet på grund av orsaker som inte kan tillskrivas ombudet, kan ombudet begära ersättning i proportion till det arbete som redan utförts.
Skadeståndskrav: Japanska Civil Code Artikel 651
1. Uppdraget kan avbrytas av båda parter när som helst.
2. Om en part avbryter uppdraget vid en ogynnsam tidpunkt för den andra parten, måste den parten ersätta den andra partens skada. Detta gäller dock inte om det finns oundvikliga skäl.

b.) I fallet med entreprenadkontrakt
Skadeståndskrav: Japanska Civil Code Artikel 641
Så länge entreprenören inte har slutfört arbetet, kan beställaren när som helst avbryta kontraktet genom att ersätta skadan.

Notera att omfånget av skadestånd baserat på Japanska Civil Code Artikel 641 inte bara inkluderar redan utbetalade kostnader, utan också “vinster som skulle ha erhållits om kontraktet inte hade avbrutits”. Detta beror på att det är meningslöst att lagen tvingar färdigställandet av ett arbete som beställaren inte längre behöver, och i sådana fall är det mer logiskt att garantera entreprenörens vinst genom att betala samma belopp.

Det bör dock noteras att det inte är ovanligt att skadestånd baserat på Japanska Civil Code Artikel 641 utesluts i individuella kontrakt mellan leverantören och användaren. I sådana fall kommer det individuella avtalet mellan parterna (dvs. kontraktet) att ha företräde, och det kan antas att dessa bestämmelser i civilrätten inte kommer att tillämpas, så var försiktig.

Fortsätt att bevisa volym och skada

När en användare avbryter av egen vilja, är det vanligt att kontraktet tillåter krav på avgifter för utfört arbete (det vill säga den slutförda delen) och skadestånd. Därför måste leverantören vanligtvis bevisa volymen och skadan för att kunna göra ett skadeståndskrav.

Men att bevisa denna volym, eller snarare graden av slutförande, kan vara en mycket krävande uppgift. Detta beror på att det kan bli en betydande mängd arbete att genomföra intervjuer för att kontrollera framstegen, särskilt om det finns flera underleverantörer, och att avgöra i vilken utsträckning varje arbetsuppgift har slutförts. Dessutom, om du måste skapa dokument för att stödja resultaten från intervjuerna och dokumentera innehållet i intervjuerna själva, kommer arbetsbördan att bli enorm. Det finns också många svårigheter, som risken att allt detta arbete kan vara förgäves om bevisningen anses otillräcklig.

Med tanke på dessa punkter kan en lösning vara att från början av kontraktet klargöra att om kontraktet avbryts i förtid, kommer avgifterna att beräknas pro rata per dag fram till avbrytandet, eller att göra beräkningarna enklare på andra sätt. Dessutom, med tanke på att det är tidskrävande att bevisa volymen, kan du överväga att ge upp kravet på volymen och istället kräva “kostnaden för att utveckla den del som redan har slutförts”. Om det är interna utvecklingskostnader kan de ofta enkelt beräknas med en enkel formel som “arbetstid x enhetskostnad”. Särskilt för projekt med låg lönsamhet kan det vara mer realistiskt att prioritera krav baserade på kostnader snarare än volym, vilket gör det lättare att återvinna fordringar samtidigt som förluster kompenseras.

Vad bör användare överväga från deras sida?

För övrigt finns det punkter som användare bör överväga i förväg, även när de tar upp frågan om att avsluta avtalet av egen vilja. Det handlar om att bekräfta en ungefärlig summa för den skadestånd som bör betalas till leverantören, till exempel hur mycket det sannolikt kommer att bli. När vi säger “ungefärlig” här, menar vi att sätta en grov riktlinje för att få en uppfattning om hur förhandlingarna kommer att fortsätta (det är kontraproduktivt om uttrycket av avsikten att avsluta försenas, så en exakt summa är inte nödvändig).

Om den bekräftade ungefärliga summan bedöms vara orimligt hög bör du begära en förklaring till varför. Men om du försöker förhandla orimligt för att hålla nere betalningsbeloppet, finns det också en risk att situationen blir ännu mer komplicerad genom meningslösa rättsliga tvister. Om förhandlingarna mellan de två parterna verkar bli svåra, kan det vara en idé att rådfråga en advokat.

För övrigt har denna artikel förklarat med antagandet att ett avtal om systemutveckling har ingåtts, men i verkligheten finns det inte få fall där det är en tvist om “om avtalet har ingåtts giltigt” i första hand i scenen för systemutveckling. Detta förklaras mer detaljerat i följande artikel.

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

Sammanfattning

I denna artikel har vi förklarat hur man hanterar situationer där ett projekt avbryts på grund av användarens omständigheter. Det viktigaste att notera från denna artikel är dock att det är nödvändigt att överväga om det verkligen kan sägas vara användarens eget ansvar, och om leverantören verkligen inte hade något fel.

En av de särskilda egenskaperna hos ett systemutvecklingsprojekt är att både leverantören och användaren tar på sig stora skyldigheter. Med detta i åtanke, om man inte noggrant överväger på förhand om det verkligen är möjligt att ensidigt skylla på den andra parten, kan det leda till en situation som bara häller olja på elden. Detta bör man vara medveten om.