Wśród danych

Blog dla przedsiębiorców działających w cyfrowym świecie

  • Michał Nosowski

Umowa wdrożeniowa - co warto do niej wpisać?

Aktualizacja: kwi 11


komputer, na którym pisze się program

Rozpoczęcie korzystania ze złożonego rozwiązania informatycznego to ambitny projekt dla każdej organizacji. Wymaga on zaangażowania dobrego zespołu, sporej ilości kasy, czasu i dobrej współpracy pomiędzy firmą IT, która takie wdrożenie prowadzi, a jej klientem. A to prowadzi nas do wniosku, że ważnym elementem takiej współpracy będzie uregulowanie jej w dobrej, możliwie precyzyjnej umowie wdrożeniowej.


Czym dokładnie jest taka umowa wdrożeniowa?


Umowa wdrożeniowa to prawnie wiążący dokument, który reguluje prawa i obowiązki dwóch podmiotów:

  • organizacji, która chce mieć nowe rozwiązanie IT (np. jakiś system ERP),

  • wykonawcy, który takie rozwiązanie tworzy/dostosowuje, uruchamia, konfiguruje, testuje i ogólnie rzecz biorąc, wspiera organizację w całym procesie.

I taka umowa może stanowić fundament współpracy obu stron, które biorą udział w projekcie, przez kilka miesięcy albo nawet lat. Dlatego też lepiej jest napisać ją dobrze.


Jak pewnie się domyślasz, takie umowy generalnie są dość skomplikowane. I często są niestety bardzo jednostronne, tzn. stworzone wyłącznie na korzyść tej strony, który ją napisała.


Zdarzają się tak abstrakcyjne sytuacje, że zamawiający (tzn. klient, który ma korzystać z nowego oprogramowania u siebie) sam wyznacza zakres prac, cenę i termin – a wykonawcy pozostaje tylko działać tak jak zamawiający mu powie. Pomijając już kwestie niezgodności takiej umowy z przepisami prawa, tego rodzaju ustalenia po prostu nie wróżą dobrej współpracy – i jest duże ryzyko, że na końcu obie strony takiej umowy zostaną ze sporami sądowymi i niedokończonym projektem.





Umowy wdrożeniowe są zwykle dość specyficznymi i rozbudowanymi umowami o dzieło. Zakładają one więc, że wykonawca bierze odpowiedzialność za rezultat projektu - tzn. powinien skutecznie doprowadzić wdrożenie do końca. Oczywiście nie wyklucza to konieczności współpracy po stronie zamawiającego (klienta). Istnieją też poglądy, że taka umowa wdrożeniowa może być umową o świadczenie usług - zwłaszcza w sytuacji gdy duża część wdrożenia jest niezależna od wykonawcy i opiera się na działaniach zamawiającego albo jeszcze innych osób.


Najczęściej jednak umowy wdrożeniowe to umowy o dzieło - taki jest standard i potwierdza to orzecznictwo sądów (acz niejednolite). Stąd też stwierdziłem, że napiszę kilka słów na temat tego co w takiej umowie powinno znaleźć.


Zakres prac i obowiązków stron, sposób współpracy


Kluczowym elementem umów wdrożeniowych jest opisanie tego, w jaki sposób strony będą ustalały to co powinno zostać zrobione przez wykonawcę. I tu od razu mamy pierwszy, specyficzny element takich umów – w momencie ich podpisywania często nie ma jeszcze szczegółowych informacji na temat tego w jaki sposób będzie przebiegał projekt i co dokładnie zostanie wykonane.


Bywa bowiem tak, że na tym etapie mamy jedynie jakiś ogólny zarys, przygotowany przez klienta, który może mniej więcej opisać czego potrzebuje i jakie są jego wymagania. Nie jest jednak wykluczone, że w trakcie realizacji wdrożenia dojdzie do modyfikacji tych założeń.


Dlatego też w umowach wdrożeniowych raczej nie opisuje się precyzyjnie tego co ma być wykonane. Ewentualne wymogi klienta mogą zostać dołączone do umowy jako załącznik. Sama umowa zawiera jednak zasady dotyczące współpracy stron, w tym takie informacje jak:

  • to w jaki sposób wykonawca (podmiot dokonujący wdrożenia) powinien dokonać analizy szczegółowych wymagań dotyczących wdrażanego rozwiązania i co powinien wziąć pod uwagę w tym procesie,

  • jaki ma być ogólny rezultat prac wykonawcy,

  • kto odpowiada za dostarczenie infrastruktury IT, udzielenie dostępów itp. (z reguły będzie to zamawiający),

  • jakich dodatkowych informacji powinien udzielić zamawiający na rzecz wykonawcy,

  • w jaki sposób przekazywane będą efekty prac wykonawcy – np. poprzez uruchomienie ich w ramach środowisk zamawiającego oraz zamieszczenie w repozytorium kodu,

  • kto odpowiedzialny jest za integrację oprogramowania z innymi elementami infrastruktury IT zamawiającego (np. robi to wykonawca, acz zamawiający zapewnia odpowiednie współdziałanie),

  • jaka dokumentacja i analizy dot. projektu zostaną stworzone przez wykonawcę, można w umowie opisać również standardy jakie ta dokumentacja powinna spełniać.

Nie ma przeszkód aby w umowie wprost napisać, że transparentność i przekazywanie sobie informacji jest kluczem do prawidłowej realizacji wdrożenia. Dlatego też strony powinny ściśle współdziałać i udzielać sobie wyczerpujących wyjaśnień. Często uświadomienie klientowi tego już na etapie zawierania umowy jest kluczowe dla późniejszego wdrożeniowego sukcesu. Nie ma bowiem nic gorszego niż zamawiający, który czeka z założonymi rękoma aż „wykonawca zrobi wszystko” i będzie koniec.



programowanie w słuchawkach


Podział na etapy/prace


Wdrożenie rozwiązań IT jest z reguły podzielone na kilka etapów, które są podzielone na mniejsze prace, np. w ramach tygodniowych/dwutygodniowych (albo innych, jeśli strony tak ustalą) sprintów.


Kwestia ta powinna jednoznacznie wynikać z umowy. Jeżeli istnieją etapy „wstępne”, które zakładają planowanie określonych działań, to ta kwestia również powinna być sprecyzowana w umowie. Szczegóły mogą znaleźć się w harmonogramie, który będzie załączony do umowy.


Uwaga! Na wszelki wypadek zalecam również opisanie jakiejś procedury dot. zmian w harmonogramie, gdyby taka konieczność się pojawiła.

Warto w umowie opisać na czym polega realizacja każdego etapu, kiedy dojdzie do sprecyzowania co zostanie zrobione w ramach poszczególnych sprintów (np. na początku etapu) i w jaki sposób dochodzi do zakończenia etapu – z reguły poprzez odbiór przez zamawiającego prac, które w skład tego etapu wchodziły.


Nie ma przeszkód, aby w umowie wskazać, że projekt będzie realizowany według metodyk zwinnych (agile). Zwracam uwagę na to, że może mieć to wpływ również na inne aspekty współpracy, które są regulowane w umowie – np. procedury odbioru, zasady zarządzania projektem (np. bieżące tworzenie backlogu) czy też wysokość wynagrodzenia. Dokładne informacje w tym zakresie znajdziesz w innym moim wpisie, który jest tutaj.



Osoby odpowiedzialne, kierownicy projektu i ich uprawnienia


W umowie warto napisać parę słów o tym jakie osoby będą brały udział w projekcie – tzn. że obie strony zapewniają działanie zespołów, które będą na bieżąco realizować wdrożenia. Często w umowach pojawiają się oświadczenia dot. tego, że wykonawca będzie korzystał z pomocy specjalistów o określonych umiejętnościach i doświadczeniu. Nie ma też przeszkód aby wpisać do umowy zasady, zgodnie z którymi będzie dochodziło do zmian w zespole.


Przykładowo, wykonawca może być zobowiązany do zastępowania członków zespołu nowymi w określonym czasie, a zamawiający może mieć prawo do tego aby zażądać odsunięcia kogoś od projektu w przypadku wystąpienia uzasadnionych przyczyn.

Kluczowymi osobami z punktu widzenia współpracy stron są kierownicy/koordynatorzy projektu – jeden z ramienia zamawiającego, a drugi z ramienia wykonawcy. To oni odpowiadają za bieżące kontakty stron, koordynują działania i podejmują bieżące decyzje dotyczące zakresu współpracy. Stąd też ważne jest to aby w umowie wskazać, do czego są oni uprawnieni. Może być to np. prawo do dokonywania zmian założeń lub zmian w harmonogramie projektu. Dodatkowo, niekiedy strony powołują tzw. komitet sterujący, złożony z przedstawicieli wykonawcy i zamawiającego, który podejmuje najistotniejsze decyzje w ramach projektu.


Modyfikacje, zasady dokonywania zmian we wcześniejszych założeniach


Wdrożenia bywają długie i w ich trakcie różne rzeczy się zmieniają. Dlatego też w umowie wdrożeniowej wypada przewidzieć procedurę dotyczącą tego, w jaki sposób strony mogą dokonywać zmian we wcześniej przyjętych założeniach. Obejmuje to zarówno zmiany w wynikach analiz przedwdrożeniowych, zmiany w dokumentacji zmiany wymagań zamawiającego czy też zmiany zakresu poszczególnych sprintów.


Co jest ważne? Wskazanie tego kto może dokonywać zmian, np. kierownicy projektu i w jakim trybie się to powinno odbywać. Dodatkowo, niekiedy zmiany mogą mieć wpływ na należne wykonawcy wynagrodzenie i tu też warto opisać sposób jego modyfikowania. Warto przy tym pamiętać, że zmiany mogą zwiększać czasochłonność prac w ramach projektu, ale też niekiedy prowadzą do jej zmniejszenia. Czasami w umowach wskazuje się też na kluczowe kwestie, które w żadnym wypadku zmianie nie powinny ulegać.


Istotne jest też to w jakiej formie takie zmiany są dokonywane. Z uwagi na dużą dynamikę prowadzenia prac sugeruję, aby można było to robić np. mailem, a nie w formie pisemnej. Niestety, konieczność podpisywania papierowych dokumentów pojawia się w umowach wdrożeniowych zdecydowanie zbyt często.


Jeśli chciałbyś poczytać więcej o składaniu elektronicznych oświadczeń woli, zapraszam tutaj:



kod źródłowy

Odbiory


Prace, które są realizowane w trakcie wdrożenia, z reguły podlegają jakimś odbiorom, dokonywanym przez zamawiającego. Zasady realizowania takich odbiorów również powinny być uregulowane w umowie. Pamiętaj, że odbiorom mogą podlegać poszczególne sprinty, etapy albo inne efekty prac - odbiór nie musi dotyczyć od razu całego wdrożenia.


Procedury w tym zakresie obejmują w szczególności:

  • sposób informowania o tym, że jakiś element jest już gotowy i może zostać odebrany przez zamawiającego,

  • zasady prowadzenia testów przez zamawiającego i ewentualne współdziałanie wykonawcy w tym zakresie,

  • weryfikację zgodności efektów prac z założeniami oraz sposób zgłaszania ewentualnych uwag – w tym termin na ich zgłoszenie przez zamawiającego. Nie ma przeszkód aby zrobić tzw. odbiory milczące - czyli jeśli zamawiający nie zgłasza uwag, uznajemy element za odebrany,

  • obowiązek wprowadzenia poprawek przez wykonawcę w określonym terminie,

  • sposób realizacji testów końcowych i dokonanie odbioru końcowego całego projektu.

Zdarza się niestety tak, że poprawki są zgłaszane ciągle, a każda z nich dotyczy czegoś innego – nie wpływa to dobrze na całość prac wdrożeniowych i powoduje eskalację różnych problemów. Dlatego wyznaczenie zamawiającemu terminu na zgłaszanie uwag jest dobrym rozwiązaniem, które dyscyplinuje strony i ułatwia działanie w przyjętych ramach czasowych.


Prawa autorskie


Umowy wdrożeniowe powinny zawierać również regulację dot. kwestii związanych z prawami autorskimi do oprogramowania, które jest wdrożone.


Przez oprogramowanie można tu rozumieć zarówno:

  • standardowy program, oferowany na rynku dla nieograniczonego katalogu osób (np. system ERP), który ma być wykorzystywany przez zamawiającego,

  • wszelkie dokonane w nim zmiany, mające na celu dostosowanie go do wymogów zamawiającego i zintegrowanie z całą resztą infrastruktury IT.

Czasem zdarza się tak tak, że oprogramowanie pisane jest od zera pod wymagania konkretnego klienta – w takim przypadku również będziemy mieli do czynienia z koniecznością uregulowania kwestii związanych z prawami autorskimi.


Modele dotyczące uregulowania praw autorskich w umowach są generalnie dwa:

  • przeniesienie autorskich praw majątkowych na zamawiającego – tzn. zamawiający staje się podmiotem uprawnionym do dalszego decydowania o oprogramowaniu i sposobach jego użycia (jego „właścicielem”),

  • udzielenia licencji dotyczącej korzystania z oprogramowania – twórca oprogramowania (wykonawca albo inny podmiot) nadal pozostaje jego „właścicielem” ale zamawiający ma prawo do tego aby z niego korzystać w ramach swojej działalności.

W sytuacji gdy standardowe oprogramowanie, o które oparte jest wdrożenie, jest wykorzystywane przez wielu klientów i oferowane powszechnie na rynku, w grę wchodzi tylko model licencyjny. Ewentualne przeniesienie autorskich praw majątkowych do takiego programu będzie bowiem praktycznie niemożliwe.


Inna sytuacja dotyczyła będzie dedykowanych elementów, które zostały stworzone przez wykonawcę w trakcie wdrożenia wyłącznie dla zamawiającego. Prawa do nich mogą nadal być przeniesione na zamawiającego, nawet jeśli „standardowa część” jest wykorzystywana w ramach licencji.


Więcej na temat praw autorskich i licencji możesz przeczytać tutaj.


A tutaj jest jeszcze jeden wpis, który opisuje sposób udzielania licencji i opisywanie pól eksploatacji.


SLA, wsparcie serwisowe


Zdarza się, że strony regulują w ramach umów wdrożeniowych również zasady wsparcia serwisowego, które świadczone jest przez wykonawcę po wdrożeniu. Oznacza to, że po wdrożeniu to wykonawca będzie odpowiadał za prawidłowe działanie oprogramowania i usuwał ewentualne błędy.


W tym zakresie reguluje się w szczególności to:

  • jakie błędy mogą wystąpić w oprogramowaniu i jakie kategorie są im przyporządkowywane (np. błąd krytyczny, istotny, nieistotny) – w zależności od tego jaki mają wpływ na działalność organizacji zamawiającego i możliwość bezproblemowego korzystania z programu,

  • w jakim czasie wykonawca powinien rozpocząć dokonywanie napraw oraz ewentualnie w jakim czasie powinno dość do usunięcia błędów – tu istotne są zarówno godziny/dni dotyczące czasu reakcji, jak również to kiedy będą prowadzone prace naprawcze – np. tylko w dni robocze od 8 do 16,

  • w jaki sposób zamawiający może zgłaszać nieprawidłowości i co musi opisywać w takim zgłoszeniu.


Warto również wskazać jak długo po zakończeniu wdrożenia usługi serwisowe będą świadczone – może być to przez czas określony (np. 2 lata od zakończenia wdrożenia) albo nieokreślony.


Zasady wyjścia, exit plan


Niestety nie każde wdrożenie kończy się sukcesem. Czasem zdarza się, że zamawiający z jakichś względów nie chce kontynuować prac, np. z uwagi na zmiany potrzeb biznesowych. Zdarza się też tak, że współpraca pomiędzy stronami się po prostu nie układa i zamawiający lub wykonawca uznają, że dalsze kontynuowanie wdrożenia jest niemożliwe.


Dlatego umowy wdrożeniowe z reguły przewidują jakieś zasady odstąpienia od umowy przez zamawiającego lub wykonawcę i mówią z jakimi konsekwencjami się to wiąże. Regulacje w tym zakresie mogą wskazywać:

  • z jakich przyczyn i kiedy można odstąpić od umowy,

  • co dzieje się z efektami prac, które zostały już wykonane – tzn. czy zamawiający może z nich korzystać,

  • w jaki sposób dochodzi do rozliczenia wykonanych dotychczas przez prac.


Wynagrodzenie


Wdrożenia systemów IT mogą być oparte o bardzo różne sposoby rozliczeń. Wynagrodzenie za cały projekt, za poszczególne etapy, sprinty albo za godziny pracy członka zespołu wdrożeniowego – możliwości jest mnóstwo. Nie ma przeszkód aby łączyć różne modele – np. wynagrodzenie za realizacje poszczególnych działań, które łącznie wyniesie nie więcej niż określona w umowie kwota maksymalna.


Oczywiście model typu fixed-price jest tym czego z reguły chcą zamawiający, a rozliczenia według godzin/dni pracy (time & material) są z kolei korzystniejsze dla wykonawcy.


Z uwagi na to, że wdrożenia charakteryzują się tym, że precyzyjne oszacowanie zakresu prac bywa trudne na samym początku, ryczałt za cały projekt łączy się z pewnym ryzykiem dla wykonawcy – po prostu będzie realizował prace aż projekt będzie skończony. Trzeba pamiętać o tym, że w trakcie wdrożenia zawsze może pojawić się konieczność zrobienia czegoś dodatkowo.


Nieważne jaki model przyjmiemy, kwestia wynagrodzenia musi być uregulowana w umowie. Istotne jest to wskazać kiedy płatne są poszczególne części wynagrodzenia – np. po zakończeniu sprintu albo etapu lub po przesłaniu miesięcznego podsumowania z wykonanymi pracami i wskazaniu ilości godzin, które zostały poświęcone na wdrożenie. Dodatkowo warto wskazać jakie są konsekwencje opóźnień w płatności – np. możliwość wstrzymania prac w przypadku niezapłacenia należności.


Podsumowanie


Umowy wdrożeniowe to z reguły dość obszerne regulacje, a poszczególne ich postanowienia niestety mogą wydawać się skomplikowane. W tym wpisie poruszyłem najważniejsze i najistotniejsze kwestie – zdaję sobie sprawę, że to jest jednak tylko czubek góry lodowej. Jeśli masz jakieś dodatkowe pytania dotyczące takich umów wdrożeniowych, możesz śmiało się ze mną skontaktować, pisząc na kontakt@bytelaw.pl, albo korzystając z formularza kontaktowego tutaj.


#umowawdrozeniowa #umowawit #prawaautorskie #umowaodzielo #umowaagile

  • LinkedIn Social Icon
72641531_2826510837372791_62610008722353

Michał Nosowski

Jestem radcą prawnym specjalizującym się w prawie nowych technologii. Stworzyłem tego bloga po to aby dzielić się swoją pasją - czyli badaniem styku świata IT i prawa.

 

W ramach kancelarii ByteLaw, której jestem współzałożycielem, pomagam głównie startupom, software house'om, freelancerom i ludziom zajmującym się marketingiem internetowym. Jeśli chcesz dowiedzieć się więcej, zapraszam do odwiedzenia strony Kancelarii.