POSTĘPOWANIE O UDZIELENIE ZAMÓWIENIA PUBLICZNEGO

Zamówienie, którego przedmiotem jest „system informatyczny” może składać się z wielu różnego rodzaju obowiązków wykonawcy, które z perspektywy prawa cywilnego mogą być klasyfikowane jako odmienne świadczenia – np. stanowiące dzieło lub świadczenie usług. Zamówienia takie mogą być także realizowane w różnych modelach, zarówno od strony techniczno-technologicznej – jako zamówienie systemu w modelu chmury obliczeniowej (np. SaaS) lub zamówienie systemu wdrażanego on-premise, jak również od strony przeprowadzenia samego procesu realizacji projektów – tj. np. jako wdrożenie zamawianego systemu realizowane w metodykach kaskadowych (waterfall) lub wdrożenie zamawianego systemu realizowane przy podejściu zwinnym (agile).

Różny zakres świadczeń składających się na zamówienia systemów IT oraz brak jednolitych standardów w tym zakresie przekłada się na bardzo różne możliwości opisu przedmiotu zamówienia (OPZ) na zakup systemu IT. To w konsekwencji powoduje, że zamawiający powinni wykazać się szczególną starannością – wyraźnie wskazując w OPZ, jakie są ich oczekiwania nie tylko względem samego systemu IT, jaki ma być kupowany, ale również względem samego sposobu, w jaki system ten ma powstawać (być wdrażany), a także tego, jak ma on później funkcjonować u zamawiającego.

W tym miejscu warto wskazać, że zamówienie na zakup systemu informatycznego, w zależności od specyficznych potrzeb zamawiającego, może obejmować różny zakres świadczeń i polegać przykładowo na dostarczeniu:

• sprzętu, oprogramowania standardowego (w tym systemowego i bazodanowego), oprogramowania dedykowanego, usług wdrożeniowych i utrzymaniowych,

• wyłącznie oprogramowania, które będzie posadowione na infrastrukturze informatycznej posiadanej przez zamawiającego lub kupowanej równolegle w innym postępowaniu,

• wyłącznie oprogramowania standardowego, dostępnego off the shelf (z półki), które nie wymaga żadnych dostosowań,

• oprogramowania standardowego, które wymaga konfiguracji, parametryzacji i rozszerzeń w postaci oprogramowania dedykowanego, stworzonego przez wykonawcę,

• wdrożenia systemu w jednym z powyższych modeli, z dodatkowymi usługami utrzymaniowymi lub rozwojowymi,

• konkretnej usługi chmury obliczeniowej lub kombinacji usług chmury obliczeniowej z rozwiązaniem informatycznym kupowanym w jednym z modeli wskazanych powyżej.

Zakupy systemów IT różnią się między sobą nie tylko ze względu na rodzaj usług składających się na dane zamówienie, lecz także z uwagi na charakter konkretnego przedsięwzięcia u zamawiającego, na potrzeby którego dokonywany jest przez zamawiającego zakup systemu IT. Zdarzają się przypadki, w których przedmiotem zamówienia jest system informatyczny budowany od podstaw, jako niezależnie tworzone rozwiązanie, które ma obsłużyć niezagospodarowane dotychczas obszary funkcjonowania danej organizacji. Należy jednak zaznaczyć, że z naturalnych względów, wskutek postępującej od wielu lat informatyzacji, jest to scenariusz coraz rzadszy. Coraz częściej natomiast systemy informatyczne zamawiane są albo jako rozwinięcie istniejących już rozwiązań (rozbudowa istniejącej infrastruktury IT zamawiającego, rozwój systemu), albo jako nowe systemy, które muszą być mocno zintegrowane z istniejącym środowiskiem informatycznym danego zamawiającego. Tym samym, coraz częściej potrzebą zamawiającego jest nie tyle zakup „systemu IT”, rozumianego jako wyodrębnione rozwiązanie informatyczne o określonych cechach i parametrach, co raczej zakup określonej funkcjonalności lub zautomatyzowanie danego procesu.

Co więcej, wraz ze zmieniającą się technologią zmienia się także sposób, w jaki zaspakajane są niektóre potrzeby zamawiających związane z automatyzacją poszczególnych procesów, co ma przełożenie na rodzaj dokonywanych zakupów w obszarze IT oraz zamawianych systemów IT. W ostatnich latach bardzo wyraźnie zaobserwować można trend rezygnacji przez zamawiających z rozbudowy własnej sprzętowej infrastruktury IT oraz przenoszenia części systemów IT w chmurę

obliczeniową, a także zamawiania poszczególnych funkcjonalności systemów IT oraz usług IT w modelach IaaS, PaaS, czy SaaS. Ten stosunkowo nowy typ zamawiania usług IT w modelu chmury obliczeniowej niesie również dla zamawiających zupełnie nowe wyzwania, jak choćby te związane z zapewnieniem odpowiedniej ochrony przetwarzanych w chmurze obliczeniowej danych, czy przeciwdziałanie wystąpieniu zjawiska vendor lock-in od dostawcy usług chmury obliczeniowej polegającego na trudnościach z przeniesieniem wyeksportowanych do chmury obliczeniowej danych do innego dostawcy (zob. rozdział VIII) oraz wymaga zupełnie odmiennego opisania przedmiotu zamówienia i ukształtowania wymagań umownych.

Zakres dostarczanych produktów oraz wykonywanych usług może być więc bardzo różny, co w oczywisty sposób wpływa na treść Specyfikacji Warunków Zamówienia (SWZ), w tym w szczególności opisu przedmiotu zamówienia (OPZ) czy wzoru umowy. Treść SWZ jest też w istotny sposób zdeterminowana innymi okolicznościami, jak np. przyjęta przez zamawiającego metodyka wdrożeniowa. Inaczej będzie sporządzony SWZ w wypadku, gdy zamawiający zdecyduje się na kaskadową metodykę wdrożenia, a inaczej, jeżeli projekt realizowany będzie w jednej z metodyk zwinnych lub z uwzględnieniem „uzwinniających” elementów. Wybór metodyki wdrożenia może mieć bowiem istotny wpływ na treść OPZ (np. w obszarze opisu produktów samego wdrożenia jak i samej organizacji pracy w ramach wdrożenia, w tym udziału zamawiającego w takim procesie), na treść umowy (np. w obszarze sposobu odbiorów i bieżącej współpracy stron), a nawet na warunki udziału w postępowaniu, czy kryteria oceny ofert (np. w obszarze kompetencji personelu wykonawcy).

Konsekwencją zarysowanej powyżej różnorodności zamówień na systemy IT jest brak możliwości sformułowania w pełni jednolitych, szczegółowych rekomendacji, znajdujących zastosowanie do wszystkich możliwych stanów faktycznych. Najprostszym przykładem uzasadniającym powyższą tezę jest kwestia rekomendacji w obszarze zabezpieczenia interesów zamawiającego poprzez odpowiednie ukształtowanie postanowień umownych dotyczących własności intelektualnej. Jeżeli przedmiot zamówienia obejmuje budowę rozwiązania od podstaw, poprzez wytworzenie nowego oprogramowania, specyficznego dla danego zamawiającego, to w pełni uzasadniona może być rekomendacja, by zamawiający nabył w jak najszerszym zakresie majątkowe prawa autorskie do stworzonego dla niego produktu. Jeżeli natomiast przedmiotem zamówienia jest oprogramowanie standardowe, które będzie w toku wdrożenia podlegało wyłącznie odpowiedniej konfiguracji, to oczekiwanie przez zamawiającego przeniesienia na niego majątkowych praw autorskich do takiego systemu może być uznane za nieadekwatne i w niezasadny sposób ograniczające konkurencję. Podobnie, błędem może być próba zabezpieczenia interesów zamawiającego poprzez wprowadzenie restrykcyjnych postanowień licencyjnych, jeżeli przedmiot zamówienia będzie obejmował usługi chmury obliczeniowej, które w inny sposób opisują zakres uprawnień do korzystania z tak udostępnianego oprogramowania.

Uwarunkowania realizacyjne konkretnego przypadku mają też wpływ na ocenę poszczególnych wymagań pod względem zgodności z fundamentalnymi zasadami prawa zamówień publicznych, jak zasada konkurencyjności, równego traktowania, czy proporcjonalności. Dane wymaganie może być uznane za nadmiarowe lub za uzasadnione, w zależności od oceny konkretnego stanu faktycznego, przykładowo od tego, jakiemu celowi służy budowa danego rozwiązania informatycznego, czy też w zależności od tego, czy system budowany jest od postaw, czy też stanowi kolejny moduł istniejącego już rozwiązania.

Biorąc pod uwagę powyższe, w Rekomendacjach przyjęto założenie, iż poszczególne zagadnienia merytoryczne zostaną omówione w odrębnych blokach, dotyczących kluczowych zagadnień wspólnych dla wszystkich rodzajów zamówień. Część dotycząca opisu przedmiotu zamówienia na system IT obejmuje następujące rozdziały:

1. Podział zamówienia na części.

2. Określoność przedmiotu zamówienia.

3. Niedyskryminacyjny OPZ, czyli zasady konkurencyjności i równego traktowania wykonawców.

4. Kryteria stosowane w celu oceny równoważności.

5. Odpowiednie opisanie wymaganych uprawnień do korzystania z systemów informatycznych w zamówieniach na systemy informatyczne.

6. Przeciwdziałanie vendor-lock in.

W poszczególnych rozdziałach uwzględnione zostaną zagadnienia właściwe dla różnych stanów faktycznych, pozwalające możliwie przekrojowo przybliżyć problematykę udzielania zamówień publicznych na systemy informatyczne.

W Rekomendacjach przyjęto trójstopniową strukturę. Na najwyższym poziomie znajdują się Rekomendacje ogólne, które dotyczą obowiązków zamawiających związanych z zapewnieniem, aby postępowanie o udzielenie zamówienia publicznego toczyło się z poszanowaniem zasad uczciwej konkurencji.

Każdej z Rekomendacji ogólnych mogą towarzyszyć Rekomendacje szczegółowe i Zagadnienia. Te pierwsze wskazują na uniwersalne powinności zamawiającego. Z kolei do kategorii zagadnień przyporządkowano sytuacje, w których działania zamawiającego bardzo istotnie zależą od okoliczności faktycznych, jednak zamawiający powinien zachować szczególną ostrożność z uwagi na zwiększone ryzyko naruszenia obowiązujących przepisów.

Wskazać należy, że zamawiający, którzy są adresatami dokumentu pn.: „Polityka zakupowa państwa”, przygotowując postępowanie na udzielenie zamówienia publicznego na system informatyczny i konstruując OPZ w takim postępowaniu, powinni wziąć pod uwagę zapisy i zalecenia dotyczące udzielania zamówień, zawarte w Polityce zakupowej państwa1.

DEFINICJE

Wskazana powyżej różnorodność możliwych stanów faktycznych, modeli wdrożeń i podejścia do projektów obejmujących budowę systemów IT, mocno utrudnia sformułowanie kompletnego katalogu definicji, adekwatnych w każdym przypadku.

Przykładowo definicja „systemu informatycznego” będzie zupełnie inna w sytuacji, w której przedmiot zamówienia będzie obejmował wyłącznie oprogramowanie standardowe, niż w sytuacji, w której przedmiotem zakupu będzie konglomerat wszystkich możliwych świadczeń i usług. Równocześnie, wiele pojęć stosowanych w branżowym języku sektora informatycznego posiada już znaczenie ustalone w języku potocznym, jednoznacznie odczytywalne nie tylko dla profesjonalistów, ale też dla przeciętnych użytkowników narzędzi informatycznych.

Należy przy tym przypomnieć ogólną zasadę tworzenia aktów prawnych, zgodnie z którą definiowanie pojęć dopuszczalne jest jedynie wówczas, gdy bez definicji nie da się ustalić znaczenia danego pojęcia poprzez sięgnięcie do jego powszechnego znaczenia lub kontekstu językowego2. Zasada ta nie dotyczy oczywiście wprost dokumentów innych niż akty prawne, jednak jej stosowanie można określić jako dobrą praktykę tworzenia dokumentów z szeroko rozumianej sfery prawa.

Dość złożona materia będąca przedmiotem tego opracowania wymaga przyjęcia pewnej wspólnej bazy terminologicznej, czyli zdefiniowania pojęć, co do których nie ma pewności lub co najmniej wysokiego prawdopodobieństwa, że będą rozumiane przez wszystkich uczestników rynku w ten sam sposób.

1 Polityka zakupowa państwa to dokument o strategicznym znaczeniu, określający priorytetowe działania w obszarze zamówień publicznych oraz wyznaczający kierunek zamawiających w zakresie udzielonych zamówień, przyjmowany uchwałą Rady Ministrów. Kierowany jest przede wszystkim do jednostek administracji rządowej. W okresie przygotowywania Xxxx XX Rekomendacji Prezesa UZP dot. zamówienia publicznego na system informatyczny Polityka zakupowa państwa nie została uchwalona i pozostawała na etapie konsultacji. Mając jednak na względzie wagę tego dokumentu w procesie udzielania zamówień, zasadne jest zwrócenie uwagi na konieczność uwzględnienia zapisów Polityki zakupowej państwa, po jej uchwaleniu, przez adresatów tego dokumentu.

2 Zgodnie z § 146 ust. 1 rozporządzenia Prezesa Rady Ministrów z dnia 20 czerwca 2002 r. w sprawie „Zasad techniki prawodawczej” (Dz. U. z 2016 r. poz. 283) w ustawie lub innym akcie normatywnym formułuje się definicję danego określenia, jeżeli: 1) dane określenie jest wieloznaczne; 2) dane określenie jest nieostre, a jest pożądane ograniczenie jego nieostrości; 3) znaczenie danego określenia nie jest powszechnie zrozumiałe; 4) ze względu na dziedzinę regulowanych spraw istnieje potrzeba ustalenia nowego znaczenia danego określenia. Zgodnie z § 146 ust. 2 ZTP, jeżeli określenie wieloznaczne występuje tylko w jednym przepisie prawnym , jego definicję formułuje się tylko w przypadku, gdy wieloznaczności nie eliminuje zamieszczenie go w odpowiednim kontekście językowym.

Z tego względu, ilekroć w niniejszym dokumencie pojawiają się następujące pojęcia pisane wielką literą, posiadają one poniżej przypisane znaczenie.

Chmura obliczeniowa/Cloud computing – model przetwarzania umożliwiający powszechny i wygodny dostęp za pośrednictwem sieci do wspólnej puli konfigurowalnych zasobów przetwarzania (np. sieci, serwerów, pamięci masowych, aplikacji i usług 3), które są szybko udostępniane z katalogu usług przy minimalnym wysiłku ze strony zespołów zarządzania lub dostawcy usług, składający się z trzech modeli usług (SaaS, PaaS, IaaS), czterech sposobów wdrażania chmur (chmura prywatna, chmura wspólnotowa, chmura publiczna, chmura hybrydowa) oraz charakteryzujący się pięcioma zasadniczymi cechami (samoobsługą na żądanie, szerokim dostępem do sieci, dynamicznym gromadzeniem zasobów, szybkim i elastycznym przydzielaniem i zwalnianiem zasobów, pomiarami i optymalizacją usług), w którym stosowana jest zasada współdzielonej odpowiedzialności między dostawcą i odbiorc ą usług chmurowych, a kluczowe technologie wykorzystywane do budowy tego modelu obejmują: szybkie i wydajne sieci rozległe, wydajne oraz relatywnie niedrogie serwery (uwzględniając ich liczbę) oraz wysokowydajną wirtualizację sprzętu.

On-premise – model budowy systemu informatycznego zakładający zainstalowanie (posadowienie) oprogramowania na konkretnych urządzeniach będących w bezpośredniej dyspozycji zamawiającego; w uproszczeniu – systemy informatyczne on-premise to systemy, które nie opierają się na technologii chmury obliczeniowej.

SLA – postanowienia SWZ określające zasady usuwania błędów lub określające wymagane przez zamawiającego parametry dotyczące działania systemu.

Oprogramowanie jako usługa/SaaS – model usługi chmurowej umożliwiający odbiorcy usług wykorzystanie aplikacji uruchomionych na infrastrukturze chmury dostarczanej przez dostawcę usług dostępnej na różnych urządzeniach klienckich za pośrednictwem np. przeglądarki internetowej lub klienta aplikacji oraz w przypadku której odbiorca usług nie zarządza ani nie kontroluje infrastruktury chmury, w tym sieci, serwerów, systemów operacyjnych, pamięci masowej, a nawet parametrów konfiguracyjnych aplikacji, z wyjątkiem ograniczonych ustawień konfiguracji aplikacji specyficznych dla użytkownika.

Platforma jako usługa/PaaS – model usługi chmurowej umożliwiający odbiorcy usług wdrożenie na infrastrukturze chmury aplikacji stworzonych przez siebie lub nabytych, które zostały przygotowane przy użyciu języków programowania, bibliotek, usług i narzędzi obsługiwanych przez dostawcę, w przypadku której odbiorca usług nie zarządza ani nie kontroluje infrastruktury chmury, w tym sieci, serwerów, systemów operacyjnych oraz pamięci masowych, ale ma kontrolę nad wdrożonymi aplikacjami i, ewentualnie, nad ustawieniami konfiguracji dla środowiska udostępnienia aplikacji.

Infrastruktura jako usługa/IaaS – model usługi chmurowej zapewniający infrastrukturę chmury, na której odbiorca usług jest w stanie wdrożyć i uruchomić dowolne oprogramowanie (systemy operacyjne i aplikacje), jednak nie zarządza ani nie kontroluje infrastruktury chmury, z wyjątkiem kontroli nad systemami operacyjnymi, pamięcią masową i wdrożonymi aplikacjami oraz, ewentualnie, ograniczonej kontroli nad wybranymi komponentami sieciowymi (np. zapór sieciowych).

Time&Material – model, w którym wynagrodzenie jest rozliczane na podstawie faktycznego czasu realizacji prac oraz stawki podanej w umowie i ewentualnie innych kosztów, których zasady zwrotu określa umowa.

Wdrożenie zwinne/agile – sposób realizacji i uprządkowania projektu informatycznego polegającego na wdrożeniu systemu IT, zakładający realizację produktu w małych fragmentach, w krótkich, następujących po sobie odstępach czasu, tj. w modelu iteracyjno-przyrostowym. Zwykle wdrożenia zwinne nie zakładają podziału na wyodrębnione etapy czy fazy, a oprogramowanie jest tworzone w ramach zamkniętych odcinków czasu (sprintów), w ramach których prace są planowane i realizowane (prowadzone są prace programistyczne i testy), a także weryfikowane. Iteracyjny sposób pracy

3 Usługi w rozumieniu technicznym (ang. „services”) np. DNS, Active Directory, itp. a nie usługi w znaczeniu prawnym (np. w rozumieniu kodeksu cywilnego lub klasyfikacji zamówień publicznych).

zapewnia sukcesywne dostarczanie fragmentów finalnego systemu, co umożliwia elastyczność w zakresie wymagań wobec systemu IT, a także ich bieżącą weryfikację i dostosowanie.

Wdrożenie kaskadowe/waterfall – sposób realizacji i uporządkowania projektu informatycznego polegającego na wdrożeniu systemu IT, zakładający sekwencyjną realizację poszczególnych etapów (faz) wdrożenia, które następują po sobie jako odrębne czynności. Zwykle wdrożenia kaskadowe zakładają następującą sekwencję prac w ramach wdrożenia: 1) analiza przedwdrożeniowa, której rezultatem jest szczegółowa specyfikacja wymagań systemu IT, 2) implementacyjna systemu IT, która realizowana jest na bazie założeń zdefiniowanych na etapie analizy przedwdrożeniowej, 3) testy akceptacyjne, w ramach których następuje weryfikacja rezultatów prac wytworzonych na etapie implementacji z wymaganiami określonymi na etapie analizy przedwrożeniowej, 4) szkolenia użytkowników i administratorów 5) start produkcyjny, 6) utrzymanie systemu.

PZP – ustawa z dnia 11 września 2019 r. − Prawo zamówień publicznych (Dz. U. z 2021 r. poz. 1129 i 1598).

DPZP – ustawa z dnia 29 stycznia 2004 r. − Prawo zamówień publicznych (Dz. U. z 2019 r. poz. 1843, z późn. zm.), która 1 stycznia 2021 r. w całości zastąpiona została PZP.

Dyrektywa klasyczna – dyrektywa Parlamentu Europejskiego i Rady 2014/24/UE z dnia 26 lutego 2014

r. w sprawie zamówień publicznych, uchylająca dyrektywę 2004/18/WE (Dz. Urz. UE L 94 z 28.03.2014, str. 65, z późn. zm.).

Prawo autorskie/pr.aut. - ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (Dz. U. z 2021 r. poz. 1062).

Definicje chmury, SaaS, PaaS i IaaS zostały zaczerpnięte z uchwały nr 97 Rady Ministrów z dnia 11 września 2019 r w sprawie Inicjatywy „Wspólna Infrastruktura Informatyczna Państwa” (WIIP).

II. PODZIAŁ ZAMÓWIENIA NA CZĘŚCI

Kwestię możliwości podziału zamówienia na części ustawodawca pozostawił dyspozycji zamawiającego

– przepis art. 91 ust. 1 PZP nie wprowadził nowych regulacji w stosunku do art. 36aa ust. 1 DPZP i wskazuje, że zamawiający może udzielać zamówienia w częściach lub dopuścić możliwość składania ofert częściowych. Pamiętać przy tym należy, że zgodnie z treścią art. 91 ust. 2 PZP zamawiający wskazuje w dokumentach zamówienia powody niedokonania podziału zamówienia na części.

Przepis ten jednak należy czytać w kontekście szerszym – tj. w kontekście aspektu zwiększania konkurencyjności na rynku danych usług czy dostaw. Tym samym podejmując decyzję co do podziału zamówienia na części lub zaniechania takiego podziału zamawiający powinien przeanalizować, czy nie dojdzie do naruszania zasady uczciwej konkurencji lub zasady równego traktowania wykonawców. Zamawiający poprzez zaniechanie takiego podziału nie może doprowadzić do uzależnienia się od jednego wykonawcy ze szkodą dla innych wykonawców, którzy mają możliwość wykonania tylko części zamówienia, ale za to dają najwyższą rękojmię wykonania tej części należycie z zachowaniem słusznych interesów zamawiającego. Podział zamówienia na części co do zasady skutkować powinien wielością wykonawców, co z kolei pomaga uniknąć uzależnienia zamawiającego od danego wykonawcy, zwiększa szanse na innowacyjność, a przede wszystkim – racjonalizuje wydatkowanie środków publicznych, bowiem większa liczba wykonawców wpływa pozytywnie na konkurencyjność cen ofert.

Podkreślić należy, że umożliwienie składania ofert częściowych jest instrumentem celowo wprowadzonym przez ustawodawcę, mającym na celu zarówno zwiększenie udziału małych i średnich przedsiębiorstw w rynku zamówień publicznych, jak i przeciwdziałanie uzależnieniu się podmiotów publicznych od jednego usługodawcy czy dostawcy. Jest to realizacja przez polskiego ustawodawcę jednego z głównych celów Dyrektywy klasycznej, tj. zwiększenia udziału sektora małych i średnich przedsiębiorstw (MŚP) w rynku zamówień publicznych oraz zwiększeniem konkurencji między wykonawcami. Zgodnie z motywem 78 preambuły do Dyrektywy klasycznej w przypadku, gdy instytucja zamawiająca zdecyduje, że podział zamówienia na części nie byłby właściwy, stosowne indywidualne sprawozdanie lub dokumenty zamówienia powinny zawierać wskazanie głównych przyczyn decyzji instytucji zamawiającej. Jako przykładowe główne przyczyny wskazano stwierdzenie przez instytucję zamawiającą, że taki podział groziłby ograniczeniem konkurencji albo nadmiernymi trudnościami technicznymi lub nadmiernymi kosztami wykonania zamówienia lub też potrzebę skoordynowania działań różnych wykonawców realizujących poszczególne części zamówienia mogłaby poważnie zagrozić właściwemu wykonaniu zamówienia.

Rekomendacja ogólna nr 1: zamawiający powinien zbadać przedmiot zamówienia pod kątem zasadności podziału zamówienia na części

W każdym przypadku, przed wszczęciem postępowania, zamawiający powinien zbadać przedmiot zamówienia pod kątem ewentualnego podziału zamówienia na części lub dopuszczenia składania ofert częściowych. W postępowaniach o udzielenie zamówienia publicznego o wartości równej lub przekraczającej progi unijne, zamawiający ma obowiązek dokonania analizy potrzeb i wymagań, o której mowa w art. 83 ust. 1 PZP. Jak stanowi art. 83 ust. 3 pkt 2 PZP, analiza ta wskazuje możliwość podziału zamówienia na części. Wskazać także należy na przepis art. 91 ust. 2 PZP, mający zastosowanie zarówno do postępowań o wartości równej lub przekraczającej progi unijne, jak i do postępowań poniżej progów unijnych, zgodnie z którym zamawiający zobowiązany jest do wskazania w dokumentach zamówienia powodów niedokonania podziału zamówienia na części. Z powyższego wywodzić należy obowiązek rozważenia przez zamawiającego, czy zamówienie może być podzielone na części. Wskazówki dotyczące podziału zamówienia na części zawiera motyw 78 preambuły do Dyrektywy klasycznej. Podkreślić jednak należy, że dyrektywa wskazuje jedynie przykładowo obszary, w których poszukiwać można przyczyn niedokonania podziału na części. Zamawiający powinien natomiast wskazać konkretne okoliczności, właściwe dla danego przypadku, które stały się podstawą jego decyzji o niedokonaniu podziału zamówienia.

Rekomendacja szczegółowa nr 1.1: zamawiający jest zobowiązany ustalić, czy zamówienie składa się z możliwych do wydzielenia części

Zamawiający ma obowiązek zbadać, czy przedmiot zamówienia może zostać podzielony na części, czy też ze swej istoty dane zamówienie nie da się racjonalnie podzielić na części. W przypadku stwierdzenia, że dany przedmiot zamówienia nie może zostać podzielony, zamawiający może zaprzestać dalszych czynności, przy czym powody niedokonania podziału powinny zostać wskazane w dokumentacji postępowania (zob. Rekomendacja szczegółowa 3.1).

Brak podziału zamówienia musi być jednak okolicznością obiektywną, wynikającą z charakteru zamówienia. W przypadku zamówień na usługi informatyczne nie jest dopuszczalne uznanie, że różne rodzaje usług, dotyczących różnych produktów – są pulą usług informatycznych, której nie można podzielić. Zamawiający nie może kierować się tutaj swoją dotychczasową praktyką, wolą posiadania tylko jednego wykonawcy, czy wręcz wygodą, w tym wolą, aby dany rozległy system, czy też kilka powiązanych ze sobą systemów IT były obsługiwane (wdrażane lub utrzymywane) przez jednego wykonawcę. Jedyną przesłanką, jaką może kierować się Zamawiający, jest istota danego zamówienia. Jako zamówienia dotyczące systemów informatycznych, które obejmują różne typy usług , a jednocześnie nie powinny być dzielone na części, można wskazać:

1. Zakup oprogramowania standardowego wraz ze wsparciem producenta.

2. Dostawa oprogramowania dedykowanego wraz z jego wdrożeniem i utrzymaniem.

Jednakże uznać należy, że łączenie w niepodzielnym zamówieniu usług wsparcia producenta danego oprogramowania standardowego z usługami rozwoju systemu opartego o to oprogramowanie standardowe może być niewłaściwe i nieuzasadnione. Także zamówienia łączące kilka różnych typów usług – np. usługi utrzymania i rozwoju tego samego systemu, powinny zostać uznane a priori za zamówienia podzielne i poddane dalszej analizie W przypadku zamówienia podlegającego dzieleniu – konieczność analizy wpływu podziału na sposób realizacji lub koszty wykonania zamówienia).

Rekomendacja ogólna nr 2: zamawiający powinien podzielić zamówienie na części, gdy zamówienie składa się z możliwych do wydzielenia części i nie zachodzą podstawy do zrezygnowania z podziału na części

Rekomendacja szczegółowa nr 2.1: zamawiający powinien ustalić odpowiedni poziom szczegółowości podziału na części

Poziom szczegółowości podziału na części zawsze zależy zarówno od specyfiki przedmiotu zamówienia, jak i od uzasadnionych potrzeb zamawiającego. Jako kierunek działań w tym zakresie należy przyjąć obowiązek stosowania przez zamawiającego zasady zachowania uczciwej konkurencji w połączeniu ze wskazanym w motywie 78 preambuły Dyrektywy klasycznej celem w postaci ułatwienia udziału w zamówieniach publicznych małym i średnim przedsiębiorcom. Przykładowym podziałem na części jest podział na usługi różnego typu, tj.: usługi wsparcia producenta dla oprogramowania standardowego, usługi rozwoju systemów informatycznych, usługi utrzymania systemów informatycznych.

Rekomendacja szczegółowa nr 2.2: zamawiający może zastosować instytucję umowy ramowej

Jednym z praktycznych sposobów zwiększenia konkurencyjności procesu udzielania zamówień jest zastosowanie umowy ramowej dla usług rozwoju systemu informatycznego czy też zamawiania usług informatycznych (outsourcing usług informatycznych). W tym modelu zamawiający zawiera z kilkoma wykonawcami umowy ramowe, na podstawie których następczo zamawia konkretne modyfikacje systemu czy też potrzebne mu usługi informatyczne.

Zagadnienie nr 2.1: zamawiający powinien dokonać weryfikacji istnienia uzasadnionych podstaw łączenia różnych typów dostaw i usług informatycznych w jednym postępowaniu

Obecnie praktyka rynkowa zmierza w kierunku dywersyfikacji wykonawców i prowadzenia wręcz osobnych postępowań na poszczególne typy usług. Analiza szerokiego spektrum postępowań o udzielenie zamówienia publicznego dotyczących systemów IT wskazuje na wypracowanie następujących typów postępowań:

1) Dostawa oprogramowania standardowego wraz ze wsparciem (stosowane umowy ramowe),

2) Dostawa systemu informatycznego wraz z utrzymaniem,

3) Utrzymanie systemu informatycznego,

4) Rozwój posiadanych systemów informatycznych (stosowane umowy ramowe),

5) Świadczenie specjalistycznych usług informatycznych (stosowane umowy ramowe)

– które prowadzone są jako osobne postępowania lub osobne części w jednym postępowaniu.

Nie oznacza to, że ich połączenie będzie w każdym przypadku naruszeniem powołanego przepisu. Zamawiający jest uprawniony do łączenia w jednym postępowaniu więcej niż jednego typu usług – w przypadku, gdy racjonalnie wykaże konieczność powierzenia usług jednemu wykonawcy. Konieczność taka może wynikać z uzasadnionych potrzeb zamawiającego, uzasadnionych nadmiernymi trudnościami, kosztami czy też poważną groźbą nieprawidłowej realizacji zamówienia.

Przykładem tutaj może być objęcie jednym zamówienie usług utrzymania i rozwoju systemu informatycznego. W wielu przypadkach – ze względu na architekturę systemu czy też infrastrukturę techniczną, na której system działa, nie jest możliwe, aby tego rodzaju usługi świadczyli w tym samym czasie dwaj różni wykonawcy. Prowadziłoby to bowiem do poważnej groźby nieprawidłowej realizacji zamówienia.

Rekomendacja ogólna nr 3: zamawiający powinien opisać powody braku podziału zamówienia na części w dokumentach zamówienia

Zgodnie z brzmieniem art. 91 ust. 2 PZP zamawiający wskazuje w dokumentach zamówienia powody niedokonania podziału zamówienia na części. Zmiana do poprzedniego stanu prawnego w stosunku do postępowań wszczętych do 31.12.2020 r. sprowadza się do tego, że poprzednio powody te powinny zostać wskazane w protokole postępowania, a obecnie – w dokumentach zamówienia. A zatem zmiana dotyczy jedynie miejsca zamieszczenia informacji, ale już nie treści.

Rekomendacja szczegółowa nr 3.1: zamawiający powinien wskazać w dokumentach zamówienia przyczyny konkretne, odnoszące się do danego zamówienia

Zgodnie z motywem 78 preambuły do Dyrektywy klasycznej w przypadku, gdy instytucja zamawiająca zdecyduje, że podział zamówienia na części nie byłby właściwy, stosowne indywidualne sprawozdanie lub dokumenty zamówienia powinny zawierać wskazanie głównych przyczyn decyzji instytucji zamawiającej. Powyższy motyw preambuły wymienia następujące przykładowe przyczyny: instytucja zamawiająca mogłaby stwierdzić, że taki podział groziłby ograniczeniem konkurencji albo nadmiernymi trudnościami technicznymi lub nadmiernymi kosztami wykonania zamówienia, lub też potrzeba skoordynowania działań różnych wykonawców realizujących poszczególne części zamówienia mogłaby poważnie zagrozić właściwemu wykonaniu zamówienia. Należy zauważyć, że ustawodawca europejski za okoliczność uzasadniającą rezygnację z podziału na części uznał jedynie nadmierne trudności czy koszty oraz brak koordynacji, skutkujący poważną groźbą nieprawidłowej realizacji zamówienia. A contrario uznać należy, iż nie jest wystarczające przewidywanie zaistnienia jakichkolwiek trudności czy kosztów, które nie są nadmierne. Samo wystąpienie jakichkolwiek trudności, jeśli nie są one nadmierne oraz trudne do przezwyciężenia poprzez odpowiednią organizację pracy, czy odpowiedni e kształtowanie postanowień umownych, nie jest wystarczającym uzasadnieniem dla zaniechania podziału zamówienia na części. Podobnie jest w przypadku stwierdzenia możliwości zaistnienia jakichkolwiek problemów z koordynowaniem działań wykonawców. Sytuacja, w której zamawiający

przewiduje przyszłe problemy, z którymi jednak nie wiąże się poważna groźba nieprawidłowej realizacji zamówienia, także nie może być przyczyną braku podziału zamówienia na części.

Podane przez zamawiającego w dokumentach zamówienia uzasadnienie zaniechania podziału zamówienia na części powinno opierać się na konkretnych okolicznościach dotyczących danego zamówienia, z powołaniem się na przeprowadzone przez zamawiającego analizy czy też badania rynku (jeżeli takie były przeprowadzone).

Nie jest zatem wystarczające zawarcie przez zamawiającego w uzasadnieniu jedynie ogólnikowych stwierdzeń. Przykładowo uzasadnienie takie nie może się ograniczać do wskazania, że udział w realizacji zamówienia dwóch lub więcej wykonawców spowodowałoby trudności organizacyjne czy też trudności w ustaleniu odpowiedzialności za należyte wykonanie zamówienia, czy też do wskazania, że elementy zamówienia są ze sobą powiązane.

Rekomendacja ogólna nr 4: zamawiający powinien analizować planowane zamówienia pod kątem ich przedmiotu oraz celu gospodarczego, w celu zapobieżenia niedozwolonemu podziałowi zamówień, prowadzącemu do niestosowania przepisów ustawy PZP

Jak wynika z art. 29 ust. 2 PZP, zamawiający nie może dzielić zamówienia na odrębne zamówienia, jeżeli prowadzi to do niestosowania przepisów ustawy, chyba że jest to uzasadnione obiektywnymi przyczynami. Regulacja ta stanowi kontynuację oczywistego zakazu dzielenia zamówień na części (odrębne zamówienia) o takich wartościach, że w odniesieniu do nich bądź nie stosuje się w ogóle przepisów prawa zamówień publicznych, bądź stosuje się przepisy o w ograniczonym zakresie (np. przepisy właściwe dla zamówień poniżej progów unijnych). Warto przy tym zwrócić uwagę na redakcję przepisu art. 29 ust. 2 PZP implementującego postanowienia art. 5 ust. 3 Dyrektywy klasycznej. Przywołany przepis w stosunku do dotychczasowej regulacji wprowadza dwie nowości. Po pierwsze, nie ma już w tym przepisie mowy o tym, że zabroniony jest taki podział zamówienia, który dokonywany jest w celu uniknięcia stosowania przepisów ustawy. Obecna regulacja abstrahuje w ogóle od intencji zamawiającego i stanowi wprost, że podział zamówienia jest niedozwolony, jeżeli prowadzi to do niestosowania przepisów ustawy, niezależnie od tego, czy taki był cel zamawiającego. Po drugie, wprowadzono istotne zastrzeżenie – podział zamówienia prowadzący do niestosowania ustawy jest niedozwolony, chyba że jest to uzasadnione obiektywnymi przyczynami. Z jednej strony ustawodawca zaostrzył więc dotychczasowe zasady, a z drugiej wyraźnie przewidział możliwość wystąpienia takich sytuacji, w których możliwe jest podzielenie zamówienia na części, nawet jeżeli doprowadzi to do uniknięcia stosowania przepisów prawa zamówień publicznych.

Z punktu widzenia praktyki stosowania dotychczasowych, a także nowych przepisów, w niektórych przypadkach może być pomocne odwołanie się do ustalenia łącznego występowania trzech czynników: tożsamości przedmiotowej i funkcjonalnej, tożsamości podmiotowej i tożsamości czasowej, co może być wskazówką interpretacyjną przy analizowaniu omawianego zagadnienia. Jeżeli więc kilka zamówień dotyczy tego samego lub zbliżonego rodzaju, jeżeli mogą one być wykonane przez ten sam krąg podmiotów i jeżeli są one lub mogą być udzielone w tym samym czasie, to istnieje wysokie prawdopodobieństwo, że stanowią one w rzeczywistości jedno zamówienie, a jego rozdzielenie na kilka zamówień i postępowań o wartościach uzasadniających niestosowanie ustawy, będzie niedozwolone.

Należy przy tym podkreślić, że samo ustalenie jednoczesnego wystąpienia lub niewystąpienia wspomnianych wyżej trzech czynników, nie jest wystarczające dla stwierdzenia, czy mamy do czynienia z jednym zamówieniem, czy też z kilkoma odrębnymi zamówieniami, których wartość powinna być szacowana odrębnie. Konieczne jest także wzięcie pod uwagę istoty i celu gospodarczego poszczególnych świadczeń. Może się bowiem okazać, że wiele świadczeń zupełnie różnego rodzaju, zamawianych w różnym czasie od różnych podmiotów, w istocie stanowi jedno zamówienie. Przykładem takiej sytuacji może być zamówienie na budowę i wdrożenie systemu informatycznego, na które składać się mogą: usługi konsultingowe (zaprojektowanie i dopasowanie do organizacji zamawiającego danego rozwiązania informatycznego), dostawy oprogramowania gotowego (np. standardowego oprogramowania systemowego czy bazodanowego), usługi programistyczne (stworzenie od podstaw dedykowanej aplikacji), usługi wdrożeniowe i szkoleniowe (instalacja, konfiguracja, testy, przeszkolenie

użytkowników) oraz usługi serwisowe (utrzymanie wdrożonego systemu). Nie ulega wątpliwości, że każde z tych świadczeń ma zupełnie inny charakter, każde może być zrealizowane przez inny krąg podmiotów i będą one realizowane z pewnością w innym czasie (w szczególności pomiędzy zaprojektowaniem systemu a przeszkoleniem użytkowników może upłynąć ponad rok). Nie ulega jednak również wątpliwości, że celem i istotą wszystkich tych świadczeń jest zbudowanie jednego działająceg o rozwiązania informatycznego i spełnienie tylko jednego lub kilku z nich, bez wykonania pozostałych, nie zaspokaja żadnej potrzeby zamawiającego. Przykładowo dostarczenie gotowego oprogramowania systemowego bez jego uruchomienia i bez zainstalowania aplikacji, która ma realizować określoną funkcjonalność, jest bezcelowe. W takiej sytuacji, uzasadnione mogłoby być objęcie opisanych świadczeń jednym zamówieniem, a podział takiego zamówienia na poszczególne kategorie świadczeń, o wartościach nieprzekraczających progu (stosowania ustawy lub unijnego), może być uznany za podział niedozwolony. Omówienie powyższego przykładu nie ma oczywiście na celu ustanowienia nakazu sumowania wartości różnego rodzaju świadczeń, jeżeli tylko da się wskazać jakikolwiek wspólny cel czy podobne okoliczności ich nabycia. Ustawa PZP przewiduje konkretne mechanizmy, w których sumowanie wartości świadczeń jest konieczne i omawiana sytuacja nie mieści się w żadnej z nich. Należy jednak pamiętać, że punktem wyjścia do ustalenia wartości zamówienia jest odpowiedź na pytanie, które w niektórych sytuacjach jest tylko pozornie proste: co właściwie jest przedmiotem zamówienia? Niewątpliwie można wskazać sytuacje, w których jeden projekt (np. rozbudowa systemu IT o konkretne funkcjonalności) będzie stanowił integralną całość, pomimo, że na jego realizację będą składać się różne świadczenia, w dodatku spełniane w różnym czasie. Chodzi więc nie o to, by dokonywać sumowania różnych świadczeń, których spełnienie ma zbliżone cele, lecz o to, żeby nie dzielić jednego zamówienia w sposób sztuczny na różne świadczenia, które – gdyby w bezrefleksyjny sposób zastosować „zasadę trzech jedności”, mogłyby stanowić przedmiot odrębnych zamówień. „Zasada trzech jedności” stanowi niewątpliwie zasadę pomocną w szacowaniu wartości zamówień i ustalaniu, czy w istocie zamawiający udziela jednego zamówienia, czy też kilku odrębnych, natomiast musi być stosowana w sposób świadomy. Możliwe są bowiem sytuacje, w których zakupy świadczeń tego samego rodzaju, dokonywane w tym samym czasie i od tych samych podmiotów, będą niezależnymi zamówieniami, jeżeli potrzeba ich udzielenia będzie wynikała z zupełnie różnych okoliczności, a cel zakupów będzie w każdym przypadku inny. Możliwe są też sytuacje, w których łączne wystąpienie tylko dwóch tożsamości, np. podmiotowej i czasowej, nie będzie przesądzało o tym, że poszczególne odrębne zamówienia należy zsumować i potraktować jak jedno zamówienie. Jeżeli przykładowo zamawiający zamierza nabyć system finansowo – księgowy i w tym samym lub nieodległym czasie zamierza nabyć rozwiązanie informatyczne wspierające kontrolę stanu zanieczyszczenia powietrza na danym terenie, to można stwierdzić, że oba zamówienia dotyczą dostarczenia systemów informatycznych, więc są tego samego rodzaju, oba mogą być zrealizowane przez tych samych dostawców i oba są udzielane w tym samym czasie. Równocześnie jednak zamawiane systemy nie są od siebie w żaden sposób zależne i każdy z nich służy zaspokojeniu zupełnie innej potrzeby zamawiającego. Trudno więc w takiej sytuacji nakazywać zamawiającemu przeprowadzenie jednego postępowania o udzielenie jednego zamówienia, którego przedmiotem byłoby dostarczenie dwóch różnych rozwiązań. W takim wypadku trudno bowiem stwierdzić tożsamość przedmiotową.

Oczywiście liczba możliwych stanów faktycznych jest nieskończona i trudno o jednoznaczne zalecenia, adekwatne do każdego przypadku. Biorąc jednak pod uwagę powyższe, ważne jest, by zamawiający planując postępowania, wzięli pod uwagę i przeanalizowali charakter poszczególnych zakupów, ich rodzaj i cel. Jeżeli w planach zamawiającego znajdzie się kilka zamówień służących osiągnięciu tego samego, konkretnego celu (np. budowy zintegrowanego systemu informatycznego), to istnieje prawdopodobieństwo, że rozdzielenie takiego przedsięwzięcia na kilka zamówień o wartościach uzasadniających niestosowanie ustawy w całości lub w pewnym zakresie, będzie stanowić niedozwolony podział zamówienia.

III. OKREŚLONOŚĆ PRZEDMIOTU ZAMÓWIENIA

Przyjmuje się, że zasady prawa zamówień publicznych zostały określone w dziale I (przepisy ogólne) w rozdziale 2 (zasady udzielania zamówień). Niemniej jednak katalog zasad dotyczących prawidłowego formułowania OPZ jest stale rozszerzany i doprecyzowywany przez doktrynę i orzecznictwo – w ramach tego trendu dołączono do w/w katalogu zasad właśnie zasadę określoności przedmiotu zamówienia. Zasada ta była w sposób oczywisty wywodzona z przepisu art. 29 ust. 1 DPZP, zaś brzmienie art. 99 ust. 1 PZP stanowi de facto powtórzenie poprzedniego przepisu. Truizmem jest ogólne stwierdzenie, że opis przedmiotu zamówienia powinien spełniać dwie cechy:

1. powinien być opisany w sposób jednoznaczny, za pomocą dostatecznie dokładnych i zrozumiałych określeń,

2. powinien być wyczerpujący, uwzględniający wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty.

Opis przedmiotu zamówienia stanowi podstawowy element specyfikacji warunków zamówienia. Podstawowym obowiązkiem zamawiającego jest dokonanie opisu w sposób jednoznaczny i wyczerpujący. Oznacza to, że opis ten powinien zapewniać, że wykonawcy będą w stanie – bez dokonywania dodatkowych interpretacji – zidentyfikować, co jest przedmiotem zamówienia. Opis przedmiotu zamówienia powinien być sformułowany w taki sposób, aby pozwalał wykonawcom na przygotowanie oferty i obliczenie ceny. Tym samym, kalkulując cenę danego zamówienia, wykonawca, po przeczytaniu opisu przedmiotu zamówienia powinien dokładnie wiedzieć, co się na takie zamówienie składa oraz jakie elementy cenotwórcze musi on uwzględnić kalkulując taką cenę. Tylko w takim przypadku możliwe będzie złożenie porównywalnych ofert. Niejasności, czy niejednoznaczności opisu przedmiotu zamówienia prowadzić mogą do sytuacji, w której poszczególni wykonawcy wycenią całkiem inny zestaw elementów składających się na ofertę, co doprowadzi z kolei do sytuacji, w której oferty nie będą porównywalne, w szczególności np. oferta z najniższą ceną nie będzie ofertą najkorzystniejszą, gdyż po prostu jej niska cena będzie wynikiem braku ujęcia w cenie wszystkich niezbędnych elementów. Stąd też to w interesie każdego zamawiającego leży odpowiednio szczegółowe, dokładne i jednoznaczne opisanie przedmiotu zamówienia.

Rekomendacja ogólna nr 5: zamawiający powinien opisać przedmiot zamówienia w sposób jednoznaczny, za pomocą dostatecznie dokładnych i zrozumiałych określeń

Obowiązek opisania przedmiotu zamówienia w sposób jednoznaczny, za pomocą dostatecznie dokładnych i zrozumiałych określeń, wynika wprost z art. 99 ust.1 PZP, a jego podstawowym celem jest zapewnienie konkurencyjności postępowania i uzyskanie porównywalnych ofert. Bardzo istotną kwestią, jest właśnie uzyskanie porównywalnych ofert. Trudno bowiem w ogóle mówić o ofercie najkorzystniejszej, jeśli wykonawcy w toku przygotowania ofert – wskutek sformułowania opisu przedmiotu zamówienia z naruszeniem przedmiotowej zasady - obejmują tymi ofertami różne zakresy usług, co z kolei przekłada się na istotne różnice w cenach ofert wynikające ze złożenia nieporównywalnych ofert. W takiej sytuacji trudno nawet mówić o cenie rażąco niskiej, czy też sprzeczności treści oferty z treścią SWZ. Bardzo poważny jest też skutek takiej wady SWZ dla zamawiającego – np. w przypadku stwierdzenia, że doszło do złożenia nieporównywalnych ofert w wyniku nieprawidłowego opisu przedmiotu zamówienia zamawiający powinien rozważyć unieważnienie postępowania (art. 255 pkt 6 PZP).

Rekomendacja szczegółowa nr 5.1: uzasadnione jest stworzenie przez zamawiającego katalogu definicji dotyczących przedmiotu zamówienia

Jednym z elementów SWZ mających na celu zapewnienie jasnego i jednoznacznego opisu przedmiotu zamówienia jest zawarcie w SWZ katalogu definicji pojęć, którymi posługuje się zamawiający. Pojęcia takie, ze względu na brak jednolitych standardów rynkowych, bez zdefiniowania mogą być różnie rozumiane przez różnych uczestników rynku i prowadzić chociażby do złożenia nieporównywalnych ofert.

SWZ dotyczący systemów informatycznych zwykle tworzony jest (czy też – powinien być tworzony) w dużej mierze przez osoby bądź to z wykształceniem informatycznym, bądź to w praktyce wykonujących ten zawód. Częstym błędem jest uznanie, że dane pojęcie (jak chociażby wdrożenie, serwis czy utrzymanie) to pojęcia o sztywno określonym zakresie, rozumiane zawsze i przez wszystkich tak samo, niezależne od kontekstu czy zakresu zamówienia. Wynika to zapewne z faktu, że w metajęzyku informatycznym niuanse w rozumieniu takich pojęć nie mają kluczowego znaczenia. Trzeba jednak pamiętać, że SWZ będzie poddawany wykładni także przez prawników, kontrolerów i administrację. I w takich przypadkach nie można powiedzieć, że istnieje tylko jedno rozumienie jakiegoś pojęcia – tak długo, jak nie istnieje jego definicja. Przykładowo można tutaj wskazać na jakże inną sytuację umów na roboty budowlane, których wykładnia może być dokonywana w oparciu o akty normatywne. Jednak tak długo, jak nie powstanie Prawo systemów informatycznych (np. na wzór Prawa budowlanego), pożądane jest zdefiniowanie przez zamawiającego wszystkich kluczowych pojęć. A zatem na etapie tworzenia opisu przedmiotu zamówienia zamawiający powinien zidentyfikować wszystkie pojęcia istotne dla przedmiotu zamówienia i jego realizacji. Poniżej wskazano kilka przykładowych, wybranych pojęć, które mogą zostać zdefiniowane w ramach opisu przedmiotu zamówienia na system informatyczny.

Element przedmiotu zamówienia	Pojęcia, które mogą wymagać zdefiniowania przez Zamawiającego w ramach danego elementu zamówienia
Oprogramowanie dedykowane	Oprogramowanie dedykowane, System informatyczny, Dokumentacja, Kod źródłowy, Projekt techniczny, Plan Testów Akceptacyjnych, Punkt Funkcyjny/Roboczogodzina (inna jednostka rozliczeniowa), Protokół odbioru.
Oprogramowanie standardowe	Oprogramowanie standardowe, System informatyczny, Dokumentacja, Nowa Wersja, Upgrade, Update, poprawka, patch, service pack.
Sprzęt	Dokumentacja.
Usługi wdrożeniowe	Wdrożenie, Testy akceptacyjne, Plan Testów Akceptacyjnych, Protokół odbioru.
Usługi utrzymania	Wada, Błąd, Awaria, Incydent, Czas Reakcji, Czas Realizacji, Dostępność, SLA, Help Desk, Poprawka/Naprawa, System Obsługi Zgłoszeń, Obejście, Asysta Techniczna, Wsparcie, Utrzymanie, Serwis.
Usługi rozwojowe	Modyfikacja, Dokumentacja Modyfikacji, Projekt techniczny, Plan Testów Akceptacyjnych, Punkt Funkcyjny/Roboczogodzina (inna jednostka rozliczeniowa), Zamówienie, Protokół odbioru.

Równocześnie należy podkreślić, że nie jest możliwe ani celowe zdefiniowanie w dokumentach zamówienia wszelkich pojęć czy też wyjaśnienie przez zamawiającego intencji każdego możliwego postanowienia. Jeżeli dane pojęcie jest jednoznaczne, tzn. jeżeli profesjonalista zajmujący się xxxx xxxxxxxxx jest w stanie bez wątpliwości ustalić jego sens (np. „procesor”, „przekątna ekranu”), to nie ma potrzeby wprowadzania do SWZ dodatkowych definicji.

Rekomendacja szczegółowa nr 5.2: zamawiający powinien opisać przedmiot zamówienia jednoznacznie, bez stosowania klauzul umożliwiających arbitralne rozszerzanie zakresu obowiązków wykonawców

Zamawiający opisując przedmiot zamówienia powinni w każdym przypadku zrobić to w sposób jednoznaczny, co oznacza, że zamawiający nie może wprowadzać postanowień, które dawałyby mu uprawnienie do arbitralnego, jednostronnego rozszerzania zakresu obowiązków wykonawcy.

Zamawiający powinien mieć na uwadze, że opisanie przedmiotu zamówienia w sposób jednoznaczny oznacza, że opis przedmiotu zamówienia musi mieć tylko jedno znaczenie (musi być rozumiany jednakowo przez wszystkich zainteresowanych ubieganiem się o udzielenie zamówienia) i nie może budzić wątpliwości.

Zamawiający zgodnie z art. 101 ust. 1 pkt 1 PZP jest uprawniony do opisania przedmiotu zamówienia poprzez określenie w SWZ wymagań dotyczących wydajności lub funkcjonalności danego systemu informatycznego. W takim przypadku dopuszczalne jest użycie w/w klauzul: w szczególności, przykładowo, między innymi – zamawiający wskazuje bowiem na pełną listę funkcjonalności, a następnie uszczegóławia tylko niektóre z nich, najistotniejsze dla niego. Podkreślić należy, że ustawodawca wyraźnie wskazał warunek takiego opisu poprzez określenie jedynie funkcjonalności – podane parametry muszą być na tyle precyzyjne, aby wykonawcy mogli ustalić przedmiot zamówienia. Co więcej – wszyscy wykonawcy powinni być w stanie ustalić ten przedmiot zamówienia w taki sam sposób. Odpowiednio szczegółowe opisanie funkcjonalności zamawianego systemu w pełni realizuje wymóg opisania przedmiotu zamówienia w sposób jednoznaczny.

Zagadnienie nr 5.1: zamawiający może zastosować model Time&Material w przypadku, gdy na etapie publikacji SWZ nie jest możliwe określenie zakresu obowiązków wykonawcy w sposób zamknięty

W praktyce udzielania zamówień związanych z systemami informatycznymi mogą zdarzać się przypadki, gdy zamawiający na etapie tworzenia SWZ nie jest w stanie wskazać nawet zamawianych funkcjonalności. Ma to miejsce w przypadku, gdy funkcjonalność ta zależy od okolicznośc i przyszłych, niezależnych od zamawiającego, jak np. przyszłe zmiany prawa (zarówno krajowego, jak i unijnego), wprowadzenie zmian w organizacji zamawiającego, konieczność zmiany elementów infrastruktury wobec zaprzestania świadczenia wsparcia przez producentów. W takiej sytuacji zamawiający może wykorzystać model Time&Material.

Rekomendacja szczegółowa nr 5.3: zamawiający powinien precyzyjnie określać sposób obliczania parametrów, które zamierza stosować do oceny jakości świadczenia

Określając parametry dotyczące świadczenia usług, zamawiający powinni nie tylko określać ich wysokość (np. „dostępność 99,9%”), ale także zasady ich obliczania. Przykładowo, posługując się pojęciem dostępności należy zdefiniować, jak zamawiający rozumie stan dostępności lub jej braku. Dokładna definicja zależy od potrzeb zamawiającego oraz jego możliwości technicznych i organizacyjnych, aby na bieżąco weryfikować wartość parametru. W przypadku dostępności zamawiający powinien mieć też na uwadze, że ta sama wartość procentowa przyjęta dla różnych okresów rozliczeniowych przekłada się na różną długość dozwolonego czasu niedostępności. Przykładowo, dozwolona niedostępność w razie przyjęcia parametru 99,999% wynosi ok. 5,5 minuty w przypadku rocznego okresu rozliczeniowego, a jedynie ok. 26 sekund w przypadku miesięcznego okresu rozliczeniowego. Zamawiający powinien dostosować wymagania do swoich potrzeb, mając na względzie, że dalej idące wymagania z reguły przekładają się na zmniejszenie liczby wykonawców zdolnych zrealizować zamówienie lub na wyższą cenę.

Rekomendacja szczegółowa nr 5.4: zamawiający powinien precyzyjnie określać przesłanki zastosowania kar umownych i dostosować ich wysokość do rzeczywistych potrzeb

Zamawiający przygotowując warunki umowy w sprawie zamówienia publicznego określa postanowienia dotyczące kar umownych. Kary umowne są przydatnym mechanizmem ułatwiającym naprawienie szkody bez potrzeby udowadniania jej wysokości lub tworzącym zachętę ekonomiczną, aby określone zobowiązanie nie zostało zlekceważone. Jednocześnie, postanowienia dotyczące kar umownych mają istotne znaczenie dla oceny ryzyka kontraktowego, a tym samym wpływają na decyzje wykonawców co do tego, czy brać udział w postępowaniu i jaką cenę zaoferować. Racjonalny wykonawca powinien bowiem wkalkulować w cenę także rezerwę na ryzyko związane z koniecznością zapłaty kar.

Dlatego określając kary umowne, zamawiający powinni dostosować charakter i wysokość kar umownych do realnych potrzeb i rzeczywistego ryzyka, z jakim wiąże się dane naruszenie zobowiązania. Dobrą praktyką jest weryfikowanie tych założeń przez symulację możliwej wysokości kar umownych w scenariuszach, które z dużym prawdopodobieństwem mogą wystąpić podczas realizacji umowy. Zamawiający co do zasady powinni też unikać kumulowania różnych kar umownych, które

mogą być naliczone za to samo zdarzenie (np. kumulowania kar umownych za przekroczenie dozwolonego czasu przywrócenia działania usługi, jeśli jednocześnie nalicza kary umowne za niedotrzymanie wymaganej dostępności).

Rekomendacja ogólna nr 6: zamawiający powinien opisać przedmiot zamówienia w sposób wyczerpujący, uwzględniający wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty

Opisanie przedmiotu zamówienia w sposób wyczerpujący umożliwia wykonawcy bez żadnych wątpliwości i dodatkowych interpretacji zidentyfikowanie, z jakich elementów składa się zamówienie i co będzie konieczne i niezbędne do jego realizacji. Taki opis z kolei przekłada się na możliwość ustalenia ceny oferty w taki sposób, aby obejmowała ona wszystkie koszty związane z należytą realizacją zamówienia.

Rekomendacja szczegółowa nr 6.1: zamawiający powinien dążyć do zlikwidowania asymetrii informacyjnej między wykonawcami (likwidacja naturalnej przewagi konkurencyjnej)

Jak już wskazano we wstępie do niniejszego Xxxx XX, zamówienia na systemy informatyczne coraz częściej dotyczą istniejących już rozwiązań IT - rozbudowy istniejącej infrastruktury IT zamawiającego, rozwoju czy też utrzymania już funkcjonującego u zamawiającego systemu. W każdym takim przypadku istnieje wykonawca posiadający unikalną wiedzę o danym systemie czy infrastrukturze IT, której nie posiadają inni wykonawcy na rynku – jest to wykonawca już świadczący dla zamawiającego usługi. Taką sytuację można określić jako naturalną przewagę konkurencyjną. Można jednak w prosty sposób zlikwidować negatywne skutki takiej przewagi – a to poprzez zawarcie w SWZ wszystkich informacji, które taki dotychczasowy wykonawca posiada, a które mają wpływ na sporządzenie oferty. W tym celu zamawiający powinien udostępnić jako element SWZ co najmniej:

1. możliwie najpełniejszy opis systemu,

2. pełną listę posiadanej infrastruktury IT,

3. wszystkie dane historyczne, które mogą mieć wpływ na świadczenie usług: liczba i rodzaj występujących błędów, incydentów.

Zamieszczenie w SWZ wszystkich informacji, które taki dotychczasowy wykonawca posiada, z jednej strony realizuje wymóg zamieszczenia wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty, a z drugiej strony zapewnia pełną konkurencyjność postępowania - zamawiający wprowadza równowagę informacyjną pomiędzy wykonawcami.

Zastrzec należy, że w przypadku informacji, których ujawnienie zagrażałoby bezpieczeństwu systemu lub usług świadczonych z jego wykorzystaniem, zamawiający powinien rozważyć postawienie wymagań dotyczących zachowania poufnego charakteru informacji (art. 18 ust. 4 PZP).

Należy także nadmienić, że jednym ze sposobów zapewnienia równego dostępu do informacji niezbędnych w celu prawidłowego sformułowania oferty oraz wykonania zamówienia, jest przewidzenie wizji lokalnej lub sprawdzenia dokumentów niezbędnych do realizacji zamówienia w siedzibie zamawiającego (art. 131 ust. 2 PZP). Mechanizm ten (zwłaszcza w wariancie obligatoryjnym) powinien być jednak stosowany świadomie i nie może być nadużywany. W szczególności wizja lokalna powinna być raczej traktowana jako uzupełnienie dokumentów zamówienia, a nie może zastępować informacji, których powinien udzielić zamawiający w celu sporządzenia oferty i realizacji zamówienia. Możliwość lub obowiązek odbycia wizji lokalnej czy sprawdzenia dokumentów w lokalizacji zamawiającego nie zwalnia też zamawiającego z obowiązku udzielenia wyjaśnień treści SWZ.

Zagadnienie nr 6.1: wymagania specyficzne dla IaaS

IaaS może stanowić przedmiot zamówienia sam w sobie, lub element większego zamówienia (np. kompleksowego wdrożenia systemu informatycznego opartego na infrastrukturze zapewnianej w

modelu IaaS). Wśród parametrów, które zamawiający powinien uwzględnić opisując przedmiot zamówienia obejmującego IaaS, należy wymienić:

1. Określenie wymagań dotyczących sprzętu, tj. rodzaju procesorów (liczby rdzeni), rozmiaru pamięci RAM, przestrzeni dyskowej, przepustowości sieci, oprogramowania do wirtualizacji.

2. Określenie wymagań dotyczących bezpieczeństwa systemów informatycznych i informacji oraz ochrony prywatności w całym cyklu życia produktu, w tym jurysdykcji4.

3. Określenie harmonogramu (w tym ewentualnie wydzielonych etapów przeznaczonych na uruchomienie usługi i zakończenie współpracy).

4. Określenie granic odpowiedzialności między zamawiającym a wykonawcą (zamawiający może oprzeć się na tzw. stosie SPI5).

5. Zdefiniowanie wymagań SLA, uwzględniając parametry znajdujące się w zakresie odpowiedzialności wykonawcy.

6. Określenie obowiązków dotyczących raportowania wykorzystania infrastruktury (postać raportów, częstotliwość składania).

7. Opisanie zasad rozliczania zgodnie z określonym modelem wynagradzania (np. jako wynagrodzenie za wykorzystanie infrastruktury: procesorów, pamięci RAM, HDD, przepustowości sieci, oprogramowania do wirtualizacji w danym okresie, itp.; tzw. płatności za użycie, pay-per-use).

8. Jeśli zamawiający ma mieć wpływ na parametry świadczonych usług (np. elastycznie określając ich zakres lub konfigurację): wskazanie osób, które są upoważnione do składania w imieniu zamawiającego oświadczeń dotyczących takich zmian, jak również ról tych osób.

Powyższa lista nie jest wyczerpująca. Zamawiający może określić inne wymagania odpowiadające jego uzasadnionym potrzebom, np. zdefiniować wymagania odnośnie zgodności przetwarzania z konkretnymi normami (np. ISO 27000) lub wymagania dotyczące redundancji infrastruktury.

Zagadnienie nr 6.2: wymagania specyficzne dla PaaS

Wśród parametrów, które zamawiający powinien uwzględnić opisując przedmiot zamówienia obejmującego PaaS, należy wymienić:

1. Określenie wymagań i zasad wskazanych dla IaaS w Zagadnieniu nr 6.1.

2. Określenie wymagań dotyczących oprogramowania standardowego, które ma zapewnić wykonawca: systemów operacyjnych, silników baz danych, oprogramowania do wirtualizacji itp.

3. Określenie granic odpowiedzialności między zamawiającym a wykonawcą (zamawiający może oprzeć się na tzw. stosie SPI); zamawiający powinien określić, jakie oprogramowanie jest składnikiem platformy (a zatem za jego zapewnienie i działanie odpowiedzialność ponosi wykonawca), a jakie oprogramowanie nie jest; dotyczy to zwłaszcza oprogramowania pośredniczącego.

4. Opisanie zasad rozliczania zgodnie z określonym modelem wynagradzania (np. jako wynagrodzenie za wykorzystanie infrastruktury np. procesorów, pamięci RAM, HDD,

4 Zamawiający mogą np. odwołać się do zasad opisanych w dokumencie Standardy Cyberbezpieczeństwa Chmur Obliczeniowych – SCCO w ramach zbioru Narodowych Standardów Cyberbezpieczeństwa, przywołanego w Strategii Cyberbezpieczeństwa Rzeczypospolitej Polskiej na lata 2019-2024.

5 Por. Standardy Cyberbezpieczeństwa Chmur Obliczeniowych – SCCO – v. 1.00 w ramach zbioru Narodowych Standardów Cyberbezpieczeństwa, przywołanego w Strategii Cyberbezpieczeństwa Rzeczypospolitej Polskiej na

lata 2019-2024 w rozdziale 4.1 Współdzielona odpowiedzialność za ochronę zasobów modelach chmur obliczeniowych.

przepustowości sieci, oprogramowania do wirtualizacji, oprogramowania standardowego i oprogramowania pośredniczącego w danym okresie, tzw. płatności za użycie, pay-per-use).

Zagadnienie nr 6.3: wymagania specyficzne dla SaaS

Wśród parametrów, które zamawiający powinien uwzględnić opisując przedmiot zamówienia obejmującego SaaS, należy wymienić:

1. Określenie wymagań funkcjonalnych dla aplikacji.

2. Określenie wymagań dotyczących bezpieczeństwa systemów informatycznych i informacji oraz ochrony prywatności w całym cyklu życia produktu.

3. Określenie harmonogramu (w tym ewentualnie wydzielonych etapów przeznaczonych na uruchomienie usługi i zakończenie współpracy).

4. Opisanie zasad rozliczania zgodnie z określonym modelem wynagradzania (np. jako wynagrodzenie za korzystanie z oprogramowania w danym okresie; tzw. płatności za użycie, pay-per-use).

5. Jeśli zamawiający ma mieć wpływ na parametry działania oprogramowania: określenie osób, które są upoważnione do składania w imieniu zamawiającego oświadczeń dotyczących takich zmian, jak również ról tych osób.

Biorąc pod uwagę charakter SaaS, zamawiający nie powinien definiować wymagań dotyczących sprzętu i oprogramowania standardowego, wykorzystywanego przez podmiot zapewniający SaaS (np. procesorów, pamięci RAM, HDD, przepustowości sieci, systemów operacyjnych, silników baz danych, oprogramowania do wirtualizacji).

Rekomendacja ogólna nr 7: opisując przedmiot zamówienia, zamawiający powinien mieć na uwadze zarówno zasadę konkurencyjności postępowania, jak i przebieg realizacji zamówienia

Niejednoznaczny lub niewyczerpujący opis przedmiotu zamówienia nie tylko zagraża konkurencyjności postępowania, ale także zwiększa ryzyko sporów między stronami już po udzieleniu zamówienia. Na rynku informatycznym istotna część sporów pomiędzy wykonawcami, a zamawiającymi dotyczy odmiennego rozumienia wymagań przez obie strony, czy też rozbieżności dotyczących tego, czy wykonawca ma obowiązek spełnić dane świadczenie.

Zagadnienie nr 7.1: zamawiający może wskazać w opisie przedmiotu zamówienia istotne dla niego cechy przedmiotu zamówienia

Zakaz opisu przedmiotu zamówienia poprzez wskazanie na konkretny znak towarowy, patent, pochodzenie, źródło czy szczególny proces nie oznacza konieczności nabycia przez zamawiającego produktów czy usług informatycznych nieodpowiadających jego potrzebom, zarówno co do jakości, funkcjonalności czy wymaganych parametrów technicznych.

Należy zwrócić w tym miejscu uwagę na przepis art. 99 ust. 5 PZP, który stanowi, że przedmiot zamówienia można opisać przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli zamawiający nie może opisać przedmiotu zamówienia w wystarczająco precyzyjny i zrozumiały sposób, a wskazaniu takiemu towarzyszą wyrazy „lub równoważny”. Jeżeli przedmiot zamówienia zostanie opisany w sposób wskazany w przywołanym wyżej przepisie, zamawiający zobowiązany jest wskazać w opisie przedmiotu zamówienia kryteria stosowane w celu oceny równoważności (art. 99 ust. 6 PZP).

IV. NIEDYSKRYMINACYJNY OPZ, CZYLI ZASADY KONKURENCYJNOŚCI I RÓWNEGO TRAKTOWANIA WYKONAWCÓW

Podstawowe zasady dotyczące opisywania przedmiotu zamówienia nie różnią się zasadniczo od tych, które przewidywała ustawa obowiązująca do 2020 r., choć pewnej zmianie uległo brzmienie opisujących je przepisów. W art. 99 ust. 4 PZP przewidziano zakaz opisywania przedmiotu zamówienia w sposób, który mógłby utrudniać uczciwą konkurencję. Naruszeniem tego zakazu może być wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charak teryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli mogłoby to doprowadzić do uprzywilejowania lub wyeliminowania niektórych wykonawców lub produktów. Nie jest to jednak wyczerpujący katalog przypadków, w których opis przedmiotu zamówienia ma charakter dyskryminacyjny.

Z art. 99 ust. 4 PZP nie wynika, że zamawiający ma obowiązek całkowitego dostosowania się do tego, jakiego rodzaju dostawy lub usługi chcieliby zaoferować potencjalni wykonawcy. Zamawiający ma prawo definiować przedmiot zamówienia uwzględniając swoje rzeczywiste, obiektywnie uzasadnione potrzeby. W postępowaniu o udzielenie zamówienia klasycznego o wartości równej lub przekraczającej progi unijne, zamawiający publiczny zdefiniowanie potrzeb musi co do zasady poprzedzić analizą potrzeb i wymagań przeprowadzoną zgodnie z art. 83 PZP. W pozostałych przypadkach, przeprowadzenie analogicznego procesu także może być uzasadnione (zob. Xxx I wytycznych, s. 3 i nast.).

Zgodnie z treścią art. 129 ust. 2 PZP (dotyczy postępowania o udzielenie zamówienia klasycznego o wartości równej lub przekraczającej progi unijne) Zamawiający może udzielić zamówienia w trybie przetargu nieograniczonego i przetargu ograniczonego, a w pozostałych trybach zamawiający może udzielić zamówienia w przypadkach określonych w ustawie. Stosowanie trybów niekonkurencyjnych (negocjacje bez ogłoszenia, zamówienie z wolnej ręki) powinno mieć miejsce jedynie wyjątkowo i nie powinno być efektem zaniedbań zamawiającego. Podobnie nie powinno dochodzić do sytuacji, w których w postępowaniu prowadzonym w trybie konkurencyjnym wskutek możliwych do uniknięcia zaniedbań zamawiającego nie istnieje rzeczywista konkurencja. Dlatego zamawiający już na etapie tworzenia opisu przedmiotu zamówienia powinni uwzględnić możliwe zagrożenia dla konkurencyjności zamówień. Chodzi o zagrożenia występujące zarówno w danym postępowaniu, jak i przyszłych postępowaniach dotyczących tego samego rozwiązania informatycznego.

Zagadnienia związane z tzw. dyskryminacją bezpośrednią, czyli opisywaniem przedmiotu zamówienia przez wskazanie znaków towarowych, patentów, pochodzenia, źródła lub szczególnego procesu, są ściśle związane z zasadami formułowania wymagań dotyczących równoważności (art. 99 ust. 5 i 6 PZP), które omówiono w rozdziale V [Kryteria stosowane w celu oceny równoważności]. Niniejszy rozdział obejmuje przede wszystkim te zagadnienia związane z zapewnieniem konkurencyjności postępowania, które odnoszą się do unikania tzw. dyskryminacji pośredniej, czyli posługiwania się wymaganiami technicznymi i jakościowymi preferującymi konkretnego wykonawcę lub producenta albo konkretny produkt.

Rekomendacja ogólna nr 8: zamawiający powinien opisywać przedmiot zamówienia w oparciu o rzetelnie ustalone i uzasadnione potrzeby

Zamawiający powinien udzielać zamówień w sposób efektywny, czyli tak, aby uzyskać jak najlepszą jakość świadczeń wykonawcy w ramach środków, które zamawiający może przeznaczyć na jego realizację, a jednocześnie uzyskać jak najlepsze efekty możliwe do uzyskania w stosunku do poniesionych nakładów (art. 17 ust. 1 PZP). Opis przedmiotu zamówienia, który nie uwzględnia rzeczywistych i uzasadnionych potrzeb zamawiającego, prowadzi do udzielenia zamówienia w sposób sprzeczny z zasadą efektywności. Można w tym zakresie wskazać na następujący przykład: jeśli zamawiający zamierza wdrożyć nowy system informatyczny w modelu On-premise, to pierwotne zamówienie z reguły będzie udzielone w trybie konkurencyjnym (art. 129 ust. 2 PZP). Jeśli na tym etapie zamawiający nie uwzględni w opisie przedmiotu zamówienia możliwych do przewidzenia zmian lub rozszerzeń, pogorszy swoją sytuację w przyszłości, ponieważ kolejne zamówienia dotyczące tego samego systemu będą udzielane w zupełnie innej sytuacji. Wówczas uprzywilejowaną sytuac ję będzie

miał pierwotny wykonawca systemu, przez co kolejne zamówienia dotyczące brakujących funkcjonalności będą udzielane w warunkach niedoskonałej lub wręcz pozornej konkurencji. Jeżeli zamawiający zidentyfikował potrzebę, ale nie podjął ostatecznej decyzji o zamówieniu, powinien rozważyć zastosowanie prawa opcji (por. art. 441 PZP).

Rekomendacja szczegółowa nr 8.1: zamawiający powinien zwrócić szczególną uwagę na formułowanie wymagań funkcjonalnych i wymagań dotyczących wykorzystania określonej technologii

Problem opisywania wymagań funkcjonalnych i wymagań dotyczących zastosowania określonych technologii należy do najbardziej złożonych w kontekście zapewnienia konkurencyjności postępowania. Trudno w tym przypadku sformułować ogólne wnioski. Jest to jednak element decydujący o tym, czy opis przedmiotu zamówienia został 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ę równie istotnie, jak posłużenie się znakiem towarowym.

Zamawiający powinien zwrócić szczególną uwagę na wymagania odwołujące się do technologii i protokołów komunikacji, które mają tzw. charakter własnościowy, a zatem ich dokumentacja nie jest powszechnie dostępna, a możliwość ich implementacji zależy od nawiązania współpracy z producentem. Zamawiający nie powinien konstruować wymagań w taki sposób, że o możliwości złożenia oferty będzie w praktyce decydowała wola podmiotu trzeciego, w szczególności zainteresowanego określonym wynikiem postępowania.

Zamawiający powinien także zweryfikować, czy stawiane przez niego wymagania nie są nadmiernie rygorystyczne w stosunku do obiektywnie uzasadnionych potrzeb. Sformułowanie zbyt daleko idących wymagań ma negatywny wpływ nie tylko na konkurencyjność postępowania, ale także na efektywność ekonomiczną udzielonego zamówienia, skoro zamawiający „przepłaca” za dostawy lub usługi, których obiektywnie nie potrzebuje.

Rekomendacja szczegółowa nr 8.2: zamawiający powinien zwrócić szczególną ostrożność tworząc wymaganie oprogramowania Commercial-off-the-Shelf

Zamawiający wymagają niekiedy, aby oferowane oprogramowanie było tzw. oprogramowaniem „z półki” (Commercial-off-the-Shelf lub COTS). Tego typu wymaganie w niektórych przypadkach może prowadzić do ograniczenia konkurencji. Takie ryzyko występuje w szczególności w przypadku zamówień na systemy wdrażane w modelu On-premise, gdy zamawiający wymaga, aby specyficzna funkcjonalność była dostępna w standardowej wersji oprogramowania, mimo że w rzeczywistości może zostać wykonana w trakcie realizacji zamówienia. Tego typu wymaganie często nie jest uzasadnione potrzebami zamawiającego, uprzywilejowuje określonego wykonawcę lub producenta i uniemożliwia zaoferowanie innych dostępnych na rynku rozwiązań, wymagających pewnego dostosowania. Zamawiający powinien zachować szczególną ostrożność przy formułowaniu wymagań, według których oferowane oprogramowanie powinno być dostępne na rynku przez określony czas przed składaniem ofert. Istnieje wówczas poważne ryzyko arbitralnego ograniczenia konkurencji, szczególnie mając na uwadze ograniczony wpływ wykonawców niebędących producentami oprogramowania na decyzje producentów dotyczące cyklu życia produktów, ewentualnych zmian nazwy, wprowadzania nowy ch wersji itp.

Rekomendacja szczegółowa nr 8.3: zamawiający powinien każdorazowo ocenić proporcjonalność swoich wymagań dotyczących certyfikatów

Certyfikaty potwierdzające zgodność oferowanych dostaw lub usług z określonymi normami mogą być dla zamawiającego przydatnym narzędziem weryfikacji świadczeń. Zamawiający powinien jednak każdorazowo ocenić proporcjonalność swoich wymagań. Szczególnie ryzykowne jest wymaganie, aby wykonawca dysponował specyficznym zestawem kilku certyfikatów albo certyfikatem, który ma charakter „niszowy”. Ocena takiego wymagania musi być dokonywana indywidualnie w każdym przypadku, jednak zamawiający wymagający certyfikatów powinien zawczasu rozważyć, jakie

obiektywne potrzeby stoją za wymaganiem i jaki wpływ na konkurencyjność postępowania będzie miało wymaganie.

Rekomendacja szczegółowa nr 8.4: zamawiający powinien formułować takie wymagania dotyczące lokalizacji przetwarzania danych w przypadku zamówień obejmujących usługi świadczone w ośrodkach przetwarzania danych (np. chmura obliczeniowa, kolokacja), które uzasadnione są obiektywnymi potrzebami zamawiającego wynikającymi z przepisów prawa lub przyjętych standardów

Wymaganie, aby przetwarzanie danych odbywało się na terenie Europejskiego Obszaru Gospodarczego, Unii Europejskiej lub w Polsce może być uzasadnione obiektywnymi potrzebami zamawiającego wynikającymi z przepisów prawa lub przyjętych standardów. W wielu przypadkach nieuzasadnione będzie jednak dokładniejsze narzucanie lokalizacji geograficznej (np. przez wskazanie obszaru w określonym promieniu od siedziby zamawiającego, w którym ma być centrum przetwarzania danych wykorzystane do świadczenia IaaS). Jeżeli zamawiającemu zależy na uzyskaniu odpowiednich parametrów dotyczących rozwiązania, powinien osiągać ten cel formułując wprost wymagania dotyczące wydajności, szybkości połączenia itp.

Konieczne jest uwzględnienie przez zamawiającego kwestii związanych z cyberbezpieczeństwem i bezpieczeństwem państwa. W tym zakresie odesłać należy do dokumentu pt.: „Narodowe Standardy Cyberbezpieczeństwa. Standardy Cyberbezpieczeństwa Chmur Obliczeniowych (SCCO) v.1.00”.

Rekomendacja szczegółowa nr 8.5: zamawiający powinien zweryfikować dostępne na rynku modele dystrybucyjne i licencyjne, które mogą mieć zastosowanie do nabywanych produktów

Produkty i rozwiązania informatyczne są oferowane w różnych modelach prawnych i biznesowych. W szczególności ta sama funkcjonalność może być zapewniona zamawiającemu bądź poprzez nabycie oprogramowania wraz z majątkowymi prawami autorskimi do niego, poprzez udzielenie licencji na korzystanie z oprogramowania lub poprzez zapewnienie korzystania z oprogramowania w modelu SaaS. Różni producenci stosują modele dystrybucyjne zróżnicowane zarówno co do konstrukcji prawnej, jak i biznesowej. Na rynku informatycznym w szczególności występują sytuacje, w których przedmiotem świadczenia jest rozwiązanie o charakterze standardowym, a podmiot zainteresowany zawarciem umowy z zamawiającym nie jest jednocześnie producentem tego rozwiązania. Taki scenariusz może ziścić się w różnego rodzaju projektach. Przykładowo, może wystąpić w przypadku dostaw sprzętu komputerowego (sprzedawca nie musi być producentem świadczącym gwarancję), dostaw standardowego oprogramowania komputerowego (wykonawca często nie jest uprawniony do udzielenia bezpośrednio zamawiającemu licencji na korzystanie z oprogramowania) czy niektórych usług chmurowych (wykonawca biorący udział w postępowaniu nie zawsze dysponuje infrastrukturą niezbędną do ich świadczenia).

Biorąc pod uwagę powyższe zróżnicowanie, Zamawiający powinien uwzględnić fakt, że rozwiązania dostępne w różnych modelach prawnych lub biznesowych mogą być względem siebie w pełni komplementarne, a wskazanie konkretnego modelu jako wymaganego, może okazać się dyskryminacyjne. Tym samym, by uniknąć nieuzasadnionej eliminacji z postępowania poszczególnych produktów poprzez narzucenie danego modelu Zamawiający powinien przeanalizować dostępne modele licencyjne i biznesowe i odpowiednio ukształtować dokumentację postępowania. Zamawiający powinien w szczególności podjąć decyzję, czy zasadne jest wymaganie, by kluczowe świadczenie było realizowane bezpośrednio przez wykonawcę. Zaletą takiego rozwiązania z perspektywy zamawiającego jest zawarcie umowy z podmiotem mającym spełnić to świadczenie, a nie jedynie z pośrednikiem. Jednocześnie z reguły postawienie takiego wymagania prowadzi do zmniejszenia liczby wykonawców zdolnych do złożenia oferty. Z uwagi na różnorodność stanów faktycznych nie można tu sformułować uniwersalnej reguły co do dopuszczalności omawianego wymagania. Kluczową kwestią jest jednak podjęcie przez zamawiającego świadomej decyzji, w oparciu o znajomość rynku oraz ocenę uzasadnionych potrzeb.

Rekomendacja ogólna nr 9: zamawiający powinien dążyć do zapewnienia, aby konkurencja w postępowaniu miała charakter międzymarkowy, a nie wewnątrzmarkowy

Przez konkurencję międzymarkową należy rozumieć konkurencję pomiędzy różnymi producentami, natomiast konkurencja wewnątrzmarkowa odbywa się pomiędzy podmiotami oferującymi produkty tego samego producenta. Jeżeli zamawiający przewiduje wdrożenie systemu informatycznego od podstaw, ponieważ nie dysponuje jeszcze takim rozwiązaniem albo zamierza zastąpić dotychczasowe, przestarzałe rozwiązania, zasadą powinno być opisywanie przedmiotu zamówienia w taki sposób, aby konkurencja odbywała się pomiędzy wykonawcami oferującymi rozwiązania różnych producentów. Ograniczenie konkurencji może być uzasadnione, jeśli wynika z obiektywnych uwarunkowań, takich jak potrzeba zapewnienia kompatybilności nowego systemu z systemem funkcjonującym już u zamawiającego.

Rekomendacja szczegółowa nr 9.1: zamawiający powinien uwzględnić w zamówieniu na oprogramowanie także usługi serwisowe i rozwojowe

Pierwotne zamówienie powinno uwzględniać także usługi dotyczące oprogramowania, związane z jego utrzymaniem i rozwojem (chyba że zamawiający zamierza w przyszłości udzielać zamówień na te usługi w trybie konkurencyjnym i jest to możliwe). W ten sposób zamawiający zapewnia, że międzymarkowa konkurencja obejmuje maksymalnie szeroki zakres świadczeń. Jest to szczególnie istotne w przypadku oprogramowania standardowego (Commercial-off-the-Shelf), w odniesieniu do którego producenci zachowują monopol faktyczny i prawny na świadczenie usług związanych z usuwaniem błędów czy aktualizacjami.

Rekomendacja szczegółowa nr 9.2: zamawiający powinien określić taki termin realizacji zamówienia, który daje wykonawcy realną możliwość wykonania zamówienia

W przypadku zamówień obejmujących rozbudowę istniejącego systemu, jeżeli zamawiający dopuszcza alternatywnie wdrożenie nowego systemu od podstaw (zob. rozdział V [Kryteria stosowane w celu oceny równoważności]), nadmierne skrócenie terminu na wdrożenie może prowadzić do utrudnienia uczciwej konkurencji, jeśli zamyka wykonawcom oferującym wdrożenie nowego systemu możliwość terminowej realizacji zamówienia.

Jeżeli zamawiający dopuszcza zaoferowanie wdrożenia nowego systemu, powinien sformułować wymagania w taki sposób, aby wykonawca decydujący się na złożenie oferty o takiej treści dysponował realną możliwością wykonania zamówienia.

Zagadnienie nr 9.1: zamawiający powinien opisywać przedmiot zamówienia określając oczekiwane efekty dotyczące współdziałania komponentów

Jeżeli istnieje po stronie zamawiającego obiektywna potrzeba zapewnienia zgodności między nowym rozwiązaniem, a rozwiązaniami już wykorzystywanymi, zamawiający powinien opisywać przedmiot zamówienia określając oczekiwane efekty dotyczące współdziałania komponentów. Dopiero jeżeli okaże się to niemożliwe (zob. art. 99 ust. 5 PZP), uzasadnione jest przygotowanie opisu ze wskazaniem znaku towarowego lub pochodzenia. Niektóre przykłady takich sytuacji zostały opisane w rozdziale V.

V. KRYTERIA STOSOWANE W CELU OCENY RÓWNOWAŻNOŚCI

Wprowadzenie

Prawo zamówień publicznych utrzymuje oczywiście zasadę, zgodnie z którą przedmiotu zamówienia nie można opisywać w sposób, który mógłby utrudniać uczciwą konkurencję. Jest to zakaz stanowiący element jednego z fundamentów aksjologicznych prawa zamówień publicznych, czyli zasady konkurencyjności. Szczególnym przypadkiem niedozwolonego działania, wprost wskazanym w PZP, jest opisywanie przedmiotu zamówienia za pomocą znaków towarowych, patentów, pochodzenia lub innych parametrów czy cech, które są właściwe dla konkretnych produktów lub usług. Zakaz takiego sformułowania opisu przedmiotu zamówienia wyrażony jest w art. 99 ust. 4 PZP, zgodnie z którym przedmiotu zamówienia nie można opisywać w sposób, który mógłby utrudniać uczciwą konkurencję, w szczególności przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli mogłoby to doprowadzić do uprzywilejowania lub wyeliminowania niektórych wykonawców lub produktów.

Od powyższej zasady ustawa PZP przewiduje wyjątek.

Stosownie do art. 99 ust. 5 PZP przedmiot zamówienia można opisać przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli zamawiający nie może opisać przedmiotu zamówienia w wystarczająco precyzyjny i zrozumiały sposób, a wskazaniu takiemu towarzyszą wyrazy „lub równoważny”. Przepis ten stanowi kontynuację zasady przewidzianej w art. 29 ust. 3 DPZP) i ma na celu umożliwienie zamawiającym sporządzenie opisu przedmiotu zamówienia wówczas, gdy z okoliczności danego zakupu wynika brak możliwości lub istotna trudność w dokonaniu opisu przedmiotu zamówienia w zobiektywizowany sposób. Nie sposób bowiem wykluczyć sytuacji, w której zamawiający, działając w interesie swojej organizacji, wręcz powinien sporządzić opis przedmiotu zamówienia wskazując na konkretny produkt. Ustawodawca, dostrzegając taką możliwość, stwierdza równocześnie, że niezależnie od realiów danego zamówienia, a w szczególności niezależnie od faktycznej celowości czy możliwości dokonania zakupu produktu innego niż wprost wskazany przez zamawiającego, konieczne jest dopuszczenie produktów równoważnych do opisanych za pomocą znaków towarowych czy innych oznaczeń jednoznacznie identyfikujących produkt. Jest to oczywista konsekwencja zasad konkurencyjności i równego traktowania wykonawców.

Na gruncie DPZP ukształtował się dość jednolity pogląd, iż przewidziane przepisem dodanie do danego elementu opisu przedmiotu zamówienia wyrazów „lub równoważny” nie jest wystarczające. Przede wszystkim z zasad równego traktowania wykonawców oraz określoności przedmiotu zamówienia wywiedziono dodatkowy obowiązek przewidzenia przez zamawiającego kryteriów równoważności. W orzecznictwie podkreślano, że konieczne jest takie opisanie tych kryteriów, by zarówno zamawiający, jak i wykonawcy, byli w stanie bez wątpliwości stwierdzić, jakie konkretnie rozwiązanie będzie mogło być uznane za równoważne. Zasada ukształtowana w dotychczasowej doktrynie i orzecznictwie znalazła odzwierciedlenie w przepisie art. 99 ust. 6 PZP, zgodnie z którym, jeżeli przedmiot zamówienia został opisany w sposób, o którym mowa w ust. 5, zamawiający wskazuje w opisie przedmiotu zamówienia kryteria stosowane w celu oceny równoważności.

Ustawa nie przewiduje żadnych wytycznych co do sposobu opisu kryteriów stosowanych w celu oceny równoważności (dalej zwanych „kryteriami równoważności”), przy czym z uwagi na fakt, iż – jak zaznaczono powyżej – przepis art. 99 ust. 6 PZP jest podniesieniem do rangi przepisu ustawy dotychczasowej zasady doktrynalnej, należy przyjąć, że aktualność zachowuje dorobek orzeczniczy w tym zakresie.

Specyfika zamówień informatycznych

Problem wskazywania w opisie przedmiotu zamówienia konkretnych znaków towarowych jest szczególnie widoczny w wypadku zamówień na systemy informatyczne. Specyfika cyklu życia rozwiązań IT polega w szczególności na tym, że systemy informatyczne podlegają aktualizacjom, zmianom, rozszerzeniom, rozbudowom, modyfikacjom, etc. System informatyczny ma bowiem zapewnić realizację właściwych dla danej organizacji procesów, a procesy te ulegają zmianom z uwagi na zmieniające się otoczenie prawne, ze względu na zmiany organizacyjne czy w związku z postępem

technologicznym. Standardowe oprogramowanie, zapewniające realizację dowolnych funkcjonalności w organizacji, podlega ciągłemu rozwojowi i doskonaleniu. Jest w szczególności oczywiste, że producenci w określonym cyklu produkcyjnym zapewniają zarówno drobne poprawki w istniejącym oprogramowaniu, jak i udostępniają jego nowe wersje, które są następcami technologicznymi poprzednich. Jest też faktem, że produkty zastąpione nowszymi, z czasem przestają być przez producentów wspierane, czego konsekwencją jest brak możliwości aktualizacji czy usuwania błędów

„starego” oprogramowania oraz brak gwarancji jego kompatybilności z innymi produktami

informatycznymi.

Kolejnym uwarunkowaniem, które musi być wzięte pod uwagę, jest konieczność zapewnienia spójności funkcjonowania infrastruktury informatycznej składającej się z komponentów różnych producentów. Jakkolwiek postępująca standaryzacja i dążenie do interoperacyjności powodują, że zdolność współpracy urządzeń czy oprogramowania różnych producentów, jest dziś istotnie większa, niż jeszcze kilka lat temu, to jednak ciągle nie sposób uniknąć sytuacji, w których osiągnięcie zamierzonego celu możliwe jest wyłącznie przy zastosowaniu konkretnego produktu czy konkretnej technologii. Wynika to z naturalnego faktu, iż producenci złożonych rozwiązań informatycznych tworzą je w określonych technologiach i nie jest dla nich priorytetem, by zapewnić maksymalną otwartość tych rozwiązań na współpracę z produktami konkurencyjnymi. Jest przy tym oczywiste, że zamawiający powinien dążyć do tego, by budowane przez niego środowisko informatyczne w maksymalnym możliwym stopniu zapewniało możliwość jego utrzymania czy rozbudowy w trybach konkurencyjnych. Z uwagi na fundamentalne zasady udzielania zamówień publicznych, wskazane jest w szczególności takie dobieranie dostępnych technologii czy rozwiązań, by nie determinowały one dalszych zakupów poprzez brak interoperacyjności i możliwości integracji z produktami innych producentów. Nie sposób jednak wykluczyć sytuacji, w której nawet pomimo dołożenia przez zamawiającego najwyższej staranności w celu uniknięcia zagrożeń wynikających z uzależnienia od danej technologii czy produktu, kolejne zakupy rozwiązań informatycznych będą jednak w jakiś sposób zdeterminowane poprzednimi.

Należy podkreślić, że dopuszczenie opisu przedmiotu zamówienia wskazującego na konkretny produkt, pod warunkiem dopuszczenia rozwiązań równoważnych, nie może być narzędziem służącym ograniczaniu konkurencji. Jest to odstępstwo od ogólnej zasady konkurencyjnego i zobiektywizowanego opisywania przedmiotu zamówienia, które może być zastosowane nie za każdym razem, ale tylko wtedy, gdy okoliczności danego zamówienia to usprawiedliwiają (gdy zamawiający „nie może opisać przedmiotu zamówienia w wystarczająco precyzyjny i zrozumiały sposób”). Sięganie do tej metody musi być więc w poszczególnych przypadkach rzeczywiście uzasadnione.

Jako przykłady z praktyki udzielania zamówień, dotyczące posłużenia się w opisie przedmiotu zamówienia znakiem towarowym lub innym oznaczeniem identyfikującym produkt można wskazać zaistnienie następujących okoliczności (z zastrzeżeniem, że każdy stan faktyczny należy badać indywidualnie i ocenić, czy nie było możliwe opisanie przedmiotu zamówienia w sposób wystarczająco precyzyjny i zrozumiały):

1. Zakup urządzenia lub oprogramowania, które jako jedyne ma zdolność współpracy z innymi urządzeniami czy oprogramowaniem posiadanymi przez zamawiającego.

2. Podniesienie wersji (upgrade) istniejącego rozwiązania.

3. Konsolidacja uprawnień licencyjnych w ramach danej infrastruktury informatycznej (nabycie nowej wersji oprogramowania na nowych, jednolitych warunkach w przypadku, gdy Zamawiający dysponuje różnymi produktami, nabywanymi z reguły przez dłuższy okres i na zróżnicowanych warunkach).

4. Przedłużenie subskrypcji i aktualizacja bazy danych w posiadanym oprogramowaniu (np. antywirusowym lub w systemie informacji prawnej).

5. Zakup (w tym przedłużenie) wsparcia producenta dla konkretnego rozwiązania informatycznego.

Trzeba przy tym zwrócić uwagę na rozróżnienie pomiędzy opisem przedmiotu zamówienia, a opisem faktycznych uwarunkowań istniejących u danego zamawiającego. Opisując produkty czy usługi, których zakup jest planowany, zamawiający zmuszony jest oczywiście do stosowania opisywanych w niniejszym rozdziale zasad dotyczących równoważności. Jeżeli jednak zamawiający opisuje w SWZ posiadane przez siebie rozwiązania informatyczne, to jest oczywiste, że nie musi dokonywać tego opisu z pominięciem znaków towarowych czy innych oznaczeń jednoznacznie identyfikujących produkty. Opis posiadanej infrastruktury, jakkolwiek jest oczywiście elementem SWZ, nie jest bowiem jednak opisem przedmiotu zamówienia i jest oczywiste, że zamawiający posiada konkretny produkt, a nie, że posiada

„konkretny produkt lub równoważny”.

Należy podkreślić, że kryteria równoważności stanowią element opisu przedmiotu zamówienia, w związku z czym zamawiający musi przy ich formułowaniu stosować zasady obowiązujące w tym zakresie, to jest przede wszystkim: określoność przedmiotu zamówienia oraz zasadę: konkurencyjności, proporcjonalności oraz równego traktowania wykonawców.

Rekomendacja ogólna nr 10: zamawiający powinien sformułować kryteria równoważności w taki sposób, by nie było wątpliwości, jaki produkt, rozwiązanie czy usługa uznane zostaną za równoważne

Zamawiający powinien zdefiniować kryteria równoważności w taki sposób, by nie było wątpliwoś ci, jaki produkt, rozwiązanie czy usługa uznane zostaną za równoważne do opisanych za pomocą znaków towarowych lub innych określeń jednoznacznie wskazujących na zamawiany przedmiot. Nie jest w szczególności wystarczające przewidzenie w SWZ ogólnikowego stwierdzenia, wskazującego, że ilekroć w SWZ znalazły się znaki towarowe, patenty lub inne oznaczenia tego rodzaju, zamawiający dopuszcza zaoferowanie rozwiązań równoważnych do tak opisanych.

Rekomendacja szczegółowa nr 10.1: zamawiający może sformułować opis równoważności za pomocą listy wymagań

W zależności od danego przypadku, uzasadnione może być dokonanie opisu kryteriów równoważności poprzez wskazanie listy konkretnych wymagań, takich jak wymagania funkcjonalne, parametry wydajnościowe, etc., których spełnienie przez oferowany produkt oznacza spełnienie kryteriów równoważności. Formułując tego rodzaju kryteria równoważności, zamawiający przyjmuje odpowiedzialność za to, że produkt równoważny, który spełni wszystkie postawione wymagania, faktycznie będzie odpowiadał jego uzasadnionym potrzebom, które stały za przyjęciem metody opisu przedmiotu zamówienia z wykorzystaniem znaku towarowego lub innego podobnego oznaczenia. Jest to metoda niewątpliwie czytelna dla wykonawców i niepozostawiająca wątpliwości co do tego, czy dany produkt zostanie uznany za równoważny. Należy jednak zwrócić uwagę na fakt, iż jest to równocześnie metoda wymagająca szczególnej dbałości o poszanowanie zasad konkurencyjności oraz równego traktowania, ponieważ może prowokować do tego, by w bezrefleksyjny sposób przenosić wszystkie cechy produktu opisanego znakiem towarowym na wymagania dla produktu równoważnego. Szerzej na ten temat w Rekomendacji ogólnej nr 12.

Rekomendacja szczegółowa nr 10.2: zamawiający może sformułować opis równoważności poprzez efekt funkcjonalny

Kolejną metodą opisu kryteriów równoważności może być zdefiniowanie jej poprzez wskazanie na konkretny efekt, który ma zostać osiągnięty wskutek dostarczenia rozwiązania równoważnego do opisanego za pomocą znaku towarowego lub innego zbliżonego określenia. Jeżeli przykładowo zamawiający prowadzi dane postępowanie w celu nabycia infrastruktury informatycznej, na której ma zostać zainstalowana konkretna aplikacja lub system informatyczny, to jest oczywiste, że zakładanym celem jest funkcjonowanie tej aplikacji czy systemu. Możliwe jest, że posiadany system jest na tyle specyficzny, że wymusza konkretną technologię nabywanych urządzeń. Jeżeli przykładowo określone oprogramowanie zostało napisane tak, że działa wyłącznie z konkretnym systemem operacyjnym, konkretnego producenta, to możliwa jest sytuacja, w której zamawiający nie ma wyjścia i jeżeli chce

zapewnić funkcjonowanie oprogramowania, to musi kupić urządzenia wyposażone w konkretny system operacyjny. Należy przy tym zaznaczyć, że kwestią zupełnie odrębną jest ocena staranności, którą zamawiający dołożył planując zakupy informatyczne, w celu uniknięcia sytuacji tego rodzaju. Skutki takiej oceny mogą prowadzić do różnych wniosków i konsekwencji (np. na gruncie przepisów o odpowiedzialności za naruszenie dyscypliny finansów publicznych), jednak w tym miejscu opisywany jest jedynie konkretny model stanu faktycznego, a nie przyczyny jego wystąpienia. Biorąc pod uwagę, że potrzebą zamawiającego jest zapewnienie funkcjonowania określonego oprogramowania, nic nie stoi na przeszkodzie, by zamawiający zdefiniował kryterium równoważności w ten sposób, że za sprzęt równoważny zostanie uznany taki, na którym możliwe jest zainstalowanie, skonfigurowanie i uruchomienie określonego oprogramowania. Koniecznym elementem takiego opisu kryterium równoważności jest oczywiście zawarcie w nim informacji dotyczących posiadanego przez zamawiającego oprogramowania. Informacje te muszą być na tyle szczegółowe, żeby umożliwić wykonawcom ocenę możliwości dostarczenia sprzętu, który będzie zdolny do współpracy z tym oprogramowaniem. Zilustrowany powyższym przykładem mechanizm można przekładać oczywiście na inne sytuacje: kryterium równoważności może być zdolność współpracy z posiadanym przez zamawiającego urządzeniem, czy szerzej – infrastrukturą informatyczną. Warunkiem wypełnienia zasady określoności przedmiotu zamówienia będzie w każdym przypadku dostarczenie wykonawcom wszelkich informacji, które umożliwią realną ocenę, czy produkt, który zamierzają zaoferować, będzie zdolny do współdziałania z innymi produktami w zakresie wskazanym przez zamawiającego.

Rekomendacja ogólna nr 11: zamawiający powinien sformułować kryteria równoważności z zachowaniem zasady proporcjonalności

Zasada proporcjonalności nie została wprawdzie przywołana wprost w przepisach dotyczących opisu przedmiotu zamówienia, lecz jest jedną z ogólnych zasad prowadzenia postępowania o udzielenie zamówienia publicznego, wskazanych w art. 16 PZP. Zgodnie z tą zasadą, zamawiający powinien prowadzić postępowanie tak, by stawiane warunki i wymagania były uzasadnione rzeczywistą sytuacją zamawiającego oraz uwarunkowaniami faktycznym dotyczącymi danego przedmiotu zamówienia. Zasada proporcjonalności służy także temu, by nie ograniczać dostępu do zamówienia wykonawcom, którzy są zdolni do jego wykonania.

Opis kryteriów równoważności musi być adekwatny do okoliczności danego przypadku. Celem zamawiającego powinno być osiągnięcie rzeczywistej równoważności nabywanego przedmiotu zamówienia do tego, który opisuje za pomocą znaku towarowego lub innego określenia identyfikującego produkt lub usługę. Należy przy tym podkreślić, że zasada proporcjonalności ma nie tylko ograniczać nadmiernie restrykcyjny opis przedmiotu zamówienia, lecz także ma zapewnić możliwość nabycia przez zamawiającego takich produktów lub usług, które są faktycznie niezbędne dla zaspokojenia jego uzasadnionych potrzeb.

Rekomendacja szczegółowa nr 11.1: zamawiający w opisie równoważności powinien uwzględnić skutki i koszty biznesowe oraz organizacyjne

Często spotykanym problemem jest kwestia zróżnicowania wysiłku zamawiającego, który musi być włożony w realizację danego zamówienia, w zależności od tego, czy będzie ono polegało na nabyciu konkretnego rozwiązania, opisanego za pomocą znaku towarowego, czy też na nabyciu rozwiązania równoważnego.

Przykładem ilustrującym sygnalizowany problem może być zamówienie, którego przedmiotem jest nowa wersja (upgrade) posiadanego oprogramowania. Rzeczywistą potrzebą zamawiającego jest nabycie nowej wersji posiadanego już rozwiązania informatycznego, po to, aby uzyskać oprogramowanie szersze funkcjonalnie, bezpieczniejsze, nieposiadające wad dotychczas wykorzystywanego, etc. Zamówienia takie wpisują się częstokroć w cykl produkcyjny producentów oprogramowania, którzy co jakiś czas publikują nowe, ulepszone, wydajniejsze, stabilniejsze i bezpieczniejsze produkty, będące następcami poprzednich. Od strony faktycznej zamówienie na „upgrade oprogramowania” polega zazwyczaj na zainstalowaniu w istniejącym środowisku nowej wersji oprogramowania, co oznacza minimalny wysiłek organizacyjny po stronie zamawiającego. Użytkownicy korzystają nadal z

oprogramowania dotychczas wykorzystywanego, tylko „ulepszonego” poprzez wykonanie podniesienia wersji do nowszej. Nie jest zazwyczaj konieczne dokonywanie zmian w otoczeniu informatycznym, cały proces podniesienia wersji odbywa się relatywnie szybko i prosto. Od strony formalnej zamówienie takie polega na nabyciu oprogramowania o określonej nazwie handlowej czy numerze katalogowym, czyli na kupieniu nowszej wersji oprogramowania już posiadanego, ale stanowiącej odrębny produkt. Zamawiający w takiej sytuacji, jeżeli nie może sporządzić opisu przedmiotu zamówienia w sposób wystarczająco precyzyjny i zrozumiały, będzie uprawniony do wskazania na konkretny produkt (oprogramowanie konkretnego producenta o określonej nazwie), oraz dopuścić zaoferowanie oprogramowania równoważnego. Zdefiniowanie kryteriów równoważności w takim wypadku wymaga gruntownego przemyślenia. Jeżeli bowiem zamawiający jako produkt równoważny wskaże taki, który posiada takie same funkcjonalności, jak oprogramowanie, które zamierza zmodernizować to w efekcie może otrzymać oferty na oprogramowanie, które wprawdzie jest odpowiednikiem dotychczas posiadanego, ale wymaga wdrożenia. To z kolei oznacza konieczność weryfikacji, czy oprogramowanie równoważne będzie współpracować ze środowiskiem informatycznym zamawiającego, dokonania ewentualnych zmian w tym środowisku, zaprojektowania i przeprowadzenia całego procesu wdrożeniowego, w tym testów, szkoleń użytkowników i migracji danych z dotychczasowego systemu. Koszty tego przedsięwzięcia poniesione zostaną przez zamawiającego, ponieważ wykonawca oferując rozwiązanie równoważne miał zapewnić jedynie to, że pod względem funkcjonalnym oferowany przez niego produkt jest odpowiednikiem dotychczasowego. Z tego względu zamawiający określając kryteria równoważności powinien przemyśleć, jaki konkretnie skutek biznesowy i organizacyjny będzie miało dla niego dostarczenie rozwiązania podstawowego, a następnie określić kryteria równoważności w sposób, który zapewnia uzyskanie takiego samego skutku. W podanym przykładzie podniesienia wersji posiadanego oprogramowania, rozwiązaniem rzeczywiście równoważnym byłoby więc nie tyle dostarczenie oprogramowania identycznego pod względem funkcjonalnym, co dostarczenie takiego oprogramowania wraz z wdrożeniem, w tym szkoleniami, migracją oraz odpowiednimi zmianami w infrastrukturze informatycznej zamawiającego, by zainstalowanie i uruchomienie nowego oprogramowania było możliwe. W takim przypadku konieczne jest precyzyjne zdefiniowanie zakresu przedmiotu zamówienia, w sposób adekwatny do rzeczywistych potrzeb zamawiającego związanych z dostarczeniem produktu podstawowego oraz równoważnego. Należy w szczególności zauważyć, że w tego rodzaju przypadkach może być konieczne sporządzenie dwóch wzorów umów – odrębnie dla rozwiązania podstawowego oraz równoważnego. Oczywiście nasuwa się wniosek, iż wykonawca, który dostarcza rozwiązanie równoważne, będzie w sytuacji mniej korzystnej niż ten, który dostarcza rozwiązanie podstawowe. Jeżeli jednak opis kryteriów równoważności będzie faktycznie proporcjonalny i adekwatny do rzeczywistych potrzeb i sytuacji zamawiającego, to zróżnicowanie takie należy uznać za uzasadnione i dopuszczalne.

Rekomendacja ogólna nr 12: zamawiający powinien sformułować kryteria równoważności z zachowaniem zasad konkurencyjności i równego traktowania wykonawców

Dopuszczenie opisu przedmiotu zamówienia wskazującego na konkretny produkt, pod warunkiem dopuszczenia rozwiązań równoważnych, nie może być narzędziem służącym ograniczaniu konkurencji. Jest to odstępstwo od ogólnej zasady konkurencyjnego i zobiektywizowanego opisywania przedmiotu zamówienia, które może być zastosowane nie za każdym razem, ale wówczas, gdy okoliczności danego zamówienia to usprawiedliwiają (gdy zamawiający „nie może opisać przedmiotu zamówienia w wystarczająco precyzyjny i zrozumiały sposób”). Sięganie do tej metody musi być więc w poszczególnych przypadkach rzeczywiście uzasadnione.

Ponadto, w odniesieniu do kryteriów równoważności znajdują zastosowanie dokładnie te same reguły, które wyznaczają granice zasad konkurencyjności i równego traktowania wykonawców. W orzecznictwie podkreśla się w szczególności, że dopuszczenie równoważności nie może być sprowadzone do fikcji, a celem kryteriów równoważności nie może być wyeliminowanie konkurencji. Formułowanie poszczególnych kryteriów równoważności musi więc uwzględniać uzasadnione i obiektywne potrzeby zamawiającego, a każde z kryteriów powinno być zbadane w celu ustalenia, czy jego celem jest faktycznie zaspokojenie tych potrzeb, czy też wyłącznie zawężenie konkurencji.

Jak zostało opisane w Rekomendacji ogólnej nr 8, zamawiający nie może w opisie przedmiotu zamówienia zawierać elementów, które w sposób nieuprawniony prowadzą do eliminacji z postępowania niektórych wykonawców lub produktów, co jest oczywistym skutkiem poszanowania zasad konkurencyjności i równego traktowania wykonawców. W doktrynie i orzecznictwie podkreśla się, że granicą zasady konkurencyjności postępowania są uzasadnione potrzeby zamawiającego, które mogą w szczególności prowadzić do ograniczenia możliwej liczby wykonawców czy rodzaju oferowanych przez nich świadczeń. Zasada ta znajduje zastosowanie także w odniesieniu do opisu kryteriów równoważności. Należy przy tym podkreślić, że obowiązkiem zamawiającego jest dobór takich kryteriów, które są rzeczywiście konieczne z uwagi na obiektywne i istotne potrzeby zamawiającego. Jeżeli więc zamawiający wskazuje, że za rozwiązanie równoważne do danego urządzenia uzna rozwiązanie o określonych cechach, to każda z tych cech powinna być konieczna z punktu widzenia istotnych interesów zamawiającego. Należy w szczególności podkreślić, że opis kryteriów równoważności nie może być bezrefleksyjnym przepisaniem wszystkich cech produktu podstawowego wyspecyfikowanych przez producenta w dokumentacji. Tytułem przykładu – wymaganie, by produkt równoważny posiadał zdolność komunikacji określonym protokołem, może być uznane za nadmiarowe i nieuzasadnione, nawet jeżeli produkt podstawowy posiada taką zdolność. Dopiero gdy zamawiający uzasadni przyczynę postawienia takiego wymagania i z uzasadnienia tego będzie wynikać, że produkt niewspierający określonego protokołu komunikacyjnego nie będzie dla zamawiającego przydatny, np. z uwagi na brak możliwości wykorzystania tego produktu w infrastrukturze zamawiającego, możliwe będzie zaakceptowanie takiego określenia kryteriów równoważności.

VI. ODPOWIEDNIE OPISANIE WYMAGANYCH UPRAWNIEŃ DO KORZYSTANIA Z SYSTEMÓW INFORMATYCZNYCH

Rekomendacja ogólna nr 13: zamawiający powinien szczegółowo opisać w SWZ wymagane i oczekiwane przez niego uprawnienia do korzystania z zamawianego systemu informatycznego oraz elementów składających się na wdrożenie

Z zasad opisanych we wcześniejszych częściach Rekomendacji, a w szczególności z zasady określoności przedmiotu zamówienia zakorzenionej w art. 99 ust. 1 PZP (zob. rozdział III „Określoność przedmiotu zamówienia”) oraz zasady sporządzania niedyskryminacyjnego opisu przedmiotu zamówienia (zob. rozdział IV „Niedyskryminacyjny OPZ, czyli zasady konkurencyjności i równego traktowania wykonawców”) wywodzonej z art. 99 ust. 4 PZP jasno wynika, że opis przedmiotu zamówienia powinien być sporządzony w sposób jasny i przejrzysty, uwzględniać wszelkie wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty, a także nie powinien być on opisany w taki sposób, który mógłby utrudniać uczciwą konkurencję.

W kontekście powyżej wspomnianych zasad, bardzo istotne, a jednocześnie w praktyce powodujące spore trudności, jest odpowiednie opisanie przez zamawiających wymaganych przez nich uprawnień do zamawianych systemów informatycznych. Nie ulega bowiem wątpliwości, że systemy informatyczne, składające się w głównej mierze z programów komputerowych, z którymi zwykle połączone są dodatkowe elementy graficzne czy tekstowe - co do zasady stanowią utwory prawnoautorskie. Tym samym zamawiający, aby przełamać monopol twórcy (uprawnionego z tytułu majątkowych praw autorskich) do korzystania z takiego systemu – powinien w sposób wyraźny i jasno opisany zapewnić sobie możliwość korzystania z zamawianego przez niego systemu informatycznego poprzez odpowiednie opisanie zakresu wymaganych przez niego uprawnień zarówno do dostarczanego oprogramowania jak i innych utworów składających się na zamówienie. Na istotne znaczenie opisania w OPZ kwestii uprawnień do korzystania z utworów wskazuje również art. 99 ust. 7 PZP, który wprost wskazuje, że zamawiający może określić w opisie przedmiotu zamówienia konieczność przeniesienia praw własności intelektualnej lub udzielenia licencji. Warto przy tym jednak podkreślić, że bez znaczenia jest to, czy wymagania te zostaną opisane bezpośrednio w OPZ, czy też stanowić będą, jak zwykle się to dzieje, część istotnych postanowień umownych. Ważne, jest natomiast to, aby wykonawca analizujący SWZ miał jasność co do tego, czego w ramach realizacji zamówienia wymaga od niego zamawiający oraz w jaki sposób zamawiający chce korzystać z dostarczonego w ramach dostawy lub całego procesu wdrożenia systemu informatycznego oraz innych utworów wytworzonych w ramach wdrożenia (np. dokumentacji, instrukcji, analiz itp.).

Zakres uprawnień wymaganych przez zamawiającego od wykonawcy w odniesieniu do zamawianego systemu informatycznego ma bowiem często istotne znaczenie cenotwórcze, a niejednokrotnie może decydować nawet o tym, czy dany wykonawca zdecyduje się na złożenie oferty, czy też zrezygnuje z jej składania. Przykładowo, wymaganie przez zamawiającego tego, że wykonawca przeniesie na zamawiającego majątkowe prawa autorskie do części lub całości dostarczanego oprogramowania składającego się na dostarczany system informatyczny powoduje, że wykonawca w konsekwencji zawarcia umowy na realizację takiego zamówienia utraci prawa do takiego oprogramowania i nie będzie mógł już w przyszłości, na potrzeby realizacji innych projektów informatycznych, go wykorzystywać, co może spowodować po jego stronie decyzję o rezygnacji z udziału w postępowaniu, w którym postanowione są takie wymogi. Podobnie również, istotnym dla wykonawcy czynnikiem cenotwórczym oferty może być to, jakie dokładnie jednostki zamawiającego lub jaki zakres, w tym ilość użytkowników po stronie zamawiającego, ma mieć uprawnienia do korzystania z dostarczanego systemu informatycznego. Z powyższych względów, dla zapewnienia równej konkurencji oraz możliwości odpowiedniego skalkulowania oferty, niezwykle istotne jest, to aby zamawiający przygotowując opis przedmiotu zamówienia na system informatyczny jasno opisali swoje oczekiwania w odniesieniu do uprawnień zamawianego systemu – wprost w OPZ lub IPU.

Warto przy tym wspomnieć, że odpowiednie opisanie uprawnień zamawiającego do zamawianego systemu oraz towarzyszących mu utworów jest nie tylko obowiązkiem zamawiającego wynikającym z PZP, ale również leży w jego najlepiej pojętym interesie. Powyższe wynika z tego, że przepisy prawa

autorskiego pisane są, co do zasady z myślą o ochronie twórcy oraz uprawnionego z tytułu majątkowych praw autorskich. Dlatego też przewidują dosyć szeroki monopol tych podmiotów oraz domyślne regulacje prawne korzystne, co do zasady, właśnie dla twórcy oraz uprawnionego z tytułu majątkowych praw autorskich. Tym samym, dopiero dokładne opisanie przez zamawiającego swoich wymagań co do zakresu korzystania z omawianych utworów, może mu zapewnić taką możliwość. Co więcej, w orzecznictwie, na gruncie poszczególnych przepisów pr. aut., np. w odniesieniu do redagowania sposobów korzystania z utworów prezentowane są poglądy wskazujące na występowanie w prawie autorskim zasady nakazującej interpretowanie wątpliwości interpretacyjnych umowy na korzyść twórcy.

Dlatego też wymagania zamawiającego opisane w OPZ lub IPU powinny być maksymalnie skonkretyzowane i kompletne – aby z jednej strony zapewnić zamawiającemu oczekiwany zakres uprawnień, a z drugiej, pozwolić wykonawcy podjąć decyzję w zakresie złożenia oferty i oszacowania jej ceny.

Rekomendacja szczegółowa nr 13.1: zamawiający powinien odpowiednio i precyzyjnie opisać siatkę pojęciową przy definiowaniu dostarczanych elementów systemu informatycznego

Opisując przedmiot zamówienia dotyczącego systemu informatycznego zamawiający powinien dokładnie wskazać, do jakich elementów dostarczanych w wyniku wdrożenia lub zainstalowania tego systemu chce uzyskać prawa do korzystania. Opisując zakres uprawnień zamawiający powinien w szczególności pamiętać o tym, że w wyniku wdrożenia systemu informatycznego powstaje zwykle nie tylko program komputerowy, ale także innego rodzaju produkty, które również mogą stanowić utwory chronione prawem autorskim, takie jak dokumentacja (w tym przewodniki, analiza przedwdrożeniowa, projekty techniczne, prezentacje), user stories, itp. Tym samym, zamawiający powinien wyraźnie w SWZ wskazać jakie uprawnienia chce uzyskać i do czego konkretnie – pamiętając także o uwzględnieniu dokumentacji i innych utworów niestanowiących programów komputerowych, które będą dostarczane zamawiającemu w ramach realizacji umowy będącej wynikiem przeprowadzonego zamówienia.

Jeśli zamawiający różnicuje zakres uprawnień do poszczególnych elementów zamawianego systemu informatycznego w zależności od tego, kto jest uprawniony z tytułu majątkowych praw autorskich do takich elementów6 lub czasu i celu ich wytworzenia7, powinien wyjaśnić (zdefiniować) pojęcia używane w SWZ, w tym IPU. Chodzi tu o pojęcia takie, jak oprogramowanie niededykowane standardowe (niededykowane), oprogramowanie systemowe, oprogramowanie aplikacyjne, oprogramowanie własne, oprogramowanie podmiotów trzecich, itp. Choć pojęcia te są często używane w kontekście zamówień na wdrożenie systemów informatycznych, nie mają jednego powszechnie przyjętego znaczenia. Dlatego też konieczne jest nadanie im znaczenia w ramach konkretnego postępowania, zgodnie z oczekiwaniami zamawiającego. Ich doprecyzowane zapewnia porównywalność ofert na etapie postępowania, zmniejszając także ryzyko późniejszych sporów na etapie realizacji umowy.

Rekomendacja szczegółowa nr 13.2: zamawiający powinien jasno wskazać, w odniesieniu do jakich elementów zamawianego systemu informatycznego, oczekuje przeniesienia majątkowych praw autorskich i określić sposoby korzystania z systemu, w tym pola eksploatacji, na których przeniesienie ma nastąpić

Ogólne zasady dotyczące przenoszenia majątkowych praw autorskich opisane zostały w rozdziale 5 pr. aut. zatytułowanym „Przejście autorskich praw majątkowych”. Zgodnie z ogólną regulacją zawartą w art. 53 pr. aut., która ma zastosowanie zarówno do utworów niebędących programami komputerowymi, jak i do programów komputerowych „Umowa o przeniesienie autorskich praw majątkowych wymaga zachowania formy pisemnej pod rygorem nieważności”. Wymogu takiego natomiast prawo autorskie nie

6 Np. na oprogramowanie producenta, oprogramowanie open source, oprogramowanie własne wykonawcy.

7 Np. odrębnie traktując utwory powstałe przed zawarciem umowy z zamawiającym i po tym momencie, lub też uzależniając ich status od tego, czy zostały wytworzone specjalnie na potrzeby danego zamówienia (np. oprogramowania standardowe/niededykowane, oprogramowanie dedykowane/skastomizowane).

przewiduje w przypadku licencji niewyłącznych, czyli takich w których licencjodawca może udzielać wielu tożsamych licencji o tym samym zakresie, co wynika a contrario z art. 67 ust. 5 pr. aut. Jednocześnie zgodnie z zasadą zawartą w art. 65 pr. aut. przyjmuje się, że w braku wyraźnego postanowienia o przeniesieniu praw, uważa się, że twórca udzielił licencji.

Powyższe oznacza, że jeśli oczekiwaniem zamawiającego jest to, aby wykonawca przeniósł na niego majątkowe prawa autorskie, np. w odniesieniu do oprogramowania dedykowanego, powinien jasno i jednoznacznie wskazać w SWZ takie oczekiwanie wraz z wyjaśnieniem co rozumie pod pojęciem oprogramowania dedykowanego (zob. Rekomendację szczegółową nr 13.1) oraz wyraźnym wskazaniem zakresu przeniesienia praw (sposobu korzystania z oprogramowania – o czym poniżej). Co istotne również, ze względu na konieczność zawarcia postanowień dotyczących przeniesienia majątkowych praw autorskich na piśmie, umowa o wykonanie zamówienia publicznego, która jest zawierana pomiędzy stronami w wyniku wyboru oferty danego wykonawcy na piśmie pod rygorem nieważności - powinna wyraźnie wskazywać postanowienia dotyczące przeniesienia majątkowych praw autorskich.

Warto również podkreślić, że do umów przenoszących autorskie prawa majątkowe, jak i umów licencyjnych (wyłącznych oraz niewyłącznych), znajduje zastosowanie art. 41 ust 2 pr. aut., który wskazuje, że „umowa o przeniesienie autorskich praw majątkowych lub umowa o korzystanie z utworu, zwana dalej "licencją", obejmuje pola eksploatacji wyraźnie w niej wymienione.”

W literaturze prawnoautorskiej wskazuje się, że o ile w odniesieniu do „zwykłych” utworów w art. 50 pr. aut. zamieszczono jedynie przykładowy, otwarty katalog ich możliwych pól eksploatacji, o tyle w odniesieniu do programów komputerowych, w art. 74 ust. 4 pr. aut. wskazany został katalog uprawnień do korzystania z utworu, traktowany przez niektórych jako zamknięty katalog pól eksploatacji. Zgodnie z art. 74 ust. 4 pr. aut. autorskie prawa majątkowe do programu komputerowego, obejmują prawo do:

1) trwałego lub czasowego zwielokrotnienia programu komputerowego w całości lub w części jakimikolwiek środkami i w jakiejkolwiek formie; w zakresie, w którym dla wprowadzania, wyświetlania, stosowania, przekazywania i przechowywania programu komputerowego niezbędne jest jego zwielokrotnienie, czynności te wymagają zgody uprawnionego; 2) tłumaczenia, przystosowywania, zmiany układu lub jakichkolwiek innych zmian w programie komputerowym, z zachowaniem praw osoby, która tych zmian dokonała; 3) rozpowszechniania, w tym użyczenia lub najmu, programu komputerowego lub jego kopii.

Zaznaczenia wymaga jednocześnie fakt, że zamawiający zwykle dążą do nabycia majątkowych praw autorskich do poszczególnych elementów systemu w przypadku, w którym chcą nabyć poszczególne części systemu na własność i uzyskać niezależność od wykonawcy, w tym możliwość swobodnego modyfikowania i rozwoju oprogramowania.

Od strony prawnoautorskiej, modyfikacja oprogramowania stanowi przede wszystkim eksploatację oprogramowania, o której mowa w art. 74 ust. 4 pkt 2 pr. aut. Natomiast, zdaniem większości przedstawicieli doktryny jeśli charakter modyfikacji oprogramowania będzie na tyle twórczy, że przesądzi to o powstaniu programu, który może być przedmiotem samodzielnej ochrony, w grę wchodzić będzie również regulacja dotycząca utworów zależnych (czyli tłumaczeń, przeróbek, adaptacji utworów) z art. 2 pr. aut. Zgodnie z art. 2 pr. aut. dla samego tworzenia utworów zależnych w stosunku do utworu pierwotnego nie jest konieczna zgoda właściciela praw autorskich do utworu pierwotnego, natomiast zgody takiej wymaga korzystanie z powstałych utworów zależnych oraz rozporządzanie nimi. W przypadku szczególnej kategorii utworów, jakimi są programy komputerowe, wspomniany art. 74 ust. 4 pkt 2 pr. aut. przesądza, że już samo dokonanie zmiany w oprogramowaniu będzie wymagać zgody twórcy. Dlatego też, nie tylko korzystanie z utworów zależnych, ale już ich wytwarzanie, które nierozerwalnie wiąże się z modyfikacją oprogramowania będzie wymagać zgody właściciela praw autorskich do pierwotnego programu komputerowego. W odniesieniu natomiast do wykonywania praw zależnych, w art. 46 pr. aut. wprowadzono domniemanie, zgodnie z którym „jeżeli umowa nie stanowi inaczej, twórca zachowuje wyłączne prawo zezwalania na wykonywanie zależnego prawa autorskiego, mimo że w umowie postanowiono o przeniesieniu całości autorskich praw majątkowych”. Z przepisu art. 46 pr. aut. wynika wprost, że w razie braku wskazania w umowie przeniesienia majątkowego prawa lub udzielenia licencji na zezwalanie na wykonywanie zależnego prawa autorskiego, zamawiający nie może korzystać z opracowań utworu, czyli dla przykładu: twórczej modyfikacji, tłumaczenia, przeróbki, czy

adaptacji utworu, do którego przysługują mu prawa, ani też wydawać zgody na wykonywanie takich opracowań.

A zatem, w razie uznania danych modyfikacji oprogramowania za utwory zależne, ich stworzenie (czyli samo dokonanie modyfikacji) będzie zależeć od udzielenia prawa na polu eksploatacji wskazanym w art. 74 ust. 4 pkt 2 pr. aut., a ponadto możliwość ich wykorzystania, rozporządzania nimi oraz zezwalania na ich tworzenie przez podmioty trzecie (np. wykonawców zapewniających w przyszłości usługi serwisowe czy rozwojowe), będzie zależna od wyraźnego udzielenia na to zgody w umowie przez producenta programu komputerowego.

W przypadku braku prawa zezwalania na wykonywanie zależnego prawa autorskiego w stosunku do programu komputerowego, zamawiający, również w przypadku, w którym przeniesiono na niego prawo do wykonywania modyfikacji programów (art. 74 ust 4 pkt 2 pr. aut.) nie będzie miał prawa do korzystania z opracowania takiego oprogramowania, czyli do korzystania z twórczej modyfikacji oprogramowania polegającej chociażby na rozbudowie oprogramowania, czy też zmianie architektury oprogramowania.

Z powyższego wynika, że jeśli zamawiający chce nabyć na własność „pełnię autorskich praw majątkowych” do systemu informatycznego lub jego elementów i mieć uprawnienia do swobodnej modyfikacji takiego systemu samodzielnie lub za pomocą osób trzecich, działających na jego zlecenie np. w celu jego rozwoju i utrzymania, powinien zagwarantować sobie w umowie:

• uprawnienie do korzystania z programu komputerowego obejmujące modyfikacje programu komputerowego (art. 74 ust. 4 pkt 2 pr. aut.) oraz

• prawo do zezwalania na wykonywanie praw zależnych (art. 46 pr. aut.) i korzystania ze zmian w programie komputerowym stanowiących opracowanie pierwotnej wersji programu (art. 2 pr. aut.).

Rekomendacja szczegółowa nr 13.3: zamawiający powinien wyraźnie wskazać zakres uprawnień jakie chce realizować w odniesieniu do zamawianego systemu informatycznego, w szczególności poprzez opisanie celu (efektu) jaki chce osiągnąć

Aby uczynić zadość wymaganiom z art. 99 ust. 1 PZP, zamawiający powinien w SWZ w sposób wyraźny i jasny wskazać na zakres uprawnień do korzystania z systemu informatycznego oraz innych utworów wytworzonych w ramach wdrożenia jaki chce uzyskać. Opisując wymagany zakres uprawnień do systemu informatycznego zamawiający może posługiwać się terminologią prawnoautorską, czyli sposobami korzystania z programu komputerowego wymienionymi w art. 74 ust. 4 pr. aut. oraz brzmieniem przepisów art. 46 pr. aut. i art. 2 pr. aut. w zakresie utworów zależnych (zob. Rekomendację szczegółową nr 13.2). Jednocześnie nie ma przeszkód, a wręcz jest to wskazane, aby zamawiający opisując oczekiwany zakres uprawnień do zamawianego systemu opisał własnymi słowami jakiego zakresu uprawnień do zamawianego systemu oczekuje, czyli aby wskazał dokładny cel (efekt) jaki chce osiągnąć. Tym samym, w SWZ zamawiający nie musi odwoływać się do pojęć prawnoautorskich i pól eksploatacji wymienionych w art. 50, czy art. 74 ust. 4 pr. aut., a może opisowo i jasno wyjaśnić co jest jego celem i co planuje z systemem i dokumentacją robić.

Rekomendacja szczegółowa nr 13.4: zamawiający powinien wyraźnie wskazać zakres podmiotów jakie w ramach zamówienia mają uzyskać uprawnienia do korzystania z systemu informatycznego

W związku z bardzo różnymi modelami licencjonowania oprogramowania występującymi na rynku IT oraz sposobami udostępniania oprogramowania do korzystania, a także mając na uwadze przepis art. 67 ust. 3 pr. aut., zgodnie z którym, jeżeli umowa nie stanowi inaczej, licencjobiorca nie może upoważnić innej osoby do korzystania z utworu w zakresie uzyskanej licencji, w ramach opisywania wymaganego zakresu uprawnień do zamawianego systemu IT zamawiający powinien jasno wskazać zakres podmiotów, jakie w ramach zamówienia mają uzyskać uprawnienia do korzystania z systemu informatycznego.

Powyższe oznacza, że zamawiający w ramach OPZ powinien jasno określić wszystkie potencjalne grupy użytkowników zamawianego systemu oraz zakres uprawnień, jakie powinni oni uzyskać. Przykładowo, zamawiający powinien wskazać, czy w ramach zamawianego systemu informatycznego wymaga, aby w ramach zaoferowanej przez wykonawcę ceny uprawnienie do korzystania z systemu uzyskali tylko pracownicy zamawiającego, czy też osoby współpracujące z zamawiającym bez względu na podstawę prawną zawartej umowy, czy z systemu mają też korzystać partnerzy biznesowi zamawiającego lub jednostki współpracujące lub powiązane z zamawiającym, a jeśli to jakie i w jakim zakresie (np. tożsamym z zamawiającym lub węższym).

Rekomendacja szczegółowa nr 13.5: zamawiający powinien wyraźnie wskazać oczekiwania co do zakresu terytorialnego korzystania z systemu informatycznego lub innych utworów

W związku bardzo różnymi modelami licencjonowania oprogramowania występującymi na rynku IT oraz sposobami udostępniania oprogramowania do korzystania, a także mając na uwadze przepis art. 66 pr. aut., zgodnie z którym umowa licencyjna uprawnia do korzystania z utworu na terytorium państwa, w którym licencjobiorca ma swoją siedzibę, chyba że w umowie postanowiono inaczej, zamawiający powinien jasno wskazać wymagania co do zakresu terytorialnego korzystania z systemu informatycznego, dostosowując wymagania do swoich rzeczywistych potrzeb. Tym samym, jeśli oczekiwaniem zamawiającego jest to, aby zamawiający mógł instalować system informatyczny w dowolnym miejscu, w tym, aby system mógł być instalowany w chmurze obliczeniowej – zamawiający powinien jasno wyrazić takie oczekiwanie w SWZ, może mieć ono bowiem znaczenie dla ustalenia ceny przez wykonawcę.

Podobnie również, jeśli oczekiwaniem zamawiającego jest to, aby użytkownicy systemu informatycznego mogli korzystać z systemu – bez względu na ich lokalizację, czyli bez żadnych ograniczeń terytorialnych, to również kwestia ta powinna być wskazana przez zamawiającego w wymaganiach SWZ.

Warto wskazać, że kwestia ta jest istotna nie tylko w przypadku licencji, ale również w przypadku postanowień dotyczących przeniesienia autorskich praw majątkowych. Wskazanie terytorium może bowiem stanowić istotną przesłankę dot. decyzji wykonawcy o złożeniu oferty – jeśli SWZ wskazywać będzie, że przeniesienie ma dotyczyć praw np. na terytorium Polski lub EOG czy UE, wykonawca zachowa prawa pozwalające mu na wykorzystywanie systemu lub innych utworów na terytorium USA czy Azji.

Rekomendacja szczegółowa nr 13.6: zamawiający powinien wyraźnie wskazać moment w jakim uzyskuje uprawnienie do korzystania z dostarczanych mu przez wykonawcę elementów systemu informatycznego lub innych utworów

Bez względu na to, czy zamawiający oczekuje od wykonawcy przeniesienia majątkowych praw autorskich do części lub całości zamawianego systemu informatycznego, czy też oczekuje zapewnienia przez wykonawcę praw do części lub całości zamawianego systemu informatycznego na innej podstawie, istotne jest, aby zamawiający wyraźnie określił moment w jakim te uprawnienia ma uzyskać.

Przykładowo, momentem tym może być dostarczenie poszczególnych elementów systemu informatycznego, odebranie ich przez zamawiającego lub też odebranie całości systemu informatycznego.

Warto przy tym, aby zamawiający miał świadomość tego, że moment nabywania przez niego uprawnień do zamawianego systemu może mieć również wpływ na ocenę sytuacji zamawiającego także w innych aspektach.

Jednocześnie, jeśli zamawiający przewiduje, że nabycie uprawnień do korzystania z systemu informatycznego ma nastąpić dopiero z odbiorem końcowym zamawianego systemu – warto, aby przewidział w ramach wymagań tymczasowe uprawnienie (aż do momentu uzyskania pełnych uprawnień) do korzystania z systemu informatycznego na potrzeby przeprowadzenia testów systemu.

Rekomendacja szczegółowa nr 13.7: zamawiający powinien wyraźnie wskazać czas na jaki mają mu zostać przyznane uprawnienia do korzystania z dostarczanego przez wykonawcę systemu informatycznego lub innych utworów

Jednym z istotnych elementów zakresu uprawnień do korzystania z oprogramowania jest czas , na jaki uprawnienie to jest przyznane. O ile w przypadku przeniesienia majątkowych praw autorskich, prawa te zwykle przenoszone są bezterminowo, o tyle w przypadku licencji, zgodnie z treścią art. 66 ust. 1 pr. aut. w braku odrębnych postanowień umownych umowa licencyjna uprawnia do korzystania z utworu w okresie pięciu lat, a po upływie tego okresu wygasa.

Tym samym, jeśli zamawiający chce sobie zagwarantować korzystanie z oprogramowania oraz innych dostarczanych utworów przez okres dłuższy lub krótszy niż 5 lat – powinien wyraźnie to wskazać w SWZ. Warto przy tym zaznaczyć, że zgodnie z art. 68 ust. 2 pr. aut. licencję udzieloną na okres dłuższy niż pięć lat uważa się, po upływie tego terminu, za udzieloną na czas nieoznaczony. Powyższe oznacza, że w przypadku postawienia wymagania, aby udzielana licencja była dłuższa niż 5 lat, w braku wyraźnych zobowiązań licencjodawcy co do niewypowiadania takiej licencji, licencja taka będzie mogła być wypowiedziana zgodnie z jej terminem wypowiedzenia, a w braku określenia takiego terminu, zgodnie z art. 68 ust. 1 pr. aut. na rok na przód na koniec roku kalendarzowego.

Zaznaczyć również należy, że zgodnie art. 435 ust. 1 pkt 4) PZP licencja na oprogramowanie komputerowe wymieniona została jako wyjątek od zasady ustanowionej w art. 434 ust. 1, (zgodnie z którą umowę o zamówienie publiczne zawiera się na czas oznaczony, nie dłuższy niż 4 lata) i może być zawarta na czas nieoznaczony. Choć art. 435 ust. 1 pkt 4 PZP wskazuje jedynie na oprogramowanie komputerowe, to mając na uwadze względy systemowe oraz celowościowe pojęcie oprogramowania komputerowego na gruncie art. 435 ust. 1 pkt 4 PZP może być rozumiane szeroko i funkcjonalnie włączając w to także inne utwory wbudowane lub funkcjonalnie powiązane z oprogramowaniem, jak również – w szczególnych przypadkach – dokumentację oprogramowania dostarczaną do oprogramowania i niezbędną do korzystania z niego.8.

Na gruncie obowiązujących przepisów prawa polskiego pewne kontrowersje prawne wzbudza to, czy dopuszczalne jest udzielenie licencji na korzystanie z oprogramowania na czas nieoznaczony (licencji bezterminowej), która nie będzie mogła być wypowiedziana. Warto w tym miejscu podkreślić, że kwestia możliwości zawarcia bezterminowej licencji bez prawa do jej wypowiedzenia nie wynika wprost z obowiązujących przepisów prawa, a kwestia możliwości zawierania tzw. „niewypowiadalnych licencji”, czy licencji wieczystych” była dotychczas kwestionowana przez niektórych w doktrynie prawa – wobec brzmienia art. 3651 Kodeksu cywilnego, zgodnie z którym „Zobowiązanie bezterminowe o charakterze ciągłym wygasa po wypowiedzeniu przez dłużnika lub wierzyciela z zachowaniem terminów umownych, ustawowych lub zwyczajowych, a w razie braku takich terminów niezwłocznie po wypowiedzeniu” Z treści przepisu tego wywodzono bowiem generalną zasadę prawa cywilnego – braku możliwości zawierania zobowiązań bezterminowych o charakterze ciągłym bez możliwości ich wypowiedzenia (zakaz zawierania tzw. stosunków niewolniczych).

Kwestia możliwości udzielenia przez producentów oprogramowania na gruncie prawa polskiego,

„wieczystych licencji” budziła wiele kontrowersji. Jednocześnie gospodarcza potrzeba istnienia tego typu stosunków prawnych wydaje się być bardzo duża, co potwierdza zwłaszcza ich duża popularność i powszechność w zachodnich systemach prawnych. Producentom oprogramowania zależy bowiem zwykle na tym, żeby nie pozbywać się majątkowych praw autorskich do oprogramowana, a udzielać niewyłącznych licencji na korzystanie z oprogramowania – tak aby mogli oni sprzedać stworzone przez

8 Warto wskazać, że szeroka wykładnia pojęcia „oprogramowania” i rozumienia go w sposób holistyczny i funkcjonalny, obejmujący jego funkcjonalne części składowe, takie jak: kod źródłowy, opis procedur operacyjnych, zestawienie danych w informacjach konwersacyjnych i dialogowych oraz kod wynikowy i interfejs została zaproponowana także na gruncie przepisów prawa podatkowego w Objaśnieniach podatkowych z dnia 15 lipca

2019 r. dotyczących preferencyjnego opodatkowania dochodów wytwarzanych przez prawa własności intelektualnej – IP BOX, zob. xxxxx://xxx.xxx.xx/xxx/xxxxxxx/xxxxxxxxxxx-xxxxxxxxx-xxx-xxxxxxxxxxxxxxx- opodatkowania-dochodow-wytwarzanych-przez-prawa-wlasnosci-intelektualnej-ip-box, s. 37

siebie oprogramowanie wielu różnym podmiotom. Dla zamawiających (licencjobiorców) kluczowe jest z kolei zapewnienie sobie trwałości i pewności korzystania z nabywanego oprogramowania. Te dwa kluczowe oczekiwania gospodarcze spełnia właśnie bezterminowa licencja bez możliwości jej wypowiedzenia.

Kwestia dopuszczalności możliwości udzielenia niewypowiadalnej, czyli „dożywotniej” licencji, zaakceptowana została częściowo w doktrynie i dostrzeżona została także w orzecznictwie.

Wydaje się jednocześnie, że dopuszczenie możliwości udzielania niewypowiadalnych licencji bezterminowych jest uzasadnione zwłaszcza w przypadku oprogramowania dystrybuowanego przez producentów w modelach wykluczających możliwość przeniesienia majątkowych praw autorskich, w szczególności ze względu na sposób jego wytwarzania, zwykle duże nakłady związane procesem wytwórczym lub też szerokie portfolio odbiorców i klientów.

Kluczowe jest jednak, aby w przypadku oczekiwania zamawiającego dotyczącego uzyskania licencji bezterminowej bez możliwości jej wypowiedzenia, było ono jasno i jednoznacznie wskazane w SWZ.

Rekomendacja szczegółowa nr 13.8: jeśli zamawiający oczekuje wydania przez wykonawcę kodów źródłowych do dostarczanych elementów lub całości systemu informatycznego powinien to jasno i wyraźnie wskazać w SWZ, opisując przy tym wymagania w odniesieniu do przekazywanych kodów źródłowych

Prawo autorskie obejmuje ochroną wszystkie formy wyrażenia programu komputerowego, a zatem zarówno kod źródłowy programu, jak i jego wersję wynikową. Jak wskazał Trybunał Sprawiedliwości Unii Europejskiej: „każda forma wyrażenia programu komputerowego musi być chroniona od chwili, gdy jej odtworzenie prowadziłoby do odtworzenia samego programu, pozwalając w ten sposób komputerowi na wypełnienie jego funkcji” (Wyrok Trybunału Sprawiedliwości z dnia 22 grudnia 2010 r. w sprawie C-393/09 Bezpečnostní softwarová asociace, C-393/09, Zbiór Orzeczeń 2010 I-13971).

Jednocześnie, z uwagi na fakt, że kod wynikowy nie jest odrębnym przejawem twórczości, a jedynie przetworzoną przez komputer formą kodu źródłowego, w rozumieniu prawa autorskiego te dwie postacie programu komputerowego traktowane są jako jeden utwór. Dlatego też kod wynikowy nie podlega odrębnej ochronie prawnoautorskiej, co oznacza, że przeniesienie praw do programu komputerowego lub udzielenie licencji na korzystanie z takiego programu komputerowego dotyczy zarówno kodu wynikowego jak i kodu źródłowego.

Jednocześnie, czym innym niż majątkowe prawo autorskie do korzystania z programowania jest faktyczny dostęp do kodów źródłowych tego oprogramowania, które są z technicznego punktu widzenia konieczne dla swobodnego modyfikowania i wprowadzania zmian w takim programie.

Sposób zapisania kodów źródłowych stanowi bowiem często chronione know-how wykonawcy, a tym samym, konieczność ich wydania przez wykonawcę może być przez niego odrębnie wyceniana i może mieć znaczenia dla ofertowanej przez niego ceny na realizację danego zamówienia.

Tym samym, jeśli celem zamawiającego jest to, aby wykonawca przekazywał lub udostępniał zamawiającemu kod źródłowy, to kwestia ta powinna zostać wyraźnie wskazana w OPZ. Warto aby zamawiający opisał również częstotliwość przekazywania takich kodów, sposób i formę ich przekazywania czy udostępniania oraz wymagany przez zamawiającego opis takich kodów źródłowych oraz inne elementy istotne dla osób po stronie zamawiającego, które później te kody będą analizowali lub modyfikowali. Konkretne wymagania w tym zakresie powinny być spójne z celem oczekiwanym przez zamawiającego – jeśli oczekuje on przekazania kodów źródłowych celem późniejszego utrzymywania lub rozwoju systemu samodzielnie lub w ramach usług podmiotu trzeciego, opis kodów źródłowych lub jego dokumentacja powinna zapewniać niezbędny transfer wiedzy i być wystarczająca dla realizacji tych celów.

Rekomendacja ogólna nr 14: zamawiający powinien odpowiednio dostosować wymagania SWZ odnośnie korzystania z zamawianego systemu informatycznego oraz elementów składających się na wdrożenie zamawianego systemu informatycznego oraz specyfiki przedmiotu zamówienia

Jak już wskazano we wstępie do niniejszej części Rekomendacji poświęconych OPZ, bardzo różny zakres świadczeń składających się na zamówienia systemów IT, a także różny rodzaj zamawianych systemów IT (przykładowo: systemy informatyczne budowane od podstaw, systemy informatyczne stanowiące rozwinięcie istniejących już rozwiązań, systemy standardowe nieznacznie jedynie dostosowywane pod potrzeby zamawiających, czy tez zakup określonej funkcjonalności w modelu SaaS lub zautomatyzowania danego procesu) oraz brak jednolitych standardów w tym zakresie powoduje, że opis przedmiotu zamówienia na zakup systemu IT może być bardzo różny, co przekłada się również na wymagania dot. zakresu uprawnień do zamawianego systemu informatycznego.

Jednocześnie, z art. 17 ust. 1 PZP wynika, że zamawiający powinien udzielać zamówień w sposób efektywny, czyli tak, aby uzyskać jak najlepszą jakość świadczeń wykonawcy w ramach środków, które zamawiający może przeznaczyć na jego realizację, a jednocześnie uzyskać jak najlepsze efekty możliwe do uzyskania w stosunku do poniesionych nakładów. Powyższe oznacza, że na etapie przygotowywania OPZ lub jeszcze we wcześniejszym etapie, nawet przed wszczęciem postępowania o udzielenie zamówienia zmawiający powinien dokonać odpowiedniego ustalenia swoich potrzeb, a także zweryfikować dostępne i ofertowane na rynku rozwiązania i systemu IT, tak aby w optymalnym zakresie opisać swoje wymagania – w tym wymagania dotyczące oczekiwań z zakresu uprawnień do systemu informatycznego, dbając jednocześnie o poszanowanie zasad równej konkurencji i utrzymanie możliwie wysokiej konkurencyjności prowadzonego postępowania.

W przypadku określania wymagań odnośnie korzystania z zamawianego systemu informatycznego oraz elementów składających się na wdrożenie zamawianego systemu informatycznego – kluczowe znaczenie ma to, czy zasadniczo system o funkcjonalnościach zamawianych przez zamawiającego już istnieje na rynku i należy oczekiwać, że najprawdopodobniej będzie on dostarczany przez wykonawcę jako system standardowy, a jedynie w części (większej lub mniejszej) dostosowywany do potrzeb zamawiającego, czy też raczej rozwiązanie oczekiwane przez zamawiającego nie funkcjonuje na rynku, a tym samym planowane wdrożenie polegać będzie na budowaniu takiego systemu informatycznego niemalże od podstaw.

Jeżeli przedmiot zamówienia obejmuje budowę rozwiązania od podstaw, poprzez wytworzenie nowego oprogramowania, specyficznego dla danego zamawiającego, to w pełni uzasadnione może być oczekiwanie zamawiającego, aby zamawiający nabył w jak najszerszym zakresie prawa autorskie do stworzonego dla niego produktu. Jeżeli natomiast przedmiotem zamówienia co do zasady ma być oprogramowanie standardowe, które będzie w toku wdrożenia podlegało wyłącznie odpowiedniej konfiguracji, to oczekiwanie przez zamawiającego przeniesienia na niego majątkowych praw autorskich do takiego systemu może być uznane za nieuzasadnione – jako nieadekwatne i w niezasadny sposób ograniczające konkurencję.

W przypadku, gdy przedmiotem zamówienia jest świadczenie usług w modelu SaaS, PaaS lub IaaS, kwestią dyskusyjną (i zależną od stanu faktycznego) jest to, na ile podmiot korzystający z oprogramowania w ogóle wkracza w sferę wyłączności wynikającą z prawa autorskiego. Niniejsze Rekomendacje nie są właściwym miejscem, by ten spór rozstrzygać. Zamawiający powinni jednak mieć na uwadze, że w praktyce spotykane są bardzo różne modele dotyczące udostępniania oprogramowania w modelu chmury obliczeniowej. Są wśród nich modele, w których usługodawcy nie udzielają licencji, lecz w ramach swoich usług udostępniają oprogramowanie, a zamawiający może korzystać z niego jako tzw. legalny użytkownik zgodnie z art. 75 ust. 1 pr. aut. Z tego względu błędem może być próba zabezpieczenia interesów zamawiającego poprzez wprowadzenie bardzo restrykcyjnych postanowień licencyjnych, jeżeli przedmiot zamówienia będzie obejmował usługi chmury obliczeniowej, które w inny sposób opisują zakres uprawnień do korzystania z tak udostępnianego oprogramowania. Zamawiając usługi SaaS, PaaS lub IaaS zamawiający powinien starannie zweryfikować nie tylko zakres potrzebnych mu uprawnień, ale także to, czy ich podstawą prawną powinna być licencja.

Tym samym, opisując swoje wymagania w zakresie uprawnień do systemu informatycznego zamawiający powinien pamiętać o tym, że opisując te wymagania w sposób nieadekwatny lub w zbyt szeroki sposób – może znacząco ograniczyć sobie liczbę podmiotów zainteresowanych udziałem w takim postępowaniu oraz oferowanych rozwiązań – zmniejszając tym samym konkurencyjność danego postępowania.

Oczywiste jest bowiem to, że wykonawcy IT oferujący standardowe rozwiązania IT i czerpiący dochody z udzielania licznych licencji na korzystanie z takiego oprogramowania nie będą zainteresowani przenoszeniem majątkowych praw autorskich do takiego oprogramowania na zamawiającego, bo przeniesienie takie wykluczyłoby dalszą możliwość licencjonowania takiego oprogramowania. Podobnie również w przypadku wykonawców oferujących swoje systemy informatyczne w modelu chmury obliczeniowej na jednolitych zasadach korzystania z takich systemów przez wszystkich użytkowników

– mogą podjąć decyzję o nieskładaniu ofert w postępowaniu, w którym zamawiający przewiduje szczegółowe zasady korzystania z oprogramowania odbiegające od zasad, na których udostępniają oni swoje oprogramowanie.

Warto jest zatem pamiętać o tym, że dane wymaganie zamawiającego może być uznane za nadmiarowe lub za uzasadnione, w zależności przykładowo od tego, jakiemu celowi służy budowa danego rozwiązania informatycznego, czy też w zależności od tego, czy system budowany jest od postaw, czy też stanowi kolejny moduł istniejącego już rozwiązania. Jednocześnie zamawiający ma prawo definiować przedmiot zamówienia uwzględniając swoje rzeczywiste, obiektywnie uzasadnione potrzeby – jednakże ustalane wymogi powinny jasno wynikać z ustalonych przez zamawiającego takich potrzeb i być adekwatnie dostosowane, mając na uwadze istniejące i oferowane na rynku IT rozwiązania oraz obiektywne potrzeby zamawiającego.

Rekomendacja szczegółowa nr 14.1: zanim zamawiający rozpocznie prace nad SWZ i opisywaniem wymaganego zakresu praw do oprogramowania powinien zweryfikować jakie systemy informatyczne występują już na rynku i co może być wykorzystane w ramach wdrożenia

Zamawiający zanim rozpocznie prace nad OPZ i opisywaniem wymaganego zakresu praw do zamawianego systemu IT powinien zweryfikować jakie rozwiązania występują już na rynku i są ofertowane jako rozwiązania standardowe, aby móc optymalnie określić zakres wymaganych przez siebie uprawnień do takiego sytemu.

Zamawiający powinien rozeznać się także, czy w ramach przedmiotu zamówienia mogą występować sytuacje, w których to nie wykonawca, z którym zawarto umowę, a inny producent IT będzie faktycznie udzielał licencji na korzystanie z oprogramowania. Jeśli z rozeznania zamawiającego okaże się, że sytuacje takie mogą występować, zamawiający powinien odpowiednio przewidzieć te sytuacje w OPZ wskazując np., że oczekiwaniem zamawiającego jest, aby wykonawca zapewnił określone uprawnienia zamawiającego, bez wskazywania, kto ma udzielać licencji na korzystanie z dostarczonych utworów.

Rekomendacja szczegółowa nr 14.2: zamawiający powinien dążyć do zabezpieczenia odpowiedniego zakresu uprawnień do korzystania z oprogramowania, w tym jego swobodnego rozwijania oraz możliwości powierzania jego utrzymania po zakończeniu zamówienia podmiotom innym niż wykonawcy z uwzględnieniem realiów rynkowych oraz poszanowaniem zachowania odpowiedniej konkurencji wykonawców

Zamawiający opisując przedmiot zamówienia na system informatyczny oraz zakres praw do tego systemu, jaki chce uzyskać, uwzględniając wytyczną, aby przedmiotu tego nie opisywać w taki sposób, który mógłby utrudniać uczciwą konkurencję, powinien patrzeć i uwzględniać nie tylko sytuację postępowania, w ramach którego system ten jest zamawiany, ale również zastanowić się nad tym, w jaki sposób po zakończeniu realizacji danego zamówienia system ten będzie wykorzystywany lub rozwijany.

Jeśli bowiem zamawiający zakłada, że po zakończeniu realizacji zamówienia system nadal będzie wykorzystywany, a na potrzeby rozwoju i utrzymania tego systemu zamawiający będzie potrzebował skorzystać z pomocy zewnętrznych podmiotów (wykonawców), zamawiający co do zasady powinien w

taki sposób ukształtować wymagania odnośnie uprawnień do zamawianego wcześniej systemu, aby realizacja tych czynności była możliwa także przez innych wykonawców, a nie jedynie przez wybranego wcześniej wykonawcę wdrażającego system - czyli, aby nie dopuścić do tak zwanej sytuacji vendor lock-in zamawiającego.

Możliwość dalszego rozwoju i utrzymania oprogramowania przez podmioty inne niż pierwotny wykonawca systemu może zależeć od technologii, w jakiej tworzone jest oprogramowanie (na ile oprogramowanie może być zmienianie jedynie poprzez zmiany konfiguracyjne i parametryzacyjne bez potrzeby wnikania w kod źródłowy oprogramowania) oraz zakresu praw jakie zamawiający, czy to na podstawie nabytych praw autorskich, czy na podstawie uprawnień licencyjnych otrzymuje w ramach realizowanej umowy od wykonawcy. Kluczowe przy tym może być tu:

• czy na podstawie nabytej licencji, czy też nabytych praw autorskich do oprogramowania zamawiający będzie mógł powierzać wykonywanie swobodnych modyfikacji takiego oprogramowania podmiotom trzecim;

• czy jeśli do modyfikowania oprogramowania konieczne jest wydanie kodów źródłowych, to czy wykonawca takie kody źródłowe zobowiązany jest przekazać zamawiającemu w ramach realizacji zamówienia na wdrożenie systemu (zob. Rekomendacja szczegółowa nr 13.8);

• czy wykonawca realizujący wdrożenie zobowiązany jest do stworzenia i przekazania zamawiającemu odpowiedniej dokumentacji umożliwiającej nowemu wykonawcy zapoznanie się z tym, w jaki sposób został zbudowany system i jak najlepiej wprowadzać do niego modyfikacje, a także udzielania nowemu wykonawcy niezbędnych wskazówek w tym zakresie.

Warto jednak pamiętać w tym miejscu o tym, że w praktyce, to co daje zamawiającemu realną szansę na uniknięcie sytuacji vendor lock-in oraz rozpisywania konkurencyjnego postępowania na rozwój lub utrzymanie wcześniej zamówionego systemu zależy w dużej mierze od przygotowania zamawiającego do danego wdrożenia, technologii, w jakiej tworzone jest oprogramowanie, zaangażowania zamawiającego w sam proces wdrożenia (chęci poznania jak oprogramowanie jest tworzone i jak zbudowane), a tylko jednym z elementów decydującym o sukcesie możliwości uniezależnienia się od wykonawcy, który wdrażał system – jest uzyskanie odpowiedniego zakresu praw do oprogramowania oraz kodów źródłowych, przynajmniej do niezbędnej dla rozwoju części takiego oprogramowania.

Nie można również pominąć tego, że w niektórych przypadkach, kiedy zamawiający świadomie zamawia w ramach wdrożenia system z jego niezbędnym utrzymaniem i rozwojem na czas całego planowanego korzystania z danego oprogramowania - dążenie przez zamawiającego do zapewnienia sobie uprawnień do samodzielnego lub przez osoby trzecie rozwoju takiego systemu może nie mieć sensu. Koszt bowiem kalkulowany przez wykonawców wynikający z postawienia takich wymagań (np. obowiązku wydania kodów źródłowych) skutkujący wzrostem oferowanych cen za realizacje zamówienia - może być zupełnie niewspółmierny do potencjalnych korzyści w postaci “ niezależności zamawiającego”, jeśli i tak po zakończeniu realizacji zamówienia zamawiający planuje lub dopuszcza możliwość zastąpienia systemu innym system wybieranym w otwartym postępowaniu.

Tym samym, aby prawidłowo opisać przedmiot zamówienia na system informatyczny oraz zakres praw do tego systemu, jaki chce uzyskać zamawiający, tak aby później nie utrudniać uczciwej konkurencji również po wyborze wykonawcy na wdrożenie systemu - zamawiający powinien zastanowić się czy, a jeśli tak to w jaki sposób planuje korzystać z systemu po zakończeniu realizacji zamówienia przez wybranego wykonawcę oraz czy w tym celu będzie mu potrzeba pomoc podmiotów trzecich (wykonawców).

Rekomendacja szczegółowa nr 14.3: zamawiający nie powinien dążyć za wszelką cenę do nabycia pełni autorskich praw majątkowych do zamawianego systemu informatycznego

Zamawiający chcąc zabezpieczyć sobie odpowiedni zakres praw do oprogramowania w ramach zamawianego systemu oczekują często przeniesienia majątkowych praw autorskich do takiego systemu przez wykonawcę. Tymczasem takie wymaganie postawione w SWZ nie zawsze jest najbardziej optymalne i uzasadnione z punktu widzenia zamawiającego, a niejednokrotnie może wręcz działać na jego niekorzyść.

Pamiętać bowiem należy o tym, że przenosząc majątkowe prawa autorskie do oprogramowania na zamawiającego, wykonawca traci możliwość dalszego korzystania z takiego oprogramowania oraz jego licencjonowania na innych klientów. Z powyższych względów wykonawcy, którzy posiadają standardowe rozwiązania (tzw. oprogramowania standardowe lub off the shelf) zwykle nie decydują się na składanie ofert w postępowaniach, gdzie wymaganiem jest przeniesienie majątkowych praw autorskich do oprogramowania na zamawiającego. Podobnie również część wykonawców tworzących nawet rozwiązania częściowo dedykowane pod klientów, ale chcących później fragmenty lub całość takiego oprogramowania wykorzystywać w swoich innych produktach – przyjmuje politykę, że co do zasady nie godzi się na przenoszenie majątkowych praw autorskich do jakichkolwiek części wytwarzanego przez nich oprogramowania na klientów i nie bierze udziału w postępowaniach gdzie takie oczekiwanie zamawiającego jest postawione.

Tym samym, zamawiający powinien być świadomy tego, że wskazując w OPZ na wymóg przeniesienia na niego majątkowych praw autorskich do systemu możne znacząco ograniczyć krąg podmiotów, którzy będą zainteresowani złożeniem oferty w takim postępowaniu. Ponadto, zamawiający powinien liczyć się z tym, że oferty złożone w postępowaniu z takim wymogiem mogą być znacznie droższe niż oferty w analogicznym postępowaniu, gdzie zamawiający wymagałby jedynie udzielenia licencji przez wykonawcę.

Z powyższych względów nie w każdym przypadku zamawiający powinien dążyć za wszelką cenę do nabycia pełni autorskich praw majątkowych do zamawianego systemu informatycznego, a żądanie takie postawione w SWZ powinno być poprzedzone wcześniejszą analizą faktycznych potrzeb zamawiającego.

Przed podjęciem decyzji co do tego, czy żądać, a jeśli tak, to w jakim zakresie i w odniesieniu do jakich elementów oprogramowania przeniesienia majątkowych praw autorskich do systemu zamawiający powinien w szczególności sprawdzić:

• czy oprogramowanie spełniające potrzeby zamawiającego lub część takich potrzeb jest już dostępne na rynku jako standardowe rozwiązanie;

• na ile zamawiane oprogramowanie jest krytyczne, a co za tym idzie na ile ryzyka związane z ewentualną wypowiadalnością licencji są dla zamawiającego krytyczne;

• jak długo zamawiający chce wykorzystywać oprogramowanie oraz czy chce je dostosowywać do swoich potrzeb po zakończeniu realizacji zamówienia.

Warto jednocześnie pamiętać o tym, że o uniezależnieniu się od wykonawcy oraz o możliwości dalszego rozwoju oprogramowania przez podmioty inne niż wykonawca nie decyduje sam fakt, czy zamawiający nabył majątkowe prawa do oprogramowania, czy uzyskał licencję, a to jaki zakres uprawnień (pól eksploatacji do korzystania z oprogramowania) uzyskał od wykonawcy, tj. czy uprawienie to obejmowało np. prawo do dokonywania wszelkich modyfikacji oprogramowania z prawem do zezwalania na wykonywanie opracowań (utworów zależnych) oraz czy było powiązane z wydaniem kodów źródłowych.

VII. PRZECIWDZIAŁANIE VENDOR LOCK-IN

Rekomendacja ogólna nr 15: zamawiający powinien przeciwdziałać vendor lock-in i dążyć do minimalizacji ryzyka przywiązania do jednego wykonawcy lub producenta

Choć nie można uniknąć pewnego uprzywilejowania podmiotu, który już realizował dla danego zamawiającego dostawy lub usługi (np. świadczy dla niego usługi chmurowe lub wdrożył system informatyczny), zamawiający powinien unikać przywiązania do jednego wykonawcy lub producenta, czyli tzw. vendor lock-in. Zjawisko to może wynikać zarówno z uwarunkowań prawnych, związanych zwłaszcza z prawami własności intelektualnej, jak i faktycznych. Szczególnym przypadkiem jest sytuacja, w której vendor lock-in wynika z braku zapewnienia odpowiedniego transferu wiedzy od wykonawcy do zamawiającego.

Zamawiający powinni konstruować opis przedmiotu zamówienia tak, aby w maksymalnym stopniu zachować swobodę podejmowania decyzji zakupowych w przyszłości (także co do trybu postępowania) i uniknąć sytuacji, w której środki publiczne wydatkowane są nieefektywnie, ponieważ określony podmiot może w praktyce dyktować warunki, na których zostanie udzielone zamówienie dotyczące danego systemu informatycznego. W takim wypadku nawet jeśli zamawiający przeprowadzi postępowanie w trybie z nazwy konkurencyjnym, w praktyce konkurencja będzie ograniczona lub wręcz pozorna.

Przeciwdziałanie vendor lock-in jest powinnością zamawiającego w przypadku każdego postępowania, które dotyczy danego systemu informatycznego, jednak szczególnie groźne i trudne do naprawienia są błędy popełnione na etapie pierwszego zamówienia. Okoliczności wynikające z zaniechania zamawiającego nie mogą być przy tym traktowane jako obiektywne czynniki przemawiające za odstępstwem od zastosowania trybu konkurencyjnego.

Rekomendacja szczegółowa nr 15.1: zamawiający powinien dążyć do zlikwidowania asymetrii informacyjnej między wykonawcami

Wykonawca już wdrożonego systemu (lub producent oprogramowania, na którym system ten jest oparty) ma najczęściej istotną przewagę nad kolejnymi wykonawcami, którzy mogliby ubiegać się o zamówienie na rozwój, rozbudowę lub utrzymanie takiego systemu. Rolą zamawiającego jest zapewnienie uczciwej konkurencji między takimi wykonawcami, w szczególności przez zapewnienie dostępu do wiedzy na temat systemu i zastosowanych w nim technologii. Zamawiający powinien uwzględnić potrzebę uzyskania odpowiednich informacji oraz prawa do ich ujawnienia potencjalnym nowym wykonawcom już na etapie pierwszego zamówienia dotyczącego danego rozwiązania.

Rekomendacja szczegółowa nr 15.2: zamawiający powinien uwzględnić potrzebę integracji między systemami informatycznymi

Niniejsza Rekomendacja uszczegóławia Rekomendację szczegółową nr 15.1. Często spotykanym zjawiskiem jest konstruowanie opisu przedmiotu zamówienia w taki sposób, że wymagania dotyczące zintegrowania nowego rozwiązania informatycznego z rozwiązaniami już działającymi u zamawiającego są nieprecyzyjne lub niekompletne. Nieuzasadnione jest przerzucanie w takich przypadkach na wykonawcę odpowiedzialności za pozyskanie odpowiednich informacji, ponieważ to zamawiający dysponuje możliwościami wynikającymi z relacji umownej z wykonawcą już wykorzystywanego rozwiązania. Zamawiający już na etapie pierwszego zamówienia dotyczącego danego rozwiązania powinien zapewnić sobie dostęp do informacji niezbędnych do późniejszej integracji z nowymi rozwiązaniami (dokumentacja interfejsów, wsparcie wykonawcy istniejącego rozwiązania lub transfer wiedzy pozwalający zamawiającemu na samodzielne świadczenie takiego wsparcia) oraz prawo do udostępniania tych informacji kolejnemu potencjalnemu wykonawcy.

Rekomendacja szczegółowa nr 15.3: zamawiający powinien odwoływać się do znanych i udokumentowanych technologii informatycznych

Oparcie zamawianego rozwiązania na niszowej lub nieudokumentowanej technologii znacząco zwiększa asymetrię informacyjną między wykonawcą, który jako pierwszy wdraża dane rozwiązanie, a kolejnymi wykonawcami, którzy mogą ubiegać się o zamówienie na jego rozwój, rozbudowę lub utrzymanie. W przypadku wprowadzenia odstępstw od standardu (np. zmodyfikowania protokołu komunikacji), powinny one zostać udokumentowane, a zamawiający powinien zapewnić sobie prawo do ich ujawnienia potencjalnym nowym wykonawcom.

Rekomendacja szczegółowa nr 15.4: w przypadku zamówień na usługi, zamawiający powinien zdefiniować wymagania umożliwiające migrację do nowego usługodawcy

Omawiana Rekomendacja dotyczy przede wszystkim zamówień na usługi (np. usługi chmurowe). Zamawiający, który nie dysponuje efektywnym planem działań na wypadek zakończenia współpracy z wykonawcą, naraża się na faktyczne uzależnienie od niego – a w przypadku, gdy wykonawca jest jedynie pośrednikiem, naraża się na faktyczne uzależnienie od podmiotu faktycznie świadczącego usługi. Formułując opis przedmiotu zamówienia, zamawiający powinien uwzględnić obowiązki wykonawcy związane z zakończeniem świadczenia usług. Szczegółowy zakres takich usług zależy od danego przedmiotu zamówienia i potrzeb zamawiającego. Z reguły koniecznie będzie przynajmniej zdefiniowanie procedury postępowania w razie zakończenia zamówienia; w tym zasad zwrotu lub usunięcia danych i informacji, w określonym formacie i strukturze.

Zakres i format danych zależą od usługi, której dotyczy migracja. Przykładowo, w przypadku usługi IaaS może to dotyczyć informacji o konfiguracji parametrów infrastruktury (np. konfiguracji systemów operacyjnych i silników bazy danych, konfiguracji urządzeń sieciowych takich jak zapory sieciowe, routery czy load balancery, czy też informacji o tzw. blacklistach adresów IP, jeśli był stosowane). Zasadne może być także przekazanie wiedzy nabytej przez dotychczasowego usługodawcę lub przekazanie danych, w których wytwarzaniu brał on udział, czego elementem może być przekazanie informacji znajdujących się w narzędziach przeznaczonych do obsługi zgłoszeń serwisowych (zlecenia, raporty itp.). Decyzja zamawiającego o sposobie zwrotu lub usunięciu określonych danych po zakończeniu świadczenia usług przez dotychczasowego wykonawcę musi uwzględniać także wymogi wynikające z odrębnych przepisów, w szczególności unormowaniach dotyczących ochrony danych osobowych czy tajemnic prawnie chronionych.

Opis przedmiotu zamówienia powinien uwzględniać realistyczny termin na przeprowadzenie migracji.

Rekomendacja szczegółowa nr 15.5: zamawiający powinien dążyć do uzyskania odpowiednich uprawnień do korzystania z utworów

Jak wskazano już w Rekomendacji szczegółowej nr 14.2 możliwość dalszego rozwoju i utrzymania oprogramowania przez podmioty inne niż pierwotny wykonawca systemu może zależeć od technologii, w jakiej tworzone jest oprogramowanie (na ile oprogramowanie może być zmieniane jedynie poprzez zmiany konfiguracyjne i parametryzację bez potrzeby wnikania w kod źródłowy oprogramowania) oraz zakresu praw jakie zamawiający, czy to na podstawie nabytych praw autorskich, czy na podstawie uprawnień licencyjnych otrzymuje w ramach realizowanej umowy od wykonawcy.

W odniesieniu do opisywanych uprawnień prawnoautorskich kluczowe przy opisywaniu odpowiednich uprawnień zamawiających może być:

• zastrzeżenie na rzecz zamawiającego lub innych podmiotów trzecich (innych wykonawców) możliwości wykonywania swobodnych modyfikacji oprogramowania oraz dokumentacji oprogramowania, w tym zezwalania na wykonywanie praw zależnych w odniesieniu do takiego oprogramowania oraz jej dokumentacji (zob. Rekomendacja szczegółowa nr 14.2) - co istotne uprawnienie to może być przekazane w postaci licencji lub jako przeniesienie praw na zamawiającego;

• Zastrzeżenie obowiązku wydania kodów źródłowych do oprogramowania zamawiającemu oraz zastrzeżenie możliwości przekazania tych kodów źródłowych także innym wykonawcom, którzy będą modyfikować stworzone przez wykonawcę oprogramowanie (zob. Rekomendacja szczegółowa nr 13.8);

• Określenie warunków gwarancji jakości na oprogramowanie w taki sposób, aby wykonywanie uprawnień nabytych przez zamawiającego do dokonywania modyfikacji oprogramowania przez podmioty trzecie nie wyłączało całkowicie odpowiedzialności wykonawcy za działanie całego systemu;

• Określenie w OPZ zasad poufności realizacji zamówienia oraz postanowień dot. tajemnicy przedsiębiorstwa wykonawcy, tak, aby nie blokowały one w praktyce uprawnień zamawiającego do udostępniania oprogramowania i jego kodów źródłowych podmiotom trzecim, jeśli jest to niezbędne do modyfikowania takiego oprogramowania i wykonywania uprawnień prawnoautorskich nabytych przez zamawiającego).

VIII. ODPOWIEDNIE OPISANIE WYMOGÓW CYBERBEZPIECZEŃSTWA SYSTEMÓW INFORMATYCZNYCH

Z uwagi na zwiększające się cyberzagrożenia, które mogą skutkować naruszeniem poufności i integralności systemów informatycznych, a także zakłóceniem ciągłego funkcjonowaniu systemu, opis przedmiotu na zamówienie systemu informatycznego powinien zawierać odpowiednie wymagania w zakresie cyberbezpieczeństwa, uwzględniające x.xx. rodzaj systemu informatycznego, kategorię i istotność danych przechowywanych lub przetwarzanych z jego wykorzystaniem, czy poziom ryzyka związanego z ewentualnym przełamaniem zabezpieczeń systemu.

Brak zapewnienia odpowiedniego poziomu cyberbezpieczeństwa może w przyszłości doprowadzić np. do ujawnienia danych przechowywanych lub przetwarzanych za pomocą systemu informatycznego, w tym danych osobowych, informacji stanowiących tajemnicę przedsiębiorstwa zamawiającego, czy informacji niejawnych (w sytuacji, gdy zamawiający posiada dostęp do takich informacji i przetwarza je z wykorzystaniem systemu informatycznego).

Naruszenie cyberbezpieczeństwa systemu informatycznego może również doprowadzić do przerw czy zakłóceń w jego działaniu, co w konsekwencji może mieć istotny, negatywny wpływ na działalność zamawiającego, uniemożliwiając np. obsługę wewnętrznych procesów, wykonywanie sprawowanych funkcji czy świadczenie usług na rzecz podmiotów trzecich. W niektórych przypadkach naruszenie cyberbezpieczeństwa systemu może również stanowić zagrożenie dla zdrowia czy bezpieczeństwa publicznego (np. w przypadku systemów zarządzania ruchem czy systemów zarządzania siecią energetyczną).

W związku z powyższym, naruszenie cyberbezpieczeństwa systemu informatycznego może wiązać się dla zamawiającego z poważnymi konsekwencjami – nie tylko na gruncie prawa cywilnego (odpowiedzialność odszkodowawcza), ale również na gruncie prawa administracyjnego (kary administracyjne za naruszenie ochrony danych osobowych, kary administracyjne na gruncie przepisów ustawy KSC), czy nawet prawa karnego (odpowiedzialność karna, np. za przestępstwo narażenia na niebezpieczeństwo utraty życia albo ciężkiego uszczerbku na zdrowiu).

Z powyższych względów, zamawiający powinien zadbać, aby wykonawca zapewnił odpowiednie i adekwatne zabezpieczenia dostarczanego systemu informatycznego.

Na chwilę obecną nie istnieją przepisy o randze ustawowej, które od strony technicznej określałyby w konkretny sposób minimalny poziom cyberbezpieczeństwa systemów informatycznych dla zamawiających z sektora publicznego. W obszarze rozwiązań i praktyk z zakresu cyberbezpieczeństwa, których wdrożenie jest zalecane i rekomendowane przez podmioty publiczne, pojawiają się natomiast regulacje zawierające zbiory dobrych praktyk, rekomendacje i wytyczne stanowiące tzw. soft law, takie jak na przykład Narodowe Standardy Cyberbezpieczeństwa (NSC) opublikowane przez Pełnomocnika Rządu ds. Cyberbezpieczeństwa. Z uwagi na szczegółowy i techniczny charakter tych standardów, nie zostaną one kompleksowo omówione w niniejszym opracowaniu. Szczegółowe rekomendacje

dotyczące zabezpieczeń systemów i kategorii danych, które mogą być przetwarzane z ich wykorzystaniem, pojawiają się także w różnego rodzaju wytycznych sektorowych (np. rekomendacje Komisji Nadzoru Finansowego dla sektora finansowego, czy rekomendacje dla sektora kolejowego, energii, wodno-kanalizacyjnego, czy ochrony zdrowia). Dodatkowe wytyczne mogą mieć zastosowanie w odniesieniu do danych przetwarzanych z wykorzystaniem chmury obliczeniowej (np. Standardy Cyberbezpieczeństwa Chmur Obliczeniowych dla podmiotów publicznych).

Ponadto, niektórzy zamawiający mogą mieć szczególne obowiązki w zakresie cyberbezpieczeństwa, w związku z objęciem ich regulacją ustawy z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Sposób zabezpieczenia systemu informatycznego oraz jego funkcjonalności powinny umożliwiać zamawiającemu wywiązanie się ze wszystkich nałożonych na niego obowiązków.

Rekomendacja ogólna nr 16: zamawiający powinien ocenić, jakie regulacje dotyczące cyberbezpieczeństwa powinien stosować w ramach prowadzonej działalności

Do dnia opublikowania niniejszych Rekomendacji nie zostały wydane powszechnie obowiązujące przepisy nakładające na wszystkich zamawiających z sektora publicznego obowiązek stosowania określonych środków na rzecz cyberbezpieczeństwa czy zapewnienia określonego poziomu zabezpieczeń wykorzystywanych systemów informatycznych. Wymogi takie nie wynikają również bezpośrednio z przepisów ustawy PZP. Niemniej jednak, rekomendowaną praktyką dla zamawiających z sektora publicznego jest uwzględnienie w przygotowywanym OPZ wytycznych i zaleceń wynikających z Narodowych Standardów Cyberbezpieczeństwa (NSC). NSC stanowią zbiór rekomendacji standaryzujących rozwiązania zabezpieczające w sieciach i systemach informatycznych wykorzystywanych przez podmioty chcące efektywnie zarządzać systemami bezpieczeństwa informacji. NSC zostały sporządzone w ramach realizacji celu określonego w pkt 6.1 załącznika do uchwały Rady Ministrów z dnia 22 października 2019 r. w sprawie Strategii Cyberbezpieczeństwa Rzeczypospolitej Polskiej na lata 2019-2024, a podstawę ich opracowania stanowiły standardy amerykańskiego NIST (National Institute of Science and Technology). NSC mają charakter soft law, czyli nieformalnych rekomendacji skierowanych x.xx. do podmiotów publicznych, w szczególności jednostek administracji publicznej, czy operatorów usług kluczowych. Narodowe Standardy Cyberbezpieczeństwa określają x.xx. zasady kategoryzacji informacji i systemów informatycznych, minimalne wymagania bezpieczeństwa, ramy zarządzania ryzykiem czy zalecane do stosowania rodzaje zabezpieczeń. NSC mają być sukcesywnie rozwijane oraz mają podlegać rewizjom i aktualizacjom, dlatego też zamawiający powinni na bieżąco śledzić ich aktualne wersje oraz – w razie takiej potrzeby – uwzględniać w przygotowywanych OPZ.

Ponadto, w zależności od rodzaju prowadzonej przez zamawiającego działalności oraz sektora gospodarki, w którym działalność ta jest prowadzona, na zamawiającego mogą zostać nałożone dodatkowe, szczególne obowiązki sektorowe w zakresie cyberbezpieczeństwa wynikające z przepisów powszechnie obowiązującego prawa lub z soft law. Z powyższych względów zamawiający powinien ustalić, w jakim zakresie jest zobowiązany stosować powszechnie obowiązujące przepisy , a także powinien uwzględnić odpowiednie, mające do niego zastosowanie wytyczne i rekomendacje o charakterze niewiążącym

Rekomendacja szczegółowa nr 16.1: zamawiający powinien ustalić, w jakim zakresie jest zobowiązany stosować powszechnie obowiązujące przepisy

Zamawiający powinien zweryfikować, czy – a jeśli tak, to w jakim zakresie – przepisy powszechnie obowiązującego prawa mają zastosowanie w stosunku do prowadzonej przez niego działalności oraz czy wpływają one na konkretne wymogi stawiane wykonawcy w odniesieniu do zabezpieczeń dostarczanego systemu informatycznego. Opis przedmiotu zamówienia powinien być skonstruowany w taki sposób, aby korzystanie przez zamawiającego z systemu informatycznego nie naruszało przepisów prawa oraz umożliwiało zamawiającemu praktyczne wywiązanie się ze wszystkich nałożonych na niego obowiązków.

Zamawiający objęci krajowym systemem cyberbezpieczeństwa (posiadający status operatorów usług kluczowych, dostawców usług cyfrowych lub podmiotów publicznych w rozumieniu ustawy KSC) powinni w szczególności uwzględnić obowiązki nałożone na nich przepisami ustawy KSC, x.xx. w

zakresie wdrożenia odpowiednich i proporcjonalnych środków technicznych i organizacyjnych na rzecz zapewnienia cyberbezpieczeństwa, zgłaszania i obsługi incydentów oraz usuwania podatności. Ponadto, zamawiający realizujący zadania publiczne powinni zwrócić uwagę na to, aby zamawiany system informatyczny zapewniał możliwość spełnienia wymagań z zakresu zarządzania bezpieczeństwem informacji, o których mowa w Krajowych Ramach Interoperacyjności (KRI)9.

Zamawiający powinien również zweryfikować, czy w związku z korzystaniem z systemu informatycznego dostarczanego przez wykonawcę będzie podlegał innym przepisom, które mogą wpływać na określenie konkretnych wymogów w zakresie cyberbezpieczeństwa. Wśród przepisów takich można wskazać x.xx. na przepisy z zakresu ochrony danych osobowych czy ochrony informacji niejawnych – w sytuacji, w której informacje takie będą przechowywane lub przetwarzane przez zamawiającego z wykorzystaniem systemu informatycznego.

Rekomendacja szczegółowa nr 16.2: zamawiający powinien uwzględnić odpowiednie mające do niego zastosowanie wytyczne i rekomendacje o charakterze niewiążącym

Przy ustalaniu wymagań w zakresie bezpieczeństwa, które powinien spełniać dostarczany przez wykonawcę system informatyczny, oprócz przepisów powszechnie obowiązującego prawa zamawiający powinni uwzględnić również soft law, czyli z nieformalne wytyczne lub rekomendacje. Przepisy soft law mogą mieć zastosowanie do wszystkich zamawiających albo mogą być stosowane do ograniczonego kręgu zamawiających. Mimo ich nieformalnego charakteru, wytyczne i rekomendacje pozwolą zamawiającemu na określenie adekwatnych i dostępnych na rynku rozwiązań z zakresu cyberbezpieczeństwa, których stosowanie jest uzasadnione z uwagi na rodzaj sprawowanych funkcji lub prowadzonej działalności.

Wśród wytycznych i rekomendacji, które powinny zostać uwzględnione przez zamawiających, można wskazać x.xx.:

• Narodowe Standardy Cyberbezpieczeństwa opracowane przez Pełnomocnika Rządu ds. Cyberbezpieczeństwa;

• wytyczne i rekomendacje publikowane przez jednostki administracji państwowej (np. Rekomendacje dotyczące działań mających na celu wzmocnienie cyberbezpieczeństwa w sektorze energii, Rekomendacje cyberbezpieczeństwa dla sektora wodno-kanalizacyjnego nr R-CYBER-01/2021, czy Rekomendacje cyberbezpieczeństwa dla podmiotów sektora ochrony zdrowia);

• wytyczne ENISA (Agencji Unii Europejskiej ds. Cyberbezpieczeństwa) – np. Railway Cybersecurity – Good Practices in Cyber Risk Management (wytyczne dla rynku kolejowego), czy Cloud Security for Healthcare Services (wytyczne dot. korzystania z chmury obliczeniowej przez podmioty z sektora ochrony zdrowia);

• wytyczne regulatorów krajowych i unijnych – organów nadzorujących poszczególne sektory gospodarki (np. Komisji Nadzoru Finansowego);

• wytyczne przedmiotowe (np. Standardy Cyberbezpieczeństwa Chmur Obliczeniowych dla podmiotów publicznych korzystających z przetwarzania danych w chmurze obliczeniowej);

• rekomendacje wydawane przez organizacje lub stowarzyszenia branżowe.

9 Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjnośc i, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (t.j. Dz. U. z 2017 r. poz. 2247)

Rekomendacja ogólna nr 17: zamawiający powinien przeprowadzić analizę ryzyka w zakresie cyberbezpieczeństwa w celu określenia poziomu ryzyka związanego z wykorzystaniem systemu informatycznego

Przed podjęciem decyzji o zamówieniu systemu informatycznego i przed określeniem szczegółowych wymagań w zakresie cyberbezpieczeństwa, które powinien spełniać system informatyczny dostarczony przez wykonawcę, zamawiający powinien przeprowadzić analizę ryzyka w zakresie cyberbezpieczeństwa w celu określenia poziomu ryzyka związanego z wykorzystaniem systemu informatycznego w prowadzonej działalności. Szacowanie ryzyka jest niezbędne z perspektywy ustalenia krytyczności systemu informatycznego dla zamawiającego oraz oszacowania ewentualnych konsekwencji niedostępności lub zakłóceń w funkcjonowaniu systemu, a także konsekwencji ujawnienia nieuprawnionym osobom trzecim danych i informacji przechowywanych lub przetwarzanych z wykorzystaniem systemu informatycznego.

Przeprowadzone przez zamawiającego szacowanie ryzyka powinno uwzględniać ryzyka występujące dla zamawiającego w całym cyklu życia projektu, tj. zarówno na etapie projektowania systemu i jego wdrażania, jak również na etapie utrzymania i korzystania z systemu.

W ramach szacowania ryzyka zamawiający powinien przeprowadzić:

• analizę i klasyfikację danych oraz zasobów przetwarzanych przez system informatyczny pod kątem ich krytyczności, wrażliwości oraz wpływu na bezpieczeństwo;

• identyfikację rzeczywistych i potencjalnych zagrożeń cyberbezpieczeństwa oraz określić prawdopodobieństwo ich wystąpienia i ich wpływ na działanie systemu informatycznego;

• analizę wpływu ewentualnych zakłóceń w funkcjonowaniu systemu informatycznego na ciągłość działania zamawiającego oraz wykonywanie powierzonych mu funkcji i zadań;

• analizę zagrożeń związanych z dostępem osób trzecich do systemu, np. wykonawcy, podwykonawców, czy podmiotu odpowiedzialnego za dalsze utrzymanie systemu;

• analizę łańcucha dostaw wykonawców dostarczających system informatycznych i świadczących usługi związane z tym systemem.

Analiza ryzyka podejmowana przez zamawiającego powinna dotyczyć także wyboru modelu wdrożenia systemu informatycznego. Decyzja o modelu wdrożenia nie powinna doprowadzić do obniżenia poziomu bezpieczeństwa wdrożonego systemu. Zamawiający nie powinien też zakładać, że jeśli dla danego modelu wdrożeń nie zostały wydane przepisy lub sformułowane wytyczne, o których mowa w Rekomendacjach 16.1 i 16.2, to wybierając taki model jest zwolniony z obowiązku zapewnienia bezpieczeństwa systemu10.

Rekomendacja ogólna nr 18: zamawiający powinien określić w OPZ wymagania dotyczące cyberbezpieczeństwa, jakie powinien spełniać system informatyczny.

W oparciu o ustalenia dotyczące przepisów prawa i soft law znajdujących zastosowanie do zamawiającego, który przystępuje do zamówienia systemu informatycznego, jak również na podstawie przeprowadzonego szacowania ryzyka, zamawiający powinien określić możliwie konkretne i precyzyjne wymagania dotyczące cyberbezpieczeństwa systemu informatycznego oraz zabezpieczeń, które powinny zostać wdrożone przez wykonawcę w tym systemie. Wymagania powinny uwzględniać obowiązki nałożone na zamawiającego przepisami prawa, wytyczne sektorowe oraz standardy rynkowe w zakresie zabezpieczenia systemów informatycznych danego rodzaju.

Na tyle, na ile jest to możliwe, wymagania dotyczące cyberbezpieczeństwa powinny zostać opisane w sposób technologicznie neutralny, tak, aby nie ograniczały konkurencji i zapewniały możliwość udziału

10 Przykładowo, w chwili powstawania niniejszych rekomendacji dostępne są wytyczne przedmiotowe dotyczące stosowania chmury obliczeniowej w podmiotach publicznych (np. Standardy Cyberbezpieczeństwa Chmur Obliczeniowych). Decydując się na wdrożenie w modelu on-premise, zamawiający powinien dążyć do tego, by system zapewniał przynajmniej taki stopień bezpieczeństwa, jak analogiczny system wdrożony zgodnie z wytycznymi w modelu chmury.

w postępowaniu możliwie najszerszemu gronu wykonawców. Oznacza to, że przy konstruowaniu opisu przedmiotu zamówienia należy unikać opisywania wymagań w sposób uprzywilejowujący konkretnego dostawcę, np. poprzez odesłanie do jego autorskich rozwiązań w zakresie cyberbezpieczeństwa czy konkretnych nazw komponentów oprogramowania, które nie są niezastępowalne innymi rozwiązaniami dostępnymi na rynku.

Zamawiający powinien opisywać wymagania w zakresie zabezpieczeń poprzez odniesienie do celu, który chce osiągnąć, i funkcjonalności w zakresie cyberbezpieczeństwa, które powinien posiadać dostarczany system, a nie poprzez odniesienie do konkretnych środków. Zamawiający powinien wskazywać na konkretne środki w zakresie cyberbezpieczeństwa jedynie wtedy, gdy wymagają tego przepisy prawa lub gdy jest to jedyny sposób na spełnienie wymagań dotyczących cyberbezpieczeństwa lub nałożonych na zamawiającego obowiązków, a także wtedy, gdy jest to jedyny skuteczny środek zapewnienia bezpieczeństwa danego systemu informatycznego.

Rekomendacja szczegółowa nr 18.1: uwzględniając wnioski z analizy ryzyka, zamawiający powinien określić wymagania cyberbezpieczeństwa oraz określić środki konieczne do zastosowania

W oparciu o rezultaty przeprowadzonej analizy ryzyka, w opisie przedmiotu zamówienia zamawiający powinien określić adekwatne i proporcjonalne do stwierdzonego ryzyka wymagania w zakresie cyberbezpieczeństwa systemu informatycznego. Powyższe oznacza, że stawiane przez zamawiającego wymagania powinny z jednej strony być wystraczające dla zapewnienia odpowiedniego poziomu zabezpieczeń tak, aby zminimalizować ryzyko wystąpienia incydentu bezpieczeństwa i ponoszenia przez zamawiającego konsekwencji z tego tytułu, a z drugiej nie mogą być nadmierne tak, aby nie prowadziły w sposób nieuzasadniony do ograniczenia konkurencji wśród wykonawców mogących ubiegać się o udzielenie zamówienia. Poziom zabezpieczeń powinien być uzasadniony wymogami prawnymi i obiektywnymi okolicznościami, które zostały zidentyfikowane i szczegółowo przeanalizowane przez zamawiającego przed udzieleniem zamówienia na etapie szacowania ryzyka.

Przy określaniu wymagań z zakresu cyberbezpieczeństwa zamawiający może odnosić się do powszechnie uznawanych norm i certyfikacji z zakresu cyberbezpieczeństwa, np. norm ISO (w szczególności normy z serii 27000), Narodowych Standardów Cyberbezpieczeństwa (np. standardu NSC 800-53) czy standardów publikowanych przez amerykański Narodowy Instytut Standaryzacji i Technologii (NIST). W przypadku stawiania potencjalnym wykonawcom wymogu posiadania konkretnej certyfikacji, zamawiający powinien dopuścić również możliwość posługiwania się przez wykonawców certyfikacją równoważną.

Zamawiający powinien również uwzględnić odpowiednie rozwiązania z zakresu zarządzania dostępem do systemu informatycznego przez personel wykonawcy i podwykonawców, w tym również przez personel podmiotów świadczących usługi utrzymaniowe i gwarancyjne.

Rekomendacja szczegółowa nr 18.2: zamawiający powinien określić wymagania systemu informatycznego w zakresie cyberbezpieczeństwa w sposób, który pozwoli reagować na dynamicznie zmieniające się uwarunkowania, w szczególności pojawiające się nowe, nieznane wcześniej zagrożenia

W związku z dynamicznym zmianami wymogów w zakresie cyberbezpieczeństwa i pojawianiem się coraz to nowych zagrożeń, konstruując opis przedmiotu zamówienia zamawiający powinien zapewnić sobie możliwość reagowania na nowe uwarunkowania poprzez dostosowanie zabezpieczeń systemu do aktualnej sytuacji.

W tym celu, zamawiający powinien określić zasady przeprowadzania regularnej, bieżącej analizy ryzyka w zakresie cyberbezpieczeństwa systemu informatycznego nie tylko przed jego wdrożeniem, ale również na etapie wdrożenia i korzystania z systemu. Gdyby przeprowadzona analiza ryzyka wykazała, że stosowane przez zamawiającego zabezpieczenia systemu nie są wystarczające, zamawiający powinien mieć możliwość ich zmiany tak, aby na każdym etapie korzystania z systemu zagwarantować adekwatne i proporcjonalne środki na rzecz cyberbezpieczeństwa.

Rekomendacja szczegółowa nr 18.3: zamawiający powinien określić odpowiednie procedury na wypadek zaistnienia incydentów bezpieczeństwa

Przed przystąpieniem do korzystania z systemu informatycznego, zamawiający powinien zaprojektować i wdrożyć odpowiednie procedury na wypadek wystąpienia incydentu bezpieczeństwa, uwzględniające x.xx. ryzyko związane z dostępem osób trzecich do danych i informacji przechowywanych lub przetwarzanych z wykorzystaniem systemu informatycznego, czy potencjalne skutki zakłóceń w funkcjonowaniu systemu informatycznego dla działalności zamawiającego.

Procedury te powinny uwzględniać x.xx.:

• czas reakcji zamawiającego na wystąpienie incydentu bezpieczeństwa;

• opis procedur zgłaszania incydentów odpowiednim podmiotom, z uwzględnieniem ewentualnych terminów na dokonanie takich zgłoszeń (w szczególności dotyczy to podmiotów, które mają obowiązek zgłaszania incydentów bezpieczeństwa do właściwego CSIRT);

• sposób obsługi incydentu bezpieczeństwa, obejmujący x.xx. opis środków zaradczych podejmowanych przez zamawiającego na wypadek wystąpienia incydentu bezpieczeństwa;

• osoby lub podmioty odpowiedzialne za podjęcie środków zaradczych;

• analizę mającą na celu podjęcie odpowiednich środków zapobiegających wystąpieniu określonych kategorii incydentów bezpieczeństwa w przyszłości.

Document Metadata

Table of Contents

POSTĘPOWANIE O UDZIELENIE ZAMÓWIENIA PUBLICZNEGO

Document Metadata