Dostawa i wdrożenie systemu obiegu dokumentów – Poznań
Pełna nazwa postępowania: Dostawa i wdrożenie oprogramowania wspierającego zarządzanie obiegiem dokumentów w Uniwersytecie Przyrodniczym w Poznaniu
Uniwersytet Przyrodniczy w Poznaniu·NIP 7770004960·Poznań
Wartość szac.
—
nie podano
Termin składania
20.08.2026
postępowanie zakończone
Otwarcie ofert
—
nie podano
Opublikowano
11 sierpnia 2026
źródło: TED
Streszczenie SWZ
Streszczenie AI · Janusz
Widzisz połowę każdej z 10 sekcjiDruga połowa — łącznie 22 zdania z warunkami, dokumentami i analizą ryzyka — odsłania się po założeniu darmowego konta.
Wartość zamówienia: powyżej 216 000 euro (próg unijny dla procedury). - Źródło finansowania: Europejski Fundusz Społeczny Plus, Program Fundusze Europejskie dla Rozwoju Społecznego, projekt „Studiuj dla klimatu! (+ 1 zdanie — pełna treść po zalogowaniu)
Doświadczenie – System LOW-CODE dla uczelni: min. 2 wdrożenia Systemu Informatycznego Uczelni opartego o oferowaną Platformę LOW-CODE, każde dla ≥ 1 000 użytkowników, z integracją bazodanową, szkoleniami i wsparciem, wartość każdego ≥ 2 000 000 zł brutto, z ostatnich 3 lat.
Doświadczenie – integracja DSpace: min. 3 zamówienia dla uczelni obejmujące integrację DSpace z systemami uczelni (CAS/AD) oraz z PBN i POL-on przez PBN REST API 2.0, z ostatnich 3 lat.
Doświadczenie – ocena pracownicza: min. 1 wdrożenie e-usługi oceny pracowniczej (platforma LOW-CODE) dla grup naukowo-badawczych, naukowo-dydaktycznych i dydaktycznych, wartość ≥ 500 000 zł brutto, z ostatnich 3 lat; nie sumować między wykonawcami.
Kadra – Kierownik Projektu: kierowanie min. 2 wdrożeniami Systemu Informatycznego Uczelni (LOW-CODE) o wartości ≥ 1 000 000 zł brutto każde; wykształcenie wyższe, biegła polski, certyfikat Prince 2 Practitioner / IPMA C (lub równoważny).
Formularz wymagań funkcjonalnych — OPZ, w tym formularz wymagań obligatoryjnych, formularz wymagań opcjonalnych i Wykaz elementów ICT (Załącznik nr 2 do SWZ).
Próbka oferowanej Platformy LOW-CODE — sprzęt z przygotowanym środowiskiem Platformy, składana z pominięciem środków komunikacji elektronicznej do Kancelarii Ogólnej Zamawiającego (Rozdział 11 pkt 7 i Rozdział 18 pkt 1 lit. c; opis w Rozdziale 18A).
Z każdej z 10 sekcji pokazujemy połowę. Załóż darmowe konto, żeby odsłonić pozostałe 22 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
Zamówienie jednoczęściowe — dostawa i wdrożenie Systemu Elektronicznego Zarządzania Dokumentacją (EZD) opartego na platformie low-code w wersji COTS, w Uniwersytecie Przyrodniczym w Poznaniu. W ramach zamówienia:
Dostawa licencji platformy low-code (bez ograniczeń czasowych i terytorialnych, dla nieograniczonej liczby użytkowników) wraz z oprogramowaniem niezbędnym do działania systemu, instalacja i konfiguracja środowisk DEV/TEST/PROD.
Analiza przedwdrożeniowa (w tym analizy biznesowe) dla 5 obszarów: administracyjny (struktura organizacyjna), studencki, kadrowy, finansowy i kancelaryjny.
Wdrożenie i konfiguracja obiegów i procesów (ok. 60 odrębnych obiegów), w tym m.in.:
obszar urlopów i wniosków rodzicielskich (ok. 16 obiegów),
wnioski socjalne (ZFŚS — ok. 4 obiegi),
praca zdalna (ok. 7 obiegów),
eTeczka pracownicza z 4 kategoriami (A, B, C, D) + część E,
portal pracowniczy,
umowy (UOP, aneksy, skierowania na badania, kwestionariusze, zgłoszenia działalności gospodarczej — ok. 5 obiegów),
ocena pracownicza (nauczyciele akademiccy oraz pracownicy administracyjni/inżynieryjno-techniczni/obsługi — ok. 3 obiegi + integracja z DSpace, POL-on, PBN),
obiegi kadrowe (dodatki, oddelegowania, prawa autorskie, staże, wynagrodzenia projektowe — ok. 6 obiegów),
obszar finansowy: budżety, zamówienia publiczne, dokumenty kosztowe z KSeF, OCR AI, wnioski o fakturę sprzedażową,
kancelaria (poczta zewnętrzna wychodząca/przychodząca tradycyjna, e-Doręczenia, ePUAP; poczta wewnętrzna; sprawy z KPA; baza kontrahentów — ok. 5 obiegów),
delegacje krajowe i zagraniczne (rejestracja, zaliczki, rozliczenie, diety, kilometrówka),
procesy HR (przyjęcia/odejścia, szkolenia, wnioskowanie o zatrudnienie, ewidencja czasu pracy),
struktura organizacyjna (jednostki, pracownicy),
obszar studencki (podania o fakturę, odwołania od decyzji, zaświadczenia, stypendia, praktyki, eTeczka studencka A/B/C/D, zapobieganie drop-out'owi).
Integracje z systemami: Microsoft Dynamics 365 (ERP, w modelu chmurowym), USOS 7.3 (Oracle, on-premise), DSpace v7, POL-on, PBN (REST API 2.0), Microsoft Exchange/Exchange Online, Active Directory + Azure AD/Entra + MS Graph, KSeF, e-Doręczenia, ePUAP, podpis elektroniczny/kwalifikowany, MS Teams, MS OneDrive, MS SQL Server.
Migracja, konfiguracja słowników, prototypowanie procesów, OCR/IDP z elementami AI (sieci neuronowe, samouczenie formatów faktur), kody QR i kreskowe, MS Fluent 2, wsparcie WCAG 2.1.
Szkolenia prowadzone w języku polskim (warsztatowo, z materiałami i nagraniami): minimum 60 dni szkoleniowych dla użytkowników kluczowych + minimum 6 dni dla administratorów (dopuszczalne online po zgodzie Zamawiającego lub stacjonarnie/hybrydowo).
Dokumentacja powykonawcza oraz instrukcje użytkownika.
24-miesięczna gwarancja i 24-miesięczny serwis (Etap 7 — prace rozwojowe i wsparcie powdrożeniowe, w tym system pomocy technicznej, czas reakcji: awaria 2 h / błąd ważny 8 h / błąd niski 24 h; czas naprawy: odpowiednio 8 h / 24 h / 72 h).
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. Ograniczenie doświadczenia wyłącznie do uczelni może nie być proporcjonalne do zakresu zamówienia, który obejmuje szeroko rozumiane procesy obiegu dokumentów, integracje, konfigurację, testy i wsparcie.
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.
Pokazujemy 7 z 12 pytań. Komplet wyjaśnień — razem z załącznikami, których dotyczą — jest w dokumentacji postępowania.
