Wyrok KIO 1592/20 z 7 września 2020

1. Oddala odwołanie.
2. Kosztami postępowania obciąża Odwołującego - wykonawcę NTT Poland Sp. z o.o. z siedzibą w Warszawie i:
3. 1. zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000 zł 00 gr (słownie: piętnaście tysięcy złotych zero groszy) uiszczoną przez Odwołującego wykonawcę NTT Poland Sp. z o.o. z siedzibą w Warszawie tytułem wpisu od odwołania.

Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. - Prawo zamówień publicznych (t.j. Dz. U. z 2019 r. poz. 1843) 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 Warszawie.

Przewodniczący:

Sygn. akt

KIO 1592/20

Zamawiający - Komenda Główna Policji w Warszawie [dalej „Zamawiający”] prowadzi postępowanie o zawarcie umowy ramowej w trybie przetargu nieograniczonego pn. Zawarcie umowy ramowej na Modernizację Policyjnego Systemu Wideokonferencyjnego (PSW) w roku 2020 (znak postępowania: 53/BŁiI/20/AP/PMP).

Ogłoszenie o zamówieniu zostało opublikowane w Dzienniku Urzędowym Unii Europejskiej w dniu 8 maja 2020 r. pod numerem 2020/S 090-214265.

W dniu 13 lipca 2020 r. wykonawca NTT Poland Sp. z o.o. z siedzibą w Warszawie [dalej „Odwołujący”] wniósł odwołanie wobec zmian postanowień SIWZ wraz z załącznikami dokonanych poprzez udzielenie uczestnikom postępowania wyjaśnień treści SIWZ z dnia 2 lipca 2020 r. w następującym zakresie:

1. zarządzanie konfiguracją i aktualizacja oprogramowania terminali
2. pkt III Wymagania funkcjonalne i techniczne ppkt 1 - zarządzanie konfiguracją Załącznik nr 4 do SIWZ i odpowiedź Zamawiającego na pytanie nr 32 w zakresie zmiany treści SIWZ poprzez wprowadzenie wymogu, aby dostarczone terminale wideokonferencyjne umożliwiały konfigurację indywidualną (pojedynczo każdy z terminali) oraz konfigurację automatyczną z szablonów dostępnych na serwerze Poly Resource Manager, umożliwiały wykonanie zdalnej konfiguracji urządzeń za pomocą systemu Poly Resource Manager, z użyciem profili konfiguracji, które są szablonem ustawień dla wszystkich urządzeń w systemie, oraz aby w razie potrzeby zmiany konfiguracji na wszystkich urządzeniach w sieci modyfikacje były wprowadzone w szablonie na serwerze konfiguracji, a następnie zaprogramowane na wszystkie wideoterminale;
3. pkt V Specyfikacja techniczna dla terminali wideokonferencyjnych ppkt 1 Terminal typu A1 Lp. 11, ppkt 2 Terminal typu A2 Lp. 10, ppkt 3 Terminal typu B Lp. 10, ppkt 4 Terminal typu C Lp. 10 - zachowanie pełnej zgodności w zakresie zdalnej aktualizacji oprogramowania Załącznik nr 4 do SIWZ i odpowiedź Zamawiającego na pytanie nr 36 w zakresie zmiany treści SIWZ poprzez wprowadzenie wymogu, aby aktualizacja oprogramowania dostarczonych terminali wideokonferencyjnych była możliwa do wykonania automatycznie z poziomu serwera Poly Resource Manager i niedopuszczenia możliwości aktualizacji oprogramowania dostarczonych terminali wideokonferencyjnych z innych serwerów; zarzucając naruszenie:
4. art. 29 ust. 1 ustawy Pzp poprzez opisanie przedmiotu zamówienia w sposób nieproporcjonalny, nieuzasadniony potrzebami Zamawiającego oraz nieuwzględniający wszystkich okoliczności faktycznych mających wpływ na realizację zamówienia, poprzez postawienie wyżej wymienionego wymagania, podczas gdy jest ono nadmiarowe i zbędne, gdyż możliwe jest zapewnienie kompatybilności rozwiązania i zrealizowane wyżej wskazanych funkcjonalności w inny sposób w szczególności poprzez dostarczenie odpowiedniego oprogramowania;
5. art. 29 ust. 2 w zw. z art. 7 ust. 1 ustawy Pzp poprzez opisanie przedmiotu zamówienia w sposób uniemożliwiający uczciwą konkurencję i naruszający zasadę równego traktowania wykonawców, poprzez postawienie wyżej wymienionych wymagań, podczas gdy oznacza to dopuszczenie do udziału w postępowaniu tylko jednego producenta lub zmusza wykonawców do dostarczenia rozwiązania tylko jednego producenta Poly, stawiając powyższe zarzuty wniósł o nakazanie Zamawiającemu:
6. modyfikacji treści SIWZ poprzez dopuszczenie możliwości zapewnienia funkcjonalności w zakresie zarządzania konfiguracją terminali i aktualizacji oprogramowania terminali przez oprogramowanie dostarczone przez wykonawcę;
7. modyfikacji treści SIWZ poprzez usunięcie zastrzeżenia, że funkcjonalności w zakresie zarządzania konfiguracją terminali i aktualizacji oprogramowania terminali nie mogą zostać zapewnione z poziomu innych serwerów (innego oprogramowania) niż Poly Resource Manager.
8. rejestracja do systemu pkt V Specyfikacja techniczna dla terminali wideokonferencyjnych ppkt 1 Terminal typu A1 Lp. 11, ppkt 2 Terminal typu A2 Lp. 10, ppkt 3 Terminal typu B Lp. 10, ppkt 4 Terminal typu C Lp. 10 - rejestracja do systemu Załącznik nr 4 do SIWZ i odpowiedź na pytanie nr 37 w zakresie zmiany treści SIWZ poprzez wprowadzenie wymogu, aby rejestracja urządzenia odbywała się poprzez nawiązanie połączenia z serwerem provisioningu (Poly Resource Manager), gdzie następuje autoryzacja za pośrednictwem kont domenowych, a w wyniku poprawnej autoryzacji pobierany był szablon konfiguracji z Poly Resource Manager, który

zawiera m.in. adres serwera SIP oraz H.323 do którego rejestruje się urządzenie zarzucając naruszenie:

1. art. 29 ust. 1 i 2 w zw. z art. 7 ust. 1 ustawy Pzp poprzez opisanie przedmiotu zamówienia w sposób nieproporcjonalny, nieuzasadniony potrzebami Zamawiającego, nieuwzględniający wszystkich okoliczności faktycznych mających wpływ na realizację zamówienia oraz uniemożliwiający uczciwą konkurencję i naruszający zasadę równego traktowania wykonawców, poprzez postawienie wyżej wymienionego wymagania, podczas gdy potrzeby Zamawiającego mogą zostać spełnione w odmienny sposób bez zastosowania specyficznego sposobu rejestracji terminala do systemu właściwego tylko dla jednego producenta, a określenie powyższego wymagania nie znajduje uzasadnienia merytorycznego ani funkcjonalnego, lecz stanowi jedynie ograniczenie konkurencji poprzez dopuszczenie do udziału w postępowaniu tylko jednego producenta lub zmuszenia wykonawców do zastosowania rozwiązania stosowanego tylko przez jednego producenta Poly,
2. art. 29 ust. 2 w zw. z art. 7 ust. 1 ustawy Pzp poprzez opisanie przedmiotu zamówienia w sposób uniemożliwiający uczciwą konkurencję i naruszający zasadę równego traktowania wykonawców, poprzez postawienie wyżej wymienionego wymagania, podczas gdy oznacza to dopuszczenie do udziału w postępowaniu tylko jednego producenta lub zmusza wykonawców do dostarczenia rozwiązania tylko jednego producenta Poly, stawiając powyższe zarzuty wniósł o nakazanie Zamawiającemu:
3. modyfikacji treści SIWZ poprzez usunięcie wymagania, aby funkcjonalność w zakresie rejestracji terminala do systemu wykonawca miał zapewnić poprzez nawiązanie połączenia z serwerem provisioningu (Poly Resource Manager), gdzie następuje autoryzacja za pośrednictwem kont domenowych, a w wyniku poprawnej autoryzacji pobierany był szablon konfiguracji z Poly Resource Manager, który zawiera m.in. adres serwera SIP oraz H.323 do którego rejestruje się urządzenie.

W uzasadnieniu odwołania Odwołujący w zakresie zarzutu dotyczącego zarządzania konfiguracją i aktualizacją oprogramowania terminali wskazał, że dnia 2 Iipca 2020 r.

Zamawiający udzielił wyjaśnień do treści SIWZ dokonując jednocześnie zmiany wymagań co do zarządzania konfiguracją terminali wideokonferencyjnych oraz aktualizacji oprogramowania terminali.

W pierwotnej wersji SIWZ Zamawiający w pkt III Wymagania funkcjonalne i techniczne ppkt 1 Załącznik nr 4 do SIWZ wskazał, że „Dostarczone terminale i serwery wideokonferencyjne muszą być kompatybilne z systemem wideokonferencyjnym Zamawiającego w zakresie co najmniej: zarządzania urządzeniami, zarządzania użytkownikami, zarządzania połączeniami, zarządzania zasobami licencyjnymi, zarządzania konfiguracją, planowania wideokonferencji, monitorowania parametrów połączeń, parametrów pracy terminali i serwerów”. W pkt V Specyfikacja techniczna dla terminali wideokonferencyjnych ppkt 1 Terminal typu A1 Lp. 11, ppkt 2 Terminal typu A2 Lp. 10, ppkt 3 Terminal typu B Lp. 10, ppkt 4 Terminal typu C Lp. 10 Załącznik nr 4 do SIWZ Zamawiający w stosunku do wszystkich typów terminali wymagał „możliwości uruchomienia, połączenia i realizacji wszystkich funkcjonalności w środowisku systemu wideokonferencyjnego firmy Poly z zachowaniem pełnej zgodności w zakresie rejestracji do systemu, zdalnej aktualizacji oprogramowania”.

Udzielając odpowiedzi na pytanie nr 32 sformułował w zakresie konfiguracji terminali wideokonferencyjnych konkretne dodatkowe wymagania, tj. aby dostarczone terminale wideokonferencyjne umożliwiały konfigurację indywidualną (pojedynczo każdy z terminali) oraz konfigurację automatyczną z szablonów dostępnych na serwerze Poly Resource Manager, umożliwiały wykonanie zdalnej konfiguracji urządzeń za pomocą systemu Poly Resource Manager, z użyciem profili konfiguracji, które są szablonem ustawień dla wszystkich urządzeń w systemie, oraz aby w razie potrzeby zmiany konfiguracji na wszystkich urządzeniach w sieci modyfikacje były wprowadzone w szablonie na serwerze konfiguracji, a następnie zaprogramowane na wszystkie wideoterminale.

Natomiast w wyniku odpowiedzi na pytanie nr 36 wprowadził nowe wymaganie w zakresie aktualizacji oprogramowania terminali, tj. aby aktualizacja oprogramowania dostarczonych terminali wideokonferencyjnych była możliwa do wykonania automatycznie z poziomu konkretnego serwera Poly Resource Manager oraz nie dopuścił możliwości aktualizacji oprogramowania dostarczonych terminali wideokonferencyjnych z innych serwerów (innego oprogramowania).

Odwołujący uzasadniał, że powyższe wymagania nie zostały wskazane ani nawet nie wynikały z pierwotnej treści SIWZ. Do dnia udzielenia wyjaśnień SIWZ wymagania te ograniczały się jedynie do zastrzeżenia, że terminale mają być „kompatybilne z systemem wideokonferencyjnym Zamawiającego w zakresie m.in. zarządzania konfiguracją” oraz zapewnione mają być „funkcjonalności w środowisku systemu wideokonferencyjnego firmy Poly z zachowaniem pełnej zgodności w zakresie (...) zdalnej aktualizacji oprogramowania.”

Rozwiązanie innego producenta, które zamierzał zaoferować Odwołujący spełniało w tym zakresie wymagania SIWZ, zgodnie z dokumentacją producenta Poly znajdującą się na stronie Odwołujący wskazał, że z informacji tam zawartych jednoznacznie wynika, jakie rozwiązania wspiera producent Poly, tj. urządzenia jakich producentów i w jakim zakresie są kompatybilne/zgodne z oferowanym przez niego rozwiązaniem. Zgodnie z przytoczoną dokumentacją, producent systemu Poly Resource Manager (str. 242) wskazuje urządzenia firm trzecich oraz zakres funkcjonalności dla nich oferowany. W szczególności wskazuje że terminale Cisco są kompatybilne z oprogramowaniem Poly Resource Manager z wykorzystaniem funkcjonalności Scheduled Management (Zarządzanie Zaplanowane), które umożliwia w określonym przez producenta Poly zakresie zarządzanie konfiguracją jak i zdalną aktualizację oprogramowania dla tych urządzeń.

Dopiero z wyjaśnień treści SIWZ Odwołujący uzyskał informację, że funkcjonalności w postaci zarządzania konfiguracją terminali i aktualizacja oprogramowania terminali ma się odbywać w określony sposób z użyciem profili konfiguracji czyli z wykorzystaniem funkcjonalności Dynamic Management (Zarządzanie Dynamiczne) (str. 287-289), specyficznej dla producenta Poly (z poziomu obecnie dostępnego u siebie oprogramowania), a dodatkowo nawet gdyby wykonawca był w stanie zrealizować te funkcjonalności w oparciu o rozwiązania innego producenta to Zamawiający zastrzegł, że nie dopuszcza możliwości realizacji tych funkcjonalności z innych serwerów niż Poly Resource Manager. Odwołujący nie ma zatem możliwości dostarczenia do terminali innego oprogramowania, pomimo, że za pomocą odpowiedniego oprogramowania zrealizowałoby wskazane przez Zamawiającego funkcjonalności i osiągnąłby ten sam efekt.

Odwołujący uzasadniał, że współpraca rozwiązań producenta Poly w pewnych obszarach jest możliwa z systemami innych producentów, jednak są także obszary gdzie rozwiązania producenta Poly są zgodne wyłącznie z rozwiązaniami oferowanymi przez tego producenta. Jednakże, w zakresie opisanych wymagań, które wskazał Zamawiający można te funkcjonalności, zrealizować poprzez dostarczenie odpowiedniego oprogramowania do terminali. W praktyce wymagana nowa funkcjonalność w ramach zarządzania konfiguracją wygląda w ten sposób, że zostaje przygotowany szablon konfiguracji terminali, w którym dokonuje się zmian, aby następnie można było zmienić automatycznie konfigurację wszystkich terminali zarejestrowanych w systemie Zamawiającego. Zamawiający opisał tę funkcjonalność dokładnie tak jak działa w systemie producenta Poly.

Aby zapewnić taką funkcjonalność w ramach zarządzania konfiguracją terminali, nie wykorzystując Poly Resource Manager, wystarczającym jest zapewnienie odpowiedniego oprogramowania do obsługi każdego z dostarczonych terminali (tj. Cisco Telepresence Management Suite), który umożliwia taką automatyczną konfigurację. Takie rozwiązanie nie zostało jednak dopuszczone przez Zamawiającego. Funkcjonalność w postaci zdalnej aktualizacji oprogramowania terminala także można zapewnić poprzez dostarczenie odpowiedniego oprogramowania do terminali, bez potrzeby wykorzystania Poly Resource Manager.

Co prawda, Zamawiający w odpowiedzi na pytanie 32 nie zastrzegł wprost, że nie zezwala na wykorzystanie innych serwerów (innego oprogramowania), w celu realizacji funkcjonalności zarządzania konfiguracją w określony sposób, ale zastrzeżenie braku możliwości zastosowania innego oprogramowania, wskazana wprost w odpowiedzi na pytanie nr 36 ma bezpośredni wpływ także na realizację tej funkcjonalności. Aktualizacja oprogramowania oznacza także konfigurację terminala (tj. zarządzanie konfiguracją terminali), a zatem brak możliwości wykorzystania innego oprogramowania także w tym zakresie.

Dodatkowo Odwołujący wskazał, że wymagany przez Zamawiającego sposób realizacji funkcjonalności w kontekście całego przedmiotu zamówienia nie ma kluczowego znaczenia dla działania systemu wideokonferencyjnego, tj. tego czy realizacja konfiguracji i aktualizacji oprogramowania odbywa się przy wykorzystaniu serwera Poly Resource Manager czy innego oprogramowania. Funkcjonalności wymagane przez Zamawiającego mają jedynie charakter administracyjny. Z wiedzy i doświadczenia Odwołującego wynika, że konfiguracja czy aktualizacja oprogramowania terminali są czynnościami wykonywanymi nie częściej niż raz lub dwa razy w roku. Nadto, Zamawiający w niniejszym postępowaniu wymaga dostarczenia ponad 413 sztuk terminali, a poprzednio zakupił jedynie 57 sztuk (Przetarg nieograniczony pn. „Modernizacja Systemu Wideokonferencyjnego w ramach

Programu Modernizacji Policji w latach 2017-2020, sprawa numer 174/BUI/19RG/PMP). Co oznacza, że obecnie wymaga dostarczenia znaczniej większej liczby terminali 1 dostosowania ich do niewielkiej liczby już posiadanych terminali działających w oparciu o Poly Resource Manager, mimo, że Odwołujący jest w stanie zapewnić mu rozwiązanie, w którym wszystkie dostarczone terminale (ponad 413 sztuk) z innym oprogramowaniem będą kompatybilne ze sobą oraz z systemem Poly w wymaganym przez Zamawiającego zakresie. Co więcej, zgodnie z treścią SIWZ Odwołujący ma obowiązek zapewnić Zamawiającemu warsztaty (szkolenia), podczas których uczestnicy uzyskają konkretne informacje i instrukcje w jak prosty sposób mogą dokonywać konfiguracji lub aktualizacji oprogramowania terminali.

Dla Odwołującego w pełni zrozumiałe jest, iż Zamawiający chce w wyniku zamówienia uzyskać system w pełni kompatybilny i zapewniający niezakłóconą współpracę między urządzeniami tworzącymi ten system. Jednakże wymagania postawione przez Zamawiającego w zakresie zarządzania konfiguracją i aktualizacji oprogramowania terminali zostały rozszerzone w zakresie zupełnie zbędnym z punktu widzenia zapewnienia prawidłowego działania całego systemu wideokonferencyjnego. Wymaganie w tym zakresie nie ma żadnego uzasadnienia merytorycznego, ani funkcjonalnego, a jedynie potwierdza, że Zamawiający w sposób niezgodny z zasadami ustawy PZP wskazuje na rozwiązanie jednego preferowanego przez siebie producenta Poly.

Z przedstawionej argumentacji wynika, że Zamawiający wskazał nie tylko konkretny, specyficzny dla jednego producenta wymóg w postaci sposobu zarządzania konfiguracją terminala i aktualizację oprogramowania terminala, ale także bezzasadnie nie dopuścił możliwości realizacji tych wymagań w odmienny sposób, poprzez dostarczenie innego oprogramowania, za pomocą którego osiągnąłby ten sam efekt. Zarzuty w tym zakresie wskazane przez Odwołującego są zatem w pełni uzasadnione Odwołujący w zakresie zarzutu dotyczącego rejestracji do systemu wskazał, że dnia 2 lipca 2020 r. Zamawiający dokonał także zmiany treści SIWZ w zakresie wymagań dotyczących rejestracji do systemu przez wszystkie typy dostarczonych terminali wideokonferencyjnych. Odwołujący przywołał brzmienie pkt V Specyfikacji technicznej dla terminali wideokonferencyjnych ppkt 1 Terminal typu A1 Lp. 11, ppkt 2 Terminal typu A2 Lp.

10, ppkt 3 Terminal typu B Lp. 10, ppkt 4 Terminal typu C Lp. 10 Załącznik nr 4 do SIWZ.

Zamawiający odpowiadając na pytanie nr 37 wprowadził w zakresie rejestracji do systemu przez terminale dodatkowe wymaganie, aby rejestracja urządzenia odbywała się poprzez nawiązanie połączenia z serwerem provisioningu (Poly Resource Manager), gdzie następuje autoryzacja za pośrednictwem kont domenowych, a w wyniku poprawnej autoryzacji pobierany był szablon konfiguracji z Poly Resource Manager, który zawiera m.in. adres serwera SIP oraz H.323, do którego rejestruje się urządzenie. Jest to sposób właściwy jedynie dla producenta Poly. Powyższe wymaganie nie zostało wskazane ani nie wynikało z pierwotnej treści SIWZ. Do dnia udzielenia wyjaśnień SIWZ wymaganie w zakresie rejestracji terminali do systemu ograniczało się jedynie do zastrzeżenia, że zapewnione mają być „funkcjonalności w środowisku systemu wideokonferencyjnego firmy Poly z zachowaniem pełnej zgodności w zakresie rejestracji do systemu”. Do momentu zmiany treści SIWZ Odwołujący zamierzał zatem zaoferować rozwiązanie, które zapewniało realizację wymagania wskazanego w SIWZ w zakresie rejestracji terminala do systemu, tj.

„w środowisku systemu wideokonferencyjnego firmy Poly z zachowaniem pełnej zgodności”.

Uzasadniał, że z wiedzy i doświadczenia Odwołującego wynika, że „provisioning” jest to określenie procesu przygotowania terminala do funkcjonowania, pierwszego uruchomienia (uruchomienie, konfiguracja, rejestracja). Nie jest to zatem funkcjonalność kluczowa dla działania terminala. Celem wykonania takiej czynności jest to, aby terminal zadziałał, tj. połączył się prawidłowo z systemem (odnalazł inne urządzenia, „wiedział” w jaki sposób ma się zalogować, jaką ma konfigurację). Tak jak w przypadku funkcjonalności w postaci zarządzania konfiguracją i aktualizacją oprogramowania terminali, pierwsza rejestracja terminala do systemu jest czynnością typowo administracyjną. Dodatkowo wykonywaną przeważnie jednorazowo, w momencie uruchomienia terminala i jego pierwszego przyłączenia do systemu lub wyjątkowo w przypadku rekonfiguracji (przebudowy) całego systemu (co zdarza się niezwykle rzadko).

Sposób pierwszej rejestracji terminala do systemu opisany przez Zamawiającego w odpowiedzi na pytanie nr 37, zgodnie z dokumentacją producenta oprogramowania Poly Resource Manager określony jest jako Dynamic Provisioning (Dynamiczne Pierwsze Uruchomienie) i jest charakterystyczny jedynie dla producenta Poly (Poly RealPresence Resource Manager System str. 371 - Załącznik nr 1).

Zamawiający wskazał, jak ma dokładnie przebiegać proces pierwszej rejestracji terminala w systemie, w sytuacji, gdy wykonanie tej czynności w określony sposób nie ma

żadnego uzasadnienia merytorycznego i funkcjonalnego, w szczególności wymóg autoryzacji za pomocą kont domenowych, którego wcześniej Zamawiający nie wskazał w SIWZ.

Każdy terminal (tj. urządzenie końcowe) standardowo w swojej konfiguracji musi mieć wpisane dane konieczne do prawidłowej pracy w systemie (ustawienia SIP). W praktyce wystarczającym jest, aby w trakcie uruchomienia tego terminala, przed przyłączeniem go do systemu wpisać określone parametry i dane wskazane przez Zamawiającego. Po zakończeniu tego procesu terminal podłącza się automatycznie do systemu i wykorzystuje do pracy serwer rejestracji (Gatekeeper), który zarządza terminalami (przysyła informacje) i zapewnia odpowiednią kompatybilność rozwiązania w zakresie wymaganym uprzednio przez Zamawiającego. Efekt końcowy będzie zatem taki sam jak w przypadku dokonania pierwszej rejestracji terminala do systemu w sposób właściwy dla producenta Poly. Zgodnie z dokumentacją określony sposób rejestracji do systemu (dynamic provisioning) może działać tylko w przypadku korzystania z zarządzania dynamicznego, czyli tylko w przypadku rozwiązania producenta Poly (terminali - urządzeń końcowych Polycom), bowiem dokonując zmiany treści SIWZ Zamawiający wskazał, że nie jest możliwe wykorzystanie zarządzania zaplanowanego (zaplanowanych profili konfiguracji), które to rozwiązanie było możliwe do zaoferowania zgodnie z pierwotną treścią SIWZ.

Dodatkowo Odwołujący zaznaczył, że sposób uruchomienia i pierwszej rejestracji terminala do systemu ma dla Zamawiającego marginalne znaczenie, bowiem zgodnie z zasadami odbioru przedmiotu umowy (Załącznik nr 2 do Umowy wykonawczej) to wykonawca dokonuje montażu, uruchomienia i konfiguracji terminali w określonym terminie na podstawie udostępnionych mu przez Zamawiającego danych. Zupełnie nieuzasadnione i niecelowe jest zatem stawianie wymogu w zakresie konkretnego sposobu pierwszej rejestracji terminala skoro tak naprawdę jedyne czego Zamawiający powinien wymagać w tym zakresie to zapewniania prawidłowej rejestracji terminala do systemu.

Zamawiający w odpowiedzi na odwołanie z dnia 2 września 2020 r. wniósł o oddalenie odwołania w całości.

Zamawiający wskazał, że w odpowiedziach na pytania nr 32, 36 i 37 z dnia 2 lipca 2020 r. nie zostały poruszone żadne inne kwestie poza występującymi w pytaniach i stanowią jedynie wyjaśnienie zagadnień poruszonych w pytaniach. W żaden sposób nie poszerzają ani nie ograniczają one już wcześniej sformułowanych wymagań a wręcz bezpośrednio wynikają z pierwotnej treści SWIZ, odnosząc się bezpośrednio do tych funkcjonalności systemu używanego przez Zamawiającego, które są wykorzystywane w codziennej pracy. Ponadto zawierają funkcjonalności opisane w dokumencie „Operation Guide Polycom RealPresence Resource Manager System” dla wersji oprogramowania 10.8, który Odwołujący sam przywołuje w uzasadnieniu. Zamawiający wskazał, iż wymagania zostały jedynie doprecyzowane w zakresie w jakim sformułowane zostało pytanie i dotyczą funkcjonalności zarządzania konfiguracją, która od początku znajduje się w SIWZ (załącznik nr 4 do SIWZ pkt III Wymagania funkcjonalne i techniczne ppkt 1 oraz pkt V specyfikacja techniczna dla terminali wideokonferencyjnych, w tym terminal A1 lp. 11, A2 lp. 10, B lp.10, C lp. 10). Zdaniem Zamawiającego Odwołujący nie mógł twierdzić, że odpowiedź na pytania 32, 36 i 37, która jest jedynie bardziej szczegółowym wyjaśnieniem funkcjonalności dotyczących zarządzania konfiguracją, w tym konfiguracją terminali, aktualizacją ich oprogramowania, rejestracją do systemu jest zmianą SIWZ, bo były one opisane wcześniej w SIWZ z zastrzeżeniem pełnej kompatybilności z systemem już działającym u Zamawiającego. Ponadto zgodnie z dokumentacją systemu w żaden sposób nie wykraczają poza funkcjonalności serwerów Zamawiającego, a więc odpowiedzi na pytania są w pełni zgodne z podstawowym warunkiem kompatybilności, a Odwołujący nie mógł pominąć tych funkcjonalności przy przygotowaniu oferty. W przeciwnym wypadku jego oferta i tak została by odrzucona.

Zamawiający wskazał, iż w części odpowiedzi na pytanie 32 dotyczącej możliwości konfiguracji automatycznej z szablonów dostępnych na serwerze Poly Resource Manager oraz możliwości wykonania zdalnej konfiguracji urządzeń za pomocą systemu Poly Resource Manager z użyciem profili konfiguracji, które są szablonem ustawień dla wszystkich urządzeń w systemie ... również nie można twierdzić, że jest to zmiana wymagań. Pierwotne wymagania określone w Załączniku nr 4 do SIWZ pkt I Wymagania funkcjonalne i techniczne pkt 1 wskazywały, że „Dostarczone terminale i serwery wideokonferencyjne muszą być kompatybilne z systemem wideokonferencyjnym Zamawiającego w zakresie co najmniej: ., zarządzania konfiguracją.”. Odwołujący nie może traktować tych wymagań jedynie jako „zastrzeżenia”, bo są to konkretne wymagania, których nie może ani lekceważyć ani pomijać przy składaniu oferty. Dodając do tego dane zawarte w Załączniku nr 4 do SIWZ pkt II Warunki realizacji Umowy pkt 1, gdzie zawarta jest informacja o serwerach jakie posiada Zamawiający, m.in. Polycom Real Presence Resource Manager, jak również informacje zawarte w Załączniku nr 4 do SIWZ, pkt V, gdzie znajduje się wymóg zachowania pełnej

zgodności dostarczonego terminala w środowisku systemu wideokonferencyjnego firmy Poly (dawniej Polycom) w zakresie „zdalnej aktualizacji oprogramowania”, zmusza do wnioskowania, że konfiguracja automatyczna i zdalna z szablonów dostępnych na serwerze Poly Resource Manager, to tylko jeden z elementów kompatybilności z systemem wideokonferencyjnym Zamawiającego w zakresie zdalnej aktualizacji oprogramowania. To kolejne z podstawowych i koniecznych funkcjonalności w zakresie zarządzania konfiguracją, które w istotny sposób ograniczają ilość czynności wymaganych do wykonania przez administratora systemu, a wynikają wprost z dokumentacji systemu w szczególności serwera RealPresence Resource Manager. Dokument, o którym mowa powyżej zawiera m.in. cały dział VII ang. „Dynamic Management” dotyczący Zarządzania Dynamicznego, w tym funkcjonalność konfiguracji automatycznej (zdalnej) z szablonów dostępnych na serwerze Poly Resource Manager. Jeżeli zatem, oferowany system miałby być zgodny z wymaganiami określonymi pierwotnie w Załączniku nr 4 do SIWZ pkt III Wymagania funkcjonalne i techniczne pkt I wskazywały, że „Dostarczone terminale i serwery wideokonferencyjne muszą być kompatybilne z systemem wideokonferencyjnym Zamawiającego w zakresie co najmniej: zarządzania konfiguracją” oferent nie może pominąć funkcjonalności konfiguracji dynamicznej. Zamawiający wskazał, iż wbrew temu co twierdzi Odwołujący jest to funkcjonalność dostępna dla urządzeń innych producentów, co wskazuje dokumentacja serwera Poly Resource Manager. W systemie RealPresence Resource Manager można skonfigurować dynamiczne udostępnianie ustawień SIP dla następujących serwerów, m.in.

SIP Cisco Unified Communications Manager.

W części dotyczącej odpowiedzi na pytanie 36 dotyczącej automatycznej aktualizacji oprogramowania dostarczonych terminali wideokonferencyjnych z poziomu serwera Poly Zamawiający wskazał, w szczególności na stronę 292 producenta systemu, gdzie znajduje się wymaganie producenta, aby „wszystkimi urządzeniami końcowymi zarządzał jednolity system zarządzania”. Ponieważ Zamawiający dysponuje tylko serwerami Poly Resource Manager jest zmuszony do dostosowania się do tych wymagań.

Odnośnie wyjaśnień treści SIWZ w zakresie pytania nr 37 Zamawiający wskazał, że jeżeli Zamawiający wskazuje jakim konkretnie środowiskiem, serwerem dysponuje, oraz wymaga realizacji wszystkich funkcjonalności w zakresie rejestracji do systemu, to Odwołujący nie może twierdzić, że nie był świadomy wymagania dotyczącego rejestracji do systemu z wykorzystaniem funkcji provisioningu. Nie może też twierdzić, że nie znał takiej funkcjonalności bo to podstawowa funkcja zarządzania terminalami stosowana powszechnie nie tylko w systemach Poly, ale też innych producentów. Odwołujący nie może twierdzić, że odpowiedzi na pytania zmieniają jego sytuację poprzez „zmianę” SIWZ, ponieważ zarówno przed jak i po udzieleniu odpowiedzi/wyjaśnień musiał uwzględniać w ofercie wszystkie funkcjonalności w zakresie kompatybilności z systemem Zamawiającego. Musiał je również znać, skoro odwołuje się dokumentacji jednego z serwerów. Nie może więc twierdzić, że chciał spełniać wymagania w zakresie zarządzania planowanego a zarządzania dynamicznego już nie.

Zdaniem Zamawiającego Odwołujący nie mógł zastosować rozwiązania Cisco Telepresence Management Suite (TMS) na żadnym etapie postępowania, ponieważ jest to rozwiązanie dostępne jedynie w wersji zwirtualizowanej w oparciu o rozwiązanie Vmware, co wyklucza dostarczenie tego typu rozwiązania. SIWZ w punkcie IV. 2 wyłącza możliwość stosowania rozwiązania opartego na środowisku wirtualnym, gdyż takim środowiskiem nie dysponuje, a zapis wyłączający takie rozwiązanie nie był i nie jest objęty zastrzeżeniami Odwołującego.

Ponadto odnośnie twierdzeń Odwołującego zawartych w punkcie 2.4 Zamawiający wskazał, że Odwołujący nie przedstawił wiarygodnych informacji o jakie rozwiązanie chodzi.

Można domniemać, że chodzi o rozwiązanie Cisco Telepresence Management Suite (TMS), które jak wykazano wyżej nie mogło być zastosowane. Dostarczenie oprogramowania dedykowanego do środowiska, którym dysponuje Zamawiający również nie może być brane pod uwagę ze względu na to, że jest ono objęte gwarancją producenta, co nie pozwala na ingerencję w oprogramowanie systemowe.

Zamawiający uzasadniał, że Odwołujący nie wykazał naruszenia art. 29 ust. 1 ustawy Pzp oraz art. 29 ust. 2 w zw. z art. 7 ust. 1 ustawy Pzp, ponieważ wymagania SIWZ wynikają wprost z faktycznej sytuacji Zamawiającego, a w szczególności z doświadczenia i wiedzy zdobytej w trakcie administrowania systemem wideokonferencyjnym, zbudowanym w ramach projektu „Modernizacja Policyjnego Systemu Wideokonferencyjnego w ramach Programu Modernizacji Policji w latach 2017-2020” - nr postepowania przetargowego 174/BŁiI/19/RG/PMP. Doświadczenia te oraz specyficzny sposób realizacji wideokonferencji w pełni uzasadnia zapisy SIWZ. Zamawiający wskazał na tezy wynikające z wyroku KIO sygn. akt: KIO 1645/19 dotyczące sposobu opisania przedmiotu zamówienia. Wskazał, że istotne znaczenie ma również fakt otwarcia ofert w toczącym się postępowaniu przetargowym, gdzie złożone zostały 2 oferty, co zaprzecza tezie o braku konkurencyjności.

Odnośnie uzasadnienia potrzeb Zamawiającego w opisaniu przedmiotu zamówienia w sposób wskazany w SIWZ Zamawiający podał, że jego celem jest podpisanie umowy/umów ramowych na modernizację istniejącego systemu poprzez dostawę urządzeń końcowych tzw. terminali wideokonferencyjnych oraz urządzeń poszerzających możliwości systemu w zakresie ilości jednoczesnych połączeń. Zamawiający nie jest w stanie określić w ilu etapach, tzn. w ramach ilu umów wykonawczych będzie dostarczany przedmiot zamówienia. Dlatego Zamawiający nie zakładał budowy dodatkowej infrastruktury serwerowej.

Zamawiający wskazał, że system wideokonferencyjny Policji nie jest wykorzystywany w standardowy sposób pozostawiający dużą dowolność i samodzielność użytkownikom.

Zaznaczył, że jest systemem wydzielonym w wewnętrznej sieci Policji z bardzo ograniczonym i kontrolowanym dostępem z sieci publicznych oraz kontrolowaną organizacją spotkań. Zespól administrujący systemem Komendy Głównej Policji jest odpowiedzialny za przygotowanie i realizację połączeń jak również administrowanie systemem wideokonferencyjnym i posiada 10 letnie doświadczenie w zarządzaniu systemem Poly, dzięki czemu możliwa jest realizacja wideokonferencji, które bardzo często są realizowane w sytuacjach kryzysowych z minimalnym wyprzedzeniem czasowym. Jest to jedna z bezpośrednich przyczyn konieczności utrzymywania jednolitej architektury zarządzania terminalami. Administratorzy systemu bezpośrednio nadzorują każde spotkanie, nie tylko pod kątem poprawności parametrów komunikacji, ale też uprawnień do udziału w spotkaniach. Zamawiający ma prawo a nawet obowiązek formułować SIWZ w sposób, który usprawnia wykonywanie jego zadań a nie dostosowanie się do oczekiwań oferentów.

Zamawiający uzasadniał, że system jest „rozpięty” na terenie całego kraju i służy do realizowania zadań przez komórki i jednostki organizacyjne Policji do poziomu Komendy Powiatowej Policji, ale też ze względu na powyższe właśnie cechy jest wykorzystywany w sytuacjach kryzysowych takich jak pandemia COVID-19. System posiada bezpośredni styk z podobnymi rozwiązaniami Rządowego Centrum Bezpieczeństwa i obejmuje swoim zasięgiem Centra Zarządzania Kryzysowego Urzędów Wojewódzkich, a także zapewnia łączność dla Administracji Państwowej i Rządowej. Istniejący system wideokonferencyjny jest wykorzystywany do obsługi: działań Policji na szczeblu krajowym oraz wojewódzkim, działań wewnętrznych poszczególnych komórek Policji, przesłuchiwań świadków koronnych przez Centralne Biuro Śledcze Policji oraz sądy, ogólnopolskich szkoleń dla funkcjonariuszy i pracowników Policji, połączeń Rządowego Zespołu Zarządzania Kryzysowego, połączeń międzyministerialnych, połączeń Kancelarii Prezesa Rady Ministrów w tym połączeń do Komisji Europejskiej, połączeń Kancelarii Prezydenta, koordynacji działań szpitali jednoimiennych oraz Ministerstwa Zdrowia, oraz wielu innych połączeń na szczeblu Prezydenta, Premiera, Ministrów oraz instytucji Państwowych.

Zamawiający wskazał, że system musi być gotowy do działania w stale zmieniających się warunkach lokalizacji terminali i w reżimie bardzo dużej dostępności. Wymusza to ograniczenie do minimum czynności administracyjnych zawiązanych z zarządzaniem urządzeniami. Dlatego takie funkcjonalności jak pojedynczy punkt rejestracji, konfiguracji czy aktualizacji oprogramowania ma znaczenie krytyczne. Nie jest tak jak twierdzi Odwołujący, że czynność rejestracji albo konfiguracji terminala jest jednorazowa. Przy bardzo krótkim czasie na przygotowanie spotkania wideo administratorzy nie mieliby czasu na rozwiązywanie takich problemów konfiguracyjnych, ponieważ odpowiadają za realizację połączeń z użytkownikami. W standardowych zastosowaniach to użytkownicy sami podłączają się do spotkania, natomiast w systemie policyjnym nie ma dowolności podłączania się użytkowników. Spotkania podlegają ścisłej kontroli i weryfikacji uprawnień do udziału w nich.

Dalej Zamawiający wskazał, iż w poprzednim postępowaniu zakupione zostało 57 terminali wideokonferencyjnych oraz wsparcie dla 23 już posiadanych. Wskazał, że na dzień 7 sierpnia br. system posiada zarejestrowanych 694 urządzeń końcowych z czego 94 terminali Poly Group series, 524 aplikacje RealPresence Desktop oraz 37 aplikacji RealPresence Mobile. Zamawiający zwracał uwagę na fakt, że dla wszystkich wymienionych urządzeń końcowych oraz aplikacji jedynym modelem zarządzania jest zarządzanie dynamiczne poprzez szablony konfiguracji. Jedynie 20 urządzeń zarejestrowanych w systemie to urządzenia, które nie są zarządzanie przez szablony dynamiczne i są to urządzenia zarejestrowane do systemu z zewnątrz sieci nie będących urządzeniami Zamawiającego. Cały czas zachodzi też potrzeba dodania do systemu kilku, kilkunastu kolejnych terminali bezpośrednio przed wideokonferencją.

Zamawiający wskazał, że twierdzenia Odwołującego, iż zmiany w konfiguracji wykonywane są niezwykle rzadko, są niezgodne z rzeczywistością ponieważ zmiany w konfiguracji urządzeń wykonywane są bardzo często, przy występowaniu dużej presji czasowej, w związku z np. koniecznością zestawienia konferencji dla Prezydenta, Premiera czy Ministrów. Realizacja działań wielokrotnie wymagała przekonfigurowania systemu wideokonferencyjnego w ciągu kilku godzin, często w nocy. W wyniku decyzji realizacji

o posiedzeń zespołów Rady Ministrów (w tym Rządowego Zespołu Zarządzania Kryzysowego) w formie wideokonferencji, wykorzystany został sprawnie działający Policyjny System Wideokonferencyjny będący w posiadaniu i administrowany przez Zamawiającego.

W ciągu jednej nocy został dostosowany do realizacji działań nie tylko Policji, ale również Prezydenta, Premiera oraz Ministrów. Od początku pandemii COVID-19 system odpowiada za zestawianie bardzo nietypowych wideokonferencji, często z wymaganym czasem na przygotowanie liczonym w minutach lub pojedynczych godzinach.

Zamawiający wskazywał, iż terminale użytkowników są wyłączane i dosyć często przenoszone. W sytuacji konieczności szybkiego uruchomienia terminala, który był wyłączony, należałoby zacząć od weryfikacji jego oprogramowania i ew. aktualizacji co jest procesem czasochłonnym i ograniczającym możliwości operacyjne systemu. Każdorazowo konferencja może posiadać inne wymagania w zakresie konfiguracji terminali w zależności od ich specyfiki. Dynamiczne szablony konfiguracji pozwalają na wymuszenie jednakowej konfiguracji na wszystkich terminalach wideokonferencyjnych, niemal natychmiast po jej dodaniu, bez oczekiwania na zaplanowany termin aktualizacji. Jest to wykonywanie automatycznie. W czasie pandemii COVID-19 zmiany w konfiguracji poprzez szablony dynamiczne były dokonywane niejednokrotnie kilka razy w tygodniu. Zamawiający podkreślał, iż jest to kluczowa funkcjonalność systemu i bezwzględnie konieczne jest jej utrzymanie. Oczywiste jest więc, że funkcjonalność automatycznej konfiguracji i aktualizacji, zamiast takich samych procesów wykonywanych zgodnie z przyjętym harmonogramem (planowanej) jest zdecydowanie efektywniejsza. Wystarczy, że kilka terminali będzie wyłączone w czasie zaplanowanej aktualizacji, a otrzymujemy niespójną konfigurację.

W takim przypadku jest rzeczą szczególnie ważną dla Zamawiającego aby system do którego w ramach niniejszego postępowania mają zostać dokupione dodatkowe terminale wideokonferencyjne utrzymał obecną spójność oraz niezawodność w zakresie zarządzania konfiguracją, wideokonferencjami, użytkownikami systemu oraz urządzeniami.

Zamawiający wskazał, iż w systemie przez niego posiadanym połączenia realizowane są w oparciu o protokół SIP. Powołując się na dokumentację załączoną przez Odwołującego należy zauważyć, iż centralnych ustawień protokołu SIP można dokonywać wyłącznie za pośrednictwem zarządzania dynamicznego. W związku z tym użycie zarządzania dynamicznego jest w pełni uzasadnione oraz konieczne.

Zamawiający odniósł się do sugestii zastosowania przez Odwołującego rozwiązania Cisco Telepresence Management Suite w celu realizacji funkcjonalności zarządzania dostarczonymi przez siebie terminalami wideokonferencyjnymi. Wskazał, iż z technicznego punktu widzenia skutkowałoby to stworzeniem obok istniejącego systemu drugiego rozwiązania, które miałoby na celu zarządzanie jedynie częścią urządzeń, tj. urządzeniami dostarczonymi przez Odwołującego w ramach niniejszego postępowania. W praktyce tworzenie drugiego systemu obok aktualnie istniejącego systemu Zamawiającego miałoby jedynie służyć umożliwieniu oferowaniu przez potencjalnych wykonawców również innych jeszcze produktów. Co więcej, Odwołujący całkowicie pominął fakt, że postępowanie dotyczy Umowy ramowej, a zatem dostawy mogą być realizowane w kilku etapach, i przez różne podmioty. Zatem takich systemów zarządzania może być kilka. Nie jest zatem, tak jak twierdzi NTT, że wymagania w zakresie zarządzania konfiguracją i aktualizacji oprogramowania terminali „zostały rozszerzone w zakresie zupełnie zbędnym z punktu widzenia prawidłowego działania całego systemu wideokonferencyjnego.” System zbudowany na bazie kilku „wysp”, każda zarządzająca tylko częścią terminali byłby tak skomplikowany na styku wykonywania połączeń, że w zasadzie niemożliwe będzie uzyskanie pełnej operacyjności, a jakakolwiek awaria, problem z rejestracją, aktualizacją oprogramowania (zgodność funkcjonalności w poszczególnych wersjach oprogramowania) nie będzie możliwe do rozwiązania, ponieważ każdy z producentów może twierdzić, że błąd leży po drugiej stronie (innego producenta/producentów). Dla Zamawiającego ustalenie przyczyn awarii będzie z powodów technicznych nie do ustalenia (bardzo specjalistyczna wiedza i brak dostępu do danych) a przedłużające się wyjaśnienia właściwie mogą unieruchomić cały system.

Zamawiający wskazał, że Odwołujący całkowicie pominął zagadnienia związane z serwisem pogwarancyjnym. Zamawiający posiada bardzo rygorystyczne wymagania serwisu gwarancyjnego wykraczające daleko poza standardową gwarancję, np. naprawa serwera max. 96 godzin, naprawa terminala max. 144 godziny. Jeżeli dostawy będą wykonywane w kilku etapach i za każdym razem będzie to inny producent to w efekcie Zamawiający będzie musiał utrzymywać kilka usług serwisowych, co z pewnością jest nieefektywne ekonomicznie, ale przede wszystkim organizacyjnie i technicznie.

Administratorzy systemu, którzy zmuszeni byliby do szkolenia w zakresie kilku różnych rozwiązań technicznych. Nie są wystarczające krótkie warsztaty aby przeszkolić administratorów w zakresie zarządzania konfiguracją w oparciu o Cisco Telepresence Management Suite. To system o całkowicie innej architekturze. Co więcej, taka wiedza i umiejętności musiałyby być aktualizowane, co również zmuszałoby Zamawiającego do ponoszenia dodatkowych kosztów a takie nie zostały uwzględnione w budżecie

Zamawiającego i nie są przedmiotem postępowania.

Zamawiający zwracał uwagę na fakt, iż w SIWZ (załącznik nr 4 punkt II ppkt l) zostało wskazane, że posiada system wideokonferencyjny w 2 węzłach podzielonych geograficznie.

Wszystkie elementy posiadanego systemu są zduplikowane w 2 niezależnych serwerowniach oraz zapewniają ciągłość działania systemu w przypadku awarii jednego z komponentów. Zamawiający nie wyobraża sobie sytuacji, gdzie dostawca dostarczy drugi albo trzeci/czwarty (kilka etapów w ramach umowy ramowej) system, istniejący obok aktualnego systemu, tj. rozwiązanie wymagające instalacji dodatkowego oprogramowania, co do którego oczekiwania Zamawiającego nie zostały w żaden sposób opisane. Dostawca nie wyjaśnia czy zamierza dostarczyć oprogramowanie, które pozostanie redundantne geograficznie jak obecna infrastruktura wideokonferencyjna w przypadku drugiego systemu.

Należy także zwrócić uwagę na fakt, iż potencjalny kolejny system wiąże się z koniecznością jego utrzymania, co generuje jak wcześniej wskazano dodatkowe koszty dla Zamawiającego (naruszałoby to dyscyplinę finansów publicznych) i nie jest przedmiotem niniejszego postępowania, jak również nie jest objęte wsparciem jakie zostało zapewnione Zamawiającemu na posiadany obecnie system wideokonferencyjny. W przypadku aktualizacji systemu oraz konieczności rozwiązywania problemów Zamawiający nie mógłby w żaden sposób egzekwować wsparcia dla drugiego systemu nie będącego przedmiotem postępowania oraz umowy na dostawę.

Podkreślał, iż celem Zamawiającego jest utrzymanie pełnej spójności aktualnego systemu, tak aby umożliwić dalsze sprawne zarządzanie wideokonferencjami oraz urządzeniami do wideokonferencji, a w efekcie nadal sprawnie i szybko reagować na potrzeby zarówno jednostek Policji jak również najważniejszych osób/organów w Państwie.

Wdrożenie dodatkowego rozwiązania (drugiego albo trzeciego i kolejnego równoległego systemu) do zarządzania częścią terminali będzie skutkowało utratą spójności aktualnego systemu. Oba systemy miałyby przy tym funkcje, które się nie pokrywają. Wskazywany przez Odwołującego System Cisco Telepresence Management Suite (TMS) posiada rozbieżne funkcjonalności względem Polycom Resource Manager. W sytuacji wdrożenia dodatkowych systemów zarządzania nie będzie możliwe utrzymanie jednej spójnej książki adresowej.

Część terminali posiadałaby w takiej sytuacji książkę adresową z systemu Poly Resource Manager a druga część urządzeń z rozwiązania Cisco Telepresence Management Suite, a kolejna część jeszcze innego producenta. Jest to rozwiązanie, które jest absolutnie niedopuszczalne przez Zamawiającego i w sposób bezpośredni zagrażałoby utrzymaniu spójności całego systemu wideokonferencyjnego i jego możliwości operacyjnych.

Zamawiający podkreślał, że podobnie jak w przypadku wymagania dotyczącego zarządzania konfiguracją wymaga zarządzania aktualizacjami z poziomu systemu zarządzania Poly Resource Manager. Nadmienił, iż aktualizacja konfiguracji jak i aktualizacja oprogramowania są funkcjami wzajemnie się uzupełniającymi. Podobnie jak w przypadku zarządzania Zamawiający nie przewiduje rezygnacji z funkcjonalności zdalnych aktualizacji jedynie aby umożliwić złożenie oferty szerszemu gronu oferentów.

Funkcjonalność aktualizacji zdalnych umożliwia nadzorowanie wersji oprogramowania systemowego terminali wideokonferencyjnych. Pozwala na centralne rozesłanie aktualizacji do terminali wideokonferencyjnych - podobnie jak rozesłanie konfiguracji. Dzięki dokonywaniu aktualizacji system zarządzania może wymusić, aby wszystkie urządzenia w nim zarejestrowane posiadały minimalną wersję oprogramowania. Pozwala to zabezpieczyć system przed rejestracją terminali wideokonferencyjnych posiadających np. starsze oprogramowanie posiadające luki w zakresie bezpieczeństwa. W sytuacji kiedy terminal wideokonferencyjny o niższej wersji oprogramowanie zgłosi się do systemu zarządzania po konfigurację razem z nią otrzyma aktualizację swojego oprogramowania systemowego. Realizacja centralnych aktualizacji jest funkcjonalnością wymaganą oraz używaną przez Zamawiającego obecnie dla wszystkich urządzeń w tym aplikacji mobilnych oraz na komputery PC. Wdrożenie kolejnych rozwiązań w ramach tego samego systemu zarządzania aktualizacjami spowodowałoby utratę spójności systemu zarządzania wersjami oprogramowania poprzez rozbicie go na różne komponenty o różnych funkcjonalnościach.

Zamawiający wskazał, że istotna jest informacja, że w zakresie wymaganych do dostarczenia w ramach umowy ramowej serwerów wideokonferencyjnych nie mieści się jakikolwiek serwer dodatkowy, tj. serwer zarządzania - nie jest on przedmiotem postępowania. Koszty takich dodatkowych urządzeń/oprogramowania nie zostały uwzględnione w budżecie Zamawiającego, a byłoby to dodatkowo utrudnione ze względu na specyfikę umowy ramowej.

Odnosząc się do funkcjonalności dotyczącej rejestracji do systemu Zamawiający wyjaśnił, iż analogicznie jak w przypadku wyjaśnień do zarzutu nr 1 realizacja zarządzania poprzez zarządzanie dynamiczne jest wymagane ze względu na: a) używanie w systemie Zamawiającego protokołu SIP, wymaga to stosowania provisioningu dynamicznego, b) posiadanie przez Zamawiającego urządzeń wspierających provisioning dynamiczny. 655

urządzeń z 694 zarejestrowanych (a zatem ponad 92%) w obecnym systemie ma możliwość wyłącznie zarządzania poprzez provisioning dynamiczny. Zamawiający wskazał, że nie ma możliwości zmiany sposobu realizacji provisioningu na inny, tylko po to aby sprostać nieuzasadnionym oczekiwaniom Odwołującego.

Zamawiający wskazał, iż nie jest prawdziwym twierdzenie Odwołującego, że zmiany w konfiguracji są dokonywane wyłącznie przy pierwszym uruchomieniu systemu.

Zamawiający ze względu na specyfikę swojej pracy często zmienia konfigurację terminali wideokonferencyjnych. Odwołujący w uzasadnieniu swojego stanowiska wskazuje jakoby provisioning służył jedynie do pierwszego ustawienia terminala. Zamawiający wyjaśnia zatem, iż katalog funkcji możliwych do ustawienia za pomocą provisioningu dynamicznego jest znacznie szerszy i obejmuje m.in.: a) ustawienia sieciowe (np. zmianę prędkości połączenia co jest szczególnie istotne gdy w sytuacji obciążenia łączy konieczne jest zmniejszenie jakości konferencji aby oszczędzić pasmo), b) funkcje związane z ruchem sieciowym (Zamawiający często prowadzi modyfikacje swojej sieci i wymaga to pilnego dostosowania konfiguracji systemu wideokonferencyjnego do nowych wymagań), c) ustawienia automatycznego odbierania połączeń (szczególnie ważne przy konieczności wykonania połączeń testowych np. w godzinach nocnych - w ramach przygotowania na następny dzień - bez obecności obsługi przy terminalu) oraz d) wiele innych funkcji, które na co dzień w znaczący sposób umożliwiają sprawne zarządzanie systemem.

Zamawiający wyjaśnił, iż organizuje bardzo duże konferencje, w których niejednokrotnie bierze udział ok. 180 lokalizacji. Wprowadzenie ustawień ręcznie na wszystkich urządzeniach jest niemal niemożliwe do realizacji, zajmowałoby kilka godzin oraz generowałoby bardzo dużą ilość potencjalnych błędów. Modyfikacja w oparciu o szablony konfiguracji pozwala na zastosowanie nowych ustawień w całym systemie Zamawiającego w czasie krótszym niż 15 minut i nie jest obarczona ryzykiem popełnienia błędu. Zatem Odwołujący nie może twierdzić, że są to wymagania nieuzasadnione.

Zamawiający wyjaśnił również, iż autoryzacja za pomocą kont domenowych jest funkcjonalnością niezbędną przy budowie tak dużego systemu - obecnie blisko 700 kont, po rozbudowie ponad 1 100 kont. Rozwiązania wideokonferencyjne w tym serwery zarządzania nie są przystosowane do katalogowania dużych zbiorów kont i optymalizowane sprzętowo w tym zakresie (zbędne wykorzystanie mocy obliczeniowej). Wszystkie konta zakładane w systemie prezentowane są w ramach jednego widoku i nie jest możliwe w żaden sposób ich grupowanie. Dlatego Zamawiający realizuje obsługę kont za pomocą kont domenowych.

Wdrożone rozwiązanie - domena - daje możliwość zarządzania użytkownikami nie tylko ze względu na ich nazwę oraz hasło, ale również na poziom uprawnień do systemu wideokonferencyjnego. W sytuacji dodania nowego użytkownika do domeny istnieje możliwość nadania mu uprawnień do specyficznych części systemu i dzieje się to w sposób automatyczny. Tym samym nie jest wymagane nadawanie uprawnień w każdym systemie z osobna i pozwala na bardzo szybkie zarządzanie. W sytuacji konieczności zmiany uprawnień lub ich wycofania konto, które zostało usunięte w domenie w sposób automatyczny zostaje wykasowane we wszystkich serwerach systemu wideokonferencyjnego. Dzięki temu Zamawiający utrzymuje spójność i bezpieczeństwo systemu w zakresie poświadczeń oraz poziomów dostępu. Jest to szczególnie istotne ze względów bezpieczeństwa - Zamawiający zakłada często w systemie konta dla podmiotów zewnętrznych, które powinny zrealizować wideokonferencję a następnie konto jest usuwane.

W takim scenariuszu nie ma ryzyka, że po usunięciu konta użytkownik nadal będzie miał dostęp do fragmentu systemu, w którym administrator przez przypadek nie wyłączył jego konta. Systemy katalogowe takie jak domena są powszechnie stosowanym rozwiązaniem w zakresie nadawania uprawnień oraz zarządzania użytkownikami. Zamawiający nie przewiduje możliwości rezygnacji z obecnie realizowanej i wymaganej przez siebie funkcjonalności jedynie po to aby umożliwić złożenie oferty większej ilości oferentów.

Po przeprowadzeniu rozprawy z udziałem Stron i Uczestnika postępowania odwoławczego, na podstawie zebranego materiału w sprawie oraz oświadczeń i stanowisk Stron i Uczestnika, Krajowa Izba Odwoławcza ustaliła i zważyła, co następuje:

Na wstępie Izba ustaliła, że nie została wypełniona żadna z przesłanek, o których stanowi art. 189 ust. 2 ustawy Pzp, skutkujących odrzuceniem odwołania.

Izba oceniła, że Odwołujący posiada interes w uzyskaniu zamówienia oraz możliwość poniesienia szkody w związku z ewentualnym naruszeniem przez Zamawiającego przepisów ustawy Pzp, czym wypełnił materialnoprawną przesłankę dopuszczalności odwołania,

o której mowa w art. 179 ust. 1 ustawy Pzp.

Izba nie podzieliła argumentacji podnoszonej przez Zamawiającego, iż Odwołujący nie wykazał interesu we wniesieniu odwołania, ponieważ nie przedstawił wiarygodnych dowodów, że po udzieleniu odpowiedzi na pytania jego sytuacja w zakresie możliwości złożenia oferty uległa zmianie. Podnoszona argumentacja w żaden sposób - zdaniem Zamawiającego - nie potwierdzała, że w wyniku odpowiedzi na pytania 32, 36 i 37 ograniczona została możliwość złożenia przez niego oferty a tym samym nie może wykazać, że mógł odnieść jakiekolwiek zyski, albo utracić jakiekolwiek korzyści. W ww. zakresie Zamawiający zwracał w szczególności uwagę na okoliczność, iż Odwołujący jest platynowym partnerem producenta systemu Poly, zatem mógł przed zmianami treści SIWZ z dnia 2 lipca 2020 r. złożyć ofertę w niniejszym postępowaniu.

Odnosząc się do powyższego Izba wskazuje, że nie jest rolą zamawiającego decydowanie za wykonawcę na jakich produktach czy rozwiązaniach wykonawca powinien oprzeć swoją ofertę. Kwestia ta jest autonomiczną decyzją wykonawcy, nawet gdyby następczo zaoferowane przez wykonawcę rozwiązania okazały się sprzeczne z wymogami zamawiającego wyrażonymi w SIWZ, czego konsekwencją byłoby odrzucenie oferty wykonawcy. Tym samym okoliczność, iż Odwołujący jest platynowym partnerem producenta systemu Poly i mógł hipotetycznie zaoferować Zamawiającemu produkty tego podmiotu, nie pozbawia wykonawcy możliwości skorzystania ze środków ochrony prawnej, jeżeli uważał on, że przedmiot zamówienia sporządzony został z naruszeniem przepisów ustawy Pzp w sposób uniemożliwiający wykonawcy złożenie oferty opartej na rozwiązaniach innych niż oczekiwane przez Zamawiającego, lecz spełniających określone funkcjonalności.

Podniesione w odwołaniu okoliczności, iż Odwołujący jest zainteresowany udziałem w przedmiotowym postępowaniu, a dokonane przez Zamawiającego czynności uniemożliwiają mu złożenie oferty w postępowaniu, czego skutkiem byłaby szkoda w postaci utraty korzyści z uzyskania zamówienia - w ocenie Izby - należało uznać za wystarczające dla stwierdzenia wykazania interesu, o którym mowa w art. 179 ust. 1 ustawy Pzp.

Zamawiający w dniu 14 lipca 2020 r. powiadomił wykonawców o wniesionym odwołaniu.

Izba dopuściła do udziału w postępowaniu odwoławczym wykonawcę Intertrading Systems Technology Sp. z o.o. z siedzibą w Warszawie zgłaszającego przystąpienie do postępowania odwoławczego w dniu 17 lipca 2020 r. po stronie Odwołującego.

Po zapoznaniu się z treścią złożonych pism procesowych, tj. pisma Odwołującego z dnia 22 lipca 2020 r. zawierającego opozycję wobec przystąpienia do postępowania odwoławczego wykonawcy VisionCube S.A. z siedzibą w Krakowie po stronie Zamawiającego, pisma zgłaszającego przystąpienie VsionCube S.A. z dnia 24 lipca 2020 r. stanowiącego odpowiedź na opozycję oraz pisma Odwołującego z dnia 27 lipca 2020 r. zawierającego odpowiedź na stanowisko VisionCube S.A. w sprawie zgłoszonej opozycji Izba stwierdziła, iż wykonawca VisionCube S.A. nie przystąpił skutecznie do postępowania odwoławczego z uwagi na niewskazanie interesu w uzyskaniu rozstrzygnięcia na korzyść strony, do której przystępuje.

Zgodnie z art. 185 ust. 2 zdanie 1. ustawy Pzp, wykonawca może zgłosić przystąpienie do postępowania odwoławczego w terminie 3 dni od dnia otrzymania kopii odwołania, wskazując stronę, do której przystępuje, i interes w uzyskaniu rozstrzygnięcia na korzyść strony, do której przystępuje.

Izba wskazuje, iż wykonawca VisionCube S.A. w złożonym przystąpieniu odnośnie kwestii interesu ograniczył się jedynie do stwierdzenia, że „zamierza złożyć ofertę w ramach niniejszego Postępowania. Nadto VisionCube S.A. złożył ofertę i wygrał postępowanie dotyczące poprzedniego etapu modernizacji systemu, tj. postępowanie pn. „Modernizacja Policyjnego Systemu Wideokonferencyjnego w ramach Programu Modernizacji Policji w latach 2017 - 2020”, numer postępowania Izba wskazuje, że jakkolwiek interes wykonawcy zgłaszającego przystąpienie do postępowania odwoławczego należy odczytywać szeroko, to jednak musi on zostać sprecyzowany przez wykonawcę w terminie określonym w art. 185 ust. 2 ustawy Pzp. Zgodnie z treścią ww. przepisu wykonawca winien wskazać interes w uzyskaniu rozstrzygnięcia na korzyść strony, do której przystępuje. Słusznie twierdził Odwołujący, iż okoliczność, że wykonawca VisionCube S.A. wygrał poprzednie postępowanie dotyczące modernizacji systemu nie miała żadnego znaczenia w kontekście ewentualnego uwzględnienia odwołania wniesionego w innym postępowaniu. Z kolei okoliczności, iż zgłaszający przystąpienie zamierzał złożyć ofertę w niniejszym postępowaniu nie można było uznać za wystarczającej, bowiem wykonawca powinien wskazać w szczególności jakie korzyści utraci lub jakie negatywne skutki wywoła po jego stronie uwzględnienie odwołania. Podkreślić należy, iż owe korzyści lub negatywne skutki nie mogą być przedmiotem domniemania, ponieważ to na wykonawcy spoczywa obowiązek wskazania interesu w uzyskaniu rozstrzygnięcia na korzyść strony, do której przystępuje.

Izba wskazuje, iż z uwagi na zawity termin zgłoszenia przystąpienia do postępowania odwoławczego, dalsze argumenty wykonawcy VisionCube S.A. mające uzasadniać interes w zgłoszeniu przystąpienia po stronie Zamawiającego, podniesione w piśmie z dnia 24 lipca 2020 r., nie mogły zostać wzięte pod uwagę. W związku z powyższym Izba uwzględniła wniesioną opozycję.

Przy rozpoznawaniu przedmiotowej sprawy Izba uwzględniła dokumentację postępowania o udzielenie zamówienia przekazaną przez Zamawiającego, w szczególności ogłoszenie o zamówieniu, specyfikację istotnych warunków zamówienia wraz z załącznikami oraz wyjaśnieniami i modyfikacjami, jak również informację z otwarcia ofert.

Skład orzekający Izby wziął pod uwagę również stanowiska i oświadczenia Stron postępowania odwoławczego złożone w pismach oraz ustnie do protokołu posiedzenia i rozprawy w dniu 2 września 2020 r. Izba wzięła pod uwagę także stanowisko merytoryczne wykonawcy VisionCube S.A. zawarte w piśmie z dnia 31 sierpnia 2020 r. zgodnie z wnioskiem Zamawiającego.

Ponadto Izba zaliczyła w poczet materiału sprawy dowody z dokumentów złożonych przez Odwołującego przy odwołaniu, jak również dowody z dokumentów złożonych przez Zamawiającego przy odpowiedzi na odwołanie.

Jednocześnie Izba wzięła pod uwagę dowody złożone przez Odwołującego, tj.:

1. pismo wykonawcy NTT Poland Sp. z o.o. z dnia 29 lipca 2020 r. w sprawie zmian treści SIWZ;
2. pismo Zamawiającego z dnia 31 lipca 2020 r.;
3. kopię postanowienia KIO z dnia 17 sierpnia 2020 r. w sprawie o sygn. akt: KIO 1066/20;
4. zrzuty z ekranu z systemu Polycom.

Izba ustaliła, co następuje:

Przedmiotem zamówienia jest modernizacja Policyjnego Systemu Wideokonferencyjnego (PSW), obejmująca dostawę w ramach umowy ramowej terminali wideokonferencyjnych oraz serwerów wideokonferencyjnych wraz z wyposażeniem i licencjami niezbędnymi do uruchomienia w środowisku systemu wideokonferencyjnego Zamawiającego.

W punkcie II załącznika nr 4 do SIWZ Zamawiający wskazał, że dysponuje infrastrukturą wideokonferencyjną w dwóch lokalizacjach na terenie kraju, opartą na rozwiązaniu firmy Poly, w tym serwerami: a) Polycom DMA v 10.0.0.P4_Build_9485, b) Polycom Collaboration Serwer 1831, c) Polycom RealPresence Resource Manager.

Zamawiający zapewnia niezbędną liczbę licencji dla rejestracji nowych urządzeń w systemie.

Zgodnie z punktem III - Wymagania funkcjonalne i techniczne:

1. Dostarczone terminale i serwery wideokonferencyjne muszą być kompatybilne z systemem wideokonferencyjnym Zamawiającego w zakresie co najmniej: - zarządzania urządzeniami, - zarządzania użytkownikami, - zarządzania połączeniami, - zarządzania zasobami licencyjnymi, - zarządzania konfiguracją, - planowania wideokonferencji,

• monitorowania parametrów połączeń, parametrów pracy terminali i serwerów.

W pkt V załącznika nr 4 do SIWZ - Specyfikacja techniczna dla terminali wideokonferencyjnych ppkt 1 Terminal typu A1 Lp. 11, ppkt 2 Terminal typu A2 Lp. 10, ppkt 3 Terminal typu B Lp. 10, ppkt 4 Terminal typu C Lp. 10 Zamawiający wymagał w stosunku do wszystkich typów terminali „możliwości uruchomienia, połączenia i realizacji wszystkich funkcjonalności w środowisku systemu wideokonferencyjnego firmy Poly z zachowaniem pełnej zgodności w zakresie rejestracji do systemu, zdalnej aktualizacji oprogramowania”.

W dniu 2 lipca 2020 r. Zamawiający udzielił wyjaśnień treści specyfikacji.

W odpowiedzi na pytanie nr 32 o treści: „Dotyczy Załącznika nr 4 do SIWZ „Opis przedmiotu zamówienia”, punkt III „Wymagania funkcjonalne i techniczne”, ppkt „zarządzanie konfiguracją”: Prosimy o wyjaśnienie, w jaki sposób w chwili obecnej funkcjonuje konfigurowanie urządzeń oraz zarządzanie konfiguracją? Czy urządzenia konfigurowane są pojedynczo, czy konieczne jest zastosowanie szablonów konfiguracji zbiorowej z serwera centralnego?” Zamawiający wyjaśnił, że: „wymaga aby dostarczone terminale wideokonferencyjne umożliwiały konfigurację indywidualną (pojedynczo każdy z terminali) oraz konfigurację automatyczną z szablonów dostępnych na serwerze Poly Resource Manager wskazanym w punkcie II ppkt 1c załącznika nr 4 do SIWZ „Opis przedmiotu zamówienia”. Dostarczone terminale wideokonferencyjne muszą mieć możliwość wykonania zdalnej konfiguracji urządzeń za pomocą systemu Poly Resource Manager z użyciem profili konfiguracji, które są szablonem ustawień dla wszystkich urządzeń w systemie. W razie potrzeby zmiany konfiguracji na wszystkich urządzeniach w sieci modyfikacje wprowadzone są w szablonie na serwerze konfiguracji, a następnie zostają rozpropagowane na wszystkie wideoterminale”.

Z kolei w odpowiedzi na pytanie nr 36 o treści: „Dotyczy Załącznika nr 4 do SIWZ „Opis przedmiotu zamówienia”, punkt V „Specyfikacja techniczna dla terminali wideokonferencyjnych, parametr dotyczący wszystkich terminali - aktualizacja”: Czy Zamawiający dopuszcza możliwość aktualizacji wideoterminali z poziomu innego niż wymieniony w OPZ posiadany system wideokonferencyjny Poly?” Zamawiający podał, że:

„podtrzymuje zapisy SIWZ w tym zakresie. Zamawiający wymaga aby aktualizacja oprogramowania dostarczonych terminali wideokonferencyjnych była możliwa do wykonania automatycznie z poziomu serwera Poly Resource Manager wskazanego w punkcie II ppkt 1 c) załącznika nr 4 do SIWZ „Opis przedmiotu zamówienia”. Zamawiający nie dopuszcza możliwości aktualizacji oprogramowania dostarczonych terminali wideokonferencyjnych z innych serwerów.”

Z kolei w odpowiedzi na pytanie nr 37 o treści: „Dotyczy załącznika nr 4 do SIWZ „Opis przedmiotu zamówienia”, punkt V „Specyfikacja techniczna dla terminali wideokonferencyjnych, inne funkcjonalności - rejestracja do systemu”: Prosimy o opisanie procesu rejestracji do posiadanej infrastruktury Poly - w jaki sposób następuje autoryzacja urządzenia podczas rejestracji? Jakie licencje są zapewniane przez Zamawiającego?”

Zamawiający wskazał, że: „Zamawiający wymaga aby dostarczone terminale wideokonferencyjne wykorzystywały do rejestracji w systemie serwer Poly DMA wskazany w punkcie II ppkt 1a) załącznika nr 4 do SIWZ „Opis przedmiotu zamówienia”, który realizuje funkcje SIP Register oraz H.323 Gatekeeper. Ponadto Zamawiający wymaga aby dostarczone terminale wideokonferencyjne w zakresie zasobów licencyjnych były w pełni zgodne z serwerem PolyResource Manager wskazanym w punkcie II ppkt 1c) załącznika nr 4 do SIWZ „Opis przedmiotu zamówienia”, który realizuje funkcjonalność serwera licencji dla wszystkich elementów systemu. Rejestracja urządzenia odbywa się poprzez nawiązanie połączenia z serwerem provisioningu (Poly Resource Manager) gdzie następują autoryzacja za pośrednictwem kont domenowych. W wyniku poprawnej autoryzacji pobierany jest szablon konfiguracji z Poly Resource Manager, który zawiera m.in. adres serwera SIP oraz H.323 do którego rejestruje się urządzenie. Zamawiający posiada możliwość rejestracji w systemie Poly 50.000 użytkowników. Zamawiający zapewnia licencje w serwerze provisiongu.”

W dniu 12 sierpnia 2020 r. odbyło się otwarcie ofert złożonych w przedmiotowym postępowaniu o udzielenie zamówienia publicznego. Do Zamawiającego wpłynęły dwie oferty, tj. oferta wykonawcy Integrated Solutions Sp. z o.o. z siedzibą w Warszawie oraz oferta wykonawców wspólnie ubiegających się o udzielenie zamówienia VisionCube S.A. z siedzibą w Krakowie oraz A. P. prowadzącego działalność gospodarczą pod nazwą KLIKmedia A. P. .

Izba zważyła, co następuje:

Odwołanie nie zasługiwało na uwzględnienie.

Za niezasadny Izba uznała zarzut naruszenia art. 29 ust. 1 i 2 w zw. z art. 7 ust. 1 ustawy Pzp poprzez opisanie przedmiotu zamówienia w zakresie funkcjonalności zarządzania konfiguracją, aktualizacją oprogramowania oraz rejestracji do systemu w sposób nieproporcjonalny i nieuzasadniony potrzebami Zamawiającego oraz ograniczający konkurencję poprzez dopuszczenie do udziału w postępowaniu tylko jednego producenta lub zmuszenie wykonawców do zastosowania rozwiązania stosowanego tylko przez jednego producenta Poly.

Zgodnie z art. 29 ust. 1 ustawy Pzp, przedmiot zamówienia opisuje się w sposób jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń, uwzględniając wszystkie wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty. Z powyższego przepisu wynika zatem, iż zamawiający opisując przedmiot zamówienia winien dołożyć staranności, by opis zamówienia był kompletny, jasny, zrozumiały dla potencjalnych wykonawców. Jednocześnie ograniczenia w swobodzie określenia przedmiotu zamówienia zawiera norma art. 29 ust. 2 ustawy Pzp, która zakazuje opisania przedmiotu zamówienia w sposób dyskryminacyjny.

Izba wskazuje, iż sporządzenie opisu przedmiotu zamówienia jest jedną z najważniejszych czynności związanych z przygotowaniem postępowania o udzielenie zamówienia publicznego. Czynność ta stanowi jednocześnie obowiązek zamawiającego, ale i jego uprawnienie, bowiem zamawiający opisując przedmiot zamówienia odzwierciedla swoje rzeczywiste potrzeby, które chce zaspokoić poprzez udzielenie zamówienia publicznego. Zamawiający ma prawo, tak określić przedmiot zamówienia, aby opisać go adekwatnie do wyznaczonego celu, zachowując jednocześnie obiektywizm i precyzję w formułowaniu swoich potrzeb. Izba podziela pogląd wielokrotnie prezentowany w orzecznictwie Krajowej Izby Odwoławczej, iż nie narusza przepisów ustawy Pzp sporządzenie opisu przedmiotu zamówienia, który uwzględnia potrzeby zamawiającego, nawet jeżeli utrudnia lub uniemożliwia niektórym podmiotom dostęp do zamówienia.

Obowiązek zachowania zasady uczciwej konkurencji nie oznacza, iż zamawiający nie może opisać przedmiotu zamówienia w sposób odzwierciedlający jego potrzeby. Zamawiający nie ma także obowiązku zapewnienia możliwości realizacji przedmiotu zamówienia wszystkim podmiotom działającym na ryku w danej branży. Dokonując opisu przedmiotu zamówienia zamawiający nie ma obowiązku czynienia tego w sposób najbardziej dogodny dla ewentualnych wykonawców. Z całą moc podkreślić jednak należy, iż w przypadku sporządzenia opisu przedmiotu zamówienia w sposób eliminujący funkcjonujące na rynku rozwiązania, po stronie zamawiającego będzie istniał obowiązek przedstawienia rzeczowych i przekonujących argumentów uzasadniających takie działanie.

Przenosząc powyższe rozważania prawne na grunt niniejszej sprawy Izba wskazuje, że na podstawie dowodów złożonych przez Odwołującego i Zamawiającego, jak również stanowiska Zamawiającego zawartego w odpowiedzi na odwołanie Izba stwierdziła, iż opis przedmiotu zamówienia został sporządzony w sposób zawężający konkurencję do produktów firmy Poly. Z dokumentacji producenta systemu Poly przedłożonej przez Strony wynika, że producent systemu posiadanego przez Zamawiającego, tj. Real Presence Resource Manager dopuszcza urządzenia końcowe (terminale) innych firm, w tym Cisco, zastrzegając przy tym, że zarządzanie dynamiczne i zarządzanie zaplanowane są funkcjonalnościami wzajemnie wykluczającymi się oraz że urządzenia końcowe innych firm nie mogą być zarządzane dynamicznie. Z dokumentacji producenta Poly wynika również, że dynamiczne zarządzanie jest możliwe w następujących przypadkach: 1) tylko dla urządzeń końcowych Polycom, 2) gdy urządzenia końcowe Polycom są w stanie automatycznie wykryć system Real Presence Resource Manager (.) oraz 3) opcjonalne, gdy system jest zintegrowany z katalogiem korporacyjnym. Ponadto z dokumentacji tej wynika, że system Real Presence Manager umożliwia dynamiczne przydzielanie niektórym urządzeniom końcowym Polycom, informacji o integracji z serwerem SIP, poświadczeń i ustawień parametrów SIP wymaganych przez urządzenia końcowe do integracji. Ustawienia SIP można skonfigurować tylko w przypadku korzystania z zarządzania dynamicznego, a do ustawień SIP nie można używać zaplanowanej ani dołączonych profili konfiguracji. Słusznie twierdził zatem Odwołujący, iż funkcjonalności dotyczące zarządzania dynamicznego oraz dynamicznego provisioningu wykorzystujące serwer Poly Resource Manager wskazują na rozwiązanie charakterystyczne dla producenta Poly.

Ponadto jak wskazał w odpowiedzi na odwołanie Zamawiający, aby zaoferowany system był zgodny z wymaganiami Zamawiającego oferent nie może pominąć funkcjonalności konfiguracji dynamicznej, a ta jak już wskazano powyżej wskazuje, na rozwiązanie Poly. Co więcej, skoro Zamawiający twierdził, że dla wszystkich posiadanych urządzeń końcowych oraz aplikacji jedynym modelem zarządzania jest zarządzanie dynamiczne przez szablony konfiguracji, podnosząc jednocześnie, że jest to funkcjonalność kluczowa i musi być utrzymana, to wyeliminował możliwość zastosowania jako

kompatybilnych do obsługi systemu Real Presence Resource Manager produktów firmy Cisco realizujących wyłącznie zarządzanie zaplanowane. Zamawiający przyznał także, że w systemie przez niego posiadanym połączenia realizowane są w oparciu o protokół SIP, który z kolei można skonfigurować tylko w przypadku korzystania z zarządzania dynamicznego oraz że znacząca większość urządzeń posiadanych przez Zamawiającego w obecnym systemie ma możliwość zarządzania tylko poprzez provisioning dynamiczny.

Konsekwencją takiego stanu rzeczy było następnie rozstrzygnięcie, czy ograniczenie wynikające z postanowień opisu przedmiotu zamówienia znajdowało usprawiedliwienie w obiektywnie uzasadnionych potrzebach Zamawiającego.

W ocenie Izby stanowisko przedstawione przez Zamawiającego potwierdziło, iż kwestionowane przez Odwołującego postanowienia SIWZ znajdują oparcie w uzasadnionych potrzebach Zamawiającego i nie są podyktowane dążeniem do ograniczenia konkurencji.

Na wstępie Izba wskazuje, że w okolicznościach niniejszej sprawy nie można pominąć, iż przedmiotem zamówienia jest modernizacja systemu już istniejącego i funkcjonującego u Zamawiającego. Zamawiający działa obecnie w środowisku systemu wideokonferencyjnego firmy Poly, posiada serwery Polycom, w tym serwer Polycom Real Presence Resource Manager, co wprost wynika z postanowień specyfikacji istotnych warunków zamówienia. Nie bez znaczenia jest również okoliczność, iż przedmiotowe postępowanie dotyczy umowy ramowej, tym samym rozbudowa systemu o kolejne urządzenia końcowe może być realizowana w kilku etapach, przez różnych wykonawców, a przedmiotem niniejszego postępowania nie jest zakup serwera dodatkowego, tj. serwera zarządzania. Co więcej, nie było sporne między Stronami postępowania odwoławczego, że producent systemu posiadanego przez Zamawiającego, tj. Poly umożliwia współpracę w pewnych obszarach z systemami innych producentów, jednakże są pewne obszary, gdzie rozwiązania producenta Poly są zgodne wyłącznie z rozwiązaniami oferowanymi przez producenta Poly.

I tak, za uzasadnioną w świetle wyjaśnień Zamawiającego Izba uznała argumentację o potrzebie utrzymania spójności posiadanego już systemu, co też przekłada się na dalsze sprawne zarządzanie wideokonferencjami oraz urządzeniami do wideokonferencji oraz umożliwia szybkie reagowanie na potrzeby zarówno jednostek Policji oraz najważniejszych osób/organów w państwie wykorzystujących rzeczony system. Jak wyjaśniał Zamawiający utrzymanie jednolitej architektury zarządzania terminalami wpływa na możliwość sprawnego administrowania systemem, w tym przygotowania i realizacji połączeń oraz nadzorowania uprawnień poszczególnych osób do udziału w wideokonferencjach organizowanych często w sytuacjach kryzysowych z minimalnym wyprzedzeniem czasowym. Ponadto jak wskazał Zamawiający system musi być gotowy do działania w stale zmieniających się warunkach lokalizacji terminali i w reżimie bardzo dużej dostępności, co też wymusza ograniczenie do minimum czynności administracyjnych zawiązanych z zarządzaniem urządzeniami. Dlatego też takie funkcjonalności jak pojedynczy punkt rejestracji, konfiguracji czy aktualizacji oprogramowania mają znaczenie krytyczne dla Zamawiającego.

Izba wskazuje, iż Zamawiający odparł twierdzenia Odwołującego, który podnosił, że czynność rejestracji albo konfiguracji terminala jest jednorazowa. Zamawiający podkreślał, iż zmiany w konfiguracji urządzeń wykonywane są bardzo często, przy występowaniu dużej presji czasowej, w związku z np. koniecznością zestawienia konferencji dla Prezydenta, Premiera czy Ministrów. Realizacja działań wielokrotnie wymagała od Zamawiającego przekonfigurowania systemu wideokonferencyjnego w ciągu kilku godzin, często w nocy.

Zamawiający uzasadniał, iż w czasie pandemii COVID-19 system odpowiada za zestawianie bardzo nietypowych wideokonferencji, często z wymaganym czasem na przygotowanie liczonym w minutach lub pojedynczych godzinach.

Dalej Zamawiający wskazywał, że terminale użytkowników są wyłączane i często przenoszone. W sytuacji konieczności szybkiego uruchomienia terminala, który był wyłączony, należałoby zacząć od weryfikacji jego oprogramowania i ewentualnej aktualizacji co jest procesem czasochłonnym i ograniczającym możliwości operacyjne systemu.

Każdorazowo konferencja może posiadać inne wymagania w zakresie konfiguracji terminali w zależności od ich specyfiki. Dlatego też w ocenie Zamawiającego funkcjonalność dotycząca dynamicznych szablonów konfiguracji, która pozwala na wymuszenie jednakowej konfiguracji na wszystkich terminalach wideokonferencyjnych, niemal natychmiast po jej dodaniu, bez oczekiwania na zaplanowany termin aktualizacji, ma kluczowe znaczenie z punktu widzenia sprawności działań Zamawiającego i konieczne jest jej utrzymanie.

Podkreślić należy, iż Odwołujący nie podważał stanowiska Zamawiającego, który twierdził, że funkcjonalność automatycznej konfiguracji i aktualizacji, zamiast takich samych procesów wykonywanych zgodnie z przyjętym harmonogramem (planowanej), jest zdecydowanie efektywniejsza. Jak tłumaczył Zamawiający, wystarczy, że kilka terminali będzie wyłączonych w czasie zaplanowanej aktualizacji, a otrzymujemy niespójną konfigurację. Dlatego też dla Zamawiającego szczególnie ważne było to, aby system do którego w ramach niniejszego

postępowania mają zostać dokupione dodatkowe terminale wideokonferencyjne utrzymał obecną spójność oraz niezawodność w zakresie zarządzania konfiguracją, wideokonferencjami, użytkownikami systemu oraz urządzeniami.

Za kluczową Izba uznała okoliczność, iż Odwołujący nie polemizował z Zamawiającym, iż rozwiązanie proponowane przez Odwołującego w celu realizacji funkcjonalności zarządzania dostarczonymi terminalami wideokonferencyjnymi przy użyciu zewnętrznego oprogramowania, tj. Cisco Telepresence Management Suite w istocie, z technicznego punktu widzenia, skutkowałoby stworzeniem obok istniejącego systemu drugiego rozwiązania, które umożliwiałoby zarządzanie jedynie częścią urządzeń, tj. urządzeniami dostarczonymi przez Odwołującego. Jak podkreślał Zamawiający wdrożenie dodatkowego rozwiązania (drugiego albo trzeciego i kolejnego równoległego systemu) do zarządzania częścią terminali będzie skutkowało utratą spójności aktualnego systemu.

Zamawiający zwracał również uwagę, iż oba systemy (posiadany obecnie przez Zamawiającego oraz proponowany przez Odwołującego) mają rozbieżne funkcjonalności, co też przekładałoby się na brak możliwości utrzymania jednej spójnej książki adresowej.

Powyższych twierdzeń Odwołujący nie kwestionował.

Zamawiający kwestionował twierdzenia Odwołującego, że wymagania w zakresie zarządzania konfiguracją i aktualizacji oprogramowania terminali „zostały rozszerzone w zakresie zupełnie zbędnym z punktu widzenia prawidłowego działania całego systemu wideokonferencyjnego”. Zamawiający uzasadniał, że system zbudowany na bazie kilku „wysp”, każda zarządzająca tylko częścią terminali byłby tak skomplikowany na styku wykonywania połączeń, że w zasadzie niemożliwe byłoby uzyskanie pełnej operacyjności, a jakakolwiek awaria, problem z rejestracją, aktualizacją oprogramowania (zgodność funkcjonalności w poszczególnych wersjach oprogramowania) nie byłby możliwy do rozwiązania, ponieważ każdy z producentów mógłby twierdzić, że błąd leży po drugiej stronie (innego producenta/producentów). Podkreślał, iż dla Zamawiającego ustalenie przyczyn awarii byłoby niemożliwe z uwagi na brak wysokospecjalistycznej wiedzy w tym zakresie, a przedłużające się wyjaśnienia mogłyby unieruchomić cały system.

Zamawiający uzasadnił również wymóg zarządzania aktualizacjami z poziomu systemu zarządzania Poly Resource Manager, nie dopuszczając tym samym możliwości aktualizacji oprogramowania dostarczonych terminali wideokonferencyjnych z innych serwerów niż już posiadany. W ww. zakresie Zamawiający wyjaśnił w szczególności, że realizacja centralnych aktualizacji jest funkcjonalnością wymaganą oraz używaną przez Zamawiającego obecnie dla wszystkich urządzeń w tym aplikacji mobilnych oraz na komputery PC, a wdrożenie kolejnych rozwiązań w ramach tego samego systemu zarządzania aktualizacjami spowodowałoby utratę spójności systemu zarządzania wersjami oprogramowania poprzez rozbicie go na różne komponenty o różnych funkcjonalnościach.

W przedmiocie funkcjonalności dotyczącej rejestracji do systemu Zamawiający wyjaśniał, iż realizacja tej funkcjonalności z użyciem serwera provisioningu (Poly Resource Manager) wymagana jest ze względu na używanie w systemie posiadanym przez Zamawiającego protokołu SIP oraz posiadanie przez Zamawiającego urządzeń wspierających provisioning dynamiczny. Jak wskazał Zamawiający, 655 urządzeń z 694 zarejestrowanych w obecnym systemie ma możliwość wyłącznie zarządzania poprzez provisioning dynamiczny.

Zamawiający podważał twierdzenia Odwołującego, który argumentował, że zmiany w konfiguracji urządzeń są dokonywane wyłącznie przy pierwszym uruchomieniu systemu.

Stanowisko Zamawiającego, który podnosił, iż katalog funkcji możliwych do ustawienia za pomocą provisioningu dynamicznego jest szeroki i nie sprowadza się wyłącznie do pierwszego uruchomienia do systemu, nie była przedmiotem repliki ze strony odwołującego się Wykonawcy.

Izba zauważa, że Odwołujący, który w toku rozprawy wskazywał na możliwość dwojakiego sposobu rejestracji urządzeń do systemu, tj. ręcznie lub półautomatycznie, po raz kolejny nie odniósł się do stanowiska Zamawiającego, który twierdził, iż wprowadzenie ustawień ręcznie na wszystkich urządzeniach jest niemal niemożliwe do realizacji, zajmowałoby kilka godzin oraz generowałoby bardzo dużą ilość potencjalnych błędów. Jak twierdził Zamawiający modyfikacja w oparciu o szablony konfiguracji pozwala na zastosowanie nowych ustawień w całym systemie Zamawiającego w czasie krótszym niż 15 minut i nie jest obarczona ryzykiem popełnienia błędu.

Zdaniem Izby Odwołujący nie podważył także twierdzeń Zamawiającego dotyczących możliwości utrzymania spójności i bezpieczeństwa systemu w zakresie poświadczeń oraz poziomów dostępu do systemu za pomocą kont domenowych.

W końcu Izba wskazuje, iż Odwołujący nie odniósł się do akcentowanej przez Zamawiającego kwestii serwisu pogwarancyjnego wskazując w szczególności, że

w przypadku gdy dostawy urządzeń będą wykonywane w kilku etapach i za każdym razem będzie to inny producent, to w efekcie Zamawiający będzie musiał utrzymywać kilka usług serwisowych, co z pewnością jest nieefektywne ekonomicznie, ale przede wszystkim organizacyjnie i technicznie.

Podsumowując powyższe Izba nie podzieliła stanowiska Odwołującego, iż Zamawiający nie wykazał uzasadnionych potrzeb w opisaniu przedmiotu zamówienia w sposób wskazany w SIWZ, dążąc do dopuszczenia do udziału w postępowaniu wykonawców oferujących produkty tylko jednego producenta. Podkreślić należy, iż zabrakło w stanowisku Odwołującego zaprezentowanym w toku rozprawy rzeczowej polemiki z Zamawiającym w przedmiocie uzasadnionych potrzeb w opisaniu przedmiotu zamówienia.

Wbrew twierdzeniom Odwołującego, Zamawiający w odpowiedzi na odwołanie przywołał szereg argumentów potwierdzających zasadność dostarczenia produktu, który będzie uwzględniał i spełniał jego obiektywnie uzasadnione potrzeby. Z kolei stanowisko Odwołującego w dużej mierze sprowadzało się do zmarginalizowali potrzeb Zamawiającego wyrażonych w opisie przedmiotu zamówienia, w miejsce żądania dopuszczenia rozwiązań i realizacji funkcjonalności w sposób oczekiwany przez Odwołującego.

Wziąwszy pod rozwagę powyższe Izba stwierdziła, że Odwołujący nie podważył uzasadnionych potrzeb Zamawiającego wyrażonych w opisie przedmiotu zamówienia i za nieuzasadnione uznała zarzuty naruszenia art. 29 ust. 1 i 2 w zw. z art. 7 ust. 1 ustawy Pzp.

Mając na uwadze powyższe orzeczono jak w sentencji.

O kosztach postępowania odwoławczego orzeczono na podstawie art. 192 ust. 9 i 10 ustawy Pzp, stosownie do wyniku postępowania. Na podstawie § 5 rozporządzenia Prezesa Rady Ministrów z dnia 15 marca 2010 r. w sprawie wysokości oraz sposobu pobierania wpisu od odwołania oraz rodzajów kosztów w postępowaniu odwoławczym i sposobu ich rozliczania (t.j. Dz. U. z 2018 r. poz. 972 ze zm.) do kosztów postępowania odwoławczego Izba zaliczyła w całości uiszczony wpis, zgodnie z § 3 pkt 1 rozporządzenia.

Przewodniczący

...................................

30