Pro objednatele by servisní smlouva měla zajistit bezproblémovou funkčnost softwaru v období po nákupu licence, pro dodavatele je servisní smlouva zárukou pravidelného a opakujícího se zdroje příjmu po dokončení softwarové dodávky.
V tomto článku vysvětlím, co je to servisní smlouva, kdo by měl servisní smlouvu uzavřít a jaké minimální náležitosti (z mého subjektivního pohledu) by servisní smlouva měla obsahovat.
Servisní smlouva je dohoda mezi dodavatelem softwaru a objednatelem o údržbě a případně též podpoře, kterou zajistí dodavatel.
Servisní smlouva je tzv. nepojmenovanou smlouvou ve smyslu § 1746 odst. 2 Občanského zákoníku („ObčZ”). To znamená, že neexistuje podpůrná zákonná úprava servisní smlouvy oproti například smlouvě licenční, která je vymezena v § 2358 a násl. ObčZ.
Běžnou vlastností softwaru je, že po čase přestane fungovat, protože je závislý na softwaru a hardwaru třetích stran, se kterými komunikuje nebo na kterých běží. Dalším důležitým aspektem softwaru je, že když přestane fungovat, není zpravidla čas na to dohadovat se, jestli se jedná o vadu, za kterou nese odpovědnost dodavatel či nikoliv, a čekat na odstranění takové vady v zákonných lhůtách (v přiměřené době).[1]
Účelem servisní smlouvy je tedy zejména zajistit kontinuální a (relativně) bezproblémový provoz softwaru, a to jak:
preventivní údržbou,
reaktivní údržbou,
či poskytováním podpory.
Úroveň dostupnosti služeb, kterou se dodavatel zavázal na základě dohody s objednatelem v servisní smlouvě zajistit, se někdy označuje jako SLA, tj. service level agreement. V souvislosti se servisními smlouvami proto občas strany hovoří o úrovni SLA. O dostupnosti se píše podrobněji dále v článku.
Je zřejmé, že investovat do pořízení softwaru, který má plnit klíčovou funkci, aniž by došlo k uzavření servisní smlouvy k takovému softwaru, by mohlo být fatální. Software, který si zaslouží servisní smlouvu s dodavatelem, je zejména:
podnikový informační systém (ERP),
systém pro správu zakázek a zákazníků (CRM),
jakýkoliv back-end webových stránek (e-shopy, fóra, systémy pro elektronickou komunikaci, jiné druhy on-line platforem),
systém pro správu spisů advokátní kanceláře
nebo systém pro vymáhání pohledávek. Dalších příkladů bychom našli bezpočet.
Když se bavíme o servisní smlouvě, někdy mají klienti představu, že se týká jen dodávek masivních on-prem IT systémů. Určitou úroveň dostupnosti, servis, podporu apod. by však měli garantovat i poskytovatelé SaaS řešení nebo dodavatelé webových stránek. Jednoduché doporučení tedy zní – mít servisní smlouvu na každé softwarové řešení, které je pro objednatele důležité.
Řada softwarových řešení a služeb, které jsou pro objednatele důležité, již mají určitou servisní smlouvu zpravidla obsaženou v podmínkách užívání (angl. terms & conditions) předmětné služby. U zbývajících služeb a řešení je nutné servis dodatečně vyjednat.
Servisní smlouvu by tedy měl mít každý podnikatel ve vztahu alespoň ke svým:
webovým stránkám,
všem e-commerce softwarovým řešením, pokud nějaké podnikatel používá (e-shopy, systémy pro správu newsletterů, analytické nástroje),
ERP systémům,
CRM systémům,
účetnímu systému
nebo systému pro správu pohledávek.
Jak jsem uvedl výše, servisní smlouva je nepojmenovanou smlouvou ve smyslu ObčZ. To zjednodušeně znamená, že servisní smlouva má jen takový obsah, jaký do ní smluvní strany vtisknou vyjádřením své vůle. Zákon na servisní smlouvu neklade žádné minimální požadavky snad kromě obecných požadavků pro účinnost právního jednání. Když v tomto článku píši o minimálních náležitostech, myslím tím tedy náležitosti, které jsou nezbytné pro to, aby smlouva pro obě strany (objednatele a dodavatele) měla smysl a přinesla jim kýžený užitek.
Bohužel, řada servisních smluv není formulována dostatečně určitě a nenaplní očekávání stran. Často se setkávám se servisní smlouvou, která např. obsahuje podobný závazek bez další specifikace:
„Software bude mít dostupnost 99,9 %.“
Na papíře to vypadá skvěle, ale takový závazek je ve skutečnosti naprosto neurčitý – kdo tuto dostupnost zajistí? Jedná se o 99,9 % času v pracovní době, kalendářním týdnu, měsíci? Jak se bude dostupnost měřit? Pokud dojde k porušení tohoto závazku, jaké to bude mít pro dodavatele následky?
V případě sporu mezi dodavatelem a objednatelem, bez dalších podrobností, taková servisní smlouva neposlouží svému účelu, protože nejasnosti dávají prostor vleklému sporu, což jde naprosto proti smyslu servisní smlouvy, kterým je zajistit okamžitou reakci a bezproblémový provoz IT systému.
Na náležitosti servisní smlouvy bylo sepsáno několik skvělých publikací. V tomto článku chci proto popsat jen ty náležitosti, které považuji za naprosto klíčové a bez kterých podle mého názoru nemá smysl servisní smlouvu vůbec uzavírat. Jedná se o:
vymezení předmětu servisní smlouvy, tedy vymezení služeb, které dodavatel poskytuje objednateli na základě servisní smlouvy,
určení parametrů poskytovaných služeb, jako je například zmiňovaná minimální dostupnost, reakční doby a doby pro odstranění incidentů a
systém řešení nedodržení sjednané úrovně dostupnosti služeb.
Servisní smlouva by v sobě vždy měla obsahovat specifikaci jejího předmětu, tj. jaké servisní služby na základě smlouvy dodavatel objednateli poskytuje. Existuje celá řada servisních služeb, jmenovitě například:
garance minimální dostupnosti (preventivní údržba),
odstraňování incidentů (reaktivní údržba),
nárok na bezplatné updates a případně upgrades,
helpdesk nebo jiná forma podpory (telefon, e-mail),
migrace dat, zálohování nebo jiná správa dat,
customizace softwaru apod.
Jak jsem uvedl výše, neexistuje podpůrná zákonná úprava servisních smluv. Každá strana přitom může při vyjednávání servisní smlouvy myslet na jiný rozsah jejího předmětu. Je proto vysoce důležité při vyjednávání „vyložit na stůl” všechny požadavky a pak se vzájemně dohodnout na přesném rozsahu servisních služeb.
Každá ze sjednaných servisních služeb by měla ve smlouvě být vyspecifikovaná, tj. mělo by být uvedeno, co konkrétní služba znamená, jak se bude realizovat a případně jaké bude mít parametry.
Na výše uvedeném případu „99,9% dostupnosti“ bylo patrné, jaké nejasnosti vyplynou, když není sjednáno, jak bude měřena garantovaná dostupnost softwaru, jaké bude mít porušení následky apod. Doporučuji nadefinovat všechny klíčové servisní služby a jejich parametry.
Dostupnost může být definována kvalitativně jako pravděpodobnost, že systém bude schopen fungovat podle specifikací v jakémkoli okamžiku po celou stanovenou dobu. Dostupnost také může být definována kvantitativně jako poměr času, kdy je systém dostupný k celkovému času, po který je systém nasazen.
Co se týče hodnocení splnění parametru dostupnosti, je vždy důležité nastavit dva parametry a sice úroveň dostupnosti a dobu, za jakou se tato úroveň měří. Typicky může být dostupnost vyjádřena například jako 99,9 % z provozní doby za měsíc. Procentuální hodnota přitom vyjadřuje onen poměr času, kdy je systém dostupný k celkovém času provozu. Významné jsou však i ostatní uvedené prvky, a sice určení, že úroveň dostupnosti se hodnotí z provozní doby a že časové období hodnocení je jeden měsíc.
U reaktivního odstraňování incidentů doporučuji vždy sjednat alespoň způsob, jakým budou hlášeny incidenty, jejich kategorizaci, reakční doby a doby pro odstranění incidentů. U posledního zmíněného parametru se pozastavím – některé servisní smlouvy neobsahují stanovenou dobu pro odstranění incidentu, ale namísto toho obsahují závazek dodavatele vyvinout úsilí incident v nějaké době odstranit. To může pochopitelně být v pořádku, protože je při sjednávání servisní smlouvy těžko odhadnutelné, v jaké době je možné objektivně odstranit všechny možné incidenty. Znamená to, že pokud dodavatel vyvine úsilí, ale nedojde k odstranění incidentu v uvedené době, nedochází z jeho strany k porušení smlouvy. V takovém případě by však servisní smlouva vždy měla navíc obsahovat závazek dodavatele incident odstranit bez zbytečného odkladu po jeho zjištění. Dále je vhodné sjednat, co znamená „odstranění incidentu” a zda tato kategorie zahrnuje i případné „workarounds” tedy dodání alternativního postupu objednateli, jak užívat software, aby došlo k obejití chyb, i když nedošlo k jejich trvalému odstranění.
Častou součástí servisních smluv je nárok objednatele na bezplatné updaty a případně upgrady. Z pohledu objednatele je zde důležité nadefinovat, co je to update a co upgrade, aby nedošlo ke sporu o nárok na novou verzi předmětného softwaru. Může být vhodné upravit i práva objednatele na případné nové produktové řady, pokud by dodavatel provedl tzv. sunsetting softwaru.
V obdobném duchu je nutné se zamyslet (a někdy konzultovat s nezávislým IT dodavatelem) nad všemi službami servisní smlouvy a jejich parametry a náležitě je ve smlouvě popsat.
V případě, že v souvislosti s poskytováním servisních služeb bude ze strany dodavatele docházet ke zpracování osobních údajů, měla by servisní smlouva obsahovat tzv. zpracovatelská ujednání ve smyslu čl. 28 GDPR. Řada servisních smluv, uzavřených před účinností GDPR, zpracovatelská ujednání neobsahují, ačkoliv na základě nich dochází ke zpracování osobních údajů zpracovatelem, čímž dochází k porušení nařízení (a to i přes to, že obdobná povinnost existovala i podle předchozí právní úpravy). Pokud je toto váš případ, doporučuji uzavřít ke smlouvě dodatek anebo samostatnou zpracovatelskou smlouvu.
Servisní smlouva bez sankcí za nedodržení sjednané úrovně dostupnosti je de facto gentlemanská dohoda. I v případě, že nedojde ke sjednání sankcí, má objednatel sice z titulu případného porušení smlouvy nárok na náhradu škody podle § 2913 ObčZ (a případné další nároky), ale vznik škody, kauzální nexus a její výše se v případě softwarových sporů velmi těžce prokazuje a objednatelé tak většinou porušení servisní smlouvy sankcionují tak, že si najdou jiného dodavatele a všechny s tím spojené ztráty a náklady odepíší jako podnikatelské riziko (pokud vůbec je možné najít nového dodavatele, jinak nezbývá než skřípat zuby).
Daleko lepší je sjednat si sankce za porušení servisní smlouvy (například za porušení garantované dostupnosti, nedodržení reakční doby apod.). Tradiční sankce, která se v takovém případě nabízí, je smluvní pokuta.
U některých méně závažných porušení však může být vhodnější sjednat si kredit, který se bude připisovat na účet objednatele a o který se zlevní poskytování servisních služeb v dalších obdobích. Sankce v podobě kreditu ocení zejména veřejní zadavatelé, kteří uzavřeli servisní smlouvu. Ti mají povinnost uplatňovat sankce, když jsou naplněny podmínky, i když jsou s dodavatelem jinak spokojeni. Uplatňování smluvních pokut však z mé zkušenosti významně narušuje vztahy mezi objednatelem a dodavatelem, přičemž uplatnění kreditu je v tomto ohledu šetrnější.
Pozor na servisní smlouvy, které se řídí právním řádem common law (Anglie a Walesu, některého ze států USA apod.). Common law obecně neumožňuje sjednání smluvních pokut (ačkoliv Anglie zaznamenává v tomto ohledu určitý posun) a namísto smluvních pokut je potřeba delikátně sestavit klauzule o tzv. paušalizované náhradě škody (angl. „liquidated damages”).
Všichni podnikatelé by měli ke klíčovým IT systémům mít uzavřenou odpovídající servisní smlouvu, která zajistí bezproblémový provoz předmětných systémů. Tato smlouva, jelikož je z pohledu ObčZ nepojmenovaná, by měla co nejpřesněji obsahovat svůj předmět, parametry poskytovaných služeb a případné sankce za nedodržení smlouvy. V opačném případě může dojít až k paralýze podnikání, pokud vypadne klíčový IT systém a ze strany dodavatele neexistuje závazek takový výpadek za rozumných podmínek odstranit. Pokud je objednatel skrze koupenou licenci a závislost na IT systému v postavení, kdy nemůže jednoduše servis zadat třetí osobě a nemůže bez IT systému existovat, může se jednat o situaci naprosto fatální. Doporučuji vždy nastavení servisní smlouvy konzultovat s právníkem, který rozumí problematice softwarového práva, a případně též s nezávislým IT konzultantem.
Mgr. Jiří Císek,
advokátní koncipient v advokátní kanceláři SEDLAKOVA LEGAL s.r.o.
[1] JANSA, L. a OTEVŘEL, P. Softwarové právo. 2. vyd. Brno: Computer Press, 2014. ISBN 9788025142011.
[2] On-prem z angl. „on-premises”, tedy IT systémů instalovaných na infrastruktuře objednatele.
[3] V situaci, kdy Vám nefungují webové stránky, potřebujete garanci ze strany jejich dodavatele, že se problémem bude v určité době zabývat, že jej vyřeší, a co vás to bude stát.
[4] Například JANSA, L. a OTEVŘEL, P. Softwarové právo. 2. vyd. Brno: Computer Press, 2014. ISBN 9788025142011. nebo GORDON, Jeffrey I. Software licensing handbook. 2nd ed. Raleigh, NC: Lulu, 2008. ISBN 9781435752511.
[5] Kolektiv autorů. Oxford Dictionary of Computing. 7th Edition. Oxford: Oxford University Press, 2016. ISBN 978–0–19–100288–5.
[6] JANSA, L. a OTEVŘEL, P. Softwarové právo.
[7] Právo objednatele na upgrade standardně znamená, že objednatel má právo na vyšší verze produktu se stejným označením, tj. produkt XY 1.0, XY 2.0, XY 3.0 apod. Některé softwarové společnosti čas od času ukončí produktovou řadu a vydají produkt, který nese nové označení, avšak slouží ke stejnému účelu (a zpravidla má jen pozměněné user interface). Namísto, aby společnost vydala produkt XY 4.0, řekne, že produktová řada XY končí a vydají produkt YZ (tzv. sunsetting produktové řady XY). Servisní smlouva by měla upravit práva objednatele k případným novým produktovým řadám.
[8] Dodavatel bude téměř vždy zpracovatelem osobních údajů ve smyslu Obecného nařízení o ochraně osobních údajů („GDPR”), jelikož za zpracování osobních údajů je považováno i nahlížení do osobních údajů nebo jejich uložení (viz čl. 4 odst. 2 GDPR). Dodavatel při servisních zásazích může mít, a zpravidla má, přístup dovnitř IT systému a/nebo databází, může na osobní údaje minimálně nahlížet, a je tedy považován za zpracovatele.
[9] GDPR ukládá povinnost správci uzavřít se zpracovatelem písemnou smlouvu o zpracování osobních údajů, pokud se zpracování neřídí jiným právním aktem podle práva Unie nebo členského státu.
[10] Srov. § 6 zákona č. 101/2000 Sb., o ochraně osobních údajů, ve znění pozdějších novel.
[11] Situace, kdy nelze najít jiného dodavatele servisu, většinou nastane, pokud to neumožňují licenční ujednání ke koupenému software. Taková situace se označuje jako tzv. vendor-lock.
[12] Toto ujednání je výhodné, protože v případě smluvních pokut je musí objednatel uplatnit a pokud dodavatel smluvní pokuty nezaplatí, objednatel musí podat žalobu na zaplacení pokut. Kredit je v tomto výhodnější, protože objednatel jednoduše nezaplatí část ceny za servis a případný žalobní nárok musí vznést dodavatel.
[13] DRAKES, Gordon a Tim RICKARD. Important Changes to the English law rule on penalty clauses - what does it mean for franchising?. Fieldfisher [online]. Anglie: fieldfisher, 2016, 25.2.2016 [cit. 2018-10-23]. Dostupné z: https://www.fieldfisher.com/publications/2016/02/important-changes-to-the-english-law-rule-on-penalty-clauses-what-does-it-mean-for-franchising