Rzeszów po raz czwarty przesunął termin składania ofert w przetargu na rozbudowę i integrację miejskiego systemu biletowego. Nowa data to 19 sierpnia 2026 r. To jednak nie jest zwykły zakup sprzętu.
Zwycięzca dostanie zaledwie 180 dni na spięcie w jedną całość aplikacji mobilnej, ponad 260 biletomatów, blisko tysiąca kasowników, urządzeń kontrolerskich i nowej serwerowni – bez wyłączania systemu, z którego codziennie korzystają pasażerowie.
Dla pasażerów najważniejsze jest to, co pojawi się na końcu: jedna aplikacja z planerem podróży i widżetami, płatność „wsiądź i jedź” z automatycznym limitem opłat oraz logowanie tożsamością elektroniczną. Zanim to nastąpi, Rzeszów musi jednak najpierw doczekać się ofert – a te, po czterech przesunięciach, mają wpłynąć do 19 sierpnia.
Co tak naprawdę chce kupić Rzeszów?
Postępowanie prowadzone pod nazwą „Rozbudowa i integracja systemów sprzedaży i kontroli oraz portalu pasażera wraz z zakupem niezbędnej infrastruktury” to unijny przetarg nieograniczony ogłoszony przez Urząd Miasta Rzeszowa na potrzeby Zarządu Transportu Miejskiego. Projekt jest współfinansowany z programu Fundusze Europejskie dla Polski Wschodniej 2021-27.
Wbrew pozorom nie chodzi o wymianę urządzeń, lecz o rozbudowę i połączenie systemów, które już działają. Opis przedmiotu zamówienia wylicza kilka warstw prac, które muszą powstać równolegle.
Warstwa cyfrowa to rozbudowa aplikacji mobilnej „JADĘ RZESZÓW”, Portalu Pasażera (jade erzeszow pl) oraz e-Sklepu. Nowością dla pasażerów ma być obsługa przejazdów w modelu Check-In / Check-Out oraz mechanizm Fare Capping — automatyczne naliczanie opłat za kolejne przejazdy aż do osiągnięcia limitu taryfowego (dziennego, tygodniowego lub miesięcznego), rozliczane z preautoryzacji karty bankowej. Dochodzi do tego logowanie przez Krajowy Węzeł Identyfikacji Elektronicznej (Profil Zaufany, mObywatel, bankowość).
Setki biletomatów i blisko tysiąc kasowników
Warstwa urządzeń terenowych obejmuje przystosowanie oprogramowania dla 51 biletomatów stacjonarnych, ponad 210 biletomatów mobilnych w pojazdach, około 969 kasowników (z czego ok. 822 z terminalem płatniczym) oraz 20 terminali kontrolerskich opartych na urządzeniach Ingenico Move 5000.
Warstwa infrastruktury to dostawa i konfiguracja 4 serwerów i rozbudowa systemu bezpieczeństwa. Do tego dochodzi migracja środowiska IT.
Dlaczego to „rozwiązanie kompleksowe”?
Klucz do zrozumienia całej sprawy leży w słowie „integracja”. Wykonawca nie buduje systemu od zera na czystym gruncie. Musi wpiąć nowe funkcje w działający organizm złożony z systemów autonomicznych: FCS (Fare Calculation System), Serwera Kontroli, Hurtowni Biletów, SRSB (System Rozliczeń Sprzedaży Biletomatów) czy Systemu Karty Mieszkańca. Dokumentacja wymienia co najmniej sześć odrębnych integracji, m.in. aplikacji mobilnej z FCS w zakresie danych z przejazdów check-in/check-out czy Serwera Kontroli z kasownikami obsługującymi karty EMV.
To właśnie odróżnia ten przetarg od typowego zakupu sprzętu: efektem ma być jeden spójny ekosystem, a nie zestaw osobnych urządzeń. Wymagania techniczne są przy tym bardzo rozbudowane. Sama specyfikacja systemu bezpieczeństwa liczy blisko sto punktów.
Cztery terminy: skąd poślizg?
Z opublikowanych danych postępowania widać serię zmian terminu składania ofert – pojawiały się kolejno daty 3, 4 i 5 sierpnia, aż ustalono 19 sierpnia 2026 r. Dokumentacja nie podaje wprost przyczyn każdego przesunięcia. Przy postępowaniach tej skali można wskazać, że kilka typowych i widocznych w samych materiałach przetargowych powodów.
Pierwszy to poziom skomplikowania technicznego. Migracja środowisk IT i wpięcie nowych funkcji w działające systemy centralne – bez paraliżu bieżącej obsługi pasażerów – wymaga od oferentów rzetelnej kalkulacji ryzyka. Zwykle przekłada się to na litanię pytanń i wniosków o czas.
Drugi to charakterystyczne dla przetargów integracyjnych pytania wykonawców. Firmy technologiczne dopytują o protokoły komunikacyjne, struktury baz danych i kompatybilność sprzętową. Każda odpowiedź zamawiającego bywa powodem korekty Specyfikacji Warunków Zamówienia; w konsekwencji wydłużenia terminu.
Trzeci to wymogi zgodności i cyberbezpieczeństwa, a także rozbudowane wymagania wobec systemu bezpieczeństwa sieciowego. Doprecyzowanie takich zapisów w toku postępowania również sprzyja przesuwaniu dat.
180 dni na rewolucję: dużo to czy mało?
Po otwarciu ofert i wyborze najkorzystniejszej firma stanie przed napiętym harmonogramem: pełne wdrożenie, testy integracyjne i uruchomienie w środowisku produkcyjnym mają zamknąć się w rygorystycznym terminie 180 dni od podpisania umowy.
Patrząc na doświadczenia z innych miast w Polsce termin jest nad wyraz ambitny. Przykłady mówią same za siebie.
Przewodniczący zarządu GZM, Kazimierz Karolczak, relacjonował swego czasu, że dane ze ŚKUP będą przenoszone do Transport GZM, a funkcjonalności starego systemu wyłączane stopniowo i odpowiednio wcześniej. Tak było w teorii. Później, Grzegorz Kwitek, członek zarządu, przyznał publicznie, że automatyczna migracja się nie powiodła i część biletów nie została przeniesiona, zapowiadając, że GZM będzie domagać się od firmy odpowiedzialności odszkodowawczej, jeśli taka wystąpi.
| Miasto / Projekt | Główny problem integracyjny | Efekt / Skutki dla harmonogramu |
|---|---|---|
| System FALA (woj. pomorskie) |
Skomplikowane integracje, wielu przewoźników, nowe i stare urządzenia w pojazdach. | Wielokrotne przesuwanie terminów, aneksowanie umów, opóźnienie wdrożenia o ponad rok od pierwotnych dat. |
| Transport GZM (Górnośląska Metropolia) |
Wyłączenie starego systemu ŚKUP i zastąpienie go nową aplikacją/kartą przy zachowaniu ciągłości sprzedaży. | Automatyczna migracja nie powiodła się w 100 proc. |
| MKA / Krakowska Karta Miejska | Łączenie kart miejskich, taryf strefowych oraz terminali EMV w pojazdach różnych spółek. | Problemy z kompatybilnością czytników i długi proces odbiorów technicznych oraz integracji oprogramowania. |
(mob)
Czytaj więcej:
Dramat w Szpitalu Uniwersyteckim w Rzeszowie. Ulewy zalały podziemia, izba przyjęć zamknięta
