Umowa wdrożeniowa IT — odbiory, SLA, change request i kary umowne

Umowa wdrożeniowa IT jest jednym z najważniejszych dokumentów w projekcie informatycznym. Powinna nie tylko określać, jaki system ma zostać dostarczony i ile będzie kosztował, lecz również tworzyć procedurę pozwalającą stronom przejść od początkowych założeń do działającego rozwiązania. To właśnie brak takiej procedury jest jedną z najczęstszych przyczyn konfliktów pomiędzy klientem a software house’em.

Na początku projektu strony zazwyczaj są zgodne co do ogólnego celu. Klient chce otrzymać system CRM, platformę sprzedażową, aplikację mobilną, rozwiązanie księgowe, system automatyzujący produkcję albo narzędzie wykorzystujące sztuczną inteligencję. Wykonawca deklaruje, że posiada odpowiedni zespół, doświadczenie i technologię. Problemy pojawiają się dopiero wtedy, gdy trzeba ustalić, czy konkretna funkcjonalność znajdowała się w cenie, czy przekazana wersja nadaje się do odbioru, kto odpowiada za opóźnienie, a także czy zgłoszona przez klienta potrzeba jest usunięciem błędu, czy płatną zmianą zakresu.

Umowa, która ogranicza się do krótkiego opisu systemu, terminu końcowego i łącznego wynagrodzenia, pozostawia większość tych problemów bez odpowiedzi. W efekcie klient może uważać, że zapłacił za kompletny produkt, natomiast wykonawca twierdzi, że dodatkowe funkcje wymagają nowego budżetu. Klient może odmawiać odbioru ze względu na liczne usterki, podczas gdy software house uznaje je za drobne błędy, które zgodnie z umową nie powinny blokować płatności.

Dobrze przygotowana umowa wdrożeniowa powinna zatem opisywać nie tylko rezultat, ale także sposób jego osiągnięcia. Kluczowe znaczenie mają procedury odbiorowe, zasady zgłaszania i kwalifikowania błędów, harmonogram oraz zależności między zadaniami stron. Jeżeli po wdrożeniu wykonawca ma świadczyć usługi utrzymania, konieczne jest odpowiednie SLA. Jeżeli zakres może się zmieniać, umowa powinna zawierać procedurę change request. Odpowiedzialność za naruszenia może zostać zabezpieczona karami umownymi, ale ich konstrukcja musi być przemyślana.

Ministerstwo Cyfryzacji w swoich materiałach dotyczących umów wdrożeniowych podkreśla znaczenie rozdzielenia wdrożenia od usług utrzymania i rozwoju, określenia etapów, odbiorów, harmonogramu, podwykonawców oraz konsekwencji przekroczenia terminów. Materiały te były przygotowywane przede wszystkim dla sektora publicznego, jednak opisane w nich problemy występują również w komercyjnych projektach IT. (Gov.pl⁠)

Czym jest umowa wdrożeniowa IT?

Polskie przepisy nie regulują umowy wdrożeniowej jako odrębnego typu umowy. Jej charakter zależy od treści zobowiązań przyjętych przez strony.

Umowa może zawierać elementy umowy o dzieło, umowy o świadczenie usług, umowy licencyjnej, umowy sprzedaży sprzętu, umowy o przeniesienie praw autorskich, hostingu, utrzymania i rozwoju systemu. Z tego powodu umowy wdrożeniowe często określa się jako umowy mieszane albo nienazwane.

Jeżeli głównym obowiązkiem wykonawcy jest stworzenie i przekazanie systemu odpowiadającego uzgodnionym wymaganiom, zobowiązanie może mieć charakter rezultatu. Klient oczekuje wówczas konkretnego dzieła, które można przetestować, odebrać i porównać ze specyfikacją.

Jeżeli natomiast projekt jest realizowany w modelu, w którym klient na bieżąco zarządza backlogiem, zmienia priorytety, decyduje o kolejnych zadaniach i płaci za pracę zespołu, relacja może być bliższa świadczeniu usług. Wykonawca odpowiada wtedy przede wszystkim za należytą staranność oraz prawidłowe zapewnienie specjalistów, a nie zawsze za ukończenie całego produktu w pierwotnie przewidywanym budżecie.

W praktyce jeden kontrakt może łączyć oba modele. Analiza przedwdrożeniowa może mieć charakter usługowy, natomiast wykonanie określonych modułów może stanowić zobowiązanie rezultatu. Po odbiorze systemu rozpoczynają się usługi utrzymania rozliczane abonamentowo, a dalszy rozwój jest realizowany na podstawie odrębnych zamówień.

Kwalifikacja prawna ma znaczenie dla odpowiedzialności, możliwości odstąpienia, zasad odbioru oraz stosowania przepisów o umowie o dzieło. Nie należy jednak zakładać, że sama nazwa dokumentu rozstrzyga o charakterze kontraktu. Sąd będzie analizował rzeczywistą treść zobowiązań i gospodarczy cel współpracy.

W sprawie dotyczącej wdrożenia oprogramowania Sąd Najwyższy zwracał uwagę, że konieczna jest szczegółowa ocena treści umowy oraz tego, czy przeważają w niej elementy umowy o dzieło, świadczenia usług czy umowy mieszanej. Samo używanie niedokończonego albo wadliwego systemu nie musi oznaczać prawidłowego wykonania całego przedmiotu wdrożenia.

Precyzyjne określenie przedmiotu wdrożenia

Podstawowym elementem umowy jest opis systemu, który ma zostać dostarczony. Sformułowanie, że wykonawca zobowiązuje się wdrożyć nowoczesny system CRM albo aplikację odpowiadającą potrzebom klienta, jest zdecydowanie zbyt ogólne. Nie pozwala później ustalić, czy konkretna funkcja miała zostać wykonana w ramach uzgodnionej ceny.

Opis przedmiotu powinien wskazywać funkcje, moduły, integracje, role użytkowników, wymagania wydajnościowe, bezpieczeństwo, obsługiwane środowiska, migrację danych, dokumentację, szkolenia oraz zakres uruchomienia produkcyjnego.

Nie oznacza to, że wszystkie wymagania muszą zostać szczegółowo opisane bezpośrednio w treści umowy. Mogą znajdować się w specyfikacji, opisie przedmiotu zamówienia, dokumentacji analitycznej, backlogu, makietach, diagramach albo statement of work. Konieczne jest jednak ustalenie hierarchii dokumentów.

W projekcie IT łatwo o sprzeczności. Oferta może przewidywać jedną funkcjonalność, specyfikacja inną, a prezentacja sprzedażowa sugerować znacznie szerszy zakres. Umowa powinna określać, który dokument ma pierwszeństwo.

Należy również zdecydować, czy system ma spełniać jedynie wymagania wyraźnie wymienione, czy także funkcje konieczne do osiągnięcia wskazanego celu. Klient może oczekiwać kompletnego, działającego procesu, natomiast wykonawca może literalnie odwoływać się do listy funkcjonalności.

Dobrym rozwiązaniem jest połączenie szczegółowych wymagań z obowiązkiem zapewnienia, że system jako całość będzie zdolny do realizacji określonego celu biznesowego. Trzeba jednak uważać, aby cel nie był tak ogólny, że wykonawca przyjmuje nieograniczoną odpowiedzialność za rezultaty biznesowe klienta.

Analiza przedwdrożeniowa

W wielu projektach szczegółowy zakres nie jest możliwy do określenia przed wykonaniem analizy przedwdrożeniowej. Analiza może obejmować warsztaty, opis procesów, wymagania funkcjonalne i niefunkcjonalne, integracje, migrację, architekturę, harmonogram oraz estymację kosztów.

Umowa powinna określać, czy analiza jest odrębnym etapem, czy częścią całości wdrożenia. Należy także ustalić, czy jej wynik może wpłynąć na wynagrodzenie i termin.

Jeżeli strony podpisują umowę ryczałtową przed przeprowadzeniem analizy, wykonawca przyjmuje istotne ryzyko błędnej wyceny. Z drugiej strony klient może później usłyszeć, że funkcje potrzebne do działania systemu nie znajdowały się w początkowej ofercie.

Bezpieczniejszy może być model, w którym najpierw realizowana jest odpłatna analiza, a następnie strony zatwierdzają szczegółowy zakres wdrożenia. Należy jednak przewidzieć, co stanie się, jeżeli nie osiągną porozumienia w sprawie ceny albo harmonogramu.

Klient powinien uzyskać prawa pozwalające przekazać dokumentację analityczną innemu wykonawcy, jeżeli zdecyduje się nie kontynuować projektu z pierwszym software house’em.

Harmonogram i kamienie milowe

Harmonogram powinien pokazywać nie tylko końcowy termin, ale także najważniejsze etapy wdrożenia. Kamieniami milowymi mogą być zakończenie analizy, przygotowanie makiet, dostarczenie określonego modułu, migracja próbna, testy integracyjne, testy akceptacyjne, uruchomienie produkcyjne i zakończenie okresu stabilizacji.

Każdy termin powinien zostać powiązany z jasno określonym rezultatem. Samo stwierdzenie, że etap programistyczny zakończy się 30 września, może nie wystarczyć, jeżeli strony nie wiedzą, co dokładnie ma zostać w tym dniu przekazane.

Warto rozróżnić terminy wiążące od orientacyjnych. Jeżeli wszystkie daty zostaną nazwane orientacyjnymi, klient może mieć problem z dochodzeniem odpowiedzialności za opóźnienia. Jeżeli każda drobna data zostanie zabezpieczona wysoką karą, wykonawca może nadmiernie zwiększyć cenę projektu albo przyjąć defensywny sposób realizacji.

Harmonogram powinien uwzględniać zależności od klienta. Wdrożenie może wymagać dostarczenia danych, dokumentacji API, dostępów, decyzji biznesowych, akceptacji makiet albo przygotowania infrastruktury.

Umowa powinna określać, co dzieje się z terminami, jeżeli klient opóźnia współdziałanie. Automatyczne przesunięcie wszystkich terminów o czas opóźnienia może być zbyt uproszczone, ponieważ brak jednej decyzji może zablokować cały zespół na znacznie dłużej. Z drugiej strony wykonawca nie powinien otrzymać prawa do dowolnego przesuwania harmonogramu.

Dobrą praktyką jest nałożenie na wykonawcę obowiązku szybkiego poinformowania o przeszkodzie, wskazania jej wpływu i podjęcia działań ograniczających opóźnienie.

W jednym z najnowszych postanowień dotyczących wdrożenia systemu informatycznego Sąd Najwyższy zaakceptował ocenę, że wykonawcom nie można było przypisać zwłoki za okres, w którym zamawiający nie przekazywał dokumentacji koniecznej do wykonania całości dzieła. Samo przekroczenie pierwotnej daty nie oznacza więc automatycznie odpowiedzialności wykonawcy, jeżeli klient nie wykonał wymaganych obowiązków współdziałania.

Odbiór jako najważniejsza procedura umowy

Odbiór jest formalnym potwierdzeniem, że określony etap albo cały system został wykonany zgodnie z umową.

Nie powinien być traktowany jedynie jako techniczna formalność potrzebna do wystawienia faktury. Odbiór wpływa na wymagalność wynagrodzenia, rozpoczęcie gwarancji, przejście do kolejnego etapu, uruchomienie utrzymania, przeniesienie praw autorskich oraz możliwość naliczania kar.

Umowa powinna wskazywać, kto zgłasza gotowość do odbioru, jakie materiały powinny zostać przekazane, ile czasu klient ma na testy oraz w jakiej formie przekazuje wynik.

Należy określić, czy brak odpowiedzi oznacza automatyczny odbiór. Milczący odbiór może chronić wykonawcę przed sytuacją, w której klient bez uzasadnienia przez wiele tygodni nie wykonuje testów i blokuje płatność. Z perspektywy klienta może jednak prowadzić do odebrania wadliwego systemu tylko dlatego, że zespół nie zdążył przeprowadzić złożonych testów.

Termin powinien być dostosowany do zakresu etapu. Trzy dni robocze mogą wystarczyć do sprawdzenia prostej makiety, ale nie do przetestowania systemu obejmującego migrację danych, setki procesów i integracje z wieloma dostawcami.

Odbiór częściowy, etapowy i końcowy

Umowa może przewidywać kilka rodzajów odbiorów.

Odbiór częściowy może dotyczyć pojedynczej funkcji albo produktu prac, który nie posiada jeszcze samodzielnej wartości użytkowej. Odbiór etapu obejmuje większą część projektu, przykładowo analizę, moduł albo migrację. Odbiór końcowy potwierdza wykonanie całego wdrożenia.

Strony powinny określić konsekwencje każdego odbioru. Czy zatwierdzenie etapu wyłącza możliwość późniejszego zgłaszania wad? Czy jedynie potwierdza gotowość do dalszych prac? Czy po odbiorze klient musi zapłacić całą transzę, mimo że system nie działa jeszcze jako całość?

Szczególnie istotne jest ustalenie, czy poszczególne etapy są samodzielnymi częściami świadczenia. Jeżeli moduły mają znaczenie wyłącznie jako element całego systemu, odbiór częściowy nie powinien być automatycznie utożsamiany z pełnym wykonaniem określonej części zobowiązania.

Sąd Najwyższy w sprawie systemu informacji przestrzennej wskazał, że sam podział kontraktu na zadania nie musiał oznaczać, że każde z nich było odrębną częścią zobowiązania. Znaczenie miało to, że zamówiony system miał wartość dla klienta jako kompletna całość, strony przewidziały jeden odbiór końcowy, a wynagrodzenie nie zostało rozdzielone pomiędzy zadania.

Scenariusze i kryteria odbiorowe

Odbiór powinien opierać się na możliwie obiektywnych kryteriach.

Jeżeli umowa pozwala klientowi odmówić odbioru z powodu każdego niezadowolenia albo subiektywnej oceny, wykonawca nie ma pewności, kiedy uzyska wynagrodzenie. Jeżeli z kolei system jest uznawany za odebrany tylko dlatego, że można go uruchomić, klient może otrzymać produkt niezgodny z wymaganiami.

Kryteria mogą wynikać ze specyfikacji, przypadków użycia, scenariuszy testowych, kryteriów akceptacji w backlogu, wymagań wydajnościowych i bezpieczeństwa.

Przed rozpoczęciem testów należy ustalić środowisko, dane testowe, wersję systemu oraz osoby uprawnione do zgłaszania wyników.

Jeżeli klient sam przygotowuje scenariusze dopiero po otrzymaniu systemu, może próbować rozszerzać wymagania. Jeżeli wszystkie testy przygotowuje wykonawca, mogą one nie obejmować realnych procesów biznesowych.

W praktyce warto wymagać wspólnego zatwierdzenia planu testów przed rozpoczęciem odbioru.

Kategorie błędów

Nie każda wada powinna blokować odbiór.

Umowa może rozróżniać błędy krytyczne, poważne, zwykłe i drobne. Definicje powinny opierać się na wpływie na działanie systemu, a nie tylko na nazwie nadanej przez zgłaszającego.

Błędem krytycznym może być wada uniemożliwiająca uruchomienie systemu, powodująca utratę albo ujawnienie danych, blokująca podstawowy proces lub stwarzająca poważne zagrożenie bezpieczeństwa.

Błąd poważny może istotnie ograniczać ważną funkcję, ale posiadać obejście. Błąd zwykły utrudnia korzystanie, lecz nie blokuje podstawowego procesu. Usterka drobna może dotyczyć interfejsu, formatowania albo niedogodności o niewielkim znaczeniu.

Umowa powinna wskazywać, które klasy błędów uprawniają do odmowy odbioru. Często przyjmuje się, że obecność błędu krytycznego lub określonej liczby błędów poważnych blokuje odbiór, natomiast drobne usterki są wpisywane do protokołu i usuwane w ustalonym terminie.

Należy również określić, co dzieje się w przypadku sporu o klasyfikację. Przydatna może być procedura eskalacji do kierowników projektu, komitetu sterującego albo niezależnego eksperta.

Odbiór warunkowy

Odbiór warunkowy może być dobrym rozwiązaniem, gdy system zasadniczo nadaje się do używania, ale pozostały w nim nieblokujące usterki. Klient potwierdza odbiór, a wykonawca zobowiązuje się usunąć listę błędów w określonym terminie. Możliwe jest zatrzymanie części wynagrodzenia do czasu wykonania poprawek.

Należy jednak uważać, aby odbiór warunkowy nie stał się sposobem regularnego przekazywania niedokończonych etapów. Liczba i charakter pozostających usterek powinny być ograniczone.

Umowa powinna wyjaśniać, czy odbiór warunkowy rozpoczyna gwarancję, okres utrzymania oraz terminy płatności. Brak odpowiedzi może prowadzić do konfliktu, gdy klient oczekuje bezpłatnego usunięcia błędów, a wykonawca traktuje je jako zgłoszenia utrzymaniowe.

Protokół odbioru

Protokół powinien identyfikować odbierany etap, wersję oprogramowania, środowisko testowe, przeprowadzone testy, stwierdzone błędy, wynik odbioru oraz terminy wykonania poprawek.

Warto wskazać, czy podpisanie protokołu oznacza brak jakichkolwiek zastrzeżeń, czy jedynie potwierdzenie określonego stanu.

Klient nie powinien podpisywać protokołu bez zastrzeżeń tylko dlatego, że wykonawca potrzebuje dokumentu do wystawienia faktury. Jeżeli istnieją wady, należy je wymienić.

Z drugiej strony klient nie powinien odmawiać podpisania protokołu z powodu problemów niezwiązanych z zakresem odbioru, na przykład z powodu sporu o przyszłe funkcje.

Umowa może dopuszczać protokoły elektroniczne, zatwierdzenie w systemie projektowym albo podpis za pomocą uzgodnionego narzędzia. Ważne jest ustalenie osób uprawnionych do złożenia wiążącego oświadczenia.

Usterka czy change request?

Jednym z najczęstszych sporów jest odróżnienie błędu od zmiany zakresu.

Klient może twierdzić, że funkcja działa nieprawidłowo i wymaga naprawy w cenie. Wykonawca może odpowiadać, że klient oczekuje zachowania, którego nie przewidywała specyfikacja.

Błędem powinno być odstępstwo od uzgodnionego wymagania, dokumentacji, zatwierdzonego projektu albo obiektywnie koniecznej właściwości systemu. Change request dotyczy natomiast nowej funkcji, zmiany zaakceptowanego rozwiązania lub zwiększenia zakresu.

Granica nie zawsze jest oczywista. Jeżeli wymaganie zostało opisane ogólnie, różne osoby mogą inaczej interpretować oczekiwany sposób działania.

Umowa powinna przewidywać mechanizm kwalifikowania zgłoszeń. Wykonawca może otrzymać określony czas na analizę i wskazanie, czy zgłoszenie jest błędem, zmianą, pytaniem czy problemem po stronie środowiska klienta.

Klient powinien mieć możliwość zakwestionowania kwalifikacji, a spór nie powinien automatycznie blokować całego projektu.

Czym jest change request?

Change request jest formalnym wnioskiem o zmianę uzgodnionego zakresu, harmonogramu, technologii, sposobu realizacji, wynagrodzenia albo innego elementu projektu.

Procedura change request chroni obie strony.

Klient uzyskuje informację, ile będzie kosztować zmiana i jak wpłynie na termin. Wykonawca zabezpiecza się przed niekontrolowanym rozszerzaniem zakresu, określanym jako scope creep.

Procedura nie powinna być nadmiernie sformalizowana. Jeżeli każda drobna korekta wymaga podpisania papierowego aneksu przez zarządy obu spółek, projekt może zostać sparaliżowany.

Jednocześnie nie warto opierać zmian wyłącznie na ustnych ustaleniach podczas spotkań. Po kilku miesiącach strony mogą nie pamiętać, czy dana funkcja została zatwierdzona i czy miała wpływać na budżet.

Rozwiązaniem może być elektroniczny formularz zatwierdzany przez wskazane osoby, wpis w uzgodnionym systemie projektowym albo podpisanie krótkiego zamówienia wykonawczego.

Co powinien zawierać change request?

Wniosek powinien opisywać proponowaną zmianę, jej uzasadnienie, wpływ na istniejące elementy systemu, koszt, harmonogram, zasoby, ryzyko i testy. Należy wskazać, czy zmiana wpływa na wcześniej wykonane funkcje, dokumentację, licencje, infrastrukturę i utrzymanie.

Wykonawca powinien przedstawić estymację w określonym terminie. Umowa powinna rozstrzygać, czy sama analiza zmiany jest bezpłatna, czy może zostać rozliczona, szczególnie gdy wymaga wielodniowych prac technicznych.

Change request powinien uzyskać jednoznaczny status. Może zostać zatwierdzony, odrzucony, wycofany albo skierowany do dalszej analizy.

Do czasu zatwierdzenia wykonawca powinien realizować dotychczasowy zakres, chyba że zmiana jest konieczna z powodu prawa, bezpieczeństwa albo technicznej niemożliwości kontynuowania.

Kto może zatwierdzić zmianę?

Umowa powinna wskazywać osoby uprawnione do zatwierdzania change requestów i maksymalną wartość zmian, które mogą zaakceptować.

Project manager może posiadać prawo do zatwierdzania drobnych modyfikacji w ramach ustalonego budżetu, podczas gdy większe zmiany wymagają decyzji komitetu sterującego albo zarządu.

Brak odpowiedniej regulacji może prowadzić do sytuacji, w której pracownik klienta zleca dodatkowe prace, ale później zarząd odmawia zapłaty, twierdząc, że osoba nie była uprawniona do zmiany umowy.

Z drugiej strony wykonawca nie powinien ignorować poleceń osób, które przez cały projekt były traktowane jako uprawnione do zarządzania zakresem.

Warto określić, że tylko zmiany zatwierdzone zgodnie z procedurą wpływają na wynagrodzenie i termin, ale jednocześnie uwzględnić możliwość późniejszego potwierdzenia prac.

Model ryczałtowy a change request

W projekcie ryczałtowym wykonawca zobowiązuje się zrealizować określony zakres za ustaloną kwotę. Change request powinien dotyczyć rzeczywistej zmiany, a nie elementów potrzebnych do prawidłowego wykonania pierwotnych zobowiązań.

Wykonawca nie może traktować jako dodatkowo płatnych napraw własnych błędów, uzupełnienia brakującego kodu albo wykonania funkcji, która jasno wynikała ze specyfikacji.

Klient nie może natomiast oczekiwać, że pod hasłem doprecyzowania wymagań otrzyma całkowicie nowe moduły bez zmiany ceny. Ryczałt przenosi na wykonawcę część ryzyka błędnej estymacji. Nie oznacza jednak, że klient może dowolnie rozwijać zakres.

Im mniej precyzyjna specyfikacja, tym większe ryzyko sporu o to, co obejmowała pierwotna cena.

Model time and material

W modelu time and material klient płaci za czas pracy zespołu według ustalonych stawek.

Procedura change request może mieć prostszą formę, ponieważ każda zmiana wpływa przede wszystkim na liczbę godzin i przewidywany termin, a nie na zamknięty ryczałt.

Nie oznacza to jednak, że procedura jest zbędna. Klient powinien wiedzieć, jak zmiana wpłynie na budżet i priorytety. Wykonawca powinien otrzymać potwierdzenie, że może rozpocząć dodatkowe prace.

Umowa powinna określać limity budżetu, sposób raportowania czasu i obowiązek ostrzegania o przekroczeniu estymacji.

W modelu time and material większe znaczenie ma zarządzanie backlogiem, transparentność pracy oraz odpowiedzialność za należytą staranność. Sam brak ukończenia wszystkich planowanych funkcji nie musi oznaczać naruszenia, jeżeli budżet został wykorzystany na zadania zaakceptowane przez klienta.

Czym jest SLA?

SLA, czyli service level agreement, określa wymagany poziom usług utrzymania systemu.

Nie powinno być utożsamiane z gwarancją albo ogólnym obowiązkiem usuwania błędów. SLA dotyczy przede wszystkim mierzalnych parametrów reakcji i obsługi zgłoszeń po uruchomieniu systemu.

Może określać dostępność usługi, czas reakcji, czas przywrócenia działania, czas rozwiązania zgłoszenia, godziny świadczenia wsparcia, kanały komunikacji, klasy incydentów oraz zasady eskalacji.

Wdrożenie i utrzymanie powinny zostać od siebie wyraźnie oddzielone. W przeciwnym razie strony mogą spierać się, czy poprawka wynika z wad wdrożenia i powinna być bezpłatna, czy stanowi już usługę utrzymaniową.

Materiały Ministerstwa Cyfryzacji dotyczące umów wdrożeniowych wskazują na potrzebę rozdzielenia wykonania systemu, usług utrzymania i usług rozwoju oraz odpowiedniego opisania każdego z tych świadczeń. (Gov.pl⁠)

Czas reakcji a czas naprawy

Czas reakcji oznacza czas od prawidłowego zgłoszenia incydentu do podjęcia przez wykonawcę określonych działań albo potwierdzenia przyjęcia zgłoszenia. Nie oznacza automatycznie usunięcia problemu.

Czas naprawy albo rozwiązania oznacza okres potrzebny do trwałego usunięcia przyczyny. Czas przywrócenia może natomiast oznaczać wdrożenie obejścia pozwalającego wznowić działanie systemu.

Umowa powinna stosować te pojęcia konsekwentnie. Klient może uważać, że czterogodzinny czas reakcji oznacza naprawienie błędu w ciągu czterech godzin, podczas gdy wykonawca wysyła jedynie automatyczne potwierdzenie.

W przypadku błędów krytycznych bardziej praktyczny może być czas przywrócenia podstawowej funkcji, a następnie dłuższy termin na trwałą naprawę.

Należy również ustalić, kiedy terminy przestają biec. Wykonawca może czekać na dane, dostęp albo potwierdzenie klienta. Mechanizm wstrzymywania powinien być przejrzysty i udokumentowany.

Godziny świadczenia wsparcia

SLA powinno określać, czy wsparcie działa w dni robocze w godzinach biurowych, czy przez całą dobę. Zapis „24/7” istotnie wpływa na koszt utrzymania, ponieważ wymaga dyżurów i gotowości zespołu poza standardowym czasem pracy.

Możliwe jest zróżnicowanie. Zgłoszenia krytyczne mogą być obsługiwane całodobowo, a pozostałe jedynie w godzinach serwisowych.

Należy ustalić strefę czasową, kalendarz dni wolnych oraz sposób liczenia godzin. Jeżeli zgłoszenie zostanie przesłane w piątek wieczorem, termin może rozpocząć się natychmiast albo dopiero w poniedziałek.

Regulacja powinna odpowiadać znaczeniu systemu. Aplikacja obsługująca płatności albo produkcję może wymagać innego SLA niż wewnętrzne narzędzie do raportowania.

Dostępność systemu

Dostępność jest zwykle określana procentowo dla miesiąca albo innego okresu rozliczeniowego.

Samo wskazanie poziomu 99,9% nie wystarczy. Umowa powinna określać sposób pomiaru, narzędzie, punkt pomiarowy, okres rozliczeniowy oraz zdarzenia wyłączone.

Należy ustalić, czy niedostępność obejmuje tylko całkowity brak działania, czy także bardzo powolne działanie albo niedostępność kluczowej funkcji.

Wyłączenia mogą dotyczyć zaplanowanych prac technicznych, awarii infrastruktury klienta, działania siły wyższej, ataków, których nie można było uniknąć, oraz błędów zewnętrznych dostawców. Nie powinny być jednak tak szerokie, aby SLA stało się pozorne.

Jeżeli wykonawca sam wybrał dostawcę chmurowego, nie zawsze powinien całkowicie wyłączać odpowiedzialność za jego awarie.

Service credits i kary za SLA

Naruszenie SLA może prowadzić do naliczenia kar umownych albo przyznania service credits, czyli obniżenia przyszłej opłaty. Service credits są prostym mechanizmem rozliczeniowym. Nie zawsze jednak rekompensują realną szkodę klienta.

Umowa powinna określać, czy są jedynym środkiem przysługującym z tytułu naruszenia SLA, czy klient może również dochodzić odszkodowania albo rozwiązać umowę przy powtarzających się problemach.

Jeżeli maksymalna rekompensata za całomiesięczną niedostępność wynosi kilka procent abonamentu, SLA może nie zapewniać realnej ochrony. Z drugiej strony wykonawca nie powinien przyjmować nieograniczonej odpowiedzialności za każde przekroczenie czasu reakcji, niezależnie od skutków.

Dobrym rozwiązaniem może być stopniowanie konsekwencji oraz odrębne prawo wypowiedzenia przy powtarzalnym naruszaniu najważniejszych parametrów.

Gwarancja, stabilizacja i utrzymanie

Okres stabilizacji następuje zazwyczaj bezpośrednio po uruchomieniu produkcyjnym i ma służyć usunięciu problemów ujawniających się podczas rzeczywistego użytkowania.

W tym okresie wykonawca może zapewnić zwiększoną dostępność zespołu i krótsze czasy reakcji.

Gwarancja dotyczy obowiązku bezpłatnego usuwania wad systemu wynikających z nieprawidłowego wykonania. Utrzymanie obejmuje natomiast szerszy zakres usług, takich jak monitoring, aktualizacje, wsparcie użytkowników, reagowanie na incydenty i dostosowanie do zmian środowiska.

Umowa powinna rozdzielać te zakresy. Klient nie powinien płacić abonamentu za naprawianie błędów, za które wykonawca odpowiada w ramach wdrożenia. Wykonawca nie powinien natomiast bezpłatnie realizować wszystkich zmian technologicznych i nowych potrzeb pod hasłem gwarancji.

Kary umowne w umowie wdrożeniowej

Kara umowna może zabezpieczać wykonanie zobowiązania niepieniężnego. Kodeks cywilny pozwala zastrzec, że naprawienie szkody wynikłej z niewykonania albo nienależytego wykonania takiego zobowiązania nastąpi przez zapłatę określonej sumy. (ELI⁠)

W umowie wdrożeniowej kary mogą dotyczyć opóźnienia w wykonaniu etapu, opóźnienia w odbiorze końcowym, naruszenia SLA, nieusunięcia wad, naruszenia poufności, braku przekazania kodu, nieuprawnionego podwykonawstwa, naruszenia praw autorskich oraz niewykonania obowiązków związanych z bezpieczeństwem.

Kara nie może zabezpieczać bezpośrednio obowiązku zapłaty ceny, ponieważ jest to zobowiązanie pieniężne. Opóźnienie klienta w płatności zabezpiecza się przede wszystkim odsetkami.

Klauzula powinna dokładnie wskazywać naruszenie, wysokość albo sposób obliczenia kary, moment rozpoczęcia naliczania, limit oraz relację do innych roszczeń.

Opóźnienie czy zwłoka?

Umowa może przewidywać karę za opóźnienie albo za zwłokę.

Zwłoka jest opóźnieniem, za które dłużnik ponosi odpowiedzialność. Jeżeli wykonawca nie realizuje etapu z przyczyn leżących po stronie klienta, nie powinien co do zasady odpowiadać jak za własną zwłokę.

Kara za opóźnienie może zostać ukształtowana szerzej, ale również wtedy konieczna jest dokładna analiza umowy. Strony mogą rozszerzyć odpowiedzialność wykonawcy, lecz nie każda przyczyna powinna prowadzić do sankcji.

Z perspektywy wykonawcy bezpieczniejsza jest kara za zwłokę. Klient może preferować karę za opóźnienie, ponieważ ogranicza spór o przyczyny. W praktyce warto przewidzieć katalog zdarzeń powodujących przesunięcie terminu, procedurę informowania i obowiązek minimalizowania skutków.

Od jakiej wartości obliczać karę?

Kara procentowa może być liczona od całego wynagrodzenia umownego albo od wartości opóźnionego etapu. Naliczanie kary od całej wartości umowy może być uzasadnione, jeżeli opóźniony element blokuje możliwość korzystania z całego systemu.

Jeżeli natomiast opóźnienie dotyczy niewielkiego, samodzielnego modułu, kara od pełnej wartości wieloletniego kontraktu może być nieproporcjonalna.

Warto zróżnicować podstawę według znaczenia obowiązku. Kara za przekroczenie terminu końcowego może być liczona od całego wdrożenia, a kara za drobny etap od jego wartości.

Umowa powinna także ustalać, czy podstawą jest kwota netto czy brutto.

Limit kar umownych

Łączny limit kar zwiększa przewidywalność ryzyka. Może wynosić określony procent wynagrodzenia, przykładowo 10, 20 lub 30%, z odrębnymi limitami dla poszczególnych kategorii naruszeń.

Nie ma jednej prawidłowej wartości. Zależy ona od projektu, znaczenia terminów, wartości informacji i możliwych skutków awarii. Niektóre naruszenia, takie jak celowe ujawnienie informacji, naruszenie praw autorskich albo poważne zdarzenie bezpieczeństwa, bywają wyłączane z limitu.

Brak limitu nie oznacza automatycznie nieważności kary. Sąd Najwyższy wskazał w sprawie wdrożenia systemu informatycznego, że kara nie może być naliczana w nieskończoność, ale sam brak umownego ograniczenia jej wysokości nie powoduje nieważności klauzuli. Nadmiernemu wzrostowi może przeciwdziałać możliwość miarkowania kary na podstawie art. 484 § 2 Kodeksu cywilnego.

Miarkowanie kary

Jeżeli zobowiązanie zostało w znacznej części wykonane albo kara jest rażąco wygórowana, dłużnik może żądać jej zmniejszenia. Uprawnienie wynika z art. 484 § 2 Kodeksu cywilnego.

Sąd może uwzględnić stopień wykonania, znaczenie naruszenia, relację kary do wynagrodzenia, szkodę i interes wierzyciela. Nie istnieje prosty próg, po którego przekroczeniu kara zawsze zostanie obniżona.

Wykonawca nie powinien więc podpisywać dowolnych kar z założeniem, że sąd później je zredukuje. Postępowanie może trwać długo, a klient może próbować potrącić kwoty z wynagrodzenia.

Klient również powinien unikać kar całkowicie oderwanych od wartości i ryzyka projektu. Proporcjonalna kara ma większą szansę spełniać funkcję motywacyjną i być skutecznie dochodzona.

Kara a odszkodowanie

Zgodnie z Kodeksem cywilnym żądanie odszkodowania przekraczającego wysokość kary nie jest dopuszczalne, chyba że strony postanowiły inaczej.

Jeżeli klient chce zachować prawo do dochodzenia pełnej szkody ponad karę, umowa powinna wyraźnie przewidywać odszkodowanie uzupełniające. Z perspektywy wykonawcy taka klauzula zwiększa ryzyko. Kara staje się minimalną sankcją, a nie maksymalnym poziomem odpowiedzialności.

Możliwe jest ograniczenie odszkodowania uzupełniającego do określonych naruszeń albo objęcie go ogólnym limitem odpowiedzialności.

Należy również rozstrzygnąć, czy kary mogą być kumulowane. Jedno opóźnienie może jednocześnie prowadzić do przekroczenia terminu etapu, terminu końcowego i naruszenia SLA. Umowa powinna zapobiegać nieuzasadnionemu wielokrotnemu sankcjonowaniu tego samego zdarzenia.

Kary za odstąpienie

Często spotyka się karę za odstąpienie od umowy z przyczyn leżących po stronie drugiej strony.

Taka klauzula powinna wskazywać, jakie przyczyny pozwalają naliczyć karę. Nie każde odstąpienie albo wypowiedzenie oznacza automatycznie odpowiedzialność.

Należy ustalić relację pomiędzy karą za opóźnienie a karą za odstąpienie. Możliwość ich łączenia zależy od treści umowy i charakteru zabezpieczanych naruszeń.

Warto również uważać na używanie pojęć odstąpienia i wypowiedzenia zamiennie. Odstąpienie może wywoływać skutki dotyczące wykonanych świadczeń, natomiast wypowiedzenie zazwyczaj kończy relację na przyszłość.

Umowa wdrożeniowa łącząca wdrożenie, licencję i utrzymanie powinna określać skutki zakończenia osobno dla każdego zakresu.

Obowiązki klienta i odpowiedzialność za współdziałanie

Umowa nie powinna regulować wyłącznie obowiązków wykonawcy.

Klient może być zobowiązany do przekazywania danych, zapewnienia pracowników, zatwierdzania dokumentów, dostarczenia infrastruktury, udzielania dostępów i podejmowania decyzji.

Należy wskazać terminy oraz osoby odpowiedzialne. Ogólny zapis, że klient będzie współdziałał, może nie wystarczyć. Wykonawca powinien informować o opóźnieniu klienta i jego konsekwencjach. Jeżeli przez kilka tygodni nie zgłasza problemu, a następnie dopiero po przekroczeniu terminu powołuje się na brak jednej informacji, jego argumentacja może być słabsza.

Warto przewidzieć procedurę eskalacji i zasadę, że opóźnienie klienta przesuwa termin wyłącznie w zakresie rzeczywistego wpływu na projekt.

Sąd Najwyższy w sprawie systemu informacji przestrzennej potwierdził znaczenie obowiązków zamawiającego i związku pomiędzy brakiem dokumentacji a możliwością terminowego ukończenia wdrożenia.

Zarządzanie projektem i eskalacja

Umowa powinna określać strukturę zarządzania.

Kierownicy projektu mogą odpowiadać za bieżące decyzje, harmonogram, zgłoszenia i change requesty. Komitet sterujący może rozwiązywać spory o zakres, budżet i krytyczne ryzyka.

Należy ustalić częstotliwość raportowania, treść raportów i sposób zatwierdzania ustaleń ze spotkań. Brak reakcji na protokół spotkania nie powinien automatycznie zmieniać całej umowy, chyba że strony świadomie przyjęły taki mechanizm.

Procedura eskalacji może wymagać najpierw rozmowy kierowników projektu, następnie osób zarządzających, a dopiero później rozpoczęcia sporu prawnego.

W projekcie technologicznym szybka decyzja jest często bardziej wartościowa niż późniejsze ustalenie, kto miał rację. Umowa powinna umożliwiać kontynuowanie bezspornych prac w czasie rozwiązywania konfliktu.

Prawa autorskie a odbiór

Umowa powinna określać, kiedy klient nabywa prawa do kodu, dokumentacji, grafik, projektów i innych rezultatów. Przejście praw może nastąpić z chwilą stworzenia, przekazania, odbioru albo zapłaty. Każde rozwiązanie wywołuje inne skutki.

Wykonawca może chcieć zachować prawa do czasu otrzymania zapłaty. Klient może potrzebować dostępu do kodu przed końcem projektu, aby ograniczyć vendor lock-in i zabezpieczyć się na wypadek upadłości wykonawcy.

W projektach etapowych możliwe jest przechodzenie praw po odbiorze i zapłacie za każdy etap.

Należy także uregulować komponenty własne wykonawcy, rozwiązania osób trzecich i open source. Klient nie może otrzymać pełnych praw do elementów, których wykonawca nie może przenieść.

Odbiór techniczny nie powinien automatycznie potwierdzać kompletnego przeniesienia praw, jeżeli nie spełniono wymogów prawa autorskiego i umowy.

Kod źródłowy, repozytorium i dokumentacja

Umowa powinna wskazywać, czy klient otrzymuje bieżący dostęp do repozytorium, czy tylko kopię przy odbiorze. Dostęp na bieżąco zwiększa bezpieczeństwo klienta, ale wykonawca może obawiać się ingerencji w kod i problemów z odpowiedzialnością.

Można przyjąć dostęp tylko do odczytu albo okresowe kopie. Przekazanie samego kodu nie wystarczy, jeżeli brakuje historii zmian, instrukcji budowania, konfiguracji, zależności, kluczy i dokumentacji wdrożeniowej.

Kryteria odbioru powinny obejmować kompletność materiałów umożliwiających uruchomienie i dalszy rozwój przez inny zespół, jeżeli taki jest cel klienta. Umowa powinna również określać zasady wydania środowisk, kont chmurowych, domen, certyfikatów i danych po zakończeniu współpracy.

Bezpieczeństwo i dane osobowe

Jeżeli system przetwarza dane osobowe, konieczne może być zawarcie umowy powierzenia przetwarzania. Należy uregulować środowiska testowe, używanie danych produkcyjnych, dostęp personelu wykonawcy, incydenty i usuwanie danych.

Kryteria odbiorowe powinny obejmować wymagania bezpieczeństwa. Testy penetracyjne przeprowadzone dopiero po odbiorze mogą ujawnić problemy, które klient formalnie zaakceptował.

Umowa powinna rozstrzygać, kto wykonuje testy, kto ponosi koszt poprawek i które podatności blokują uruchomienie.

Jeżeli rozwiązanie podlega wymaganiom sektorowym, przykładowo DORA, NIS2, regulacjom finansowym albo medycznym, wymagania powinny zostać włączone do zakresu projektu.

Odstąpienie i plan wyjścia

Klient powinien mieć możliwość zakończenia projektu, gdy opóźnienie, wady albo brak współpracy wykonawcy zagrażają osiągnięciu celu.

Wykonawca powinien móc zakończyć współpracę przy długotrwałym braku płatności, niewykonywaniu obowiązków przez klienta albo bezprawnych poleceniach.

Umowa powinna wskazywać procedurę wezwania, dodatkowy termin oraz przypadki pozwalające na natychmiastowe zakończenie. Należy określić, co dzieje się z wykonanymi etapami, płatnościami, kodem, danymi, licencjami i prawami autorskimi.

Plan wyjścia powinien obejmować przekazanie projektu nowemu wykonawcy, dokumentacji, dostępów i wiedzy. Bez tych elementów klient może posiadać formalne prawo do zakończenia umowy, ale nie mieć technicznej możliwości kontynuowania systemu.

Najczęstsze błędy w umowach wdrożeniowych

Jednym z najczęstszych błędów jest nieprecyzyjny zakres połączony z ceną ryczałtową. Drugim jest brak jasnej procedury odbioru. Strony nie wiedzą, jakie wady blokują odbiór, ile trwa testowanie ani kiedy faktura staje się należna.

Kolejnym problemem jest brak change requestu albo procedura, której nikt nie stosuje. Dodatkowe funkcje są uzgadniane na spotkaniach, ale nie wiadomo, czy wpłynęły na cenę i termin.

Częstym błędem jest nazywanie wszystkich problemów błędami albo odwrotnie — kwalifikowanie każdej poprawki jako dodatkowo płatnej zmiany. SLA bywa ograniczone do deklaracji „wsparcie 24/7” bez określenia czasów reakcji, naprawy i sposobu pomiaru dostępności.

Kary są natomiast naliczane od całej wartości umowy za każde drobne uchybienie, bez limitu, zasad kumulowania i uwzględnienia opóźnień klienta. Problematyczne jest także uzależnienie wszystkich praw do kodu od końcowego odbioru. Jeżeli projekt upadnie na ostatnim etapie, klient może nie posiadać praw do żadnej części, mimo że zapłacił większość wynagrodzenia.

Jak przygotować bezpieczną umowę wdrożeniową?

Prace powinny rozpocząć się od ustalenia modelu projektu, a nie od pobrania uniwersalnego wzoru.

Należy zdecydować, czy zakres jest wystarczająco znany dla ryczałtu, czy właściwszy będzie model etapowy albo time and material. Następnie trzeba opisać rezultaty, role, harmonogram, zależności i kryteria odbioru.

Procedura change request powinna być dopasowana do sposobu zarządzania projektem. Powinna umożliwiać sprawne wprowadzanie zmian, ale pozostawiać dowód ich zatwierdzenia.

SLA należy budować na podstawie realnego znaczenia systemu, dostępności zespołu i budżetu. Nie warto wpisywać parametrów, których wykonawca nie jest w stanie spełnić albo których klient nie potrafi zmierzyć.

Kary powinny zabezpieczać najważniejsze obowiązki, a nie każdy paragraf umowy. Należy określić ich limit, podstawę, możliwość kumulowania i relację do odszkodowania.

Dokument powinien być przejrzany przez osoby techniczne i biznesowe. Prawnik nie powinien samodzielnie wymyślać kryteriów odbioru, klas błędów i parametrów dostępności bez konsultacji z zespołem projektowym.

Podsumowanie

Umowa wdrożeniowa IT powinna być przede wszystkim instrukcją realizacji projektu. Nie wystarczy w niej wskazać systemu, ceny i terminu końcowego.

Kluczowe znaczenie mają jednoznaczny zakres, hierarchia dokumentów, harmonogram, obowiązki współdziałania i obiektywne kryteria odbioru. Procedura odbiorowa powinna rozróżniać wady krytyczne od drobnych usterek, określać czas na testy oraz konsekwencje odbioru częściowego, warunkowego i końcowego.

Change request powinien pozwalać kontrolować zmiany zakresu, kosztu i terminu. Chroni wykonawcę przed scope creep, a klienta przed nieprzewidywalnymi fakturami.

SLA musi opierać się na mierzalnych parametrach. Należy odróżnić czas reakcji, przywrócenia i trwałej naprawy, określić godziny wsparcia oraz sposób pomiaru dostępności.

Kary umowne powinny zabezpieczać najważniejsze zobowiązania niepieniężne i pozostawać proporcjonalne. Umowa powinna wskazywać ich podstawę, limit, zasady kumulowania oraz możliwość dochodzenia odszkodowania ponad karę.

Nie można pominąć obowiązków klienta. Opóźnienie w przekazaniu danych, podjęciu decyzji albo zapewnieniu infrastruktury może wpłynąć na harmonogram i odpowiedzialność wykonawcy.

Dobrze przygotowana umowa nie eliminuje wszystkich problemów technicznych, ale pozwala szybko ustalić, jak należy na nie zareagować. W projekcie IT jest to często ważniejsze niż najbardziej rozbudowane ogólne deklaracje o współpracy i należytej staranności.