Zamówienie jednoczęściowe: wdrożenie platformy multiportalowej dla Uniwersytetu Jana Długosza w Częstochowie — dostarczenie licencji i instalacja na zasobach zamawiającego, na min. 2 maszynach wirtualnych (strona główna uczelni i pozostałe serwisy), obejmujące:
panel globalny zarządzający wieloma portalami oraz lokalne panele administracyjne poszczególnych portali;
co najmniej 4 warianty szablonów graficznych (motywów) i co najmniej 3 wersje językowe serwisów;
integracje z 3 systemami uczelni — CAS, USOS i Egeria (Comarch) — wraz z dokumentacją integracyjną;
udokumentowane API REST do zdalnej administracji i integracji (portale, użytkownicy, strony, aktualności, akapity, wydarzenia, galerie zdjęć);
zgodność z WCAG 2.2 AA i ATAG 2.0: wbudowane walidatory WCAG 2.2, moduł deklaracji dostępności, automatyczne generowanie opisów alternatywnych i korekta treści narzędziem AI (LLM), dwuskładnikowe uwierzytelnianie (e-mail + TOTP);
menedżer plików z AI-generatorem opisów alternatywnych, menedżer wersji graficznych (w tym wersja żałobna), moduły aktualności i wydarzeń globalnych oraz treści globalnych;
prace wdrożeniowe: analiza przedwdrożeniowa, dostarczenie licencji, instalacja i parametryzacja, uruchomienie funkcjonalności, testy i poprawy błędów;
szkolenia dla użytkowników i administratorów oraz przekazanie dokumentacji i instrukcji dla użytkowników.
Trudność: wysoka
Złożone technicznie wymagania dotyczące dostępności (WCAG 2.2 AA, ATAG 2.0), integracji z trzema systemami uczelnianymi (CAS, USOS, Egeria) oraz dedykowanej architektury multiportalowej z panelem globalnym i lokalnymi panelami administracyjnymi wymaga doświadczenia i koordynacji wielu specjalizacji.
Terminy realizacji
Czas na realizację (termin wykonania) do 20 tygodni od zawarcia umowy; etapy (OPZ, zał. 1): analiza przedwdrożeniowa do 6 tyg. od podpisania umowy, dostarczenie licencji i instalacja/parametryzacja do 2 tyg. od odbioru analizy, uruchomienie funkcjonalności do 8 tyg. od odbioru analizy, testy i poprawy błędów do 4 tyg. od uruchomienia, szkolenia do 4 tyg. od uruchomienia, dokumentacja najpóźniej do 20 tyg. od zawarcia umowy
Wymagany okres gwarancji min. 24 mies. (2 lata) od odbioru Systemu / przekazania protokołem „bez uwag”; do oceny maks. 60 mies.
Warunki udziału
AI
1Doświadczenie – platforma multiportalowa — min. 1 zakończona i odebrana usługa wdrożenia gotowej platformy multiportalowej (centralne zarządzanie wieloma portalami, delegowanie administracji lokalnej, treści wspólne i lokalne) z instalacją na infrastrukturze zamawiającego, wartość ≥ 200 000,00 zł brutto, ostatnie 3 lata
2Integracja z USOS — min. 1 zakończona i odebrana usługa integracji własnego rozwiązania z systemem USOS z automatycznym zarządzaniem uprawnieniami użytkowników (zakładanie kont, blokowanie/usuwanie dostępu)
Pozostałe 11 warunków po założeniu darmowego konta.
Kryteria wyboru oferty
AI
Wagi punktowe, według których zamawiający oceni oferty.
Cenabrutto, wzór C = (Cmin/Co) × 70
70%
Okres gwarancji24/36/48/60 mies.
30%
Czerwone flagi
AI
Sygnały, na które warto zwrócić uwagę przed startem.
SWZ zmodyfikowany 43 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.
Kary i sankcje
AI
Kary umowne: w projekcie umowy (zał. nr 9 do SWZ).
Pytania i odpowiedzi
9
Wyodrębnione z wyjaśnień treści SWZ.
1Ten sam zakres doświadczenia Zamawiający ocenia inaczej wobec programisty i wobec wykonawcy. Od programisty, który fizycznie wykona integrację, przyjmuje doświadczenie z USOS „lub innym systemem dziekanatowym, kadrowym lub systemem zarządzania tożsamością (IAM)” (pkt 7.1 ppkt 2 lit. c). Od wykonawcy wymaga wyłącznie integracji z USOS. Przedmiotem zamówienia nie jest wdrożenie USOS, lecz wymiana danych z nim. Wymaga to tych samych kompetencji co integracja z każdym innym systemem uczelni: uwierzytelniania, synchronizacji użytkowników oraz przypisywania ról i uprawnień. USOS jest przy tym jednym z integrowanych systemów, obok CAS i Egerii. Warunek wyklucza więc wykonawców z równoważnym doświadczeniem i naszym zdaniem ogranicza krąg wykonawców ponad potrzebę wynikającą z przedmiotu zamówienia (art. 16 pkt 1 i art. 112 ust. 1 Pzp). Czy Zamawiający dopuści integrację z USOS lub innym systemem dziekanatowym, kadrowym albo systemem zarządzania tożsamością, tak jak w przypadku programisty?
Zamawiający zmienia następujące zapisy:1) rozdziału 7 SWZ, który otrzymuje brzmienie:
„Zamawiający określa warunki udziału w postępowaniu dotyczące zdolności technicznej lub zawodowej:
Zamawiający wymaga, by wykonawca w sposób należyty wykonał 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, co najmniej
jedną zakończoną i odebraną usługę o wartości nie mniejszej niż 200 000,00 zł brutto polegającą na wdrożeniu gotowej platformy multiportalowej umożliwiającej centralne zarządzanie wieloma portalami internetowymi, delegowanie administracji lokalnej do poszczególnych portali oraz publikację treści wspólnych i lokalnych, wraz z instalacją na infrastrukturze zamawiającego;
jedną zakończoną i odebraną usługę polegającą na integracji platformy multiportalowej z systemem USOS (Uniwersytecki System Obsługi Studiów) lub innym systemem dziekanatowym, kadrowym lub systemem zarządzania tożsamością (IAM).
Usługi, o których mowa w lit. a) i b), mogą być wykazane w ramach jednego zamówienia (umowy), jeżeli obejmowało ono oba wskazane zakresy, albo w ramach dwóch odrębnych zamówień (umów).Za gotową platformę multiportalową Zamawiający uzna rozwiązanie istniejące i rozwijane przed dniem wszczęcia postępowania, posiadające wdrożenia produkcyjne u klientów zewnętrznych oraz niewymagające wytworzenia systemu od podstaw na potrzeby niniejszego zamówienia. Za realizację integracji uznaje się należycie wykonaną i odebraną usługę, potwierdzoną dokumentem potwierdzającym jej należyte wykonanie, obejmującą integrację platformy multiportalowej z systemem USOS lub innym systemem dziekanatowym, kadrowym lub systemem zarządzania tożsamością (IAM), zapewniającą co najmniej automatyczne zarządzanie uprawnieniami użytkowników do platformy multiportalowej. Przez automatyczne zarządzanie uprawnieniami Zamawiający rozumie co najmniej automatyczne zakładanie kont oraz automatyczne blokowanie lub usuwanie dostępu w następstwie utraty przez użytkownika odpowiedniego statusu, roli lub uprawnienia w systemie źródłowym.
Zamawiający wymaga, by wykonawca do realizacji zamówienia skierował niżej wymienione osoby:
Kierownik Projektu - co najmniej 1 osoba, posiadająca:
wykształcenie wyższe;
minimum 3-letnie doświadczenie zawodowe w zarządzaniu projektami IT;
udział w roli kierownika projektu w co najmniej dwóch zakończonych projektach wdrożeniowych systemów informatycznych realizowanych na rzecz podmiotów sektora finansów publicznych lub innych podmiotów zobowiązanych do zapewnienia dostępności cyfrowej usług publicznych;
Poprzednia odpowiedź nie miała wymaganego kształtu.
2O zdolności wdrożenia platformy multiportalowej świadczą jej cechy funkcjonalne: centralne zarządzanie wieloma portalami, delegowanie administracji lokalnej oraz publikacja treści wspólnych i lokalnych. Nie świadczy o niej miejsce instalacji (art. 112 ust. 1 Pzp). Zamawiający nie przeprowadził wstępnych konsultacji rynkowych (pkt 4.1.1 ogłoszenia), więc nie mógł ocenić, ilu wykonawców spełnia warunek w obecnym brzmieniu. Czy Zamawiający: - dopuści wdrożenie platformy o wskazanych cechach niezależnie od miejsca instalacji, - potwierdzi, że usługa mogła być wykonana na rzecz dowolnego podmiotu, nie tylko uczelni, - uzna za gotową platformę autorski CMS wykonawcy, istniejący przed danym wdrożeniem?
Zamawiający nie wyraża zgody na zmianę warunku udziału w postępowaniu określonego w pkt 7.1. ppkt 1 lit. a) SWZ. Wskazany wymóg nie odnosi się do miejsca instalacji w znaczeniu geograficznym ani do określonego rodzaju podmiotu, na rzecz którego wykonywana była usługa, lecz do sposobu wdrożenia rozwiązania i doświadczenia Wykonawcy w realizacji wdrożenia platformy na infrastrukturze podmiotu będącego odbiorcą danego rozwiązania. Wymaganie pozostaje związane z przedmiotem i sposobem realizacji niniejszego zamówienia, ponieważ zgodnie z Opisem Przedmiotu Zamówienia oferowany System musi umożliwiać instalację na własnych zasobach Zamawiającego oraz współpracę z określonym w Opisie Przedmiotu Zamówienia środowiskiem infrastrukturalnym Zamawiającego. Zamawiający potwierdza jednocześnie, że usługa wykazywana na potwierdzenie spełnienia warunku określonego w pkt 7.1 ppkt 1 lit. a) SWZ mogła zostać wykonana na rzecz dowolnego podmiotu, nie tylko uczelni ani jednostki sektora finansów publicznych, pod warunkiem spełnienia wszystkich wymagań określonych w tym warunku. Zamawiający potwierdza również, że autorski system CMS Wykonawcy może zostać uznany za gotową platformę multiportalową, o ile spełnia wymagania funkcjonalne wskazane w pkt 7.1. ppkt 1 lit. a) SWZ oraz definicję gotowej platformy multiportalowej określoną w punkcie 7.1. ppkt 1 SWZ, tj. stanowi rozwiązanie istniejące i rozwijane przed dniem wszczęcia postępowania, posiadające wdrożenia produkcyjne u klientów zewnętrznych oraz niewymagające wytworzenia systemu od podstaw na potrzeby niniejszego zamówienia. Zamawiający podtrzymuje zapisy SWZ w powyższym zakresie.
3Zamawiający wymaga „rozwiązania istniejącego, sprawdzonego i posiadającego wdrożenia produkcyjne” (Załącznik 10), a jednocześnie „dedykowanego rozwiązania (…) zaprojektowanego pod specyficzne wymagania bezpieczeństwa Zamawiającego” (OPZ). Czy wymaganie „rozwiązania istniejącego” dotyczy platformy bazowej, czyli systemu CMS wdrożonego produkcyjnie u innych klientów? Czy funkcjonalności wymagane w OPZ mogą zostać zrealizowane na tej platformie w ramach etapu „uruchomienia funkcjonalności” (§ 3 ust. 1 wzoru umowy)?
Zamawiający wyjaśnia, że wymaganie dotyczące rozwiązania istniejącego, sprawdzonego i posiadającego wdrożenia produkcyjne odnosi się do oferowanego Systemu stanowiącego podstawę wdrażanej Platformy Multiportalowej. Zgodnie z pkt 7.1. podpunkt 1 SWZ rozwiązanie to musi istnieć i być rozwijane przed dniem wszczęcia postępowania, posiadać wdrożenia produkcyjne u klientów zewnętrznych oraz nie może wymagać wytworzenia systemu od podstaw wyłącznie na potrzeby niniejszego zamówienia.
Pojęcie „dedykowanego rozwiązania”, którym posłużono się w Opisie Przedmiotu Zamówienia, nie oznacza obowiązku wytworzenia nowego systemu od podstaw. Odnosi się ono do wdrożenia oferowanego Systemu, opartego na istniejącym rozwiązaniu, które zostanie skonfigurowane, zintegrowane i dostosowane do wymagań Zamawiającego określonych w dokumentacji postępowania.
Zamawiający potwierdza, że po zawarciu umowy, w ramach analizy przedwdrożeniowej oraz prac wdrożeniowych, dopuszczalne będzie wykonanie czynności przewidzianych w dokumentacji postępowania, w szczególności instalacji Systemu w środowisku Zamawiającego, jego konfiguracji i parametryzacji, wykonania wymaganych integracji, przygotowania warstwy graficznej i szablonów, uruchomienia poszczególnych funkcjonalności oraz dostosowania ustawień i sposobu działania Systemu do infrastruktury i potrzeb Zamawiającego.
4OPZ zawiera wymagania niezwiązane bezpośrednio z celem projektu „Uniwersytet dostępny II”, m.in. forum z ocenianiem postów, ankiety z dwuetapową oceną ekspertów, bazę noclegową i płatności online w module konferencji. Mamy obawę, że ten zestaw, połączony z wymogiem istnienia rozwiązania w dniu składania ofert, w praktyce odpowiada zakresowi funkcjonalnemu jednego rozwiązania dostępnego na rynku uczelnianym. Opis przedmiotu zamówienia może wtedy zostać odczytany jako opis określonego produktu, a nie potrzeb Zamawiającego, czego art. 99 ust. 4 Pzp pozwala uniknąć. Czy Zamawiający ustalił, ilu dostawców oferuje system spełniający jednocześnie wszystkie wymagania OPZ? Czy ograniczy wymagania obligatoryjne do funkcji związanych z celem projektu: dostępności cyfrowej, zarządzania wieloma serwisami i integracji z systemami uczelni?
Zamawiający nie wyraża zgody na ograniczenie wymagań obligatoryjnych Opisu Przedmiotu Zamówienia wyłącznie do funkcjonalności wskazanych w pytaniu, tj. dostępności cyfrowej, zarządzania wieloma serwisami oraz integracji z systemami Zamawiającego.
Zamawiający nie ustalał dokładnej liczby dostawców oferujących system spełniający łącznie wszystkie wymagania OPZ. Przed przygotowaniem dokumentacji Zamawiający przeanalizował dostępne rozwiązania oraz rzeczywiste potrzeby przyszłych użytkowników Platformy i na tej podstawie określił wymagany zakres funkcjonalny.
Zamawiający podtrzymuje zapisy Specyfikacji Warunków Zamówienia i Opisu Przedmiotu Zamówienia w powyższym zakresie.
5Próbka wymaga, by już w dniu składania ofert, na koszt i ryzyko wykonawcy, działało 30 scenariuszy obejmujących znaczną część przedmiotu zamówienia. Żądanie przedmiotowych środków dowodowych jest uprawnieniem Zamawiającego (art. 106 ust. 1 Pzp), a w tym kształcie naszym zdaniem zawęża krąg wykonawców ponad potrzebę (art. 16 pkt 1 i 3 Pzp). Czy Zamawiający zrezygnuje z próbki i prezentacji na rzecz weryfikacji działających wdrożeń produkcyjnych wskazanych w wykazie usług? Czy dopuści przedstawienie raportu z audytu dostępności przy odbiorze końcowym?
Zamawiający nie zrezygnuje z próbki i prezentacji na rzecz weryfikacji działających wdrożeń produkcyjnych wskazanych w wykazie usług. Zamawiający podtrzymuje wymaganie dotyczące przeprowadzenia prezentacji zgodnie ze scenariuszem demonstracyjnym określonym w dokumentacji zamówienia.
Zamawiający nie wyraża zgody na przedstawienie raportu z audytu dostępności wyłącznie przy odbiorze końcowym.