„Panie Michale, nasz serwer się popsuł i nie możemy dziś pracować. Dzwoniliśmy do człowieka, który nam to wszystko uruchamiał, ale on mówi, że jest na urlopie i do końca przyszłego tygodnia nie będzie w stanie pomóc. Czy możemy go jakoś zmusić, żeby do nas przyjechał i wszystko naprawił?”
Takie pytanie otrzymałem jakiś czas temu, a wysłał je właściciel kliniki stomatologicznej. Okazało się, że zakładając klinikę, kupił program do obsługi gabinetu wraz z wsparciem serwisowym producenta. Program zainstalował na swoim serwerze, który skonfigurował mu kolega kolegi.
Niestety, pewnego poranka panie z recepcji zauważyły, że nic nie działa. Zadzwoniły do twórców oprogramowania, żeby w ramach wsparcia serwisowego pomogli w przywróceniu systemu do działania. Uprzejmi panowie powiedzieli jednak, że wsparcie świadczą tylko zdalnie i dotyczy ono tylko samego programu. Nie obejmuje natomiast serwera, który jest własnością kliniki. Zresztą nie mogą nic zrobić, bo nie połączą się zdalnie z serwerem, który nie działa.
Właściciel kliniki zaczął więc dzwonić do człowieka, który konfigurował serwer. Ten jednak powiedział, że jest na urlopie i sprawą się nie może zająć, a poza tym nie mają żadnej umowy i on nie jest zobowiązany do naprawiania czegokolwiek, a zwłaszcza za darmo.
Klinika więc przestała przyjmować pacjentów, właściciel się denerwował, a człowiek od serwerów leżał na plaży. Czy można było uniknąć tego problemu?
Czy umowy SLA, serwisowe i utrzymaniowe to to samo?
Nazwa SLA wywodzi się z angielskich słów service level agreement i oznacza ona ustalenie gwarantowanego poziomu działania usługi IT, dokonane pomiędzy:
klientem - podmiotem, który korzysta z danego oprogramowania/usługi IT,
usługodawcą - podmiotem, który odpowiada za działanie takiego programu lub usługi
W teorii umowy serwisowe lub utrzymaniowe obejmują zaś szerszy zakres regulacji – takich jak sposób dokonywania napraw, aktualizacji albo nawet wsparcia użytkowników w bieżącym korzystaniu z oprogramowania. Dodatkowo, umowy takie często zawierają postanowienia dot. hostingu oprogramowania lub utrzymania odpowiedniej infrastruktury serwerowej przez usługodawcę - czyli sprzętu, na którym opiera się działanie usługi, z której korzysta klient.
W praktyce jednak te pojęcia czasem używane są zamiennie. Jeżeli więc ktoś mówi, że chce „podpisać SLA” to może chodzić mu o umowę serwisową. Dla porządku, w tej notatce piszę u umowach serwisowych, a ustalenie minimalnego poziomu SLA może być jej elementem.
Takie umowy serwisowe to bardzo popularna forma porozumienia pomiędzy przedsiębiorcą IT (np. software house) a podmiotem, który korzysta z jakiegoś oprogramowania albo usług informatycznych.
Podstawowe kwestie, które powinny znaleźć się w umowie serwisowej
Dwie podstawowe rzeczy, które powinieneś uregulować w umowie serwisowej to:
kto świadczy usługi serwisowe (bierze odpowiedzialność za naprawianie programu) i na czyją rzecz mają być świadczone takie usługi – to wydaje się oczywiste, choć trzeba uważać jeżeli z oprogramowania korzysta kilka spółek (np. w ramach jednej grupy kapitałowej). W takim przypadku może być konieczne uwzględnienie tego w umowie serwisowej, zwłaszcza jeśli przedstawiciele każdej ze spółek ma mieć prawo do samodzielnego zgłaszania problemów technicznych,
jakiego oprogramowania/sprzętu ma dotyczyć serwis – to bardzo ważne, bo w przedsiębiorstwach wykorzystywane jest mnóstwo narzędzi i sprzętu IT. A zawarcie umowy serwisowej nie musi być związane z serwisowaniem wszystkiego, co klient posiada – z reguły jest dokładnie odwrotnie i np. software house wskazuje, że zajmuje się tylko oprogramowaniem, które sam stworzył lub wdrożył. Nie odpowiada zaś za działanie np. sprzętu albo innych programów (tym może się zajmować inny podmiot, świadczący usługi IT). Dlatego też prawidłowe i precyzyjne rozgraniczenie tego za jaki program/sprzęt odpowiada usługodawca, jest bardzo istotne.
W ramach umowy powinieneś też określić zakres działań, które musi podejmować podmiot serwisujący i jak ma przebiegać cała współpraca. Pamiętaj, że umowy serwisowe bardzo mocno bazują na kooperacji i często w samej umowie strony starają się uregulować warunki takiej współpracy – wskazują np. zasady przyznawania zdalnego dostępu albo udzielania sobie wzajemnych informacji.
Poza samymi naprawami zgłoszonych błędów czasem przydatne są dodatkowe usługi, które ma zapewniać podmiot serwisujący, takie jak bieżący monitoring prawidłowego działania oprogramowania (a czasem nawet całej infrastruktury, serwerów czy sieci lokalnej) lub doradztwo w zakresie odpowiedniego korzystania z oprogramowania – jeżeli Twój klient chce abyś pomógł mu również w tym zakresie, nie wahaj się wpisać tego do umowy serwisowej.
Co ważne, zdarzają się sytuacje, gdzie jeden podmiot tworzy oprogramowanie, a inny sprawuje nad nim bieżącą opiekę. I czasami w takich przypadkach pojawiają się błędy, które tylko twórca programu może usunąć. Stąd też w umowie serwisowej można wskazać, że usługodawca powinien współpracować również z twórcą oprogramowania i reprezentować swojego klienta w kontaktach z takim twórcą – zdarza się to często w sytuacjach, gdy podmiot świadczący usługi serwisowe jest jednocześnie autoryzowanym partnerem twórcy oprogramowania.
Jak klasyfikować błędy i co z nimi robić?
Twoim podstawowym działaniem, jako podmiotu świadczącego usługi serwisowe, będzie naprawianie różnego rodzaju wad oprogramowania, błędów, bugów i innych nieprawidłowości, które występują w związku z działaniem programu. Stąd też dobrze byłoby abyś zawarł w umowie definicję takiego błędu/nieprawidłowości/problemu/wady– szczegółowy wybór dot. nazewnictwa może być podjęty przez same strony.
Przykładowo: Błąd to każde nieprawidłowe lub niezgodne z Dokumentacją działanie Systemu.
Czasem dodaje się, że błąd musi wynikać z nieprawidłowości w samym programie, a nie np. z wadliwego działania sprzętu klienta (zwłaszcza, jeśli usługodawca nie odpowiada za działanie sprzętu, a jedynie dba o prawidłowe funkcjonowanie oprogramowania zainstalowanego u klienta).
W umowie warto opisać też kategorie błędów – tzn. błędy dzieli się na różne poziomy istotności, biorąc pod uwagę ich wpływ na funkcjonowanie całego oprogramowania.
Przykładowo:
Błąd Krytyczny/Awaria – brak możliwości uruchomienia oprogramowania, zatrzymanie działania oprogramowania lub brak możliwości korzystania z podstawowych funkcji oprogramowania, niemożność zalogowania się do programu przez użytkownika czy utrata danych - w umowach czasem wskazuje się wprost jak należy rozumieć "podstawowe funkcje oprogramowania". Czasem lista takich funkcji jest też załącznikiem do umowy,
Błąd Średni/Defekt – istotne utrudnienia w korzystaniu z oprogramowania, które polegają w szczególności na braku możliwości korzystania z innych niż podstawowe funkcje oprogramowania,
Błąd Drobny/Usterka – inne nieprawidłowości w funkcjonowaniu oprogramowania, które nie uniemożliwiają korzystania z jego funkcjonalności, lecz mogą utrudniać lub spowalniać bieżącą pracę użytkownika.
Kto wskazuje kategorie błędów?
Z reguły klient, choć często jest to przedmiotem dość burzliwych negocjacji pomiędzy stronami. Dlatego czasem, w ramach kompromisu, przyjmuje się, że usługodawca może zgłaszać swoje uwagi do tego w jaki sposób błąd został przypisany do danej kategorii albo wręcz się sprzeciwić takiej decyzji klienta. W takiej sytuacji strony powinny zgodnie ustalić jak istotne jest wystąpienie błędu i w jaki sposób powinien on zostać naprawiony.
Czas reakcji i czas naprawy
Wraz z kategoriami błędów powinieneś określić czas reakcji i czas naprawienia danego błędu w konkretnej kategorii. Czasem określa się tylko czas reakcji albo tylko czas naprawy – to tak naprawdę zależy od tego jakie są wymagania i możliwości negocjacyjne stron umowy.
Uregulowanie tej kwestii w umowie może wyglądać tak:
Dodatkową kwestią, którą można uregulować jest też wskazanie czasu znalezienia obejścia danego problemu, czyli rozwiązania tymczasowego nie usuwającego przyczyny błędu, ale przywracającego oprogramowanie do stanu, gdzie można z niego korzystać.
Jak zgłaszać błędy i co wpisać w zgłoszeniu?
W umowie powinieneś również opisać to jak realizowany jest cały proces zgłoszenia błędów. Pozwoli to później uniknąć ewentualnych problemów komunikacyjnych. Zwykle regulacje dotyczą takich kwestii:
w jaki sposób dokonać samego zgłoszenia – warto abyś opisał w umowie np. to kto jest uprawniony do dokonywania zgłoszeń albo w jaki sposób dokonać zgłoszenia (np. założyć ticket w systemie serwisowym, wysłać wiadomość na adres e-mail albo zadzwonić na odpowiedni numer),
jakie dane należy podać w zgłoszeniu (jak opisać błąd, czy wskazywać dodatkowe informacje dot. wykorzystywanego systemu operacyjnego, sprzętu itp.),
czy serwisant ma prawo do żądania dodatkowych informacji i czy do momentu konkretniejszego wyjaśnienia napotykanego problemu usługodawca może wstrzymać się z działaniami naprawczymi – tzn. czy żądanie dodatkowych informacji wstrzymuje bieg terminu naprawy (np. gdy błąd został opisany bardzo lakonicznie i niemożliwe jest wywnioskowanie, gdzie leży problem),
w jaki sposób będzie realizowane usuwanie błędu, w szczególności to, czy ewentualne naprawy są wykonywane bezpośrednio w ramach środowiska produkcyjnego klienta. Tego typu postanowienie z reguły wymaga abyś uregulował to, że klient powinien zapewnić zdalny dostęp do takiego środowiska,
kiedy można uznać błąd za naprawiony, poprzez np. przyznanie klientowi prawa do zweryfikowania tego, że dana nieprawidłowość została usunięta przez serwisanta.
Odpowiedzialność i kary umowne
W umowach serwisowych często wskazuje się, że dostawca usług serwisowych nie odpowiada za cały szereg zdarzeń, które skutkują jakimiś nieprawidłowościami w działaniu oprogramowania. Zaliczają się do nich np. takie sytuacje, gdy:
błąd jest skutkiem dokonywania przez klienta samodzielnych zmian w programie, modyfikacji ustawień czy kodu źródłowego, które nie są konsultowane z dostawcą usług IT,
błąd jest skutkiem nieprawidłowych działań użytkowników, którzy dokonują operacji w sposób sprzeczny z instrukcją lub innymi zaleceniami,
błąd jest skutkiem niepoprawnego działania innych programów lub elementów infrastruktury IT klienta.
Dodatkowo, w umowach serwisowych standardem są klauzule dotyczące innych wyłączeń odpowiedzialności usługodawcy, np. określenia siły wyżej, która miałaby wyłączyć odpowiedzialność umowną w związku z niewypełnieniem jakiegoś zobowiązania.
Za siłę wyższą można uznawać zdarzenia związane z siłami przyrody (np. powódź), zamieszkami, strajkami itp. Obecnie, w czasach pandemii COVID-19, można spotkać się z klauzulami, gdzie skala rozprzestrzeniania się wirusa oraz restrykcje i inne decyzje państwa w ramach walki z wirusem nie są uznawane za siłę wyższą i nie wyłączają odpowiedzialności umownej.
Jeżeli chcesz dowiedzieć się więcej na temat stosowania kar umownych w umowach IT, zapraszam do przeczytania tego wpisu.
Klauzule SLA, czyli nieprzerwane działanie usługi
W niektórych umowach zawiera się postanowienia, dotyczące gwarantowanego poziomu działania danej usługi IT – czyli typowe regulacje dot. poziomu SLA. Z reguły dotyczy to sytuacji, gdy firma IT odpowiada za całe oprogramowanie i infrastrukturę IT, niezbędną do tego, aby klient korzystał z programu. Dlatego właśnie tego typu regulacje są popularne zwłaszcza w przypadku świadczenia usług chmurowych.
Z reguły poziom SLA określa się w procentach, które odnoszą się do określonego czasu – np. miesiąca lub roku. Tym samym, możemy np. wskazać, że usługa chmurowa będzie działała co najmniej przez 95% czasu w ramach każdego miesiąca. Umowy czasem wprost przewidują, że jeżeli usługa nie będzie dostępna przez wskazany czas, dostawca zapłaci karę umowną albo np. obniży wysokość wynagrodzenia należnego mu z tytułu świadczenia usługi.
Postanowienie w tym zakresie może wyglądać tak:
Usługodawca gwarantuje, że dostępność Systemu obliczana dla każdego miesiąca nie będzie mniejsza niż 99,0% (tj. łączny czas przestoju Systemu nie przekroczy 1% czasu pracy Systemu obliczanego w sposób nieprzerwany, 24 godziny na dobę, siedem dni w tygodniu).
Co ważne, postanowienia te mogą być łączone z regulacjami dot. czasu reakcji i napraw, jak również mogą funkcjonować samodzielnie. W takim przypadku usługodawca wskazuje, że oprogramowanie po prostu będzie działało, bez zapewnień dot. tego w jakim czasie powinny być usuwane usterki.
Jeżeli zdecydujesz się na regulację w jednej umowie obu tych kwestii, tzn. zarówno poziomu dostępności jak i czasów reakcji i napraw, warto abyś precyzyjnie opisał zależność między tymi dwoma elementami. Przykładowo, dotrzymywanie czasu reakcji i naprawy nie ma wpływu na konieczność zapewnienia nieprzerwanego poziomu działania usługi w skali miesiąca. Tym samym, nawet jeżeli usługodawca na bieżąco likwiduje błędy, ale łączny czas niemożności korzystania z programu jest mniejszy niż określony przez strony procent (np. 95%), klient może uznać, że druga strona naruszyła swoje obowiązki.
Poufność i dane osobowe
W ramach świadczonych usług możliwe jest zapoznanie się przez serwisanta z dokładnym sposobem funkcjonowania danego przedsiębiorcy. Z tego właśnie powodu, odpowiednie byłoby opisanie kwestii związanych z zachowaniem poufności oraz ewentualnej odpowiedzialności za wyciek takich informacji.
Dodatkowo, jeżeli w związku z działaniami serwisowymi dostawca będzie mógł przetwarzać dane osobowe, w umowach pojawiają się postanowienia dotyczące powierzenia przetwarzania danych osobowych, wymagane zgodnie z RODO (o umowach powierzenia możesz przeczytać więcej tutaj).
Prawa autorskie i umowa serwisowa. Czy to się łączy?
Często pomijanym lub traktowanym pobocznie elementem wielu umów serwisowych są kwestie własności intelektualnej. Należy pamiętać, że oprogramowanie bardzo często będzie podlegało regulacjom prawa autorskiego, tzn. będzie uznawane za utwór w rozumieniu ustawy i podlegało ochronie tam wskazanej.
Jeżeli w trakcie wykonywania umowy powstaną jakieś rzeczy rozumiane przez prawo autorskie jako utwory (np. nowa dokumentacja lub nowe oprogramowanie) konieczne będzie uregulowanie ich statusu w umowie. W praktyce po prostu będzie to przeniesienie autorskich praw majątkowych (lub udzielenie licencji) do stworzonych utworów.
Co więcej, jeżeli następuje sytuacja, gdzie inne podmioty tworzą i serwisują oprogramowanie, warto zastanowić się nad dodaniem do umowy postanowień związanych z koniecznością respektowania przez serwisanta praw twórców oprogramowania.
Kwestie dodatkowe
Niekiedy możesz mieć potrzebę, aby w umowie serwisowej uregulować inne, dodatkowe kwestie. Najczęściej są to takie rzeczy jak:
uzależnienie czasu reakcji i naprawy błędów, a także godzin przyjmowania zgłoszeń od godzin pracy podmiotu serwisującego – tj. wskazanie, że zgłoszenia błędów przyjmowane są np. tylko w określonych godzinach w dniach roboczych. Dookreślenie tego aspektu pozwoli uniknąć budzenia specjalisty o 2 w nocy z informacją, że system się zepsuł i musi siadać do pracy :) Czasem pojęcia takie jak godziny robocze i dni robocze są wprost definiowane w umowie, tak aby nie pozostawić wątpliwości co do tego kiedy rzeczywiście możliwe jest realizowanie napraw,
uregulowanie obowiązku aktualizacji dokumentacji oprogramowania w trakcie świadczonych usług lub tworzenia regularnych raportów dotyczących wykonywania usług w zakresie stanu oprogramowania i jego utrzymywania (tzw. health-check report).
umożliwienie, ograniczenie (np. poprzez konieczność wskazywania klientowi każdego serwisanta z imienia i nazwiska) lub zabronienie podmiotowi świadczącemu usługi serwisowe korzystania z podwykonawców,
zakaz zatrudniania przez klienta pracowników firmy IT, którzy świadczą usługi serwisowe – pozwala to zapobiec „podbieraniu” specjalistów przez klienta, który może w pewnym momencie uznać, że sam stworzy zespół ludzi, którzy będą serwisować jego program – i do tego najlepiej nadadzą się byli pracownicy usługodawcy
Jeśli chcesz, możesz w umowie serwisowej dopisać również możliwość świadczenia dodatkowych usług, np. wsparcia użytkowników w bieżącym wykorzystywaniu oprogramowania w ramach jakiegoś helpdesku.
W takim przypadku w umowie warto określić dodatkowe wynagrodzenie za takie usługi oraz maksymalną ilość godzin w miesiącu, które może wykorzystać klient. To dobre zabezpieczenie interesów usługodawcy – dzięki temu klient nie zgłasza jako nieprawidłowości tych rzeczy, których nie potrafi wykonać w ramach programu, chociaż wszystko działa dobrze.
Przywołana na początku wpisu historia kliniki stomatologicznej skończyła się na szczęście dobrze – „człowiek od serwerów” w końcu poprosił kolegę, żeby ten przyjechał na miejsce i zobaczył co stało się z serwerem. Awarię udało się zlikwidować w pół godziny, a żadne dane nie zostały utracone. Co więcej, od tego czasu w klinice robione są kopie zapasowe, a usługa bieżącej obsługi sprzętu IT została uregulowane w odrębnej umowie, którą przygotowałem właścicielowi kliniki :) biorąc pod uwagę to, że wszystko wróciło do normy po kilkunastu godzinach, właściciel miał sporo szczęścia :)
Tematyka umów serwisowych Cię zainteresowała? Masz jakieś dodatkowe pytania? Daj mi znać przez formularz kontaktowy na www.bytelaw.pl albo napisz na kontakt@bytelaw.pl.
