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.
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:
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.
Jeżeli zainteresowała Cię ta tematyka, to więcej na temat praw autorskich i licencji do programów komputerowych możesz przeczytać w artykułach podlinkowanych poniżej:
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.
Kliknij w link jeśli chcesz poczytać więcej o umowach SLA.
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.
