Modernizację systemu zarządzania zasobami cyfrowymi, integrującego dane z digitalizacji z
Pełna nazwa postępowania: Modernizację systemu zarządzania zasobami cyfrowymi, integrującego dane z digitalizacji z opisami metadanowymi zgodnie z przyjętymi w projekcie standardami na potrzeby realizacji przez Małopolski Instytut Kultury w Krakowie projektu „Wirtualne Muzea Małopolski 2030. Fenomenalna Małopolska” dofinansowanego ze środków programu Fundusze Europejskie dla Małopolski 2021–2027.
Małopolski Instytut Kultury w Krakowie·NIP 6750004488·Kraków
Wartość szac.
—
nie podano
Termin składania
27.07.2026
postępowanie zakończone
Otwarcie ofert
—
nie podano
Opublikowano
14 lipca 2026
źródło: EB2B
Streszczenie SWZ
Streszczenie AI · Janusz
Widzisz połowę każdej z 10 sekcjiDruga połowa — łącznie 34 zdania z warunkami, dokumentami i analizą ryzyka — odsłania się po założeniu darmowego konta.
Postępowanie dotyczy modernizacji systemu zarządzania zasobami cyfrowymi, integrującego dane z digitalizacji z opisami metadanowymi na potrzeby projektu „Wirtualne Muzea Małopolski 2030. Fenomenalna Małopolska”.
Numer sprawy:26-ZOA-ZP/2
Skrócona nazwa: Modernizacja systemu zarządzania zasobami cyfrowymi na potrzeby projektu Wirtualne Muzea Małopolski 2030. Fenomenalna Małopolska
Typ zamówienia: usługi
Tryb udzielenia zamówienia: tryb podstawowy bez możliwości prowadzenia negocjacji (art. 275 pkt 1 ustawy Pzp)
Kody CPV:
72211000-7 (Usługi oprogramowania systemowego i dla użytkownika)
Postępowanie prowadzone jest w trybie podstawowym bez możliwości prowadzenia negocjacji, zgodnie z art. 275 pkt 1 ustawy Pzp. Zamawiający nie przewiduje wyboru najkorzystniejszej oferty z możliwością przeprowadzenia negocjacji. Szacunkowa wartość zamówienia nie przekracza kwoty określonej w obwieszczeniu Prezesa Urzędu Zamówień Publicznych, wydanym na podstawie **art. (+ 4 zdania — pełna treść po zalogowaniu)
Szacunkowa wartość zamówienia nie przekracza kwoty określonej w obwieszczeniu Prezesa Urzędu Zamówień Publicznych, wydanym na podstawie art. 3 ust. 2 ustawy Pzp. (+ 3 zdania — pełna treść po zalogowaniu)
Termin składania ofert: 27 lipca 2026 r., godz. 10:00 — s. 16 (termin zaktualizowany przez zamawiającego — pierwotna dokumentacja podawała 22 lipca 2026)
Termin otwarcia ofert: 22 lipca 2026 r., godz. 10.30 — s. 16
Zamawiający określił następujące warunki udziału w postępowaniu:
Doświadczenie: Wykonawca musi wykazać, że w okresie ostatnich 3 lat przed upływem terminu składania ofert (a jeżeli okres prowadzenia działalności jest krótszy – w tym okresie) należycie wykonał (lub wykonuje) co najmniej 2 usługi, z których każda polegała na stworzeniu lub rozbudowie i utrzymaniu systemu informatycznego (portal wraz z bazą danych), w tym zaprojektowaniu makiet funkcjonalnych i projektu graficznego serwisu internetowego oraz przeprowadzeniu testów i badań użyteczności prototypu takiego serwisu wraz z wdrożeniem serwisu, przy czym wartość każdej z tych usług musi wynosić nie mniej niż 500 000 zł brutto. Zamawiający nie dopuszcza sumowania wartości usług. * Zespół osób: Wykonawca musi dysponować co najmniej 5-osobowym zespołem dedykowanym do realizacji zamówienia, w skład którego wchodzą: 1. Kierownik projektu: posiadający certyfikat Professional Scrum Master (lub równoważny) oraz doświadczenie jako kierownik lub zastępca kierownika w co najmniej 1 projekcie informatycznym (zakończonym i odebranym bez zastrzeżeń) dotyczącym budowy/rozbudowy systemów z prezentacją zdigitalizowanych zasobów o wartości min. 500 000 zł brutto (doświadczenie z ostatnich 3 lat). (+ 5 zdań — pełna treść po zalogowaniu)
Kary pieniężne (ustawa sankcyjna): do 20 000 000 zł nakładane przez Prezesa UZP za składanie ofert podlegających wykluczeniu z art. 7 ust. 1 ustawy sankcyjnej.
Kary umowne: szczegółowe postanowienia zawarte w Projekcie umowy (Załącznik nr 2 do SWZ).
1. Podwykonawstwo: Zamawiający nie zastrzega obowiązku osobistego wykonania kluczowych zadań. Wykonawca może powierzyć część usług podwykonawcom, pod warunkiem wskazania ich w ofercie lub zgłoszenia w trakcie realizacji za zgodą Zamawiającego. Wykonawca odpowiada za działania podwykonawców jak za własne.
2. RODO: Zamawiający przetwarza dane osobowe w celu przeprowadzenia postępowania i realizacji umowy. Wykonawca jest zobowiązany do wypełnienia obowiązków informacyjnych wobec osób fizycznych, których dane przekazuje Zamawiającemu, oraz złożenia stosownego oświadczenia wraz z ofertą.
3. Warunki realizacji:
Czas realizacji: Zamówienie musi zostać zrealizowane w terminie 12 miesięcy od dnia zawarcia umowy.
Z każdej z 10 sekcji pokazujemy połowę. Załóż darmowe konto, żeby odsłonić pozostałe 34 zdania — 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
Modernizacja systemu zarządzania zasobami cyfrowymi (projekt Wirtualne Muzea Małopolski 2030) obejmująca aktualizację oprogramowania systemowego, frameworków oraz aplikacji portalowej.
Wdrożenie nowego, centralnego modułu repozytorium plików i publikacji wraz z migracją istniejących danych (multimedia, dokumenty, publikacje).
Implementacja modułu synchronizacji zasobów pomiędzy środowiskiem digitalizacji a systemem centralnym.
Rozbudowa systemu CMS o nowe funkcjonalności redakcyjne, w tym „Miejsca” (narracja przestrzenna), „Fenomeny” (mapy myśli) oraz zaawansowany kompozytor kolekcji.
Optymalizacja warstwy prezentacyjnej portalu, w tym przebudowa struktury nawigacji, edycji stron statycznych oraz mechanizmów komunikacji z użytkownikiem.
Przeprowadzenie walidacji SEO oraz pełne testy bezpieczeństwa infrastruktury i aplikacji.
Uruchomienie nowej wersji systemu w środowisku produkcyjnym wraz z migracją danych i aktualizacją dokumentacji technicznej.
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.
Zamawiający potwierdzie jednoznacznie, że wiążącym terminem realizacji całości przedmiotu zamówienia jest 31.05.2028 r. Jeżeli obowiązuje inny termin — proszę o jego wskazanie wraz z ewentualnymi terminami pośrednimi (kamieniami milowymi).
Zamawiający wyjaśnia, że wskazana w OPZ data 31.05.2028 r. odnosi się do Okresu Realizacji Projektu „Wirtualne Muzea Małopolski 2030. Fenomenalna Małopolska”, a nie do terminu realizacji całości przedmiotu zamówienia. Wiążący termin realizacji przedmiotu zamówienia został określony w dokumentacji postępowania jako - do 12 miesięcy od dnia zawarcia Umowy. Zamawiający nie wskazuje odrębnych terminów pośrednich (kamieni milowych) poza tymi, które wynikają wprost z dokumentacji postępowania.
W odniesieniu do ogłoszonego postępowania o nr sprawy/zamówienia: 26-ZOA-ZP/2 z dnia 14 lipca br., wnosimy o rezygnację z wymogu posiadania przez personel certyfikatu Professional Scrum Master (PSM) lub równoważnego, opisanego w SWZ (rozdział VII, pkt 4.2 p.1), bądź uznanie i określenie jemu równoważnych.
Wymóg posiadania certyfikatu Professional Scrum Master uważamy za zawężający do zakresu kompetencji wymaganych od kierownika projektu. Certyfikat ten potwierdza przede wszystkim znajomość metodyki Scrum oraz kompetencje właściwe dla roli Scrum Mastera. Dla szerszego ujęcia, możemy wskazać choćby certyfikat PRINCE2, który potwierdza kompetencje w zakresie kompleksowego zarządzania projektem, obejmujące planowanie, zarządzanie ryzykiem, harmonogramem, budżetem, jakością, zmianą oraz wysokie kompetencje w zakresie nadzoru nad realizacją projektu. W przypadku projektów wymagających całościowego zarządzania, kompetencje potwierdzane certyfikatem PRINCE2 są co najmniej równoważne, a w wielu aspektach szersze niż kompetencje potwierdzane certyfikatem Professional Scrum Master. Z tego względu zasadne jest uznanie certyfikatu PRINCE2 za spełniający wymagania dotyczące kwalifikacji kierownika projektu lub odstąpienie od wskazywania konkretnego certyfikatu na rzecz wymogu w zakresie odpowiednich kompetencji i doświadczenia. Na zakończenie, należy podnieść inny, bardzo ważną aspekt, a mianowicie fakt, że nadrzędną dyrektywą opisaną szeroko w prawie zamówień publicznych jest zasada proporcjonalności oraz zachowania uczciwej konkurencji, dlatego właśnie ufamy, że powyższa argumentacja znajdzie się ze zrozumieniem i przychylnością Zamawiającego – warunki udziału w danym postępowaniu powinny być niezbędne do należytego wykonania zamówienia i nie mogą swoimi zapisami ograniczać konkurencji bardziej, niż jest to niezbędnie konieczne.”
Zgodnie z Rozdziałem VII pkt 4 ppkt 4.2.SWZ, poz. 1 tabeli, o udzielenie zamówienia publicznego mogą ubiegać się wykonawcy, którzy dysponują lub będą dysponować osobami zdolnymi do realizacji zamówienia tj. przynajmniej 5-osobowym zespołem, który będzie wykonywał zamówienie, 1 osobą na stanowisku Kierownika projektu posiadającą co najmniej Certyfikat Professional Scrum Master lub równoważny.
Zgodnie z Rozdziałem VII pkt 5 SWZ jako certyfikat równoważny Zamawiający rozumie certyfikat analogiczny co do zakresu wskazanego certyfikatu, co jest rozumiane jako:
a) analogiczna dziedzina merytoryczna wynikająca z roli (wiedzy), której dotyczy certyfikat,
b) analogiczny stopień poziomu kompetencji,
c) analogiczny poziom doświadczenia zawodowego wymagany dla otrzymania danego certyfikatu,
d) potwierdzenie certyfikatu egzaminem, jeśli uzyskanie certyfikatu wymaga złożenia egzaminu.
Certyfikat równoważny nie może być wystawiony przez Wykonawcę lub podmiot zależny od Wykonawcy.
Zamawiający wyjaśnia, że wskazanie przez Zamawiającego w SWZ jako przykładowego certyfikatu Scrum Master nie miało na celu ograniczania zasady uczciwej konkurencji oraz równego traktowania wykonawców. Certyfikat Scrum Master został wskazany w SWZ jako przykładowy, popularny, często stosowany dla zespołów realizujących projekty informatyczne. W ocenie Zamawiającego proponowany przez Wykonawcę certyfikat Prince 2 spełnia w równoważnym stopniu wymagania dotyczące kwalifikacji zawodowych kierownika projektu, które potwierdza certyfikat Scrum Master.
W związku z powyższym, w celu potwierdzenia spełniania warunku dotyczącego zdolności technicznej lub zawodowej w zakresie kwalifikacji zawodowych kierownika projektu, określonych w Rozdziale VII pkt 4 ppkt 4.2.SWZ, poz. 1 tabeli, wykonawcy mogą posłużyć się certyfikatem Prince 2 jako certyfikatem równoważnym do certyfikatu Scrum Master.
Proszę o jednoznaczne wskazanie topologii: czy komponenty (CMS, Muza, Portal, bazy) działają na pojedynczej maszynie wirtualnej, czy w środowisku rozproszonym? Proszę podać liczbę maszyn, ich role oraz czy obowiązują wymagania wysokiej dostępności (HA) i odtwarzania po awarii (DR).
Zamawiający wyjaśnia, że komponenty Systemu, tj. CMS, Muza, Portal oraz bazy danych, działają w środowisku rozproszonym. Aktualna topologia obejmuje następujące maszyny wirtualne:
● Maszyna wirtualna 1 – system Muza, uruchomione i skonfigurowane w środowisku Docker
● Maszyna wirtualna 2 – CMS, API, Portal, uruchomione i skonfigurowane w środowisku Docker
● Maszyna wirtualna 3 – zasoby plikowe (NFS)
● Maszyna wirtualna 4 – prezentacje (serwer WWW)
Maszyny są uruchomione w środowisku wysokiej dostępności realizowanej na poziomie infrastruktury.
Jednocześnie Zamawiający wyjaśnia, że nie narzuca szczególnych wymagań w zakresie realizacji mechanizmów wysokiej dostępności (HA) ani odtwarzania po awarii (DR) po stronie oprogramowania stanowiącego przedmiot zamówienia, poza wymaganiami wynikającymi wprost z treści OPZ.
Proszę o wskazanie konkretnych technologii obecnie realizujących przechowywanie plików i generowanie adresów URL (nazwa i wersja oprogramowania/bibliotek, typ storage).
Zamawiający wyjaśnia, że obecne środowisko przechowywania plików oraz generowania adresów URL nie jest oparte o pojedyncze, standardowe rozwiązanie produktowe. Za przechowywanie plików oraz generowanie adresów URL odpowiada obecnie ekosystem częściowo autorskich komponentów systemowych, w szczególności system CMS oraz system Muza, wykorzystujące m.in. technologie PHP, PostgreSQL oraz Symfony Framework.
W zakresie generowania adresów URL publikacja zasobów realizowana jest za pośrednictwem autorskiego systemu CDN opartego o technologię nginx, pracującego produkcyjnie w konfiguracji skalowalnej na poziomie 3 replik.
W zakresie warstwy składowania danych: pliki przechowywane są równolegle na systemach klasy NAS i SAN (Środowisko Digitalizacji) oraz na macierzach dyskowych klasy SAN (System). Preferowanym protokołem udostępniania danych jest obecnie NFS.
W zakresie nazewnictwa i identyfikacji plików: algorytm nazewnictwa oparty jest o dwa odrębne moduły importowe (osobny dla systemu Muza oraz osobny dla systemu CMS), wykorzystujące algorytmy haszujące oraz identyfikatory UUID. Adresy URL generowane przez usługę CDN nie mają formy zrozumiałej dla użytkownika, składają się z losowych ciągów znaków.
Szczegółowe konfiguracje poszczególnych komponentów zostaną udostępnione Wykonawcy na etapie analizy przedwdrożeniowej.
OPZ dopuszcza „rozszerzenie istniejącego rozwiązania lub wdrożenie nowego". Proszę o rozstrzygnięcie, którą z tych dróg Zamawiający wymaga, oraz o opis, jaki komponent przechowywania plików istnieje dziś (funkcje, granice). Odpowiedź „decyzja Wykonawcy" proszę potwierdzić wprost — wówczas Wykonawca dokona wyboru i będzie on wiążący dla obu stron.
Zamawiający potwierdza, że w ramach OPZ dopuszczalne są oba warianty realizacji, tj. zarówno rozszerzenie istniejącego rozwiązania, jak i wdrożenie nowego rozwiązania. Wybór wariantu realizacji pozostaje po stronie Wykonawcy i powinien zostać dokonany na podstawie wyników analizy przedwdrożeniowej oraz własnej oceny możliwości technicznych, z uwzględnieniem wymagań określonych w OPZ. Wybrany przez Wykonawcę wariant realizacji będzie wiążący dla obu stron.
Jednocześnie Zamawiający wyjaśnia, że w obecnym Systemie nie jest możliwe precyzyjne wyodrębnienie granic komponentu przechowywania plików jako całkowicie odrębnego modułu, ponieważ funkcjonalność ta stanowi integralną część systemów CMS i Muza oraz jest powiązana z innymi obszarami Systemu.
Proszę o podanie liczbowych parametrów migracji na dzień publikacji OPZ: (a) liczba plików, (b) łączny rozmiar w TB, (c) liczba Elementów Publikacji, (d) liczba obiektów w Muzie. Dane te są niezbędne do rzetelnej wyceny zgodnie z zasadą jednoznacznego opisu przedmiotu zamówienia.
Zamawiający wyjaśnia, że na dzień publikacji OPZ nie określa wiążących, precyzyjnych parametrów migracji w rozumieniu sztywnej liczby plików czy łącznego wolumenu danych. Wartości te mają charakter zmienny, wynikający z bieżącej eksploatacji systemów, i nie stanowią gwarantowanego zakresu ilościowego na potrzeby realizacji przedmiotu zamówienia.
Jednocześnie Zamawiający wskazuje, że przedstawione w dokumentacji postępowania oraz w wyjaśnieniach informacje ilościowe należy traktować jako dane orientacyjne, służące oszacowaniu skali środowiska, a nie jako wiążące parametry kontraktowe dla migracji. Szczegółowe ustalenia dotyczące rzeczywistego zakresu danych oraz sposobu ich przeniesienia będą przedmiotem analizy przedwdrożeniowej.
Orientacyjne dane według stanu na dzień publikacji OPZ przedstawiają się następująco: całkowita liczba plików w systemach Muza oraz CMS wynosi 42 031 642, liczba Elementów Publikacji wynosi 40 347, a liczba obiektów w systemie Muza wynosi 4 425. Całkowity rozmiar produkcyjnego środowiska Systemu, rozumiany jako rozmiar zasobów LUN dla maszyn wirtualnych, wynosi 6,5 TB + 7 TB + 15 TB, przy czym łączny rozmiar danych to około 22 TB. Całkowity rozmiar posiadanych danych digitalizacyjnych, obejmujących System oraz Środowisko Digitalizacji, wynosi około 80 TB.
Proszę o jednoznaczne potwierdzenie, że wymiana danych między Środowiskiem Digitalizacji a Systemem odbywa się wyłącznie przez współdzielony Folder Wymiany (SMB/NFS) i że w Systemie nie występuje szyna danych, broker komunikatów ani platforma iPaaS. Jeżeli takie narzędzie istnieje — proszę o jego nazwę i rolę.
Zamawiający wyjaśnia, że podstawowy mechanizm wymiany danych między Środowiskiem Digitalizacji a Systemem opiera się na współdzielonym Folderze Wymiany z wykorzystaniem protokołów SMB/NFS. W ramach tego procesu wykorzystywane są skrypty synchronizacyjne oraz mechanizmy przetwarzania po stronie systemów odbierających dane.
Ponadto w systemach Muza i CMS dostępna jest także funkcjonalność ręcznego importu danych multimedialnych z poziomu interfejsu użytkownika.
Zamawiający jednocześnie informuje, że w Systemie nie funkcjonuje odrębna szyna danych ani platforma integracyjna typu iPaaS wykorzystywana do realizacji tej wymiany. Ewentualne mechanizmy kolejkowania lub buforowania, o ile występują, mają charakter techniczny i wewnętrzny po stronie komponentów odbierających dane, a nie odrębnej warstwy integracyjnej.
Proszę o wskazanie obecnego mechanizmu i protokołu integracji Muza↔CMS oraz o potwierdzenie, czy istnieje udokumentowane API systemu Muza. Jeżeli tak — proszę o zobowiązanie do udostępnienia dokumentacji API najpóźniej na etapie analizy przedwdrożeniowej.
Zamawiający wyjaśnia, że w posiadanym rozwiązaniu system Muza integruje się z systemem CMS z użyciem API zbudowanego w na bazie widoków bazodanowych. Komunikacja pomiędzy systemami realizowana jest z wykorzystaniem wewnętrznych mechanizmów integracyjnych API, stanowiących element istniejącego rozwiązania, a nie odrębnego publicznego interfejsu API.
System CMS wyposażony jest w publiczne API i jest ono dostępne w narzędziu CMS. Zamawiający nie dysponuje odrębną dokumentacją API systemu Muza i nie przewiduje jej udostępnienia na etapie analizy przedwdrożeniowej. Jednocześnie, w celu umożliwienia Wykonawcy przeprowadzenia analizy przedwdrożeniowej, Zamawiający przewiduje przekazanie dostępu do baz danych i wszelkich innych plików i zasobów Systemu w zakresie niezbędnym do identyfikacji i analizy istniejących mechanizmów integracyjnych.
Pokazujemy 8 z 26 pytań. Komplet wyjaśnień — razem z załącznikami, których dotyczą — jest w dokumentacji postępowania.
