Wszystkie teksty umieszczane na Linkedin lub naszych stronach internetowych są naszą opinią. Prosimy nie traktować ich jako porady prawnej w konkretnej sprawie, ponieważ konkretna sprawa zawsze wymaga indywidualnej analizy.
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.
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 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.
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”.
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. Większość kontraktów nie opisuje tego zagadnienia. Albo opisuje w stylu: „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ż X godzin”. Jedynym sensownym wyjściem jest opracowanie załącznika, który opisze zakres tego współdziałania. Analiza go uszczegółowi, ale najważniejsze kwestie zostaną omówione i zapisane. Żą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 zagadnienie z punktu widzenia procesów sądowych, to 60% postępowań dotyczy przedmiotu umowy, 20% niezbędnego współdziałania, 20% całej reszty. A w zakresie sporów dotyczących współdziałania często wykonawca, planując taki ruch, jest lepiej przygotowany od strony dokumentacyjnej, co niekoniecznie oznacza jego złą wolę. Precyzyjny załącznik to konieczność.
Niejednokrotnie przed sądem stajemy w głupiej sytuacji. Umowa jest jasna, ale projekt jest prowadzony inaczej. Prawnicy sobie, świat sobie. 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 zostały spisane, na co strony zgodnie zeznają: „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 stwierdził, że 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 złotych odszkodowania, które pojawiło się tylko dlatego, że wykonawca nie przypilnował zgodności umowy z rzeczywistością.
Gorący i trudny temat. Począwszy od mitów (prawa majątkowe dają więcej uprawnień niż licencje), poprzez trudną, czasem 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 Urzędu Zamówień Publicznych) określa zbyt 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:
Zazwyczaj dużo czasu poświęca się prawu do modyfikacji kodu (często zamawiający nie ma 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 głównie dlatego że ryzyko sporu po stronie zamawiających jest za duże i lepiej podpisać ugodę. A 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 nośnika u notariusza. Z reguły dzieje się to bez sprawdzenia, co na 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 kwestii, 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 odmówił podania hasła. Lista roszczeń teoretycznie jest długa, tylko że w IT nie chodzi o roszczenia.
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 biznesowe. I zarazem jedna z najbardziej twórczych prac podczas negocjacji.
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, za nieusunięcie zgłoszonych błędów (retestowanie niepoprawionych wersji), rozbudowane systemy SLA ze szczegółowym systemem sankcji. Idea jest prosta: po pierwsze, zabezpieczyć kluczowe interesy stron, po drugie zrobić to precyzyjnie i skutecznie.
Niezwykle trudno jest pisać o kluczowych interesach w sposób abstrakcyjny, bo one 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 zmuszania do retestowania tych samych wersji wymagają ścisłej współpracy z zespołem IT czy zespołem odpowiedzialnym za biznes. Brak współdziałania prowadzi do standardowych kontraktów, które nie radzą sobie z innymi problemami.
W sądach często pojawia się spór, jak rozumieć zapisy – za co jest kara (mityczna „dostępność”), jak należy ją liczyć (procent wynagrodzenia w kontraktach ze zmiennym wynagradzaniem) i czy jest skuteczna (kary za zwłokę przy odstąpieniu od umowy). To warsztat prawny, ale zaniedbania w precyzyjnym opisie są częste i zasłużenie kwalifikują się do „top five”.
Każdy z punktów wymaga oddzielnego omówienia, a to lista niepełna. Przez ostanie 20 lat kontrakty IT nauczyły mnie, że niepowodzenie projektu IT ma 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ć. Zajmują za wiele czasu i kosztują zbyt dużo. O wiele więcej niż uczciwe przeprowadzone negocjacje.