13 Własny proces wykonywalny

Efekty uczenia się: U1, U4, U5, K2 · Treści programowe: 9, 11 · Czas: Nauka 35 min, Wyzwanie 55 min

13.1 Nauka

Od gotowego przykładu do własnego procesu

Na spotkaniu 12 uruchomiłeś proces, który ktoś przygotował za Ciebie. Teraz zaczynasz projekt Z4: własny proces wykonywalny wraz z pisemnym opisem procedury. Projekt zajmie trzy spotkania:

Spotkanie	Co powstaje
13	inwentarz procesów instytucji, wybór procesu, opis w tabeli kroków, pierwsza wykonywalna wersja modelu przygotowana z agentem
14	testy wszystkich ścieżek w Camunda 8 Run, analiza zmian w otoczeniu, opis procedury
15	prezentacja projektu i oddanie zadania Z4

Projekt łączy wszystko, czego nauczyłeś się w kursie: opis procesu, notację BPMN i DMN, analizę, pracę z agentem i silnik procesów.

Inwentarz procesów

Zanim wybierzesz proces, spójrz na instytucję szerzej. Inwentarz procesów (process inventory, także process architecture) to uporządkowana lista procesów organizacji. Odpowiada na pytanie: „jakie procesy w ogóle mamy, kto za nie odpowiada i które z nich są opisane?”. Dla instytucji informacyjnej inwentarz jest częścią zarządzania wiedzą instytucjonalną. Pokazuje, gdzie wiedza o pracy jest spisana, a gdzie istnieje tylko w głowach pracowników.

Najprostszy inwentarz to tabela:

Kolumna	Co wpisujesz	Przykład (biblioteka uczelniana)
proces	nazwa: czynność i jej przedmiot	Gromadzenie zbiorów: propozycja zakupu
grupa	proces podstawowy, wspierający albo zarządczy	podstawowy
właściciel	rola odpowiedzialna za proces	kierownik Oddziału Gromadzenia
odbiorca i wynik	kto dostaje wynik i jaki	czytelnik: książka dostępna w katalogu
wejście	co uruchamia proces	propozycja czytelnika
systemy i rejestry	z czego korzysta	system biblioteczny, katalog, budżet
poziom modelu	brak, opisowy, analityczny, wykonywalny	analityczny
ostatni przegląd	kiedy sprawdzono, czy model jest aktualny	październik

Procesy podstawowe dostarczają wynik odbiorcy instytucji (wypożyczenie, kwerenda, udostępnienie). Wspierające umożliwiają pracę podstawowym (zakupy, kadry, IT). Zarządcze kierują instytucją (planowanie budżetu, audyt, przegląd jakości). Już samo zestawienie bywa odkryciem: często okazuje się, że najważniejsze procesy nie mają żadnego opisu, a opisane są te, które kiedyś wymagał audyt.

Jak wybrać proces do projektu

Z inwentarza wybierz jeden proces, który spełnia poniższe warunki. Dzięki nim projekt będzie wykonalny w trzy spotkania, a jednocześnie pokaże pełny zakres kursu.

Warunek	Dlaczego
proces informacyjny w instytucji, którą znasz albo możesz poznać z dokumentów (regulamin, procedura, rozmowa)	opis musi być wiarygodny
8–15 kroków, co najmniej trzy role (linie)	mniejszy proces nie pokaże współpracy, większy nie zmieści się w czasie
co najmniej jedna decyzja według reguł, które da się zapisać w tabeli	tabela DMN i zadanie reguły biznesowej
co najmniej jeden termin	zdarzenie czasowe, zwykle graniczne
co najmniej dwa zadania użytkownika z formularzem	praca w Tasklist
co najmniej dwa różne zakończenia	testy różnych ścieżek
bez danych osobowych prawdziwych osób	w opisie, formularzach i testach używasz danych fikcyjnych

Dobre przykłady: rezerwacja sali w bibliotece, udostępnienie materiałów archiwalnych, przyjęcie daru do zbiorów, zgłoszenie błędu w opisie katalogowym, wniosek o dostęp do bazy danych, zgłoszenie publikacji do repozytorium, wypożyczenie sprzętu wydziałowego. Nie wybieraj procesu z laboratorium ani przykładu z rozdziału 12.

Role, kompetencje i ludzie w procesie

Linie w modelu to role, ale za rolami stoją konkretni ludzie z kompetencjami. Na spotkaniu 4 mówiliśmy o „bohaterach”: osobach, do których wszyscy przychodzą z pytaniami, bo tylko one wiedzą, jak załatwić nietypową sprawę. W modelu wykonywalnym to pytanie wraca w praktycznej postaci: kto dostanie zadanie w Tasklist?

Camunda pozwala przypisać zadanie użytkownika do osoby (assignee) albo do grupy kandydatów (candidate groups), np. „gromadzenie” albo „kierownicy”. Przypisanie do grupy odpowiada linii w modelu. Przy projektowaniu odpowiedz na trzy pytania:

Czy zadanie może wykonać każdy członek grupy, czy tylko osoba o szczególnych kompetencjach (np. znajomość języka, uprawnienia do danych osobowych)?
Czy ta sama osoba nie wykonuje dwóch kroków, które powinny być rozdzielone (zasada dwóch par oczu z rozdziału 8)?
Co się stanie, gdy jedyna kompetentna osoba jest na urlopie? Czy proces ma na to odpowiedź (termin, eskalacja, zastępstwo)?

W projekcie wystarczy, że opiszesz te decyzje w opisie procedury. Na Camunda 8 Run zalogowany użytkownik demo widzi wszystkie zadania, więc przypisania do grup nie są potrzebne do testów.

Opis procesu dla agenta

Projekt prowadzisz w pakiecie bpmn-agent, który znasz z rozdziałów 10 i 11. Skill bpmn-modelowanie ma tryb dla Camunda 8: zna rozszerzenia zeebe:, formularze i tabele decyzyjne, a polecenie tok check sprawdza model opcją --camunda.

Opis procesu zapisujesz w pliku projekt/opis.md. Szablon ma tabelę kroków z dodatkową kolumną Dane oraz dwie sekcje: reguły decyzyjne i formularze. Od jakości opisu zależy jakość modelu. Agent nie wie nic o Twojej instytucji poza tym, co napiszesz. Dobre opisy:

mówią, w jakim systemie i w jakim terminie wykonywany jest krok;
przy decyzji podają reguły, a nie tylko „kierownik decyduje”;
przy każdym kroku w systemie wymieniają pola formularza i ich typ;
nie nazywają elementów BPMN wprost, tylko opisują sytuację tak jak w laboratorium.

Praca z agentem nad modelem wykonywalnym

Polecenie dla agenta jest w pliku PROMPT-Z4.md. Prosi o pięć plików w folderze projekt/: mapowanie, model, tabelę decyzyjną i formularze. Agent ma używać zadań skryptowych zamiast usługowych i sprawdzać model poleceniem tok check w trybie --camunda, aż walidacja zgłosi 0 błędów.

Pętla pracy jest taka sama jak w laboratorium, ale z jednym dodatkowym krokiem. Model nie tylko musi być poprawny w notacji. Musi też działać w silniku:

agent przygotowuje pliki i sprawdza je poleceniem tok check;
Ty czytasz projekt/mapowanie.md i porównujesz je z opisem, jak w recenzji z rozdziału 11;
Ty wdrażasz pliki w Camunda Modeler i uruchamiasz jedną instancję;
jeśli coś nie działa (incydent w Operate, brak formularza, zła ścieżka), opisujesz agentowi objaw i miejsce: „Zadanie »Akceptacja wniosku« nie ma formularza w Tasklist. Sprawdź formId.”;
każde polecenie dopisujesz do prompty.md.

Formularze i tabelę decyzyjną możesz też poprawiać samodzielnie w Camunda Modeler: ma edytor formularzy (plik typu Form (Camunda 8)) i edytor tabel DMN. Często tak jest szybciej niż przez agenta. Po zmianie w Modelerze uruchom ponownie tok check z opcją --camunda, żeby sprawdzić spójność identyfikatorów.

Czego agent nie zrobi za Ciebie

Agent przygotuje pliki szybciej niż Ty. Nie wie jednak, czy proces wygląda tak w Twojej instytucji, czy reguły w tabeli są zgodne z regulaminem i czy formularz pyta o dane, które naprawdę są potrzebne. Ocenia to autor projektu. Dlatego w ocenie Z4 liczą się przede wszystkim opis, testy, opis procedury i uzasadnienie decyzji, a nie samo to, że model się wdraża.

13.2 Wyzwanie

Polecenie: wybierz proces do projektu Z4 i doprowadź go do pierwszej wersji, która wdraża się do Camunda 8 Run i przechodzi jedną ścieżką od startu do końca.

Dane wejściowe: pakiet bpmn-agent (szablon projekt/opis.md, polecenie PROMPT-Z4.md), działający Camunda 8 Run.

Kroki:

Sporządź inwentarz 4–6 procesów wybranej instytucji (tabela z części Nauka) w pliku projekt/inwentarz.md.
Wybierz z niego jeden proces spełniający warunki projektu. Uzasadnij wybór w dwóch zdaniach pod tabelą.
Wypełnij projekt/opis.md: tabela kroków z kolumną Dane, reguły decyzyjne, pola formularzy.
Uruchom agenta w folderze bpmn-agent i wklej polecenie z PROMPT-Z4.md. Zapisuj polecenia w prompty.md.
Przeczytaj projekt/mapowanie.md i popraw błędne decyzje agenta.
Wdróż pliki w Camunda Modeler i przeprowadź jedną sprawę przez Tasklist.

Rezultat: folder projekt/ z plikami inwentarz.md, opis.md, mapowanie.md, proces.bpmn, proces.svg, decyzja.dmn, plikami .form oraz prompty.md w folderze pakietu. Polecenie tok check projekt/proces.bpmn --camunda --lang pl zgłasza 0 błędów.

Praca: indywidualnie. Prowadzący konsultuje wybór procesu w pierwszych 20 minutach.

Czas: 55 minut. Pracę dokończ przed spotkaniem 14.

Na co zwrócić uwagę

Zanim wkleisz polecenie agentowi, przeczytaj swój opis tak, jakbyś nie znał instytucji. Czy z opisu wynika, kto i w jakim systemie wykonuje każdy krok?
Nazwy pól w formularzach i nazwy zmiennych w warunkach muszą być identyczne. zgoda i Zgoda to dla silnika dwie różne zmienne.
Jeśli agent mimo polecenia użył zadania usługowego, tok check zgłosi uwagę C021. Poproś o zamianę na zadanie skryptowe albo użytkownika.
Do testów używaj fikcyjnych danych: „Jan Testowy”, „Biblioteka Przykładowa”.

13.3 Pytania sprawdzające

Czym różnią się procesy podstawowe, wspierające i zarządcze? Podaj po jednym przykładzie z archiwum.
Jakie informacje o procesie powinien zawierać inwentarz? Dlaczego jest on narzędziem zarządzania wiedzą instytucjonalną?
Po co w opisie procesu dla agenta kolumna „Dane”? Co się stanie w silniku, jeśli nazwa pola w formularzu będzie inna niż nazwa zmiennej w warunku?
Jakie pytania o role i kompetencje warto zadać przy przypisywaniu zadań użytkownika do grup?
Które elementy projektu Z4 może przygotować agent, a za które odpowiada wyłącznie autor projektu?