eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plBaza orzeczeń KIO2018 › Sygn. akt: KIO 26/18
rodzaj: WYROK
data dokumentu: 2018-01-22
rok: 2018
sygnatury akt.:

KIO 26/18

Komisja w składzie:
Przewodniczący: Agnieszka Trojanowska Protokolant: Edyta Paziewska

po rozpoznaniu na rozprawie w Warszawie w dniu 17 stycznia 2018r.
odwołania
wniesionego do Prezesa Krajowej Izby Odwoławczej w dniu 2 stycznia 2018r. przez
wykonawc
ę GMV Innovating Solutions spółka z ograniczoną odpowiedzialnością z
siedzibą w Warszawie, ul. Hrubieszowska 2
w postępowaniu prowadzonym przez
Zamawiającego: Miasto Opole z siedzibą w Opolu, ul. Piastowska 17

przy udziale
wykonawcy S&T Poland spółka z ograniczoną odpowiedzialnością z
siedzibą w Warszawie, ul. Postępu 21D
zgłaszającego swoje przystąpienie w sprawie
sygn. akt KIO 26/18 po stronie odwołującego

przy udziale
wykonawcy MPTechnology spółka z ograniczoną odpowiedzialnością z
siedzibą w Słupsku, ul. Portowa 13B
zgłaszającego swoje przystąpienie w sprawie sygn.
akt KIO 26/18 po stronie odwołującego

przy udziale
wykonawcy Pixel spółka z ograniczoną odpowiedzialnością z siedzibą w
Osielsku, ul. Jana Pawła II 28
zgłaszającego swoje przystąpienie w sprawie sygn. akt KIO
26/18 po stronie zamawiającego


orzeka:
1.
Uwzględnia odwołanie i nakazuje zamawiającemu zmianę opisu przedmiotu
zamówienia w ogłoszeniu o zamówieniu i specyfikacji istotnych warunków
zamówienia w taki sposób, że nakazuje zamawiającemu wykreślenie i
konsekwentnie uwzględnienie skutków tego wykreślenia tak w ogłoszeniu o
zamówieniu jak i siwz zalecanego rozwiązania opartego na integracji z

posiadanym przez zamawiającego systemem i oprogramowaniem oraz
systemami dziedzinowymi, zajezdniowymi i autobusowymi, nakazała
zamawiającemu wykreślenie podkryterium Opis Techniczny Integracji w całości
i dokonanie opisu podkryterium Opis Techniczny Systemu w taki
sposób, aby
jednoznacznie było określone, jakie elementy i na jakim stopniu
szczegółowości mają być opisane przez wykonawcę ze wskazaniem punktu
OPZ,
do którego dany element się odnosi, ze wskazaniem, czy do danego
elementu zamawiający życzy sobie prezentacji na schemacie, czy w formule
tabelarycznej i czy wymaga podanie komponentów: w tym urządzeń,
oprogramowania standardowego (z półki) z nazwy i producenta i do jakiego
stopnia szczegółowości, określenia czy wymagany jest jedynie producent i
model
/nazwa komponentu głównego, czy też wraz z konfiguracją tego
komponentu np. w zakresie pamięci, procesora, pojemności dyskowej itp., Izba
nakazuje także zamawiającemu wskazanie w jaki sposób będzie oceniał ofertę
w tym kryterium, czy będzie wymagał, aby za każdy moduł opisu wykonawca
otrzymał punktu ze skali np. 1 – 5, czy też wykonawca, w którymś module może
otrzymać zero punktów, a mimo to jego ocena w całości kryterium będzie
pozytywna, z
amawiający powinien także wyjaśnić wykonawcom w sposób nie
budzący wątpliwości, kiedy ich oferta ulegnie odrzuceniu w przypadku
błędów/braków w opisie technicznym systemu w stosunku do wymagań
zamawiającego opisanych w opisie przedmiotu zamówienia,
2.
w pozostałym zakresie odwołanie oddala
3.

Kosztami postępowania obciąża Miasto Opole z siedzibą w Opolu, ul. Piastowska
17
i
3.1.
Zalicza na pocz
et kosztów postępowania kwotę 15 000 zł. 00 gr (słownie:
piętnaście tysięcy złotych zero groszy) uiszczoną przez wykonawcę GMV
Innovating Solutions
spółka z ograniczoną odpowiedzialnością z
siedzibą w Warszawie, ul. Hrubieszowska 2
tytułem wpisu od odwołania
3.2.
Zasądza od Miasta Opola z siedzibą w Opolu, ul. Piastowska 17 na
rzecz
GMV
Innovating
Solutions
spółka
z
ograniczoną
odpowiedzialnością z siedzibą w Warszawie, ul. Hrubieszowska 2

kwotę 18 941 zł. 67 gr(słownie: osiemnaście tysięcy dziewięćset
czterdzieści jeden złotych sześćdziesiąt siedem groszy) z tytułu
poniesionych kosztów zastępstwa prawnego i kosztów dojazdu oraz
uiszczonego wpisu.
Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. -
Prawo zamówień
publicznych (t.j. Dz. U. z 2017 r., poz.1579) na niniejszy wyrok - w terminie 7 dni od dnia jego

doręczenia - przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do
Sądu Okręgowego w Opolu.
Przewodniczący: ……………



Sygn. akt KIO 26/18
Uzasadnienie

Postępowanie o udzielenie zamówienia publicznego w trybie przetargu nieograniczonego na
dostawę i wdrożenie Systemu wraz z urządzeniami służącego elektronicznej obsłudze
pasażerów i poszerzeniu zakresu świadczonych usług w ramach projektu „Czysta
komunikacja publiczna -
zwiększenie mobilności mieszkańców Aglomeracji Opolskiej oraz
modernizacja infrastruktury’ towarzyszącej transportowi publicznemu - etap I” oraz
„Bezpieczny transport w Opolu."” zostało wszczęte ogłoszeniem opublikowanym w Dzienniku
Urzędowym Unii Europejskiej z dnia 21 grudnia 2017r. za numerem 2017/S 245-511561.

W dniu 2 stycznia 2018
r. wykonawca GMV Innovating Solutions spółka z ograniczoną
odpowiedzialnością z siedzibą w Warszawie – zwany dalej odwołującym wniósł odwołanie na
treść specyfikacji istotnych warunków zamówienia (siwz). Odwołanie zostało podpisane
przez pełnomocnika działającego na podstawie pełnomocnictwa z dnia 1 lipca 2016r.
udzielonego przez dwóch członków zarządu ujawnionych w KRS i upoważnionych do łącznej
reprezentacji, zgodnie z załączonym odpisem. Kopia odwołania została przekazana
zamawiającemu w dniu 2 stycznia 2018r.
Odwołujący wniósł odwołanie wobec:
1.
treść Uwag dla wykonawców w Części I siwz - Opis Przedmiotu Zamówienia:
„ W związku z trwającym procesem wymiany taboru w ramach projektu „ Czysta komunikacja
publiczna... ” oraz faktem wyłonienia dostawcy pierwszej partii autobusów, którym jest firma
MAN Bus A Truck Polska sp. z o. o., wykonawca
obowiązany jest do wykonania montażu
Modułów Pokładowych Systemu w sposób nienaruszający gwarancji dla przedmiotowych
autobusów, przy uwzględnieniu następujących wymogów:
a.
montowane urządzenia muszą posiadać dokumentację techniczną oraz certyfikaty
CE,
b.
stelaż biletomatu i sposób jego montażu musi być zgodny z wytycznymi MAN TruckA
Bus sp. z o. o. (zaleca się zakupienie stelaża w sieci serwisowej MAN),
c.
montaż instalacji w pierwszym pojeździe musi się odbyć pod nadzorem technika MAN
Bus A Truck Polska sp. z o. o. Koszty asysty technicznej (dojazdu i pracy technika) pokrywa
wykonawca,
d.
odbiór pierwszego montażu Modułów Pokładowych Systemu będzie zrealizowany
przez przedstawiciela MAN TruckA Bus Sp. z o. o., co potwierdzone będzie protokołem wraz
z wy
tycznymi instalacji Modułów Pokładowych Systemu.
Wykonawca
winien w sprawie asysty technicznej skontaktować się z MAN Bus A Truck
Polska sp. z o. o., ul. Poznańska 4a, Sady, 62-080 Tarnowo Podgórne; Pan R.K. (e-mail:
R.K.@man.eu). W przypadku zakupu autobu
sów w kolejnych postępowaniach zamawiający

zawrze w dokumentach przetargowych odpowiednie zapisy, które zapewnią odpowiednie
wyposażenie (stelaże, wyprowadzenia instalacji elektrycznej i teleinformatycznej, szyny
CAN, etc.) umożliwiające podłączenie i montaż Modułów Pokładowych Systemu bez utraty
gwarancji. ”
2.
treść pkt 4. w Części II siwz - Oferta Przetargowa Terminy Realizacji, co odpowiada
treści pkt II.2.4) Ogłoszenia o zamówieniu,
3.
treść pkt 1. IV w Części II siwz - Oferta Przetargowa Kryterium ocena techniczno-
eksploatacyjna Podkryterium obudowa kasowników,
4.
treść pkt 5a) i b) w Części III siwz - Instrukcji dla wykonawców Wykaz oświadczeń lub
dokumentów składanych przez wykonawcę wraz z ofertą, co odpowiada treści pkt III.l.l) pkt 5
a) i b) Ogłoszenia o zamówieniu,
5. treść pkt 1.4. Opisu kryteriów wyboru Oferty w Części III siwz - Instrukcji dla wykonawców
Ocena techniczno - eksploatacyjna,
6.
treść pkt 1. IV Opisu kryteriów wyboru Oferty w Części III siwz - Instrukcji dla
wykonawców Kryterium ocena techniczno-eksploatacyjna Podkryterium obudowa
kasowników,
7.
treść pkt 4. IV Opisu kryteriów wyboru Oferty w Części III siwz - Instrukcji dla
wykonawców Kryterium ocena techniczno-eksploatacyjna Podkryterium koncepcja
techniczna Systemu,
8.
treść pkt 5. IV Opisu kryteriów wyboru Oferty w Części III siwz - Instrukcji dla
wykonawców Kryterium ocena techniczno-eksploatacyjna Podkryterium kompatybilność z
systemami pokładowymi i zajezdniowymi,
9.
treść pkt II.l.16 Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu
Zamówienia, Wymagania Ogólne,
10.
treść pkt II.2.7 Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu
Zamówienia, Wymagania stawiane wykonawcy,
11.
treść pkt II.3.1.1 a) Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu
Z
amówienia, Łączność pomiędzy elementami Systemu. Informacje Ogólne,
12.
treść pkt II.4.12 Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu
Zamówienia, Wymiana danych pomiędzy elementami Systemu, Systemami Dziedzinowymi i
Systemami Zajedniowymi, w zakresie:
„Dlatego w ww. przypadkach wykonawca zapewni wykonywanie funkcji Systemów
Zajezdniowych, wymienionych w pkt 11.8.2 OPZ (tabela SYSTEMY ZAJEZDNIOWE), w inny
sposób np. poprzez dostarczenie oprogramowania o równoważnej funkcjonalności i
zbliżonym stopniu wymaganej pracochłonności dla personelu Operatora oraz zagwarantuje
ergonomiczną i komfortową obsługę Pokładowych Systemów Autobusowych, a także
raportowania
danych
eksploatacyjnych
autobusów.
wykonawca
musi
również

zagwarantować stałe przesyłanie do Systemu niezbędnych danych, w szczególności w
zakresie danych eksploatacyjnych autobusów i ich lokalizacji. wykonawca musi zapewnić w
szczególności funkcjonalności automatycznego przesyłania danych niezbędnych do
właściwego frakcjonowania Pokładowych Systemów Autobusów, Podsystemu DIP,
Podsystemu RJ, Podsystemu e-
bilet, w tym Modułów Pokładowych Systemu oraz
pozyskiwania danych eksploatacyjnych z wszystkich autobusów wyposażonych w
Autokomputer, jak i ich raportowanie w zakresie funkcjonalnym (np. do pro
gramu PDA). ”
13.
treść pkt II.8.2. Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu
Zamówienia, Zasoby zamawiającego,
14.
treść pkt II.8.4. Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu
Zamówienia, Zasoby zamawiającego, w zakresie programu KF3000 przedsiębiorstwa R&G
PLUS Sp. z o.o.
15.
treść pkt IV.6.3.2.2.1.9a) Załącznika nr 1 do umowy (IV Część siwz) – Opis
Przedmiotu Zamówienia, Podstawowe wymagania techniczne Kasownika dwufunkcyjnego,
Odwołujący zarzucił zamawiającemu:
1. narus
zenie przepisów art. 29 ust. 1 i 2 ustawy w zw. z art. 7 ust. 1 ustawy w zw. z art. 36
ust. 1 pkt. 3 w zw. z art. 41 pkt. 4 ustawy
, poprzez opisanie przedmiotu zamówienia w
sposób niejednoznaczny i niewyczerpujący, bez uwzględnienia wszystkich wymagań oraz
okoliczności mogących mieć wpływ na sporządzenie oferty, uniemożliwiający odwołującemu
złożenie oferty i ubieganie się o udzielenie zamówienia, a także w sposób naruszający
zasady zachowania uczciwej konkurencji oraz równego traktowania wykonawców, jak
również nakładający na wykonawców obowiązek spełnienia świadczenia, które jest
niemożliwe do spełnienia, poprzez:
a)
ustanowienie wymogu współpracy (integracji) dostarczanych urządzeń przez
wykonawców z posiadaną infrastrukturą zamawiającego, pomimo braku zdefiniowania
parametrów technicznych urządzeń oraz brak przekazania przez zamawiającego tzw.
protokołów komunikacyjnych oraz kodów źródłowych pozwalających na wymianę danych
informatycznych pomiędzy dostarczanymi urządzeniami wykonawcy, a istniejącą
infrast
rukturą zamawiającego, co uniemożliwia sporządzenie oferty i realizację zamówienia,
b)
brak ustanowienia możliwości dostarczenia przez
w
ykonawcę nowego,
równoważnego oprogramowania oraz urządzeń (infrastruktury), które spełniałoby wymagania
zamawiającego, a w konsekwencji uzależnienie udziału w postępowaniu od uzyskania zgody
producenta i dostawcy obecnego oprogramowania na jego wykorzystanie, a co sprawia, iż
wobec takiego sformułowania wymagań, preferowany jest producent i dostawca obecnego
oprogramowania
oraz urządzeń jako podmiot, który ma uzyskać przedmiotowe zamówienie
publiczne,
c)
ustanowienie wymogu współpracy (integracji) dostarczanych urządzeń przez

wykonawców z posiadaną infrastrukturą zamawiającego, pomimo braku zdefiniowania
parametrów technicznych urządzeń oraz brak przekazania przez zamawiającego tzw.
protokołów komunikacyjnych oraz kodów źródłowych pozwalających na wymianę danych
informatycznych pomiędzy dostarczanymi urządzeniami wykonawcy, a istniejącą
infrastrukturą zamawiającego, co prowadzi do konieczności uzyskania przez wykonawców
zgody producenta i dostawcy obecnego oprogramowania na jego wykorzystanie, w tym
implementowanie i konfigurację z istniejącym systemem, co powoduje, iż przedsiębiorstwo
PIXEL Sp. z o.o. nie będzie zainteresowane nieodpłatnym udostępnieniem dostępu do
danych lub w ogóle ich udostępnieniem, co w konsekwencji sprawia, że wykonanie
zamówienia publicznego jest niemożliwe do objęcia normalnym ryzykiem kontraktowym,
które to ryzyko jest niemożliwe do oszacowania, co w konsekwencji uniemożliwia
przygotowanie należytej wyceny oferty,
d)
ustanowienie wymogu współpracy dostarczonego systemu ze wszystkimi
urządzeniami zamawiającego mimo braku przedstawienia przez zamawiającego specyfikacji
technicznej i funkcjonalnej użytkowanych urządzeń, oraz udostępnienia protokołów
komunikacyjnych do wymiany danych oraz kodów źródłowych oprogramowania, co
uniemożliwia wykonawcy, przed rozpoczęciem testów z urządzeniami, weryfikację
ewentual
nego oddziaływania oprogramowania i urządzeń na urządzenia eksploatowane
przez
zamawiającego, co z kolei uniemożliwia realizację zamówienia i przygotowanie oferty
odpowiadającej wymaganiom zamawiającego,
e)
ustanowienie wymogu dostarczenia przez wykonawców szczegółowej dokumentacji
w postaci Opisu Technicznego Systemu oraz Opisu Technicznego Instalacji, która ma
określać proponowane przez wykonawców rozwiązania, podczas, gdy zamawiający nie
udostępnił tzw. protokołów komunikacyjnych oraz kodów źródłowych do wymiany danych, a
w konsekwencji nie jest możliwym sporządzenie owej dokumentacji przez wykonawcę
niebędącego producentem oraz dostawcą obecnego oprogramowania, a brak dostarczenia
przez wykonawcę opisu proponowanych rozwiązań w konsekwencji powoduje odrzucenie
oferty przez
zamawiającego,
f)
ustanowienie wymogu, aby autokomputer dostarczony przez w
ykonawcę umożliwiał
synchronizację urządzeń innych dostawców, które nie są objęte niniejszym postępowaniem,
co bez znajomości specyfikacji technicznej i funkcjonalnej oraz tzw. protokołów
komunikacyjnych producenta urządzeń, uniemożliwia realizację zamówienia i przygotowanie
oferty odpowiadającej wymaganiom zamawiającego, powodując tym samym, że
przedsiębiorstwa PIXEL Sp. z o.o. oraz R&G Sp. z o.o. z siedzibą w Mielcu, które są
właścicielami użytkowanego przez zamawiającego oprogramowania oraz urządzeń, z uwagi
na posiadanie pełnej wiedzy technicznej w przedmiocie specyfikacji technicznej i
funkcjonalnej użytkowanych urządzeń, będą w stanie przedstawić ofertę indywidualnie

spełniającą wyznaczone przez zamawiającego warunki, z uwagi na zastosowanie wymagań,
które preferują określonego wykonawcę, przez co złożyć korzystniejszą ofertę zarówno pod
względem ceny realizacji zamówienia, mając na uwadze ustanowione w postępowaniu
kryteria oceny,
2.
naruszenie art. 36 ust. 1 pkt 13 ustawy oraz art. 41 pkt. 9 ustawy w zw. z art. 7 ust. 1
ustawy poprzez wskazanie kryterium Oceny techniczno-
eksploatacyjnej w sposób
nieadekwatny do przedmiotu zamówienia, uniemożliwiający wybór najkorzystniejszej oferty,
naruszający zasady uczciwej konkurencji i równego traktowania uczestników postępowania,
poprzez:
a)
wskazanie
jako kryterium oceny ofert obudowę kasowników, preferując jednocześnie
metal jako materiał obudowy kasowników, podczas, gdy obudowa kasowników wykonana z
innych materiałów może zapewnić taką samą, a nawet lepszą jakość i wytrzymałość, a co
powoduje również, iż jedynie przedsiębiorstwo R&G Sp. z o.o. może spełnić przedmiotowe
kryterium i złożyć ofertę indywidualnie spełniającą wyznaczone przez zamawiającego
warunki, gdyż jest jedynym przedsiębiorstwem na polskim rynku produkującym kasowniki w
metalowej obudowie,
b)
wskaza
nie jako kryterium oceny ofert koncepcji technicznej systemu i uzależnienie
punktacji przyznawanej podczas oceny ofert od dostarczenia szczegółowej dokumentacji w
postaci Opisu Technicznego Systemu, który ma określać proponowane przez wykonawców
rozwiązania, podczas, gdy zamawiający nie udostępnił tzw. protokołów komunikacyjnych
oraz kodów źródłowych do wymiany danych, a w konsekwencji nie jest możliwym
sporządzenie owej dokumentacji przez wykonawcę niebędącego producentem oraz
dostawcą obecnego oprogramowania, co powoduje, iż wykonawca nie jest w stanie spełnić
owego kryterium,
c)
wskaza
nie jako kryterium oceny ofert kompatybilności z systemami pokładowymi i
zajezdniowymi i uzależnienie punktacji przyznawanej podczas oceny ofert od dostarczenia
szczegółowej dokumentacji w postaci Opisu Technicznego Instalacji, który ma określać
proponowane przez wykonawców rozwiązania, podczas, gdy zamawiający nie udostępnił
tzw. protokołów komunikacyjnych oraz kodów źródłowych do wymiany danych, a w
konsekwen
cji nie jest możliwym sporządzenie owej dokumentacji przez wykonawcę
niebędącego producentem oraz dostawcą obecnego oprogramowania, co powoduje, iż
wykonawca nie jest w stanie spełnić owego kryterium,
3.
naruszenie przepisów art. 7 ustawy w zw. z art. 14 ustawy i art. 139 ust. 1 ustawy
oraz art. 29 ust. 1 ustawy w zw. z art. 353(1) k.c. w zw. z art. 36 ust. 1 pkt. 16 ustawy, przez
ukształtowanie warunków umowy żądając spełnienia przez wykonawców świadczenia
niemożliwego.
Odwołujący wniósł o:

1.
nakazanie za
mawiającemu równego traktowania wszystkich podmiotów ubiegających
się o udzielenie zamówienia w przedmiotowym postępowaniu w sposób umożliwiający
zachowanie zasad uczciwej konkurencji,
2.
nakazanie
zamawiającemu opisanie przedmiotu zamówienia, w sposób który będzie
jednoznaczny i wyczerpujący i nie będzie utrudniał uczciwej konkurencji oraz będzie
umożliwiał złożenie oferty, tj. w sposób opisany w uzasadnieniu zarzutów zawartych w
niniejszym odwołaniu, w tym w szczególności poprzez zapewnienie przez zamawiającego
przekazania potencjalnym wykonawcom najpóźniej na 15 dni przed dniem składania ofert
protokołów komunikacyjnych oraz kodów źródłowych, które pozwoliłby wykonawcom na
integrację z istniejącymi urządzeniami u zamawiającego przy zapewnieniu pełnej
funk
cjonalności tych urządzeń, w tym zapewnienia przekazania przez zamawiającego
wykonawcom zgody producenta i dostawcy obecnego oprogramowania na jego
wykorzystanie, a także przedstawienia przez zamawiającego potencjalnym wykonawcom
kompletnej listy urządzeń oraz specyfikacji technicznej i funkcjonalnej urządzeń, w celu
przeprowadzenia wymaganej integracji z urządzeniami zamawiającego, a w konsekwencji
nakazanie
zamawiającemu dokonania odpowiedniej modyfikacji treści siwz oraz Ogłoszenia
o zamówieniu, tym samym odwołujący się wniósł o nakazanie zamawiającemu
wprowadzenia zamian w treści siwz w następującym zakresie:
a.
Uwag dla
wykonawców w Części I siwz - Opis Przedmiotu Zamówienia, w
ten sposób, że zamawiający zapewni samodzielnie odsprzedanie wykonawcom stelażu
biletomatów oraz usunie fragment postanowienia w zakresie zalecenia wykonawcy zakupu
stelażu sieci serwisowej MAN, jak również pokrywania przez wykonawcę kosztów asysty
technicznej,
b.
pkt 4. w Części II siwz - Oferta Przetargowa Terminy Realizacji w ten sposób, że
zamawiający dokona wykreślenia treści:
„ Termin do dnia 30.11.2019 r. na wykonanie usług rozwoju i przeniesienie części urządzeń
instalowanych w autobusach (m.in. sterowników e-bilet, kasowników, biletomatów
mobilnych), dostarczonych w etapie
V, i zainstalowania ich oraz wdrożenia w Systemie w
kolejno dostarczanych nie więcej niż 33 fabrycznie nowych autobusach zamawiającego. ”
c.
pkt 5a) i b) w Części III siwz - Instrukcji dla wykonawców Wykaz oświadczeń lub
dokumentów składanych przez wykonawcę wraz z ofertą, w ten sposób, że zamawiający
zmieni wymagania w zakresie elementów, które ma zawierać dokumentacja Opisu
Technicznego Systemu oraz Opisu Systemu Instalacji w ten sposób, iż treść
pr
zedmiotowych punktów winna otrzymać następujące brzmienie (w treści poniższych
punktów zaznaczono żądane przez odwołującego wykreślenia niedozwolonych
postanowień):
Opis Techniczny Systemu musi zawierać następujących 5 elementów:

1.
Koncepcję Systemu Centralnego
a)
Technologia wykonania Systemu Centralnego.
b)
Rozwiązanie serwerowe -- koncepcja rozwiązania, zastosowany sprzęt i urządzenia.
c)
Koncepcja wymiany danych pomiędzy Systemem Centralnym, Urządzeniami,
pojazdami oraz Lokalizacjami Zdalnymi (wraz z p
rzykładami graficznymi).
d)
Koncepcja sieci łączącej System Centralny, Urządzenia, pojazdy oraz Lokalizacje
Zdalne (wraz z przykładami graficznymi).
e)
System backupu.
W ramach tego rozdziału wykonawca opisze w jaki sposób zostanie wykonane rozwiązanie
serwerowe (s
erwerownia), wskazując technologie wykonania oraz zasady funkcjonowania
zapewniające zarówno wymaganą wydajność, jak i bezpieczeństwo, w szczególności podział
na serwery i ich zadania. Przygotuje opis technologii, koncepcję wykonania rozwiązania ze
wskazaniem Urządzeń i Oprogramowania, które zostaną nim zastosowane, ich roli i funkcji
(w szczególności serwerów i Urządzeń}, w tym ewentualnego zastosowania technologii
wirtualizaeyjnych (m.in. -
podział na serwery wirtualne i ich zadania). Wskazane zostaną
zastosowane środki gwarantujące: ciągłość i stabilność pracy Systemu (dostępność) oraz
mechanizmy utrzymania wysokiej dostępności (HA) dla Urządzeń i Oprogramowania.
Przedstawione zostaną czasy niedostępności rozwiązania ze względu na wymagania
utrzymania i konserwacji Systemu Centralnego. Wykonawca
przedstawi również planowany
zapas wydajności Systemu Centralnego i we wszystkich aspektach tj.—moc obliczeniowa,—
wydajność systemu dyskowego,—wydajność rozwiązań sieciowych i pojemności dyskowej.
Przedstaw
iona zostanie również koncepcja centralnego węzła sieci i węzłów w głównych
lokalizacjach (Serwerownia, POK, siedziba Operatora, siedziba
zamawiającego) oraz
Lokalizacjach Zdalnych tj. POS-
y, biletomaty, Moduły Pokładowe Systemu, tablice DIP,
urządzenia kontrolerskie) ujmując Urządzenia, Oprogramowanie i koncepcję funkcjonowania
węzła sieciowego. wykonawca opisze zastosowane rozwiązanie backupowe (Urządzenia,
Oprogramowanie) oraz sugerowaną strategię backupu dla Systemu, zapewniającą
bezpieczeństwo danych dla poszczególnych podsystemów lub modułów i możliwość
odtworzenia danych do wybranego momentu czasowego w przypadku Awarii.
2.
Koncepcję techniczną Podsystemów
a)
Technologia wykonania Podsystemów.
b)
—Integracja Podsystemów. Modułów itp., w ramach Systemu wraz z-przepływami
danych.
c)
—Integracji Systemu z systemami dziedzinowymi (FK. Kadry Place, itp.) wraz z
przepływami danych.
d)
Opis zastosowanych
proponowanych Urządzeń i Oprogramowania.
e)
Karta e-biletu.

f)
Uprawnienia do Systemu.
W ramach tego rozdziału wykonawca zaprezentuje technologię wykonania Podsystemów i
modułów Systemu, ich wpływ na bezpieczeństwo, wydajność i stabilność pracy z
uwzględnieniem rozwiązań softwarowych dotyczących pracy Podsystemów i Modułów, w
sieci rozleglej
i przemieszczających się lokalizacjach (np. autobusy, urządzenia
kontrolerskie) oraz koncepcję wymiany danych, spełniającą wymagania zamawiającego w
zakresie wymiany danych poza zajezdnią i offline na terenie zajezdni, a także w przypadku
utraty łączności elementów zainstalowanych w Lokalizacjach Zdalnych z Systemem
Centralnym, jak również opis mechanizmów pracy offline i późniejszej synchronizacji dla
systemów zdalnych. Zaprezentowana zostanie również integracja Podsystemów i modułów
Systemu uwzględniająca wymaganie zamawiającego, że dane w Systemie powinny być
wprowadzono raz, a wymiana danych pomiędzy Podsystemami musi się odbywać
automatycznie, bez konieczności ingerencji operatora i w zakresie wszystkich niezbędnych
danych potrzebnych Podsystemom, Modu
łami Pokładowymi Systemu, itd. Z uwagi na fakt,
iż zamawiający zakłada wymianę danych tj.—wykorzystanie danych z systemów
dziedzinowych Operatora
, tak aby nie było konieczne ręczne przenoszenie danych oraz
zasilanie zwrotne systemów dziedzinowych Operatora wszystkimi niezbędnymi danymi (np.
księgowymi, kadrowo placowymi, eksploatacyjnymi, rozliczania paliw, itp.), wykonawca
przedstawi koncepcje wymiany danych z systemami dziedzinowymi wraz ze wskazaniem
schematów’ wymiany danych i zakresami wymiany danych. Wykonawca wyspecyfikuje
również Urządzenia i Oprogramowanie wykorzystane do budowy Podsystemów i sposób ich
udostępnienia na Stanowiskach do obsługi Systemu i Urządzeniach. Opis zawierać będzie
również koncepcję funkcjonowania karty e-biletu, mapy karty oraz jej zabezpieczeń
fizycznych, technologicznych i elektronicznych, jak i zabezpieczenia Systemu przed
kopiowaniem kart e-
bilet, niewłaściwym wykorzystaniem kart lub wykorzystaniem kart
nieautoryzowanych w Systemie. W ramach opisu przedstawiony zostanie sp
osób nadawania
uprawnień do poszczególnych funkcjonalności danych Systemu, sposób wsparcia
administratora w przyznawaniu, modyfikowaniu lub odbieraniu uprawnień użytkownikom
Systemu i jego funkcjonalności.
3.
Monitorowanie Systemu
a)
Wykrywanie, monitorowanie Awarii Systemu.
b)
Program do zgłaszania i usuwania Awarii („ bug trucker ”).
c)
Badanie i raportowanie wydajności i dostępności Systemu.
Wykonawca
zaprezentuje sposób monitorowania poprawności działania Systemu oraz
metody zarządzania Systemem (w tym m.in. aktualizacji, konfiguracji, itp. poszczególnych
jego elementów: Podsystemów, Modułów, Urządzeń, itp.) wraz z wskazaniem narzędzi do
tego przeznac
zonych. Monitorowanie poprawności działania obejmie zarówno System

Centralny i Serwerownię, jak i Moduły Pokładowe Systemu, lokalizacje zdalne (w
szczególności POS), Urządzenia, funkcjonowanie Podsystemów i modułów Systemu (ze
szczególnym uwzględnieniem POP). Elementem szczególnie istotnym opisu jest
monitorowanie Systemu Centralnego i Serwerowni, ze względu na fakt, że będzie ona
zlokalizowana poza siedzibą Operatora i zamawiającego. Przedstawiona zostanie również
koncepcja zgłaszania Awarii do wykonawcy oraz możliwości monitorowania stanu ich
realizacji i zgodności z wymaganiami dotyczącymi serwisu, możliwości generowania
statystyk występowania Awarii, w podziale na ich rodzaje, zakres i typy. wykonawca poda
sposób i algorytm, w jaki będzie monitorował i raportował dostępność oraz wydajność
Systemu, w wymaganych przez
zamawiającego, okresach miesięcznych. Raportowanie
dostępności powinno się odnosić do deklarowanych w ofercie wartości.
4.
Koncepcja systemu raportowania
a)
Opis zastosowanego narzędzia do raportowania.
b)
Sposób realizacji systemu raportowania dla Systemu Centralnego i Podsystemów.
c)
Możliwość tworzenia własnych raportów, zestawień, statystyk itp., elementy
wspierające użytkowników w ich tworzeniu.
Rozdział zawierać będzie opis systemu i narzędzi do raportowania z uwzględnieniem:
możliwości wykonywania i tworzenia raportów, przenoszenia ich do innych aplikacji,
wykorzystywania raportów do pozyskiwania danych, wsparcie dla automatycznego
wykonywania raportów zestawień i statystyk (okresowo, jednorazowo na wskazany
czas/datę, itp.), możliwości tworzenia własnych raportów, zestawień czy statystyk przez
użytkowników oraz rozwiązania wspierające administratora w przygotowaniu, system
uprawnień i do raportów i ich wykonywania przez użytkowników.
5.
Licencje
a)
Opis proponowanego sposobu licencjonowania Systemu, Podsystemów, Modułów,
Urządzeń i Oprogramowania.
b)
Możliwość przenoszenia licencji pomiędzy zamawiającym i Operatorem.
Rozdział zawierać będzie ogólne zasady i przyjęty sposób licencjonowania Systemu,
zarówno Oprogramowania Standardowego, Dedykowanego jak i Oprogramowania RJ,
odnośnie do przedstawionych preferencji przez zamawiającego, możliwości przenoszenia
licencji pomiędzy zamawiającym i Operatorem, możliwości przenoszenia licencji pomiędzy
Urządzeniami, zasady rozszerzania licencji. Opis ma pozwolić na zweryfikowanie
dostarczonego zestawienia Oprogramowania w zakresie zgodności z wymaganiami OPZ.
Wymagania dotyczące sposobu wykonania Opisu Technicznego Systemu:
-
Poszczególne punkty (1 do 5) wymienione powyżej stanowić będą rozdziały Opisu
Technicznego.
-
Wymagania wykazane w każdym z punktów stanowiły będą podrozdziały każdego z

rozdziałów zgodnie z ww. kolejnością.
-
Zwięzłość opisu, przedstawienie informacji w-formie tabelarycznej.
-
Zawa
rcie istotnych informacji pozwalających zamawiającemu potwierdzić możliwość
realizacji - wykonania Systemu przez w
ykonawcę.
-
Każdy z opisów musi mieć odniesienia do (wskazanie rozdziału i punktów)
wymagania
z OPZ, które-jest wypełniane.
-
Koncepcja musi w
skazywać rozwiązania gwarantujące wydajność i bezpieczeństwo
proponowanego rozwiązania.
Dla przepływów danych oraz rozwiązań złożonych z wielu urządzeń wymagane są schematy
graficzne.
-
zamawiający nie dopuszcza załączania wprost manuali lub instrukcji, ani ich fragmentów.
d.
pkt 1.4. Opisu kryteriów wyboru Oferty w Części III siwz - Instrukcji dla wykonawców
Ocena techniczno -
eksploatacyjna, w ten sposób, że zamawiający dokona usunięcia
kryterium oceny ofert w postaci tego kryterium jak
o preferującego rozwiązania stasowane
przez dotychczasowego wykonawcę systemu lub w przypadku nieuwzględnienia
przedmiotowego żądania dokonanie zmian zgodnie z punktami e), f), i g) poniżej,
e.
pkt 1. IV Opisu kryteriów wyboru Oferty w Części III siwz - Instrukcji dla wykonawców
Kryterium ocena techniczno-
eksploatacyjna Podkryterium obudowa kasowników, w ten
sposób, że zamawiający dokona usunięcia kryterium oceny ofert w postaci obudowy
kasowników,
f.
pkt 4. IV Opisu kryteriów wyboru Oferty w Części III siwz - Instrukcji dla wykonawców
Kryterium ocena techniczno-eksploatacyjna Podkryterium koncepcja techniczna Systemu,
przez zmianę postanowienia w ten sposób, że zamawiający określi dokładnie dane, które
mają zostać zawarte w dokumencie Koncepcji technicznej Podsystemów, określi rodzaje
podsystemów oraz usunie wymóg opisania przez wykonawcę opisu zastosowanych
urządzeń oraz oprogramowania, jak również usunie postanowienie: „Złożenie Opisu
Technicznego Systemu, nie spełniającego wymagań określonych w OPZ będzie skutkować
odrzuceniem oferty wykonawcy
jako niezgodnej z treścią siwz na podstawie art. 89 ust. 1
pkt. 2 Prawa. ”
g.
pkt 5. IV Opisu kryteriów wyboru Oferty w Części III siwz - Instrukcji dla wykonawców
Kryterium ocena techniczno-eksploatacyjna Podkryterium
kompatybilność z systemami
pokładowymi i zajezdniowymi, przez zmianę postanowienia w ten sposób, że zamawiający
nie będzie wymagał od wykonawcy wymiany danych i kompatybilności Modułów
Pokładowych Systemu z Systemami Pokładowymi Autobusów i Zajezdniowymi oraz umożliwi
wykonawcy dostarczenie równoważnego oprogramowania oraz urządzeń, a także w ten
sposób, że zamawiający wykaże wszelkie informacje oraz dane niezbędne do
p
rzeprowadzenia integracji pokładowej oraz usunie wymóg opisania przez wykonawcę opisu

zastosowanych urządzeń oraz oprogramowania,
h.
pkt II.l.16 Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu Zamówienia,
Wymagania Ogólne, w ten sposób, że zamawiający określi termin zatwierdzenia przez
zamawiającego projektu Systemu oraz projektów interfejsów użytkowników,
i.
pkt II.2.7 Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu Zamówienia,
Wymagania stawiane wykonawcy,
przez wykreślenie ppkt. w całości.
j.
pkt II.3.1.1 a) Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu
Zamówienia, Łączność pomiędzy elementami Systemu. Informacje Ogólne, przez
wykreślenie tego postanowienia,
k.
pkt II.4.12 Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu Zamówienia,
Wymiana danych pomiędzy elementami Systemu, Systemami Dziedzinowymi i Systemami
Zajezdniowymi, w ten sposób, że zamawiający dopuści możliwość dostarczenia odrębnego,
równoważnego oprogramowania, które nie będzie musiało spełniać wymogu
kompatybilności,
l.
pkt II.8.2. Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu Zamówienia,
Zasoby
zamawiającego, przez usunięcie postanowienia,
m.
pkt II.8.4. Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu Zamówienia,
Zasoby zama
wiającego, w zakresie pierwszego wiersza w tabeli dotyczącego programu
KF3000 przedsiębiorstwa R&G PLUS Sp. z o.o., przez usunięcie postanowienia,
n.
pkt IV.6.3.2.2.1.9a) Załącznika nr 1 do umowy (IV Część siwz) – Opis Przedmiotu
Zamówienia, Podstawowe wymagania techniczne Kasownika dwufunkcyjnego, przez
usunięcie wymaganego maksymalnego wymiaru kasownika.
J
ak również o nakazanie zamawiającemu wprowadzenia zamian w treści Ogłoszenia o
zamówieniu w następującym zakresie:
a.
pkt II.2.4) Ogłoszenia o zamówieniu, w ten sposób, że zamawiający dokona
wykreślenia treści:
„Termin do dnia 30.11.2019 r. na wykonanie usług rozwoju i przeniesienie części urządzeń
instalowanych w autobusach (m.in. sterowników e-bilet, kasowników, biletomatów
mobilnych), dostarczonych
w etapie V, i zainstalowania ich oraz wdrożenia w Systemie w
kolejno dostarczanych nie więcej niż 33 fabrycznie nowych autobusach zamawiającego. ”
b.
pkt III.1.1) pkt 5 a) i b) Ogłoszenia o zamówieniu, w ten sposób, że zamawiający
zmieni wymagania w zakres
ie elementów, które ma zawierać dokumentacja Opisu
Technicznego Systemu oraz Opisu Systemu Instalacji.
Odwołujący wskazał, że jako wykonawcy ubiegającemu się o udzielenie zamówienia,
przysługuje prawo do wniesienia odwołania zgodnie z dyspozycją przepisu art. 179 ust. 1
ustawy. Interes
odwołującego wyraża się tym, że w razie braku wprowadzenia
wnioskowanych zmian, a co za tym idzie utrzymania zapisów, które w ocenie odwołującego

są sprzeczne z przepisami ustawy, odwołujący może zostać pozbawiony możliwości złożenia
prawidłowej, niepodlegającej odrzuceniu oferty, a co za tym idzie możliwości uzyskania
zamówienia publicznego, jak również zawarcia niepodlegającej unieważnieniu umowy w
przedmiocie zamówienia publicznego na warunkach, które umożliwiają jej wykonanie.
Odwołujący podniósł, że bezwzględnym obowiązkiem zamawiającego jest opisanie
przedmiotu zamówienia tak, aby umożliwiał on złożenie ofert porównywalnych,
zawierających urządzenia spełniające identyczne wymagania techniczne i jakościowe.
W ocenie
odwołującego, w przedmiotowej sprawie zamawiający nie zrealizował swego
podstawowego, opisanego powyżej obowiązku w zakresie przygotowania postępowania
przetargowego. Doszło bowiem do naruszenia zarówno art. 29 ust. 1 i 2 ustawy, jak i art. 7
ustawy
, gdyż zamawiający dopuścił się opisania przedmiotu zamówienia w sposób
niejednoznaczny, nie uwzględniając wszystkich wymagań i okoliczności mogących mieć
wpływ na sporządzenie oferty. Co więcej dokonał opisu przedmiotu zamówienia w sposób,
który rażąco narusza zasady uczciwej konkurencji i równego traktowania wykonawców.
Z
amawiający w treści siwz nie wskazał informacji w zakresie protokołu komunikacyjnego ani
pozostałej dokumentacji niezbędnej wykonawcom, która umożliwi w sposób należyty
współpracę (integrację) dostarczanych urządzeń przez wykonawców z posiadaną
infrastrukturą zamawiającego. Brak zdefiniowania parametrów technicznych urządzeń oraz
brak przekazania przez
zamawiającego tzw. protokołów komunikacyjnych oraz kodów
źródłowych pozwalających na wymianę danych informatycznych pomiędzy dostarczanymi
urządzeniami wykonawcy, a istniejącą infrastrukturą zamawiającego, uniemożliwia w istocie
sporządzenie oferty i realizację zamówienia. Odwołujący podkreślił, iż dopiero udostępnienie
przez
zamawiającego protokołu komunikacyjnego oferentom oraz pozostałej dokumentacji
technicznej, najpóźniej na 15 dni przed terminem składania ofert, umożliwi wykonawcom
realizację przedmiotu zamówienia. Brak uwzględnienia przez zamawiającego informacji w
zakresie przekazania dokumentacji przerzuca na
wykonawców obowiązek dokonania
integracji bez przekazania danych technicznych dotyczących urządzeń zamontowanych u
zamawiającego, jak i danych do integracji z systemem zamawiającego. Nie ujawnienie
danych technicznych warunkujących możliwość dokonania integracji w rezultacie oznacza
nałożenie na wykonawcę wyłonionego w przetargu samodzielnego uzyskania wszelkich
informacji, danych i zezwoleń niezbędnych do zapewnienia kompatybilności oraz integracji z
systemem zamontowanym w pojazdach zamawiającego oraz zapewnienia sobie współpracy
z podmiotami, którym przysługują prawa autorskie do oprogramowania, z którego aktualnie
korzysta
zamawiający. zamawiający nie zapewnił jednakże, że dane techniczne w ogóle
zostaną udostępnione przez dostawcę systemu informacji pasażerskiej. W ocenie
odwołującego zamawiający powinien zobowiązać się do uzyskania wszelkiego rodzaju
niezbędnego oprogramowania (niezbędnych protokołów komunikacyjnych i kodów

źródłowych) oraz zgód i zezwoleń niezbędnych do wykonania przedmiotu zamówienia i nie
obarczać ryzykiem ich nieuzyskania wykonawców. Wykonawca jest w rezultacie zdany na
dobrą wolę dotychczasowego dostawcy systemu, który może podyktować zróżnicowane
warunki współpracy w zależności od danego wykonawcy, a co bardziej prawdopodobne nie
udostępnić tych danych w ogóle, co umożliwi temu wykonawcy złożenie jedynej oferty w
przedmiotowym postępowaniu.
W związku z powyższym zamawiający powinien dokonać modyfikacji Uwag dla wykonawców
w Części I siwz - Opis Przedmiotu Zamówienia w ten sposób, że zamawiający powinien we
własnym zakresie dopełnić obowiązku zakupu niezbędnych stelaży biletomatów, a także
wykupienia usług związanych z nadzorem przy montażu urządzeń (pkt b, c oraz d). W ocenie
odwołującego się nie może dochodzić do sytuacji, w których podmiot trzeci jest uprawniony
do dyktowania różnych cen podmiotom zainteresowanym uzyskaniem zamówienia
publicznego. Jest bowiem powszechną praktyką, iż poszczególni producenci autobusów
współpracują z niektórymi wykonawcami systemów informacji pasażerskiej, a tym samym
wykonawcy ci będą znajdować się w pozycji uprzywilejowanej do pozostałych wykonawców,
co tym samym naruszać będzie zasadę równego traktowania wykonawców. Dodatkowo
MAN Truck& Bus Sp. z o. o. wiedząc, że wykonawca przedmiotu zamówienia będzie
zobowiązany do korzystania z jego usług może zaoferować niekonkurencyjne stawki
wynagrodzenia za swoją usługę stawiając wykonawcę w sytuacji bez wyjścia. Złożenie oferty
do udziału w postępowaniu przez wykonawcę jest uzależnione od uzyskania zgody
producenta i dostawcy obecnego oprogramowania (przedsiębiorstwo PIXEL Sp. z o.o. z
siedzibą w Osielsku oraz R&G Sp. z o.o. z siedzibą w Mielcu), na jego wykorzystanie, a co
sprawia, iż wobec takiego sformułowania wymagań, preferowany jest producent i dostawca
obecnego oprogramowania oraz urządzeń jako podmiot, który ma uzyskać przedmiotowe
zamówienie publiczne. Zasada równego traktowania wykonawców sprzeciwia się
preferowaniu lub dyskryminacji któregokolwiek z wykonawców, gwarantuje wykonawcom
równe szanse w dostępie do informacji o zamówieniu i w uzyskaniu zamówienia oraz
przeciwdziała wykorzystywaniu pozycji monopolistycznych przez któregokolwiek z
wykonawców. Nie można określać w specyfikacji istotnych warunków zamówienia wymogów
dla przedmiotu zamówienia tak, aby spełniał je tylko jeden oferowany na rynku produkt. Tym
k
oniecznym jest dokonanie przedmiotowej zmiany lub też zapewnienie przez zamawiającego
udzielenia ww. zgód przez obu dotychczasowych wykonawców. Zamawiający ustanowił
wymóg dostarczenia przez wykonawców szczegółowej dokumentacji w postaci Opisu
Technicznego
Systemu oraz Opisu Technicznego Instalacji, która ma określać proponowane
przez wykonawców rozwiązania, podczas, gdy zamawiający nie udostępnił tzw. protokołów
komunikacyjnych oraz kodów źródłowych do wymiany danych. zamawiający nie podaje
żadnych szczegółów technicznych dotyczących systemów zajezdniowych, a tym samym

niemożliwym jest stworzenie przez wykonawców żądanej przez zamawiającego
dokumentacji.
Z
amawiający ustanowił wymóg, aby autokomputer dostarczony przez wykonawcę umożliwiał
synchronizację urządzeń innych dostawców, które nie są objęte niniejszym postępowaniem,
co bez znajomości specyfikacji technicznej i funkcjonalnej oraz tzw. protokołów
komunikacyjnych producenta dotychczas funkcjonujących u zamawiającego urządzeń,
uniemożliwia realizację zamówienia i przygotowanie oferty odpowiadającej wymaganiom
zamawiającego, powodując tym samym, że jedynie przedsiębiorstwa PIXEL Sp. z o.o. oraz
R&G Sp. z o.o. z siedzibą w Mielcu, które są właścicielami użytkowanego przez
zamawiającego oprogramowania oraz urządzeń, z uwagi na posiadanie pełnej wiedzy
technicznej w przedmiocie specyfikacji technicznej i funkcjonalnej użytkowanych urządzeń,
będą w stanie przedstawić ofertę.
Z
amawiający jako podkryterium umieścił wymóg w zakresie obudowy kasowników,
przyznając 1 pkt za metalową obudowę urządzenia. Wskazanie przez zamawiającego jako
kryterium oceny ofert obudowy kasowników i preferowanie jednocześnie metalu jako
materiału obudowy kasowników powoduje, iż przedmiotowe kryterium może spełnić jedynie
przedsiębiorstwo R&G, gdyż jest jedynym przedsiębiorstwem na polskim rynku
produkującym kasowniki w metalowej obudowie. Odwołujący wskazał, iż obudowa
kasowników wykonana z innych materiałów może zapewnić taką samą, a nawet lepszą
jakość i wytrzymałość, a zatem zamawiający nie powinien stawiać w uprzywilejowanej
pozycji tylko jednego z wykonawców. Zamawiający winien dopuścić możliwość zaoferowania
przez wykonawców kasowników w obudowie wykonanej z innego materiału niż metal i
całkowicie usunąć kryterium oceny ofert w postaci obudowy kasowników.
K
ryterium oceny ofert koncepcji technicznej systemu i uzależnienie punktacji przyznawanej
podczas oceny ofert od dostarczenia szczegółowej dokumentacji w postaci Opisu
Technicznego Systemu również narusza zasadę równego traktowania wykonawców w
postępowaniu przetargowym, gdyż jedynym podmiotem, który jest w stanie dostarczyć
zamawiającemu przedmiotową dokumentacje jest przedsiębiorstwo PIXEL, które posiada
szczegółową i techniczną wiedzę na temat urządzeń, którymi obecnie dysponuje
zamawiający. Żaden inny wykonawca, nie jest w stanie sporządzić dokumentacji, która ma
określać proponowane przez wykonawców rozwiązania, podczas, gdy zamawiający nie
udostępnił tzw. protokołów komunikacyjnych oraz kodów źródłowych do wymiany danych.
zamaw
iający wskazał w treści siwz, iż wykonawca ma przedstawić Integrację Podsystemów,
Modułów wraz z przepływami danych nie precyzując w żaden sposób jakie to mają być
podsystemy oraz jakie dane, ani w jakich zakresach dane mają zostać wymienione. W
ocenie odw
ołującego się na etapie oceny ofert zamawiający nie powinien wymagać od
wykonawców przedstawienia opisu urządzeń oraz oprogramowania. wykonawcy nie są

również w stanie sporządzić szczegółowej dokumentacji w postaci Opisu Technicznego
Instalacji. Jedynym pr
zedsiębiorstwem, które jest w stanie zapewnić kompatybilność
oprogramowania z aktualnie wykorzystywanym przez za
mawiającego sprzętem jest
przedsiębiorstwo Pixel. Znamiennym jest także, że zamawiający nie umożliwił wykonawcom
dostarczenia równoważnych lub lepszych urządzeń innych niż produkcji przedsiębiorstwa
Pixel. Z
amawiający nie podał również żadnych informacji niezbędnych do przeprowadzenia
rzeczonej integracji pokładowej. Zamawiający wymaga dostarczenia Koncepcji rozwiązań
sieciowych na terenie zajezdni (w tym urządzeń i oprogramowania do wymiany danych na
terenie zaj
ezdni, jednakże wykonawca będzie miał możliwość wyboru urządzeń dopiero na
późniejszym etapie, po zweryfikowaniu potrzeb zamawiającego. Zamawiający nie przekazał
wykonawcom żadnych standardów wymiany danych dla autokomputerów przedsiębiorstwa
Pixel oraz oprogramowania przez nich dostarczonego tj. PDA (Pixel Data Analyzer).
W pkt II. 1.16 Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu Zamówienia,
Wymagania Ogólne, zamawiający nie określił terminu zatwierdzenia przez siebie projektu
Systemu oraz projektów interfejsów użytkowników.
W pkt II.2.7 Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu Zamówienia,
Wymagania stawiane wykonawcy
, podkreślić należy iż podczas instalacji nowych urządzeń
w przypadku ingerencji w instalację elektryczną autobusu nie zajdzie potrzeba czasowego
ograniczenia lub zatrzymania funkcjonalności obecnie użytkowanych Urządzeń i Systemów,
nie będących własnością wykonawcy. Brak przedstawienia przez zamawiającego
specyfikacji technicznej i funkcjonalnej użytkowanych urządzeń oraz udostępnienia
protokołów komunikacyjnych do wymiany danych oraz kodów źródłowych oprogramowania
uniemożliwia wykonawcy weryfikację ewentualnego oddziaływania oprogramowania i
urządzeń na urządzenia eksploatowane przez zamawiającego
Odnosząc się do pkt II.3.1.1 a) Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu
Zamówienia, Łączność pomiędzy elementami Systemu. Informacje Ogólne, odwołujący
podkreślił, iż wykonawcy nie są w stanie zagwarantować bezpieczeństwa komunikacji dla
urządzeń, które nie są ich własnością, tj. autokomputerów stanowiących własność
podmiotów trzecich, a zatem należy wykreślić owe postanowienie.
Odnosząc się do pkt II.4.12 Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu
Zamówienia, Wymiana danych pomiędzy elementami Systemu, Systemami Dziedzinowymi i
Systemami Zajezdniowymi,
odwołujący podkreślił, iż zarówno program Pixel Data Analyzer
PDA jak i Pakiet PIXEL 3 nie zapewnia w żadnym stopniu realizacji funkcji związanych z
zarządzaniem e- biletem tj. m.in. definiowaniem taryfy biletowej, rozliczeniami, raportami,
zarządzaniem Punktami Obsługi Pasażera, personalizacją kart e-bilet, kodowaniem
doładowań, zarządzaniem kasownikami oraz biletomatami mobilnymi. Niezbędnym jest
dostarczenie osobnego oprogramowania, które będzie realizowało wymienione funkcje.

Odwołujący wniósł zatem o zmianę postanowienia, w ten sposób, aby zamawiający dopuścił
mo
żliwość dostarczenia odrębnego, równoważnego oprogramowania, które nie będzie
musiało spełniać wymogu kompatybilności.
Nawiązując do pkt II.8.2. Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu
Zamówienia, Zasoby zamawiającego, odwołujący wskazał, iż nie jest w stanie dostarczyć
oprogramowania spełniającego tożsame funkcje, gdyż jedynym przedsiębiorstwem
mogącym je spełnić jest przedsiębiorstwo PIXEL Sp. z o.o. Odwołujący wniósł zatem o
nakazanie usunięcia przedmiotowego postanowienia.
Zdaniem odw
ołującego pkt II.8.4. Załącznika nr 1 do umowy (IV Część siwz) - Opis
Przedmiotu Zamówienia, Zasoby zamawiającego, winien zostać usunięty przez
zamawiającego w zakresie pierwszego wiersza w tabeli dotyczącego programu KF3000
przedsiębiorstwa R&G PLUS Sp. z o.o. Odwołujący wskazał, iż nie jest w stanie dostarczyć
oprogramowania spełniającego tożsame funkcje, gdyż jedynym przedsiębiorstwem
mogącym je spełnić jest przedsiębiorstwo R&G PLUS Sp. z o.o. Odwołujący wniósł zatem o
nakazanie usunięcia przedmiotowego postanowienia.
Pkt IV.6.3.2.2.1.9a) Załącznika nr 1 do umowy (IV Część siwz) - Opis Przedmiotu
Zamówienia, Podstawowe wymagania techniczne Kasownika dwufunkcyjnego, winien zostać
usunięty, gdyż zamawiający nie powinien wymagać od wykonawcy dostarczenia kasownika
o określonych wymiarach, gdyż w żadnym stopniu nie wpływa to na jego jakość czy też
funkcjonalność. Podkreślić przy tym należy, iż zamawiający określił maksymalne wymiary
kasownika, który jest stosowane w produkcji kasowników przedsiębiorstwa R&G Sp. z o.o.

W dniu 3 stycznia 2018
r. zamawiający poinformował wykonawców o wniesieniu odwołania
zamieszczając na stronie internetowej kopię odwołania.

W dniu 4 stycznia 2018
r. do postępowania odwoławczego po stronie odwołującego zgłosił
swój udział wykonawca S&T Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
Warszawie wnosząc o uwzględnienie odwołania. Wskazał, że posiada interes w
rozstrzygnięciu na korzyść odwołującego, gdyż zamierza złożyć ofertę w tym postępowaniu,
a zaskarżone postanowienia siwz i ogłoszenia mogą uniemożliwić bądź utrudnić mu
uzyskanie przedmiotowego zamówienia. Zgłoszenie zostało podpisane przez prezesa
zarządu i członka zarządu ujawnionych w KRS i upoważnionych do łącznej reprezentacji,
zgodnie ze złożonym odpisem. Kopia zgłoszenia została przekazana odwołującemu i
zamawiającemu w dniu 4 stycznia 2018r.

W dniu 5 stycznia 2018r. do postępowania odwoławczego po stronie zamawiającego zgłosił
swój udział wykonawca Pixel spółka z ograniczoną odpowiedzialnością z siedzibą w

O
sielsku wnosząc o oddalenie odwołania. Wskazał, że posiada interes w rozstrzygnięciu na
korzyść zamawiającego, gdyż w razie uwzględnienia żądań odwołującego jego interes dozna
uszczerbku i może zostać pozbawiony możliwości uzyskania zamówienia. Zgłoszenie
zostało podpisane przez pełnomocnika działającego na podstawie pełnomocnictwa z dnia 4
stycznia 2018r. udzielonego przez prezesa zarządu ujawnionego w KRS i upoważnionego do
samodzielnej reprezentacji, zgodnie z załączonym odpisem. Kopia zgłoszenia została
przekazana zamawiającemu i odwołującemu w dniu 5 stycznia 2018r.

W dniu 8 stycznia 2018r. do postępowania odwoławczego po stronie odwołującego zgłosił
swój udział wykonawca MPTechnology spółka z ograniczoną odpowiedzialnością z siedzibą
w Słupsku wnosząc o uwzględnienie odwołania. Wskazał, że posiada interes w
rozstrzygnięciu na korzyść odwołującego, gdyż zamierza złożyć ofertę w tym postępowaniu,
a zaskarżone postanowienia siwz i ogłoszenia mogą uniemożliwić bądź utrudnić mu
uzyskanie przedmiotowego zam
ówienia. Zgłoszenie zostało podpisane przez prezesa
zarządu ujawnionego w KRS i upoważnionego do samodzielnej reprezentacji, zgodnie ze
złożonym odpisem. Kopia zgłoszenia została przekazana odwołującemu i zamawiającemu w
dniu 8 stycznia 2018r.

Zamawiający i przystępujący Pixel na posiedzeniu wnieśli odpowiedzi na odwołanie żądając
oddalenia odwołania w całości. Zgodnie wskazali, że zamawiający dopuścił rozwiązanie
równoważne w postaci możliwości stworzenia systemu w oparciu o własne urządzenia i
oprogramo
wanie wykonawcy, bez konieczności integracji. Zamawiający premiowanie
rozwiązania opartego o integrację uzasadniał specyfiką zawodu kierowcy i koniecznością
szkolenia personelu bez możliwości zaburzenia przebiegu komunikacji miejskiej,
efektywnością wydatkowania środków publicznych, a także tym, że do części urządzeń i
oprogramowanie nie posiada kodów źródłowych i protokołów komunikacyjnych, nie jest
zainteresowany ich nabywaniem i nie może ich przekazać, ale w jego ocenie współpraca z
dostawcami urządzeń i oprogramowani jest możliwa, zaś nadzór MAN Truck &Bus wynika z
warunków gwarancyjnych, a firma stosuje ogólnodostępne cenniki. Zamawiający podkreślał
także większą trwałość kasowników metalowych, opartą o doświadczenie własne
zamawiającego. Przystępujący podnosił natomiast chaotyczność i niespójność odwołanie,
brak powiązania zarzutów z żądaniami i bezzasadność żądań.

Izba ustaliła następujący stan faktyczny:
Izba dopuściła dowody z dokumentacji postępowania tj. ogłoszenia o zamówieniu i siwz wraz
z załącznikami:
W ogłoszeniu o zamówieniu w sekcji II.2.4 zamawiający zawarł następujące postanowienia:

Dostawa i wdrożenie Systemu wraz z urządzeniami służącego elektronicznej obsłudze
pasażerów i poszerzeniu zakresu świadczonych usług w ramach projektów: „Czysta
komunikacja publiczna
– zwiększenie mobilności mieszkańców Aglomeracji Opolskiej oraz
modernizacja infrastruktury towarzyszącej transportowi publicznemu – etap I” oraz
„Bezpieczny transport w Opolu”.
Termin realizacji
– 270 dni od daty podpisania umowy na realizację podstawowego zakresu
przedmiotu zamówienia. Termin do dnia 30.11.2019 r. na wykonanie usług rozwoju i
przeniesienie części urządzeń instalowanych w autobusach (m.in. sterowników e-bilet,
ka
sowników, biletomatów mobilnych), dostarczonych w etapie V, i zainstalowania ich oraz
wdrożenia w Systemie w kolejno dostarczanych nie więcej niż 33 fabrycznie nowych
autobusach Zamawiającego.
Zamawiający przewiduje udzielenie zamówienia, o którym mowa w art. 67 ust. 1 pkt. 7
Prawa zamówień publicznych w wielkości nie więcej niż 21 kompletów Modułów
Pokładowych Systemu, tj. wyposażania pokładowego autobusów takiego jak: kasowników,
biletomatów mobilnych, sterowników e-biletu oraz innych urządzeń, połączonych ze sobą na
pokładzie autobusu siecią informatyczną tworzącą spójny system, komunikujących się z
Systemem Centralnym online za pomocą sieci GSM lub Wi-Fi. Przedmiotowe zamówienie
związane jest z zamiarem zwiększenia ilości taboru.
Izba oceniła, że zamawiający w par. 4 wzoru umowy zdefiniował pojęcie „usług rozwoju” w
sposób precyzyjny i jednoznaczny. Jednocześnie zamawiający przewidział definicję
Modułów Pokładowych Systemu, z której wynika, że są to urządzenia, których montaż i
instalacja leży po stronie wykonawcy Systemu, a zatem Izba dała wiarę wyjaśnieniom
zamawiającego, że przeniesienie urządzeń dotyczy tylko tych urządzeń, które montuje
wy
konawca Systemu, a nie urządzeń innych wykonawców. Izba oceniła takie rozwiązanie
jako dopuszczalne na gruncie art. 29 ust. 1 i 2 ustawy oraz art. 7 ust. 1 ustawy, biorąc
przede wszystkim pod uwagę fakt, że jeśli są to wyłącznie usługi rozwojowe według przyjętej
definicji, oraz przenoszenie urządzeń dostarczonych przez wykonawcę Systemu, to wymóg
ten jest jednoznacznie opisany i jednakowy dla wszystkich wykonawców, a tym samym nie
narusza uczciwej konkurencji. Zamawiający w ocenie Izby podał także wiarygodny powód
określenia daty końcowej terminem 30 listopada 2019r., gdyż jest to termin wynikający z
wymogów udzielonego zamawiającemu dofinansowania.
W części I siwz OPZ zamawiający w uwagach dla wykonawców podał:
W związku z trwającym procesem wymiany taboru w ramach projektu „Czysta komunikacja
publiczna…” oraz faktem wyłonienia dostawcy pierwszej partii autobusów, którym jest firma
MAN Bus & Truck Polska sp. z o. o., Wykonawca obowiązany jest do wykonania montażu
Mo
dułów Pokładowych Systemu w sposób nienaruszający gwarancji dla przedmiotowych
autobusów, przy uwzględnieniu następujących wymogów:

a.
montowane urządzenia muszą posiadać dokumentację techniczną oraz certyfikaty
CE,
b.
stelaż biletomatu i sposób jego montażu musi być zgodny z wytycznymi MAN Truck&
Bus sp. z o. o. (zaleca się zakupienie stelaża w sieci serwisowej MAN),
c.
montaż instalacji w pierwszym pojeździe musi się odbyć pod nadzorem technika MAN
Bus & Truck Polska sp. z o. o. Koszty asysty technicznej (dojazdu i pracy technika) pokrywa
Wykonawca,
d.
odbiór pierwszego montażu Modułów Pokładowych Systemu będzie zrealizowany
przez przedstawiciela MAN Truck& Bus Sp. z o. o., co potwierdzone będzie protokołem wraz
z wytycznymi instalacji Modułów Pokładowych Systemu.
Wykonawca winien w sprawie asysty
technicznej skontaktować się z MAN Bus & Truck
Polska sp. z o. o., ul. Poznańska 4a, Sady, 62-080 Tarnowo Podgórne; Pan R.K. (e-mail:
R.K.
@man.eu). W przypadku zakupu autobusów w kolejnych postępowaniach Zamawiający
zawrze w dokumentach przetargowych odpow
iednie zapisy, które zapewnią odpowiednie
wyposażenie (stelaże, wyprowadzenia instalacji elektrycznej i teleinformatycznej, szyny
CAN, etc.) umożliwiające podłączenie i montaż Modułów Pokładowych Systemu bez utraty
gwarancji.
Izba przy ocenie tego wymagan
ia wzięła pod uwagę pismo z MAN BUS & TRUCK z dnia 11
stycznia 2018r., w którym MAN potwierdził, że wymóg asysty technicznej przy montażu
stelaży wynika z udzielonych zamawiającemu warunków gwarancji. W ocenie Izby
odwołujący nie wykazał, że któryś z wykonawców, będzie preferowany przez MAN przy
asyście związanej z instalacją montaży, lub też któryś otrzyma inne warunki finansowania niż
pozostali wykonawcy. Nadto w ocenie Izby potencjalna odmowa asysty byłaby niezgodna z
potwierdzonymi przez MAN warunkami g
warancji, zatem wykonanie zamówienia w tym
zakresie nie jest niemożliwe. Izba dała wiarę oświadczeniu firmy MAN, że udostępnia on na
swoich stronach internetowych ogólnodostępne cenniki, co było możliwe do zweryfikowania i
ustalenia, że części akcesoriów publikowane są w formie nieodpłatnych cenników, a część
cenników w tym dotyczących akcesoriów do autobusów jest dostępna w płatnym dostępie
czasowym. Biorąc to pod uwagę, Izba oceniła, że odwołujący nie wykazał, że istnieje
przykładowo podmiot zabudowujący systemy na autobusach MAN, który może uzyskać
bardziej preferencyjne warunki, niż inni wykonawcy. Tym samym Izba uznała, że wymóg
zamawiającego jest uzasadniony jego potrzebami i nie zostało wykazane, że jest wymogiem
dyskryminującym.
W
pkt. 4 części II siwz - Oferta zamawiający wskazał:
W pkt 4 termin realizacji
– 270 dni od daty podpisania umowy na realizację podstawowego
zakresu przedmiotu zamówienia. Termin do dnia 30.11.2019 r. na wykonanie usług rozwoju i
przeniesienie części urządzeń instalowanych w autobusach (m.in. sterowników e-bilet,

kasowników, biletomatów mobilnych), dostarczonych w etapie V, i zainstalowania ich oraz
wdrożenia w Systemie w kolejno dostarczanych nie więcej niż 33 fabrycznie nowych
autobusach Zamawiającego.
Izba w tym zakresie podtrzymuje swoje ustalenia poczynione na kanwie sekcji II.2.4.
ogłoszenia o zamówieniu.
Zamawiający określił jako czwarte kryterium:
IV kryterium: ocena techniczno-eksploatacyjna:
1. podkryterium: obudowa kasowników
Materiał z jakiego wykonano obudowę kasowników TAK/NIE* obudowa metalowa/ obudowa
z tworzyw sztucznych i innych
Izba rozważając stanowiska stron i uczestników postępowania wzięła pod uwagę, że
zamawiający przyznał, iż istnieje norma w zakresie wytrzymałości kasowników na uderzenie,
ale stwierdził, czemu odwołujący i przystępujący po jego stronie nie zaprzeczyli, że nie
istnieje nor
ma na trwałość kasowników. Zamawiający wskazał, że jego doświadczenie
wskazuje na to, że obudowy kasowników z metalu są trwalsze. W ocenie Izby obowiązek
wykazania, że kryterium oceny ofert jest nieprawidłowo określone, ciąży na odwołującym.
Odwołujący wskazał, że jedynym producentem na rynku krajowym jest wykonawca R&G,
jednak zamawiający wskazał, że na rynku europejskim istnieje jeszcze co najmniej jeden
wykonawca oferujący takie obudowy. Kryteria oceny ofert z racji ich eliminacyjnego
charakteru zawsze b
ędą preferowały określone parametry czy rozwiązania, gdyż mają
prowadzić do wyboru oferty najkorzystniejszej. W ocenie Izby bezsporne jest to, że nie ma
obiektywnej normy na trwałość, którą zamawiający mógłby zastosować, zamawiający ma
uzasadnioną potrzebę, aby kasowniki były trwałe, bo zmniejsza to koszty ich eksploatacji,
zamawiający wykazał także, że nie ograniczył konkurencji do jednego dostawcy kasowników,
tym samym Izba nie znalazła podstaw do przyjęcia, że przedmiotowe kryterium oceny ofert
mogło zaburzyć konkurencyjność przedmiotowego postępowania w sposób sprzeczny z
ustawą. Na taką ocenę dokonaną przez Izbę miał także wpływ fakt, iż zamawiający
przewidział 1% wagę tego kryterium.
W pkt. 5 a i b pkt. I Warunki udziału dla wykonawców część III siwz zamawiający wskazał:
5.
W celu potwierdzenia, że oferowane dostawy odpowiadają wymaganiom określonym w
SIWZ Wykonawca do oferty dołączy:
a.
Opis Techniczny Systemu zawierający rozwiązania oferowane przez wykonawcę
(szczegółowe wymagania zamawiający zawarł na str. 19-26 SIWZ, w rozdziale „Opis
kryteriów wyboru oferty”).
Dokument winien zawierać wszystkie wymagane szczegółowe informacje w danym punkcie
opisu proponowanyc
h rozwiązań. Proponowane przez wykonawcę rozwiązania należy
potwierdzić przykładami ze zrealizowanych wdrożeń. Opisy uzupełnić przykładami

graficznymi (np. schematami logicznymi/ schematami blokowymi/ rysunkami/ diagramami,
itp.) dotyczącymi w szczególności: połączeń sieciowych pomiędzy urządzeniami; instalacji
serwerowej, autobusowej, w lokali
zacjach; sieci rozległej lub lokalnej; przepływu danych
pomiędzy podsystemami/ modułami/ Urządzeniami, Systemem, a systemami dziedzinowymi,
itp.
b.
Opis Techniczny Integracji w zakresie wymiany danych pomiędzy systemami
zajezdniowymi, Systemem Centralnym
i Podsystemami oraz koncepcję programowania
Systemów Pokładowych Autobusu i Modułów Pokładowych Systemu (szczegółowe
wymagania z
amawiający zawarł na str. 19-26 SIWZ, w rozdziale „Opis kryteriów wyboru
oferty”).
Opisy techniczne oferowanych
rozwiązań, załączone do oferty wykonawcy, będą podstawą
dla projektu Systemu wymaganego do przygotowania, zgodnie z przedmiotem umowy, w
ramach Etapu I.
W części III siwz przy opisie kryteriów oceny ofert zamawiający zawarł następujące
postanowienia:
IV kryterium: ocena techniczno-eksploatacyjna (waga = 15%)
– 15 pkt.
W ramach powyższego kryterium zamawiający zastosuje 5 podkryteriów.
1. podkryterium: obudowa kasowników (T1) = waga 1% - 1 pkt
Materiał z jakiego wykonano obudowę kasowników:
- obudowa metalowa
– 1 pkt
- obudowa z tworzywa sztucznego
– 0 pkt.
4. podkryterium: koncepcja techniczna Systemu (T4) = waga 4% - 4 pkt.
Zamawiający przyzna punkty w powyższym podkryterium na podstawie Opisu Technicznego
Systemu zaproponowanego przez w
ykonawcę w ofercie.
Dokument na
leży przygotować w języku polskim zgodnie z wymaganiami przedstawionymi
poniżej, z zachowaniem kolejności i numeracji poszczególnych podrozdziałów. Dokument
musi się odnosić do każdego punktu poniższych wymagań z zachowaniem podanej
numeracji oraz zawierać wszystkie wymagane szczegółowe informacje w danym punkcie
opisu (dla oceny danego punktu nie będą brane pod uwagę opisy zawarte w innych punktach
opisu technicznego) proponowanych rozwiązań.
Opis Techniczny Systemu musi zawierać następujących 5 elementów:
1.
Koncepcję Systemu Centralnego
a)
Technologia wykonania Systemu Centralnego.
b)
Rozwiązanie serwerowe – koncepcja rozwiązania, zastosowany sprzęt i urządzenia.
c)
Koncepcja wymiany danych pomiędzy Systemem Centralnym, Urządzeniami,
pojazdami oraz Loka
lizacjami Zdalnymi (wraz z przykładami graficznymi).
d)
Koncepcja sieci łączącej System Centralny, Urządzenia, pojazdy oraz Lokalizacje

Zdalne (wraz z przykładami graficznymi).
e)
System backupu.
W ramach tego rozdziału wykonawca opisze w jaki sposób zostanie wykonane rozwiązanie
serwerowe (Serwerownia), wskazując technologie wykonania oraz zasady funkcjonowania
zapewniające zarówno wymaganą wydajność, jak i bezpieczeństwo, w szczególności podział
na serwery i ich zadania. Przygotuje opis technologii, konce
pcję wykonania rozwiązania ze
wskazaniem Urządzeń i Oprogramowania, które zostaną w nim zastosowane, ich roli i funkcji
(w szczególności serwerów i Urządzeń), w tym ewentualnego zastosowania technologii
wirtualizacyjnych (m.in. podział na serwery wirtualne i ich zadania). Wskazane zostaną
zastosowane środki gwarantujące: ciągłość i stabilność pracy Systemu (dostępność) oraz
mechanizmy utrzymania wysokiej dostępności (HA) dla Urządzeń i Oprogramowania.
Przedstawione zostaną czasy niedostępności rozwiązania ze względu na wymagania
utrzymania i konserwacji Systemu Centralnego. Wykonawca przedstawi również planowany
zapas wydajności Systemu Centralnego (we wszystkich aspektach tj. moc obliczeniowa,
wydajność systemu dyskowego, wydajność rozwiązań sieciowych) i pojemności dyskowej.
Przedstawiona zostanie również koncepcja centralnego węzła sieci i węzłów w głównych
lokalizacjach (Serwerownia, POK, siedziba Operatora, siedziba z
amawiającego) oraz
Lokalizacjach Zdalnych tj. POS-
y, biletomaty, Moduły Pokładowe Systemu, tablice DIP,
urządzenia kontrolerskie) ujmując Urządzenia, Oprogramowanie i koncepcję funkcjonowania
węzła sieciowego. Wykonawca opisze zastosowane rozwiązanie backupowe (Urządzenia,
Oprogramowanie) oraz sugerowaną strategię backupu dla Systemu, zapewniającą
bezpieczeństwo danych dla poszczególnych podsystemów lub modułów i możliwość
odtworzenia danych do wybranego momentu czasowego w przypadku Awarii.
2.
Koncepcję techniczną Podsystemów
a)
Technologia wykonania Podsystemów.
b)
Integracja Podsystemów, Modułów itp., w ramach Systemu wraz z przepływami
danych.
c)
Integracji Systemu z systemami dziedzinowymi (FK, Kadry-
Płace, itp.) wraz z
przepływami danych.
d)
Opis zastosowanych Urządzeń i Oprogramowania.
e)
Karta e-biletu.
f)
Uprawnienia do Systemu.
W rama
ch tego rozdziału wykonawca zaprezentuje technologię wykonania Podsystemów i
modułów Systemu, ich wpływ na bezpieczeństwo, wydajność i stabilność pracy z
uwzględnieniem rozwiązań softwarowych dotyczących pracy Podsystemów i Modułów, w
sieci rozległej i przemieszczających się lokalizacjach (np. autobusy, urządzenia
kontrolerskie) oraz koncepcję wymiany danych, spełniającą wymagania zamawiającego w

zakresie wymiany danych poza zajezdnią i offline na terenie zajezdni, a także w przypadku
utraty łączności elementów zainstalowanych w Lokalizacjach Zdalnych z Systemem
Centralnym, jak również opis mechanizmów pracy offline i późniejszej synchronizacji dla
systemów zdalnych. Zaprezentowana zostanie również integracja Podsystemów i modułów
Sy
stemu uwzględniająca wymaganie zamawiającego, że dane w Systemie powinny być
wprowadzone raz, a wymiana danych pomiędzy Podsystemami musi się odbywać
automatycznie, bez konieczności ingerencji operatora i w zakresie wszystkich niezbędnych
danych potrzebnych Podsystemom, Modułami Pokładowymi Systemu, itd. Z uwagi na fakt, iż
z
amawiający zakłada wymianę danych tj. wykorzystanie danych z systemów dziedzinowych
Operatora, tak aby nie było konieczne ręczne przenoszenie danych oraz zasilanie zwrotne
systemów dziedzinowych Operatora wszystkimi niezbędnymi danymi (np. księgowymi,
kadrowo-
płacowymi, eksploatacyjnymi, rozliczania paliw, itp.), Wykonawca przedstawi
koncepcje wymiany danych
z systemami dziedzinowymi wraz ze wskazaniem schematów
wymiany danych i zakresami wymiany danych. Wykona
wca wyspecyfikuje również
Urządzenia i Oprogramowanie wykorzystane do budowy Podsystemów i sposób ich
udostępnienia na Stanowiskach do obsługi Systemu i Urządzeniach. Opis zawierać będzie
również koncepcję funkcjonowania karty e-biletu, mapy karty oraz jej zabezpieczeń
fizycznych, technologicznych i elektronicznych, jak i zabezpieczenia Systemu przed
kopiowaniem kart e-
bilet, niewłaściwym wykorzystaniem kart lub wykorzystaniem kart
nieautoryzowanych w Systemie.
W ramach opisu przedstawiony zostanie sposób nadawania
uprawnień do poszczególnych funkcjonalności i danych Systemu, sposób wsparcia
administratora w przyznawaniu, modyfikowaniu lub odbieraniu uprawnień użytkownikom
Systemu i jego funkcjonalności.
3.
Monitorowanie Systemu
a)
Wykrywanie, monitorowanie Awarii Systemu.
b)
Program do zgłaszania i usuwania Awarii („bug trucker”).
c)
Badanie i raportowanie wydajności i dostępności Systemu.
Wykonawca zaprezentuje sposób monitorowania poprawności działania Systemu oraz
metody zarządzania Systemem (w tym m.in. aktualizacji, konfiguracji, itp. poszczególnych
jego elementów: Podsystemów, Modułów, Urządzeń, itp.) wraz z wskazaniem narzędzi do
tego
przeznaczonych. Monitorowanie poprawności działania obejmie zarówno System
Centralny i Serwerownię, jak i Moduły Pokładowe Systemu, lokalizacje zdalne (w
szczególności POS), Urządzenia, funkcjonowanie Podsystemów i modułów Systemu (ze
szczególnym uwzględnieniem POP). Elementem szczególnie istotnym opisu jest
monitorowanie Systemu Centralnego i Serwerowni, ze względu na fakt, że będzie ona
zlokalizowana poza siedzibą Operatora i Zamawiającego. Przedstawiona zostanie również
koncepcja zgłaszania Awarii do Wykonawcy oraz możliwości monitorowania stanu ich

realizacji i zgodności z wymaganiami dotyczącymi serwisu, możliwości generowania
statystyk występowania Awarii, w podziale na ich rodzaje, zakres i typy. Wykonawca poda
sposób i algorytm, w jaki będzie monitorował i raportował dostępność oraz wydajność
Systemu, w wymaganych przez Zamawiającego, okresach miesięcznych. Raportowanie
dostępności powinno się odnosić do deklarowanych w ofercie wartości.
4.
Koncepcja systemu raportowania
a)
Opis zastosowanego narzędzia do raportowania.
b)
Sposób realizacji systemu raportowania dla Systemu Centralnego i Podsystemów.
c)
Możliwość tworzenia własnych raportów, zestawień, statystyk itp., elementy
wspierające użytkowników w ich tworzeniu.
Rozdział zawierać będzie opis systemu i narzędzi do raportowania z uwzględnieniem:
możliwości wykonywania i tworzenia raportów, przenoszenia ich do innych aplikacji,
wykorzystywania raportów do pozyskiwania danych, wsparcie dla automatycznego
wykonywania raportów zestawień i statystyk (okresowo, jednorazowo na wskazany
czas/datę, itp.), możliwości tworzenia własnych raportów, zestawień czy statystyk przez
użytkowników oraz rozwiązania wspierające administratora w przygotowaniu, system
uprawnień i do raportów i ich wykonywania przez użytkowników.
5.
Licencje
a)
Opis proponowanego sposobu licencjonowania Systemu, P
odsystemów, Modułów,
Urządzeń i Oprogramowania.
b)
Możliwość przenoszenia licencji pomiędzy Zamawiającym i Operatorem.
Rozdział zawierać będzie ogólne zasady i przyjęty sposób licencjonowania Systemu,
zarówno Oprogramowania Standardowego, Dedykowanego jak i Oprogramowania RJ,
odnośnie do przedstawionych preferencji przez Zamawiającego, możliwości przenoszenia
licencji pomiędzy zamawiającym i Operatorem, możliwości przenoszenia licencji pomiędzy
Urządzeniami, zasady rozszerzania licencji. Opis ma pozwolić na zweryfikowanie
dostarczonego zestawienia Oprogramowania w zakresie
zgodności z wymaganiami OPZ.
Wymagania dotyczące sposobu wykonania Opisu Technicznego Systemu:
-
Poszczególne punkty (1 do 5) wymienione powyżej stanowić będą rozdziały Opisu
Technicznego.
-
Wymagania wykazane w każdym z punktów stanowiły będą podrozdziały każdego z
rozdziałów zgodnie z ww. kolejnością.
-
Zwięzłość opisu, przedstawienie informacji w formie tabelarycznej.
-
Zawarcie istotnych informacji pozwalających zamawiającemu potwierdzić możliwość
realizacji
– wykonania Systemu przez wykonawcę.
-
Każdy z opisów musi mieć odniesienia do (wskazanie rozdziału i punktów)
wymagania z OPZ, które jest wypełniane.

-
Koncep
cja musi wskazywać rozwiązania gwarantujące wydajność i bezpieczeństwo
proponowanego rozwiązania.
-
Dla przepływów danych oraz rozwiązań złożonych z wielu urządzeń wymagane są
schematy graficzne.
-
Zamawiający nie dopuszcza załączania wprost manuali lub instrukcji, ani ich
fragmentów.
Za każdy z ww. 5 elementów wykonawca może otrzymać 10 punktów:
0 pkt. otrzyma oferta, której opis realizacji danego rozwiązania (każdego z wymaganych
osobno) pomija sposób jej wdrożenia i/albo przedstawione rozwiązanie nie w pełni
pokrywa/opisuje oczekiwania z
amawiającego określone w wymaganiach.
10 pkt. otrzyma oferta, której opis realizacji danego wymagania [każdego z wymaganych
osobno (wypisanych w pkt. 1. do 5.)] przedstawiał będzie sposób wdrożenia opisanej
funkcjon
alności oraz będzie pokrywał/spełniał oczekiwania zamawiającego określone w
wymaganiach, a także będzie ujmował uzasadnienie, że przedstawiony sposób wdrożenia
pozwalał będzie zrealizować w pełni opisane wymaganie, wskazując szczegóły tego
rozwiązania. Wskazane jest także zaprezentowanie przykładowego wdrożenia zrealizowane
przez wykonawcę lub wskazanego podwykonawcę.
Łącznie wykonawca w podkryterium „koncepcja techniczna Systemu” może otrzymać do 50
pkt. (OToferta).
Wartość w tym podkryterium zostanie obliczona na podstawie poniższego wzoru:

OT = (OToferta/OTmax) x 4 pkt.,
gdzie:
OToferta
– liczba punktów otrzymanych w kryterium „koncepcja techniczna Systemu” dla
badanej oferty,
OTmax
– liczba punktów najlepszej oferty otrzymanych w kryterium „koncepcja techniczna
Systemu” dla badanej oferty.
Złożenie Opisu Technicznego Systemu, nie spełniającego wymagań określonych w OPZ
będzie skutkować odrzuceniem oferty Wykonawcy jako niezgodnej z treścią SIWZ na
podstawie art. 89 ust.1 pkt. 2 Prawa.
W ocenie Izby opis sposobu oceny przedmiotowego kryterium oceny ofert nie jest
jednoznaczny i czytelny. Świadczą o tym także pytania zadawane wobec postanowień tego
podkryterium, które Izba ustaliła poniżej, a które wzięła pod uwagę przy ocenie ustalonego
stanu faktycznego. Izba nie dała wiary stanowisku zamawiającego, że wymaga jedynie
koncepcji technicznej systemu, przeczy temu zarówno opis oceny tego podkryterium, w
którym zamawiający domaga się przedstawienia w ocenie Izby szczegółowych rozwiązań tak
programistycznych jak i sprzętowych i to tak w zakresie hardwaru, jak i innych urządzeń
systemu w tym Modułów Pokładowych Systemu. W ocenie Izby żądanie takiego opisu

powinno być jednoznaczne i precyzyjne. Zamawiający powinien szczegółowo wskazać, dla
których elementów systemu wymaga jedynie przedstawienia schematów, prezentacji
graficznych, dla których rozwiązań dotyczycących przepływu informacji, jakie funkcjonalności
są dla zamawiającego najważniejsze i wymagają uwzględnienia w koncepcji. W ocenie Izby
przedstawienie z jednej strony szczegółowych wymagań w opisie technicznym systemu, a z
drugiej wymaganie, aby wykonawca odzwierciedlił wszystkie elementy opisu przedmiotu
zamówienia, które to wymaganie jest wymaganiem blankietowym (w rzeczywistości
mogącym być odzwierciedlone przez przepisanie OPZ do opisu technicznego systemu z
podaniem nazw zastosowanych urządzeń czy oprogramowania), powoduje, że kryterium nie
jest jednoznaczne. W ocenie Izby niejednoznac
zny jest także sposób przyznawania punktacji
i to kiedy wykonawca otrzyma punkty, a kiedy nie i kiedy zostanie odrzucony. W ocenie Izby
po zapoznaniu się ze sposobem oceny tego kryterium można powziąć wątpliwość, czy
uzyska się punkty w sytuacji, gdy choćby za jeden element opisu tych punktów się nie
uzyskało, i czy fakt nieuzyskania punktów w danym elemencie opisu będzie skutkować
odrzuceniem oferty. Biorąc pod uwagę to, że kryteria oceny oferty powinny być mierzalne i
obiektywne przy istnieniu wyżej wskazanych wątpliwości (co potwierdzają zapytania
kierowane do siwz), Izba ustaliła, że ustalone podkryterium tych wymogów nie spełnia.
5. podkryterium: kompatybilność z systemami pokładowymi i zajezdniowymi (T5) = waga 8%
- 8 pkt.
W celu oceny kompatybilności programowej Modułów Pokładowych Systemu z
użytkowanymi przez Operatora Systemami Pokładowymi Autobusów oraz Systemami
Zajezdniowymi, wykonawca przedstawi Opis Techniczny Integracji w zakresie wymiany
danych pomiędzy systemami zajezdniowymi, Systemem Centralnym i Podsystemami oraz
koncepcję programowania Systemów Pokładowych Autobusu i Modułów Pokładowych
Systemu obejmującą następujące zagadnienia:
1.
Koncepcja wdrożenia elementów Systemu w autobusach.
2.
Wymiana danych i kompatybilność Modułów Pokładowych Systemu z Systemami
Pokładowymi Autobusów i Zajezdniowymi.
3.
Koncepcja rozwiązań sieciowych na terenie zajezdni (w tym Urządzenia i
Oprogramowanie do wymiany danych na terenie zajezdni).
4.
Wykorzystanie zasobów zamawiającego (Systemów Zajezdniowych i wymiany
danych).
Wykonawca przedstawi koncepcję kompatybilności programowej Modułów Pokładowych
Systemu
z użytkowanymi przez Operatora Systemami Pokładowymi Autobusów oraz
Systemami Zajezdniowymi opisując poszczególne powiązania oraz standardy wymiany
danych,
koncepcję i logikę funkcjonowania Systemu na zajezdni i poza zajezdnią wraz z
graficznymi przykładami w zakresie: rozwiązań sieciowych, wykorzystania posiadanych

zasobów Operatora, kompatybilności/ integracji Modułów Pokładowych Systemu z
Systemami Pokładowymi Autobusów (obejmującą wszystkie autobusy Operatora
wyposażonych w Autokomputer) lub jednoznacznie zadeklaruje jej brak. W przypadku braku
integracji przedstawiona zostanie koncepcja w jaki sposób zostaną zrealizowane funkcje
programowania Systemów Pokładowych Autobusów danymi z Podsystemu RJ, wsparcia
funkcjonalności dyspozytorskiej danymi z autobusów (w tym danymi eksploatacyjnymi), która
zapewni ergonomiczną i komfortową obsługę tego Podsystemu, powodującą w jak
najmniejszym stopniu wzrost wymaganej
pracochłonności. Jednocześnie Wykonawca musi
udowodnić, że Pokładowe Systemy Autobusów, Moduły Pokładowe Systemu, Systemy
Zajezdniowe, Podsystem RJ, Podsystem e-
bilet będą zasilane wszelkimi niezbędnymi
danymi wymaganymi do ich właściwego funkcjonowania dla wszystkich autobusów.
Przestawiona zostanie koncepcja działania Modułów Pokładowych Systemu obejmująca
graficzny schemat opisujący logikę współdziałania Urządzeń w autobusie i wymiany danych
wewnątrz i na zewnątrz autobusu.
Wykonawca w podkryterium komp
atybilność z systemami pokładowymi i zajezdniowymi
otrzyma
8 punktów jeśli zaproponowane rozwiązanie zapewni dla wszystkich autobusów
wyposażonych w Autokomputer:
1)
wyłącznie jeden punkt obsługi dla kierowcy (np. logowanie) dla autobusowych:
Modułów Pokładowych Systemu oraz Systemów Pokładowych Autobusu, którym jest
Autokomputer pojazdu;
2)
komunikację/wymianę danych pomiędzy Systemem Centralnym, a autobusem: online
poprzez sieć GSM (APN) poza zajezdnią, realizowaną z wykorzystaniem jednej karty SIM i
danych
z jednego urządzenia GPS, oba zarządzane przez Autokomputer autobusu, w
zakresie danych niezbędnych do pełnego i właściwego funkcjonowania Systemów
Pokładowych Autobusu i Modułów Pokładowych Systemu oraz Systemu Centralnego i
wszystki
ch Podsystemów, w szczególności zapewnienie aktualności danych zarówno po
stronie autobusu jak i Systemu;
3)
jeden punkt „zrzutu” danych na terenie zajezdni poprzez sieć Wi-Fi; automatyczny
„zrzut danych” z Systemów Pokładowych Autobusów i Modułów Pokładowych Systemu do
Sys
temów Zajezdniowych (w tym systemu PDA) oraz do Systemu Centralnego;
4)
jeden punkt automatycznego programowania dla
Systemów Pokładowych Autobusów
i Modułów Pokładowych Systemu przy wykorzystaniu modułu transmisji danych Wi-Fi (na
terenie zajezdni) na po
dstawie danych z Podsystemów (w szczególności Oprogramowania
RJ i Podsystemu e-bilet);
5)
nadzór online (monitorowanie) przez System nad poprawnością działania oraz nad
aktualnością danych i oprogramowania Modułów Pokładowych Systemu, Autobusowych
Systemów Pokładowych, realizowany poprzez jedną kartę SIM w autobusie pod kontrolą

Autokomputera autobusu.
6)
dostęp online (poprzez sieć GSM - APN) do danych niezbędnych dla funkcjonowania
Podsystemu DIP, w szczególności o położeniu pojazdu, danych eksploatacyjnych pojazdów
(udostępnianych przez Autokomputer autobusu) jak i w zakresie bezpieczeństwa (przycisk
antynapadowy, wgląd do kamer monitoringu pokładowego autobusu, dla wszystkich
pojazdów wyposażonych w system monitoringu).
0 punktów otrzyma Wykonawca, którego oferta nie spełni któregokolwiek z powyższych
wymagań w jakimkolwiek zakresie, w szczególności:
1)
System działający w trybie niezależnym / niezintegrowanym, nie współpracujący lub
współpracujący w niepełnym zakresie Modułów Pokładowych Systemu z Systemami
Pokładowymi Autobusu i zajezdniowymi,
2)
brak możliwości programowania Systemów Pokładowych Autobusu wszystkich
autobusów (wyposażonych w Autokomputer) z dostarczonego Systemu lub
3)
opis będzie niejasny lub sporządzony niezgodnie z wymaganiami dla opisu lub z
którego trudno jest wywnioskować czy powyższe wymagania w zakresie integracji zostały
spełnione.
W zakresie opisu podkryterium Kompatybilność z systemami pokładowymi i zajezdniowymi
obowiązują wymagania dla przygotowania Opisu Technicznego Integracji, jak dla Opisu
Technicznego Systemu.
W przypadku, gdy opisane rozwiązanie nie udowodni integracji/ kompatybilności w wyżej
wymienionym, w niniejszym rozdziale zakresie i jednocześnie System nie zapewni
automatycznej i pełnej obsługi Systemów Pokładowych Autobusu, niezbędnej do
prawidłowego ich działania dla wszystkich autobusów wyposażonych w Autokomputer,
będzie to skutkować odrzuceniem oferty wykonawcy jako niezgodnej z treścią SIWZ na
podstawie art. 89 ust.1 pkt. 2 Prawa.
Ponownie Izba zwróciła uwagę na używane przez zamawiającego sformułowania
„współpracujący w niepełnym zakresie Modułów Pokładowych Systemu z Systemami
Pokładowymi Autobusu i zajezdniowymi”, „opis będzie niejasny lub sporządzony niezgodnie
z wymaganiami dla
opisu lub z którego trudno jest wywnioskować czy powyższe wymagania
w zakresie integracji zostały spełnione”, ’ System nie zapewni automatycznej i pełnej obsługi
Systemów Pokładowych Autobusu, niezbędnej do prawidłowego ich działania dla wszystkich
autobu
sów wyposażonych w Autokomputer”. Te sformułowania w ocenie Izby powodują, że
przedstawione kryterium oceny ofert jest niemierzalne i niejednoznaczne. Użyte pojęcia są
nieostre i nie zostały przez zamawiającego zdefiniowane, co może prowadzić do arbitralnej
oceny ofert wykonawców przez zamawiającego. Nadto w ocenie Izby z opisu przedmiotu
zamówienia wynika, że to sterownik e-biletu ma pełnić w systemie funkcję łączącą moduły
systemu i zapewniającą przepływ danych, jednak z opisu przedmiotowego kryterium oceny

ofert wynika, że zamawiający w tym zakresie preferuje ruch za pomocą autokomputera jako
element zarządzający. Izba wzięła pod uwagę, że autobusy zamawiającego obecnie
wyposażone są tak w sterowniki jak i autokomputery, przy czym autokomputery są w
różnych wersjach, tym samym zagwarantowanie opisanej przez zamawiającego koncepcji
może być trudne jeśli nie niemożliwe do spełnienia. Nadto jak wynika z załącznika nr 2 do
OPZ wszystkie autokomputery pochodzą od firmy PIXEL, co przy braku protokołów
komunikacy
jnych i kodów źródłowych, który przyznał zamawiający, może powodować, że to
nie przedmiot zamówienia o określonych cechach jakościowych, czy użyteczności będzie
preferowany przez zamawiającego, ale konkretne rozwiązanie pochodzące tylko od jednego
producen
ta. Izba w tym zakresie wzięła pod uwagę także zapytania skierowane do treści
siwz, gdzie jeden z wykonawców zwracał zamawiającemu uwagę na możliwość odwrócenia
ten koncepcji i oparcia Systemu w zakresie zarządzania, komunikacji i udostępniania danych
o sterownik e-
biletu. Biorąc powyższe pod uwagę Izba oceniła, że ustalony stan faktyczny
daje podstawy do uznania, że kryterium zostało opisane w sposób preferujący jednego
producenta i wykonawców oferujących rozwiązania oparte o sprzęt tegoż producenta, co
po
woduje, że kryterium zagraża uczciwej konkurencji i równemu traktowaniu wykonawców, a
także z uwagi na użycie pojęć nieostrych i ocennych nie zapewnia obiektywizmu i brak
arbitralności po stronie zamawiającego.
Opis Techniczny Integracji i Opis Techniczny
Systemu oferowanego rozwiązania, które
muszą być załączone do oferty wykonawcy, będą podstawą dla projektu Systemu
wymaganego do wykonania (Etap 1) zgodnie z przedmiotem umowy.
Punkty, które otrzyma oferta w kryterium " ocena techniczno-eksploatacyjna " będą liczone
wg wzoru:
T = T1+ T2+ T3+ T4+ T5
Ofertę, która uzyska najwyższą ilość punktów zamawiający uzna za najkorzystniejszą.
W załączniku nr 1 do siwz - OPZ zamawiający w pkt. II.1.16 postawił wymóg
16)
Przed wdrożeniem Systemu wymagane jest przygotowanie projektu Systemu. Projekt
Systemu, projekty interfejsów użytkowników podlegają zatwierdzeniu, tj. będą przedkładane
do zatwierdzenia przez Zamawiającego.
W ocenie Izby powołane postanowienie nie narusza zasad udzielania zamówień
publicznych.
Poprzedzenie wdrożenia projektem jest standardową procedurą, a odwołujący
nie wykazał w jaki sposób brak terminu zatwierdzenia projektu powoduje naruszenie
przepisów powołanych przez odwołującego w zarzutach i w jaki sposób uniemożliwia mu
skalkulowanie of
erty i jej złożenie. W ocenie Izby brak określenia terminu zatwierdzenia
projektu powoduje powstanie po stronie zamawiającego obowiązku zatwierdzenia projektu
bez zbędnej zwłoki.

W tym samym załączniku w pkt. II.2.7 zamawiający podał:
7)
Zamawiający bezwzględnie wymaga, aby do momentu ostatecznego uruchomienia
dostarczonego Systemu, działały wszystkie obecnie zamontowane Urządzenia. Wyklucza się
sytuację, w której na potrzeby realizacji prac przez Wykonawcę konieczna będzie obsługa
linii komunikacyjnych a
utobusami bez działających urządzeń lub wystąpi brak obecnej
funkcjonalności innych urządzeń (z wyjątkiem wcześniej uzgodnionych przez Strony),
trwałym lub czasowym zatrzymaniem albo ograniczeniem funkcjonalności obecnego
Systemu (z wyjątkiem uzgodnionych wcześniej sytuacji).
Izba wzięła pod uwagę wyjaśnienia zamawiającego złożone na rozprawie. Zamawiający
wskazał, a Izba dała temu wiarę, że zamawiający dopuszcza montaż nowego systemu w
autobusach bez wyłączenia systemu starego i system stary będzie działał do tego momentu,
do którego nie nastąpi montaż urządzeń i instalacja nowego Systemu w sposób
umożliwiający wyłączenie starego. Zamawiający wskazał, że przewidział brak działających
urządzeń, brak obecnej funkcjonalności w sytuacjach uzgodnionych z zamawiającym, czy w
czasie montażu nowych urządzeń instalacji systemu, przy czym te wyłączenia będą
następowały partiami i w sposób uzgodniony. W ocenie Izby wymaganie to znajduje
uzasadnienie w usprawiedliwionych potrzebach zamawiającego, gdyż dostarczanie
społeczeństwu stałego dostępu do komunikacji autobusowej jest zadaniem zamawiającego i
trudno wyobrazić sobie by zamawiający mógł ustanowić dzień lub dni bez wyjazdu taboru,
lub zapewnić transport taborem z niedziałającymi systemami np. uniemożliwiającymi
komu
nikację autobusu z zajezdnią podczas awarii.

Dalej w pkt. II.3.1.1.a podał: II.3.1. Informacje ogólne.
Łączność pomiędzy każdym z elementów Systemu jest podstawowym warunkiem
funkcjonowania całości Systemu i Wykonawca musi zadbać przede wszystkim o:
1)
zapewnienie bezpiecznej komunikacji pomiędzy Systemem Centralnym, a
Urządzeniami wykorzystującymi łączność w sieci komórkowej montowanymi w:
a) autobusach,
W ocenie Izby to postanowienie samo w sobie jest jednoznaczne, konkretne i czytelne. W
ocenie Izby
zamawiający zamawia system, który ma zapewnić połączenie wszystkich
niezbędnych zamawiającemu modułów: zajezdniowych, dziedzinowych i autobusowych za
pomocą jednego systemu nadrzędnego, zarządzającego pozostałymi systemami i
umożliwiającego przepływ danych pomiędzy poszczególnymi systemami w sposób
uporządkowany i automatyczny. Tym samym wymaganie, aby tak komunikacja była
łącznością w siedzi komórkowej i była komunikacją bezpieczną, a także zapewniała
komunikację pomiędzy systemem centralnym, a urządzeniami montowanymi w autobusach,
jest wymaganiem racjonalnym.

W pkt. II.4.12 zamawiający zawarł wymaganie, aby:
12)
W przypadku braku realizacji integracji pomiędzy Systemami Zajezdniowymi a
Systemem, z
amawiający nie dopuszcza sytuacji ograniczenia lub zakłócenia możliwości:
a)
programowania Pokładowych Systemów Autobusowych,
b)
pobierania danych eksploatacyjnych, z wszystkich autobusów wyposażonych w
Autokomputer i ich raportowania w zakresie funkcjonalnym (np. do programu PDA).
Ograniczenie lub zakłócenie rozumiane jest w szczególności jako:
a)
zmniejszenie liczby funkcjonalności realizowanych przez Systemy Zajezdniowe,
b)
istotny wzrost wymaganej pracochłonności np. przez konieczność wykonywania
procedur w sposób nieautomatyczny tj. ręcznie przy udziale użytkownika Systemu,
c)
brak przesyłania do Oprogramowania wymaganych danych we właściwym czasie,
d)
brak możliwości obsługi w ww. zakresie części autobusów, które nastąpiło w wyniku
uruchomienia Systemu.
Dlatego w ww. przypadkach wykonawca zapewni wykon
ywanie funkcji Systemów
Zajezdniowych, wymienionych w pkt II.8.2 OPZ (tabela SYSTEMY ZAJEZDNIOWE), w inny
sposób np. poprzez dostarczenie oprogramowania o równoważnej funkcjonalności i
zbliżonym stopniu wymaganej pracochłonności dla personelu Operatora oraz zagwarantuje
ergonomiczną i komfortową obsługę Pokładowych Systemów Autobusowych, a także
raportowania
danych
eksploatacyjnych
autobusów.
Wykonawca
musi
również
zagwarantować stałe przesyłanie do Systemu niezbędnych danych, w szczególności w
zakresie dan
ych eksploatacyjnych autobusów i ich lokalizacji. Wykonawca musi zapewnić w
szczególności funkcjonalności automatycznego przesyłania danych niezbędnych do
właściwego funkcjonowania Pokładowych Systemów Autobusów, Podsystemu DIP,
Podsystemu RJ, Podsystemu e-
bilet, w tym Modułów Pokładowych Systemu oraz
pozyskiwania danych eksploatacyjnych z wszystkich autobusów wyposażonych w
Autokomputer, jak i ich raportowanie w zakresie funkcjonalnym (np. do programu PDA).
W ocenie Izby z powyższych postanowień wynika, że zamawiający przewiduje, że
wykonawca, albo podłączy posiadane przez zamawiającego urządzenia i systemy do
systemu centralnego, albo dostarczy oporgramowanie do równoważnej funkcjonalności i
pracochłonności oraz zapewni automatyczne pozyskiwanie i przepływ danych z autobusów
wyposażonych w autokomputer. W ocenie Izby powoduje to ustalenie, że zamawiający
ustanowił dwa sposoby realizacji przedmiotowego zamówienia pierwsze za pomocą
integracji z istniejącymi systemami i urządzeniami w system centralny albo za pomocą
stworzenia systemu centralnego wraz z podsystemami i modułami o funkcjonalnościach
równoważnych posiadanym przez zamawiającego z użyciem urządzeń i sprzętu
niezbędnego dla odtworzenia tych funkcjonalności. Zamawiający uznał na rozprawie oba

rozwiązania za równoważne pod względem technicznym, ale nie użytkowym. Zamawiający
przyznał także, że nie posiada protokołów komunikacyjnych i kodów źródłowych do części
oprogramowania zarządzającego posiadanymi przez zamawiającego urządzeniami. W
zakresie urządzeń i oprogramowania zamontowanego w autobusach zamawiający wskazał,
że posiada te dane w odniesieniu do 61 pojazdów, przy czym 28 z nich to pojazdy, które
będą dostarczone w 2018r. Zamówienie w wersji podstawowej dotyczy 95 autobusów, a
zatem zamawiający nie posiada kodów źródłowych i protokołów komunikacyjnych w
odniesieniu do 34 autobusów, co stanowi ponad 35% całości taboru. Odwołujący podnosił,
że analogiczna sytuacja dotyczy także systemów zajezdniowych, a zamawiający temu nie
przeczył. Izba wzięła pod uwagę fakt, że obecnie postępowaniem zainteresowanych jest
około 10 wykonawców (odwołujący, przystępujący S&T, przystępujący MPTechnology,
przystępujący PIXEL, a także 6 innych wykonawców, którzy skierowali do zamawiającego
pytania dotyczące sposobu integracji i udziału w tej integracji zamawiającego. Poza
odwołującym i przystępującymi po jego stronie, pytania o wykonanie integracji przez
dotychczasowych dostawców, czy udostępnienie niezbędnych protokołów przez
zamawiającego zadało jeszcze czterech innych wykonawców (na obecnym etapie Izba z
uwagi na treść art. 38 ust. 2 ustawy nie ujawnia źródeł zapytań w inny sposób niż
identyfikacja zapytań przez datę ich wpływu. Jedynie trzech wykonawców nie składało
zapytań o udział zamawiającego w procesie integracji, a zapytania te dotyczyły tak urządzeń
i oprogramowania autobudowego, systemów zajezdniowych i dziedzinowych, a także
dostępu do baz danych. Wszyscy wykonawcy oczekiwali pozyskania dostępu do tych
systemów i oprogramowania za pośrednictwem zamawiającego, a część z wykonawców
oczekiwała odejścia od priorytetowego traktowania autokomputerów na rzecz sterownika e-
biletu. Zakres postanowień OPZ budzących wątpliwości wykonawców dotyczył praktycznie
całego zakresu zalecanej przez zamawiającego integracji. Biorąc powyższe pod uwagę Izba
oceniła, że opis przedmiotu zamówienia w części dotyczącej zalecanej integracji jest
przeważającej mierze niekompletny i co najmniej utrudnia wykonawcom uczciwą
konkurencję. Zamawiający oświadczył na rozprawie, że nie jest zainteresowany nabyciem
kodów źródłowych i protokołów komunikacyjnych, a zadaniem wykonawcy jest nawiązanie
współpracy z twórcami oprogramowania czy systemów, w taki sposób aby umożliwić sobie
wykonanie zalecanej integracji.
Zamawiający podkreślał możliwość skorzystania z rozwiązania alternatywnego jakim jest
stworzenie systemu i jego modułów z zachowaniem równoważnych do obecnych
funkcjonalności od podstaw wraz z dostawą niezbędnych urządzeń i sprzętu. Zamawiający
wskazywał, że rozwiązanie oparte o integrację jest dla niego korzystniejsze, gdyż kadra
obsługująca tabor jest niechętna zmianom i szkoleniom, konieczne jest utrzymanie trwałości
usługi transportowej w czasie, rozwiązanie gwarantuje gospodarne wydatkowanie środków

publicznych.
W ocenie Izby rozwiązania oparte o integrację i o nowy system nie są równoważne także
pod względem technicznym. W ocenie Izby są to dwa zupełnie odmienne sposoby
wykonania systemu centralnego obejmujące zupełnie inny zakres zamówienia i dlatego w
ocenie Izby nie są one równoważne. Wykonawcy powinni mieć możliwość złożenia ofert
porównywalnych, natomiast w ocenie Izby nie jest możliwe porównanie systemu opartego o
rozwiązania już istniejące z systemem zbudowanym od podstaw i jak wynika z OPZ taki, do
którego muszą być użyte urządzenia i sprzęt nowy, pochodzący najdalej sprzed 6 miesięcy.
Zamawiający powinien być dokonać wyboru pomiędzy dwoma możliwymi sposobami
realizacji przedmiotowego zamówienia i określić przedmiot zamówienia jako zamówienie z
i
ntegracją na jednakowych warunkach konkurowania przez wszystkich wykonawców – nie
tylko dostawców obecnie funkcjonujących rozwiązań, albo zdecydować się na budowę
całości systemu znowu na jednakowych warunkach dla wszystkich wykonawców. W ocenie
Izby zamaw
iający nie może przerzucać na wykonawców braku własnej dbałości o
konkurencyjność przyszłych postępowań. Zamawiający miał świadomość faktu, że budowa
systemu centralnego zarządzania posiadanym taborem, jego obsługą techniczną,
personalną, serwisową i zarządzaniem całym procesem komunikacji publicznej jest
procesem rozłożonym w czasie. Świadczy o tym choćby fakt rozłożenia w czasie dostaw
partii autobusów, czy też etapowania powstawania poszczególnych modułów systemu. Tym
samym to obowiązkiem zamawiającego było zadbanie o to, aby postępowania wszczynane
na poszczególnych etapach budowy systemu gwarantowały konkurencyjność postępowań
na przyszłych etapach. Zamawiający mógł to zrobić na wiele sposobów. Nie tylko przez
uzyskanie kodów źródłowych i protokołów wymiany, ale także przez zlecenie przyszłych
integracji dotychczasowym dostawcom, czy wreszcie przez zastrzeżenie obowiązku
współdziałania z przyszłymi wykonawcami w zakresie integracji i współodpowiedzialnością
za jej wynik, oraz ustaleniem stawek jednakowyc
h dla wszystkich wykonawców z tytułu
świadczonej współpracy. Zamawiający w niniejszym postępowaniu natomiast, nie opisał
przedmiotu zamówienia w zakresie integracji w sposób umożliwiający jej rzeczywiste
przeprowadzenie i ten brak dotyczy znacznej części przedmiotu wymaganej integracji.
Zdaniem Izby jest to około 70% całego zakresu integracji. W tym stanie rzeczy Izba ustaliła,
że zamawiający nie opisał przedmiotu zamówienia w sposób jednoznaczny i wyczerpujący z
uwzględnieniem wszystkich okoliczności mających wpływ na kalkulację ceny oferty. Tym
samym Izba oceniła, że zalecany sposób realizacji zamówienia z zastosowaniem integracji
preferuje dotychczasowych dostawców oprogramowania i tym samym utrudnia uczciwą
konkurencję i jako taki nie spełnia wymagań wynikających z art. 29 ust. 1 i 2 ustawy w
związku z art. 7 ust. 1 ustawy.
W pkt. II.8.2.
zamawiający wskazał:

Operator użytkuje Systemy Zajezdniowe wymienione w poniższej tabeli, które służą do
zbierania,
raportowania
i
automatycznej wymiany
danych,
w
szcze
gólności z
oprogramowaniem do tworzenia rozkładów jazdy (AGC BusMan) oraz do programowania
Systemów Pokładowych Autobusów. Zamawiający zaleca, aby systemy (programy)
wymienione w poniższej tabeli zostały zintegrowane z Systemem Centralnym w ramach
umowy. W
przypadku braku integracji Wykonawca musi zapewnić, możliwość
automatycznego wykonywania funkcji wymienionych poniżej Systemów Zajezdniowych w
inny, automatyczny sposób (np. przy użyciu innego dostarczonego oprogramowania), w
szczególności możliwość:
1)
programowania Pokładowych Systemów Autobusowych wszystkich autobusów
Operatora,
2)
pozyskiwania danych eksploatacyjnych ze wszystkich autobusów wyposażonych w
Autokomputer oraz ich raportowanie o zakresie funkcjonalnym (jak np. do systemu PDA),
3)
zapewn
ienia przesyłania do Systemu niezbędnych danych z Modułów Pokładowych
Systemu i danych eksploatacyjnych z autobusów.
W pkt. II.8.4.
zamawiający podał:
Operator użytkuje Systemy Dziedzinowe wymienione w poniższej tabeli, które są niezbędne
do funkcjonowania
Operatora i zasilania systemów zamawiającego, a których
funkcjonalności wykonawca zastąpi przez funkcjonalności Systemu, poprzez zapewnienie
odpowiedniej wymiany danych w ramach Systemu oraz z Systemami Dziedzinowymi i
Systemami Zajezdniowymi zgodnie z wy
maganiami OPZ opisanymi w pkt 2 Rozdziału II.4
Wymiana danych pomiędzy elementami Systemu.
W pkt. IV.6.3.2.2.
zamawiający dla podstawowych wymagań technicznych Kasownika
dwufunkcyjnego wskazał:
1.
Kasownik powinien posiadać:
9)
maksymalne wymiary kasownika:
a)
szerokość: 190 mm.
Izba na podstawie załącznika nr 2 do OPZ, że posiada 94 autobusy, w których
zainstalowane są różne elementy wyposażenia:
-
autokomputery: produkcji PIXEL w różnych wersjach i R&G, w tym 4 nieznanego
producenta
– poz. 45, 92, 93, 94,
-
elektroniczne tablice kierunkowe produkcji PIXEL w różnych wersjach,
- tablice klapkowe produkcji PIXEL, R&G, BROSE, MOBITEC, GROBA,
-
tablice informacyjne wewnętrzne produkcji PIXEL i R&G,
-
urządzenia informacji dźwiękowej PIXEL i nieokreślonych producentów,
- monitoring wizyjny : produkcji PI
XEL i nieokreślonego producenta,
-
urządzenia do komunikacji i lokalizacji: produkcji PIXEL,

-
urządzenia diagnostyczne: produkcji PIXEL
- kasowniki: KRG i PIXEL.
Zamawiający otrzyma w 2018r. 28 nowych autobusów wyposażonych w autokomputer
PIXEL,, tablice informacyjne wewnętrzne – PIXEL, urządzenia informacji dźwiękowej –
PIXEL, monitoring wizyjny
– nieznanego producenta, radiomodem nieokreślonego
producenta.
Łącznie jest to 122 autobusy, przy czym przedmiot zamówienia określa ilość autobusów na
95 z możliwością rozszerzenia docelowo do 116 autobusów, co może oznaczać, że część
autobusów wskazanych w wykazie nie będzie objęta przedmiotem zamówienia.
Informacje
z załącznika nr 2 do OPZ są sprzeczne z informacjami zawartymi w pkt. IV.61.2,
gdzie mowa jest o 95 autobusach i zobowiązaniu do przeniesienia części dostarczonych i
zainstalowanych w autobusach Modułów Pokładowych Systemu w kolejnych 33 autobusach,
czy łącznie 127. Nadto z zestawienia w załączniku nr 2 wynika, że autokomputery są w co
najmniej 47 autobusach
(jeśli przyjąć, że te autobusy, gdzie wprost nie oznaczono
„autokomputer” są wyposażone jedynie w sterownik), które posiada zamawiający, a z pkt.
IV.6
.3.1 wynika, że w 41 szt. autobusów znajdują się autokomputery. Określając
wyposażenie autobusów zamawiający nie określił, dla których urządzeń posiada kody
źródłowe i protokoły komunikacyjne i które przekaże wykonawcy wybranemu. Jedynie na
podstawie oświadczenie zamawiającego złożonego na rozprawie można było ustalić, że
zamawiający dla 61 autobusów, w tym 28 tych, które mają być dostarczone w 2018r.
Oznacza to, że z 94 autobusów wskazanych przez zamawiającego jedynie w odniesieniu do
33 zamawiający dysponuje kodami i protokołami. Przy czym nie sposób ustalić czy liczba 33
nie odnosi się do autobusów, które na które w przyszłości wykonawca ma przenieść Moduły
Pokładowe Systemu, czy tez odnosi się do autobusów posiadanych przez zamawiającego.
Nie można także ustalić, czy wszystkie autobusy, którymi obecnie dysponuje zamawiający
będą włączane do systemu czy też nie. Wprawdzie zamawiający zamieścił załącznik nr 5 do
OPZ, z którego wynika jaka marka/typ kiedy podlega wymianie, ale nie wynika, czy
zamawiający oczekuje montażu systemu na autobusach wycofywanych, czy na wszystkich?
W ocenie Izby również i powyższe ustalenia przemawiają za niejednoznacznością opisu
przedmiotu zamówienia i brakiem wskazania danych niezbędnych dla prawidłowego
sporządzenia oferty.
W pkt. II.8.2 zamawiający wymienił posiadane systemy zajezdniowe i opisał funkcje
programu, dane programu oraz kierunek i sposób wymiany danych. Wskazał na
- pakiet PIXEL 3,
- PDA Analizator Danych PIXEL
- Data Access Server
- PIXEL Busman Import.

W pkt
II.8.3 zamawiający w podobny sposób opisał systemy dziedzinowe, które mają
wymieniać dane z systemem:
- System EGC firmy SYSTEmEG
- Stacja Paliw,
- VeritumXL firmy System-1
W pkt. II.8.4 zamawiający opisał systemy dziedzinowe, których funkcjonalności mają być
zastąpione przez system:
- KF3000 firmy R&GPlus
- Depozyt firmy MARCOM M.H.
- Busman v100.0991 firmy AGC Consulting,
- Busgraf firmy ACG Consulting
- Eksploatacja firmy MARCOM M.H.
-
Trzeźwość firmy MARCOM M.H.
Izba ustaliła, że przy żadnym z oprogramowani zamawiający nie podał czy jest w posiadaniu
protokołów komunikacyjnych i kodów źródłowych, przy czym w zakresie pkt. II.8.2
zamawiający wymagał zapewnienia automatycznego wykonywania funkcji systemów
zajezdniowych w inny automatyczny sposób przy użyciu innego dostarczonego
oprogramowania.
Izba ustaliła także, iż 8 wykonawców zadało zamawiającemu pytania do treści siwz, w tym w
zakresie spornym pomiędzy stronami. Z uwagi na treść art. 38 ust. 2 ustawy Izba określi tych
wykonawców jako „zainteresowany wykonawca” Treść zapytań jest następująca:
Zapytanie zainteresowanego wykonawcy z dnia 8 stycznia 2018r.:
Pytanie 2.
Plik SIWZ.doc, strona 22, pkt. 4. „podkryterium: koncepcja techniczna Systemu
(T4) waga 4% -
4 pkt.” Wykonawca prosi o interpretację, czy niedostarczenie opisu
Technicznego Systemu zaproponowanego przez Wykonawcę w ofercie będzie
jednoznaczne z odrzucen
iem oferty czy też przyznaniem 0 pkt w tym kryterium?
Pytanie 3.
Plik SIWZ.doc, strona 22t pkt. 4. „podkryterium: koncepcja techniczna Systemu
(T4) waga 4% -
4 pkt.” Czy zdaniem Zamawiającego różni się złożenie Opisu Technicznego
Systemu, nie spełniającego wymagań określonych w OPZ skutkujące odrzuceniem oferty
Wykonawcy jako niezgodnej z treścią SIWZ na podstawie art. 89 ust.l pkt. 2 Prawa. od
sytuacji w której z każdy z 5 ocenianych w koncepcji elementów przyznane Wykonawcy
zostanie 0
pkt. ? czy taka sytuacja oznacza także odrzucenie oferty?
Pytanie 4.
Plik OPZ.docx strona 23, pkt 11.8,3,. Ciy Zamawiający posiada dokumentację
bazy danych każdego z wymienionych systemów dziedzinowych w oczekiwanym zakresie
integracji? W przypadku odpowiedzi negatywnej prosimy o wskazanie w jaki sposób należy
dokonać integracji?
Pytanie 5
Plik OPZ.docx strona 24, pkt. III.8.3 Czy zamawiający posiada dokumentację bazy

danych każdego z wymienionych systemów dziedzinowych w oczekiwanym zakresie
integracji? W przypadku odpowiedzi negatywnej prosimy o wskazanie w jaki sposób dokonać
integracji?
Pytanie 12.
Plik OPZ.docx strona 20, pkt.ll.8.2. „Zasoby Zamawiającego” Czy w przypadku
rezygnacji z integracji
dostarczanych przez Wykonawcę rozwiązań z opisanymi przez
Zamawiającego w tabeli na stronie 20 OPZ oprogramowaniem zajezdniowym i
autobusowym, Wykonawca zobowiązany jest w ramach niniejszego zamówienia do
zapewnienia pełnej tożsamej funkcjonalności sterowania dotychczas eksploatowanymi
autobusowymi urządzeniami informacji pasażerskiej (w tym wewnętrznymi i zewnętrznymi
tablicami i systemem zapowiedzi dźwiękowych) wg stanu inwentarzowego opisanego w
załączniku nr 2 do OPZ?
Pytanie 13. Plik OPZ.do
cx strona 20 pkt. II.8.2 "Zasoby zamawiającego" Czy w przypadku
braku możliwości dostosowania dostarczonego przez wykonawcę rozwiązania
autobusowego w zakresie funkcjonalności oprogramowania opisanego w tabeli na stronie 20
OPZ z dotychczas eksploatowanymi w pojazdach urządzeniami (w tym tablicami),
wykonawca zobowiązany jest na swój koszt i swoim staraniem wymienić, dostarczyć i
zainstalować nowe autobusowe urządzenia (w tym tablice) współpracujące z dostarczanym
w ramach niniejszego pos
tepowania systemem w ilości opisanej w załączniku nr 2 do OPZ?
Prosimy o potwierdzenie.
Z zapytań innego zainteresowanego wykonawcy z dnia 9 stycznia 2018r. wynika, że:
pytanie 1
Pytania
a) ile typów pojazdów MAN jest dostarczanych w pierwszej partii pojazdów?
b)
Czy asysta technika firmy MAN ma dotyczyć każdego z typów pojazdów z pierwszej
partii pojazdów?
c)
Czy Zamawiający może podać Wykonawcy uzgodniony zryczałtowany koszt dzienny
asysty technika firmy MAN dla czynności montażu i odbioru pojazdu z pierwszej partii?
d)
Kto odpowiada za przygotowanie odnośnego dokumentu „wytycznych instalacji
Modułów Pokładowych Systemu" przedstawiciel MAN czy Wykonawca?
e)
Czy producent pojazdów MAN z pierwszej partii jest zobowiązany zapisami odnośnej
specyfikacji przetargowej do odpowiedniego wyposażenia (np. przygotowania instalacji
elektrycznej i teleinformatycznej, udostępnienie danych z szyny CAN, etc.) umożliwiającej
podłączenie i montaż Modułów Pokładowych Systemu, czy też za te prace dodatkowe
wymagane po stronie pojazdu MAN ma zapłacić Wykonawca (musi ująć je w ofercie)?
Pytanie 5
OPZ
— Załącznik nr 1 Dotyczy strona 10

System ten powinien być łatwy w obsłudze i zostać zintegrowany (współpracować

automatycznie wymieniać dane) z Oprogramowaniem do budowy rozkładów jazdy oraz
Systemami Pokładowymi Autobusów
Pytanie:
Prosimy o informację z jakim Oprogramowaniem do budowy rozkładów jazdy ma
zostać zintegrowane rozwiązanie Wykonawcy?
Pytanie 12
OPZ -
Załącznik nr 1 Dotyczy rozdział II.4 strona 14
a.
„II.4. Wymiana danych pomiędzy elementami Systemu, Systemami Dziedzinowymi i
Systemami Zajedniowymi
Pytani
e: Czy Zamawiający posiada i może udostępnić Wykonawcy na potrzeby integracji
dokumentację interfejsów i/lub struktur danych do posiadanych Systemów Dziedzinowych i
Systemów Zajedniowych?
Pytanie 13
OPZ -
Załącznik nr 1 Dotyczy rozdział II.4 punkt 10 strona 14
b.
System Centralny zostani
e wyposażony w API (interfejs programistyczny aplikacji)
umożliwiający bieżące udostępnianie informacji o lokalizacji autobusów zewnętrznym
systemom ITS muł) systemom informacji pasażerskich (np. kiedyPrzyjedzie.pl, jakdojade.pl),
Pytanie.- Czy obecnie is
tnieje system ITS, do którego mają być przygotowane dane w API?
b) Czy integracja i dostosowanie API z kiedyPrzyjedzie.pl, jakdojade-pl l
eży po stronie
Wykonawcy czy też autorów odnośnego oprogramowania?
Pytanie 14
OPZ
— Załącznik nr 1 Dotyczy rozdział II.4 punkt 11 strona 15
Komentarz: Zamawiający wymaga dostawy nowego sterownika systemu e-biletu do
wszystkich 95 autobusów i zarazem zaleca integrację z posiadanym przez MZK Opole
autokomputerem oraz wymaga wyłącznie jeden punkt obsługi dla kierowcy , którym jest
Autokomputer. Obecnie posiadany w 41 pojazdach autokomputer musiałby zatem stanowić
element interfejsu kierowcy, a autokomputera nie ma w 54 autobusach i do czasu
rozstrzygnięcia przetargów na dostawy kolejnych nowych autobusów rolę interfejsu kierowcy
i autokomputera musi pełnić sterownika systemu e-biletu . Logicznym zatem wydaje się
odwrócenie wymagania, by tę rolę pełnił nowo dostarczony sterownik e-biletu, który byłby
punktem obsługi dla kierowcy i współpracowałby z już posiadanymi 41. Autokomputerami.
Interfejs GUI sterownika systemu e-
biletu mógłby nawiązywać do obecnego interfejsu
urządzenia, by ułatwić obsługę kierowcom. Pytanie: Wnosimy o dopuszczenie niniejszego
rozwiązania jako bardziej oczywistego w świetle wymagań OPZ Zamawiającego co
kry
tycznych wymagań odnośnie do nowo wdrażanego systemu biletowego (np. system
biletowy CICO i dokładność lokalizacji pojazdu, bilety czasowe, ograniczenie reklamacji -
pliki taryfowe, lista kart zastrzeżonych, doładowania internetowe, raportowanie) i wygodnego
dla kierowcy z racji wymagań co do większego ekranu niż obecnie posiadane urządzenie.

Pytanie 16
Punkt: IV.7.2.2.2. Panel szybkiej sprzedaży, punkt 14. - Jaki terminal płatniczy będzie/jest
używany przez Zamawiającego i czy posiada on odpowiedni protokół do komunikacji z
komputerem sprzedaży ?
Zapytania innego zainteresowanego wykonawcy z dnia 10 stycznia 2017r.
Pytania:
1)
W związku z wymaganiami OPZ/SIWZ dotyczącymi integracji oraz wykorzystania
urządzeń obecnie używanych przez Zamawiającego do wdrożenia wszystkich podsystemów
proszę o przekazanie pełnej dokumentacji technicznej wyszczególnionych autokomputerów
(minimum niezbędne do integracji zgodnej z OPZ to karty katalogowe, instrukcje obsługi,
opisy protokołów komunikacyjnych, kody źródłowe oprogramowania firmware urządzeń) : -
Pixel STR 1-1
-
Pixel STR 1-2
-
Pixel Autokomputer Asterix
-
Pixel Autokomputer XC-6
-
SRG-3000P
-
KPP-2/1CU-4000
-
STR 1-1 LAWO
-
STR 1-1 GORBA
Proszę o jednoznaczne określenie, które z wyżej wymienionych modeli posiadają możliwość
przesyłu danych przez GPRS / slot na kartę SIM. Proszę o jednoznaczne określenie, które z
wyżej wymienionych urządzeń posiadają możliwość podłączenia oraz pełnej obsługi
programowej kasowników dwufunkcyjnych (m.in. przesyłanie plików konfiguracyjnych
aktualnie obowiązującej taryfy biletowej, przesyłanie „białej” oraz „czarnej” listy kart...).
Proszę o przekazanie dla każdego z urządzeń pełnego opisu protokołów komunikacyjnych,
których to uzyskanie niezbędnym jest do przygotowania opisu technicznego wymaganego w
OPZ.
2)
Czy wszystkie wymienione w OPZ autokomputery zapewniają sterowanie wszystkimi
modułami i systemami pokładowymi autobusu?
3)
Czy wszystkie wymienione w OPZ autokomputery zapewniają komunikację / wymianę
danych pomiędzy systemami zajezdniowymi a autobusem (online poprzez sieć GSM (APN)
poza zajezdnią?
4)
Zamawiający w SIWZ przywołuje nazwę „system PDA” proszę o wyjaśnienie o jaki
system chodzi? Kto jest jego producentem? Kiedy i w jakim zakresie został wdrożony oraz w
jakim zakresie jest wykorzystywany w codziennej eksploatacji taboru?
5)
W związku z wymaganiami OPZ/SIWZ dotyczącymi integracji oraz wykorzystania
urządzeń obecnie używanych przez Zamawiającego do wdrożenia wszystkich podsystemów

proszę o przekazanie pełnej dokumentacji technicznej wyszczególnionych tablic (minimum
niezbędne do integracji zgodnej z OPZ to karty katalogowe, opisy protokołów
komunikacyjnych, kody źródłowe oprogramowania firmware urządzeń):
-
Pixel TD
-
tablice klapkowe R&G (przód, bok, tył)
-
tablice klapkowe
PIXEL (przód, bok, tył)
-
MOBITEC (przód, bok, tył)
-
BROSE (przód, bok, tył)
-
GORBA (przód, bok, tył)
-
Pixel TML 16-120
-
ETL 416120
-
Pixel TD
-
Pixel
-
Pixel TML 16-120
-
Pixel PDL16x84-10
-
Pixel PDL16x21-10
-
Pixel XTD
-
Pixel XTD
-
Pixel DOT-LED PDL - Pixel DOT-LED PDL 16x84
-
Pixel PL 12x21
-
Pixel TD 11
-
Pixel TD 11 16x84
-
Pixel TD 11 12x21
-
Pixel
-
Pixel LCD XID 220
-
Pixel XTD
ETH
-
Pixel XTD 16x84 ETH
-
Pixel XTD
ETH
6)
W związku z wymaganiami OPZ/SIWZ dotyczącymi integracji oraz wykorzystania
urządzeń obecnie używanych przez Zamawiającego do wdrożenia wszystkich podsystemów
proszę o przekazanie pełnej dokumentacji technicznej wyszczególnionych rejestratorów
monitoringu wizyjnego (minimum niezbędne do integracji zgodnej z OPZ to karty katalogowe,
opisy protokołów komunikacyjnych, kody źródłowe oprogramowania firmware urządzeń):
-
Pixel DV-MEGA
-
X200
-
Pixel rejestrator mobilny IP PVRS
7)
OPZ „Przed wdrożeniem Systemu wymagane jest przygotowanie projektu Systemu.

Projekt Systemu, projekty interfejsów użytkowników podlegają zatwierdzeniu, tj. będą
przedkładane do zatwierdzenia przez Zamawiającego.” - w jakim terminie projekt powinien
być przygotowany oraz ile czasu na jego zatwierdzenie ma Zamawiający? Co w przypadku
poprawek/niezgodności?
8)
OPZ str. 8 „W skład Modułów Pokładowych Systemu wejdą, oprócz wyżej
wymienionych Biletomatów mobilnych, Kasowniki wraz ze Sterownikiem e-bi/et, jeśli System
będzie tego wymagał i nie będzie możliwe wykorzystanie obecnie zainstalowanych
Autokomputerów. ” Czy Zamawiający gwarantuje, iż wszystkie aktualnie używane
autokomputery mają możliwość zarządzania kasownikami dwufunkcyjnymi oraz
biletomatami? Jeśli nie, to proszę o informację które mają taką techniczną możliwość oraz w
jakim zakresie.
9)
OPZ str. 8 „Urządzenia będą podłączone do Systemu Centralnego za pomocą
Sterownika ebilet lub Autokomputera. Wymiana danych odbywać się będzie za pomocą
modułu transmisji danych GSM i Wi-Fi na zajezdni. System Centralny zapewni nadzór oraz
re
alizację serwisu Urządzeń i utrzymania Oprogramowania.” - czy Zamawiający dopuszcza
możliwość, iż zarówno obecnie użytkowany autokomputer jak i nowodostarczony sterownik
e-
biletu będą wyposażone w moduł transmisji danych GSM? Jeśli tak to proszę o
potwierd
zenie, iż Zamawiający dostarczy niezbędną ilość kart SIM dla urządzeń.
18)
OPZ str. 12 „Zamawiający bezwzględnie wymaga, aby do momentu ostatecznego
uruchomienia dostarczonego Systemu, działały wszystkie obecnie zamontowane
Urządzenia.
Wyklucza się sytuację, w której na potrzeby realizacji prac przez Wykonawcę konieczna
będzie obsługa linii komunikacyjnych autobusami bez działających urządzeń lub wystąpi
brak obecnej funkcjonalności innych urządzeń (z wyjątkiem wcześniej uzgodnionych przez
Strony), trwałym lub czasowym zatrzymaniem albo ograniczeniem funkcjonalności obecnego
Systemu (z wyjątkiem uzgodnionych wcześniej sytuacji).” - bez przekazania informacji co do
kodów źródłowych i protokołów komunikacyjnych dla obecnie użytkowanych urządzeń
niemożliwym jest określenie czy wprowadzane zmiany nie spowodują tymczasowego
zatrzymania lub ograniczenia funkcjonalności Systemu tym samym wnosimy o wykreślenie
podpunktu w całości.
19)
OPZ str. 13 „zapewnienie bezpiecznej komunikacji pomiędzy Systemem Centralnym,
a U
rządzeniami wykorzystującymi łączność w sieci komórkowej montowanymi w: a)
autobusach -
Wykonawca nie może gwarantować bezpieczeństwa komunikacji dla urządzeń
aktualnie użytkowanych przez Zamawiającego. Prosimy o zredagowanie zapisu
„zapewnienie bezpiecznej komunikacji pomiędzy Systemem Centralnym, a Urządzeniami,
dostarczonymi przez Wykonawcę, wykorzystującymi łączność w sieci komórkowej
montowanymi w: a) autobusach”.

23)
OPZ str. 15 „11) W autobusach przeznaczonych do wyposażenia w ramach umowy w
Moduły Pokładowe Systemu - w których Systemy Pokładowe Autobusu wyposażone są w
Autokomputer -
Zamawiający zaleca zintegrować Moduły Pokładowe Systemu z Systemami
Pokładowymi Autobusów, Integracja będzie polegała na zapewnieniu sterowania oraz
komunikacji z System
em Centralnym przez jedno urządzenie sterujące tj. Autokomputer za
pomocą jednej karty SIM, wykorzystując urządzenie GPS autobusu.” - czy Zamawiający
dopuszcza jako rozwiązanie równoważne instalację sterownika e-biletu wyposażonego w
moduł komunikacyjny GSM, niezależnego od Autokomputera, zapewniającego obsługę
kasowników oraz biletomatów mobilnych?
25)
OPZ str. 15 „d) ... automatyczne przekazywanie danych z Systemów Pokładowych
Autobusów i Modułów Pokładowych Systemu do Systemów Zajezdniowych (w tym systemu
PDA)” - w jakim zakresie i w jakiej formie przekazywane mają być dane do systemu PDA?
Proszę o przekazanie protokołu komunikacyjnego (formatu) w jakim przekazywane mają być
te dane. Czy Zamawiający dopuszcza aby Wykonawca dostarczył własne oprogramowanie
realizujące wszystkie obecnie użytkowane przez Zamawiającego funkcje tożsame z tymi z
oprogramowania PDA?
26)
OPZ str. 15 „g) jego danych eksploatacyjnych (udostępnianych przez Autokomputer),
jak i w zakresie bezpieczeństwa (przycisk antynapadowy, wgląd do kamer monitoringu
pokładowego autobusu, dla wszystkich pojazdów wyposażonych w system monitoringu”
które pojazdy wyposażone są w przycisk antynapadowy? Które pojazdy wyposażone są w
system monitorigu umożliwiający podgląd kamer monitoringu on-line? W jaki sposób dane z
kamer i rejestratora są udostępniane? Proszę o przekazanie pełnego protokołu
komunikacyjnego umożliwiającego realizację tego wymagania.
27)
OPZ str. 15 „12) w przypadku braku integracji...” - czy w przypadku braku integracji
Zamawiający potwierdza, iż dla całości floty nadal wykorzystywać będzie aktualny sposób
programowania Pokładowych Systemów Autobusowych? Czy Zamawiający dopuszcza jako
rozwiązanie równoważne realizowanie celów programowania Pokładów Systemów
Autobusowych jak i pobierani
a danych eksploatacyjnych, z wszystkich autobusów
wyposażonych w Autokomputer i ich raportowania w zakresie funkcjonalnym w aktualnie
używanym przez Zamawiającego oprogramowania (PDA, Pixel 3 etc.)? Na jakich warunkach
licencyjnych aktual
nie użytkowane jest to oprogramowanie? Proszę o przekazanie kodów
źródłowych i pełnych opisów komunikacyjnych dla całości oprogramowania wymienionego w
OPZ aktualnie użytkowanego przez Zamawiającego.
66)
Str 95. OPZ „22) Wykonawca dostarczy Zamawiającemu, po podpisaniu umowy,
projekt montażu Tablic DIP w wybranych lokalizacjach do akceptacji przez Zamawiającego. ”
-
w jakim terminie Zamawiający zaakceptuje przedstawiony przez Wykonawcę projekt?
71)
Str. 145 Załącznik 7 do OPZ „4) odmowy wykonania integracji Systemu z innymi

systemami Zamawiającego lub Operatora,” — proszę o wykreślenie wymagania w całości
lub doszczegółowienie o jakie inne systemy chodzi.
Zapytania innego zainteresowanego wykonawcy z dnia 9 stycznia 2017r.
Pytanie 3.
Punkt 11.8.2. str. 20
1)
Jaki jest wymagan
y przez Zamawiającego zakres integracji planowanego systemu e-
bilet z poszczególnymi systemami zajezdniowymi?
2)
Czy w celu wykonania integracji Zamawiający udostępni Wykonawcy narzędzia
programistyczne do wykonania integracji w wymaganym zakresie?
Pytanie 4.
Punkt 11.8.3. str. 23
1) Jaki jest wymagany przez Zamawiającego zakres integracji planowanego systemu e-bilet
z poszczególnymi systemami dziedzinowymi?
2) Czy w celu wykonania integracji Zamawiający udostępni Wykonawcy narzędzia
programistyczne do wykonania integracji w wymaganym zakresie?
Pytanie 6.
Punkt 11.8.2 - 11.8.4
Czy Zamawiający udostępni strukturę wraz z opisem pół plików wymiany danych na potrzeby
wymaganej przez Zamawiającego integracji?
Pytanie 9. Punkt IV.I.I. 10) str. 32
Czy zamawiający dostarczy narzędzia informatyczne umożliwiające import wymaganych
danych z systemu Veritum XL?
Pytanie 13.
Punkt IV.3 19) str. 34
Czy Zamawiający udostępni narzędzia informatyczne umożliwiające wymianę danych
pomiędzy Systemem a systemem windykacji EGC?
Pytanie 14.
Punkt IV.3 28) str. 34
Wykonawca nie zna programów eksploatowanych przez Operatora.
Skoro Wykonawca jest zobowiązany do integracji Systemu z systemami eksploatowanymi
przez Operatora, Zamawiający lub Operator powinni dostarczyć niezbędne narzędzia
informatyczne w celu wykonania takiej integracji
— np. API.
Czy Zamawiający udostępni narzędzia informatyczne (API) umożliwiające wykonanie
integracji pomiędzy Systemem a systemem windykacji EGC oraz systemem księgowym
Veritum?
Izba na podstawie tych wska
zanych i przywołanych pytań ustaliła, że znaczna większość
wykonawców nie jest na obecnym etapie zamówienia zaoferować integracji bez
współdziałania ze strony zamawiającego. Izba ustaliła także, że kryteria oceny ofert budzą
wątpliwości wykonawców, co do ich jednoznaczności i sposobu dokonywania przez ich
pryzmat oceny ofert.
Z pisma MAN z dnia 11 stycznia 2018r. wynika, że nadzór specjalisty MAN jest konieczny,
aby nie doszło do utraty gwarancji. Stelaż pod biletomat musi spełniać warunki homologacji,

stelaż i jego sposób montażu został przebadany przez producenta pojazdu pod względem
bezpieczeństwa dla pasażerów przy wszelkiego typu kolizjach drogowych. MAN stosuje
ogólnodostępny cennik swoich produktów oraz cennik usług identyczny dla wszystkich
podmi
otów występujących z zapytaniem o ofertę.

Izba w zakresie ustalonym powyżej przyjęła pismo MAN jako wiarygodne i nie budzące
wątpliwości. Izba zweryfikowała także dostępność cenników akcesoriów i wyposażenia
dodatkowego firmy MAN i ustaliła, że takie cenniki są ogólnodostępne i możliwe do
pozyskania darmo lub w drodze czasowego odpłatnego dostępu.
Izba nie dopuściła dowodu odwołującego zgłoszonego po zamknięciu rozprawy, gdyż w
ocenie Izby nie jest on konieczny do rozstrzygnięcia, a jego celem jest jedynie podważenie
wiarygodności i mocy dowodowej pisma producenta MAN, podczas gdy przedmiotem
badanie Izby są czynności i zaniechania zamawiającego, a nie podmiotów trzecich. Tym
samym Izba nie znalazła podstaw do otwarcia rozprawy na nowo.

Izba zważyła:
Iz
ba stwierdziła, że zgłoszone przystąpienia spełniają wymogi formalne określone w art. 185
ust. 2 ustawy.
Izba ustaliła, że nie zaistniały przesłanki określone w art. 189 ust. 2 ustawy, które
skutkowałyby odrzuceniem odwołania.

Izba ustaliła, że odwołujący wykazał, że posiada interes w uzyskaniu zamówienia i może
ponieść szkodę w przypadku stwierdzenia naruszenia ustawy przez zamawiającego, co
wypełnia przesłankę materialnoprawną z art. 179 ust. 1 ustawy.

Zarzut naruszenia przez zamawiającego art. 29 ust. 1 i 2 ustawy w zw. z art. 7 ust. 1 ustawy
w zw. z art. 36 ust. 1 pkt. 3 w zw. z art. 41 pkt. 4 ustawy, poprzez opisanie przedmiotu
zamówienia w sposób niejednoznaczny i niewyczerpujący, bez uwzględnienia wszystkich
wymagań oraz okoliczności mogących mieć wpływ na sporządzenie oferty, uniemożliwiający
odwołującemu złożenie oferty i ubieganie się o udzielenie zamówienia, a także w sposób
naruszający zasady zachowania uczciwej konkurencji oraz równego traktowania
wykonawców, jak również nakładający na wykonawców obowiązek spełnienia świadczenia,
które jest niemożliwe do spełnienia, poprzez:
a)
ustanowienie wymogu współpracy (integracji) dostarczanych urządzeń przez
wykonawców z posiadaną infrastrukturą zamawiającego, pomimo braku
zdefiniowania parametrów technicznych urządzeń oraz brak przekazania przez
zamawiającego tzw. protokołów komunikacyjnych oraz kodów źródłowych

pozwalających na wymianę danych informatycznych pomiędzy dostarczanymi
urządzeniami wykonawcy, a istniejącą infrastrukturą zamawiającego, co
unie
możliwia sporządzenie oferty i realizację zamówienia
Zarzut potwierdził się. Izba ustaliła, że zamawiający nie dysponuje kodami źródłowymi i
protokołami komunikacyjnymi do przeważającej części oprogramowania i systemów dla
których zaleca integrację. Zamawiający nie wskazał także w siwz tych systemów i
oprogramowania dla których takie dane jest w stanie udostępnić lub są one oparte o
protokoły otwarte udostępniane przez producenta bez ograniczeń. Zamawiający oświadczył,
że nie nabył i nie jest zainteresowany nabyciem tych informacji. Zamawiający nie zawarł
także w siwz informacji, że obowiązek integracji obciąża dotychczasowego dostawcę lub jest
on z mocy umowy z zamawiający zobowiązany do współpracy z wykonawcą w celu
wykonania inte
gracji, nie zawarł także informacji, że zobowiązał dotychczasowych
dostawców do dostarczenia odpłatnego lub nie potrzebnych informacji wykonawcom za stałą
cenę i na jednakowych warunkach. Tym samym zamawiający nie wykazał, że wykonanie
przedmiotu zamówienia przez wykonanie integracji jest dla innych wykonawców poza
dotychczasowymi dostawcami w ogóle dostępne. Biorąc pod uwagę, że zamawiający
dysponuje systemami i oprogramowaniem różnych dostawców, to również należy poddać
pod wątpliwość, czy zamawiający wykazał, że wykonanie przedmiotu zamówienia przez
choćby jednego wykonawcę jest w ogóle możliwe. Biorąc to pod uwagę Izba oceniła, że
ustalony stan faktyczny daje podstawy do przyjęcia, że opis przedmiotu zamówienia w
zakresie rozwiązania zalecanego nie jest jednoznaczny i precyzyjny, ani nie zawiera
elementów umożliwiających wykonawcom przygotowanie ofert. W tej mierze Izba oparła się
przede wszystkim na treści zapytań kierowanych przez wykonawców do zamawiającego.
Izba oceniła, że przedmiotowy stan faktyczny odbiega znacząco od stanu będącego
przedmiotem badanie przez Izbę w spraiwe sygn.. akt KIO 286/17, gdzie przedmiotem
zamówienia nie był system centralny, a jedynie moduł tego systemu – zintegrowany system
dynamicznej informacji pasażerskiej. Nadto zamawiający nie zalecał zerojedynkowego
postępowania, albo integrujesz, albo robisz od nowa, ale wykonawcom pozostawiał decyzję
czy i w jakim zakresie wykorzystają infrastrukturę zamontowaną w autobusach –
autokomputery. Tym samym tak zakres integracji i rodzaj s
ystemu nie dają podstaw do
przyjęcia, że ustalenia i ocena Izby poczyniona w postępowaniu w sprawie sygn. akt KIO
286/17 nadaje się do podzielenia w niniejszym postępowaniu. Izba oceniła, że pozostawienie
rozwiązania opartego o integrację skutkowałoby zaburzeniem uczciwej konkurencji i tym
samym nakazała wykreślenie tego zalecenia zamawiającego z pkt. II.8.2 i II.8.4 opz i
konsekwentnie uwzględnienie skutków tego wykreślenia tak w ogłoszeniu o zamówieniu jak i
siwz.
b)
brak ustanowienia możliwości dostarczenia przez wykonawcę nowego,

równoważnego oprogramowania oraz urządzeń (infrastruktury), które spełniałoby
wymagania
zamawiającego, a w konsekwencji uzależnienie udziału w
postępowaniu od uzyskania zgody producenta i dostawcy obecnego
oprogramowania na jego w
ykorzystanie, a co sprawia, iż wobec takiego
sformułowania wymagań, preferowany jest producent i dostawca obecnego
oprogramowania oraz urządzeń jako podmiot, który ma uzyskać przedmiotowe
zamówienie publiczne,
Zarzut nie potwierdził się. W ocenie Izby z postanowień siwz wynika, że wykonawca ma
możliwość dostarczenia nowego, równoważnego oprogramowania oraz urządzeń
(infrastruktury), które spełniałoby wymagania zamawiającego, jest to dopuszczone
rozwiązanie alternatywne, które w ocenie Izby jako jedynie umożliwiające realizację
przedmiotowego zamówienia na równych warunkach dla wszystkich wykonawców, jest
jedynym rozwiązaniem opisanym w siwz zgodnym z przepisami ustawy. W tym kontekście
również nie zasadny jest zarzut dotyczący usług rozwoju i świadczenia przeniesienia
urządzeń, gdyż w całości dotyczyć on może jedynie urządzeń zaoferowanych przez
wykonawcę.
c)
ustanowienie wymogu współpracy (integracji) dostarczanych urządzeń przez
wykonawców z posiadaną infrastrukturą zamawiającego, pomimo braku
zdefiniowania p
arametrów technicznych urządzeń oraz brak przekazania przez
zamawiającego tzw. protokołów komunikacyjnych oraz kodów źródłowych
pozwalających na wymianę danych informatycznych pomiędzy dostarczanymi
urządzeniami wykonawcy, a istniejącą infrastrukturą zamawiającego, co prowadzi
do konieczności uzyskania przez wykonawców zgody producenta i dostawcy
obecnego oprogramowania na jego wykorzystanie, w tym implementowanie i
konfigurację z istniejącym systemem, co powoduje, iż przedsiębiorstwo PIXEL Sp.
z o.o. nie b
ędzie zainteresowane nieodpłatnym udostępnieniem dostępu do
danych lub w ogóle ich udostępnieniem, co w konsekwencji sprawia, że
wykonanie zamówienia publicznego jest niemożliwe do objęcia normalnym
ryzykiem kontraktowym, które to ryzyko jest niemożliwe do oszacowania, co w
konsekwencji uniemożliwia przygotowanie należytej wyceny oferty,
Zarzut potwierdził się. W tym zakresie Izba w całości podtrzymuje stanowisko wyrażone w
rozstrzygnięciu zarzutu wskazanego w lit. a).

d)
ustanowienie wymogu współpracy dostarczonego systemu ze wszystkimi
urządzeniami zamawiającego mimo braku przedstawienia przez zamawiającego specyfikacji
technicznej i funkcjonalnej użytkowanych urządzeń, oraz udostępnienia protokołów
komunikacyjnych do wymiany danych oraz kodów źródłowych oprogramowania, co

uniemożliwia wykonawcy, przed rozpoczęciem testów z urządzeniami, weryfikację
ewentualnego oddziaływania oprogramowania i urządzeń na urządzenia eksploatowane
przez
zamawiającego, co z kolei uniemożliwia realizację zamówienia i przygotowanie oferty
odpowiadającej wymaganiom zamawiającego,

Zarzut potwierdził się. W tym zakresie Izba w całości podtrzymuje stanowisko wyrażone w
rozstrzygnięciu zarzutu wskazanego w lit. a).

d)
ustanowienie
wymogu dostarczenia przez wykonawców szczegółowej
dokumentacji w postaci Opisu Technicznego Systemu oraz Opisu Technicznego
Instalacji, która ma określać proponowane przez wykonawców rozwiązania,
podczas, gdy zamawiający nie udostępnił tzw. protokołów komunikacyjnych oraz
kodów źródłowych do wymiany danych, a w konsekwencji nie jest możliwym
sporządzenie owej dokumentacji przez wykonawcę niebędącego producentem
oraz dostawcą obecnego oprogramowania, a brak dostarczenia przez wykonawcę
opisu proponowanych r
ozwiązań w konsekwencji powoduje odrzucenie oferty
przez
zamawiającego

Zarzut potwierdził się. Jak Izba ustaliła zamawiający w sposób niejednoznaczny i nie
umożliwiający sporządzenie oferty opisał przedmiot zamówienia w zakresie zalecanej
integracji, nadto w opisie sposobu oceny ofert w zakresie podkryterium Opisu Technicznego
Integracji zawarł pojęcia nieostre, ocenne, których zastosowanie umożliwia arbitralną ocenę
przez zamawiającego i może prowadzić do nieobiektywnej oceny ofert. Co do podkryterium
Opi
su Technicznego Systemu, to również zachodzi sprzeczność pomiędzy wymogiem opis
zawartym w samym kryterium, a wymaganiami opisu przedmiotu zamówienia, których nie
spełnienie ma skutkować odrzuceniem oferty, nie jest także jednoznacznie określony sposób
prz
yznawania punktacji w tym kryterium, nadto szczegółowe i surowe wymagania siwz
pozostają w sprzeczności z oświadczeniami zamawiającego czynionymi na rozprawie i w
odpowiedzi na odwołanie, że opis ma przyjąć jedynie formę koncepcji, schematów i
graficznych
opisów. W ocenie Izby obecne postanowienia siwz w zakresie podkryterium Opis
Techniczny Systemu mogą prowadzić do niemierzalności ofert w tym kryterium i arbitralnej
oceny przez zamawiającego. Izba zatem nakazała zamawiającemu wykreślenie
podkryterium Opis Techniczny Integracji i dokonanie opisu podkryterium Opis Techniczny
Systemu w taki
sposób, aby jednoznacznie było określone, jakie elementy i na jakim stopniu
szczegółowości mają być opisane przez wykonawcę ze wskazaniem punktu OPZ, do którego
dany eleme
nt się odnosi, ze wskazaniem, czy do danego elementu zamawiający życzy sobie
prezentacji na schemacie, czy w formule tabelarycznej i czy wymaga podania
komponentów

w tym urządzeń, oprogramowania standardowego (z półki) z nazwy i producenta i do jakiego
sto
pnia szczegółowości czy jedynie producent i model/nazwa komponentu głównego, czy też
wraz z konfiguracją tego komponentu np. w zakresie pamięci, procesora, pojemności
dyskowej
itp. Izba nakazuje także zamawiającemu wskazanie, w jaki sposób będzie oceniał
o
fertę w tym kryterium, czy będzie wymagał, aby za każdy moduł opisu wykonawca otrzymał
punktu ze skali np. 1
– 5, czy też wykonawca, w którymś module może otrzymać zero
punktów, a mimo to jego ocena w całości kryterium będzie pozytywna. Zamawiający
powinie
n także wyjaśnić wykonawcom w sposób nie budzący wątpliwości kiedy ich oferta
ulegnie odrzuceniu w przypadku błędów/braków w opisie technicznym systemu w stosunku
do wymagań opisanych w opisie przedmiotu zamówienia.

e)
ustanowienie wymogu, aby autokomputer dostarczony przez w
ykonawcę
umożliwiał synchronizację urządzeń innych dostawców, które nie są objęte
niniejszym postępowaniem, co bez znajomości specyfikacji technicznej i
funkcjonalnej oraz tzw. protokołów komunikacyjnych producenta urządzeń,
uniemożliwia realizację zamówienia i przygotowanie oferty odpowiadającej
wymaganiom
zamawiającego, powodując tym samym, że przedsiębiorstwa PIXEL
Sp. z o.o. oraz R&G Sp. z o.o. z siedzibą w Mielcu, które są właścicielami
użytkowanego przez zamawiającego oprogramowania oraz urządzeń, z uwagi na
posiadanie pełnej wiedzy technicznej w przedmiocie specyfikacji technicznej i
funkcjonalnej użytkowanych urządzeń, będą w stanie przedstawić ofertę
indywidualnie spełniającą wyznaczone przez zamawiającego warunki, z uwagi na
zas
tosowanie wymagań, które preferują określonego wykonawcę, przez co złożyć
korzystniejszą ofertę zarówno pod względem ceny realizacji zamówienia, mając
na uwadze ustanowione w
postępowaniu kryteria oceny
Zarzut potwierdził się. W ocenie Izby zgromadzony materiał dowodowy powoduje, że
uprawdopodobnione zostało, że dla większości wykonawców dla realizacji integracji, w tym
urządzeń oferowanych przez wykonawcę z urządzeniami będącymi w posiadaniu
zamawiającego, konieczne jest współdziałanie ze strony zamawiającego w celu realizacji
integracji. Znamienne jest w tym zakresie stanowisko jednego wykonawców wyrażone w
zapytaniu: „Wykonawca nie zna programów eksploatowanych przez Operatora.
Skoro Wykonawca jest zobowiązany do integracji Systemu z systemami eksploatowanymi
przez Operatora, Zamawiający lub Operator powinni dostarczyć niezbędne narzędzia
informatyczne w celu wykonania takiej integracji
— np. API.”
Tym samym skoro zamawiający oświadczył, że nie jest zainteresowany pozyskaniem takich
narzędzi, tym samym należało dać wiarę odwołującemu, że brak tych informacji utrudnia
uczciwą konkurencję i prowadzi do preferowania wykonawców, którzy wcześniej dostarczali

zamawiającemu urządzenia wraz z oprogramowaniem lub podsystemy. W ocenie Izby taki
opis przedm
iotu zamówienia narusza zasadę wyrażoną w art. 29 ust. 2 ustawy, a w
konsekwencji prowadzi do naruszenia art. 7 ust 1 ustawy. Skoro zamawiający nie może lub
nie jest zainteresowany dostarczeniem wykonawcom instrumentów umożliwiających
integrację, należało nakazać zamawiającemu wykreślenie rozwiązania opartego na integracji
z posiadanym przez zamawiającego systemem i oprogramowaniem oraz systemami
dziedzinowymi, zajezdniowymi i autobusowymi.

Zarzut naruszenia przez zamawiającego art. 36 ust. 1 pkt 13 ustawy oraz art. 41 pkt. 9
ustawy w zw. z art. 7 ust. 1 ustawy poprzez wskazanie kryterium Oceny techniczno-
eksploatacyjnej w sposób nieadekwatny do przedmiotu zamówienia, uniemożliwiający wybór
najkorzystniejszej oferty, naruszający zasady uczciwej konkurencji i równego traktowania
uczestników postępowania, poprzez:
a)
wskaz
anie jako kryterium oceny ofert obudowę kasowników, preferując
jednocześnie metal jako materiał obudowy kasowników, podczas, gdy obudowa
kasowników wykonana z innych materiałów może zapewnić taką samą, a nawet
lepszą jakość i wytrzymałość, a co powoduje również, iż jedynie przedsiębiorstwo
R&G Sp. z o.o. może spełnić przedmiotowe kryterium i złożyć ofertę indywidualnie
spełniającą wyznaczone przez zamawiającego warunki, gdyż jest jedynym
przedsi
ębiorstwem na polskim rynku produkującym kasowniki w metalowej
obudowie,
Zarzut nie potwierdził się. W ocenie Izby strony przyznały, że nie ma obiektywnych norm za
pomocą, których zamawiający mógłby badać trwałość kasownika. Zamawiający wskazał, że
zależy mu na trwałych kasownikach, choćby z uwagi na niższe koszty eksploatacji.
Odwołujący nie podjął nawet próby udowodnienia, że kasowniki z innych materiałów są
bardziej trwałe niż z metalu.

b)
wskazanie jako kryterium oceny ofert koncepcji technicznej systemu i
uzależnienie punktacji przyznawanej podczas oceny ofert od dostarczenia
szczegółowej dokumentacji w postaci Opisu Technicznego Systemu, który ma
określać proponowane przez wykonawców rozwiązania, podczas, gdy
zamawiaj
ący nie udostępnił tzw. protokołów komunikacyjnych oraz kodów
źródłowych do wymiany danych, a w konsekwencji nie jest możliwym
sporządzenie owej dokumentacji przez wykonawcę niebędącego producentem
oraz dostawcą obecnego oprogramowania, co powoduje, iż wykonawca nie jest w
stanie spełnić owego kryterium
Zarzut potwierdził się. W ocenie Izby opis kryterium oceny ofert w sposób niejednoznaczny i

pozostawiający miejsce na uznaniowość zamawiającego, a także niejednoznaczny, co do
skutków nieprzyznania punktów w poszczególnych elementach tego opisu powoduje, że
kryterium oceny oferty nie umożliwia wyboru oferty najkorzystniejszej w rozumieniu art. 2 pkt
5 ustawy, ani także nie zapewnia realizacji zasad postepowania określonych w art. 7 ust. 1 i
3 ustawy. Rację należy także przyznać odwołującemu, że w sytuacji niemożności
dostarczenia przez zamawiającego instrumentów niezbędnych do dokonania integracji,
wymóg opisu systemu uwzględniającego integrację jest niemożliwy do wykonania. Tak
opisane zatem podkryterium zatem nie służy wyborowi oferty najkorzystniejszej, co
pozostaje w sprzeczności z treścią art. 7 ust. 3 ustawy.

c)
wskaza
nie jako kryterium oceny ofert kompatybilności z systemami pokładowymi i
zajezdniowymi i uzależnienie punktacji przyznawanej podczas oceny ofert od
dostarczenia szczegółowej dokumentacji w postaci Opisu Technicznego Instalacji,
który ma określać proponowane przez wykonawców rozwiązania, podczas, gdy
zamawiający nie udostępnił tzw. protokołów komunikacyjnych oraz kodów
źródłowych do wymiany danych, a w konsekwencji nie jest możliwym
sporządzenie owej dokumentacji przez wykonawcę niebędącego producentem
oraz dostawcą obecnego oprogramowania, co powoduje, iż wykonawca nie jest w
stanie spełnić owego kryterium
Zarzut potwierdził się. W ocenie Izby ustanowienie podkryterium opisu technicznego
integracji w sytuacji, gdy nie wszyscy wykonawcy mają równy dostęp do instrumentów
umożliwiających tę integrację, a nadto premiowanie opisu ocenianego za pomocą
niejednoznacznych, ocennych pojęć prowadzi do naruszenia zasady kryterium
o
biektywnego, mierzalnego. Jak już Izba wskazywała, zadaniem kryterium oceny ofert
nie jest równe traktowanie wykonawców, ale wybór oferty najkorzystniejszej, czyli
najlepszej w przyjętych kryteriach oceny ofert. Z tego względu oczywiście kryteria oceny
ofe
rt zawierają w sobie element dyskryminujący, jednak w ocenie Izby aby mogło dojść
do wyboru wykonawcy korzystniejszego oferty poddawanych ocenie wykonawców muszą
być porównywalne, zatem muszą dotyczyć tego samego zakresu przedmiotowego. Jak
ustaliła Izba wyżej zaoferowanie nowego systemu centralnego i wszystkich jego modułów
i podsystemów wraz z urządzeniami i sprzętem nie jest tym samym, co integracja
dotychczasowych modułów i systemów wraz z urządzeniami i sprzętem w celu
stworzenia systemu centralnego, z
właszcza w sytuacji, w której zamawiający nie
zapewnia wykonawcom możliwości realizowania integracji na jednakowych warunkach.
Tym samym skoro rozwiązania nie są porównywalne nie jest w ocenie Izby dopuszczalne
preferowanie jednego z rozwiązań przewidzianych przez zamawiającego. Prowadzi to
bowiem, nie do zaspokojenia potrzeb zamawiającego, ale do utrzymania

dotychczasowego kręgu dostawców i producentów. W ocenie Izby premiowanie takiego
ograniczenia nie może być rozpatrywane przez pryzmat oszczędności środków
publicznych czy trudności adaptacyjnych personelu zamawiającego. Izba stoi na
stanowisku, że nie zadbanie przez zamawiającego o instrumenty umożliwiające
wykonawcom wykonanie integracji na podobnych warunkach powoduje, że zamawiający
sam naraził się na konieczność dopuszczenia rozwiązania opartego o budowę całkowicie
nowego systemu opartego o nowopowstałe moduły, podsystemy, urządzenia i sprzęt.
Izba zaś oceniła, że tylko takie rozwiązanie jest jedynym zapewniającym uczciwą
konkurencję i równe traktowanie wykonawców. Tym samym kryterium oparte o
rozwiązanie niekonkurencyjne nie jest kryterium ustalonym zgodnie z przepisami ustawy i
dlatego Izba nakazała jego wykreślenie.
Zarzut naruszenia przez zamawiającego art. 7 ustawy w zw. z art. 14 ustawy i art. 139 ust. 1
ustawy oraz art. 29 ust. 1 ustawy w zw. z art. 353(1) k.c. w zw. z art. 36 ust. 1 pkt. 16 ustawy,
przez ukształtowanie warunków umowy żądając spełnienia przez wykonawców świadczenia
niemożliwego.

Wobec uwzględnia zarzutów odnoszących się do rozwiązania opartego na integracji oraz
przez uwzględnienie zarzutów dotyczących niemożności świadczenia w ramach takiego
rozwiązania na warunkach konkurencyjnych, a w konsekwencji nakazania zamawiającemu
zmiany opisu przedmiotu zamówienia i kryteriów oceny ofert przez usunięcie
dopuszczalności rozwiązania opartego o integrację z siwz, rozstrzygnięcie o tych zarzutach
stało się bezprzedmiotowe, bo odniesienie kwestionowanych postanowień pkt. II.1.16, II.2.7,
III.3.1.1a i II.4.12 stało się bezprzedmiotowe. W przypadku, gdy jedynym dopuszczalnym
rozwiązaniem jest budowa w pełni nowego systemu wszystkie kwestionowane
postanowienia odnoszą się do urządzeń i oprogramowanie dostarczanego przez samego
wykonawcę. Nadto w ocenie Izby model przechodzenia z systemów starych na system nowy
w sposób opisany przez zamawiającego w rozumieniu takim jak zaprezentował go na
rozprawie nie uniemożliwia wykonania zamówienia.

Mając na uwadze powyższe Izba uwzględniła odwołanie w oparciu o art. 192 ust. 1, 2 i 3 pkt.
1 ustawy.

O kosztach postępowania orzeczono na podstawie art. 192 ust. 9 i 10 ustawy stosownie do
wyniku spraw oraz zgodnie
z § 3 pkt. 1 i 2 lit. a i b oraz § 5 ust. 2 pkt. 1 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 (Dz. U. Nr 41, poz. 238 ze zm. Z 2017r. poz. 47) zaliczając na poczet niniejszego

postępowania odwoławczego koszt wpisu od odwołania uiszczony przez odwołującego oraz
zasądzając od zamawiającego na rzecz odwołującego koszty zastępstwa prawnego na
podstawie faktury Vat złożonej przez zamawiającego na rozprawie z ograniczeniem do kwoty
maksymalnej dopuszczonej przez rozporządzenie tj. w kwocie 3 600zł. oraz kosztów dojazdu
w wysokości 341, 67zł. brutto.

Przewodniczący: ……………


Wcześniejsze orzeczenia:

Baza orzeczeń KIO - wyszukiwarka

od: do:

Najnowsze orzeczenia

Dodaj swoje pytanie