Wyrok KIO 2650/24 z 30 sierpnia 2024

Zamawiający – Komenda Główna Policji, ul. Puławska 148/150,02-624 Warszawa, prowadzi postępowanie w trybie przetargu nieograniczonego w celu zawarcia umowy ramowej pn. „Zawarcie umowy ramowej na dostawę urządzeń pełniących rolę Mobilnych Terminali Noszonych oraz licencji MDM”, numer referencyjny: 87/BŁiI/24/AL/DG. Ogłoszenie o zamówieniu zostało opublikowane w Dzienniku Urzędowym Unii Europejskiej w dniu 16.07.2024 r., nr 137/2024 4268742024.

W dniu 26.07.2024 r. do Prezesa Krajowej Izby Odwoławczej wpłynęły odwołania dwóch wykonawców:

A. Axians IT Solutions Poland sp. z o.o., ul. Postępu 21D, 02-676 Warszawa (dalej: Odwołujący Axians”) - KIO 2650/24, B. Orange Polska S.A., Al. Jerozolimskie 160, 02-326 Warszawa (dalej: „Odwołujący Orange”) - KIO 2651/24.

Odwołujący Axians zarzucił Zamawiającemu naruszenie art. 99 ust. 1, 4, 5 i 6 w zw. z art. 16 pkt 1) i 3) ustawy Prawo zamówień publicznych (t.j. Dz.U. z 2023 r. poz. 1605 ze zm.), zwanej dalej: „ustawą Pzp”, poprzez opisanie przedmiotu zamówienia w sposób niejednoznaczny, nieproporcjonalny, naruszający zasadę zachowania uczciwej konkurencji oraz równego traktowania wykonawców, niezapewniający możliwości zaoferowania równoważnego rozwiązania.

W szczególności Odwołujący Axians podniósł, co następuje.

„IV.1) [pkt VIII, ust. 8 ppkt. 8.6]

1. W pkt VIII, ust. 8 ppkt. 8.6 SW Z Zamawiający określił jeden z wymogów wypełnienia formularza ofertowego. Zgodnie z tym wymogiem wykonawca zobowiązany jest wskazać w formularzu ofertowym nazwę, nr wersji oraz wersję kompilacji systemu operacyjnego. (…)
2. O ile więc możliwe jest podanie nazwy i numeru wersji, o tyle wersja kompilacji systemu operacyjnego jest za daleko idącym, nieproporcjonalnym wymogiem. Ponadto do czasu dostarczenia urządzeń wersja ta z pewnością będzie ulegać kilkukrotnym zmianom. Należy wskazać, że zmiany te są pożądane, ponieważ m.in. zwiększają bezpieczeństwo. Z kolei ich utrzymanie jest nieproporcjonalnym i zbędnym, z punktu widzenia potrzeb Zamawiającego, wymogiem.
3. Z tego powodu Odwołujący wnosi o wykreślenie wymogu podania w formularzu ofertowym „wersji kompilacji systemu operacyjnego”.

IV.2) [pkt. IX, ust. 1]

1. We wskazanym postanowieniu Zamawiający określił warunek udziału w postępowaniu, dotyczący zdolności technicznej lub zawodowej - wykonania w okresie trzech lat przed upływem terminu składania ofert, a jeżeli okres prowadzenia działalności jest krótszy – to w tym okresie, jednej dostawy mobilnych urządzeń wyposażonych w interfejs komunikacyjny GSM o wartości minimum 3 000 000,00 złotych (słownie: trzy miliony złotych) brutto. (…)
2. W związku z tym Odwołujący wnosi o zapewnienie konkurencyjności w dostępie do zamówienia i zmianę warunku w tym zakresie bądź poprzez obniżenie wartości jednej dostawy do kwoty 2 mln zł brutto bądź pozostawienie kwoty 3 mln zł brutto lub nawet podwyższenie jej do 4 mln zł brutto, ale umożliwienie spełnienia tego warunku w ramach jednej umowy ramowej (niezależnie od ilości umów wykonawczych) – co będzie odpowiadać schematowi niniejszego postępowania. (…)
3. Odwołujący wnosi o zmianę wymogu poprzez pozostawienie samego określenia „dostawa mobilnych urządzeń” (bez określania ich wyposażenia) lub rozszerzenie możliwego wyposażenia mobilnych urządzeń w referencyjnej usłudze o np. skaner kodów kreskowych 1D lub 2D (wskazać należy, że dla Zamawiającego ten skaner jest istotną częścią urządzenia, zaplanował nawet testy pod kątem tej części) – dostawy mobilnych urządzeń wyposażonych w interfejs komunikacyjny GSM lub we wbudowany skaner kodów kreskowych 1D /2D. (…) IV.3) [pkt XIII, ust. 1]
4. W pkt. V, ust. 3 SW Z Zamawiający wskazał, że celem przeprowadzenia niniejszego postępowania jest wyłonienie maksimum dwóch (2) Wykonawców, z którymi zostanie zawarta umowa ramowa.
5. Jednocześnie w pkt. XIII, ust. 1 SWZ, w którym określono kryteria oceny ofert przy wyborze wykonawców do zawarcia umowy ramowej wskazano, że Zamawiający udzieli zamówienia Wykonawcy, którego oferta odpowiada wszystkim

wymaganiom określonym w ustawie Pzp i niniejszej SWZ oraz łącznie uzyska najwyższą liczbę punktów. (…)

1. W związku z tym, wykonawca wnosi o zmianę pkt XIII, ust. 1 SW Z, z której jednoznacznie będzie wynikać, że umowa ramowa zostanie zawarta maksymalnie z dwoma wykonawcami.

IV.4) [pkt XIII, ust. 2]

1. W pkt. XIII, ust. 2 SW Z Zamawiający określił kryteria oceny ofert i ich znaczenie w celu zawarcia umowy wykonawczej. Pozacenowym kryterium oceny ofert jest termin realizacji zamówienia wykonawczego (kryterium K3).
2. Zamawiający wskazał, że przyzna 1 punkt za każdy dzień skrócenia końcowego terminu realizacji umowy w stosunku do określonego przez niego w zaproszeniu maksymalnego terminu realizacji zamówienia (nie więcej niż 20 punktów).
3. Należy zwrócić uwagę, że w połączeniu z innymi postanowieniami zawartymi w dokumentacji zamówienia niemożliwym stanie się wypełnienie kryterium, które może zapewnić aż 20% oceny ofert. (…)
4. W praktyce wykonawca nie jest w stanie zabezpieczyć z wyprzedzeniem – ani samodzielnie, ani nawet wraz z producentem – zapasu urządzeń z obawy o to, że czas między produkcją a dostawą przekroczy 9 miesięcy, co spowoduje niezgodność dostarczonego przedmiotu z umową. Wykonawca nie tylko nie może samodzielnie trzymać tych urządzeń na magazynie (bo mogą ulec „przeterminowaniu” względem ww. postanowienia PPUW, a sprzedanie takiego urządzenia innemu zamawiającemu będzie wręcz niemożliwe), ale także nie może wcześniej dokonać ustaleń z producentem (nieznany czas dostawy i ilość zamawianych urządzeń). Oznacza to, że urządzenia muszą być zamawiane dla każdej umowy wykonawczej oddzielnie.
5. Wskazać należy, że urządzenia takie najczęściej są sprowadzane spoza Unii Europejskiej, co powoduje konieczność przeprowadzenie procedury celnej. To właśnie ta procedura i jej nieprzewidywalność czasowa uniemożliwia określenie (co do dnia) terminu dostawy urządzeń, a tym samym – otrzymanie aż 20% w pozacenowym kryterium oceny ofert K3.
6. Należy wskazać, że prowadzi to do nierównego traktowania wykonawców z niezależnych od nich przyczyn tj. od czasu w jakim zostanie dokonana odprawa celna, a której nie mogą dokonać wcześniej ze względu na brak jakiegokolwiek harmonogramu zamówień i bardzo krótki czas „ważności” urządzeń (9 miesięcy od jej produkcji).
7. Odwołujący (…) wnosi o wydłużenie minimalnego terminu realizacji umowy wykonawczej wskazanego w rozdziale VI SW Z, a także w §3 ust. 3 PPUR do 90 dni roboczych w przypadku dostaw powyżej 250 sztuk danego rodzaju urządzeń i do 60 dni roboczych w przypadku dostaw poniżej 250 sztuk danego rodzaju urządzeń, a dopiero alternatywnie o usunięcie kryterium K3.

IV.5) [pkt XIII, ust. 2, W42]

1. W tabeli w ust. 2 pkt XIII Zamawiający określił parametry pożądane urządzeń stanowiące kryterium pozacenowe oceny ofert. (…)
2. Zamawiający przyzna punkty za spełnienie każdej dodatkowej funkcjonalności określonej w zamieszczonej tam tabeli. Wskazany wymóg (W42) dotyczy kryterium mocy procesora i za jego spełnienie wykonawca może otrzymać aż 4 punkty (a więc 4% oceny oferty). Jest to więc szczególnie istotne kryterium. (…)
3. Odwołujący wnosi więc o przyznanie punktów w tym wymaganiu nie ze względu na sumę częstotliwości oferowanego procesora, ale na podstawie testu wydajności. Ponadto różnice (zarówno przy sumie częstotliwości, jak i w testach wydajności) mogą być minimalne i punktacja powinna to odzwierciedlać w celu równego traktowania wykonawców. Obecnie Zamawiający wymaga sumy częstotliwości 16 GHz (W41) – jest to warunek udziału w postępowaniu – i nie przyznaje za jego spełnienie punktów. Natomiast zaoferowanie procesora o sumie częstotliwości 17,5 GHz da wykonawcy już o 4 punkty więcej. Natomiast w żaden sposób nie są punktowani wykonawcy oferujący procesory z przedziału między 16 a 17,5 GHz.
4. W związku z tym Odwołujący wnosi o określenie zakresów wyników testów wydajności i przyznanie w zależności od tych wyników z zastosowaniem wzoru 4*(wydajność badanego urządzenia) / (największa osiągnięta wydajność spośród oferentów) kolejno 1, 2, 3 lub 4 punktów.
5. Ewentualnie w przypadku pozostawienia obecnego kształtu wymogów – przyznania 1 punktu za zaoferowanie procesora o sumie częstotliwości od 16.0 GHz do 16.2 GHz, następnie od 16.2 GHz do 16.8 GHz – przyznania 2 punktów, od 16.8 GHz do 17.5 GHz - przyznanie 3 punktów, powyżej 17,5 GHz przyznanie 4 punktów.

V.1) [udostępnienie projektu aplikacji DEMO TEST]

1. Odwołujący podnosi zarzuty wobec postanowień dotyczących przeprowadzenia testów akceptacyjnych (Warunki ogólne), a związanych z projektem aplikacji DEMO TEST.
2. W pierwszej kolejności należy wskazać, że Zamawiający nie określił precyzyjnie, kiedy nastąpi udostępnienie projektu aplikacji DEMO TEST dla wykonawców. W treści załącznika nr 9 do SW Z wskazano jedynie, że Zamawiający celem

przeprowadzenia możliwości oceny wykorzystania dostarczanych bibliotek wraz z interfejsem API udostępni projekt aplikacji DEMO TEST. Wykonawcy nie wiedzą, kiedy to udostępnienie nastąpi i ile będą mieć czasu na zapoznanie się z aplikacją i określenie kompatybilności aplikacji z oferowanym urządzeniem. (…)

1. Ponadto w tabeli B (wiersz 6) Zamawiający wskazał w kolumnie Oczekiwany rezultat testu: W projekcie nie została naruszona konfiguracja dotycząca dołączonych przez zamawiającego bibliotek, tj. nie zostały usunięte z projektu biblioteki oraz nie została zmieniona ich wersja.
2. Wskazać należy, że w tej samej „kratce” Zamawiający wskazał, że projekt aplikacji zawiera m.in. Gradle 7.3.3 oraz Android Gradle Plugin 7.2.1. Są już one przestarzałe. Obecnie istnieje Gradle 8.9, a wersja 7.3.3 pochodzi sprzed blisko 3 lat (grudzień 2021 r.), natomiast w przypadku Android Gradle Plugin jest obecnie w wersji 8.5, a wersja z projektu aplikacji ma blisko 2,5 roku (data premiery: maj 2022 r.). Ze względów bezpieczeństwa i kompatybilności wykonawca powinien mieć prawo aktualizacji tych bibliotek do najnowszej wersji. Brak aktualizacji może powodować problemy z działaniem lub nawet niedziałanie aplikacji. Tymczasem oczekiwanym rezultatem testu według Zamawiającego, jest to, żeby wersja tych bibliotek nie została zmieniona, co nie ma żadnego uzasadnienia.
3. Podkreślenia wymaga, że w projekcie aplikacji mogą być także inne biblioteki, które mogą być niekompatybilne z bibliotekami SDK lub nieaktualne. (…)
4. Ponadto Odwołujący wnosi o umożliwienie aktualizowania bibliotek i innych elementów projekt aplikacji, w przypadku, gdy istnieją ich nowsze wersje, co jest uzasadnione bezpieczeństwem działania aplikacji oraz uniknięciem problemów z kompatybilnością.

V.2) [powtórzenie testu]

1. W Warunkach ogólnych wskazano, że po uzyskaniu informacji o negatywnym wyniku testu wykonawca może zawnioskować o powtórzenie testu. Powtórzenie testu jest możliwe tylko w przypadku, gdy badana funkcjonalność istnieje, ale wynik jej sprawdzenia będzie inny niż opisany w rubryce „oczekiwany wynik testu”. Dodano również, że o możliwości powtórzenia testu decyduje Zamawiający. (…)
2. Odwołujący wnosi bądź o usunięcie testu i udostępnienie aplikacji, tak by każdy mógł samodzielnie sprawdzić jej kompatybilność z urządzeniem bądź o określenie obiektywnych kryteriów powtórki testu tj. każdy wykonawca ma prawo do jednokrotnego powtórzenia testu.

V.3) [parametry testu]

1. W Warunkach ogólnych przewidziano, że w trakcie wykonywania testów Zamawiający może zażądać sprawdzenia dowolnego wymaganego parametru, bądź funkcjonalności opisanej w Specyfikacji technicznej.
2. Należy zwrócić uwagę, że Zamawiający określił w tabelach w załączniku nr 9 jakie parametry będą badane, a całościowy opis warunków przeprowadzania testów wskazuje, że to wykonawcy muszą przygotować wszystkie niezbędne elementy do ich przeprowadzenia. Wykonawcy więc przygotowują się do odbycia testów określonych w scenariuszu.
3. Do sprawdzenia niektórych parametrów potrzebna jest specjalna aparatura lub specjalistyczna wiedza (np. do badania wytrzymałości na temperaturę – komora klimatyczna). W obecnym kształcie postanowień Zamawiający mógłby wymagać sprawdzenia tego parametru bez przygotowania się do takiego testu ze strony wykonawcy. Nie szukając tak daleko - nawet sprawdzenie wymiarów może być problematyczne, ponieważ nie przewidziano ich w testach, a wykonawca nie ma obowiązku nosić narzędzi do pomiaru urządzeń.
4. Prowadzi to także do nierównego traktowania wykonawców. Wszyscy muszą przejść testy określone w tabelach, ale przytoczone postanowienie pozwoli Zamawiającemu sprawdzić u jednego wykonawcy kilku dodatkowych parametrów, nieokreślonych w scenariuszu testów, na przeprowadzenie, których wykonawca nie musi być przygotowany, a u drugiego – żadnego.
5. W związku z tym Odwołujący wnosi bądź o usunięcie tego postanowienia, które pozwala Zamawiającemu na uznaniowe przeprowadzanie dalszych testów, niesprecyzowanych w załączniku nr 9. Ewentualnie o usunięcie tego postanowienia i wymienienie wszystkich parametrów, które Zamawiający chce zbadać, w tabelach w załączniku nr 9.

V.4) [stacja dokująca]

1. W OPZ Zamawiający definiuje zestaw MTN:
2. Z kolei w opisie testów Zamawiający przewiduje (m.in. w wierszu 7 tabeli A) sprawdzenie handstrapa ze stacją dokującą. Wyposażenie to w żadnym punkcie dokumentacji nie zostało wskazane jako wymagane do dostarczenia, natomiast ma być przedmiotem testów oferowanych urządzeń.
3. W związku z tym Odwołujący wnosi o doprecyzowanie czy w skład „Zestawu MTN” wchodzi handstrap ze stacją dokującą. Jeżeli tak – to o doprecyzowanie definicji w OPZ, jeżeli to – wykreślenie testów związanych z badaniem parametrów tych urządzeń.

V.5) [interfejs]

1. W wierszu 8 tabeli A w opisie testu wskazano sprawdzenie obecności wbudowanego interfejsu LAN i USB.
2. LAN i USB nie mogą działać jednocześnie w stacji dokującej. W danym czasie działa jedno albo drugie, a niemożliwym jest jednoczesne działanie. (…)
3. Mając to na uwadze Odwołujący wnosi o uściślenie, że Zamawiający uzna warunek za spełniony, jeżeli w danym czasie w stacji dokującej będzie działać jeden albo drugi interfejs, a nie oba jednocześnie. Ponadto wnosi o doprecyzowanie tabeli sprzętu w załączniku nr 2.

V.6) [odczyt dokumentów]

1. W wierszu 1 tabeli B określono, że odczyt dokonywany przez wbudowany w urządzenie czytnik kodów kreskowych musi być możliwy dla dokumentów w okładkach, w szczególności dowód rejestracyjny.
2. Wskazać należy, że okładki dokumentów, warunki oświetleniowe oraz kąt skanowania mają znaczący wpływ na możliwości odczytu kodu. Dlatego w celu równego traktowania wykonawców dokumenty w okładkach powinny być wykluczone lub Zamawiający powinien opisać precyzyjnie lub udostępnić wykonawcom okładkę testową i zapewnić wszystkim wykonawcom te same warunki oświetleniowe mające istotny wpływ na skanowanie.
3. Istotność tego postanowienia przejawia się tym, że niespełnienie tego warunku powoduje odrzucenie oferty wykonawcy.

V.7) [aplikacja KM SWD]

1. W wierszu 7 tabeli B Zamawiający opisuje test używając aplikacji KM SW D. Wskazać należy, że instalacja tej aplikacji następuje dopiero później (w ramach testów opisanych w tabeli C).
2. Na tym etapie test jest prowadzony przy użyciu aplikacji DEMO TEST i najprawdopodobniej w tabeli została popełniona omyłka pisarska.
3. Odwołujący wnosi o potwierdzenie, że w wierszu tym nie chodziło o aplikację KM SW D,a DEMO TEST, a w przypadku, gdyby rzeczywiście Zamawiający z jakiegoś powodu żądał już na tym etapie testu na niezainstalowanej aplikacji KM SWD – wykreślenie tego testu jako niemożliwego do spełnienia.

V.8) [tabela C]

1. Tabela C określa testy mające na celu sprawdzenie poprawności uruchomienia wspomnianej powyżej aplikacji KM SWD na oferowanym systemie operacyjnym.
2. Należy wskazać, że nie można stwierdzić, czy aplikacja będzie się poprawnie uruchamiać na oferowanym systemie operacyjnym. Zależy to od czynników, które nie są zależne od dostawcy urządzeń. (…)
3. Wpływ na wyniki testów ma także jakość oprogramowania, a nie oferowanego urządzenia. Podkreślenia wymaga, że szereg testów przewidzianych w tabeli C nie zależy od systemu operacyjnego oferowanego urządzenia, ale sposobu implementacji.
4. Ostatecznie także, oprogramowanie może być niekompatybilne z innymi urządzeniami, ponieważ było pisane (tworzone) pod inny, konkretny produkt i na nim testowane, bez uwzględniania różnic dla innych urządzeń.
5. Jak więc widać wykonawca z powodu wielu, niezależnych od siebie czynników, może nie uzyskać pozytywnego wyniku testów opisanych w tabeli C. Może to także być przejawem nierównego traktowania wykonawców, gdy którykolwiek z nich zdecyduje się zaoferować jako nowe urządzenia MTN takie same urządzenia, które ma już Zamawiający i na potrzeby, których była tworzona aplikacja, która będzie brała udział w testach. Dostęp do aplikacji ma też wykonawca, który realizował wcześniejsze zamówienie na dostawę urządzeń i oprogramowania.
6. Z tego względu Odwołujący wnosi o usunięcie testów określonych w tabeli C. Ewentualnie o rozbudowę aplikacji DEMO TEST o funkcjonalności wykorzystywane przez KM SW D, tak aby potencjalny wykonawca mógł dostosować konfigurację urządzenia lub wskazać błędy w udostępnionej aplikacji (aplikacja DEMO TEST udostępniana wykonawcom powinna testować te funkcjonalności, które Zamawiający chciał sprawdzić za pomocą KM SWD).

V.9) [instalacja aktualizacji]

1. Na wypadek nieusunięcia testów z tabeli C, Odwołujący podnosi także zarzuty wobec poszczególnych scenariuszy testowych.
2. W wierszu 8 tabeli C wskazano jako wymagany parametr, że aplikacja KM SW D ma możliwość instalacji nowszej wersji (aktualizacji) z wcześniej pobranego pliku APK do pamięci urządzenia.
3. Takie zachowanie aplikacji uznawane jest za niebezpieczne i w środowisku programistycznym traktowane jako zła praktyka. Nowe wersja Androida wręcz zabezpieczają przed taką aktualizacją. Skonfigurowanie sprzętu po to, by aplikacja mogła się samodzielnie aktualizować jest zagrożeniem bezpieczeństwa.
4. Podkreślić należy, że po to urządzenia MTN są wyposażone w MDM, by to oprogramowanie było odpowiedzialne (bez zbędnego ryzyka) za aktualizację KM SW D. Dopuszczanie, by działo się to automatycznie, z poziomu aplikacji jest po pierwsze zbędne, a po drugie – niebezpieczne.
5. Wobec powyższego Odwołujący wnosi o usunięcie tego wymogu.

V.10) [czas przejścia pomiędzy widokami]

1. W wierszu 11 tabeli C opisano scenariusz testowy mający na celu zbadanie parametru – przejścia pomiędzy widokami powinny być mniejsze niż około 1 sekundy”.
2. Zachowanie aplikacji w tym zakresie (czasu przejścia) jest w niewielkim stopniu zależne od urządzenia.
3. Podkreślenia wymaga, że wykonawca nie ma żadnego wpływu na sposób, w jaki jest napisana aplikacja, na której będą przeprowadzane testy, nie będzie jej dostosowywał, a może dojść do sytuacji, że sekwencja działań w aplikacji spowoduje dłuższe przejścia między ekranami. Ani urządzenie, ani tym bardziej wykonawca nie będą mieli na to wpływu, a przez to może dojść do odrzucenia jego oferty, co jest nieproporcjonalną sankcją za okoliczności, za które nie ponosi odpowiedzialności.
4. W związku z tym Odwołujący wnosi o usunięcie tego wymogu.

V.11) [sprawdzenie komunikacji do systemów centralnych]

1. W opisie testu w wierszu 1 tabeli D wskazano, że po włożeniu karty SIM i skonfigurowaniu APN w przeglądarce internetowej na urządzeniu zostanie wpisany i wywołany adres strony testowej [https://szum.app.policja].
2. Test zostanie zaliczony, jeżeli na urządzeniu wyświetli się strona testowa. Trzeba jednak wskazać, że APN może nie działać na urządzeniu z przyczyn niezależnych od tego urządzenia.
3. W celu sprawiedliwego przeprowadzenia tego testu koniecznym jest, by Zamawiający potwierdził, że testowana konfiguracja APN działa na innym urządzeniu zanim zrobi to wykonawca na swoim urządzeniu.
4. Właśnie o wprowadzenie takiego potwierdzenia do opisu testów wnosi Odwołujący.

V.12) [dodanie urządzenia do systemu]

1. W opisie testu z wiersza 2 wskazano: Instalacja z wykorzystaniem kodu QR, ADB, konta Google afw#famoc (komunikacja wi-fi do sieci Internet) lub instalowana z paczki umieszczonej na urządzeniu.
2. Po pierwsze opis testu stanowi wymienienie funkcjonalności MDM, a nie realnego opisu testu.
3. Po drugie, jeżeli traktować to jako opis testu to jest on niejednoznaczny. Czy instalacja wykonywana będzie wszystkimi wymienionymi sposobami czy może jednym wybranym. Jeżeli wybranym to czy nie ma konieczności zapewnienia instalacji z wykorzystaniem pozostałych sposobów, a także kto dokonuje tego wyboru – Zamawiający czy wykonawca.
4. W związku z tym Odwołujący wnosi o doprecyzowanie opisu testu w tym zakresie (czy wymagane jest zapewnienie tylko jednego sposobu instalacji czy wszystkich czterech; jeżeli czterech – czy będą testowane wszystkie czy jedno, kto wybiera to jedno; jeżeli jeden – kto wybiera ten jeden).

V.13) [integracja z Essentials MDM]

1. Wiersz 3 tabeli D opisuje wymagany parametr określony jako integracja z systemem Essentials MDM (Oprogramowanie Zarządzające).
2. Należy wskazać, że konfiguracji MDM (w tym przypadku Essentials MDM) można dokonać na wiele różnych sposób, z wyborem adekwatnego sposobu do danej sytuacji.
3. Wykonawca nie wie (z wyjątkiem tego, który dostarczył obecnie używane MDM) jaki sposób konfiguracji został wybrany. Nie ma możliwości sprawdzenia tego sposobu konfiguracji i ewentualnego dostosowania go pod nowe urządzenie. Może być tak, że obecny sposób nie będzie odpowiedni chociażby ze względu na zaoferowanie nowszej wersji Androida.
4. Oczywistym jest, że wykonawca nie może ponosić negatywnych konsekwencji w ramach testu na skutek nieujawnienia mu sposobu konfiguracji, który będzie mógł zweryfikować i dostosować do oferowanego rozwiązania.
5. W związku z tym Odwołujący wnosi o przekazanie wraz z dokumentacją zamówienia precyzyjnego opisu sposobu konfiguracji MDM w celu jego samodzielnego sprawdzenia przez wykonawcę wraz z zapewnieniem prawa do poprawienia konfiguracji. Ewentualnie, przy braku możliwości wprowadzenia takiej zmiany – usunięcie wymogu, ponieważ jego zachowanie prowadzi do nierównego traktowania wykonawców oraz uzależnia rezultat testu od czynników niezależnych od wykonawcy i oferowanego przez niego rozwiązania.

VI.1) [termin realizacji]

1. W §3 ust. 3 PPUR nie dokonano wystarczająco precyzyjnego określenia terminu na realizację dostawy. Z treści tego postanowienia wynika, że Wezwanie, w którym Zamawiający wskaże wielkość dostawy i rodzaj urządzenia oraz termin realizacji, nastąpi za pośrednictwem poczty elektronicznej wskazanej w ust. 8 pkt 1 lub platformy zakupowej. Termin realizacji umowy wykonawczej nie będzie krótszy niż 70 dni roboczych w przypadku dostaw powyżej 250 szt. Danego rodzaju urządzeń. Termin realizacji umowy wykonawczej nie będzie krótszy niż 40 dni roboczych w przypadku dostaw do 250 szt. danego rodzaju urządzeń.
2. W skrajnie niekorzystnej interpretacji tego postanowienia dla wykonawców, można uznać, że wskazany termin, nie krótszy niż 40 lub 70 dni jest liczony od dnia doręczenia wezwania.
3. Odwołujący wnosi o doprecyzowanie, że termin (nie krótszy niż 40 lub 70 dni roboczych) biegnie od daty zawarcia umowy wykonawczej.
4. Jednocześnie Odwołujący wskazuje, że powyżej wnosi o wydłużenie tych terminów. W przypadku uwzględnienia tego żądania zmianie oczywiście ulegnie również to postanowienie.

VI.2) [zmiana produktów]

1. W §8 ust. 2 pkt 2) PPUR określono zasady zmiany umowy ramowej w przypadku wprowadzenia przez producenta nowszych wersji urządzeń mobilnych i/lub oprogramowania lub innego produktu objętego umową. Zamawiający w takim przypadku dopuszcza zmianę produktów pod warunkiem, że jest to korzystne dla Zamawiającego, są one co najmniej tożsame funkcjonalnie, o parametrach co najmniej tożsamych lub lepszych niż zaoferowane w postępowaniu i spełnią wymagania określone w SWZ, a nie powodują zmiany ceny.
2. Wszystkie powyższe przesłanki z wyjątkiem „bycia korzystnym dla Zamawiającego” są mierzalne i weryfikowalne.

Natomiast przesłanka „korzyści” jest bardzo mocno uznaniowa i może spowodować, że Zamawiający nie wyrazi zgody na dostarczenie urządzeń tożsamych funkcjonalnie, o co najmniej tożsamych lub lepszych parametrach niż zaoferowane w postępowaniu, spełniających wymagania w SW Z i niepowodujące zmiany ceny, jedynie na podstawie nieweryfikowalnej podstawy. (…)

1. W związku z tym Odwołujący wnosi bądź o usunięcie fragmentu „jest to korzystne dla Zamawiającego” lub określenie weryfikowalnych przesłanek w tym zakresie.

VI.3) [zmiana cen]

1. W §8 ust. 3 lit. b) PPUR określono zasady zmiany cen jednostkowych brutto określonych w ofercie w przypadku zmiany miesięcznych wskaźników cen towarów i usług konsumpcyjnych ogłaszanych po zawarciu umowy ramowej. (…)
2. Taki sposób określenia klauzuli waloryzacyjnej przerzuca w ogromnej części ryzyko inflacyjne na wykonawcę. W przypadku wzrostu wskaźnika cen o 1% co miesiąc, zgodnie z powyższym postanowieniem, chociaż przez trzy lata wskaźnik cen wzrósłby o 42% wykonawcy nie przysługiwałaby umowna zmiana cen. Umowa nie przewiduje waloryzacji, gdy w skali półrocza inflacja nie przekroczy 7%. Może się zdarzyć, że w ciągu roku osiągnie nawet 10%, ale nadal nie umożliwi to zmiany cen. (…)
3. W świetle powyższego Odwołujący wnosi, by waloryzacja była zgodna z przytoczonym wzrostem / spadkiem wskaźników GUS za odpowiedni okres od ostatniej waloryzacji / podpisania umowy, a nie liczonych miesiąc do miesiąca. (…) VI.4) [odstąpienie od umowy ramowej]
4. W §9 ust. 1 PPUR Zamawiający przewidział możliwości wypowiedzenia przez niego Umowy ramowej ze skutkiem natychmiastowym. W pkt 5 tego postanowienia wskazano, że Zamawiający będzie miał taką możliwość, gdy Wykonawca nienależycie wykonał co najmniej jedną Umowę wykonawczą pod warunkiem, iż zwłoka z przyczyn leżących po stronie Wykonawcy w wykonaniu Przedmiotu umowy wyniosła co najmniej 10 dni roboczych w stosunku do terminu wykonania zawartej umowy, określonego w § 4 ust. 1 Umowy wykonawczej albo dwie Umowy wykonawcze pod warunkiem, iż w każdej z nich, zwłoka z przyczyn leżących po stronie Wykonawcy w wykonaniu Przedmiotu umowy wyniosło co najmniej 5 dni roboczych. (…)
5. Zwłoka 10 dni roboczych przy tak trudnych logistycznie dostawach, gdzie inne postanowienia dokumentacji zamówienia uniemożliwiają wcześniejsze przygotowanie urządzeń do dostawy (m.in. wymóg, by urządzenia były nie starsze niż 9 miesięcy w momencie dostawy), jest, niestety, bardzo możliwa i sankcja w postaci odstąpienia od umowy ramowej, ze skutkiem natychmiastowym, przy jednocześnie zastrzeżonych karach umownych z tytułu zwłoki jest zdecydowanie zbyt wygórowana.
6. W związku z tym Odwołujący wnosi o usunięcie tego punktu bądź wydłużenie terminów w nim zawartych odpowiednio do 30 dni roboczych w przypadku jednej umowy i 15 dni roboczych w przypadku dwóch umów.

VII.1) [instalacja i aktywacja oprogramowania]

1. Zgodnie z §1 ust. 5 PPUW - Na dostarczonym Sprzęcie wyodrębnionym i opisanym w Załączniku nr 1 do Umowy Wykonawca musi dokonać instalacji i aktywacji zakupionego oprogramowania.
2. Zakupionym oprogramowaniem jest również MDM, a to oznacza, że do obowiązków wykonawcy należy zainstalowanie MDM na urządzeniach.
3. Z doświadczenia wykonawcy wynika, że w celu przygotowania urządzeń do instalacji MDM konieczne jest otrzymanie od Zamawiającego m.in. kart SIM w celu aktywacji.
4. W związku z tym Odwołujący wnosi o dodanie postanowienia, że Zamawiający przekaże wykonawcy wszystkie niezbędne procedury, instrukcje, rzeczy (np. Karty SIM, jeśli są potrzebne do aktywacji MDM) na co najmniej 2 tyg. przed terminem dostawy lub 4 tyg. przed terminem dostawy, jeżeli zamówienie przekracza 2000 sztuk celem skonfigurowania poprawnie urządzeń.

VII.2) [rozporządzenie]

1. W §3 ust. 6 PPW U wskazano: Wykonawca jest zobowiązany do spełnienia wymogów w zakresie zapewnienia efektywności energetycznej dostarczanych urządzeń, wynikających z Rozporządzenia Parlamentu Europejskiego i Rady (W E) 106/2008 z dnia 15.01.2008 w sprawie wspólnotowego programu znakowania efektywności energetycznej urządzeń biurowych.
2. Podkreślenia wymaga, że zgodnie z treścią ww. rozporządzenia nie obejmuje ono terminali mobilnych, nie są one objęte specyfikacją: (…)
3. Wymaganie to dotyczy, jak widać na załączonym powyżej fragmencie rozporządzenia, komputerów biurowych, stacji roboczych, konsol do gier itd. (urządzeń większych gabarytowo). Nie dotyczy natomiast terminali mobilnych (urządzeń typu handheld) stanowiących przedmiot niniejszego zamówienia.
4. Z tego powodu wymóg ten powinien zostać wykreślony, ponieważ nie odnosi się on do dostarczanych urządzeń.

VII.3) [wersje systemu]

1. W §3 ust. 11 PPUW wskazano: W przypadku dostarczenia sprzętu z systemem innym niż Android w wersji nie starszej niż jedna iteracja w dół od ostatniego oficjalnego, publicznego wydania (obecnie wersje 12 i 13), Wykonawca dostarczy oprogramowanie z funkcjonalnościami zgodnymi z Klientem Mobilnym SW D Policji wraz z kodami źródłowymi oraz specyfikacją środowiska programistycznego (dot. zestawów MTN). (…)
2. W pierwszej kolejności należy wskazać, że ostatnią, publicznie wydaną wersją Androida jest wersja 14, niemniej na dniach ma zostać wydana wersja 15. Nieaktualny i sprzeczny pozostaje więc wymóg dotyczący możliwości dostarczenia sprzętu z systemem Android. W takim przypadku należy albo dostarczyć równoważne oprogramowanie z kodami źródłowymi (o powodach dlaczego to niezasadne – poniżej) lub liczyć się z tym, że w momencie dostawy ostatnimi wersjami będą w najlepszym przypadku wersje 14 i 15 (a może i późniejsze), a urządzenia w starszych wersjach, co może prowadzić do problemów z kompatybilnością.
3. Natomiast w drugim przypadku – w żadnym miejscu nie zostały opisane funkcjonalności aplikacji KM SW D.

Wykonawca nie wie więc, jakie funkcjonalności musi posiadać dostarczane, równoważne do Androida, oprogramowanie, które ma posiadać funkcjonalności zgodne z tą aplikacją. (…)

1. Z tego względu Odwołujący wnosi o usunięcie wskazanego postanowienia w całości. Ewentualnie o umożliwienie dostosowania oferowanej aplikacji za pomocą modyfikacji kodów źródłowych aplikacji KM SW D, dostarczonych przez Zamawiającego.

VII.4) [wysokość kar umownych]

1. W §7 ust. 2 lit. d) PPUW Zamawiający przewidział karę umowną za przekroczenie terminów określonych w ust. 11, 12 i 14 Warunków gwarancyjnych, a dotyczących czynności związanych z odpowiedzialnością gwarancyjną wykonawcy: (…)
2. Wskazać należy, że zastrzeżona w lit. c) kara z tytułu przekroczenia wymaganego czasu naprawy gwarancyjnej za każdy rozpoczęty dzień zwłoki wynosi 800 zł za każde urządzenie, a więc odnosi się do pojedynczego urządzenia.
3. Uzasadnionym byłoby określenie analogicznej kary w lit. d), a więc zmianę jej wysokości na 800 zł za każde urządzenie oraz dodanie, że jest ona naliczana za każdy dzień zwłoki.

VII.5) [odbiór jakościowy sprzętu]

1. W załączniku nr 2 do PPUW – Zasady odbioru Przedmiotu umowy (dalej: „Zasady odbioru”) w pkt II ust. 10 Zamawiający przewidział odbiór jakościowy urządzeń MTN na podstawie weryfikacji poprawności odczytu kodów MRZ, AZTEC, kodu kreskowego z prawa jazdy, weryfikacji uzyskania dostępu do Policyjnych Systemów Informatycznych za pomocą transmisji danych w prywatnym APN.
2. Należy wskazać na to, że Zamawiający przewidział na etapie ubiegania się o zamówienie szczegółowe testy, wśród których znalazły się również takie, których celem jest weryfikacja powyższych okoliczności. Brak jest jakichkolwiek argumentów za przeprowadzeniem ponownych testów, dla których nie zastrzeżono żadnych weryfikowalnych warunków przeprowadzenia, a także w jaki sposób wykonawcy mogą uzyskać w nim pozytywny rezultat.
3. Według własnego uznania Zamawiający może odrzucić dostawę urządzeń, które wcześniej zweryfikował precyzyjnie opisanymi, weryfikowalnymi testami.
4. Co istotne, gdy bez jasno określonych przyczyn Zamawiający odrzuci dostawę urządzeń, w dalszym ciągu biegnie termin dostawy, co może narazić wykonawcę na kary umowne, które mogą nie wynikać nie tylko z jego winy, ale jego działania bądź zaniechania, a jedynie uznania Zamawiającego. Takie sytuacje są oczywiście niedopuszczalne.
5. W związku z tym Odwołujący wnosi o usunięcie całego postanowienia dotyczącego ponownej możliwości odbioru jakościowego. Ewentualnie o wprowadzenie określonej procedury badania jakości jak np. dla nowych typów urządzeń, zgodnych z procedurą w postępowaniu wykonawczym.

VII.6) [warunki gwarancyjne]

1. Załącznik nr 3 do PPUW – Wymagania gwarancyjne (dalej: „Wymagania gwarancyjne”), jak wskazuje sama nazwa, określa warunki gwarancyjne na dostarczane urządzenia.
2. W ust. 4 Wymagań gwarancyjnych wskazano, że Gwarancja obejmuje wady materiałowe i konstrukcyjne, a także nie spełnienie deklarowanych przez producenta parametrów i/lub funkcji użytkowych, naprawę wykrytych uszkodzeń komponentów urządzeń w tym wymianę uszkodzonych podzespołów na nowe.
3. Postanowienie to jest nieprecyzyjne i nie pozwala określić zakresu odpowiedzialności gwarancyjnej wykonawcy. Nie określono czy gwarancji podlegają uszkodzenia mechaniczne albo uszkodzenia umyślne. Czy chodzi jedynie o wady materiałowe.
4. Koniecznym jest sprecyzowanie warunków odpowiedzialności gwarancyjnej, w tym jednoznaczne wykluczenie uszkodzeń mechanicznych i o to wnosi Odwołujący.

VII.7) [trzykrotne uszkodzenie]

1. W ust. 12 Wymagań gwarancyjnych określono, że trzykrotne uszkodzenie tego samego egzemplarza Sprzętu zaistniałe w okresie gwarancji obliguje Wykonawcę do wymiany tego sprzętu na nowy.
2. Ponownie taka forma postanowienia nie pozwala na określenie zakresu odpowiedzialności wykonawcy.

Postanowienie w obecnym kształcie nie pozwala jednoznacznie określić czy trzykrotne uszkodzenie ma dotyczyć tego samego komponentu czy mogą to być trzy uszkodzenia różnych elementów, czy do uszkodzeń zaliczają się również uszkodzenia mechaniczne lub uszkodzenia wyrządzone celowo (co wynika pośrednio z powyższego zarzutu).

1. Ponadto nawet wielokrotne uszkodzenia różnych elementów nie muszą jednoznacznie oznaczać, że produkt jest wadliwy i brak jest wtedy konieczności wymiany urządzenia.
2. W związku z tym Odwołujący wnosi o uściślenie warunków gwarancji, w tym wykluczenie uszkodzeń mechanicznych.

VIII.1) [wymóg W17]

1. Wymóg W17 określa długość działania urządzenia na jednym akumulatorze.
2. Wskazać należy, że po pierwsze – w wymogu W18 wskazano pojemność akumulatora i wydaje się zbędne określanie de facto tego samego parametru za pomocą dwóch wymogów.
3. Co jednak ważniejsze – opisany w wymogu W17 „test” żywotności akumulatora nie jest precyzyjny. Zamawiający wymaga pracy minimum 12 godzin przy założeniu włączonego ekranu przez 2h przy jasności 500NIT’s, włączonym GPS oraz włączonej transmisji danych min. GPRS.
4. Przede wszystkim nie określono co ma znajdować się na włączonym przez 2h ekranie, a dużą różnicą dla spadku energii z akumulatora powoduje czy będzie to wyświetlany ekran startowy, puszczony przez 2h film czy któraś z aplikacji.

Może to również prowadzić do nierównego traktowania wykonawców. Nie określenie tak istotnego punktu testu powoduje, że jeden z wykonawców może być poproszony o włączenie właśnie filmu, a inny – jedynie o pozostawienie ekranu włączonego na ekranie startowym.

1. W związku z tym Odwołujący wnosi bądź o usunięcie testu (pojemności akumulatora dotyczą kolejne wymagania, więc nie ma obawy, że Zamawiający nie będzie w stanie określić tego parametru) bądź o doprecyzowanie warunków testu wytrzymałości akumulatora.

VIII.2) [wymóg W44]

1. W wymogu W44 Zamawiający określił jako pożądany parametr funkcjonalność umożliwiająca odczyt tablic rejestracyjnych realizowana za pomocą czytnika kodów lub kamery tylnej (głównej) urządzenia.
2. Wymóg ten jest niejednoznaczny. Należy wskazać, że tablice rejestracyjne w zależności od kraju, gdzie zostały wydane mają różne czcionki / wielkości. Tworzone są oprogramowania do „czytania” tych tablic, ale Zamawiający winien uściślić, czy chodzi mu o odczytywanie polskich tablic rejestracyjnych, ewentualnie tych z terenu Unii Europejskiej czy wykonawcy mają dostarczyć w celu uzyskania dodatkowych punktów oprogramowanie, które będzie czytało więcej rodzajów tablic rejestracyjnych, co łączy się oczywiście z większymi nakładami pracy i czasu. Wymóg ten musi zostać uszczegółowiony, by zapewnić równą konkurencję.

VIII.3) [wymóg W45]

1. W wymogu tym wskazano, że urządzenie ma zapewniać wykonywanie połączeń głosowych w sieci GSM/4G na terytorium RP.
2. Oczywistym jest, że wykonawca nie ma wpływu na rodzaj (standard) używanej sieci do połączeń głosowych. Nie jest to zależy ani od urządzenia, ani od wykonawcy.
3. Koniecznym jest zmiana niniejszego wymogu na zapewnienie wykonywania połączeń głosowych w sieci komórkowej na terytorium RP.

VIII.4) [wymóg W83]

1. W wymogu W83 dotyczącym stacji dokujących i ładujących wskazano - ładowarka sieciowa wyposażona w podłączenie do sieci energetycznej z wtykiem europejskim (bez użycia adapterów).
2. Odwołujący wnosi o doprecyzowanie powyższego postanowienia. Między innymi w ładowarkach Apple ładowarki sieciowe mają wyciągane, wymienne piny. Stanowią one część ładowarki, ale można je samodzielnie wyciągnąć, włożyć.
3. Stąd konieczność uściślenia, że taki pin nie stanowi zakazanego adaptera, a przez użyte pojęcie chodzi o adaptery różnych standardów wtyków z jednego standardu wtyczki do innego, a nie adapter będący częścią ładowarki.

VIII.5) [wstępny test]

1. Na stronie 14 OPZ przedstawiono wymogi dotyczące wstępnego testu poprawnego działania aplikacji KM SW D na posiadanym przez Wykonawcę systemie operacyjnym.
2. W pierwszej kolejności należy zwrócić uwagę na postanowienie – Zamawiający umożliwi wykonanie wstępnego testu poprawnego działania aplikacji KM SW D na posiadanym przez Wykonawcę systemie operacyjnym wyłącznie w siedzibie Zamawiającego na pisemny wniosek Wykonawców złożony nie później niż na 10 dni od dnia publikacji postępowania na Platformie zakupowej. Wykonawca do przeprowadzenia wstępnego testu dostarczy do zamawiającego maksymalnie 2 urządzenia wraz z ładowarką nie później niż na 5 dni przed datą wyznaczonych testów.
3. Należy zwrócić uwagę, że postanowienie te na wiele sposobów prowadzi do nierównego traktowania wykonawców, a także utrudnia im złożenie oferty niepodlegającej odrzuceniu. (…)
4. Najlepszym rozwiązaniem w niniejszej sytuacji jest usunięcie wstępnego testu KM SW D oraz całej metodologii testów aplikacji, na co wskazywano w zarzutach powyżej, oraz rozbudowanie aplikacji DEMO TEST udostępnianej przez Zamawiającego wykonawcom o funkcjonalności wykorzystywane przez KM SW D, tak aby potencjalny wykonawca mógł samodzielnie sprawdzić kompatybilność i dostosować konfigurację urządzenia lub wskazać błędy w udostępnionej aplikacji, bez ujawniania innym podmiotom o kształcie swojej oferty. O taką zmianę w dokumentacji wnosi Odwołujący. (…) VIII.6) [tabela wymagań MDM]
5. Na stronie 18 OPZ rozpoczyna się cały rozdział dotyczący licencji do posiadanego przez Zamawiającego oprogramowania MDM. To właśnie tutaj objawia się najpełniej zarzut niezapewnienia przez Zamawiającego możliwości zaoferowania rzeczywistego rozwiązania równoważnego. Opis wymagań uniemożliwia zaoferowanie innych licencji niż licencji do posiadanego już przez Zamawiającego oprogramowania Essentials MDM.
6. Zamawiający wskazuje, że dostarczane licencje muszą zapewniać pełną współpracę z posiadanym przez Zamawiającego oprogramowaniem MDM Essentials MDM w wersji 5.33 lub nowszej oraz dostarczane licencje muszą integrować się z posiadaną przez Zamawiającego infrastrukturą systemową zawierającą serwery zarządzające oparte na oprogramowaniu Essentials MDM.
7. Tylko Essentials MDM jest w stanie zapewnić „pełną współpracę” oraz „integrację” z infrastrukturą zawierającą serwery zarządzające oparte na Essentials MDM. Istnieją dziesiątki oprogramowani MDM, ale one nie współpracują ze sobą. Oznacza to, że wymóg zapewnienia współpracy z danym oprogramowaniem jednoznacznie powoduje, że wykonawca musi dostarczyć właśnie to oprogramowanie. W ten sposób, chociaż oprogramowanie nie jest wskazane wprost z nazwy, to tak ukształtowane postanowienie powoduje, że jedynym oprogramowaniem spełniającym wszystkie wymogi jest Essentials MDM.
8. Co więcej wymienione w tabeli funkcjonalności MDM są wprost skopiowane z dokumentu „Techstep Essentials MDM. Matryca funkcjonalności”, czyli dokumentu opisującego funkcjonalności Essentials MDM. Zamawiający więc nie opisał rzeczywiście wymaganych funkcjonalności, niezbędnych mu, a skopiował te, które posiada użytkowane przez niego oprogramowanie Essentials MDM. (…)
9. Takie opisanie przedmiotu zamówienia stwarza jedynie pozór możliwości zaoferowania jakiegokolwiek innego oprogramowania, niż to, posiadane przez Zamawiającego.
10. Zamawiający powinien wprost określić, że wymaga dostarczenia Essentials MDM (co obecnie jest jedyną możliwością) lub oprogramowania równoważnego i określić te parametry równoważności w rzeczywisty sposób (a nie opisujący Essentials MDM), tak by uczynić zadość postanowieniom art. 99 ust. 5 i 6 Pzp.
11. Wskazać też należy, że wymieniona lista funkcjonalności systemu MDM nie tylko jest przepisana z dokumentu dotyczącego konkretnego oprogramowania i jest spełniania tylko przez to jedno oprogramowanie, ale wymienia funkcje charakterystyczne dla Essentials MDM bez wskazania co one oznaczają, jaką funkcjonalność zapewniają, tak by było możliwe jej spełnienie przez inne oprogramowanie.
12. Lista musi opisywać wymagane funkcjonalności oraz integracji, które mają być stosowane z zakupionymi

urządzeniami, a nie wymieniać (często jedynie z nazwy np. Smart Group, lub ogólnikowo – „konfigurowany branding”) funkcjonalności z karty posiadanego już oprogramowania. (…)

1. Ponadto należy wskazać, że w OPZ nie wymieniono w żaden sposób funkcjonalności związanych z tymi integracjami.
2. Końcowo podkreślenia wymaga, że funkcjonalności w tabeli „Funkcjonalności” posiadają także opisy specyficzne i nawet nie istniejące (Apple zero-touch). Oczywistym jest więc, że wskazana tabela nie jest opisem stosowanych obecnie rozwiązań u Zamawiającego i nie stanowi jego rzeczywistych potrzeb.
3. Mając to na uwadze Odwołujący wnosi o wprowadzenie postanowień zapewniających możliwość dostarczenia oprogramowania równoważnego do Essentials MDM, które przy obecnym kształcie postanowień jest jedynym możliwym produktem do zaoferowania przez wykonawców, co utrudnia uczciwą konkurencję. Ponadto Odwołujący wnosi o wykreślenie wszystkich niestosowanych technologii, integracji (niepotrzebnych Zamawiającemu, a stanowiących jedynie pozorny wymóg, utrudniający złożenie oferty) oraz wprowadzenie rzeczywistych opisów funkcjonalności. (…)” Odwołujący Orange zarzucił Zamawiającemu naruszenie:
4. art. 99 ust. 1, ust. 4 w zw. z art. 101 ust. 1 pkt 1 w zw. z art. 16 pkt 1, 2 i 3 ustawy Pzp poprzez opisanie przedmiotu zamówienia w sposób nieprzejrzysty, niejednoznaczny i niewyczerpujący, w tym poprzez określenie wymagań w zakresie funkcjonalności w sposób nieprecyzyjny, nadmiarowy, nieuzasadniony obiektywnymi potrzebami Zamawiającego, bez uwzględnienia wszystkich wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty, a przy tym w sposób, który mógłby utrudniać uczciwą konkurencję uprzywilejowując poszczególnych wykonawców,
5. art. 99 ust. 2 i 4, w zw. z art. 16 pkt 1 i 3 w zw. z art. 353 1 kc oraz art. 5 kc w zw. z 8 ust. 1 ustawy Pzp poprzez opisanie przedmiotu zamówienia w sposób nieproporcjonalny, nieuzasadniony obiektywnymi potrzebami Zamawiającego oraz w sposób, który mógłby utrudniać uczciwą konkurencję, a także poprzez wprowadzenie do SW Z postanowień w sposób rażąco naruszający równowagę kontraktową stron, przerzucając na wykonawców ryzyka kontraktowe, w tym wynikające z okoliczności niezależnych od wykonawcy lub zależnych od Zamawiającego, sprzeciwiając się tym samym naturze stosunku zobowiązaniowego oraz zniechęcając wykonawców do składania ofert w postępowaniu i ograniczając konkurencję.

W szczególności Odwołujący Orange podniósł, co następuje.

„1a) Zarzut dotyczący aplikacji KM SWD - Wymagania systemu operacyjnego w zakresie aplikacji KM SWD Jak wspomniano Zamawiający nie wskazał wprost w OPZ w części dotyczącej systemu operacyjnego jaki system ma być zainstalowany na urządzeniach MTN. Jednocześnie obok dziesiątek wymagań co do samego systemu operacyjnego wskazanych w tabeli w załączniku OPZ Zamawiający dodał wymaganie o kodzie W S9:System operacyjny musi umożliwiać uruchamianie w jego środowisku aplikacji KM SWD. (…) Jak wskazano powyżej Zamawiający opisując wymagania systemu operacyjnego urządzenia MTN, jako jedną z jego „funkcjonalności” wskazał poprawne działanie Aplikacji KM SW D precyzując tę funkcjonalność systemu operacyjnego bardzo szerokim opisem funkcjonalności samej aplikacji KM SW D. Co istotne dysponentem aplikacji KM SW D jest Zamawiający. Odwołujący nie ma faktycznej możliwości zweryfikowania na dowolnym etapie przed składaniem ofert czy zaoferowane przez niego urządzenie z systemem operacyjnym umożliwia działanie aplikacji KM SW D w pełnym zakresie opisanym przez zamawiającego w teście akceptacyjnym. Zamawiający w treści SW Z/OPZ nie przedstawia jakiejkolwiek specyfikacji technicznej aplikacji KM SW D (poza informacją o jej kompatybilności z systemem Android), poprzestając na wskazaniu jej funkcjonalności. Jednak sam opis funkcjonalności tej aplikacji w żaden sposób nie pozwala wykonawcom na ocenę czy aplikacja ta będzie funkcjonowała w ramach zaoferowanego systemu operacyjnego urządzenia. Co więcej także przewidziane w OPZ testy wstępne (o czym w dalszej części odwołania) nie pozwalają Odwołującemu ocenić czy zaoferowanego przez niego urządzenie z oprogramowaniem spełni te wszystkie wymagania. (…) Jednakże biorąc pod uwagę treść pozostałych wymagań OPZ Odwołujący nie może mieć pewności czy aplikacja KM SW D – która przecież nie jest przedmiotem tego Postępowania - jest rzeczywiście w pełni kompatybilna z systemem Android, czy też być może do jej poprawnego działania wymagane są jakieś dodatkowe prace programistyczne, integratorskie, adaptacyjne, bez których nie będzie działała lub nie będzie działała poprawnie w zakresie każdej z wymaganych funkcjonalności. Takie sformułowanie warunków Postępowania w sposób oczywisty promuje te podmioty, które obecnie świadczą usługi na rzecz Zamawiającego i mają dostęp do przedmiotowej aplikacji KM SW D, jak również te podmioty, które napisały to oprogramowanie dla Zamawiającego lub posiadają prawa autorskie do tego oprogramowania. Powyższe rodzi także ryzyko prowadzenia postępowania bez zachowania zasady uczciwej konkurencji i równego traktowania wykonawców niezasadnie promujące te podmioty. Nie sposób uznać, aby opis

wymagań dotyczący przedmiotu zamówienia był w tym zakresie jednoznaczny i wyczerpujący skoro nie uwzględnia informacje dotyczących aplikacji KM SW D, mających wpływ na sporządzenie oferty. Podane w SW Z/OPZ parametry techniczne aplikacji KM SW D, jak i jej funkcjonalności nie są na tyle precyzyjne , aby umożliwiły wykonawcom ustalenie produktu, który będzie spełniał wszystkie wymagania – funkcjonalności aplikacji KM SW D determinują funkcjonalność systemu operacyjnego, których na bazie posiadanych informacji, nie jest w stanie odpowiednio zweryfikować Wykonawca przed złożeniem oferty. (…) W związku z powyższym, jak i z uwzględnieniem dalszej argumentacji w zakresie wskazanym w pkt 1-3 powyżej, które to kwestie są powiązane z aplikacją KM SWD, Odwołujący wnosi o dokonanie modyfikacji SWZ:

1. poprzez usunięcie z treści dokumentacji Postępowania jakichkolwiek wymogów odnoszących się do aplikacji KM SW D, w zakresie w jakim postanowienia te mają wpływ na ocenę spełniania przez zaoferowane przez wykonawców urządzenia/oprogramowanie warunków Postępowania;
2. ewentualnie poprzez udostępnienie wykonawcom, przed terminem składania ofert, dokumentacji technicznej lub kodów źródłowych aplikacji KM SW D, w sposób i terminie umożliwiającym wszystkim uczestnikom równą i realną możliwość weryfikacji spełniania poszczególnych wymagań przez oferowane przez nich rozwiązanie w odniesieniu do aplikacji KM SWD, i dostosowanie w tym zakresie postanowień SWZ; - Testy wstępne Zamawiający prawdopodobnie w próbie uniknięcia zarzutu o niezgodne z prawem zamówień publicznych stawianie wykonawcom warunków dotyczących spełniania przez oferowane przez nich urządzenie/oprogramowanie wymagań dotyczących aplikacji KM SW D (opisanych we wcześniejszej części Odwołania), przy jednoczesnym braku przekazania wykonawcom jakichkolwiek danych technicznych, czy kodów źródłowych tej aplikacji umożliwiających zweryfikowanie możliwości spełnienia tych wymagań, wprowadził do SW Z możliwość przeprowadzenia testów wstępnych. (…) Tym samym testy wstępne w żaden sposób nie są wstanie potwierdzić wykonawcom, że oferowane przez nich urządzenie z zainstalowanym na nim systemem operacyjnym jest w stanie zapewnić poprawne działanie aplikacji KM SW D w pełnym zakresie. Skoro wykonawcy nie są w stanie tego zweryfikować na etapie testów wstępnych to nie będą posiadali tej wiedzy także na etapie składania ofert. Nie są więc w stanie w sposób racjonalny ocenić ryzyka związanego ze składaną ofertą. Nie wiadomo także jak w takiej sytuacji Wykonawcy mają złożyć oświadczenie, że oferowany przez nich produkt spełnia wymagania SWZ. (…) W zakresie testów wstępnych Odwołujący pragnie zwrócić uwagę na jeszcze jedno postanowienie, które w sposób oczywisty narusza zasady zachowania uczciwej konkurencji oraz równego traktowania wykonawców. Zarzut ten dotyczy sposobu przeprowadzenia testów wstępnych wskazany przez Zamawiającego (str. 14 OPZ):

Jednocześnie Zamawiający informuje, że wstępny test będzie miał charakter łączony tzn. dla wszystkich wykonawców jednocześnie, z zastrzeżeniem, że w przypadku dużej liczby wykonawców z przyczyn logistycznych spotkanie zostanie podzielone na kilka sal konferencyjnych.

Wprowadzenie przez Zamawiającego łączonego charakteru testu wstępnego oznacza, że każdy z potencjalnych oferentów, który będzie chciał przetestować swoje urządzenie będzie przed złożeniem ofert, a jednocześnie każdy z potencjalnych konkurentów uczestniczących w tych testach będzie mógł poznać jaki model i markę urządzenia dany Wykonawca będzie chciał zaoferować. To pozwoli konkurentom oszacować ofertę wykonawcy, który chcąc chociaż w minimalnym zakresie zweryfikować swój produkt w kontekście funkcjonalności aplikacji KM SW D będzie musiał przedłożyć do testów urządzenie, które będzie docelowo oferował. Dodatkowo podmiot, który ma wiedzę na temat funkcjonowania aplikacji KM SW D i nie potrzebuje testowania pod tym kątem swojego urządzenia może przystąpić do testów z dowolnym urządzeniem. Dzięki temu nie ujawni on pozostałym oferentom swoich planów co do oferowanego urządzenia. To wszystko powoduje, że podmioty te mogą zdobyć dzięki tak zorganizowanym testom wstępnym ogromną przewagę nad Odwołującym co do warunków składania ofert. Będą mogli oni na etapie składani ofert oszacować z dużym prawdopodobieństwem wartość minimalną oferty wykonawcy, który przystąpił do wstępnych testów.

W związku z powyższym Odwołujący, niezależnie od żądania sformułowanego w zakresie Zarzutu 1a tiret pierwszy, wnosi o dokonanie modyfikacji SWZ poprzez:

1. usunięcie postanowień OPZ w zakresie przeprowadzenia testów wstępnych lub taką ich modyfikację, aby testy wstępne odpowiadały 1:1 co do swojego zakresu testom akceptacyjnym;
2. usunięcie postanowień dotyczących OPZ zgodnie z którymi test wstępny będzie miał charakter łączny. - Testy akceptacyjne Testy akceptacyjne (weryfikacyjne) mają zostać przeprowadzone zgodnie z Załącznikiem nr 9 do SW Z. W ramach tych testów Zamawiający ma dokonać m. in. sprawdzenia możliwości zastosowania dostarczanych bibliotek w istniejącej aplikacji KM SW D wraz z niektórymi funkcjonalnościami dostarczanego urządzenia oraz sprawdzania poprawności

uruchomienia aplikacji KM SW D na oferowanym systemie operacyjnym. Odwołujący już we wcześniejszej części niniejszego Odwołania podawał przyczyny, dla których aplikacja KM SW D nie powinna być elementem warunków niniejszego Postępowania. W tym miejscu chciałby po raz kolejny podkreślić, że Zamawiający na tym etapie (czyli po złożeniu ofert) chce weryfikować, czy zaoferowane produkty spełniają wymagania dotyczące funkcjonalności aplikacji KM SW D, jednocześnie w żaden sposób nie zapewniając wykonawcom przed złożeniem oferty, danych (dokumentów, kodów, specyfikacji, oprogramowania testowego) umożliwiających zweryfikowanie czy oferowane urządzenie rzeczywiście spełnia te wymagania.

Ponadto jak już wspomniano zakres tych testów akceptacyjnych jest znacząco różny od testów wstępnych co uniemożliwia poprawne przygotowanie oferty, tak aby chociaż uprawdopodobnić uzyskanie pozytywnego wyniku w ramach testów akceptacyjnych. Takie przygotowanie Postępowania w oczywisty sposób promuje wykonawcę, którego dostarczał już urządzenia objęte niniejszym Postępowaniem i ma wiedzę na temat aplikacji KM SW D lub dostarczył samą aplikację KM SWD i będzie się ubiegał także o to zamówienie.

Jednym z elementów przeprowadzenia testów akceptacyjnych jest aplikacja DEMO TEST. Aplikacja ta ma być dostarczona poszczególnym wykonawcom przez Zamawiającego. Jednakże także w tym zakresie postanowienia Opisu testów i ich ocen zawartych w załączniku nr 9 do SW Z nie zapewniają, że wykonawcy będą traktowani w równy sposób, z poszanowaniem zasady uczciwej konkurencji. W postanowieniach tych nie ma żadnych zapisów, które gwarantowałyby wykonawcom, że:

1. aplikacja DEMO TEST zostanie przekazana przez Zamawiającego wszystkim Oferentom jednocześnie;
2. wezwanie do zdeponowaniu urządzeń do testowania zostanie przekazane wszystkim Oferentom jednocześnie.

Zamawiający w ogóle nie odnosi się do kwestii przekazania aplikacji DEMO TEST. Tymczasem aplikacja ta jest niezwykle istotna dla „zaliczenia” testów akceptacyjnych. Podmiot, który wcześniej ją otrzyma lub dłużej będzie mógł ją testować będzie miał nieuzasadnioną przewagę konkurencyjną nad pozostałymi podmiotami. Zamawiający wskazuje jedynie, że W terminie 3 dni od wezwania przez Zamawiającego Wykonawcy zdeponują we wskazanej przez Zamawiającego lokalizacji w Warszawie kompletny Zestaw MTN oraz zmodyfikowany projekt aplikacji DEMO TEST zawierającej implementacje dostarczanych bibliotek zapisany na nośniku CD/DVD/USB do testów w zaplombowanych (np. taśmą klejącą Wykonawcy) opakowaniach transportowych. Pozostawienie w tym zakresie wyłącznie terminu na zdeponowanie urządzeń od daty wezwania w żaden sposób nie gwarantuje uczestnikom Postępowania równego traktowania – Zamawiający może w dowolnym i różnym dla poszczególnych wykonawców momencie udostępnić aplikację DEMO TEST, jak i może w dowolnym i różnym dla poszczególnych wykonawców momencie wezwać do zdeponowania urządzeń, de facto decydując ile czasu dać poszczególnym wykonawcom na przygotowanie urządzeń od testów. Odwołujący podkreśla, że Zamawiający wymaga złożenia przez wykonawców zmodyfikowanego projektu aplikacji DEMO TEST. Wykonawca nie zna tej aplikacji, nie wie jaki zakres prac do jej modyfikacji będzie konieczny, jednocześnie oczywistym jest, że każdy podmiot, który będzie miał więcej czasu na przygotowanie zmodyfikowanej aplikacji DEMO TEST osiągnie przewagę konkurencyjną względem tych podmiotów, których czas zostanie ograniczony.

Niestety obecne postanowienia SWZ umożliwiają całkowicie dowolne różnicowanie oferentów w tym zakresie.

Dodatkowo w ramach przeprowadzania testów Zamawiający zastrzegł dla siebie prawo do dowolnego różnicowania poszczególnych oferentów. Mianowicie, w przypadku gdy zachodzi konieczność powtórzenia testu to Zamawiający dowolnie decyduje o możliwości powtórzenia testu – przy czym możliwość ta nie jest ograniczona co do ilości powtórzeń. Zgodnie z załącznikiem nr 9 do SWZ:

Po uzyskaniu informacji od Zamawiającego o negatywnym wyniku testu Wykonawca najpóźniej w kolejnym dniu roboczym może zawnioskować o powtórzenie testu. O możliwości powtórzenia testu decyduje Zamawiający.

Tym samym Zamawiający może zezwolić preferowanemu przez siebie oferentowi powtarzać testy dowolną ilość razy aż do uzyskania pozytywnego wyniku, jednocześnie odmawiając prawa do powtórzenia testu innym oferentom. Jest to jawne naruszenia zasad przejrzystości, zachowania uczciwej konkurencji jak i równego traktowania wykonawców.

W związku z powyższym Odwołujący, niezależnie od żądania sformułowanego w zakresie Zarzutu 1a tiret pierwszy, wnosi o dokonanie modyfikacji SWZ poprzez:

1. usunięcie postanowień OPZ w zakresie przeprowadzenia testów akceptacyjnych w zakresie: Sprawdzenie możliwości zastosowania dostarczanych bibliotek w istniejącej aplikacji KM SW D wraz z niektórymi funkcjonalnościami dostarczanego urządzenia oraz w zakresie sprawdzania poprawności uruchomienia aplikacji KM SW D na oferowanym systemie operacyjnym lub taką ich modyfikację, aby testy akceptacyjne w tym zakresie odpowiadały 1:1 zakresowi testu wstępnego, a zarazem gwarantowały wszystkich uczestnikom jednakowe (zarówno co do zakresu i jak i terminu) warunki uczestnictwa w teście (w szczególności dostęp do oprogramowania testowego);
2. usunięcie postanowień dotyczących OPZ, zgodnie z którymi Zamawiający jest uprawniony do jednostronnego,

dowolnego decydowania o tym czy zostanie ponownie przeprowadzony test akceptacyjny. - wymagań dostarczenia biblioteki wraz z API Konsekwencją odwoływania się przez Zamawiającego do aplikacji KM SW D w ramach wymagań dotyczących przedmiotu zamówienia jest wskazanie, że API dostarczane przez wykonawcę wraz z bibliotekami mają zapewniać odpowiednią interakcję z aplikacją KM SW D. Dotyczy to wymagań dostarczenia biblioteki wraz z API, której interfejs umożliwi implementację w aplikacji KM SW D (wymagania wskazane w OPZ w kodach wymagań nr: W43, W44, W47, W48, W50, W CB22) lub odczytanie danych w tej aplikacji (W S23). Zamawiający nie przekazuje jednak na żadnym etapie Postępowania jakichkolwiek danych dotyczących aplikacji KM SW D, które umożliwiałyby Odwołującemu na ustalenie czy dostarczone API będą zapewniały wymaganą implementację lub odczytywanie danych z tej aplikacji. Oczywistym jest, że w związku z tym w uprzywilejowanej sytuacji jest podmiot który ma już wiedzę na temat: albo dostarczał już urządzenia na rzecz Zamawiającego i integrował je z aplikacją KM SW D, albo przygotowywał tą aplikację dla Zamawiającego. Tym samym postanowienia te po raz kolejny promują w sposób nieuzasadniony wybranych wykonawców mających dostęp do aplikacji KM SWD.

W związku z powyższym Odwołujący, niezależnie od żądania sformułowanego w zakresie Zarzutu 1a tiret pierwszy, wnosi o dokonanie modyfikacji SW Z poprzez usunięcie w zakresie dostarczonych API wymaga odwołujących się bezpośrednio do aplikacji KM SWD.

1b) Zarzut dotyczący wymagań dotyczących Licencji - definicja „oprogramowania” Obok urządzeń MTN wraz z akcesoriami i oprogramowaniem systemowym przedmiotem Postępowania jest także dostawa licencji MDM (Mobile Device Management) czyli oprogramowania umożliwiającego zarządzanie urządzeniami mobilnymi. Zamawiający posiada oprogramowanie Essentials MDM (wcześniej znane jako Famoc Manage) firmy Techstep Poland (dawniej Famoc S.A.) i oczekuje de facto dostawy analogicznych licencji MDM.

Powyższą definicję MDM Zamawiający umieścił m. in. w Umowie wykonawczej (analogicznie zdefiniował ten zakres dostawy w Umowie ramowej oraz OPZ). Jest to jedyna definicja w Umowie wykonawczej odnosząca się wprost do oprogramowania lub licencji jako przedmiotu dostawy. Jednocześnie w samej Umowie Wykonawczej Zamawiający wielokrotnie posługuje się samym pojęciem „oprogramowanie” nie definiując go. Co więcej pojęcie „oprogramowanie” służy Zamawiającemu do opisu Przedmiotu dostawy realizowanego w ramach tej Umowy Wykonawczej (§ 1 ust. 3 tej Umowy): (…) Inaczej niż w pozostałych dokumentach przedmiot dostawy nie został opisany poprzez zdefiniowane pojęcia (MDM, Zestaw MTN, MTN), lecz przez niezdefiniowane pojęcie „oprogramowanie”: - W § 1 ust. 3 pkt. 2 Umowy wykonawczej Zamawiający żąda instalacji i aktywacji na dostarczonym sprzęcie zakupionego oprogramowania oraz przekazania dokumentów licencji do oprogramowania; - W § 1 ust. 3 pkt. 4 Umowy wykonawczej Zamawiający żąda dostarczenie licencji na oprogramowanie standardowe, w tym przekazania dokumentów licencji, - W § 1 ust. 3 pkt. 5 Umowy wykonawczej Zamawiający żąda udzielenie i dostarczenie dokumentów licencji umożliwiających zarządzanie dostarczonymi urządzeniami MTN, licencji na oprogramowanie bibliotek urządzeń mobilnych (dot. MTN i czytnika linii papilarnych) Zamawiający nigdzie nie precyzuje czym jest oprogramowanie standardowe wskazane w § 1 ust. 3 pkt 4 oraz czym różni się od oprogramowania wskazanego w § 1 ust. 3 pkt 2 Umowy ramowej. Czy Zamawiającemu chodzi w tym opisanym zakresie o Licencje MDM, czy może licencję dla oprogramowania systemowego urządzeń MTN, a może jeszcze o inną licencję na oprogramowanie, którego nie wskazał wprost w wymaganiach? (…) Opis ten dotyczy bezpośrednio przedmiotu dostawy realizowanego w ramach Postępowania i jako taki musi być precyzyjny i zgodny z warunkami całego Postępowania. Przy takim opisie Przedmiotu zamówienia jak zawarto w § 1 ust.

3 Umowy ramowej wykonawcy nie mogą mieć pewności czy zrealizowane przez nich dostawy będą zgodne z tym czego oczekuje na podstawie Umowy wykonawczej Zamawiający. Jest to o tyle istotne, że zgodnie § 3 ust. 4 pkt 1 Umowy wykonawczej Wykonawca oświadcza oraz gwarantuje, iż Sprzęt i oprogramowanie są zgodne z Umową i realizują wszystkie funkcjonalności opisane w Załączniku nr 1 do Umowy.

W związku z powyższym Odwołujący, wnosi o dokonanie modyfikacji SW Z poprzez doprecyzowanie przez Zamawiającego sformułowania „oprogramowanie”/ „oprogramowanie standardowe” wykorzystywanego w Umowie wykonawczej i odniesienie go wprost do zakresu postępowania określonego w OPZ. - Wymagania w zakresie instalacji i aktywacji oprogramowania Dodatkowo Zamawiający w ramach wymagań wpisanych w Umowie wykonawczej wymaga od Wykonawcy (§ 1 ust.3 pkt 3 Umowy Wykonawczej) instalacja i aktywacja na dostarczonym Sprzęcie zakupionego oprogramowania. W żadnym innym dokumencie Postępowania Zamawiający nie odnosi się do konieczności instalacji i aktywacji oprogramowania

przez Wykonawcę. Mając przy tym na uwadze opisaną w poprzednim zarzucie nieprecyzyjność Zamawiającego w posługiwaniu się słowem „oprogramowywanie” Odwołujący nie ma pewności instalacji i aktywacji jakiego oprogramowania żąda Zamawiający w ramach umowy wykonawczej. Nie wiadomo też dlaczego wymóg ten (instalacja i aktywacja) nie został szczegółowo opisany co do zakresu w OPZ, a jedynie wspomniany niejako przy okazji w projekcie Umowy wykonawczej. (…) W związku z powyższym Odwołujący, wnosi o dokonanie modyfikacji SW Z poprzez doprecyzowanie zakresu prac instalacyjnych i aktywacyjnych jakie ma wykonać wykonawca na podstawie § 1 ust. 3 pkt 3 umowy wykonawczej oraz precyzyjnego określenia jakiego oprogramowania te prace instalacyjne i aktywacyjne dotyczą.

Zarzut nr 2 - naruszenie art. 99 ust. 2, ust. 4, w zw. z art. 16 pkt. 1 i 3 w zw. z art. 353 1 kodeksu cywilnego (dalej „kc”) oraz art. 5 kc w zw. z 8 ust. 1 Ustawy - czas naprawy urządzeń w okresie gwarancji Zgodnie z wymaganiem zawartym w OPZ dotyczącym gwarantowanego czasu naprawy Mobilnych Terminali (kod wymagania W79) Wykonawca zobowiązany jest do dokonana naprawy urządzenia w terminie maksymalnie 6 dni roboczych liczonych od dnia zgłoszenia urządzenia do serwisu:

W79 C Czas naprawy urządzenia w okresie trwania gwarancji (od dnia wymagany zgłoszenia urządzenia do serwisu, do dnia powrotu urządzenia do jednostki) max. 6 dni roboczych W ocenie Odwołującego termin na naprawę danego urządzenia powinien być liczony od momentu potwierdzenia przez Wykonawcę dostarczenia do serwisu uszkodzonego urządzenia, a nie od zgłoszenia tego urządzenia do serwisu przez Zamawiającego. Wykonawca nie ma wpływu na to czy użytkownik ze strony Zamawiającego przekaże kurierowi zamówionemu przez Wykonawcę uszkodzone urządzenie w pierwszym możliwym terminie. Co istotne w takim przypadku Zamawiający, zgodnie z § 7 ust. 2 lit c) Umowy wykonawczej jest uprawniony do naliczenia kary umownej w wysokości 800 zł za pojedynczy Przedmiot umowy zgłoszony do naprawy z tytułu przekroczenia wymaganego czasu naprawy gwarancyjnej za każdy rozpoczęty dzień zwłoki.

Także wysokość kary umownej jest w tym przypadku całkowicie nieproporcjonalna do skali ewentualnego naruszenia.

Kara w wysokości 800 zł naliczana jest od każdego pojedynczego przedmiotu za każdy dzień, niezależnie od tego czy to jest Terminal MTN, zapasowa bateria, rysik, czy ładowarka samochodowa. W przypadku gdy przedmiotem naprawy ma być cały zestaw MTN kara taka liczona byłaby odrębnie od każdego elementu zestawu (w tym np. rysika, czy zapasowej baterii). Taki sposób naliczania kary umownej jest nadmiarowy i nieproporcjonalny do ewentualnej szkody jaką może ponieść Zamawiający w wyniku opóźnienia w naprawie.

W związku z powyższym Odwołujący, wnosi o dokonanie modyfikacji SWZ poprzez:

1. doprecyzowanie wymagań dotyczących liczenia czasu naprawy urządzeń od momentu potwierdzenia przez Wykonawcę dostarczenia do serwisu uszkodzonego urządzenia, zamiast od dnia zgłoszenia urządzeń do serwisu;
2. zmianę kary umownej określonej w § 7 ust. 2 lit c Umowy Wykonawczej w taki sposób, aby jej wysokość odnosiła się do wartości urządzenia, które jest przedmiotem naprawy, a jednocześnie w przypadku zwrotu elementów składających się na zestaw MTN, aby kara ta była naliczana wobec całego zestawu MTN a nie odrębnie liczonych poszczególnych jego elementów. - kara umowna za wypowiedzenie Umowy ramowej W § 7 ust. 2 Umowy Ramowej Zamawiający wprowadził postanowienia umożliwiające mu nałożenie kar umownych na Wykonawcę:
3. W przypadku wypowiedzenia Umowy ramowej przez Wykonawcę lub w przypadku wypowiedzenia Umowy przez Zamawiającego z przyczyny, o której mowa w § 10 ust. 1 pkt. 1-4 i 6 Umowy, Wykonawca zapłaci na rzecz Zamawiającego karę umowną w wysokości 5% kwoty brutto, o której mowa w § 4 ust.1.

W postanowieniu tym Zamawiający w sposób całkowicie nieuprawniony nadał sobie prawo do nakładania kary umownej na wykonawcę w sytuacji, gdy to wykonawca wypowie umowę ramową – bez względu przy tym na przyczyny takiego wypowiedzenia. Brak jakichkolwiek ograniczeń w tym względzie oznacza, że Zamawiający może naliczyć taką karę umowną w przypadku wypowiedzenia Umowy ramowej przez wykonawcę zarówno wtedy, gdy nastąpiło to z przyczyn dotyczących wykonawcy, jak i wtedy gdy wykonawca wypowiedział tę umowę ramową z przyczyn dotyczących Zamawiającego (np. brak płatności), lub z przyczyn niezależnych od obu stron. Takie uprawnienie Zamawiającego w sposób oczywisty rażąco narusza równowagę stron umowy przerzucając na wykonawców niemożliwe do oszacowania ryzyko związane z realizacją Umowy ramowej (…) W związku z powyższym Odwołujący wnosi o dokonanie modyfikację SW Z poprzez doprecyzowanie w § 7 ust. 2 Umowy ramowej, że prawo Zamawiającego do naliczenia kary umownej w przypadku wypowiedzenia umowy ramowej przez Wykonawcę nie przysługuje w przypadku gdy Wykonawca wypowiedział tę umowę z przyczyn dotyczących

Zamawiającego, lub podmiotów trzecich, na których działanie lub zaniechanie Wykonawca nie ma wpływu. - kara umowna za zwłokę w Umowie Wykonawczej W § 7 ust. 2 lit b) i d) Umowy wykonawczej Zamawiający sformułował prawo do naliczenia kary umownej za zwłokę w realizacji przedmiotu Umowy wykonawczej:

1. Wykonawca zobowiązuje się zapłacić Zamawiającemu następujące kary umowne: b) 0,15% wartości brutto Przedmiotu umowy, o której mowa w § 5 ust. 1, za każdy rozpoczęty dzień zwłoki w wykonaniu Przedmiotu umowy; W przypadku, gdy Wykonawca zaoferuje skrócenie terminu realizacji i przekroczy zaoferowany termin realizacji Umowy, kara za zwłokę będzie liczona podwójnie; d) 0,15% wartości brutto Przedmiotu umowy, o której mowa w § 5 ust. 1, za przekroczenie terminów, o których mowa w ust. 11, 12, 14 Załącznika nr 3 do Umowy za każdy dzień przekroczenia; W tym wypadku Odwołujący zwraca uwagę, że przedmiotowe kary umowę są liczone od całej wartości brutto przedmiotu umowy za każdy dzień zwłoki, niezależnie od tego jakiej części zamówienia zwłoka dotyczy. W ocenie Odwołującego takie sformułowanie postanowień umowy wykonawczej w sposób rażący narusza równowagę stron i są rażąco niekorzystne dla wykonawców. Takie sformułowanie kary umownej może wręcz doprowadzić do tego, że będzie ona rażąco wygórowana a tym samym powstanie podstawa do jej miarkowania.

W związku w powyższym Odwołujący wnosi o taką zmianę powyższych postanowień Umowy wykonawczej, aby kara była naliczana od wartości Przedmiotu umowy, którego dotyczy zwłoka. - prawo do odstąpienia od Umowy wykonawczej bez wyznaczania minimalnego terminu na usunięcie naruszeń W § 11 ust. 2 pkt 1 i pkt 2 Umowy wykonawczej Zamawiający określił prawo do odstąpienia wskazując: 2. Zamawiający zastrzega sobie prawo odstąpienia od Umowy w całości bądź w części w przypadku:

1. zwłoki w realizacji Umowy, której Przedmiot umowy został określony w § 1 ust. 1, trwającej dłużej niż 3 dni robocze w stosunku do terminu określonego w § 4 ust. 1. Prawo odstąpienia Zamawiający może wykonać w terminie do 30 dni roboczych od powzięcia wiadomości o okolicznościach skutkujących możliwością odstąpienia od Umowy, bez wyznaczania Wykonawcy dodatkowego terminu na wykonanie Umowy;
2. dostarczenia Przedmiotu umowy (w tym oprogramowania) i licencji niespełniającego wymogów określonych w Załączniku nr 1 lub Załączniku nr 3 do Umowy. Prawo odstąpienia Zamawiający może wykonać w terminie do 30 dni roboczych od powzięcia wiadomości o okolicznościach skutkujących możliwością odstąpienia od Umowy, bez wyznaczania Wykonawcy dodatkowego terminu na wykonanie Umowy.

W ocenie Odwołującego powyższe postanowienia w sposób rażący naruszają równowagę stron umowy, zarówno prawną jak i ekonomiczną. Wynika to z określenie zbyt wysokiego ryzyka dla wykonawców związanego z realizacją Zamówienia, nieproporcjonalnego i nieadekwatnego do uzasadnionych potrzeb Zamawiającego. Powyższe może także spowodować, że wykonawcy zdolni do należytego wykonania Zamówienia, ze względu na zbyt duże ryzyko związane z jego realizacją w danym przypadku w ogóle nie złożą oferty na wykonanie danego Zamówienia. Wskazane powyżej klauzule umowne są także niezgodne z zasadą współżycia społecznego uregulowaną art. 5 i art. 353 (1) kc i rażąco naruszają równowagę stron, bowiem znacznie przekraczają dopuszczalną swobodę Zamawiającego w jednostronnym kształtowaniu postanowień umowy o udzielenie zamówienia publicznego. (…) W związku z powyższym Odwołujący wnosi o taką zmianę powyższych postanowień Umowy wykonawczej, aby przed złożeniem oświadczenia o odstąpieniu Zamawiający był zobowiązany do wezwania wykonawców do usunięcia stwierdzonych naruszeń wyznaczając im w tym zakresie odpowiedni do danej sytuacji minimalny termin.”

Następujący wykonawcy zgłosili przystąpienie do postępowania odwoławczego po stronie Odwołujących:

1. wykonawca Suntar sp. z o.o., ul. Marii Drozd 12, 33-100 Tarnów - w postępowaniach o sygn. akt: KIO 2650/24 i KIO 2651/24, 2)wykonawca Axians IT Solutions Poland sp. z o.o., ul. Postępu 21D, 02-676 Warszawa -w postępowaniu o sygn. akt:

KIO 2651/24.

Izba stwierdziła, że przystąpienia obu wykonawców zostały dokonane skutecznie.

Pismami z dnia 19.08.2024 r. Zamawiający złożył odpowiedzi na oba odwołania, w których poinformował o braku substratu zaskarżenia w zakresie określonych zarzutów z uwagi na dokonane w dniu 16.08.2024 r. zmiany SW Z oraz wniósł o oddalenie obu odwołań w pozostałym zakresie.

Pismami z dnia 23.08.2024 r. obaj Odwołujący ustosunkowali się do odpowiedzi na odwołanie i przedstawili stanowiska procesowe w odniesieniu do podniesionych zarzutów.

W dniu 23.08.2024 r. Zamawiający ponownie przedstawił swoją argumentację i przekazał informację o kolejnych zmianach SWZ dokonanych w dniu 22.08.2024 r.

W dniu 27.08.2024 r. Zamawiający przekazał informację o przesunięciu terminu przeprowadzenia testów wstępnych z dnia 28.08.2024 r. na dzień 06.09.2024 r.

Na podstawie pisma Odwołującego Axians z dnia 23.08.2024 r. i jego oświadczeń złożonych w trakcie posiedzenia i rozprawy Izba ustaliła, że w sprawie KIO 2650/24:

1. postępowanie odwoławcze podlega umorzeniu jako zbędne na podstawie art. 568 pkt 2 ustawy Pzp z powodu zmian SW Z dokonanych przez Zamawiającego (tj. braku substratu zaskarżenia) w zakresie następujących zarzutów: IV.1) – żądanie a), IV.2) – żądanie b) i c), IV.3) – żądanie d), IV.5) – żądanie f), V.1) – żądanie g) i i), V.2) – żądanie j), V.4) – żądanie l), V.5) – żądanie m), V.6) – żądanie n), V.7) – żądanie o), V.10) – żądanie r), V.11) – żądanie s), V.12) – żądanie t), V.13) – żądanie u), VI.2) – żądanie w), VI.3) – żądanie x), VI.4) – żądanie y), VII.1) – żądanie z), VII.2) – żądanie aa), VII.3) – żądanie bb), VII.4) – żądanie cc), VII.7. – żądanie ee), VIII.1) – żądanie ff), VIII.2) – żądanie gg), VIII.4) – żądanie ii), VIII.5). – żądanie ii), 2)postępowanie odwoławcze podlega umorzeniu na podstawie art. 568 pkt 1 ustawy Pzp z powodu cofnięcia odwołania w zakresie zarzutu VI.1) – żądanie v), 3)rozpoznaniu podlegają następujące zarzuty: ·IV.4) [pkt XIII, ust. 2] – żądanie e), ·V.1) [udostępnienie projektu aplikacji DEMO TEST] – żądanie h), ·V.3) [parametry testu] – żądanie k), ·V.8) [tabela C] – żądanie p), ·V.9) [instalacja aktualizacji] – żądanie q), ·VII.5) [odbiór jakościowy sprzętu] – żądanie dd), ·VII.6) [warunki gwarancyjne] – żądanie ee), ·VIII.3) [wymóg W45] – żądanie hh), ·VIII.6) [tabela wymagań MDM] – żądanie jj).

Na podstawie treści odwołania, pisma Odwołującego Orange z dnia 23.08.2024 r. i jego oświadczeń złożonych w trakcie posiedzenia i rozprawy Izba ustaliła, że w sprawie KIO 2651/24:

1. postępowanie odwoławcze podlega umorzeniu jako zbędne na podstawie art. 568 pkt 2 ustawy Pzp z powodu zmian SW Z dokonanych przez Zamawiającego (tj. braku substratu zaskarżenia) w zakresie zarzutów dotyczących: charakteru łącznego testu wstępnego - żądanie 2 ze str. 12 odwołania, jednakowych warunków w teście aplikacji Demo Test – żądanie 1 ze str. 14 odwołania, jednostronnej decyzji o powtórzeniu testów akceptacyjnych - żądanie 2 ze str. 14 odwołania, definicji oprogramowania - żądanie 2 ze str. 17 odwołania, wymagań w zakresie instalacji i aktywacji oprogramowania - żądanie 2 ze str. 18 odwołania, kary umownej za wypowiedzenie umowy ramowej żądanie ze str. 20 odwołania, kary umownej za zwłokę w umowie wykonawczej - żądanie ze str. 21 odwołania oraz § 11 ust. 2 pkt 2 PPUW - żądanie ze str. 22 odwołania,
2. rozpoznaniu podlegają zarzuty dotyczące: ·wymagań systemu operacyjnego w zakresie aplikacji KM SWD – zarzut 1a z żądaniami na str. 9 odwołania, ·testów wstępnych – zarzut 1a z żądaniami na str. 12 odwołania, ·testów akceptacyjnych – zarzut 1a z żądaniem pierwszym do słów „a zarazem” na str. 14 odwołania, ·wymagań dostarczenia biblioteki wraz z API – zarzut 1a z żądaniem na str. 15 odwołania, ·czasu naprawy urządzeń w okresie gwarancji – zarzut 2 z żądaniami na str. 19 i 20 odwołania, ·§ 11 ust. 2 pkt 1 PPUW – zarzut 2 z żądaniem na str. 22 odwołania.

Krajowa Izba Odwoławcza rozpoznając na rozprawie złożone odwołanie i uwzględniając dokumentację z niniejszego postępowania o udzielenie zamówienia publicznego oraz stanowiska Stron i Przystępujących złożone na piśmie i podane do protokołu rozprawy, zważyła co następuje.

W pierwszej kolejności Izba ustaliła wystąpienie przesłanek z art. 505 ust. 1 ustawy Pzp, tj. istnienie po stronie Odwołujących interesu w uzyskaniu zamówienia oraz możliwość poniesienia przez nich szkody z uwagi na kwestionowane czynności Zamawiającego.

Ponadto Izba stwierdziła, że nie została wypełniona żadna z przesłanek ustawowych skutkujących odrzuceniem odwołań, wynikających z art. 528 ustawy Pzp.

Odwołanie Axians – KIO 2650/24 Zarzut VII.6) dotyczący warunków gwarancyjnych – żądanie ee) Zgodnie z art. 99 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 wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty.

W ust. 4 Wymagań gwarancyjnych stanowiących zał. nr 3 do PPUW (projektu umowy wykonawczej) Zamawiający wskazał: Gwarancja obejmuje wady materiałowe i konstrukcyjne, a także niespełnienie deklarowanych przez producenta parametrów i/lub funkcji użytkowych, naprawę wykrytych uszkodzeń komponentów urządzeń w tym

wymianę uszkodzonych podzespołów na nowe.

Odwołujący stwierdził, że ww. postanowienie jest nieprecyzyjne i nie pozwala określić zakresu odpowiedzialności gwarancyjnej wykonawcy, bo nie określono w nim, czy gwarancji podlegają uszkodzenia mechaniczne albo uszkodzenia umyślne, czy też chodzi w nim tylko o wady materiałowe.

Zamawiający w odpowiedzi na odwołanie powołał się na wymóg zgodności urządzenia z normami wytrzymałościowymi normy MIL-STD-810G lub nowszej i treść wymagań gwarancyjnych obejmujących „niespełnienie deklarowanych przez producenta parametrów i/lub użytkowych”, twierdząc, że obejmuje to wszelkie wady, w tym uszkodzenia mechaniczne, wynikające np. z niespełnienia deklarowanej normy MIL-STD-810G.

Izba zgadza się z Odwołującym, że informacje przekazane przez Zamawiającego w odpowiedzi na odwołanie powinny znaleźć się w opisie Wymagań gwarancyjnych, tak aby wiedzę o nich mogli powziąć wszyscy wykonawcy, także ci nieuczestniczący w postępowaniu odwoławczym. Dotyczy to przede wszystkim informacji o zamiarze ustalania zakresu odpowiedzialności gwarancyjnej w oparciu o normę MIL-STD-810G oraz o tym, że zakres tej odpowiedzialności obejmuje także uszkodzenia mechaniczne. Poza tym Zamawiający w dalszym ciągu nie zamieścił w wymaganiach gwarancyjnych informacji dotyczących uszkodzeń dokonanych umyślnie oraz uszkodzeń mechanicznych powstałych w sytuacjach innych niż określone w ww. normie. Z uwagi na brak wszystkich wyżej wymienionych informacji w Wymaganiach gwarancyjnych, w świetle art. 99 ust.1 ustawy Pzp, Izba uznała zarzut za zasadny i nakazała Zamawiającemu sprecyzowanie warunków odpowiedzialności gwarancyjnej wykonawcy.

Jednocześnie Izba pominęła podniesiony dopiero na rozprawie zarzut braku pozostawienia do decyzji wykonawcy, czy uszkodzenie będzie podlegać w ramach gwarancji naprawie czy wymianie, ponieważ nie był on zawarty w odwołaniu (art. 555 ustawy Pzp).

Zarzut VIII.6) dotyczący tabeli wymagań MDM – żądanie jj) Zgodnie z art. 99 ust. 1, 4, 5 i 6 ustawy Pzp:

1. 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 wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty.
2. Przedmiotu zamówienia nie można opisywać w sposób, który mógłby utrudniać uczciwą konkurencję, w szczególności przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli mogłoby to doprowadzić do uprzywilejowania lub wyeliminowania niektórych wykonawców lub produktów.
3. Przedmiot zamówienia można opisać przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli zamawiający nie może opisać przedmiotu zamówienia w wystarczająco precyzyjny i zrozumiały sposób, a wskazaniu takiemu towarzyszą wyrazy „lub równoważny”.
4. Jeżeli przedmiot zamówienia został opisany w sposób, o którym mowa w ust. 5, zamawiający wskazuje w opisie przedmiotu zamówienia kryteria stosowane w celu oceny równoważności.

W OPZ w rozdziale pn. Licencje do posiadanego przez Zamawiającego oprogramowania MDM, Zamawiający wskazał m.in.: ˗ dostarczane licencje muszą zapewniać pełną współpracę z posiadanym przez Zamawiającego oprogramowaniem MDM Essentials MDM w wersji 5.33 lub nowszej, - dostarczane licencje muszą integrować się z posiadaną przez Zamawiającego infrastrukturą systemową zawierającą serwery zarządzające oparte na oprogramowaniu Essentials MDM (dawniej FAMOC).

Odwołujący wskazuje, że Zamawiający nie zapewnił możliwości zaoferowania rozwiązania równoważnego, bowiem taki opis wymagań uniemożliwia zaoferowanie innych licencji niż licencje do posiadanego już przez Zamawiającego oprogramowania Essentials MDM. Tylko oprogramowanie Essentials MDM jest w stanie zapewnić „pełną współpracę” oraz „integrację” z infrastrukturą zawierającą serwery zarządzające oparte na Essentials MDM. Odwołujący dodaje, że wymienione w tabeli funkcjonalności MDM są wprost skopiowane z dokumentu „Techstep Essentials MDM.

Matryca funkcjonalności”, czyli dokumentu opisującego funkcjonalności Essentials MDM. Zamawiający nie opisał więc rzeczywiście wymaganych i niezbędnych mu funkcjonalności, a jedynie skopiował te, które posiada użytkowane przez niego oprogramowanie Essentials MDM. Odwołujący zakwestionował też opis wymogów dotyczących integracji systemu MDM, brak w OPZ funkcjonalności związanych z tymi integracjami oraz podkreślił, że funkcjonalności w tabeli „Funkcjonalności” posiadają także opisy specyficzne i nawet nie istniejące (Apple zero-touch), co oznacza, że wskazana tabela nie jest opisem rozwiązań stosowanych obecnie u Zamawiającego i nie stanowi jego rzeczywistych potrzeb.

Zamawiający stwierdził na rozprawie, że zarzut jest nieprawidłowo skonstruowany, bo wymagane licencje nie zostały opisane poprzez wskazanie znaku towarowego, zatem Zamawiający nie ma obowiązku dopuszczenia w tym zakresie rozwiązań równoważnych. Ponadto wskazał w odpowiedzi na odwołanie okoliczności, z powodu których nie

może zrezygnować z wymogu, aby oprogramowania MDM były kompatybilne z posiadanym przez niego oprogramowaniem Essentials MDM firmy TechStep.

Po pierwsze, należy zauważyć, że Zamawiający nie zaprzeczył, że wymóg „pełnej współpracy” i „integracji” z oprogramowaniem Essentials MDM oznacza, że w istocie wykonawcy muszą dostarczyć licencje do tego właśnie oprogramowania. Taki wymóg może jednak utrudniać uczciwą konkurencję poprzez eliminowanie określonych wykonawców (oferujących inne licencje) lub produktów (innych licencji), a w efekcie stanowi naruszenie art. 99 ust. 4 ustawy Pzp. Mimo to ww. wymóg mógłby być, zgodnie z jednolitym stanowiskiem doktryny i z orzecznictwem uznany za dopuszczalny, gdyby wynikał z uzasadnionych potrzeb Zamawiającego. Tymczasem Zamawiający w odpowiedzi na odwołanie powołuje się na to, że dopuszczenie zaoferowania innych licencji spowoduje konieczność zaznajomienia się administratorów w Policji z kilkoma systemami MDM (zwłaszcza, że do zawarcia umowy ramowej może być wyłonionych 2 wykonawców), że w związku z tym konieczne będzie przeprowadzenie czasochłonnych i kosztownych szkoleń oraz że Zamawiający będzie musiał rozbudować obecne Data Center o dodatkowe serwery i elementy sieciowe oraz kontrolować, który terminal ma się łączyć z MDM, dla którego ma licencję. Takie argumenty Zamawiającego świadczą o tym, że zaoferowanie innych licencji niż licencje do oprogramowania Essentials MDM nie jest niezbędne dla zaspokojenia jego potrzeb, a jedynie ułatwia mu wykonywanie zadań. Argumentacja ta nie potwierdza zatem, że potrzeby Zamawiającego są uzasadnione, zwłaszcza w świetle argumentacji powoływanej przez Odwołującego, który wskazuje, że systemy MDM są do siebie w dużej mierze podobne, szkolenia trwają zwykle jeden dzień i odbywają się w trybie online praktycznie bezkosztowo, a ponadto nawet przy zachowaniu istniejącej instalacji MDM Essentials Zamawiający i tak musi rozbudować Data Center i elementy sieciowe w związku z przyjęciem 13 tysięcy nowych urządzeń, a w konsekwencji nie będzie problemu z wydzieleniem na serwerach miejsca na nowy system MDM. Nie można zatem uznać, że potrzeby Zamawiającego są uzasadnione i Zamawiający rzeczywiście musi żądać dostarczenia wyłącznie licencji zapewniających pełną współpracę i integrację z oprogramowaniem Essentials MDM.

Po drugie, abstrahując nawet od naruszenia art. 99 ust. 4 ustawy Pzp i skupiając się na art. 99 ust. 5 i 6 ustawy Pzp, na których naruszenie wskazuje argumentacja zawarta w odwołaniu, należy zauważyć, że obowiązek dopuszczenia rozwiązań równoważnych ma miejsce nie tylko w przypadku opisania przedmiotu zamówienia za pomocą znaków towarowych, ale także za pomocą szczególnego procesu charakteryzującego produkty. W tym wypadku wymóg „pełnej współpracy” i „integracji” licencji z oprogramowaniem Essentials MDM jest takim szczególnym procesem, który charakteryzuje wyłącznie licencje do oprogramowania Essentials MDM. Zamawiający nie używając więc znaków towarowych, ale wskazując na proces „pełnej współpracy” i „integracji” licencji z oprogramowaniem Essentials MDM w istocie opisał przedmiot zamówienia w sposób charakteryzujący konkretne produkty (licencje do tego oprogramowania), co rodzi po jego stronie obowiązek dopuszczenia rozwiązań równoważnych, zgodnie z art. 99 ust. 6 ustawy Pzp.

Izba rozumie przy tym chęć ograniczenia po stronie Zamawiającego wysiłku, jaki będzie związany z ewentualnym zaoferowaniem innych licencji, jednakże nie można tracić z pola widzenia, że naczelną zasadą udzielania zamówień, wskazaną zarówno w art. 99 ustawy Pzp, jak i w art. 16 ustawy Pzp, jest zasada uczciwej konkurencji, której przestrzeganie jest obowiązkiem Zamawiającego, a której złamanie w tym wypadku dodatkowo grozi uzależnieniem Zamawiającego od danego producenta.

W zakresie poruszonych w ww. zarzucie kwestii dotyczących wymienionych w wymaganiach Zamawiającego niepotrzebnych technologii i integracji, należy zauważyć, że w dniu 16.08.2024 r. Zamawiający dokonał już zmiany SW Z usuwając część integracji (w tym zakresie zastosowanie znajduje art. 568 pkt 2 ustawy Pzp), natomiast nie zaprzeczył i nie odniósł się do kwestii wymaganych funkcjonalności, wymienionych też w dołączonym jako dowód do odwołania dokumencie „Techstep Essentials MDM”.

W związku z tym Izba uwzględniła odwołanie w zakresie tego zarzutu i nakazała dopuszczenie oprogramowania równoważnego do Essentials MDM oraz wykreślenie z wymagań dotyczących licencji wszystkich niestosowanych technologii i opisanie rzeczywiście wymaganych funkcjonalności.

Zarzut IV.4) dotyczący pkt XIII, ust. 2 – żądanie e) W rozdziale XIII SW Z Zamawiający wskazał kryteria oceny ofert, w tym „termin realizacji zamówienia wykonawczego” – 20%.

W rozdziale VI SW Z Zamawiający wskazał: Maksymalny termin realizacji umów wykonawczych w ramach poszczególnych zaproszeń wskazany będzie w umowie wykonawczej i określony będzie w zależności od rodzaju i ilości sprzętu informatycznego, jednak nie będzie krótszy niż 70 dni roboczych w przypadku dostaw powyżej 250 szt. danego rodzaju urządzeń. Termin realizacji umowy wykonawczej nie będzie krótszy niż 40 dni roboczych w przypadku dostaw do 250 szt. danego rodzaju urządzeń, licząc od dnia zwarcia umowy wykonawczej Zgodnie z § 3 ust. 3 PPUW: Wykonawca oświadcza, że sprzęt, urządzenia mobilne, zestawy urządzeń

mobilnych wraz z ukompletowaniem stanowią jego wyłączną własność, są fabrycznie nowe, nie używane w innych projektach, wolne od wad, pakowane w oryginalne bezzwrotne opakowania producenta. Przedmiot umowy jest nie starszy niż dziewięć miesięcy od daty produkcji, oraz że urządzenia mobilne posiadają oznakowanie (certyfikat) CE – Conformite europeenne.

Odwołujący wskazuje, że do momentu otrzymania zaproszenia do zawarcia umowy wykonawczej wykonawca nie zna ilości oraz terminu dostawy urządzeń. W praktyce nie jest więc w stanie zabezpieczyć z wyprzedzeniem, nawet z producentem, zapasu urządzeń z obawy o to, że czas między produkcją a dostawą przekroczy 9 miesięcy, co spowoduje niezgodność dostarczonego przedmiotu z umową. Podkreśla, że zamawiane urządzenia są najczęściej sprowadzane spoza UE, co powoduje konieczność przeprowadzenia procedury celnej, której czas trwania jest nieprzewidywalny - może trwać 1 – 2 dni, ale także ponad miesiąc.

Przede wszystkim należy zauważyć, że Zamawiający dokonał zmian zarówno w zakresie terminu realizacji umów wykonawczych, jak i w zakresie okresu, z którego muszą pochodzić dostarczane urządzenia, liczonego od daty produkcji. W dniu 16.08.2024 r. Zamawiający dokonał bowiem zmiany § 3 ust. 3 PPUW wydłużając okres 9 miesięcy liczony od daty produkcji do 12 miesięcy, co oznacza, że wykonawca może dostarczyć urządzenia starsze o 3 miesiące w stosunku do wcześniejszego wymogu. Ponadto na skutek odwołania wykonawcy Orange (KIO 1285/24) Zamawiający zmienił termin realizacji umów wykonawczych z wymaganych w poprzednio prowadzonym postępowaniu 45 dni roboczych na wymagane obecnie 70 i 40 dni roboczych (zależnie od ilości zamawianych urządzeń), czyli odpowiednio ponad 3 miesiące i ok. 2 miesięcy. Taki okres w świetle argumentacji Odwołującego powinien więc być wystarczający do przeprowadzenia procedury celnej.

Wreszcie nie można także pominąć, że w pkt VI SW Z wskazano, że maksymalny termin realizacji umów wykonawczych w ramach poszczególnych zaproszeń wskazany będzie w umowie wykonawczej i określony będzie w zależności od rodzaju i ilości sprzętu informatycznego. Tym samym kwestionowane w odwołaniu terminy 70 i 40 dni roboczych nie są terminami sztywnymi, ale terminami minimalnymi, które będą dostosowywane przez Zamawiającego do rodzaju i ilości zamawianego sprzętu.

Z uwagi na powyższe okoliczności Izba uznała zarzut za niezasadny i oddaliła odwołanie w tym zakresie.

Zarzut V.1) dotyczący udostępnienia projektu aplikacji DEMO TEST – żądanie h) W zał. nr 9 do SW Z dotyczącym testów akceptacyjnych w tabeli B w poz. 6 dotyczącej projektu aplikacji Demo Test Zamawiający zamieścił wymóg, aby: W projekcie nie została naruszona konfiguracja dotycząca dołączonych przez zamawiającego bibliotek, tj. nie zostały usunięte z projektu biblioteki oraz nie została zmieniona ich wersja.

Odwołujący twierdzi, że konkretne biblioteki, które Zamawiający wskazał w celu przeprowadzenia testów aplikacji Demo Test, są już przestarzałe i ze względów bezpieczeństwa i kompatybilności wykonawca powinien mieć prawo aktualizacji tych bibliotek do najnowszej wersji.

Zamawiający twierdzi, że bardzo często nowe biblioteki nie są w pełni kompatybilne z innymi bibliotekami oraz pluginami, zwłaszcza że Policja wykorzystuje w swoich autorskich rozwiązaniach konkretne biblioteki. Zamawiający zwrócił też uwagę na brak istotnego ryzyka w przypadku luk w systemie bezpieczeństwa z uwagi na działanie aplikacji w sieci wewnętrznej.

W ocenie Izby to Zamawiający lepiej zna środowisko, w którym będą odbywać się testy i zagrożenia wynikające z aktualizacji bibliotek do najnowszej wersji. W świetle wskazywanego przez Zamawiającego ryzyka niekompatybilności bibliotek i faktu, że Policja używa tylko określonych ich wersji w swoich autorskich rozwiązaniach należy przyjąć, że gospodarz postępowania ma prawo stawiać wymagania wynikające z jego uzasadnionych potrzeb. Dodatkowo ryzyka wskazywane przez Odwołującego zostaną ograniczone z uwagi na działanie aplikacji w wewnętrznej sieci Zamawiającego. Z uwagi na powyższe Izba oddaliła odwołanie w zakresie tego zarzutu.

Zarzut V.3) dotyczący parametrów testu – żądanie k) W zał. 9 do SW Z w Wymaganiach ogólnych Zamawiający wskazał: W trakcie wykonywania testów Zamawiający może zażądać powtórzenia dowolnego testu, a także sprawdzenia dowolnego wymaganego parametru, bądź funkcjonalności opisanej w Specyfikacji technicznej.

Odwołujący podnosi, że Zamawiający chce badać w trakcie testów również elementy wykraczające poza przewidziany scenariusz, co może prowadzić do naruszenia zasady uczciwej konkurencji, a poza tym zwraca uwagę, że do sprawdzenia niektórych parametrów potrzebna jest specjalna aparatura lub specjalistyczna wiedza (np. do badania wytrzymałości na temperaturę – komora klimatyczna) i wykonawca może nie być przygotowany do testu w takim zakresie.

Zamawiający wskazał w odpowiedzi na odwołanie, że: „Celem przeprowadzenia testów akceptacyjnych jest właśnie dokonanie opisanej powyżej weryfikacji. Zamawiający wskazał zakres przewidywanych testów, ale pozostawił sobie możliwość sprawdzenia dowolnego parametru. Zamawiający wskazuje, że wprowadzenie tego zapisu wynika z

doświadczeń Zamawiającego – kiedy to podczas realizacji opisanego scenariusza testowego Zamawiający stwierdził, że nie jest spełniony parametr zawarty w SW Z, ale nie uwzględniony w scenariuszu testowym. Przeprowadzenie dodatkowego sprawdzenia pozwalało na wyjaśnienie wątpliwości lub odrzucenie oferty niespełniającej wymagań. (…) Przeprowadzenie dodatkowego sprawdzenia jest to uprawnienie Zamawiającego, które zobowiązany będzie przeprowadzić w granicach postawionych wymagań sprzętowych. Jeżeli do przeprowadzenia sprawdzenia będą potrzebne dodatkowe urządzenia, będzie to obowiązek Zamawiającego, nie Wykonawcy”.

W ocenie Izby należy zauważyć, że celem postępowania o udzielenie zamówienia jest uzyskanie przez zamawiającego określonego świadczenia, które ma zaspokoić jego uzasadnione potrzeby. Zamawiający zdecydował się na przeprowadzenie testów akceptacyjnych w celu zweryfikowania spełnienia przez oferowane urządzenia określonych wymagań, ale nie zmienia to faktu, że Zamawiający oczekuje, że urządzenia będą spełniać wszystkie jego wymagania określone w Specyfikacji technicznej, a nie tylko te, które wprost zostały wymienione w scenariuszu testów akceptacyjnych. Jeżeli więc w trakcie testów okaże się, że jakaś funkcjonalność nie działa i zachodzi prawdopodobieństwo, że jest to wynikiem niespełnienia określonego wymagania niewymienionego w scenariuszu testów, Zamawiający powinien mieć prawo do sprawdzenia spełniania tego wymagania, choćby po to, by móc dokonać oceny zgodności oferty wykonawcy z warunkami zamówienia. Należy przy tym dostrzec, że Zamawiający uprzedza wykonawców o tej możliwości i daje im też prawo wniesienia uwag do protokołu z testów.

Odnosząc się do obaw Odwołującego i Przystępującego Suntar o równe traktowanie wykonawców w związku z zastosowaniem ww. postanowienia, należy zwrócić uwagę, że Zamawiający nie planuje sprawdzać całkowicie dowolnych parametrów / funkcjonalności wykraczających poza te wskazane w scenariuszu testów, ale jedynie te, które są objęte wymaganiami Specyfikacji Technicznej i jednocześnie co do których w trakcie testów pojawi się wątpliwość, czy zostały spełnione. Oczywiście może to prowadzić do sytuacji, w której u jednego wykonawcy sprawdzone zostaną tylko funkcjonalności wymienione w scenariuszu, gdyż w jego przypadku żadne nieprawidłowości wymagające dalszego sprawdzania nie pojawią się w czasie testów, a u innego wykonawcy w związku z wystąpieniem jakichś nieprawidłowości zajdzie konieczność sprawdzenia dodatkowo funkcjonalności niewymienionych w scenariuszu. Takie dodatkowe sprawdzanie nie jest jednak oparte na dowolnej decyzji Zamawiającego i nie ma nieograniczonego zakresu, ale wynikać będzie z określonej budzącej wątpliwości sytuacji zaistniałej w trakcie testów i dotyczyć będzie tylko wymagań wskazanych w Specyfikacji Technicznej. Wykonawca musi być zatem świadomy, że do testów akceptacyjnych należy przygotować urządzenie pod kątem spełnienia wszystkich wymagań zawartych w Specyfikacji Technicznej, a nie tylko tych objętych scenariuszem, o czym Zamawiający lojalnie uprzedza.

Konieczność sprawdzenia wszystkich wymagań objętych Specyfikacją Techniczną Izba uznała więc za uzasadnioną potrzebę Zamawiającego, szczególnie w kontekście potrzeby dokonania oceny zgodności oferty z warunkami zamówienia i dlatego oddaliła odwołanie w zakresie tego zarzutu.

Zarzut V.8) dotyczący tabeli C – żądanie p) W zał. nr 9 do SW Z dotyczącym testów akceptacyjnych w tabeli C Zamawiający określił testy mające na celu sprawdzenie poprawności uruchomienia aplikacji KM SWD na oferowanym systemie operacyjnym.

Odwołujący podnosi, że nie można stwierdzić, czy aplikacja będzie się poprawnie uruchamiać na oferowanym systemie operacyjnym, gdyż zależy to od czynników, które nie są zależne od dostawcy urządzeń. Odwołujący wskazuje, że: „Wpływ na wyniki testów ma także jakość oprogramowania, a nie oferowanego urządzenia. Podkreślenia wymaga, że szereg testów przewidzianych w tabeli C nie zależy od systemu operacyjnego oferowanego urządzenia, ale sposobu implementacji. Ostatecznie także, oprogramowanie może być niekompatybilne z innymi urządzeniami, ponieważ było pisane (tworzone) pod inny, konkretny produkt i na nim testowane, bez uwzględniania różnic dla innych urządzeń”.

Zamawiający wskazał w odpowiedzi na odwołanie, że aplikacja KM SW D działa prawidłowo w środowisku produkcyjnym i że jest dla niego „absolutnie niedopuszczalne, aby na kupionych urządzeniach aplikacja KM SW D nie działała poprawnie”. Zamawiający dokonał też zmiany w poz. 11 tabeli C w zał. 9 do SW Z dodając: Przed rozpoczęciem testu na urządzeniach posiadanych przez zamawiającego zostanie dokonana instalacja tego samego pakietu aplikacji KM SWD, aby udowodnić działanie aplikacji w sposób prawidłowy.

Izba stwierdziła, że poprawne działanie aplikacji KM SW D na zamawianych urządzeniach ma dla Zamawiającego znaczenie priorytetowe i nakazanie mu rezygnacji z testów akceptacyjnych w zakresie dotyczącym tej aplikacji pozbawiałoby go możliwości zbadania prawidłowego jej działania i w efekcie stwarzałoby ryzyko dostarczenia mu urządzeń nieprzydatnych. Ochrona uzasadnionych potrzeb Zamawiającego wyklucza zatem uwzględnienie odwołania w zakresie tego zarzutu i przychylenie się do podstawowego żądania wskazanego w odwołaniu, tj. usunięcia z zał. 9 do SWZ testów określonych w tabeli C. Dlatego odwołanie w zakresie tego zarzutu zostało oddalone.

Należy jednak zauważyć, że Izba uwzględniła odwołanie Odwołującego Orangew sprawie KIO 2651/24 w zakresie dotyczącym testów wstępnych i nakazała Zamawiającemu udostępnienie wykonawcom dokumentacji

technicznej i kodów źródłowych do aplikacji KM SW D. Oznacza to, że wykonawcy będą mogli odpowiednio przygotować się do testów w zakresie dotyczącym tej aplikacji. Ze względu na powyższe Izba nie przychyliła się też do żądań ewentualnych Odwołującego, takich jak zaoferowanie przez wykonawcę usług wsparcia, czy rozbudowę aplikacji DEMO TEST o funkcjonalności wykorzystywane przez KM SWD, zwłaszcza, że Zamawiający i tak twierdzi, że uruchomienie się aplikacji Demo Test na danym urządzeniu nie gwarantuje, że uruchomi się na nim aplikacja KM SWD.

Zarzut V.9) dotyczący instalacji aktualizacji – żądanie q) W zał. nr 9 do SW Z w tabeli C w poz. 8 Zamawiający wskazał: aplikacja KM SW Dma możliwość instalacji nowszej wersji (aktualizacji) z wcześniej pobranego pliku APK do pamięci urządzenia.

Odwołujący wskazuje na ryzyko, jakie wiąże się z ww. wymogiem Zamawiającego. Rozwiązanie takie, zdaniem Odwołującego, jest niebezpieczne i traktowane w środowisku programistycznym jako zła praktyka. Zwraca też uwagę na niekonsekwencję Zamawiającego, który dopuszcza możliwość samodzielnej instalacji aktualizacji z pliku APK do pamięci urządzenia, a z drugiej strony nie zgadza się na podobne działania ze strony wykonawców (Zarzut V.1. dotyczący udostępnienia projektu aplikacji DEMO TEST – żądanie h).

Zamawiający w odpowiedzi na odwołanie wskazuje, że urządzenia działają w wydzielonej izolowanej sieci, która nie ma dostępu do sieci Internet, co zmniejsza ryzyko wskazywane przez Odwołującego. Poza tym zwraca uwagę na „wysoki priorytet” wdrożenia zmian przepisów i integracji z systemami międzynarodowymi oraz warunki pracy w Policji, które wymagają natychmiastowej aktualizacji aplikacji z pliku APK do pamięci urządzenia.

Izba ponownie stwierdziła, że to Zamawiający zna najlepiej swoje potrzeby i ma prawo stawiać wymagania, które zapewnią zaspokojenie tych (uzasadnionych) potrzeb, zwłaszcza w sytuacji, gdy działanie urządzeń w sieci wewnętrznej Zamawiającego obniża ryzyko wskazywane przez Odwołującego. Z uwagi na powyższe odwołanie w zakresie tego zarzutu zostało oddalone.

Zarzut VII.5) dotyczący odbioru jakościowego sprzętu – żądanie dd) W zał. nr 2 do PPUW pn. Zasady odbioru Przedmiotu umowy w pkt II.10. Zamawiający opisał procedurę odbiorową urządzeń MTN na podstawie weryfikacji poprawności odczytu kodów MRZ, AZTEC, kodu kreskowego z prawa jazdy, weryfikacji uzyskania dostępu do Policyjnych Systemów Informatycznych za pomocą transmisji danych w prywatnym APN.

Odwołujący wskazuje, że z uwagi na testy, które będą przeprowadzane w trakcie postępowania, brak jest podstaw do tego, aby zamawiający poddawał urządzenia przy odbiorze kolejnym testom, których negatywny wynik może narazić wykonawcę na kary umowne. Dlatego Odwołujący żąda usunięcia tego postanowienia albo wprowadzenia procedury badania jakości, np. jak dla nowych typów urządzeń, zgodnych z procedurą w postępowaniu wykonawczym.

Zamawiający zwraca uwagę na ryzyko, że wykonawca w celu obniżenia kosztów produkcji zmieni określone parametry urządzenia, które w efekcie nie będzie na etapie dostawy spełniało wszystkich wymagań Zamawiającego.

Izba stwierdziła, że badanie zgodności przedmiotu zamówienia z wymaganiami opisanymi w dokumentach zamówienia na etapie jego odbioru jest uzasadnioną potrzebą Zamawiającego i powinno w takiej czy innej formie, zależnej od rodzaju i specyfiki danego zamówienia, stanowić praktykę na rynku zamówień publicznych. Nie po to bowiem zamawiający prowadzi postępowanie i w jego trakcie bada zgodność oferty z warunkami zamówienia, żeby następnie narażać się na to, że na ostatnim etapie całego procesu, czyli na etapie odbioru, uzyska produkty/usługi/roboty, które nie odpowiadają jego wymaganiom, niwecząc tym samym cel całego postępowania.

W tym wypadku Zamawiający zdecydował się na przeprowadzenie testów odbiorowych i opisał procedurę odbiorową, w tym m.in. konieczne dokumenty, sprawdzany zakres i wymagany poziom spełnienia wymagań, a także - w przypadku gdy stwierdzona zostanie niezgodność pomiędzy dostarczonym produktem a opisem Przedmiotu umowy – obowiązek niezwłocznego usunięcia niezgodności i ponownego przystąpienia do procedury odbioru. Wobec tego, w ocenie Izby, nie ma podstaw do wprowadzania kolejnej procedury badania jakości, jak też do stwierdzenia, że Zamawiający naruszył przepisy ustawy Pzp i wskazał wymogi przekraczające jego uzasadnione potrzeby. Dlatego odwołanie w zakresie tego zarzutu zostało oddalone.

Zarzut VIII.3) dotyczący wymogu W45 – żądanie hh) W OPZ (zał. nr 2 do SW Z) Zamawiający wskazał w wymogu W45: Możliwość wykonywania połączeń głosowych w sieci GSM/4G na terytorium RP.

Odwołujący wskazuje, że wykonawcy nie mają wpływu na rodzaj (standard) używanej sieci do połączeń głosowych, bo nie jest to zależne od urządzenia ani od wykonawcy.

Zamawiający wyjaśnił natomiast na rozprawie, że chodzi mu jedynie o posiadanie przez urządzenie funkcjonalności zapewniającej wykonywania połączeń głosowych w sieci GSM/4G, natomiast nie oczekuje do wykonawców, że zapewnią oni takie połączenia w terenie, w którym nie ma zasięgu.

Izba stwierdziła, że stanowisko Zamawiającego wyjaśnione na rozprawie rzeczywiście znajduje potwierdzenie w

opisie wymogu, zwłaszcza wobec użycia w nim słowa: „możliwość”. W tym stanie rzeczy Izba uznała zarzut za niezasadny i oddaliła odwołanie w tym zakresie.

Odwołanie Orange – KIO 2651/24 Odwołujący Orange sformułował treść odwołania w taki sposób, że w ramach jednego zarzutu oznaczonego danym numerem podnosił w istocie kilka kwestii, dla których formułował odrębne żądania. Z uwagi na konieczność precyzyjnego ustalenia, w jakim zakresie postępowanie odwoławcze podlega umorzeniu i w jakim stosunku dokonać podziału kosztów tego postępowania między jego Stronami, Izba dokonała poniższego wyodrębnienia poszczególnych zarzutów opierając się w tym zakresie na argumentacji podnoszonej przez Odwołującego, wskazanych przez niego w odwołaniu podtytułach oraz przede wszystkim na żądaniach sformułowanych w stosunku do podnoszonych w tym odwołaniu kwestii (zarzutów).

Zarzut 1a dotyczący testów wstępnych z żądaniami na str. 12 odwołania Zgodnie z art. 99 ust. 1, 2 i 4 ustawy Pzp:

1. 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 wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty.
2. Zamawiający określa w opisie przedmiotu zamówienia wymagane cechy dostaw, usług lub robót budowlanych. Cechy te mogą odnosić się w szczególności do określonego procesu, metody produkcji, realizacji wymaganych dostaw, usług lub robót budowlanych, lub do konkretnego procesu innego etapu ich cyklu życia, nawet jeżeli te czynniki nie są ich istotnym elementem, pod warunkiem że są one związane z przedmiotem zamówienia oraz proporcjonalne do jego wartości i celów.
3. Przedmiotu zamówienia nie można opisywać w sposób, który mógłby utrudniać uczciwą konkurencję, w szczególności przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli mogłoby to doprowadzić do uprzywilejowania lub wyeliminowania niektórych wykonawców lub produktów.

W pierwszej kolejności należy zauważyć, że aplikacja KM SW D, której dotyczy zarzut, musi działać poprawnie na zamawianych urządzeniach MTN, aby Zamawiający mógł realizować zadania spoczywające na Policji. W celu sprawdzenia działania KM SW D na danym urządzeniu z jego systemem operacyjnym Zamawiający przewidział testy, w tym m.in. opisane w OPZ testy wstępne (i w dalszej kolejności testy akceptacyjne). Zamawiający, w ocenie Izby, nie może zostać pozbawiony prawa testowania oferowanych urządzeń pod kątem możliwości uruchomienia i działania na nich funkcjonalności aplikacji KM SW D, ponieważ powiększyłoby to ryzyko wyboru jako najkorzystniejszej oferty z urządzeniami, które okażą się dla Zamawiającego nieprzydatne, a tym samym udzielenie niniejszego zamówienia straciłoby sens.

Z drugiej strony nie można pominąć, że wykonawcy nie znają tej aplikacji, ponieważ jej autorem i jedynym dysponentem jest Zamawiający. Odwołujący i Przystępujący podnoszą, że co do zasady aplikacje pisze się pod konkretne wymagania i nie znając dokumentacji oraz kodów źródłowych aplikacji KM SW D nie będą mogli w trakcie testów wstępnych zweryfikować, dlaczego aplikacja się nie uruchamia lub nie działają jej określone funkcjonalności, jak też nie będą mogli ewentualnie dostosować do niej oferowanego urządzenia. Rodzi to po stronie wykonawców ryzyko odrzucenia oferty w testach akceptacyjnych, a nawet jeśli testy akceptacyjne zakończyłyby się wynikiem pozytywnym i dany wykonawca zawarłby umowę z Zamawiającym, istniałoby ryzyko dostarczenia urządzeń, na których aplikacja nie będzie działała, co grozi odstąpieniem Zamawiającego od umowy wykonawczej i nawet wypowiedzeniem umowy ramowej (w myśl postanowień PPUR i PPUW przewidzianych przez Zamawiającego). Argumentacja wykonawców została częściowo potwierdzona przez Zamawiającego, który sam stwierdził, że w trakcie testów wstępnych możliwe będzie zidentyfikowanie błędów leżących tylko po stronie sprzętu lub oprogramowania, ale nie samej aplikacji KM SWD.

Jednocześnie Zamawiający ma rację, że zakres testów wstępnych nie został ograniczony, ale nie zmienia to faktu, że bez znajomości dokumentacji i kodów źródłowych aplikacji, wykonawcy nie będą mogli w trakcie testów wstępnych ustalić, jakie cechy tej aplikacji powodują, że nie działa ona na danym urządzeniu. Sytuacji nie polepszyła też odpowiedź Zamawiającego z dnia 26.08.2024 r. na pytanie wykonawcy, w której Zamawiający poinformował, że:

„Zamawiający podczas testu wstępnego udostępni aplikację KM SW D, karty sim do APN wykorzystywanego przez zamawiającego, skróconą instrukcję obsługi aplikacji KM SW D oraz dane testowe niezbędne do zalogowania się do aplikacji. W związku z powyższym nie ma potrzeby aby używać środowisko z Android Studio. Test ten ma na celu umożliwienie sprawdzenia uruchomienia i poprawnego działania istniejącej aplikacji KM SW D, której skompilowany pakiet otrzyma wykonawca w dniu testu. Wykonawca może posiadać ze sobą własne stanowisko z interfejsem umożliwiającym debug urządzenia oraz odczyt logów (np. Logcat), aby w przypadku gdy wystąpi krytyczny wyjątek działania aplikacji wykonawca mógł poznać przyczynę powstania błędu na podstawie odczytanych danych”.