Top pięć błędów w umowach wdrożeniowych

  • Marcin Maruta,

Redakcja „Computerworld” poprosiła mnie o artykuł opisujący pięć najczęściej popełnianych błędów w umowach wdrożeniowych, patrząc z perspektywy prawa. Temat wraca co chwila, ale muszę przyznać, że niestety nie traci na aktualności. A nawet, można powiedzieć, zyskuje. Przez wiele, wiele lat nieudane wdrożenia były traktowane jak siła wyższa, strata, którą trzeba szybko przeboleć, a problem zakopać. 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 idealnie wychodzą wszelkie zaniedbania dotyczące etapu negocjacji, a przede wszystkim samej umowy. Poniżej przedstawiam pięć zagadnień, które w mojej opinii najczęściej powodują nieporozumienia i spory. Wybór, rzecz jasna, jest subiektywny.

I. Przedmiot umowy (świadczenia). Na co my 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ł.

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” 28 października 2014 w Warszawie.

Szczegóły na: https://www.computerworld.pl/konferencja/umowyIT3

Nie ma prostej recepty na poprawne opisanie przedmiotu świadczenia. Jeśli mamy rozbudowane, precyzyjne specyfikacje, to świetnie, ale i tak musimy w umowie opisać zarządzanie zmianą, ze szczególnym uwzględnieniem roli analizy. W większości przypadków specyfikacje są na tyle ogólne, że dopiero analiza (projekt funkcjonalny, koncepcja itd.) opisuje prawdziwe „co”. I już na samym początku w kontrakcie muszą być uwzględnione 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 z takich sposobów jest wprowadzenie umownego prawa odstąpienia od umowy. To minimum prawniczej przyzwoitości, pozwalające stosunkowo małym kosztem wycofać się z umowy.

Przedmiot świadczenia to nie tylko zakres wdrożenia. To np. kwestia środowisk, ich administracji, wgrywania wersji testowych, zasad testowania etc. To też przypisanie prac do etapów. Niezwykle dużo kwestii, a co gorsza – wszelkie braki czy odmienne zrozumienie prędzej czy później prowadzi do konfliktu. Strony umowy rozmaicie starają się radzić sobie z tym problemem. W wersji idealnej tak konstruują umowę, żeby proces zmian był pod kontrolą (metod jest wiele, choć to tylko dążenie do ideału, rzadko sporów w ogóle nie ma). 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 zdecydowany faworyt do numeru 1 w kategorii „co by tu jeszcze spieprzyć panowie, co by tu jeszcze”.

II. 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 wpuścimy Wykonawcy na nasze środowiska, to nie zainstaluje systemu. Czyli 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.

W sytuacji, kiedy projekt idzie źle, w szczególności wtedy, gdy konflikt o to, co jest jego przedmiotem przybiera na sile, dla Wykonawcy jest to pierwsza (i niejednokrotnie ostatnia) 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 to ten zły – bywa i tak, że to Zamawiający zmienia koncepcję i sabotuje, jak może, projekt wdrożeniowy, w tym nie dostarcza niezbędnych zasobów.

Nie wiem dlaczego, ale w większości kontraktów pomija się to zagadnienie. Co najwyżej spotykam się z opisem: „Zamawiający zapewni niezbędną współpracę...” lub – co gorsza – „Zamawiający udzieli Wykonawcy wszelkich żądanych przez niego informacji w terminie nie dłuższym niż XXX godzin”. Jedynym sensownym wyjściem jest poświęcenie czasu i energii podczas negocjacji na opracowanie załącznika, który opisze zakres tego współdziałania. Zapewne analiza go uszczegółowi, ale najważniejsze kwestie zostaną omówione i zapisane. A żądania Wykonawcy potrafią zaskoczyć – w zeszłym roku moim faworytem było „zapewnienie dla wszystkich członków zespołu Wykonawcy laptopów z odpowiednim oprogramowaniem” oraz „wyłączenie systemu produkcyjnego na okres weryfikacji działania zainstalowanej nowej wersji”. Dla jasności – był to system billingowy online.

Jeżeli spojrzeć na to zagadnienie z punktu widzenia procesów sądowych, to 60% postępowań jest skupionych wokół przedmiotu umowy, 20% wokół niezbędnego współdziałania, 20% wokół całej reszty. A w zakresie sporów dotyczących współdziałania często Wykonawca – planując taki ruch – jest o wiele lepiej przygotowany od strony dokumentacyjnej. Co – jak podkreślam – niekoniecznie oznacza jego złą wolę. W związku z tym optymalnie precyzyjny załącznik to konieczność.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem IDGLicensing@theygsgroup.com