Kapitola třetí
platnost právního úkonu107. Většina smluv v oblasti IT je v tomto směru více či méně vadná. Nejrozšířenější vadou je tzv. beletristický popis předmětu plnění. Plnění je popsáno všeobecně, požaduje např., aby IT systém či program měl „všechny potřebné“ nebo „obvyklé“ vlastnosti, aniž by způsob, jak budou tyto vlastnosti určeny, byl jakkoliv specifikován. Tento postup je diktován snahou zákazníka formulovat vlastnosti programu či systému co nejobecněji, aby v případě, že některou z potřebných vlastností z neznalosti či nezkušenosti nepředvídal a nepožadoval, mohl ji v rámci obecně popsaného plnění požadovat jako vlastnost či funkčnost obvyklou či samozřejmou. Ve svém důsledku však takový postup znamená, že pokud neurčitý popis nezpůsobí neplatnost smlouvy, a tudíž i nevymahatelnost závazku, může paradoxně nastat situace, kdy zcela samozřejmá vlastnost či funkčnost nebude dodána, protože nejasný popis předmětu díla může být (v případě sporu i soudem) interpretován, že se strany jasně nedohodly, že dílo má tu či onu konkrétní vlastnost, a proto ji poskytovatel v rámci uzavřené smlouvy není povinen dodat. Další zásadní chybou je specifikace plnění termíny, které jsou sice běžně užívány, jejichž obsah však není nikde závazně definován. To platí zejména pro termíny jako „implementace“, „systémová integrace“, „lokalizace“, „outsourcing“, „update“, „upgrade“, „cloud computing“ a podobně. Tyto termíny nemají oporu v žádném právním předpisu, proto je nezbytně nutné je buď definovat nejlépe přímo ve smlouvě, nebo v dokumentu, který jejich obsah definuje, a který se tak stane nedílnou součástí smlouvy. Je zcela běžné, že se obě smluvní strany opírají o tyto zdánlivě odborné termíny, přičemž je každá strana chápe jinak. Řada uvedených termínů jsou v podstatě termíny obchodní a to, co nabízí jeden poskytovatel v rámci implementace, může být značně méně či více, než co pod zcela totožným názvem nabízí zcela legitimně konkurence. Není to tedy tak, že by snad některý z nich užíval příslušný termín chybně, ale vzhledem k tomu, že termín není definován, může jím kdokoliv označit, co si přeje – pokud ovšem termín přesně definuje přímo ve smlouvě, pak je jeho výklad nejen závazný, ale v rámci daného vztahu dokonce jediný možný. Dalším specifikem je, že na rozdíl od jiných oborů se setkáváme se situací, že při uzavírání smlouvy na začátku projektu smluvní strany často nemají jasnou představu o definitivní podobě či konkrétních vlastnostech plnění (dodávaného systému nebo vyvíjeného programu). Patrně ještě 107
Srov. § 37 občanského zákoníku.
84 Ukázka elektronické knihy, UID: KOS186323
Smluvní aspekty IT
přesnější je říci, že zatímco poskytovatel má profesionální vědomosti o možnostech a vlastnostech počítačového programu, ale velmi omezené znalosti o činnosti či provozu zákazníka, zákazník má naproti tomu velmi omezené znalosti o možnostech nabízeného systému, ale zná velmi dobře svoje potřeby a činnost, jíž se zabývá. Aby se tudíž vytvořil systém, který by optimálně sloužil zákazníkovi při současném optimálním využití předností systému, je nezbytně nutné vynaložit jak na straně zákazníka, tak na straně poskytovatele poměrně značné úsilí, a to optimálně ještě před uzavřením smlouvy. To je v praxi velký problém, protože obě strany se obvykle zdráhají vynaložit prostředky a energii v situaci, kdy tato oboustranná spolupráce může vyústit ve zjištění, že uvažovaný systém není vhodný pro uvažovaný projekt, a k uzavření předpokládaných smluv vůbec nedojde. Tento problém lze řešit teoreticky na straně poskytovatele tak, že nutnou analýzu u zákazníka provede poskytovatel na své náklady s tím, že tyto náklady jsou již zohledněny v ceně programu/systému. Toto řešení však poskytovatelé rozhodně nebudou preferovat, protože tyto náklady pro ně budou znamenat čistou ztrátu v případě, že se zamýšlená smlouva neuzavře, nehledě na to, že v praxi to znamená, že se produkty poskytovatele budou prodražovat, což ztíží jejich pozici na trhu. Druhým řešením je analýza vhodnosti programu či programů na náklady zákazníka – zde je problémem najít subjekt, který je schopen zpracovat takovou analýzu nestranně a nezávisle – subjekty schopné provést takovou analýzu jsou buď samy dodavateli podobného plnění, nebo v určitém vztahu např. ke konkurenci potenciálního poskytovatele. V praxi se tudíž často setkáváme se situací, že podrobná specifikace předmětu plnění není v době podpisu smlouvy dostatečně podrobně sjednána. Součástí smlouvy by tedy měl být i závazek vytvořit úvodní koncepci struktury informačních technologií (studii informačních technologií, analýzu potřeb a systému, plán implementace „blueprint“ atd.) s tím, že teprve tento dokument po schválení oběma stranami podrobně předmět smlouvy (vlastnosti či funkčnosti díla – programu/systému) specifikuje. Taková situace může představovat naprostou katastrofu jak pro zákazníka, tak pro poskytovatele. Autor jako rozhodce rozhodoval spory, kdy zákazník zcela účelově odmítal akceptovat výsledek úvodní analýzy, aby se vyhnul zaplacení za tuto část plnění (pokud je podstatnou částí takového plnění analýza, nelze znemožnit zákazníkovi její užití – zjištěnou znalost nelze prostě vymazat), a na druhé straně spory, kdy se zákazník právem domáhal toho, že dodavatel mu účelově vytvořil zbytečně naddimenzovaný systém, aby dosáhl většího plnění. Zatímco první situace je v krajním případě řešitelná patrně 85 Ukázka elektronické knihy, UID: KOS186323
Kapitola třetí
jen některým ze způsobů řešení sporu a znaleckým posudkem, druhá situace je řešitelná tím, že si strany sjednají maximální rozsah plnění a funkčností s tím, že v případě, že zákazník zjistí, že potřebuje menší rozsah, má možnost jednostranně sjednaný rozsah plnění snížit. V některých smlouvách se upřesnění podmínek plnění nazývá „kontrolní specifikace“. V kontrolní specifikaci se detailněji než ve smlouvě konkretizuje rozsah díla, stanovují se milníky provádění díla a upřesňují se akceptační kritéria. Aby mohla být pro obě smluvní strany kontrolní specifikace závazná, je nutné ji oběma stranami přijmout, proto by měla být již ve smlouvě stanovena pravidla pro samotnou akceptaci kontrolní specifikace. Pro tyto účely je rovněž vhodné sjednat důsledky, které mohou nastat v případech, kdy k takové akceptaci nedojde, a to ať už z důvodu vzniklého na straně zhotovitele, či objednatele. Kontrolní specifikace, i když je vyhotovena za součinnosti objednatele, je zpravidla samostatným výstupem zhotovitele, který má pro objednatele hodnotu samu o sobě, neboť mu přináší nové technologické poznatky a ukazuje cestu možných řešení. Z toho důvodu se doporučuje, aby za takový výstup zhotovitele byla sjednána samostatná odměna, a to právě pro případ, že spolupráce stran bude po vyhodnocení kontrolní specifikace ukončena.
3.4
Stanovení povinností stran
Ačkoliv se to zdá samozřejmé, v řadě případů nejsou povinnosti smluvních stran stanoveny jasně a jednoznačně. V některých případech je to ještě v důsledku přejímání špatně přeložených anglických textů nebo tím, že určité části textu ve smlouvě nezpracovává právník, ale odborník v IT. Ve smlouvě proto můžete objevit formulace jako „systém bude dodán“, „akceptační testy budou provedeny“, „závada bude odstraněna“, „systém bude opět zprovozněn“ a podobně. Tyto formulace byly původně způsobeny nesprávným přeložením slova shall v anglickém textu, který v běžné angličtině vyjadřuje budoucí čas, v právnické terminologii se však jedná o pomocné (modální) sloveso, které vyjadřuje povinnost ještě silnějším způsobem než podobné sloveso must. Proč se tyto formulace vyskytují setrvačností ještě dnes, je obtížně vysvětlitelné jinak než podceněním kontraktačního procesu smluvními stranami. V zájmu obou stran je, aby pokud je ve smlouvě stanovena povinnost či závazek, byla nejen jako závazek či povinnost jasně stanovena, ale také 86 Ukázka elektronické knihy, UID: KOS186323