Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



07.06.2022

Red Hat Enterprise Linux 9

Red Hat zaprezentował system operacyjny Red Hat Enterprise Linux 9 (RHEL 9)...
07.06.2022

Technologiczna piaskownica

Koalicja partnerów KIR, IBM, Chmura Krajowa, PKO Bank Polski, Urząd Komisji Nadzoru...
07.06.2022

Sztuczna inteligencja w...

OVHcloud wprowadziło na rynek AI Notebooks – najnowszy element w ofercie usług...
07.06.2022

Spójna ochrona brzegu sieci

Fortinet zaprezentował FortiOS 7.2 – najnowszą wersję swojego flagowego systemu...
07.06.2022

Zarządzanie transferem

Firma Progress wypuściła nową wersję oprogramowania do zarządzania transferem plików...
07.06.2022

Notebook ekstremalny

Panasonic przedstawił 14-calowy Toughbook 40, notebook do pracy w ekstremalnych...
07.06.2022

Zestaw startowy dla robotyki

Firma AMD przedstawiła najnowszy produkt w portfolio adaptacyjnych modułów SOM...
07.06.2022

Precyzja kadrowania

Najnowsze rozwiązania klasy pro firmy Poly mają sprostać zmieniającym się potrzebom...
07.06.2022

Serwer klasy korporacyjnej

QNAP zaprezentował nowy model serwera NAS, TS-h1886XU-RP R2, który działa na systemie...

Jak prawidłowo opisać SLA – kwestie prawne

Data publikacji: 09-12-2021 Autor: Damian Łapka, Piotr Łochowski

Zgodnie z definicją ITIL SLA, czyli Service Level Agreement, to: „umowa pomiędzy dostawcą usług informatycznych a odbiorcą. Umowa SLA opisuje usługę informatyczną, dokumentuje docelowy poziom świadczenia usługi, określa obowiązki dostawcy usług informatycznych i odbiorcy”. Sporządzenie jej w poprawny sposób może się okazać nie lada wyzwaniem.

 

W branży IT pojęciem SLA zwykło określać się także same parametry usług, do jakich zapewnienia (zagwarantowania) zobowiązany jest usługodawca wraz z konsekwencjami ich niedotrzymania. Prawidłowe opisanie tych parametrów potrafi sprawić znaczne trudności, wymaga bowiem zaangażowania w równym stopniu działu prawnego, technicznego, jak i biznesu.

 

> Zakres usług serwisowych i podstawa ich świadczenia, dobre praktyki

 

Z branżowego punktu widzenia wsparcie serwisowe najczęściej obejmuje następujące rodzaje usług: •naprawę wad/błędów oprogramowania wchodzącego w skład systemu, wynikających z jego nieprawidłowej konfiguracji czy działań użytkowników; •utrzymywanie dostępności, wydajności i innych parametrów jakościowych związanych z działaniem systemu na określonym w umowie poziomie;•aktualizację oprogramowania wchodzącego w skład systemu; •konsultacje udzielane użytkownikom systemu;•zarządzanie systemem.

 

Podstawą świadczenia usług serwisowych najczęściej jest samodzielna umowa wsparcia (utrzymania) systemu informatycznego (dalej: umowa serwisowa) lub umowa wdrożeniowa, w której oprócz zadań projektowych znalazł się obowiązek wykonywania usług serwisowych. Nie wyklucza to jednak zapewnienia przez dostawcę wsparcia serwisowego, np. na podstawie dodatkowych oświadczeń gwarancyjnych czy przewidzenia pewnych uprawnień związanych ze wsparciem systemu (lub ogólniej oprogramowania) w umowie licencyjnej czy umowie o dostarczenie oprogramowania w modelu chmurowym.

 

Bardzo często rozwiązania polegające na uregulowaniu usług serwisowych w umowie, której przedmiotem są również inne świadczenia niż usługa serwisowa, mogą wywołać trudności na etapie ich realizacji. Na przykład włączenie obowiązków dotyczących świadczenia usług serwisowych w treść umowy wdrożeniowej może rodzić problem rozdzielenia (odróżnienia) tych usług od świadczeń związanych z realizacją wdrożenia lub wynikających z udzielonej gwarancji.

 

W pierwszym wypadku sytuacja taka może wystąpić, gdy umowa serwisowa zostaje zawarta i zaczyna obowiązywać równolegle do niezrealizowanej jeszcze umowy wdrożeniowej. W praktyce najczęściej przejawiać się to będzie w przerzuceniu obowiązków, jakie powinny być zrealizowane przez dostawcę w ramach okresu stabilizacji do odrębnie płatnej umowy serwisowej. Wskutek tego zamawiający staje się zobowiązany do płacenia „dwa razy za to samo”. Skoro bowiem w ramach wdrożenia zasadniczo powinien zostać dostarczony działający system, to zamawiający nie powinien być zmuszony do uiszczenia odrębnej zapłaty za osiągniecie tego rezultatu. Od tej sytuacji mogą oczywiście zaistnieć wyjątki, wynikające chociażby z poziomu złożoności wdrażanego systemu czy możliwości wcześniejszego osiągnięcia parametrów świadczących o ustabilizowaniu się działania systemu po zalokowaniu w tym celu przez dostawcę dodatkowych, uzgodnionych z zamawiającym środków.

 

W drugim wypadku (aczkolwiek sytuacja ta równie dobrze może wystąpić i w omówionym powyżej) przy braku stosownej procedury zgłaszania i kwalifikacji błędów istnieje ryzyko, że zgłoszenie zostanie przypisane do kolejki błędów usuwanych z powodu udzielonej gwarancji. Ta zaś bardzo często obejmuje jedynie najpoważniejsze błędy oraz przewiduje znacznie gorsze parametry SLA (jeżeli w ogóle zostaną określone) aniżeli umowa serwisowa.

 

Co więcej, gwarancja w przypadku wdrożenia systemu informatycznego obejmuje zazwyczaj usuwanie wad tkwiących w oprogramowaniu (kodzie) lub wynikających z wadliwości konfiguracji elementów systemu. Celem usług serwisowych jest natomiast pokrycie szerszego pola nieprawidłowości w działaniu systemu, w szczególności także takich błędów, których źródłem jest zachowanie samego usługobiorcy (tj. użytkowników). Dobrą praktyką konstruowania umów wdrożeniowych, które zawierają osobny komponent serwisowy, jest więc wyraźne oddzielenie tych dwóch obowiązków usługodawcy. Usuwanie błędów w ramach gwarancji odbywa się bowiem bez osobnego wynagrodzenia, gdyż zostało już ono zapłacone za prace wdrożeniowe. Celem gwarancji jest zapewnienie umówionej jakości systemu w ramach wykonanych prac wdrożeniowych. To, co wykracza poza ten zakres, powinno być kwalifikowane jako dodatkowa usługa serwisowa, za którą należy się osobne wynagrodzenie.

 

Z tej okoliczności nie należy wyciągać jednak zbyt uproszczonego wniosku, że bardziej pożądanym rozwiązaniem jest za każdym razem eliminowanie z umowy wdrożeniowej elementu serwisowego. Przyczyna problemu nie leży bowiem w tym, czy posłużymy się jednym lub dwoma dokumentami, ale czy prawidłowo opiszemy obowiązki wynikające z samego wdrożenia (udzielonej gwarancji) i usług serwisowych tak, aby nie dochodziło na tym tle do nieporozumień, a obsługa zgłoszonego incydentu była prawidłowo zakwalifikowana i w efekcie także poprawnie obsłużona. Rozpatrzyć zatem należy, jak powinna być skonstruowana umowa serwisowa.

 

> KONSTRUKCJA UMOWY SERWISOWEJ

 

Z punktu widzenia techniki tworzenia umowy parametry SLA warto opisywać w osobnym załączniku do umowy. Pozwoli to na zmniejszenie objętości głównego dokumentu umowy oraz – co nawet istotniejsze – pozytywnie wpłynie na jej przejrzystość. Podstawową wadą wielu umów jest bowiem ich nieczytelność, uniemożliwiająca ich efektywną obsługę na poziomie operacyjnym. W takim zaś wypadku treść o charakterze technicznym zostanie wyodrębniona, przez co nie będzie się „mieszać” z postanowieniami natury prawnej, istotnie ułatwiając kontrolę wykonania umowy i jakości świadczonych przez dostawcę usług.

 

Istotną kwestią z punktu widzenia kontroli jakości świadczenia usługi utrzymania jest także nałożenie na usługodawcę obowiązków informacyjnych, np. dotyczących sporządzania miesięcznych raportów, pełniących rolę sprawozdania z zakresu i jakości świadczonej usługi. Wskazany raport, w zależności od zakresu świadczonej usługi, może zawierać informacje o: •historii i statusach dokonanych zgłoszeń;•liczbie błędów, które wystąpiły w danym miesiącu, wraz z informacją, które błędy usunięto w terminie, a które poza umówionymi ramami czasowymi;•dostępności (wyrażonej procentowo wartości określającej, jak często w danym czasie występowały przerwy w działaniu systemu);•wydajności (efektywności działania systemu, w szczególności reakcji na polecenia jego użytkowników);•poprawkach, aktualizacjach wprowadzonych przez usługodawcę.

 

Raport powinien dostarczać usługobiorcy niezbędnych danych, pozwalających ocenić zgodność świadczonej usługi z parametrami określonymi w umowie, w tym stwierdzić, czy nie zaktualizowały się przesłanki do nałożenia kary umownej lub zakończenia współpracy z przyczyn leżących po stronie usługodawcy.

 

Za dobrą praktykę uznać należy także to, aby taki raport podlegał odbiorowi, a co najmniej aby usługobiorca miał prawo zgłaszania do niego zastrzeżeń. Pożądanym rozwiązaniem jest także wykorzystanie do tworzenia raportu automatycznych narzędzi zapewniających integralność danych prezentowanych w raporcie, takich jak czas reakcji na zgłoszenie i długość naprawy (śledzenie czasu usunięcia błędu), charakter błędu, informacje o wydajności i dostępności systemu. Za dobrą praktykę można uznać także udostępnienie usługobiorcy panelu klienta, w którym jest on w stanie na bieżąco sprawdzać efektywność świadczonej usługi. Niezależnie od powyższego z perspektywy usługobiorcy istotne znaczenie ma także wskazanie w umowie prawa do przeprowadzenia audytu świadczonych usług samodzielnie lub z wykorzystaniem zewnętrznego audytora. Kontrola może bowiem wykazać nieprawidłowości, których raport nie wykazał.

 

W przypadku wprowadzania przez usługodawcę poprawek i aktualizacji umowa serwisowa powinna zawierać niezbędne postanowienia, gwarantujące usługobiorcy nabycie uprawnień do korzystania z tych elementów oprogramowania. Należy zwrócić uwagę, że w przypadku umów przewidujących nabycie praw autorskich majątkowych – oprócz przeniesienia praw do wykonanych elementów oprogramowania – równie ważne jest zabezpieczenie faktycznej możliwości korzystania z nich. W tym celu warto nałożyć na usługodawcę obowiązek w szczególności regularnego przekazywania kodów źródłowych oprogramowania, pełnej i aktualnej dokumentacji, przedstawienia wykazu bibliotek programistycznych, z jakich usługobiorca korzystał, narzędzi niezbędnych do budowy środowisk systemu itd.

 

W przypadku umów serwisowych, przewidujących obowiązek dostarczania i wprowadzania, poprawek i aktualizacji oprogramowania zasadne jest także określenie zakresu tych usług, a w szczególności jasne i jednoznaczne dla stron rozgraniczenie poprawek i aktualizacji dostarczanych „w cenie” od odrębnie płatnego rozwoju oprogramowania, a także wskazanie, przez jaki okres takie aktualizacje czy poprawki będą dostarczane. Brak precyzyjnego określenia tych elementów wiązać się może z ryzykiem dla obydwóch stron umowy. Po stronie usługobiorcy skutkować będzie niepewnością co do zakresu udzielanego wsparcia, w szczególności korzystania z nabytego oprogramowania. Natomiast w przypadku usługodawcy może skutkować próbami wymuszenia przez niego uzyskania funkcjonalności, które w przypadku prawidłowo skonstruowanej siatki pojęciowej wchodziłyby w zakres odrębnie płatnego upgrade’u.

 

Projektując umowę serwisową, warto rozważyć kwestię transferu wiedzy od usługodawcy do usługobiorcy, jeśli usługobiorca planuje, aby w przyszłości jego wewnętrzny dział IT lub inny usługobiorca przejął usługi utrzymania. W takiej sytuacji usługodawca powinien zezwolić i zapewnić personelowi usługobiorcy możliwość udziału przy świadczeniu przez niego usług, zapewnić przeszkolenie personelu usługobiorcy oraz dostęp do konkretnych danych, np. diagnostycznych, czy przewidzieć w procedurze wyjścia z umowy (tzw. exit plan), że dotychczasowy usługobiorca będzie współpracować z podmiotem, który go zastąpi w ramach przejęcia obowiązków związanych ze świadczeniem usług wsparcia.

 

Warto napisać kilka słów o „zakończeniu” umowy serwisowej. Umowa taka zasadniczo będzie mieć charakter umowy o świadczenie usług, ewentualnie będzie mogła zostać zakwalifikowana jako tzw. umowa mieszana, tj. umowa, która z uwagi na swoją konstrukcję wykazuje cechy różnych umów nazwanych, w tym wypadku najczęściej umowy o świadczenie usług lub umowy o dzieło. W odniesieniu do umów o świadczenie usług poprzez odwołanie zawarte w art. 750 kc zastosowanie znajdą przepisy Kodeksu cywilnego o zleceniu. Obowiązujące regulacje o wypowiedzeniu umowy-zlecenia nie sprzyjają trwałości umowy, gdyż pozwalają na jej wypowiedzenie w każdym czasie, przy czym jedynie w sytuacji wypowiedzenia umowy przez którąkolwiek ze stron bez tzw. ważnego powodu skutkować to będzie odpowiedzialnością odszkodowawczą. W związku z tym warto ograniczyć podstawy wypowiedzenia tylko do ważnych powodów. Jakkolwiek nie jest możliwe określenie w umowie wszystkich ważnych powodów, jakie mogą uzasadniać wypowiedzenie umowy, tak dobrym pomysłem jest wskazanie sytuacji, które same strony umowy traktują jako taki ważny powód. Niewątpliwie niedochowanie przez usługodawcę parametrów SLA, w szczególności jeśli jest to stan utrzymujący się przez dłuższy czas, może zostać za taki powód uznane. Usługobiorca powinien bowiem mieć prawo wypowiedzieć umowę, gdy usługa świadczona na jego rzecz nie jest odpowiedniej jakości. W przeprowadzeniu tej oceny pomocny może być raport, o którym już wspomniano powyżej. W przypadku podstaw wypowiedzenia umowy po stronie usługodawcy ważne powody najczęściej zostają ograniczane do braku terminowej płatności za świadczone usługi.

 

> SLA a odpowiedzialność

 

Kluczową kwestią, na którą powinien zwrócić uwagę zarówno usługodawca, jak i usługobiorca, jest prawidłowe opisanie zasad odpowiedzialności z tytułu niedotrzymania parametrów SLA. Jak wskazaliśmy w poprzedniej części artykułu, umowa wsparcia systemu informatycznego (czy też szerzej – infrastruktury systemowo-sprzętowej) najczęściej będzie mieć charakter umowy o świadczenie usług (pomijamy w tym miejscu zagadnienie charakteru prawnego umowy o wdrożenie systemu informatycznego z elementami jego wsparcia). To z kolei prowadzi do wniosku, że:•wobec braku szczególnej regulacji kodeksowej zasad odpowiedzialności zleceniobiorcy Kodeks cywilny nakazuje stosować do umów o świadczenie usług odpowiednio przepisy o zleceniu; •wobec braku odmiennych ustaleń stron odpowiedzialność usługodawcy za nienależyte wykonanie lub niewykonanie ciążących na nim zobowiązań opierać się będzie na tzw. zasadach ogólnych.

 

Kluczowe znaczenie mają w tym kontekście artykuły 471–472 kc. Zgodnie z pierwszym z przywołanych artykułów: „[d]łużnik obowiązany jest do naprawienia szkody wynikłej z niewykonania lub nienależytego wykonania zobowiązania, chyba że niewykonanie lub nienależyte wykonanie jest następstwem okoliczności, za które dłużnik odpowiedzialności nie ponosi”. Przytoczony przepis stanowi podstawę zasad odpowiedzialności kontraktowej i wymienia jej przesłanki:•(istnienie zobowiązania oraz) niewykonanie lub nienależyte wykonanie zobowiązania wskutek okoliczności, za które odpowiada dłużnik;•szkoda po stronie wierzyciela;•adekwatny związek przyczynowy pomiędzy zdarzeniem stanowiącym niewykonanie lub nienależyte wykonanie zobowiązania a szkodą.

 

Treść ostatniej przesłanki wynika z konieczności odczytywania art. 471 k.c. łącznie z art. 361 § 1 k.c., w myśl którego „[z]obowiązany do odszkodowania ponosi odpowiedzialność tylko za normalne następstwa działania lub zaniechania, z którego szkoda wynikła”.

 

Jeśli przeniesiemy treść przepisów na analizowaną sytuację, dłużnikiem, o którym mowa w przytoczonym artykule, będzie usługodawca. Jego wierzycielem będzie natomiast usługobiorca i to na nim ciążyć będzie obowiązek wykazania powstania szkody oraz pozostawania przez nią w adekwatnym związku przyczynowym z niewykonaniem lub nienależytym wykonaniem zobowiązania (w tym wypadku: z niedotrzymaniem parametrów usług określonych w umowie). Z drugiej strony nie będzie on zobowiązany do wykazania, że nienależyte wykonanie lub niewykonanie zobowiązania wynikało z okoliczności, za które odpowiedzialność ponosi usługodawca – w tym wypadku zastosowanie znajdzie domniemanie ustawowe wystąpienia takich okoliczności (potocznie zwane domniemaniem winy dłużnika). Pojawia się w tym miejscu pytanie, czy i w jaki sposób dłużnik może zwolnić się z odpowiedzialności.

 

Po pierwsze, dłużnik może wskazywać, że nie odpowiada za okoliczności będące przyczyną niewykonania lub nienależytego wykonania zobowiązania. Okolicznością taką może być zachowanie wierzyciela, co w przypadku umów w zakresie utrzymania systemów informatycznych może być np. samodzielną modyfikację oprogramowania przez usługobiorcę, która doprowadziła do powstania błędu. Po drugie, dłużnik może zwolnić się z odpowiedzialności, wykazując, że dochował należytej staranności.

 

Zgodnie z przywołanym wcześniej art. 472 kc „[j]eżeli ze szczególnego przepisu ustawy albo z czynności prawnej nie wynika nic innego, dłużnik odpowiedzialny jest za niezachowanie należytej staranności”. Należytą staranność, zgodnie z art. 355 § 1 kc, należy rozumieć jako staranność ogólnie wymaganą w stosunkach danego rodzaju. W odniesieniu do dłużników prowadzących działalność gospodarczą należyta staranność powinna być określana przy uwzględnieniu zawodowego charakteru tej działalności (355 § 2 kc). Inaczej mówiąc, przepisy Kodeksu cywilnego nakazują uwzględnić w odniesieniu do profesjonalistów ich – przynajmniej teoretycznie – wyższe kompetencje, doświadczenie i umiejętności.

 

[...]

 

Damian Łapka – radca prawny. Specjalizuje się we wsparciu prawnym projektów IT, ze szczególnym uwzględnieniem umów wdrożeniowych, licencyjnych i utrzymaniowych, a także i innych z zakresu prawa własności intelektualnej.

 

Piotr Łochowski – adwokat w kancelarii Barta & Kaliński sp. j. Specjalizuje się w umowach dla sektora IT oraz w projektach dla branży reklamowej i mediowej oraz doradztwie z zakresu praw spółek.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

prenumerata Numer niedostępny Spis treści

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"