Umowa serwisowa i umowa utrzymaniowa oprogramowania – co powinien wiedzieć przedsiębiorca?

Umowa serwisowa oprogramowania to w gruncie rzeczy fundament bezpieczeństwa użytkownika oprogramowania. Jej głównym celem jest określenie zasad, na jakich dostawca systemu zobowiązuje się do reagowania w sytuacjach awaryjnych. Chodzi przede wszystkim o naprawę błędów, usuwanie usterek czy przywracanie działania aplikacji wtedy, gdy nagle „coś przestaje działać”. To właśnie dzięki umowie serwisowej przedsiębiorca może mieć pewność, że nie zostanie pozostawiony sam sobie w krytycznym momencie, a reakcja na zgłoszenie będzie odbywać się w określonym, przewidywalnym trybie.

Umowa utrzymaniowa oprogramowania idzie o krok dalej. Jej zakres nie ogranicza się wyłącznie do gaszenia pożarów, lecz obejmuje także troskę o to, by system pozostawał aktualny i funkcjonował bez zakłóceń w dłuższej perspektywie. W praktyce oznacza to chociażby regularne wprowadzanie poprawek, dostosowywanie oprogramowania do zmieniających się wymagań prawnych czy technicznych, a często także zapewnienie określonego poziomu dostępności systemu (tzw. SLA – Service Level Agreement). Można więc powiedzieć, że umowa utrzymaniowa pełni rolę „opiekuna” oprogramowania – pozwala mu rozwijać się razem z biznesem i reagować na zmiany otoczenia.

W codziennej praktyce granice pomiędzy tymi dwiema umowami bywają płynne. Wiele software house’ów łączy je w jednym kontrakcie, w którym znajdziemy zarówno elementy serwisowe, jak i utrzymaniowe. Niezależnie od przyjętej formy, sedno jest wspólne – chodzi o zagwarantowanie przedsiębiorcy stabilności i ciągłości działania systemu IT. Bo nawet najlepiej zaprojektowane oprogramowanie bez bieżącej opieki szybko staje się źródłem frustracji i kosztów, zamiast wspierać rozwój firmy.

Wdrożenie oprogramowania to inwestycja, której wartość mierzy się nie tylko kosztem projektu, lecz przede wszystkim jego bezawaryjnym działaniem w przyszłości. Brak umowy serwisowej lub utrzymaniowej szybko daje o sobie znać. Zamawiający, pozostawiony bez wsparcia, w obliczu awarii często musi szukać pomocy na zewnątrz, płacąc wielokrotnie więcej niż wyniosłaby stała opłata abonamentowa. Software house z kolei, nie mając jasno wyznaczonych granic odpowiedzialności, zmaga się z lawiną zgłoszeń, które wykraczają poza pierwotne ustalenia, co rodzi konflikty i prowadzi do zerwania współpracy.

Nieporozumienia pojawiają się także tam, gdzie zabrakło precyzyjnych ustaleń dotyczących czasu reakcji czy zasad zgłaszania błędów. Klient uważa, że odpowiedź w ciągu tygodnia to zdecydowanie za późno, dostawca zaś sądzi, że mieści się w „rozsądnym terminie”. Takie spory łatwo rozwiązuje się wtedy, gdy umowa zawiera szczegółowe postanowienia a nie ogólnikowe deklaracje.

Umowy serwisowe i utrzymaniowe to nie tylko formalny dodatek do kontraktu wdrożeniowego. To dokumenty, które w praktyce decydują o bezpieczeństwie systemu IT i przewidywalności współpracy między zamawiającym a software house. Dobrze przygotowana umowa chroni przed konfliktami, niepotrzebnymi kosztami i co najważniejsze, zapewnia ciągłość działania biznesu.

Na co szczególnie zwrócić uwagę przy ich zawieraniu?

Podstawowe pytanie brzmi: czego dokładnie potrzebuje zamawiający i co realnie może zapewnić wykonawca. Zakres usług może obejmować wyłącznie usuwanie błędów, ale w praktyce często pojawia się też:

• wsparcie techniczne w postaci infolinii,
• instalacja aktualizacji,
• wgrywanie poprawek (tzw. patchy i fixów),
• szkolenia użytkowników,
• doradztwo dotyczące utrzymania systemu.

Dobrze skonstruowany kontrakt powinien jasno oddzielać obowiązki podstawowe od usług dodatkowych.

Nie każdy błąd ma to samo znaczenie dla funkcjonowania organizacji. Błąd w rozumieniu umowy serwisowej czy utrzymaniowej to sytuacja, w której oprogramowanie nie działa zgodnie ze swoją specyfikacją lub w sposób przewidywany przez użytkownika. Może dotyczyć zarówno awarii całego systemu, jak i pojedynczej funkcjonalności. Aby uniknąć nieporozumień, strony powinny precyzyjnie opisać, jak rozumieją „błąd” oraz jakie są jego kategorie.

W praktyce wyróżnia się zwykle co najmniej cztery poziomy:

Błąd krytyczny – całkowicie blokuje podstawową działalność firmy.

Błąd poważny – znacząco utrudnia korzystanie z systemu, choć nie powoduje całkowitego zatrzymania działalności.

Błąd średni – dotyczy funkcjonalności wspierających, które nie są kluczowe dla działania biznesu.

Błąd niski – to drobne usterki, często o charakterze estetycznym lub ergonomicznym.

Takie rozróżnienie jest kluczowe, bo dla każdej kategorii ustala się inne czasy reakcji i naprawy. Błąd krytyczny może wymagać interwencji w ciągu godzin, a niski być planowany do usunięcia w ramach kolejnej zbiorczej aktualizacji.

Brak jednoznacznej klasyfikacji prowadzi do sporów. Klient zgłasza „awarię krytyczną”, bo dana funkcja jest dla niego biznesowo istotna, ale wykonawca traktuje to jako błąd niższej kategorii, skoro system nadal działa. W efekcie czas SLA liczony jest inaczej przez obie strony, co generuje niepotrzebne napięcia. Dlatego warto nie tylko wymienić kategorie błędów, ale także podać przykłady sytuacji przypisanych do każdej z nich, tak aby w razie problemu nie było wątpliwości, jak klasyfikować dane zgłoszenie.

SLA to serce każdej umowy serwisowej i utrzymaniowej. Określa ono, w jakim czasie wykonawca ma zareagować na zgłoszenie (czas reakcji) czy rozwiązać problem (czas naprawy) a niekiedy zastosować obejście (czas obejścia). Na pierwszy rzut oka brzmi to prosto, ale w praktyce kryje się w tym wiele pułapek.

W umowie zabrakło jasnego ustalenia, czy SLA liczone jest w godzinach kalendarzowych, czy wyłącznie w godzinach pracy wykonawcy. Wydawało się, że obie strony rozumieją to samo, ale w praktyce każda miała inną interpretację.

SLA może obejmować także inne elementy, np. poziom dostępności systemu (99,5% w skali miesiąca). Wysokie SLA oznacza wyższe wynagrodzenie – i warto o tym pamiętać, żeby oczekiwania klienta były realistyczne.

Samo SLA nie wystarczy, aby współpraca w ramach serwisu czy utrzymania oprogramowania przebiegała bezproblemowo. Równie istotne są limity godzin oraz sposób ich rozliczania. To właśnie one decydują o tym, ile realnie wsparcia otrzyma zamawiający w ramach ustalonego abonamentu i co dzieje się w sytuacji, gdy te godziny się wyczerpią.

Limit godzin to określona pula czasu pracy specjalistów przeznaczona na obsługę zgłoszeń w danym okresie rozliczeniowym (np. miesiącu). Może to być np. 20 godzin miesięcznie na poprawki, reakcje na awarie i wsparcie techniczne. W teorii brzmi to jasno, ale w praktyce rodzi wiele pytań:

• Co dzieje się, gdy na koniec miesiąca zostają niewykorzystane godziny? Przechodzą na kolejny okres czy przepadają?
• Co w sytuacji odwrotnej – gdy w połowie miesiąca limit zostanie wyczerpany, a pojawia się poważna awaria? Czy wykonawca powinien kontynuować prace i naliczyć dodatkowe wynagrodzenie, czy ma prawo wstrzymać działania do kolejnego okresu?
• Jak rozliczać prace dodatkowe, które wykraczają poza standardowe zgłoszenia serwisowe – np. wdrożenie nowej funkcji na życzenie klienta?

Nieporozumienia najczęściej biorą się stąd, że zamawiający utożsamia SLA z gwarancją nieograniczonego wsparcia, podczas gdy wykonawca traktuje SLA jako obietnicę czasu reakcji w ramach przyznanego limitu godzin.

Warto więc umieć rozróżniać czasy SLA (terminy reakcji i naprawy) od limitów godzin (ile realnie pracy wchodzi w pakiet) oraz ustalić jak rozliczane są godziny nadmiarowe – czy obowiązuje stawka godzinowa, czy konieczne jest rozszerzenie pakietu oraz czy niewykorzystane godziny przechodzą na kolejne miesiące, czy przepadają.

Dzięki temu strony mają pewność, że oczekiwania są jasne i nie pojawią się spory.

Jednym z najczęściej pomijanych, a jednocześnie najbardziej problematycznych obszarów w umowach serwisowych i utrzymaniowych jest kwestia tzw. vendor lock-in – czyli uzależnienia klienta od jednego wykonawcy. Dzieje się tak wtedy, gdy zamawiający nie ma realnych możliwości zmiany dostawcy, bo tylko dotychczasowy software house ma dostęp do kodu źródłowego, dokumentacji technicznej czy kluczowych narzędzi administracyjnych.

Na pierwszy rzut oka może się wydawać, że to naturalne – skoro wykonawca stworzył system, to najlepiej zna jego architekturę. Problem pojawia się jednak wtedy, gdy współpraca się kończy, np. z powodu sporu, braku satysfakcji z usług albo zmiany budżetu. Bez odpowiednich zapisów w umowie klient zostaje z systemem, którego nie jest w stanie rozwijać ani utrzymywać z innym partnerem. To klasyczny vendor lock-in – sytuacja, w której biznes jest całkowicie uzależniony od jednej firmy IT.

Ryzyko tzw. vendor lock-in – czyli uzależnienia od jednego dostawcy – powstaje już na etapie wdrożenia systemu. To właśnie wtedy powinny zostać uregulowane kwestie praw autorskich do kodu źródłowego, dokumentacji technicznej i administracyjnej czy dostępu do repozytoriów. Jeśli w umowie wdrożeniowej zabraknie takich zapisów, późniejsza umowa serwisowa czy utrzymaniowa może jedynie „łatać” powstałe ryzyka, ale nie rozwiąże problemu w pełni.

Dlatego w kontrakcie utrzymaniowym warto mimo wszystko wprowadzić postanowienia dotyczące:

• praw autorskich do kodu źródłowego – czy pozostają u wykonawcy, czy są przenoszone na zamawiającego, a jeśli nie, to czy udzielana jest licencja i w jakim zakresie,
• dostępu do dokumentacji – technicznej, administracyjnej i użytkowej, tak aby inny podmiot mógł w razie potrzeby przejąć utrzymanie systemu,
• warunków przekazania kodu i narzędzi administracyjnych w przypadku zakończenia umowy (np. source code escrow),
• zakazu utrudniania migracji – np. poprzez stosowanie nietypowych, „autorskich” rozwiązań, które uniemożliwiają lub znacząco podnoszą koszty zmiany dostawcy.

Każda umowa serwisowa czy utrzymaniowa musi regulować, za co wykonawca odpowiada, a za co nie. Brak takich postanowień sprawia, że w razie awarii obie strony mają zupełnie różne oczekiwania – klient zakłada, że serwis obejmie „wszystko, co nie działa”, a wykonawca twierdzi, że to problem sprzętowy, ingerencja osoby trzeciej albo wina konfiguracji środowiska, na które nie miał wpływu.

Dlatego w umowie powinny znaleźć się precyzyjne zapisy dotyczące:

• zakresu odpowiedzialności wykonawcy – np. tylko za poprawność kodu i działania oprogramowania zgodnie ze specyfikacją,
• limitów odpowiedzialności – najczęściej do wysokości określonego wynagrodzenia (np. miesięcznego lub rocznego),
• wyłączeń odpowiedzialności – czyli katalogu sytuacji, w których serwis nie obejmuje zgłoszenia.

Do najczęstszych wyłączeń należą:

• awarie spowodowane ingerencją osób trzecich (np. zewnętrzny administrator serwera wprowadził zmianę),
• błędy wynikające z nieautoryzowanych modyfikacji systemu przez klienta,
• problemy związane z infrastrukturą sprzętową lub sieciową, na którą wykonawca nie ma wpływu,
• usterki wynikające z korzystania z nieaktualnych lub nieobsługiwanych wersji oprogramowania.

Gdyby w umowie wprost wskazano, że odpowiedzialność wykonawcy nie obejmuje skutków działań podmiotów trzecich, konfliktu można by było uniknąć.

Umowy serwisowe i utrzymaniowe to dokumenty, które przesądzają o stabilności i bezpieczeństwie biznesu. Dobrze przygotowane pozwalają uniknąć przestojów, niepotrzebnych kosztów i sporów z dostawcą IT. Źle skonstruowane – mogą sparaliżować działalność firmy w najmniej odpowiednim momencie.

Dlatego warto zadbać o to, aby takie umowy były dostosowane do realnych potrzeb organizacji i rodzaju oprogramowania, z jasnym podziałem obowiązków, precyzyjnym SLA, przejrzystymi zasadami odpowiedzialności i zabezpieczeniem przed vendor lock-in.

W Silesia Legal House wspieramy zarówno przedsiębiorców korzystających z systemów IT, jak i software house’y przygotowujące się do współpracy z klientami. Pomagamy tworzyć, negocjować i analizować umowy serwisowe oraz utrzymaniowe tak, aby zabezpieczały interesy obu stron i odpowiadały na wyzwania praktyki biznesowej.

Jeśli potrzebujesz wsparcia w zakresie przygotowania umowy serwisowej oprogramowania – zapraszamy do kontaktu.