Dlaczego BPMN?
(podstawy modelowania w BPMN)
Materiał poświęcony jest podstawom notacji BPMN. Przedstawia genezę standardu, opisuje występujące w nim obiekty i podaje przykłady zastosowań. Zwrócono uwagę na różnice BPMN w stosunku do innych notacji opisu procesów biznesowych. Omówiona jest również symulacja modeli BPMN i przejście z modeli BPMN do kodu BPEL.
(Ten artykuł jest w wersji roboczej i oparty jest na referacie wygłoszonym we Wrocławiu podczas Międzynarodowej Konferencji "Inżynieria Produkcji" (7-8.12.2006))
Cytowane tego artykułu jest dozwolone pod warunkiem umieszczenia informacji o źródle materiału i autorze. Autorem jest Piotr Biernacki.1. GENEZA BPMNOd lat istniały dwa światy modelowania procesów biznesowych — świat analityków biznesowych i świat programistów. 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. Mimo, że zaproponowany przez OMG UML stał się praktyczne standardem dla programistów to jednak próby przekonania analityków biznesowych do UML’a kończyły się niepowodzeniem — był on za trudny dla „zwykłych” uczestników procesów biznesowych, dla których budowane są modele analityczne. Z resztą i analitycy mieli kłopoty z ich zrozumieniem co powodowało, że informatyczną implementację procesu przyjmowali „na słowo”.
Na początku lat 2000 grupa analityków i przedstawicieli firm informatycznych skupiona w BPMI postanowiła zaproponować notację stanowiącą kompromis pomiędzy zrozumiałością modeli biznesowych i wymaganiami modeli implementacji. Tak powstała notacja BPMN. Wykorzystuje ona doświadczenia takich firm jak BEA, 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. PODSTAWOWE INFORMACJE O BPMN2.1. CZYM JEST BPMN?
Business Process Modeling Notation (BPMN) jest graficzną notacją opisującą kroki w procesie biznesowym. Została specjalnie zaprojektowana tak, aby odzwierciedlić przepływ procesu i informacji pomiędzy różnymi.
2.2. DLACZEGO BPMN JEST TAK ISTOTNY?
W ostatnich czasach coraz częściej procesy biznesowe są wynoszone poza organizację, gdzie stają się fragmentami procesów tamtych organizacji. Zaistniała potrzeba pokazania relacji pomiędzy niezależnymi procesami. Ponieważ w różnych organizacjach do opisu procesów mogły być wykorzystywane różne narzędzia wzrastało ryzyko nieporozumień pomiędzy nimi. Przed BPMN nie było standardu opisującego relacje pomiędzy procesami przebiegającymi u różnych uczestników. Dlatego najważniejsi gracze na tym rynki zaproponowali BPMN – bezpłatny standard opisu procesów i relacji pomiędzy nimi. Od tego momentu przestało być istotne w jakim narzędziu tworzone są modele procesów – nacisk został przełożony na opis zrozumiały dla wszystkich uczestników bez względu na zastosowane narzędzia.
Równie istotne jest to, że BPMN zaproponował jednoznaczny sposób translacji tak zaprojektowanych diagramów do innego standardu – BPEL. Ułatwia to migrację pomiędzy narzędziami implementacji procesów. Tak więc w przypadku wybrania BPMN jako metody opisu obiegu informacji w systemach IT istnieje możliwość automatycznej ich implementacji w różnych systemach dających się wysterować BPEL’em. Uniezależnia to od rozwiązań dostawcy (łatwiej zmienić dostawcę) jak i ułatwia konsolidację firm w które przed konsolidacją korzystały z różnych narzędzi.
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).
Ostatnią zaletą standardu jest standaryzacja szkoleń. Przy rozwiązaniach bazujących na oprogramowaniu konkretnej firmy szkolenia były w zasadzie szkoleniami dotyczącymi wykorzystania danego narzędzia w opisie procesów. Trudno było znaleźć rozgraniczenie pomiędzy metodyką cechami oprogramowania. Nowe narzędzie oznaczało nowe szkolenie Przy BPMN na potrzeby szkolenia można wybrać dowolne narzędzie, gdyż bez względu na docelową implementację wszystkie najważniejsze zasady opisu procesu pozostają bez zmian. Zwiększa to szybkość przepływu wiedzy, gdyż trenerzy rozwijają przede wszystkim swoją wiedzę związaną z metodyką opisu a nie z narzędziami.
2.3. KTO POWINIEN ZAINTERESOWAĆ SIĘ 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 (np. Six Sigma Black Belts i Six Sigma Green Belts, Lean Manufacturing ), analitycy Rachunku Kosztów Działań (ABC). Ł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’u. 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).
Szczególną rolę może pełnić BPMN 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.
2.4. JAKIE SĄ ZASADNICZE RÓŻNICE POMIĘDZY BPMN A UML?
UML służy obiektowo zorientowanemu modelowaniu aplikacji natomiast BPMN procesowo zorientowanemu modelowaniu systemów. Ponieważ BPMN jest zogniskowany na procesach biznesowych (i ich wsparciu przez systemy informatyczne) a UML na projektowaniu oprogramowania można powiedzieć, że obie notacje są komplementarne względem siebie, gdyż pokazują różne punkty widzenia na modelowanie systemów.
Co również istotne obie notacje są ze sobą zgodne co do idei. Nie wszystkie procesy biznesowe muszą być realizowane w postaci zautomatyzowanych procesów biznesowych wykonywanych za pomocą języka realizacji procesów. Jeśli taka automatyzacja jest niezbędna to procesy i ich uczestnicy mogą być doprecyzowani w postaci modeli behawioralnych języku UML. Jeśli jednak te „cegiełki” zachowania się zautomatyzowanych procesów są już zdefiniowane w postaci tzw. Web Serwisów to modele BPMN po przekonwertowaniu do BPEL umożliwiają „wywoływanie tych cegiełek”.
2.5. JAKIE SĄ RELACJE POMIĘDZY BPMN A BPEL?
BPEL to oparty na XML u język opisujący procesy biznesowe w którym większość zadań to interakcje pomiędzy procesami a zewnętrznymi Web Serwisami. Proces sam w sobie jest przedstawiany jako Web Serwis i jest wykonywany przez maszynę BPEL, która wykonuje opisy procesu.
BPMN to standardowy zestaw konwencji opisu diagramu procesu biznesowego zaprojektowany do wizualizacji bogatego zestawu sematyk dotyczących przepływu procesu i jego komunikacji z innymi niezależnymi procesami. Przewidziano w nim możliwość umieszczenia wystarczającej ilości informacji by stał się graficzną reprezentacją wykonywalnego procesu. Ponieważ standardem języka do realizacji procesów w systemach informatycznych jest BPEL to BPMN umożliwia eksport procesu do tego właśnie języka.
Jednakże BPMN umożliwia zastosowanie technik nie wspieranych przez BPEL (np. podprocesy Ad Hoc). Ich pokazanie ma wtedy jedynie wartość analityczną.
3. ZASADY BUDOWY DIAGRAMÓW W BPMN3.6. OBIEKTY WYKORZYSTANE DO MODELOWANIA PRZEPŁYWU
Podstawowe 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:
Obiekty przepływu
- Zdarzenia – Events1
- Czynności – Activities1
- Bramki – Gateways1
- Inne obiekty – Artefakty1
Elementy łączenia obiektów
- Przebieg procesu (Przepływ sekwencyjny) – Sequence Flow1
- Przebieg informacji – Message Flow1
- Powiązania – Association1
Artefakty
- Dane1
- Adnotacje1
- Grupy1
Miejsca realizacji procesu
- Jednostki (Uczestnicy) – Pools1
- Role Biznesowe (Partycje, Tory) – Lanes1
3.7. KONCEPCJA ŻETONU – TOKENA
W BPMN pojedyncza transakcja jest reprezentowana przez żeton, który „krąży” zgodnie z przepływem w procesie i „przechodzi” przez modelowane obiekty. Żeton posiada unikalny identyfikator ID zwany czasem TokenID. Początek procesu biznesowego generuje żeton z identyfikatorem TokenID
Główny TokenID jest wspólny dla wszystkich nowych żetonów generowanych w czasie rozwidlenia przepływu procesu. Nazwa się je czasem „rodziną żetonów”. Unikalne dla każdej nowej ścieżki w przypadku jej rozwidlenia uzupełnienie identyfikatora głównego TokenID nazywane jest czasem SubTokenID. Jeśli ścieżki się łączą w taki sposób, że tylko jeden żeton może przejść dalej to po taki połączeniu SubTokenID może zostać „odcięty”.
3.8. OBIEKTY PRZEBIEGU
3.8.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. Mogą rozpoczynać (zdarzenia początkowe), przerywać (pośrednie) lub kończyć (końcowe) przebieg.
3.8.1.1. ZDARZENIE POCZĄTKOWE
Wskazuje miejsce w którym w procesie generowana jest transakcja (pojawia się żeton). Proces może posiadać wiele zdarzeń początkowych. Każde takie zdarzenie jest traktowane jako niezależne
Zdarzenie początkowe jest obrazowane w postaci okręgu o pojedynczej cienkiej linii + ew. symbol oznaczający rodzaj zdarzenia
Generuje żeton dla każdego przepływu sekwencyjnego. Do zdarzenia „start” nie mogą być przyłączone żadne przepływy z obiektami
W podprocesach można nie pokazywać zdarzenia początkowego ale:
· Jeżeli jest zdarzenie końcowe (End), musi być obowiązkowo zdarzenie początkowe (Start)
· Jeżeli jest zdarzenie początkowe, wszystkie pozostałe przepływy muszą wynikać z tego zdarzenia
· Wyjątek : czynności kompensacyjne
Nie wszystkie zdarzenia mogą być zdarzeniami początkowymi. Dozwolone:
· odebranie wiadomości
· czas
· zasada
· łącze z ...
· wielokrotne
· (nieokreślone)
3.8.1.2. ZDARZENIE TYPU KOŃCOWE
Wskazuje zakończenie procesu / gałęzi procesu. Kończy przebieg transakcji w danej gałęzi, „konsumuje” żeton wygenerowany przez zdarzenie (zdarzenia) początkowe Może być wiele różnych zdarzeń końcowych kończących proces
Zdarzenie końcowe jest obrazowane w postaci okręgu o pojedynczej grubej linii + ew. symbol oznaczający rodzaj zdarzenia
Jeżeli jest zdarzenie rozpoczynające proces, musi być przynajmniej jedno zdarzenie kończące proces. Jeżeli jest zdarzenie końcowe, to musi być ono rezultatem dla przynajmniej jednego przebiegu sekwencyjnego.
Nie każde zdarzenie może być końcowym. Dozwolone:
· wysłanie wiadomości
· wyjątek / usterka
· anulowanie
· kompensacja
· łącze do ...
· zerwanie
· wielokrotne
3.8.1.3. ZDARZENIE POŚREDNIE (1)
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 + ew. symbol 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
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
Rys. 6. Zdarzenia pośrednie w inicjacji kompensacji
Nie każde zdarzenie może być zdarzeniem pośrednim. Dozwolone:
· wysłanie/odebranie wiadomości
· czas
· wyjątek/usterka
· anulowanie (tylko jako przebieg wyjątkowy, dla podprocesu typu „transakcja biznesowa”)
· kompensacja
· zasada
· wielokrotne
3.8.2. CZYNNOŚCI
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
Podprocesy mogą być przedstawiane w wersji rozwiniętej pokazującej w jaki sposób realizowany jest dany podproces.
Notacja BPMN pozwala na to by czynności posiadały również cechy:
· Bramki dzielącej typu AND (najczęściej właśnie tak się pokazuje podział na ścieżki równoległe)
· Bramki decyzyjnej XOR lub OR- czynność z wbudowaną decyzją
· Zdarzenia - czynność Typu „odebranie / wysłanie wiadomości”
Rys. 8. Czynności o atrybutach innych obiektów
Czynności mogą mieć jeden lub więcej znaczników,
Ciekawym typem czynności jest podproces typu Transakcja Biznesowa. Czynności te są wspierane protokółem transakcji w rozumieniu Web Services i dzięki temu mogą być całkowicie zautomatyzowane.
Czynność typu Transakcja Biznesowa pokazywana jest podwójną krawędzią. Normalny przepływ wychodzący pokazuje ścieżkę jaka będzie wybrana w przypadku zakończenia transakcji sukcesem. Zdarzenie pośrednie Anulowanie pokazuje ścieżkę, jaka występuje w przypadku anulowania zadania. Anulowanie może być zdarzeniem pośrednim inicjującym przepływ warunkowy jedynie w przypadku obsługi anulowania w czynności typu Transakcja Biznesowa. Zdarzenie pośrednie Wyjątek pokazuje ścieżkę jaka będzie wybrana w wypadku obsługi niestandardowej (tutaj niemożliwość realizacji transakcji automatycznej z wykorzystaniem Web Serwisów). Czynności wykorzystywane do kompensacji są rysowane poza normalnym przebiegiem i są skojarzone z czynnościami, których prawidłowe działanie należy odwołać na skutek braku możliwości zakończenia sukcesem działań w innych gałęziach. Nie są rysowane w normalnym przebiegu, gdyż nie są elementami tego procesu (tu rezerwacji biletów i noclegu)
Rys. 9. Przykład czynności typu Transakcji Biznesowa
3.8.3. BRAMKI
Bramki to elementy służące do kontrolowania w jaki sposób ścieżki przepływu wchodzą w interakcję ze sobą. Bramki decyzyjne określają ile żetonów będzie prze-chodziło którymi ścieżkami. Bramki łączące określają które żetony przejdą dalej lub jak się połączą. Bramki nie muszą występować w procesie (jeśli nie istnieje potrzeba sterowania przebiegiem procesu).
3.8.3.1. BRAMKA XOR
Bramka XOR może być wykorzystana jako:
· Bramka decyzyjna
· Bramka łącząca
Dwa typy bramki XOR (ALBO)
· Wyzwalana danymi Data-Based, oznaczana rombem z symbolem x albo pustym rombem ew. z napisem określającym działanie bramki.
· Wyzwalana zdarzeniem (Bramka Zdarzenie) Event-Based, oznaczana rombem z gwiazdką w okręgu z podwójną cienką linią. Ta bramka występuje jedynie jako decyzyjna.
Bramka decyzyjna XOR (wyzwalana danymi) pozwala na wybranie tylko jednej ścieżki z dowolnie wielu wariantów (tylu, ile jest wyjść). Definiuje alternatywne ścieżki przebiegu dla żetonu. Musi mieć przypisaną logikę decyzyjną.
Jest to najczęściej wykorzystywany typ bramki. Wykorzystuje dane przypisane żetonowi lub procesowi aby określić jaka ścieżką zostanie wybrana np.:
· Proces jest w stanie w którym występuje konieczność wyboru ścieżki awaryjnej – Tak albo Nie
· butelka duża – Prawda albo Fałsz
W bramce decyzyjnej XOR warunki sprawdzane w określonej kolejności: jeśli pierwszy warunek spełniony żeton idzie tą ścieżką, jeśli nie sprawdzany jest następny warunek. Jedna ze ścieżek może być domyślną (ukośnik na linii). Wybór tej ścieżki rozważany jako ostatni warunek (jeśli inne nie – to ta ścieżka). Wskazanie ścieżki domyślnej nie jest obowiązkowe (nie mniej brak ścieżki przy możliwości, że wszystkie ścieżki są na nie, traktowany jest jako błąd konstrukcji).
Bramka Decyzyjna XOR Wyzwalana Zdarzeniem nazywana jest czasem bramką typu Zdarzenie. Wybór odpowiedniego wyjścia odbywa się na podstawie informacji z powiązanego z nią zdarzenia. Na wyjściu z bramki XOR mogą być zdarzenia typu:
· odbierz wiadomość
· czas
· zasada
Dopuszczalne są również czynności sterowane odebraną wiadomością.
Łącząca bramka XOR, łączy kilka przebiegów w jeden. Tylko pierwszy zaakceptowany żeton przechodzi dalej, pozostałe są usuwane!!! Pokazywana jest w posta-ci rombu z X w środku, pustego albo z opisem w środku. Można nią pokazać zakończenie ścieżki, której początkiem była bramka decyzyjna XOR ale najczęściej jest wykorzystywana do pokazania sytuacji, gdzie mamy ścieżki dublujące się i tylko szybsza jest akceptowana.
Rys. 11. Bramki XOR
Uwaga! Sytuacja A różna od B, szary przebieg nie jest wykonywany
3.8.3.2. BRAMKA OR
Bramka typu OR może być wykorzystywana jako:
· Bramka decyzyjna
· Bramka łącząca
Pokazywana jest w postaci rombu z o w środku.
W bramce OR decyzyjnej przynajmniej jedna ścieżka musi być wybrana. Musi mieć przypisaną logikę decyzyjną dla każdej ścieżki i definiuje alternatywne ścieżki przebiegu dla żetonu zgodnie z tą logiką. Każda wychodząca ścieżka jest niezależnym przepływem. Spełnienie warunku dla danej ścieżki nie wstrzymuje sprawdzania dla pozostałych.
Bramka łącząca OR czeka na wszystkie żetony które mają nadejść (synchronizuje je). Nie wymaga żetonów ze wszystkich ścieżek wejściowych (jak bramka AND)
Najczęściej jest stosowana na zejściu się ścieżek po bramce decyzyjnej OR.
3.8.3.3. BRAMKA ZŁOŻONA
Bramka złożona obsługuje sytuacje które trudno zamodelować przez inne bramki. Bywa także wykorzystywana jako jedna bramka zamiast kilku podstawowych
Może być używana jako:
· Bramka decyzyjna
· Bramka łącząca
Pokazywana jest jako romb z ośmioramienną gwiazdką w środku
W złożonej bramce decyzyjnej wyrażenie opisujące bramkę decyduje o jej charakterze i „zasadach działania”. Przynajmniej jedna ze ścieżek powinna być wybrana.
W złożonej bramce łączącej logika bramki określa, które z przychodzących ścieżek (i związane z nimi żeton) zostaną wybrane aby dalej kontynuować realizację procesu.
3.8.3.4. BRAMKA RÓWNOLEGŁA (AND)
Bramka I (AND) może być wykorzystywana jako:
· Bramka rozdzielająca (Fork)
· Bramka łącząca
Pokazywana jest w postaci rombu z + w środku
Jako bramka rozdzielająca AND jest wykorzystywana do tworzenia współbieżnych przepływów. W BPMN bramka nie jest wymagana (każdy przebieg odchodzący od danego symbolu działa tak jak taka bramka), ale czasem jest zalecana dla zachowania przejrzystości modelowania
Bramka łącząca AND służy do łączenia ścieżek równoległych. Oczekuje na żeton z każdej ścieżki. Po zebraniu ostatniego żetonu łączy je i dalej przechodzi jeden żeton.
3.9. OBIEKTY NIE BĘDĄCE OBIEKTAMI PRZEBIEGU
3.9.1. UCZESTNICY I TORY
BPMN wykorzystuje pojęcie torów (swimlanes) najczęściej w celu pokazania z jaką rolą biznesową związana jest dana czynność, lub jaki system ją realizuje. Wy-stępują następujące obiekty:
· Uczestnik – Pool
· Tor (Rola biznesowa) – Lane
Tory i uczestnicy mogą być rysowani w poziomie albo pionie. Każdy schemat w BPMN posiada domyślnie jednego uczestnika. Jeśli jest tylko jeden uczestnik i nie ma podziału na tory lub tylko jeden uczestnik ma rozpisane swój proces i nie ma po-działu na tory to schemat nie musi zawierać ramki wokół tego uczestnika ani nazwy.
Rys. 13. Uczestnicy i tory – dopuszczalny sposób zapisu
Diagram BPMN może przedstawiać więcej niż jeden proces, ale każdy proces biznesowy musi odbywać u innego uczestnika i przy jednej konwersji do BPEL4WS konwertowany jest tylko jeden proces
W BPMN jeśli twórca diagramu zna proces danego uczestnika to może mu wysłać tą informację w konkretne miejsce jego procesu. Nie musi jednak znać jego procesu, więc wiadomość może być te z wysłana „do uczestnika”
Dlaczego nie ma przepływy procesu pomiędzy uczestnikami? Inny uczestnik realizuje swój proces, na którego realizację nie mamy wpływu. Gdy jego proces osiągnie odpowiedni stan może on przesłać informację do uczestnika, a ten może tą informację odebrać i na jej podstawie kontynuować realizację swojego procesu.
3.9.2. POŁĄCZENIA
W BPMN występują trzy sposoby łączenia obiektów:
· Przebieg procesu – Sequence Flow, który jest wykorzystywany do pokazy-wania kolejności wykonywania poszczególnych czynności w procesie.
· Przebieg wiadomości Message Flow, który jest wykorzystywany do pokazywania przekazywania informacji pomiędzy dwoma autonomicznymi jednostkami (uczestnikami) procesu uprawnionymi do wysyłania i odbierania ich.
· Powiązania Association, które są wykorzystywane do połączenia informacji i artefaktów z czynnościami, zdarzeniami, bramkami i przebiegami.
Przebieg procesu pokazuje kolejność wykonywanych czynności w procesie. Żeton porusza się sekwencyjnie od źródła do celu zgodnie z kierunkiem strzałki. Może mieć tylko jedno źródło i jeden cel:
· Zdarzenie
· Czynność
· Bramka
Uwaga!!! Informacja przekazywana w ramach uczestnika traktowana jest jak każda inna transakcja w przebiegu procesu
Przebieg wiadomości (Informacji) – Message Flow 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,
· przebiegami
· pokazywania czynności / podprocesu wykorzystywanego do kompensacji procesu
Powiązanie może mieć kierunek. Powiązania są pokazywane w postaci cienkiej linii kropkowanej:
· bez zakończenia - przyłączenia artefaktów
· zakończonej otwartą strzałką - przepływ danych
· zakończonej pełną strzałką - kompensacja
1.9.3. ARTEFAKTY
Artefakty są elementami diagramu wykorzystywanymi aby pokazać dodatkowe in-formacje 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 arte-fakty:
· Obiekty danych Data Objects
· Adnotacje Annotations
· Grupy Groups
Użytkownik można definiować nowe typy artefaktów4. RÓŻNE SPOSOBY WYKORZYSTYWANIA DIAGRAMÓW BPMN4.10. OPIS PROCESU BIZNESOWEGO.
.
Rys. 15. Proces biznesowy
Najczęstszy sposób wykorzystywania diagramów BPMN. Opisywany jest przebieg procesu, często bez rozpisania na role biznesowe.
Rys. 16. Proces biznesowy rozpisany na uczestników.
Typowy sposób opisu procesów tak, aby pokazać przepływ informacji pomiędzy różnymi uczestnikami i systemami zaangażowanymi w realizację procesu. Metoda skuteczna przy analizie systemu informacyjnego organizacji np. na potrzeby wdrożenia systemów ERP, WorkFlow i t.p.
Rys. 17. Proces biznesowy zakupu książki (do automatycznego konwersji na BPEL).
Typowy model pozwalającym na tworzenie oprogramowania np. witryny internetowej realizującej określone zadania.
Rys. 17. Proces biznesowy dostawy tworzony na potrzeby analityki..
Ten typ diagramów BPMN jest najczęściej wykorzystywany (po odpowiednim sparametryzowaniu) do pogłębionej analizy procesów
Przydatne łącza:skrót do polskiego Forum BPMN
skrót do wpisu w Wikipedii
skrót witryny BPMN
skrót do informacji o firmach wspierających  Oprogramowanie do tworzenia modeli BPMN Przykładowe aplikacje wspierające BPMN. Jeśli znają Państwo inne aplikacje, mogą je zrecenzować i chcieliby by Państwo umieścić je na tej liście to proszę o kontakt.
iGrafx - bardzo dobre modelowanie, możliwość symulacji, kontrola poprawności modelu z wymogamo BPMN
Magic Draw - wymaga specjalnego pluginu. Na razie wersja beta.
BPMN for ADONIS®. Jest to nakładka na Adonisa.
Borland Together 2006 for Elipse 3.2
Business Process Visual ARCHITECT Modeler Edition 1.0
Microsoft Visio wymaga specjalnego szablonu: Visio stencil (twórca - Orbus Software)
Enterprise Architect - wymaga rozszerzenia i specjalnego profilu
Corporate Modeler 10 - Casewise - wymaga specjalnego rozszerzenia. Załączony przykład dokumentu niezgodny z BPMN.
|
