KIO 3141/25

Sygn. akt KIO 3141/25 WYROK Warszawa, 19 września 2025 roku Krajowa Izba Odwoławcza - w składzie: Przewodnicząca: Agnieszka Trojanowska Protokolantka: Aldona Karpińska po rozpoznaniu na rozprawie, odwołania wniesionego do Prezesa Krajowej Izby Odwoławczej 28 lipca 2025 r. przez wykonawcę Mennica Polska spółka akcyjna z siedzibą w Warszawie, ul. Ciasna 6 w postępowaniu prowadzonym przez zamawiającego Miasto Poznań - Zarząd Transportu Miejskiego w Poznaniu, ul. Matejki 59 Uczestnik po stronie odwołującego GMV Innovating Solutions Spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie, ul. Hrubieszowska 2 orzeka: 1.Umarza postępowanie w zakresie pkt. 10.1 oraz INTEGRACJA PLANOWANEGO SYSTEMU MTT PEKA Z ISTNIEJĄCYM SYSTEMEM PEKA w zakresie dotyczącym wyłącznie systemu PEKA na podstawie art. 568 pkt 2 ustawy, 2.Oddala odwołanie w pozostałym zakresie, 3.Kosztami postępowania obciąża odwołującego i: 3.1.Zalicza w poczet kosztów postępowania kwotę 15 000 zł. (piętnaście tysięcy złotych zero groszy) tytułem uiszczonego wpisu, kwotę 3 600 zł 00 gr (trzy tysiące sześćset złotych zero groszy) tytułem wydatków pełnomocnika odwołującego. Na orzeczenie – w terminie 14 dni od jego doręczenia przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do Sądu Okręgowego w Warszawie- Sądu Zamówień Publicznych. Przewodnicząca:…………………. Sygn. akt KIO 3141/25 Uzasadnienie Postępowanie o udzielenie zamówienia publicznego prowadzonego w trybie przetargu nieograniczonego pn. „Rozbudowa i unowocześnienie systemu PEKA”, znak sprawy: ZTM.EZ.3310.10.2025 ogłoszono w w Dzienniku Urzędowym UE numer: OJ S 136/2025 z 18 lipca 2025 28 lipca 2025 r. wykonawca Mennica Polska spółka akcyjna z siedzibą w Warszawie, ul. Ciasna 6 wniósł odwołanie przez pełnomocnika działającego na podstawie pełnomocnictwa z 24 lipca 2025 r. udzielonego przez prezesa zarządu i prokurenta. Odwołanie zostało opłacone i dołączono dowód jego przekazania zamawiającemu. Odwołujący zarzucił zamawiającemu naruszenie następujących przepisów: 1.art. 99 ust. 1 i 2 i 4 ustawy przez opisanie przedmiotu zamówienia w sposób ogólny i nieadekwatny do wymagań związanych z opisaniem przedmiotu zamówienia oraz w sposób ograniczający i uniemożlwiający udział odwołującego w realizacji zamówienia, jak również przez zaniechanie udostępnienia dokumentacji pochodzącej od podmiotów trzecich tj. spółki Eviden Polska S.A. i spółki R&G Plus Sp. z o. o., i zaniechanie opisania przedmiotu zamówienia z uwzględnieniem wszystkich wymagań mogących mieć wpływ na sporządzenie oferty; 2.art. 133 ust. 1 ustawy przez zaniechanie udostępnienia dokumentacji pochodzącej od podmiotów trzecich tj. spółki Eviden Polska S.A. i spółki R&G Plus Sp. z o. o. i zaniechanie określenia, że dokumentacja pochodząca od ww. podmiotów może mieć charakter poufny w sytuacji, gdy z dokumentacji przetargowej wynika obowiązek współpracy odwołującego i innych wykonawców z tymi ww. podmiotami, a zamawiający zaniechał określenia zasad współpracy z tymi podmiotami; 3.art. 431 ustawy przez wyłączenie obowiązku współpracy pomiędzy potencjalnym wykonawcą (w tym odwołującym) a zamawiającym na etapie realizacji umowy w sprawie zamówienia publicznego przez zobowiązanie potencjalnego wykonawcy (w tym odwołującego) do współpracy z wykonawcą sytemu PEKA, w sytuacji gdy współpraca taka jest niemożliwa do realizacji bądź utrudniona z przyczyn niezależnych od potencjalnego wykonawcy(w tym odwołującego); 4.art. 16 ustawy przez zaniechanie przeprowadzenia postępowania o udzielenie zamówienia publicznego w sposób zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców. Wniósł o: 1.uwzględnienie odwołania w całości; 2.nakazanie zamawiającemu dokonanie zmiany treści SW Z w zakresie opisu przedmiotu zamówienia - w sposób wskazany w uzasadnieniu odwołania, w szczególności: a)opisanie i udostępnienie narzędzi informatycznych do integracji planowanego systemu MTT PEKA z istniejącym systemem PEKA; b)określenie zasad współpracy z wykonawcą systemu PEKA – spółką Eviden Polska S.A. oraz R&G Plus Sp. z o. o. z uwzględnieniem postanowień wskazujących na zamawiającego jako gwaranta współpracy wybranego wykonawcy z dostawcą systemu PEKA tj. firmą Eviden Polska S.A. bez ponoszenia przez wykonawcę jakichkolwiek kosztów tej współpracy; c)określenie listy urządzań tj. modemów, routerów do realizacji systemu łączności; d)wyłączenia odpowiedzialności wykonawcy za prawidłowość i ciągłość działania systemu w sytuacji, w której jest on zobowiązany do używania urządzeń, na których działanie nie ma wpływu ewentualnie usunięcie takiego wymagania z dokumentacji postępowania; e)określenie danych sprzedażowych w celu umożliwienia kalkulacji kosztów prowizji Agenta rozliczeniowego; f)udostępnienia dokumentacji wytworzonej w toku realizacji zamówienia z wykonawcą systemu PEKA – spółką Eviden Polska S.A. oraz R&G Plus Sp. z o.o. g)wyłączenie odpowiedzialności wykonawcy w związku z realizacją umowy w sprawie zamówienia publicznego związanej z koniecznością nawiązania współpracy z wykonawcą systemu PEKA- spółką Eviden Polska S.A. Odwołujący jest wykonawcą, który ma interes w uzyskaniu przedmiotowego zamówienia oraz może ponieść szkodę w wyniku naruszenia przez zamawiającego powołanych w odwołaniu przepisów ustawy . Odwołujący jest zainteresowany udziałem w postępowaniu oraz zawarciem umowy w sprawie zamówienia publicznego. Jednakże w sytuacji, gdy postanowienia SW Z zostały sformułowane w sposób sprzeczny z ustawą, odwołujący nie ma możliwości złożenia oferty spełniającej wymagania SWZ oraz stanowiącej faktyczną konkurencję wobec pozostałych wykonawców ubiegających się o udzielenie zamówienia, a w szczególności tych, którzy w chwili obecnej świadczą na rzecz zamawiającego usługę tożsamą z przedmiotem zamówienia i od których to podmiotów uzależniona jest możliwość złożenia oferty i skalkulowania ceny. Kwestionowane w odwołaniu postanowienia SW Z pozbawiają odwołującego możliwości uzyskania przedmiotowego zamówienia publicznego i jego realizacji na najkorzystniejszych dla zamawiającego warunkach. Powyższe niezbicie dowodzi istnienia interesu odwołującego w uzyskaniu przedmiotowego zamówienia. Odwołujący wskazał, że w wyniku naruszenia przez zamawiającego przepisów ustawy może ponieść szkodę. Gdyby zamawiający postąpił zgodnie z przepisami ustawy , to prawidłowo sformułowałby postanowienia SW Z w zakresie opisu przedmiotu zamówienia i udostępniłby wszystkie dokumenty, w tym dotyczące podmiotów trzech wskazanych w dokumentacji przetargowej. Tym samym oferta odwołującego mogłaby zostać wybrana jako najkorzystniejsza. Przez kwestionowane w odwołaniu postanowienia SW Z zamawiający pozbawił odwołującego możliwości uzyskania zamówienia i zawarcia z zamawiającym umowy w sprawie zamówienia publicznego. W rezultacie odwołujący nie może uzyskać przedmiotowego zamówienia i osiągnąć zysku, który odwołujący planował osiągnąć w wyniku realizacji przedmiotowego zamówienia. Sporządzenie opisu przedmiotu zamówienia to prerogatywa zamawiającego, a zarazem jeden z jego kluczowych obowiązków związanych z przygotowaniem postępowania o udzielenie zamówienia publicznego. Zamawiający jako gospodarz postępowania ma prawo, wyznaczając cel, jaki zamierza zrealizować, tak określić przedmiot zamówienia, aby ten cel osiągnąć, zachowując jednocześnie obiektywizm w formułowaniu opisu swoich potrzeb oraz wytyczne wynikające z przepisów. Jednakże sporządzając opis przedmiotu zamówienia nie można tracić z pola widzenia naczelnych zasad prawa zamówień publicznych, w szczególności związanych z zachowaniem równego traktowania wykonawców i takiego opisu przedmiotu zamówienia, który nie będzie wykluczał wykonawców z możliwości złożenia konkurencyjnej względem pozostałych wykonawców ubiegających się o udzielenie zamówienia, oferty. Zasady sporządzenia opisu przedmiotu zamówienia określone zostały w art. 99 – 103 ustawy. Zgodnie z art. 99 ust. 1 ustawy , 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. Zgodnie zaś z art. 99 ust. 4 ustawy przedmiotu zamówienia nie można opisywać w sposób, który mógłby utrudniać uczciwą konkurencję. Zamawiający opisał przedmiot zamówienia ale z pominięciem ustawowych wymagań w tym zakresie. Określił co jest przedmiotem zamówienia i określił główne założenia realizacji zamówienia, ale nie określił szczegółowo sposobu jego realizacji, uzależniając konieczność pozyskania danych niezbędnych do jego wykonania od podmiotu trzeciego tj. wykonawcy systemu PEKA spółki Eviden Polska S.A. Zamawiający opisał przedmiot zamówienia w taki sposób, że uniemożliwia odwołującemu przygotowanie i złożenie oferty. Dokumentacja przetargowa i wymagania dotyczące przedmiotu zamówienia, wszelkich praw i obowiązków związanych z realizacją zamówienia nie są czytelne i możliwe do spełnienia dla potencjalnych wykonawców, z wyjątkiem podmiotów, które świadczą na rzecz zamawiającego analogiczną usługę jak przedmiotowe zamówienia, a które to podmioty zostały wprost wskazane w dokumentacji przetargowej – R&G Plus Sp. z o. o. oraz Eviden Polska S.A. Postępowanie o udzielenie zamówienia musi być zatem prowadzone tak, aby nie prowadziło do wyłączenia bez uzasadnionej przyczyny chociażby jednego wykonawcy z możliwości złożenia oferty, stwarzając korzystniejszą sytuację pozostałym wykonawcom. Tymczasem w przedmiotowym postępowaniu reguła ta jest całkowicie wypaczona. Zamawiający nie tylko opisał przedmiot zamówienia w sposób, który faworyzuje podmioty realizujące usługę tożsamą z zamawianą, ale zaniechał udostępniania jakiejkolwiek dokumentacji tych podmiotów, przerzucając ciężar pozyskania stosownych dokumentów na wykonawców zainteresowanych realizacją zamówienia. W sytuacji, gdy zamawiający nie jest w stanie opisać przedmiotu zamówienia z zachowaniem wszelkich zasad wynikających z ustawy , to powinien przynajmniej udostępnić posiadaną dokumentację, w tym także pozyskaną od podmiotów trzecich realizujących w chwili obecnej zamówienia, która to dokumentacja pozwoli odwołującemu oszacować zakres zamówienia oraz wszelkie ryzyka, jak również pozwoli określić zasady współpracy z podmiotami trzecimi na etapie przed złożeniem oferty. W ocenie odwołującego następujące zapisy wskazane w treści opisu przedmiotu zamówienia w sposób istotny ograniczają uczciwą konkurencję w postępowaniu wskazując na wymaganie, które w żaden sposób nie znajduje uzasadnienia w obiektywnych potrzebach zamawiającego, zaś służą faworyzowaniu podmiotów wprost wskazanych w dokumentacji postępowania. Odwołujący zakwestionował następujące postanowienia: INTEGRACJA PLANOWANEGO SYSTEMU MTT PEKA Z ISTNIEJĄCYM SYSTEMEM PEKA To wymaganie jest wskazane w wielu miejscach OPZ, np.: 1)1. WSTĘP Poniższy dokument stanowi Opis Przedmiotu Zamówienia dla wyłonienia wykonawcy zadania pn. Rozbudowa i unowocześnienie systemu PEKA przez uruchomienie systemu płatności zbliżeniowych w kasownikach wraz z dostawą infrastruktury podsystemu transportowego i integracją z systemem PEKA. 2)3.3. PRZEDMIOT ZAMÓWIENIA „Integracja systemu płatności zbliżeniowych MTT (System MTT PEKA) z Systemem Centralnym PEKA, umożliwiająca w trybie online obsługę usług realizowanych przez Konto Pasażera oraz sprawne zarządzanie całym systemem biletowym, urządzeniami oraz kanałami sprzedaży biletów…” 3)10.2. SYSTEM RAPORTOWY MTT PEKA: „Zamawiający wymaga dostarczenia systemu raportowego powalającego na realizację poniższych wymagań oraz eksport danych MTT PEKA do bazy danych systemu PEKA.” 4)16. WSPÓŁPRACA Z WYKONAWCĄ SYSTEMU PEKA „komunikacji Kasowników z Systemem MTT PEKA i Systemem PEKA, wraz z obsługą aktualnych procesów Systemu PEKA” Jednocześnie brak jest jakiejkolwiek informacji, że zamawiający udostępni wykonawcom jakiekolwiek narzędzia informatyczne, które umożliwią przeprowadzenie takiej integracji. W miejsce tego Zamawiający wymaga (p. 16 OPZ) podjęcia współpracy z wykonawcą systemu PEKA – spółką Eviden Polska S.A., który jest również potencjalnym wykonawcą w postępowaniu na wdrożenie systemu MTT PEKA. Powyższe działanie uniemożliwia odwołującemu prawidłowe skalkulowanie ceny, gdyż nie ma wiedzy na temat dostępnych narządzi informatycznych do realizacji zamówienia. Co więcej odwołujący nie ma absolutnej pewności, że spółka Eviden Polska S.A. umożliwi korzystanie z narzędzi, a jeśli tak to na jakich warunkach. W szczególności nie wskazano czy korzystanie z narządzi będzie nieodpłatne czy też konieczne jest zawarcie odpłatnej umowy z ww. podmiotem. Zamawiający tym samym ciężar przygotowania prawidłowego opisu przedmiotu zamówienia i określenia faktycznego zakresu prac oraz warunków tych prac przerzucił na potencjalnego wykonawcę. Uzależnienie realizacji zamówienia od współpracy z podmiotem trzecim – także potencjalnym wykonawcą zamówienia, stanowi wyraz utrudnienia uczciwej konkurencji. Powołał wyrok KIO z dnia 5 marca 20221, sygn. akt KIO 89/21. 5. NOŚNIKI IDENTYFIKATORÓW W SYSTEMIE PEKA I MTT System MTT PEKA będący nowym modułem Systemu PEKA, połączonym z Systemem Centralnym PEKA i powinien zapewnić obsługę kart PEKA w zakresie wskazanym w p. 5.1. OPZ. Jednocześnie zamawiający nie wskazał, że udostępni wykonawcy jakiekolwiek narzędzia informatyczne, które umożliwią komunikację z kartami PEKA. Brak informacji na temat udostępnienia narzędzi uniemożliwia skalkulowanie ceny oferty i określania ryzyk związanych z realizacją zamówienia. 7.1. TERMINAL KIEROWCY/STEROWNIK KASOWNIKÓW Obecnie zamawiający użytkuje Terminale Kierowcy typu SRG5000P oraz SRG7000P firmy R&G Plus Sp. z o.o. z siedzibą w Mielcu, ul. Traugutta 7, 39-300 Mielec. W ramach realizacji zamówienia, wykonawca zobowiązany będzie do integracji swoich urządzeń z komputerami pokładowymi w pojazdach wszystkich operatorów (w autobusach i tramwajach). W tym celu niezbędnym jest ustalenie przez Wykonawcę zasad współpracy bezpośrednio z gwarantem systemu PEKA – firmą Eviden Polska S.A. z siedzibą w Warszawie, ul. Pułaska 180, 00-180 Warszawa. Z tego tytułu zamawiający nie będzie ponosił dodatkowych kosztów na rzecz wykonawcy. Dopuszczalne jest zastosowanie innych rozwiązań umożliwiających połączenie Kasowników Systemu MTT PEKA z urządzeniami w pojeździe oraz Systemem Centralnym PEKA i innych podsystemów PEKA, z zastrzeżeniem, że kierowca nie może być zobligowany do podwójnego logowania się do systemów. Powyższe zapisy to ewidentne uprzywilejowanie konkretnych wykonawców: 1.R&G Plus Sp. z o.o. – dostawcę terminali kierowcy, z którymi trzeba się zintegrować, 2.Eviden Polska S.A. – dostawcę obecnego systemu PEKA. Z bardzo dużym prawdopodobieństwem można stwierdzić, że oba ww. podmioty będą uczestniczyły w bieżącym postępowaniu. A to oznacza, że nałożenie na wykonawcę wymogu współpracy z firmą Eviden może oznaczać bardzo wysokie koszty dla wszystkich pozostałych wykonawców lub skutkować brakiem możliwości przystąpienia do postępowania. W ramach ww. wymagania pojawia się wprawdzie zapis: W przypadku, gdy wykonawca uzna, że w miejsce integracji z obecnie użytkowanymi urządzeniami (Terminal Kierowcy), dostarczy i skonfiguruje własne, zobowiązany będzie do zachowania pełnej, działającej dotychczas funkcjonalności tych urządzeń dla Systemu PEKA i Systemu ITS. Wymagane jest także w tym przypadku dostarczenie zamawiającemu w pełni udokumentowanych protokołów komunikacji między tymi urządzeniami, umożliwiających dokonywanie przez zamawiającego dalszych integracji. Jednak takie rozwiązanie oznacza bardzo duże i nieuzasadnionych koszty na zdublowanie już istniejących rozwiązań. W konsekwencji powyższe wymaganie oznacza wyeliminowanie wszystkich wykonawców oprócz dwóch wskazanych powyżej podmiotów. 7.3. ŁĄCZNOŚĆ Wykonawca zobowiązany jest wykorzystać do realizacji systemu łączności działające w pojazdach urządzenia, takie jak modemy, routery, anteny, po wcześniejszych uzgodnieniach poczynionych bezpośrednio z wykonawcą Systemu PEKA. Powyższe zapisy to ewidentne uprzywilejowanie konkretnych wykonawców: 1.R&G Plus Sp. z o.o. – dostawcę wyposażenia pojazdów, 2.Eviden Polska S.A. – dostawcę obecnego systemu PEKA. Powyższe wymaganie oznacza, że wykonawcy inni niż dwaj wskazani powyżej nie są w stanie skutecznie realizować wymagania określonego w p. 4 pp. 2 OPZ tj. zapewnić ciągłości działania systemu MTT PEKA w przypadku braku połączenia (synchronizacji) z Systemem Centralnym PEKA, zachowując redundancję i dywersyfikację kanałów sprzedaży ZTM, są oni bowiem zobowiązani do wykorzystania urządzeń, na których sprawność i jakość działania nie mają żadnego wpływu. Jednocześnie zamawiający nie wskazał listy urządzeń, które mają być wykorzystane przez wykonawców co uniemożliwia oszacowanie ostatecznej wartości oferty w postępowaniu. 16. WSPÓŁPRACA Z WYKONAWCĄ SYSTEMU PEKA Wykonawca Systemu MTT PEKA zobowiązany będzie do ścisłej współpracy z wykonawcą/Gwarantem Systemu PEKA, co najmniej w zakresie: 1.wyposażenia pojazdów w urządzenia MTT PEKA i ich integrację z istniejącymi urządzeniami pokładowymi, 2.integracji Serwisu Internetowego MTT PEKA z Portalem Pasażera, 3.konfiguracji połączeń sieciowych pomiędzy systemami, 4.komunikacji Kasowników z Systemem MTT PEKA i Systemem PEKA, wraz z obsługą aktualnych procesów Systemu PEKA, 5.każdym innym, wymaganym do realizacji celów projektu Systemu MTT PEKA. Wykonawca Systemu MTT PEKA zobowiązany będzie do sprawnej, bezpiecznej i zgodnej z wymaganiami integracji systemów, współpracy z obecnym wykonawcą Systemu PEKA. Powyższe zapisy powodują zależność wszystkich wykonawców od podmiotu trzeciego tj. Eviden Polska S.A. Spółka Eviden może zażądać od pozostałych wykonawców (albo tylko od niektórych) wygórowanych cen za swoje usługi. Albo może w ogóle nie przedstawić oferty na swoje usługi. To powoduje, że cena ofertowa może być bardzo zawyżona lub w ogóle niemożliwa do skalkulowania. Zamawiający zobowiązany jest do opisania przedmiotu zamówienia w sposób, który zapewni równy dostęp dla każdego zainteresowanego podmiotu świadczącego usługi i prowadzącego działalność gospodarczą w obszarze związanym z przedmiotem zamówienia. Usługi będą przedmiotem tego zamówienia są usługami możliwymi do świadczenia także przez inne podmioty niż te wymienione w dokumentacji przetargowej, pod warunkiem, że informacje na temat obecnie świadczonych usług i katalog czynności do wykonania przez przyszłego wykonawcę, będzie wynikał wprost z dokumentacji przetargowej. Zamawiający w tym zakresie ograniczył się jedynie do wskazania katalogu czynności współpracy, a nie zakresu wymaganego świadczenia. W sytuacji, gdy zamawiający wymaga współpracy z podmiotem trzecim, winien udostępnić całość dokumentacji tego podmiotu. Zamawiający ma ku temu narzędzia choćby nawet przez udostępnienie dokumentacji podmiotu trzeciego po odebraniu stosownego oświadczenia o zachowaniu poufności. Zamawiający nie ma obowiązku udostępniać SW Z, jeśli zawiera ona informacje o poufnym charakterze podlegające ochronie. W takiej sytuacji jest zobowiązany wskazać inny sposób dostępu do SW Z wraz z wymaganiami (zwłaszcza technicznymi) zapewniającymi ochronę poufnego charakteru informacji (art. 133 ust. 3 ustawy). W przedmiotowym postępowaniu zaniechał udostępnienia dokumentacji podmiotów R&G Plus Sp. z o.o. oraz Eviden Polska S.A. oraz nie wskazał, że dokumentacja ta ma poufny charakter, przerzucając ciężar pozyskania dokumentacji i informacji niezbędnych do realizacji zamówienia na wykonawców. Działania takie nie zasługuje na ochronę i jako takie stanowi ograniczenie konkurencji dla podmiotów zainteresowanych realizacją zamówienia. 10.1. PŁATNOŚCI W SYSTEMIE MTT PEKA Koszty agenta rozliczeniowego 14. Koszt prowizji od transakcji obsłużonej przez Agenta rozliczeniowego leży po stronie wykonawcy. Nie ma możliwości oszacowania tych kosztów, ponieważ zamawiający nie wskazuje żadnych danych sprzedażowych, od których można byłoby te wartości wyliczyć. To uniemożliwia oszacowanie wartości oferty. Powyższe postanowienia OPZ mają kluczowa znaczenie dla ustalenia ostatecznego zakresu przedmiotu zamówienia oraz określenia ryzk związanych z realizacją zamówienia. Zamawiający przez ustanowienie obowiązku współpracy z wykonawcą systemu PEKA, uchylił się od współpracy z potencjalnym wykonawcą przedmiotowego zamówienia. Zakres współpracy wykonawcy z wykonawcą systemu PEKA winien dotyczyć współpracy z zamawiającym w miejsce spółki Eviden Polska S.A. Zasada współdziałania w zakresie realizacji umowy o zamówienie publiczne określona w art. 431 ustawy , adresowana jest do zamawiającego oraz wybranego w postępowaniu wykonawcy czyli stron umowy o zamówienie publiczne. Zgodnie z tym przepisem zamawiający i wykonawca obowiązani są współdziałać przy wykonaniu umowy w sprawie zamówienia publicznego, w celu należytej realizacji zamówienia. Zasada ta ma na celu wzmocnienie regulacji dotyczącej etapu realizacji umowy w sprawie zamówienia publicznego. Zasada współdziałania polega na współpracy wykonawcy z zamawiającym, przejawiającej się w szczególności koniecznością wzajemnego informowania się o przebiegu umowy, zgłaszaniu wątpliwości i problemów, a także szybkim reagowaniu i podejmowaniu decyzji, niezbędnych dla prawidłowej realizacji zobowiązania. Dyspozycją tego przepisu nie są objęte inne podmioty uczestniczące przy realizacji zamówienia takie jak wykonawca systemu PEKA. W związku z tym obowiązek nawiązania współpracy z spółką Eviden Polska S.A.. powinien być wyłączony albo wyłączona powinna być odpowiedzialność związana z realizacją umowy w sprawie zamówienia publicznego, która uzależniona jest także od współpracy z podmiotem trzecim. Elementy określone przez zamawiającego, które powinny być przedmiotem współpracy, w szczególności wskazane w pkt 16 opisu przedmiotu zamówienia, takie jak: wspólne ramy integracji, odpowiedzialność za interfejsy, uzgodniony harmonogram i kamienie milowe, wspólne szkolenia oraz pozostałe elementy, przenikają do postanowień umownych jako obowiązki wykonawcy związane z realizacją zamówienia. Sankcją za jakiekolwiek uchybienia w zakresie obowiązków wykonawcy, są kary umowne. Zamawiający zaniechał przy tym jednoznacznego wskazania, że wykonawca nie ponosi odpowiedzialności i nie będą mu naliczone jakiekolwiek kary umowne z tytułu braku współpracy z podmiotami trzecimi, w szczególności z wykonawcą systemu PEKA – spółką Eviden Polska S.A. Jak wskazano powyżej, podmiot ten jako konkurencja odwołującego, może nie być zainteresowany współpracą zarówno przed złożeniem oferty, jak również na etapie realizacji zamówienia. Z tego względu zasadne jest wyłączenie odpowiedzialności odwołującego w sytuacji braku współpracy bądź też utrudnionej współpracy na etapie realizacji zamówienia. Odwołujący z uwagi na brak danych co do zakresu szczegółowej współpracy na etapie przed złożeniem oferty, jak również w trakcie realizacji zamówienia, nie jest w stanie wycenić ryzyka związanego z przypisaniem odpowiedzialności za brak współpracy odwołującego z wykonawcą systemu PEKA. Z tego względu uzasadnione jest udostępnienia pełnej dokumentacji dotyczącej systemu PEKA, a w przypadku gdyby udostępnienie nie było możliwe, wyłączenie odpowiedzialności odwołującego w przypadku braku współpracy lub utrudnionej współpracy ze spółką Eviden Polska S.A.. 30 lipca 2025 r. zamawiający poinformował o wniesieniu odwołania. 31 lipca 2025 r. do postępowania odwoławczego po stronie zamawiającego zgłosił się Eviden Polska SA z siedzibą w Warszawie, ul. Puławska 180 działając przez prezesa zarządu. Dołączono dowody przekazania przystąpienia stronom. Wniósł o odrzucenie odwołania Mennica Polska S.A.. jako niezasadnego i nieopartego na rzeczywistych naruszeniach przepisów ustawy. Przystępujący posiada interes w uzyskaniu rozstrzygnięcia na korzyść zamawiającego, gdyż uwzględnienie odwołania spowoduje zmianę niezgodnych z przepisami ustawy zapisów Specyfikacji Warunków Zamówieniu i umożliwi przystępującemu złożenie ważnej oferty w postępowaniu. 1 sierpnia 2025 r. Eviden Polska spółka akcyjna przekazał kolejne przystąpienie z wnioskiem o odrzucenie odwołania, w którym interes sprecyzował w następujący sposób „Stosownie do treści art. 525 ust.1 ustawy Pzp wskazuję, że wykonawca Eviden Polska S.A. ma interes w uzyskaniu rozstrzygnięcia na korzyść Zamawiającego, albowiem uwzględnienie odwołania powodowałoby, iż interes Przystępującego w uzyskaniu zamówienia zostałby naruszony. Przystępujący zastrzega sobie prawo do podniesienia szczegółowej argumentacji dotyczącej zarzutów na posiedzeniu, ewentualnie na rozprawie.” 1 sierpnia 2025 r. do postępowania odwoławczego po stronie odwołującego zgłosił się GMV Innovating Solutions Spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie, ul. Hrubieszowska 2 działając przez pełnomocnika na podstawie pełnomocnictwa z 21 lipca 2025 r. udzielnego przez prezesa i wiceprezesa zarządu. D zgłoszenia dołączono dowody jego przekazania stronom. Wniósł uwzględnienie odwołania złożonego przez Wykonawcę Mennica Polska S.A. Przystępujący stwierdził, że wszystkie zarzuty odwołującego i argumentacja wskazana dla ich poparcia są w pełni zasadne, toteż wniósł on o uwzględnienie odwołania. Działania zamawiającego wskazane w odwołaniu naruszają również interes przystępującego, gdyż zaskarżone przez odwołującego zapisy SW Z uniemożliwiają skutecznie złożenie oferty przez przystępującego. Przystępujący posiada interes w przystąpieniu do sprawy jako uczestnik postępowania, mający szanse na uzyskanie przedmiotowego zamówienia publicznego. 4 września 2025 r. zamawiający złożył odpowiedź na odwołanie i odnośnie wniosku przystępującego w przedmiocie odrzucenia odwołania wskazał, że czynność odrzucenia odwołania zgodnie z art. 528 ustawy, badana jest przez Izbę z urzędu, bez względu na ewentualny wniosek strony czy uczestnika postępowania, tym samym zachowuje postawę neutralną, wobec tego wniosku, albowiem nie może merytorycznie się do niego odnieść z uwagi na brak wskazania przesłanki mającej stanowić podstawę uzasadnienia dokonania tej czynności, a w przypadku, jeżeli autor miał na myśli oddalenie odwołania to popiera go w całości. Wniósł o: 1.Oddalenie odwołania w całości jako bezzasadnego. 2.Nieuwzględnianie żądań zmiany treści SW Z, które prowadziłyby do ograniczenia równościi naruszenia zasad proporcjonalności, transparentności i uczciwej konkurencji. Zamawiający nie podziela uzasadnienia odwołującego, w zakresie przedstawionych w odwołaniu zarzutów. Przesądzającym jest w szczególności, brak rzeczowej argumentacji oraz brak poparcia zarzutów dowodami. Odwołujący zatem nie tylko, że nie udowodnił swoich twierdzeń, ale nawet ich nie uprawdopodobnił. W ocenie zamawiającego, odwołanie wniesione przez Mennica Polska S.A. należy uznać za niezasadne i zmierzające w istocie nie do zapewnienia uczciwej konkurencji, lecz do jej ograniczenia przez eliminację konkurentów. Argumentacja przedstawiona przez odwołującego jest wewnętrznie sprzeczna, nielogiczna, a przede wszystkim nie wskazuje rzeczywistego naruszenia przepisów ustawy. Celem odwołującego jest de facto zablokowanie postępowania, co wpisuje się w model działania rynkowego polegający na wykorzystywaniu procedur odwoławczych jako narzędzia przewagi konkurencyjnej, a nie realnej ochrony interesów wykonawców. 1. Co do zarzutu naruszenia art. 99 ust. 1, 2 i 4 ustawy Zarzut ten jest bezpodstawny. Zamawiający dokonał opisu przedmiotu zamówienia w sposób wyczerpujący, jednoznaczny i dostatecznie precyzyjny, uwzględniając okoliczności mające wpływ na przygotowanie oferty. Odwołujący wskazał, że nie ma dostępu do informacji dot. integracji z systemem PEKA oraz narzędzi informatycznych. Tymczasem OPZ przewiduje możliwość dostarczenia własnych urządzeń oraz protokołów komunikacyjnych umożliwiających integrację. Zamawiający nie narzuca konkretnego producenta ani technologii, a jedynie wymaga kompatybilności z istniejącym systemem, co jest standardem w projektach IT realizowanych na rzecz JST. Odwołujący w treści zarzutu nr 1 operuje treściami nieostrymi i wieloznacznymi, co w istocie uniemożliwia nawet zamawiającemu ich merytoryczną weryfikację, a w konsekwencji ocenę ich zasadności. 2. Co do zarzutu naruszenia art. 133 ust. 1 ustawy (brak udostępnienia dokumentacji podmiotów trzecich) Zarzut ten nie znajduje potwierdzenia w faktach. Dokumentacja, która mogłaby pochodzić od firm Eviden Polska S.A. i R&G Plus Sp. z o.o., stanowi ich know-how i może zawierać informacje poufne. W takiej sytuacji nie jest dopuszczalne jej udostępnienie bez zgody tych podmiotów, a zamawiający nie posiada uprawnień właścicielskich do tych danych. Odwołujący może, jak każdy wykonawca, samodzielnie wystąpić do tych podmiotów w celu uzyskania informacji niezbędnych do integracji, o czym zresztą wspomniano w OPZ. Niezależnie od powyższego zamawiający zwrócił uwagę, że tak samo jak w przypadku zarzutu nr 1 zarzut ten jest absolutnie nieprecyzyjny i ma charakter otwarty, a rolą zamawiającego nie jest snucie domysłów, lub usiłowanie dookreślenia tego zarzutu i zamknięcie go w konkretne ramy. Odwołujący bowiem nie pisze udostępnienia jakiej dokumentacji domaga się w tym punkcie i która to dokumentacja pochodząca od podmiotów trzecich stanowi przedmiot jego żądania. Wynikowo podobnie jak w przypadku zarzutu pierwszego sam odwołujący czyni swój zarzut niemożliwy do uwzględnienia i merytorycznej weryfikacji. Narracja zatem odwołującego o rzekomych umowach mających na celu zainicjowanie poufności ma tylko charakter „technikaliów” nie może natomiast stanowić zastąpienia merytorycznej treści zarzutu, którą można byłoby zweryfikować pod kątem prawdziwości i zasadności. 3. Co do zarzutu naruszenia art. 431 ustawy (brak gwarancji współpracy) Zarzut ten jest absurdalny. Zamawiający nie może zobowiązywać podmiotów trzecich, takich jak dostawca systemu PEKA, do współpracy z wykonawcami. Zamawiający może jednak i faktycznie to czyni, zapewnić, że podejmie niezbędne działania organizacyjne, aby umożliwić współpracę, np. udostępniając kontakty czy organizując spotkania robocze. Pryncypialność stwierdzenia o absurdalności tego zarzutu wynika z faktu, że zarzut ten w istocie nie dotyczy treści SW Z a w szczególności opisu przedmiotu zamówienia, natomiast okoliczności o charakterze faktycznym a w dodatku okoliczności tego rodzaju, że mają one charakter przyszły i niepewny, a co najważniejsze pozostający w całości poza mocą postulacyjną zamawiającego. Wynikowo zatem czynienie zamawiającemu zarzutu opartego o chybione podstawy, które niemożliwe są do weryfikacji w sposób obiektywny, a raczej pozbawiony kontaktu z rzeczywistością, nie może się ostać. 4. Co do zarzutu naruszenia art. 16 ustawy (brak równego traktowania) Brak jest jakichkolwiek przesłanek potwierdzających zarzut naruszenia zasad uczciwej konkurencji. Zamawiający nie wskazuje konkretnych producentów ani wykonawców, nie narzuca ich wyboru, ani nie warunkuje wykonania zamówienia współpracą z konkretnym podmiotem. Wręcz przeciwnie – wskazuje, że wykonawca może dostarczyć alternatywne rozwiązania, o ile zapewni kompatybilność systemową. To właśnie stanowi urzeczywistnienie zasad równości i uczciwej konkurencji. 5. Odwołujący jako wykonawca dominujący na rynku Odwołujący jest dominującym uczestnikiem rynku sprzedaży biletów miejskich i usług rozliczeniowych w sektorze publicznym. Wniesienie odwołania przez taki podmiot może być postrzegane jako działanie zmierzające do ograniczenia możliwości wejścia na rynek nowym wykonawcom. W odwołaniu nie wskazano żadnych realnych barier technologicznych, które uniemożliwiałyby przygotowanie oferty – przeciwnie, odwołujący oczekuje, aby zamawiający zrealizował znaczącą część prac przygotowawczych za wykonawcę, co jest sprzeczne z naturą zamówienia w formule projektowej. 6. Brak interesu wykonawcy Odwołujący nie wykazał rzeczywistego interesu, który mógłby zostać naruszony. Nie wykazano też, żeby ograniczenia w dokumentacji faktycznie uniemożliwiały złożenie oferty, a nie stanowiły jedynie o podwyższonym poziomie trudności lub ryzyka przedsięwzięcia usprawiedliwianych specjalistycznym charakterem zamówienia skierowanym do grupy podmiotów profesjonalnych i technologicznie przygotowanych do realizacji zakresu zamówienia. Stanowisko zamawiającego wobec poszczególnych żądań Ad 2a) Opisanie i udostępnienie narzędzi informatycznych do integracji planowanego systemu MTT PEKA z istniejącym systemem PEKA Zamawiający nie miał i nie ma prawnego ani technicznego obowiązku udostępniania wykonawcom szczegółowych narzędzi informatycznych ani kodów źródłowych, ani interfejsów integracyjnych, które pozostają w posiadaniu odrębnych wykonawców (np. Eviden Polska S.A.). Dokumentacja postępowania określa wymaganą funkcjonalność, a wykonawcy mają swobodę wyboru rozwiązań integracyjnych. Zgodnie z przepisami ustawy, Zamawiający nie może faworyzować konkretnego rozwiązania lub wykonawcy. Zamawiający zapewnił natomiast w SWZ i OPZ wszelkie niezbędne informacje do zaplanowania i zrealizowania integracji – m.in. przez: −opis wymaganego efektu integracji, −wskazanie punktów styku systemów, −dopuszczenie alternatywnych rozwiązań technicznych (np. dostarczenie własnych urządzeń zamiast integracji z istniejącymi), −określenie obowiązków po stronie wybranego wykonawcy wyłącznie na etapie realizacji umowy, a nie na etapie przygotowywania oferty. Brak bezpośredniego udostępnienia narzędzi nie uniemożliwia złożenia oferty ani realizacji zamówienia – o ile wykonawca rzeczywiście dysponuje potencjałem, by wykonać tego typu projekt. Nadto, zamawiający podkreślił, że w odniesieniu do sformułowania: „opisanie i udostępnienie narzędzi informatycznych do integracji planowanego systemu MTT PEKA z istniejącym systemem PEKA”, zauważył, że jego konstrukcja jest nieprecyzyjna i może prowadzić do błędnych interpretacji zakresu oraz charakteru oczekiwanych działań. Po pierwsze, nie zostało jednoznacznie określone, jakie konkretnie narzędzia informatyczne mają zostać opisane i udostępnione – czy chodzi o dokumentację API, gotowe komponenty integracyjne, czy też pełne środowisko programistyczne. Brakuje również doprecyzowania, czy „udostępnienie” oznacza jedynie opis koncepcyjny, czy przekazanie działających narzędzi wraz z prawami dostępu i wdrożeniem. W tej postaci zarzut jest wadliwy i należałoby go traktować jako pusty, a nawet „niepostawiony”. W związku z powyższym, uzasadnione jest stwierdzenie, że zarzut w obecnej formie nie pozwala na jednoznaczne odniesienie się do jego treści, a tym samym może utrudniać rzetelną ocenę sytuacji z punktu widzenia rozpoznania właściwych żądań odwołującego. W ocenie zamawiającego interfejs nowego rozwiązania pomiędzy systemami PEKA i MTT zostanie wytworzony dopiero na etapie realizacji umowy przez wybranego wykonawcę, po uzyskaniu informacji od wybranego wykonawcy na etapie realizacji umowy. Odwołujący w treści uzasadnienia w punkcie przywołującym zapisy OPZ dotyczące nośnikówi identyfikatorów w systemie PEKA i MTT w pkt. 5.1 OPZ, usiłuje zasugerować jakoby istniał zbiór narzędzi informatycznych, w których posiadaniu jest zamawiający. Zamawiający uznaje ten zarzut za wadliwie sformułowany, gdyż de facto nie istnieje legalna definicja narzędzia informatycznego, dzięki której można byłoby rozpoznać intencję odwołującego w kwestionowaniu akurat tego zapisu. Brak precyzji w sformułowaniu tego zarzutu uniemożliwia jego weryfikacje i uwzględnienie z przyczyn leżących po stronie samego odwołującego. Dotychczasowe doświadczenie w tego typu integracjach z wykorzystaniem karty PEKA jako nośnika w systemach innych operatorów (w tym również w systemie biletomatów stacjonarnych, których operatorem jest odwołujący na podstawie odrębnej umowy zawartej między ZTM a Mennicą) wykazuje, że wystarczająca jest dokumentacja apletu karty PEKA, którą zamawiający przekaże po podpisaniu stosownych umów z wybranym wykonawcą. Dodatkowo do prawidłowej komunikacji z kartą PEKA konieczne jest dostarczenie modułów SAM, co zamawiający uwzględnił w OPZ, a odwołujący nie kwestionuje. Zamawiający wnosi o uznanie żądania za bezzasadne. Ad 2b) Określenie zasad współpracy z Eviden i R&G Plus, w tym ustanowienie zamawiającego gwarantem współpracy, bez kosztów po stronie wykonawcy Zamawiający nie ma kompetencji prawnych, aby zagwarantować wykonawcom współpracę z innym niezależnym podmiotem gospodarczym, co znaczy, że zamawiający nie może być gwarantem współpracy pomiędzy wyłonionym wykonawcą a firmą Eviden Polska S.A. lub R&G Plus Sp. z o.o. Zamówienie nie ma charakteru tzw. "zamówienia powiązanego". Zamawiający nie może narzucać innemu wykonawcy (np. Eviden) obowiązku świadczenia usług na rzecz przyszłego wykonawcy systemu MTT PEKA, ani brać za niego odpowiedzialności. Żądanie odwołującego, aby zamawiający przejął rolę gwaranta współpracy wykonawcy z Eviden Polska S.A., a tym samym wyeliminował koszty tej współpracy po stronie wykonawcy jest bezpodstawne i niezgodne z podstawowymi zasadami prawa zamówień publicznych, w szczególności z zasadą równego traktowania wykonawców oraz zakazem zawierania umów nienazwanych w trybie zamówień publicznych. Zgodnie z art. 431 ustawy obowiązek współdziałania przy realizacji zamówienia publicznego dotyczy wyłącznie stron umowy, tj. zamawiającego i wybranego wykonawcy. Nie obejmuje on podmiotów trzecich. Wprowadzenie postulowanej przez odwołującego regulacji, w której zamawiający staje się gwarantem relacji pomiędzy wykonawcą a innym podmiotem gospodarczym (Eviden), byłoby niezgodne z systematyką ustawy i praktyką orzeczniczą KIO. Zamawiający nie jest i nie może być stroną ewentualnych stosunków cywilnoprawnych pomiędzy wykonawcą a podmiotem trzecim. Zamawiający stworzył warunki niedyskryminujące – dopuszczając m.in.: − zastosowanie innych urządzeń niż obecnie wykorzystywane (np. własne terminale zamiast SRG5000P, SRG7000P), − realizację integracji przez dostarczone przez wykonawcę protokoły i dokumentację, − współpracę między zamawiającym a wykonawcą oraz podmiotem trzecim – ale wyłącznie na etapie realizacji, co jest zgodne z art. 431 ustawy. Zasady współpracy z wykonawcą Systemu PEKA zostały określone przez zamawiającego w rozdziale 16 OPZ. Żądanie odwołującego zmierza w istocie do ograniczenia ryzyk biznesowych po stronie wykonawcy i przeniesienia ich na zamawiającego, co pozostaje w sprzeczności z zasadami prawa zamówień publicznych. Rolą zamawiającego jest zapewnienie otwartego i konkurencyjnego postępowania, a nie gwarantowanie określonych warunków biznesowych w relacjach między wykonawcami a podmiotami trzecimi. Przejęcie przez zamawiającego obowiązku gwarantowania współpracy i pokrywania kosztów, w sytuacji, gdy są one nierozerwalnie związane z działalnością gospodarczą wykonawcy, stanowiłoby w istocie finansowanie części realizacji zamówienia z pominięciem mechanizmu konkurencyjnego. Zamawiający wniósł o uznanie żądania za bezzasadne. Ad 2c) Określenie listy urządzeń (modemy, routery) do realizacji systemu łączności Zamawiający świadomie nie określił konkretnego, zamkniętego katalogu urządzeń, ponieważ nie ogranicza wykonawców do jednego konkretnego rozwiązania sprzętowego. Wskazano, że należy wykorzystywać istniejącą infrastrukturę albo zaproponować własną – pod warunkiem zapewnienia pełnej funkcjonalności i zgodności systemowej. Zamawiający świadomie dopuścił dowolność w zakresie doboru sprzętu, ograniczając się jedynie do wskazania wymagań funkcjonalnych. Narzucanie konkretnej listy urządzeń ograniczałoby konkurencję i mogłoby naruszyć neutralność technologiczną, o której mowa w naczelnych zasadach ustawy. Takie podejście służy zachowaniu konkurencyjności i otwiera postępowanie na różne rozwiązania techniczne. Niemniej jednak, zamawiający oczywiście dysponuje listą urządzeń pokładowych w pojazdach komunikacji miejskiej, którą to rzecz jasna, udostępni wykonawcy na etapie realizacji umowy po podpisaniu stosownej umowy o zachowaniu poufności, tym samym przedstawiając aktualny stan urządzeń wg ich stanu na dzień wdrażania systemu. W odpowiedzi na żądanie odwołującego, aby zamawiający udostępnił listę konkretnych urządzeń sieciowych wykorzystywanych w istniejącym środowisku (np. modemy, routery) stanowczo podkreślił, że takie działanie mogłoby prowadzić do ujawnienia informacji wrażliwych z punktu widzenia bezpieczeństwa teleinformatycznego systemu PEKA oraz infrastruktury IT zamawiającego. Lista urządzeń i ich konfiguracja techniczna, a w szczególności wykorzystywany sprzęt transmisji danych, adresacja sieciowa, protokoły komunikacyjne czy model topologii sieci – to elementy, które w myśl powszechnie przyjętych standardów polityk bezpieczeństwa informacji (m.in. według normy ISO/IEC 27001, Narodowego Standardu Cyberbezpieczeństwa NSC 200 wer. 2.1 oraz innych krajowych zaleceń NASK i ABW) nie powinny być publicznie udostępniane, zwłaszcza na etapie ogłaszania postępowania przetargowego. Udostępnienie tych danych mogłoby narazić zamawiającego na: −zagrożenia o charakterze cybernetycznym, w tym próby przejęcia lub zakłócenia działania infrastruktury telekomunikacyjnej wykorzystywanej do obsługi systemów transportowych i rozliczeniowych, −osłabienie zabezpieczeń systemów, zwłaszcza jeżeli nieautoryzowane podmioty uzyskałyby dostęp do konfiguracji urządzeń infrastruktury sieciowej, −naruszenie zasad ochrony informacji niejawnych lub prawnie chronionych, jeżeli dane te zostaną uznane za dane wrażliwe z perspektywy ciągłości działania usług publicznych (transportu, płatności). Z tych względów zamawiający ograniczył się do przedstawienia wymagań funkcjonalnych i interoperacyjnych systemu, bez udostępniania szczegółowych danych sprzętowych. Takie podejście jest zgodne z art. 99 ust. 4 ustawy, który nakazuje zamawiającemu określenie przedmiotu zamówienia w sposób zarówno proporcjonalny i umożliwiający dostęp do zamówienia szerokiemu gronu wykonawców – bez narażania bezpieczeństwa publicznego lub infrastrukturalnego, jak i w sposób neutralny technologicznie. Zamawiający wniósł o uznanie żądania za bezzasadne. Ad 2d) Wyłączenie odpowiedzialności za urządzenia, na które wykonawca nie ma wpływu Postulat odwołującego prowadzi do zniesienia odpowiedzialności wykonawcy za integralną część systemu, nad którą ma on kontrolę w momencie projektowania i wdrażania rozwiązania. Zamawiający nie nakłada obowiązku odpowiedzialności za cudzy sprzęt – wykonawca może dostarczyć własne urządzenia, zgodnie z opisem przedmiotu zamówienia. Brak takiej decyzji leży wyłącznie po stronie wykonawcy. Wykonawca ma pełną kontrolę nad wyborem rozwiązania – jeśli decyduje się na korzystanie z urządzeń istniejących, to czyni to na własne ryzyko. Nie zachodzi więc konieczność wyłączenia jego odpowiedzialności. Tym samym żądanie wyłączenia odpowiedzialności za świadomie wybrane przez wykonawcę rozwiązania jest bezzasadne. W ocenie zamawiającego wprowadzenie do umowy „wyłączenia odpowiedzialności wykonawcy za prawidłowość i ciągłość działania systemu w sytuacji, w której jest on zobowiązany do używania urządzeń, na których działanie nie ma wpływu” rodziłoby nieproporcjonalne komplikacje w praktycznym funkcjonowaniu systemu. Takie jednoznaczne wyłączenie odpowiedzialności rygorystycznie prowadzić może do sytuacji, że w przypadku wystąpienia awarii lub nieprawidłowości działania urządzeń dostarczonych przez wykonawcę, zamawiający każdorazowo będzie zmuszony prowadzić szczegółowe dochodzenie w celu ustalenia, czy dana część systemu faktycznie działała zgodnie z oczekiwaniami i po której stronie doszło do ewentualnego zaniedbania czy błędów w działaniu. W praktyce może to znacznie opóźniać procesy naprawcze i skutkować nieefektywnością w zarządzaniu systemem w całości, ze względu na przerzucenie całego ciężaru diagnostyki technicznej na zamawiającego Podkreślił, że wspomniane urządzenia odpowiadają za transmisję danych w pojeździe, która ma wpływ nie tylko na funkcjonalności wdrażane w ramach tego postępowania, ale również na pozostałe elementy systemu PEKA. W sytuacji, gdy transmisja przestanie działać, naturalne będzie podejmowanie działań mających na celu możliwie szybkie usunięcie problemu — niezależnie od podziału odpowiedzialności. Zaznaczył, że nie jest zamiarem zamawiającego obciążanie wykonawcy za każdą usterkę wykraczającą poza jego kontrolę. Wykonawca odpowiada w pełnym zakresie za działanie systemu, a odpowiedzialność mogłaby zostać ograniczona lub wyłączona w takim wypadku, jeżeli wykaże, że nienależyte działanie systemu nie wynika z przyczyn lub winy po jego stronie. Zamawiający wniósł o uznanie żądania za bezzasadne. Ad 2e) Określenie danych sprzedażowych do kalkulacji prowizji Agenta Rozliczeniowego Zamawiający wskazał, że system MTT PEKA stanowi nowy kanał dystrybucji, wobec czego nie istnieją wiarygodne dane historyczne, które mogłyby być podstawą kalkulacji kosztów prowizji. Ponadto, struktura wynagrodzenia została określona jako ryczałtowa, a wykonawca zobowiązany jest do samodzielnej oceny ryzyk ekonomicznych. Żądanie odwołującego w tym zakresie jest bezzasadne i niemożliwe do zrealizowania. Dane historyczne sprzedażowe nie mają charakteru danych publicznych w rozumieniu ustawy – a ich brak nie uniemożliwia oszacowania oferty, ponieważ system MTT PEKA to nowy kanał sprzedaży, dla którego dane historyczne nie istnieją, a wykonawca powinien zakładać model oparty na szacunkach rynkowych i analizie ryzyka z uwagi na to, że koszt prowizji agenta leży po jego stronie i stanowi element jego polityki handlowej. Zamawiający wniósł o uznanie żądania za bezzasadne. Niemniej jednak, wychodząc naprzeciw oczekiwaniom odwołującego oraz innych zainteresowanych uczestników postępowania, zamawiający w odpowiedzi na pytania do postępowania, zamieścił dane sprzedażowe za lata 2020-2024 w podziale na kanale sprzedaży, celem umożliwienia dostępu do materiałów pomocniczych do oszacowania kosztów obsługi operatora płatności. Ad 2f) Udostępnienie dokumentacji wykonawców systemu PEKA - Eviden / R&G Plus Zamawiający nie jest właścicielem ani dysponentem wszystkich elementów dokumentacji podmiotów trzecich i nie ma prawnej możliwości jej udostępnienia, o ile te podmioty nie wyrażą zgody lub nie zostały one wytworzone na potrzeby niniejszego zamówienia. Co istotne – wykonawca nie musi z niej korzystać, jeśli wdroży własne rozwiązania. Żądanie to jest nieproporcjonalne i nieuzasadnione. Ponadto: − dokumentacja nie jest integralną częścią opisu przedmiotu zamówienia, − wykonawca może zrealizować integrację niezależnie od szczegółowych danych podmiotów trzecich, − zamawiający dopuścił stosowanie własnych rozwiązań, co czyni ten zarzut bezzasadnym. Wnoszone żądanie dotyczące pełnego udostępnienia dokumentacji wytworzonej w ramach współpracy z dotychczasowymi wykonawcami systemu PEKA znacząco wykracza poza zakres przedmiotowego zamówienia. Zamawiający stanowczo podkreśla, że nawet przekazanie całego obecnie posiadanego zasobu dokumentacji nie zagwarantowałoby spełnienia oczekiwań wykonawcy, ze względu na konieczność realizacji dodatkowych prac integracyjnych po stronie ZTM, które będą miały miejsce dopiero po wyłonieniu wykonawcy. W szczególności zaznaczył, że dla zapewnienia właściwej współpracy systemu PEKAz nowoprojektowanymi komponentami, niezbędne będzie zlecenie przez ZTM Poznań firmie Eviden Polska S.A dedykowanych prac programistycznych, takich jak dostosowanie lub opracowanie interfejsów API. W efekcie samo przekazanie istniejącej dokumentacji nie rozwiązuje kwestii technicznych integracji — może wręcz prowadzić do błędnego założenia, że takiego dodatkowego wysiłku nie będzie trzeba podejmować. Ponadto, dokumentacja zawiera rozwiązania technologiczne oraz know-how chronione tajemnicą przedsiębiorstw, których ujawnienie przed podpisaniem stosownej umowy mogłoby naruszyć interesy komercyjne aktualnych wykonawców systemu PEKA. Zarówno Eviden Polska S.A., jak i R&G Plus Sp. z o.o. nie wyrazili zgody na udostępnianie pełnej dokumentacji na etapie postępowania, co wiąże się także z koniecznością poszanowania przepisów dotyczących cyberbezpieczeństwa i ochrony informacji poufnych. W związku z powyższym, przekazanie niezbędnej dokumentacji będzie możliwe wyłącznie po zawarciu umowy z wybranym wykonawcą, przy jednoczesnym doprecyzowaniu zakresu potrzebnych materiałów oraz uzgodnieniu zasad ich wykorzystania. Zamawiający wniósł o uznanie żądania za bezzasadne. Ad 2g) Wyłączenie odpowiedzialności wykonawcy za brak współpracy ze spółką Eviden Zamawiający jednoznacznie uregulował w dokumentacji, że odpowiedzialność wykonawcy dotyczy dostarczonego efektu końcowego – tj. funkcjonującego systemu zintegrowanego z PEKA. Wybór sposobu dojścia do tego rezultatu należy do wykonawcy. Wykonawca może dobrać sprzęt i zaprojektować integrację dowolnie, pod warunkiem zapewnienia wymaganej funkcjonalności. Nie można wyłączyć odpowiedzialności wykonawcy za jego własny wybór – tj. współpracę z firmą zewnętrzną zamiast zaprojektowania własnego rozwiązania. Zamawiający nie może w sposób arbitralny przejąć odpowiedzialności za jeden rodzaju ryzyka technicznego na siebie, pozostawiając inne ryzyka po stronie wykonawców, ponieważ naruszałoby to zasadę proporcjonalności i konkurencyjności. Zamawiający nie wymaga integracji z konkretnej listy podmiotów – dopuścił alternatywne technologie, rozwiązania i urządzenia. Tym samym żądanie wyłączenia odpowiedzialności za dobrowolnie wybrane rozwiązanie jest sprzeczne z konstrukcją kontraktową i ryzykiem kontraktowym wykonawcy. Jak już wskazano wyżej, wykonawca odpowiada w pełnym zakresie za działanie systemu, a odpowiedzialność mogłaby zostać ograniczona lub wyłączona w takim wypadku, jeżeli wykaże, że nienależyte działanie systemu nie wynika z przyczyn lub winy po jego stronie. Zamawiający wniósł o uznanie żądania za bezzasadne.IV. Wnioski końcowe Zamawiający zaprzeczył wszystkim zarzutom i twierdzeniom odwołania odwołującego, których wyraźnie nie przyznał. Zamawiający wniósł o oddalenie odwołania w całości jako bezzasadnego, opartego na założeniu konieczności narzucania przez zamawiającego rozwiązań technicznych, które w rzeczywistości pozostają po stronie wykonawcy. Dokumentacja przetargowa została przygotowana z poszanowaniem zasad uczciwej konkurencji, równego traktowania wykonawców oraz proporcjonalności. Konstrukcja dokumentacji przetargowej zachowuje transparentność i otwartość na różne rozwiązania. Zamawiający umożliwia zastosowanie różnych rozwiązań technicznych i modeli biznesowych, co potwierdza otwartość i neutralność technologiczną postępowania. Odwołujący nie wykazał, aby postanowienia SW Z uniemożliwiały mu złożenie oferty – przeciwnie, żądania te mają charakter instrumentalny i zmierzają do eliminacji konkurencji poprzez sztuczne rozszerzanie obowiązków zamawiającego w miejsce zadań, za które odpowiedzialność winien wziąć wykonawca pod kątem technicznym i biznesowym. 16 września 2025 r. zamawiający złożył dodatkowe pisemne stanowisko dotyczące argumentacji kwestii zapewnienia integracji Systemu MTT PEKA z istniejącymi komponentami obecnie użytkowanego Systemu PEKA – Terminali Kierowców 1. Przyjęte w OPZ założenia Zamawiający opisując w OPZ oczekiwane funkcjonalności nowego rozwiązania, jako punkt odniesienia przyjął konstrukcję obecnie użytkowanego Systemu PEKA, z którym zintegrowane zostaną nowe funkcjonalności będące przedmiotem projektu (Systemu MTT PEKA). Przewidziano różne warianty realizacji przedmiotu zamówienia, np.: •bezpośrednie porozumienie się z obecnym gwarantem systemu PEKA – firmą Eviden Polska S.A. •zastosowanie innych, alternatywnych rozwiązań, które powinny zostać opracowane i zaproponowane przez wykonawcę Systemu MTT PEKA. 2. Przywołane zapisy OPZ dotyczące integracji nowego rozwiązania z autokomputerami w pojazdach W pkt. 3.3 ust. 1 pkt 3) zapisano m.in., cyt.: „Dopuszczalne jest rozwiązanie bez kasownika Master, jeśli będzie możliwa bezpośrednia współpraca każdego z kasowników z Terminalem Kierowcy. (…) Zamawiający wyklucza możliwość zastosowania dodatkowego autokomputera, na którym koniecznym byłoby kolejne logowanie się prowadzącego pojazd.” W pkt. 7.1. OPZ zapisano, cyt.: „Dopuszczalne jest zastosowanie innych rozwiązań umożliwiających połączenie Kasowników Systemu MTT PEKA z urządzeniami w pojeździe oraz Systemem Centralnym PEKA i innych podsystemów PEKA, z zastrzeżeniem, że kierowca nie może być zobligowany do podwójnego logowania się do systemów. Terminal Kierowcy wraz ze swoim oprogramowaniem powiązany jest zarówno z Systemem PEKA, jak również z Systemem ITS Miasta Poznań (priorytetyzacja przejazdów oraz automatyczne sterowanie zwrotnicami). W przypadku, gdy Wykonawca uzna, że w miejsce integracji z obecnie użytkowanymi urządzeniami (Terminal Kierowcy), dostarczy i skonfiguruje własne, zobowiązany będzie do zachowania pełnej, działającej dotychczas funkcjonalności tych urządzeń dla Systemu PEKA i Systemu ITS. Wymagane jest także w tym przypadku dostarczenie Zamawiającemu w pełni udokumentowanych protokołów komunikacji między tymi urządzeniami, umożliwiających dokonywanie przez Zamawiającego dalszych integracji.” Zamawiający wyjaśnił, że w świetle powyższych zapisów wykonawca może dostarczyć swoje rozwiązania i nie jest wymagane dokonanie bezpośredniej (fizycznej) integracji z autokomputerem w pojeździe. Co więcej, istnieje możliwość dokonania integracji bazującej na innych komponentach udostępnianych przez zamawiającego, tj. m.in.: •otwartych danych Miasta Poznania – danych GTFS i GTFS-RT oraz •API udostępnionego przez zamawiającego. Przykładem może być obecnie użytkowany System OPS w Poznaniu. 3. Projektując nowe rozwiązania Systemu MTT PEKA możliwe jest powzięcie założeń: •System MTT PEKA powinien działać w trybie kontocentrycznym i zostać zintegrowany z nowymi Kasownikami w pojeździe (z Kasownikiem Master lub innym sterownikami Kasowników w pojeździe) oraz Systemem Centralnym PEKA. •Komunikacja nowych Kasowników może być dokonana w sposób niezależny od autokomputera w pojeździe (nie jest wymagana fizyczna integracja Kasowników z autokomputerem). •System Centralny PEKA jest zintegrowany z Systemem ITS w autokomputerze pojazdu. Ta istniejąca obecnie funkcjonalność pozostanie zachowana nawet, gdy nowe Kasowniki nie będą fizycznie zintegrowane z Kasownikami. •Zapewnienie wymaganych OPZ funkcjonalności, w tym wymóg braku zastosowania dodatkowego autokomputera, w którym koniecznym byłoby kolejne logowanie się prowadzącego pojazd, może być spełniony przez zaprojektowanie odpowiedniej metody komunikacji nowego Kasownika z Systemem MTT PEKA. •Zapewnienie wymaganych w OPZ funkcjonalności może być zrealizowane przez integrację z Systemem Centralnym PEKA, który jest zintegrowany z autokomputerem (np. kontrola biletów). 4. Przykładowo część procesu realizowanego w nowym systemie może wyglądać następująco: Kasownik systemu MTT PEKA połączony z Kasownikiem typu Master lub innym sterownikiem Kasowników w pojeździe, może rejestrować i przekazywać do systemu operacje dotyczące podróży Pasażera: check-in i check-out, czas, położenie GPS, informacje o numerze pojazdu (każdy Kasownik jest przypisany do danego pojazdu). System MTT PEKA w trybie kontocentrycznym odbiera informacje z GTFS-RT i GTFS (lub innych z innych dostępnych interfejsów zamawiającego) i dokonuje obliczenia podróży oraz jej weryfikacji. Obliczona wartość opłaty jest przekazywana do systemu PEKA w celu dokonania rozliczenia ze środków tPortmonetki lub rozliczona w trybie MTT PEKA. 5. Uwarunkowania sprzętowe projektowanego rozwiązania Wykonawca projektując nowy system może bazować na swoich rozwiązaniach sprzętowych, zapewniających komunikację kontrocentrycznych systemów MTT PEKA i Systemu Centralnego PEKA (z zastrzeżeniem zachowania wymagania podłączenia nowych urządzeń na istniejącym okablowaniu w pojazdach). Zamawiający nie dostrzega więc konieczności informowania potencjalnego wykonawcy o wykorzystywanych obecnie w pojazdach rozwiązaniach sprzętowych – rolą wykonawcy jest przedstawienie swojej propozycji systemowo-sprzętowej projektu systemu. Stan faktyczny: Załącznik nr 1 do Specyfikacji Warunków Zamówienia Opis Przedmiotu Zamówienia 1.WSTĘP Poniższy dokument stanowi Opis Przedmiotu Zamówienia dla wyłonienia Wykonawcy zadania pn. Rozbudowa i unowocześnienie systemu PEKA poprzez uruchomienie systemu płatności zbliżeniowych w kasownikach wraz z dostawą infrastruktury podsystemu transportowego i integracją z systemem PEKA. System PEKA, ciągle rozbudowywany, dostarcza swoim użytkownikom wiele nowoczesnych usług dla pasażerów, poprzez elektroniczne indywidualne konto użytkownika. Nowe usługi elektroniczne (e-usługi) będą koncentrowały się na wdrożeniu obsługi: •Biletu elektronicznego MTT/PaYG, rozumianego jako usługa zbliżeniowej płatności elektronicznej w modelu MTT/PaYG za przejazd transportem publicznym na terenie Aglomeracji poznańskiej, tzw. „Bilet elektroniczny MTT”, dokonywanej kartą płatniczą EMV lub jej surogatem. •Sprawdzenia aktywnego biletu elektronicznego rozumianego jako usługa sprawdzenia aktywności biletu elektronicznego PEKA i/lub biletu MTT opłaconego środkiem płatniczym EMV lub jego surogatem. •Spłaty należności za bilet elektroniczny MTT/PaYG, rozumianej jako usługa dokonania płatności elektronicznej w modelu MTT/PaYG za nieuregulowaną należność z tytułu braku środków po zakupie biletu MTT. •Historii biletów elektronicznych MTT/PaYG, rozumianej jako udostępnienie informacji o historii zakupionych biletów elektronicznych MTT na przejazdy transportem zbiorowym na obszarze Aglomeracji poznańskiej realizowany w środkach transportu zbiorowego eksploatowanymi na obszarze Aglomeracji. Realizacja projektu rozbudowy i unowocześnienia systemu PEKA w opisywanym dalej kształcie zakłada uproszczenie, a tym samym zwiększenie szybkości obsługi pasażera tak, aby poruszanie się komunikacją miejską było bardziej intuicyjne i dostępne. Unowocześnione standardy i metody płatności w systemie PEKA skrócą czas załatwiania spraw z urzędami publicznymi (ZTM Poznań), odgrywając istotną rolę w dalszym upowszechnieniu płatności bezgotówkowych, realizowanych w niezwykle prosty sposób, w tym również za pomocą telefonów i innych urządzeń obsługujących tego rodzaju płatności. Dzięki powszechnej dla mieszkańców aglomeracji dostępności, system PEKA będzie pomostem integrującym transport publiczny na obszarze aglomeracji, z uwzględnieniem różnych rodzajów transportu publicznego i możliwości zakupu biletów. Aplikacja PEKAAplikacja mobilna dostarczona w ramach realizacji Systemu PEKA, umożliwiająca Pasażerom m.in. nabywanie Biletów i zarządzanie Kontem Pasażera. Aplikacja PEKA umożliwia identyfikację Pasażera w ramach Rozwiązań niezbędnych do celów rozliczeniowych oraz realizuje szereg innych funkcjonalności dostępnych w Systemie PEKA. Projekt PEKAProjekt obejmujący swym rzeczowym zakresem rozbudowę systemu PEKA poprzez uruchomienie systemu płatności zbliżeniowych MTT w kasownikach wraz z dostawą infrastruktury podsystemu transportowego oraz integracją z systemem PEKA. Portal Pasażera / Portal PEKA / SOP (System Obsługi Pasażera)Interfejs transakcyjny Systemu PEKA, dostępny dla Pasażerów pod adresem www.peka.poznan.pl, służący do: a)zarządzania swoimi danymi, b)zakupu biletów okresowych, c)doładowania tPortmonetki, d)dostępu do wykonanych transakcji, e)dostępu do historii użycia tPortmonetki, f)dostępu do wydruku lub eksportu faktur, g)składania wniosków i reklamacji. SOP i System Centralny PEKA jest zintegrowany poprzez dedykowane interfejsy z agentem/agentami płatności internetowych umożliwiającymi przeprowadzenie transakcji zakupu biletów za pomocą Internetu. APIŚciśle określony zestaw reguł i ich opisów, w jaki sposób programy komputerowe komunikują się między sobą. Aplikacja PEKAAplikacja mobilna dostarczona w ramach realizacji Systemu PEKA, umożliwiająca Pasażerom m.in. nabywanie Biletów i zarządzanie Kontem Pasażera. Aplikacja PEKA umożliwia identyfikację Pasażera w ramach Rozwiązań niezbędnych do celów rozliczeniowych oraz realizuje szereg innych funkcjonalności dostępnych w Systemie PEKA. AutokomputerPatrz: Terminal kierowcy/Sterownik kasowników KasownikKomponent Podsystemu transportowego montowany w pojazdach Komunikacji Miejskiej lub w innych wskazanych miejscach, umożliwiające Pasażerom aktywację Biletów oraz wnoszenie opłat za przejazd przy wykorzystaniu Nośników. Urządzenie posiada funkcjonalności: czytnika NFC, czytnika kodów QR oraz dotykowy ekran i służy do wykonywania operacji Check-in/Check-out w modelu MTT/PAYG i do obsługi tPortmonetki. System Centralny PEKASprzęt i oprogramowanie obejmujące centralną bazę danych Systemu, moduł zarządzania cyklem życia kart, tożsamością cyfrową Użytkowników, ich identyfikacją, uwierzytelnianiem i autoryzacją, moduły i aplikacje, a w szczególności: administracji i konfiguracji, edycji taryf, urządzeń, zarządzania pracownikami, obsługą klienta MOPR, faktur i rozliczeń, moduł integracji systemów zewnętrznych oraz podsystemu transportowego, centrum personalizacji kart wraz z Systemem Obsługi Pasażera (SOP), poprzez który dostępne są usługi klienckie Systemu. System Centralny przechowuje wszystkie informacje o klientach i usługach funkcjonujących w systemie PEKA oraz udostępnia interfejsy dostępu do tych informacji dla pozostałych komponentów i użytkowników Systemu. Terminal Kierowcy /Sterownik kasownikówUrządzenia zainstalowane w pojazdach komunikacji miejskiej lub innych wskazanych miejscach, sterujące pracą urządzeń pokładowych zainstalowanych w Pojazdach, zapewniające łączność z systemem centralnym PEKA, systemem ITS oraz pozostałymi systemami obsługującymi pracę kierowcy. Urządzenie posiada terminal pozwalający kierowcy na logowanie się systemu. 3.3.PRZEDMIOT ZAMÓWIENIA 1.Przedmiotem niniejszego zamówienia jest: 1)Dostawa, uruchomienie i utrzymanie Systemu MTT PEKA wraz z serwisem gwarancyjnym w okresie wdrożenia, gwarancji oraz trwałości projektu, jako nowego modułu Systemu PEKA. 2)Zapewnienie licencji na korzystanie z oprogramowania MTT/PaYG w całym okresie trwałości projektu. 3)Dostawa fabrycznie nowych Kasowników uniwersalnych z obsługą EMV i kodów 2D w Systemie MTT, typu „Master/Slave” w ogólnej liczbie 4780 szt. wraz z oprogramowaniem i utrzymaniem oraz integracją kasowników Master lub każdego z kasowników z terminalami kierowców oraz zapewnienie wszelkich innych urządzeń niezbędnych do prawidłowego funkcjonowania systemu, a niewymienionych w OPZ. Dopuszczalne jest rozwiązanie bez kasownika Master, jeśli będzie możliwa bezpośrednia współpraca każdego z kasowników z Terminalem Kierowcy. W ramach ogólnej liczy kasowników, 3 zestawy należy przekazać Zamawiającemu jako urządzenia testowo- prezentacyjne. Zamawiający wyklucza możliwość zastosowania dodatkowego autokomputera, na którym koniecznym byłoby kolejne logowanie się prowadzącego pojazd. 5)Integracja nowych funkcjonalności z obecnie użytkowanym systemem PEKA, w tym eksport danych transakcyjnych MTT oraz wymiana niezbędnych danych do obsługi ulg i uprawnień pasażerów zapisanych w systemie. 8)Integracja Kasownika Master (lub każdego z kasowników – w zależności od zastosowanego rozwiązania) z Terminalem Kierowcy, co najmniej obejmująca pobieranie informacji o: a)lokalizacji pojazdu, b)numerze pojazdu, c)numerze linii pojazdu, d)otwartych/zamkniętych drzwiach pojazdu, e)rozkładzie jazdy, f)strefie, g)kierunku trasy, h)taryfie, i)listach kontrolnych (białych, czarnych, itp.), j)doładowaniach tPortmonetki. 6.Zamawiający zobowiązany będzie do dostarczenia rozwiązania działającego w wydzielonej sieci APN/VPN, tożsamej z obsługującą System PEKA, do łączności pomiędzy oprogramowaniem centralnym a urządzeniami (w pojazdach), budując ją w oparciu o dostarczone przez Zamawiającego karty. 5.1.WYMAGANIA OGÓLNE System MTT PEKA będący nowym modułem Systemu PEKA, połączonym z Systemem Centralnym PEKA i powinien zapewnić realizację niżej zdefiniowanych wymagań 7.1.TERMINAL KIEROWCY/STEROWNIK KASOWNIKÓW Obecnie Zamawiający użytkuje Terminale Kierowcy typu SRG5000P oraz SRG7000P firmy R&G Plus Sp. z o.o. z siedzibą w Mielcu, ul. Traugutta 7, 39-300 Mielec. W ramach realizacji zamówienia, Wykonawca zobowiązany będzie do integracji swoich urządzeń z komputerami pokładowymi w pojazdach wszystkich operatorów (w autobusach i tramwajach). W tym celu niezbędnym jest ustalenie przez Wykonawcę zasad współpracy bezpośrednio z gwarantem systemu PEKA – firmą Eviden Polska S.A. z siedzibą w Warszawie, ul. Pułaska 180, 00-180 Warszawa. Z tego tytułu Zamawiający nie będzie ponosił dodatkowych kosztów na rzecz Wykonawcy. Dopuszczalne jest zastosowanie innych rozwiązań umożliwiających połączenie Kasowników Systemu MTT PEKA z urządzeniami w pojeździe oraz Systemem Centralnym PEKA i innych podsystemów PEKA, z zastrzeżeniem, że kierowca nie może być zobligowany do podwójnego logowania się do systemów. Terminal Kierowcy wraz ze swoim oprogramowaniem powiązany jest zarówno z Systemem PEKA, jak również z Systemem ITS Miasta Poznań (priorytetyzacja przejazdów oraz automatyczne sterowanie zwrotnicami). W przypadku, gdy Wykonawca uzna, że w miejsce integracji z obecnie użytkowanymi urządzeniami (Terminal Kierowcy), dostarczy i skonfiguruje własne, zobowiązany będzie do zachowania pełnej, działającej dotychczas funkcjonalności tych urządzeń dla Systemu PEKA i Systemu ITS. Wymagane jest także w tym przypadku dostarczenie Zamawiającemu w pełni udokumentowanych protokołów komunikacji między tymi urządzeniami, umożliwiających dokonywanie przez Zamawiającego dalszych integracji. 7.3.ŁĄCZNOŚĆ W przypadku realizacji rozwiązania wykorzystującego kasownik typu Master dane niezbędne do poprawnej pracy kasowników powinny być pobierane z Terminala Kierowcy (m.in. linia, brygada, kurs) lub w inny sposób, który nie będzie angażował prowadzącego pojazd. Zadaniem Wykonawcy jest dostawa systemu łączności z urządzeniami za pomocą wydzielonej sieci APN/VPN, jak również łączności z systemami zewnętrznymi (system Agenta rozliczeniowego kart płatniczych, System centralny PEKA) za pomocą bezpiecznych łączy. Wykonawca zobowiązany jest wykorzystać do realizacji systemu łączności działające w pojazdach urządzenia, takie jak modemy, routery, anteny, po wcześniejszych uzgodnieniach poczynionych bezpośrednio z Wykonawcą Systemu PEKA. 16.WSPÓŁPRACA Z WYKONAWCĄ SYSTEMU PEKA Wykonawca Systemu MTT PEKA zobowiązany będzie do ścisłej współpracy z Wykonawcą/Gwarantem Systemu PEKA, co najmniej w zakresie: 1.wyposażenia pojazdów w urządzenia MTT PEKA i ich integrację z istniejącymi urządzeniami pokładowymi, 2.integracji Serwisu Internetowego MTT PEKA z Portalem Pasażera, 3.konfiguracji połączeń sieciowych pomiędzy systemami, 4.komunikacji Kasowników z Systemem MTT PEKA i Systemem PEKA, wraz z obsługą aktualnych procesów Systemu PEKA, 5.każdym innym, wymaganym do realizacji celów projektu Systemu MTT PEKA. Wykonawca Systemu MTT PEKA zobowiązany będzie do sprawnej, bezpiecznej i zgodnej z wymaganiami integracji systemów, współpracy z obecnym Wykonawcą Systemu PEKA. Współpraca ta winna obejmować co najmniej: 1.Wspólne ramy integracji •Wykonawcy muszą działać w oparciu o jeden wspólny model architektury integracji (np. ESB, REST API, komunikaty). •Wykonawcy muszą określić standardy wymiany danych oraz protokoły 2.Odpowiedzialność za interfejsy •Każdy wykonawca odpowiada za udostępnienie i dokumentację swoich API/interfejsów. •Wymagane są jasne zasady wersjonowania i kompatybilności wstecznej. •Strony muszą zapewnić środowisko testowe (sandbox) do symulacji integracji. 3.Uzgodniony harmonogram i kamienie milowe •Zdefiniowane etapy integracji i czytelny harmonogram działań (w tym testy integracyjne). •Wspólne przeglądy postępu prac (status meetings, milestone reviews). 4.Zasady współpracy zespołów technicznych •Ustalenie punktów kontaktowych po obu stronach. •Wspólna przestrzeń współpracy, tu: repozytorium kodu •Regularna wymiana informacji i szybkie reagowanie na błędy integracyjne. 5.Zarządzanie zmianą i konfliktem •Opracować procedurę wprowadzania zmian do interfejsów i danych (change management). •Opracować mechanizmy eskalacji i rozwiązywania sporów technicznych oraz organizacyjnych. 6.Bezpieczeństwo i zgodność •Opracować wspólne uzgodnienia dot. bezpieczeństwa transmisji danych (szyfrowanie, VPN). •Dbać o zgodność z RODO oraz politykami ochrony danych. •Zapewnić audytowalność – logowanie i monitorowanie wszystkich punktów integracji. 7.Testowanie i odbiory •Zaplanowanie wspólnych etapów testów: jednostkowe → integracyjne → akceptacyjne (UAT). •Jasno określić kryteria sukcesu integracji. •Wykonać wspólne testy obciążeniowe i odpornościowe, jeśli wymagane. 8.Wspólne zarządzanie ryzykiem •Zapewnić wspólną identyfikację i aktualizację ryzyk integracyjnych. •Opracować plan działań naprawczych w razie awarii lub opóźnień. 9.Zgodność z Zamawiającym •Obaj wykonawcy zobowiązani są do działania w interesie Zamawiającego. •Zamawiający może pełnić rolę koordynatora integracji lub wyznaczyć niezależnego integratora. 10.Wspólne szkolenia i dokumentacja końcowa •Opracować dokumentację powdrożeniową integracji. •Zapewnić szkolenia i instrukcje dla użytkowników oraz administratorów. Wyjaśnienia treści SWZ: Wyjaśnienia SWZ z 4 września 2025 r.: Pytanie nr 24: Załącznik nr 1 do SWZ - OPZ P. 3.3. pp.1 Prosimy o potwierdzenie, że Zamawiający dopuści rozwiązanie, w którym Wykonawca zamiast kasowników typu Master/Slave dostarczy Kasowniki typu Slave oraz Sterowniki Kasowników będące jednostkami centralnymi, do których są podłączone kasowniki (switch), jak również Autokomputer. W takim rozwiązaniu dane techniczne, o których mowa w pkt.8 str. 15 dystrybuowane z Autokomputera byłyby przetwarzane przez Sterownik kasowników i dalej dystrybuowane do poszczególnych kasowników. Sterownik kasowników również odgrywałby kluczową rolę w realizacji wymagań z pkt. 9 str. 16 tj. integracji systemu kasowników z Terminalami kontrolerskimi w celu zapewnienia systemowego blokowania i odblokowywania Kasowników. Sterownik Kasowników (jednostka centralna) nie będzie zainstalowany na pulpicie kierowcy. Zastosowanie Kasownika Master niesie za sobą ryzyko, że nie będzie można do niego doprowadzić dużej wiązki kabli. Odpowiedź na pytanie nr 24: Zamawiający wyjaśnia, że podany przez Wykonawcę opis rozumiany jest jako zbieżny z obsługą w układzie Master/Slave. Tym samym, rozwiązanie zostanie dopuszczone do realizacji, pod warunkiem zapewnienia realizacji wszystkich wymogów funkcjonalnych, wskazanych w OPZ. Pytanie nr 25: Załącznik nr 1 do SWZ - OPZ 17 P. 3.3. pp.1 7) Zamawiający wymaga przeprowadzenie integracji systemu płatności zbliżeniowych MTT (System MTT PEKA) z Systemem Centralnym PEKA. Prosimy o potwierdzenie, że Zamawiający udostępni Wykonawcy wszelkie niezbędne narzędzia informatyczne do przeprowadzenia integracji z Systemem Centralnym PEKA. Prosimy również o wskazanie jakie to będą narzędzia informatyczne w celu oszacowania kosztów oferty. Odpowiedź na pytanie nr 25: Zamawiający informuje, że wszelkie informacje dot. warunków integracji z systemem PEKA zostaną przekazane po podpisaniu umowy. Nie istnieją dedykowane narzędzia informatyczne do przeprowadzenia integracji z Systemem Centralnym PEKA. Jednocześnie Zamawiający informuje na podstawie dotychczasowych doświadczeń w tego typu integracjach z wykorzystaniem karty PEKA jako nośnika w systemach innych operatorów (np. w systemie biletomatów stacjonarnych), że wystarczająca jest dokumentacja apletu karty PEKA, którą Zamawiający przekaże po podpisaniu stosownych umów z wybranym Wykonawcą. Dodatkowo do prawidłowej komunikacji z kartą PEKA konieczne jest dostarczenie modułów SAM, co Zamawiający uwzględnił w OPZ. Pytanie nr 27: Załącznik nr 1 do SWZ - OPZ P. 3.3. pp.1 8) Zamawiający wymaga przeprowadzenia integracji Kasownika Master (lub każdego z kasowników – w zależności od zastosowanego rozwiązania) z Terminalem Kierowcy. Prosimy o potwierdzenie, że Zamawiający udostępni Wykonawcy wszelkie niezbędne narzędzia informatyczne do przeprowadzenia integracji urządzeń planowanego systemu biletowego z istniejącymi Terminalami Kierowcy. Prosimy również o wskazanie jakie to będą narzędzia informatyczne w celu oszacowania kosztów oferty. Odpowiedź na pytanie nr 27: Zamawiający wyjaśnia, że nie istnieją dedykowane narzędzia informatyczne do przeprowadzenia integracji urządzeń planowanego systemu biletowego z istniejącymi Terminalami Kierowcy. Wykonawca zobowiązany będzie do wykonania tej integracji własnymi środkami, siłami i wiedzą. Pytanie nr 28: Załącznik nr 1 do SWZ - OPZ P. 3.3. pp.1 9) Zamawiający wymaga przeprowadzenia integracji Kasownika Master (lub każdego z kasowników – w zależności od zastosowanego rozwiązania) z Terminalami Kontrolerskimi. Prosimy o potwierdzenie, że Zamawiający udostępni Wykonawcy wszelkie niezbędne narzędzia informatyczne do przeprowadzenia takiej integracji. Prosimy również o wskazanie jakie to będą narzędzia informatyczne w celu oszacowania kosztów oferty. Odpowiedź na pytanie nr 28: W systemie PEKA funkcjonuje dedykowany interfejs, który jest wykorzystywany w tym celu dla podobnych zadań w systemie PEKA. Po zawarciu stosownej umowy z Wykonawcą zostaną uszczegółowione warunki integracji, w zależności od zaproponowanego rozwiązania. Pytanie nr 34: Załącznik nr 1 do SWZ - OPZ P. 3.3. pp. 11 1) System będzie działał w oparciu o centralne repozytorium identyfikatorów nośników w systemie PEKA. Prosimy o potwierdzenie, że Zamawiający udostępni Wykonawcy wszelkie niezbędne narzędzia informatyczne do przeprowadzenia integracji z centralnym repozytorium identyfikatorów nośników. Przekazanie tej informacji w celu właściwego oszacowania kosztów i przyjęcia właściwych rozwiązań technologicznych w projekcie. Odpowiedź na pytanie nr 34: Zamawiający wykona wszelkie niezbędne prace programistyczne po stronie interfejsów systemu PEKA . Wymagania odnośnie integracji zostaną ustalone po podpisaniu umowy. Por. odp. na pyt. nr 25. Pytanie nr 39: Załącznik nr 1 do SWZ - OPZ P. 4 pp. 2 Podczas wdrożenia nowej funkcjonalności należy zapewnić ciągłość działania systemu MTT PEKA w przypadku braku połączenia (synchronizacji) z Systemem Centralnym PEKA, zachowując redundancję i dywersyfikację kanałów sprzedaży ZTM. Zważywszy na fakt, że zarówno System Centralny PEKA jak i System MTT PEKA będą działały w chmurze obliczeniowej Zamawiającego, prosimy o potwierdzenie, że odpowiedzialność Wykonawcy za ciągłość działania systemu obejmuje wyłącznie przypadki, za które Wykonawca odpowiada. Ponadto, mając na względzie wymaganie wskazane w p. 7.3 OPZ, że Wykonawca zobowiązany jest wykorzystać do realizacji systemu łączności działające w pojazdach urządzenia, takie jak modemy, routery, anteny itp., na których poprawne działanie Wykonawca nie ma żadnego wpływu, prosimy o potwierdzenie, że odpowiedzialność Wykonawcy za ciągłość działania systemu obejmuje wyłącznie przypadki, za które Wykonawca odpowiada. Odpowiedź na pytanie nr 39: Wykonawca odpowiada w pełnym zakresie za działanie systemu, a odpowiedzialność mogłaby zostać ograniczona lub wyłączona w taki wypadku, jeżeli wykaże, że nienależyte działanie systemu nie wynika z przyczyn lub winy po jego stronie. Pytanie nr 51: Załącznik nr 1 do SWZ - OPZ P. 7.1. W ramach realizacji zamówienia, Wykonawca zobowiązany został przez Zamawiającego do integracji swoich urządzeń z komputerami pokładowymi w pojazdach wszystkich operatorów (w autobusach i tramwajach) co oznacza zależność wszystkich Wykonawców od jednego uprzywilejowanego Wykonawcy tj. firmy Eviden Polska S.A. Takie wymaganie wskazuje jednoznacznie na ograniczenie konkurencji i próbę wyeliminowania wszystkich Wykonawców z wyłączeniem: R&G Plus Sp. z o.o. – dostawcy wyposażenia pojazdów, w tym terminali kierowcy, z którymi trzeba się zintegrować, Eviden Polska S.A. – dostawcy obecnego systemu PEKA. Wnosimy o zmianę wymagania w takim zakresie, że to Zamawiający będzie gwarantem współpracy wybranego Wykonawcy z firmą Eviden Polska S.A. w zakresie przeprowadzenia integracji urządzeń z komputerami pokładowymi w pojazdach bez ponoszenia przez Wykonawców jakichkolwiek kosztów tej współpracy, bo jedynie takie rozwiązanie zagwarantuje równe prawa dla wszystkich Wykonawców. Odpowiedź na pytanie nr 51: Zamawiający nie ma kompetencji prawnych aby zagwarantować wykonawcom współpracę z innym niezależnym podmiotem gospodarczym, co znaczy, że Zamawiający nie może być gwarantem współpracy pomiędzy wyłonionym Wykonawcą a firmą Eviden Polska S.A. lub R&G Plus Sp. z o.o. Zamówienie nie ma charakteru tzw. "zamówienia powiązanego". Zamawiający nie może narzucać innemu wykonawcy (np. Eviden) obowiązku świadczenia usług na rzecz przyszłego Wykonawcy systemu MTT PEKA, ani brać za niego odpowiedzialności. Pytanie nr 56: Załącznik nr 1 do SWZ - OPZ P. 7.3 Wykonawca zobowiązany jest wykorzystać do realizacji systemu łączności działające w pojazdach urządzenia, takie jak modemy, routery, anteny, po wcześniejszych uzgodnieniach poczynionych bezpośrednio z Wykonawcą Systemu PEKA. Wnosimy o usunięcie wymagania, ponieważ Wykonawcy inni niż: R&G Plus Sp. z o.o. – dostawca wyposażenia pojazdów, Eviden Polska S.A. – dostawca obecnego systemu PEKA. nie są w stanie skutecznie realizować wymagania określonego w p. 4 pp. 2 OPZ, tj. zapewnić ciągłości działania systemu MTT PEKA w przypadku braku połączenia (synchronizacji) z Systemem Centralnym PEKA, zachowując redundancję i dywersyfikację kanałów sprzedaży ZTM, są oni bowiem zobowiązani do wykorzystania urządzeń, na których sprawność i jakość działania nie mają żadnego wpływu. W przypadku podtrzymania przez Zamawiającego niniejszego wymagania wnosimy o udostępnienie kompletnej listy urządzeń, które mają być wykorzystane przez Wykonawców wraz numerami pojazdów, w których są zamontowane ponieważ brak tej informacji uniemożliwia nam prawidłowe oszacowanie kosztów oferty. Ponadto wnosimy o potwierdzenie przez Zamawiającego, że odpowiedzialność Wykonawcy za ciągłość działania systemu, o której mowa w p. 4 pp. 2 obejmuje wyłącznie przypadki, za które Wykonawca odpowiada. Odpowiedź na pytanie nr 56: Zamawiający nie może udostępnić listy konkretnych urządzeń sieciowych wykorzystywanych w istniejącym środowisku (np. modemy, routery). Takie działanie mogłoby prowadzić do ujawnienia informacji wrażliwych z punktu widzenia bezpieczeństwa teleinformatycznego systemu PEKA oraz infrastruktury IT Zamawiającego. Lista urządzeń i ich konfiguracja techniczna zostanie przekazana po podpisaniu Umowy o zachowaniu poufności. Zamawiający podtrzymuje zapisy w OPZ. Por. odp. na pyt. 30 i 39. Pytanie nr 61: Załącznik nr 1 do SWZ - OPZ P. 16 Wykonawca Systemu MTT PEKA zobowiązany będzie do ścisłej współpracy z Wykonawcą/Gwarantem Systemu PEKA. Zważywszy, że wykonawca Systemu PEKA będzie najprawdopodobniej również Wykonawcą w niniejszym postępowaniu, powyższe wymaganie oznacza zależność wszystkich Wykonawców od jednego z Wykonawców tj. od Eviden Polska S.A. W konsekwencji spółka Eviden może zażądać od pozostałych Wykonawców (albo tylko od niektórych) wygórowanych cen za swoje usługi, albo może w ogóle nie przedstawić oferty na swoje usługi eliminując konkurencję. Wnosimy o zmianę wymagania w takim zakresie, że to Zamawiający będzie gwarantem współpracy wybranego Wykonawcy z firmą Eviden Polska S.A. bez ponoszenia przez Wykonawców jakichkolwiek kosztów tej współpracy, bo jedynie takie rozwiązanie zagwarantuje równe prawa dla wszystkich Wykonawców. Odpowiedź na pytanie nr 61: Zamawiający pozostawia zapisy OPZ bez zmian. Por. odp. na pyt. nr 51. Pytanie nr 77: Pytanie do Załącznik nr 1 do SWZ-OPZ ust. 3.3 pkt 1 ppkt. 1) Dostawa, uruchomienie i utrzymanie Systemu MTT PEKA wraz z serwisem gwarancyjnym w okresie wdrożenia, gwarancji oraz trwałości projektu, jako nowego modułu Systemu PEKA. Prosimy o doprecyzowanie, czy określenie, iż System MTT PEKA ma stanowić „nowy moduł Systemu PEKA” oznacza konieczność technologicznej spójności z obecnym Systemem PEKA (np. stosowania tej samej platformy, dostawcy lub technologii), co mogłoby prowadzić do uprzywilejowania obecnego Wykonawcy PEKA. W związku z tym prosimy o informację, w jaki sposób Zamawiający zapewni równe warunki konkurencji dla wszystkich Wykonawców, niezależnie od ich relacji z obecnym dostawcą Systemu PEKA. Odpowiedź na pytanie nr 77: System MTT PEKA ma stanowić odrębny moduł, który musi być zintegrowany z systemem PEKA. System PEKA oparty jest na typowych protokołach komunikacyjnych w technologii SOAP API oraz REST API, które zostaną udostępnione na etapie realizacji umowy wyłonionemu Wykonawcy, co zapewni równe warunki konkurencji dla wszystkich. Pytanie nr 78: Pytanie do Załącznik nr 1 do SWZ-OPZ ust. 3.3 pkt 1 ppkt. 5) Integracja nowych funkcjonalności z obecnie użytkowanym systemem PEKA, w tym eksport danych transakcyjnych MTT oraz wymiana niezbędnych danych do obsługi ulg i uprawnień pasażerów zapisanych w systemie. Prosimy o doprecyzowanie, w jaki sposób Zamawiający zapewni Wykonawcom dostęp do niezbędnych informacji i interfejsów systemu PEKA, umożliwiających integrację nowych funkcjonalności Systemu MTT PEKA – w szczególności w zakresie eksportu danych transakcyjnych oraz wymiany danych dotyczących ulg i uprawnień pasażerów. Czy Zamawiający dysponuje aktualną dokumentacją techniczną i czy zostanie ona udostępniona wszystkim Wykonawcom już na etapie przygotowania ofert, w celu zagwarantowania równości konkurencyjnej i możliwości prawidłowej wyceny prac integracyjnych? Odpowiedź na pytanie nr 78: Na etapie składania ofert Zamawiający nie dysponuje dokumentacją techniczną dotyczącą przyszłych rozwiązań technicznych. Jednocześnie Zamawiający informuje, że interfejs nowego rozwiązania pomiędzy systemami PEKA i MTT zostanie wytworzony dopiero na etapie realizacji projektu, po uzyskaniu informacji o zaproponowanym rozwiązaniu od wybranego Wykonawcy. Por. odp. na pyt. nr 25. Pytanie nr 81: Pytanie do Załącznik nr 1 do SWZ-OPZ ust. 3.3 pkt 1 ppkt. 8) Integracja Kasownika Master (lub każdego z kasowników – w zależności od zastosowanego rozwiązania) z Terminalem Kierowcy, co najmniej obejmująca pobieranie informacji o: a) lokalizacji pojazdu, b) numerze pojazdu, c) numerze linii pojazdu, d) otwartych/zamkniętych drzwiach pojazdu, e) rozkładzie jazdy, f) strefie, g) kierunku trasy, h) taryfie, i) listach kontrolnych (białych, czarnych, itp.), j) doładowaniach tPortmonetki. Wymagane jest utrzymanie jednolitego czasu we wszystkich urządzeniach systemu, tym samym nowe urządzenia pokładowe muszą synchronizować swoje wewnętrzne zegary z zegarem autokomputera pokładowego. Prosimy o doprecyzowanie, w jaki sposób Zamawiający zapewni możliwość integracji Kasownika Master (lub pozostałych kasowników) z Terminalem Kierowcy i autokomputerem pokładowym, w szczególności w zakresie dostępu do danych takich jak lokalizacja pojazdu, numer pojazdu, numer linii, stan drzwi, rozkład jazdy, strefa, kierunek trasy, taryfa, listy kontrolne (białe, czarne) oraz doładowania tPortmonetki. Czy Zamawiający udostępni odpowiednie interfejsy i dokumentację techniczną systemów źródłowych (PEKA, autokomputer, inne), a także czy zapewni możliwość synchronizacji czasu nowych urządzeń z autokomputerem? Odpowiedź na pytanie nr 81: Zamawiający oczekuje przedstawienia przez Wykonawcę rozwiązań technicznych pozostających w zgodności z wymaganiami zawartymi w pkt. 7.1. OPZ. Wybór docelowego rozwiązania, jego omówienie, akceptacja będą przedmiotem działań w Etapie 1 Wdrożenia systemu (Projekt systemu MTT PEKA). Pytanie nr 82: Pytanie do Załącznik nr 1 do SWZ-OPZ ust. 3.3 pkt 1 ppkt. 9) Integracja Kasownika Master (lub każdego z kasowników – w zależności od zastosowanego rozwiązania) z Terminalami Kontrolerskimi, w celu zapewnienia systemowego blokowania i odblokowania Kasowników przez kontrolerów biletów w kontrolowanym pojeździe. Prosimy o doprecyzowanie, w jaki sposób Zamawiający zapewni możliwość integracji Kasownika Master (lub pozostałych kasowników) z Terminalem Kontrolerskim w celu realizacji funkcji systemowego blokowania i odblokowywania kasowników przez kontrolera w pojeździe. Czy zostaną udostępnione odpowiednie interfejsy i dokumentacja techniczna niezbędna do realizacji tej funkcjonalności? Odpowiedź na pytanie nr 82: Zamawiający zapewni możliwość integracji kasownika Master lub pozostałych kasowników z terminalem kontrolerskim za pomocą dedykowanego modułu z Systemu PEKA. Pytanie nr 86: Pytanie do Załącznik nr 1 do SWZ-OPZ ust. 7.1 Obecnie Zamawiający użytkuje Terminale Kierowcy typu RG5000P oraz SRG7000P firmy R&G Plus Sp. z o.o. z siedzibą w Mielcu, ul. Traugutta 7, 39-300 Mielec. W ramach realizacji zamówienia, Wykonawca zobowiązany będzie do integracji swoich urządzeń z komputerami pokładowymi w pojazdach wszystkich operatorów (w autobusach i tramwajach). W tym celu niezbędnym jest ustalenie przez Wykonawcę zasad współpracy bezpośrednio z gwarantem systemu PEKA –firmą Eviden Polska S.A. z siedzibą w Warszawie, ul. Pułaska 180, 00-180 Warszawa. Z tego tytułu Zamawiający nie będzie ponosił dodatkowych kosztów na rzecz Wykonawcy. Dopuszczalne jest zastosowanie innych rozwiązań umożliwiających połączenie Kasowników Systemu MTT PEKA z urządzeniami w pojeździe oraz Systemem Centralnym PEKA i innych podsystemów PEKA, z zastrzeżeniem, że kierowca nie może być zobligowany do podwójnego logowania się do systemów. Terminal Kierowcy wraz ze swoim oprogramowaniem powiązany jest zarówno z Systemem PEKA, jak również z Systemem ITS Miasta Poznań (priorytetyzacja przejazdów oraz automatyczne sterowanie zwrotnicami). W przypadku, gdy Wykonawca uzna, że w miejsce integracji z obecnie użytkowanymi urządzeniami (Terminal Kierowcy), dostarczy i skonfiguruje własne, zobowiązany będzie do zachowania pełnej, działającej dotychczas funkcjonalności tych urządzeń dla Systemu PEKA i Systemu ITS. Wymagane jest także w tym przypadku dostarczenie Zamawiającemu w pełni udokumentowanych protokołów komunikacji między tymi urządzeniami, umożliwiających dokonywanie przez Zamawiającego dalszych integracji. Prosimy o doprecyzowanie, w jaki sposób Zamawiający zapewni zachowanie zasad uczciwej konkurencji i równego dostępu do informacji dla wszystkich Wykonawców, w kontekście wymogu integracji urządzeń z Terminalami Kierowcy SRG5000P/SRG7000P firmy R&G Plus oraz konieczności samodzielnego ustalania zasad współpracy z gwarantem Systemu PEKA – firmą Eviden Polska S.A. Czy Zamawiający posiada uzgodnienia gwarantujące, że wskazane podmioty (R&G Plus oraz Eviden) udostępnią niezbędną dokumentację techniczną, interfejsy oraz zapewnią współpracę na równych zasadach wszystkim Wykonawcom? W przeciwnym razie istnieje ryzyko uprzywilejowania wybranych wykonawców lub niemożności wyceny i realizacji zamówienia w sposób rzetelny i zgodny z wymaganiami. Odpowiedź na pytanie nr 86: Zamawiający nie może zobowiązywać podmiotów trzecich, takich jak dostawca systemu PEKA, do współpracy z wykonawcami. Zamawiający może jednak i faktycznie to czyni, zapewnić, że podejmie niezbędne działania organizacyjne, aby umożliwić współpracę, np. udostępniając kontakty czy organizując spotkania robocze. Zamawiający nie wskazuje konkretnych producentów ani wykonawców, nie narzuca ich wyboru, ani nie warunkuje wykonania zamówienia współpracą z konkretnym podmiotem. Wręcz przeciwnie – wskazuje, że wykonawca może dostarczyć alternatywne rozwiązania, o ile zapewni kompatybilność systemową. To właśnie stanowi urzeczywistnienie zasad uczciwej konkurencji. Pytanie nr 88: Pytanie do Załącznik nr 1 do SWZ-OPZ ust. 7.2 pkt 14 Integracja z oprogramowaniem centralnym współpracującym z Kasownikiem, umożliwiającym m.in. zarządzanie urządzeniami i aktualizacje oprogramowania, możliwość zdalnego połączenia z wybranym urządzeniem, tworzenie dedykowanej taryfy biletowej (w tym okresowej taryfy promocyjnej) i interfejsu sprzedażowego (np. wiele wersji językowych), analizę danych, wyświetlanie treści na wygaszaczu ekranu, wyświetlanie komunikatów przez Zamawiającego, współpracę z Agentem rozliczeniowym, integrację z systemem biletu elektronicznego i Portalem Pasażera Czy Zamawiający oczekuje wdrożenia nowej aplikacji do zarządzania kasownikami (i ich integracji z systemem centralnym), czy dopuszcza również rozbudowę lub wykorzystanie istniejącego rozwiązania? Jeśli istnieje już takie oprogramowanie, prosimy o doprecyzowanie jego zakresu funkcjonalnego oraz wymagań integracyjnych. Odpowiedź na pytanie nr 88: Zamawiający wyjaśnia, że nie określa sposobu realizacji, lecz określa swoje wymagania funkcjonalne. Wybór docelowego rozwiązania, jego omówienie, akceptacja będą przedmiotem działań w Etapie 1 Wdrożenia systemu (Projekt systemu MTT PEKA). Wymagane jest dostarczenie aplikacji (oprogramowania) służącej do zdalnego zarządzania kasownikami, zapewniając jednocześnie integrację z systemem centralnym PEKA (np. w zakresie zarządzania taryfami, punktami poboru opłat itp.). Pytanie nr 94: Pytanie do Załącznik nr 1 do SWZ-OPZ ust. 7.3 Wykonawca zobowiązany jest wykorzystać do realizacji systemu łączności działające w pojazdach urządzenia, takie jak modemy, routery, anteny, po wcześniejszych uzgodnieniach poczynionych bezpośrednio z Wykonawcą Systemu PEKA Czy Zamawiający dopuszcza zastosowanie własnych urządzeń łączności (np. modemów, routerów, anten), jeżeli obecnie używane urządzenia w pojazdach okażą się niewystarczające lub niekompatybilne z wymaganiami systemu MTT PEKA? Czy dopuszczalna jest ich modyfikacja lub uzupełnienie? W jaki sposób Zamawiający zamierza zapewnić, że obecny Wykonawca Systemu PEKA podejmie współpracę i będzie aktywnie uczestniczył w uzgodnieniach wymaganych od Wykonawcy systemu MTT PEKA? Czy planowane są formalne porozumienia lub gwarancje dostępności tego podmiotu? Odpowiedź na pytanie nr 94: Zamawiający preferuje wykorzystanie istniejącej infrastruktury sieciowej w pojazdach, aby uniknąć niepotrzebnego rozbudowywania systemu łączności. Wprowadzanie dodatkowych urządzeń mogłoby skomplikować architekturę techniczną, zwiększyć koszty utrzymania oraz utrudnić kontrolę nad wykorzystaniem transferu danych przypisanego do poszczególnych kart SIM. Dodatkowo należy uwzględnić, że w części pojazdów występują ograniczenia techniczne i organizacyjne, które utrudniają ingerencję w istniejącą infrastrukturę. Niemniej jednak, w uzasadnionych przypadkach Zamawiający dopuszcza możliwość modyfikacji lub uzupełnienia obecnych rozwiązań. Zamawiający dołoży wszelkich starań, aby zapewnić prawidłową współpracę z obecnym Wykonawcą Systemu PEKA, w szczególności w zakresie uzgodnień wymaganych od Wykonawcy systemu MTT PEKA. Zamawiający jest świadomy znaczenia tej współpracy dla prawidłowej realizacji przedmiotu zamówienia i będzie podejmował działania organizacyjne oraz komunikacyjne mające na celu jej zapewnienie. Formalne gwarancje dostępności obecnego Wykonawcy Systemu PEKA mogą zostać ustanowione po zawarciu nowej umowy serwisowej, której podpisanie planowane jest na marzec 2026 roku. Do tego czasu Zamawiający będzie dążył do wypracowania roboczych mechanizmów współpracy, umożliwiających skuteczne prowadzenie uzgodnień technicznych i organizacyjnych. Pytanie nr 95: Pytanie do Załącznik nr 1 do SWZ-OPZ ust. 7.3 Wykonawca, w ramach wynagrodzenia umownego, zobowiązany będzie do dostarczenia wszelkich urządzeń rozszerzających dostęp do obecnie użytkowanej infrastruktury pojazdowej w ww. zakresie, jeśli zajdzie taka potrzeba. Czy Zamawiający może precyzyjnie wskazać, jaka infrastruktura pojazdowa jest obecnie dostępna w pojazdach (np. modemy, routery, koncentratory danych, źródła zasilania, złącza komunikacyjne itp.)? Odpowiedź na pytanie nr 95: Zamawiający dysponuje listą urządzeń pokładowych w pojazdach komunikacji miejskiej, którą to udostępni Wykonawcy na etapie realizacji Umowy po podpisaniu stosownej umowy o zachowaniu poufności, tym samym przedstawiając aktualny stan urządzeń wg ich stanu na dzień wdrażania systemu. Udostępnienie listy konkretnych urządzeń sieciowych wykorzystywanych w istniejącym środowisku na etapie składania ofert mogłoby prowadzić do ujawnienia informacji wrażliwych z punktu widzenia bezpieczeństwa teleinformatycznego systemu PEKA oraz infrastruktury IT Zamawiającego. Pytanie nr 96: Pytanie do Załącznik nr 1 do SWZ-OPZ ust. 12 Pojazdy objęte gwarancją będą wymagały uprzedniej zgody GWARANTA. Wszelkie uzgodnienia z gwarantami prowadzi Wykonawca we współpracy z operatorami (MPK i pozostali Operatorzy), koszty związane z udzieleniem zgód ponosi Wykonawca. Wszelkie koszty związane z ewentualną koniecznością dostosowania infrastruktury w pojazdach, wraz z modernizacją paneli kierujących pojazdami i okablowania ponosi Wykonawca Które konkretnie pojazdy, spośród objętych przedmiotem zamówienia, będą nadal objęte gwarancją w trakcie realizacji prac? Kto pełni rolę gwaranta dla tych pojazdów (producenci, operatorzy, inne podmioty)? Czy Zamawiający zapewni wsparcie w nawiązaniu kontaktu z gwarantami przed podpisaniem umowy? Odpowiedź na pytanie nr 96: Zamawiający nie zapewni wsparcia w kontaktach z gwarantami. Wykonawca zobowiązany jest do uzgodnienia sposobu wykonania instalacji w Pojazdach z osobami reprezentującymi osoby prawne dysponujące prawem własności do tych pojazdów. Strony przed zainstalowaniem Sprzętu w pojazdach Operatorów PTZ podpiszą trójstronne umowy, szczegółowo określające podział ról i obowiązków pomiędzy Stronami, w terminie nie później niż 6 miesięcy od podpisania Umowy. Pytanie nr 98: Pytanie do Załącznik nr 1 do SWZ-OPZ ust. 16 Prosimy o doprecyzowanie zasad i warunków współpracy z obecnym Wykonawcą/Gwarantem Systemu PEKA, w szczególności w kontekście: Czy Zamawiający posiada formalne porozumienie lub zapewnienie ze strony obecnego Wykonawcy Systemu PEKA, gwarantujące jego aktywną i terminową współpracę z przyszłym Wykonawcą Systemu MTT PEKA w zakresie: •udostępnienia niezbędnej dokumentacji technicznej, •otwarcia interfejsów systemowych, •udziału w testach i wdrożeniu? Czy zostanie zapewniony dostęp do środowiska testowego Systemu PEKA oraz dedykowane osoby kontaktowe po stronie obecnego Wykonawcy PEKA? W jaki sposób Zamawiający planuje zabezpieczyć skuteczną i równą współpracę między Wykonawcą Systemu MTT PEKA a Wykonawcą Systemu PEKA – biorąc pod uwagę, że obecny Wykonawca PEKA może być równocześnie uczestnikiem postępowania? Czy Zamawiający dopuszcza możliwość wyznaczenia niezależnego integratora lub pełnienia roli technicznego koordynatora integracji, aby uniknąć sytuacji, w której jeden z Wykonawców ma przewagę informacyjną lub kontroluje kluczowe elementy integracyjne? Bez wskazania ram współpracy, gwarancji zaangażowania obecnego Wykonawcy PEKA oraz jasnego podziału odpowiedzialności, istnieje ryzyko naruszenia zasady równego traktowania Wykonawców oraz ograniczenia konkurencji. Prosimy o odniesienie się do powyższego. Odpowiedź na pytanie nr 98: Tak, zostanie zapewniony dostęp do środowiska testowego Systemu PEKA oraz dedykowane osoby kontaktowe po stronie obecnego Wykonawcy PEKA. Zamawiający dołoży wszelkich starań, aby zapewnić prawidłową współpracę z obecnym Wykonawcą Systemu PEKA, w szczególności w zakresie uzgodnień wymaganych od Wykonawcy systemu MTT PEKA. Zamawiający jest świadomy znaczenia tej współpracy dla prawidłowej realizacji przedmiotu zamówienia i będzie podejmował działania organizacyjne oraz komunikacyjne mające na celu jej zapewnienie. Formalne gwarancje dostępności obecnego Wykonawcy Systemu PEKA mogą zostać ustanowione po zawarciu nowej umowy serwisowej, której podpisanie planowane jest na marzec 2026 roku. Do tego czasu Zamawiający będzie dążył do wypracowania roboczych mechanizmów współpracy, umożliwiających skuteczne prowadzenie uzgodnień technicznych i organizacyjnych. Zamawiający nie widzi potrzeby dopuszczenia wyznaczenia niezależnego integratora lub osoby do pełnienia roli technicznego koordynatora integracji. Pytanie nr 102: Dotyczy: Załącznik nr 1 do SWZ - OPZ + zał. 1 oraz 2 - Par. 1 pkt.3. Treść: Nowe kasowniki w pojazdach zapewnią komunikację z Systemem MTT PEKA jak również z Systemem Centralnym PEKA i kartami PEKA oraz umożliwią odczyt kodów QR generowanych w Systemie Centralnym PEKA Pytanie: Czy Zamawiający posiada i udostępni nieodpłatnie całą i kompletną dokumentację integracyjną z Systemem Centralnym PEKA, Kartami PEKA oraz API do odczytu kodów QR generowanych w Systemie Centralnym PEKA w celu oszacowania zakresu i przewidywanych kosztów? Brak takiej dokumentacji uniemożliwia rzetelne oszacowanie kosztów i preferuje aktualnego dostawcę powodując nierówne traktowanie podmiotów w procesie przetargowym. Odpowiedź na pytanie nr 102: Zamawiający udostępni dokumentację dotyczącą odczytu kodów QR po podpisaniu Umowy i rozpoznaniu szczegółowych wymagań przedstawionych przez wybranego Wykonawcę. Pytanie nr 123: Dotyczy: Załącznik nr 1 do SWZ - OPZ + zał. 1 oraz 2 - Par. 7.2.16. Treść: Kasownik powinien zapewnić możliwość podglądu historii zakupu biletów elektronicznych przypisanych w Systemie do zbliżeniowej karty płatniczej (co najmniej 10 ostatnich zakupów, z możliwością definiowania tego parametru w Systemie). Pytanie: Czy Zamawiający oczekuje wyświetlenia zakupów z systemu PEKA NTT czy także PEKA? Jeśli z obu to czy zamawiający posiada i udostępni bezkosztowo odpowiednie API? Odpowiedź na pytanie nr 123: Tak, Zamawiający udostępni odpowiednie API. Pytanie nr 169: 7.1. Terminal Kierowcy/Sterownik kasowników W ramach realizacji zamówienia, Wykonawca zobowiązany będzie do integracji swoich urządzeń z komputerami pokładowymi w pojazdach wszystkich operatorów (w autobusach i tramwajach). W tym celu niezbędnym jest ustalenie przez Wykonawcę zasad współpracy bezpośrednio z gwarantem systemu PEKA – firmą Eviden Polska S.A. z siedzibą w Warszawie, ul. Pułaska 180, 00-180 Warszawa. Z tego tytułu Zamawiający nie będzie ponosił dodatkowych kosztów na rzecz Wykonawcy. Dopuszczalne jest zastosowanie innych rozwiązań umożliwiających połączenie Kasowników Systemu MTT PEKA z urządzeniami w pojeździe oraz Systemem Centralnym PEKA i innych podsystemów PEKA, z zastrzeżeniem, że kierowca nie może być zobligowany do podwójnego logowania się do systemów. Pytanie 4: a) Czy Zamawiający dysponuje otwartym i udokumentowanym interfejsem (API) umożliwiającym integrację urządzeń Systemu MTT PEKA z komputerami pokładowymi i systemem centralnym PEKA – bez konieczności uzgadniania szczegółów technicznych i warunków finansowych bezpośrednio z Eviden Polska S.A.? b) Czy Zamawiający przewiduje udostępnienie opisu dostępnych protokołów komunikacyjnych lub dokumentacji integracyjnej (jeśli istnieje) dla potrzeb przetargu? c) Czy Zamawiający dopuszcza, aby to on – jako właściciel systemu – zawarł niezbędne porozumienie z Eviden, otwierające warstwę integracyjną (middleware) dla wszystkich potencjalnych wykonawców na równych zasadach? Obecna konstrukcja zapisu stawia wykonawców w nierównej sytuacji – brak regulacji kosztów współpracy z gwarantem (Eviden) może skutkować znacznymi różnicami ofertowymi, zależnymi wyłącznie od ich indywidualnych negocjacji z podmiotem trzecim. Odpowiedź na pytanie nr 169: Por. odp. na pyt. 86, 94 i 98 Dowody zamawiającego: Umowa nr ZTM.IU.0730-32/12 pomiędzy zamawiającym, a Business Unit Manager Goverment&Lokal Administration (według oświadczenia zamawiającego poprzednika prawnego Eviden Polska): Par. 1 pkt. 1 Dokumentacja- oznacza kompletny zestaw aktualnych, poprawnych i czytelnych rysunków, tekstów i innych dokumentów (w tym dokumentację użytkową, Dokumentację Interfejsów i Dokumentację Powykonawczą) dostarczonych zamawiającemu przez wykonawcę w ramach realizacji umowy, niezbędnych do prawidłowej eksploatacji systemu PEKA Par. 7 pkt. 3 Wykonawca zobowiązuje się do zapewnienia otwartości i interoperabilności (zdolności do wymiany danych z innymi systemami) dostarczonego rozwiązania oraz jawności definicji zaimplementowanych w tym celu protokołów komunikacyjnych Par. 8 pkt. 16 Wykonawca zobowiązany jest przekazać zamawiającemu dokumentacje, w tym dokumentacje powykonawcze systemu PEKA. Wymagania odnośnie dokumentacji, która musi być dostarczona przez wykonawcę zawarto w SOPZ Par. 15 pkt 4 Gwarancja obejmuje sprzęt, oprogramowanie, usługi i dokumentację, dostarczone i wykonane w ramach niniejszej umowy Pkt. 6 Uaktualnienie Dokumentacji następuje każdorazowo po zmianach wprowadzonych przez wykonawcę, gdy dostarczona dokumentacja przestaje być zgodna ze stanem faktycznym Systemu Par. 16 pst. 1 System PEKA musi posiadać możliwość zdefiniowania i obsługi kolejnych użytkowników Systemu Centralnego i Podsystemu Transportowego PEKA. Pkt. 2 Wykonawca określi szczegółowe warunki techniczne oraz inne, w tym procedury konfiguracji systemu umożliwiające obsługę lit. h wymiany danych z systemem zewnętrznym (np. sprzedaży e-biletów do kina, teatru, na koncert, zawody sportowe itp.) Pkt 3 Warunki, o których mowa powyżej, zostaną szczegółowo opisane i zawarte w dokumentacji systemu. Par. 17 pkt 7 Z chwilą odbioru przez zamawiającego przedmiotu umowy, wykonawca przenosi na zamawiającego autorskie prawa majątkowe do oprogramowania dedykowanego, a także do dokumentacji opracowanej na potrzeby realizacji umowy, rozumianych jako utwory w rozumieniu art. 1 ustawy z 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (t.j. DZ. U. z 2006 r. nr 60 poz. 631 z późn. Zm. ) na następujących polach eksploatacji: lit. g modyfikowanie całości oraz pojedynczych fragmentów w tym m. in. prawo do korekty, dokonywania przeróbek, zmian i adaptacji, lit. h. łączenie fragmentów z innymi utworami. Pkt. 8 Z chwilą odbioru przez zamawiającego przedmiotu umowy, wykonawca udziela zamawiającemu nieodwołalnych, niewyłącznych, nieograniczonych czasowo praw licencyjnych na oprogramowanie standardowe na następujących polach eksploatacji: lit. g modyfikowanie całości oraz pojedynczych fragmentów w tym m. in. prawo do korekty, dokonywania przeróbek, zmian i adaptacji, lit. h. łączenie fragmentów z innymi utworami. Pkt. 10 wykonawca wyraża zgodę na wprowadzenie zmian w przedmiocie umowy (prawa zależne) wynikających z konieczności dokonywania w okresie późniejszym zmian, modyfikacji, ulepszeń dzieła, o ile czynności nie będą naruszały niezbywalnych osobistych praw autorskich autora dzieła. Zgoda ta dotyczy wszystkich pól eksploatacji, o których mowa powyżej. Pkt. 12 W zakresie posiadanych praw autorskich zamawiający może modyfikować wykonane zamówienie jego poprzez rozbudowę, modyfikowanie istniejących i dodawanie nowych funkcjonalności, dodawanie nowych użytkowników, w tym pojazdów transportu zbiorowego, organizatorów transportu, przewoźników, jednostek samorządowych i innych, których włączenie do systemu PEKA jest w interesie zamawiającego. Pkt 13 Wykonawca w okresie realizacji umowy deponować będzie u uzgodnionego między stronami notariusza bądź w uzgodnionym między stronami banku kody źródłowe oprogramowania, którego producentem jest wykonawca/ Zamawiający będzie miał możliwość podjęcia kodów źródłowych z depozytu tylko w przypadku upadłości lub likwidacji wykonawcy. - umowa sprzedaży biletów nr ZTM.EBS.40300-47/14 pomiędzy zamawiającym i Mennica Polską spółka akcyjna: Par. 2 pkt. 1 Przedmiotem umowy jest: a)Sprzedaż na rzecz operatora przez ZTM biletów komunikacji miejskiej uprawniających do korzystania ze środków lokalnego transportu zbiorowego na liniach organizowanych przez ZTM w formie: i.Elektronicznej na karcie PEKA, ii.Papierowej na Mifare Ultralight C, iii.Biletu papierowego starego typu (w okresie przejściowym) iv.Doładowań tPortmonetki na karcie PEKA (…) b)Sprzedaż na rzecz operatora przez ZTM biletów komunikacji miejskiej uprawniających do korzystania ze środków lokalnego transportu zbiorowego na liniach organizowanych przez ZTM w formie: i.Elektronicznej na karcie PEKA. ii.Doładowań tPortmonetki na karcie PEKA (…) c)Sprzedaż przez ZTM operatorowi aktualnie użytkowanych 50 szt. stacjonarnych automatów biletowych oraz terminali PSB w poszczególnych punktach sprzedaży stanowi załącznik nr 4 o tytule „Harmonogram instalacji automatów biletowych i terminali PSB” par. 3 pkt 3 Zobowiązania operatora Wdrożenia i uruchomienia interfejsu oraz zapewnienie łączności pomiędzy systemem GOLD należącym do operatora, a systemem PEKA należącym do ZTM w celu wymiany danych o sprzedaży biletów dla celów rozliczeniowych zgodnie z warunkami niniejszej umowy par. 4 ZTM zobowiązany jest do: pkt 2 Dostarczenia operatorowi wszystkich niezbędnych informacji i dokumentacji technicznej koniecznej do prawidłowego kodowania biletów oraz doładowań tPortmonetki na kartach PEKA i Mifare Ultralight C oraz dokumentacji technicznej umożliwiającej integrację systemu GOLD z systemem PEKA, a także na prośbę operatora udzielanie wszelkich informacji w tym zakresie. Protokół przekazania dostarczonej dokumentacji, o której mowa powyżej stanowi załącznik nr 8 o tytule „Protokół przekazania dokumentacji technicznej PEKA dla Operatora” pkt. 3 Zapewnienia środowiska testowego w zakresie integracji systemów PEKA i GOLD w terminie 14 dni od daty podpisania umowy par. 15 pkt 1 W przypadku rozszerzenia funkcjonalności systemu PEKA o nowe produkty lub usługi strony podejmą negocjacje w celu ustalenia warunków współpracy i realizacji rozliczeń sprzedaży - zarządzenie nr 1/2023 Dyrektora ZTM w Poznaniu z 2 stycznia 2023 r. w sprawie wprowadzenia Polityki Systemu Zarządzania Bezpieczeństwem Informacji w ZTM pkt 3 Terminologia System Zarządzania w ZTM – wdrożony w ZTM system zarządzania, który realizując wytyczne norm ISO 9001 i 14001 stanowi część Zintegrowanego Systemu Zarządzania(objętego wspólną certyfikacją ) dodatkowo został rozszerzony o system zarzadzania bezpieczeństwem informacji spełniając wytyczne normy ISO 27001. W zakresie SZBI system zarzadzania w ZTM nie jest objęty certyfikacją. 5.6.4 Zasada ochrony informacji – wszystkie informacje, w tym jawne, chronione są ze względu na ich integralność (wiarygodność) oraz dostępność. Informacje chronione, w tym stanowiące tajemnicę ZTM, chronione są również ze względu na ich poufność, w szczególności nie mogą być one przekazywane osobom nieuprawnionym. Przekazania informacji do publicznej wiadomości dokumentuje wyłącznie Dyrektor ZTM oraz upoważnione przez niego osoby. 5.9.13 Tajemnice ZTM, po weryfikacji celu i zasadności, mogą być udostępniane w ramach kontroli i audytów Urzędu Miasta Poznania (w tym audytorów wewnętrznych ZSZ) oraz kontrahentom zobowiązanych poprzez zawarte umowy do ich stosowania. 5.9.19 ZTM podejmuje działania w celu zapewnienia realizacji zobowiązania przez współpracowników, w szczególności przez: - umieszczenia stosownych postanowień w umowach z podmiotami zewnętrznymi, - odbieranie stosowanych oświadczeń od współpracowników, wzór oświadczenia stanowi załącznik nr 1 do polityki Bezpieczeństwa w Zakresie Bezpieczeństwa Osobowego w ZTM 5.17 Nadzór nad dostawcami zewnętrznymi opisuje instrukcja IP-17 „Instrukcja nadzoru nad dostawcami mającymi dostęp do infrastruktury teleinformatycznej ZTM i realizującymi umowę o powierzeniu przetwarzania danych osobowych w ZTM”,. A także procedura PO-04 „Tworzenie umów”. - wykaz informacji stanowiących Tajemnicę ZTM 5. DJ. Dokumentacja techniczna systemu PEKA oraz modułów i interfejsów z nim związanych, wraz z wymiana informacji prowadzona w tym zakresie – Ochrona tajemnicą organizacji obszaru infrastruktury technicznej obsługującej klientów jest konieczna dla zapewnienia bezpieczeństwa usług, ochrony danych oraz minimalizacji zakłóceń i nieuprawnionego dostępu, co wynika wprost z przepisów o Krajowym Systemie Cyberbezpieczeństwa (KSC) oraz Narodowej Strategii Cyberbezpieczeństwa (NSC) - wyciąg z normy PN-ISO/IEC 27001 Technika informatyczna, Techniki Bezpieczeństwa systemy zarzadzania bezpieczeństwem informacji Wymagania A.13.2.2. Porozumienia dotyczące przesyłania informacji Zabezpieczenie Porozumienia powinny uwzględniać bezpieczne przesyłanie informacji biznesowych między organizacją i podmiotami zewnętrznymi - umowa ZTM.EZ.3313.2.2023 Par. 1 pkt. 1 Dokumentacja- oznacza kompletny zestaw aktualnych, poprawnych i czytelnych rysunków, tekstów i innych dokumentów (w tym dokumentację użytkową, Dokumentację Interfejsów i Dokumentację Powykonawczą) dostarczonych zamawiającemu przez wykonawcę w ramach realizacji umowy, niezbędnych do prawidłowej eksploatacji systemu PEKA Par. 2 pkt 1 Przedmiotem niniejszej umowy jest świadczenie usługi serwisu gwarancyjnego i wsparcia technicznego dla systemu oraz realizacji prac dodatkowych ( w ramach godzin deweloperskich lub prawa opcji), które z przyczyn technicznych oraz przyczyn związanych z ochroną praw wyłącznych, świadczone i realizowane mogą być jedynie przez dotychczasowego wykonawcę systemu czyli Atos Polska spółka akcyjna (według oświadczenia zamawiającego na rozprawie poprzednika prawnego Eviden Polska) Pkt. 8 w ostatnim kwartale obowiązywania umowy, niezależnie od sposobu w jaki umowa zostanie zakończona, wykonawca zobowiązany jest do transferu wiedzy zamawiającemu lub wskazanemu przez niego podmiotowi polegającego na (…) Pkt. 1 lit. d deponowanie kodów źródłowych – wykonawca zobowiązuje się najpóźniej w dniu podpisania umowy do zdeponowania kodów źródłowych całego oprogramowania dedykowanego oraz wszelkich niezbędnych modułów i bibliotek niezbędnych do prawidłowej jego kompilacji u uzgodnionego między stronami notariusza bądź w w uzgodnionym między stronami banku. Kody źródłowe deponowane będą przez cały okres realizacji umowy (…) Lit. ii Zamawiającemu przysługuje licencja do posługiwania się zdeponowanymi kodami źródłowymi na wszystkich polach eksploatacji zwłaszcza w przypadku ogłoszenia upadłości, likwidacji przedsiębiorstwa wykonawcy, zaprzestania prowadzenia działalności gospodarczej, zaprzestania rozwoju oprogramowania, w przypadku awarii oprogramowania, której nie chce usunąć wykonawca oprogramowania przez wykonawcę lub jego następców prawnych Par. 16 pkt 7 Z chwilą odbioru przez zamawiającego każdego elementu zamówienia bez zastrzeżeń, wykonawca udziela zamawiającemu licencji i sublicencji oraz wszelkiej dokumentacji wykonanej w ramach niniejszej umowy jako utworu w rozumieniu art. 1 ustawy z 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (t.j. DZ. U. z 2006 r. nr 60 poz. 631 z późn. Zm. ) oraz autorskich praw majątkowych do systemu PEKA oraz nowych wersji systemu wraz z wyłącznym prawem do zezwalania na wykonywanie praw zależnych na następujących polach eksploatacji: e) wykonywanie i zezwalania na wykonywania autorskich praw zależnych, g) modyfikowanie całości oraz pojedynczych fragmentów w tym m. in. prawo do korekty, dokonywania przeróbek, zmian i adaptacji. h) łączenie fragmentów z innymi utworami pkt. 10 wykonawca wyraża zgodę z wprowadzenie zmian w przedmiocie umowy (prawa zależne), wynikających z konieczności dokonywania w okresie późniejszym zmian, modyfikacji, ulepszeń dzieła, o ile czynności nie będą naruszały niezbywalnych osobistych praw autorskich autora dzieła. Zgoda ta dotyczy wszystkich pól eksploatacji, o których mowa powyżej. Pkt. 12 W zakresie posiadanych praw autorskich zamawiający może modyfikować wykonane zamówienie jego poprzez rozbudowę, modyfikacje istniejących i dodawanie nowych funkcjonalności, dodawanie nowych użytkowników, w tym pojazdów transportu zbiorowego, organizatorów transportu, przewoźników, jednostek samorządowych i innych, których włączenie do systemu jest w interesie zamawiającego - pismo ZTM do R&G z 30 lipca 2025 r. o przedstawienie opisu funkcjonalnego interfejsu między kasownikiem PEKA a autokomputerem w pojazdach komunikacji miejskiej Wskazany interfejs niezbędny jest do integracji autokomputera z nowymi kasownikami (PEKA i MTT) i dotyczy zarówno sposobu, zasad działania jak i zastosowanych technologii zarówno w komunikacji autokomputer—kasownik (w tym m.in. dane niezbędne do prawidłowej taryfikacji) jak i kasownik—autokomputer (w tym m.in. dane do logowania prowadzącego pojazd kartą kierowcy/motorniczego). Jednocześnie prosimy o określenie możliwości i formy dostarczenia opisu stosowanego interfejsu między autokomputerem a kasownikiem. Udzielona odpowiedź: W związku z Państwa zapytaniem o przedstawienie opisu funkcjonalnego interfejsu między kasownikiem PEKA, a autokomputerem w pojazdach komunikacji miejskiej oraz sposobu, zasad jego działania jak i zastosowanych technologii, niezbędnych do integracji autokomputera PEKA z nowymi kasownikami MTT/PEKA, w tym danych niezbędnych do prawidłowej taryfikacji i danych do identyfikacji logowania prowadzącego pojazd (kartą kierowcy/motorniczego), w odpowiedzi poniżej wskazujemy możliwe formy udostępnienia i dostarczenia dla ZTM opisu interfejsu komunikacyjnego między autokomputerem, a kasownikiem z systemu pokładowego pojazdów w odniesieniu do informacji o logowaniu prowadzącego pojazd i przekazywania lokalnie z SRG pliku taryf obecnego kasownika systemu PEKA. W szczególności: w zakresie sprzętowym do komunikacji pomiędzy autokomputerem SRG-5000P (SRG-7000P z dostaw z ostatnich kilku lat do przewoźników i MPK Poznań), a kasownikiem KRG-7 w projekcie systemu PEKA jest używany protokół przewodowy po sieci Ethernet 10/100Mbit, dostarczany przez R&G PLUS Sp. z o.o. dla firmy BULL/ATOS do projektu PEKA sprzęt i oprogramowanie nie podlegało obowiązkowi przygotowania i przekazania dla Integratora lub zamawiającego dokumentacji opisującej funkcjonalny interfejs pomiędzy kasownikiem PEKA typu KRG-7 a autokomputerem w pojazdach komunikacji miejskiej w odniesieniu do sposobu przekazywania i struktury plików taryf i danych do identyfikacji logowania prowadzącego pojazd, protokół R&G używany w systemie PEKA został opracowany jedynie w celu zapewnienia właściwej pracy systemu PEKA zgodnie z potrzebami zamawiającego i w takim kształcie został wtedy odebrany oraz funkcjonuje do dnia dzisiejszego. Obecnie eksploatowany w pojazdach protokół komunikacyjny pomiędzy kasownikiem PEKA typu KRG-7 i autokomputerem, co do swojej struktury i zawartości jest również używany i stosowany w systemach innych Klientów R&G PLUS Sp. z o.o. i w tym zakresie nie stanowi on gotowego rozwiązania możliwego do udostępnienia dla ZTM Poznań - z prawem i licencją umożliwiającą jego przekazania przez ZTM Poznań stronom trzecim tj. wykonawcom systemu MTT/PEKA ze względu na posiadane prawa własności/autorskie, których właścicielem w zakresie opracowania/rozwijania/modyfikacji protokołu jest firma R&G PLUS Sp. z o.o. protokół komunikacyjny i programowy pomiędzy kasownikiem PEKA, a autokomputerem nie podlegał wymaganiom odnośnie przekazania zamawiającemu autorskich praw majątkowych do dokumentacji interfejsu/protokołu logicznego, w szczególności w odniesieniu do obecnie wymaganych pól eksploatacji w zakresie modyfikacji i możliwości jego użycia/udostępnienia do integracji autokomputera poza systemem PEKA, np. dla wykonawcy i integracji ze wskazywanym w zapytaniu kasownikiem MTT/PEKA, dodatkowe dokumenty i opisy związane z opisem interfejsu i protokołu softwarowego eksploatowanego w systemie pokładowym w pojazdach PEKA oraz struktury danych (w zakresie obejmującym struktury danych przesyłanych do/z systemów ce niezbędne do prawidłowej taryfikacji obsługi kart PEKA w kasownikach: pliki taryf rozkładów jazdy dane zalogowanych kierowców/motorniczych zawarte w rt zastosowane algorytmy, przykłady zawartości testowych ramek i opisy scenariuszy do komunikacji pomiędzy różnymi autokomputerami (SRG-5000P, SRG-7000P) i kas naszej produkcji nie są przedmiotem udostępniania (np. ze względu na zobowiązania wynikające z Umowy pomiędzy R&G PLUS Sp. z o.o., a firmą ATOS). W związku z powyższym: a)W danych naszego protokołu LAN pomiędzy SRG-5000P (SRG-7000P), a kasownikiem KRG-7 nie ma zawartej informacji nt. prowadzącego pojazd (zalogowanego kierowcy/motorniczego). Te informacje zawarte i zapisywane są jedynie w raporcie 5000P (SRG-7000P) wysyłanym do Centrum Nadzoru Ruchu, który nie jest elementem systemu PEKA, lecz został dostarczony na potrzeby ZTM Poznań w ramach budowy ITS. Aby była możliwość udostępnienia tych informacji w pojazdach to w protokole ETH/LAN konieczne są zmiany •w oprogramowaniu SRG-5000P/SRG-7000P. Informuję jednak, że oprogramowanie autokomputera SRG-5000P dla PEKA nie jest już rozwijane ze względu na to, iż w R&G PLUS Sp. z o.o. zakończone zostało wsparcie programowe tego rozwiązania. Wyrób SRG-5000P nie jest już produkowany ze względu na niedostosowanie platformy sprzętowej i brak wsparcia ze strony dostawcy systemu operacyjne zastosowanego w tym autokomputerze. Autokomputer SRG-5000 nie spełni równie wymagań w zakresie „cyberbezpieczeństwa” (np. wdrażanie w Polsce Dyrektywą Rozporządzenia UE nr 2024/284). W związku z tym jakiekolwiek nowe modyfikacje oprogramowania SRG-5000P i udostępnia danych na pokładzie pojazdów zawierającego informacje o numerze kierowcy/motorniczego musiałyby być „wyłączone” spod wymagań w „cyberbezpieczeństwa” i traktowane jako modyfikacje oprogramowania sprzętu/rozwiązania PEKA. Dopiero wtedy byłoby możliwe udostępnienie dla ZTM dokumentacji protokołu zawierającego wymagane dane, z prawem i licencją umowną jego przekazania przez ZTM Poznań stronom trzecim tj. Wykonawcy systemu MTT/P b)Tabele taryfowe na potrzeby funkcjonowania systemów R&G PLUS Sp. z kasowników PEKA w pojazdach dostarcza system centralny ATOS. c)Wewnętrzna struktura i sposób zakodowania taryf na pokładzie i w protokole komunikacyjnym LAN pomiędzy SRG- 5000P (SRG-7000P) i kasownikiem KRG-7 w pojazdach nie jest do udostępnienia dla ZTM Poznań w obecnej postaci (z prawem i licencją umożliwiającą przekazanie przez ZTM Poznań stronom trzecim) ze względu na posiadane prawa własności/autorskie, których właścicielem w zakresie opracowania/rozwijania interfejsu jest firma R&G PLUS Sp. z o.o., gdyż obecna struktura danych w i protokole pomiędzy autokomputerem i kasownikiem KRG-7 jest również i stosowana w systemach innych Klientów R&G PLUS Sp. z o.o. W razie dalszych pytań lub konieczności dodatkowych wyjaśnień oraz uzgodnienia r sposobu pozyskania wymaganych danych dla systemu MTT/PEKA pozostajemy w dyspozycji. - Pismo ZTM z 2 września 2025 r. do Eviden Polska: w związku z obowiązującą umową nr ZTM.EZ.3313.2.2023 z dnia 31 marca 2023 r. dotyczącą świadczenia usług serwisu gwarancyjnego i wsparcia technicznego dla Systemu PEKA (dalej: Umową serwisową), uprzejmie przypominamy, że zgodnie z 52 ust. 7 Umowy, na 9 miesięcy przed jej wygaśnięciem są Państwo zobowiązani do przygotowania i przekazania zamawiającemu szczegółowej agendy zagadnień koniecznych do transferu wiedzy z zakresu realizacji przedmiotu Umowy oraz działania Systemu. Jednocześnie, biorąc pod uwagę, że zamawiający jest w trakcie postępowania o udzielenie zamówienia publicznego w trybie przetargu nieograniczonego pod nazwą: „Rozbudowa i unowocześnienie systemu PEKA”, znak (numer/sygn.) sprawy: ZTM.EZ.3310.10.2025, zwracamy się do Państwa — jako gwaranta ciągłości funkcjonowania systemu — z wnioskiem o: 1. Przekazanie niezbędnych informacji technicznych dotyczących integracji planowanego modułu MTT PEKA z obecnym systemem PEKA, w szczególności w zakresie: •interfejsów komunikacyjnych, wymagań technicznych i bezpieczeństwa, protokołów niezbędnych do integracji urządzeń (np. kasowników, terminali kierowcy, serwisów webowych), •parametrów integracji z istniejącym Systemem PEKA (w tym wymagane interfejsy, protokoły komunikacyjne, architekturę logiczną), •wymagań w zakresie bezpieczeństwa systemu, w szczególności w obszarze autoryzacji, szyfrowania, przesyłu danych oraz zgodności z obowiązującymi politykami bezpieczeństwa Zamawiającego. 2.Przekazanie wymaganych informacji dotyczących odczytu i walidacji kodu QR generowanego przez System Centralny PEKA w nowych kasownikach dostarczonych przez W systemu MTT PEKA. 3.Przygotowanie odpowiedniej biblioteki lub modułu oprogramowania umożliwiających obsługę kart PEKA w nowych kasownikach dostarczonych przez Wykonawcę systemu PEKA. 4.Wskazanie potencjalnych ryzyk technicznych związanych z włączeniem nowego mc PEKA oraz możliwych sposobów ich minimalizacji. 5.Informację, czy w związku z dodaniem nowego modułu konieczne są jakiekolwiek obecnych komponentach PEKA lub ich konfiguracji, a jeśli tak — jakie warunki należy 6.Wskazanie ewentualnych ryzyk- i rekomendacji technicznych związanych z planowaną rozbudową systemu PEKA o moduł MTT PEKA. 7.Zapewnienie udziału przedstawiciela Eviden w konsultacjach technicznych organizowanych przez Zamawiającego w terminach uzgodnionych z wyprzedzeniem w ostatnim obowiązywania Umowy, zgodnie z 52 ust. 8. 8.Przedstawienie opisu funkcjonalnego interfejsu między kasownikiem a autokomputerem, umożliwiającego integrację autokomputerów SRG5000p i nowymi kasownikami. 9.W związku z planowaną integracją nowych kasowników z systemem PEKA, ot zarówno autobusy, jak i tramwaje, udostępnienie aktualnej, obowiązującej dok technicznej dotyczącej infrastruktury transmisji danych z pojazdów do systemu Ceł Dokumentacja ta jest niezbędna do zapewnienia kompatybilności urządzeń z istniejącym środowiskiem systemowym oraz do prawidłowego przebiegu procesu wdrożenia. Podstawą niniejszego wniosku jest obowiązek wynikający z Umowy serwisowej, w szczególności zapis zobowiązujący Wykonawcę do przygotowania agendy transferu wiedzy oraz współpracy niezbędnej dla należytej realizacji przedmiotu Umowy i ciągłości funkcji systemu PEKA. Zgodnie z zasadą współdziałania stron przy wykonywaniu umów (art. 431u Prawo zamówień publicznych), oczekujemy niezwłocznego podjęcia działań, które I Zamawiającemu prawidłowe prowadzenie postępowania oraz realizację projektu zapewniający spójność i bezpieczeństwo systemu. Zastrzegamy, iż powyższy katalog zagadnień i informacji ma charakter otwarty, a w tok analizy technicznej oraz wskutek ustaleń w związku z prowadzonym postępowaniem mogą się pojawić dodatkowe obszary wymagające uzupełnienia lub doprecyzowania przez Wykonawcę. Informacje przekazane w ramach niniejszej konsultacji będą wykorzystane wyłącznie w celu należytej realizacji Umowy serwisowej oraz zapewnienia ciągłości i bezpieczeństwa działania Systemu PEKA, a po wyłonieniu Wykonawcy w postępowaniu na rozbudowę systemu PEKA, stanowić będą przedmiot uzgodnień pomiędzy Stronami. Wszelkie dane mające poufny charakter zostaną odpowiednio zabezpieczone. Jednocześnie informujemy, że w przypadku, gdy odpowiedzi będą miały znaczenie dla prawidłowego prowadzenia postępowania o udzielenie zamówienia publicznego, ich zakres (z wyłączeniem informacji poufnych) zostanie udostępniony wszystkim potencjalnym wykonawcom za pośrednictwem platformy zakupowej w formie odpowiedzi na pytania, zgodnie z art. 284 ustawy Prawo zamówień publicznych. Zamawiający zapewnia, że informacje ogólne istotne dla kalkulacji ofert zostaną opublikowane, co eliminuje zarzut działania na korzyść konkretnego podmiotu. Prosimy o przekazanie wstępnej odpowiedzi w terminie 7 dni od dnia otrzymania niniejszego pisma, w szczególności potwierdzenia gotowości do udziału w konsultacjach oraz harmonogramu przekazania niezbędnych informacji. Brak podjęcia współpracy w powyższym zakresie może zostać uznany za nienależyte wykonanie Umowy. Rozkłady jazdy GTFS i GTFS-RT wskazują jakie pliki dotyczące informacji o pojazdach i trasach mogą być bezpośrednio pobierane. Dialog techniczny odpowiedzi na pytania udzielone przez Mennicę: 12. Czy możliwa jest integracja z systemem zamawiającego (System R&G) - czy możliwe jest przekazywanie raportów pomiędzy jakimi przystankami lub na jakim przystanku został zakupiony bilet? Taka integracja jest możliwa. Warunkiem jest udostępnienie przez zamawiającego narzędzi informatycznych do wykonania takiej integracji (API). Przykładem integracji systemu PEKA z systemami zewnętrznymi może być istniejąca i sprawnie działająca integracja pomiędzy systemem PEKA z systemem rozliczeniowym Mennicy GOLD. Zapewnienie integracji umożliwi sprawdzenie, w obrębie którego przystanku bilet był kupiony, a w przypadku systemu check-in/check-out również przystanku, na którym zarejestrowano wyjście z pojazdu. Umowa ZTM.SW.3310.8.2021 z Mennicą Polską na wybór operatora systemu płatności za przejazd transportem publicznym za pomocą zbliżeniowych kart płatniczych i urządzeń mobilnych Par. 4 ust. 3 Zobowiązania operatora Operator zobowiązuje się do wykonania interfejsów zapewniających prawidłową integracje i komunikację z Systemem PEKA, szczegółowo określonych w załączniku nr 1, zgłoszenia Sprzedającemu gotowości działania tego rozwiązania oraz uzyskania jego akceptacji Ust. 21 Eksportu danych sprzedażowych z systemu dystrybucji biletów Operatora do systemu centralnego PEKA. Opis interfejsu i procedury wymiany danych zostaną uzgodnione przez Strony w terminie 1 miesiąca po podpisaniu umowy. Operator zapewni codzienny przepływ informacji ilościach, wartościach i rodzajach sprzedanych biletów Raport sprzedaży pokazuje, że można uzyskać dane o dacie i godzinie transakcji, nr pojazdu, nr kontraktu, id transakcji, nazwie biletu, tokenie, cenie linii, przystanku kierunku i statusie transakcji. Raport stanu urządzeń pokazuje, że można uzyskać dane o nr kasownika, nr bocznym pojazdu, typie pojazdu, nazwie przewoźnika, stanie komunikacji, błędzie, kodzie, kierunku GTFS-RT ostatnim przystanku, ostatnim odczycie GTFS, ostatniej transakcji i ostatnim zdarzeniu Dowód przystępującego: ogłoszenie o dialogu technicznym - odpowiedzi GMV na pytanie 12 12. Czy możliwa jest integracja z systemem zamawiającego (System R&G) - czy możliwe jest przekazywanie raportów pomiędzy jakimi przystankami lub na jakim przystanku został zakupiony bilet? Jest to uzależnione od interfejsu i protokołów komunikacyjnych oraz ich dokumentacji, jakimi dysponuje zamawiający, które będą niezbędne do przeprowadzenia integracji. Do szerszego omówienia podczas spotkania. Dowody: KIO dopuściła i przeprowadziła dowody z dokumentacji postępowania oraz dowody złożone przez zamawiającego i przystępującego GMV. Rozważania Krajowej Izby Odwoławczej: Krajowa Izba Odwoławcza (KIO) dopuściła GMV Innovating Solutions w charakterze uczestnika postępowania. KIO uwzględniła opozycję odwołującego wobec przystąpienia do postępowania EvidenPolska spółka akcyjna, bo KIO doszła do przekonania, że przystąpienie datowane na 31 lipca 2025 r. zawierało wskazanie interesu niezgodne z żądaniem rozstrzygnięcia korzystnego dla strony, do której Eviden przystąpił, zaś przystąpienie z 1 sierpnia 2025 r. poza stwierdzeniem, że interes zostałby naruszony nie zawierało wskazania, na czym ten interes Eviden polega i w jaki sposób mógł zostać naruszony wniesionym odwołanie. Taki sposób wykazania posiadania interesu w uzyskaniu rozstrzygnięcia korzystnego dla strony, do której nastąpiło przystąpienie jest nie wystarczający do oceny istnienia tego interesu. Z tego względu należało uznać, że przystępujący nie wykazał interesu w uzyskaniu rozstrzygnięcia korzystnego dla zamawiającego, a w konsekwencji opozycję należało uznać za zasadną. KIO ustaliła, że nie zaistniała przesłanka do odrzucenia odwołania w myśl art. 528 ustawy. KIO oceniła, że odwołujący wykazał przesłankę materialno-prawną dopuszczalności odwołania o której mowa w art. 505 ust. 1 ustawy. KIO podzieliła w tym zakresie stanowisko odwołującego, że interes, którym ma się legitymować wnoszący odwołanie wykonawca jest interesem w uzyskaniu zamówienia, a nie interesem w możliwości zapewnienia szansy na złożenie oferty. Zarzuty odwołania wskazują na to, że odwołujący choć formalnie ma możliwość złożenia oferty, to jednak uważa, że będzie musiał zrobić to na warunkach nierównej konkurencji, a to zmniejsza jego szanse na uzyskanie zamówienia. Tym samym odwołanie nakierowane na zwiększenie tych szans, jest odwołaniem, w którym odwołujący wykazał interes w uzyskaniu zamówienia. Z tego względu KIO nie uwzględniła stanowiska zamawiającego wskazującego na brak interesu odwołującego we wniesieniu odwołania. Odwołujący wnosił o umorzenie na podstawie art. 568 pkt 2 ustawy odwołania w zakresie zarzutów odnoszących się do pkt. 10.1 PŁATNOŚCI W SYSTEMIE MTT PEKA raz pkt INTEGRACJA PLANOWANEGO SYSTEMU MTT PEKA Z ISTNIEJĄCYM SYSTEMEM PEKA w zakresie odnoszącym się do integracji z systemem PEKA (str. 6 odwołania). Odwołujący wskazywał, że w świetle odpowiedzi na pytanie udzielonych przez zamawiającego 4 września 2025 r. nr 13, 77 i 123 zamawiający podał informacje umożliwiające oszacowanie oferty w odniesieniu do Agenta Rozliczeniowego oraz zobowiązał się do udostępnienia API umożliwiającego integrację systemu MTT PEKA z systemem PEKA. W konsekwencji twierdził, że doszło do zmiany dotychczasowych postanowień SW Z w sposób czyniący zadość jego oczekiwaniom w tym zakresie, a w skutek tego spór w tej części pomiędzy stronami wygasł i orzekanie stało się zbędne. W ocenie KIO skoro dysponent postępowania jakim jest odwołujący uważa, że w jakimś zakresie przed wydaniem orzeczenia w sprawie wygasły pomiędzy stronami elementy sporne, to należy uznać, że brak jest substratu zaskarżenia, a orzekanie w tym przedmiocie staje się zbędne. Takie ustalenie powoduje, że zachodzi hipoteza normy art. 568 pkt 2, która prowadzi do ziszczenia się dyspozycji art. 568 ust. 2, a więc orzeczenia o umorzeniu postępowania w tej części, w której orzekanie stało się zbędne. Odwołujący postawił zarzuty naruszenia art. 99 ust. 1, 2 i 4 ustawy, uzasadniając ten zarzut wskazywał, że brak jest jakiejkolwiek informacji, że zamawiający udostępni wykonawcom jakiekolwiek narzędzia informatyczne, które umożliwią przeprowadzenie takiej integracji. W miejsce tego zamawiający wymaga (p. 16 OPZ) podjęcia współpracy z wykonawcą systemu PEKA – spółką Eviden Polska S.A., który jest również potencjalnym wykonawcą w niniejszym postępowaniu na wdrożenie systemu MTT PEKA. W ocenie KIO zarzut ten zdezaktualizował się w świetle odpowiedzi udzielonych przez zamawiającego 4 września 2025r. przede wszystkim zamawiający udzielając wykonawcom odpowiedzi na ich pytania wskazywał wielokrotnie na możliwość zastosowania rozwiązań alternatywnych, choćby w odpowiedzi na pytania 24, ale także w innych (np. 86) wskazywał, że wykonawca może dostarczyć rozwiązanie alternatywne, o ile zapewni kompatybilność systemu. Zamawiający wskazywał nadto, że oczekuje na przedstawienie projektu realizacji od wykonawcy i po jego uzyskaniu dobrane zostaną odpowiednie metody jego realizacji. Tym samym zamawiający nie wyklucza możliwości komunikacji przede wszystkim w zakresie komunikacji kasownika z autokomputerem w oparciu o inne rozwiązania, niż dotychczas posiadane. Stawia w tym przypadku tylko warunek braku konieczność podwójnego logowania się do urządzeń przez kierowcę. Zamawiający w ocenie KIO logicznie na rozprawie argumentował, że możliwe jest dodanie urządzeń, na których nie będzie konieczności logowania. KIO dostrzegła też, że w odpowiedzi R&G, które choć odmawia zamawiającemu przekazania protokołów komunikacyjnych z uwagi na brak odpowiedniego przejścia praw autorskich, to jednak wskazuje, kto jest w posiadaniu takich protokołów komunikacyjnych - firma Eviden (z którą R&G łączy umowa jako z następcą firmy ATOS). Zatem jedynym podmiotem, z którym wykonawcy mieliby nawiązywać współpracę byłby de facto wykonawca Eviden. W odniesieniu do niego zamawiający zobowiązał się udostępnić API do integracji z systemem PEKA, zobowiązał się do przekazania dokumentacji technicznej, wskazał, że API jest oparte na typowych protokołach komunikacyjnych SOAP API i REST API, co więcej w odpowiedzi na przede wszystkim na pytanie 94 i 98 wskazał, że będzie współpracował z wykonawcą w celu umożliwienia współpracy z Eviden w szczególności zamawiający zobowiązał się do udostępnienia kontaktów, organizacji spotkań roboczych (pyt. 86), ale także wskazał, że bardziej szczegółowe warunki współpracy będą określone w przyszłej umowie serwisowej od marca 2026, a do tego czasu zamawiający będzie dążył do wypracowania roboczych mechanizmów współpracy, umożliwiających skuteczne prowadzenie uzgodnień technicznych i organizacyjnych. Wskazywał, że jest świadomy znaczenia tej współpracy dla prawidłowej realizacji przedmiotu zamówienia i będzie podejmował działania organizacyjne oraz komunikacyjne mające na celu jej zapewnienie. Zamawiający wskazał, że zostanie zapewniony dostęp do środowiska testowego Systemu PEKA oraz dedykowane osoby kontaktowe po stronie obecnego wykonawcy PEKA. W ocenie KIO z udzielonych odpowiedzi nie wynika zatem, że zamawiający odmawia współpracy z wykonawcą, w sytuacji potrzeby zapewnienia współdziałania z firmą Eviden, przeciwnie zamawiający dekalruje tę współpracę, wskazuje na jej formy zobowiązuje się do przekazania tego co posiada, a więc API i dokumentacji po podpisaniu umowy. W ocenie KIO również przedstawione przez zamawiającego umowy - umowa z Eviden z 2012 r. wskazuje, że wykonawca był zobowiązany do wytworzenia warunków, w tym technicznych umożliwiających komunikację z innymi systemami w przyszłości i udostępnienia tych warunków zamawiającemu. To potwierdza w ocenie KIO prawo zamawiającego do przekazania wykonawcom API. Również umowa serwisowa wskazuje, że Eviden jest obowiązany do transferu wiedzy zamawiającemu, a pismo z 2 września 2025 r. potwierdza, że zamawiający zamierza egzekwować to prawo. Nadto obie umowy z Mennicą potwierdzają, że zamawiający przekazuje dokumentację po zawarciu umowy i udostępnia interfejsy. Odwołujący zaś, jak słusznie podnosił zamawiający nie uprawdopodobnił twierdzonego faktu, że współpraca z Eviden będzie niemożliwa, nadmiernie utrudniona lub kosztowna. Odwołujący poprzestał w tym zakresie jedynie na oświadczeniach zawartych w odwołaniu nie przywołując, ani konkretnych zdarzeń z przeszłej współpracy z zamawiającym, w ramach której miał potrzebę integracji z systemem PEKA, ani nie wskazywał, że występował do Eviden w związku z tym postępowaniem i nie otrzymał odpowiedzi lub otrzymał odpowiedź odmowną, albo nieakceptowalne, także do co kosztu warunki współpracy. Tym samym tezy odwołanie a tym zakresie pozostają gołosłowne, w przeciwieństwie do postawy zamawiającego, który z jednej strony udziela odpowiedzi wskazujących na wolę współdziałania w celu umożliwienia współpracy z dotychczasowym wykonawcą, jak i woli przekazania informacji, w których jest posiadaniu. Oczywistym jest, że dotychczasowy wykonawca ma większy dostęp do informacji, lepszą znajomość systemu, z którym trzeba wykonać integrację, jednak odwołujący nie zdołał przekonać KIO, że zamawiający nie udostępni mu wystarczających danych umożliwiających zrealizowanie zamówienia na warunkach konkurencyjnych. Odwołujący i przystępujący uczestniczyli w dialogu konkurencyjnym, wskazywali na to, że możliwość realizacji zamówienia w zakresie integracji z autokomputerem zależy od tego, czy zamawiający udostępni interfejs, jednak sam przystępujący wskazywał, że może nie być takiej istotnej potrzeby pobierania danych z autokomputera jeśli te same dane są gromadzone czy to w systemie PEKA, do którego będzie dostęp przez API, czy w innym systemie, a tu przystępujący wskazywał na ITS. Zatem po udostępnieniu dokumentacji przez zamawiającego wykonawcy będą mieli możliwość odpowiedniego zaprojektowania systemu i niezbędnego zakresu komunikacji między systemami w celu umożliwienia wykonania przedmiotowego zamówienia. Co do tego, że dokumentacja i niezbędne informacje zostaną przez zamawiającego przekazane dopiero wykonawcy po podpisaniu umowy, to faktycznie brak tych danych już na etapie ofertowania powoduje, że wykonawcy, którzy dotychczas nie mieli styczności z systemem PEKA mogą mieć trudność w szacowaniu ryzyka projektu. Jednak zamawiający wykazał, że dokumentacja ta jest informacją objętą tajemnicą jego przedsiębiorstwa, a odwołujący choć podniósł zarzut naruszenia art. 133 ust. 1 ustawy, ale nie stawia zarzutu z art. 133 ust. 3 w związku z art. 18 ust. 4 ustawy i nie żąda określenia reguł dostępu do dokumentacji w takim zakresie, w jakim ma ona charakter poufny z uwagi na potrzebę ochrony systemów teleinformatycznych i spełniania wymogów cyberbezpieczeństwa. W żadnym z żądań nie sprecyzował wniosku o skierowanie do zamawiającego nakazu udostępnienia dokumentacji wraz z określeniem warunków dostępu do niej na etapie ofertowania. Zamawiający zaś zobowiązał się ją przekazać w ramach realizacji zamówienia. Odwołujący ponownie mimo, że już dwukrotnie realizował zamówienie wymagające integracji z systemem PEKA i wymiany z nim danych nie wskazał, w czym upatruje odmienności tego projektu od wcześniejszych. Dlaczego wówczas wystarczające było przekazanie przez zamawiającego dokumentacji i określenie danych przy zawarciu umowy. Oczywiście tamte umowy nie były zawierane w reżimie zamówień publicznych, ale co najmniej jedna z nich w otwartym konkursie, co również zakłada możliwość konkurowania większej liczby wykonawców niż jeden. Odwołujący zatem nie uprawdopodobnił, że udostępnienie dokumentacji na etapie zawarcia umowy może prowadzić do nierównego traktowania wykonawców i ograniczenia konkurencyjności postępowania. Nie wskazywał również na to, że zamawiający przekazał wówczas dokumentacje niekompletną, utrudniał wymianę informacji bądź nie współpracował z wykonawcą, co uprawdopodabniałoby trudności w wykonaniu także bieżącego zamówienia. Co do odjęcia odpowiedzialności za działanie systemu wykonawcy, to w ocenie KIO takie żądanie z uwagi na treść art. 554 ust. 6 ustawy nie mogło być żądaniem skutecznym. KIO nie wolno jest nakazać wprowadzenia do umowy postanowień określonej treści. W ocenie KIO także całkowite wyłączenie odpowiedzialności za działanie systemu MTT PEKA byłoby także sprzeczne z przepisami kodeksu cywilnego niepozwalającymi na umowne bezwzględne wyłączenie odpowiedzialności kontraktowej za okoliczności zawinione przez wykonawcę. Zamawiający nadto odpowiadając na pytanie 39 wskazał jak rozumie odpowiedzialność wykonawcy za działanie systemu i kiedy może się on zwolnić z tej odpowiedzialności czyli kiedy wykaże, że nienależyte działanie tego systemu nie wynika z przyczyn lub winy po jego stronie. Zatem jeśli przyczyną nienależytego działania systemu MTT PEKA będzie odmowa współpracy przez zamawiającego lub Eviden, to wykonawca powołując się na wyjaśnienie treści SW Z nr 39 będzie mógł zamawiającemu wykazać, że zachodzą podstawy do wyłączenia jego odpowiedzialności. Co więcej takie rozumienie odpowiedzialności koreluje z umownym obowiązkiem wykonawcy informowania w terminie 14 dni od zaistnienia okoliczności, o wszelkich okolicznościach, które mogą utrudniać zrealizowanie zamówienia. Przechodząc do braku listy urządzeń modemów, routerów i anten, to zamawiający udzielając odpowiedzi na to, że lista ma charakter poufny i ze względów na wymogi ochrony systemu teleinformatycznego przekaże ją wykonawcy po podpisaniu umowy o poufności - odpowiedź na pytanie 56 czy 95. Tu także odwołujący poza zagrożeniem braku ciągłości i potencjalnej niemożliwości synchronizacji nie wskazał, na czym polega przewaga R&G i Eviden. Jeśli działanie systemu MTT PEKA byłoby niemożliwe z przyczyn leżących po stronie urządzeń innych podmiotów, to w ocenie KIO odpowiedź na pytanie nr 39 miałaby w tym przypadku zastosowanie i umożliwiałaby wykonawcy zwolnienie się z odpowiedzialności za działanie systemu MTT PEKA. Odwołujący nie sprecyzował o jaką listę mu chodzi, czy ilościową, czyli ile jest routerów, modemów lub anten, czy rodzajową czyli bez określania ilości jakie modele routerów, modemów lub anten funkcjonują w pojazdach. Bez sprecyzowania zakresu potrzebnych danych, trudno byłoby nakazać zamawiającemu konkretne działanie. Także w tym przypadku odwołujący nie stawiał żądań związanych z zapewnieniem sobie dostępu do dokumentów zawierających informacje charakterze poufnym. Odwołujący zakwestionował także wymóg „5. NOŚNIKI IDENTYFIKATORÓW W SYSTEMIE PEKA I MTT System MTT PEKA będący nowym modułem Systemu PEKA, połączonym z Systemem Centralnym PEKA i powinien zapewnić obsługę kart PEKA w zakresie wskazanym w p. 5.1. OPZ.” Przy czym w tym zakresie w ocenie KIO zamawiający udzielił jednoznacznej odpowiedzi na pytanie 25 wskazuje, że w tym zakresie wystarczająca jest dokumentacja apletu karty PEKA, którą zamawiający przekaże po podpisaniu umowy. Podobnie w przypadku kodów QR w odpowiedzi na pytanie 34 zamawiający wykona wszelkie niezbędne prace programistyczne po stronie interfejsów programu PEKA. To w ocenie KIO wskazuje, że integracja w tym zakresie będzie możliwa także bez współpracy z Eviden. Co do pkt. 16 to wprost do tego jak zamawiający zamierza doprowadzić do skutecznej współpracy pomiędzy Eviden, a wykonawcą świadczy odpowiedź na pytanie 98, w której zamawiający zobowiązał się do współdziałania w celu umożliwienia współpracy. Dodatkowo KIO uznała zarzut naruszenia art. 431 ustawy za niezasadny, bowiem z projektowanych postanowień umownych jednoznacznie wynika, że zamawiający zobowiązał się do współpracy z wykonawcą przy realizacji przedmiotowej umowy Z tych wszystkich względów KIO postanowiła oddalić odwołanie. O kosztach postępowania odwoławczego orzeczono na podstawie art. 574 i 575 ustawy, tj. stosownie do wyniku postępowania, z uwzględnieniem postanowień Rozporządzenia Prezesa Rady Ministrów w sprawie szczegółowych rodzajów kosztów postępowania odwoławczego, ich rozliczania oraz wysokości i sposobu pobierania wpisu od odwołania z dnia 30 grudnia 2020 r. (Dz.U. z 2020 r. poz. 2437) na podstawie par. 8 ust. 2 pkt. 1 cyt. rozporządzenia zaliczając w poczet kosztów koszty wpisu, koszty wydatków pełnomocnika odwołującego, koszty wydatków pełnomocnika zamawiającego. Skoro zarzuty odwołania nie potwierdziły się, żaden z zaliczonych kosztów odwołującego nie podlegał rozliczeniu. Zamawiający nie wnosił o zasądzenie kosztów i nie złożył faktury, z tego względu KIO nie nakazała odwołującemu zwrotu na rzecz zamawiającego kosztów postępowania. Przewodnicząca: …………………………