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

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

Zobacz również:

  • Trendy i wyzwania dla przedsiębiorców w 2024 roku – ekspercka analiza Comarch
  • Rząd Ghany pracuje nad regulacjami dotyczącymi AI

Piękna umowa, tylko nie na temat

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

Prawa autorskie i kod źródłowy

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: czasu trwania umowy, zasad wypowiadania (także w wypadku 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 (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.


TOP 200