Skip to main content

Klasyczna umowa wdrożeniowa jest umową o dzieło. Regulacje dotyczące tej szczególnej umowy cywilnoprawnej znajdziesz w Kodeksie cywilnym. Z pierwszego przepisu dotyczącego umowy o dzieło dowiadujemy się, że należy oznaczyć dzieło. Odnosząc to do umowy wdrożeniowej oznacza to, że powinno się wskazać jaki program komputerowy ma zostać wykonany. Oznaczenie najczęściej w tym przypadku dokonywane jest poprzez stworzenie specyfikacji technicznej. Precyzyjne określenie przedmiotu umowy poprzez szczegółową specyfikację jest absolutnie fundamentalne dla powodzenia projektu. Doświadczenie praktyczne pokazuje, że nieprecyzyjne kontrakty, zwłaszcza te oparte na uproszczonych wzorach, często prowadzą do licznych nieporozumień i konfliktów. Niejasno zdefiniowana specyfikacja jest jedną z głównych przyczyn opóźnień w projektach software’owych i późniejszych sporów. Drugim elementem umowy wdrożeniowej istotnym dla zamawiającego – po ustaleniu co ma zostać wykonane – jest termin wykonania prac.

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.

Charakter terminu w umowie wdrożeniowej

Umowa o dzieło co prawda jest umową terminową ale w odróżnieniu od umowy zlecenia (np. umowy o świadczenie usług programistycznych) nie jest zobowiązaniem ciągłym, z ew. możliwością wypowiedzenia. Umowa wdrożeniowa zawsze ma swój początek i koniec. Co ważne umowa o dzieło nie jest umową zawartą na czas określony. Jest raczej rodzajem umowy terminowej.

“(…) z istoty umowy o dzieło wynika, że strony muszą przewidzieć upływ pewnego czasu na wykonanie zamówienia; z tej perspektywy umowa o dzieło nie może być jednak określana jako typowa umowa zawarta na czas określony, ale jako rodzaj umowy terminowej.” (Wyrok Sądu Apelacyjnego w Białymstoku z dnia 18 czerwca 2013 r., I ACa 232/13) 

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

  • Umowa na wdrożenie systemu informatycznego [PL/ENG]
    Wybierz opcje Ten produkt ma wiele wariantów. Opcje można wybrać na stronie produktu Quick View

    Umowa na wdrożenie systemu informatycznego [PL/ENG]

    599,00 799,00  (z VAT)
  • Promocja!
    Pakiet wzorów umów dla software house’u/firmy IT [PL/EN]
    Wybierz opcje Ten produkt ma wiele wariantów. Opcje można wybrać na stronie produktu Quick View

    Pakiet wzorów umów dla software house’u/firmy IT [PL/EN]

    1199,00 1999,00  (z VAT)

    Ostatnia najniższa cena przed zastosowaniem obniżki ceny: 1199,00 .

Jak to wygląda w praktyce?

Umowa wdrożeniowa przewiduje zazwyczaj termin końcowy oraz terminy pośrednie. O terminach pośrednich przeczytasz w artykule dotyczącym harmonogramu. Zazwyczaj terminy pośrednie są terminami instrukcyjnymi i ich przekroczenie nie ma dotkliwych skutków. Oczywiście strony w umowie mogą postanowić inaczej.

Chociaż terminy pośrednie są domyślnie instrukcyjne, ich wyraźne określenie jako wiążących i powiązanie z nimi konkretnych konsekwencji (np. kar umownych, prawa do interwencji zamawiającego) przekształca je w potężne narzędzia zarządzania projektem i mitygacji ryzyka. Ustanawianie punktów odniesienia i kamieni milowych w umowach na rozwój oprogramowania jest niezwykle ważne dla mierzenia postępu i dostosowywania celów projektu.

Procedury odbiorów częściowych, często powiązane z tymi pośrednimi kamieniami milowymi, zwiększają kontrolę zamawiającego nad projektem i umożliwiają wczesne zgłaszanie uwag, co znacząco zmniejsza ryzyko rozczarowania na etapie odbioru końcowego.

Sprawdź również: Jak powinna wyglądać procedura odbioru oprogramowania?

Najważniejszy jest jednak termin końcowy. Przez termin końcowy oddania oznaczonego dzieła (programu komputerowego) uznaje się zazwyczaj dzień, w którym zamawiający mógł zapoznać się z całością prac i przystąpić do fazy testowania po swojej stronie.

Dlaczego to takie ważne? Termin końcowy jest punktem odniesienia zarówno dla wykonawcy jak i dla zamawiającego.

Jeżeli wykonawca opóźnia się z rozpoczęciem lub wykończeniem dzieła tak dalece, że nie jest prawdopodobne, żeby zdołał je ukończyć w czasie umówionym, zamawiający może bez wyznaczenia terminu dodatkowego od umowy odstąpić jeszcze przed upływem terminu do wykonania dzieła (art. 635 Kodeksu cywilnego).

Kluczowe jest tutaj rozróżnienie między „opóźnieniem” a „zwłoką”. Artykuł 635 KC odnosi się do „opóźnienia”, które oznacza niedotrzymanie terminu niezależnie od tego, czy wykonawca ponosi za to winę. To fundamentalne rozróżnienie obniża próg dla zamawiającego do odstąpienia od umowy – może on to zrobić nawet gdy opóźnienie wynika z nieprzewidzianych trudności technicznych czy problemów z dostawcami zewnętrznymi.

Interpretacja pojęcia „nieprawdopodobieństwa ukończenia dzieła w terminie” w orzecznictwie sądowym koncentruje się na obiektywnej, wysokiej niemożności wykonania dzieła. Software house nie może polegać wyłącznie na „dobrych chęciach” czy „należytej staranności”, jeśli obiektywny postęp prac jest niewystarczający.

Sprawdź również: Zwłoka a opóźnienie w umowach IT – czym się różnią?

Skutkiem odstąpienia od umowy na podstawie art. 635 KC jest uznanie umowy za „niebyłą”, czyli taką, która nigdy nie została zawarta. Prowadzi to do konieczności wzajemnego zwrotu świadczeń przez obie strony. Dodatkowo, zamawiający może domagać się naprawienia szkody, którą poniósł w wyniku niedotrzymania terminu wykonania dzieła. Ten retroaktywny skutek odstąpienia jest poważną konsekwencją dla software house’u – cała wartość projektu może zostać utracona, a wszystkie otrzymane płatności mogą podlegać zwrotowi.

Z drugiej strony wykonawca powinien mieć prawo do przesunięcia terminu końcowego oddania prac w sytuacji gdy do opóźnienia doszło w sposób przez niego niezawiniony. W tym miejscu odsyłam Cię do artykułu dotyczącego współdziałania.

W kontekście umów wdrożeniowych IT, współdziałanie zamawiającego jest wręcz niezbędne do prawidłowej realizacji projektu. Mimo że polskie prawo cywilne zakłada obowiązek współdziałania, kluczowe jest jego wyraźne i precyzyjne określenie w umowie.

Software house’y powinny dążyć do włączenia do umowy szczegółowej listy obowiązków klienta, wraz z terminami odpowiedzi na zapytania, dostarczania danych, zapewnienia dostępu do systemów czy dostępności kluczowego personelu. Jeśli zamawiający nie współdziała, software house może wyznaczyć mu odpowiedni termin na podjęcie współdziałania, z zagrożeniem odstąpienia od umowy po jego bezskutecznym upływie (art. 640 KC).

Warto również rozważyć włączenie do umowy klauzuli siły wyższej, która zwolni strony z odpowiedzialności za niewykonanie zobowiązań w wyniku nieprzewidywalnych i niemożliwych do uniknięcia zdarzeń. W branży IT takimi zdarzeniami mogą być poważne awarie infrastruktury, rozległe cyberataki wpływające na świadczenie usług czy nagłe zmiany regulacyjne.

Dobrze sformułowana klauzula siły wyższej jest niezbędna dla software house’ów, aby chronić się przed odpowiedzialnością za opóźnienia spowodowane zdarzeniami, które są faktycznie poza ich kontrolą.

Dodatkowo precyzyjne wskazanie terminu oddania programu komputerowego zamawiającemu może mieć istotne znaczenie z punktu widzenia terminu zapłaty wynagrodzenia. Zgodnie z art. 642 Kodeksu cywilnego “w braku odmiennej umowy przyjmującemu zamówienie należy się wynagrodzenie w chwili oddania dzieła.”

Jeśli dzieło ma być oddawane częściami, wynagrodzenie należy się z chwilą spełnienia każdego ze świadczeń częściowych. W celu zabezpieczenia interesów software house’u, zaleca się powiązanie momentu przeniesienia praw własności intelektualnej do oprogramowania lub udzielenia licencji z momentem odbioru bez zastrzeżeń, a optymalnie – z momentem zapłaty wynagrodzenia.

Powiązanie warunków płatności bezpośrednio z jasno zdefiniowanymi i sformalizowanymi kamieniami milowymi odbioru jest najskuteczniejszym sposobem na zapewnienie stałego przepływu środków pieniężnych i zminimalizowanie ryzyka braku lub opóźnienia płatności.

Najczęstsze przyczyny opóźnień w projektach software’owych, na które software house powinien być przygotowany, to: słabo zdefiniowane wymagania i częste zmiany w specyfikacji, niewystarczające planowanie, nadmiernie optymistyczne szacunki czasowe, utrata kluczowych członków zespołu deweloperskiego, powolne podejmowanie decyzji i zatwierdzeń przez klienta, oraz wąskie gardła związane z integracjami z systemami stron trzecich.

Większość z tych przyczyn można skutecznie mitygować poprzez odpowiednie klauzule umowne, szczególnie dotyczące zarządzania zmianą, współdziałania klienta oraz procedur odbioru. Kary umowne są powszechnym sposobem zabezpieczenia wykonania umowy, jednak źle sformułowane klauzule mogą być uznane za rażąco wygórowane, co prowadzi do ich „miarkowania” przez sądy.

W przypadku sporów dotyczących terminów i opóźnień, warto rozważyć włączenie do umowy klauzuli arbitrażowej. Arbitraż może zapewnić znacznie szybsze rozstrzygnięcie sporów (średnio 6-12 miesięcy) w porównaniu z tradycyjnymi postępowaniami sądowymi.

Potrzebujesz wsparcia prawnika rozumiejącego branżę IT? Napisz do mnie!



    Łukasz Kulicki

    Radca prawny w Kancelarii After Legal specjalizującej się w obsłudze prawnej firm z sektora IT, nowych technologii i branży internetowej, a także podmiotów przechodzących transformację cyfrową. Specjalizuje się w negocjowaniu umów IT, w szczególności umów wdrożeniowych, umów na usługi IT (w tym chmurowych) i umów body leasingowych. Zajmuje się także doradztwem prawnym z zakresu ochrony danych osobowych (RODO), prawa e-commerce i własności intelektualnej.

    0
      0
      Koszyk
      Twój koszyk jest pustyWróć do sklepu