Finansowanie: Projekt „Rozwój zrównoważonej mobilności miejskiej na terenie ROF" (FEPW 2021-2027), nr FEPW.03.01-IP.01-0005/25, dofinansowany przez PARP/UE.
5
Terminy
Widoczne 50%
Termin składania ofert:8 września 2026 r., godz. 10:00 (modyfikacja z 13.08.2026) (termin zaktualizowany przez zamawiającego — pierwotna dokumentacja podawała 26 sierpnia 2026)
Doświadczenie (zdolność techniczna): min. 1 zamówienie na wykonanie i wdrożenie systemu biletu elektronicznego z aplikacją mobilną (identyfikator biletów: aplikacje mobilne i karty płatnicze) zintegrowanego z portalem pasażera, biletomatami, aplikacją mobilną i systemem kontroli biletów, wartości brutto ≥ 1 400 000,00 zł, wykonane w ostatnich 3 latach (lub w krótszym okresie działalności); w przypadku świadczeń powtarzających się lub ciągłych dopuszczalne zamówienia nadal wykonywane; jeden wykonawca/konsorcjant musi spełnić warunek samodzielnie, nie sumuje się doświadczenia podmiotów.
7
Kryteria oceny ofert
Pełna treść
Cena oferty brutto: waga 100% (wzór: P1 = Cn/Cb × 100 × 100%, ocena do dwóch miejsc po przzecinku).
8
Kary i sankcje
Pełna treść
Zabezpieczenie należytego wykonania:5% ceny brutto; 30% kwoty na roszczenia z tytułu rękojmi/gwarancji (zmiana z 24.07.2026). - Kary umowne: w projektowanych postanowieniach umowy (załącznik do SWZ).
9
Inne zapisy
Widoczne 50%
Realizacja: do 180 dni od dnia podpisania umowy.
Gwarancja i rękojmia:60 miesięcy na cały przedmiot zamówienia.
Rozwiązania równoważne: dopuszczone; dla Microsoft RDS User CAL w Formularzu OFERTA wskazać produkt równoważny i dołączyć środki dowodowe.
Wykluczenie ICT: zakaz produktów/usług/procesów ICT z rekomendacji art. 33 ust. 4 ustawy o KSC oraz dostawców wysokiego ryzyka (art. 67b ust. 15).
Z każdej z 10 sekcji pokazujemy połowę. Załóż darmowe konto, żeby odsłonić pozostałe 14 zdań — pełne warunki udziału, dokumenty i analizę ryzyka Janusza. Bez karty, 14 dni za darmo.
14 dni za darmo Bez karty płatniczej Rezygnacja w 1 klik
Opis przedmiotu zamówienia
Streszczenie AI · Janusz
Rozbudowa i integracja systemu elektronicznego poboru opłat w Zarządzie Transportu Miejskiego w Rzeszowie (jedno zamówienie, bez podziału na części), obejmująca:
rozbudowę systemów centralnych (FCS, Serwer Kontroli, Hurtownia Biletów, systemy rozliczeń),
rozbudowę aplikacji mobilnej „JADĘ RZESZÓW" (Android/iOS) o planer podróży, widżety, rozkłady jazdy, model Check-In/Check-Out, rozliczanie Fare Capping z preautoryzacją karty, obsługę spraw do BOK, historię transakcji, integrację z Krajowym Węzłem Identyfikacji Elektronicznej, dostępność WCAG 2.2 AA,
rozbudowę oprogramowania biletomatów (ok. 51 stacjonarnych + 211 mobilnych istniejących),
rozbudowę oprogramowania urządzeń kontrolerskich (20 szt.) i kasowników (ok. 969 szt.),
integrację systemów (mobilna↔FCS, Serwer Kontroli↔kasowniki/urządzenia kontrolerskie, biletomaty↔e-Sklep, Portal↔Karta Mieszkańca),
dostawę i uruchomienie infrastruktury teleinformatycznej: 4 serwery rackowe wysokiej wydajności, 1 urządzenie zabezpieczające sieć (Firewall/UTM), 1 usługa konfiguracji i migracji firewalla, 16 licencji systemu operacyjnego serwerowego (klasa Datacenter, Windows Server 2025), 1 usługa konfiguracji i migracji środowiska wirtualizacyjnego, 150 licencji dostępowych użytkownika, 40 licencji zdalnego dostępu RDS User CAL, 2 licencje bazy danych klasy MS SQL Server Standard 2025,
dokumentację powykonawczą, projekt wykonawczy w UML, audyt dostępności WCAG.
Pytania i odpowiedzi
Wyjaśnienia treści SWZ udzielone przez zamawiającego. Odpowiedzi wiążą wszystkich wykonawców — także tych, którzy nie zadali pytania.
Prawa 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.
[brak pytań w dokumencie]
[dokument zawiera zmiany treści SWZ, brak pytań i odpowiedzi]
Prawa 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.
Prawa 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.
Prawa 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.
Prawa 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.
Prawa 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.
Prawa 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.
Technologia 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.
Technologia 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.
Technologia 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.
Technologia 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.
Technologia 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.
Technologia 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.
Zakres 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.
Zakres 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.
Zakres 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.
Zakres 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.
Zakres i sposób doprecyzowania prac programistycznych
Czy Wykonawca odpowiada również za dostosowanie/rozbudowę systemów centralnych (FCS,
Serwer Kontroli, HB), czy tylko za warstwy klienckie (aplikacja, portal, e-Sklep, biletomaty,
kasowniki, urządzenia kontrolerskie)?
Zakres obowiązków Wykonawcy dotyczący rozbudowy systemów centralnych oraz
pozostałych elementów rozwiązania został określony w $ 2 ust. 2 projektowanych postanowień
umowy oraz w pkt 4 OPZ.
Backlog, stan realizacji i prace w toku
Czy istnieje backlog prac, lista znanych błędów lub rejestr zgłoszeń, które mają zostać zrealizowane
w ramach zamówienia? Jeśli tak - czy zostanie udostępniony?
Zamawiający nie posiada backlogu prac ani rejestru znanych błędów dotyczącego
zakresu objętego niniejszym zamówieniem.
Pokazujemy 20 z 24 pytań. Komplet wyjaśnień — razem z załącznikami, których dotyczą — jest w dokumentacji postępowania.
