Postępowanie prowadzone jest w trybie przetargu nieograniczonego zgodnie z art. 132 ustawy z dnia 11 września 2019 r. Prawo zamówień publicznych (Dz. U. 2024 poz. (+ 4 zdania — pełna treść po zalogowaniu)
Zamówienie ma wartość szacunkową powyżej 216 000 euro. Rozliczenia między Zamawiającym a Wykonawcą będą prowadzone wyłącznie w walucie polskiej (PLN). W Formularzu oferty należy podać cenę całkowitą brutto. (+ 2 zdania — pełna treść po zalogowaniu)
Zamówienie należy zrealizować w terminie 24 miesięcy od zawarcia umowy.
Wykonawca może polegać na zdolnościach podmiotów udostępniających zasoby (art. 118 ustawy Pzp).
Podwykonawcy nie mogą podlegać wykluczeniu z postępowania.
Zamawiający zawrze umowę w terminie nie krótszym niż 10 dni od dnia przesłania zawiadomienia o wyborze oferty (przy komunikacji elektronicznej) lub 15 dni (w innym przypadku).
Umowa zostanie uzupełniona o zapisy wynikające ze złożonej oferty.
Administratorem danych jest Uniwersytet Przyrodniczy w Poznaniu.
Sygn. 1 — wskazanie produktu: wymagania funkcjonalne pokrywają się z architekturą i dokumentacją platformy WEBCON BPS (OPZ, Zestawienie porównawcze, s. 5–6).
Sygn. 2 — restrykcyjne doświadczenie: 3 zamówienia w ostatnich 3 latach dla Uczelni z integracją DSpace z PBN i POL-on (PBN REST API 2.0) (SWZ, Rozdział 16, s. 16).
Z każdej z 10 sekcji pokazujemy połowę. Załóż darmowe konto, żeby odsłonić pozostałe 28 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
Dostawa i wdrożenie systemu do zarządzania obiegiem dokumentów opartego na platformie typu low-code. Zamówienie obejmuje:
Dostawę licencji oprogramowania.
Instalację i konfigurację środowisk: programistycznego (DEV), testowego (TEST) oraz produkcyjnego (PROD).
Przeprowadzenie analizy biznesowej dla obszarów: administracyjnego, studenckiego, kadrowego, finansowego oraz kancelaryjnego.
Implementację i konfigurację procesów biznesowych we wskazanych obszarach.
Testy systemowe i poprawki wdrożeniowe.
Odbiór końcowy systemu.
24-miesięczne wsparcie powdrożeniowe i usługi rozwojowe.
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.
Czy Zamawiający dopuści wykazanie doświadczenia w dostawie i wdrożeniu systemu workflow/BPM/DMS/low-code dla organizacji publicznych lub dużych organizacji wielooddziałowych, obejmującego obieg dokumentów, formularze elektroniczne, integracje, role, uprawnienia, raportowanie, szkolenia i wsparcie techniczne, zamiast ograniczenia wyłącznie do „Systemu Informatycznego Uczelni”? Uzasadnienie: Przedmiot zamówienia dotyczy przede wszystkim zarządzania obiegiem dokumentów oraz procesów administracyjnych, finansowych, kadrowych i kancelaryjnych. Są to obszary procesowe, które występują również w dużych organizacjach publicznych i prywatnych. Równoważne doświadczenie w projektach workflow/BPM/DMS/low-code może więc potwierdzać zdolność wykonawcy do realizacji zamówienia.
Zamawiający nie wyraża zgody na zmianę warunku w postulowanym zakresie. Zamawiający podtrzymuje wymaganie wykazania doświadczenia w dostawie i wdrożeniu Systemu Informatycznego Uczelni wykonanego w oparciu o oferowaną przez wykonawcę w ramach niniejszego postępowania Platformę LOW-CODE.
Prosimy o doprecyzowanie, czy przez „System Informatyczny Uczelni” Zamawiający rozumie wyłącznie system dedykowany szkolnictwu wyższemu, czy również platformę workflow/BPM/DMS/low-code wdrożoną w uczelni i wspierającą procesy administracyjne, finansowe, kadrowe, kancelaryjne lub studenckie. Uzasadnienie: Pojęcie „System Informatyczny Uczelni” może być interpretowane szeroko lub wąsko. Doprecyzowanie jest konieczne do prawidłowej oceny spełnienia warunków udziału przez wykonawców.
Zamawiający wyjaśnia, że przez „System Informatyczny Uczelni” należy rozumieć system zgodny z definicją zawartą w SWZ. Zamawiający nie ogranicza tego pojęcia wyłącznie do jednego konkretnego rodzaju systemu dedykowanego szkolnictwu wyższemu, jednak system wykazywany w ramach warunku musi być systemem wdrożonym dla uczelni i służyć zarządzaniu procesami uczelni w obszarach wskazanych w SWZ. Nie będzie wystarczające wykazanie ogólnej platformy workflow/BPM/DMS/low-code wdrożonej w dowolnej organizacji, jeżeli wdrożenie to nie dotyczyło środowiska uczelni i nie obejmowało procesów charakterystycznych dla uczelni.
Czy Zamawiający dopuści spełnienie warunku dotyczącego liczby użytkowników poprzez wykazanie wdrożenia dla organizacji posiadającej co najmniej 1000 użytkowników końcowych systemu, niezależnie od tego, czy była to uczelnia, czy inna organizacja o porównywalnej skali organizacyjnej? Uzasadnienie: Ryzyko wdrożeniowe związane z liczbą użytkowników dotyczy przede wszystkim skali organizacji, wydajności systemu, zarządzania uprawnieniami, adopcji użytkowników, wsparcia i utrzymania, a nie wyłącznie typu podmiotu.
Zamawiający nie wyraża zgody na postulowaną zmianę. Zamawiający podtrzymuje wymaganie, aby wdrożenie wykazywane w ramach warunku dotyczyło Systemu Informatycznego Uczelni umożliwiającego jednoczesną pracę minimum 1000 użytkowników końcowych. Zamawiający zgadza się, że liczba użytkowników jest istotnym elementem skali wdrożenia, jednak sama liczba użytkowników nie jest wystarczająca do potwierdzenia zdolności wykonawcy do realizacji niniejszego zamówienia. W przypadku UPP istotna jest nie tylko skala użytkowników, ale również specyfika grup użytkowników, w szczególności pracowników administracyjnych, nauczycieli akademickich, osób funkcyjnych, jednostek organizacyjnych, komisji, studentów oraz użytkowników uczestniczących w procesach kancelaryjnych, finansowych, kadrowych i studenckich. Wdrożenie dla organizacji posiadającej 1000 użytkowników końcowych, ale funkcjonującej poza sektorem uczelni wyższych, nie daje Zamawiającemu wystarczającej podstawy do oceny, czy wykonawca rozumie specyfikę procesową i organizacyjną uczelni.
Czy Zamawiający dopuści wykazanie doświadczenia w integracji platformy workflow/BPM/DMS/low-code z systemami zewnętrznymi poprzez API, REST/SOAP/JDBC, systemami dziedzinowymi, repozytoriami dokumentów lub systemami administracyjnymi, zamiast wymogu dokładnie trzech integracji DSpace z systemami uczelni, PBN i POL-on? Uzasadnienie: Wymóg integracji DSpace/PBN/POL-on dotyczy bardzo specyficznego obszaru uczelnianego, podczas gdy zasadniczy przedmiot zamówienia obejmuje szeroką platformę do obiegu dokumentów i automatyzacji procesów. Tak sformułowany warunek może ograniczać konkurencję do podmiotów posiadających doświadczenie w jednym fragmencie ekosystemu uczelni, mimo że kluczowe kompetencje wykonawcze dotyczą platformy workflow, integracji, dokumentów, procesów i wdrożenia.
Zamawiający nie wyraża zgody na zastąpienie wymogu doświadczenia w integracji DSpace/PBN/POL-on ogólnym doświadczeniem integracyjnym. Zamawiający podtrzymuje wymaganie wykazania doświadczenia w integracji systemu DSpace z innymi systemami uczelni oraz z systemami PBN i POL-on przy wykorzystaniu PBN REST API 2.0. Zamawiający wskazuje, że integracje DSpace/PBN/POL-on nie są przypadkowym ani pobocznym wymaganiem technicznym, lecz odnoszą się do specyficznego obszaru funkcjonowania uczelni wyższej, w szczególności danych dotyczących działalności naukowej, dorobku pracowników, procesów oceny i sprawozdawczości oraz powiązania tych danych z procesami realizowanymi w systemie obiegu dokumentów. Ogólne doświadczenie w integracji systemów poprzez API, REST/SOAP/JDBC, repozytoria dokumentów lub systemy administracyjne nie jest równoważne z doświadczeniem w integracji DSpace/PBN/POL-on, ponieważ nie potwierdza znajomości modelu danych, uwarunkowań organizacyjnych, wymagań merytorycznych i praktycznych problemów występujących przy integracji systemów charakterystycznych dla szkolnictwa wyższego i nauki. Zamawiający podkreśla, że przyjęty warunek służy ograniczeniu ryzyka wdrożeniowego i jest bezpośrednio związany z przedmiotem zamówienia.
Czy Zamawiający potwierdza, że doświadczenie w zakresie integracji DSpace/PBN/POL-on może zostać wykazane przez podmiot udostępniający zasoby lub podwykonawcę, który będzie realnie wykonywał ten zakres zamówienia? Uzasadnienie: Pozwoli to na udział wykonawców posiadających kompetencje w zakresie platform workflow/BPM/DMS/low-code, przy jednoczesnym zapewnieniu specjalistycznego doświadczenia w obszarze repozytoriów uczelnianych i systemów nauki.
Zamawiający potwierdza, że wykonawca może polegać na zasobach podmiotu udostępniającego zasoby na zasadach określonych w SWZ oraz przepisach ustawy Pzp. Jednocześnie Zamawiający wyjaśnia, że w przypadku polegania na doświadczeniu podmiotu trzeciego w zakresie integracji DSpace/PBN/POL-on, podmiot ten musi realnie wykonywać tę część zamówienia, do realizacji której wymagane jest wskazane doświadczenie. Zamawiający będzie oceniał nie tylko fakt udostępnienia zasobów, ale również zakres, sposób i okres ich udostępnienia oraz rzeczywisty udział podmiotu udostępniającego zasoby w realizacji zamówienia.
Czy Zamawiający dopuści wykazanie doświadczenia w realizacji procesu oceny pracowniczej, okresowej oceny, ankietyzacji, akceptacji lub workflow HR dla dużej organizacji, zamiast ograniczenia wyłącznie do e-usługi oceny pracowniczej dla pracowników naukowo-badawczych, naukowo-dydaktycznych i dydaktycznych uczelni? Uzasadnienie: Mechanika procesowa takich rozwiązań jest porównywalna: formularze, role, ścieżki akceptacji, oceny, statusy, raportowanie, uprawnienia i archiwizacja. Specyfika grup akademickich może być przedmiotem analizy i konfiguracji na etapie wdrożenia.
Zamawiający nie wyraża zgody na zastąpienie wymogu dotyczącego e-usługi oceny pracowniczej dla pracowników uczelni ogólnym doświadczeniem w zakresie oceny pracowniczej, ankietyzacji, akceptacji lub workflow HR. Zamawiający podtrzymuje wymaganie wykazania doświadczenia obejmującego wdrożenie opartej o platformę LOW-CODE e-usługi realizującej proces oceny pracowniczej dla pracowników naukowo-badawczych, naukowo-dydaktycznych i dydaktycznych uczelni. Zamawiający wskazuje, że proces oceny pracowniczej w publicznej uczelni wyższej nie jest prostym procesem HR ani typową ankietyzacją pracowniczą. Obejmuje specyficzne grupy pracowników, kryteria oceny związane z działalnością naukową, dydaktyczną i organizacyjną, udział określonych organów lub komisji, wieloetapowy obieg, możliwość odwołania, powiązanie z danymi o dorobku naukowym oraz konieczność uwzględnienia wewnętrznych regulacji uczelni. Doświadczenie w realizacji standardowego procesu HR dla dużej organizacji nie daje Zamawiającemu wystarczającej pewności, że wykonawca będzie w stanie prawidłowo zidentyfikować, zaprojektować i wdrożyć proces oceny pracowniczej właściwy dla uczelni wyższej bez nadmiernego zaangażowania po stronie Zamawiającego i bez zwiększenia ryzyka błędów wdrożeniowych.
Czy Zamawiający dopuści doświadczenie członków zespołu projektowego w projektach workflow/BPM/DMS/low-code dla dużych organizacji publicznych lub prywatnych o złożonej strukturze organizacyjnej, zamiast wymogu doświadczenia wyłącznie w projektach „Systemu Informatycznego Uczelni”? Uzasadnienie: Kompetencje kierownika projektu, konsultantów, specjalistów wdrożeniowych i specjalisty ds. ryzyka są przenoszalne między organizacjami o podobnej skali i złożoności.
Zamawiający nie wyraża zgody na zmianę warunku w postulowanym zakresie. Zamawiający podtrzymuje wymaganie, aby osoby skierowane do realizacji zamówienia posiadały doświadczenie w projektach obejmujących dostarczenie i wdrożenie Systemu Informatycznego Uczelni wykonanego w oparciu o Platformę LOW-CODE. Zamawiający wskazuje, że w niniejszym postępowaniu kluczowe znaczenie ma nie tylko ogólne doświadczenie członków zespołu w projektach workflow/BPM/DMS/low-code, ale także ich praktyczna znajomość specyfiki uczelni wyższej. Dotyczy to w szczególności kierownika projektu, konsultanta głównego, specjalistów wdrożeniowych i specjalisty ds. zarządzania ryzykiem wdrożeniowym. Osoby te będą odpowiedzialne za analizę, modelowanie procesów, uzgadnianie rozwiązań z jednostkami uczelni, zarządzanie ryzykiem, komunikację z interesariuszami, testy, szkolenia i wsparcie. Brak doświadczenia w środowisku uczelni mógłby prowadzić do błędnej identyfikacji wymagań, niedoszacowania prac, nieprawidłowego zaprojektowania ról i uprawnień oraz zwiększenia ryzyka niepowodzenia wdrożenia.
Czy Zamawiający potwierdza, że w ramach próbki oferowanej platformy dopuszczalne jest wykorzystanie danych demonstracyjnych oraz symulacji integracji/API, jeżeli rzeczywiste systemy Zamawiającego nie są dostępne dla wykonawców przed złożeniem oferty? Uzasadnienie: Pełne uruchomienie integracji z systemami Zamawiającego może wymagać dostępu do środowisk, konfiguracji, danych, kont technicznych i dokumentacji technicznej, których wykonawcy nie posiadają przed etapem realizacji zamówienia. Dla zapewnienia równego traktowania wykonawców prosimy o potwierdzenie, że w próbce możliwe będzie zaprezentowanie mechanizmu integracyjnego na danych demonstracyjnych lub symulowanym API.
Zamawiający potwierdza, że w ramach próbki oferowanej platformy dopuszczalne jest wykorzystanie danych demonstracyjnych oraz testowych. Jednocześnie Zamawiający wyjaśnia, że dopuszczenie danych demonstracyjnych nie oznacza dopuszczenia prezentacji pozornej, statycznej, opisowej lub multimedialnej. Próbka musi zostać przygotowana z użyciem oferowanej wersji Platformy LOW-CODE i musi umożliwiać praktyczną prezentację działania wymaganych funkcjonalności. W zakresie integracji Zamawiający dopuszcza wykorzystanie symulowanych źródeł danych lub testowych endpointów API, o ile prezentacja pozwoli na rzeczywiste wykazanie mechanizmu integracyjnego oferowanej platformy, w szczególności konfiguracji źródła danych, wywołania usługi, pobrania lub przekazania danych, mapowania danych, obsługi odpowiedzi oraz prezentacji danych w formularzu lub procesie. Zamawiający nie wymaga dostępu do rzeczywistych systemów Zamawiającego przed złożeniem oferty, ale wymaga, aby próbka potwierdzała realne funkcjonalności oferowanej platformy, a nie jedynie deklaracje wykonawcy.
Pokazujemy 8 z 35 pytań. Komplet wyjaśnień — razem z załącznikami, których dotyczą — jest w dokumentacji postępowania.
