Sygn. akt: KIO 1129/19
WYROK
z dnia 4 lipca 2019 r.
Krajowa Izba Odwoławcza
w składzie:
Przewodniczący: Anna Chudzik
Protokolant:
Klaudia Ceyrowska
po rozpoznaniu na rozprawie w dniu 2 lipca 2019
r. w Warszawie odwołania wniesionego do
Prezesa Krajowej Izby Odwoławczej w dniu 17 czerwca 2019 r. przez wykonawcę
mpTechnology Sp. z o.o. z siedzibą w Słupsku,
w
postępowaniu prowadzonym przez Miasto Białystok,
orzeka:
Uwzględnia odwołanie i nakazuje Zamawiającemu zmianę postanowień SIWZ poprzez:
1.1.1. alternatywnie: (i)
udostępnienie informacji o kodach źródłowych do posiadanego
przez
Zamawiającego systemu informatycznego dynamicznej informacji
pasażerskiej, wraz z opisem niezbędnym do prawidłowej realizacji przedmiotu
zamówienia, albo (ii) udostępnienie informacji o protokołach komunikacyjnych
i interfejsach
wymiany danych do posiadanego przez Zamawiającego systemu
informatycznego dynamicznej informacji pasażerskiej, w zakresie niezbędnym
do
prawidłowej realizacji przedmiotu zamówienia, albo (iii) wprowadzenie
postanowień dopuszczających zastąpienie posiadanego przez Zamawiającego
systemu informatycznego dynamicznej informacji pasażerskiej nowym
systemem o
zakresie modułów i funkcjonalności wskazanym w § 1 ust 1.1 i 1.2.
Załącznika nr 1 do SIWZ, wraz z podaniem informacji dotyczących interfejsów
wymiany danych i protokołów komunikacyjnych do posiadanej przez
Zamawiającego infrastruktury, w celu umożliwienia komunikacji nowego
systemu
z posiadanym sprzętem;
wprowadzenie zobowiązania Zamawiającego do uzyskania zgody gwarantów
urządzeń i systemów posiadanych przez Zamawiającego na ingerencję
niezbędną w celu prawidłowej realizacji przedmiotu zamówienia;
przedłużenie terminu składania ofert o co najmniej 15 dni od dnia ogłoszenia
orzeczenia.
2. Kosztami p
ostępowania obciąża Miasto Białystok i:
2.1. zalicza w
poczet kosztów postępowania odwoławczego kwotę 7 500 zł 00 gr
(słownie: siedem tysięcy pięćset złotych zero groszy) uiszczoną przez
Odwołującego tytułem wpisu od odwołania oraz nakazuje zwrot z rachunku
Urz
ędu Zamówień Publicznych na rzecz Odwołującego kwoty 7 500 zł 00 gr
(słownie: siedem tysięcy pięćset złotych zero groszy) stanowiącej nienależnie
uiszczoną kwotę wpisu.
zasądza od Zamawiającego na rzecz Odwołującego kwotę 11 100 zł 00 gr
(słownie: jedenaście tysięcy sto złotych zero groszy) stanowiącą uzasadnione
koszty strony poniesione z tytułu wpisu od odwołania oraz wynagrodzenia
pełnomocnika;
Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. Prawo zamówień
publicznych (t.j. Dz. U. z 2018 r., poz. 1986
z późn. zm.) na niniejszy wyrok – w terminie
dni od dnia jego doręczenia – przysługuje skarga za pośrednictwem Prezesa Krajowej Izby
Odwoławczej do Sądu Okręgowego w Białymstoku.
Przewodniczący: ………………..
U z a s a d n i e n i e
Zamawiający
Miasto Białystok – prowadzi w trybie przetargu nieograniczonego
postępowanie o udzielenie zamówienia publicznego pn. Usługa asysty technicznej, bieżącej
konserwacji i rozbudowy
systemu informatycznego dynamicznej informacji pasażerskiej.
Wartość zamówienia jest mniejsza niż kwoty określone w przepisach wydanych na
podstawie art. 11 ust. 8 ustawy Pzp. Ogłoszenie o zamówieniu zostało opublikowane
w
Biuletynie Zamówień Publicznych 10 czerwca 2019 r. pod numerem 554481-N-2019.
W dniu 17 czer
wca 2019 r. wykonawca mpTechnology Sp. z o.o. wniósł odwołanie
wobec treści SIWZ określającej opis przedmiotu zamówienia. Odwołujący zarzucił
Zamawiającemu naruszenie przepisów: art. 7 ust. 1 w zw. z art. 29 ust. 1 i 2 ustawy Pzp
Odwołujący wskazał, że w treści § 1 ust. 1.1 Wzoru umowy Zamawiający
w
trzydziestu dziewięciu punktach wskazał, jakie moduły składają się na funkcjonalność
obecnie wykorzystywanego przez Zamawiającego systemu CeSIP. Zaś w § 1 ust. 1.2 Wzoru
umowy Zamawiający w czterech punktach wskazał, jakie nowe moduły – w ramach rozwoju
i rozbudowy tego systemu
– wykonawca zobowiązany jest dostarczyć. Wykonawca
zobowiązany jest rozbudować system o następujące funkcjonalności:
1.2.1. Możliwość tworzenia w systemie tzw. „przedziałów punktualności" w którym definiuje
się domknięty przedział odchyłki pojazdu od rozkładu jazdy (OD i DO) przypisując
utworzonemu przedziałowi kolor który będzie wyświetlany dla pojazdów mieszczących się
w
danym zakresie odchyłki,
1.2.2. System powinien oferować użytkownikom funkcję pozwalającą na podstawie danych
historycznych o pozycjach GPS autobusów w określonym przedziale czasu (data i godzina)
i
uprzednio wcześniej zdefiniowanym na mapie obszarze będącym dowolnym wielokątem
(poligonie) wyszukiwać i raportować obecność pojazdów. Wielkość przedziału dla którego
będzie realizowane zapytanie dot. obecności pojazdów w danej strefie może wynosić do 30
minut.
1.2.3. Możliwość przypisywania do każdego wariantu na linii jego nazwy opcjonalnej (innej
niż nazwa ostatniego przystanku na wariancie) a także symbolu legendy widocznego
w portalu i
aplikacji pasażerskiej,
1.2.4. Możliwość generowania z systemu danych w międzynarodowym formacie GTFS
Odwołujący podniósł, że w związku z tym, że dostawcą dotychczasowego systemu
CeSIP jest
PIXELS. z o.o. oraz że Zamawiający nie przekazał podstawowych informacji,
umożliwiających realizację ww. zakresów wykonawcom innym niż producent posiadanego
oprogramowania, stwierdzić należy, że obecnie jedynie PIXEL oraz ewentualny
podwykonawca PIXEL, kt
óry jest twórczą dostarczonego programu CeSIP, są w stanie
złożyć ofertę.
Odwołujący stwierdził, że Zamawiający używa zamiennie sformułowania „moduły"
i
„funkcjonalność", przy czym, mając na uwadze cytowany opis, stwierdzić należy, że
przedmiotem zamówienia jest rozbudowa funkcjonalności danych modułów, a nie dodanie
nowych modułów do systemu. Różnica ta ma istotne znaczenie, z uwagi na zakres danych,
które Zamawiający jest zobowiązany udostępnić w zależności od oczekiwanego zakresu
usługi. Na przykładzie urządzenia wielofunkcyjnego, jeżeli urządzenie to ma moduł
skanowania jednostronnego, to rozbudowa urządzenia o kolejny moduł mogłaby np.
dotyczyć kserowania, natomiast rozbudowa o kolejną funkcjonalność polegać mogłaby na
dodaniu skanowania dwustronnego. O
ile przy rozbudowie o dodatkowy moduł potrzebną są
dane umożliwiające doczepienie kolejnego „klocka", o tyle przy dodatkowej funkcjonalności,
co do zasady, potrzebne są dane umożliwiające ingerencją wewnątrz danego modułu w celu
jego przemodelowania w spo
sób, umożliwiający wykonywanie przez ten moduł
dodatkowych, wymaganych poleceń.
Zdaniem Odwołującego możliwe jest trojakie sformułowanie SIWZ, które czyniłoby
zadość oczekiwaniom Zamawiającego, a jednocześnie nie stałoby w sprzeczności
z dyspozycjami norm
zawartymi w art. 29 ust. 1 i 2 ustawy Pzp. Istnieją bowiem trzy sposoby
modyfikacji SIWZ, które prowadziłyby do umożliwienia każdemu wykonawcy, który posiada
odnośną wiedzę i doświadczenie w tego typu usługach, realizację przedmiotowego
zamówienia, bez ograniczania tej konkurencji. Każdy z przedstawionych poniżej sposobów
wymaga udostępnienia innych danych.
Po pierwsze Odwołujący wskazał, że możliwość świadczenia usługi asysty
technicznej, bieżącej konserwacji i rozbudowy SDIP (jest możliwa w drodze udostępnienia
przez Zamawiającego na obecnym etapie, tj. ogłoszenia przetargu, kodów źródłowych tego
oprogramowania (nie protokołów komunikacyjnych), gdyż obecnie (tj. bez ich udostępnienia
wykonawcom zainteresowanych zamówieniem) modyfikację czy aktualizację autorskiego
oprogramowania PIXEL może zostać wykonać tylko przez PIXEL. Odwołujący zaznaczył, że
Zamawiający wymaga od wykonawcy ingerencji bezpośrednio w kod źródłowy istniejącego
rozwiązania (CeSIP) poprzez jego rozbudowę o szczegółowe, nowe funkcje, które mogą
poprawnie działać tylko i wyłącznie poprzez ścisłe połączenie z oprogramowaniem CeSIP
i
innymi funkcjami, które obecnie realizuje. Wbrew nomenklaturze stosowanej przez
Zamawiającego CeSIP nie jest oprogramowaniem modułowym w takim stopniu jak, na
pier
wszy rzut oka, wynikałoby z opisu przedstawionego przez Zamawiającego. W związku
z
tym, nie jest możliwe dodanie do niego kolejnych „modułów" programowych bez ingerencji
w jego strukturę i modyfikację kodów źródłowych. Przywołane przez Zamawiającego
w rozd
ziale 1.1. załącznika nr 1 do SIWZ tzw. moduły są de facto funkcjami oprogramowania
CeSIP, stanowiącymi jego integralną część. Nie mogą one bowiem funkcjonować
niezależnie, jak również nie są „dodawane" do CeSIP jak moduły, czyli jako zewnętrzne
elementy,
ale stanowią, wewnętrzną, jednolitą strukturę programową, bez której CeSiP nie
pełniłby żadnej z funkcji Systemy Dynamicznej Informacji Pasażerskiej. Wskazać tu można
np. funkcje (zwane przez Zmawiającego modułami) opisane w: 1.1.7.; 1.1.8; 1.1.9; 1.1.10;
1.1.11; 1.1.12; 1.1.15 itd.. czy kolejne od 1.1.31 do 1.1.39. De facto,
tylko 4 tzw. moduły są
prawdziwymi modułami programowymi, czyli zewnętrznym oprogramowaniem „dołączanym"
do oprogramowania źródłowego w postaci modułowej, i są to moduły wskazane w: 1.1.4;
1.1.5; 1.1.14; 1.1.21, 1.1.22; 1.1.27; Pozostałe wymienione funkcje (moduły) stanowią
również integralną część oprogramowania, choć realizują funkcje drugorzędne z punktu
widzenia działania CeSIP. Niemniej, ze względu na niemodułową architekturę CeSIP oraz
fakt, że nie jest to rozwiązanie „gotowe" a dedykowane, wykonane na zlecenie
Zamawiającego przez PIXEL oraz ewentualne podmioty powiązane, w ramach innego
zamówienia publicznego, obecnie jedynie PIXEL i Zamawiający posiadają informacje
wymagane do re
alizacji zamówienia w zakresie rozbudowy CeSiP, gdyż w swobodnym
obiegu nie są dostępne żadne podręczniki czy instrukcje rozbudowy CeSiP o dodatkowe
moduły. Po przekazaniu tej wiedzy możliwe będzie wykonanie rozbudowy wg wytycznych
Zamawiającego również przez inne podmioty.
Odwołujący wskazał, że Zamawiający ma możliwość otwarcia postępowania na
konkurencję w trojaki sposób:
Po pierwsze, Zamawiający może podać kody źródłowe do posiadanego SIDP wraz
z
opisem umożliwiającym ich pełną interpretację, w zakresie niezbędnym do umożliwienia
realizacji całego przedmiotu usług.
Po drugie,
możliwość świadczenia usługi asysty technicznej, bieżącej konserwacji
i
rozbudowy SDIP jest możliwa w drodze udostępnienia przez Zamawiającego na obecnym
etapie, tj. ogłoszenia przetargu, protokołów komunikacyjnych i/lub interfejsów programowych
do oprogramowania CeSiP, które umożliwią dwukierunkową wymianę danych z CeSiP
i
zawierać będą wszystkie dane dzięki którym, wykonawca będzie mógł dołączyć
opracowane przez siebie moduły programowe. W ten sposób, dzięki zapewnieniu interfejsów
wymiany danych przez Zamawiającego nowe moduły dostarczane przez wykonawcę będą
w
pełni kompatybilne z CeSiP. Proponowane rozwiązanie wymaga minimalnej ingerencji
w
CeSIP, zapewniając jego pełną kompatybilność z nowymi modułami programowanymi,
o
których mowa w rozdz. 1.2 załącznika nr 1 do SIWZ, jednakże jest warunkiem koniecznym
do wykonania zamówienia w przypadku braku możliwości podania kodów źródłowych,
bowiem w
celu spełnienia wymagań Zamawiającego:
.2.1 należy wprowadzić funkcję zmieniającą kolor ikony pojazdu w zależności od wartości
jego opóźnienia/przyspieszenia, co nie jest możliwe bez uzyskania w czasie rzeczywistym
danych z obecnych funkcji (modułów) CeSIP (w zależności od ich szczegółów technicznych),
np. 1.1.12,1.1.13, 1.1.16; 1.1.21, 1.1.23, 1.1.25,1.1.27, oraz przekazania w czasie
rzeczywistym danych z funkcji (modułu) 1.2.1 do obecnych funkcji (modułów), np.
1.1.1,1.1.11,1.1.12,1.1.13 i 1.1.38 w celu prezentacji koloru pojazdu w CeSIP;
2 należy wprowadzić funkcję wyszukującą i raportującą pojazd ze względu na pozycję
GPS (historyczną), poprzez wprowadzenie tzw. wyszukiwarki pojazdów w wybranych
strefach detekcji, co nie jest możliwe bez uzyskania danych z obecnych funkcji (modułów)
CeSIP (w
zależności od ich szczegółów technicznych), np. 1.1.21, 1.1.23, 1.1.25,1.1.30,
1.2.3 należy wprowadzić funkcję przypisującą nowe atrybuty dla poszczególnych linii i ich
wariantów (tras), co nie jest możliwe bez uzyskania danych z obecnych funkcji (modułów)
CeSIP (w zależności od ich szczegółów technicznych), np. 1.1.6; 1.1.8; oraz przekazania
w
czasie rzeczywistym danych z funkcji (modułu) 1.2.1 do obecnych funkcji (modułów), np.
1.1.1, 1.1.20,1.1.28,1.1.36, w celu prezentacji atrybutów w CeSIP,
1.2.4 n
ależy wprowadzić funkcję generującą na zewnętrz systemu dane w formacie GTFS,
co nie jest możliwe bez uzyskania danych z obecnych funkcji (modułów) CeSIP
(w
zależności od ich szczegółów technicznych), np. 1.1.12,1.1.13, 1.1.16; 1.1.21, 1.1.23,
Po trzecie, możliwość świadczenia usługi asysty technicznej, bieżącej konserwacji
i
rozbudowy SDIP jest możliwa w drodze wyrażenia przez Zamawiającego zgody na
zastąpienie istniejącego systemu SDIP nowym systemem oraz udostępnienie przez
Zamawiającego na obecnym etapie, tj. ogłoszenia przetargu, protokołów komunikacyjnych
do wszystkich tablic pasażerskich oraz urządzeń w pojazdach obsługiwanych przez CeSIP,
w
celu umożliwienia nowemu SDIP bieżącej komunikacji i wymiany danych z infrastrukturą
Zamawiającego. Zdaniem Odwołującego wykonawcy są w stanie spełnić wymagania
stawiane
przez
Zamawiającego
poprzez
dostarczenie
własnych
rozwiązań
(oprogramowania), zastępujących CeSIP i obejmujących zarówno funkcje (moduły)
wskazane w rozdz. 1.1. załącznika nr 1 do SIWZ, jak również nowo wymagane,. Zarówno
CeSIP, jak i rozwiązania innych wykonawców, wymagają odbierania i przesyłania danych
w czasie rzeczywistym do i z
pojazdów komunikacji miejskiej i przystankowych tablic
informacji pasażerskiej. W przypadku dostawy nowego systemu centralnego, zastępującego
CeSIP, do jego poprawnego działania wymagane jest dostosowanie przez wykonawcę
interfejsów wymiany danych z pojazdami i tablicami przystankowymi, w jego własnym
oprogramowaniu, do interfejsów wymiany danych obecnie wykorzystywanych przez
autobusy i tablice przystankowe. Jest to możliwe tylko i wyłącznie na podstawie otrzymanych
od Zamawiającego opisów tychże interfejsów. W przypadku, gdy Zamawiający z jakiś
przyczyn nie będzie w stanie udostępnić przedmiotowych opisów, wykonawca może
udostępnić Zamawiającemu swoje interfejsy wraz z opisami, które powinny być
zaimplementowane przez Zamawiającego w autobusach i tablicach przystankowych.
W związku z powyższym Odwołujący o nakazanie Zamawiającemu alternatywnie:
1. dopisania
do części III po treści „Szczegółowy opis przedmiotu zamówienia oraz zakres
znajduje się w załączniku nr 1 do SIWZ stanowiącym projekt umowy" dalszej części
zdania w brzmieniu: „oraz w Załączniku nr 5, zawierającym kody źródłowe do
posiadanego przez Zamawi
ającego SIDP wraz z opisem umożliwiającym ich pełną
interpretację, w zakresie niezbędnym do umożliwienia realizacji całego przedmiotu usług";
dopisania do części III po treści „Szczegółowy opis przedmiotu zamówienia oraz zakres
znajduje się w załączniku nr 1 do SIWZ stanowiącym projekt umowy" dalszej części
zdania w brzmieniu: „oraz w Załączniku nr 5, zawierającym protokoły komunikacyjne
i
interfejsy wymiany danych do posiadanego przez Zamawiającego SIDP, w zakresie
niezbędnym do umożliwienia realizacji całego przedmiotu usług";
dopisania do części III po treści „Szczegółowy opis przedmiotu zamówienia oraz zakres
znajduje się w załączniku nr 1 do SIWZ stanowiącym projekt umowy" kolejnego zdania
w
brzmieniu: „Zamawiający dopuszcza zastąpienie posiadanego przez Zamawiającego
SIDP nowym systemem SIDP o zakresie modułów i funkcjonalności wskazanym w § 1 ust
1.1 i 1.2. Załącznika nr 1 do SIWZ, w związku z czym w Załączniku nr 5 przekazuje opisy
interfejsów wymiany danych i protokołów komunikacyjnych do posiadanej przez
Zamawiającego infrastruktury w celu umożliwienia komunikacji nowego SDIP
z
posiadanym sprzętem w tym urządzeniami pojazdowymi i tablicami przystankowymi".
Odwołujący podniósł, że w celu otwarcia konkurencji w postępowaniu, wystarczające
jest, aby Zam
awiający – zgodnie z własnym wyborem – uwzględnił odwołanie i zrealizował
jedno z żądań alternatywnych. Zdaniem Odwołującego obecne brzmienie SIWZ w sposób
rażący narusza normy z art. 7 ust. 1 i art. 29 ust. 1 i 3 ustawy Pzp, a jeżeli na obecnym
etapie Zam
awiający nie dokona stosownych modyfikacji, to zmuszony będzie do
unieważnienia postępowania, gdyż będzie ono obciążone nieusuwalnymi wadami albo
dokona wyboru oferty najkorzystniejszej z rażącym naruszeniem normy z art. 7 ust.3 ustawy
Pzp.
Odwołujący podniósł, że dla uznania naruszenia ustanowionego w art. 29 ust. 2
ustawy Pzp zakazu wystarczające jest jedynie takie działanie Zamawiającego, które mogłoby
sprzyjać naruszeniu zasady uczciwej konkurencji, niekoniecznie zaś godzić w nią
bezpośrednio. Wskazał, że celu urzeczywistnienia żądań Zamawiającego, zwycięski
wykonawca musi dysponować bardzo szczegółowymi danymi, które umożliwią realizację
usługi na systemie konkurencyjnym lub zastąpienie systemu konkurencyjnego własnym
systemem, a brak tych danych całkowicie uniemożliwia innym wykonawcom, niż twórcy
i
dostawcy obecnego SDIP złożenie oferty. SIWZ, w obecnym brzmieniu, nie pozwala
jednoznacznie stwierdzić, że Zamawiający ma zamiar przekazać zwycięskiemu wykonawcy
jakiekolwiek dane, a jeżeliby nawet przyjąć, że tak, to brak jest potwierdzenia, że zakres
przekazanych danych umożliwi wyłonionemu wykonawcy osiągnięcie zakładanego przez
Zamawiającego celu.
Odwołujący zaznaczył, że interfejsy wymiany danych to dane pozwalające na
automatyczną wymianę danych i dokumentów między różnymi systemami komputerowymi
z
wykorzystaniem ustalonych formatów komunikatów. Celem elektronicznej wymiany danych
jest wyeliminowanie wielokrotnego wprowadzania danych oraz przyspieszenie i zwiększenie
dokładności przepływu informacji dzięki połączeniu odpowiednich aplikacji komputerowych
między firmami uczestniczącymi w wymianie. Użycie interfejsów wymiany danych pozwala
poprawić czasową dostępność informacji logistycznej, poszerzyć i uściślić dane, a także
zmniejszyć pracochłonność procesu. Aby w pełni wykorzystać zalety elektronicznej wymiany
danych, uczestnicy kanału logistycznego powinni się komunikować za pośrednictwem
komputera. Innymi słowy, efektywne wdrożenie elektronicznej wymiany danych wymaga
bezpośredniej komunikacji między systemami komputerowymi, zarówno nabywców, jak
i
sprzedawców produktu, do czego niezbędne są rzeczone interfejsy wymiany danych. Kody
źródłowe to zapis programu komputerowego przy pomocy określonego języka
programowania, opisujący operacje jakie powinien wykonać komputer na zgromadzonych
lub otrzymanych danych. Kod źródłowy jest wynikiem pracy programisty i pozwala wyrazić
w
czytelnej dla człowieka formie strukturę oraz działanie programu komputerowego. Jest on
zwykle zapisywany w pliku tekstowym, lecz może również występować w postaci
fragmentów kodu opublikowanych w artykułach prasowych lub książkach. Przed
wykonaniem kod źródłowy musi zostać poddany translacji na kod wynikowy, w procesie
zwanym kompilacją. Polega on na konwersji kodu do postaci kodu wynikowego, najczęściej
kodu maszynowego, jako jedynego możliwego do wykonania przez procesor. Inną metodą
jest wykonywanie w czasie rzeczywistym („w locie") programu zapisanego kodem źródłowym
za pomocą interpretera lub kompilatora JIT (ang. Just In Time), który wykonuje kompilację
fragmentów kodu na bieżąco. Określenie „wykonanie kodu źródłowego" jest równoważne
wykonaniu programu stworzonego na podstawie tego kodu. Zamawiający w treści SIWZ nie
przekazał informacji w zakresie protokołu komunikacyjnego, kodów źródłowych ani
pozostałej dokumentacji niezbędnej wykonawcom, która umożliwi wykonanie w sposób
należyty usługi asysty technicznej, bieżącej konserwacji i rozbudowy SDIP. Brak przekazania
przez Zamawiającego tzw. protokołów komunikacji oraz kodów źródłowych pozwalających
na modyfikację systemu informatycznego, niezbędną do jej rozbudowy, konserwacji
i
bieżącej asysty technicznej, uniemożliwia w istocie sporządzenie oferty, a tym bardziej
realizację zamówienia. Zdaniem Odwołującego, udostępnienie przez Zamawiającego
protokołów komunikacyjnych, kodów źródłowych oferentom oraz pozostałej dokumentacji
technicznej, najpóźniej na 15 dni przed terminem składania ofert, umożliwi wykonawcom
oszacowanie zakresu zamówienia, jego wycenę, a na późniejszym etapie realizację
przedmiotu zamówienia. Brak uwzględnienia przez Zamawiającego informacji w zakresie
żądanej dokumentacji przerzuca na wykonawców obowiązek dokonania rozbudowy,
konserwacji i
bieżącej asysty technicznej SDIP bez elementarnych danych, umożliwiających
wyko
nanie świadczenia. Nieujawnienie danych technicznych oznacza nałożenie na
wykonawcę obowiązku samodzielnego uzyskania wszelkich informacji, danych i zezwoleń
niezbędnych do bardzo głębokiej ingerencji w autorski systemem PIXEL, któremu
przysługują prawa autorskie do oprogramowania, z którego korzysta Zamawiający. W ocenie
Odwołującego, to Zamawiający powinien – w ramach należytego sporządzania opisu
przedmiotu zamówienia – uzyskać wszelkiego rodzaju dane oraz zgody i zezwolenia
niezbędne do wykonania przedmiotu zamówienia i nie obarczać ryzykiem ich nieuzyskania
wykonawców. Wykonawcy są w rezultacie zdani na dobrą wolę dotychczasowego dostawcy
SDIP, który może podyktować zróżnicowane warunki współpracy w zależności od danego
wykonawcy, a co bardziej prawdopo
dobne, może w ogóle nie udostępnić tych danych.
Odwołujący wskazał na marginesie, że formułując żądania przedstawione
w
odwołaniu, rozważał możliwość zastosowania innych rozwiązań, które Zamawiający
mógłby chcieć zastosować w niniejszej sprawie, ale rozwiązanie to odrzucił, uznając je za
nieefektywne i nie gwarantujące uczciwej konkurencji. Odwołujący rozważał legalność
rozwiązania, które nakładałoby na wykonawców obowiązek zdobycia we własnym zakresie
niezbędnych kodów źródłowych, interfejsów oraz pozwoleń od gwarantów. Zostało to jednak
przez Odwołującego odrzucone z uwagi na niżej przedstawione przyczyny, które świadczą
o
niedopuszczalności przedstawionych rozwiązań. Zatem, jedynie przekazanie pełnych
informacji, o które Odwołujący wnioskuje, oraz uzyskanie przez Zamawiającego potwierdzeń
od gwarantów urządzeń oraz systemów, zapewnia Zamawiającemu podejmowanie działań
zgodnych z prawem.
Odwołujący wskazał, że choć sam mógłby zabiegać o pozyskanie tych danych, to
działania takie – abstrahując od faktu, że z pewnością nie przyniosłyby pożądanego efektu –
nie byłyby zgodne z zasadą równego traktowania wszystkich wykonawców. To Zamawiający
jest gospodarzem p
ostępowania, wiele miesięcy je przygotowywał i to na nim ciąży
obowiązek umożliwienia wykonawcom złożenie porównywalnych ofert. To Zamawiający
powinien zapewnić wszystkim potencjalnym wykonawcom te same warunki realizacji
zamówienia. Zamawiający nie może oczekiwać, że uprzywilejowany wykonawca PIXEL –
stanowiący bezpośrednią konkurencję dla Odwołującego – bez problemów przekaże
wszelkie niezbędne dane swojej konkurencji, by Jego konkurencja mogła złożyć ofertę
w
Postępowaniu. Jeżeli natomiast chciałby zrobić to odpłatnie, to oczekiwanie
Zamawiającego, by wykonawcy na własny koszt kupowali niezbędne dane, jest wprost
niezgodne z nakazem, by opis przedmiotu zamówienia nie utrudniał uczciwej konkurencji.
Dodatkowo, oczekiwanie by każdy inny wykonawca niż uprzywilejowany PIXEL ponosił
dodatkowe koszty, w rażący sposób narusza art. 29 ust. 2 ustawy Pzp.
Odwołujący dodał, że każda z ofert winna uwzględniać ten sam zakres przedmiotowy
– tylko w ten sposób Zamawiający uzyska porównywalne oferty. O porównywalności ofert
w
zakresie kryterium ceny (stanowi ona 60% kryteriów oceny ofert) można mówić jedynie
wówczas, gdy określone w ofertach wykonawców ceny, zostały obliczone w odniesieniu do
tego samego zakresu. Gdyby więc Odwołujący nie żądał przekazania niezbędnych informacji
i zapewnienia koniecznej komunikacji między posiadanymi przez Zamawiającego
i dostarczanymi w ram
ach postępowania rozwiązaniami informatycznymi, to mogłoby się
okazać że dostawca dotychczasowego SIDP, jako jedyny, nie jest zobowiązany do
ponoszenia dowolnie określonego przez siebie kosztu, tytułem przekazania tych
dokumentów konkurencji.
Dalej Odwołujący podniósł, że zwycięski wykonawca, który realizować będzie
przedmiotowe zamówienie, musi również mieć pewność, że czynności, które będzie
podejmował, nie będą kolidowały z uprawnieniami gwarancyjnymi Zamawiającego,
w zakresie posiadanej prz
ez Zamawiającego infrastruktury. Wskazał, że każda ingerencja
w
dostarczone urządzenia i system (a taką ingerencją jest rozbudowa, konserwacja i bieżąca
asysta techniczna systemu SDIP) może naruszać warunki gwarancji, posiadanej przez
Zamawiającego infrastruktury. Zdaniem Odwołującego SIWZ w obecnym brzmieniu nie
pozwala jednoznacznie stwierdzić, że Zamawiający posiada zgodę gwarantów posiadanych
urządzeń i systemów na ingerencję, polegającą na rozbudowie SIDP lub zastąpieniu
obecnego SIDP nowym SIDP. Bez t
akiej zgody wykonawca nie będzie w stanie bez szkody
dla Zamawiającego wykonać własnej umowy, tym samym narażając siebie na ewentualne
roszczenia odszkodowawcze.
Odwołujący wniósł o nakazanie Zamawiającemu dopisania w Części III SIWZ zdania
o
następującej treści: „Zamawiający oświadcza, że uzyska zgodę gwarantów urządzeń
i
systemów na ingerencję niezbędną w celu realizacji niniejszego zamówienia. Przedmiotowe
zgody gwarantów stanowić będą załącznik do podpisanej z Wykonawcą umowy."
Ponadto Odwołujący podniósł, że ustalony termin składania ofert (18 czerwca 2019
r.) jest zbyt krótki. Wyznaczony termin nie uwzględnia specyfiki zamówienia, złożonego
charakteru żądanych modyfikacji, a nade wszystko okoliczności, że opis przedmiotu
zamówienia jest niekompletny i niejasny. Z uwagi na fakt, że opis przedmiotu zamówienia nie
gwarantuje możliwości złożenia oferty, uwzględniające wszelkie wymagania i okoliczności
niezbędne do należytej realizacji zamówienia, Odwołujący zmuszony jest do wstrzymania się
z wyceną oferty do czasu doprecyzowania zakresu zamówienia. Sam Zamawiający
przygotowywał się do przeprowadzenia postępowania przez wiele miesięcy, zatem powinien
rozumieć, że również wykonawcy – w celu rzetelnego przygotowania oferty przetargowej –
obowiązani są do dokonania szczegółowej analizy wymagań technicznych, a także rzetelnej
wyceny wszystkich kosztów składających się na przedmiot zamówienia oraz ryzyk im
towarzyszących. Tylko wówczas bowiem wykonawcy będą w stanie należycie określić
optymalne rozwiązania, które powinny być użyte przy realizacji zamówienia oraz ewentualnie
ustalić warunki handlowe kontrahentami itp.
Odwołujący wniósł o nakazanie Zamawiającemu wydłużenia terminu składania ofert
o
co najmniej 15 dni, liczonego od czasu ogłoszenia orzeczenia KIO.
Na podstawie dokument
acji przedmiotowego postępowania oraz biorąc pod uwagę
stanowiska stron i dowody przedstawione na rozprawie, Izba
ustaliła, co następuje:
Zgodnie z punktem III SIWZ
przedmiotem zamówienia jest usługa asysty technicznej,
bieżącej konserwacji i rozbudowy systemu informatycznego dynamicznej informacji
pasażerskiej zwanego dalej „CeSIP”, którego producentem jest firma Pixel sp. z o.o. (…).
Zamawiający posiada bezterminową i nielimitowaną stanowiskowo licencję na korzystanie
z systemu
dynamiczn
ej informacji pasażerskiej zainstalowanego na serwerach
Zamawiającego. Szczegółowy opis przedmiotu zamówienia oraz zakres znajduje się
w
załączniku nr 1 do SIWZ stanowiącym projekt umowy.
W § 1 ust. 1 pkt 1.1 projektu umowy Zamawiający wyszczególnił dotychczasowe
moduły systemu (39 modułów).
Zgodnie z § 1 ust. 1 pkt 1.2 projektu umowy, w ramach rozwoju i rozbudowy systemu
Wykonawca powinien w ciągu 5 miesięcy od daty podpisania umowy rozbudować system
o
następujące funkcjonalności:
Możliwość tworzenia w systemie tzw. „przedziałów punktualności” w którym definiuje
się domknięty przedział odchyłki pojazdu od rozkładu jazdy (OD i DO) przypisując
utworzonemu przedziałowi kolor który będzie wyświetlany dla pojazdów
mieszczących się w danym zakresie odchyłki,
System powinien oferować użytkownikom funkcję pozwalającą na podstawie danych
historycznych o pozycjach GPS autobusów w określonym przedziale czasu (data
i
godzina) i uprzednio wcześniej zdefiniowanym na mapie obszarze będącym
dowolnym wielokątem (poligonie) wyszukiwać i raportować obecność pojazdów.
Wielkość przedziału dla którego będzie realizowane zapytanie dot. obecności
pojazdów w danej strefie może wynosić do 30 minut.
Możliwość przypisywania do każdego wariantu na linii jego nazwy opcjonalnej (innej
niż nazwa ostatniego przystanku na wariancie) a także symbolu legendy widocznego
w portalu i aplikacji pasażerskiej,
Możliwość generowania z systemu danych w międzynarodowym formacie GTFS,
1.2.5. Rozbudowane oprogramowanie powinn
o oferować następujące raporty:
Raport dot. danych z pojazdu i punktualności: Możliwość analizy i raportowania
wszystkich danych dostarczonych z pojazdu zestawionych z rozkładami
teoretycznymi
– m.in. nr boczny pojazdu, wysłana pozycja GPS – w formacie
WGS84 z czasem wysłania (HH:MM:SS), prędkość (km/h), informacja o wciśnięciu
przycisku panic buton, nr linii, nr brygady, nr kursu, nr wariantu, godzina jego
rozpoczęcia (HH:MM), godzina jego zakończenia (HH:MM), nazwa kierunku, nr
kierowcy, odchyłka względem teoretycznego rozkładu jazdy gdzie znak + oznacza
opóźnienie a znak minus poprzedzający wartość to przyspieszenie, nr przystanku
na którym zatrzymał się pojazd, nazwa przystanku, rzeczywista godzina przyjazdu
na przystanek (HH:MM:SS), rzeczywista godzina wyjazdu z przystanku
(HH:MM:SS), czas postoju na przystanku.
Analiza punktualności – raport ogólny dla danego dnia: W raporcie prezentowane
następujące informacje: Nr linii, nr brygady, nazwa operatora, Godzina rozpoczęcia
kursu (HH:MM)
, godzina zakończenia kursu (HH:MM), długość kursu (m),
informacja czy kurs przyspieszony /opóźniony/ w granicy tolerancji, l.p. przystanku,
nr inwentarzowy przystanku, nazwa przystanku, godzina rozkładowa (HH:MM),
rzeczywista godzina przyjazdu na przystanek (HH:MM:SS), rzeczywista godzina
odjazdu z przystanku (HH:MM:SS), odchyłka zaokrąglana do pełnych minut, nr
boczny pojazdu, informacja czy przystanek jest punktem kontroli.
Analiza odchyłek – odchyłki zbiorczo za okres dla przystanków: Możliwość
stworzenia raportu poprzez zdefiniowanie następujących parametrów: Data
początkowa (YYYY-MM-DD), Data końcowa (YYYY-MM-DD), typ dnia w wybranym
przedziale (możliwość wybrania także wszystkich), wybór linii (możliwość wybrania
wszystkich), możliwość wybrania danej brygady, możliwość zaznaczenia czy raport
ma zostać wygenerowany dla wszystkich przystanków czy tylko tych mających
cechę punktu kontroli, zakres odchyłki od do (znak minus oznacza przyspieszenie,
znak + oznacza opóźnienie).
1.2.5.4. Analiza od
chyłek – dla linii i dnia: Możliwość stworzenia raportu poprzez
zdefiniowanie następujących parametrów: Data początkowa (YYYY-MM-DD), Data
końcowa (YYYY-MM-DD), typ dnia w wybranym przedziale (możliwość wybrania
także wszystkich), wybór linii (możliwość wybrania wszystkich), wybór brygady
(możliwość wybrania wszystkich), (opcjonalnie zamiast wyboru linii i brygady można
wybrać nr boczny pojazdu), możliwość zaznaczenia czy raport ma zostać
wygenerowany dla wszystkich przystanków na linii czy tylko tych mających cechę
punktu kontroli, zakres odchyłki od do (znak minus oznacza przyspieszenie, znak +
oznacza opóźnienie).
Rzeczywiste czasy przejazdu między przystankami: Możliwość stworzenia raportu
poprzez zdefiniowanie następujących parametrów: Podajemy nr linii, nr przystanku
początkowego i przystanek docelowy (oczywiście operator może wybierać
przystanek docelowy tylko z dostępnej listy połączeń międzyprzystankowych – tj.
między przystankami musi być relacja), wybór przedziału dat (YYYY-MM-DD), typ
r
ozkładu. Wynikiem są wylistowane czasy przejazdu między przystankami (podane
w
sekundach z możliwością zaokrąglenia do minut), niezależnie od linii. Jako opcja
do zaznaczenia
– sam przejazd – lub – z obsługą przystanku startowego
– z obsługą przystanku docelowego (czyli + postój na przystanku podany
w sekundach).
Raport zatrzymań na przystanku: Tworzenie zestawień ilościowych dotyczących
zatrzymań na przystankach z podziałem na przewoźników, linie lub warianty linii
w zadanych ramach czasowych.
Moduł importu danych rozkładowych z programu SPGraf użytkowanego przez
zamawiającego.
Możliwość generowania z systemu tabliczek rozkładowych zawierających dane:
nr linii,
trasa przejazdu,
nazwa i nr inw. przystanku,
kierunek jazdy,
godziny i minuty odjazdu w dzień roboczy, sobotę i dzień świąteczny,
nazwa operatora przewozu oraz tel. kontaktowy,
data ważności rozkładu (ważny od),
legenda: opis cech autobusu, oznaczenie zjazdu do zajezdni, dojazdu do przystanku,
przystanki na trasie
z informacją o teoretycznym czasie przejazdu między przystankami
w minutach,
logo, nr telefonu, adres strony internetowej Organizatora,
kolorystyka i układ graficzny do uzgodnienia z Zamawiającym.
Zamawiający nie zamieścił w SIWZ informacji o kodach źródłowych ani o protokołach
komunikacyjnych i interfejsach wymiany danych do posiadanego systemu informatycznego,
jak również nie uwzględnił kwestii zgody gwarantów urządzeń i systemów, które
Zamawiający posiada, na ingerencję niezbędną w celu prawidłowej realizacji przedmiotu
zamówienia.
Izba zważyła, co następuje:
Na wstępie Izba ustaliła, że Odwołujący spełnia określone w art. 179 ust. 1 ustawy
Pzp przesłanki korzystania ze środków ochrony prawnej, tj. ma interes w uzyskaniu
zamówienia, a naruszenie przez Zamawiającego przepisów ustawy Pzp może spowodować
poniesienie przez niego szkody polegającej na utracie możliwości ubiegania się o udzielenie
zamówienia.
Odwołanie w całości zasługuje na uwzględnienie.
Zgodnie z art. 29 ust. 1 ustawy Pzp p
rzedmiot zamówienia opisuje się w sposób
jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń,
uwzględniając wszystkie wymagania i okoliczności mogące mieć wpływ na sporządzenie
oferty.
Art. 29 ust. 2 ustawy Pzp stanowi, że przedmiotu zamówienia nie można opisywać
w
sposób, który mógłby utrudniać uczciwą konkurencję. W ocenie Izby opis przedmiotu
zamówienia w zaskarżonym zakresie narusza przywołane wyżej przepisy ustawy.
Oceniając kwestię naruszenia art. 29 ust. 1 ustawy Pzp należy mieć na uwadze, że
celem tego przepisu jest wyeliminowanie
elementu niepewności wykonawców co do
oczekiwań zamawiającego dotyczących przedmiotu zamówienia i zagwarantowanie im
wiedzy
niezbędnej do prawidłowego przygotowania oferty i wykonania zamówienia.
Zamawiający zobowiązany jest opisać wymagania dotyczące przedmiotu zamówienia na tyle
wyczerpująco, aby każdy wykonawca miał pewność, czego zamawiający oczekuje i w jaki
sposób to wykonać.
Z kolei w świetle art. 29 ust. 2 ustawy Pzp swoboda zamawiającego
w
określaniu cech przedmiotu zamówienia i sposobu jego realizacji jest ograniczona
koniecznością zachowania w postępowaniu uczciwej konkurencji. Z jednej strony oczywistym
jest, że określenie wymagań dotyczących przedmiotu zamówienia należy do zamawiającego,
który jest gospodarzem postępowania i przyszłym nabywcą określonych towarów czy usług,
a
konieczności zachowania uczciwej konkurencji nie można utożsamiać z nakazem
umożliwienia złożenia oferty przez jak najszerszy krąg wykonawców, w oderwaniu od
potrzeb Zamawiaj
ącego. Z drugiej jednak strony niedopuszczalne jest takie opisanie
przedmiotu zamówienia, które bezzasadnie ogranicza możliwość złożenia ofert wykonawcom
mającym wszelkie kwalifikacje i możliwości jego wykonania, a nie mogą złożyć oferty z uwagi
na brak in
formacji, które są dla nich niezbędne, aby przedmiot zamówienia zrealizować.
W rozpoznawanej sprawie brak wyczerpujących informacji o przedmiocie zamówienia
i wszelkich okolicznościach mających wpływ na sporządzenie oferty stanowi jednocześnie
naruszenie u
czciwej konkurencji poprzez pozbawienie możliwości ubiegania się o udzielenie
zamówienia wykonawców innych niż spółka Pixel (wykonawca posiadanego przez
Zamawiającego systemu) lub podmioty z nią współpracujące. Przedmiot zamówienia
obejmuje bowiem m.in. rozbudow
ę systemu informatycznego dynamicznej informacji
pasażerskiej, polegającą na wdrożeniu do niego dodatkowych funkcjonalności, a wykonanie
tego elementu zamówienia w sposób nienaruszający praw wyłącznych autora systemu, nie
jest możliwe bez dostępu do kodów źródłowych lub protokołów komunikacyjnych i interfejsów
wymiany danych.
Zauważyć należy, że konieczność dostępu do kodów źródłowych nie była
kwestionowana przez Zamawiającego, który nie wykazał, aby wymagana rozbudowa
systemu była możliwa do wykonania bez dostępu do ww. danych. Zamawiający ograniczył
się do stwierdzenia, że tymi danymi nie dysponuje i próbował wykazać prawidłowość opisu
przedmiotu zamówienia powołując się na to, że zamieścił w SIWZ rzetelną informację
o
stanie prawnym dotyczącym systemu informatycznego, tj. posiadanie bezterminowej
i nielimitowanej stanowiskowo licencji na korzystanie z systemu dynamicznej informacji
pasażerskiej zainstalowanego na serwerach Zamawiającego. Nie ulega jednak wątpliwości,
że ww. licencja uprawnia jedynie do korzystania z systemu, nie umożliwia natomiast
dokonywania w nim zmian oczekiwanych przez Zamawiającego w niniejszym postępowaniu.
Do ich wprowadzenia konieczne jest bowiem dysponowanie danymi, których wykonawcom
nie przekazano, w związku z czym zamówienie może zostać zrealizowane wyłącznie
z
udziałem spółki Pixel. Nie zasługuje więc na aprobatę konsekwentnie podtrzymywana
przez Zamawiającego teza, jakoby taki opis przedmiotu zamówienia był wyczerpujący i nie
ograniczał konkurencji w postępowaniu. Skoro do wykonania rozbudowy systemu konieczny
jest dostęp do kodów źródłowych, a Zamawiający ich nie przekazał, to oczywiste jest, że
prz
edmiot zamówienia może być wykonany tylko przez producenta systemu lub przy jego
udziale. Twierdzenia
Zamawiającego o nieograniczeniu konkurencji nie zasługują na
aprobatę tym bardziej, że z jego stanowiska przedstawionego w odpowiedzi na odwołanie
oraz na rozprawie nie wynika, aby
stał on na stanowisku, że można rozbudować system bez
dostępu do ww. danych. Wręcz przeciwnie, podczas rozprawy na pytanie o taką możliwość
powołał się na art. 23 ustawy Pzp, co wprost wskazuje na konieczność udziału spółki Pixel
przynajmniej jako jednego z wykonawców wspólnie ubiegających się o udzielenie
zamówienia. Wskazał również na możliwość nawiązania współpracy z ww. podmiotem.
Wynika z tego, że sam Zamawiający dostrzega konieczność określonej formy udziału tej
spółki w rozbudowie systemu, w związku z czym twierdzenie, jakoby opis przedmiotu
zamówienia nie ograniczał konkurencji, jest w tych okolicznościach niezrozumiałe.
Odnosząc się do twierdzeń Zamawiającego, że prawidłowość opisu przedmiotu
zamówienia należy ocenić z uwzględnieniem sytuacji Zamawiającego, który nie dysponuje
kodami źródłowymi do systemu, podkreślić należy, że fakt nienabycia tych kodów jest
błędem, który nie może tłumaczyć ograniczania konkurencji w kolejnych postępowaniach.
W
tym miejscu warto przywołać stanowisko wyrażone w Rekomendacjach Prezesa UZP
dotyczących udzielania zamówień na systemy informatyczne oraz dostawę zestawów
komputerowych,
(https://www.uzp.gov.pl/__data/assets/pdf_file/0012/30702/Rekomendacje_PrezesaUZP_za
mowienia_informatyczne_2011.pdf
), w których Prezes Urzędu podał:
Zamawiający chcąc uzyskać prawo do swobodnej rozbudowy i modyfikacji systemu
informatycznego powinien przede wszystkim w umowie o zamówienie publiczne zawrzeć
postanowienia dotyczące:
przeniesienia autorskich pra
w majątkowych do zakupywanego systemu, łącznie z prawem
na udzielania zezwoleń na wykonywania zależnego prawa autorskiego; zamawiający
w
zależności od swoich potrzeb powinien szczegółowo i jednoznacznie określić pola
eksploatacji obejmujące autorskie prawa majątkowe (np. uprawniające zamawiającego do
modyfikacji oprogramowania, jego kodów źródłowych itp.);
przeniesienie praw powinno dotyczyć również kodów źródłowych w stosunku do
nowoutworzonego systemu, ich swobodnej modyfikacji; jednocześnie, zamawiający
powinien zobowiązać wykonawcę w umowie do wydania kodów źródłowych oraz pełnej
dokumentacji technicznej systemu;
warunki gwarancji jakości powinny być tak zapisywane, by nie ograniczyć lub wyłączyć
uprawnień zamawiającego z posiadania autorskich praw majątkowych, zatem modyfikacja
oprogramowania, jego kodów źródłowych prowadzona niezależnie od pierwotnego
wykonawcy nie powinna mieć wpływu na uprawnienia zamawiającego wynikłe z gwarancji
udzielonej przez wykonawcę (…).
Analogiczne stanowisko zostało przedstawione w Rekomendacjach Prezesa UZP już
w 2009 r.
https://www.uzp.gov.pl/__data/assets/pdf_file/0025/27574/Rekomendacje_UZP20ws._zamo
wiec584_na_systemy_informatyczne.pdf
Izba w pełni podziela stanowisko wyrażone w tych dokumentach, stwierdzając, że
brak możliwości przekazania wykonawcom w niniejszym postępowaniu danych niezbędnych
do wykonania zamówienia jest konsekwencją niedołożenia należytej staranności lub też
braku przewidzenia potrzeby rozbudowy systemu informatycznego na etapie jego
nabywania.
Nie stanowi to jednak usprawiedliwienia dla udzielania zamówienia w sposób
niekonkurencyjny. Tymczasem, chociaż obecne postępowanie prowadzone jest jako
przetarg nieograniczony, to de facto nie ma ono cech trybu otwartego.
Gdyby przyjąć
stanowisko o dopuszczalności takiego wyłączenia lub istotnego ograniczenia konkurencji
z
uwagi na zaniedbania powstałe na etapie nabycia systemu informatycznego, stanowiłoby
to sprzeczne z naczelnymi zasadami zamówień publicznych zezwolenie na nieograniczone
w czasie „uzależnienie” zamawiającego od pierwotnego wykonawcy systemu
informatycznego.
Analogiczne stanowisko zajęła Krajowa Izba Odwoławcza w wyroku z 8 czerwca
2018 r.
w sprawie o sygn. akt KIO 1023/18. Izba w niniejszej sprawie w pełni podziela
poglądy wyrażone w uzasadnieniu tego wyroku.
Wobec powyższego za pozostający bez znaczenia dla rozstrzygnięcia sprawy
pozostaje złożony przez Zamawiającego dowód w postaci umowy Nr BKM.I.342-2/10
zawartej 23 kwietnia 2010 r., przedstawiony
na okoliczność sytuacji prawnej i faktycznej
Zamawiającego.
Podkreślenia wymaga również, że nie sposób oczekiwać od wykonawców, którzy są
konkurentami rynkowymi
spółki Pixel, nabycia kodów źródłowych we własnym zakresie.
Oczekiwanie takie, nawet przy optymistycznym założeniu, że ww. spółka zechce je zbyć na
rzecz podmiotu będącego jej konkurentem, nadal powodowałoby nierówność wykonawców,
wyrażającą się w uzależnieniu ich sytuacji od woli i warunków podyktowanych przez
podmiot, z którym pozostają w relacjach konkurencyjnych.
Dodatkowo nie zasługuje na uwzględnienie stanowisko Zamawiającego, który na
rozprawie twierdził, że w postępowaniu o udzielnie zamówienia Zamawiający powinien
sformułować swoje oczekiwania, a wykonawca ma je zrealizować. Odnosząc się do tego
twierdzenia zauważyć należy, że jakkolwiek zamawiającemu przysługuje niekwestionowane
prawo sformułowania oczekiwań wobec przedmiotu zamówienia, to z uprawnieniem tym
skorelowany jest bezwzględny obowiązek określenia tych wymagań w sposób wyczerpujący
i precyzyjny oraz z poszanowaniem zasad uczciwej konkurencji. Zauważyć należy, że
w rozpoznawanej
sprawie nie jest tak, że Odwołujący próbuje narzucić Zamawiającemu
oczekiwania co do przedmiotu zamówienia. Przeciwnie, Odwołujący wyraża gotowość jego
wykonania zgodnie z wszystkimi wymaganiami, które Zamawiający określił, jednakże
potrzebne są do tego dane, których Zamawiający nie przekazał ani nie zobowiązał się do ich
przekazania.
Izba nie podziela również tezy Zamawiającego, że Odwołujący próbuje wymusić
dopuszczenie zaoferowania nowego systemu. Zauważyć należy, że żądanie takie zostało
sformułowane jako trzecie w kolejności żądanie alternatywne. Ponieważ jednak Odwołujący
nie będzie w stanie wykonać zamówienia bez dysponowania kodami źródłowymi lub
protokołami komunikacyjnymi i interfejsami wymiany danych, w sytuacji gdyby Zamawiający
nie uzyskał dostępu do tych danych w celu ich przekazania wykonawcom lub nie zapewnił
współpracy ze strony producenta systemu, to o nie ma innej możliwości niż dopuszczenie
rozwiązań nowych, tylko wówczas postępowanie będzie mogło być prowadzone bez
nieuzasadnionego ograniczenia konkurencji.
Jeżeli więc Zamawiający chce, aby przedmiot
zamówienia obejmował rozbudowę systemu, nie ma innej możliwości jak wykonanie
któregoś z żądań alternatywnych sformułowanych przez Odwołującego.
Dodatkowo należy zwrócić uwagę, że wykonując obowiązek udostępnienia
wykonawcom danych, o których mowa w sentencji orzeczenia, Zamawiający powinien mieć
na uwadze przepis art. 37 ust. 6 ustawy Pzp, określający sposób udostępnienia części SIWZ
w razie nałożenia na wykonawców wymogów mających na celu ochronę poufnego
charakteru informacji.
Odnosząc się do złożonych przez Odwołującego dowodów w postaci odwołań
złożonych w analogicznych sprawach i oświadczeń zamawiających o uwzględnieniu tych
odwołań, stwierdzić należy, że nie mogą być one rozstrzygające dla oceny przedmiotowej
sprawy, dotyczą bowiem innych postępowań, co do których nie są znane specyficzne dla
nich okoliczności. Niezależnie jednak od tego, z powodów wskazanych we wcześniejszej
części uzasadnienia, zarzuty odwołania należało uznać za zasadne.
Izba uwzględniła również zarzut dotyczący zaniechania określenia obowiązku
Zamawiającego dotyczącego zapewnienia, że czynności, które wykonawca będzie
podejmował w celu realizacji przedmiotu zamówienia, nie będą kolidowały z uprawnienia
z
uprawnieniami gwarancyjnymi Zamawiającego w zakresie posiadanej przez niego
infrastruktury.
Odwołujący słusznie wskazał, że ingerencja w dostarczone urządzenia
i
system może potencjalnie naruszać warunki takiej gwarancji, co mogłoby narażać
Zamawiającego na szkodę, a wykonawcę na roszczenia odszkodowawcze. Zamawiający
natomiast n
ie przedstawił w odpowiedzi na odwołanie żadnego stanowiska w tym zakresie.
Biorąc pod uwagę, że wykonanie przedmiotu zamówienia będzie się wiązać z ingerencją
w
infrastrukturę, którą Zamawiający dysponuje, wykonawca musi mieć pewność, że
wykonując zamówienie prawidłowo i zgodnie z wymaganiami Zamawiającego, nie narazi się
na roszczenia odszkodowawcze.
W związku z tym brak sprecyzowania obowiązków
Zamawiającego w tym zakresie należy uznać za naruszenie z art. 29 ust. 1 i 2 ustawy Pzp.
Izba uwzględniła również wniosek Odwołującego dotyczący terminu składania ofert
i
nakazała Zamawiającemu jego przedłużenie o co najmniej 15 dni od dnia ogłoszenia
orzeczenia
przez Izbę. Uwzględniając zmiany, jakie Izba nakazała wprowadzić w SIWZ,
przedłużenie terminu składania ofert uznać należy za zasadne i konieczne w celu
umożliwienia wykonawcom przygotowanie ofert.
Podsumowując, należy stwierdzić, że formułując postanowienia SIWZ Zamawiający
naruszył przepisy art. 7 ust. 1 oraz art. 29 ust. 1 i 2 ustawy Pzp. Ponieważ naruszenie to
może mieć istotny wpływ na wynik postępowania, odwołanie – stosownie do art. 192 ust. 2
ustawy Pzp
– podlegało uwzględnieniu.
O kosztach postępowania odwoławczego orzeczono na podstawie art. 192 ust. 9 i 10
ustawy Pzp oraz w oparciu o przepisy § 3 pkt 1 i 2 lit. b rozporządzenia Prezesa Rady
Ministrów z dnia 15 marca 2010 r. w sprawie wysokości i sposobu pobierania wpisu od
odwołania oraz rodzajów kosztów w postępowaniu odwoławczym i sposobu ich rozliczania
2018 r. poz. 972), stosownie do wyniku postępowania obciążając kosztami
Zamawiającego.
Przewodniczący: ………………..
Otrzymuj raz w tygodniu aktualne informacje
o zmianach w prawie oraz komentarzach ekspertów
Otrzymasz darmowy e-book w prezencie!
„6 pytań o znowelizowane przepisy Pzp"