Spis treści:
- Kluczowy OPZ
- Przeniesienie praw autorskich czy licencja?
- Surowa umowa
- Dobre praktyki
- Złoty środek
Przygotowanie i przeprowadzenie postępowania o udzielenie zamówienia publicznego, w tym skonstruowanie umowy dostosowanej do przedmiotu zamówienia i realiów rynku IT, jest przedsięwzięciem złożonym i stawia przed zamawiającymi wiele wyzwań.
Postępująca informatyzacja administracji publicznej, a także nieustannie rosnąca rola innowacyjnych rozwiązań w działaniu podmiotów publicznych prowadzi do zwiększenia liczby postępowań w przedmiocie zamówień na dostawę i wdrożenie oprogramowania, jak i zapewnienia świadczenia usług IT. Coraz większe wymagania od administracji publicznej, jak i zwiększona specjalizacja rozwiązań informatycznych prowadzi nieuchronnie do tego, że postępowania i przygotowywane w ich ramach umowy stają się skomplikowane i wymagające nierzadko eksperckiej wiedzy. Chęć pozyskiwania nowoczesnych rozwiązań opartych na chmurze, wspartych sztuczną inteligencją czy systemów i usług z zakresu cyberbezpieczeństwa, wymaga z jednej strony precyzyjnych opisów przedmiotu zamówienia, a z drugiej znajomości nowych regulacji prawnych. Dodatkowo prawo zamówień publicznych nakłada na zamawiających szereg obowiązków, mających na celu zapewnienie przejrzystości, uczciwej konkurencji oraz efektywności wydatkowania publicznych środków.
Wszystkie te okoliczności nie sprzyjają z pewnością zamawiającym w pozyskiwaniu tego rodzaju usług i produktów. Powinni być na bieżąco ze zmieniającymi się realiami branży IT, a jednocześnie przestrzegać sztywnych norm obowiązujących podmioty publiczne.
W niniejszym artykule autorzy chcieliby podzielić się swoimi spostrzeżeniami na temat praktycznych problemów, które powszechnie dostrzegają w postępowaniach zakupowych z zakresu technologii IT. W swojej praktyce doradzamy zarówno zamawiającym, jak i wykonawcom, tak w ramach zamówień publicznych, jak i na rynku prywatnym. Perspektywa ta pozwala na obiektywne spojrzenie i dostrzeżenie pewnych uniwersalnych problemów, które dotyczą wielu postępowań o udzielenie zamówienia na dostawę rozwiązania lub usługi IT.
Omówione w niniejszym artykule zagadnienia i przykłady są jedynie wycinkiem tej problematyki i z pewnością nie wyczerpują tematów związanych z prowadzeniem postępowań o udzielenie zamówienia z obszaru IT. To swoisty subiektywny zbiór praktycznych problemów trapiących wiele postępowań i umów, które zamawiający mogą wziąć pod uwagę, szczególnie przy przetargach na systemy informatyczne.
Kluczowy OPZ
Truizmem będzie stwierdzenie, że jednym z kluczowych elementów postępowania o udzielenie zamówienia publicznego jest prawidłowe przygotowanie opisu przedmiotu zamówienia. Jednakże już na tym etapie powstaje zalążek szeregu przyszłych problemów z realizacją umowy po udzieleniu zamówienia.
Już w pierwszym kroku zamawiający powinien ocenić, czy ma zespół kompetentny, by przygotować opis przedmiotu zamówienia w sposób wystarczająco precyzyjny i dokładny, a także uwzględniający adekwatne potrzeby zamawiającego – w tym również najnowsze standardy i wytyczne, normy branżowe, w tym także w zakresie cyberbezpieczeństwa systemów IT. Przygotowanie opisu przedmiotu zamówienia stanowi bazę dla prawidłowej realizacji umowy. Będzie on stanowić punkt odniesienia dla stron i wyraz oczekiwań zamawiającego. Daje także możliwość weryfikacji potencjalnym wykonawcom tego, czy spełniają wymogi stawiane w ramach danego postępowania. W praktyce okazuje się bowiem nierzadko, że OPZ zawiera wyraz pewnej ogólnej potrzeby biznesowej zamawiającego, która nie jest jednak poprzedzona odpowiednim rozpoznaniem rynku i dostępnych aktualnie rozwiązań, mogących na tę potrzebę odpowiedzieć. Prowadzi to do nieporozumień na linii zamawiający–wykonawca, gdyż oczekiwania co do przedmiotu umowy rozmijają się z dostarczonym przez wykonawcę narzędziem. Stąd warto na etapie tworzenia OPZ dbać o precyzję stawianych wymagań oraz uwzględnienie specyfiki pożądanego produktu w kontekście rynkowym. Tytułem przykładu można spotkać się z sytuacjami, gdzie OPZ stawia ogólne wymogi, wskazując, że dostarczany system zapewni bezpieczeństwo informacji i danych zamawiającego w nim przetwarzanych. Po udzieleniu zamówienia danemu wykonawcy okazuje się, że stosowane w praktyce przez wykonawcę standardy bezpieczeństwa nie odpowiadają od strony technicznej wymogom wewnętrznym zamawiającego i jego działu bezpieczeństwa informacji, gdyż nie zostały one ujęte w treści w treści opisu przedmiotu zamówienia.
Te drobne sytuacje powodują w konsekwencji utrudnienie współpracy pomiędzy stronami kontraktu i wątpliwości co do faktycznego zakresu oczekiwań zamawiającego oraz obowiązków wykonawcy. Jednocześnie należy mieć świadomość trudnego położenia zamawiającego. Musi on także mieć na względzie konieczność zapewnienia konkurencyjności postępowania. Opis przedmiotu zamówienia musi być sporządzony w sposób zapewniający uczciwą konkurencję. Sformułowanie wymagań odwołujących się do konkretnych rozwiązań technologicznych może ograniczyć konkurencję, co czyni przygotowanie prawidłowego OPZ zadaniem niezwykle złożonym.
Przeniesienie praw autorskich czy licencja?
Powtarzającym się problemem w umowach przygotowywanych na potrzeby publicznych postępowań zakupowych jest dążenie przez zamawiających do przeniesienia w całości praw autorskich majątkowych do wszystkich utworów dostarczonych przez wykonawcę w ramach umowy. Z jednej strony jest to zapewne wynik dużej ostrożności zamawiających i obawy przed potencjalną utratą kontroli nad pozyskanym narzędziem czy oprogramowaniem. Podejście to sprawdzi się także w sytuacji, gdy zamawiający będzie poszukiwać rozwiązania IT szytego na miarę, które powstanie od podstaw na jego potrzeby. Z drugiej strony może to być jednak wynikiem złego rozpoznania przez zamawiającego sytuacji rynkowej oraz sposobu dostarczania przez wykonawców swoich rozwiązań. Jakkolwiek oczekiwanie do uzyskania pełni praw autorskich leży w interesie zamawiającego i sprzyja jego ochronie prawnej, jednak może się ono okazać nieakceptowalne dla wykonawców, którzy dane produkty dostarczają.
Z perspektywy rynku IT coraz częstszym rozwiązaniem jest bowiem udzielenie licencji zamiast zapewnienia przeniesienia praw autorskich. Oferuje to większą elastyczność wykonawcom, którzy chcą zachować prawa do swoich dzieł i czerpać z nich długoterminowe korzyści, zamiast całkowicie się ich zbywać, jak w przypadku przeniesienia praw, które jest trwałe i zasadniczo oznacza utratę kontroli nad utworem przez twórcę. Wykonawcy przy realizacji umów wdrożeniowych opierają się na wcześniej wypracowanych rozwiązaniach (np. dokumentacji czy kodach źródłowych), jak również zapewniają przynajmniej w części standardowe aplikacji, udostępnianych wszystkim swoim klientom. Przeniesienie praw autorskich majątkowe uniemożliwiłoby takim dostawcom dalsze komercyjne wykorzystywanie swoich rozwiązań i stałoby zapewne w sprzeczności z modelem biznesowym. Przykładowo: systemy klasy ERP najczęściej dostarczane są na rynku w modelu licencyjnym. W większości przypadków nieuzasadnione byłoby zatem oczekiwanie przez zamawiającego transferu całości praw własności intelektualnych co do takiego systemu. Ponadto rozwiązania informatyczne dostarczane przez wykonawców mogą zawierać w sobie elementy podmiotów trzecich, np. zintegrowane aplikacje należące do podmiotu innego niż wykonawca. W takim wypadku wykonawca przeważnie nie będzie uprawniony do przeniesienia praw autorskich do całości dostarczonego zamawiającemu rozwiązania, gdyż sam może takich praw nie mieć.
Surowa umowa
Powszechną bolączką postępowań na zamówienia IT pozostaje także nadmierny rygoryzm umów przygotowywanych przez zamawiających. Przejawia się on w szczególności w kształtowaniu bardzo wysokich kar umownych, rozbudowanym i często nieprecyzyjnym katalogu uprawnień do odstąpienia od umowy zastrzeżonym wyłącznie na korzyść zamawiającego oraz braku jakichkolwiek ograniczeń odpowiedzialności wykonawcy. Konstrukcje te, choć z perspektywy zamawiającego mają wzmacniać bezpieczeństwo realizacji zamówienia, w praktyce mogą prowadzić do efektów odwrotnych od zamierzonych. Na rynku IT standardem jest bowiem kontraktowe ograniczanie odpowiedzialności wykonawcy, w szczególności co do jej wysokości, ale także co do jej zakresu (np. wyłączenie odpowiedzialności za utracone korzyści). Brak takich mechanizmów skutkuje często albo ograniczeniem konkurencji – poprzez rezygnację doświadczonych wykonawców z udziału w postępowaniu – albo podwyższeniem ceny ofertowej w celu skompensowania nadmiernego ryzyka kontraktowego. W konsekwencji rygorystyczne postanowienia umowne nie zawsze zwiększają ochronę interesu publicznego, a niekiedy mogą wręcz utrudniać sprawną i efektywną realizację projektów informatycznych.
Dobre praktyki
Zaangażowanie ekspertów interdyscyplinarnych
Specyfika umów IT wymaga połączenia świata technologii, biznesu i prawa. Jedną z kluczowych dobrych praktyk na etapie przygotowywania umowy IT jest zaangażowanie ekspertów o interdyscyplinarnych kompetencjach. Takie wielowymiarowe spojrzenie na projekt powinno pozwolić lepiej zidentyfikować potencjalne ryzyka, właściwie ukształtować postanowienia umów, a finalnie zwiększyć szanse na zakończenie projektu sukcesem.
W ramach przygotowywania umowy obok zespołu prawnego warto rozważyć udział ekspertów technicznych (np. architekci systemów, programiści, specjaliści z zakresu cyberbezpieczeństwa), którzy powinni uczestniczyć w procesie opisu zakresu prac, wymagań funkcjonalnych, standardów jakości, a także możliwości technicznych realizacji samego projektu. Ponadto zaangażowani powinni zostać także przedstawiciele biznesu lub product ownerzy, którzy de facto najlepiej znają zarówno cele projektu, jak i potrzeby organizacji.
W praktyce często widzimy, że to właśnie brak współpracy prowadzi do powstawania nieprecyzyjnych, niespójnych postanowień umownych, które na dalszym etapie są przyczyną sporów pomiędzy wykonawcą a zamawiającym.
Rzetelna analiza rynku przed wszczęciem postępowania
Przed wszczęciem postępowania warto przeprowadzić także rzetelne rozeznanie rynku. Analiza ta pozwoli lepiej zrozumieć dostępne rozwiązania technologiczne, modele realizacji tego rodzaju kontraktów oraz standardy stosowane przez wykonawców w danym obszarze. Rzetelna analiza rynku powinna umożliwić sformułowanie wymagań, które są nie tylko zgodne z potrzebami zamawiającego, lecz także wykonalne i adekwatne do rzeczywistości rynkowej. Wnioski z tej analizy powinny znaleźć odzwierciedlenie w przyjętym modelu rozliczeń, harmonogramie realizacji projektu oraz poziomie oczekiwanej odpowiedzialności wykonawcy.
Rozpoznanie rynku oraz sposoby dostarczania przez wykonawców poszczególnych rozwiązań IT mogą ułatwić w szczególności dobór odpowiedniego trybu postępowania przetargowego. Wspomniana wcześniej już potrzeba stworzenia precyzyjnego opisu przedmiotu zamówienia oraz konieczność pozyskania wiedzy niezbędnej do prawidłowego ukształtowania zakupu systemu informatycznego może skłonić zamawiającego do wyboru innego niż standardowy tryb postępowania o udzielenie zamówienia. W zależności od okoliczności oraz spełnienia wymogów ustawowych, dobrym rozwiązaniem mogą okazać się negocjacje z ogłoszeniem czy też dialog konkurencyjny. Obydwa tryby w dużym uproszczeniu będą polegać na sporządzeniu przez zamawiającego opisu potrzeb i wymagań, a następnie na skutek ofert wstępnych, negocjacji czy dialogu, zamawiający może pozyskać wiedzę, która umożliwia mu sporządzenie docelowej dokumentacji przetargowej optymalnie oddającej jego potrzeby i możliwości wykonawców. Adresować to będzie niewątpliwie odpowiednie rozeznanie realiów rynkowych oraz umożliwi stworzenie precyzyjnego opisu przedmiotu zamówienia, o którym była mowa wcześniej.
Transparentna komunikacja w toku postępowania
Dobrą praktyką na etapie postępowania przetargowego jest aktywna komunikacja pomiędzy wykonawcą a zamawiającym. Częstym problemem w praktyce bywa brak pełnego zrozumienia wzajemnych oczekiwań, co może skutkować sporami już na etapie realizacji umowy. Zadawanie pytań przez wykonawców pozwala doprecyzować wymagania oraz wcześnie zidentyfikować potencjalne niejasności. Z perspektywy powodzenia projektu istotne jest również, aby zamawiający nie poprzestawał na lakonicznych odpowiedziach, lecz udzielał wyczerpujących i merytorycznych wyjaśnień. Można spotkać się z sytuacjami, gdzie zamawiający na szczegółowe pytania wykonawców do specyfikacji warunków zamówienia odpowiada zdawkowo „jak w OPZ”, a na proponowane zmiany do postanowień umowy odpowiada krótko „brak zgody”. Niekiedy warto jednak pokusić się o większą refleksję nad wątpliwościami wykonawców. Mogą one być cenną wskazówką, że pewne elementy przygotowanej przez zamawiającego dokumentacji są nieprecyzyjne, co można zawczasu skorygować. Z drugiej strony jest to przestrzeń dla zamawiającego do odpowiedniego uzasadnienia swojego stanowiska i przekonania wykonawców do tego, że przedstawiona dokumentacja ma ugruntowanie w odpowiednim rozeznaniu sytuacji rynkowej lub spełnienia konkretnych oczekiwań zamawiającego, nawet jeśli nie są one standardowe.
Precyzja w formułowaniu postanowień umownych
Kwestia precyzji w formułowaniu postanowień umownych wydaje się oczywista – natomiast praktyka pokazuje, że w toku analizy umów często dochodzi do sporów interpretacyjnych. Zdarza się, że postanowienia na pierwszy rzut oka wydają się sformułowane na korzyść zamawiającego, lecz ich szczegółowa analiza nie jest już tak jednoznaczna.
Kluczowe znaczenie ma precyzyjne określenie przedmiotu umowy, którego podstawą jest wcześniej przygotowany Opis Przedmiotu Zamówienia. Zakres oczekiwanych prac powinien zostać opisany w sposób jednoznaczny, z uwzględnieniem w szczególności zarówno wymagań funkcjonalnych, jak i niefunkcjonalnych, standardów jakości, wymogów z zakresu cyberbezpieczeństwa oraz zasad integracji z istniejącymi systemami zamawiającego. Brak odpowiedniej szczegółowości bądź posługiwanie się zbyt ogólnymi sformułowaniami może prowadzić do rozbieżności interpretacyjnych na etapie realizacji umowy, a w konsekwencji do sporów pomiędzy zamawiającym a wykonawcą.
W tym miejscu warto zwrócić uwagę na zasadę contra proferentem, zgodnie z którą niejasne postanowienia umowne interpretuje się na niekorzyść strony, która je sformułowała. W przypadku zamówień publicznych oznacza to, że ciężar negatywnych konsekwencji obciąża zamawiającego jako autora dokumentacji i projektu umowy.
Konsekwencją precyzyjnego określenia przedmiotu umowy jest konieczność równie precyzyjnego uregulowania zasad odbioru przedmiotu zamówienia/umowy, które stanowią kluczowy mechanizm weryfikacji prawidłowości realizacji umowy przez wykonawcę. Etapem, który w praktyce niemal zawsze budzi kontrowersje, są odbiory, od których powodzenia często uzależniona jest wypłata poszczególnych transz wynagrodzenia dla wykonawcy.
Procedura odbiorowa powinna być nie tylko szczegółowo i jednoznacznie opisana, lecz także spójna z Opisem Przedmiotu Zamówienia oraz pozostałymi postanowieniami umowy. Istotne znaczenie ma w szczególności określenie kryteriów odbioru, terminów jego przeprowadzenia, sposobu dokumentowania rezultatów odbioru, a także konsekwencji stwierdzenia ewentualnych wad lub niezgodności z wymaganiami zamawiającego.
Projekty wdrożeniowe, z uwagi na ich złożoność oraz czas trwania, najczęściej realizowane są etapami, określanymi jako kamienie milowe. Każdy z kamieni milowych powinien zostać opisany w sposób jednoznaczny i pozostawać w ścisłej zgodności z wcześniej sporządzonym Opisem Przedmiotu Zamówienia.
Brak spójności pomiędzy OPZ a opisem poszczególnych kamieni milowych może prowadzić do istotnych sporów na etapie realizacji umowy. Zamawiający może bowiem oczekiwać wdrożenia określonej funkcjonalności na wczesnym etapie realizacji projektu, podczas gdy wykonawca będzie podnosił, że realizacja tej funkcjonalności nie została przypisana do żadnego z kamieni milowych i wobec braku odpowiednich postanowień umowy może zostać wykonana dopiero do momentu zakończenia całego projektu.
Reasumując, kryteria odbioru powinny jasno wskazywać, w jaki sposób i na jakiej podstawie będzie oceniane prawidłowe wykonanie umowy, w tym procedury testowe, dokumentację odbiorową oraz konsekwencje nieosiągnięcia założonych rezultatów. Brak precyzyjnych regulacji w tym zakresie może prowadzić do sporów co do momentu należytego wykonania umowy oraz zasadności wstrzymania odbioru lub płatności wynagrodzenia.
Komunikacja jako element zarządzania ryzykiem
Jako kolejną dobrą praktykę należy wskazać zapewnienie stałej i uporządkowanej komunikacji. Już na etapie sporządzania umowy warto precyzyjnie określić podstawowe zasady komunikacji, w tym sposób raportowania postępu wykonania umowy, częstotliwość i formę spotkań roboczych, a także możliwości dokonywania przeglądów jakości realizowanych prac. W celu ograniczenia ryzyka sporów zasadne jest również przewidzenie procedury eskalacyjnej. Na etapie bieżącej realizacji projektu komunikacja ma zazwyczaj charakter operacyjny i odbywa się pomiędzy zespołami projektowymi, jednak w przypadku pojawienia się niezgodności lub ryzyk istotnych np. dla harmonogramu lub zakresu projektu, mechanizm eskalacji umożliwia zaangażowanie kluczowych interesariuszy po obu stronach, w tym osób decyzyjnych. Jasno określone zasady eskalacji pozwalają na szybsze rozwiązywanie problemów i ograniczają ryzyko ich wzrostu.
Istotnym elementem efektywnej komunikacji jest także jej transparentność. Dobrą praktyką jest sporządzanie protokołów ze spotkań, raportów statusowych oraz bieżące dokumentowanie postępów w realizacji umowy. Tego rodzaju dokumentacja ma nie tylko znaczenie organizacyjne, lecz również dowodowe, w szczególności w przypadku ewentualnych sporów dotyczących zakresu prac, terminów lub jakości realizacji.
W tym kontekście warto jednak zachować odpowiednią równowagę pomiędzy interesami zamawiającego a realiami realizacji projektu. Nadrzędnym celem jest dostarczenie określonego rozwiązania IT, dlatego nadmiernie sformalizowane lub obciążające obowiązki komunikacyjne nie powinny negatywnie wpływać na samą realizację projektu.
Prawa własności intelektualnej
Kluczowe znaczenie w umowach IT ma także jednoznaczne i precyzyjne uregulowanie kwestii praw własności intelektualnej. Dobrą praktyką jest wyraźne rozróżnienie pomiędzy istniejącymi wcześniej rozwiązaniami wykonawcy a rozwiązaniami nowo wytworzonymi w toku realizacji umowy (np. kodem źródłowym, aplikacjami, dokumentacją czy innymi elementami o charakterze twórczym). Jeżeli jest to możliwe, już na etapie zawierania umowy warto jednoznacznie uregulować, do których elementów zamawiający nabędzie autorskie prawa majątkowe, a w odniesieniu do których uzyska jedynie licencję.
W odniesieniu do rozwiązań istniejących (tzw. background IP) zasadne jest pozostawienie praw po stronie wykonawcy, przy jednoczesnym zapewnieniu zamawiającemu odpowiednich licencji umożliwiających pełne korzystanie z tych elementów. Z kolei w przypadku rozwiązań nowo tworzonych (tzw. foreground IP), które często są dedykowane jedynie dla zamawiającego należy przeanalizować, czy uzasadnione jest przeniesienie autorskich praw majątkowych, czy też wystarczające będzie udzielenie szerokiej licencji przez wykonawcę.
Obecnie, jeżeli jest to możliwe z perspektywy biznesowej oraz charakteru danego produktu, warto rozważać zastosowanie szerokiej licencji zamiast przeniesienia praw autorskich – taka konstrukcja prawna często umożliwia wykonawcy dalszy rozwój systemu, co w praktyce może przełożyć się również na korzyści dla zamawiającego, w szczególności w postaci lepszej jakości rozwiązania, jego skalowalności oraz długoterminowego wsparcia.
Jasne zasady odpowiedzialności
Kwestia odpowiedzialności niemal zawsze budzi najwięcej emocji w toku negocjacji kontraktów. Z oczywistych względów wykonawca dąży do jej ograniczenia, w tym do wynegocjowania możliwie najniższych kar umownych, natomiast zamawiający zmierza do jej maksymalizacji poprzez rozbudowane mechanizmy odpowiedzialności, szerokie przesłanki jej zastosowania oraz zapewnienie realnych możliwości jej wyegzekwowania również w przypadku niepowodzenia całego przedsięwzięcia.
Dobrą praktyką w umowach IT jest jasne, przejrzyste i proporcjonalne ukształtowanie zasad odpowiedzialności stron, w tym wprowadzenie czytelnych limitów odpowiedzialności, procentowych limitów kar umownych oraz mechanizmów ograniczających nadmierne ryzyka kontraktowe, adekwatnych do charakteru i skali projektu.
Złoty środek
Podsumowując, zamówienia publiczne w obszarze IT wymagają od zamawiających szczególnej staranności i proaktywnego podejścia już na etapie przygotowania postępowania i umowy. Kluczowe jest balansowanie ryzyk kontraktowych, zamiast ich jednostronnego przerzucania na wykonawców, oraz uwzględnienie realiów rynku IT. Takie podejście sprzyja konkurencyjności, sprawnej realizacji projektów i efektywnemu wydatkowaniu środków publicznych.
Autorzy
Paweł Dymek
autor jest radcą prawnym w kancelarii Głowacki i Wspólnicy. Specjalizuje się w zakresie prawa nowych technologii, w szczególności umów IT oraz ochrony danych osobowych.
Paulina Ostrowska
autorka jest adwokatem w kancelarii Głowacki i Wspólnicy. Specjalizuje się w zagadnieniach z zakresu prawa nowych technologii, w szczególności cyberbezpieczeństwa oraz ochrony danych osobowych.
