BPMN - opis notacji

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

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.

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

•

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

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

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

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)

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)

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)

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

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,

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.

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