Artykuły

BPMstandard.pl używa cookies.

Brak zmiany ustawienia przeglądarki oznacza Twoją zgodę.

Zrozumiałem
07Kwi2016

Poglądowe i wykonywalne modele procesów biznesowych

modele procesow biznesowych pogladowe wykonywalnePierwsze podejście do modelowania procesów zwykle polega na opracowaniu modelu poglądowego. Jest to model wysokopoziomowy, pokazujący złożone czynności i przepływy sterowania pomiędzy nimi. Celem takiego modelu jest uzyskanie ogólnej orientacji w przebiegu procesu, dlatego czynności w takim modelu zwykle nie są dekomponowane do poziomu atomowych akcji. Nie przedstawia się też zwykle w takim modelu wszystkich możliwych ścieżek alternatywnych i wyjątkowych.

Poglądowy model procesu biznesowego

Przykład poglądowego modelu procesu jest przedstawiony na Rysunku 1.

pogladowy model procesu

Rysunek 1. Poglądowy model procesu obsługi zgłoszeń

Poglądowy model procesu jest często opracowywany na etapie wstępnej analizy biznesowej, gdy nasza wiedza o przyszłym systemie ogranicza się do tego, że system ma wspierać pewne procesy biznesowe (w naszym przykładzie – proces obsługi zgłoszeń), natomiast nie wiemy, w jaki sposób (jakimi funkcjonalnościami) system ma te procesy wspierać. Opracowanie modelu poglądowego może ułatwić określenie, które czynności w procesach będą wykonywane całkowicie automatycznie, które przez człowieka ze wsparciem systemu, a które całkowicie ręcznie, poza systemem. Można to zrobić w samym modelu, określając typy czynności BPMN. 

elementy bpmn

Rysunek 2. Wybrane typy czynności w BPMN

Na Rysunku 3 przedstawiony jest model procesu obsługi zgłoszeń, w którym poszczególne czynności zostały zaklasyfikowane jako ręczne, użytkownika i automatyczne.

proces obslugi zgloszen

Rysunek 3. Proces obsługi zgłoszeń z określonymi typami czynności

Zgodnie z tym modelem:

  • obsługa problemu na 1. i 2. linii wsparcia będzie wspierana przez system informatyczny, który musi oferować odpowiednie funkcje umożliwiające taką obsługę,
  • konsultacje 2. linii wsparcia z produkcją oprogramowania będą prowadzone poza systemem – zapewne telefonicznie, mailowo lub w formie spotkań i rozmów,
  • jeśli 2. linia wsparcia stwierdzi, że konieczna jest poprawka oprogramowania, zamówienie tej poprawki zostanie zgłoszone automatycznie (na podstawie danych wprowadzonych w ramach czynności „Obsługa problemu na 2. linii wsparcia”),
  • przekazanie rozwiązania klientowi będzie czynnością użytkownika, ponieważ 1. linia wsparcia musi opisać rozwiązanie problemu w sposób zrozumiały dla klienta.

Taki model jest już całkiem niezłą podstawą do zaprojektowania funkcjonalności systemu np. w formie przypadków użycia w języku UML lub w postaci procesu wykonywalnego.

Wykonywalny model procesu biznesowego

Wiele systemów informatycznych obecnie projektuje się w oparciu o tzw. silniki przepływu prac. Aby taki silnik mógł funkcjonować, trzeba w nim skonfigurować schematy procesów. Zauważmy jednak, że proces pokazany na Rys. 3 nie nadaje się do automatycznego uruchomienia choćby z tego powodu, że zawiera czynności wykonywane poza systemem. Poglądowy model procesu trzeba zatem „przetłumaczyć” na model wykonywalny, który nadaje się do uruchomienia w silniku przepływu prac.

Silnik przepływu prac (ang. workflow engine) – uniwersalny moduł systemów informatycznych, sterujący przepływem pracy w systemie zgodnie ze skonfigurowanymi schematami procesów. Silnik przepływu prac komunikuje się z uczestnikami przepływu, przekazując im kolejne zadania do wykonania, a także w razie potrzeby wywołuje inne aplikacje.

Podstawowym mechanizmem pracy użytkownika w systemie opartym o silnik przepływu prac jest tzw. lista zadań. Użytkownik pobiera z listy zadań kolejne zadania przeznaczone do wykonania przez niego (zgodnie z konfiguracją procesu) i wykonuje je np. przy pomocy dedykowanego formularza ekranowego. Po zakończeniu wykonania zadania silnik przepływu prac kontynuuje proces zgodnie z jego konfiguracją, np. generując kolejne zadanie dla innego użytkownika.

proces obslugi zgloszen wykonywalny

Rysunek 4. Proces obsługi zgłoszeń w postaci wykonywalnej

Proces obsługi zgłoszeń w postaci wykonywalnej jest przedstawiony na Rysunku 4. Zwróćmy uwagę na następujące różnice w stosunku do modelu poglądowego przedstawionego na Rysunku 3:

  • Proces nie zawiera czynności wykonywanych poza systemem, oznaczonych w modelu poglądowym jako „ręczne”.
  • Proces nie zawiera basenu „Klient” ani toru „Produkcja oprogramowania”, ponieważ klienci pracownicy produkcji nie są bezpośrednimi użytkownikami systemu.
  • Nazwy czynności są sformułowane w trybie rozkazującym. Jest to istotne przede wszystkim odnośnie czynności „użytkownika”, ponieważ ich nazwy będą wyświetlane w interfejsie użytkownika systemu jako nazwy zadań do wykonania. Jednak dla zachowania spójności na tryb rozkazujący zmieniono także nazwy czynności automatycznych.
  • Wysłanie rozwiązania zostało zamodelowane jako zdarzenie wywołujące i oddzielone od czynności przygotowania opisu rozwiązania.
  • Czynność „Opisz rozwiązanie” została umieszczona tylko na ścieżce wracającej z 2. linii wsparcia, aby 1. linia wsparcia mogła „przetłumaczyć” techniczny opis opracowany przez 2. linię wsparcia na język biznesowy. Jeśli problem został rozwiązany samodzielnie przez 1. linię wsparcia, opis rozwiązania dla klienta powstaje już w czynności „Obsłuż zgłoszenie (1. linia wsparcia)”.
  • Jeśli w ramach wykonania czynności użytkownik podejmuje jakąś decyzję (np. samodzielnie rozwiązać problem na 1. linii wsparcia, czy przekazać go do 2. linii wsparcia), to taka decyzja jest zamodelowana jako bramka wykluczająca bezpośrednio po czynności, w której następuje decyzja. Ścieżki wychodzące z takiej bramki (np. „problem rozwiązany” i „przekaż do 2. linii wsparcia”) będą widoczne w interfejsie użytkownika na ekranie wykonania zadania jako możliwe opcje jego zakończenia (np. przyciski ekranowe).
  • Uszczegóławiając model poglądowy, dodano możliwość powrotu do 2. linii wsparcia, jeśli rozwiązanie przedstawione przez 2. linię wsparcia jest nie akceptowane przez 1. linię wsparcia.

Przekształcenie modelu poglądowego w wykonywalny

Jak pokazuje powyższy przykład, przekształcenie modelu poglądowego w wykonywalny nie jest czynnością trywialną i z reguły nie daje się zautomatyzować. W trakcie przekształcania wprowadza się zwykle dodatkowe optymalizacje oraz nowe ścieżki przebiegu procesu, nie uwzględnione w modelu poglądowym. Nie świadczy to bynajmniej o złej jakości modelu poglądowego, który ze swej natury jest ogólny i nie musi pokazywać wszystkich nietypowych ścieżek wykonania procesu. Natomiast model wykonywalny musi obejmować wszystkie ścieżki – jeśli o jakiejś zapomnimy, nie będzie ona dostępna w oprogramowaniu.

Jeśli więc nasz system ma działać w oparciu o wykonywalne procesy skonfigurowane na silniku przepływu prac, to w planie projektu należy zaplanować pracę polegającą na opracowaniu modelu wykonywalnego.

Szymon Zioło – główny konsultant w RedPill

szymon ziolo

logo red pill

Kierownik projektów i analityk systemów IT z 15-letnim doświadczeniem. Specjalizuje się we wdrażaniu systemów przepływu pracy i obiegu dokumentów. Opracowuje specyfikacje wymagań i opisy przedmiotu zamówienia. Doradza w projektach IT zarówno po stronie zamawiającego, jak i po stronie wykonawcy. Prowadzi szkolenia z modelowania procesów w notacji BPMN, modelowania w języku UML oraz XML-a i technologii pokrewnych.

Więcej artykułów

Modelowanie procesów biznesowych AS IS i TO BE