KIO 26/18 WYROK dnia 22 stycznia 2018 r.

Stan prawny na dzień: 23.02.2018

Sygn. akt: KIO 26/18 

WYROK 

z dnia 22 stycznia 2018 r. 

Krajowa Izba Odwoławcza - 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: 

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, 

w pozostałym zakresie odwołanie oddala 

Kosztami postępowania obciąża Miasto Opole z siedzibą w Opolu, ul. Piastowska 

17 i 

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 

Zasądza  od  Miasta  Opola  z  siedzibą  w  Opolu,  ul.  Piastowska  17  na 

rzecz 

GMV 

Innovating 

Solutions 

spółka 

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: 

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: 

[email protected]). 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. ” 

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, 

treść  pkt  1.  IV  w  Części  II  siwz  -  Oferta  Przetargowa  Kryterium  ocena  techniczno- 

eksploatacyjna Podkryterium obudowa kasowników, 

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, 

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, 

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, 

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, 

treść  pkt  II.l.16  Załącznika  nr  1  do  umowy  (IV  Część  siwz)  -  Opis  Przedmiotu 

Zamówienia, Wymagania Ogólne, 

treść  pkt  II.2.7  Załącznika  nr  1  do  umowy  (IV  Część  siwz)  -  Opis  Przedmiotu 

Zamówienia, Wymagania stawiane wykonawcy, 

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, 

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). ” 

treść  pkt  II.8.2.  Załącznika  nr  1  do  umowy  (IV  Część  siwz)  -  Opis  Przedmiotu 

Zamówienia, Zasoby zamawiającego, 

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. 

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, 

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, 

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: 


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, 

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: 


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. 

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. 

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. 

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. 

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.  

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ł: 

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:  

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. 

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. 

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. 

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. 

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: 

Koncepcja wdrożenia elementów Systemu w autobusach. 

Wymiana  danych  i  kompatybilność  Modułów  Pokładowych  Systemu  z  Systemami 

Pokładowymi Autobusów i Zajezdniowymi. 

Koncepcja  rozwiązań  sieciowych  na  terenie  zajezdni  (w  tym  Urządzenia  i 

Oprogramowanie do wymiany danych na terenie zajezdni). 

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: 

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; 

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; 

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;  

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); 

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. 

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:  

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,  

brak  możliwości  programowania  Systemów  Pokładowych  Autobusu  wszystkich 

autobusów (wyposażonych w Autokomputer) z dostarczonego Systemu lub  

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  

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ł: 

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: 

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: 

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 

automatycznej  wymiany 

danych, 

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ść: 

programowania  Pokładowych  Systemów  Autobusowych  wszystkich  autobusów 

Operatora,  

pozyskiwania  danych  eksploatacyjnych  ze  wszystkich  autobusów  wyposażonych  w 

Autokomputer oraz ich raportowanie o zakresie funkcjonalnym (jak np. do systemu PDA),  

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ł: 

Kasownik powinien posiadać: 

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: 

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. 

Czy wszystkie wymienione w OPZ autokomputery zapewniają sterowanie wszystkimi 

modułami i systemami pokładowymi autobusu? 

Czy wszystkie wymienione w OPZ autokomputery zapewniają komunikację / wymianę 

danych pomiędzy systemami zajezdniowymi a autobusem (online poprzez sieć GSM (APN) 

poza zajezdnią? 

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? 

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 

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 

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? 

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. 

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ń. 

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. 

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”. 


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? 

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? 

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. 

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. 

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? 

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 

Jaki jest wymagan

y przez Zamawiającego zakres integracji planowanego systemu e-

bilet z poszczególnymi systemami zajezdniowymi? 

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:      ……………