Ostatnio na forum analizy biznesowej śledziłem wątek dotyczący kaskadowego procesu akceptacji (ang. waterfall acceptance business process) zainicjowanego przez inicjatora w następujący sposób (po przetłumaczeniu): „… sposób zaprezentowania procesu, który zawiera wiele kroków akceptacji wykonywanych przez różnych aktorów biznesowych. Każda z ról (4 lub 5) z występujących w procesie może zaakceptować lub odrzucić (odesłać do poprzedniej roli) dokument. Przebieg procesu nie może zostać zmodyfikowany […] Diagram ma być czytelny…”. Cały wątek znajduje się na forum Modern Analyst.
W powyższym opisie można wskazać następujące elementy:
- inicjator poszukiwał sposobu na prezentację procesu;
- w procesie uczestniczy kilka osobnych osób;
- dokument niezaakceptowany jest odsyłany do poprzedniej roli;
Na poniższym diagramie zaprezentowano (przetłumaczone) dwie propozycje rozwiązania powyższego problemu. Ta po lewej przygotowana została przez inicjatora wątku. Z kolei ta po prawej, została przedstawiona przez jednego z uczestników wątku. Obydwa diagramy przytoczone bez zmian w przebiegu – zaprezentowane w jednorodnej notacji (diagram aktywności UML).
Pierwszy z nich wskazuje wprost do kogo wraca dokument po jego odrzuceniu przez danego uczestnika procesu. Natomiast drugi nie pokazuje tego wprost – wymagane jest zapoznanie się z opisem procesu. Myślę, że nie jest to korzystne, ponieważ proces akceptacji to przede wszystkim przebieg dokumentu między recenzentami/akceptantami i samym inicjatorem. Jednakże zaletą takiego przedstawienia jest uproszczenie diagramu oraz wskazanie, że kolejni uczestnicy (poza inicjatorem) wykonują podobne czynności. Wdrażając rozwiązanie w systemie będą to prawdopodobnie „wywołania” tego samego przypadku użycia. Taki przypadek użycia będzie musiał przede wszystkim „wiedzieć”, gdzie odesłać i gdzie przesłać dalej dokument, a także kiedy zakończyć proces.
Warto sobie zadać pytania:
- dla kogo ma zostać przygotowana prezentacja procesu?
- do czego zostanie wykorzystana prezentacja procesu?
Odpowiedzi na te pytania determinują poziom szczegółowości procesu i sposób prezentacji. Każda z odpowiedzi: „ma pokazywać kto”, „ma pokazywać co” lub „ma pokazywać jak” może wymusić inny sposób prezentacji. Jedyne co wiemy o oczekiwaniach, to wymóg czytelności diagramu. Wydaje się, że diagram po lewej stronie jest bardziej czytelny, dzięki zastosowaniu podziału na „partycje”, wskazanie stanów dokumentów oraz wykonywanych akcji.
Modelowanie procesów biznesowych 
Diagram (oba) dopuszcza pętlę nieskończoną (rozsądek nie jest cecha martwego modelu)…
Zgadzam się. Dlatego też wskazałem, że podczas realizacji takiego procesu w systemie „przypadek użycia będzie musiał przede wszystkim ‚wiedzieć’, gdzie odesłać i gdzie przesłać dalej dokument, a także kiedy zakończyć proces”.
Osobiście uważam, że tu wystarcza trzy kroki:
1.Utwórz dokument (Inicjator)
2.Skonsultuj z recenzentami i akceptantem
3.[gotowe]
Drugi krok ma procedurę mówiąc z kim konsultować, w postaci jak wyżej nie jednej osoby odpowiedzialnej za proces, autor powinien pilnować całości. Drugi krok, recenzji i akceptacji, powinien mieć przerwanie po ustalonym czasie co zapobiegnie pętli nieskończonej.
A jakby się chciało pokazać, kto poprawia dokument po uwagach recenzenta/akceptanta?
Ja staram się takie przypadki modelować tak, że „jakaś osoba” w procesie tworzy dokument i ponosi odpowiedzialność za jego jakość, narzędziem utrzymania jakości jest wymóg konsultacji. To drugie pozostawiam w gestii autora (twórcy) dokumentu, jako narzędzie będzie miał dość powszechny w systemach moduł korespondencji lub innej pracy grupowej. Nic nie stoi na przeszkodzie by dokument był wersjonowany a autorzy uwag „sledzeni”.. w przeciwnym wypadku „płyniemy” w algorytmizację pracy człowieka a to moim zdaniem ślepa uliczka…
[…] procesów biznesowych trochę od innej strony… « Co pokazać na diagramie procesu? Proces akceptacji – sposób sterowania Marzec 5, […]