Umowa wdrożeniowa na system IT – odbiór, zarządzanie projektem, wynagrodzenie, odpowiedzialność

Niniejszy artykuł stanowi drugi z serii artykułów poświęconych tematyce umów wdrożeniowych. Zostaną w nim omówione zagadnienia związane z odbiorem prac, zarządzaniem projektem, wynagrodzeniem oraz zasadami odpowiedzialności.

Odbiór prac

Umowa wdrożeniowa może przewidywać jednorazowy odbiór przedmiotu prac po zakończeniu projektu, bądź  kilka odbiorów po zakończeniu poszczególnych etapów. Podstawowym celem odbioru jest potwierdzenie należytego wykonania prac. W przypadku projektów programistycznych, z reguły będzie to wymagało przeprowadzenia testów oprogramowania przez techników zamawiającego. Strony powinny oszacować czas trwania testów i uwzględnić go w harmonogramie. Dodatkowo, odbiór może pełnić również inne funkcje, np. warunkować uruchomienie płatności lub rozpoczęcie kolejnego etapu prac. W tym ostatnim przypadku warto przewidzieć możliwość przejścia do kolejnego etapu, mimo istnienia pewnych zastrzeżeń do prac podlegających odbiorowi. W tym celu, w praktyce często dokonuje się odbiorów cząstkowych, które obejmują jedynie tę część prac, co do której zamawiający nie wniósł zastrzeżeń. Innym rozwiązaniem jest dokonanie odbioru z zastrzeżeniami. Należy wówczas precyzyjnie określić zakres nieprawidłowości oraz wskazać wykonawcy termin na ich usunięcie. Po upływie tego terminu prace powinny podlegać ponownemu odbiorowi. Odbiór prac powinien zostać udokumentowany przez strony w formie protokołu odbioru. Za wskazane należy uznać również potwierdzenie odmowy odbioru prac wraz z określeniem przyczyny takiej decyzji.

Zarządzanie projektem

Strony umowy wdrożeniowej powinny zadbać, aby łączący je kontrakt zawierał reguły zarządzania wdrożeniem oraz wymiany informacji. Zakłócenia w przepływie informacji lub niejasny tryb uzgodnień mogą skutkować nie tylko fiaskiem projektu, ale w skrajnych przypadkach nawet sporem sądowym. W związku z powyższym jako dobrą praktykę należy wskazać powołanie kierowników projektu oraz sporządzanie przez strony protokołów uzgodnień. Kierownicy projektów to wyznaczeni w umowie przedstawiciele stron odpowiedzialni za współpracę stron w ramach projektu. Do zadań kierowników projektu może należeć np. utrzymywanie bieżącego kontaktu z drugą stroną, w tym odbiór korespondencji, udzielanie wyjaśnień drugiej stronie oraz jej personelowi, podpisywanie protokołów odbioru, składanie oświadczeń woli w imieniu stron. W przypadku większych projektów zasadnym może okazać się powołanie komitetu sterującego tj. gremium złożonego z przedstawicieli obydwu stron, uprawnionego do podejmowania najważniejszych decyzji związanych z projektem.

Protokół uzgodnień powinien stanowić zapis kluczowych decyzji i czynności podejmowanych w ramach projektu, np. strony mogą w nim opisać szczegóły rozwiązań lub zmiany oprogramowania, których potrzeba wprowadzenia pojawiła się w trakcie realizacji prac. W takiej sytuacji protokół będzie stanowić potwierdzenie, że strony zgodziły się na zmianę lub rozszerzenie przedmiotu umowy. Ponadto, za rozsądną praktykę należy uznać opisywanie w umowie tzw. procedury zarządzania zmianą, tj. postępowania pozwalającego stronom na zmianę przedmiotu umowy bez potrzeby jej aneksowania.

Wynagrodzenie

W zależności od charakteru projektu informatycznego umowa wdrożeniowa może posługiwać się różnymi modelami wynagrodzenia. Do najczęściej spotykanych modeli należą:

• fixed price – z góry określona wysokość wynagrodzenia za wykonanie prac przewidzianych umową;
• time&materials – wynagrodzenie jako iloczyn stawki godzinowej oraz faktycznie przepracowanych godzin;
• modele mieszane – łączące elementy powyższych rozwiązań, np. za prace wymienione w umowie wynagrodzenie określone z zastosowaniem modelu fixed price, natomiast za prace dodatkowe (incydentalne) wynagrodzenie obliczone w oparciu o wariant time&materials.

Model wynagrodzenia zwykle wynika z charakteru zawartej umowy. W przypadku umowy o dzieło najczęściej spotykany będzie model fixed price. Przy umowach o świadczenie usług zwykle zastosowanie znajdzie model time&materials, natomiast  dla umów mieszanych najczęściej będziemy mieli do czynienia  z modelem mieszanym, np. elementy noszące znamiona dzieła będą wiązać się z wynagrodzeniem fixed price natomiast świadczenia stanowiące zlecenie wynagradzane będą w oparciu o model time&materials.

Odpowiedzialność

Z uwagi na szeroki zakres zagadnienia, należy w tym miejscu zwrócić uwagę na wybrane kwestie związane z odpowiedzialnością stron umowy wdrożeniowej. Szersze omówienie tej tematyki znajdą Państwo w prezentacji dostępnej pod adresem https://jciw.pl/artykuly/wynagrodzenie-zasady-odpowiedzialnosci-webinarium/.

Przy sporządzaniu umowy szczególnie istotne jest precyzyjne zdefiniowanie błędu/usterki oprogramowania. Oprócz opóźnienia w realizacji projektu, zastrzeżenia dotyczące funkcjonowania programu stanowią najczęstszą podstawę odpowiedzialności wykonawcy. Wzmożonej uwagi stron wymagają również zapisy dotyczące kar umownych. W praktyce system kar umownych może być ukształtowany w różnoraki sposób i zależy przede wszystkim od uwarunkowań natury biznesowej. Tytułem przykładu można wskazać kary umowne ustalone ryczałtowo, które będą uzasadnione w przypadku jednorazowych naruszeń, np. obowiązku zachowania poufności. W przypadku kar umownych za zwłokę często spotyka się kary naliczane za każdy dzień zwłoki według określonej stawki dziennej. Kolejnym zagadnieniem o znacznej doniosłości są klauzule ograniczające odpowiedzialność stron. Limitacja odpowiedzialności może dotyczyć określonego rodzaju szkód, np. wyłączenie odpowiedzialności za utracone korzyści, jak również szkód powstałych wskutek wystąpienia wskazanych w umowie okoliczności, np. nieprawidłowego działania infrastruktury informatycznej zamawiającego. Warto zasygnalizować także tematykę rękojmi oraz gwarancji na oprogramowanie. Rękojmia stanowi szczególny rodzaj odpowiedzialności za wady fizyczne lub prawne przedmiotu umowy. Uprawnienia z tytułu rękojmi, np. oświadczenie o obniżeniu ceny z powodu występowania wady lub oświadczenie o odstąpieniu od umowy, przysługują zamawiającemu z mocy ustawy. Tymczasem gwarancja stanowi oświadczenie gwaranta (najczęściej jest nim wykonawca), w którym określone są obowiązki gwaranta i uprawnienia zamawiającego na wypadek, gdyby oprogramowanie nie miało właściwości określonych w tym oświadczeniu. Co istotne, uprawnienia z tytułu rękojmi i gwarancji mogą być wykonywane przez zamawiającego równocześnie. Strony mogą również postanowić o wyłączeniu uprawnień z tytułu rękojmi. Takie wyłączenie nie jest jednak dopuszczalne, jeżeli stroną umowy jest konsument w rozumieniu przepisów Kodeksu cywilnego.

Zakończenie

Oba artykuły poświęcone problematyce umowy wdrożeniowej opublikowane na naszej stronie z pewnością nie wyczerpują zbioru zagadnień istotnych z punktu widzenia tej umowy. Zapewne również każdy z przedstawionych tutaj tematów mógłby  stanowić przedmiot odrębnego artykułu. Niemniej jednak warto pamiętać, że nawet najbardziej szczegółowy opis modelu nie jest w stanie zastąpić analizy konkretnego przypadku, w szczególności zaś jego biznesowych uwarunkowań. Dostosowanie kontraktu do indywidualnych potrzeb stanowi jedną z przesłanek pomyślnego zakończenia projektu, dlatego negocjując umowę należy unikać dróg na skróty, w szczególności zaś szablonowych rozwiązań.