Niniejszy opis ma na celu wsparcie Partnerów EZD RP podczas analizy procesu, która stanowi pierwszy etap wdrażania procesów biznesowych w module BPMN EZD RP.
Wdrażanie procesów w Module BPMN to doskonała okazja do oceny procesów realizowanych w organizacji pod kątem ich zasadności i efektywności. Wypracowane dzięki temu zmiany mogą wprowadzić nowy ład funkcjonalny w organizacji. Dlatego ważne jest, aby inicjatywa miała wyraźne poparcie kierownictwa jednostki organizacyjnej.
Czy procesowość w EZD RP jest potrzebna organizacji?
EZD RP dostarcza użytkownikom funkcje, które kompleksowo wspierają większość potrzeb biznesowych organizacji w zakresie elektronicznego zarządzania dokumentacją, w tym przepływu informacji w organizacji i poza nią czy wspomagania procesu decyzyjnego.
Zaawansowana procesowość w EZD RP stanowi odpowiedź na złożone potrzeby biznesowe Partnerów EZD RP, które nie mogą być zaspokojone przy wykorzystaniu standardowych funkcji. Wykorzystanie modułu BPMN powinno zatem wynikać ze świadomej decyzji, poprzedzonej analizą procesu i próbą osiągnięcia oczekiwanych rezultatów za pomocą standardowych narzędzi dostępnych w EZD RP.
Co może wskazywać na potrzebę zastosowania modułu BPMN?
Istnieje kilka wskazówek, które w trakcie wykonywania analizy procesu mogą sugerować potrzebę zastosowania modułu BPMN. Należą do nich m.in.:
- orientacja na realizację celu biznesowego, funkcjonalność i automatyzację realizowanych spraw;
- potrzeba zbudowania dynamicznego formularza do zbierania informacji w procesie;
- warunkowość przepływu, czyli sytuacja, gdy przebieg ścieżki obiegu zależy od jakiegoś warunku, np. od kwoty zamówienia publicznego (poniżej progu – ścieżka uproszczona, powyżej kolejnych progów – odpowiednio rozbudowane obiegi) lub decyzji (np. potrzeba obsługi wniosku negatywnie zaopiniowanego);
- chęć odkładania informacji zbieranych w procesie do rejestru (potrzeba analizy tych danych).
Zespół projektowy
Po ustaleniu potrzeby utworzenia procesu w EZD RP, należy każdorazowo wyznaczyć zespół pracowników do realizacji inicjatywy. Analiza procesu powinna być przeprowadzana z udziałem jak najszerszego grona konsultantów.
Kluczowi uczestnicy procesu analitycznego, zgodnie z ich rolami i posiadanymi kompetencjami, to:
- projektanci/koordynatorzy procesu – odpowiadają za stworzenie składowych schematu procesu i uruchomienie samego Schematu procesu, od projektantów oczekuje się umiejętności analitycznych oraz znajomości BPMN 2.0;
- właściciele procesu, czyli osoby mające wiedzę o procesie jako całości – są głównymi dostawcami wiedzy o procesie, odpowiedzialni są za potwierdzenie zgodności wdrożonego Schematu z oczekiwaniami;
- przedstawiciele uczestników procesu – dostarczają szczegółowej wiedzy o etapach procesu, wskazują zakres informacyjny procesu;
- dostawcy danych referencyjnych (źródłowych informacji) dla procesu – mają informacje o tym gdzie i w jaki sposób są gromadzone dane źródłowe oraz w jakim trybie są aktualizowane;
- odbiorcy produktów wytwarzanych w procesie, np. osoby przetwarzające dane zebrane w rejestrze dla procesu na potrzeby statystyk i analiz – rozszerzają zakres informacyjny procesu i wskazują jego otoczenie;
- pracownicy mający kompetencje techniczne – są niezbędni do osiągnięcia bardziej złożonej funkcjonalności modułu BPMN, która wymaga przynajmniej podstawowej znajomości JavaScript, Groovy, HTML i innych technologii.
Dobór członków zespołu
Definiowanie procesu
Pierwszym etapem prac przy wdrażaniu procesów organizacji w ramach modułu BPMN w EZD RP jest analiza procesu. Dobra analiza powinna obejmować opis procesu, określenie jego celu, zakresu i cech, a także jego składowych i ich wzajemnych powiązań. Poziom złożoności analizy powinien być dostosowany do poziomu złożoności procesu (ma tu zastosowanie zasada skalowalności).
Podczas analizy procesu należy w sposób możliwie szczegółowy określić co najmniej te czynniki, które zostały wymienione na poniższej liście.
- Oczekiwania wobec procesu – należy określić, jakie wartości dostarczy nam proces i skąd będziemy wiedzieć, że zbudowaliśmy taki proces, jakiego oczekiwaliśmy. Konieczne jest też ustalenie, czego nam brakuje w obecnym funkcjonowaniu procesu i czy możemy to uzyskać (np. powiadomienie e-mailowe osoby wnioskującej o ostatecznym rezultacie).
- Zakres procesu – konieczne jest określenie, jaki jest zakres procesu: w którym momencie się zaczyna i kiedy się kończy, czy ma swoją kontynuację, jakie są jego związki z innymi procesami i czy można podzielić go na etapy.
- Uczestnicy procesu – istotnym czynnikiem jest zidentyfikowanie wszystkich ról w procesie. Ważniejsze jest określenie ról (funkcjonalnie) niż personalnych uczestników. Osoby mogą występować w kilku rolach – każdorazowe ich pojawienie się w procesie powinno być odnotowane.
- Scenariusz procesu – należy określić, co uruchamia proces (np. wpływ skargi, wniosek o urlop itp.), a także kto i jakie czynności wykonuje w procesie (przepływ pracy – workflow). Następnie konieczne jest ustalenie, jakie są warunki przepływu i kiedy występują, tzn. kiedy i na jakiej podstawie dochodzi do zmiany ścieżki przepływu – np. na podstawie wartości zamówienia (progów kwotowych) proces kierowany jest na uproszczoną lub rozbudowaną ścieżkę akceptacji. Należy też określić, jakie i kiedy oczekiwane są zautomatyzowane aktywności systemu (zapis do rejestru informacji z procesu, dołączenie załączników z procesu do sprawy itp.). Ustalamy też, w którym momencie proces się kończy. W zdefiniowaniu scenariusza procesu pomocne są obowiązujące w organizacji regulaminy i procedury postępowania – należy się do nich odwołać w analizie.
- Zakres informacyjny procesu – aby zbudować formularz, musimy wiedzieć, jakimi informacjami wypełniać go będą uczestnicy procesu na każdym jego kolejnym etapie. Jeżeli od uczestnika procesu oczekiwana jest jakaś aktywność (np. decyzja), należy na formularzu stworzyć mu przestrzeń do jej zrealizowania (np. lista wyboru, przycisk itp.). W związku z tym, że rejestr tworzony jest na podstawie formularza, trzeba w nim odzwierciedlić oczekiwane pola rejestru (jeśli będą inne niż te dla użytkowników). Jeżeli chcemy informacje z procesu umieszczać na dokumencie PDF – najłatwiej je wprowadzić jako zmienne formularza. Warto odwołać się do istniejących dokumentów, takich jak wzory wniosków i formularze. Należy także zidentyfikować powiązania z innymi systemami, które mogą dostarczyć dane, np. systemy ewidencyjne, co zredukuje błędy i usprawni pracę.
- Automatyzacja, optymalizacja, rozwój – należy sprawdzić, czy proces można uprościć, zreorganizować, zautomatyzować, a także określić obszary do potencjalnego rozwoju, zmiany.
Rekomendowane jest udokumentowanie analizy, aby stanowiła punkt wyjścia dla prac analitycznych projektantów. W toku prac projektowych dokument powinien być aktualizowany o konkretne ustalenia realizacyjne. Forma opracowania jest dowolna, powinna być jednak przejrzysta i zrozumiała dla wszystkich uczestników procesu analitycznego.
Metoda PDSA i przeglądy procesów
Po analizie procesu jest odzwierciedlenie ustaleń w Składowych schematu procesu i skonstruowanie samego Schematu Procesu. Szczegółowe informacje można znaleźć tutaj. Scenariusz procesu zostanie przede wszystkim przedstawiony na diagramie BPMN, natomiast zakres informacyjny w formularzu.
Zalecanym podejściem do pracy z wdrażanymi w module BPMN Schematami Procesów jest metoda PDSA (Plan-Do-Study-Act). Obejmuje ona następujące etapy:
- Plan (P) – planowanie
- Do (D) – wykonanie
- Study (S) – analiza rezultatów
- Act (A) – reagowanie na nieprawidłowości
Regularne przeglądy wdrożonych procesów i reagowanie na odstępstwa od zakładanych celów są kluczowe. W razie wykrycia nieprawidłowości należy wrócić do etapu analitycznego.
Celem wdrażania procesów w module BPMN EZD RP jest wsparcie i usprawnienie realizowanych w organizacjach procesów. Przy budowaniu Schematów Procesów należy mieć na uwadze te wartości.