Forholdet mellem forsinkelse i systemudviklingsfristen og juridisk forsinkelse i opfyldelse

Et projekt som systemudvikling er på en måde altid en kamp mod tidsfristen. Fra et juridisk perspektiv kan man overveje “risikoen, der opstår, hvis man ikke når tidsfristen” i forbindelse med systemudvikling.

I denne artikel vil vi forklare, under hvilke omstændigheder “forsinkelse af tidsfristen” vil blive behandlet som en forsinkelse i opfyldelsen, og vil resultere i juridisk ansvar for manglende opfyldelse af forpligtelser og lignende.

Hvad er leveringstid i systemudvikling?

Leveringstid i generelle termer

I generelle termer refererer “leveringstid” til den deadline, der er sat for levering af et produkt, der er anmodet af en kunde. Selv i udviklingsmiljøer, hvor uforudsete problemer kan opstå, er det ikke ualmindeligt, at leveringstider skal overholdes strengt. Hvis der er en magtubalance mellem ordregiveren og ordremodtageren, kan tendensen til at overholde leveringstider være endnu mere udtalt. Eller, hvis leveringstiden overskrides, kan der være tilfælde, hvor der gives en rabat i forhold til overskridelsen, eller hvor overskydende arbejde udføres gratis. Uanset hvad, er leveringstid generelt vigtig for at opretholde et tillidsforhold med handelspartnere.

Vi har også forklaret konceptet om “fuldførelse af arbejde” i lovens forstand og leveringstid i en anden artikel.

https://monolith.law/corporate/completion-of-work-in-system-development [ja]

Leveringstid set fra et juridisk perspektiv

Fra et juridisk synspunkt opstår der en forpligtelse (gæld) for leverandøren til at levere systemet, når en kontrakt er indgået mellem leverandøren og brugeren. Leveringstiden kan siges at være en begrænsning for, hvornår denne gæld skal opfyldes. Med andre ord, en forsinkelse i leveringstiden kan betragtes som en form for misligholdelse af gæld, nemlig forsinket opfyldelse. Derfor vil leverandøren være ansvarlig for misligholdelse af gæld på grund af forsinket opfyldelse (Japansk Civil Code § 412) i tilfælde af forsinkelse i leveringstiden forårsaget af leverandørens forsætlige eller uagtsomme handlinger.

1. Når der er en fastsat frist for opfyldelse af en gæld, pådrager gældneren sig ansvaret for forsinkelse fra det tidspunkt, hvor fristen er nået.
2. Når der er en usikker frist for opfyldelse af en gæld, pådrager gældneren sig ansvaret for forsinkelse fra det tidspunkt, hvor han blev klar over, at fristen var nået.
3. Når der ikke er fastsat en frist for opfyldelse af en gæld, pådrager gældneren sig ansvaret for forsinkelse fra det tidspunkt, hvor han modtog en anmodning om opfyldelse.

Japansk Civil Code § 412

Når denne artikel taler om “at pådrage sig ansvar”, refererer det simpelthen til erstatningsansvar.

Når gældneren ikke opfylder sin gæld i overensstemmelse med dens formål, kan kreditor kræve erstatning for den skade, der er forårsaget deraf. Det samme gælder, når gældneren ikke er i stand til at opfylde sin gæld på grund af en årsag, der kan tilskrives ham.

Japansk Civil Code § 415

Desuden, hvis brugeren har fastsat en “rimelig periode” og har anmodet leverandøren om at levere inden denne dato, men leverandøren ikke har leveret, kan brugeren også annullere kontrakten.

Når en af parterne ikke opfylder sin gæld, kan den anden part, efter at have fastsat en rimelig periode og anmodet om opfyldelse inden for denne periode, annullere kontrakten, hvis der ikke er nogen opfyldelse inden for denne periode.

Japansk Civil Code § 541

For en generel forklaring på denne “annullering” mulighed i sådanne tilfælde, se følgende artikel for detaljer.

https://monolith.law/corporate/cancellation-of-contracts-in-system-developme [ja]

Alle leveringsforsinkelser er ikke nødvendigvis juridiske misligholdelser

Det er vigtigt at bemærke, at det overfladiske faktum, at “leveringstiden ikke blev overholdt”, ikke nødvendigvis betyder en misligholdelse i form af forsinket opfyldelse. For at en simpel leveringsforsinkelse skal blive en juridisk forsinkelse, skal flere betingelser være opfyldt, som vist nedenfor.

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

Da systemudvikling normalt er et projekt, hvor både brugeren og leverandøren har forpligtelser, kan det være, at begge parter bliver fundet skyldige i misligholdelse, og skadeserstatningen bliver modregnet.

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

For at tilføje til dette emne, er det normalt “accept” af produktet, der foretages tæt på leveringstiden. Accept er detaljeret behandlet i artiklen nedenfor. Her forklarer vi tilfælde, hvor levering ikke er fuldført, fordi brugeren ikke accepterer.

https://monolith.law/corporate/estimated-inspection-of-system-development [ja]

Pointen er, at “ikke at overholde leveringstiden = misligholdelse” ikke er så simpelt. Selvom vi taler om forsinkelse i leveringstiden, kan årsagen være forskellig, enten det er leverandørens skyld eller brugerens skyld. Der er en stor forskel mellem det formelle faktum “forsinkelse i deadline” og den faktiske misligholdelse “forsinket opfyldelse”.

Retspraksis omhandlende forsinket opfyldelse

Lad os se på en retssag, hvor det blev diskuteret, om det er muligt at forfølge ansvar for manglende opfyldelse af forpligtelser på grund af forsinket levering. Selvom det er en tvist om leveringsfrister, er det vigtigt at organisere sagen på baggrund af grundlæggende systemudvikling, uanset om det er “brugerens samarbejdspligt”, “projektledelsespligt” eller andre konflikter.

Eksempel på en sag, hvor forsinket opfyldelse blev modregnet med brugerens overtrædelse af samarbejdspligt og uagtsomhed

I den dom, vi citerer nedenfor, blev en sag anlagt af en bruger, fordi leverandørens leveringstid var forsinket. Denne påstand blev delvist accepteret i retten, men samtidig blev det påpeget, at manglen på passende samarbejde fra brugerens side også var en faktor, og det blev indikeret, at 40% af skaden forårsaget af forsinkelsen i leveringstiden var brugerens ansvar.

Overvejelserne ovenfor viser, at brugeren ikke har ydet passende samarbejde, da han ikke har truffet rettidige og passende beslutninger, såsom at løse udestående spørgsmål, som leverandøren har bedt om at få løst inden for den fastsatte tidsramme.
Men hvad angår brugerens påstand om leverandørens overtrædelse af samarbejdspligten i forbindelse med brugerens anmodning om tilføjelse eller ændring af funktioner, kan det ikke siges, at brugerens anmodning om tilføjelse eller ændring af udviklingsindholdet, som var forventet i det grundlæggende design, udgør en overtrædelse af brugerens samarbejdspligt, og leverandørens påstand er ubegrundet.
Desuden er der ingen grund til leverandørens påstand om overtrædelse af samarbejdspligten i forbindelse med brugerens overdrevne krav, da det ikke kan anerkendes, at brugeren har stillet overdrevne krav i forhold til honoraret for denne computersystemudviklingskontrakt.
Snarere kan det siges, at der var upassende aspekter af leverandørens projektledelse, da leverandøren først blev klar over antallet af transaktioner (antallet af “transaktioner” pr. juli eller august samme år) efter januar 1999 (1999 i den gregorianske kalender), og da leverandøren efter den 31. maj samme år foreslog at bære en urimelig ekstra kontraktgebyr og reducere antallet af transaktioner.

Tokyo District Court, 10. marts 2004 (2004 i den gregorianske kalender)

Denne dom anerkendte forsinket opfyldelse på grund af leverandørens forsinkede levering, men påpegede også, at en del af årsagen var, at brugeren ikke havde løst bekymringer fremsat af leverandøren, og anerkendte brugerens krav ved at “skære” 60% af den skade, som brugeren hævdede. Dette er en “modregning for uagtsomhed”, ligesom i tilfælde af trafikulykker, hvor skadelidte også er skyldige.

I denne domsafgørelse optræder udtrykket “samarbejdspligt” mere end 40 gange i hele teksten, inklusive indholdsfortegnelsen. Fra et juridisk synspunkt kan det siges, at essensen snarere er at skelne mellem leverandørens projektledelsespligt og brugerens samarbejdspligt.

Eksempel på en sag, hvor forsinket opfyldelse blev fuldt anerkendt

Den følgende dom er en sag, hvor leverandørens ansvar for forsinket levering blev fuldt bevist, og ansvar for manglende opfyldelse af forpligtelser på grund af forsinket opfyldelse blev anerkendt. I dette tilfælde blev kontrakten annulleret af brugeren lige før systemet blev færdigt, og leverandøren anlagde sag, men brugeren hævdede, at forsinkelsen var årsagen til tvisten.

Det kan ikke benægtes, at leverandøren har givet forskellige ændringsinstruktioner til designsystemet, og at færdiggørelsen er blevet forsinket i nogen grad som følge heraf. Især har leverandøren givet endelige ændringsinstruktioner den 23. juni 2005 (2005 i den gregorianske kalender), så det kan anerkendes, at det ikke kan tilskrives leverandøren, at funktionen “automatisk beregning af detaljerede elementer for kantsten” baseret på disse instruktioner ikke er færdig.
Men de andre ændringsinstruktioner fra leverandøren blev givet inden begyndelsen af april samme år, og det kan ikke anerkendes, at der er omstændigheder, der skal fortolkes som at ændre planen for at fuldføre designsystemet (bortset fra den del, der er ændret på grund af leverandørens ændringsinstruktion den 23. juni samme år).
Det kan ikke anerkendes, at leverandøren havde fuldført designsystemet til en grad, hvor det faktisk kunne drives og bruges ved udgangen af juni samme år, bortset fra den del, der blev ændret på grund af leverandørens ændringsinstruktion den 23. juni, og det kan anerkendes, at vigtige dele af systemet, såsom manglende evne til at vise billeder eller manglende funktionalitet i søgefunktionen, ikke var færdige.
(Omitted) Det kan antages, at leverandøren ikke har forvaltet arbejdsprocedurerne i forbindelse med systemudviklingen tilstrækkeligt.
Derfor kan det ikke anerkendes, at den primære årsag til, at leverandøren ikke kunne overholde leveringstiden, ligger i leverandørens instruktioner, og det kan ikke anerkendes, at der ikke er nogen årsager, der skal tilskrives leverandøren.

Tokyo District Court, 16. februar 2007 (2007 i den gregorianske kalender)

I denne dom blev det indikeret, at det ikke kunne tilskrives leverandøren, at en funktion, der ikke var færdig på grund af en ændringsinstruktion givet af brugeren en uge før den planlagte leveringsdato, ikke var færdig. Men ved at tage højde for følgende:

• Punkter, der endnu ikke er blevet imødekommet, selvom ændringsinstruktioner blev givet flere måneder i forvejen
• Punkter, hvor en e-mail med den forventede fuldførelsesdato er blevet sendt fra leverandøren efter at disse instruktioner er blevet givet
• Ufuldstændige dele er vigtige dele af systemet, såsom implementering af billedvisning og søgefunktioner, og det faktum, at disse ikke er blevet imødekommet, er et element, der understøtter overtrædelsen af projektledelsespligten

blev ansvar for manglende opfyldelse af forpligtelser på grund af forsinket opfyldelse anerkendt.

Hvad vi kan lære af begge domme

Når vi ser på begge domme, kan vi sige, at problemet med “leveringstid” i systemudvikling i sidste ende er et spørgsmål om, hvordan man trækker grænsen mellem brugerens samarbejdspligt og leverandørens projektledelsespligt. Med andre ord, da juridisk forsinket opfyldelse er en form for ansvar for manglende opfyldelse af forpligtelser, bliver det naturligt et spørgsmål, om der har været nogen overtrædelse af pligten fra leverandørens side. Og for at overveje, om det skadebegivenhed, der er blevet manifesteret som et resultat (dvs. tabet for brugeren som følge af forsinkelsen i leveringstiden), kan tilskrives leverandøren, er det nødvendigt at se på, hvordan man fortolker brugerens samarbejdspligt på samme tid.

Opsummering

Når man hører udtrykket “forsinket opfyldelse”, kan det ved første øjekast synes at være en omskrivning af “forsinket levering” på grund af betydningen af ordene. Men forsinket opfyldelse er en form for misligholdelse af gæld. Derfor er det mere passende at forstå det som en “overtrædelse af projektledelsesforpligtelsen”.

Spørgsmålet om “leveringstid” i forbindelse med systemudviklingsprojekter bør ikke kun fokuseres på den overfladiske tid før og efter levering, men det er vigtigt at omorganisere det som et spørgsmål om leverandørens projektledelsesforpligtelse og brugerens samarbejdsforpligtelse.