Po terminiePrzetarg nieograniczony · PN526476-2026
Cyfryzacja procesów i e-usług publicznych – Katowice
Miejski Zarząd Ulic i Mostów w Katowicach9 aktualnych · 182 w archiwum·NIP 6340008185·śląskie
Przedmiot zamówienia
AIZamówienie obejmuje cyfryzację procesów back-office oraz e-administracji, digitalizację danych przestrzennych dróg publicznych, zakup i wdrożenie systemu teleinformatycznego smart city, opracowanie rozwiązań geoinformacyjnych z interoperacyjnością oraz zapewnienie zgodności z cyberbezpieczeństwem i ochroną danych osobowych.
Trudność: wysoka
Zamówienie obejmuje złożone integracje IT, dane przestrzenne, cyberbezpieczeństwo i zgodność z RODO w kontekście smart city.
Czerwone flagi
AISygnały, na które warto zwrócić uwagę przed startem.
Termin składania ofert przypada na okres wakacyjny (11 sierpnia)
Termin w okresie wakacyjnym (lipiec-sierpień) może ograniczać liczbę oferentów ze względu na urlopy.
Pytania i odpowiedzi
81Wyodrębnione z wyjaśnień treści SWZ.
11. Nieproporcjonalny i nadmiarowy zakres OPZ- OPZ opisuje bardzo szeroki zakres wymagań obejmujący jednocześnie system dziedzinowy, platformę e-usług, narzędzia klasy GIS, narzędzia raportowe klasy BI, aplikację desktop, integracje z nieokreślonym systemem EOD, moduły utrzymaniowe, mobilne, analityczne, dendrologiczne oraz rozwojowe. Zamawiający nie rozróżnił funkcjonalności niezbędnych do uruchomienia e-usług i cyfrowej pracy wewnętrznej, funkcjonalności przydatnych, ale możliwych do realizacji w późniejszych etapach, funkcjonalności eksperckich możliwych do realizacji przez odrębne narzędzia GIS, BI lub narzędzia open source, oraz usług dodatkowych, które powinny stanowić zakres opcjonalny albo odrębne zamówienie.
Czy Zamawiający dokona modyfikacji OPZ przez ograniczenie wymagań do funkcjonalności koniecznych dla realizacji e-usług, prowadzenia ewidencji dróg, zarządzania infrastrukturą drogową, prezentacji danych przestrzennych, fotorejestracji i chmury punktów 3D, z jednoczesnym przeniesieniem funkcjonalności dodatkowych, rozwojowych i eksperckich do zakresu opcjonalnego oraz opisanie wymagań poprzez oczekiwane rezultaty, a nie przez narzucanie określonej architektury lub sposobu wykonania?
Zamawiający pozostawia zapisy bez zmian. Po pierwsze, Zamawiający – działając na podstawie art. 99 ust. 1 i 2 ustawy Pzp – jest uprawniony do opisania przedmiotu zamówienia z uwzględnieniem wszystkich wymagań niezbędnych z punktu widzenia własnych potrzeb. Prawo zamówień publicznych zakazuje opisu utrudniającego uczciwą konkurencję (art. 99 ust. 4 ustawy Pzp), nie zaś opisu obszernego lub precyzyjnego. Wielomodułowość OPZ wynika z wielości realizowanych e-usług publicznych i złożoności ustawowych obowiązków zarządcy drogi, nie zaś z arbitralnych decyzji Zamawiającego.
Po drugie, zakres OPZ pozostaje w bezpośrednim i nierozerwalnym związku z celami projektu, tj. wdrożeniem 22 e-usług publicznych na 5. poziomie dojrzałości. Jak wskazuje OPZ (pkt 3.2.2), „Procesowanie spraw, dla których zostaną wytworzone e-usługi w Miejskim Zarządzie Ulic i Mostów w Katowicach jest niemożliwe bez dostępu do aktualnej informacji o majątku drogowym, danych zawartych w bazie ewidencji gruntów i budynków oraz związanych z nim procesach."
Po trzecie, zakres zamówienia jest wynikiem prac zespołu roboczego Zamawiającego powołanego do opracowania OPZ. Potrzeby Zamawiającego w zakresie zarządzania infrastrukturą drogową wynikają z licznych wymagań prawa dziedzinowego, w tym z rozporządzeń dotyczących ewidencji dróg i obiektów mostowych, organizacji ruchu drogowego, geodezji i kartografii oraz przepisów prawa.
22. Nieokreślony system EOD/EZD do integracji (pkt 7.10.4 OPZ)- Zgodnie z pkt 7.10.4 OPZ wymagana jest integracja platformy z elektronicznym obiegiem dokumentów. Jednocześnie Zamawiający nie wskazał jednoznacznie, z jakim systemem EOD/EZD ma zostać wykonana integracja – dokumentacja wskazuje, że Zamawiający rozważa system eDokument firmy Rekord, system EOD firmy Finn Sp. z o.o. albo EZD RP, a decyzja zostanie podjęta nie później niż w połowie terminu realizacji projektu. Zakres prac integracyjnych, koszty, wymagania techniczne oraz ryzyka zależą w całości od konkretnego systemu, jego dokumentacji API, dostępności środowiska testowego i wsparcia producenta. Wykonawca nie jest w stanie rzetelnie wycenić integracji z systemem, który nie jest znany na etapie składania ofert. Czy Zamawiający nada pkt 7.10.4 OPZ brzmienie wskazujące konkretny system EOD/EZD, z którym ma zostać wykonana integracja, z zapewnieniem udostępnienia dokumentacji API, środowiska testowego, kont technicznych i wsparcia producenta systemu EOD/EZD, a ewentualną integrację z innym systemem wydzieli jako zakres opcjonalny lub odrębne zamówienie: „Integracja platformy z elektronicznym obiegiem dokumentów zostanie wykonana z systemem [nazwa systemu], wykorzystywanym przez Zamawiającego na dzień składania ofert. Zamawiający udostępni wykonawcy aktualną dokumentację API, środowisko testowe, konta techniczne, osobę odpowiedzialną za integrację oraz zapewni współpracę producenta systemu EOD/EZD, jeżeli będzie ona konieczna do wykonania integracji. W przypadku zmiany systemu EOD/EZD po terminie składania ofert integracja z nowym systemem nie stanowi zakresu podstawowego zamówienia i może zostać zlecona jako zakres opcjonalny albo odrębne zamówienie, po uzgodnieniu zakresu technicznego, harmonogramu oraz wynagrodzenia.”
Zamawiający doprecyzowuje treść pkt 7.10.4 Opisu Przedmiotu Zamówienia następująco:
W pkt 7.10.4 OPZ
Jest: „Obecnie Zamawiający posiada system eDokument formy Rekord, w trakcie realizacji projektu nie później niż w połowie terminu jego realizacji Zamawiający poinformuje Wykonawcę z jakim systemem EOD ma zintegrować się system dziedzinowy. Zamawiający rozważa wdrożenie systemu EOD firmy Finn Sp. z o.o. lub EZD RP.”
Powinno być: „Obecnie Zamawiający posiada system eDokument formy Rekord, w trakcie realizacji projektu nie później niż w połowie terminu jego realizacji Zamawiający planuje integrację z systemem EZD FINN firmy LTC. Zamawiający wskazuje jako jedyny docelowy system integracji EZD FINN firmy LTC.”
33. Wymóg pełnej aplikacji desktop Windows (pkt 8.26.1 OPZ)- Punkt 8.26.1 OPZ wymaga dostarczenia pełnej aplikacji desktop pracującej pod kontrolą systemu Windows, posiadającej wszystkie aplikacje dziedzinowe jak dla wersji przeglądarkowej. OPZ jednocześnie opisuje system jako nowoczesną platformę webową dostępną przez przeglądarkę. Wymóg ten powoduje konieczność zdublowania bardzo dużej części funkcjonalności systemu w osobnym komponencie desktopowym, jest nadmiernie kosztotwórczy oraz preferuje wykonawców dysponujących rozwiązaniami desktopowymi, ograniczając udział wykonawców oferujących nowoczesne rozwiązania webowe. Zamawiający nie wykazał, jakie konkretne procesy wymagają pełnej aplikacji desktop ani dlaczego nie mogą być obsługiwane przez system webowy, aplikację mobilną, standardowe formaty wymiany danych, API lub powszechnie dostępne narzędzia GIS.
Czy Zamawiający usunie pkt 8.26.1 OPZ albo nada mu brzmienie dopuszczające realizację funkcji dziedzinowych w aplikacji przeglądarkowej, z zapewnieniem dostępu do danych GIS, fotorejestracji sferycznej i chmury punktów 3D poprzez standardowe formaty i usługi (API, WMS/WFS, SHP/GPKG/DXF/LAS/LAZ): „Zamawiający dopuszcza realizację funkcji dziedzinowych systemu w aplikacji przeglądarkowej. W zakresie pracy eksperckiej na danych GIS, fotorejestracji sferycznej i chmurze punktów 3D wykonawca zapewni możliwość dostępu, eksportu lub podłączenia danych w standardowych formatach i usługach, w szczególności poprzez API, WMS/WFS, pliki SHP/GPKG/DXF/LAS/LAZ lub inne formaty uzgodnione z Zamawiającym, umożliwiające wykorzystanie danych w narzędziach GIS, w tym narzędziach desktop GIS.”
Zamawiający w pkt. 8.26.1 dodaje zapis po ppkt. 16 o treści: „ Zamawiający dopuszcza realizację wymaganej funkcjonalności aplikacji desktop jako funkcjonalności systemu uruchamianej za pomocą przeglądarki internetowej, pod warunkiem spełnienia przez takie rozwiązanie wszystkich wymagań funkcjonalnych opisanych w wyżej wymienionych punktach”.
44. Nadmierne wymagania dotyczące kreatora raportów i analiz przestrzennych (pkt 8.2 OPZ) - Punkt 8.2 OPZ przewiduje wymóg kreatora raportów i analiz przestrzennych obejmującego dostęp do pełnego modelu danych systemu, wybór dowolnych tabel i encji, definiowanie relacji JOIN przez użytkownika końcowego, budowanie złożonych warunków logicznych, pola obliczeniowe, agregacje, wykorzystanie raportu jako źródła kolejnego raportu oraz relacje topologiczne, bufory i filtry LRS. Taki zakres właściwy jest dla uniwersalnego narzędzia klasy BI/GIS, a nie dla systemu dziedzinowego zarządzania infrastrukturą drogową. Użytkownicy Zamawiającego potrzebują raportów dziedzinowych, list, filtrów, eksportów i zdefiniowanych raportów przekrojowych, a nie budowy złożonych relacji JOIN przez użytkownika końcowego pomiędzy dowolnymi tabelami systemu.
Czy Zamawiający zmieni pkt 8.2 OPZ przez nadanie mu następującego brzmienia: „Zamawiający dopuszcza realizację funkcji dziedzinowych systemu w aplikacji przeglądarkowej. W zakresie pracy eksperckiej na danych GIS, fotorejestracji sferycznej i chmurze punktów 3D wykonawca zapewni możliwość dostępu, eksportu lub podłączenia danych w standardowych formatach i usługach, w szczególności poprzez API, WMS/WFS, pliki SHP/GPKG/DXF/LAS/LAZ lub inne formaty uzgodnione z Zamawiającym, umożliwiające wykorzystanie danych w narzędziach GIS, w tym narzędziach desktop GIS.”
Zamawiający pozostawia zapis bez zmian. Zakres wymagań modułu raportów i statystyk (OPZ pkt 8.2) wynika z rzeczywistych potrzeb operacyjnych Miejskiego Zarządu Ulic i Mostów w Katowicach jako zarządcy dróg i był kształtowany przez powołany przez Zamawiającego zespół specjalistów merytorycznych. Wymagania te nie tworzą narzędzia klasy BI ani GIS, lecz stanowią zaawansowany, lecz typowy dla systemów zarządzania infrastrukturą drogową moduł raportowy operujący wyłącznie na danych własnych systemu dziedzinowego.
Wizualny kreator zapytań umożliwiający budowanie raportów bez znajomości SQL, dostęp do pełnego modelu danych systemu, filtry przestrzenne oparte na relacjach topologicznych ISO 19125, operatory pikietażowe LRS oraz agregacje statystyczne są funkcjonalnościami spotykalnymi w dojrzałych, dostępnych rynkowo systemach klasy zarządzania infrastrukturą drogową. Zamawiający nie wymaga integracji zewnętrznego narzędzia analitycznego – wszystkie opisane operacje mają dotyczyć danych zgromadzonych w ramach jednej platformy dziedzinowej, co eliminuje potrzebę dodatkowej warstwy semantycznej.
Wymagania przestrzenne – w tym relacje topologiczne i filtry LRS – są nierozerwalnie związane z charakterem zamówienia. Zarządzanie infrastrukturą drogową jest z natury zadaniem przestrzennym, a analiza zdarzeń i procesów w oparciu o kilometraż, stronę drogi, odległość od osi drogi czy relacje topologiczne obiektów stanowi podstawę codziennej pracy zarządcy drogi..
OPZ pkt 8.2 poz. 15 zawiera zamknięty katalog 38 standardowych raportów dziedzinowych do wygenerowania podczas wdrożenia. Każdy z tych raportów odpowiada konkretnym obowiązkom prawnym lub operacyjnym zarządcy drogi. Kreator raportów (poz. 21) umożliwia generowanie raportów niestandardowych wynikających z bieżących potrzeb i zmian przepisów, co jest uzasadnione wieloletnim cyklem eksploatacji systemu.
Historia zmian
17.06.2026 — ogłoszenie o zamówieniu
21.07.2026 — sprostowanie
30.07.2026 — sprostowanie
10.08.2026 — sprostowanie
11.08.2026 — upływ terminu składania ofert
20.08.2026 — sprostowanie