Hvordan man håndterer situationer, hvor systemudviklingsarbejde er afbrudt på grund af brugerens omstændigheder

Systemudviklingsopgaver tager ofte form af langvarige projekter. Men hvad sker der, hvis brugeren ensidigt siger noget i retning af “Vi har ikke længere brug for det system, så du behøver ikke at bygge det”, efter at systemudviklingen er begyndt? Hvad kan leverandøren, der har påtaget sig opgaven, gøre i en sådan situation?

I denne artikel vil vi gennemgå de særlige karakteristika ved kontrakter om systemudvikling og forklare, hvordan man kan håndtere sådanne situationer.

Betydningen af at overveje afbrydelser på grund af brugerens omstændigheder

En kontrakt om systemudvikling har flere karakteristiske træk, når man ser på den som en kontrakt. Et af dem er, at projektets varighed normalt strækker sig over en længere periode, og at leverandøren, sammen med stor skønsbeføjelse, bærer en betydelig forpligtelse til at styre projektet. Den samlede indhold af leverandørens projektledelsesforpligtelser er detaljeret forklaret i følgende artikel.

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

En anden karakteristik er, at brugeren, selvom de er en kunde, har en bred forpligtelse til at samarbejde med leverandørens arbejde. Da det er et system, der bruges internt i virksomheden, kan det ikke bare “kastes” til leverandøren. Der er en forpligtelse til at samarbejde passende fra virksomhedens interne side, så leverandøren kan udøve sin ekspertise og udføre sit arbejde. Dette er detaljeret forklaret i følgende artikel.

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

Hvis vi kort sammenfatter ovenstående, er der mellem leverandøren og brugeren både en betalingsrelation mellem “ekstern leverandør”, der udvikler systemet, og “kunden”, der betaler for det, og samtidig er der også et aspekt, hvor de skal samarbejde mod det fælles mål om at fuldføre projektet, som om de var “partnere”. Denne kompleksitet i relationerne er normalt ikke til stede i en simpel skrædder af skræddersyede dragter, og det er en stor karakteristik ved kontrakter omkring systemudvikling. Konflikter omkring systemudvikling er på grund af denne kompleksitet i relationerne, og når de først er indviklede, kan det være kompliceret at afgøre, hvordan begge parters relationer juridisk skal organiseres.

At overveje problemet med, hvordan man skal forstå begge parters rettigheder og forpligtelser, når brugeren ændrer mening og pludselig siger, “Vi har alligevel ikke brug for det system, så du behøver ikke fortsætte projektet”, har en vis betydning i at præsentere et eksempel på juridisk tænkning i lyset af disse komplekse kontraktforhold. Nedenfor vil vi organisere de spørgsmål, der skal overvejes efter at have antaget en sådan situation.

Først skal vi organisere årsagerne til opsigelsen

Set fra leverandørens synspunkt kan der være tilfælde, hvor “brugeren ensidigt ønsker at afbryde projektet”, men det er ikke nødvendigvis sådan, at denne opfattelse altid deles med brugeren. Lad os antage et eksempel, hvor et projekt var i gang for at udvikle et system til at administrere personale, der arbejder på udenlandske baser, og senere blev planen om at ekspandere til udlandet trukket tilbage, hvilket gjorde udviklingen af et sådant system unødvendigt. Det er sandt, at hvis man kun ser på denne forklaring, kan det tolkes som en ensidig ændring af mening fra brugerens side.

Men hvad nu hvis der var faktiske brud på projektledelsesforpligtelserne fra leverandørens side, såsom forsinkelser i forskellige faser, og at vanskelighederne med at fremskride med udviklingen også var en af årsagerne til ændringen i virksomhedens politik?

Som nævnt tidligere er systemudvikling noget, hvor både leverandøren og brugeren deler betydelige forpligtelser og går frem i tæt samarbejde. Derfor, selvom det var brugeren, der først ønskede at afbryde, og leverandøren troede, at det var en opsigelse på grund af brugerens egen bekvemmelighed, skal man være opmærksom på, at der er en mulighed for, at leverandøren kan blive påpeget for at have årsager til at bære skylden, og at det kan blive hævdet, at det er en annullering baseret på manglende opfyldelse af forpligtelser eller en gensidig opsigelse.

Om det er en opsigelse på grund af egen bekvemmelighed, en annullering baseret på manglende opfyldelse af forpligtelser, eller en gensidig opsigelse, afhænger ofte af projektets fremskridt og forløbet af tidligere forhandlinger, og tendensen er at dømme individuelt for hvert tilfælde. Derfor, hvis leverandøren går videre med efterbehandlingen under den opfattelse, at det er en opsigelse på grund af brugerens egen bekvemmelighed, er det vigtigt at efterlade en klar registrering af dette i mødereferater og lignende, for at undgå fremtidige konflikter om dette punkt.

Næste skridt: Kontroller bestemmelserne for honorarkrav og erstatning

Efter at have taget ovenstående punkter i betragtning, hvis samtalen kan fortsætte som en brugerinitieret opsigelse, vil det næste skridt være at overveje, om leverandøren kan kræve honorar fra brugeren baseret på fuldførelsesgraden, og om det er muligt at kræve erstatning for skader.

Den bestemmelse, der skal henvises til i sådanne tilfælde, varierer afhængigt af kontrakttypen. Kontrakter om systemudvikling kan generelt opdeles i entreprisekontrakter og quasi-mandatkontrakter.

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

Og i tilfælde af quasi-mandatkontrakter og entreprisekontrakter har den japanske civillov (Japansk Civillov) følgende bestemmelser:

a.) I tilfælde af quasi-mandatkontrakter
Honorarkrav: Japansk Civillov Artikel 648, stk. 3
Når udførelsen afsluttes midtvejs på grund af årsager, der ikke kan tilskrives mandatar, kan mandatar kræve honorar i forhold til den del af udførelsen, der allerede er udført.
Erstatningskrav: Japansk Civillov Artikel 651
1. Mandatet kan til enhver tid opsiges af begge parter.
2. Hvis en af parterne opsiger mandatet på et tidspunkt, der er ugunstigt for den anden part, skal denne part kompensere den anden part for skaden. Dog gælder dette ikke, hvis der er uundgåelige omstændigheder.

b.) I tilfælde af entreprisekontrakter
Erstatningskrav: Japansk Civillov Artikel 641
Så længe entreprenøren ikke har fuldført arbejdet, kan bestilleren til enhver tid opsige kontrakten ved at kompensere for skaden.

Desuden antages det, at omfanget af erstatning baseret på Japansk Civillov Artikel 641 ikke kun omfatter de allerede afholdte omkostninger, men også “den fortjeneste, der ville være opnået, hvis kontrakten ikke var blevet opsagt”. Dette skyldes, at det er meningsløst for loven at tvinge fuldførelsen af arbejdet, der er blevet unødvendigt fra bestillerens synspunkt, og i sådanne tilfælde er det mere rationelt at sikre entreprenørens fortjeneste gennem betaling af et tilsvarende beløb.

Det skal dog bemærkes, at der ofte er tilfælde, hvor erstatning baseret på Japansk Civillov Artikel 641 er udelukket i individuelle kontrakter mellem leverandøren og brugeren. I sådanne tilfælde vil de individuelle aftaler mellem parterne (dvs. kontrakten) have forrang, og det kan antages, at disse bestemmelser i civilloven ikke vil gælde, så vær opmærksom på dette.

Yderligere fremskridt med bevisførelse af volumen og skader

I tilfælde af opsigelse på grund af brugerens egen bekvemmelighed, er det almindeligt at se i kontrakter, at der kan fremsættes krav om betaling for det udførte arbejde (dvs. den fuldførte del) og krav om erstatning for skader. Derfor er det normalt nødvendigt for leverandørsiden at fremlægge beviser for det udførte arbejde og skader for at fremsætte et krav om erstatning.

Imidlertid kan det forventes, at bevisførelse af det udførte arbejde, dvs. graden af fuldførelse, kan være en meget krævende opgave, hvis det skal gøres i praksis. Dette skyldes, at det kan være en betydelig mængde arbejde at gennemføre interviews for at bekræfte fremskridt, især hvis der er flere underleverandører, for at afgøre, i hvilken grad forskellige arbejdsopgaver er blevet fuldført. Desuden vil det være en enorm opgave at lave dokumentation til at understøtte resultaterne af disse interviews og at dokumentere indholdet af interviewene selv. Hvis der er risiko for, at bevisførelsen stadig betragtes som utilstrækkelig trods al denne indsats, kan det arbejde, der er lagt i forberedelsen af bevisførelsen, ende med at være forgæves, hvilket er en af mange udfordringer.

En mulig løsning på disse problemer kunne være at gøre det klart i kontrakten fra starten, at hvis kontrakten opsiges undervejs, vil beregningen blive foretaget på daglig basis op til opsigelsestidspunktet, for at gøre beregningerne mere enkle. Desuden, i betragtning af den indsats, der kræves for at bevise det udførte arbejde, kan man overveje at opgive kravet om betaling for det udførte arbejde og i stedet fremsætte krav om “omkostningerne forbundet med udviklingen af den allerede fuldførte del”. Hvis det er interne udviklingsomkostninger, kan de ofte nemt beregnes med en simpel formel som “arbejdstimer x enhedspris”. Især for projekter med lav profitmargin kan det være mere realistisk at prioritere krav baseret på omkostninger frem for det udførte arbejde, da dette kan gøre det lettere at inddrive gæld, samtidig med at tabene kompenseres.

Hvad bør brugeren overveje?

Forresten, der er også punkter, som brugeren bør overveje på forhånd, hvis de ønsker at opsige aftalen af egen vilje. Det er at bekræfte et omtrentligt beløb for skadeserstatning, der skal betales til leverandøren. Når vi siger “omtrentligt”, er det for at få en generel ide om, hvad der kan forventes i de efterfølgende forhandlinger (selvom det ikke er det nøjagtige beløb, er det nok, da det ville være kontraproduktivt, hvis erklæringen om opsigelse blev forsinket).

Hvis det bekræftede omtrentlige beløb vurderes som urimeligt højt, bør du bede om en forklaring. Men hvis du forsøger at føre urimelige forhandlinger for at reducere betalingsbeløbet, kan det også føre til unødvendige retssager og yderligere komplikationer. Hvis forhandlingerne mellem de to parter ser ud til at være vanskelige, kan det være en god ide at konsultere en advokat.

I denne artikel har vi forklaret med den forudsætning, at en kontrakt om systemudvikling er indgået. Men i virkeligheden er der mange tilfælde, hvor det er et stridspunkt, om kontrakten overhovedet er gyldigt indgået i systemudviklingssituationer. Vi har forklaret dette mere detaljeret i artiklen nedenfor.

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

Opsummering

I denne artikel har vi forklaret processen for at håndtere situationer, hvor et projekt afbrydes på grund af brugerens omstændigheder. Det vigtigste punkt i denne artikel er dog, at det er nødvendigt at overveje, om det virkelig kan siges at være brugerens egen skyld, og om leverandøren virkelig ikke har begået nogen fejl.

Det er karakteristisk for systemudviklingsprojekter, at både leverandører og brugere påtager sig store forpligtelser. Derfor er det vigtigt at overveje på forhånd, om det virkelig er muligt at placere skylden ensidigt hos den anden part. Hvis man ikke gør det, kan det risikere at hælde olie på ilden og forværre situationen, hvilket man bør være opmærksom på.