V předchozím díle seriálu byly do větších podrobností představeny implementační smlouvy. Právě na implementaci nového informačního systému (software) obvykle následně navazuje období, ve kterém dochází k optimalizaci daného software, odstraňování jeho chyb a zahajování jeho běžného provozování, což se málokdy obejde bez zapojení tvůrce takového software. Z toho důvodu dochází zpravidla již s uzavřením implementační smlouvy (ne však vždy) k uzavření servisní smlouvy, jejímž účelem je podpora, údržba či další rozvoj implementovaného software. Obdobně jako implementační smlouvy nejsou servisní smlouvy samostatným smluvním typem dle občanského zákoníku.  

Vymezení předmětu 

Vymezení předmětu servisní smlouvy je velmi důležité, jelikož jednak reflektuje náklady dodavatele s poskytováním servisu, jednak skutečné potřeby objednatele. Obvykle bývá předmětem servisní smlouvy podpora, údržba, správa, provoz, rozvoj software, a to samostatně, nebo v různých kombinacích. Objednatel by měl ještě před uzavřením servisní smlouvy vědět, jaké služby bude potřebovat. Předně jestli chce aktivní servis (dodavatel vyhledává problémy nebo nedostatky sám) nebo pasivní (dodavatel reaguje až na oznámení objednatele). Jak objednatel potřebuje, aby software fungoval; jestli nepřetržitě (24/7), v pracovní dny (10/5), jestli má být součástí samostatný nástroj pro incident management – Service Desk umožňující udělování pokynů dodavateli prostřednictvím softwarového nástroje (lze si představit jako online chat), jak rychle objednatel potřebuje, aby dodavatel reagoval na jakékoliv podněty a odstraňoval problémy a nedostatky software a podobně. Tyto požadavky objednatele následně tvoří podmínky a požadavky na kvalitu poskytování servisních služeb (SLA – „Service Level Agreement“). Obecně platí, že čím přísněji jsou nastavené SLA, tím vyšší je cena za poskytování servisních služeb. Je tedy vhodné při stanovování SLA brát v úvahu především praktické využití software – například účetní systém objednatel obvykle nepotřebuje nepřetržitě (24/7), ale stačí mu v pracovní dny deset hodin denně (5/10).  

Kdy uzavírat? 

Jak bylo uvedeno výše, je vhodné servisní smlouvu uzavřít současně s implementační smlouvou, na základě které byl dodán anebo vytvořen software.  Samozřejmě pokud objednatel od počátku ví, že si nechá dodat software od jednoho dodavatele a servis mu bude poskytovat odlišný dodavatel, není uzavření obou smluv zároveň nezbytné. Pokud by z jakéhokoliv důvodu nebylo možné uzavřít implementační a servisní smlouvu zároveň, existují nejméně dvě další doporučeníhodné možnosti. Uzavření smlouvy o smlouvě budoucí, ve které bude obsah těla servisní smlouvy sjednán alespoň obecným způsobem a podmínky SLA s tím, že k samotnému uzavření servisní smlouvy dojde v budoucnu. Jako vhodný budoucí okamžik lze odporučit jakýkoliv okamžik před zahájením „ostrého“ provozu software. Další možností je stanovení základních parametrů SLA již v implementační smlouvě s tím, že servisní smlouva bude následně uzavřena s SLA stejnými nebo výhodnějšími pro objednatele. Jiný postup, například pozdní uzavření servisní smlouvy bez stanovení SLA již v implementační smlouvě, se obvykle odrazí na vyšší ceně SLA pro objednatele.  

Preambule 

Opět si dovolíme zdůraznit roli preambule, která může mít u servisních smluv patrně ještě významnější roli, než u implementační smlouvy. Sporů o interpretaci servisní smlouvy může totiž potenciálně vzniknout mnoho (například není dostatečně vymezena součinnost objednatele, provozovatele napojeného systému, jsou nejasně vymezeny sankce za vadné poskytování SLA apod). V preambuli by se tedy měl objevit účel a činnost, pro kterou objednatel užívá software ve svém podnikání, co by měl v obecnosti umět, včetně případného rozvoje software do budoucna a v neposlední řadě jaký je praktický účel servisní smlouvy. Existence a význam preambule se bohužel ukazuje často až u soudu, kde již je na její doplnění pozdě.  

Licence 

Licence není významná pouze v implementační smlouvě, ale v servisní smlouvě má také své opodstatnění a to ze dvou základních důvodů. Předně je nezbytné mít dostatečnou licenci k software k tomu, aby bylo možné uzavřít servisní smlouvu. Pokud je servisní smlouva uzavírána spolu s implementační, obvykle dané nebývá problém, ale pokud je například dodavatel software odlišný od poskytovatele servisu, získává licence ještě větší význam. V takovém případě musí být totiž objednatel oprávněn udělit oprávnění (podlicenci) poskytovateli, aby mohl servis poskytovat a zasahovat do software. Druhým důvodem je, že součástí servisních služeb je mnohdy rozvoj, například pokud chce objednatel rozšířit software o nové funkcionality. Pak by měl objednatel požadovat na poskytovateli servisu, aby mu k výstupům takového rozvoje, které budou obvykle počítačovými programy (tedy také software), poskytnul licenci alespoň v rozsahu, aby mohl takto nově vytvořené programy užívat spolu se software, nejlépe alespoň v rozsahu licence k software dle implementační smlouvy. Opět opakujeme dvě pravidla, na která jsme naráželi v předchozím článku a to: čím širší licence, tím obvykle vyšší cena za její udělení a tedy i za rozvoj software. 

Součinnost a rozlišování vad a incidentů 

Pokud jsme jako vhodnou součást implementační smlouvy zmiňovali správné vymezení součinnosti objednatele, u servisní smlouvy to platí dvojnásob, a to ze stejných důvodů. Servisní smlouva by měla obsahovat skutečně podrobně definovanou součinnost obou smluvních stran co do jejich odpovědnosti za provoz software. Pokud například software běží na hardware objednatele, měl by být objednatel odpovědný za provoz takového hardware a jeho udržování v dobrém stavu. Naopak poskytovatel by v případě proaktivního servisu měl sám vyhledávat případné nedostatky software a ty odstraňovat, provádět periodické činnosti se software (pročištění databáze, záloha software, záloha dat a podobně). K definici konkrétní odpovědnosti a součinnosti lze rovněž užít některé obecně přijímané standardy, například standardy ITIL.  

Častým problémem servisních smluv je odlišování vad a incidentů. Vadami se obvykle rozumí odchylky software od jeho specifikace dle implementační smlouvy, zatímco incidenty jsou často vnímané jako jakákoliv nefunkčnost software. Často se však zapomene, že vady nemusí být vždy incidentem a například pro odstraňování vad si smluvní strany nesjednají SLA. V takovém případě pak dodavatel sice odstraňuje incidenty, ale zásadní vadu, která znesnadňuje objednateli užívání software, odstraňuje v rámci odstraňování záručních vad, tedy bez stanovených SLA, jinými slovy bez nutnosti odstranit vadu například do 48 hodin od nahlášení. Proto lze pouze doporučit buď danou dichotomii vyloučit (uvedení, že vada je vždy incidentem) nebo přesně definovat, co se rozumí ještě vadou, co již je naopak incidentem, a stanovit SLA pro obě kategorie nedostatků software vedle sebe. Stejně jako rozdělení obou nedostatků software je vhodné jejich kategorizace do různých kategorií podle důležitosti a s tím spojené doby pro odstranění vad/incidentů. Každý jednotlivý objednatel může mít jiné potřeby a požadavky na funkčnost software (viz preambule a vymezení předmětu výše). Je tedy vhodné definovat ty zásadní, označit je za nejdůležitější kategorii a v rámci SLA požadovat jejich rychlé odstranění. Například pokud nefunguje malému podniku v jeho CRM systému (Customer Relations Management) políčko pro vyhledávání a nebude fungovat týden, nemusí to pro něj být takový problém, jako pro společnost s deseti tisíci zákazníků.  

Monitoring, sankce a odpovědnost za újmu 

Monitoring dodržování SLA je nezbytným nástrojem pro ohlídání kvality poskytovaných servisních služeb. Rozhodně lze doporučit monitorovací nástroj (instalovaný program, online nástroj či jiný mechanismus) nezávislý na poskytovateli servisu. Pokud servisní smlouva nepočítá s monitorovacím systémem, je následně velmi problematické dokazovat, že poskytovatel porušil SLA. Pochopitelně, stejně jako u implementačních smluv, je vhodné zvolit správný motivační mechanismus, který motivuje poskytovatele k tomu, aby poskytoval servis dle SLA – sankce. Pro obě smluvní strany je obvykle vhodný systém slev z pravidelné měsíční platby za servis. Jedná se ve fakticky o smluvní pokutu, ovšem s odlišným způsobem zúčtování. Stejným způsobem poslouží samozřejmě systém vhodných smluvních pokut. V této souvislosti je nezbytné zdůraznit, že pokud servisní smlouva obsahuje vzorec pro výpočet sankcí, je vhodné jej propočítat tak, aby nevycházela nesmyslná čísla, nebo naopak aby nevycházela příliš nízká sleva. Zároveň ovšem stanovení příliš vysoké slevy z ceny nebo smluvní pokuty může mít opačný efekt – tedy demotivující. Lze proto doporučit být při stanovování výše slev z ceny a smluvních pokut rozumný a vážit rizika obou smluvních stran.  

Zároveň je vhodné zmínit, že tržním standardem je omezení odpovědnosti za újmu způsobenou poskytovanými servisními službami. Absence takového omezení má obvykle významný dopad na cenu a je proto určitě ke zvážení, byť nutně nemusí být součástí servisní smlouvy.   

Osobní údaje  

Touto částí se dostáváme k často opomíjeným náležitostem servisních smluv, jejichž absence má zpravidla velmi závažné následky – exit a smlouva o zpracování osobních údajů. Pokud software pracuje s daty, která obsahují informaci, na základě které je možné identifikovat konkrétní fyzickou osobu a poskytovatel servisu může mít k takovým datům přístup, nebo s nimi dokonce přímo nakládat, bude zpravidla nezbytné uzavřít smlouvu o zpracování osobních údajů. Účelem takové smlouvy je zejména zabezpečení osobních údajů před jejich únikem a zneužitím. Náležitosti smlouvy o zpracování osobních údajů a povinnost ji uzavřít stanoví zákon č. 101/2000 Sb., o ochraně osobních údajů. Opět platí stejné doporučení, a to uzavřít smlouvu o zpracování osobních údajů se servisní smlouvou. Sankce za neuzavření smlouvy o zpracování osobních údajů nebo její nevhodné nastavení mohou jít do milionů korun; proto lze pouze doporučit nechat si takovou smlouvu připravit od odborníků, je-li nezbytná.  

Exit 

Byť je exit důležitý až na konci trvání servisní smlouvy, je jednou z jeho nejdůležitějších součástí již ve fázi sjednávání smlouvy. Jde o proces předání poskytování servisu novému poskytovateli, předání software objednateli, nebo zakonzervování software pro další užití v budoucnu. Jde tedy o stanovení toho, co se má dít se software a daty v něm uloženými po skončení trvání servisní smlouvy nebo bezprostředně předtím. To platí jak pro ukončení servisní smlouvy uplynutím stanovené doby, tak pro výpověď nebo odstoupení. Exit je vhodné rozdělit do dvou základních situací a to je předávání poskytování servisu novému poskytovateli nebo předávání (migrací) dat do nového softwarového řešení, kterým je software nahrazován. Pokud se jedná o předání servisu, je klíčový požadavek na poskytování součinnosti a informací dosavadním poskytovatelem novému poskytovateli, předání dokumentace, know-how base, incident managementu a výpisu incidentů, manuálů a příruček, to vše podle povahy software. Pokud jde o nahrazování software, klíčový bude zejména export dat do spustitelných databázových exportních souborů a předání objednateli k importu do nového řešení. Fáze exitu bude velmi rozdílná podle charakteru software – tedy jde-li o software na míru objednateli, krabicový software, opensource software a podobně. Účel je však vždy stejný – upravit práva a povinnosti smluvních stran v případě skončení trvání servisní smlouvy a toho, co se bude dít se software a daty v něm uloženými. 

O každé jednotlivé části tohoto článku je možné napsat samostatný článek a i tak to nebude postačovat ke sdělení všech úskalí, které servisní smlouva může přinášet. Pevně však doufáme, že tento článek Vám bude nápomocným v případě tvorby anebo uzavírání servisních smluv. 

Článek byl publikován v časopise IT Systems – https://www.systemonline.cz/

JUDr. Jan Diblík, advokát a partner
HAVEL&PARTNERS s.r.o, advokátní kancelář

JUDr. Samuel Král, advokát, HAVEL&PARTNERS s.r.o, advokátní kancelář