Po terminiePrzetarg nieograniczony · PN465342-2026
Rozbudowa i integracja systemów sprzedaży i kontroli oraz portalu pasażera wraz z zakupem
Gmina Miasto Rzeszów - Urząd Miasta Rzeszowa6 aktualnych · 288 w archiwum·NIP 8133734188·podkarpackie
Składanie ofert: 12 sierpnia 2026
Przedmiot zamówienia
AIPrzedmiotem zamówienia jest rozbudowa i integracja systemów sprzedaży i kontroli biletów komunikacji miejskiej ZTM w Rzeszowie wraz z dostawą infrastruktury IT.
Zakres prac:
- Rozbudowa oprogramowania: modyfikacja aplikacji mobilnej „JADĘ RZESZÓW” (m.in. funkcje Fare Capping, obsługa spraw, planer podróży, integracja z Węzłem Krajowym), rozbudowa Portalu Pasażera i systemu e-Sklepu, rozbudowa oprogramowania biletomatów oraz modernizacja oprogramowania urządzeń kontrolerskich i kasowników.
- Usługi: prace projektowe (w tym UML), wdrożeniowe, integracyjne (z istniejącymi systemami biletowymi, płatnościami, bazami danych), migracyjne oraz szkolenia.
- Dostawa sprzętu i licencji:
- 4 serwery rackowe wysokiej wydajności,
- 1 urządzenie zabezpieczające sieć (Firewall/UTM) z usługą migracji,
- 16 licencji systemu operacyjnego klasy Datacenter (16 rdzeni),
- 150 licencji dostępowych użytkownika (User CAL),
- 40 licencji zdalnego dostępu (RDS User CAL),
- 2 licencje serwerowej bazy danych (2 rdzenie).
- Gwarancja: 60 miesięcy.
Trudność: wysoka
Zamówienie wymaga złożonej integracji wielu systemów informatycznych (aplikacje, biletomaty, kontrolery, kasowniki, serwery) w działającym środowisku produkcyjnym, co wiąże się z wysokim ryzykiem technicznym i koniecznością precyzyjnej koordynacji prac.
Czerwone flagi
AISygnały, na które warto zwrócić uwagę przed startem.
SWZ zmodyfikowany 28 dni po udostępnieniu dokumentów
Późna modyfikacja specyfikacji może sugerować dostosowanie wymagań pod konkretnego wykonawcę lub celowe utrudnienie konkurencji, która przygotowała ofertę na pierwotną wersję SWZ.
Termin składania ofert przypada na okres wakacyjny (19 sierpnia)
Termin w okresie wakacyjnym (lipiec-sierpień) może ograniczać liczbę oferentów ze względu na urlopy.
Kary i sankcje
AI- Kary umowne: szczegółowe zapisy w projektowanych postanowieniach umowy (dostępne w załącznikach do SWZ)
- Wadium: 0 zł (Zamawiający nie wymaga wniesienia wadium)
- Zabezpieczenie należytego wykonania umowy: 0 zł (Zamawiający nie wymaga wniesienia zabezpieczenia)
Pozostałe 1 zapis o karach po założeniu darmowego konta.
Pytania i odpowiedzi
26Wyodrębnione z wyjaśnień treści SWZ.
1(Brak wyraźnego pytania w dokumencie)
(Dokument zawiera jedynie zmiany treści SWZ — brak par pytanie→odpowiedź)
1[brak pytań w dokumencie]
[dokument zawiera zmiany treści SWZ, brak pytań i odpowiedzi]
1Prawa autorskie, kod źródłowy i współpraca z obecnymi wykonawcami
Czy Zamawiający posiada majątkowe prawa autorskie do kodu źródłowego rozbudowywanych
systemów (aplikacja mobilna „JADĘ RZESZÓW”, Portal Pasażera, e-Sklep, FCS, Serwer Kontroli,
Hurtownia Biletów, SRSB, oprogramowanie biletomatów, kasowników i urządzeń kontrolerskich)?
Zamawiający nie posiada majątkowych praw autorskich do kodu źródłowego
rozbudowywanych systemów. Wykonawca jest zobowiązany do pozyskania we własnym zakresie
zgód i licencji umożliwiających rozbudowę lub majątkowych praw autorskich koniecznych do
przeprowadzenia rozbudowy w ramach niniejszego postępowania.
2Prawa autorskie, kod źródłowy i współpraca z obecnymi wykonawcami
Czy Zamawiający udostępni Wykonawcy kod źródłowy, repozytoria, dane dostępowe oraz
środowiska (dev/test/prod) niezbędne do rozbudowy? Jeśli tak - na jakim etapie i w jakiej formie?
Zamawiający nie udostępni kodów źródłowych ani repozytoriów, których nie posiada.
Dostęp do zasobów pozostających w dyspozycji podmiotów trzecich Wykonawca zapewnia we
własnym zakresie. Zamawiający udostępni Wykonawcy dane, informacje i dostępy pozostające w
wyłącznej dyspozycji Zamawiającego, niezbędne do realizacji przedmiotu zamówienia, na etapie
realizacji umowy, w zakresie i terminie wynikającym z potrzeb realizacyjnych. Sposób ich
przekazania lub udostępnienia będzie każdorazowo dostosowany do charakteru danego zasobu.
Środowiska deweloperskie i testowe niezbędne do realizacji prac Wykonawca zapewnia we własnym
zakresie.
3Prawa autorskie, kod źródłowy i współpraca z obecnymi wykonawcami
Kto jest obecnym producentem/autorem poszczególnych systemów? Czy ci sami dostawcy nadal je
serwisują?
Producentami/autorami poszczególnych systemów są:
aplikacja mobilna „JADĘ RZESZÓW" - Asseco Data System S.A.,
Portal Pasażera / e-Sklep - Asseco Data System S.A.,
FCS — SOLVEO Sp. z 0.0.,
Serwer Kontroli - SOLVEO Sp. z 0.0., R&G Plus Sp. z 0.0.,
Hurtownia Biletów - SOLVEO Sp. z 0.0.,
SRSB — SOLVEO Sp. z 0.0., Mera Systemy Sp. z 0.0.,
Centralny system sprzedażowy - R&G Plus Sp. z 0.0.,
oprogramowanie biletomatów — Mera Systemy Sp. z 0.0., Merona Poland Sp. z 0.0.,
oprogramowanie kasowników — R&G Plus Sp. z 0.0.,
aplikacja na urządzeniach kontrolerskich — eService Sp. z 0.0.,
system płatności elektronicznych i rozliczeń — eService Sp. z 0.0., payU S.A.
Systemy są serwisowane przez tych samych dostawców, z wyjątkiem Merona Poland Sp. z 0.0.
4Prawa autorskie, kod źródłowy i współpraca z obecnymi wykonawcami
Czy do realizacji zamówienia wymagana/przewidywana jest współpraca z obecnymi wykonawcami
systemów autonomicznych (np. System Karty Mieszkańca, operator płatności)? Czy Zamawiający
zapewni pośrednictwo i dostęp do ich API?
Realizacja przedmiotu zamówienia wymaga współpracy z podmiotami będącymi
producentami lub dostawcami istniejących systemów. Wykonawca zobowiązany jest we własnym
zakresie zapewnić współpracę z tymi podmiotami w zakresie niezbędnym do realizacji wymaganych
rozbudów i integracji. Zamawiający nie zapewnia pośrednictwa w relacjach z podmiotami
zewnętrznymi ani dostępu do zasobów pozostających wyłącznie w ich dyspozycji.
5Prawa autorskie, kod źródłowy i współpraca z obecnymi wykonawcami
Czy w obecnych systemach wykorzystywane są komponenty/biblioteki firm trzecich lub licencje,
które ograniczają możliwość modyfikacji kodu? Jeśli tak - jakie?
W istniejących systemach wykorzystywane są komponenty i biblioteki, do których
prawa przysługują producentom systemów lub innym podmiotom trzecim. Zamawiający nie
dysponuje kompletnym wykazem tych komponentów i bibliotek ani pełną informacją o
ograniczeniach licencyjnych dotyczących możliwości ich modyfikacji. Pozyskanie informacji oraz
uprawnień niezbędnych do realizacji przedmiotu zamówienia należy do obowiązków Wykonawcy, z
zastrzeżeniem danych, których wyłącznym dysponentem jest ZTM, zgodnie z $4 ust.2
projektowanych postanowień umowy.
4Prawa autorskie, kod źródłowy i współpraca z obecnymi wykonawcami
Czy do realizacji zamówienia wymagana/przewidywana jest współpraca z obecnymi wykonawcami
systemów autonomicznych (np. System Karty Mieszkańca, operator płatności)? Czy Zamawiający
zapewni pośrednictwo i dostęp do ich API?
Realizacja przedmiotu zamówienia wymaga współpracy z podmiotami będącymi
producentami lub dostawcami istniejących systemów. Wykonawca zobowiązany jest we własnym
zakresie zapewnić współpracę z tymi podmiotami w zakresie niezbędnym do realizacji wymaganych
rozbudów i integracji. Zamawiający nie zapewnia pośrednictwa w relacjach z podmiotami
zewnętrznymi ani dostępu do zasobów pozostających wyłącznie w ich dyspozycji.
6Prawa autorskie, kod źródłowy i współpraca z obecnymi wykonawcami
Na czyich kontach deweloperskich publikowana jest aplikacja mobilna w Google Play i App Store
(Zamawiającego czy dotychczasowego wykonawcy)? Kto będzie właścicielem kont po realizacji?
Aplikacja mobilna jest publikowana na kontach developerskich producentów tych
systemów. Zamawiający nie przewiduje żadnych zmian w tym zakresie po realizacji zamówienia.
7Prawa autorskie, kod źródłowy i współpraca z obecnymi wykonawcami
Jakie prawa do nowo wytworzonego oprogramowania Zamawiający wymaga przenieść (pełne
majątkowe prawa autorskie, licencja, kod źródłowy, depozyt kodu)? Czy jest to opisane w projekcie
umowy?
Zasady dotyczące praw do nowo wytworzonego oprogramowania, przeniesienia
autorskich praw majątkowych, udzielania licencji oraz przekazania kodów źródłowych zostały
określone w $4 ust. 10 oraz $7 projektowanych postanowień umowy.
8Technologia i architektura systemów istniejących
W jakich technologiach (języki, frameworki, bazy danych) wykonane są poszczególne
rozbudowywane systemy?
Rozbudowywane systemy wykorzystują w szczególności technologie: PHP, CSS,
JavaScript, Java, Sencha, Node.js, .NET, SQL Server oraz PostgreSQL.
9Technologia i architektura systemów istniejących
Czy aplikacja mobilna „JADĘ RZESZÓW” jest napisana natywnie (Android/iOS osobno), czy w
technologii wieloplatformowej (np. Flutter, React Native)? Jakie minimalne wspierane wersje
systemów mobilnych?
Aplikacja „JADĘ RZESZÓW” jest wykonana natywnie, odrębnie dla systemów
Android i iOS. Minimalne obecnie wspierane wersje systemów to Android 10 oraz iOS 16.
10Technologia i architektura systemów istniejących
Jaka jest architektura backendu (monolit / mikrousługi), gdzie jest hostowany obecnie (on-premises
czy chmura), i czy po dostawie nowych serwerów całość ma zostać przeniesiona do infrastruktury
Zamawiającego?
Obecna architektura backendu ma charakter monolityczny i jest utrzymywana w
infrastrukturze producenta systemu. Zamawiający nie posiada informacji pozwalających na
jednoznaczne określenie modelu infrastruktury producenta jako on-premises lub chmurowej.
Zamawiający nie przewiduje obowiązku przeniesienia całego backendu do _ infrastruktury
Zamawiającego po dostawie nowych serwerów. Jednocześnie docelowe rozwiązanie musi spełniać
wymagania dokumentacji postępowania, w tym $ 4 ust. 11 projektowanych postanowień umowy
dotyczący miejsca przechowywania danych na serwerach zamawiającego.
11Technologia i architektura systemów istniejących
Czy istnieje aktualna dokumentacja techniczna, architektura systemów, opis API oraz modeli
danych? Czy zostanie udostępniona na etapie postępowania lub po podpisaniu umowy?
Zamawiający nie dysponuje kompletną dokumentacją techniczną obejmującą
architekturę wszystkich systemów, pełny opis interfejsów/API oraz modeli danych. Dokumentacja
pozostająca w dyspozycji Zamawiającego zostanie udostępniona Wykonawcy na etapie realizacji
umowy, w zakresie niezbędnym do realizacji przedmiotu zamówienia.
12Technologia i architektura systemów istniejących
Jakie interfejsy/API udostępniają systemy centralne (FCS, Serwer Kontroli, HB) i systemy
zewnętrzne, z którymi wymagana jest integracja? Czy dostępne są ich specyfikacje?
Zamawiający nie dysponuje kompletnym wykazem istniejących interfejs6w/API ani
pełną dokumentacją ich specyfikacji. W ramach realizacji integracji Wykonawca zobowiązany jest
do rozbudowy systemów centralnych w zakresie niezbędnym do wykonania integracji wskazanych
w OPZ, w tym do wykonania odpowiednich interfejséw/API, jeżeli będą one niezbędne do realizacji
wymaganej wymiany danych.
13Technologia i architektura systemów istniejących
Jakie są obecne wolumeny (liczba kont pasażerów, transakcji dziennie/miesięcznie, szczyty ruchu),
aby prawidłowo zwymiarować rozbudowę i wydajność?
Aktualna liczba kont pasażerów wynosi około 40 000, natomiast roczna liczba
transakcji wynosi około 300 000. Zamawiający nie dysponuje zestawieniem średnich wolumenów
dziennych i miesięcznych ani odrębnymi danymi dotyczącymi szczytów ruchu.
14Zakres i sposób doprecyzowania prac programistycznych
OPZ określa wyłącznie wymagania funkcjonalne, a szczegółowe parametry mają zostać ustalone na
etapie analizy wymagań i projektu wykonawczego. W jaki sposób i w jakim terminie będą one
doprecyzowywane, skoro cena oferty jest składana wcześniej?
Sposób doprecyzowania szczegółowych parametrów funkcjonalności został określony
w pkt 3.1 oraz w pkt 4 OPZ. Wykonawca powinien skalkulować ofertę na podstawie minimalnego
zakresu funkcjonalnego określonego w OPZ z uwzględnieniem obowiązku przeprowadzenia
szczegółowej analizy wymagań i opracowania projektu wykonawczego.
15Zakres i sposób doprecyzowania prac programistycznych
Czy przez „rozbudowę” Zamawiający rozumie wyłącznie modyfikację istniejącego kodu, czy
dopuszcza wymianę/przebudowę wybranych modułów na nowe rozwiązania równoważne
funkcjonalnie?
Przez rozbudowę Zamawiający rozumie wykonanie prac niezbędnych do osiągnięcia
funkcjonalności określonych w OPZ, obejmujących zarówno modyfikację istniejących elementów
systemów, jak również zastosowanie nowych komponentów, jeżeli jest to niezbędne do osiągnięcia
wymaganych funkcjonalności.
16Zakres i sposób doprecyzowania prac programistycznych
Jak zostanie rozstrzygnięta sytuacja, w której wymagania doprecyzowane na etapie analizy wykroczą
poza zakres funkcjonalny opisany w OPZ - czy przewidziano tryb zmiany umowy/wynagrodzenia?
Analiza wymagań i projekt wykonawczy służą określeniu sposobu realizacji wymagań
zawartych w dokumentach zamówienia i nie mogą stanowić podstawy do rozszerzenia przedmiotu
zamówienia poza zakres określony w SWZ, OPZ i projektowanych postanowieniach umowy. Zmiany
umowy mogą następować wyłącznie na zasadach określonych w projektowanych postanowieniach
umowy i przepisach ustawy Pzp.
17Zakres i sposób doprecyzowania prac programistycznych
Czy Zamawiający dysponuje makietami, projektami UX/UI lub wytycznymi wizualnymi dla nowych
funkcjonalności, czy ich opracowanie jest po stronie Wykonawcy?
Zamawiający nie dysponuje gotowymi makietami ani projektami UX/UI dla nowych
funkcjonalności. Ich opracowanie należy do Wykonawcy. Projekty podlegają uzgodnieniu i
akceptacji Zamawiającego na etapie projektowania.
Historia zmian
07.07.2026 — ogłoszenie o zamówieniu
16.07.2026 — sprostowanie
31.07.2026 — sprostowanie
05.08.2026 — modyfikacja dokumentacji (3 modyfikacje dokumentacji)
06.08.2026 — sprostowanie
12.08.2026 — upływ terminu składania ofert
14.08.2026 — sprostowanie
21.08.2026 — sprostowanie
26.08.2026 — sprostowanie