Jaké jsou povinnosti dodavatele po dokončení vývoje systému

Je dobře známo, že ve vývoji systémů nese dodavatel, který je odborníkem na vývoj systémů, “povinnost řízení projektu”. Avšak v právním kontextu je zde také koncept, který je podobný, ale odlišný, a to “povinnost podpory”. V tomto článku vysvětlíme tuto “povinnost podpory”, přičemž zohledníme i minulé soudní případy.

Co je povinnost podpory

Přehled povinnosti podpory

V případě povinností, které dodavatel nese vůči uživateli, je typickým příkladem povinnost řízení projektu. Tato povinnost byla opakovaně zmíněna v minulých soudních případech a postupně se ustálila. Jedná se o koncept, který shrnuje povinnosti, které dodavatel jako odborník na vývoj systémů nese vůči celému projektu.

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

Povinnost řízení projektu je velmi známým právním termínem v oblasti vývoje systémů a nepochybně je to hlavní povinnost, kterou dodavatel přebírá. Nicméně, některé soudní případy uznávají existenci povinnosti, která se liší od povinnosti řízení projektu, a to jako “povinnost podpory”.

Povinnost podpory se stává problémem v podpoře provozu pro uživatele

Co tedy je povinnost podpory? A proč je to něco, co je označováno jiným názvem než povinnost řízení projektu? Povinnost podpory se obvykle stává problémem po dokončení vývoje systému. Projekt vývoje systému je “vývoj”, takže základní myšlenkou je, že projekt končí, jakmile je systém, který má být vytvořen, dokončen. To znamená, že projekt vývoje systému začíná tím, že se jasně definuje, co má být systém (definice požadavků), a končí tím, že se ověří, zda byl systém skutečně vytvořen (testování nebo přijetí). Pokud jde o proces přijetí, podrobně se zabýváme právními problémy, které se často vyskytují v této fázi, v následujícím článku, s ohledem na to, že má důležitý význam jako “konec projektu vývoje systému”.

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

Avšak, i když je projekt vývoje systému chápán jako samotný proces vývoje nového systému, je samozřejmé, že vyvinutý systém bude poté využíván v provozu. Jinými slovy, může se zdát nesmyslné říci, že “jakožto strana, která se zabývá pouze vývojem, stačí, když systém vytvoříme”, aniž bychom se vůbec zabývali tím, jak bude systém po jeho vývoji využíván. S ohledem na tyto okolnosti se v minulých soudních případech stala otázkou, zda by dodavatel, který se zabývá vývojem systému, neměl nést určitou povinnost podpory provozu. Jinými slovy, otázka je, zda by povinnosti, které dodavatel nese v rámci smlouvy o vývoji systému, neměly zahrnovat také povinnosti související s podporou provozu po vývoji. Protože podpora provozu není součástí samotného procesu vývoje, je pravděpodobné, že se začalo používat označení “povinnost podpory” k jeho odlišení od povinnosti řízení projektu.

Případ soudního sporu týkajícího se povinnosti poskytování podpory

Případ, kdy provozování uživatelských operací bylo narušeno v době systémového testování

V následujícím citovaném rozsudku se jedná o případ, kdy uživatel nebyl schopen využívat systém tak, jak původně předpokládal, během systémového testování před zahájením provozu systému, a v důsledku toho uživatel nakonec vzdal provoz systému. Tento případ se týkal problémů při zahájení provozu ze strany uživatele, a otázkou bylo, jak odůvodnit odpovědnost dodavatele na základě předchozí smlouvy o vývoji systému. Výsledkem bylo, že byla uznána nároky uživatele na náhradu škody a jako důvod bylo uvedeno “porušení povinnosti poskytování podpory”.

I Porušení povinnosti poskytování podpory
(A) Zástupce žalobce požádal žalovaného dne 14. července 1997 (rok Heisei 9), aby “nejen vytvořil systém, ale také se postaral o to, aby správně fungoval až do konce.” a “jsme laici, takže pokud platíme vysokou cenu, chceme, aby systém fungoval až do konce.“. Na to žalovaný vysvětlil, že je možné vytvořit systém, který dosáhne cílů žalobce, a slíbil, že poskytne podporu až do doby, kdy systém bude správně fungovat. Tímto byla mezi žalobcem a žalovaným uzavřena dohoda, že žalovaný poskytne podporu až do doby, kdy žalobce bude schopen správně využívat systém.
Je zřejmé, že žalovaný má povinnost poskytovat podporu žalobci, protože v rámci platby za smlouvu o vývoji systému byla za položku “podpora při zavádění balíčku” účtována částka 1 726 000 a v nabídce bylo uvedeno, že “pozdržovací poplatek za šest měsíců po zavedení je zdarma” a v dokumentu s názvem “O podpoře SE v budoucnosti (interní materiál pro jednání)” bylo potvrzeno, že je možné získat podporu SE pro “vytvoření postupu zavedení (plán)” a “práci na ověřování dat/provozu” pro čerstvé objednávky.

(B) A konkrétně, povinnost poskytování podpory, kterou žalovaný má vůči žalobci, zahrnuje alespoň do doby, kdy žalobce začne plně využívat systém, to, že žalovaný poskytne žalobci ①vhodné rady ohledně provozu systému, ②účast na provozních testech a reakci na problémy se systémem, které vznikly během provozních testů, ③zlepšení systému v reakci na výsledky provozních testů, ④výuku pro operátory.
Ale žalovaný, i když se vyskytlo mnoho problémů během provozních testů, neřešil je vážně, tvrdil, že je to problém dovedností operátorů, a požadoval pouze náklady na výuku operátorů, aniž by poskytl žalobci jakoukoli vhodnou podporu směřující k plnému provozu.

Rozsudek pobočky Hachioji tokijského okresního soudu ze dne 5. listopadu 2003 (rok Heisei 15)

V tomto rozsudku se slovo “podpora” objevuje asi třicetkrát v celém textu, včetně obsahu. Je zřejmé, že byl dosažen závěr po pečlivém zvážení konkrétních okolností případu, včetně zaznamenání hlasu uživatele požadujícího náležitou podporu v textu rozsudku. Dalšími body, na které bychom měli zvláště upozornit při pochopení tohoto případu, jsou:

• Porušení povinnosti poskytování podpory je považováno za “neprovedení závazku”, a proto byla nařízena náhrada škody vzniklé v důsledku toho.
• Po celou dobu rozsudku nebylo ani jednou použito slovo “povinnost řízení projektu”.

Je zřejmé, že se snaží zacházet s tím jako s povinností smlouvy, která je zahrnuta v smlouvě o vývoji systému, i když je to jiný koncept než řízení projektu.

Jak by měla být povaha podpůrné povinnosti interpretována?

Podpůrná povinnost ještě není jasným konceptem

Jak bylo uvedeno v předchozích soudních případech, dodavatel, který vyvíjí systém, by měl také poskytnout nezbytnou podporu, aby uživatel mohl systém spustit. Avšak podpůrná povinnost nemá tak bohatou sbírku soudních rozhodnutí jako povinnost řízení projektu a neexistuje mnoho způsobů, jak pochopit její skutečnou podstatu. Zejména termín “podpora” sám o sobě zahrnuje problém, že není zcela jasné, co konkrétně by mělo být provedeno.

Podpůrná povinnost není neomezeně uznávána

Navíc, výše uvedený rozsudek, který uznal porušení podpůrné povinnosti dodavatele, také ukázal velmi důležitý bod.

Obžalovaný je podle smlouvy o dílo povinen poskytnout žalobci určitou podporu potřebnou pro provoz systému, který pro něj vytvořil a dodal. Nicméně, její obsah není takový, jak tvrdí žalobce, že by poskytoval veškerou podporu zdarma, dokud žalobce nebude schopen provozovat tento systém, bez ohledu na dobu.

Rozsudek Hachiōji pobočky Tokijského okresního soudu ze dne 5. listopadu 2003 (rok 15 Heisei)

Je možné, že bylo poukázáno na to, že pokud je hlavní částí přijaté práce vývoj systému, pak by měla být také omezení na to, co by mělo být provedeno jako podpora pro následný provoz. V tomto rozsudku jsou také některé charakteristické body, jako je citace hlasu uživatele, který požaduje podporu v textu rozsudku, zmínka o obsahu předchozího odhadu a zmínka o existenci speciální dohody o poskytování podpory. Jinými slovy, s ohledem na to, že pokud se koncept podpůrné povinnosti neomezeně rozšiřuje, bude to znamenat velkou zátěž pro dodavatele, je pravděpodobné, že byl záměrem provést určitou opatrnost při uznání porušení povinnosti.

Podstata podpůrné povinnosti by měla být zvážena společně s povinností uživatele spolupracovat

Co se týče dosavadní diskuse, lze říci, že jde o otázku, “jak by měli uživatelé a dodavatelé sdílet pracovní zátěž v počáteční fázi provozu vývoje systému”. To zahrnuje jistě složitý problém, do jaké míry má dodavatel právní povinnost při zahájení provozu od smlouvy o “vývoji”. Zároveň je třeba říci, že je silný trend vyžadovat rozhodnutí na základě konkrétních okolností.

Avšak, jaká je skutečná podstata podpůrné povinnosti, kterou má dodavatel, může být jasnější, pokud porozumíme povinnosti uživatele spolupracovat.

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

Úsilí o zlepšení práce pomocí nového systému je v první řadě společnou prací dodavatele, který je odborníkem na technologii, a uživatele, který má znalosti o práci ve společnosti. Proto se domníváme, že i v případě takzvané podpůrné povinnosti, pokud uživatel jasně určí, co by měl řešit v rámci “plnění povinnosti spolupráce”, rozsah se často samočinně stanoví.

Shrnutí

V tomto článku jsme se zaměřili na základy projektového managementu a uspořádali jsme informace o takzvané “povinnosti podpory”, která je odvozena od projektového managementu. I když koncept povinnosti podpory stále obsahuje mnoho nejasností, důležité pro jeho pochopení jsou základní otázky, jako je “povinnost projektového managementu” a “povinnost spolupráce”.