KIO 245/18 WYROK dnia 26 lutego 2018 r.

Sygn. akt: KIO 245/18 

WYROK 

z dnia 26 lutego 2018 r. 

Krajowa Izba Odwoławcza   -   w składzie: 

Przewodniczący:      Daniel Konicz 

Protokolant:            

Marta Słoma 

po rozpoznaniu na rozprawie w dniu 22 lutego 2018 

r. w Warszawie odwołania wniesionego 

do  Prezesa  Krajowej  Izby  Odwoławczej  9 lutego  2018  r.  przez  Odwołującego  –  Comarch 

Polska S.A. z siedzibą w Krakowie, w postępowaniu prowadzonym przez Zamawiającego – 

Gminę Miasto Mysłowice, 

orzeka: 

Uwzględnia odwołanie i nakazuje Zamawiającemu zmianę postanowień SIWZ w zakresie 

załącznika nr 3 do Formularza oferty – „Lista oferowanych funkcjonalności” w następujący 

sposób: 

1.1. poz. 1.10 

– przez wskazanie co należy rozumieć przez wykonywanie podstawowych 

analiz przestrzennych oraz udostępnianie dedykowanych narzędzi do zaawansowanej 

analityki wielowymiarowej; 

1.2. poz. 1.16 

– przez wskazanie poziomu szczegółowości analizy danych ewidencyjnych, 

o których mowa w tym wymaganiu; 

1.3. poz. 1.22 

– przez określenie niezbędnych elementów uproszczonego wniosku o dostęp 

do danych PZGiK; 

1.4. poz. 2.1 

– przez określenie katalogu dokumentów dla firmy wywozowej, o którym mowa 

w tym wymaganiu; 

1.5. poz.  2.4 

–  przez  wskazanie  rodzajów  urządzeń,  na  które  mają  być  pobierane 

dokumenty oraz z których dokumenty mają być przesyłane do repozytorium; 

1.6. poz.  2.5 

–  przez  wskazanie  atrybutów  (metadanych),  którymi  opisywane  będą 

dokumenty wskazane w tym wymaganiu; 

1.7. poz. 2.6 

– przez wskazanie sposobów grupowania fizycznego dokumentów; 

1.8. poz. 2.7 

– przez wskazanie sposobów grupowania logicznego dokumentów; 

1.9. poz. 2.8 

– przez wskazanie co należy rozumieć przez składanie uprawnień. 

Oddala odwołanie w pozostałym zakresie. 

Kosztami postępowania obciąża Zamawiającego i: 

3.1. zalicza  w  poczet 

kosztów  postępowania  odwoławczego  kwotę  15.000,00 zł 

(słownie: piętnaście  tysięcy  złotych  00/100)  uiszczoną  przez  Odwołującego  tytułem 

wpisu od odwołania, 

zasądza  od  Zamawiającego  na  rzecz  Odwołującego  kwotę  18.600,00 zł 

(słownie: osiemnaście  tysięcy  sześćset  złotych  00/100)  stanowiącą  koszty 

postępowania  odwoławczego  poniesione  przez  Odwołującego  z  tytułu  wpisu  od 

odwołania i wynagrodzenia pełnomocnika. 

Stosownie  do  art.  198a  i  198b  ustawy  z  dnia  29  stycznia  2004  r. 

–  Prawo  zamówień 

publicznych (Dz.U.2017.1579 j.t. ze zm.) 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 Katowicach. 

Przewodniczący:   ………………………………………. 

Sygn. akt KIO 245/18 

Uzasadnienie 

Gmina  Miasta  Mysłowice  (dalej: „Zamawiający”)  prowadzi  w  trybie  przetargu 

nieograniczonego,  na  podstawie  przepisów  ustawy  z  dnia  29 stycznia  2004  r. 

Prawo 

zamówień publicznych (Dz.U.2015.2164 j.t. ze zm.), zwanej dalej „Pzp”, postępowanie 

o  udzielenie  zamówienia  publicznego  na  „Dostawę  Zintegrowanego  Systemu  Informacji 

Przestrzennej  oraz  sprzętu  i  oprogramowania  serwerowego  w  ramach  Projektu  Budowa 

Mysłowickiej  Infrastruktury  Informacji  Przestrzennej  jako  narzędzie  zwiększenia  zakresu 

i 

jakości  usług  świadczonych  drogą  elektroniczną  realizowanego  w  ramach  Działania  2.1 

Wsparcie 

rozwoju 

cyfrowych 

usług 

publicznych, 

Oś 

priorytetowa 

II  

Cyfrowe  Śląskie  Regionalnego  Programu  Operacyjnego  Województwa  Śląskiego  na  lata 

2020”, zwane dalej: „Postępowaniem”. 

Wartość  zamówienia  przekracza  kwoty  określone  w  przepisach  wykonawczych 

wydanych na podstawie art. 11 ust. 8 Pzp. 

Ogłoszenie  o  zamówieniu  zostało  opublikowane  w  Dzienniku  Urzędowym 

Unii Europejskiej  30  stycznia  2018  r.  pod  nr  2018/S  020-041201.  Tego  samego  dnia 

Zamawiający zamieścił specyfikację istotnych warunków zamówienia (dalej „SIWZ”) na stronie 

internetowej. 

Postanowienia  SIWZ  zaskarżone  zostały  odwołaniem  wniesionym  do  Prezesa  Izby 

9 lutego  2018 

r.  przez  wykonawcę  Comarch  Polska  S.A.  z  siedzibą  w  Krakowie 

(dalej 

„Odwołujący”). 

Odwołujący zarzucił Zamawiającemu naruszenie art. 7 ust. 1 Pzp w zw. z § 13 ust. 1 

pkt 

1  Rozporządzenia  Ministra  Rozwoju  z  dnia  26  lipca  2016  r.  w  sprawie  rodzajów 

dokument

ów, jakich może żądać zamawiający od wykonawcy w postępowaniu o udzielenie 

zamówienia (Dz.U.2016.1126), zwanego dalej „Rozporządzeniem”, a także art. 29 ust. 1 Pzp 

przez: 

zaniechanie  określenia  kryteriów  oceny,  czy  prezentowana  Zamawiającemu 

podczas  demons

tracji  próbki  systemu  funkcjonalność  spełnia  wymagania 

Zamawiającego (zaniechanie określenia scenariuszy prezentacji funkcjonalności), 

co  uniemożliwia  wykonawcom  zweryfikowanie  przed  terminem  składania  ofert, 

czy 

ich oferta może być uznana za niezgodną z SIWZ, co również narusza zasadę 

uczciwej konkurencji i równego traktowania wykonawców; 

zobowiązanie  wykonawców  do  demonstracji  funkcjonalności,  których  zbiór 

wykracza  poza  zakres  standardowych  funkcjo

nalności  systemów  oferowanych 

w 

postępowaniach,  których  przedmiotem  jest  dostawa  systemu  informacji 

przestrzennej, co przeczy idei próbki jako instrumentu Prawa zamówień publicznych 

i  może  naruszać  zasadę  prowadzenia  postępowania  z  zachowaniem  uczciwej 

konkurencji i równego traktowania wykonawców; 

w  związku  z  powołanymi  pod  lit.  a]  okolicznościami  –  opisanie  przedmiotu 

zamówienia  w  sposób  nieprecyzyjny,  niejednoznaczny,  bez  uwzględnienia 

wszystkich okoliczności mogących mieć wpływ na przygotowanie oferty. 

Odwołujący wniósł o uwzględnienie odwołania i nakazanie Zamawiającemu zmianę 

postanowień SIWZ, polegającą na doprecyzowaniu zakresu i sposobu demonstracji, przez: 

rezygnację  z  wymagania  załączenia  do  oferty  próbki  (i  demonstracji  działania 

funkcjonalności),  względnie  –  zmianę  wymaganych  do  zaprezentowania 

funkcjo

nalności 

na 

standardowe 

funkcjonalności 

systemów 

informacji 

przestrzennych, opisanych dokładnie i bez niejasności (przykładowy zbiór 

i sposób opisu Odwołujący zamieścił w załączniku do odwołania), 

w przypadku utrzymania wymagania załączenia do oferty próbki i przeprowadzenia 

demonstracji 

–  określenie  zasad  dotyczących  kryteriów  demonstracji,  tj.  jakie 

parametry  muszą  być  spełnione,  aby  Zamawiający  uznał  oprogramowanie  za 

spełniające wymagania określone w SIWZ. 

Odwołujący  podkreślił,  że  ma  interes  w  uzyskaniu  zamówienia,  ponieważ  jest 

podmiotem  zdolnym  do  jego  wykonania,  posiadającym  w  tym  zakresie  odpowiednie 

kompetencje i doświadczenie. Przez sformułowanie przez Zamawiającego postanowień SIWZ 

w sposób naruszający przepisy ustawy Odwołujący może być pozbawiony możliwości złożenia 

oferty  i  uzyskania  zamówienia,  tym  samym  w  wyniku  naruszenia  przez  Zamawiającego 

przepisów  ustawy  Odwołujący  może  ponieść  szkodę  polegającą  na  braku  uzyskania 

przedmiotowego zamówienia. 

Uzasadniając zarzuty odwołania Odwołujący wyjaśnił, że zgodnie z treścią rozdziału V 

SIWZ 

–  „Wykaz  oświadczeń  i  dokumentów,  potwierdzających  spełnianie  warunków  udziału 

w 

postępowaniu oraz brak podstaw do wykluczenia”, pkt 14 (str. 12-13 SIWZ): „Wraz z ofertą 

Wykonawca  ma  złożyć  próbkę,  zgodnie  z  załącznikiem  nr  9  do  SIWZ  tj.  próbkę 

oprogramowania na nośniku danych. (...) Niezłożenie przez Wykonawcę wymaganej próbki 

oraz dokumentów określonych w niniejszym rozdziale skutkować będzie odrzuceniem oferty. 

Złożenie  przez  Wykonawcę  próbki  niezgodnej  z  wymaganiami  Zamawiającego  skutkować 

będzie odrzuceniem oferty na podstawie art. 89 ust 1 pkt 2 uPzp. Niestawienie się Wykonawcy 

w  wyznaczonym  terminie  na  demonstrację  próbki  będzie  uznane  za  niezgodność  oferty 

z SIWZ i oferta taka zostanie odrzucona na podstawie 

art 89 ust 1 pkt 2 uPzp […]”. 

W  Załączniku  Nr  9  do  SIWZ  Zamawiający  zawarł  opis  zasad  przygotowania 

i 

przeprowadzenia  demonstracji  próbki.  W  pkt  5-7  powołanego  załącznika  Zamawiający 

określił, że: 

„W  celu  oceny  zgodności  z  SIWZ  oferowanego  rozwiązania,  każdy  Wykonawca 

zostanie  poproszony  przez  Zamawiającego  o  wykonanie  demonstracji  Próbki,  która  to 

procedura w dalszej części nazywana będzie demonstracją Próbki lub demonstracją. 

Zadeklarowane  funkcjonalności  uznaje  się  za  zgodne  ze  stanem  faktycznym, 

jeśli demonstracja  wykaże,  że  funkcjonalności,  które  deklarują  Wykonawcy  są  zawarte 

w 

systemie,  jeśli  w  trakcie  demonstracji  w  próbce  nie  zostaną  przez  Zamawiającego 

zidentyfikowane  właściwości,  które  zgodnie  z  deklaracją  Wykonawcy  system  posiada, 

wówczas Zamawiający uzna, że Wykonawca przedstawił w ofercie nieprawdziwą informację. 

Przedstawienie przez Wykonawcę informacji wprowadzających w błąd Zamawiającego 

mogących  mieć  wpływ  na  decyzje  podejmowane  przez  Zamawiającego  w  niniejszym 

zamówieniu, w szczególności niepotwierdzenie w trakcie demonstracji oświadczeń złożonych 

w  ofercie  Wykonawcy  co  do  właściwości  (w  tym  funkcjonalności)  oferowanego  Systemu, 

skutkować 

będzie 

wykluczeniem 

Wykonawcy 

z 

prowadzonego 

postępowania,  

zgodnie z art. 24 ust 1 pkt 17 uPzp, 

niezależnie od innych skutków przewidzianych prawem 

[…]”. 

Ponadto

, zgodnie z treścią pkt 3 i 4 Załącznika nr 9 do SIWZ: 

„Wszystkie  wymagania  oprogramowania  wskazane  w  załączniku  nr  3  do 

Formularza 

ofertowego  są  obligatoryjne  na  moment  składania  oferty.  Brak  spełnienia 

któregokolwiek z ww. wymagań obligatoryjnych skutkuje odrzuceniem oferty. […] 

Przygotowanie  Próbki  w  sposób  uniemożliwiający  zaprezentowanie  wszystkich 

właściwości,  o  których  mowa  powyżej,  brak  złożenia  próbki  wraz  z  ofertą,  a  także  brak 

wykaz

ania  właściwości  wymaganych  przez  Zamawiającego,  będzie  traktowane  jako 

niezgodność oferty z wymaganiami SIWZ i spowoduje odrzucenie oferty na podstawie art. 89 

ust. 1 pkt 2 ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (tekst jednolity: 

Dz. U. z 

2017 r., poz. 1579), dalej uPzp […]”. 

W Załączniku nr 3 do Formularza ofertowego Zamawiający wymienił w trzech tabelach 

łącznie  55  wybranych  funkcjonalności,  które  wykonawcy  zobowiązani  są  zaprezentować 

podczas  demonstracji  próbki.  Oznacza  to,  że  funkcjonalności  te  muszą  być  gotowe  

(być w standardzie systemu) na dzień złożenia oferty. 

W  pierwszej  kolejności  Odwołujący  zauważył,  że  zgodnie  z  ugruntowaną  linią 

orzeczniczą,  zamawiający  w  ramach  próbki  może  żądać  zademonstrowania  wyłącznie 

funkcjonalności,  które  są  standardowe  dla  danego  rodzaju  systemu  informatycznego. 

Tymczasem  Zamawiający  dokonał  wyboru  55  wymaganych  na  dzień  złożenia  oferty 

funkcjonalności, spośród których większość stanowią funkcjonalności specyficzne, które mogą 

być  realizowane  przez  system  informacji  przestrzennej,  lecz  na  poziomie  bardzo 

szczegółowym  –  jako  finalna  wersja  danej  aplikacji,  dostosowanej  do  potrzeb  i  wymagań 

danego  klienta.  Nie  jest  to  zatem  standard,  baza,  l

ecz  elementy  szczegółowe.  Co  prawda 

elementy  te  zostały  wybrane  przez  Zamawiającego  spośród  wielu  funkcjonalności 

wymaganych na etapie wdrożenia, lecz de facto, aby je pokazać, system musi być praktycznie 

w  większej  części  gotowy  na  moment  złożenia  oferty,  ponieważ  aby  zaprezentować 

szczegółowe funkcjonalności, wymagane przez Zamawiającego - konieczne jest już właśnie 

posiadanie takiego gotowego systemu. 

Tytułem  przykładu  Odwołujący  podał,  że  wykazanie  spełniania  wymagania  2.11. 

(Portal Budżet obywatelski): „W części aplikacyjnej portal musi posiadać kreator formularza 

zgłoszeniowego  „zgłoś  Projekt"  –  który  musi  umożliwiać  budowę  dowolnego  w  swojej 

strukturze  formularza  (pola  tekstowe,  listy  wyboru,  nieograniczona  liczba  elementów 

formularza), gdzie pola obowiązkowe definiowane są przez administratora. Kreator posiada 

zabezpieczenia,  pozwalające  na  zgłoszenie  jednego  projektu  tylko  przez  jedną  osobę 

(np. 

weryfikacja  numeru  PESEL,  o  ile  istnieje,  po  stronie  zleceniodawcy,  możliwość 

pozyskania  go,  inne  zaimplementowane  środki  bezpieczeństwa)[…]”  implikuje  posiadanie 

również  funkcjonalności  opisany  w  OPZ  w  punkcie  4.1.5.3.3.  Portal  Budżet  obywatelski: 

„dowolne  definiowanie  struktury  portalu  w  jego  części  opisowej,  w  tym  dodawanie,  

edycja  i  usuwanie  pozycji  menu  portalu  na  wszystkich  poziomach,  definiowanie  przedziału 

cza

sowego  wyświetlania  danej  pozycji;  dowolne  definiowane  treści  poszczególnych 

dokumentów  opisowych  wraz  z  możliwością  umieszczania  materiałów  multimedialnych  

(pliki:  foto,  video,  animacje  fl

ash),  definiowanie przedziału czasowego wyświetlania danego 

dokume

ntu,  automatyczny  mechanizm  publikacji  i  zakończenia  publikację  w  zadanym 

przedziale 

czasowym; 

definiowanie 

dowolnych 

grup 

tematycznych/obszarowych, 

umożliwiających  klasyfikowanie  zgłoszonych  projektów  (jeden  projekt  może  zostać 

umieszczony  w  jednej  lub  kilku  grupach 

–  narzędzie  definiujące  po  stronie  administratora), 

możliwość  dowolnego  opisania  danej  grupy  –  dokument  klasy  CMS,  pozwalający  na 

umieszczanie dowolnych treści tekstowych, a także fotograf i i multimediów; tworzenie grupy 

dokumentów  pełniącej  rolę  forum  informacyjnego  moderowanego  przez  administratora, 

posiadającej odnośniki do przygotowanych indywidualnie stron opisowych, w tym możliwość 

tworzenia formularzy, np. „zadaj pytanie do BO” […]”. 

To jedno wymaganie powoduj

ę – zdaniem Odwołującego – że należy dostarczyć nie 

tylko zawansowane narzędzia klasy CMS system zarządzania treścią (content management 

system), 

ale  i  narzędzia  deweloperskie,  umożliwiające  budowę  tak  skomplikowanych 

formularzy z zaawansowaną logiką ich działania. Jeżeli na zadaniu próbnym wymagane jest 

zaprezentowanie wymagania 2.11, to potencjalny wykonawcy musi również spełnić pozostałe 

wymienione  wymagania  funkcjonalne,  gdyż  zwierają  się  one  w  tej  samej  grupie  z  zakresu 

zawansowanych narzędzi deweloperskich. 

Odwołujący  stwierdził,  że  dotyczy  to  praktycznie  wszystkich  opisanych  przez 

Zamawiającego  w  Załączniku  nr  3  formularza  ofertowego,  a  więc  tych,  które  mają  być 

zademonstrowane  jako  istniejące  w  systemie  na  dzień  złożenia  oferty.  W  konsekwencji, 

w 

ocenie  Odwołującego,  nie  wiadomo  czym  Zamawiający  kierował  się  przy  wyborze 

funkcjonalności, które mają być gotowe na dzień złożenia oferty.  

Dla  przykładu,  Zamawiający  wymaga  gotowej  funkcjonalności  i  zademonstrowania 

większości (6 z 9) wymagań (wymagania nr 1.11 do 1.16), dotyczących aplikacji dostępu do 

danych  ewidencji  gruntów  i  budynków,  a  jednocześnie  stwierdza  w  OPZ,  

że  „Szczegóły  w  zakresie  dotyczącym  sposobu  implementacji  funkcjonalności  aplikacji 

dostępu  do  danych  ewidencji  gruntów  i  budynków  oraz  jej  ostatecznej  konfiguracji, 

ustalone 

zostaną przez Wykonawcę z Zamawiającym na etapie opracowania Szczegółowego 

projektu wdrożenia […]”. To samo dotyczy aplikacji zarządzania systemem i użytkownikami i 

geoportalu miejskiego.  

Inny  przykład  –  Zamawiający  wymaga  gotowej  funkcjonalności  i  zademonstrowania 

kilku wybranych, według trudnych do określenia w opinii Odwołującego, wymagań np.: 2 z 8 

(pierwsze  i  ostatnie  wymaganie  dotyczące  modułu  konfiguracyjnego),  1  z  6  (środkowe) 

wymagań  dotyczących  modułu  diagnostycznego,  nie  stawia  natomiast  wymagań  odnośnie 

modułu  administracyjnego  i  modułu  diagnostycznego  oraz  pozostałych  wymagań. 

Nie wiadomo 

według jakiego klucza Zamawiający dokonał wyboru funkcjonalności, które mają 

być zaprezentowane. Faktem jest jednak, że wybór ten wygląda na dokonany przypadkowo, 

wyrywkowo, ponieważ funkcjonalności pochodzą z różnych modułów i różnych jego warstw 

zaawansowania.  Być  może  jest  jakiś  system,  który  ma  wszystkie  wymagane  przez 

Zamawiającego  funkcjonalności  w  standardzie,  oznaczałoby  to  jednak,  że  Zamawiający 

określił wymagania wobec próbki na bazie jednego, konkretnego systemu, i tylko ten jeden 

konkretny  system  może  być  zaoferowany,  co  jest  oczywiście  sprzeczne  z  podstawowymi 

zasadami  zakazu 

opisywania  przedmiotu  zamówienia  w  sposób  naruszający  uczciwą 

konkurencję i równe traktowanie wykonawców. 

Ponadto, 

zdaniem Odwołującego, niezrozumiałe jest przypisywanie w załączniku nr 3 

do  formularza  ofertowego  poszczególnych  wymaganych  do  zademonstrowania 

funkcjonalności  do  określonych  modułów  oprogramowania.  Oczywistym  jest,  że  w  każdym 

systemie  informatycznym  określona  funkcjonalność  może  być  umiejscowiona  w  innym 

module.  J

est  to  wyłącznie  kwestia  konstrukcji  technologicznej  i  pojęciowej  systemu, 

niemająca wpływu na faktyczny zakres funkcjonalny systemu.  

Przykładowo,  Zamawiający  wymaga,  aby  określone  funkcjonalności  systemu 

znajdowały  się  w  Aplikacji  dostępu  do  danych  przestrzennych  i  opisowych. 

Aplikacja 

administrowania  systemem  i  jego  użytkownikami  jest  typową  aplikacją 

administracyjną  wewnętrzną,  obsługiwaną  przez  bardzo  ograniczoną  grupę  użytkowników 

(administratorów).  Aplikacje  tego  typu  charakteryzują  się  również  indywidualnymi, 

specyficznymi  elementami  obsługi  Systemu  i  Użytkowników.  Wymaganie,  aby  aplikacja 

posiadała moduł diagnostyczny umożliwiający m.in.: wgląd do rejestru wykonywanych zasileń 

(np.  plików  SWDE/GML,  plików  SHP/DBF,  plików  XLS,  XML),  może  być  realizowane 

w 

systemie  w  inny  sposób,  przez  inne  moduły,  niekonieczne  nazwane  modułami 

administracyjnymi. 

Inny  przykład  –  wymaganie  2.3:  „Moduł  musi  umożliwiać  wysyłkę  do  klienta  urzędu 

następujących informacji: • informacji spersonalizowanej, • informacji dotyczącej konieczności 

podjęcia konkretnych działań np. wygaśnięcie terminu płatności raty podatku / opłaty lokalnej, 

konieczność złożenia deklaracji etc. […]”. 

Moduł  powiadamiania  klienta  faktycznie  może  istnieć  jako  wyodrębniona  aplikacja, 

ale 

często  występuje  jako  pewien  zakres funkcjonalności  rozbitych  pomiędzy  wszystkie  lub 

większość  modułów  systemu.  Sama  deklaracja  otrzymywania  informacji  od  Systemu  przez 

wskazane źródła komunikacji (SMS, mail itp.) jest w wielu systemach deklarowana podczas 

zakładania  konta  w  modułach  administracyjnych  systemu.  Sama  chęć  otrzymywania 

konkretnych  wiadomości  o  stanie  sprawy  czy  zaległościach  deklarowana  jest  już 

w 

konkretnych modułach aplikacji z których korzysta użytkownik. 

Odwołujący  podkreślił,  że  nie  ma  określonej  „złotej”  metody  budowania  systemów 

informatycznych dla funkcjonalności, dla których nie ma określonych reguł narzuconych przez 

zewnętrze czynniki, jakim jest  przykładowo stan  prawny.  Każdy  z  wykonawców  może mieć 

owe funkcjonalności administracyjne, zarządcze, rozłożone w dowolny sposób. 

W  ocenie  Odwołującego  wadliwy  jest  również  dokonany  przez  Zamawiającego  opis 

funkcjonalności. 

P

rzykładowo, w wymaganiu 1.10 Zamawiający określa, że „Aplikacja musi umożliwiać 

łatwe  wykonywanie  podstawowych  analiz  przestrzennych  oraz  udostępniać  dedykowane 

narzędzia  do  zaawansowanej  analityki  wielowymiarowej,  w  szczególności  aplikacja  musi 

umożliwiać: wykorzystanie przestrzennych zależności pomiędzy różnymi obiektami tej samej 

lub  wielu  różnych  warstw  tematycznych  w  celu  poszerzenia  możliwości  selekcji  o  funkcje 

rozszerzania i zawężania oraz zawierania i przecinania, stykania się i nakładania się, a także 

rozłączności obiektów) […]”. 

Abstrahując  od  faktu,  że  –  co  wskazano  wyżej  –  analizy  przestrzenne  nie  są 

standardowymi funkcjonalnościami realizowanymi przez przeglądarkę www, Zamawiający nie 

określa dokładnie zakresu funkcjonalnego zadania. Nie wiadomo w szczególności, jak należy 

rozumieć stwierdzenie „wykonywanie podstawowych analiz przestrzennych” i „udostępnianie 

dedykowanych 

narzędzi 

do 

zaawansowanej 

analityki 

wielowymiarowej”. 

Odwołujący zaznaczył  również  fakt  braku  dokładnego  opisu,  na  czym  ma  polegać  analiza 

zawężania oraz zawierania i przecinania, stykania się i nakładania się, a także rozłączności 

obiektów. 

Podobnie,  w  przypadku  wymagania  1.16: 

„Aplikacja  musi  umożliwiać  wykonywanie 

szczegółowych  analiz  danych  ewidencyjnych  w  oparciu  o  dodatkowe  atrybuty  opisowe 

skojarzone  z  obiektami  ewidencji  a  pochodzących  z  innych  baz  źródłowych,  

wraz z możliwością wyświetlania wyszukanych obiektów na mapie (np. informacje o funkcji 

terenu w MPZP dla danej działki, po załadowaniu takich danych do systemu) […]”. 

Takie 

przedstawienie 

wymagania 

funkcjonalnego 

jest 

zbyt 

ogólne 

i, 

według Odwołującego, Zamawiający wymaga skojarzenia danych w niewłaściwym module lub 

aplikacji. To aplikacja dostępu do danych, przykładowo do danych w MPZP (Miejscowe Plany 

Zagospodarowania  Przestrzennego), 

powinna  umożliwić  skojarzenie  informacji  o  funkcji 

terenu w MPZP z danymi ewidencji gruntów i budynków na którym został uchwalony ten plan. 

Dane  dotyczące,  przykładowo,  działki  ewidencyjnej  są  elementem  pierwotnym, 

referencyjnym  w  stosunku  do  innych  danych  przestrzennych.  Żąda  się  w  wymaganiu,  

aby w miejscu tworzenia danych pierwotnych, jakimi są informacje o działkach i budynkach, 

była  również  gromadzona  informacja  o  wszystkich  innych  danych,  które  wykorzystują  ową 

informację pierwotną. Trudno jest na etapie tworzenia modułu dostępu do danych ewidencji 

gruntów  i  budynków  przewidzieć  wszystkie  możliwe  inne  moduły,  które  z  danych  modułu 

danych  ewidencji  gruntów  i  budynków  będą  korzystać.  Możliwe  jest  jednak,  aby  każdy 

z 

modułów  korzystających  z  danych  ewidencji  gruntów  i  budynków  zapisywał  w  swych 

strukturach  skojarzenie  z  danymi  ewidencji  gruntów  i  budynków  –  i  tak  wg.  Odwołującego 

winno być sformułowane wymaganie. 

Inny przykład – wymaganie 1.22: „Poza pełnym formularzem, portal musi umożliwiać 

złożenie  wniosku  o  dostęp  do  danych  pzgik  w  formie  uproszczonej,  przez  uproszczony 

formularz składający się dowolnie zdefiniowanych przez administratora pól […]”. 

Odwołujący  podkreślił,  że  we  wspomnianym  Rozporządzeniu  Ministra  Administracji 

i 

Cyfryzacji  z  9  lipca  2014  r.  w  sprawie  udostępniania  materiałów  państwowego  zasobu 

geodezyjnego  i  kartograficznego,  wydawania  licencji  oraz  wzoru  Dokumentu  Obliczenia 

Opłaty,  nie  ma  wytycznych  co  do  uproszczonej  formy  wniosku.  Wniosek  takowy  często 

powstaje  na  skutek  praktyk,  jakie  w  urzędzie  są  tworzone.  Nie  ma  zatem  wytycznych  jak 

takowy wniosek powinien 

wyglądać i jakie pola obligatoryjne posiadać. 

Kolejny przykład – wymaganie 2.1: „Moduł musi udostępniać w portalu internetowym 

po  uwierzytelnieniu  następujące  informacje  dla  firm  wywozowych:  dane  na  temat 

obsługiwanych nieruchomości wraz z ich ewentualną charakterystyką (np. zobowiązanie do 

segregacji,  liczba  kubłów  itp.)  oraz  możliwość dodania innych  zestawień  jak  np.  informacje 

z 

rejestru  działalności  regulowanej;  wybrane  dokumenty  dla  firmy  wywozowej; 

wykaz 

dokumentów  przesłanych  do  urzędu  przez  firmę  wywozową  (np.  harmonogram 

wywozu, lub raport z wywozu odpadów) oraz możliwość wysłania dokumentów […]”. 

We 

wszytkach tych punktach brak jest informacji, co dokładne powinno być elementem 

prezentacji  na  zadaniu  próbnym.  Stwierdzenie  „wybrane  dokumenty  dla  firmy  wywozowej”, 

nie 

określa, jakie to mają być dokładnie dokumenty. Stwierdzenie „oraz możliwość wysłania 

dokumentów”  nie  określa,  jakie  dokumenty  powinny  podlegać  procesowi  wysłania. 

Całościowo wymaganie  jest  zbyt  ogólne  w  swym  zakresie  i  powinno  podlegać 

uszczegółowieniu  (przy  czym,  w  ocenie  Odwołującego,  powinno  się  to  odbywać  na  etapie 

realizacji 

projektu, a nie prezentacji próbki). 

Kolejny  przykład  –  wymagania  dla  Modułu  repozytorium  dokumentów  dla  Rady 

i 

Zarządu Miasta: 

„2.4.  Moduł musi umożliwiać pobranie dokumentów na urządzenie oraz przesłania dokumentu 

z  urządzenia  do  repozytorium  (dla  użytkownika  nie  będącego  administratorem  – 

bez 

możliwości nadpisania dokumentu – zapis nowej wersji), 

Moduł musi umożliwiać indeksowanie i porządkowanie dokumentów oraz ich opisywanie 

zestawem atrybutów (metadanych). 

Moduł musi udostępniać różne sposoby grupowania fizycznego (katalogi) dokumentów 

przez administratora. 

Moduł  musi  udostępniać  różne  sposoby grupowania logicznego (widoki)  dokumentów 

zarówno przez administratora (konfiguracja domyślna), jak i przez użytkownika według 

jego indywidualnych potrzeb i preferencji. 

Moduł  musi  umożliwiać  przyporządkowanie  użytkownika  do  wielu  grup  ¡składanie 

uprawn

ień […]”. 

Wszystkie  ww. 

wymagania  są,  w  przekonaniu  Odwołującego,  nieprecyzyjne  i  na  ich 

podstawie trudno jest przygotować konkretny scenariusz prezentacji zadania próbnego.  

Przykładowo: 

1.  pkt 2.4. 

nasuwa pytania: O jakim urządzeniu jest mowa? Do jakiego repozytorium 

na być przesłany dokument? 

2.  pkt  2.5.  nasuwa  pytanie:  O 

jaki  jest  tez  zestaw  atrybutów  (metadanych)  chodzi 

Zamawiającemu? 

3.  pkt 2.6. 

nasuwa pytanie: Jakie są te różne sposoby grupowania fizycznego? 

4.  pkt 2.7. 

nasuwa pytanie: Jakie są te różne sposoby grupowania logicznego? 

5.  p

kt 2.8. nasuwa pytanie: niezrozumiałe jest stwierdzenie „użytkownika do wielu grup 

¡składanie  uprawnień”  –  co  dokładnie  jest  wymaganiem,  gdyż  stwierdzenie 

„składanie uprawnień” nie jest zrozumiałe? 

Odwołujący  podkreślił,  że  na  przestrzeni  ostatnich  kilku  lat  zamawiający, 

którzy ogłaszają postępowania na wdrożenie systemów informacji przestrzennej, w większości 

przypadków  nie  wymagają  próbki  systemu  podczas  procedury  o  udzielenie  zamówienia 

publicznego,  najprawdopodobniej  dlatego,  że  określenie  zestawu  standardowych 

funkcjonalności  systemów  tego  rodzaju,  bez  narażania  się  na  zarzut  naruszania  uczciwej 

konkurencji, 

może być trudne. Systemy dostępne na rynku różnią się między sobą  – każdy 

dostawca w odmienny sposób realizuje dane, konkretne wymaganie danego klienta, często 

nawet ten sam dostawca dla różnych klientów realizuje funkcjonalności w odmienny sposób, 

co dodatkowo utrudnia ustalenie, co jest standardem tego ro

dzaju systemów, i co może być 

w 

związku z tym objęte próbką.  

Odwołujący  podał,  że  przeanalizował  na  stronie  http://ted.europa.eu  wyniki 

wyszukiwania o

głoszeń z terytorium Polski, opublikowanych w okresie od 1 stycznia 2016 r. 

do 7 lutego 2018 r., opatrzonych kodem CPV 38221000 

– Geograficzne systemy informacyjne 

(GIS  lub 

równorzędne),  zamieszczonych  przez  „Władze  lokalne”  (atrybut  wyszukiwania: 

Rodzaj  Instytucji) 

i  znalazł  42  pozycje  dotyczących  10  postępowań.  Wśród  znalezionych 

przetargów próbka nie jest wymagana w 6 przypadkach, w 2 jest wymagana (z czego jeden 

przetarg niedawno został ogłoszony, nie ma informacji o 2 przetargach.  

Odwołujący  podkreślił,  że  w  tych  nielicznych  postępowaniach,  w  których  próbka 

występuje,  zamawiający  szczegółowo  opisuje  przebieg  badania  danej  funkcjonalności 

określa  scenariusze  testowe)  –  w  przeciwnym  przypadku  demonstracja  działania  systemu 

byłaby narzędziem arbitralnego decydowania zamawiającego, jaki zakres zademonstrowany 

przez wykonawcę można uznać za wystarczający dla uznania, że system spełnia wymagania 

zamawiającego.  Tym  samym  istniałoby  zbyt  duże  ryzyko  prowadzenia  postępowania  bez 

zachowania zasady uczciwej konkurencji i równego traktowania wykonawców.  

Odwołujący wniósł o dopuszczenie i przeprowadzenie dowodów z niżej wskazanych 

dokumentów załączonych do odwołania: 

przykładowego opisu funkcjonalności próbki (dowód O1); 

analizy  występowania  wymagania  załączenia  próbki  w  postępowaniach 

ogłoszonych w okresie 1 stycznia 2016 r. – 7 lutego 2018 r., obejmujących podobny 

przedmiot zamówienia (dowód O2); 

SIWZ  z  postępowania  prowadzonego  przez  Gminę  Miasta  Bolesławiec  na 

utworzenie systemu informacji przestrzennej (znak sprawy ZI-V.271.13.2017.DW) 

– 

do

wód O3; 

Zamawiający w pisemnej odpowiedzi na odwołanie wniósł o jego oddalenie w oparciu 

o poniższą argumentację. 

W zakresie zarzutu 

dotyczącego próbki systemu i zaniechania określenia scenariuszy 

prezentacji funkcjonalności Zamawiający wyjaśnił, że przedmiotem zamówienia jest dostawa 

systemu informacji przestrzennej, a nie je

go wykonanie, zatem ma rację Odwołujący w tym 

kontekście,  że  taki  system  musi  już  istnieć  i  być  gotowy  na  dzień  składania  ofert. 

Zamawiający podkreślił,  że  dopuszcza  zbudowanie  systemu  docelowego  z  istniejących 

paki

etów oprogramowania. 

Zamawiający  stwierdził  następnie,  że  zgodnie  z  wymogami  Pzp  ocena  ofert 

dokonywana  jest  na  podstawie  oferty  pisemnej.  W

ykonawca  musi  oświadczyć, 

jakie 

funkcjonalności  w  chwili  składania  oferty  spełnia  oferowany  przez  niego  system. 

Niestety 

praktyka pokazuje, że wykonawcy w swej ofercie oświadczają, że oferowany system 

ma daną funkcjonalność, ale często tak nie jest, co niestety napawa trudnościami na etapie 

realizacji zamówienia. Aby wyeliminować taką sytuację wprowadzono w Postępowaniu wymóg 

okazania 

(demonstracji)  systemu  jako  próbki  celem  zweryfikowania,  czy  złożone  w  ofercie 

oświadczenia  są  zgodne  z  rzeczywistością.  Zaniechanie  badania  próbki  może  bowiem 

doprowadzić  do  sytuacji,  w  której  wykonawca  zadeklaruje  w  ofercie  spełnienie  wszystkich 

para

metrów,  przy  czym  na  etapie  realizacji  zamówienia  nie  uda  mu  się  wytworzyć 

oprog

ramowania  spełniającego  wszystkie  wymagania  określone  w  Szczegółowym  Opisie 

Przedmiotu Za

mówienia („SOPZ”) w założonym czasie i budżecie. 

Po  drugie,  próbka  służy  weryfikacji  wiarygodności  oświadczeń  wykonawcy  co  do 

właściwości  oferowanego  produktu,  a  więc  zarzut  naruszenia  jakiegokolwiek  przepisu 

R

ozporządzenia jest zupełnie nieadekwatny.  

Po trzecie wymóg załączenia oprogramowania testowego wynika wprost z pkt VI.14 

SIWZ 

w  ramach  dokumentów,  jakie  wykonawca  jest  zobowiązany  załączyć  do  oferty.  W 

punkcie tym jasno przesądzono o tym, że niezłożenie przez Wykonawcę wymaganej próbki 

skut

kować  będzie  odrzuceniem  oferty.  Złożenie  przez  wykonawcę  próbki  niezgodnej 

z 

wymaganiami Zamawiającego skutkować będzie odrzuceniem oferty na  podstawie art. 89 

ust. 1 pkt 2 Pzp. 

Zasady te znalazły odzwierciedlenie w załączniku nr 9 do SIWZ, zawierającym 

opis  zasad  przygotowania  i  przeprowadzenia  demonst

racji  próbki.  Przesądza  to  – 

w 

kontekście przepisu art. 26 ust. 3 Pzp – że próbka jest elementem oferty. 

Fakt 

że  próbka  jest  elementem  oferty  powoduje,  że  postanowienia  dotyczące 

przedmiotu  zamówienia  w  pełnym  zakresie  mają  do  niej  zastosowanie  także  w  zakresie 

równoważności  przyjętych  rozwiązań.  Zwrócić  należy  przy  tym  uwagę,  że na  str.  18  SOPZ 

zamieszczone 

zostało  postanowienie:  „W  celu  zachowania  reguły  konkurencyjności 

dopuszcza się rozwiązania równoważne  do  wyspecyfikowanych  w  treści    niniejszego OPZ, 

przy  czym  za  rozwiązanie  równoważne  uważa  się  takie  rozwiązanie,  które  pod  względem 

technologii,  wydajności  i  funkcjonalności  przez  to  rozwiązanie  oferowanych,  nie  odbiega 

znacząco  od  technologii  funkcjonalności  i  wydajności  wyszczególnionych  w  rozwiązaniu 

wyspecyfikowanym,  przy  czym  nie 

podlegają  porównaniu  cechy  rozwiązania  właściwe 

wyłącznie  dla  rozwiązania  wyspecyfikowanego,  takie  jak:  zastrzeżone  patenty, 

własnościowe rozwiązania  technologiczne,  własnościowe  protokoły  itp.,  a  jedynie  te, 

które stanowią  o  istocie  całości  zakładanych  rozwiązań  technologicznych  i  posiadają 

odniesienie w rozwiązaniu równoważnym. W związku z tym wykonawca może zaproponować 

rozwiązania  które  spełniają  takie  same  funkcjonalności  wyspecyfikowane  przez 

Zamawiającego w inny, niż podany, sposób. Za rozwiązanie równoważne nie można uznać 

rozwiązania  identycznego  (tożsamego),  a  jedynie  takie,  które  w  porównywanych  cechach 

wykazuje dokładnie tą samą  lub  bardzo zbliżoną wartość użytkową.  Przez  bardzo zbliżoną 

wartość  użytkową  rozumie  się  podobne,  z  dopuszczeniem  nieznacznych  różnic  nie 

wpływających  w  żadnym  stopniu  na  całokształt  systemu,  zachowanie  oraz  realizowanie 

podobnych 

funkcjonalności w danych warunkach, identycznych dla obu rozwiązań, dla których 

to  w

arunków  rozwiązania  te  są  dedykowane.  Rozwiązanie  równoważne  musi  zawierać 

dokumentację  potwierdzającą,  iż  spełnia  wymagania  funkcjonalne  Zamawiającego,  w  tym 

wyniki porównań, testów czy możliwości oferowanych przez to rozwiązanie w odniesieniu do 

rozwiązania wyspecyfikowanego”.  

Zamawiający  dopuszcza  zatem  rozwiązania,  które  realizują  daną  funkcjonalność 

w 

sposób  inny,  niż  opisany  w  SOPZ,  a  w  szczególności  w  ramach  innych,  niż  opisane, 

modułów,  co  przeczy  twierdzeniom  Odwołującego.  Ponadto  etap  3  wdrożenia  systemu 

obejmuje opracowanie „Projektu technicznego Systemu CRD oraz węzła MIIP. W ramach prac 

analitycznych  i  projektowych  wykonawca  ma  możliwość  dowolnego  modelowania  systemu 

docelowego (zgodnie jednak ze złożoną ofertą) tak, aby spełniona została wymagana przez 

Zamawiającego funkcjonalność, lecz bez uprzedniego określenia w ramach których modułów 

mają  być  realizowane  poszczególne  funkcje  systemu  jest  zależne  od  oferowanego  przez 

w

ykonawcę zestawu komponentów/ aplikacji składowych systemu), 

Nie  jest  zatem  celowe  doprecyzowanie 

procedury  badania  próbki  przez  określenie 

szczegółowych  „scenariuszy  prezentacji  funkcjonalności,  gdyż  właśnie  takie  działanie 

pow

odowałoby  naruszenie  uczciwej  konkurencji,  uniemożliwiając  udział  Postępowaniu 

w

ykonawcom,  których  systemy  realizują  wymagane  w  SOPZ  funkcjonalności. 

Zaniechanie 

określenia  szczegółowych  „scenariuszy  prezentacji  funkcjonalności”  nie  może 

jakkolwiek  naruszać  zasadę  uczciwej  konkurencji  i  równego  traktowania  wykonawców, 

gdyż wszyscy  wykonawcy  mają  taką  samą  wiedzę  wynikającą  z  treści  załącznika  nr  9  do 

SIWZ. 

Ponadto fakt, że w niektórych postępowaniach o udzielenie zamówienia publicznego 

dotyczących  systemów  informatycznych  określono  szczegółowe  scenariusze  prezentacji 

funkcjonalności nie świadczy o tym, że jest to standardem, ani wymogiem znajdującym swe 

odzwierciedlenie w przepisach Pzp.  

Nadto  dalej  trzeba  podkreślić,  że  żądanie  określenia  szczegółowych  scenariuszy 

prezentacji funkcjonalności, zgodnie z zaprezentowanym przez Odwołującego przykładowym 

rozwiązaniem, a więc żądanie ścisłego doprecyzowania działania systemów (przez opisanie 

wymaganej  reakcji  systemów  na  wykonywane  operacje/  wywoływane  funkcje)  stoi 

w 

sprzeczności z uwagą ze str. 5 odwołania, tj. „niezrozumiałe jest przypisanie w załączniku 

nr  3  do  formularza  ofertowego  poszczególnych  wymaganych  do  zademonstrowania 

fun

kcjonalności  do  określonych  modułów  oprogramowania  […]”  i  dalszym  wywodem,  

że „w każdym systemie informatycznym określona funkcjonalność może być umiejscowiona 

w innym module 

[…]”, co jest de facto żądaniem mniej szczegółowego opisu funkcjonalności 

systemów, 

W  związku  z  zarzutami  opisania  przedmiotu  zamówienia  w  sposób  nieprecyzyjny 

i 

niejednoznaczny i zobowiązania wykonawców do demonstracji funkcjonalności, których zbiór 

wykra

cza poza zakres standardowych funkcjonalności Zamawiający podał, że znikąd nie da 

się wyprowadzić wniosku, że próbki nie można żądać w zakresie systemów istniejących na 

chwilę składania ofert, a raczej (o ile w ogóle taki wniosek można wyprowadzić) dotyczy to 

systemów, które mają być dopiero opracowane w ramach realizacji zamówienia.  

Zamawiający  stwierdził,  że  badanie  próbki  jest  mechanizmem  dość  powszechnym 

w przetargach na systemy IT

, na dowód czego wskazał na postępowania, w których wymóg 

taki przewidziano.  

Odnosząc  się  do  zarzutu  naruszenia  zasady  wyrażonej  w  art.  29  ust.  1  Pzp 

Zamawiający  podkreślił,  że  dokonał  opisu  przedmiotu  zamówienia,  w  tym  żądanych 

funkcjonalności próbki, w sposób jednoznaczny i wyczerpujący.  

Ponadto nie sposób zgodzić się ze stwierdzeniem na str. 3 odwołania, że wymagane 

na  dzień  złożenia  funkcjonalności  są  specyficzne  i  „mogą  być  realizowane  przez  system 

informacji przestrzennej, lecz na poziomie bardzo 

szczegółowym – jako finalna wersja danej 

aplikacji, 

dostosowanej 

do 

potrzeb 

i 

wy

magań 

danego 

klienta 

[…]”. 

Wymagane 

funkcjonalności, co przyznaje również Odwołujący, są wybranymi wymaganiami 

z SOPZ i 

Zamawiający miał prawo wybrać akurat te a nie inne wymagania, jako te, które mają 

być  spełnione  na  dzień  składania  ofert.  Wymagania  te  nie  dotyczą  oprogramowania 

narzędziowego (samych silników systemów informacji przestrzennej, podobnie jak nie dotyczą 

silników relacyjnych baz danych, oprogramowania biurowego systemów graficznych, itp. oraz 

innego 

oprogramowania 

narzędziowego), 

lecz 

oprogramowania 

aplikacyjnego. 

Nie 

wykraczają  one  poza  przykładowe  (w  tym  wskazane  powyżej)  aplikacje  systemów 

informacji przestrzennej wdrażanych w jednostkach samorządu terytorialnego w Polsce. 

Niezależnie od argumentacji merytorycznej Zamawiający wniósł również o rozważanie 

przez 

Izbę  konieczności  pozostawienia  bez  rozpatrywania  odwołania,  która  nie  spełnia 

podstawowych wymagań, jakim powinno się cechować odwołanie. 

Zgodnie z przepisem art. 180 ust. 3 Pzp, odwołanie powinno wskazywać czynność lub 

zaniechanie 

czynności  zamawiającego, której  zarzuca  się niezgodność  z  przepisami ustaw 

i 

zawierać zwięzłe przedstawienie zarzutów, określać żądanie oraz wskazywać okoliczności 

faktyczne i prawne uzasadniające wniesienie odwołania.  

Odwołujący wniósł o nakazanie Zamawiającemu modyfikacji SIWZ przez rezygnację 

z 

wymagania załączenia do oferty próbki (i demonstracji działania funkcjonalności), względnie 

zmianę  wymaganych  do  zaprezentowania  funkcjonalności  na  standardowe  funkcjonalności 

systemów informacji przestrzennej, opisanych dokładnie i bez niejasności lub, w przypadku 

utrzymania  wymagania  załączenia  do  oferty  próbki  i  przeprowadzenia  demonstracji, 

określenie zasad dotyczących kryteriów demonstracji – jakie parametry muszą być spełnione, 

aby 

Zamawiający  uznał  oprogramowanie  za  spełniające  wymagania  określone  w  SIWZ, 

czyli 

określenie scenariuszy dla każdej z wymaganych do zaprezentowania funkcjonalności. 

Nie  sposób  nie  zauważyć,  że  powyższe  żądania,  poza  żądaniem  rezygnacji 

z wymagani

a  załączenia  do  oferty  próbki,  są  skrajnie  nieprecyzyjne.  Po  pierwsze  wskazać 

należy,  że  sformułowanie  „standardowe  funkcjonalności”  niczego  nie  określa.  Nie  istnieje 

bowiem  definicja,  obiektywny  zbiór  „standardowych  funkcjonalności"  systemów  informacji 

przestrzennej.  Wypełnienie  rzeczonego  żądania,  bez  określenia  konkretów  przez  samego 

Odwołującego, nie jest możliwe do spełnienia. Po wtóre, Odwołujący określił, że ewentualnie 

oczekuje określenia kryteriów demonstracji i scenariuszy testowych, bez bliższego określenia, 

co uniemożliwiło Zamawiającemu uwzględnienie odwołania w tej części. 

Na rozprawie strony podtrzymały zaprezentowaną powyżej argumentację. 

Zamawiający wniósł o dopuszczenie i przeprowadzenie dowodów z treści: 

1.  wniosku  o  dofinansowanie  realizacji  projektu 

pn.:  „Budowa  Mysłowickiej 

Infrastruktury Informacji Przestrzennej jako narzędzie zwiększenia zakresu i jakości 

usług świadczonych drogą elektroniczną z załącznikiem nr 3 w postaci dokumentacji 

technicznej o charakterze programu funkcjonalno-

użytkowego (dowód Z1); 

zestawienia wymogów dla przedmiotu zamówienia, sporządzonego według wzoru 

stanowiącego  załącznik  nr  3  do  formularza  ofertowego,  opatrzony  komentarzami 

Zamawiającego (dowód Z2). 

Po  przeprowadzeniu  rozprawy  Izba,  uwzględniając  zgromadzony  materiał 

dowodowy  omówiony  w  dalszej  części  uzasadnienia,  jak  również  biorąc  pod  uwagę 

oświadczenia  i  stanowiska  stron  zawarte  w  odwołaniu  i  odpowiedzi  na  odwołanie, 

a 

także  wyrażone  ustnie  na  rozprawie  i odnotowane  w protokole,  ustaliła  i  zważyła, 

co nas

tępuje. 

Skład  orzekający  stwierdził,  że  Odwołujący  jest  legitymowany,  zgodnie  z  przepisem 

art. 

179 ust. 1 Pzp, do wniesienia odwołania. 

Izba dopuściła i przeprowadziła dowody z treści SIWZ oraz dokumentów załączonych 

do  odwołania  i  przedstawionych  na  rozprawie  stwierdzając,  że  stan  faktyczny  sprawy 

(brzmienie kwestionowanych postanowień SIWZ) jest niesporny. 

Rozpoznając  sprawę  w  granicach  podniesionych  zarzutów  Izba  stwierdziła, 

że odwołanie  zasługuje  na  częściowe  uwzględnienie.  Odnosząc  się  kolejno  do  zarzutów 

i 

żądań odwołania skład orzekający przedstawia następujący pogląd w sprawie. 

Nie  znalazło  uznania  Izby  żądanie  nakazania  Zamawiającemu  usunięcia  z  SIWZ 

postanowień nakładających na wykonawców  wymóg złożenia wraz z ofertą próbki systemu 

i 

opisujących  procedurę  jej  weryfikacji.  Żądanie  to  zostało  postawione  w  związku 

z 

twierdzeniem  o  braku  precyzji  w  opisie  przedmiotu  zamówienia,  zaniechaniu  podania 

scenariuszy testowych próbki oraz nałożeniu wymogu dostarczenia w ramach próbki niemal 

gotowego  produktu.  Należy  jednak  zauważyć,  że  nawet  stwierdzenie  którejkolwiek  

z  ww.  okoliczności  nie  uzasadnia  jeszcze  całkowitej  rezygnacji  z  zakwestionowanego 

wymogu.  Żądanie  przez  zamawiających  próbek,  niezależnie  od  ich  charakteru  i  funkcji 

w 

danym postępowaniu (kwestia ta nie była przedmiotem zaskarżenia, wobec czego obszerna 

argumentacja Zamawiającego o istocie próbki w Postępowaniu była zbędna) jest powszechną 

praktyk

ą w zamówieniach publicznych. Próżno szukać w przepisach regulujących tę materię 

jakichkolwiek  wskazań  przemawiających  za  dopuszczalnością,  bądź  niedopuszczalnością 

możliwości zobowiązania wykonawcy do złożenia próbki. W konsekwencji nie sposób również 

twierdzić,  że  w  postępowaniach  mających  za  przedmiot  zamówienia  określone  rodzajowo 

roboty  budowlane,  dostawy  lub  usługi  istnieje  generalna  zasada,  czy  też  tendencja  do 

nie 

stawiania wykonawcom wymogu przedstawienia próbki. Stąd, dowód O2 pozbawiony był 

znaczenia dla sprawy. 

Skład orzekający nie podzielił również zapatrywań Odwołującego, jakoby Zamawiający 

dopuścił  się naruszenia przywołanych w  petitum  odwołania przepisów  także w  ten  sposób, 

że zobowiązał  wykonawców  do  przedstawienia  próbki  systemu  o  zaawansowanych, 

wykraczających poza typowe funkcjonalności, cechach. Przedstawiony w tym zakresie dowód 

O1 stanowi, w ocenie Izby, tylko jedno z możliwych podejść do tej kwestii, bowiem – co uznane 

zostało  za  okoliczność  kluczową  –  próżno  szukać  generalnych  zasad,  czy  prawidłowości 

dotyczących stopnia zaawansowania próbki, której załączenia do oferty zamawiający oczekuje 

od wykonawcy. Oznacza to, że próbka, w zależności od okoliczności, stanowić może zarówno 

gotowy, w pełni funkcjonalny wyrób, jak i jego prototyp. Tytułem przykładu wskazać można na 

zamówienia  na  dostawy  wyrobów  medycznych,  w  których  rolę  próbek  pełnią  wyroby, 

które następnie będą dostarczane w wykonaniu umowy w sprawie zamówienia publicznego. 

Co  do  zasady  inaczej  będzie  w  przypadku  zamówień  na  systemy  IT,  w  przypadku  których 

należy  raczej  liczyć  się  z  koniecznością  stworzenia  określonych  rozwiązań  od  nowa, 

względnie – przystosowania istniejących rozwiązań do specyficznych potrzeb zamawiającego. 

Niemniej  jednak,  nawet  w  takiej  sytuacji 

poszukiwanie  prawidłowości,  zgodnie  z  którymi 

określone  cechy  systemu  IT  uznawane  są  za  typowe,  a  tym  samym  –  mogące  podlegać 

badaniu  w  ramach  prezentacji  próbki,  a  inne  –  nie,  jest  nieuzasadnione.  W  tym  zakresie 

decydujące znaczenie ma stanowisko zamawiającego, jako odbiorcy i przyszłego użytkownika 

systemu, który decyduje na jakim poziomie szczegółowości chce zapoznać się z oferowanymi 

przez wykonawców rozwiązaniami. Ad casum Zamawiający objął wymogiem przygotowania 

w 

ramach próbki funkcjonalności ujęte w dokumentach aplikacyjnych, stanowiących dowody 

Z1  i  Z2,  co  przeczy  postawionej  przez  Odwołującego  tezie  o  przypadkowym, 

pozbawionym 

racjonalności,  doborze  funkcji  systemu,  które  będą  weryfikowane  w  toku 

prezentacji.  Ponadto,  biorąc  pod  uwagę  powyższe  oraz  twierdzenia  Odwołującego 

z 

odwołania i rozprawy, który wskazywał na konieczność poniesienia przez niego znacznych 

nakładów  czasowych  i  finansowych  celem  przygotowania  próbki  należy  powiedzieć, 

że Odwołujący  może  je  ująć  w  cenie  oferty.  Może  również  poddać  analizie  metodologię 

wykonywania zamówień tego typu, w poszukiwaniu rozwiązań bardziej efektywnych, skoro – 

jak sam stwierdził – nie ma „złotej” metody budowania systemów informatycznych. 

W konsekwencji orzeczono jak w pkt 2 sentencji wyroku.  

Na  uwzględnienie  zasługiwał  natomiast  zarzut  nieprecyzyjnego  opisania  przedmiotu 

zamówienia,  a  zarazem  –  zważywszy  na  konstrukcję  SIWZ  –  zasad  weryfikacji  zgodności 

próbki  z  wymogami  Zamawiającego.  Przy  czym,  wbrew  twierdzeniom  odwołania, 

Zamawiający opisał co i w jaki sposób będzie badał w toku prezentacji  – załącznik nr 9 do 

SIWZ  zawiera  bowiem  wyraźne  odesłanie  załącznika  nr  3  do  formularza  oferty  

(dalej:  „Lista  funkcjonalności”).  Okoliczność,  że Zamawiający  nie  przygotował  scenariuszy 

testowych w sposób zgodny z rozumieniem tego pojęcia przez Odwołującego (także bowiem 

w  tym  zakresie  nie  istnieją,  zdaniem  Izby,  jednolite,  wyłącznie  poprawne,  standardy, 

wobec 

czego  dowód  O3  nie mógł  stanowić  potwierdzenia  zasadności  omawianego  zarzutu 

odwołania,  jako  że  prezentuje  jedną  z  metod  podejścia  do  zagadnienia  badania  próbki) 

pozostaje 

bez 

znaczenia. 

Nie 

sposób 

nie 

zauważyć, 

że 

Odwołujący 

– 

zarzucając Zamawiającemu brak precyzji w określeniu scenariuszy testowych – powoływał się 

na  sytuacje,  w  których  funkcjonalności  próbki,  weryfikowane  w  toku  prezentacji, 

podlegały ocenie w  kryterium  pozacenowym  (zob.  dowód  O3).  Ad casum  sytuacja taka nie 

występuje,  wobec  czego  nie  było  potrzeby  nakazywania  Zamawiającemu  szczegółowego 

opisywania sposobów weryfikacji danej cechy zamawianego systemu, czy określenia metod 

dojścia  do  weryfikowanej  funkcjonalności,  do  czego  sprowadzały  się  oczekiwania 

Odwołującego. 

Powyższe  nie  oznacza  jednak  przyzwolenia  na  brak  precyzji  w  opisie  przedmiotu 

zamówienia, bowiem reguły, jakie nim rządzą (art. 29 ust. 1-3 Pzp) mają charakter uniwersalny 

–  nie  zależą  ani  od  rodzaju  przedmiotu  zamówienia,  ani  od  okoliczności,  czy  zamawiający 

żąda przedstawieniu mu próbki oraz jaki ma ona na gruncie postępowania charakter. 

Przy  czym,  nawiązując  do  argumentacji  Zamawiającego  o  konieczności  pominięcia 

zarzutów,  które  nie  zostały  w  odwołaniu  sprecyzowane  oraz  biorąc  pod  uwagę  treść 

odwołania, skład orzekający uznał, że Odwołujący zaskarżył w istocie 9 spośród 55 wymogów 

zawartych 

na  Liście  funkcjonalności.  Wyłącznie  w  powyższym  zakresie  Odwołujący 

przedstawił  bowiem  argumentację  uzasadniającą  naruszenie  przez  Zamawiającego 

wskazanych  w  odwołaniu  przepisów.  Odwołujący  wprawdzie  zaznaczył,  że  opisane 

w 

odwołaniu  naruszenia  mają  charakter  przykładowych,  tym  niemniej  ze  względu  na 

konieczność  ścisłego  interpretowania  zarzutów  odwołania,  mającą  źródło  w  art.  192  ust.  7 

Pzp, Izba nie może domniemywać niezgodności postanowień SIWZ z Pzp w niewskazanym 

wprost  w  odwołaniu  zakresie.  Co  zaś  dotyczy  twierdzenia  Zamawiającego,  jakoby  na 

przeszkodzie uwzględnieniu odwołania stały  pozbawione precyzji  w  sformułowaniu żądania 

odwołania, skład orzekający wyjaśnia, że z przywołanego przepisu art. 192 ust. 7 Pzp wynika 

związanie Izby zarzutami odwołania, nie zaś jego wnioskami. 

Mając  powyższe  na  względzie  Izba  uznała,  że  przywołane  w  pkt  1.1-1.9 

sentencji wyroku  postanowienia  z 

Listy  funkcjonalności  są  sformułowane  w  sposób 

niejednoznaczny i nieprecyzyjny, co godzi w obowiązki zamawiającego, wynikając z art. 29 

ust.  1  Pzp.  Izba  badając  tę  kwestię  zawsze  ma  na  względzie,  że  postanowienia  SIWZ 

kierowane  są  do  profesjonalistów,  zatem  mogą  odwoływać  się  do  specyficznych  pojęć, 

czy 

języka technicznego, tym niemniej bezwzględnie muszą być zrozumiałe, nawet przy tak 

określonym  adresacie.  Skład  orzekający  uznał,  że  w  zakresie  przywołanych  w  sentencji 

opisów  funkcjonalności  i  użytych  w  nim  pojęć  Zamawiający  nie  sprostał  temu  wymogowi, 

zaś ani w odpowiedzi na odwołanie, ani w czasie rozprawy, nie odniósł się do nich. Jedynie dla 

przykładu  skład  orzekający  zwraca  uwagę  na  wymaganie  2.1,  zgodnie  z  którym  moduł 

gospodarki odpadami musi udostępniać m.in. wybrane dokumenty dla firmy wywozowej. O ile 

wykonawca  powinien  mieć  świadomość,  że  system  informacji  przestrzennej  może 

przewidywać  taką  funkcjonalność  (Odwołujący  nie  przedstawił  Izbie  argumentów 

uzasadniających  tezę  przeciwną),  o  tyle  jej  sprecyzowanie  przez  wskazanie 

katalogu 

dokumentów, których możliwość udostępnienia uznana zostanie za spełnienie przez 

próbkę  wymogu  SIWZ,  obciąża  Zamawiającego.  Ma  to  tym  większe  znaczenie,  że  – 

jak 

zadeklarował  Zamawiający  –  próbki  będą  oceniane  w  formule  „spełnia  –  nie  spełnia”, 

zaś niepomyślny  dla  wykonawcy  przebieg  prezentacji  spowoduje  nie  tylko  odrzucenie  jego 

oferty na podstawie art. 89 ust. 1 pkt 2 Pzp, ale również wykluczenie z Postępowania w oparciu 

o art. 24 ust. 1 pkt 17 Pzp (zob. przykładowo pkt I.6 i I.7 załącznika nr 9 do SIWZ). 

Powyższej  oceny  nie  zmienia  dowód  Z2,  który  –  po  pierwsze  –  nie  odnosi  się  do 

wszystkich  kwestionowanych  w  odwołaniu  pozycji  Listy  funkcjonalności.  Po  drugie  – 

w 

zakresie w jakim odnosi się do przedmiotu sporu zawiera jedynie ogólnikowe spostrzeżenia 

o podstawowym charakterze danej funkcjonalności, czy o jej dostępności w oferowanych na 

rynku produktach od lat. 

Mając powyższe na uwadze Izba orzekła, jak w pkt 1 sentencji wyroku. 

O  kosztach  postępowania  odwoławczego  (pkt  3  sentencji  wyroku)  orzeczono 

stosownie do jego wyniku, na 

podstawie art. 192 ust. 9 i 10 Pzp oraz w oparciu o przepisy § 5 

ust. 

2  pkt  1  w  zw.  z  §  3  pkt  1  i  pkt  2  lit.  b  rozporządzenia  Prezesa  Rady  Ministrów  z  dnia 

15 marca  2010  r.  w 

sprawie  wysokości  i sposobu  pobierania  wpisu  od  odwołania  oraz 

rodzajów kosztów w postępowaniu odwoławczym i sposobu ich rozliczania (Dz.U.2010.41.238 

ze zm.).  

Przewodniczący:   ……………………………………….