Obchodní smlouvy v IT - 2. díl
Autor: Mgr. Petr Otevřel | Vloženo: 19. 2. 2007 08:59 | Přečteno: 10736XTento díl je věnován smlouvám o dodávce a implementaci. Tyto smlouvy, na základě kterých bývá „něco“ implementováno nebo dochází k zásadním změnám stávajících systémů či aplikací, jsou smluvním typem smlouvy o dílo. Implementací zde rozumíme dodávku a instalaci systémového řešení nebo aplikací a uvedení do rutinního provozu. Nicméně i v tomto případě je zapotřebí ošetřit celou řadu okolností, které se vymykají klasické smlouvě o dílo. Dále budou uvedeny vybrané oblasti, které jsou specifické a v praxi bývají často ošetřeny nedostatečně.
Vybraná problematika smluv o implementaci
Vymezení předmětu smlouvy
V minulém díle byla zmiňována důležitost vymezení účelu a cíle smlouvy. Předmět smlouvy by na toto měl navazovat a ve smlouvě by měl být přesně specifikován. Opět to zní banálně, ale v praxi smluvní strany často použijí nějakou obecnou smlouvu o dílo a uvedou, že dodavatel (zhotovitel) je povinen provést a předat dílo specifikované v příloze č. x. Pokud smlouva neobsahuje přesně vymezený účel a cíl smlouvy a příloha x je vágní nebo dokonce neúplná, dochází v praxi v průběhu plnění smlouvy k oboustrannému rozčarování a zklamání, které lze stručně shrnout asi takto: „Co by za ty peníze vlastně chtěli?!“ (stěžuje si dodavatel) a zároveň „Takových peněz už to stálo, nic pořádně nefunguje a za každou drobnost chtějí další!!“ (stěžuje si objednatel).
Předmět smlouvy by měl specifikovat přesné povinnosti zejména dodavatele, přitom lze vřele doporučit též negativní výčet toho, co dodavatel nezajišťuje – v německé právní praxi soudy např. dovozují, že není-li ve smlouvě uvedeno jinak, má dodavatel povinnost dodat spolu s implementací informačního systému též kompletní dokumentaci včetně uživatelské; u rozsáhlejších systémů je povinen též provést školení. V praxi přitom nebývá dodávka kompletní dokumentace nutná, zejména tam, kde se jedná o implementaci systémových řešení, kdy správu a údržbu zpravidla zajišťuje dodavatel na základě zvláštní smlouvy. V některých případech postačí odkaz na internetové stránky příslušných výrobců, na kterých je uvedena dokumentace v elektronické podobě. Do negativního výčtu předmětu smlouvy zpravidla uvádíme průběžnou správu a údržbu, zálohování dat, telekomunikační a webhostingové služby, provedení elektroinstalací či vzduchotechniky apod.
U větších projektů bývá zpravidla proces implementace rozdělen do jednotlivých fází, kdy smlouva vychází z hrubého konceptu řešení, zatímco samotná implementace probíhá na základě tzv. implementačního projektu, který je vytvářen v první fázi projektu - implementační projekt pak tvoří přesnou technickou specifikaci předmětu smlouvy, která je ve shora popsaném případě dotvářena až po podpisu smlouvy. Jednotlivé fáze jsou „plovoucí“, a to v závislosti na odsouhlasení fáze předchozí, v prvé fázi tedy v závislosti na odsouhlasení implementačního projektu. Protože se technická specifikace doplňuje někdy až po uzavření smlouvy, je o to důležitější upravit ve smlouvě postup při schvalování implementačního projektu, případném jeho doplňování nebo námitkám ze strany objednatele (např. povinnost dát námitky v určité lhůtě a zdůvodnit je, vhodná je též fikce udělení souhlasu v případě nepodání námitek ve lhůtě).
Dodávka hardware, síťových komponent, spotřebního materiálu
Zvláště u větších projektů bývá obvyklé, že je dodavatel realizuje komplexně, včetně dodávky hardware (zejména serverů) a garantuje funkcionalitu celého systému. V této souvislosti je vhodné upravit některá specifika. Pokud dodává hardware jako jeho vlastník, pak se jedná o kupní smlouvu, která je v obchodním zákoníku poměrně dobře upravena včetně odpovědnosti za vady.
Pokud však dodavatel pouze zprostředkovává dodávku hardware, je vhodné upravit, kdo je odpovědný za převzetí hardware, kontrolu nákladních listů či jiné přepravní dokumentace a její soulad s dodaným zbožím. Použije-li výrobce hardware dopravní společnost a hardware bude poškozen, nabývá jeho převzetím objednatel práva k uplatnění případných škod – s tímto právem je spojena určitá důkazní povinnost a také tuto otázku je vhodné ve smlouvě řešit (čím později začneme uplatňovat, tím hůře prokazujeme důvod vzniku škody).
Obchodní zákoníku ukládá kupujícímu povinnost provést s odbornou péčí prohlídku převzatého zboží – pro které zde užíváme pojem „hardware“ – a oznámit bez zbytečného odkladu jeho vady. Pokud tak neučiní, v podstatě ztrácí své zákonné nároky z titulu odpovědnosti za vady a pak je na vůli výrobce/prodávajícího, zda objednateli bezplatně vady odstraní nebo provede výměnu hardware. Tuto povinnost by měla smlouva vždy ukládat dodavateli, který je osobou odborně způsobilou takovou prohlídku provést.
Dodávka software
Problematika software by vydala na několik článků a nelze ji v rámci tohoto článku rozebrat, proto zde pouze telegraficky.
Dodává-li dodavatel vlastní již hotový software, u něhož probíhá pouze customizace (např. při implementaci ERP systému), pak je sjednávána licenční smlouva. Pokud dodavatel zhotovuje software na míru, pak toto spadá do režimu „zhotovení díla na objednávku“ dle autorského zákona, který objednateli k takto zhotovenému software popř. databázím dává stejná práva, jako má zaměstnavatel k dílu zhotovenému jeho zaměstnancem, tzn. práva takřka absolutní. Autorský zákon však připouští možnost sjednat si režim práv odchylně; pokud dodavatel chce software nebo jeho části užít i v jiných případech, musí proto sjednat licenci ve smlouvě.
Je-li v rámci širšího řešení dodáván software třetích výrobců, pak by musí dodavatel vycházet z licenčních podmínek jeho výrobce a seznámit s těmito podmínkami objednatele. Neučiní-li tak, může být v případě nelegálního užití takového software (např. překročení sjednaného počtu instalací) sporné, kdo je odpovědným z takové situace.
Školení
Na školení obvykle smlouvy o implementacích pamatují, byť bývá úprava poměrně vágní. V německy mluvících zemích bývá smluvní úprava podstatně preciznější, a to především „zásluhou“ soudů, které judikovaly obsáhlou povinnost dodavatelů poskytnout školení. Tuto povinnost považují soudy za dílčí plnění bezprostředně související s hlavním závazkem ze smlouvy. V SRN dokonce soud rozhodnul, že objednatel není povinen systém převzít, nebude-li provedeno bezplatně řádné školení v přiměřeném rozsahu.
V Rakousku zase objednatel úspěšně zažaloval dodavatele o bezplatné poskytnutí dodatečného školení (které dodavatel nabízel za úplatu), protože rozsah dosud bezplatně poskytnutého školení byl shledán nedostatečným. Neobsahuje-li smlouva jinou úpravu, rozsah školení by měl dle soudu být posuzován individuálně v závislosti na složitosti dodávaného systémového řešení či aplikací. Soud dále dovodil povinnost školit v sídle objednatele (není-li sjednáno jinak).
Opět se dostáváme k zásadám správné kontraktace, kde platí, že i velmi tvrdě vyjednaná, ale zato precizní smlouva, může předejít zbytečným sporům a pocitům křivdy na té které straně. V prvním shora uvedeném případě smlouva výslovná ustanovení o rozsahu školení neobsahovala, ve druhém dodavatel rozsah buď podcenil (např. proto, že si na počátku neověřil počítačovou gramotnost zaměstnanců objednatele), popř. se pokoušel zvýšit si tímto způsobem marži.
Součinnost objednatele
Obchodní zákoník řeší součinnost objednatele pouze vágně konstatováním, že ji objednatel poskytnout musí. Přitom jde o zásadní podmínku řádné implementace a má vliv na splnění povinností dodavatele a tedy i na vznik případné škody nebo nároku objednatele na smluvní pokutu (ani v těch nejhorších smlouvách zpravidla nechybí smluvní pokuty za prodlení s dodáním). Některé požadavky dodavatelů na součinnost přitom nemusí být objednatelem považovány za běžné či přiměřené. Dobře ošetřená součinnost proto může předejít nedorozuměním a pozdějším sporům.
Nezbytná je povinnost objednatele sdělovat včas informace a předávat případné podklady (týkající se zejména stávající HW infrastruktury objednatele a jeho provozních specifik), včetně práva dodavatele vyžadovat doplňující informace, pokud odůvodní jejich účelnost. O informace by měl dodavatel žádat v určitém předstihu, objednatel by je měl podávat v bez zbytečného odkladu. Tato otázka může být řešena též na jiném místě ve smlouvě, a sice v části týkající se projektového managementu.
Také by měly být vytvořeny podmínky pro působení projektového týmu. U větších projektů se považuje za vhodné, aby mohli vybraní zástupci projektového týmu za dodavatele působit přímo u objednatele, který jim přidělí prostory. Nejdeme-li tak daleko, je vhodné si předem vyjasnit, v jakém rozsahu potřebují zaměstnanci dodavatele přístup na jednotlivé provozovny (24 hodin denně/mezi … a … hod; o víkendech, o svátcích, pouze v pracovních dnech).
S úpravou stávající infrastruktury stejně jako s implementací systémového či aplikačního software či prováděním migrace dat jsou spojeny výpadky a omezení provozu. Také toto je vhodné ošetřit ve smlouvě tak, aby bylo patrno, že to objednatel vzal na vědomí.
Budou-li prováděny zkoušky jednorázově na simulovaných datech, je třeba předem projednat scénář zkoušek; objednatel by měl pro tyto účely uvolnit zaměstnance, kteří budou předem proškoleni, jinak nebude moci být dost dobře simulováno zatížení systému a namísto zkoušek bude dodavatel školit. Probíhá-li testování za ostrého provozu za souběžného provozu dosavadního systému či aplikací, měl by si být objednatel vědom toho, že dojde ke snížení efektivity a zpomalení některých procesů (včetně případného nárůstu přesčasových hodin).
Existuje celá řada dalších příkladů, kdy je vhodné sjednat součinnost výslovně. V této souvislosti je na místě také výslovně upravit, že objednateli nevznikají/vznikají nároky na náhrady nákladů souvisejících s poskytnutím součinnosti, např. za prostoje zaměstnanců, jejich účast na testech či zkouškách aj.
Autor tohoto článku se zatím nesetkal s návrhem smlouvy (s výjimkou jeho vlastních), který by řešil situaci, kdy objednatel součinnost neposkytne. Ze zákona v tomto případě vyplývá pouze to, že objednateli nevzniká nárok na škodu a že by dodavatel mohl neposkytnutí součinnosti považovat za podstatné porušení smlouvy a od této odstoupit. Ve smlouvách je zpravidla též upraveno, že se o tuto dobu posouvají termíny splnění. Nicméně by měl být řešen také režim situace, kdy objednatel po určité době, kdy součinnost nebyl schopen poskytnout, oznámí dodavateli, že „už může přijít“. Protože jde o sofistikované činnosti, není často možné reagovat na výzvu objednatele obratem – smlouva by měla stanovit lhůty a režim, jakým spolu smluvní strany komunikují (pro případ pozdějších sporů).
Odpovědnost za vady
Problematika vad je obchodním zákoníkem řešena poměrně dobře, nicméně tato zákonná úprava obsahuje řadu pojmů obecných, jejichž výklad je subjektivní. I toto téma by vydalo na několik samostatných článků.
Už vymezení toho, co je vlastně vadou, může působit potíže. Zákon uvádí, že by mělo „dílo“ odpovídat výsledku určenému ve smlouvě. V německé praxi je doporučováno, aby si objednatel sjednal, že dodaný systém či aplikace bude mít vlastnosti odpovídající aktuálnímu stavu technických znalostí, čímž se rozumí, že funkcionalita systému či aplikace je prokazatelně ověřená a bude rezistentní vůči existujícím bezpečnostním hrozbám.
Ve smlouvách bývají zpravidla sjednány doby reakce a doby odstranění vad (často závislé na povaze – kategorii vady), na tato ustanovení navazují smluvní pokuty. Je proto vhodné věnovat náležitou pozornost vlastnostem, které by měl implementovaný systém či aplikace mít. Rovněž je vhodné si výslovně sjednat, že běžná chybová hlášení, které nemají vliv na funkcionalitu, se nepovažují za vady – jinak může být sporné, zda vzniká objednateli nárok na smluvní pokutu jenom proto, že se např. uživatelům při přihlášení pracovní stanice do sítě zobrazí chybové hlášení, které však stanici ani síť nijak negativně neovlivňuje.
V praxi bývá zpravidla opomíjena zákonná povinnost objednatele „předmět díla prohlídnout nebo zajistit jeho prohlídku co nejdříve po předání“, přitom „soud nepřizná objednateli právo z vad díla, jestliže je objednatel neoznámí bez zbytečného odkladu poté, kdy je měl zjistit při vynaložení odborné péče při prohlídce“. Tato úprava je dispozitivní a odpovídá spíše vztahu subdodavatel – investor, kdy na obou stranách jsou osoby stejné odbornosti, zatímco v případě implementací jsou objednatelé v poněkud nerovném postavení. Je proto vhodné sjednat si provádění zkoušek a jejich protokolaci.
Rovněž práva objednatele z vad jsou dispozitivní a je přípustná odlišná úprava. V praxi je zažitý systém dělení vad do dvou nebo více kategorií (např. havárie, výpadek), čímž se dodavatel brání mj. i nevhodnému výběru nároku ze strany objednatele, který by jinak mohl požadovat rovnou slevu z ceny nebo od smlouvy odstoupit.
Náležitá pozornost by měla být věnována též řádnému oznamování vad ze strany objednatele. Vhodné jsou připravené formuláře (nejlépe elektronické, které umožňují archivaci), přičemž by měl být objednatel povinen zaslat bez zbytečného odkladu popis vad a přiložit chybová hlášení. Namístě je i výslovné ujednání o tom, že dodavateli vzniká nárok na náhradu nákladů tehdy, kdy prokáže, že vada vznikla prokazatelně zavinění třetí osoby nebo objednatele.
Odpovědnost za škodu
Odpovědnost za škody je mnohdy podceňována a navíc se do smluvní úpravy vkrádají termíny anglosaského práva, jako je „vyšší moc“. Pod vyšší moc, která zprošťuje dodavatele odpovědnosti za škodu, bývají zpravidla uváděny příklady, které lze zařadit do kategorie tzv. okolností vylučujících odpovědnost dle § 374 obchodního zákoníku. V některých případech se úprava „vyšší moci“ ve smlouvě zčásti překrývá s ust. § 374 obchodního zákoníku, a částečně ji rozšiřuje. Podle judikatury soudů však nelze neúměrně rozšiřovat okruh okolností vylučujících odpovědnost, protože by to vlastně znamenalo vzdání se práva na náhradu škody předem. Neodpovídá-li smluvní úprava české terminologii a soudní praxi, může to vést až k tomu, že soud prohlásí tuto smluvní úpravu za neplatnou (a smluvní strana, která z této úpravy chtěla těžit, se takto může ocitnout zcela bez ochrany).
Mnohem vhodnější je proto negativní výčet v předmětu smlouvy (viz výše) spolu s podrobně upravenou součinností objednatele. Při řádné smluvní úpravě může dodavatel legitimně namítnout, že za určité výpadky či omezení nenese odpovědnost. Objednatele může přimět k větší ostražitosti. Je známo (nikoli však každému běžnému uživateli), že už na instalaci prostých ovladačů k novému typu tiskárny může systém zareagovat úplným zhroucením. Dobře sjednaná smlouva by měla pro tento případ nejen chránit dodavatele před nároky na náhradu škody, ale vůbec něčemu takovému předejít i na straně objednatele.
Závěr
Shora uvedená doporučení a náměty na vhodnou smluvní úpravu nejsou a nemohou být v tomto rozsahu vyčerpávající. Stále je třeba vycházet z tezí obsažených v prvním díle, kdy mnohdy dobře míněný úmysl na jednoduché a stručné smlouvy někdy vyvolají opravdovou smršť právních rozborů, žalob, znaleckých posudků a právní nejistoty, ještě častěji rozčarování některé nebo obou smluvních stran. Jak uvádí autoři první níže zmíněné publikace, „dodavatel, který striktně požaduje jasné podmínky, jasné požadavky v přesných termínech a sám je ochoten pracovat pouze za takto přesně stanovených podmínek, je obvykle důvěryhodnější než ten, který hned vše slíbí, souhlasí se vším a tváří se, že vše dokáže okamžitě udělat.“
Použitá literatura
Vrana, I., Richta, K.: Zásady a postupy zavádění podnikových informačních systémů, Praha: Grada, 2005
Jaburek, W. J.: Handbuch der EDV-Verträge, Wien: Verlag Medien und Recht, 2000
Autor: Petr Otevřel
Autor působí v advokátní kanceláři Jansa, Mokrý, Otevřel & partneři v.o.s., kde se zabývá zejména smluvní úpravou v oblasti informačních technologií, obchodnímu a autorskému právu. Je členem České společnosti pro systémovou integraci a je zapsán v Národním registru poradců agentury CZECHINVEST.
Kategorie
Naše služby
Naše infoportály
Kniha Softwarové právo
