banner

Service Level Agreement (SLA) w praktyce kontraktowej

Service Level Agreement (SLA) w praktyce kontraktowej

W poprzednim artykule starałem się wyjaśnić istotę SLA. Słowem przypomnienia – SLA jest jednym z postanowień umownych, elementem umowy podstawowej łączącej strony, określającym granice w jakich może się poruszać usługodawca, aby nie narazić się na zarzut nienależytego wykonania umowy.

 

W praktyce kontraktowej SLA najczęściej przyjmuje postać osobnego dokumentu, stanowiącego załącznik do umowy głównej. Zdarza się, jeśli usługa świadczona jest drogą elektroniczną, że w regulaminie świadczenia usługi występuje odniesienie do dokumentu SLA znajdującego się pod wskazanym adresem internetowym.

W jakich umowach ustępuje SLA?

Zapisów dotyczących SLA powinniśmy się spodziewać w takich umowach jaka np.:
– umowa o świadczenie usług dostępu do sieci Internet,
– umowa usługi hostingowej (serwera VPS),
– umowa dostępu do przestrzeni dyskowej w chmurze obliczeniowej,
– umowa dostępu do aplikacji internetowej (świadczonej w modelu SaaS),
a więc w tych umowach, gdzie istotne jest, aby wyznaczyć z jednej strony minimalny czas dostępu do usługi (patrząc od strony usługobiorcy), a z drugiej ustalić maksymalny czas możliwej niedostępności (patrząc od strony usługodawcy).

O SLA należy w szczególności pamiętać przy zawieraniu umów wdrożeniowych. Nie zagłębiając się w tematykę samych umów wdrożeniowych należy przyjąć, że konstrukcja tych umów składa się z dwóch głównych części:
I. stworzenia oprogramowania wraz z wdrożeniem go u zamawiającego albo wyłącznie zainstalowania go w systemach zamawiającego (jeśli wykonawca posiada już swoje autorskie programowanie, jest jego resellerem bądź autoryzowanym dystrybutorem, którego wdrożeniem zamawiający jest zainteresowany).
II. utrzymania wdrożonego systemu, przy czym utrzymanie może mieć dwie postaci (w zależności od rodzaju wdrożenia): udzielenie gwarancji jakości na wykonane oprogramowanie lub serwis oprogramowania.

 

Gwarancja jakości a serwis

Gwarancja jakości najczęściej obejmuje wykonywanie wyłącznie napraw oprogramowania w ustalonym w umowie okresie po wdrożeniu. Naprawy wykonywane przez wykonawcę oprogramowania w ramach gwarancji są tutaj nieodpłatne. Oprogramowanie komputerowe, które powstanie w ramach wykonanej umowy będzie z zasady utworem w rozumieniu ustawy o prawach autorskich i prawach pokrewnych, a co ma istotne znaczenie w kontekście wygaśnięcia uprawnień z tytułu rękojmi za wady dzieła będącego jednocześnie utworem z momentem jego wydania.

W zakres serwisu wchodzi natomiast wykonywanie napraw oprogramowania, względnie także jego rozwój i modyfikacje, już po upływie okresu gwarancyjnego, ale za dodatkowym wynagrodzeniem. Serwis jest więc nową usługą świadczoną przez wykonawcę oprogramowania na rzecz dotychczasowego zamawiającego.

Na marginesie należy wskazać, aby kwestie gwarancji jakości i serwisu bardzo dokładnie opisać i wyraźnie je rozdzielić w negocjowanej umowie.

Zarówno jeśli chodzi o gwarancję jakości jak i serwis, ich istotą jest zobowiązanie się wykonawcy do podjęcia reakcji oraz usunięcia błędu (awarii, usterki) w maksymalnym ustalonym w umowie czasie. Jak widać z powyższego, SLA w umowach wdrożeniowych będzie dotyczyła zarówno określenia czasu dostępności aplikacji (systemu), jak i czasu usunięcia przyczyn ich powstania.

 

Zasady konstruowania SLA w umowach

Jak wspomniałem na początku, dla umów o świadczenie usług telekomunikacyjnych oraz umów na usługi informatyczne (hosting, aplikacja SaaS) w SLA zakłada się minimalny czas dostępu do usługi, liczony najczęściej jako procent czasu faktycznej dostępności w stosunku do całości okresu rozliczeniowego. Porównując dostępność należy mieć wzgląd na okres rozliczeniowy, który może być ustalony na miesiąc, kwartał, rok – przy czym im krótszy okres rozliczeniowy, tym korzystniej dla usługobiorcy. W praktyce usługodawcy w regulaminach wyraźnie wskazują, że zaplanowane prace techniczne nie wliczają się do czasu niedostępności usługi.

W SLA regulujących gwarancję jakości oraz serwis pogwarancyjny zaleca się dokonanie rozróżnienia rodzajów błędów (usterek, awarii) w zależności od wpływu jaki ma błąd (usterka, awaria) na działanie całego oprogramowania lub jego części, a następnie ustalenia hierarchii tych błędów (awarii, usterek). Dopiero po tym możliwe jest ustalenie dla poszczególnych rodzajów błędów maksymalnych czasów reakcji, czasów obejścia i czasów naprawy.

W obu przypadkach ważne jest, aby określone zasady dochowania czasów z SLA były możliwe do zweryfikowania.

Prawidłowo skonstruowane SLA zawiera również zapisy o karach nakładanych na usługodawcę (wykonawcę) za niedotrzymanie przez niego czasów określonych w dokumencie SLA. Kary te mogą zostać określone jako kary umowne albo kwoty gwarancyjne i będą mieć charakter zryczałtowanego odszkodowania. Niemniej, ich rola sprowadza się z jednej strony do dyscyplinowania usługodawcy (wykonawcy), z drugiej natomiast ma za zadanie zabezpieczyć interesy zamawiającego. Od dostępności usługi (aplikacji, systemu) będzie zależeć sprawność jego przedsiębiorstwa, utrzymanie na rynku oraz możliwość zarobkowania.

Wysokość kar powinna być obliczona z uwzględnieniem ryzyka jakie niesie dłuższa niż ustalona niedostępność aplikacji (systemu). Kary mogą być ustalone kwotowo albo procentowo, przy czym w drugim przypadku odniesieniem jest najczęściej kwota miesięcznego wynagrodzenia za świadczoną usługę. W praktyce wykonawcy (usługodawcy) umieszczają w umowach zapisy ograniczające ich odpowiedzialność. Maksymalna wysokość kar umownych nakładanych na wykonawcę będzie uzależniona od długości czasów reakcji oraz naprawy, jak również wysokości jednorazowej kary za ich przekroczenie.

Search

+