Kontrakty IT rzadko są podpisywane z myślą o sporze, a jednak to właśnie one bardzo często stają się jego źródłem. Natomiast, jak zawsze powtarzam swoim klientom Umowy nie tworzymy jedynie na „złe czasy”, ale tworzymy ją po to, aby strony wiedziały jak wykonywać wzajemne ustalenia i miały jasno określone cele postępowania. Projekty informatyczne łączą technologię, biznes i prawo, a każdy skrót myślowy lub nieprecyzyjne postanowienie w umowie może prowadzić do opóźnień, dodatkowych kosztów lub poważnych konfliktów między stronami.
W praktyce wiele błędów w umowach IT nie wynika ze złej woli, lecz z braku zrozumienia specyfiki projektów technologicznych lub z korzystania z uniwersalnych wzorów, które nie przystają do realiów danego projektu. Często Używamy nieodpowiednich słów lub nie regulujemy ważnych kwestii jak np. praw autorskich. Efekt? Rozbieżne oczekiwania, spory o zakres prac, problemy z odbiorami czy brak przeniesienia praw autorskich czy udzielenia odpowiedniej licencji.
W tym artykule omawiam najczęstsze błędy popełniane przy tworzeniu kontraktów IT oraz podpowiadam, na co zwrócić uwagę, aby umowa realnie chroniła interesy obu stron i wspierała sprawną realizację projektu.
1. Brak precyzyjnego opisu przedmiotu umowy
W pierwszej kolejności możemy zwrócić uwagę na brak precyzyjnego opisywania przedmiotu umowy lub zbyt ogólnikowy zakres wykonania, który nie do końca znajduje odzwierciedlenie w faktycznym jej wykonaniu.
Sformułowania typu „wykonanie systemu IT”, „stworzenie aplikacji” czy „wdrożenie platformy” brzmią neutralnie, ale w praktyce nie definiują, co dokładnie ma zostać dostarczone. Każda ze stron może rozumieć zakres prac inaczej. Brak precyzji umowy na tak ważnym etapie może już prowadzić do pierwszych konfliktów między stronami. Klient może oczekiwać znacznie innych rezultatów, niż wykonawca w ogóle jest w stanie mu dostarczyć np. klient oczekuje kompletnego, gotowego do użycia rozwiązania, a wykonawca zakłada realizację jedynie podstawowych funkcjonalności.
Aby przedmiot umowy był jeszcze bardziej precyzyjnie opisany możemy szczegóły tego przedmiotu przenieść np. do załącznika umowy, który będzie stanowił jej integralną część i tam precyzyjnie określić jakie będą szczegóły przedmiotu umowy. Jeżeli do opisu przedmiotu umowy konieczne są jakiekolwiek dokumenty to bardzo ważnym jest, aby również one stanowiły załącznik umowy. Możemy się nimi posłużyć, aby precyzyjnie zdefiniować naszą umowę. Jeżeli w trakcie wykonywania umowy dojdzie do jakichkolwiek zmian w przedmiocie umowy to bardzo ważnym jest również jej zaktualizowanie np. w postaci stworzenia do niej aneksu precyzującego zmiany w przedmiocie umowy. Cały przedmiot umowy powinien być spójny z jej dalszą treścią.
2. Niejasny model realizacji projektu (fixed price vs. time & materials)
Temat modeli fixed price oraz time & materials jest bardzo ciekawy, więc poświęciłam mu osobny post na blogu -> tutaj możesz go przeczytać.
Są to dwa odrębne modele przy realizacji projektów z branży IT i mają wpływ na budżet, harmonogram czy odpowiedzialność stron. Niejasne postanowienia umowne mogą wprowadzać strony w błąd co do modelu, w którym chciałyby działać. Kluczowe znaczenie ma nie tylko wybór modelu, ale jego prawidłowe opisanie w umowie.
Time & Materials
To wyrażenie stosowane w umowach dotyczących danego projektu, w których Zamawiający zgadza się zapłacić Wykonawcy wynagrodzenie obliczane na podstawie poświęconego przez Wykonawcę czasu oraz za zużyte przy realizacji projektu materiały. Umowa „Czas i materiały” jest często wykorzystywana przy projektach, w których nie jest możliwe precyzyjne oszacowanie wielkości projektu, czy też jego wymagań.
Fixed Price
Rozliczanie w modelu „Fixed Price” polega na rozliczeniu się za projekt z góry ustaloną przez Strony kwotę. Wykonawca jest zobowiązany do ukończenia projektu w ramach uzgodnionej ceny i terminu.
Jaki model wybrać?
Każdy ze wskazanych powyżej modeli ma swoje wady i zalety. Wybór najkorzystniejszego modelu zależy od biznesowych założeń Zamawiającego oraz od okoliczności i doświadczenia w zlecaniu danych projektów.
Wybór modelu „Time & Materials” prowadzi do płynnych relacji między stronami i daje możliwość dostosowania efektu końcowego projektu do oczekiwań i preferencji Klienta.
W praktyce możliwe jest również połączenie wskazanych powyżej modeli, np. w fazie projektowania zastosowań model „Time & Materials” ze względu na elastyczność w tworzeniu i możliwości wprowadzania zmian, natomiast na etapie rozwoju projektu można skorzystać już z modelu „Fixed Price”.
Możliwym jest także sporządzenie umowy ramowej przewidującej oba modele rozliczania się i uzyskanie elastyczności w składaniu zamówień na dane projekty, w zależności od oczekiwań Klienta.
Więcej informacji w tym zakresie znajduje się w linku podanym powyżej, gdzie możecie poczytać o zaletach i wadach każdego z tych modeli.
3. Brak procedury zmian w kontrakcie IT
Naturalnym elementem projektów IT, jak i wszystkich umów są zmiany. Relacje między stronami się zmieniają, ewoluują, projekt może się zmieniać, może się rozwijać i dochodzą nowe potrzeby biznesowe. Problem pojawia się wtedy, kiedy umowa nie przewiduje takich możliwości i nie precyzuje tego w zakresie finansowym czy proceduralnym. Nie mówimy tutaj tylko o kwestiach, które można zmienić aneksem do umowy, ale o kwestiach, które pozwalałyby nam świadomie tych zmian dokonywać już z pewnym zapleczem ustaleń. Brak takich postanowień często może powodować późniejsze konflikty – szczególnie co do kwestii rozliczeń nowych zadań.
Bez jakichkolwiek postanowień w zakresie zmian koniecznym będzie dodatkowe rozszerzania zakresu oraz dokonywania ustaleń co do kwestii rozliczeń, harmonogramów czy dodatkowych postanowień umownych.
Odpowiednie postanowienia w zakresie zmian mogą nam określać mechanizm zgłaszania zmian, analizowania i zatwierdzania ich przez odpowiednio wybrane w umowie osoby. Modyfikacja taka jest świadoma i odpowiednio udokumentowana. Dobrze opisana procedura pozwala nam:
- określić kto może zgłaszać zmiany
- w jakiej formie zmiany będą przyjmowane
- określa termin na ich ocenę przez wykonawcę
- zmiany w wynagrodzeniu.
Każda zmiana w projekcie może wpływać na zmianę harmonogramu, jeżeli taka procedura nie jest rozpisana w umowie to:
- klient może oczekiwać realizacji zmian bez zmian terminów w harmonogramie
- wykonawca ma większy problem ze zmianą harmonogramu.
Umowa powinna określać:
- szacowane koszty zmian
- samą kwestię dodatkowego wynagrodzenia przy dodatkowych pracach czy zmianach
- kwestię akceptacji takich zmian
- termin akceptacji zmian
- sposób ich dokumentowania
- wpływ na harmonogram
- formę akceptacji obu stron
Formalna procedura zmian nie ogranicza elastyczności projektu IT, wręcz przeciwnie, pozwala na bezpieczne i kontrolowane wprowadzanie modyfikacji bez ryzyka sporów.
4. Nieokreślenie odbioru prac
W postanowieniach umownych kolejnym bardzo istotnym błędem jest brak szczegółowego określenia odbioru pracy.
W zależności od wybranego modelu umownego koniecznym jest dokonanie późniejszych odbiorów prac czy to etapami czy odbioru końcowego. Jeżeli nie określimy w umowie postanowień w zakresie odbioru to nie mamy odpowiednich zabezpieczeń, które pozwalają nam obiektywnie potwierdzić wykonanie przedmiotu umowy, a jego końcowy etap może doprowadzić do negocjacji, gdzie strony nie zgadzają się z finalną wersją projektu. W takim przypadku żadna ze stron nie dysponuje mierzalnym punktem odniesienia do oceny zgodności projektu z przedmiotem umowy i ustalonym zakresem.
Powyższa sytuacja może prowadzić do subiektywnej oceny przedmiotu umowy bez prawidłowej oceny jej jakości i kompletności systemu, różnic w interpretacji tego czy projekt jest prawidłowo wykonany, a jeżeli zawiera błędy to w jaki sposób strony mają je prawidłowo naprawić, w jakim terminie itd.
Brak odpowiedniego odebrania projektu może stanowić później problemy z dochodzeniem wynagrodzenia i wstrzymania jego wypłaty. Potem może dojść do sytuacji wykonywania niezliczonej ilości poprawek bez formalnej podstawy kontraktowej i rozmycia odpowiedzialności wykonawcy.
Brak takich postanowień powoduje, że strony zamiast opierać się na postanowieniach umownych to opierają się na wzajemnej korespondencji, wymianie zdań, co często prowadzi do sporów umownych i komplikuje proces rozliczenia i zakończenia umowy.
5. Pomijanie kwestii praw autorskich i licencji
Bardzo często spotykanym błędem w umowach jest pominięcie kwestii praw autorskich i licencji. Brak odpowiednich postanowień w tym zakresie może prowadzić do sytuacji, że po zakończeniu projektu nie jest jednoznaczne kto i w jakim zakresie może korzystać z wytworzonego np. oprogramowania, dokumentacji czy kodu źródłowego. W praktyce skutkuje to ograniczeniami w dalszym rozwoju systemu, brak możliwości jego modyfikacji czy przekazania innemu wykonawcy, a ostatecznie może doprowadzić to do sporu sądowego poprzez naruszenie praw autorskich do wytworzonego utworu.
Postanowienia w zakresie praw autorskich czy udzielenia licencji dają nam możliwość:
- legalnego korzystania z wytworzonego utworu przy określeniu odpowiednich pól eksploatacji,
- brak ryzyka naruszeń przez osoby trzecie,
- otrzymania odpowiedniego wynagrodzenia za wytworzone dzieło,
- możliwość dalszej modyfikacji i dysponowania utworem
-wszystko zależy od postanowień umownych w tym zakresie.
Częstym błędnym myśleniem jest pewność, że zapłata wynagrodzenia za wytworzony utwór oznacza nabycie pełni praw autorskich, podczas gdy brak precyzyjnych postanowień dotyczących przeniesienia praw autorskich czy udzielenia licencji, momentu ich nabycia, oznaczenia terytorium, czasu trwania i zakresu dozwolonego korzystania powoduje późniejszy spór, co niesie za sobą ryzyko biznesowe po obu stronach relacji.
WIęcej na temat praw autorskich i licencji pisałam w poście: o tutaj.
A z tego artykułu: o tutaj – dowiesz się jak prawidłowo podpisać umowę zawierająca postanowienia w zakresie praw autorskich.
6. Nieproporcjonalna odpowiedzialność stron
Kolejnym błędem jest nieproporcjonalna odpowiedzialność stron, najczęściej na wykonawcę nakłada się zbytnią odpowiedzialność nieadekwatną często do swoich obowiązków i realnego wpływu na projekt oraz otrzymanego wynagrodzenia, co może przejawiać się w brakach limitów odpowiedzialności, nadmiernie wygórowanych karach umownych zupełnie nieproporcjonalnych do wynagrodzenia, odpowiedzialności za utracone korzyści czy zdarzenia, które pozostają całkowicie poza kontrolą wykonawcy. Takie postanowienia w konsekwencji prowadzą do zachwiania równowagi kontaktowej, zbytnim ryzykiem biznesowym, eskalacją sporów w przypadku niepowodzenia projektu czy niespełnienia oczekiwań zamawiającego. Wykonawca pozostaje wtedy obciążony nadmiernym ryzykiem i może dążyć do nadmiernej ostrożności i minimalizacji współpracy, aby nie naruszyć jakiegokolwiek postanowienia umownego.
7. Brak postanowień w zakresie poufności i bezpieczeństwa danych
Nie każda umowa jest taka sama i nie każda umowa posiada tę samą wartość. Dlatego tak ważne są tzw. klauzule poufności lub umowy NDA, a także w związku z coraz większą cyberprzestępczością postanowienia dotyczące bezpieczeństwa danych. Wszystkie informacje przekazywane w związku z realizacja umowy takie jak know-how, dane klientów, dane osobowe, informacje handlowe powinny być zastrzeżone odpowiednimi postanowieniami umownymi. Często zdarza się tak, że już przed podpisaniem umowy głównej strony podpisują umowę NDA czyli umowę o zachowaniu poufności. W przeciwnym razie strony mogą nie wiedzieć jakie informacje podlegają ochronie i inaczej mogą interpretować standardy bezpieczeństwa i odpowiedzialności za incydenty. W umowie nie określimy wtedy środków technicznych czy organizacyjnych co robić w przypadku naruszenia takich danych, nie wskażemy też kar umownych, co może później spotkać się z konsekwencjami finansowymi i bezpieczeństwa.
8. Niejasne zasady rozwiązania umowy
Umowa zawierana jest przeważnie na jakiś okres czasu mówimy wtedy, że zawieramy umowę na czas określony lub nieokreślony. Najważniejszym rozwiązaniem jest (szczególnie w zakresie umów na czas nieokreślony), aby można być ją skutecznie rozwiązać, w przypadku kiedy strony chciałyby z pewnych powodów zakończyć współpracę przed ukończeniem projektu. Czasami zdarzają się zupełnie kryzysowe i nieprzewidywalne sytuacje i strony chciałyby zakończyć współpracę lub jedna ze stron nie chciałaby jej kontynuować. Jeżeli umowa nie określa przesłanek rozwiązania umowy, okresu jej wypowiedzenia, skutków rozwiązania, powodów rozwiązania, zasad rozliczenia to może to prowadzić do późniejszych sporów o wynagrodzenie, prawa do wytworzonych utworów i ich przekazanie w części czy w całości, a także może to zwiększyć ryzyko paraliżu projektu.
9. Brak konsultacji ze specjalistą
Ten punkt może wam się wydawać promocją, ze względu na to, iż pisze to sam radca prawny, ale z doświadczenia w ciągu prowadzenia naszej działalności wynika, że nasza praca naprawdę ma znaczenie przy przygotowaniach umowy czy konsultacji przed jej podpisaniem. Kontrakty, które dostają nasi klienci często opierały się na wzorach (co gorsze na wzorach wytworzonych przez AI bez modyfikacji) bez przemyślenia, bez dostosowania ich do indywidualnych potrzeb stron. Umowy nie zawierały prawidłowych postanowień w zakresie praw autorskich, a także były skrajnie niekorzystne dla klienta. Niestety, nie zawsze jesteśmy w stanie przywrócić wszystkie możliwości, które klient miałby przed skonsultowaniem się z nami. Na późniejszym etapie ciężar rozstrzygnięcia niejasności przechodzi do etapu sporu, gdzie koszty finansowe, organizacyjne i wizerunkowe są znacznie wyższe, niż koszt wcześniejszego profesjonalnego wsparcia. Sama umowa nie była niestety dla stron narzędziem do pracy, a jedynie problemem i rodziła więcej ryzyk, niepewności i konfliktów, niż dobrze napisane postanowienia.
Podsumowanie
Na zakończenie warto podkreślić, że większość problemów związanych z kontraktami IT nie wynika z samej technologii ani z niepowodzenia projektu jako takiego, lecz z nieprecyzyjnych, niedopasowanych lub pominiętych postanowień umownych, które ujawniają swoje konsekwencje dopiero na etapie realizacji, odbiorów lub rozliczeń, gdy zmiana postanowień umownych jest już niemożliwa lub kosztowna, dlatego dobrze przygotowana umowa IT powinna nie tylko regulować kwestie formalne, ale przede wszystkim odzwierciedlać rzeczywisty sposób pracy stron, uwzględniać zmienność projektów technologicznych, jasno określać zakres, odpowiedzialność, prawa autorskie, procedury zmian i zasady zakończenia współpracy, ponieważ to właśnie precyzja i spójność kontraktu w największym stopniu decydują o tym, czy projekt IT zakończy się sprawną realizacją celów biznesowych, czy długotrwałym i kosztownym sporem. Jak zawsze powtarzam moim klientom umowy nie konstruujemy tylko na „złe czasy”, ale właśnie na te „dobre czasy”, aby umowa była naszym narzędziem, przewodnikiem i mogliśmy z niej śmiało korzystać bez dalszych obaw.
Jeżeli masz jeszcze jakieś pytania w tym zakresie to zapraszamy do skorzystania z naszych porad prawnych. Możesz to zrobić klikając w ten link:
Jeżeli interesujesz się branżą IT po prostu zostaw nam swojego e-maila, poinformujemy się o kolejnych wpisach. Jeżeli potrzebujesz przygotować konkretną umowę czy jej konsultację również do nas napisz.
Photo by Christina @ wocintechchat.com M on Unsplash
Udostępnij:
