Servisná zmluva k softvéru (SLA) – 5 vecí na čo si dávať pozor
Service Level Agreement (SLA) je zmluva, ktorá dojednáva, akú kvalitu má mať poskytovaná služba a nastavuje pravidlá jej údržby. Najčastejšie sa uzatvára pri dodávke softvéru, pričom klientovi garantuje jeho funkčnosť a pre dodávateľa zaručuje pravidelný príjem za poskytovanie servisu po odovzdaní riešenia.
Keďže náležitosti SLA neupravuje žiadny zákon, jej obsah je na vôli strán. V praxi sa však často stáva, že firmy túto zmluvu buď vôbec neuzatvoria, alebo použijú starý vzor inej zmluvy a servisné podmienky spíšu v nedostatočnom rozsahu. Na konci dňa je takáto zmluva často nepoužiteľná a pri riešení vád majú obe strany hlavu v smútku.
V našej praxi IT právnikov sme sa stretli s viacerými situáciami, kedy sa softvér „pokazil“ a klienti museli využiť naše právne služby. Spísali sme niekoľko dôležitých bodov, na ktoré si treba dať pozor a ktoré by v správne nastavenej SLA nemali chýbať.
1. Presný (!) opis servisných služieb
Pamätajte, služby garantované dodávateľom by mali byť vždy popísané čo najdetailnejšie. Vyhnete sa tak sporom, či napríklad vada softvéru má byť riešená v rámci servisného paušálu, alebo vám dodávateľ má účtovať cenu podľa odpracovaných man-days.
Ak si projekt vyžaduje servisné služby vo veľkom rozsahu, odporúčame tieto definovať v samostatnej prílohe. Opis služby by mal obsahovať tiež podrobné informácie o tom, akých aplikácií a informačných systémov sa služby týkajú. Zároveň, pri definovaní služby odporúčame podrobne rozpracovať otázky:
- inštalácie softvérových zariadení,
- správy dátových centier a úložísk, zálohovanie dát,
- časového rámca prevádzky,
- zákazníckej podpory,
- priebežného merania dostupnosti služby,
- spôsobu identifikácie a lokalizácie problémov a vád a ich odstraňovanie,
- podmienky údržby a aktualizácie.
Aj keď sa to môže javiť ako samozrejmé, odporúčame v SLA uviesť aj výpočet činností, ktoré dodávateľ nezabezpečuje (napr. pripojenie k internetu, servis hardwaru a pod.).
2. Ako dohodnúť odmenu?
V praxi sa strany najčastejšie dohodnú na paušálnej odmene za dohodnutý počet hodín servisu za určité obdobie (spravidla mesačne alebo kvartálne). Ak tento rozsah hodín strany nevedia určiť pri odovzdaní softvéru, odporúčame dohodnúť skúšobnú dobu (napr. 3 mesiace). Po jej skončení si strany vyhodnotia priemerný mesačný počet hodín a nastavia vhodný paušál.
Strany si tiež môžu dohodnúť jednotkovú cenu za služby nad rámec paušálu. V praxi sa najčastejšie využíva odmena podľa hodinovej sadzby, prípadne podľa tzv. man-days. Zo skúsenosti odporúčame v zmluve upraviť tiež povinnosť dodávateľa informovať klienta o potrebe prác „naviac“ spolu s ich odhadovaným rozsahom. Pri vyúčtovaní odmeny nezabudnite na povinnosť predložiť výkaz práce.
3. Ako upraviť úroveň dostupnosti služby a na čo nezabudnúť pri výnimkách
Poskytovateľ v SLA štandardne garantuje dostupnosť služieb softvéru v určitom rozsahu a kvalite.
V praxi sa často stretávame s ustanovením „dodávateľ je povinný zabezpečiť dostupnosť softvéru na úrovni 99 %“. Takáto úprava je však nešťastn – nedáva žiaden návod na to, ako dostupnosť merať a vytvára priestor pre spory. Najhorší scenár je, že príliš stručná definícia môže spôsobiť neplatnosť zmluvy a s celým servisným projektom skončíte ešte skôr, ako ste začali.
Pri dostupnosti je potrebné pamätať na dva základné prvky – úroveň dostupnosti a obdobie, za ktoré sa meria. Dostupnosť sa najčastejšie určuje v percentách a meria sa spravidla mesačne. Je tiež potrebné definovať, či sa do dostupnosti zahŕňa doba mimo pracovných dní, či prevádzkových hodín a pod.
SLA by mala obsahovať ustanovenia o spôsobe, akým bude dodávateľ oznamovať zákazníkovi výsledky merania dostupnosti a ako si ich tento môže overiť. Zároveň, je dôležité presne určiť, čo je výnimkou z dostupnosti softvéru a odlíšiť takéto situácie od prípadných porušení zmluvy (ktoré môžu aktivovať zmluvné pokuty). V SLA odporúčame uviesť najmä tieto výnimky z dostupnosti:
- pravidelný servis,
- dočasné vopred dohodnuté vyradenie systému z prevádzky,
- výpadky systému zapríčinené tretími stranami,
- výpadky zapríčinené objednávateľom (napríklad kvôli neposkytnutiu
- výpadky zapríčinené vírusmi v systéme,
- výpadok spôsobený prekročením určených kapacít a pod.
4. Nie sú chyby ako chyby.
Ako postupovať pri ich riešení
Veci sa kazia a softvér v tomto smere nie je žiadnou výnimkou. Preto aj pri definícií možných vád platí pravidlo „čím detailnejšie, tým lepšie“. V praxi je užitočné klasifikovať vady, ktoré sa môžu vyskytnúť, napríklad na:
a) nepodstatné vady (softvér je funkčný a chyba spôsobuje nepatrné problémy),
b) významné vady (softvér je spomalený, dochádza k výpadkom niektorých funkcionalít softvéru),
c) kritické vady (softvér nefunguje vôbec alebo došlo k výpadku základnej funkcie).
Tento príklad je len názorný, v praxi sa chyby definujú ešte podrobnejšie podľa konkrétneho projektu. Odporúčame v zmluve uviesť aj to, čo sa za vadu nepovažuje (napr. chyby spôsobené nesprávnym používaním aplikácie zákazníkom).
Tiež postup po zistení chyby je vhodné stranami dohodnúť dopredu. Preto v SLA odporúčame jasne určiť reakčnú dobu, t.j. čas medzi prijatím oznámenia o probléme a spätnou odozvou o plánovanom postupe riešenia. Ďalej je vhodné nastaviť pravidlá pre „dobu odstránenia incidentu“ (doba medzi prijatím oznámenia o probléme a jeho vyriešením). Napokon, klientom radíme definovať aj „dobu definitívneho odstránenia problému“ (čas potrebný na vyriešenie problému bez náhradného plnenia).
5. Sankcie, pokuty, odstávky a iné nepríjemnosti
Každá SLA by mala upravovať, čo sa stane, ak niektorá strana poruší svoje povinnosti. Nie je to vyhrážanie ani nátlak, jednoducho pomáhate motivovať strany, aby si riadne a zodpovedne plnili svoje záväzky.
Typickými sankciami sú:
- zmluvná pokuta – v praxi je vhodné ju odstupňovať podľa závažnosti porušenia povinnosti,
- právo odstúpiť od zmluvy, resp. prerušiť dodávku služieb,
- bezplatné rozšírenie/predĺženie licencie – v praxi radíme nastaviť tak, aby došlo k predĺženiu automaticky bez potreby akéhokoľvek úkonu od porušujúcej strany,
- kredity – každý kredit predstavuje porušenie zmluvnej povinnosti (v závislosti od jeho intenzity a dĺžky trvania), pričom konečná výška pokuty sa určí súčtom kreditov v dohodnutom období.
Pri zmluvnej pokute je dôležité pamätať aj na to, či je táto jednorazová alebo ju možno uplatniť pri opakovanom porušení.
Finálny účet za výpadok služby sa nemusí skončiť u vás vo firme. Nezabudnite sa preto s právnikom poradiť tiež o doložke o odškodnení (indemnity clause). Táto upravuje povinnosť dodávateľa nahradiť škodu, ktorá vznikla klientovi (napríklad pri výpadku softvéru vo firme, v ktorej riadi predaj, logistiku a pod.). Doložka zvyčajne zahŕňa aj nároky tretích strán (napr. príjemcov služby), ktoré porušením povinnosti dodávateľa utrpeli ujmu.
Záver
Hovorí sa, že pri draftovaní zmluvy potrebujete vidieť aj za roh a predvídať maximálnu množinu situácií, ktoré môžu nastať. Pri SLA to platí dvojnásobne.
Keďže podstatou tejto zmluvy je riešenie budúcich problémov, kompromisné riešenia sa tu nevyplácajú. Podmienky musia byť vždy definované detailne, jasne a presne. Takto napísaná zmluva poskytne stranám projektu potrebnú istotu a naplní svoj účel – nastavenie pravidiel pre riadne a efektívne fungovanie softvéru.
Ostatné články
Oblasti, v ktorých je potrebné zosúladiť VOP s prijatou novelou
Dňa 1.7.2024 nadobudne účinnosť dlho očakávaná novela spotrebiteľského práva. Nový zákon o ochrane spotrebiteľa komplexne upravuje práva a povinnosti spotrebiteľov aj obchodníkov. Prijatie novely sa výrazne dotkne aj všeobecných obchodných podmienok (VOP). 1. Rozšírenie informačných povinností obchodníka Novela rozširuje informačné povinnosti obchodníka vo vzťahu k spotrebiteľovi, napr. o: a. …
Prvá regulácia umelej inteligencie
EÚ prichádza s prvou právnou reguláciou AI na svete (AI Act). Neregulované využívanie AI môže zasahovať nie len do bezpečnosti krajín EÚ, ale aj do ľudských práv a súkromia občanov. Na začiatok chce Komisia priniesť definíciu AI systému. Jej presné znenie ešte nie je známe, avšak hlavným kritériom pri jej vytváraní by…