Wdrożenie systemu IT to jedno z najbardziej spornych obszarów prawa umów. Zamawiający oczekuje gotowego, działającego systemu spełniającego jego potrzeby. Wykonawca dostarcza to, co zostało opisane w specyfikacji — jeśli specyfikacja była niekompletna, różnice między oczekiwaniami a dostarczonym produktem mogą być kolosalne. Właśnie dlatego umowa wdrożeniowa IT wymaga szczególnej precyzji w zakresie: opisu przedmiotu, procedury odbiorowej, zarządzania zmianami zakresu i odpowiedzialności za opóźnienia.
Przedmiot umowy — specyfikacja jako fundament
Najważniejszy element umowy wdrożeniowej to opis przedmiotu świadczenia. Im bardziej precyzyjna specyfikacja (SRS — Software Requirements Specification lub podobny dokument), tym mniejsze ryzyko sporów. Specyfikacja powinna zawierać: wykaz funkcjonalności (jako załącznik do umowy), wymagania niefunkcjonalne (wydajność, bezpieczeństwo, dostępność), wymagania integracyjne (z jakimi systemami ma się integrować), wymagania środowiskowe (serwer, baza danych, system operacyjny) oraz kryteria akceptacji — po spełnieniu których dany etap lub całość wdrożenia zostanie uznana za ukończoną.
Brak precyzyjnej specyfikacji lub jej ogólnikowość to proszenie się o kłopoty. „System ma obsługiwać procesy HR spółki" to zdanie bezużyteczne z prawnego punktu widzenia — nie wiadomo, co konkretnie ma robić system i kiedy wdrożenie jest zakończone. Umowa powinna zawierać specyfikację jako załącznik, a za jej zmiany — stosować procedurę zmiany zakresu.
Procedura odbiorowa — klucz do rozliczenia
Procedura odbiorowa określa, w jaki sposób zamawiający weryfikuje i akceptuje wykonane prace. Bez precyzyjnej procedury wykonawca może domagać się zapłaty za system „działający", a zamawiający odmówić zapłaty twierdząc, że system nie spełnia wymagań — i obie strony będą miały rację na swój sposób.
Dobra procedura odbiorowa powinna zawierać: (1) terminy testów akceptacyjnych po dostarczeniu przez wykonawcę, (2) zakres i scenariusze testów akceptacyjnych, (3) sposób zgłaszania usterek (pismo, ticket systemowy, e-mail), (4) podział usterek na krytyczne (blokujące odbiór), istotne (wymagające naprawy w określonym terminie) i nieistotne (do naprawy w przyszłości), (5) termin na naprawę usterek przez wykonawcę, (6) zasadę milczącego odbioru (brak uwag w terminie = odbiór).
Zasada milczącego odbioru (ang. deemed acceptance) jest ważna: jeśli zamawiający nie zgłosi uwag do odebranych prac w terminie X dni, uznaje się je za przyjęte. Chroni to wykonawcę przed sytuacją, gdy zamawiający zwleka z odbiorem bez uzasadnienia, blokując zapłatę. Warto jednak wyraźnie zapisać tę zasadę w umowie — sąd nie domniemuje milczącego odbioru automatycznie.
Duże wdrożenia powinny przewidywać odbiory etapowe (milestones). Każdy etap ma własne kryteria akceptacji i wynagrodzenie częściowe. Zaleta: zamawiający kontroluje postęp prac, a wykonawca otrzymuje regularny przepływ gotówki. Wada: spory mogą pojawić się przy każdym etapie. Umowa powinna określić, że odbiór etapu poprzedniego jest warunkiem rozpoczęcia kolejnego — co chroni wykonawcę przed rozchodzącym się harmonogramem.
Zarządzanie zmianami zakresu — procedura change request
Rozszerzenie zakresu (scope creep) to stopniowe rozszerzanie zakresu wdrożenia bez formalnej zmiany umowy i wynagrodzenia. Jest to jedna z głównych przyczyn przekroczeń budżetu i terminów w projektach IT. Wykonawcy często zgadzają się na „małe" zmiany w trakcie projektu, a po zakończeniu okazuje się, że wykonali o 30% więcej pracy niż przewidywała umowa — i nie mają podstaw do dodatkowego wynagrodzenia.
Procedura change request (CR) to formalny mechanizm zarządzania zmianami zakresu. Każda zmiana specyfikacji wymaga: pisemnego wniosku o zmianę (CR), oceny przez wykonawcę wpływu zmiany na harmonogram i wynagrodzenie, pisemnej akceptacji zamawiającego, i dopiero wtedy — realizacji. Bez pisemnej akceptacji CR wykonawca nie realizuje żadnych zmian wykraczających poza pierwotną specyfikację.
W umowie warto wprost zapisać: „Wszelkie zmiany zakresu prac wymagają zawarcia aneksu do umowy w formie pisemnej. Wykonawca nie jest zobowiązany do realizacji prac wykraczających poza specyfikację bez uprzedniego zawarcia aneksu określającego dodatkowe wynagrodzenie i harmonogram." To proste zdanie może uchronić przed sporami wartymi setki tysięcy złotych.
Kary umowne za opóźnienie — jak skonstruować skutecznie
Kara umowna za opóźnienie w dostarczeniu systemu (art. 483 KC) to standardowe narzędzie w umowach wdrożeniowych. Jednak jej skuteczność zależy od precyzji. Kara powinna być wyrażona jako procent wynagrodzenia za każdy dzień lub tydzień opóźnienia, z górnym limitem (cap) — np. 0,1% wynagrodzenia dziennie, nie więcej niż 10% wartości umowy.
Ważna kwestia: kara umowna za opóźnienie, nie za nienależyte wykonanie. Opóźnienie (art. 476 KC) to stan, gdy dłużnik nie spełnił świadczenia w terminie bez względu na winę. Kara za opóźnienie jest surowsza niż za zwłokę (zawinione opóźnienie). Jeśli w umowie mowa o „karze za opóźnienie", wykonawca odpowiada nawet bez winy — co jest korzystne dla zamawiającego.
Kara umowna może być zastrzeżona wyłącznie na rzecz jednej strony (zamawiającego) lub obustronnie — wówczas zamawiający płaci karę za opóźnienie w dostarczeniu danych lub udzieleniu dostępów wymaganych przez wykonawcę. Wzajemna kara umowna jest dobrym rozwiązaniem w projektach, gdzie obie strony mają obowiązki terminowe.
Własność intelektualna — prawa do systemu po wdrożeniu
Umowa wdrożeniowa musi precyzować, kto po wdrożeniu posiada prawa do systemu. Możliwe modele: (1) pełne przeniesienie praw autorskich do systemu na zamawiającego (droższe, ale zamawiający może system modyfikować bez zgody wykonawcy); (2) licencja na korzystanie z systemu (wykonawca zachowuje prawa, zamawiający może tylko używać); (3) model mieszany — zamawiający otrzymuje prawa do kodu customowego, a licencję na komponenty standardowe wykonawcy.
Przygotowujemy i negocjujemy umowy wdrożeniowe IT zarówno po stronie zamawiającego, jak i wykonawcy. Doradzamy w sporach dotyczących odbiorów i zmiany zakresu. Kontakt: kancelaria@cenkier.pl, Lublin.
Gwarancja i serwis po wdrożeniu
Umowa wdrożeniowa powinna wyraźnie oddzielić: rękojmię (ustawową odpowiedzialność za wady istniejące w chwili odbioru), gwarancję (umowne zobowiązanie do usuwania usterek przez określony czas po wdrożeniu) i serwis (umowną odpłatną usługę utrzymaniową). Mieszanie tych pojęć prowadzi do sporów — np. czy dana usterka to wada gwarancyjna (bezpłatna naprawa) czy płatna usługa serwisowa.
SLA (Service Level Agreement) po wdrożeniu powinno zawierać: czas reakcji i czas naprawy dla różnych kategorii usterek, kary za niedotrzymanie SLA, procedurę eskalacji, procedurę zmiany systemu i sposób zarządzania kodem (repozytorium, dostęp zamawiającego do kodu źródłowego).
Praktyczna rada: czas zainwestowany w specyfikację to czas zaoszczędzony na sporach
Każda godzina spędzona na precyzyjnym opisie wymagań i procedury odbiorowej przed podpisaniem umowy oszczędza dziesiątek godzin sporów i postępowań sądowych. Zamawiający powinien wymagać od wykonawcy pisemnego potwierdzenia, że przeczytał specyfikację i nie zgłasza zastrzeżeń — co utrudnia późniejsze argumentowanie, że specyfikacja była niekompletna. Wykonawca powinien wymagać od zamawiającego pisemnego zatwierdzenia każdego etapu, zanim przejdzie do kolejnego. Precyzja i dyscyplina procesowa na początku projektu to najlepsza inwestycja w spokojną realizację i pewne wynagrodzenie.
Powiązane strony