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).
Zamówienie obejmuje dostawę platformy low-code, wdrożenie kilkudziesięciu złożonych obiegów w 5 obszarach funkcjonalnych uczelni, integracje z licznymi systemami (ERP, USOS, DSpace, POL-on, PBN, KSeF, ePUAP, e-Doręczenia, AD/Entra), elementy AI/OCR, rozbudowane szkolenia oraz 2-letni serwis z SLA — łącznie duży zakres i wysokie ryzyko wdrożeniowe.
Terminy realizacji
Czas na realizację zamówienia 24 miesiące od dnia zawarcia umowy; Etap 1: 1 mies., Etap 2: 2 mies., Etap 3: 7 mies., Etap 4: 20 mies., Etap 5: 23 mies., Etap 6: 24 mies. od zawarcia umowy; Etap 7: do 24 mies. od Odbioru Końcowego (Etapu 6)
Wymagany okres gwarancji 24 miesiące gwarancji na System + 24 miesiące usługi serwisu od odbioru
Warunki udziału
AI
1Doś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; nie sumować między wykonawcami wspólnymi
2Doś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
Pozostałe 5 warunków po założeniu darmowego konta.
Kryteria wyboru oferty
AI
Wagi punktowe, według których zamawiający oceni oferty.
Cena [C]50 pkt; najniższa cena spośród ofert
50%
Parametry funkcjonalne [T]50 pkt; funkcjonalności dodatkowe z Załącznika nr 2
50%
Czerwone flagi
AI
Sygnały, na które warto zwrócić uwagę przed startem.
Termin składania ofert przypada na okres wakacyjny (20 sierpnia)
Termin w okresie wakacyjnym (lipiec-sierpień) może ograniczać liczbę oferentów ze względu na urlopy.
Kary i sankcje
AI
Zabezpieczenie należytego wykonania:5% ceny brutto oferty.
Kara za zwłokę w realizacji Etapów:0,5% wartości brutto wynagrodzenia za dany Etap za każdy rozpoczęty dzień zwłoki.
Kara za przekroczenie Czasu Naprawy: Awaria — 1 000 zł/godz., Błąd Ważny — 1 000 zł/dzień, Błąd Niski — 500 zł/dzień.
Pozostałe 3 zapisy o karach po założeniu darmowego konta.
Pytania i odpowiedzi
38
Wyodrębnione z wyjaśnień treści SWZ.
1Czy 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.
2Prosimy 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.
3Czy 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.
4Czy 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.
5Czy 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.
6Czy 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.
7Czy 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.
8Czy 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.
Historia zmian
30.06.2026 — ogłoszenie o zamówieniu
03.08.2026 — sprostowanie (Zamawiający przedłuża termin składania ofert z dnia 04.08.2026 r. na dzień 17.08.2026 r., w związku z czym termin otwarcia ofert ulega zmianie z dnia z dnia 04.08.2026 r. na dzień 17.08.2026 r. Godzina terminu składania ofert oraz otwarcia ofert pozostaje bez zmian. Termin związania ofertą ulega zmianie z dnia 01.11.2026 r. na dzień 14.11.2026 r.)
12.08.2026 — sprostowanie (Zamawiający przedłuża termin składania ofert z dnia 17.08.2026 r. na dzień 20.08.2026 r., w związku z czym termin otwarcia ofert ulega zmianie z dnia z dnia 17.08.2026 r. na dzień 20.08.2026 r. Godzina terminu składania ofert oraz otwarcia ofert pozostaje bez zmian. Termin związania ofertą ulega zmianie z dnia 14.11.2026 r. na dzień 17.11.2026 r.)