(na podstawie https://www.visual-paradigm.com/guide/bpmn/what-is-bpmn/, korekta tłumaczenia maszynowego i rozszerzenie: Jarosław Żeliński).

Opis ten powstał dla adresatów dokumentów zawierających schematy blokowe wykonane z użyciem notacji BPMN (pierwotnie dla pracowników firm moich klientów, dla nich zapoznanie się z tym dokumentem jest nadal obowiązkiem wynikającym z zawartej umowy). Jest to jednak dokument publicznie dostępny, adresowany do każdego, kto ma do czynienia z analitycznymi modelami procesów biznesowych wykonanych z użyciem notacji BPMN .

Wprowadzenie

Stosowanie sformalizowanych notacji ma jeden podstawowy cel: jednoznaczne wyrażenie i przekazanie adresatom modeli określonej treści. Tak zwany język naturalny, nawet uporządkowany w listy i tabele, jest bogaty w niejednoznaczności bo taką ma naturę. W efekcie opisy wykonane z użyciem naturalnego języka (listy wypunktowane i tabele także) są z zasady narażone na niejednoznaczność, a naukowe badania dokumentacji w projektach z obszaru analizy biznesowej oraz specyfikowania wymagań potwierdzają to .

Dlatego, aby zagwarantować jednoznaczność treści często w miejsce tak zwanej prozy, stosuje się sformalizowane schematy blokowe, zwane także często modelami (model: ?konstrukcja, schemat lub opis ukazujący działanie, budowę, cechy, zależności jakiegoś zjawiska lub obiektu?, SJP). Kluczową cechą poprawnie wykonanego schematu blokowego jest legenda użytych symboli i konstrukcji na diagramie, czyli opis tego jak JEDNOZNACZNIE zinterpretować taki diagram (semantyka i syntaktyka notacji).

Niektóre dziedziny i obszary wiedzy, z uwagi na ich powszechność, zostały objęte standardami. W przypadku schematów blokowych są nimi sformalizowane notacje. Tam gdzie schemat blokowy jest modelem czegoś, zwane także językami modelowania.

Krótka historia BPMN

BPMN wywodzi się z syntezy wielu notacji modelowania biznesowego. Pierwotnie opublikowany przez Business Process Management Initiative (BPMI) w 2004 roku. BPMN jest obecnie utrzymywany przez OMG, ponieważ te dwie organizacje połączyły się w 2005 roku (BPMI połączyło się z OMG, czyli Object Management Group). Specyfikacja BPMN została wydana przez OMG w lutym 2006 roku. Wersja 2.0 BPMN została opracowana w 2010 roku, a obecna wersja specyfikacji została wydana w grudniu 2013 roku. Najnowsza wersja (BPMN 2.0.2) została formalnie opublikowana przez ISO jako standard edycji 2013: ISO/IEC 19510.

Korzyści wynikające z BPMN

BPMN pozwala uchwycić i udokumentować procesy biznesowe organizacji w jasny i spójny sposób, który zapewnia, że interesariusze, tacy jak właściciele procesów i użytkownicy biznesowi, są łatwo angażowani w proces analizy. Dzięki temu, zespół projektowy może skuteczniej reagować na wszelkie problemy zidentyfikowane w procesach. BPMN dostarcza wszechstronne i jednocześnie bogate w treść, symbole notacji, które mogą być łatwo zrozumiane zarówno przez interesariuszy technicznych, jak i nietechnicznych. Modelowanie procesów biznesowych zapewnia istotne korzyści dla firm i organizacji, takie jak te wymienione poniżej:

• Standard przemysłowy opracowany przez konsorcjum OMG, grupę przemysłową typu not-for-profit.
• Zapewnia przedsiębiorstwom możliwość definiowania i zrozumienia ich procedur.
• Zapewnienie standardowej notacji, która jest łatwo zrozumiała dla wszystkich interesariuszy biznesowych.
• Wypełnienie luki komunikacyjnej, która często występuje pomiędzy projektowaniem i wdrażaniem procesów biznesowych.
• Prosty do opanowania, ale wystarczająco wydajny, aby zobrazować potencjalną złożoność procesu biznesowego.

Adresaci BPMN

• Eksperci techniczni odpowiedzialni za realizację procesu.
• Analitycy biznesowi, którzy tworzą i usprawniają procesy.
• Menedżerowie, którzy monitorują i kontrolują procesy.

Notacja BPMN

Business Process Modeling Notation (BPMN) to graficzny język modelowania wykorzystywany, na etapie analizy biznesowej, do specyfikowania przepływów procesów pracy w przedsiębiorstwie. Jest otwartym standardem notacyjnym dla graficznych diagramów przepływu wykorzystywanych do opisu przepływów procesów biznesowych. Jest to popularny i intuicyjny język graficzny, który może być łatwo zrozumiany przez wszystkich interesariuszy biznesowych, w tym użytkowników biznesowych, analityków biznesowych, programistów i architektów danych.

W BPMN procesy opisywane są za pomocą diagramów zawierających szereg elementów graficznych. Taka wizualna prezentacja ułatwia użytkownikom zrozumienie logiki procesów biznesowych i ich związków między nimi.

BPMN został opracowany przede wszystkim z myślą o projektowaniu i odczytywaniu zarówno prostych (poglądowe i analityczne), jak i złożonych (wykonywalne) diagramów procesów biznesowych. W tym celu standard BPMN klasyfikuje elementy graficzne według tych kategorii (poglądowe, analityczne, wykonywalne). Dzięki temu elementy te są łatwo rozpoznawalne przez użytkowników pracujących z diagramami procesów biznesowych.

Podstawowym elementem na etapie Analizy Biznesowej jest elementarny (atomowy) analityczny proces biznesowy

BPMN Process Types: “Both Descriptive and Analytic focus on visible elements and a minimal subset of supporting attributes/elements”

analytic non-executable process, patrz specyfikacja BPMN 2.0.2., rozdz. 2.2.1

definiowany jako abstrakcyjna aktywność mająca określony cel biznesowy, a tym celem jest, co do zasady, tworzona lub zmienia treść (dokument, DataObject). Każdy proces biznesowy składa się z elementarnych (atomowych) aktywności także mających określony cel (produkt), są to elementarne (atomowe) procesy biznesowe. W modelach analitycznych model, szczegóły elementarnych aktywności (atomowych procesów biznesowych) dokumentowane są osobno jako procedury (mogą to być opisy, tabele, ale także – rzadziej – kolejne diagramy). Innymi słowy: atomowa aktywność na mapie procesu (task) to nazwa procedury.

Analityczny model procesów biznesowych to diagram obrazujący połączone w logiczny ciąg procedury i dokumenty z nimi powiązane. Procedury na diagramie są reprezentowane jako Zadania (Task w BPMN) a dokumenty jako Obiekty Danych (DataObject w BPMN).

UWAGA! Niezbędnym uzupełnieniem modeli procesów biznesowych, wykonanych z użyciem notacji BPMN, są biznesowy słownik pojęć oraz reguły biznesowe budowane z jego użyciem. Co do zasady logika biznesowa powinna być dokumentowana jako procedury i reguły biznesowe a nie jako procesy, zaś wspólny biznesowy słownik pojęć to narzędzie pozwalające utrzymać jednoznaczność i spójność całości dokumentacji. Notacja BPMN nie służy do modelowania logiki biznesowej tylko do modelowania przepływu pracy i wartości dodanej .

UWAGA! Dalszy opis dotyczy wyłącznie modeli analitycznych, bo tylko takie są tworzone na etapie analizy biznesowej. Modele te są elementem CIM (What is Computation Independent Model) .

Podstawowe elementy

Istnieje pięć podstawowych kategorii elementów BPMN. Każda z nich reprezentuje unikalny aspekt procesu biznesowego.

Pule i tory

Pule (Pool) i tory (lane) są graficznymi kontenerami reprezentującymi uczestników procesu. Istnieją dwa rodzaje kontenerów: pule (pool) reprezentujące organizacje (firma, urząd, itp. to uczestnicy procesu), oraz tory (lane, wydzielone partycje wewnątrz puli), reprezentujące komórki organizacyjne, stanowiska, role (zależnie od przyjętej przez autora modeli konwencji). Torów używamy wyłącznie do organizacji i kategoryzacji aktywności.

Elementy przepływu – symbole

Elementy przepływu to elementy, które łączą się ze sobą tworząc przepływ pracy. Symbolizują aktywne elementy procesu. Elementy przepływu są podstawowymi elementami, które definiują logikę i przebieg procesu. Mamy trzy rodzaje elementów przepływu: Zdarzenia (Start, Intermediate, End), Aktywności (Task, Sub-Process) i Bramki (Gateway). UWAGA! Na diagramach analitycznych nie używamy symboli oznaczających elementy kodu (dodatkowe ikonki wewnątrz elementów Task, są one przeznaczone dla modeli wykonywalnych zwanych Common Executable, reprezentują polecenie w języku BPEL).

Co do zasady wszystkie elementy modeli BPMN, elementy przepływu także, muszą mieć określone unikalne etykiety (podpisy). W notacji BPMN etykieta elementu diagramu jest także jego identyfikatorem w repozytorium. W konkretnych modelach nie powinny to być “start” czy “stop” a faktyczne zdarzenia np. Odebrano zamówienie (inicjujące), Fakturę doręczono (pośrednie) czy Zamówienie zrealizowano (kończące).

Elementy przepływu i łączniki

Łączniki (związki) łączą elementy przepływu i są nazywane “obiektami łączącymi”. Istnieją cztery rodzaje obiektów łączących: przepływy sekwencji (Sequence flow) i przepływy komunikatów (Message flow), które wyrażają następstwo, oraz powiązania pojęciowe (Association) i powiązania danych (Data Association).

Dokument (Data Object) i Repozytorium (Data Stor)

Dokumenty (strukturalne dane) to informacje wymagane lub wytwarzane podczas realizacji procesu biznesowego. Notacja BPMN nie służy jednak do modelowania struktur danych (dokumentów. Istnieją cztery rodzaje tych symboli: Obiekty danych (Data Object) reprezentują dokumenty, dane wejściowe (Data Input), dane wyjściowe (Data Output) oraz repozytoria, magazyny danych/dokumentów (Data Stor). W modelach analitycznych stosujemy wyłącznie Data Object. Struktury dokumentów (treść, szablon formularza) modelowane są odrębnie z użyciem np. notacji UML (diagram struktur złożonych) . Elementów Data Stor można używać w modelach analitycznych by pokazać, że określone treści nie stanowią odrębnych dokumentów, a zapisy w rejestrach (wiersze tabel, Data Stor reprezentuje wtedy główkę takiej tabeli).

BPMN – modelowanie

Obiekty typu swimlanes (pule i tory) w BPMN są prostokątnymi polami, które reprezentują uczestników (organizacja) procesu biznesowego (pool). Mogą one zawierać obiekty przepływu, które są wykonywane przez rolę lub komórkę organizacyjną (lane). Wyjątkiem jest pula, tak zwana “czarna skrzynka” (opisana w dalszej części tego opisu). Na typowym diagramie BPMN, proces przepływa od lewej do prawej (ale rysowanie z góry na dół jest dopuszczalne).

Pule

Pule reprezentują uczestników procesu biznesowego (organizacje i/lub ich klientów, także samodzielne osoby np. klienta firmy, petenta urzędu).

Wewnątrz puli znajdują się elementy przepływu procesu. Reprezentują one zadania (prace), które muszą być wykonane w ramach modelowanego procesu. Istnieje także rodzaj puli, który nie posiada żadnej zawartości. Jest to tak zwana czarna skrzynka (blackbox). Pula blackbox jest często używana przy modelowaniu podmiotów zewnętrznych w stosunku do modelowanego procesu biznesowego. Ponieważ jest ona poza obszarem analizy, jej wewnętrzny przepływ nie ma żadnego wpływu na modelowany proces, może on zostać pominięty. Poniższy BPD (Business Proces Diagram, diagram procesu biznesowego) przedstawia przykład puli z procesem i czarną skrzynkę. Klient (Customer) jest tu taką czarną skrzynką. Ponieważ proces koncentruje się na tym, jak kuchnia (Chef) przygotowuje posiłek, to co robi klient nie jest przedmiotem zainteresowania. Użycie czarnej skrzynki zależy od perspektywy, jaką przyjmujemy modelując proces.

Pule można dzielić na tory (linie, partycje), reprezentują one wtedy wewnętrzny podział na komórki organizacyjne lub role i stanowiska. Wewnątrz każdego toru znajdują się elementy przepływu. Reprezentują one prace, które musi wykonać (za które odpowiada) określona komórka organizacyjna lub rola w ramach modelowanego procesu.

Aktywności

Aktywności są pracami (ich nazwami) wykonywanymi w ramach procesu biznesowego. Są one przedstawione w postaci zaokrąglonych prostokątów, z nazwami opisującymi prace do wykonania. Istnieją dwa rodzaje aktywności: Zadanie i Podproces.

Gdy chcemy zamodelować atomową (elementarną) pracę, której nie da się (lub nie ma potrzeby) dalej rozłożyć na detale, lub poszczególne kroki są znane ale nie są samodzielne (wtedy osobno powstaje opis: procedura), używamy zadania (task):

Jeżeli chcemy pokazać, że zamodelowano osobno zadania reprezentują określoną złożoną pracę, która może być rozłożona na mniejsze ale samodzielne podrzędne zadania (każde tworzy jakiś produkt), używamy symbolu podprocesu. Oznacza to, że powstał dodatkowy model (diagram) jako kolejny poziom szczegółowości (odrębny, skojarzony diagram BPD). Podproces zawiera więc inny, podległy mu, diagram BPD modelujący jego szczegóły.

Wybór metody opisu jest związany z tym, jak skomplikowana może być to praca, ale również z tym, jak szczegółowa wiedza na jej temat jest w danym projekcie analitycznym potrzebna.

Zdarzenia

Zdarzenia to coś, do czego dochodzi (fakt) i może to mieć wpływ na proces biznesowy. Zdarzenie może być zarówno zewnętrzne jak i wewnętrzne. Jeśli tylko mogą mieć wpływ na modelowany proces, powinny zostać zamodelowane (i tylko wtedy). Zdarzenia przedstawiane są w postaci kółek. W niektórych przypadkach wewnątrz nich znajdują się ikony, które reprezentują typ zdarzenia.

Istnieją trzy główne typy zdarzeń: zdarzenie początkowe (inicjujące, z zasady przechwytywane), zdarzenie pośrednie (przechwytywane lub generowane) i zdarzenie kończące (z zasady generowane).

Każdy proces powinien posiadać zdarzenie inicjujące go, które pokazuje początek (przyczynę inicjacji) procesu biznesowego. Pozwala to czytelnikowi na zlokalizowanie w BPD miejsca rozpoczęcia procesu. Zdarzenie kończące służy do wskazania miejsca (faktu) zakończenia procesu biznesowego, a zdarzenie pośrednie jest odpowiedzialne za sterowanie przepływem wewnątrz procesu biznesowego. Zdarzenie pośrednie może być dołączone do zadania (na jego krawędzi dlatego bywa nazywane krawędziowe lub graniczne) w celu zamodelowania faktu, który może wystąpić W TRAKCIE realizowania tej aktywności i przerwać realizację Zadania, jak również może być połączone przez obiekt łączący (strzałka) w celu zamodelowania zdarzenia, które może wystąpić PO wykonaniu wcześniejszego elementu przepływu. Więcej o tym przypadku w dalszej części.

Poniższy przykład pokazuje sposób pokazanie zdarzenia występującego w tracie zadania. Diagram poniższy pokazuje, że w momencie gdy otrzymujemy zamówienie (order arrived), zaczynamy je przetwarzać (Process Order). Jeśli i tylko wtedy, gdy przekroczony jest limit kredytowy (no credit limit) przerywamy prace nad dalszym przetwarzaniem zamówienia i sprawdzamy ten problem (Check Problem) (aktywność Process Order nie zostanie wykonana do końca). Proces kończy się, gdy Zamówienie zostało zrealizowane albo nie, ale problem został zidentyfikowany.

Bramki

Bramki są odpowiedzialne za zobrazowanie kontroli przepływu procesów biznesowych. Są one przedstawiane w postaci rombów. W procesie, prace do wykonania i wyjście mogą się różnić w zależności od różnych warunków. Na przykład, rabat będzie oferowany tylko kupującemu VIP. Bramkę umieszczamy by pokazać, że warunki były oceniane i jaka decyzja została podjęta w poprzedzającej tę bramkę aktywności.

Oto kilka typowych rodzajów bramek:

Bramka danych wyłącznej alternatywy XOR (exclusive) , zwana również bramką wyłączną, służy do sterowania przepływem procesu na podstawie danych (zawartość dokumentów: Data Object, tu nie pokazano). Każdy wychodzący z bramki przepływ odpowiada określonemu warunkowi. Jeżeli warunki te wykluczają się (tylko jeden warunek może być tu spełniony) jest to bramka XOR.

Bramka danych wyboru OR (inclusive) może być użyta do tworzenia różnych jednoczesnych ścieżek. Warunki wszystkich wychodzących przepływów nie muszą się tu wzajemnie wykluczać. Wszystkie przepływy z pozytywnym wynikiem oznaczają kontynuację procesu. Dlatego też, może to skutkować wykonaniem wielu przepływów jednocześnie, jeśli jednocześnie spełnione są różne warunki.

Z uwagi na to, że przepływy zależą od warunków i ich kombinacje mogą być różne, obecnie obu opisanych wyżej bramek nie rozróżnia się graficznie na diagramach (obecnie, w modelach analitycznych, w obu przypadkach stosuje się pusty symbol rombu, UWAGA! bramki danych to warunki budowane na bazie treści dokumentów DataObject!).

Bramka równoległa (w oryginale ‘fork’, rozwidlenie) służy do modelowania obligatoryjnego dzielenia (rozwidlenia) przepływu bez sprawdzania jakichkolwiek warunków. Innymi słowy, wszystkie wychodzące z niej przepływy muszą być wykonane.

Bramka zdarzeniowa jest używana do modelowania alternatywnych ścieżek, gdzie warunkami nie są dane (treści zawarte w Data Object) a zaistniałe fakty (zdarzenia). Na przykład oczekiwanie na odpowiedź Tak lub Nie, gdzie każda odpowiedź ma inne konsekwencje (przepływ). Bramka ta jest zatem sterowana przez alternatywne zdarzenia (poniżej wyzwalacz oznaczający wiadomość). Kiedy którekolwiek z tych zdarzeń wystąpi, realizowany jest przepływ, który następuje po tym zdarzeniu. Wszystkie inne zdarzenia i będące za nimi przepływy, nie będą już realizowane (nie istnieją w BPMN zdarzenia jednoczesne). Poniżej przykład trzech alternatywnych zdarzeń: dwa komunikaty i graniczny czas jaki upłynął.

Przepływ sterowania (sekwencji)

Przepływ jest używany do łączenia elementów procesu. Jest on przedstawiony jako linia skierowana ciągła z otwartym grotem strzałki. Pokazuje kolejność elementów przepływu.

Przepływu sterowania (sekwencja) można używać tylko do łączenia elementów przepływu w obrębie tej samej puli. Aby połączyć elementy pomiędzy pulami, nie wolno użyć sekwencji, należy użyć przepływu komunikatów.

Przepływy komunikatów

W BPMN komunikacja pomiędzy pulami (reprezentuje wymianę treści między różnymi różnymi organizacjami) odbywa się za pomocą komunikatów. Przepływ komunikatów jest używany do pokazania przepływu treści pomiędzy pulami (podmiotami). Przepływ komunikatów jest przedstawiony w postaci linii przerywanej z zamkniętym grotem strzałki. Przykłady komunikatów między podmiotami: faks, telefon, email, list, zawiadomienie itp..

Dokumenty (Obiekty Danych)

Podczas wykonywania procesu biznesowego, zgodnie z definicją, w ramach realizowania aktywności są generowane dane, zarówno w trakcie jak i po zakończeniu procesu. Na przykład, pomyślne wykonanie zadania Złóż zamówienie spowoduje wytworzenie danych takich jak zamówienie zakupu, faktura, paragon, itp. W BPMN, w modelach analitycznych, dane są modelowane jako Obiekt danych. Istnieje tu także możliwość zdefiniowania zarządzania stanami tych dokumentów (wtedy [nazwa stanu] jest umieszczana pod nazwą dokumentu).

Asocjacja pomiędzy Zadaniem a Dokumentem może być dodatkowo skierowana, wskazuje to wtedy czy jest to wejściowy czy wyjściowy dokument.

Grupy

Grupa to ramka w postaci linii przerywanej, zapewniająca mechanizm grupowania kształtów według różnych kategorii, w realnych modelach muszą mieć one także nazwy.

Powyższa konstrukcja jest poprawna formalnie: górny tor – ostatnim faktem jest wysłany komunikat, co w tym przypadku (jest to ostatnie zadanie) jest tożsame ze zdarzeniem kończącym proces, komunikat ten w drugiej puli jest pierwszym faktem, który inicjuje proces i jest to tożsame z wystąpieniem zdarzenia inicjującego.

Z uwagi na ryzyko błędnej interpretacji takich konstrukcji, zaleca się jednak stosowanie każdorazowo zdarzeń inicjujących i kończących proces w każdej puli (wymaga tego większość serwerów BPMS). Podobna konstrukcja jest poniżej w części BPMN – Przykład.

Adnotacje tekstowe

Adnotacja tekstowa może być użyta do dodania dodatkowych szczegółów do obiektów przepływu w BPD. Nie ma ona wpływu na przepływ, ale podaje dodatkowe szczegóły dotyczące wybranych elementów modeli.

BPMN – przykład

Firma True Aqua Distilled Water Company jest młodym dostawcą wody destylowanej w mieście. Sprzedaje wodę destylowaną dla biznesu i do użytku domowego. Obecnie firma True Aqua Distilled Water Company chce zwiększyć swój udział w rynku z 5% do 10% w ciągu najbliższych 12-18 miesięcy. Aby osiągnąć ten cel, firma stara się znaleźć sposoby na zwiększenie efektywności operacyjnej i osiągnięcie wyższego poziomu satysfakcji klientów.

W związku z tym firma True Aqua Distilled Water Company postanowiła usprawnić proces zamawiania wody destylowanej. Jesteś teraz analitykiem biznesowym odpowiedzialnym za tę misję. Po spotkaniu z firmą True Aqua Distilled Water Company zebrałeś następujące informacje na temat procesu zamawiania. Przyjrzyjmy się temu.

Poniższy rysunek przedstawia schemat procesu biznesowego dla procesu dostarczania wody destylowanej w firmie The True Aqua Distilled Water Company (patrz komentarz powyżej w rozdz. Grupy).

Zgodnie z diagramem, aby zamówić wodę destylowaną klienci mogą albo zadzwonić na infolinię, albo wysłać do nas e-mail. Obecnie 90% zamówień pochodzi z rozmów telefonicznych, podczas gdy 10% zamówień składanych jest za pomocą poczty elektronicznej. Pracownik obsługi klienta, który otrzyma zamówienie, sprawdzi czy klient jest już istniejącym czy nowym klientem. Jeśli klient nigdy wcześniej nie składał zamówienia, asystent obsługi klienta utworzy dla niego konto klienta przed realizacją zamówienia.

Dostawa wody destylowanej jest realizowana raz w tygodniu w każdą środę. W związku z tym w każdą środę rano pracownik działu obsługi klienta przekazuje zamówienia do działu logistyki w celu realizacji dostawy. Po otrzymaniu zamówień kierownik w Dziale Logistyki organizuje dostawę, przydzielając pracowników do obsługi różnych zamówień, drukując i wywieszając harmonogram. Pracownicy odbierają telefony i odpowiednio dostarczają wodę do klienta.

Kluczowe cechy poprawności analitycznych modeli procesów biznesowych

Definicje w BPMN (dodatek C spec. BPMN):

Proces Biznesowy: zdefiniowany zestaw aktywności, które reprezentują kroki wymagane do osiągnięcia celu biznesowego.
Atomowa aktywność: działanie, które nie zostało podzielone na bardziej szczegółowy poziom Modelu Procesu. Jest to liść w
drzewiastej hierarchii aktywności Procesu. Graficznie pojawi się jako Zadanie
w BPMN.

Modele analityczne to modele opisujące przepływ pracy i treści a poziom szczegółowości wyznacza podręcznikowa definicja procesu biznesowego brzmiąca: “aktywność mające wejście i wyjście (tworząca produkt), angażująca określone zasoby. Dlatego poprawny model analityczny to diagram, na którym:

• każda aktywność ma wskazany jej produkt (data object),
• każda aktywność reprezentuje określona procedurą lub zdefiniowaną kompetencję,
• każdy “data object” reprezentuje nazwany typ (szablon) dokumentu.

Tak więc poza diagramami BPMN dokumentacja taka powinna zawierać załączniki: procedury, nazwy stanowisk, szablony dokumentów. Na diagramach nie powinno być tak zwany “śmieciowych czynności” czyli takich, dla których nie wskazano ich produktu (data object).

Dlatego poprawne modele analityczne procesów pokazują tylko przepływ pracy i dokumentów ale nie pokazują detali tworzonej treści ani logiki biznesowej (to dokumentujemy jako reguły biznesowe). Dlatego modele BPMN muszą być uzupełniane opisami procedur (np. tabele, listy wypunktowane, proste schematy blokowe) i makietami dokumentów, co pokazano schematycznie poniżej:

(osoby zainteresowane szczegółami takich pojęć jak proces biznesowy i procedury, oraz tym jak są one modelowanie, polecam artykuł Procesy biznesowe a procedury)

Dodatek: typowe i często popełniane błędy

Powyższa treść dotyczy intepretowania diagramów. Okazuje się jednak, że ten opis zyskał sobie dużą popularność, bo czytanie dokumentów (w tym ocena poprawności diagramów) to także element ich odbioru, gdy opracowanie dokumentacji procesów było płatną usługą. Poniżej więc dodatkowo uwagi dotyczące tego, czego tam być nie powinno…

Modelowanie rzeczy oczywistych oraz niebędących procesem biznesowym czyli śmieciowe elementy na diagramach

Proces biznesowy to aktywność, lub ich łańcuch, cechująca się samodzielnością, określonym celem (jej produktem).

Aktywności wchodzące w skład procesu i zwane atomowymi (zadania), tworzą atomowe procesy biznesowy, czyli elementarne pary: “nazwana praca i jej efekt”:

Atomic Activity: An activity not broken down to a finer level of Process Model detail. It is a leaf in
the tree-structure hierarchy of Process activities. Graphically it will appear as a Task in BPMN.
Business Process: A defined set of business activities that represent the steps required to achieve a
business objective. It includes the flow and use of information and resources.

(źr.: specyfikacja BPMN, Annex C, Glossary)

Atomowa aktywność: Działanie, które nie zostało podzielone na kolejne niższe poziomy szczegółowości modelu procesu. Jest to tak zwany liść w drzewiastej hierarchii aktywności Procesu. Graficznie w BPMN będzie modelowane jako Zadanie.
Proces biznesowy: Zdefiniowany zestaw aktywności biznesowych, które reprezentują kroki wymagane do osiągnięcia celu biznesowego. Obejmuje on przepływ i wykorzystanie informacji oraz zasobów.

Tak więc proces biznesowy (modelowany w notacji BPMN) to aktywność i jej określony produkt (Task->DataObject), lub ich łańcuch, na jednym diagramie. Atomowa aktywność w BPMN to Zadanie (Task).

Nie umieszczamy więc na modelach analitycznych zadań które nie tworzą samodzielnych produktów, takich jak: “przekazanie dokumentu przełożonemu” czy “zapoznanie się z treścią dokumentu”, także dlatego, że są to rzeczy oczywiste, wynikające ze strzałek i torów w basenach na diagramach BPMN lub z samego kontekstu (akceptacja dokumentu z zasady wymaga zapoznania się z nim).

Nie rysujemy na modelu BPMN sposobu wypełniania formularza, np. “wstawianie numeru NIP do faktury”, “wyliczenie wartości w polu upust”, bo to dokumentujemy osobno jako szablon dokumentu np. Faktura i reguły jego poprawnego wytworzenia.

Nie umieszczamy na modelach procesów biznesowych elementów instrukcji obsługi sprzętu i oprogramowania, instrukcji stanowiskowych i procedur, np. “zapisanie dokumentu jako pliku na dysku sieciowym D:/”, “wyeksportowanie tabeli do formatu Excel”, “wysłanie umowy z użyciem email do adresata”, bo są to detale specyficzne dla wdrożonej metody pracy, a nie dla procesu jako takiego. Przywołujemy je tu (kojarzymy z Zadaniami na diagramie) jako osobne instrukcje obsługi oprogramowania, procedury, instrukcje stanowiskowe itp.. Nieprzestrzeganie tych zasad szybko prowadzi to zjawiska zwanego spaghetti-modeling opisanej dalej.

Używanie elementów specyficznych dla modeli wykonywalnych na modelach analitycznych

Notacja BPMN powstała pierwotnie jako narzędzie do generowania skryptów BPEL4WS (Business Process Execution Language for Web-Services) wykonywanych na w środowisku BPMS (Business Process Management Systems). Dlatego pierwotna specyfikacja zawiera nie tylko elementy ogólne (task, activiti) ale też przede wszystkim ich specjalizacje oznaczone specjalnymi ikonami, które reprezentują określone konstrukcje języka BPEL.

Po kilku latach używania notacji BPMN, praktycy zwrócili uwagę na to, że znakomita większość powstających modeli procesów biznesowych nie służy do generowania skryptów BPEL, a jedynie do analizy biznesowej, czyli do tworzenia modeli procesów na wyższym poziomie abstrakcji (patrz wyżej: atomowa aktywność – zadanie), które dodatkowo muszą być zrozumiałe dla osób z tak zwanego biznesu, bo to one są ich adresatem (a nie serwery BPMS/BPEL). Dlatego ostatnie wydanie specyfikacji BPMN zawiera rozdział 2.2.1. w którym zwrócono na to uwagę. Generalnie wniosek jest prosty: nie używamy na modelach analitycznych symboli zadań z małymi ikonami w rogu, bo one służą do modelowania detalicznych linii poleceń skryptów BPEL. Używanie ich na modelach analitycznych wprowadza tylko zamęt u ich adresatów (zamiast nauczyć się kilku prostych, podstawowych symboli notacji BPMN, muszą nauczyć się poprawnie interpretować kilkadziesiąt ikon). Szczególnie poważnym błędem jest uznaniowe “umawianie się” na to co oznaczają te ikonki.

Na modelach analitycznych, semantycznie mają sens i nie raz muszą być jednak użyte (inicjacja procesu lub bramka zdarzeniowa) wybrane zdarzenia (wyzwalacze): timer (oznacza moment w czasie a nie upływ czasu!), spełnienie określonego warunku (np. proces uzupełnienia stanu magazynu jest inicjowany stwierdzeniem faktu spadku ilości towaru poniżej 10 sztuk), stwierdzenie otrzymania lub wygenerowania komunikatu (ale na modelach wykonywalnych są to oznaczone kopertą aktywności a nie wyzwalacze).

Pętle

To temat wielu kontrowersji, dlatego opiszę problem i wyjaśnię dlaczego nie tworzymy pętli na modelach analitycznych.

1. Notacja BPMN wymaga zadeklarowania czy model jest modelem analitycznym czy wykonywalnym, są to odrębne modele (rozdz. 2.2.1. spec BPMN).
2. W analizach biznesowych tworzymy modele CIM (Computation Independent Model), które całkowicie abstrahują od użytych technologii.
3. Organizacja to nie komputer więc proces biznesowy (jego model) to nie algorytm (algorytmy to modele wykonywalne dla maszyn BPMS, patrz poprzedni rozdział).
4. Aktywność (task) na analitycznym modelu procesu to nazwa procedury.
5. Proces biznesowy to kolejno realizowane aktywności, ich ścieżki mogą się rozwidlać i łączyć, ale nie cofają nas w czasie wstecz.
6. Jeżeli proces jest realizowany cyklicznie to powodem kolejnego jego wykonania, jest ponowne wystąpienie inicjującego go zdarzenia, a nie to co sie wydarzyło na końcu tego procesu.
7. Jeżeli jakaś czynność jest wykonywany cyklicznie (np. napełnianie wiaderka piaskiem z użyciem łyżeczki do herbaty) to jest opis procedury realizacji tego zadania (napełnienie wiaderka) a nie cyklicznie wykonywane w pętli zadanie.

Dlatego na modelach procesów biznesowych pokazujemy działanie organizacji i nie rysujemy pętli. Jeżeli ktoś musi kilkanaście razy opracować ofertę, to nie dlatego, że skończył poprzednią, a dlatego, że nadal czeka jakieś “Zapytanie ofertowe” o statusie [nowe]. Bo proces opracowania oferty jest inicjowany zapytaniem, a nie wysłaniem poprzedniej oferty. Nie ma tu żadnej pętli. Są powtarzające się zdarzenia inicjujące ten sam proces.

Używanie zdarzeń, bramek i obiektów danych jako aktywności

Powszechnym błędem na diagramach jest wyrażanie pracy symbolami, które tej pracy, w notacji BPMN, nie reprezentują. W notacji BPMN tylko jeden symbol reprezentuje realizowaną pracę: jest to aktywność.

Pozostałe symbole stanowią sobą wyłącznie stwierdzenie faktu, że do czegoś doszło, a fakty nie trwają w czasie i nie są w BPMN semantycznie łączone z rolą lub komórką organizacyjną (tory):

Lanes are used to organize and categorize Activities.

(źr.: BPMN v.2.0.2. str. 27: Table 7.1 ? Basic Modeling Elements)

Tak więc zdarzenia reprezentują wyzwalacze, po nich (zdarzenie przechwytywane) lub przed nimi (zdarzenie generowane) MUSI pojawić się aktywność, bo wyzwalacz nie jest pracą (aktywnością).

Umieszczenie zdarzenia w torze nie znaczy, że coś się zdarzyło w miejscu reprezentowanym przez ten tor, na zdarzenie MUSI ktoś dopiero zareagować i to jest dopiero wykonana praca (aktywność). Miejsce: tor, umieszczenia symboli nie będących aktywnością, nie ma znaczenia na modelach BPMN, umieszczamy je (zalecenie) kontekstowo, łącznie z aktywnościami których dotyczą, dla łatwości percepcji modeli.

Więc na diagramie po lewej stronie (powyżej): nie jest prawdą, że Rola 1 zareagowała i zrobiła cokolwiek, i nie jest prawdą że Rola 1 dostała dokument wytworzony przez Rolę 2 i go np. przeczytała. Zależnie od tego jaki jest stan faktyczny, poprawne są diagramy środkowy i po prawej.

Utrata panowania nad złożonością

To między innymi konsekwencja, opisanego powyżej, stosowania śmieciowych elementów na diagramach. To także jedna z najczęstszych wad wielu diagramów (nie tylko BPMN, np. UML także). W literaturze przedmiotu problem ten jest często określany jako “spaghetti modeling” czyli nieczytelne, zagmatwane modele.

Jednym z podstawowych zaleceń, dotyczących od dekad zarządzania złożonością schematów blokowych, jest zasada mówiąca, że:

jeżeli diagram jest nieczytelny po wydrukowaniu na papierze formatu A4, jest to z zasady źle wykonany diagram.

Poniżej zanonimizowane przykłady z audytowanych dokumentów:

Jak widać są praktycznie nieczytelne więc także nieprzydatne, więc po co powstały?

Panowanie nad złożonością modeli (schematów blokowych) ma dwa aspekty: używanie właściwej formy wyrazu (notacja) oraz właściwego poziomu abstrakcji, dobranego do wyartykułowania określonego problemu. Właściwa forma wyrazu to np. decyzja co wyrazimy notacją BPMN (proces biznesowy), co notacją UML (np. szablon treści dokumentu), co tekstem jako procedurę i co, także tekstem, jako reguły biznesowe. Mogą się pojawić macierze RACI i itp. Poziom abstrakcji to właściwy dobór detali i ich liczby, do kontekstu danego diagramu i celu jego utworzenia: każdy diagram powinien mieć jeden cel i jeden kontekst.

Co do zasady adresatem każdego dokumentu jest człowiek z jego indywidualną umiejętnością interpretacji (percepcji) tego co czyta. Dokumenty te udostępniane są im na ekranie komputera lub na wydruku. Zapominanie o tym, jest poważnym błędem wielu ich autorów…

Mieszanie kontekstu biznesowego i aplikacyjnego

Na koniec kolejny często popełniany błąd na modelach BPMN: mieszanie kontekstów biznesu i technologii. Organizacja trzymająca pieczę nad notacją BPMN i standaryzująca także inne (np. UML) czyli OMG, opublikowała zalecenia Model Driven Architecture (MDA), czytamy w nich:

Model Driven Architecture? (MDA?) is an approach to software design, development and implementation spearheaded by the OMG. MDA provides guidelines for structuring software specifications that are expressed as models. MDA separates business and application logic from underlying platform technology.

(Model Driven Architecture? (MDA?) jest podejściem do projektowania, tworzenia i wdrażania oprogramowania, zainicjowanym przez OMG. MDA zawiera wytyczne dotyczące strukturyzacji specyfikacji oprogramowania, które są wyrażane jako modele. MDA oddziela logikę biznesową i aplikacyjną od podstawowej technologii platformy.)

Kluczem jest ostatnie zdanie: nie mieszamy logiki biznesowej z faktem posiadania i używania oprogramowania (systemów IT), bo te są jedynie narzędziem a nie sensem biznesu. Dlatego z zasady tworzymy dwa oddzielne modele dla organizacji: Computation Independent Model (CIM), czyli model biznesowy, niezależny od posiadanych systemów informatycznych oraz te systemy (planowane lub posiadane) jako Platform Independent Model (PIM) czyli model logiki działania systemów IT (oprogramowania) niezależny od użytych technologii. Innymi słowy model biznesowy organizacji i model wykorzystanego oprogramowania, to odrębne modele. Na modelach CIM nie umieszczamy żadnych wzmianek o oprogramowaniu (generalnie o narzędziach użytych w procesach) . To, że jakimś momencie używamy jakiegoś oprogramowania jest treścią instrukcji stanowiskowej lub procedury, ale

umieszczanie toru “system ERP” na modelu procesów biznesowych BPMN jest łamaniem podstawowej zasady MDA: model procesów biznesowych abstrahuje od użytych narzędzi.

Więc jak i gdzie udokumentować to, że coś robimy z użyciem oprogramowania? Do tego służy tak zwane śladowanie, czyli kojarzenie aktywności na modelach procesów biznesowych z przypadkami użycia (więcej w artykule: Transformacja modelu procesów biznesowych na model przypadków użycia) lub komponentami na modelach UML. Stosowane są także konwencje by nazwy aktywności na modelach BPMN dodatkowo uzupełniać nazwami przypadków użycia lub komponentów systemów IT: np. aktywność “Wystawienie faktury [moduł FK ERP]”

Czy elementy na diagramach mogą się powtarzać

Tak. Nie ma w specyfikacji BPMN reguły mówiącej, że jakikolwiek element nie może się powtórzyć na jednym diagramie. Poniżej typowa sytuacja: powtarza się aktywność Archiwizacja oraz dokumenty Zamówienie i Faktura:

Teza, że jeden element można tylko raz “narysować” na jednym diagramie nie znajduje potwierdzenia w specyfikacji BPMN, a jak widać powyżej, są to częste sytuacje.

---

Szkolenia

Przeczytałeś? Więc po co Ci szkolenie? Bo tu dowiedziałeś najważniejszych rzeczy by zrozumieć te modele, a na szkoleniu poznasz przyczyny tego dlaczego tak a nie inaczej i będziesz mógł w dowolnym momencie o wszystko zapytać.

Osoby zainteresowane poszerzeniem wiedzy i nabyciem praktyki dotyczącej analizy i modelowania procesów biznesowych zapraszam na stronę Szkolenia.

Literatura