Kliknąłeś w wilka brawo !

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ł.

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ść.

III. Piękna umowa, tylko nie na temat

Niejednokrotnie w sądzie stajemy wobec głupiej sytuacji – umowa jako taka jest jasna, ale projekt jest prowadzony całkowicie inaczej. Prawnicy sobie, świat sobie. Począwszy od definicji (w tym moje ulubione pomieszanie definicji „itilowskich” ze swobodą twórczą prawników) po opisanie SLA, priorytetów błędów, metodyk etc.

Efekty są zdumiewające – sądy otrzymują umowy i interpretują je tak, jak są napisane. Na co wstają strony i zgodnie zeznają „nie, nie, nie, myśmy to zupełnie inaczej robili”. Wtedy sąd wyjmuje umowę i czyta: „wszelkie zmiany wymagają formy pisemnej pod rygorem nieważności”. Strony milczą. Prawnicy mają dużo pracy. Surrealistycznej.

Przykład prawdziwy i szkoleniowy – kierownicy projektu zmienili harmonogram szczegółowy (będący załącznikiem do analizy, która była załącznikiem do umowy). Pełna zgoda stron. Tylko że sąd – skądinąd słusznie – stwierdził, iż po pierwsze, nie mieli w umowie do tego pełnomocnictw, a po drugie – nie dochowali formy pisemnej. I uznał roszczenie Zamawiającego o zapłatę kar umownych, liczonych według harmonogramu z umowy, a nie realizowanego rzeczywiście. W sumie kilkaset tysięcy odszkodowania, które pojawiło się tylko dlatego, że Wykonawca nie przypilnował zgodności umowy z rzeczywistością.

IV. Prawa autorskie i kod źródłowy

Niezwykle gorący i trudny temat. Począwszy od mitów (prawa majątkowe dają więcej uprawnień niż licencje), poprzez trudną (czasem wręcz niemożliwą) interpretację warunków licencyjnych oferowanych przez producentów, po faktyczne uwarunkowania biznesowe, które z tymi warunkami stoją w jawnej sprzeczności (modele SaaS, cloud, zwłaszcza w grupach kapitałowych).

Lista błędów, które można popełnić podczas negocjowania rozdziału o prawach autorskich jest długa. Duża część zamawiających (zwłaszcza publicznych, pod wpływem dość nieszczęśliwych co do wniosków rekomendacji Prezesa UZP) określa za daleko idące, nierynkowe wymagania (w tym nabycie praw majątkowych do standardowych produktów). Z drugiej strony zamawiający nie zabezpieczają kluczowych interesów – czasu trwania umowy, zasad wypowiadania (także w przypadku naruszenia warunków licencji), prawa do rozwoju, przenoszenia licencji, możliwości outsourcingu, powierzenia administracji na zewnątrz etc. Zazwyczaj dużo czasu poświęca się prawu do modyfikacji kodu (choć często Zamawiający nie ma żadnej faktycznej możliwości i zasobów, by rozwijać taki kod), pomijając np. sposób liczenia opłat serwisowych. W tym zakresie jest stosunkowo mało sporów sądowych, ale to głównie dlatego, że ryzyka sporu po stronie zamawiających są za duże i lepiej podpisać ugodę. Ale jeszcze lepiej jasno wynegocjować swoje oczekiwania.

Depozyt kodów źródłowych jest zwierzęciem mitycznym. W 90% umów, które znam, utożsamia się depozyt ze złożeniem jakiegoś nośnika u notariusza. Z reguły dzieje się to bez sprawdzenia, co na tym nośniku jest, nie mówiąc o próbnej kompilacji. Ani o kopii w innym miejscu. Ani o procedurach dostarczania nowych wersji. Ani o wymaganiach dokumentacji kodu. Idea depozytu jest świetna – rozwiązuje wiele spornych rzeczy, ale tylko wtedy, kiedy jest profesjonalnie obsłużona przez wyspecjalizowane podmioty. Osobiście byłem dwa razy przy podjęciu kodu – raz był to czysty kod, bez linijki komentarza, drugi raz kod był zaszyfrowany. A wykonawca zwyczajnie odmówił podania hasła. Oczywiście lista roszczeń teoretycznie jest długa, tylko że w IT, jak rzadko w której części biznesu, zupełnie nie chodzi o roszczenia.

V. Odpowiedzialność i system kar umownych

Najbardziej prawniczy temat, z niewiadomych przyczyn powierzany prawnikom. Wbrew pozorom nie jest to zdanie nielogiczne. O ile same zapisy muszą być przez prawników tworzone czy weryfikowane, o tyle pomysły na zasady odpowiedzialności to kwestie wybitnie biznesowe. I zarazem jedna z najbardziej twórczych prac podczas negocjacji. Oczywiście może być tak, że wystarczą nam same kary za zwłokę. Ale dobry kontrakt przewiduje prawdziwe zagrożenia i próbuje im przyporządkować zasady odpowiedzialności – np. wprowadzając progresję kar, kary za nieodpowiednią jakość kodu, kary za nieusunięcie zgłoszonych błędów (retestowanie niepoprawionych wersji), rozbudowane systemy SLA z rozbudowanym systemem sankcji. Idea jest prosta – po pierwsze, zabezpieczyć prawdziwie kluczowe interesy stron, po drugie – zrobić to precyzyjnie i skutecznie.

Niezwykle trudno jest pisać o „kluczowych” interesach w sposób abstrakcyjny, bo one bardzo się różnią. Opóźnienia w projekcie to oczywistość, ale np. procedura testowania, kary za przekazanie do testowania niewłaściwej jakości kodu, za niepoprawienie błędu i zmuszanie do retestowania tych samych wersji wymagają bardzo ścisłej współpracy z zespołem IT czy zespołem odpowiedzialnym za biznes. Brak tego współdziałania prowadzi do standardowych kontraktów, które nie uchronią przed problemami innymi niż standardowe.

W sądach często pojawia się spór dotyczący tego, jak rozumieć zapisy – za co jest kara (mityczna „dostępność”), jak należy ją liczyć (procent wynagrodzenia w kontraktach ze zmiennym wynagradzaniem) i czy w ogóle jest skuteczna (kary za zwłokę przy odstąpieniu od umowy). To już warsztat prawny, ale zaniedbania w precyzyjnym opisie są częste i zasłużenie kwalifikują się do „top five”.

Każdy z powyższych punktów wymaga oddzielnego omówienia, a to oczywiście lista niepełna. Przez ostanie dwadzieścia lat kontrakty IT nauczyły mnie jednego – że niepowodzenie projektu IT ma z reguły o wiele większe skutki niż wartość samej umowy. Nie negocjujemy kontraktu o wartości X – negocjujemy niezbędny fragment inwestycji o wartości wiele razy X. Nie jest możliwe napisanie idealnego, precyzyjnego i niepozbawionego pola do interpretacji kontraktu – ale zbyt często, pod wpływem presji czasu lub innych czynników, zgadzamy się na zapisy jawnie prowokujące do sporów. Których – zaręczam – warto w naszym systemie sądownictwa unikać, jak tylko się da. Zajmują za wiele czasu, emocji i kosztują zbyt dużo. O wiele więcej niż uczciwie przeprowadzone negocjacje.