(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 .
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! Dlatego analityczny model procesów biznesowych to de facto mapa procedur z przepływem dokumentow!
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.



Jestem pod ogromnym wrażeniem pana wiedzy i sposobu formułowania treści. Bardzo rzeczowy opis. Nie raz gdy podchodzę do artykułów i zagadnień związanych z BPMN widzę jak jest opisywany jak bardziej jakiś system filozofii w którym wszystko jest subiektywne a nie narzędzie dla inżyniera oprogramowania. Jestem aktualnie w projekcie gdzie postulaty dokumentowania procesów biznesowych upadły i są tylko w głowach programistów i analityków. Teraz widzę, że jednak warto nie składać broni.
Dziękuję za dobre słowo :). Generalnie BPMN to od wielu lat narzędzie ale coraz mniej dla programistów: tu mamy UML. BPMN to dwa obszary: “stary”, który dzisiaj byłby nazwany no-code (citizen development jednak nie działa), oraz aktualny (od wersji 2.0 BPMN). Ten aktualny to modele opisowe i analityczne (rozdz. 2.2.1. specyfikacji BPMN), to modele opisujące jak działa biznes a nie “jak działa logika i komputery”.
Dokumentowanie (modelowanie) procesów biznesowych to model działania organizacji: tak naprawdę jest to mapa procedur a nie procedury. W projektach dotyczących oprogramowania ma nieocenione znaczenie, bo oprogramowanie to formatki ekranowe czyli dokumenty. A to znaczy, że zanim powstanie jakikolwiek oprogramowanie, zwany biznesowym, należy precyzyjnie zinwentaryzować dokumenty, ich rolę i logikę powstawania i przepływu. I tu analiza biznesowa i modelowanie procesów biznesowych są nieocenione.