Relationen mellan förseningar i systemutvecklingens leveranstid och laglig prestandaförsening

Projekt som involverar systemutveckling är i viss mening alltid en kamp mot tidsfristen. Från ett juridiskt perspektiv kan vi överväga “risken som uppstår om vi inte hinner klart i tid” när det gäller “tidsfristen” i systemutveckling.

I denna artikel kommer vi att förklara under vilka omständigheter “förseningar i tidsfristen” behandlas som dröjsmål i prestation och leder till juridiskt ansvar för kontraktsbrott och liknande.

Vad innebär leveranstid i systemutveckling?

Leveranstid i allmänhet

I allmänhet syftar “leveranstid” på den deadline då en produkt som efterfrågas av en kund ska levereras. Även i utvecklingsmiljöer, där oväntade problem kan uppstå, är det inte ovanligt att leveranstiden strikt följs. Om det finns en maktobalans mellan beställaren och leverantören, tenderar efterlevnaden av leveranstiden att bli ännu mer framträdande. Alternativt kan det finnas fall där rabatter ges för förseningar, eller där övertidsarbete inte debiteras och görs kostnadsfritt. Oavsett är leveranstiden generellt sett viktig för att upprätthålla förtroendet med affärspartners.

Vi har också förklarat konceptet “arbetsfärdigställande” och leveranstid ur ett juridiskt perspektiv i en separat artikel.

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

Leveranstid ur ett juridiskt perspektiv

Ur ett juridiskt perspektiv uppstår en skyldighet (skuld) för leverantören att leverera systemet när ett kontrakt ingås mellan leverantören och användaren. Leveranstiden kan sägas vara en begränsning för när denna skuld ska uppfyllas. Med andra ord, en försening av leveranstiden kan betraktas som en form av kontraktsbrott, nämligen försenad prestation. Detta innebär att om leveranstiden försenas på grund av leverantörens avsiktliga eller oavsiktliga handlingar, kommer leverantören att bära ansvaret för kontraktsbrott på grund av försenad prestation (Japanska civilrätten, artikel 412).

1. När det finns en fastställd tidsfrist för uppfyllande av en skuld, bär gäldenären ansvaret för försening från den tidpunkt då tidsfristen har uppnåtts.
2. När det finns en osäker tidsfrist för uppfyllande av en skuld, bär gäldenären ansvaret för försening från den tidpunkt då gäldenären blev medveten om att tidsfristen har uppnåtts.
3. När ingen tidsfrist har fastställts för uppfyllande av en skuld, bär gäldenären ansvaret för försening från den tidpunkt då en begäran om prestation mottogs.

Japanska civilrätten, artikel 412

“Att bära ansvar” i denna artikel innebär i enkla ordalag att bära ansvaret för skadestånd.

När gäldenären inte uppfyller sin skuld i enlighet med dess huvudsakliga innebörd, kan borgenären begära skadestånd för den skada som uppstått därav. Detsamma gäller när gäldenären inte kan uppfylla sin skuld på grund av en orsak som kan tillskrivas gäldenären.

Japanska civilrätten, artikel 415

Dessutom, om användaren ger leverantören en “rimlig tidsperiod” och begär leverans till den dagen, men leverantören inte levererar, kan användaren också avbryta kontraktet.

När en part inte uppfyller sin skuld, kan den andra parten, efter att ha begärt uppfyllande inom en rimlig tidsperiod, avbryta kontraktet om uppfyllandet inte sker inom den tidsperioden.

Japanska civilrätten, artikel 541

För en mer detaljerad förklaring av alternativet “avbrytande” i sådana fall, se följande artikel.

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

Alla leveransförseningar är inte juridiskt sett kontraktsbrott

Det är dock inte alltid så att det faktum att “leveransen inte var i tid” nödvändigtvis innebär en försening i utförandet som ett kontraktsbrott. För att en ren leveransförsening ska bli en juridisk försening i utförandet, måste flera villkor uppfyllas, som visas nedan.

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

Med tanke på att systemutveckling normalt är ett projekt där både användaren och leverantören har skyldigheter, kan det hända att båda parterna erkänns ha brutit mot sina skyldigheter och att skadeståndet kompenseras.

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

För att lägga till detta ämne, det som vanligtvis sker nära leveranstiden är “godkännande” av resultatet. Vi behandlar godkännandet i detalj i följande artikel. Här förklarar vi fall där leveransen inte slutförs på grund av att användaren inte godkänner.

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

Poängen med diskussionen är att “inte vara i tid = kontraktsbrott” inte är så enkelt. Även om vi pratar om förseningar i leveransen, kan orsakerna variera, från att det är leverantörens fel till att det är användarens fel. Det finns en stor skillnad mellan det formella faktumet “försening av deadline” och det faktiska brottet “försening i utförandet”.

Rättsfall gällande förseningar i uppfyllande

Låt oss titta på rättsfall där möjligheten att förfölja ansvar för kontraktsbrott baserat på förseningar i uppfyllande har debatterats på grund av förseningar i leveransen. Även om det handlar om en tvist om leveranstid, är det viktigt att organisera fallet med hänsyn till grunderna för systemutveckling, såsom “användarens samarbetsplikt” och “projektledningsskyldighet”. Detta skiljer sig inte från andra tvister.

Exempel där försening av fullgörande har motverkats av användarens brott mot samarbetsplikt och vårdslöshet

I det rättsfall som citeras nedan, inledde användaren en rättsprocess mot leverantören på grund av försenad leverans. Denna stämning accepterades delvis i domstol, men samtidigt konstaterades det att användarens brist på lämpligt samarbete också var en bidragande faktor, och fyrtio procent av skadorna orsakade av förseningen ansågs vara användarens ansvar.

Enligt vår granskning kan det sägas att den klagande användaren inte har samarbetat på lämpligt sätt, eftersom den inte har fattat lämpliga beslut i tid, till exempel att inte lösa de frågor som leverantören har begärt lösningar på inom den angivna tidsramen.
Men, även om det erkänns att den klagande användaren har begärt tillägg och ändringar av funktioner som resulterade i tillägg och ändringar av utvecklingsinnehållet som förväntades i det grundläggande design-dokumentet, kan det inte sägas att detta utgör ett brott mot användarens samarbetsplikt, och leverantörens argument är utan grund.
Även när det gäller leverantörens påstående om brott mot samarbetsplikten på grund av användarens överdrivna krav, kan det inte erkännas att användaren har gjort överdrivna krav med tanke på avgiften för denna dataprogramutvecklingskontrakt etc., och det finns ingen anledning.
Snarare kan det sägas att det fanns olämpligheter i leverantörens projektledning, eftersom leverantören blev medveten om antalet transaktioner (antalet “transaktioner” vid tidpunkten för juli eller augusti samma år) från och med januari 1999 (Heisei 11) och från och med den 31 maj samma år föreslog orimliga ytterligare avgifter och minskningar av transaktioner.

Tokyo District Court, 10 mars 2004 (Heisei 16)

Den ovanstående domen erkände förseningen i leverantörens leverans som en försening i fullgörandet, men en del av orsaken var att användaren inte löste de problem som leverantören hade uttryckt, och erkände användarens krav genom att “klippa” sextio procent av den skada som användaren hävdade. Detta är en process som kallas “vårdslöshetsavdrag”, vilket är samma som i trafikolyckor där det finns fel på offrets sida.

I denna dom används termen “samarbetsplikt” mer än 40 gånger i hela texten, inklusive innehållsförteckningen. Från ett juridiskt perspektiv kan det snarare sägas att kärnan var att skilja mellan leverantörens projektledningsplikt och användarens samarbetsplikt.

Rättsfall där fullständig fördröjning av utförande erkändes

Nedan citerar vi ett domslut där leverantörens ansvar för förseningen av leveransen fullständigt bevisades och ansvar för kontraktsbrott på grund av fördröjning i utförandet erkändes. I detta fall blev kontraktet upplöst av användaren strax före systemets färdigställande, vilket ledde till en stämning från leverantören, men användaren hävdade att förseningen var orsaken till tvisten.

Det kan inte förnekas att svaranden har gett olika ändringsinstruktioner för designsystemet och att detta har försenat färdigställandet till viss grad. Särskilt eftersom svaranden gav de slutliga ändringsinstruktionerna den 23 juni 2005 (Heisei 17), kan det inte anses vara leverantörens fel att funktionen för “automatisk beräkning av detaljposter för kantstenar” baserat på dessa instruktioner inte är klar.
Men alla andra ändringsinstruktioner från svaranden gavs före början av april samma år, och det finns inga omständigheter som skulle tyda på att planen att slutföra designsystemet ändrades (med undantag för delen som beror på svarandens ändringsinstruktioner den 23 juni).
Det kan inte erkännas att käranden hade slutfört designsystemet till en nivå där det faktiskt kunde driftsättas vid slutet av juni 2005, med undantag för den del som berodde på ändringsinstruktionerna den 23 juni, och det erkänns att viktiga delar av systemet, såsom att bilder inte kan visas eller sökfunktionen inte fungerar, var ofullständiga.
(Utelämnat) Det kan antas att käranden inte hade hanterat arbetsprocedurerna för systemutvecklingen tillräckligt.
Med tanke på ovanstående kan det inte erkännas att den huvudsakliga orsaken till att käranden inte kunde följa leveranstiden var svarandens instruktioner, och det kan inte erkännas att det inte finns några skäl att skylla på käranden.

Tokyo District Court, 16 februari 2007 (Heisei 19)

I detta domslut indikerades att leverantören inte kan skyllas för att denna funktion är ofullständig, med tanke på att instruktioner för specifikationsändringar gavs ungefär en vecka före leveransdatumet. Men med hänsyn till följande punkter,

• Att ändringsinstruktioner som gavs flera månader tidigare fortfarande inte har följts
• Att e-postmeddelanden om det förväntade slutförandet har skickats från leverantören sedan dessa instruktioner gavs
• Att de ofullständiga delarna är viktiga delar av systemet, såsom implementering av bildvisning och sökfunktioner, och att detta inte har följts stöder överträdelsen av projektledningsskyldigheten

kontraktsbrott på grund av fördröjning i utförandet erkändes.

Vad vi kan förstå från båda domarna

Med tanke på båda domarna kan vi säga att frågan om “leveranstid” i systemutveckling i slutändan handlar om hur man drar gränsen mellan användarens samarbetsplikt och leverantörens projektledningsplikt. Med andra ord, eftersom laglig fördröjning i prestation är en typ av ansvar för kontraktsbrott, blir frågan om leverantören har brutit mot någon skyldighet en tvistepunkt. Och för att bedöma om den skada som har uppstått som ett resultat (dvs. förlusten för användaren på grund av förseningen i leveransen) kan tillskrivas leverantören, måste vi också överväga hur vi tolkar användarens samarbetsplikt.

Sammanfattning

Termen “försenad prestation” kan vid första anblicken verka vara en omskrivning av “försenad leverans” på grund av dess innebörd. Men försenad prestation är en typ av kontraktsbrott. Därför är det mer lämpligt att förstå det som en “överträdelse av projektledningsplikten”.

Frågan om “leveranstid” i systemutvecklingsprojekt bör inte bara fokusera på den ytliga tidpunkten för leveransen, utan det är viktigt att omorganisera det som en fråga om leverantörens projektledningsplikt och användarens samarbetsplikt.