Vztah mezi zpožděním dodání systémového vývoje a právními důsledky prodlení s plněním

Projekty jako je vývoj systému jsou v jistém smyslu stále bojem s dodacími lhůtami. Z právního hlediska lze u “dodacích lhůt” v systémovém vývoji zvážit “rizika, která se projeví, pokud se náhodou nedodrží termín”.

V tomto článku vysvětlíme, za jakých okolností se “zpoždění dodací lhůty” považuje za prodlení s plněním a vede k právní odpovědnosti za nesplnění závazků a podobně.

Co je dodací lhůta v systémovém vývoji

Dodací lhůta v obecném pojetí

Obecný význam termínu “dodací lhůta” odkazuje na termín, do kterého je třeba dodat produkt požadovaný zákazníkem. I v prostředí vývoje, kde se předpokládá možnost neočekávaných problémů, je často požadováno striktní dodržování dodacích lhůt. Pokud existuje rozdíl v mocenských vztazích mezi dodavatelem a objednatelem, tendence k dodržování dodacích lhůt je často ještě výraznější. V případě zpoždění dodací lhůty může dojít k slevě v závislosti na překročení, nebo k bezplatnému provedení práce nad rámec. Každopádně, dodací lhůta je obecně považována za důležitou pro udržení důvěryhodného vztahu s obchodním partnerem.

Koncept “dokončení práce” v právním smyslu a dodací lhůty jsou vysvětleny v jiném článku.

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

Dodací lhůta z právního hlediska

Z právního hlediska, jakmile dodavatel a uživatel uzavřou smlouvu, dodavatel má povinnost (dluh) dodat systém. Dodací lhůta je pak omezení doby, kdy by měl být tento dluh splněn. Jinými slovy, zpoždění dodací lhůty je považováno za prodlení s plněním, což je jeden z typů nesplnění dluhu. To znamená, že pokud je zpoždění dodací lhůty způsobeno úmyslným nebo nedbalým jednáním dodavatele, dodavatel nese odpovědnost za nesplnění dluhu způsobené prodlením s plněním (japonský občanský zákoník článek 412).

1. Pokud je pro splnění dluhu stanoven pevný termín, dlužník nese odpovědnost za prodlení od okamžiku, kdy tento termín nastane.
2. Pokud je pro splnění dluhu stanoven neurčitý termín, dlužník nese odpovědnost za prodlení od okamžiku, kdy se dozvěděl o nástupu tohoto termínu.
3. Pokud pro splnění dluhu nebyl stanoven žádný termín, dlužník nese odpovědnost za prodlení od okamžiku, kdy byla požadována plnění.

Japonský občanský zákoník článek 412

“Nesení odpovědnosti” v tomto kontextu znamená v podstatě odpovědnost za náhradu škody.

Pokud dlužník nesplní svůj dluh v souladu s jeho podstatou, věřitel může požadovat náhradu škody způsobené tímto. Totéž platí, pokud dlužník nemůže splnit svůj dluh z důvodu, který je mu přičitatelný.

Japonský občanský zákoník článek 415

Dále, pokud uživatel vyzve dodavatele k dodání v “přiměřené lhůtě” a dodavatel nesplní do stanoveného dne, uživatel může smlouvu zrušit.

Pokud jedna ze stran nesplní svůj dluh, druhá strana může stanovit přiměřenou lhůtu pro splnění a pokud do této lhůty nedojde k plnění, druhá strana může smlouvu zrušit.

Japonský občanský zákoník článek 541

Podrobnější vysvětlení možnosti “zrušení” v těchto případech najdete v následujícím článku.

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

Ne každé zpoždění dodání není z hlediska práva nesplněním závazku

Je třeba zdůraznit, že skutečnost, že “dodání nebylo včas”, nutně neznamená zpoždění plnění jako nesplnění závazku. Aby se situace jednoduchého zpoždění dodání stala právním zpožděním plnění, je třeba splnit několik podmínek, jak je uvedeno níže.

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

Navíc, vzhledem k tomu, že vývoj systému je obvykle projekt, na kterém mají povinnosti jak uživatel, tak dodavatel, může dojít k situaci, kdy je porušení povinnosti uznáno na obou stranách a náhrada škody je kompenzována.

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

Dále k tématu, obvykle se blíží k termínu dodání, je “převzetí” výsledku. O převzetí se podrobněji zabýváme v následujícím článku. Zde se zabýváme případy, kdy dodání není dokončeno, protože uživatel nesouhlasí s převzetím.

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

Pointou je, že “nedodání včas = nesplnění závazku” není tak jednoduché. I když mluvíme o zpoždění dodání, důvody mohou být různé, ať už je to chyba dodavatele nebo uživatele. Mezi formální skutečností “zpoždění dodání” a skutečným porušením povinnosti, které tvoří “zpoždění plnění”, je značný rozdíl.

Soudní případy týkající se prodlení s plněním

Podívejme se na soudní případy, ve kterých bylo diskutováno, zda je možné uplatnit odpovědnost za nesplnění dluhu na základě prodlení s plněním, které vzniklo kvůli zpoždění dodací lhůty. Ačkoli se jedná o spor týkající se dodací lhůty, podstatou je “povinnost spolupráce uživatele”, “povinnost řízení projektu”, a je důležité uspořádat případ na základě základů vývoje systému. Tento aspekt se neliší od ostatních sporů.

Příklad, kdy prodlení s plněním bylo vyrovnáno porušením povinnosti spolupráce a nedbalostí uživatele

V následujícím citovaném rozsudku se jedná o případ, kdy uživatel podal žalobu, protože dodavatel nesplnil termín dodání. Tato žaloba byla částečně přijata soudem, ale zároveň bylo konstatováno, že jedním z důvodů byla také absence náležité spolupráce na straně uživatele, a bylo rozhodnuto, že čtyřicet procent škody způsobené zpožděním dodání je odpovědností uživatele.

Na základě výše uvedeného zjištění lze konstatovat, že žalobce, uživatel, nesplnil svou povinnost náležité spolupráce tím, že neudělal včasné a správné rozhodnutí, například nevyřešil problémy, které mu dodavatel předložil k řešení do stanoveného termínu.
Nicméně, co se týče tvrzení žalobce, uživatele, o porušení povinnosti spolupráce dodavatelem v souvislosti s požadavky na přidání nebo změnu funkcí, lze uznat, že žalobce, uživatel, skutečně požadoval přidání nebo změnu obsahu vývoje, který byl předpokládán v základním návrhu tohoto případu, ale toto neznamená, že by toto tvořilo porušení povinnosti spolupráce ze strany žalobce, uživatele, a tvrzení dodavatele je bezdůvodné.
Stejně tak, co se týče tvrzení dodavatele o porušení povinnosti spolupráce žalobcem, uživatelem, v souvislosti s nadměrnými požadavky, nelze uznat, že žalobce, uživatel, měl nadměrné požadavky vzhledem k poplatkům za smlouvu o vývoji počítačového systému atd., a tvrzení je bezdůvodné.
Naopak, lze konstatovat, že dodavatel měl nedostatky v projektovém managementu, například v tom, že pochopil počet transakcí až po lednu 1999 (Heisei 11) a po 31. květnu téhož roku navrhl neoprávněné zvýšení poplatků nebo snížení transakcí.

Rozsudek tokijského okresního soudu ze dne 10. března 2004 (Heisei 16)

Výše uvedený rozsudek uznal prodlení s plněním ze strany dodavatele kvůli zpoždění dodání, ale zároveň uvedl, že část příčiny spočívala také v tom, že uživatel nevyřešil problémy, které mu dodavatel předložil, a uznal nárok uživatele na škodu tím, že “ořízl” šedesát procent z nároku uživatele. Toto je stejný postup jako u dopravních nehod, kde je také viníkem oběť, tzv. “vyrovnání nedbalosti”.

V tomto rozsudku se výraz “povinnost spolupráce” objevuje více než čtyřicetkrát v celém textu včetně obsahu. Z právního hlediska lze říci, že podstatou bylo spíše rozdělení povinnosti projektového managementu dodavatele a povinnosti spolupráce uživatele.

Případ, kde bylo plně uznáno zpoždění v plnění

Následující citace je z rozsudku, ve kterém byla plně prokázána odpovědnost dodavatelské strany za zpoždění dodání a byla uznána odpovědnost za nesplnění dluhu kvůli zpoždění v plnění. V tomto případě byla smlouva zrušena uživatelem těsně před dokončením systému, což vedlo k žalobě ze strany dodavatele, ale uživatel tvrdil, že příčinou bylo zpoždění dodání.

Obžalovaný dal různé pokyny k změně designového systému, což způsobilo určité zpoždění v dokončení, což nelze popřít. Obzvláště obžalovaný dal konečné pokyny ke změně 23. června 2005 (Heisei 17), takže skutečnost, že funkce “automatického výpočtu položek detailů bočního kamene” na základě těchto pokynů nebyla dokončena, nemůže být přičítána na vinu žalobci.
Nicméně, ostatní pokyny k změně od obžalovaného byly dány do začátku dubna téhož roku a nebylo uznáno, že byly změněny okolnosti, které by měly být interpretovány jako změna plánu dokončení designového systému (s výjimkou části způsobené pokynem k změně obžalovaného ze dne 23. června téhož roku).
Nebylo uznáno, že žalobce měl designový systém dokončený do konce června 2005 (Heisei 17) do té míry, že by mohl být skutečně provozován, s výjimkou části způsobené pokynem k změně ze dne 23. června téhož měsíce, a bylo uznáno, že důležité části systému, jako je neschopnost zobrazit obrázky nebo nefunkční vyhledávací funkce, nebyly dokončeny.
(Vynecháno) Je zřejmé, že žalobce nedostatečně spravoval pracovní postupy spojené s vývojem systému.
Na základě výše uvedeného nelze uznat, že hlavní příčinou neschopnosti žalobce dodržet termín dodání byly pokyny obžalovaného, a nelze uznat, že neexistují důvody, které by měly být přičítány na vinu žalobci.

Rozsudek tokijského okresního soudu ze dne 16. února 2007 (Heisei 19)

V tomto rozsudku bylo uvedeno, že pokud jde o skutečnost, že pokyn k změně specifikací byl vydán asi týden před termínem dodání, nelze to přičítat na vinu dodavateli, pokud tato funkce nebyla dokončena. Nicméně,

• skutečnost, že stále nebylo reagováno na pokyn k změně, který byl vydán několik měsíců předtím
• skutečnost, že po vydání tohoto pokynu byl od dodavatele odeslán e-mail s oznámením o předpokládaném datu dokončení
• skutečnost, že nedokončené části jsou důležité části systému, jako je zobrazení obrázků nebo implementace vyhledávací funkce, a skutečnost, že na to nebylo reagováno, potvrzuje porušení povinnosti řízení projektu

Bylo uznáno nesplnění dluhu na základě zpoždění v plnění.

Co lze vyčíst z obou rozsudků

Při zohlednění obou rozsudků lze říci, že problém “dodacích lhůt” při vývoji systému je v konečném důsledku otázkou, jak stanovit hranice mezi povinností uživatele spolupracovat a povinností dodavatele řídit projekt. Jinými slovy, zákonné zpoždění plnění je jedním z typů odpovědnosti za nesplnění závazků, a proto se automaticky stává bodem sporu, zda došlo k nějakému porušení povinnosti na straně dodavatele. A aby bylo možné posoudit, zda lze škodu, která se projevila jako výsledek (tj. ztráty na straně uživatele v důsledku zpoždění dodání), přičíst dodavateli, je třeba zároveň zvážit, jak chápat povinnost uživatele spolupracovat.

Shrnutí

Termín “zpoždění v plnění” může na první pohled vypadat jako jiný způsob, jak říci “zpoždění dodávky”. Avšak zpoždění v plnění je jedním z typů nesplnění závazků. Proto je vhodnější chápat to jako “porušení povinnosti řízení projektu”.

Problémy s “dodacími lhůtami” v projektech vývoje systémů by neměly být chápány pouze v kontextu povrchního předstihu nebo zpoždění dodávky. Místo toho je důležité je přeformulovat a uspořádat jako otázky týkající se povinnosti dodavatele řídit projekt a povinnosti uživatele spolupracovat.