Artykuł pochodzi z wydania: Czerwiec 2021
Na skutek pandemii w znacznym stopniu zmieniło się podejście do realizacji projektów wsparcia teleinformatycznego dla jednostek administracji publicznej. Wystąpiła też konieczność zaadresowania zupełnie nowych usług – w szczególności pracy zdalnej i komunikacji.
Krytycznymi czynnikami dla wdrażania tych usług stały się czas i efektywność kosztowa. Doświadczenia minionych miesięcy wykazały, że bardzo często właściwym (a czasem jedynym) rozwiązaniem było oparcie się na usługach z chmury – bezpieczne, łatwe we wdrożeniu i pozwalające na sukces w krótkim czasie. Wiele podmiotów napotkało jednak na problemy związane z właściwym opisaniem swoich potrzeb w specyfikacjach przetargów publicznych. Na bazie tych doświadczeń można sprecyzować kilka kluczowych zasad pozwalających zgodnie z prawem zamówień publicznych nabyć komponenty chmury publicznej.
Ustalenie przedmiotu zamówienia
Praktyka wynikająca z ogłoszonych i rozstrzygniętych postępowań wskazuje, że najlepszym podejściem jest zdefiniowanie przedmiotu zamówienia chmury publicznej jako dostawy standardowych pakietów subskrypcji chmury publicznej. Taki opis wynika między innymi z przytoczonej definicji chmury publicznej jako pakietów standardowych o precyzyjnie określonym zakresie funkcjonalności i sposobie działania.
Można więc, podobnie jak w przypadku pakietów oprogramowania lub karty telefonicznej prepaid, określić pakiety chmury publicznej jako produkty podlegające dostawie, opisane kodem CPV 48900000-7 – różne pakiety oprogramowania i systemy komputerowe. Rozszerzając ten opis, definiujemy opisywany komponent chmury publicznej jako produkt typu COTS (Commercial off-the-shelf). Pola eksploatacji takich produktów określone są zwykle przez dostawcę w umowach typu adhezyjnego, które można przyjąć (jeżeli odpowiadają wymaganiom zamawiającego) lub zrezygnować z zakupu produktu.
Podstawowym obowiązkiem organizatora przetargu publicznego jest ustalenie rodzaju zamówienia (zakwalifikowanie go do kategorii dostawy albo usługi), który będzie determinował szereg konsekwencji prawnych. Znowelizowana ustawa z dnia 11 września 2019 r. – Prawo zamówień publicznych (DzU z 2019 r., poz. 2019, dalej: pzp) zawiera definicje legalne dostaw i usług wskazujące odpowiednio, że: „dostawą jest nabywanie produktów, którymi są m.in. rzeczy ruchome oraz prawa majątkowe, jeżeli mogą być przedmiotem obrotu, w szczególności na podstawie umowy sprzedaży, dostawy, najmu, dzierżawy oraz leasingu z opcją lub bez opcji zakupu, które może obejmować dodatkowo rozmieszczenie lub instalację”. Usługą określa natomiast wszelkie świadczenia, które nie są robotami budowlanymi lub dostawami.
Aktualnie obowiązujące pzp podtrzymuje brzmienie definicji pojęcia „dostawy”, usuwając z niej nabycie „praw” i pozostawiając w zakresie pojęciowym nabywanie „innych dóbr”, jednak zakres pojęcia w dalszym ciągu obejmuje również nabywanie praw majątkowych.
Zasadniczo uznać można, że w sytuacji, gdy w ramach świadczenia usług chmurowych zamawiający nabywa prawo do korzystania z oprogramowania, mamy do czynienia z dostawami.
W przypadku tzw. zamówień rodzajowo mieszanych pzp wskazuje w art. 27, że jeżeli zamówienie obejmuje równocześnie usługi i dostawy, do udzielenia zamówienia stosuje się przepisy ustawy dotyczące głównego przedmiotu zamówienia.
Rola wykonawcy w przetargu na komponenty chmury
Określenie komponentów chmury publicznej jako produktów standardowych jest szczególnie ważne w sytuacji, gdy udział wykonawców w ramach realizacji przedmiotu zamówienia jest ograniczony do zapewnienia zamawiającemu dostępu do usług chmurowych świadczonych przez podmiot trzeci – dostawcę. Najczęściej dostawca nie bierze udziału w przetargu, a komponenty chmury oferowane są przez wykonawców. Wymóg, aby wykonawca składający ofertę był dostawcą chmury, ogranicza konkurencyjność. Implikuje to zakres wymagań, które można postawić wykonawcom w zakresie ich doświadczenia, zrealizowanych zamówień oraz wymagań zawartych w projekcie umowy.
Przyjmując jako przedmiot wykonania zamówienia dostawę, nie można wymagać od wykonawców kompetencji czy referencji związanych z wykonywaniem jakichkolwiek usług poza dostawą produktów. Przykładowo, adekwatnym wymaganiem do dostawy jest wykonanie w ciągu ostatnich trzech lat przynajmniej trzech dostaw pakietów subskrypcji pochodzących od producenta oferowanych pakietów subskrypcji dla przynajmniej 100 użytkowników.
Wyczerpujący opis oczekiwanych funkcji
W niezbędnych elementach opisu przedmiotu zamówienia należy wskazać na minimalne wymagania odnośnie do funkcjonalności, cech użytkowych produktów, czy też ich zgodności z wymaganiami bezpieczeństwa i prawa, np. wymagania dotyczące czasu, w jakim produkt będzie dostępny dla zamawiającego (12, 24 lub 36 miesięcy.) Określenia wymagają też parametry dostępności usług w produkcie – np. dostępność 24/7 z SLA (Service Level Agreement – umowa o gwarantowanym poziomie świadczenia tudzież dostępności usług) na poziomie minimum 99,9%.
Do listy wymaganych funkcji realizowanych przez produkt można dodać też możliwość tworzenia maszyn wirtualnych, analizę danych, składowanie danych, obsługę poczty elektronicznej, funkcje systemu finansowego i specyficzne usługi z zakresu bezpieczeństwa teleinformatycznego.
Oprócz określenia głównych funkcji produktu należy również opisać szczegółowe wymagania funkcjonalne czy techniczne, np. rodzaj systemu operacyjnego na maszynach wirtualnych, narzędzia monitorujące i zarządzające, sposób komunikacji, protokoły i wszystkie inne potrzebne zamawiającemu cechy. Należą więc do nich wymagania dotyczące parametrów poszczególnych komponentów produktu i zakresu możliwych zmian tych parametrów (konfiguracji) przez uprawnionego użytkownika, np. minimalna pojemność przestrzeni dyskowej, rdzeni procesora czy pamięci RAM, z określeniem możliwości i sposobu jej zmiany w trakcie eksploatacji, określenie wymaganego szyfrowania danych i transmisji danych czy też parametrów wydajnościowych. Należy też pamiętać o określeniu wymagań dotyczących współpracy z posiadaną przez zamawiającego infrastrukturą, np. mechanizmami zarządzania tożsamością cyfrową czy wymiany danych.
[…]
Paweł Walczak
Autor jest dyrektorem ds. rozwoju sektora publicznego Microsoft Central and Eastern Europe. Odpowiadał za koordynację działań w projekcie Zintegrowanego Systemu Zarządzania i Kontroli (realizującego dopłaty bezpośrednie dla rolnictwa) oraz brał udział w kilkudziesięciu kluczowych projektach informatycznych na terenie Polski. Odpowiada za przygotowanie wizji funkcjonalnej i technicznej projektów dla administracji publicznej oraz jest włączony w ich realizację.
