Zabezpieczenie wykonania umowy wdrożeniowej IT. Poradnik dla software house’ów #19

Każdej ze stron umowy wdrożeniowej zazwyczaj zależy na tym aby realizowany projekt się udał. Powodzeniem projektu w tym wypadku jest podpisanie przez zamawiającego końcowego protokołu odbioru i zapłata całości wynagrodzenia wykonawcy. W klasycznych umowach wdrożeniowych stosuje się jednak różnego rodzaju zabezpieczenia. Większość z nich wymagana jest przez zamawiającego, jednak są i takie, które powinny zwrócić uwagę wykonawców. Oczywiście poprzez zabezpieczenie prawnicy najczęściej rozumieją takie instrumenty jak wystawienie weksla lub przedstawienie gwarancji bankowej. W branży IT jest to jednak niezwykle rzadka sytuacja. Do kwestii zabezpieczenia można podejść także czysto organizacyjnie a nie jedynie poprzez wystawianie zabezpieczeń w formie jakiegoś dokumentu.

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.

Rozliczenie częściowe

Z punktu widzenia wykonawcy rozliczanie częściowe może być traktowane jako rodzaj zabezpieczenia. Dzięki rozliczeniom zaraz po wykonaniu każdego etapu wykonawca zapewnia sobie płynność finansową i nie musi “kredytować” zamawiającego.

Płatności powiązane z kamieniami milowymi (milestone payments) są szczególnie korzystne dla software house’ów, ponieważ eliminują potrzebę długoterminowego finansowania projektu z własnych środków. System ten redukuje stres finansowy związany z długimi okresami oczekiwania na płatność i pozwala na lepszą kontrolę nad przepływem gotówki. Co istotne, płatności etapowe pełnią także funkcję wyrafinowanego mechanizmu podziału ryzyka – strategicznie wykorzystują interes finansowy klienta do wspierania jego aktywnego zaangażowania, terminowego przekazywania informacji zwrotnych i przestrzegania harmonogramów projektu.

Odpowiedzialność za powodzenie projektu jest wtedy niejako rozłożona na dwa podmioty. Zamawiający przy płatnościach częściowych zwykle bardziej angażuje się w projekt. Z drugiej strony, jeśli np. w połowie projektu dojdzie do sporu to z punktu widzenia wykonawcy, lepiej jest się bronić (lub atakować), posiadając już część należnego wynagrodzenia.

Aby rozliczenia częściowe były skuteczne, umowa musi precyzyjnie definiować każdy kamień milowy i powiązane z nim dostarczalne. Kluczowe jest jasne określenie harmonogramu płatności, procedur przeglądu i akceptacji poszczególnych etapów oraz konsekwencji za niedotrzymanie terminów lub standardów jakości. Każdy kamień milowy powinien być mierzalny i zawierać szczegółowy opis zakresu prac. Praktyka pokazuje, że wskazane jest wymaganie zaliczki na początku dużych projektów – zabezpiecza to wykonawcę przed ryzykiem utraty płynności.

Software house’y powinny także rozważyć automatyzację procesów fakturowania i wysyłania przypomnień o płatnościach, co znacznie usprawnia zarządzanie finansami.

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

Depozyt kodu źródłowego

Kolejnym rodzajem zabezpieczenia jest złożenie kodu źródłowego do depozytu. Takie rozwiązanie często proponują zamawiający. Jest to zabezpieczenie na wypadek gdyby dostawca danego programu komputerowego np. zakończył działalność, ogłosił upadłość lub odmówił usunięcia awarii.

Depozyt taki można ustanowić np. w banku lub u notariusza. Depozyt powinien być ustanowiony na podstawie umowy depozytowej, która jasno wskaże kiedy taki depozyt może być wydany zamawiającemu. W praktyce coraz częściej wykorzystuje się wyspecjalizowanych agentów depozytowych (escrow agents), którzy posiadają odpowiednie doświadczenie techniczne i prawne. Depozyt kodu źródłowego to umowa trójstronna między dostawcą oprogramowania (deponentem), klientem (beneficjentem) oraz niezależnym agentem depozytowym. Choć jest to przede wszystkim zabezpieczenie dla klienta, paradoksalnie dobrze zarządzany i zweryfikowany proces depozytowy znacząco wzmacnia reputację software house’u i buduje zaufanie, potencjalnie prowadząc do zwiększonych możliwości biznesowych.

Warunki wydania (release conditions) muszą być precyzyjnie określone i niezależnie weryfikowalne przez agenta depozytowego. Typowe warunki to: bankructwo lub niewypłacalność dostawcy, zaprzestanie wsparcia dla oprogramowania, istotne naruszenie umowy licencyjnej lub wsparcia. Należy unikać zbyt ogólnych sformułowań, które mogą być trudne do jednoznacznej interpretacji.

Z punktu widzenia zamawiającego warto zwrócić uwagę na to, że niewystarczające jest złożenie nośnika (np. dysku przenośnego) zawierającego jedynie kod źródłowy. Do depozytu musi być złożona także dokumentacja kodu źródłowego oraz wszelkie dane umożliwiające kompilację kodu źródłowego.

Software house powinien pamiętać o kilku kluczowych elementach minimalizujących ryzyko. Po pierwsze, należy wprowadzić do umowy klauzulę dającą wykonawcy określony czas na usunięcie naruszenia przed faktycznym wydaniem kodu (cure period). Po drugie, umowa depozytowa powinna zawierać rygorystyczne postanowienia dotyczące poufności oraz ograniczenia użytkowania wydanego kodu przez beneficjenta wyłącznie do celów wewnętrznych, z zakazem kopiowania lub rozpowszechniania. Po trzecie, software house powinien zachować wszelkie prawa własności do zdeponowanych materiałów, a licencja dla beneficjenta powinna aktywować się tylko w przypadku faktycznego wydania kodu z depozytu. Częstotliwość aktualizacji depozytu powinna być powiązana z cyklem wydawniczym oprogramowania, a najlepiej zautomatyzowana poprzez integrację z systemami kontroli wersji.

Kary umowne

Bardzo popularnym rozwiązaniem stosowanym przez zamawiających w umowach wdrożeniowych są kary umowne.

Zgodnie z Kodeksem cywilnym można zastrzec w umowie, że naprawienie szkody wynikłej z niewykonania lub nienależytego wykonania zobowiązania niepieniężnego nastąpi przez zapłatę określonej sumy (art. 483 KC). Kary umowne najbezpieczniej jest ustalać kwotowo lub poprzez wskazanie wzoru i podstawy wyliczania takiej kary.

“Jeżeli strony nie ustalą w umowie wprost kwoty kary umownej, to powinny wprowadzić taki miernik jej wyliczenia, aby chodziło jedynie o dokonanie w przyszłości (gdy zajdą przesłanki naliczenia tej kary) działania o charakterze wyłącznie arytmetycznym, bez konieczności ustalenia podstawy, od której będzie uzależniona wysokość kary umownej. W przeciwnym razie postanowienie umowne będzie nieważne, jako sprzeczne z art. 483 § 1 KC” (wyrok SN z dnia 3 października 2019 r., I CSK 280/18).

Kara umowna nie może być także naliczana bez limitu.

“Nie określenie w umowie końcowego terminu naliczania kar umownych ani ich kwoty maksymalnej, prowadzi do obciążenia zobowiązanego tym świadczeniem w nieokreślonym czasie, a więc w istocie tworzy zobowiązanie wieczne, niekończące się. Takie ukształtowanie zobowiązania zapłaty kary umownej, nie spełnia należącego do jego istoty wynikającego z art. 483 § 1 k.c. wymagania określenia sumy pieniężnej podlegającej zapłacie w związku z niewykonaniem lub nienależytym wykonaniem zobowiązania niepieniężnego. Wymóg ten jest spełniony, gdy strony z góry określają wysokość kary umownej, albo gdy w treści umowy wskazują podstawy do definitywnego określenia jej wysokości” (wyrok SN z dnia 22 października 2015 r., IV CSK 687/14).

Warto pamiętać, że zgodnie z art. 484 KC, kara umowna należy się wierzycielowi w zastrzeżonej wysokości bez względu na wysokość poniesionej szkody, chyba że strony inaczej postanowiły. Jednocześnie przepis ten przewiduje możliwość miarkowania kary umownej przez sąd, jeśli zobowiązanie zostało w znacznej części wykonane lub gdy kara jest rażąco wygórowana. Software house’y powinny negocjować kary umowne tak, aby ich wysokość była proporcjonalna do rzeczywistej, przewidywalnej szkody, a nie miała charakteru czysto karnego. Strategią obronną jest także powiązanie kar umownych z jasno zdefiniowanymi i mierzalnymi metrykami w umowach Service Level Agreement (SLA), takimi jak czas dostępności systemu czy czas reakcji na zgłoszenia.

Przykłady kar umownych stosowanych przez zamawiających:

1. kara za odstąpienie od umowy z winy wykonawcy,
2. kara za opóźnienie lub zwłokę,
3. kara za opóźnienia w realizacji warunków SLA,
4. kara za brak konkretnego pracownika po stronie wykonawcy.

Sprawdź również: Kary umowne w IT – co trzeba wiedzieć?

Moment przeniesienia autorskich praw majątkowych do oprogramowania

Klauzula przeniesienia autorskich praw majątkowych rzadko wykorzystywana jest do zabezpieczenia interesów wykonawcy. Podchodzi się do niej czysto technicznie. Natomiast wykonawca może ją skonstruować z korzyścią dla siebie zabezpieczając wypłatę wynagrodzenia.

Klauzula ta powinna oznaczać moment ich przeniesienia z wykonawcy na zamawiającego. Wykonawca powinien dążyć do tego aby tym momentem był moment zapłaty wynagrodzenia. Zamawiającemu zależy na tym aby szybko zacząć komercyjnie wykorzystywać stworzony program komputerowy. Zwiększa to prawdopodobieństwo terminowej płatności wynagrodzenia lub jego części.

Przeniesienie praw własności intelektualnej może być wykorzystane jako strategiczny mechanizm zabezpieczający płatność. Umowa powinna zawierać wyraźną klauzulę warunkową, która jasno stanowi, że własność intelektualna (w tym prawa autorskie do kodu źródłowego i dokumentacji) przechodzi na klienta dopiero po otrzymaniu pełnej płatności za projekt.

Taka konstrukcja daje software house’owi znaczącą dźwignię negocjacyjną – klient, aby móc komercyjnie wykorzystać oprogramowanie, musi najpierw uregulować wszystkie należności. Jest to silny bodziec do terminowej płatności, chroniący software house przed ryzykiem niezapłaconych faktur.

Należy precyzyjnie określić zakres przenoszenia praw (np. prawa majątkowe, licencje) oraz rozważyć, czy w danym projekcie bardziej odpowiednie jest przeniesienie pełnych praw autorskich, czy udzielenie licencji.

Licencjonowanie pozwala wykonawcy zachować własność IP, jednocześnie umożliwiając klientowi korzystanie z oprogramowania na określonych warunkach.

Zabezpieczenia w umowach wdrożeniowych w reżimie prawa zamówień publicznych

Jeśli umowa wdrożeniowa zawierana jest przez podmiot publiczny na podstawie przepisów prawa zamówień publicznych to możesz spodziewać się także bardziej standardowych zabezpieczeń.

Przykładowo umowa może zobowiązywać wykonawcę do ustanowienia zabezpieczenia należytego wykonania umowy w wysokości konkretnej procentowej wysokości ceny zaoferowanej w postępowaniu poprzedzającym zawarcie Umowy.

Zabezpieczenie wnoszone jest zazwyczaj w formie pieniężnej lub gwarancji bankowej. Zamawiający w takim wypadku musi zwrócić/zwolnić zabezpieczenie w konkretnym terminie po odbiorze przedmiotu umowy wdrożeniowej. Zwrot może odbywać się także okresowo.

W kontekście zamówień publicznych software house’y mogą wybierać między różnymi formami zabezpieczeń. Gwarancje bankowe, choć kosztowne (wiążą się z opłatami bankowymi), pozwalają na utrzymanie płynności finansowej, ponieważ środki wykonawcy nie są zamrażane jak w przypadku kaucji pieniężnej.

Alternatywą są gwarancje ubezpieczeniowe (performance bonds), które stanowią umowę trójstronną między wykonawcą, beneficjentem i poręczycielem. Wybór formy zabezpieczenia powinien uwzględniać sytuację finansową software house’u, wielkość projektu oraz koszty związane z daną formą zabezpieczenia. Dla mniejszych podmiotów bariera wejścia związana z uzyskaniem gwarancji może być znacząca, co należy uwzględnić już na etapie przygotowywania oferty przetargowej.

Dodatkowo, w umowach publicznych często stosuje się klauzulę retencji, polegającą na wstrzymaniu określonego procentu płatności (zazwyczaj 10-30%) do momentu zakończenia wszystkich prac i usunięcia ewentualnych usterek.

Software house’y powinny negocjować niższy procent retencji, precyzyjne warunki jej zwolnienia (np. połowa po odbiorze końcowym, reszta po zakończeniu okresu odpowiedzialności za wady) oraz rozważyć powiązanie retencji z akceptacją poszczególnych kamieni milowych zamiast całości projektu.

Warto także wprowadzić klauzule określające konsekwencje dla zamawiającego w przypadku opóźnień w zwolnieniu retencji, co zabezpiecza interesy wykonawcy.