Pięć typowych błędów w umowach wdrożeniowych

Niepowodzenie projektu IT ma o wiele większe skutki niż wartość samej umowy. Nie jest możliwe napisanie idealnego, precyzyjnego i niepozbawionego pola do interpretacji kontraktu, ale zbyt często zgadzamy się na zapisy jawnie prowokujące do sporów, których warto unikać.

Przez wiele lat nieudane wdrożenia były traktowane jak siła wyższa, strata, którą trzeba przeboleć. Nigdy więcej. Zamawiający nie godzą się z niedokończonymi projektami, podobnie jak wykonawcy. Zarówno przed sądami powszechnymi, jak i arbitrażowymi obserwujemy wzrost liczby postępowań, a w procesach widać wszelkie zaniedbania procesu negocjacyjnego, a przede wszystkim wady samej umowy. Przedstawiamy pięć zagadnień, które najczęściej powodują nieporozumienia i spory. Wybór jest subiektywny.

Przedmiot umowy (świadczenia): na co się właściwie umówiliśmy?

Top of the top, crème de la crème umów wdrożeniowych. Studenci prawa nie są w stanie uwierzyć, że umowa wdrożeniowa nie opisuje precyzyjnie przedmiotu świadczenia. Wiemy, na kiedy i za ile, ale nie wiemy co. Bo to „co” określi analiza, CR-y, uzgodnienia kierowników, a podczas testowania niejedno może się zmienić. Problem dla obu stron: zamawiający może dostać coś, co nie spełnia jego wymagań, a wykonawca może być zmuszony do prac, których budżet nie przewidywał.

Zobacz również:

Nie ma recepty na poprawne opisanie przedmiotu świadczenia. Jeśli mamy rozbudowane, precyzyjne specyfikacje, to i tak musimy w umowie opisać zarządzanie zmianą, ze szczególnym uwzględnieniem roli analizy. W większości wypadków specyfikacje są na tyle ogólne, że dopiero analiza (projekt funkcjonalny, koncepcja itp.) opisuje prawdziwe „co”. Już na początku kontrakt musi zadbać o interesy stron (zwłaszcza zamawiającego), jeżeli okaże się, że analiza – choć przeprowadzona poprawnie – prowadzi do wniosków nieakceptowalnych (koszty, zakres zmian, terminy). Jednym ze sposobów jest wprowadzenie umownego prawa odstąpienia od umowy. To minimum prawniczej przyzwoitości, pozwalające małym kosztem wycofać się z umowy.

Więcej o umowach wdrożeniowych autor artykułu, Marcin Maruta opowie podczas warsztatów „Najlepsze praktyki umów wdrożeniowych- czyli droga do udanego projektu IT” 4 czerwca 2014 w Warszawie. Więcej szczegółów na temat warsztatów: http://www.computerworld.pl/konferencja/praktyki-umowyIT.

Przedmiot świadczenia to nie tylko zakres wdrożenia. To np. kwestia środowisk, ich administracji, wgrywania wersji testowych, zasad testowania etc. To również przypisanie prac do etapów. Wszelkie braki czy odmienne zrozumienie prowadzą do konfliktu. Strony umowy różnie starają się radzić sobie z tym problemem. W wersji idealnej tak konstruują umowę, żeby proces zmian był pod kontrolą. W wersji krańcowo nieidealnej piszą umowę na „wdrożenie systemu ERP”, po czym zamawiający stara się nadużyć pozycji dominującej i wymusić maksymalnie dużo kastomizacji, a wykonawca idzie w zaparte: „jakie interfejsy?”. W razie sporu – koszmar. Z wielką niewiadomą co do wyniku. Mój faworyt do nr. 1 w kategorii „co by tu jeszcze spieprzyć, panowie, co by tu jeszcze”.

Współdziałanie zamawiającego

Przedmiot umowy à rebours. Większość umów wdrożeniowych to umowy o dzieło, a przepisy mówią jasno: zamawiający ma obowiązek współdziałać przy wykonaniu dzieła w takim zakresie, w jakim jest to niezbędne do jego wykonania. Rozsądne, jeżeli nie dopuścimy wykonawcy do naszych środowisk, to nie zainstaluje systemu. Tym samym uniemożliwiamy wykonanie umowy. Nasza wina, nasze konsekwencje, zresztą daleko idące – nie można wykluczyć roszczenia wykonawcy o zapłatę pełnego wynagrodzenia mimo niezakończenia prac.

Kiedy projekt idzie źle, zwłaszcza gdy konflikt o to, co jest jego przedmiotem, przybiera na sile, dla wykonawcy jest to pierwsza metoda ataku (obrony). Zasypanie zamawiającego stosem żądań i odstąpienie od umowy, gdy ich nie spełnia. Co nie znaczy, że w każdym przypadku wykonawca gra rolę złego. Bywa, że to zamawiający zmienia koncepcję i sabotuje projekt wdrożeniowy, w tym nie dostarcza niezbędnych zasobów.


TOP 200