KIO 245/18

Sygn. akt: KIO 245/18 WYROK z dnia 26 lutego 2018 r. Krajowa Izba Odwoławcza - w składzie: Przewodniczący: Daniel Konicz Protokolant: Marta Słoma po rozpoznaniu na rozprawie w dniu 22 lutego 2018 r. w Warszawie odwołania wniesionego do Prezesa Krajowej Izby Odwoławczej 9 lutego 2018 r. przez Odwołującego – Comarch Polska S.A. z siedzibą w Krakowie, w postępowaniu prowadzonym przez Zamawiającego – Gminę Miasto Mysłowice, orzeka: 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 demonstracji 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 funkcjonalnoś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 funkcjonalnoś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 wykazania 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, lecz 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 czasowego 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 flash), definiowanie przedziału czasowego wyświetlania danego dokumentu, 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. Jest 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. Przykł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 uprawnień […]”. 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. pkt 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 rodzaju 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 ogł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) – dowó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 jego 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 pakietów oprogramowania. Zamawiający stwierdził następnie, że zgodnie z wymogami Pzp ocena ofert dokonywana jest na podstawie oferty pisemnej. Wykonawca 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 parametrów, przy czym na etapie realizacji zamówienia nie uda mu się wytworzyć oprogramowania spełniającego wszystkie wymagania określone w Szczegółowym Opisie Przedmiotu Zamó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 Rozporzą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 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 Pzp. Zasady te znalazły odzwierciedlenie w załączniku nr 9 do SIWZ, zawierającym opis zasad przygotowania i przeprowadzenia demonstracji 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 warunkó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 wykonawcę 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 powodowałoby naruszenie uczciwej konkurencji, uniemożliwiając udział Postępowaniu wykonawcom, 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 funkcjonalnoś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 wykracza 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 wymagań 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 wymagania 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 nastę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: ……………………………………….