Rozwój i utrzymanie systemu IT w umowie wdrożeniowej. Poradnik dla software house’ów #16

W większości przypadków realizacja przedmiotu umowy wdrożeniowej, tj. wykonanie opisanego w specyfikacji programu komputerowego nie kończy się na tym etapie. W zasadzie to dopiero początek. Umowa wdrożeniowa w polskim systemie prawnym nie posiada odrębnej definicji ustawowej i jest klasyfikowana jako umowa nienazwana. Oznacza to, że jej treść, role oraz odpowiedzialności stron nie są z góry jednolicie określone przez przepisy prawa, co wymusza indywidualne podejście do każdego kontraktu. Ta hybrydowa natura pozwala na elastyczne dopasowanie kontraktu do specyficznych potrzeb projektu IT, które rzadko mieszczą się w sztywnych ramach jednego typu umowy. Wykonany i wdrożony system od początku generuje potrzebę ciągłego utrzymywania (serwisu). Z biegiem czasu pojawia się także potrzeba rozwoju systemu poprzez dodanie nowych elementów nieprzewidzianych wcześniej w specyfikacji. W związku z tym umowy wdrożeniowe zazwyczaj zawierają postanowienia, które dają furtkę do płynnego przejścia z fazy wdrożeniowej do fazy rozwojowej czy też utrzymaniowej.

Artykuł jest częścią serii dotyczącej umowy wdrożeniowej, poniżej znajdziesz odnośniki do pozostałych wpisów. Jeśli, któryś z artykułów nie jest jeszcze podlinkowany, oznacza to, że wpis dotyczący tego zagadnienia pojawi się na blogu w najbliższej przyszłości.

Postanowienie dotyczące rozwoju w umowie wdrożeniowej

Kwestia rozwoju wykonanego programu komputerowego najczęściej rozwiązywana jest poprzez dodanie prostego postanowienia do umowy wdrożeniowej. Postanowienie to zazwyczaj przybiera dwie formy.

W pierwszym wypadku wskazuje, że wszelkie prace, które wykraczają poza specyfikację są rozliczane w oparciu o stawkę godzinową i przepracowany czas (tzw. time and material).

Model Time & Material charakteryzuje się wysoką elastycznością, co jest szczególnie istotne w kontekście dynamicznie zmieniających się wymagań biznesowych. Według analizy rynku, model ten doskonale współgra z metodykami zwinnymi takimi jak Agile, które zakładają iteracyjny rozwój i adaptację. Główną zaletą tego modelu jest możliwość bieżącego wprowadzania zmian bez konieczności renegocjowania całej umowy. Jednocześnie zapewnia transparentność rozliczeń, gdyż płatności są oparte na faktycznie przepracowanych godzinach. Należy jednak pamiętać, że model ten wymaga większego zaangażowania klienta w proces rozwoju oraz stałej komunikacji między stronami.

W drugim wypadku, gdy strony przewidują, że projekt może być bardziej skomplikowany lub gdy po prostu zamawiający nie chce rozliczać się w formie T&M, stosuje się procedurę składania dodatkowych zamówień w trybie złożenia zapytania i oferty. Takie zamówienie, po jego akceptacji przez obie strony zasadniczo można traktować jako oddzielną umowę.

Sprawdź również: Fixed Price vs. Time & Material 

Procedura zarządzania zmianami (change order process) jest kluczowym elementem każdej umowy wdrożeniowej. W rozwoju oprogramowania zmiana zakresu projektu jest zjawiskiem nieuniknionym. Efektywne zarządzanie zmianami wymaga wdrożenia jasnych polityk, proaktywnego planowania potencjalnych ryzyk oraz solidnych ram do śledzenia, dokumentowania i komunikowania wszelkich modyfikacji. Bez dobrze zdefiniowanego procesu zarządzania zmianami, rozpełzanie się zakresu (scope creep) staje się niekontrolowanym ryzykiem, prowadzącym do przekroczeń budżetu, opóźnień i niezadowolenia klienta.

W zamówieniu zazwyczaj określa się co najmniej:

1. specyfikację prac dodatkowych,
2. termin lub harmonogram wykonania prac dodatkowych,
3. sposób rozliczania i wysokość wynagrodzenia,
4. inne informacje zgodnie z zapotrzebowaniem stron.

Do powyższego katalogu warto dodać również: analizę wpływu zmian na istniejący system i harmonogram projektu, określenie priorytetów wprowadzanych modyfikacji, procedury testowania i walidacji wprowadzonych zmian, zasady aktualizacji dokumentacji technicznej oraz określenie wpływu zmian na umowy SLA i gwarancje. Proces ten powinien także obejmować formalne zatwierdzenie zmian przez upoważnione osoby po stronie klienta i wykonawcy, co stanowi zabezpieczenie przed późniejszymi sporami.

Istotnym aspektem jest również kwestia praw autorskich do modyfikacji.

W polskim prawie autorskim, prawa majątkowe do utworów stworzonych w ramach umów cywilnoprawnych nie przechodzą automatycznie na zamawiającego.

Dlatego każde zamówienie na prace rozwojowe powinno zawierać precyzyjne postanowienia dotyczące przeniesienia praw autorskich lub udzielenia odpowiedniej licencji, określające pola eksploatacji zgodnie z art. 41 ustawy o prawie autorskim i prawach pokrewnych.

Zamów wzór umowy wdrożeniowej IT!

Postanowienia dotyczące utrzymania (SLA) w umowie wdrożeniowej

W przypadku usług utrzymaniowych zazwyczaj stosuje się inne rozwiązanie niż w przypadku usług związanych z rozwojem wdrażanego systemu. Standardowym obecnie rozwiązaniem jest dołączanie do umowy wdrożeniowej w formie załącznika wzoru umowy serwisowej (SLA, service level agreement).

Service Level Agreement to formalna umowa między dostawcą usług a klientem, która określa poziom usług, jaki dostawca zobowiązuje się dostarczyć. W kontekście polskich software house’ów, SLA definiuje kluczowe metryki takie jak czas dostępności systemu (uptime), czas odpowiedzi na zgłoszenie problemu oraz czas jego rozwiązania.

Zgodnie z wzorcowymi klauzulami IT publikowanymi przez polskie instytucje rządowe, usługi utrzymania mają na celu zapewnienie zgodnego z umową i nieprzerwanego działania oprogramowania.

Jest to dobre rozwiązanie z uwagi na to, że sama umowa serwisowa potrafi być obszernym dokumentem. Z czysto praktycznych względów zamieszczanie jej wprost w treści umowy wdrożeniowej może być uciążliwe. Z drugiej strony – i to od strony prawnej jest ważniejsze – umowa SLA jest umową o świadczenie usług. Ma więc inny charakter od umowy wdrożeniowej.

Kluczowe elementy, które powinna zawierać umowa SLA dołączona do umowy wdrożeniowej to: szczegółowy opis świadczonych usług utrzymaniowych z podziałem na naprawy błędów, aktualizacje bezpieczeństwa i poprawę wydajności; konkretne, mierzalne cele poziomu usług (SLO) takie jak gwarantowany czas dostępności systemu wyrażony w procentach; czasy odpowiedzi i rozwiązania problemów z podziałem na poziomy ważności (krytyczny, poważny, drobny); wykluczenia i wyjątki jasno określające, co nie jest objęte standardowym utrzymaniem; procedury zgłaszania i eskalacji problemów; harmonogram i zakres prac technicznych/konserwacyjnych; kary umowne za niedotrzymanie uzgodnionych poziomów usług.

Umowa wdrożeniowa jest zazwyczaj umową o dzieło (ważny jest rezultat prac) a umowa SLA jest umową zlecenia (ważne jest staranne działanie). Dla porządku więc warto te dwa obszary od siebie oddzielić.

Dodatkową kwestią, która może być ważna jest to, że strony nie będą musiały przystępować do negocjacji umowy serwisowej po zakończeniu wdrożenia systemu. Dzięki temu zamawiający ma pewność, że będzie miał zapewnioną ciągłość wsparcia ze strony wykonawcy, zaś wykonawca ma zapewniony stały przychód po zakończeniu wdrożenia. Oczywiście umowa wdrożeniowa może przewidywać, że umowa SLA nie musi zostać ostatecznie podpisana. 

Warto jednak zaznaczyć, że brak podpisania umowy SLA może stanowić istotne ryzyko biznesowe dla obu stron. Dla zamawiającego oznacza to brak gwarancji wsparcia technicznego w krytycznych momentach funkcjonowania systemu. Dla software house’u natomiast może to skutkować utratą przewidywalnego źródła przychodów oraz osłabieniem relacji z klientem. Dlatego rekomenduje się, aby umowa wdrożeniowa zawierała mechanizmy motywujące do zawarcia umowy SLA, takie jak preferencyjne warunki cenowe w pierwszym okresie obowiązywania czy automatyczne wejście w życie podstawowego pakietu usług serwisowych.

Integracja postanowień rozwojowych i utrzymaniowych w umowie wdrożeniowej powinna być przemyślana strategicznie. Software house powinien dążyć do stworzenia spójnego ekosystemu usług, który zapewni klientowi kompleksową obsługę przez cały cykl życia systemu. Taka integracja nie tylko zwiększa wartość oferowanych usług, ale także buduje przewagę konkurencyjną software house’u na rynku. Należy pamiętać, że zgodnie z polską praktyką rynkową, klienci coraz częściej oczekują kompleksowych rozwiązań obejmujących nie tylko dostarczenie systemu, ale także jego długoterminowe wsparcie i rozwój.