BPMN

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 BPMN

Od 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 BPMN

2.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 BPMN

3.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”.

\"BPMN

3.8 OBIEKTY

3.8.1 ZDARZENIA

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

 

 

\"BPMN

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

 

\"BPMN

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).

\"BPMN

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

3.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ów

4. RÓŻNE SPOSOBY WYKORZYSTYWANIA DIAGRAMÓW BPMN

4.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:

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.

 

 

Kategoria: