Nejčastější problémy servisních smluv a SLA
Dodáním softwaru často spolupráce se zákazníkem ještě zdaleka nekončí. Přestože nějaká forma záruky je standardní součástí smluv, péče o produkt, zajištění jeho provozu, a zejména odstraňování vad je obvykle pokryto samostatnou smlouvou. Provozní, servisní či SLA smlouva stanoví podrobnosti poimplementačních činností souvisejících se softwarem. Klíčové prvky těchto smluv představíme v následujícím článku.
Před samotným obsahem servisní smlouvy je zajímavé zamyslet se už nad tím, kdy takovou smlouvu uzavřít. V praxi bývá obvyklé souběžné uzavření implementační a servisní smlouvy, tedy sjednání závazku dodání softwaru i následného provozu a servisu. Někdy obě oblasti činností mohou být součástí jediné smlouvy. Uzavření servisní smlouvy společně s implementační smlouvou, a nikoliv později – s blížícím se koncem implementace – je často lehce výhodné pro zákazníka. Ten má totiž při vyjednávání silnější pozici, než by měl ke konci implementačního projektu, kdy začíná být nucen zajistit si podporu pro svůj nový produkt. Obezřetný zákazník však bude počítat také s variantou, kdy obchodní spolupráce nebude probíhat podle jeho představ, a do smluv bude chtít začlenit exitové možnosti pro takové případy, tedy například možnost odstoupit od servisní smlouvy v případě neuspokojivého plnění implementační smlouvy. Jde již o standardní mechanismy, které by dodavatele neměly překvapit.
Dohoda o úrovni služeb (SLA)
Jádrem servisních smluv bývá tzv. dohoda o úrovni služeb (service level agreement – SLA). Klíčovými součástmi SLA je garantovaná dostupnost řešení (uptime) a lhůty odstraňování vad, ačkoliv ne vždy se nutně sjednávají obě.
Dostupnost služby se vždy počítá v provozní době za určité vyhodnocovací období. Standardní provozní doba může kopírovat pracovní dobu zákazníka (režim 8 × 5, tedy osm hodin denně, pět dnů v týdnu, zpravidla mimo svátky a dny pracovního klidu), ale může být i rozšířená (např. 10 × 5) či nepřetržitá (24 × 7). Vyhodnocovací období je zpravidla měsíční. Samotná dostupnost bývá vyjádřena procenty – poměrem doby, kdy je služba dostupná, a doby, kdy dostupná má být (tedy bez plánovaných výpadků, jejichž rozsah bývá v rámci SLA také upraven).
Pro představu, uptime 99,9 % při nepřetržitém provozu připouští výpadek cca necelých 44 minut za měsíc, zatímco uptime 99 % kolem 7 h 18 min.
Režim provozu i sjednaná doba dostupnosti mívá přímý vliv na cenu služeb, je proto vhodné zákazníka vést k racionálním požadavkům v těchto oblastech, které se opírají o reálné potřeby zákazníkova závodu. Velká část aplikací jednoduše nepotřebuje extrémně vysokou garantovanou dostupnost v režimu 24 × 7.
Odstraňování vad
Dohoda o odstraňování vad je často hlavním důvodem pro uzavření SLA, a proto by jí měla být věnována největší pozornost. Vše začne již výskytem vady, její správnou kategorizací a jejím nahlášením. Dalším krokem je určení odpovědnosti za kategorizaci vad, ale i možnost řešení sporu o kategorii vady. Cílem je, aby vždy nakonec existovalo jasné určení kategorie vady a s tím související lhůty pro její odstranění.
SLA může stanovit lhůty už pro reakci na hlášení vady, kterou se obvykle myslí doba mezi prokazatelným nahlášením vady v souladu se smlouvou a doba zahájení činností směřujících k odstranění vady. Je obvyklé, že pro splnění reakce na vadu nepostačuje například automatizovaná reakce na hlášení.
Klíčová lhůta je pak samozřejmě pro odstranění vady. Pro ni je klíčová také správná definice odstranění vady: někdy je nezbytné skutečné vyřešení vady a uvedení systému do stavu před výskytem vady, jindy může být dostačující dočasné řešení (workaround) či snížení závažnosti vady s benevolentnější lhůtou pro finální odstranění vady.
Obdobně jako u dostupnosti i pro reakční lhůty a lhůty pro odstranění vady je nutné nastavit období, ve kterém lhůty běží, přičemž tyto nemusí nutně být v režimu 24 × 7. Pokud lhůty neběží nepřetržitě, je nutné věnovat velkou pozornost jejich počítání a nastavení. Například odstranění vady do čtyř hodin od nahlášení v režimu 8 × 5 při nahlášení v pátek odpoledne znamená konec lhůty v pondělí dopoledne nebo i později, pokud je třeba pondělí státním svátkem, na což je snadné zapomenout. Podobně v režimech mimo 24 × 7 často nefungují dobře lhůty definované například ve dnech, protože vzniká nejistota a možný spor v jejich počítání – kdy přesně běží, a hlavně kdy končí.
Je vhodné přímo ve smlouvě určit kanály pro hlášení vad. V jednodušších případech postačí třeba jen e-mail, ale často se využívá specializovaná aplikace. V urgentních případech je vhodné mít k dispozici telefonický kontakt pro hlášení kritických vad. Přesto by mělo následně dojít k písemnému zachycení hlášení o vadě e-mailem nebo v příslušné aplikaci. Pokud se pro service desk využívá aplikace, smlouva by měla stanovit, u které strany aplikace poběží a jaký rozsah přístupů do aplikace bude mít druhá strana k dispozici. Důvodem je i ekonomická stránka – licence specializovaných aplikací jsou obvykle množstevní a vyšší počet přístupů může prodražit služby.
Další služby a ukončení spolupráce
Servisní smlouvy bývají uzavírány na delší dobu, a proto někdy zahrnují další služby související s provozem příslušného řešení. Někteří zákazníci mají zájem o služby profylaxe, tedy o pravidelnou drobnou, preventivní údržbu dodaných zařízení, případně i preventivní prohlídky a testy softwaru. Častá bývají také školení pro případy změn řešení, nástupů nových zaměstnanců zákazníka apod.
Některá řešení mohou podléhat legislativní regulaci, a zákazníci proto mohou požadovat služby jako upozornění na nadcházející změny a zajištění souladu řešení s aktuální legislativou. U takové služby se obvykle vedou intenzivní diskuse k její ceně, resp. zda bude součástí paušálních služeb, nebo bude hrazena ad hoc podle objednávek. Druhá varianta bývá pro zákazníka příznivější, protože jinak musí dodavatel v nacenění paušálu odhadovat dopředu rozsah legislativních změn, který pochopitelně obvykle raději nadcení.
V neposlední řadě by měla servisní smlouva počítat s tím, že jednou skončí – ať už uplynutím doby, na kterou je sjednána, nebo výpovědí či odstoupením jedné ze stran. Kromě podmínek samotného ukončení smlouvy by mělo být sjednáno, jaké služby zákazník dostane či si bude moci objednat při ukončení smlouvy.
Tyto služby exitu, jak bývají obvykle označovány, obvykle zahrnují předání aktuálních podkladů k řešení zákazníkovi (někdy včetně zdrojového kódu a související dokumentace) tak, aby zákazník mohl v provozu řešení pokračovat. Přechod zákazníka k jinému dodavateli není ojedinělý, proto zákazníci mnohdy ve smlouvách požadují určitou míru součinnosti končícího dodavatele s takovým převodem služeb. Obdobně jako v případě legislativních updatů je důležité sjednat cenu takových služeb v případě, že již nejsou zahrnuty například v paušálních platbách.
Licence, dokumentace, aktualizace
V servisních smlouvách je nezbytné pamatovat na to, že v rámci podpory softwaru bude nutně docházet k zásahům do samotného řešení. Tyto změny by měly být reflektovány v licenčních ujednáních, aby nevznikly pochyby o tom, zda a v jakém rozsahu má zákazník příslušná oprávnění k užití řešení. Je možné, že už licenční ujednání v implementační smlouvě pro prvotní dodání řešení bude zahrnovat oprávnění k budoucím změnám, ale pro vyloučení pochybností by potřebná licenční ustanovení měla být obsažena i v servisní smlouvě.
Dále je vhodné nezapomenout na aktualizaci dokumentace při každé relevantní změně řešení. V případě, že zákazník dostává také zdrojový kód řešení, měl by dostávat jeho aktualizace vyvolané upgrady, updaty i řešeními vad. Obecně lze očekávat, že zákazník bude požadovat, aby měl vždy k dispozici aktuální verze nejen dodaného řešení samotného, ale všech souvisejících podkladů.
Není pravidlem, že zákazník společně s řešením dostává také zdrojový kód a příslušnou technickou dokumentaci. Předání těchto podkladů přesto může být dohodnuto pro některé případy, typicky ukončení smlouvy, ale také třeba ukončení činnosti dodavatele. Tyto situace se obvykle řeší samostatnou smlouvou o úschově zdrojového kódu (tzv. escrow), která by měla hlavně stanovit předmět úschovy, způsob a četnost jeho uložení a podmínky pro jeho uvolnění zpět dodavateli, nebo naopak zákazníkovi. Je také potřeba zahrnout do servisní smlouvy příslušná oprávnění pro zákazníka, pokud dojde k vydání předmětu úschovy právě zákazníkovi.
Obecně má správná servisní smlouva dostatečně pokrýt všechny aspekty spolupráce zákazníka a dodavatele v rámci provozu dodaného řešení. Cílem je, aby podrobné vymezení práv a povinností obou stran nedalo prostor ke zbytečným sporům a smlouva byla stranám oporou při řešení jakýchkoli nejasností.
  |
| Mgr. et Mgr. Ing. Jan Tomíšek, Ph.D. Mgr. David Sláma Autoři článku jsou advokáti specializující se na IT právo, kteří působí v kanceláři ROWAN LEGAL. |
