Jak se vypořádat s přerušením vývoje systému z důvodu uživatelských okolností

Obchodní činnost, jako je vývoj systémů, často představuje dlouhodobé projekty. Co může dodavatel, který přijal práci, udělat, pokud je jednostranně konfrontován s uživatelem, který řekne, že “již není třeba tento systém vytvářet”, když se jednou začne s vývojem systému?

V tomto článku se budeme zabývat charakteristikami smlouvy o vývoji systému a vysvětlíme, jaké jsou možnosti reakce v takovém případě.

Význam zamyšlení se nad přerušením z důvodu uživatele

Smlouvy o vývoji systémů mají několik charakteristických rysů, pokud se na ně díváme jako na smlouvy. Jedním z nich je, že jejich doba trvání je obvykle dlouhá a dodavatel má v rámci své povinnosti řízení projektu velkou pravomoc a zároveň nese velkou odpovědnost. Celkový obsah povinností dodavatele v oblasti řízení projektů je podrobně vysvětlen v následujícím článku.

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

Dalším rysem je, že i když je uživatel zákazníkem, má širokou povinnost spolupracovat na práci dodavatele. Pokud jde o systémy používané uvnitř společnosti, nemůže to být jen “hozené” dodavateli. I z vnitřních zdrojů společnosti existuje povinnost spolupracovat tak, aby dodavatel mohl uplatnit svou odbornost v práci. Toto je podrobně vysvětleno v následujícím článku.

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

Shrneme-li výše uvedené, mezi dodavatelem a uživatelem existuje vztah “externího dodavatele”, který vyvíjí systém, a “zákazníka”, který platí odměnu, ale zároveň existuje také aspekt “kolegy”, který by měl spolupracovat na dosažení společného cíle projektu. Tato složitost vztahů obvykle neexistuje u obyčejných švadlen, kteří šijí na míru obleky, a je to také velkým rysem smluv o vývoji systémů. Spory související s vývojem systémů jsou kvůli této složitosti vztahů náchylné k tomu, že se jednou zamotají, a je obtížné určit, jak by měly být obě strany právně uspořádány.

Pokud uživatel změní názor a řekne něco jako “nakonec ten systém nepotřebujeme, takže už nemusíte pokračovat v projektu”, má smysl zvážit, jak by měly být vztahy práv a povinností obou stran chápány. To má také význam předložení praktického příkladu právního myšlení vzhledem k této složité smluvní situaci. Níže jsou uvedeny věci, které by měly být zváženy po předpokládání takové situace.

Nejprve ujasněte důvody pro vypovězení smlouvy

Z pohledu dodavatele může být situace, kdy “uživatel jednostranně chce přerušit projekt”, vnímána jinak než uživatelem. Například, představme si situaci, kdy byl zahájen projekt na vývoj systému pro správu personálu pracujícího v zahraničních pobočkách, ale později byl plán na expanzi do zahraničí zrušen a vývoj takového systému se stal zbytečným. Na první pohled by se mohlo zdát, že se jedná o jednostrannou změnu názoru ze strany uživatele.

Ale co když k tomuto rozhodnutí došlo v důsledku skutečnosti, že dodavatel také nesplnil své povinnosti v rámci řízení projektu, jako je zpoždění v jednotlivých fázích, a obtíže s pokrokem vývoje také přispěly ke změně firemní politiky?

Jak bylo uvedeno výše, vývoj systému je proces, při kterém dodavatel a uživatel spolupracují a vzájemně na sebe přebírají značné povinnosti. Proto, i když uživatel chce projekt přerušit a dodavatel to považuje za vypovězení smlouvy z důvodu vlastního zájmu uživatele, měl by být dodavatel připraven na možnost, že bude konfrontován s výtkami týkajícími se jeho vlastních důvodů pro neplnění povinností a může být obviněn z porušení smlouvy nebo dohodnutého ukončení.

Rozlišení mezi vypovězením smlouvy z vlastního zájmu, ukončením smlouvy na základě neplnění povinností nebo dohodnutým ukončením závisí na pokroku projektu a průběhu dosavadních jednání a má tendenci být posuzováno individuálně v každém případě. Proto, pokud dodavatel postupuje s následným zpracováním na základě předpokladu, že se jedná o vypovězení smlouvy z důvodu vlastního zájmu uživatele, je důležité pečlivě zaznamenat tuto skutečnost, například v zápisech z jednání, aby se později nestala předmětem sporu.

Potvrzení základních ustanovení pro nároky na odměnu a náhradu škody

Po zohlednění výše uvedených bodů, pokud můžeme pokračovat v diskusi jako o ukončení z důvodu uživatele, budeme následně zvažovat, zda je možné od dodavatele požadovat odměnu odpovídající dokončené části práce nebo náhradu škody.

Ustanovení, na která bychom se měli v takových případech odkazovat, se liší podle typu smlouvy. Smlouvy o vývoji systémů lze obecně rozdělit na smlouvy o dílo a smlouvy o zastoupení.

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

A v případě smluv o zastoupení a smluv o dílo, občanský zákoník stanovuje následující:

a.) V případě smlouvy o zastoupení
Nárok na odměnu: Článek 648 odstavec 3 Japonského občanského zákoníku (1896)
Pokud zástupce ukončí plnění v průběhu z důvodu, který nelze přičíst na jeho vinu, může požadovat odměnu odpovídající již provedenému plnění.
Nárok na náhradu škody: Článek 651 Japonského občanského zákoníku
1. Zastoupení může být kdykoli ukončeno kteroukoli ze stran.
2. Pokud jedna ze stran ukončí zastoupení v nevýhodném okamžiku pro druhou stranu, musí tato strana nahradit škodu druhé straně. Toto však neplatí, pokud existuje neodkladný důvod.

b.) V případě smlouvy o dílo
Nárok na náhradu škody: Článek 641 Japonského občanského zákoníku (1896)
Dokud dodavatel nedokončí práci, může objednatel kdykoli ukončit smlouvu s náhradou škody.

Rozsah náhrady škody podle článku 641 Japonského občanského zákoníku se považuje za zahrnující nejen již vynaložené náklady, ale také “zisk, který by byl získán, pokud by smlouva nebyla ukončena”. To odráží myšlenku, že by bylo nesmyslné, aby zákon vynucoval dokončení práce, která se stala zbytečnou z pohledu objednatele, a že je proto logičtější zaručit zisk dodavatele prostřednictvím platby ekvivalentní odměny.

Je však třeba poznamenat, že v případě náhrady škody podle článku 641 Japonského občanského zákoníku, není neobvyklé, že v individuálních smlouvách mezi dodavatelem a uživatelem je náhrada škody vyloučena. V takových případech má přednost individuální dohoda (smlouva) mezi stranami a ustanovení občanského zákoníku se již neuplatňují, což vyžaduje opatrnost.

Dále pokračujeme v důkazech o objemu a škodách

V případě ukončení smlouvy z vlastní vůle uživatele je běžné, že smlouva umožňuje požadovat poplatky za objem (tj. dokončenou část) a náhradu škody. Proto je obvykle nutné, aby dodavatelé předložili důkazy o objemu a škodách, aby mohli požadovat náhradu škody.

Avšak, důkaz o objemu, tedy o procentu dokončení, může být velmi náročný. To je proto, že se očekává, že pokud budete muset provést rozhovory pro ověření pokroku, zejména pokud existuje více subdodavatelů, množství práce bude značné. Navíc, pokud budete muset vytvořit dokumenty podporující výsledky rozhovorů a dokonce i dokumentovat samotný obsah rozhovorů, množství práce se stane obrovským. Existuje také mnoho problémů, jako je riziko, že i po všem tomto úsilí budou důkazy považovány za nedostatečné, a práce vynaložená na přípravu důkazů se může stát marnou.

Vzhledem k těmto faktorům můžeme zvážit opatření, jako je jasné uvedení v předběžné fázi smlouvy, že v případě ukončení uprostřed bude výpočet proveden na den do ukončení, aby byl výpočet jednoduchý. Kromě toho, vzhledem k tomu, že důkaz o objemu je náročný, můžeme zvážit opuštění požadavku na objem a místo toho požadovat “náklady vynaložené na vývoj již dokončené části”. Pokud jde o interní náklady na vývoj, není neobvyklé, že je lze snadno vypočítat pomocí jednoduchého vzorce “pracovní hodiny x jednotková cena”. Zejména u projektů s nízkou marží může být prioritou požadavek na náklady namísto objemu, což usnadňuje vymáhání pohledávek a kompenzaci ztrát, což může být realističtější řešení.

Co by měli uživatelé zvážit z jejich pohledu?

Mimochodem, i pro uživatele, kteří se rozhodnou zrušit smlouvu z vlastních důvodů, existují body, které by měli předem zvážit. Jedná se o to, zjistit přibližnou částku náhrady škody, kterou budou muset zaplatit dodavateli. Když zde hovoříme o “přibližné” částce, máme na mysli stanovení zhruba odhadované částky, která nám pomůže určit směr budoucích jednání (pokud by projevení záměru zrušit smlouvu bylo zpožděno, bylo by to kontraproduktivní, takže přesná částka není nutná).

Pokud se domníváte, že předem zjištěná přibližná částka je nespravedlivě vysoká, měli byste požádat o vysvětlení. Pokud se však pokusíte o neústupné jednání, aby jste snížili částku k zaplacení, může to vést k zbytečným soudním sporům a dalšímu zkomplikování situace. Pokud se jednání mezi oběma stranami zdá být obtížné, může být jednou z možností konzultace s právníkem.

Ve tomto článku jsme předpokládali, že smlouva o vývoji systému je uzavřena. Ve skutečnosti však v oblasti vývoje systémů často dochází k sporům o to, zda byla smlouva vůbec platně uzavřena. Podrobněji o tomto tématu diskutujeme v následujícím článku.

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

Shrnutí

V tomto článku jsme vysvětlili postup řešení případů, kdy je projekt přerušen z důvodu uživatele. Nicméně, hlavní bod tohoto článku je, že je třeba zvážit, zda je to opravdu z důvodu uživatele, a zda na straně dodavatele skutečně nebyla žádná chyba.

Charakteristikou projektu vývoje systému je, že jak dodavatel, tak uživatel nesou velkou odpovědnost. Vzhledem k tomu je třeba pečlivě zvážit, zda je skutečně možné jednostranně přičítat vinu druhé straně. Pokud to neuděláte předem, může to vést k situaci, která ještě více přilévá olej do ohně, a to byste měli mít na paměti.