Budowa i modernizacja platform informatycznych – Łódź

Źródła danych przewidziane do migracji podane są w załączniku nr 2 do OPZ RSIP WŁ– „Pozyskanie danych do systemu RSIP WŁ”. Jednocześnie Zamawiający informuje, że wyjaśnienia dotyczące migracji danych zostały umieszczone w odpowiedziach na pytania 6, 10-25, 28 z zestawu 2 zamieszczonych na stronie prowadzonego postępowania w dniu 25.06.2026 r.

Wykonawca opracuje harmonogram szczegółowy prac, według którego będą realizowane etapy prac i przypisane im zadania. W oparciu o harmonogram Wykonawca ustali z Zamawiającym datę przekazania niezbędnych danych do realizacji e-usług tak, aby zadanie mogło być zrealizowane w terminie.

Zamawiający przyjmuje, że dane przekazane Wykonawcy będą poprawne merytorycznie. Dokładny zakres odpowiedzialności Wykonawcy opisany jest w odpowiedzi udzielonej do pytania 6 (zestaw 2) zamieszczonej na stronie prowadzonego postępowania w dniu 25.06.2026 r. Ponadto według załącznika nr 2 do OPZ RSIP WŁ – „Pozyskanie danych do systemu RSIP WŁ” Wykonawca zobowiązany jest do przeprowadzenia migracji próbnej, której celem jest identyfikacja błędów i niezgodności oraz migracja właściwa.

Dane pozyskane według wytycznych z załącznika nr 2 „Pozyskanie danych do systemu” do OPZ RSIP WŁ będą podlegały odbiorowi zgodnie ze sporządzonym przez Wykonawcę i zaakceptowanym przez Zamawiającego harmonogramem szczegółowym realizacji przedmiotu zamówienia. Jednocześnie Zamawiający przypomina, że harmonogram szczegółowy ma uwzględniać terminy realizacji prac podane w rozdziale 18 OPZ RSIP WŁ.

Zamawiający informuje, że systemy, z którymi RSIP będzie integrowany, zostały jednoznacznie wskazane w rozdziale 8.6 (Integracja z systemami zewnętrznymi) dokumentu „Załącznik nr 1 do UMOWY - OPZ RSIP WŁ”. Odnosząc się do drugiej części pytania, Zamawiający wyjaśnia, że określenie dokładnego statusu, dostępności oraz szczegółowej specyfikacji technicznej interfejsów API dla wskazanych systemów stanowi integralną część prac analityczno-projektowych leżących po stronie Wykonawcy. To w ramach opracowywania dokumentacji analitycznej i technicznej Wykonawca ma za zadanie zweryfikować stan interfejsów, zaprojektować docelową architekturę i dobrać odpowiednie mechanizmy komunikacji. W związku z tym Zamawiający nie przekazuje na obecnym etapie dodatkowych zestawień dotyczących statusu poszczególnych API. Jednocześnie Zamawiający odsyła do odpowiedzi na pytanie 6 zestaw 3 zamieszczonej na stronie prowadzonego postępowania w dniu 25.06.2026 r., w której napisano, że w ramach systemu EZD RP NASK dostarczył ujednolicony interfejs programistyczny API EZD RP i że API EZD RP dostępne jest publicznie a przykłady użycia metod opisane są na stronie https://podrecznik.ezdrp.gov.pl/przyklady-uzycia-metod-api-ezd-rp/.

Zamawiający informuje, że posiada dokumentację techniczną istniejącego systemu RSIP WŁ. Z uwagi na bezpieczeństwo infrastruktury, przedmiotowa dokumentacja zostanie udostępniona wyłącznie Wykonawcy wyłonionemu w postępowaniu, niezwłocznie po podpisaniu umowy. Jednocześnie Zamawiający przypomina, że udostępniona dokumentacja będzie stanowić jedynie materiał wyjściowy. Zgodnie z wymaganiami określonymi w dokumencie „Załącznik nr 1 do UMOWY - OPZ RSIP WŁ”, po stronie Wykonawcy leży przeprowadzenie analizy rozwiązania wraz z opracowaniem docelowej dokumentacji analitycznej i technicznej (rozdział 14 pkt.14.1). W ramach tych prac Wykonawca jest bezwzględnie zobowiązany do samodzielnego przeprowadzenia inwentaryzacji i weryfikacji rzeczywistego stanu infrastruktury oraz komponentów (tzw. analiza stanu "as-is", polegająca na szczegółowym zbadaniu i udokumentowaniu aktualnego stanu środowiska przed wprowadzeniem jakichkolwiek zmian). Ewentualne rozbieżności między przekazaną dokumentacją historyczną a stanem faktycznym ustalonym podczas inwentaryzacji nie mogą stanowić podstawy do roszczeń, a ostateczna dokumentacja projektowa musi zostać opracowana na podstawie zweryfikowanego stanu rzeczywistego.

Zamawiający informuje, że nie gwarantuje zapewnienia środowisk testowych dla jakichkolwiek systemów zewnętrznych podlegających integracji. Przez „systemy zewnętrzne” Zamawiający rozumie zarówno systemy należące do podmiotów trzecich, jak i odrębne systemy udostępniające e-usługi/dane, które są utrzymywane przez samego Zamawiającego. Zamawiający udostępni środowiska testowe własnych systemów wyłącznie w sytuacji, gdy takowymi dedykowanymi środowiskami dysponuje. W pozostałych przypadkach (w tym dla wszystkich systemów podmiotów trzecich), zgodnie z dobrymi praktykami inżynierii oprogramowania, przygotowanie i utrzymanie odpowiedniego środowiska testowego – w tym stworzenie na własny koszt odpowiednich symulatorów usług niezbędnych do przeprowadzenia testów przedwdrożeniowych – leży w całości po stronie Wykonawcy. W uzasadnionych przypadkach, za uprzednią zgodą Zamawiającego, dopuszcza się ostrożne przeprowadzenie testów integracyjnych z wykorzystaniem bezpiecznego dostępu do usług produkcyjnych, wyłącznie w trybie odczytu i w zakresie niepowodującym żadnego wpływu na ciągłość i stabilność ich działania.

Zamawiający nie przewiduje nieterminowego przekazania danych, dokumentów, decyzji lub dostępów przez Zamawiającego skutkują automatycznym przesunięciem terminów realizacji odpowiednich etapów. Wykonawca jako profesjonalny podmiot zobowiązany jest do wcześniejszego o nie wystąpienia.

Jeżeli produkty zostaną przekazane w terminie oraz ewentualne uwagi zgłoszone przez Zamawiającego też zostaną poprawione w terminie, nie zostaną wliczane opóźnienia, pod warunkiem, że zostaną zachowane i uwzględnione zapisy OPZ RSIP WŁ. Wykonawca opracowując szczegółowy harmonogram realizacji przedmiotu zamówienia musi uwzględnić czas na przygotowanie dokumentów oraz terminy dwóch iteracji przekazania i weryfikacji przez Zamawiającego wszystkich produktów (zgodne z przyjętym czasem na weryfikację Zamawiającego opisanym w rozdziale 17.1 i 17.2). Harmonogram musi zakładać odbiór produktów w terminach zakończenia etapów technicznych opisanych w rozdziale 18.

Zamawiający przewiduje procedurę zarządzania zmianą (Change Request) dla nowych wymagań zidentyfikowanych podczas analizy przedwdrożeniowej. Wykonawca jest zobowiązany zgłosić konieczność wprowadzania zmian niezwłocznie po ich zidentyfikowaniu Zamawiającemu oraz przedstawić ich zakres oraz przewidywane skutki do akceptacji. Po uzyskaniu akceptacji Wykonawca musi zaktualizować harmonogram szczegółowy prac.

Zamawiający wyjaśnia, że w ramach przedmiotu zamówienia nie narzuca zastosowania jednej, konkretnej platformy pełnej orkiestracji kontenerów (np. Kubernetes, OpenShift). Wybór technologii – w tym decyzja o zastosowaniu lżejszych mechanizmów zarządzania kontenerami (np. środowiska Docker) wspartych programowym mechanizmem równoważenia obciążenia (np. HAProxy) czy też pełnej orkiestracji – leży po stronie Wykonawcy. Wybrane rozwiązanie musi jednak bezwzględnie spełniać wszystkie wymagania OPZ, w tym te dotyczące elastyczności, skalowalności oraz odporności na awarie i niezawodności (rozdział 9.1.3 oraz 9.1.4). Ostateczna architektura docelowa zostanie uszczegółowiona i zatwierdzona przez Zamawiającego na etapie prac analitycznych, w ramach przygotowywania Analitycznego Opisu Systemu oraz Dokumentacji Technicznej. Zamawiający również wyjaśnia, że zastosowane rozwiązanie nie może generować dla niego żadnych ukrytych, cyklicznych kosztów subskrypcyjnych ani licencyjnych warunkujących jego legalne i pełne funkcjonowanie.

Zgodnie z OPZ RSIP WŁ Zamawiający dostarcza wyłącznie nowe maszyny wirtualne z zainstalowanymi systemami operacyjnymi. Dostarczenie (instalacja) i konfiguracja ewentualnego środowiska kontenerowego na udostępnionych maszynach wirtualnych, jak i wdrożenie mechanizmów zarządzania kontenerów lub pełnej orkiestracji kontenerów leży po stronie Wykonawcy.

Zamawiający potwierdza, że funkcjonalności prezentowane w próbce mogą być realizowane na danych demonstracyjnych przygotowanych przez Wykonawcę. Jednocześnie odsyła do odpowiedzi na pytanie 37 zestaw 1 zamieszczonej na stronie prowadzonego postępowania w dniu 25.06.2026 r.

Zgodnie z zapisem V. 4.1 SWZ oferowane przez Wykonawcę docelowe rozwiązanie musi być wykonane w technologii takiej samej, jak prezentowana próbka. Złożona próbka ma na celu potwierdzenie spełnienia wymagań funkcjonalnych opisanych w Załączniku 13 do SWZ „Wymagania dla próbki” oraz zademonstrowanie podstawowych mechanizmów działania i logiki oferowanego oprogramowania. Zamawiający wyjaśnia, że wymóg, zgodnie z którym „próbka stanowi wzorzec rozwiązania”, odnosi się do głównego stosu technologicznego oraz architektury aplikacyjnej (np. zastosowane języki programowania, frameworki, czy docelowy model architektury – np. kontenerowa, mikrousługowa). Jednocześnie Zamawiający doprecyzowuje, że na etapie składania próbki nie wymaga pełnego odwzorowania docelowej, ostatecznej architektury infrastrukturalnej i sieciowej (np. zapewnienia pełnej wysokiej dostępności – HA, fizycznego klastrowania węzłów). Ostateczna architektura środowiska produkcyjnego – w tym ścisłe dostosowanie do infrastruktury Zamawiającego zgodnie z wymogami OPZ – zostanie zaprojektowana, uszczegółowiona i zatwierdzona z Zamawiającym dopiero na etapie realizacji umowy, w ramach prac analitycznych (przygotowanie Analitycznego Opisu Systemu oraz Dokumentacji Technicznej). Podsumowując: próbka musi stanowić technologiczny i funkcjonalny wzorzec oprogramowania, ale Zamawiający nie wymaga od Wykonawcy jej demonstracji na ostatecznej, docelowej infrastrukturze sprzętowej.