BPMN

Business Process Modeling Notation

Created by Mosquit

Streszczenie

Notacja BPMN jest powszechnie stosowanym standardem zapisu procesów biznesowych..
W niniejszej pracy omówiono najważniejsze aspekty związane z automatyzacją procesów
biznesowych, przedstawiono podstawowe elementy notacji BPMN, oraz przykłady jej
zastosowania. Opracowanie zawiera również przegląd przykładowych narzędzi do
modelowania, sposób „automatyzacji implementacji”, oraz krótkie porównanie BPMN z
językiem UML.

1. Geneza powstania BPMN

Notacja BPMN, powstała z inicjatywy organizacji BPMI (Business Process Modeling Initiative).
Zamiarem twórców było stworzenie sposobu zapisu procesów biznesowych na tyle prostego, by mogli
z niego korzystać użytkownicy biznesowi (niemający wcześniej kontaktu z informatyką), a
jednocześnie umożliwiającego zapisanie wszystkich niezbędnych informacji o procesie potrzebnych
analitykom i informatykom. Miał on być czymś w rodzaju wspólnego języka pomiędzy osobami
mającymi kompetencje tematyczne i informatyczne.

Zanim powstała notacja BPMN procesy zamodelowane przez analityków w notacjach takich jak
IDEF0 , czy Swimlane były pracowicie „tłumaczone” na modele implementacyjne np. w UML po to,
by można je było zaimplementować w narzędziach informatycznych.

Notacja BPMN wykorzystuje doświadczenia takich firm jak BEA (przejęta przez Oracle w 2008r.),
Borland, Casewise, IBM, IDS Scheer, iGrafx (d. Micrografx), Popkin, Stafware czy Tibco.

Nowemu standardowi jako założenie wstępne określono zdolność automatycznego tłumaczenia
zamodelowanego procesu do kodu języka wykonującego procesy. Początkowo miał być to BPML i
ew. BPEL ale już w wersji 1.0 zdecydowano się jedynie na BPEL4WS.

Standard ten przyjęto w maju 2004 roku.

2. Właściwości BPMN

Notacja definiuje jeden rodzaj diagramu BPD (Business Process Diagram). Prostota ta okupiona jest
zmniejszeniem pola zastosowań:

•

służy jedynie do modelowania procesów biznesowych

•

nie modeluje przepływu danych, a jedynie przepływ sterowania (dane mogą być opisywane
dodatkowo)

•

nic nie mówi o strukturze i dostępie do danych (zwłaszcza w przekroju bezpieczeństwa)

•

nie najlepiej odwzorowuje organizację firmy

Założenie te nie są traktowane jednak jako wady, lub niekompletność języka, ponieważ takie były
intencje jego twórców. Diagram ma bowiem uwidaczniać logikę biznesową procesu i nie jest jego

2

zadaniem całościowy opis systemu informatycznego. Główną z wad BPMN jest to, iż słabo opisuje
dynamiczne grupy oraz hierarchię użytkowników.

3. Elementarz BPMN

Podstawowy zestaw elementów modelowania pozwala na łatwe tworzenie diagramów procesów
biznesowych (BPD) wyglądających zrozumiale dla większości analityków biznesowych (diagram typu
Flowchart). Na diagramach rozróżniamy następujące obiekty:

•

Zdarzenia – Events

•

Czynności – Activities

•

Bramki – Gateways

•

Przebieg procesu (Przepływ sekwencyjny) – Sequence Flow

•

Przebieg informacji – Message Flow

•

Powiązania – Association

•

Dane

•

Adnotacje

•

Jednostki (Uczestnicy) – Pools

•

Role Biznesowe (Partycje, Tory) – Lanes

Rys. 1. Podstawowe elementy składni BPMN

3.1. Zdarzenia

Zdarzenie

jest

stanem

jaki

pojawia

się

podczas

przebiegu

procesu

biznesowego.

Zdarzenia mają wpływ na przebieg procesu i zazwyczaj coś wyzwalają lub są czegoś rezultatem.
Wyróżnia się trzy typy zdarzeń, które mogą rozpoczynać (zdarzenia początkowe/inicjujące),
przerywać (pośrednie) lub kończyć (końcowe) przebieg. Poszczególne typy zdarzeń dodatkowo dzielą
się na rodzaje. Typy, oraz rodzaje zdarzeń przedstawiono w Tabeli 1.

3.1.1. Zdarzenie początkowe/inicjujące

Zdarzenie to wskazuje miejsce w którym w procesie generowana jest transakcja. Każdy proces może
posiadać wiele zdarzeń inicjujących. Każde takie zdarzenie jest traktowane jako niezależne.

Zdarzenie początkowe jest obrazowane w postaci okręgu o pojedynczej cienkiej linii (ewentualnie z
symbolem oznaczającym rodzaj zdarzenia). Do zdarzenia „start” nie mogą być przyłączone żadne
przepływy z obiektami. W podprocesach można nie pokazywać zdarzenia początkowego.

3

Tabela 1. Dozwolone zdarzenia (rodzaje i typy)

Rodzaj

↓

/ Typ

→

Początkowe

Pośrednie

Końcowe

Ogólne

Message

Timer

Niedozwolone

Rule

Niedozwolone

Link

Multiple

Cancel

Niedozwolone

Exception

Niedozwolone

Compensation

Niedozwolone

Terminate

Niedozwolone Niedozwolone

Ź

ródło: [1, 135]

3.1.2. Zdarzenie pośrednie

Zdarzenie pośrednie występuje jedynie wewnątrz procesu. Wpływa na przepływ tokenu w tym lub
innych procesach (np. zdarzenie wyślij wiadomość), ale go nie konsumuje. W procesie nie muszą
występować zdarzenia pośrednie!

Zdarzenie pośrednie jest obrazowane w postaci okręgu o podwójnej cienkiej linii (ewentualnie z
symbolem oznaczający rodzaj zdarzenia. Może być wykorzystywane do:

Wysyłania informacji do innego uczestnika.

•

Pokazania miejsc gdzie oczekiwana jest informacja lub opóźnienie

4

•

Przerwania normalnego przepływu w celu obsługi przepływu wyjątkowego

Rys. 2. Sposoby wywołanie zdarzenia pośredniego

Pokazania konieczności wykonania działań odwołujących stan procesu wynikający z dalszych kroków
(kompensacja). Umieszczane są wtedy na krawędzi czynności, w których może zaistnieć przepływ
wyjątkowy

3.1.3. Zdarzenie końcowe

Wskazuje zakończenie procesu / gałęzi procesu. Może istnieć wiele różnych zdarzeń końcowych
kończących proces.

Zdarzenie końcowe jest obrazowane w postaci okręgu o pojedynczej grubej linii (ewentualnie z
symbolem oznaczającym rodzaj zdarzenia). Jeżeli występuje zdarzenie rozpoczynające proces, musi
istnieć przynajmniej jedno zdarzenie kończące proces! Jeżeli występuje natomiast zdarzenie końcowe,
to musi być ono rezultatem dla przynajmniej jednego przebiegu sekwencyjnego.

3.2. Czynności (zadania i podprocesy)

Czynność to „praca” wykonywana podczas realizacji procesu biznesowego. Czynności mogą być
elementarne lub złożone. Czynnościami w modelu procesu mogą być:

•

proces

•

podproces

•

zadanie

Tabela 2. Zadania i podprocesy

Czynność

↓

/ Typ

→

Ogólne

Wieloinstancyjne

Powtarzalne

Ad hoc

Zadania

BRAK

Podprocesy

Ź

ródło: [1, 134]

Dodatkowo podprocesy mogą być przedstawiane w wersji rozwiniętej, pokazującej w jaki sposób
realizowany jest dany podproces (Rys 3).

Rys. 3. Wersja rozwinięta podprocesu

5

3.3. Bramki

Bramki to elementy służące do kontrolowania w jaki sposób ścieżki przepływu wchodzą w interakcję
ze sobą. Wyróżniamy dwa rodzaje bramek:

•

bramki decyzyjne określają którymi ścieżkami będzie przechodził dany przepływ.

•

bramki łączące określają jak i kiedy się połączą dane przepływy w procesie.

Bramki nie muszą występować w procesie (jeśli nie istnieje potrzeba sterowania przebiegiem
procesu).

Tabela 3. Bramki

Bramka

XOR

Służy przede wszystkim do przedstawiania poleceń warunkowych.
Ważne – w każdej sytuacji musi być spełniony jeden i tylko jeden
warunek wyjściowy bramki XOR

Umożliwia łączenie kilku gałęzi procesu, przy czym akceptowana jest
tylko gałąź, w której proces najszybciej dotrze do bramki. Innym
zastosowaniem łączenia XOR jest formalne połączenie procesu
rozdzielonego wcześniej inną bramką XOR.

Bramka

OR

Bramka OR różni się tym od bramki XOR, że warunki wyjściowe
mogą się pokrywać. Ważne – zawsze przynajmniej jeden warunek
musi być spełniony

Podobnie jak bramka AND pozwala synchronizować kilka gałęzi
procesu. Różnica jest taka, że nie wszystkie gałęzie muszą być
aktywne. Z gałęzi nieaktywnych bramka nie będzie oczekiwała
nadejścia przepływu.

Bramka

Complex

Bramka Complex jest odmianą bramki OR dla wielu wyjść. Od
bramki OR różni się liczbą gałęzi wychodzących

Pozwala dokonać selekcji kilku różnych gałęzi procesu. To, czy praca
przychodząca z konkretnej gałęzi zostanie przepuszczona, zależy od
spełnienia warunków zdefiniowanych dla tej gałęzi.

Bramka

AND

Służy do rozszczepienia procesu na gałęzie, które będą wykonywane
równolegle

Służy do scalenia dwóch gałęzi procesu, z tym że; w odróżnieniu od
bramki XOR; proces nie ruszy dalej, póki nie zostaną ukończone
zadania z obu gałęzi.

Bramka XOR
sterowana
zdarzeniami

Wybór aktywnej gałęzi procesu zależy od tego, jakie nastąpi
zdarzenie. Na wyjściu bramki XOR powinny być wyłącznie
zdarzenia. Bramka ta może być sterowana zdarzeniami typu:
Meesage, Timer i Rule.

Ź

ródło: Opracowanie własne na podstawie [1]

Rys. 4. Bramka XOR sterowana zdarzeniami - przykład

6

3.4. Przepływy

W BPMN występują trzy sposoby łączenia obiektów:

•

Przebieg procesu – pokazuje kolejność wykonywanych czynności w procesie. Może mieć tylko
jedno źródło i jeden cel: zdarzenie, czynność, bramka

•

Przebieg wiadomości – w BPMN jest wykorzystywany do pokazywania miejsca przekazywania
informacji pomiędzy dwoma autonomiczny-mi jednostkami (uczestnikami) procesu
uprawnionymi do wysyłania i odbierania ich. Przebieg wiadomości służy do synchronizacji
procesów u różnych uczestników. Tylko w ten sposób różne procesy mogą się komunikować ze
sobą

•

Powiązania – są wykorzystywane do połączenia informacji i artefaktów z czynnościami,
zdarzeniami, bramkami i przebiegami.

Tabela 4. Połączenia

Przebieg procesu

Przepływ
sterowania/
pracy

Zapisujemy w kształcie strzałki

Przepływ
domyślny

Umożliwia określenie jednego z wyjść jako
domyślnego (defaultowe). Ułatwia to zachowanie
poprawności modelu.

Przepływ
warunkowy

Alternatywny sposób zapisu wyboru
wielowariantowego. Zapisuje się go w postaci strzałki
rozpoczętej rombem i opisanej warunkiem

Przebieg wiadomości

Wiadomość,
komunikat

Oznacza otrzymanie lub wysłanie komunikatu

Powiązania

Asocjacja

Oznacza przyłączenia artefaktów

Asocjacja
skierowana

Przepływ danych

Ź

ródło: Opracowanie własne na podstawie [1]

3.5. Artefakty

Artefakty są elementami diagramu wykorzystywanymi aby pokazać dodatkowe informacje dotyczące
procesu. Nie są bezpośrednio związane z przebiegiem procesu lub przebiegiem informacji.

Uwaga! Artefakty nie są czynnościami!

Aby połączyć artefakty z innymi obiektami należy użyć powiązań. Notacja BPMN nie ogranicza
liczby artefaktów. Występują trzy standardowe artefakty:

•

Obiekty danych (Data Objects)

•

Adnotacje (Annotations)

•

Grupy (Groups)

7

Rys. 5. Artefakty w BPMN

Użytkownik można definiować nowe typy artefaktów, ponieważ standard BPMN dopuszcza
stosowanie własnych symboli graficznych. Możliwość taka jest jednak obwarowana pewnymi
warunkami:

•

Własne symbole graficzne wolno stosować jedynie wówczas, gdy jest to niezbędne lub w
znaczący sposób upraszcza diagram procesu

•

Zabronione jest nadawanie innych znaczeń symbolom już w BPMN istniejącym

•

Należy unikać stosowania symboli podobnych do znaków wykorzystywanych w innych
popularnych notacjach opisu procesów[1]

4. Przykładowe wzorce projektowe

4.1. Czynność typu transakcja

Rys. 6. Przykładowa transakcja

Transakcja to grupa zadań, która może być wykonana w całości lub wcale (niedopuszczalne jest
częściowe wykonanie – jeśli nie uda się wykonać wszystkich zadań objętych transakcją, skutki zadań
już wykonanych są wycofane).

Symbolem transakcji jest prostokąt z zaokrąglonymi rogami i podwójną linią brzegową. Idealnym i
sztandarowym przykładem prostej transakcji jest proces zaimplementowany w biurze turystycznym
realizujący zamówienie klienta na obsługę wczasów (rezerwacja podróży i hotelu)

8

4.2. Synchronizacja

Rys. 6. Synchronizacja

Zadanie powiadomienie klienta nie zacznie być wykonywane zanim nie skończą się wszystkie zadania
w gałęziach wejściowych do synchronizującej bramki AND.

5. Przykłady zastosowań BPMN

BPMN jest kierowany przede wszystkim do szeroko pojętych analityków biznesowych. Tak
rozumując mogą nimi być szefowie różnych szczebli zarządzania organizujący pracę swoich
zespołów, piony pełnomocników ds. Systemów Zarządzania Jakością (np. ISO 9001), konsultanci
zewnętrzni i wewnętrzni analitycy procesów biznesowych, analitycy Rachunku Kosztów Działań.
Łatwość tworzenia i zrozumiałość modeli predysponuje je do wykorzystywania we współpracy nawet
z ludźmi o bardzo niskiej świadomości modelowania procesów (komunikowanie funkcjonowania
procesu dla jego uczestników)

Dla informatyków BPMN może być uzupełnieniem UML’a. Pozwala na przygotowanie
konfiguratorów systemów, dzięki którym po uruchomieniu systemu dalsze zmiany mogą być
wykonywane przez analityków już bez udziału informatyków (dzięki eksportowi do BPEL).
Doświadczenie pokazuje, iż szczególną rolę BPMN pełni dla zespołów wdrożeniowych systemów
ERP /CRM /WorkFlow, gdyż może stanowić wspólną platformę porozumienia dla dostawców
oprogramowania, konsultantów wdrożenia i użytkowników systemu. Często firmy wymagają również
zamieszczenia diagramów procesów w dokumentacji powdrożeniowej.

Rys. 7 Przykładowe procesy

(Produkcja i rozwój oprogramowania – Adonis CE; Produkcja płytek drukowanych – BizAgi)

9

6. Narzędzia do modelowania – przegląd

•

BPMN for ADONIS®. – Bazowy projekt założonej w 1995r. firmy BOC wywodzącej się z
grupy BPMS Uniwersytetu Wiedeńskiego.

Rys. 8 Profil firmy BOC

System ADONIS jest wykorzystywany na całym świecie przez setki firm, które poszukiwały
elastycznego i intuicyjnego oprogramowania pomagającego zarządzać procesami. Użytkownikami
systemu ADONIS są m.in. Vodafone, Allianz, Austrian Airlines, Deutsche Bank, Generali,
Telefónica, UNIQUA i wiele innych.

Grupa BOC udostępnia również system ADONIS uczelniom, posiadającym w swoich programach
nauczania tematykę zarządzania procesami biznesowymi. W samej tylko Polsce ponad 20 uczelni
wykorzystuje system ADONIS w dydaktyce, dzięki czemu każdego roku ponad tysiąc polskich
studentów poznaje to oprogramowanie i tematykę zarządzania procesami.

•

BizAgi Process Modeler - ładnie wyglądający, z przyzwoitym eksportem do XPDL, ale dość
niewygodny przy większych modelach

Rys. 9 Przykładowe loga wybranych produktów

•

Business Process Visual ARCHITECT

•

iGrafx - bardzo dobre modelowanie, możliwość symulacji, kontrola poprawności modelu z
wymogami BPMN

•

Magic Draw

•

Microsoft Visio - wymaga specjalnego szablonu

•

Enterprise Architect

•

Corporate Modeler 10

7. BPEL i inne funkcjonalności

Większość z dostępnych na rynku narzędzi umożliwia eksport narysowanych procesów do języka
BPEL4WS (w uproszczeniu nazywany BPEL - ang. Business Process Execution Language), opartego
na standardzie XML, umożliwiającego definiowanie procesów zrozumiałych dla systemów

10

wykorzystujących technologię Web Services. Jest to zastosowanie przewidziane, opisane i promowane
przez twórców BPMN.

Wsparcie dla BPEL i sposób przedstawiania komunikacji uczestników pozwala na precyzyjne
odzwierciedlanie procesów biznesowych realizowanych przez Architekturę Zorientowaną na Usługi
(SOA - Service Oriented Architecture).

Rys. 10 Wycinek kodu BPEL

Modele stworzone w wi

ę

kszo

ś

ci systemów do modelowania mo

ż

na łatwo udost

ę

pni

ć

szerokiemu

gronu odbiorców jako:

•

Dokumenty do druku (Word, PDF), takie jak księgi jakości oraz opisy procesów,

•

Intranet w formie dokumentacji HTML (strony WWW zachowujące wszelkie powiązania
między modelami i obiektami i wszystkie dane obiektów).

•

Dokumenty w formacie XPDL, XML

•

Inne

Rys. 11 Przykładowy model w oknie przeglądarki internetowej (dokument HTML)

Niektóre z dostępnych narzędzi (m.in. ADONIS,) posiadają również bogate funkcjonalnie
komponenty służące do oceny modeli, jak np.: komponenty analizy i symulacji. Umożliwiają one
optymalizację procesów, a także wyliczanie zapotrzebowania na personel i zasoby.

Symulacja jest narzędziem umożliwiającym analitykom analizę modeli procesów przed ich
wdrożeniem. Model w trakcie symulacji odwzorowuje działanie przedsiębiorstwa przechodząc przez
procesy i wydarzenia w przyspieszonym tempie, jednocześnie pokazując animowany obraz przebiegu
procesu.
Ponieważ oprogramowanie symulacyjne zbiera statystyki dotyczące elementów modelu, możliwe staje
się określenie miar wydajności na podstawie analizy danych wynikowych symulacji modelu. Pozwala
to na uniknięcie kosztownych pomyłek, dzięki dogłębnej weryfikacji wydajności i skuteczności,
jeszcze przed wdrożeniem procesów.

8. BPMN a UML

Pojawienie się BPMN, BPML i systemów BPMS nie powoduje, że projektowanie systemów za
pomocą UML staje się przestarzałe. Projektowanie systemów nadal jest istotnym elementem
tworzenia architektury przedsięwzięcia.

•

UML jest językiem projektowania, specyfikacji, wizualizacji i dokumentowania systemów
oprogramowania. Jest on narzędziem dla architektów systemów i projektantów
oprogramowania. Został opracowany do ułatwienia i przyspieszenia produkcji oprogramowania,

11

od projektu architektury systemu aż po implementację i jest skierowany do użytkowników o
wysokich umiejętnościach technicznych.

•

BPMN jest przeznaczony dla analityków biznesowych, architektów systemów i projektantów
oprogramowania. Został opracowany do optymalizacji zarządzania cyklem życia projektu od
etapu projektowania procesów i jest przeznaczony głównie dla użytkowników biznesowych

Diagramy dynamiki zachowania, głównie diagramy use-case i aktywności są często używane do
modelowania procesów biznesowych. BPMN jest zbliżony do UMLa w tym, że definiuje graficzną
reprezentację procesów biznesowych zbliżoną do notacji w diagramach UMLowych. Jednakowoż
UML i BPMN mają zupełnie odmienne podejście do modelowania procesów biznesowych.

UML koncentruje się na obiektach, podczas gdy BPMN na procesach. Większość narzędzi
UMLowych wymaga najpierw zdefiniowania statycznych obiektów w diagramach struktur, a dopiero
później pozwala określić dynamikę interakcji między tymi obiektami za pomocą diagramów
zachowań. Taka ścieżka rozumowania jest obca większości analityków biznesowych.

BPMN oferuje podejście skoncentrowane na procesach, które jest bardziej naturalne i intuicyjne dla
analityków biznesowych. W notacji BPMN najpierw modelowane są przepływy wiadomości i
sterowania procesów. Model obiektowy procesu w trakcie normalnego modelowania nie jest
definiowany wprost. Niemniej jednak BPMN dostarcza również możliwość zdefiniowania
obiektowego modelu procesu explicite, na wypadek gdyby istniało zagrożenie, że zostanie on
ujawniony przez usługi biznesowe w przebiegu procesu.

BPMN definiuje jeden diagram BPD zaopatrzony w rozmaite widoki wyprowadzone z tego samego,
leżącego u podstaw notacji, meta modelu realizacji procesów. Wynika z tego w naturalny sposób, że
reprezentacja procesu w języku wykonawczym procesów biznesowych jest po prostu kolejnym
szczególnym widokiem.

Wreszcie UML nie definiuje żadnego meta modelu realizacji procesów biznesowych modelowanych
za jego pomocą. Model taki musi być zdefiniowany za pomocą architektury modeli MDA (ang. Model
Driven Architecture). BPMN bazuje na meta modelu realizacji procesów dzielonym z BPML i dzięki
temu nie wymaga podjęcia żadnych dodatkowych kroków w celu wygenerowania wykonywalnych
procesów.

Przewiduje się, że BPMN i UML będą koegzystować. Wielu technicznych użytkowników nie będzie
chciało przejść na BPML jako ostateczny mechanizm realizacji projektów i będą dalej używać UMLa.
BPMN może być używany jako metoda generowania rozwiązań działających w systemach BPMS lub
jako narzędzie dla analityków biznesowych do opracowywania specyfikacji UMLowych
przeznaczonych do dalszej produkcji oprogramowania. W takim układzie użytkownicy UMLa
postrzegaliby procesy biznesowe jako kolejny element projektowania. [5]

9. Podsumowanie

Dynamiczne, osiągające sukcesy przedsiębiorstwa zawdzięczają swoją przewagę konkurencyjną
umiejętności dopasowywania procesów biznesowych do szybko zmieniających się warunków
rynkowych. Zarządzanie procesami biznesowymi pozwala radzić sobie z rosnącą dynamiką na
rynkach międzynarodowych oraz zaostrzającą się konkurencją.

Dlatego też modelowanie, analiza, symulacja oraz ocena procesów biznesowych stają się coraz
bardziej istotne dla sukcesu przedsiębiorstwa. Zarządzanie procesami biznesowymi pozwala bowiem
na optymalizację procesów oraz właściwe dopasowanie struktur organizacyjnych, jak również
posiadanych zasobów i technologii do potrzeb biznesowych

Notacja BPMN została zaprojektowana tak, by umożliwić łatwe modelowanie typowych procesów
biznesowych, a jednocześnie pozwolić na modelowanie procesów o dowolnie dużym stopniu
komplikacji, włącznie z przekazywaniem wiadomości między procesami w relacjach B2B i B2C.

12

Bibliografia

[1]

Piotrowski M., Notacja modelowania procesów biznesowych – podstawy, Wydawnictwo btc,

Warszawa 2007

[2]

Biernacki P., Podstawy modelowania BPMN, referat wygłoszony podczas międzynarodowej konferencji
„Inżynieria produkcji”, Wrocław 7-8.12.2006r.

[3]

Flasiński M., Zarządzanie projektami informatycznymi, Wydawnictwo Naukowe PWN, Warszawa 2006

[4]

Seminarium dla użytkowników systemu Adonis CE – materiały szkoleniowe, Warszawa 18.11.2009r.

[5]

BPMN cz.4, [dostęp: 12.12.2009], dostępny na: http://www.skutecznyprojekt.pl/artykul.htm?AID=97