Smlouva se jako základ projektů při dodávkách podnikových informačních systémů nebo služeb často stává předmětem diskuse až v okamžiku, kdy nastane závažnější problém. Není přitom výjimkou, že strany v takových případech hledají jakoukoliv, byť formální, trhlinu, která by jim v řešení sporu pomohla. Proto je vhodné věnovat smlouvám patřičnou pozornost. A to právě i v rámci prevence vleklých sporů.

Dalším přínosem smluv, který strany často opomíjejí, je nutnost jasně formulovat vzájemné požadavky. I když si dodavatel se zákazníkem většinou rozumějí, teprve v okamžiku, kdy mají svou dohodu formulovat písemně, objeví se otázky, které do této doby vůbec neřešili.

Co by ale správná IT smlouva v oblasti implementace podnikového informačního systému a poskytování služeb měla obsahovat? Ve smlouvách je především nutné jednoznačně, srozumitelně a jasně specifikovat předmět plnění a proces jeho realizace. Ne vždy má management podniků hned na začátku zcela jasnou představu o tom, jak má informační systém fungovat. Proto bývají podobné projekty rozděleny do dvou fází – analytické a realizační.

Z hlediska smluvního nečiní zásadní problémy situace, kdy je vytvoření analýzy (jakožto podrobného zadání pro dodavatele IT) dodáváno nezávisle na samotné implementaci, a to na základě samostatné smlouvy. V praxi je však velmi často analýza součástí samotného procesu implementace. Z právního hlediska to znamená, že smlouva obsahuje konkrétní vymezení části plnění (obsahuje ujednání o tom, jak by měl vypadat výstup analýzy) a víceméně obecné vymezení ostatního plnění (samotná implementace totiž může být ovlivněna výsledkem analýzy). V takových případech je zejména nutné vyřešit otázku, jak postupovat, když zákazník odmítne převzít analýzu? Nebo co když analýza prokáže nutnost navýšit cenu celkové implementace?

Řešení závisí vždy na konkrétních okolnostech případu. Někdy může smlouva obsahovat vymezení celého informačního systému s tím, že pokud zákazník akceptuje v rámci analýzy změny, budou tyto změny transponovány do celkového zadání. Pokud tedy zákazník naopak analýzu neakceptuje, postupuje dodavatel dle původního zadání. Alternativně lze například sjednat právo zákazníka odstoupit od smlouvy v části implementace, pokud nesouhlasí s dalším postupem dle analýzy, přičemž v takovém případě uhradí dodavateli cenu za práce na analýze. Samozřejmě, pokud by dodavatel při tvorbě analýzy porušil své povinnosti, tj. analýza by obsahovala chyby, pak by se měl vždy uplatnit režim odpovědnosti za takové vady se všemi myslitelnými důsledky (nárok na opravu chyb, nárok na odstoupení od smlouvy apod.). Aby však bylo možné dojít k závěru, že analýza obsahuje vady, je skutečně nutné ve smlouvě jednoznačně specifikovat, jaké parametry má analýza splňovat.

Vedle specifikace plnění by smlouva měla vždy obsahovat i proces převzetí tohoto plnění zákazníkem, a to tak, aby byla garantována práva zákazníka na řádné plnění i práva dodavatele na to, aby za řádně provedené plnění dostal zaplacenu stanovenou odměnu. V případě implementace by smlouvy neměly ignorovat možné situace, kdy například zákazník neposkytne včas potřebnou součinnost nebo začne informační systém užívat bez toho, aby ho předem akceptoval. Zákazník by měl naopak dbát zejména o to, aby na základě písemné specifikace bylo zřejmé, kdy vlastně má systém vady, tj. kdy je oprávněn požadovat po dodavateli nápravu. Ne výjimečně se totiž stává, že zákazník si teprve během implementace uvědomí, že určitou funkcionalitu si „představoval“ trochu jinak, přičemž ale specifikace díla tuto jeho představu neobsahuje. Častou praktickou chybou je, že strany ponechávají tuto otázku bez řešení a odkazují na budoucí dohodu. Právě taková dohoda však není na konci projektu snadná. Ne výjimečně končí podobný spor dokonce u soudu.

Problematičtější otázkou je předání plnění ve formě služeb. Jde-li o podnikové informační systémy, patří sem vedle různých upgradů či úprav systému zejména jeho údržba. Služba, jakožto výkon, má v mnoha případech určitý výstup. Na ten pak lze vztáhnout podmínky obdobné podmínkám pro převzetí implementovaného systému (nepřebírají se tak služby, ale výstupy těchto služeb). V ostatních případech je pak zřejmě jedinou měřitelnou hodnotou kvalita osob tyto služby poskytujících a samozřejmě i časový rozsah služeb. Obě smluvní strany by si měly vždy uvědomit, v čem konkrétně poskytovaná služba spočívá a jak je možné hodnotit, zda byla poskytnuta řádně, či nikoliv. A tento princip opět co nejjednoznačněji vtělit do smlouvy.

Zcela samostatnou, nikoliv však nepodstatnou stránkou podobných IT projektů je úprava autorských práv, tj. práv zákazníka nakládat s informačním systémem. Licenční ujednání by vždy mělo odpovědět na základní otázky typu:

• Kdo může informační systém užívat? Zde je nutné důkladně zvážit, zda k systému budou přistupovat pouze zaměstnanci zákazníka, nebo například i s ním propojené společnosti, smluvní partneři, zákazníci, dodavatelé apod.
• Jak dlouho bude licence účinná? Standardně lze odlišit licence poskytnuté na dobu „trvání majetkových práv“ k dílu (tj. na dobu, kdy je předmětný systém chráněn autorským právem“) a na dobu omezenou časovým rozsahem (např. na dva roky).
• Kde může být informační systém užíván? Působí zákazník skutečně výhradně v České republice? Neuvažuje o možném rozšíření činnosti v zahraničí?
• Jak může být informační systém užíván? Smlouva by měla jasně stanovit, zda zákazník smí například systém dále rozšiřovat či upravovat apod.

Podstatnou součástí smlouvy je i otázka řešení sporů. Stále oblíbenějším řešením je přenechat rozhodování sporů, které strany nejsou s to urovnat dohodou, rozhodčím soudům v rámci rozhodčích řízení. Ta umožňují řešit spory rychle, za účasti věci znalých rozhodců a neveřejně.

V mnoha implementačních i servisních smlouvách bývá podceněna též část věnovaná zániku právního vztahu. V případě implementace by si strany měly udělat zcela jasno v tom, jaké dopady bude mít případné odstoupení od smlouvy na již provedená plnění, dodané licence apod., a tuto dohodu pak srozumitelně zformulovat do smlouvy. U služeb může být situace o něco komplikovanější, protože zákazník může mít například zájem ponechat si informační systém vytvořený původním dodavatelem, služby ale plánuje čerpat od třetích stran. Na to se musí pamatovat při přípravě smlouvy nejen v části týkající se licencí, ale právě i v ustanoveních o dopadech zániku smlouvy. Často je totiž v rámci změny poskytovatele služeb nutná určitá spolupráce s poskytovatelem stávajícím (například při migraci dat apod.).

Existuje tedy vůbec nějaký obecný recept na to, jak z právního hlediska správně ošetřit smlouvy v IT? Ačkoliv při přípravě smluv narazí dodavatelé i zákazníci mnohokrát na poměrně složité konkrétní právní otázky, určité obecné recepty existují. Smluvní strany by vždy měly v rámci předsmluvních jednání vystupovat s maximální otevřeností. Stejně tak by měly vždy usilovat o to, aby smlouvy byly oboustranně vyvážené v režimu win–win. A nelze zapomenout ani na problém, který v českém prostředí a na trhu IT platí dvojnásob – pak řada smluv trpí zcela nepochopitelnou, leč velmi kritickou vadou, kterou je nesrozumitelnost. Autoři těchto smluv, s právním vzděláním, i bez něho, se často poměrně složitými formulacemi snaží vtělit do smlouvy v zásadě jednoduché principy. Zapomínají přitom na rizika s tím spojená – nebude-li smlouvě rozumět dodavatel stejně jako zákazník, objevuje se první možný důvod budoucího střetu. Je-li smlouva nesrozumitelná do té úrovně, že z ní vůbec není jasné, co má které ustanovení říci, pak jí (nebo aspoň dotčenému ustanovení) hrozí neplatnost. Při tvorbě smluv by navíc strany vždy měly vést v patrnosti, že těmto dokumentům musí rozumět nejen osoby, které stojí u jejich zrodu, ale i jejich případní nástupci a, v případě zásadnějšího sporu, i soudy.