Jaké jsou opatření v případě, že se po převzetí systému objeví jeho nedostatky?

Vývoj systému je obecně řečeno proces, kde se podle obsahu stanoveného v definici požadavků postupuje k implementaci programu a nakonec se jak uživatel, tak dodavatel ověří, zda je výsledek v souladu se specifikacemi. Projekt je ukončen po úspěšném přijetí.

Ale v praxi se může stát, že chyby nebo problémy, které nebyly odhaleny během testovací fáze nebo při přijetí, se objeví během následující provozní fáze. Jaké právní nároky můžete uplatnit, pokud jste již přijali dodávku?

Není divu, že po přijetí nebo testovací fázi zůstávají chyby

Z technického hlediska není vůbec neobvyklé, že po dokončení různých testovacích fází dodavatele a po přijetí uživatelem se objeví různé chyby a problémy. To, co uživatel obvykle dělá během přijímací fáze, je především kontrola vstupů a výstupů, které lze ověřit na obrazovce. Avšak IT systémy často mají složitou a detailní strukturu v databázi nebo v částech programu, které řídí různé výpočty a ovládání, což je mnohem více než to, co lze vidět na obrazovce z pohledu uživatele. Proto existují omezení toho, co lze zjistit z kontroly vstupů a výstupů na obrazovce z pohledu uživatele. Proto není realistické vyčerpat všechny možnosti problémů, které by mohly nastat v následující provozní fázi, prostřednictvím kontroly.

Podobné okolnosti platí i z pohledu dodavatele, který je zodpovědný za vývoj. Například kontrola, zda program, který byl implementován, neobsahuje chyby nebo problémy, je “testovací fáze”. Ale i v testovací fázi, není vždy možné vyčerpat všechny možnosti chyb a problémů. I po tom, co je systém plně využíván v praxi, může dojít k operacím, které dodavatel nepředvídal, nebo k registraci velkého množství dat, nebo k tomu, že více uživatelů přistupuje současně. Vytvoření systému, který bude i nadále fungovat bez problémů v těchto podmínkách, vyžaduje vysokou úroveň technických dovedností.

Měli byste si uvědomit, že v fázích jako je přijetí nebo testování, není realistické najít a vyřešit všechny možné chyby a problémy, a že po skutečném začátku používání mohou nastat různé problémy s IT systémy.

Obvyklé je považovat dluh samotný za splněný

Jak bychom měli postupovat, když se takové problémy skutečně objeví? Řešíme to podle právního postupu.

Nejprve, pokud se po skutečnosti objeví různé chyby a problémy, uživatelé budou chtít dodavatele, kterému dosud svěřovali práci, nějakým způsobem stíhat. Nicméně, obvykle, pokud je dodání již dokončeno a bylo schváleno, je často obtížné stíhat odpovědnost na základě nesplnění dluhu.

Samotná smlouva o vývoji systému, pokud nejsou připraveny žádné speciální dohody, se týká implementace programu podle ustanovení o smlouvě o dílo podle občanského zákoníku. Co je smlouva o dílo, je podrobně vysvětleno v následujícím článku.

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

A v smlouvě o dílo je “dokončení práce” požadavkem na splnění dluhu. Co konkrétně znamená “dokončení práce” je podrobně vysvětleno v následujícím článku.

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

Zde vysvětlujeme, že “dokončení práce” ve smlouvě o dílo znamená v kontextu vývoje systému ukončení celého vývojového procesu podle minulých soudních případů. A také vysvětlujeme, že problémy, jako jsou chyby a problémy, které se objeví po ukončení celého vývojového procesu, se stávají problémem odpovědnosti za záruku vady ve smlouvě o dílo.

Shrnutí, pokud je dodání přijato a schválení je dokončeno, předpokládá se, že dluh samotný je již splněn, a poté se stává problémem, zda je možné stíhat odpovědnost za záruku vady, tj. problém kvality.

Postup při uplatňování odpovědnosti na základě záruky za vady

Jak bychom měli postupovat, pokud chceme na základě záruky za vady požadovat nápravu od dodavatele? Podívejme se na to podrobněji.

Nejprve ověřte závažnost a vážnost chyb a nedostatků

Pokud se chyby a nedostatky objeví až po dodání a jsou považovány za “vady” z hlediska práva, záleží na závažnosti těchto chyb a nedostatků. Otázka právních vad se obecně dělí na tři kategorie:

1. Je to chyba nebo nedostatek, ale je to jen drobná věc, která nemůže být považována za “vadu” z hlediska práva.
2. Je to “vada” z hlediska práva, ale je možné dosáhnout cíle smlouvy.
3. Je to “vada” z hlediska práva a není možné dosáhnout cíle smlouvy.

Tyto tři vzorce rozdělují možnost uplatňování odpovědnosti na základě záruky za vady na hranici mezi 1 a 2, a možnost ukončení smlouvy na základě záruky za vady na hranici mezi 2 a 3.

Článek 634

1. Když je výrobek vadný, může objednatel požadovat od dodavatele opravu vady v přiměřené lhůtě. Toto však neplatí, pokud je vada nepodstatná a oprava by vyžadovala nepřiměřené náklady.

2. Objednatel může požadovat náhradu škody místo opravy vady, nebo spolu s opravou vady. V tomto případě se použije ustanovení článku 533.

Článek 635

Když je výrobek vadný a kvůli tomu není možné dosáhnout cíle smlouvy, může objednatel smlouvu zrušit. Toto však neplatí pro budovy a jiné stavby na pozemku.

Podrobnější vysvětlení těchto “vad” a jejich postupného rozlišování najdete v následujícím článku.

https://monolith.law/corporate/defect-warranty-liability[ja]

Poté jasně určete, co byste měli požadovat od dodavatele

Dále je třeba jasně určit, co požadujete od druhé strany. Pokud chcete zrušit smlouvu, nestačí prokázat, že je to vada, ale musíte prokázat, že je to tak závažné, že “není možné dosáhnout cíle smlouvy”. Při posuzování tohoto “cíle” jsou důležité zápisy z jednání na začátku projektu vývoje systému a položky uvedené ve specifikacích. Dokonce i po přijetí mohou chyby a nedostatky vyjít najevo později, takže je důležité pečlivě uchovávat všechny dokumenty i po ukončení projektu vývoje.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Kromě zrušení smlouvy můžete také požadovat náhradu škody nebo opravu vady jako součást záruky za vady.

Další důležité body

Při provádění právních úkonů, jako je zrušení smlouvy, je třeba věnovat pozornost způsobu provedení

Pokud se rozhodnete zrušit smlouvu jako součást odpovědnosti za vady, měli byste se také seznámit s tím, jak provést právní postupy potřebné pro zrušení. Podrobnosti o účincích zrušení smlouvy, o způsobu vyjádření platného úmyslu a o způsobu oznámení, které nezpůsobí problémy v budoucnosti, jsou podrobně vysvětleny v následujícím článku.

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

Řešení by mělo být dosaženo formou vyjednávání, nikoli sporu

Tato právní diskuse není relevantní pouze v případě, že dojde k soudnímu sporu. Řešení sporů soudem je pro obě strany velmi náročné. Naopak, tyto právní poznatky by měly být využity již v předchozí fázi vyjednávání. Jaký význam mají tyto právní poznatky v jednáních mimo soud, je vysvětleno v následujícím článku.

https://monolith.law/corporate/disputes-related-to-system-development[ja]

Chyby a nedostatky by měly být odlišeny od nedostatku funkcí

Diskuse se liší v závislosti na tom, zda existují chyby nebo nedostatky v implementovaných funkcích a specifikacích, nebo zda chybí potřebné funkce. Pokud nejsou k dispozici všechny potřebné funkce, může být “dokončení práce” v rámci smlouvy o dílo neuznáno a může být odmítnuto plnění dluhu.

Na druhé straně, i když nejsou k dispozici potřebné funkce a specifikace, pokud je to výsledek toho, že uživatel neposkytl adekvátní informace v fázi definování požadavků, může být nevhodné považovat to za součást smluvních podmínek.

Shrnutí

Problémy vzniklé v průběhu projektu se mohou projevit jak během jeho průběhu, tak až v provozní fázi nebo později. Charakteristickým rysem projektů vývoje systémů, které nezaručují klid ani po úspěšném dokončení všech fází, se zdá být systém “japonské záruky za vady”. Důležité je nejen důkladně spravovat dokumenty s ohledem na období po dokončení projektu vývoje systémů, ale také porozumět tomuto celkovému procesu.