Jak rozszerzyć możliwości EZD RP?

Automatyzacja zarządzania pracą zespołową z docuRob® WorkFlow

Intelligent Document Engineering sp. z o.o.

(www.docurob.com)

Platforma docuRob® zintegrowana z systemem EZD RP otwiera nowe możliwości automatyzacji w administracji publicznej. Uzupełniamy klasyczny obieg korespondencji o narzędzia usprawniające pracę zespołów, które pomagają realizować zadania terminowo i z zachowaniem rygorystycznych limitów budżetowych.

System doskonale sprawdza się między innymi przy tworzeniu aktów prawnych, planowaniu inwestycji czy nadzorowaniu projektów. Automatyzacja tych procesów gwarantuje sprawną koordynację i pełną kontrolę nad zadaniami zespołu. Wykorzystanie standardu BPMN 2.0 pozwala nie tylko na usprawnienie bieżącej pracy, ale też umożliwia dokładną analizę zaangażowania pracowników. W efekcie instytucje mogą stale optymalizować czas i koszty realizowanych przedsięwzięć.

Wykorzystanie narzędzi zgodnych z międzynarodowymi standardami zarządzania pozwala na płynną integrację z potencjałem sztucznej inteligencji. Platforma docuRob® – dzięki modułom Workflow oraz Object Manager – dostarcza kompletne środowisko narzędziowe do budowy systemów w architekturze procesowej. Taka konstrukcja ułatwia wdrażanie zaawansowanej koordynacji inteligentnych agentów (orchestration) współpracujących z nowoczesnymi modelami AI.

Kluczową rolę odgrywają tu mechanizmy wyszukiwania semantycznego oparte na wektorowych bazach danych. Stanowią one fundament technologii RAG (Retrieval-Augmented Generation), która zasila zapytania do AI precyzyjnymi danymi kontekstowymi. Jakość generowanych odpowiedzi podnosimy dodatkowo poprzez bezpośrednie udostępnianie usług aplikacyjnych modelom LLM. W tym celu platforma docuRob® oferuje wsparcie dla protokołu MCP (Model Context Protocol), zapewniając płynną, kontekstową synergię z systemami sztucznej inteligencji.

Przedstawiony wzorzec wspiera pracę zespołową w instytucjach publicznych i naukowych na przykładzie standardowego procesu publikacji. Jego kluczowym atutem jest automatyczna koordynacja zadań dzięki pełnej integracji z systemem EZD RP. Każdy tworzony dokument automatycznie trafia do repozytorium, co zapewnia kompletną historię sprawy w jednym miejscu.

Model procesu zarządzania pracą grupową

Model procesu pracy grupowej w notacji BPMN 2.0 (Rysunek 1) ilustruje przebieg działań realizowanych na platformie. Wykorzystuje on takie funkcje docuRob®, jak graficzny interfejs użytkownika oraz procesowe zasoby semantyczne zawarte w mapie wiedzy.

Model został opracowany w narzędziu docuRob® Projektant Procesów zgodnym ze standardem BPMN 2.0, stworzonym przez międzynarodową organizację Object Management Group (OMG). Szczegółowy opis narzędzi modelowania i zarządzania procesami znajduje się w dokumentacji platformy (www.docurob.com).

Rysunek 1. Model procesu pracy grupowej Opracowanie publikacji

Operacyjna weryfikacja i czytelność standardu BPMN 2.0

Poziom szczegółowości modelu pozwala na jego operacyjną weryfikację w oparciu o dane rzeczywiste oraz umożliwia prowadzenie uzgodnień analitycznych z użytkownikami na podstawie w pełni funkcjonalnego graficznego interfejsu.

Dzięki metodzie projektowania od lewej do prawej, od góry do dołu model procesu jest przejrzysty i intuicyjny dla odbiorców. Przyjęta konwencja oznaczania ról uczestników kolorami pomaga utrzymać dyscyplinę prezentacji. System opcjonalnie pozwala na budowanie modeli opartych na klasycznej metodzie torów pływackich.

Architektura rozwiązań i właściwości Low-code

System docuRob® WorkFlow umożliwia tworzenie procesów opartych na usługach SOAP lub REST oraz uruchamianie dowolnego oprogramowania. Rolę interfejsu graficznego w zadaniach dla użytkownika (User Task) pełnią elektroniczne formularze docuRob® eForms. Natomiast interaktywne aplikacje zewnętrzne dostarczają własny interfejs użytkownika.

Wykorzystanie właściwości low-code platformy docuRob® pozwala znacząco skrócić czas tworzenia aplikacji. Jest to szczególnie widoczne przy obsłudze procesów wymagających dużej elastyczności i złożonych, dynamicznych interfejsów.

Najpopularniejszą techniką wdrażania rozwiązań w środowisku docuRob® jest wykorzystanie modułu Object Manager jako trwałej pamięci dla danych oraz narzędzia do projektowania dynamicznych formularzy elektronicznych (moduł eForms).

Monitorowanie procesów w czasie rzeczywistym

W ramach bieżącego nadzoru platforma zapewnia dostęp do graficznej historii wykonania każdej instancji procesu.

• Rysunek 2 prezentuje historię zakończonej już instancji omawianego procesu.
• Rysunek 3 przedstawia zrzut ekranu z systemu EZD RP, obrazujący stopniowo narastające akta automatycznie założonej sprawy elektronicznej.

Rysunek 2. Historia wykonania procesu pracy grupowej Opracowanie publikacji

Rysunek 3. Akta sprawy elektronicznej w EZD RP

Przepływy zadań

Podstawowym elementem sterującym przebiegiem prac jest bramka sterowana zdarzeniami. Działa ona w oparciu o stan zmiennej globalnej $step, aktualizowanej przez zadanie Opracowanie przy każdej kolejnej iteracji. Ten prosty, ale niezawodny mechanizm decyduje o kolejności uruchamiania pozostałych zadań funkcjonalnych: Recenzji, Redakcji technicznej oraz Zatwierdzenia opracowania.

Po zakończeniu każdego z tych trzech zadań, pośrednie zdarzenie rzucające Eskalacja uruchamia podproces Dodanie dokumentu z plikami do sprawy EZD RP. Ten podproces, sterowany początkowym nieprzerywającym zdarzeniem eskalacji, pełni kluczową rolę integracyjną i odpowiada za automatyczny zapis dokumentów wraz z załącznikami.

Instancja procesu pracy grupowej pozostaje aktywna przez cały cykl życia koordynowanej przez nią sprawy. W prezentowanym przykładzie proces może opcjonalnie zamknąć sprawę w EZD RP lub zakończyć swoje działanie po odebraniu sygnału o zamknięciu procedury bezpośrednio z systemu EZD RP.

Integracja docuRob® ↔️ EZD RP

Na poziomie modelu procesu dwie automatyczne czynności typu Usługa, powiązane z rolą EZD RP, zapewniają pełną integrację workflow z repozytorium dokumentów. Czynności złożone (Inicjalizacja danych oraz Dodawanie dokumentów do sprawy EZD RP) zaimplementowano jako podprocesy wykorzystujące REST API systemu EZD RP. Pozwala to na ich ponowne użycie jako standardowych komponentów integracyjnych w dowolnych procesach na platformie docuRob® WorkFlow.

Parametry wejściowe i wyjściowe obu tych usług przedstawiają odpowiednio Rysunek 4 i Rysunek 5. Odwołania do API EZD RP na poziomie modelu procesu są automatycznie obsługiwane przez skrypty BPQL z wykorzystaniem zmiennych kontenera danych. Obie te czynności można łatwo przenosić między definicjami różnych procesów za pomocą operacji kopiuj/wklej (wraz z powiązanymi zmiennymi kontenera). Logika biznesowa samej procedury publikacji została graficznie wyodrębniona za pomocą ramki.

Zasada działania integracji

Proces obsługi sprawy elektronicznej może być uruchamiany automatycznie poprzez założenie sprawy w ramach określonej pozycji JRWA lub bezpośrednio z poziomu środowiska webowego docuRob®. Prezentowany model integracji jest zgodny z drugą metodą. W ramach czynności Inicjalizacja danych system automatycznie przygotowuje środowisko oraz zakłada sprawę w EZD RP zgodnie z wyznaczoną pozycją Jednolitego Rzeczowego Wykazu Akt (JRWA). Opcjonalnie proces może również automatycznie utworzyć wpis w odpowiednim rejestrze.

Akta sprawy w EZD RP są zasilane bez udziału człowieka – system na bieżąco dołącza do nich dokumenty powstające w procesie. Pozwala to kadrze zarządzającej na wygodne śledzenie postępów prac bezpośrednio w EZD RP, bez konieczności uruchamiania graficznej reprezentacji procesu w docuRob®.

Rysunek 4. Utworzenie sprawy Opracowanie publikacji w EZD RP

Jak pokazano w tabelach parametrów dla usługi utworzenia sprawy (Rysunek 4) oraz usługi dodania dokumentu (Rysunek 5), wartości zmiennych kontenera procesu nadrzędnego są mapowane jako parametry wejściowe (in) podprocesu. W przypadku parametrów wyjściowych (out), mapowanie realizowane jest w odwrotnym kierunku.

Rysunek 5. Dodanie dokumentu do sprawy Opracowanie w EZD RP

Graficzny interfejs użytkownika

Elektroniczny formularz procesu publikacji (Rysunek 6) zawiera metadane dokumentu oraz wybrane dane strukturalne. Odzwierciedla on kolejne kroki procedury oraz rejestruje dane wprowadzane przez wykonawców.

• Przechowywanie danych: Plik formularza w formacie XML jest trwale zapisywany w repozytorium obiektów modułu docuRob® Object Manager.
• Baza relacyjna: Wybrane atrybuty formularza trafiają do relacyjnej bazy danych.
• Baza wektorowa (AI): Elementy zawartości dokumentów są dzielone na mniejsze fragmenty (chunks) jako rodzaj indeksu (embedding). Umożliwia to wykonywanie semantycznych zapytań przez modele LLM.

Projektowanie formularzy w technologii Low-code

Pełny formularz procesu bywa zbyt skomplikowany, by wyświetlać go na każdym etapie. Główną zasadą projektowania zadań użytkownika jest prezentowanie wyłącznie tych danych, które są niezbędne do wykonania danej operacji.

Aby zachować tę regułę w środowisku low-code, na etapie projektowania formularza dodano mechanizm definiowania jego logicznych obszarów.

Funkcja ta pozwala na selektywne wyświetlanie wybranych widoków w konkretnych zadaniach. Ponadto w ramach GUI użytkownik ma dostęp do listy plików powiązanych z daną instancją procesu i może je wygodnie dodawać, aktualizować lub usuwać.

Wszystkie dane osobowe (Rysunek 6) są odsłaniane dopiero w podprocesie Uzupełnienie danych formularza, sterowanym przez nieprzerywające zdarzenie eskalacji. Formularz może również zostać przekonwertowany do formatu PDF i automatycznie dołączony do akt sprawy elektronicznej prowadzonej w EZD RP.

Rysunek 6. Formularz procesu uzupełniony danymi wykonawców zadań

Rysunek 7 przedstawia cztery wersje interfejsu zadania Opracowanie, które odpowiadają jego kolejnym iteracjom – od rejestracji nowego raportu aż po uzyskanie akceptacji.

Rysunek 7. Interface zadania Opracowanie w 4 różnych odsłonach

Rysunek 8 prezentuje interfejsy następujących po sobie zadań Recenzja i Redakcja techniczna. Warto zauważyć, że na tych etapach dane osobowe poszczególnych wykonawców są celowo ukryte w celu zachowania bezstronności. Na liście plików w zadaniu Recenzja plik będący w trakcie dodawania i wymagający zatwierdzenia jest wyróżniony zielonym tłem.

Rysunek 8. Odpowiednio interfejsy zadań Recenzja i Redakcja techniczna

Ontologia procesu pracy

Zarządzanie ontologią procesów w module docuRob® Ontology Manager oparto na standardzie Topic Maps (ISO/IEC 13250). Służy on do budowy mapy wiedzy (knowledge map) opisującej pojęcia i ich wzajemne relacje. Tak skonstruowana mapa stanowi fundament systemu sterowania procesami. Głównym atutem standardu jest możliwość definiowania dowolnych typów obiektów z unikalnymi zestawami atrybutów, co umożliwia odzwierciedlenie specyfiki praktycznie dowolnej dziedziny.

Na potrzeby integracji z EZD RP wdrożono model mapy wiedzy dopasowany bezpośrednio do wymagań administracji publicznej oraz zarządzania zasobami ludzkimi (HR). Rysunek 9 przedstawia definicję pojęcia Pracownik oraz sieć jego powiązań z innymi elementami ontologii procesu.

Rysunek 9. Metadane użytkownika EZD RP w ontologii docuRob®

**
**

Dynamiczne przypisywanie zadań i reguły biznesowe

Role pracowników są kluczowym kryterium dystrybucji zadań we wzorcu zintegrowanym z EZD RP. Rysunek 10 prezentuje przykładowe role przypisane do jednego z członków grupy roboczej Opracowanie.

Rysunek 10. Role użytkownika w grupie roboczej Opracowanie

Przykłady dynamicznego przypisywania wykonawców za pomocą reguł BPQL prezentuje Tabela 1. Wyrażenia te definiują zbiór pracowników uprawnionych do podjęcia zadania w oparciu o ich rolę (np. autor). Zgodnie z zasadą efektywności, zadanie realizuje ten pracownik, który jako pierwszy pobierze je ze swojej kolejki – w tym momencie zadanie znika z list pozostałych uprawnionych osób.

Zadanie	Nr	Reguła wyboru wykonawcy (BPQL)
Opracowanie	5	UserHasRoleInWorkgroup('autor','100419770') \ WM_Fun_ActivityOwner('7')
Recenzja	7	UserHasRoleInWorkgroup('recenzent','100419770') \ WM_Fun_ActivityOwner('5')
Redakcja techniczna	9	UserHasRoleInWorkgroup('redaktor','100419770') \ WM_Fun_ActivityOwner('5')
Zatwierdzenie opracowania	10	UserHasRoleInWorkgroup('odpowiedzialny','100419770') \ WM_Fun_ActivityOwner('5')

Tabela 1. Reguły zgodności z regulaminem procesu Opracowanie publikacji

Poprzez zastosowanie operacji różnicy zbiorów, drugi człon wyrażenia wprowadza twarde ograniczenie biznesowe, np.: autor opracowania nie może być jednocześnie jego recenzentem. Identyfikator 100419770 wskazuje konkretną grupę roboczą, natomiast numery w nawiasach odpowiadają numerom zadań z modelu procesu (Rysunek 1).

Wdrożenie i wymagania po stronie administratora EZD RP

Warunkiem koniecznym do pełnego wykorzystania mechanizmów automatyzacji zarządzania przebiegiem sprawy jest odzwierciedlenie profili jej uczestników w ontologii systemu docuRob®. Projektowanie ontologii procesu opiera się na informacjach zaimportowanych z EZD RP, które są następnie rozbudowywane o relacje wymagane do skonstruowania mapy wiedzy.

Integracja jest przyjazna dla działów IT. Jedyne zadanie, jakie stoi po stronie administratora systemu EZD RP w instytucji, to jednorazowy eksport danych użytkowników, którzy będą uczestniczyć w sprawach procesowych. Eksport ten powinien zawierać podstawowe informacje o strukturze organizacyjnej i/lub grupach zadaniowych.

Wszystkie pozostałe, zaawansowane elementy modelu – takie jak szczegółowe kompetencje, role projektowe czy zależności służbowe – są konfigurowane i zarządzane bezpośrednio w mapie wiedzy procesu platformy docuRob®.

Podsumowanie korzyści dla Twojej instytucji:

• Automatyczne zasilanie EZD RP – Dokumenty z procesów pracy grupowej automatycznie tworzą akta sprawy w repozytorium EZD RP, zgodnie z JRWA.
• Bezpieczna sztuczna inteligencja – Dzięki bazom wektorowym, architekturze RAG i protokołowi MCP urzędnicy zyskują inteligentnego asystenta, działającego wyłącznie w oparciu o bezpieczny kontekst urzędu.
• Zgodność z przepisami i regulaminami – Reguły BPQL automatycznie pilnują, aby np. autor dokumentu nie mógł być swoim własnym recenzentem.
• Architektura low-code – Szybkie wdrażanie dedykowanych e-formularzy i elastycznych przepływów pracy bez długich i kosztownych projektów programistycznych.

Środowisko użytkownika procesów

Proces pracy może być inicjowany automatycznie w momencie zarejestrowania pierwszego pisma w sprawie przypisanej do właściwej kategorii JRWA lub ręcznie – poprzez wskazanie odpowiedniego typu procesu w bibliotece systemu docuRob® WorkFlow (Rysunek 11). W tym drugim przypadku system automatycznie zakłada powiązaną sprawę.

Rysunek 11. Biblioteka procesów pracy

Dla każdego zarejestrowanego użytkownika system prowadzi dwie powiązane listy zadań. Pierwsza z nich (Rysunek 12) zawiera zadania nowe oraz będące w trakcie realizacji, przypisane do danego pracownika. Druga (Rysunek 13) stanowi ewidencję wszystkich zadań, które zostały już przez niego ukończone.

Rysunek 12. Lista bieżących zadań użytkownika

Rysunek 13. Lista zadań wykonanych przez użytkownika

Kliknięcie wybranego zadania wyświetla daty jego utworzenia i wykonania oraz kontekst całej instancji procesu, zilustrowany za pomocą graficznego modelu historii wykonania.