Wprowadzenie

W roku 2017 komentowałem dokument, który Ministerstwo Cyfryzacji opublikowało (Opublikowano: 22.11.2017), zatytułowany “Wzorcowe klauzule w umowach IT”. Czytam tam między innymi:

Klauzule zostały opracowane na zlecenie Ministra Cyfryzacji przez zespół kancelarii MARUTA WACHTA Sp. j. pod kierownictwem mec. Marcina Maruty i mec. Bartłomieja Wachty. Wykorzystano w nich również uwagi pracowników administracji publicznej, zarówno prawników, jak i specjalistów z dziedziny IT.

(źr. https://www.gov.pl/cyfryzacja/wzorcowe-klauzule-w-umowach-it)

Moje uwagi umieściłem we wpisie: Wzorcowe klauzule w umowach IT. Gorąco polecam przeczytanie, opisałem tam kwestie słownika w Umowie, który jest kluczem dla brzmienia Umowy i jej późniejszej interpretacji. Te klauzule nadal są oficjalne na stronie Ministerstwa Cyfryzacji. Na otwartą prośbę Ministerstwa doręczyłem swoje krytyczne uwagi, do dziś nie dostałem żadnej odpowiedzi. To było w 2017 roku.

12 grudnia 2023 r. (wtorek) o godz. 10:00 miała miejsce prezentacja (webinar on-line) prowadzona przez prawników kancelarii Lawspective Litwiński Valirakis Radcowie Prawni Sp. k.. zatytułowana “Przed Tobą wdrożenie systemu IT?” link do źródła: https://www.linkedin.com/feed/update/urn%3Ali%3Aactivity%3A7134871019667808260/

Od strony prawnej trudno cokolwiek zarzucić prelegentom. Niestety prezenterzy powielają “mity” głoszone przez dostawców oprogramowania. Generalnie polecam obejrzenie prezentacji (prawa i miejsce prezentacji należą do ww. kancelarii).

Tu odniosę do niektórych kwestii dotyczących inżynierii oprogramowania i jej styku z prawem autorskim oraz z know-how. To te miejsca, w których – mom zdaniem – prawnicy Ci wykazali się niestety zupełnym brakiem wiedzy i zrozumienia tego czym jest oprogramowanie, jego tworzenie i wdrażanie. Momentami nawet rekomendowali szkodliwe zapisy w umowach na wdrożenia.

Wymagania: nie piszcie sami (NIE UCZCIE SIE NA SOBIE)

Zapisano wiele papieru na temat niespójności specyfikacji opracowywanych metodami burzy mózgów spisanych językiem naturalnym, jedna z nich poniżej:

Šenkýř, D.; Kroha, P. Problem of Incompleteness in Textual Requirements Specification: In Proceedings of the 14th International Conference on Software Technologies; SCITEPRESS – Science and Technology Publications: Prague, Czech Republic, 2019; pp 323–330. https://doi.org/10.5220/0007978003230330.

Wymagania na oprogramowanie to nie lista życzeń. Deweloper to firma inżynierska, powinna dostać projekt techniczny jako wymaganie.

Jeżeli ktoś Ci mówi, żeby nie pisać umowy samemu i skorzystać z pomocy prawnika, to ja powiem: nie pisz wymagań sam, skorzystaj z usług projektanta.

Kastomizacje vs. rozwiązania dedykowane

Kastomizacje? Jednym słowem: NIGDY. Bo stracisz gwarancję producenta, a jak nie masz rękojmi usługodawcy, to już nikt Ci nie pomoże. Tu więcej: Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

Prawa autorskie

To kontynuacja poprzedniego punktu: Jak licencja to na oprogramowanie standardowe, jak autorskie prawa majątkowe, to z zasady do dedykowanej dla Ciebie części: moduły dedykowane tworzymy zawsze osobno i zintegrowane (jeżeli to możliwe, to w tej samej technologii i środowisku co integrowane systemu). Jednak prawa majątkowe do elementów dedykowanych i sugestia, że to ekstra koszt (za przekazanie praw majątkowych) to jest to nadużycie ze strony dostawcy (polecam tu lekturę wpisu: Prawo autorskie w projektach IT)

Uzależnienie od dostawcy

Jeżeli ktoś pozwolił się uzależnić od dostawcy to jest to na prawdę dramat, ale można tego uniknąć. Jak? Należy mieć DOKUMENTACJĘ tego jak działa oprogramowanie. Oprogramowanie standardowe powinno mieć co najmniej podręcznik użytkownika. Oprogramowanie dedykowane powinno mieć dokładną specyfikację mechanizmów działania (architektura, algorytmy, użyte metody). Brak dokumentacji prowadzi do sytuacji gdy tylko wykonawca zna mechanizm działania oprogramowanie i w efekcie ma monopol na usługi utrzymania i rozwoju, a tego nie chcemy. Oczywiście, prawa majątkowe do dedykowanego oprogramowania z zasady u zamawiającego i bez dopłaty.

Migracja

Każde nowe wdrożenie w obecnych czasach, to migracja ze starych rozwiązań do nowego. Problem w tym, że znakomita większość aplikacji jest zbudowana na tak zwanych relacyjnych bazach danych. Taka baza to setki wzajemnie połączonych tabel. problem w tym, że każda aplikacja ma inny układ tych tabel. W efekcie przeniesienie danych z jednej takiej struktury do drugiej w 100% jest praktycznie niemożliwe.

Nawet jeżeli dostawca obiecuje taką migrację, bardzo często okazuje się, że jest bardzo kosztowna, nie obejmuje wszystkich danych i bardzo często nie jest potrzebna. Z reguły wystarczy przeniesienie do nowego systemu kilku kluczowych rejestrów i słowników. Resztę można udostępnić innymi, tańszymi i pewniejszymi metodami.

Integracja

Integracja i wyimaginowany jej wielki koszt to jeden z kluczowych “straszaków” form oferujących stare, monolityczne ERP. Dzisiaj nie ma możliwości wdrożenia czegokolwiek bez integracji, bo żadna działalność gospodarcza nie mieści się w granicach jednej aplikacji. Po drugie tak zwana digitalizacja to nic innego jak integracja systemów informatycznych firmy, jej partnerów handlowych i instytucji publicznych (ze skarbówką na czele). Kluczem jest to, by te integrację zrozumieć i zaprojektować przed wyborem dostawcy oprogramowania (integracja powinna być wymaganiem).

Chmura

Temat rzeka, często słyszę (tu prawnicy także to sugerowali), że to dostawca w ofercie proponuje (lub nie) rozwiązanie chmurowe. Nic bardziej błędnego: taka decyzja powinna być konsekwencją strategii firmy (należy taką mieć) a nie dostawcy oprogramowania (który z zasad oferuje rozwiązania korzystane dla niego). Wykonawca nigdy nie powinien sam decydować o tym czy system jest lokalnie instalowany czy w chmurze.

Harmonogram

Prawnicy mówią: w umowie musi być harmonogram wdrożenia. A jakim cudem, skoro nie ma projektu tego systemu, bo “analiza wymagań i analiza przedwdrożeniowa oraz projekt systemu” to treść zlecenia dla tego dostawcy oprogramowania? Brak projektu technicznego oznacza, że zbudowanie harmonogramu jest niemożliwe bo na etapie zawierania umowy dostawca nie wie co ma powstać! Przecież nie było jeszcze żadnej analizy!

Współdziałanie

Jest to bardzo ważna część zawieranej umowy. Podstawą współdziałania jest opis tego JAKIE i W JAKIEJ postaci materiały ma dostarczać zamawiający oraz w jakim terminie. Ale to dotyczy także DOSTAWCY, który nie powinien być świętą krową. Email i telefon, spotkania, jako metoda komunikacji to DRAMAT. Podobnym dramatem są tablice on-line typu MIRO. Kluczowym celem komunikacji w projekcie jest wiedza: KTO, CO, KIEDY I DO KOGO NAPISAŁ. Nie mniej kluczowe jest to, by dokumentacja systemu (patrz wpis: Opis Techniczny Oprogramowania) nie była zlepkiem notatek i ustaleń z niekończących sie spotkań, kolekcjonowanych od dnia podpisania umowy. Powinien to być jeden, spójny, aktualizowany dokument mający jawnie wskazanego autora. Współdziałanie to umowa SLA na wzajemną komunikację obowiązująca jednakowo obie strony umowy.

Umowa

Co do kwestii czysto cywilno-prawnych nie odnoszę się, bo tu detale to w 100% kompetencje prawników.

Jednak umowa na dostarczenie i wdrożenie oprogramowania była umową o dzieło, która musi zawierać OPIS PRZEDMIOTU ZAMÓWIENIA. Tym opisem powinien być opis techniczny oprogramowania. Przedmiot takiej umowy (szczególnie logika biznesowa) jest często tajemnicą przedsiębiorstwa.

Tu zwracam uwagę, że sam cel zamawiającego, jakim jest wdrożenie czegoś nieopisanego, nie jest takim opisem. Niestety nie są chronione prawem same spisane funkcjonalności programu czyli specyfikacja (lista) wymagań funkcjonalnych (wyrok SA w Poznaniu z dnia 4 stycznia 1995 r. I ACr 422/94). Precyzję opisu dającą ochronę uzyskuje się dopiero opracowując projekt stosując wzory matematyczne, algorytmy, unikalne struktury i schematy blokowe opisujące mechanizmy działania i struktury informacji.

Kolejna ważna rzecz, to konsekwencja powyższego: umowa powinna zawierać rolę generalnego projektanta/architekta systemu, który powinien być po stronie zamawiającego (analogicznie jak w każdej innej inżynierii).

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy systemów mogą być cennym elementem cyfrowej transformacji, ale nigdy nie powinni mieć całkowitej, niekontrolowanej władzy nad całym przedsięwzięciem

 (źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : THE HERTZ VS. ACCENTURE DISASTER)

Zapis o możliwości dobrowolnego odstąpienie od umowy, bez żadnych kar i bez podawania przyczyny (zaprzestanie współpracy), powinno być w nią wpisane, jako obrona przed vendor lock-in i jakimkolwiek perswazyjnym szantażem (dotyczy to obu stron umowy).

Wdrożenie

Jeżeli wdrożenie prowadzi partner producenta oprogramowania, wyłączenie rękojmi w umowie z pośrednikiem to samobójstwo. Gwarancje z zasady daje producent a wyłączanie rękojmi w takich wdrożeniach to nie jest żaden zwyczaj tylko manipulacja dostawcy! Tak więc partner producenta, który nie ma prawa udzielenia gwarancji na nie swój produkt, powinien udzielić rękojmi. W przeciwnym wypadku każdą niezgodność oprogramowania z jego opisem, kupujący będzie musiał osobiście wyjaśniać z jego producentem: życzę powodzenia w kontaktach z amerykańskimi firmami i nie nie tylko amerykańskimi.

Umowa z dostawcą powinna zawierać zapis o tym, że dostawca (producent) ponosi skutki wadliwości praw autorskich w umowach, to ZAWSZE można wynegocjować, a nawet należy tego żądać.

Umowy zwane “wdrożenie agile” … odradzam :). Dlaczego? Bo nie zawierają opisu przedmiotu umowy innego niż staranne działanie, a w takim przypadku odpowiedzialność za uzyskany efekt w całości spada na zamawiającego.

Odbiór

Przedmiotem odbioru jest co do zasady Przedmiot Zamówienia, więc jego precyzyjny opis powinien być załącznikiem do umowy. Przypomnę że, lista funkcjonalności nie powinna być przedmiotem umowy z dostawcą/wykonawcą oprogramowania : idea systemu nie jest opisem systemu. Taką umowę (funkcjonalności jako wymagania) można zawrzeć wcześniej z projektantem, gdzie przedmiotem umowy jest opracowanie opisu technicznego i – coraz częściej – nadzór autorski w toku pracy (patrz wyżej generalny projektant).

Bardzo ważna rzecz: NIE JEST PRAWDĄ ŻE SYSTEM MOŻE MIEĆ BŁĘDY w TRAKCIE ODBIORU!!!!!!! Wskazówką może tu być podział oprogramowania na niezależne moduły/komponenty, wtedy można je odbierać niezależnie, ale odbierany moduł nie moze mieć błędów!

Przedmiotem umowy i odbioru nie powinno być “oprogramowanie” a “działający komputer”!

Podsumowanie

Powyższe to, poparte okresem 20 lat reprezentacji nabywców oprogramowania, rekomendacje. Nie jedyne, bo na moim blogu znajdziesz czytelniku więcej takich. Powyższe nie wyczerpuje problemów w umowach, celem moim było zwrócenie uwagi na częste propozycje wielu prawników, pokazujące, że zawarcie umowy na wdrożenie oprogramowania, bez merytorycznego wsparcia (jak sie okazuje prawnik nim nie jest) jest ogromnym ryzykiem.

Biorąc pod uwagę fakt, że z zasady dostawca zaawansowanych technologii ma ogromną przewagę merytoryczną nad swoim klientem, niezapewnienie sobie, po swojej stronie, eksperta z dziedziny inżynierii oprogramowania, to prosta droga do kłopotów.

Jeżeli Twój prawnik ma inne zdanie to, zanim podpiszesz niekorzystną dla siebie umowę, zapraszam na spotkanie. Z jakiegoś nieznanego mi powodu, prawnicy często bezgranicznie wierzą dostawcom oprogramowania mimo, że nie rozumieją tego co jest przedmiotem tych umów. A nabywcy oprogramowania bezgranicznie zaś wierzą tym prawnikom. Ot taka zabawa w głuchy telefon, w której dostawca oprogramowania najczęściej wygrywa.

Taka ciekawostka: fraza “ERP implementation failure” w Goole, wynik: ok. “5,330,000 results”. Czyli generalnie ryzyko jest bardzo duże. Zwracam uwagę, że skrót ERP w prasie branżowej i w blogach, w zasadzie z zasady oznacza znane monolityczne produkty w tej kategorii.