rodzaj: WYROK
data dokumentu: 2018-02-26
rok: 2018
data dokumentu: 2018-02-26
rok: 2018
sygnatury akt.:
KIO 245/18
KIO 245/18
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,
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:
1.
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ń.
2.
Oddala odwołanie w pozostałym zakresie.
3.
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,
3.2.
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
2014-
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:
1.
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;
2.
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;
3.
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:
1.
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),
2.
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),
2.5.
Moduł musi umożliwiać indeksowanie i porządkowanie dokumentów oraz ich opisywanie
zestawem atrybutów (metadanych).
2.6.
Moduł musi udostępniać różne sposoby grupowania fizycznego (katalogi) dokumentów
przez administratora.
2.7.
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.
2.8.
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:
1.
przykładowego opisu funkcjonalności próbki (dowód O1);
2.
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);
3.
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);
2.
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: ……………………………………….
1.
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ń.
2.
Oddala odwołanie w pozostałym zakresie.
3.
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,
3.2.
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
2014-
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:
1.
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;
2.
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;
3.
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:
1.
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),
2.
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),
2.5.
Moduł musi umożliwiać indeksowanie i porządkowanie dokumentów oraz ich opisywanie
zestawem atrybutów (metadanych).
2.6.
Moduł musi udostępniać różne sposoby grupowania fizycznego (katalogi) dokumentów
przez administratora.
2.7.
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.
2.8.
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:
1.
przykładowego opisu funkcjonalności próbki (dowód O1);
2.
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);
3.
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);
2.
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: ……………………………………….
Wcześniejsze orzeczenia:
- Sygn. akt KIO 391/18 z dnia 2018-03-13
- Sygn. akt KIO 216/18 z dnia 2018-03-01
- Sygn. akt KIO 244/18 z dnia 2018-02-28
- Sygn. akt KIO 237/18 z dnia 2018-02-27
- Sygn. akt KIO 212/18 z dnia 2018-02-27
