Notacja BPMN – Jak czytać diagramy

(na pod­sta­wie https://​www​.visu​al​-para​digm​.com/​g​u​i​d​e​/​b​p​m​n​/​w​h​a​t​-​i​s​-​b​p​mn/, korek­ta tłu­ma­cze­nia maszy­no­we­go i roz­sze­rze­nie: Jarosław Żeliński).

Wprowadzenie

Business Process Modeling Notation (BPMN) to gra­ficz­ny język mode­lo­wa­nia wyko­rzy­sty­wa­ny, na eta­pie ana­li­zy biz­ne­so­wej, do spe­cy­fi­ko­wa­nia prze­pły­wów pro­ce­sów pra­cy w przed­się­bior­stwie. Jest otwar­tym stan­dar­dem nota­cyj­nym dla gra­ficz­nych dia­gra­mów prze­pły­wu wyko­rzy­sty­wa­nych do opi­su prze­pły­wów pro­ce­sów biz­ne­so­wych. Jest to popu­lar­ny i intu­icyj­ny język gra­ficz­ny, któ­ry może być łatwo zro­zu­mia­ny przez wszyst­kich inte­re­sa­riu­szy biz­ne­so­wych, w tym użyt­kow­ni­ków biz­ne­so­wych, ana­li­ty­ków biz­ne­so­wych, pro­gra­mi­stów i archi­tek­tów danych.

Opis ten powstał dla pra­cow­ni­ków firm moich klien­tów (dla nich zapo­zna­nie się z tym doku­men­tem jest obo­wiąz­kiem wyni­ka­ją­cym z zawar­tej umo­wy), jest to jed­nak doku­ment publicz­nie dostęp­ny, adre­so­wa­ny do każ­de­go, kto ma do czy­nie­nia z ana­li­tycz­ny­mi mode­la­mi pro­ce­sów biz­ne­so­wych wyko­na­nych z uży­ciem nota­cji BPMN .

Krótka historia BPMN

BPMN wywo­dzi się z syn­te­zy wie­lu nota­cji mode­lo­wa­nia biz­ne­so­we­go. Pierwotnie opu­bli­ko­wa­ny przez Business Process Management Initiative (BPMI) w 2004 roku. BPMN jest obec­nie utrzy­my­wa­ny przez OMG, ponie­waż te dwie orga­ni­za­cje połą­czy­ły się w 2005 roku (BPMI połą­czy­ło się z OMG, czy­li Object Management Group). Specyfikacja BPMN zosta­ła wyda­na przez OMG w lutym 2006 roku. Wersja 2.0 BPMN zosta­ła opra­co­wa­na w 2010 roku, a obec­na wer­sja spe­cy­fi­ka­cji zosta­ła wyda­na w grud­niu 2013 roku. Najnowsza wer­sja (BPMN 2.0.2) zosta­ła for­mal­nie opu­bli­ko­wa­na przez ISO jako stan­dard edy­cji 2013: ISO/IEC 19510.

Korzyści wynikające z BPMN

BPMN pozwa­la uchwy­cić i udo­ku­men­to­wać pro­ce­sy biz­ne­so­we orga­ni­za­cji w jasny i spój­ny spo­sób, któ­ry zapew­nia, że odpo­wied­ni inte­re­sa­riu­sze, tacy jak wła­ści­cie­le pro­ce­sów i użyt­kow­ni­cy biz­ne­so­wi, są łatwo anga­żo­wa­ni w pro­ces ana­li­zy. Dzięki temu, zespół pro­jek­to­wy może sku­tecz­niej reago­wać na wszel­kie pro­ble­my ziden­ty­fi­ko­wa­ne w pro­ce­sach. BPMN dostar­cza wszech­stron­ne i jed­no­cze­śnie boga­te w treść, sym­bo­le nota­cji, któ­re mogą być łatwo zro­zu­mia­ne zarów­no przez inte­re­sa­riu­szy tech­nicz­nych, jak i nie­tech­nicz­nych. Modelowanie pro­ce­sów biz­ne­so­wych zapew­nia istot­ne korzy­ści dla firm i orga­ni­za­cji, takie jak te wymie­nio­ne poniżej:

  • Standard prze­my­sło­wy opra­co­wa­ny przez kon­sor­cjum OMG, gru­pę prze­my­sło­wą typu not-for-profit.
  • Zapewnia przed­się­bior­stwom moż­li­wość defi­nio­wa­nia i zro­zu­mie­nia ich procedur.
  • Zapewnienie stan­dar­do­wej nota­cji, któ­ra jest łatwo zro­zu­mia­ła dla wszyst­kich inte­re­sa­riu­szy biznesowych.
  • Wypełnienie luki komu­ni­ka­cyj­nej, któ­ra czę­sto wystę­pu­je pomię­dzy pro­jek­to­wa­niem i wdra­ża­niem pro­ce­sów biznesowych.
  • Prosty do opa­no­wa­nia, ale wystar­cza­ją­co wydaj­ny, aby zobra­zo­wać poten­cjal­ną zło­żo­ność pro­ce­su biznesowego.

Adresaci BPMN

  • Eksperci tech­nicz­ni odpo­wie­dzial­ni za reali­za­cję procesu.
  • Analitycy biz­ne­so­wi, któ­rzy two­rzą i uspraw­nia­ją procesy.
  • Menedżerowie, któ­rzy moni­to­ru­ją i kon­tro­lu­ją procesy.

Notacja BPMN

W BPMN pro­ce­sy opi­sy­wa­ne są za pomo­cą dia­gra­mów zawie­ra­ją­cych sze­reg ele­men­tów gra­ficz­nych. Taka wizu­al­na pre­zen­ta­cja uła­twia użyt­kow­ni­kom zro­zu­mie­nie logi­ki pro­ce­sów biz­ne­so­wych i ich związ­ków mię­dzy nimi.

BPMN został opra­co­wa­ny przede wszyst­kim z myślą o pro­jek­to­wa­niu i odczy­ty­wa­niu zarów­no pro­stych (poglą­do­we i ana­li­tycz­ne), jak i zło­żo­nych (wyko­ny­wal­ne) dia­gra­mów pro­ce­sów biz­ne­so­wych. W tym celu stan­dard BPMN kla­sy­fi­ku­je ele­men­ty gra­ficz­ne według tych kate­go­rii (poglą­do­we, ana­li­tycz­ne, wyko­ny­wal­ne). Dzięki temu ele­men­ty te są łatwo roz­po­zna­wal­ne przez użyt­kow­ni­ków pra­cu­ją­cych z dia­gra­ma­mi pro­ce­sów biznesowych.

Podstawowym ele­men­tem na eta­pie Analizy Biznesowej jest ana­li­tycz­ny pro­ces biz­ne­so­wy (ana­ly­tic non-exe­cu­ta­ble pro­cess, patrz spe­cy­fi­ka­cja BPMN 2.0.2., rozdz. 2.2.1 BPMN Process Types: Both Descriptive and Analytic focus on visi­ble ele­ments and a mini­mal sub­set of sup­por­ting attributes/elements”) defi­nio­wa­ny jako abs­trak­cyj­na aktyw­ność mają­ca okre­ślo­ny cel biz­ne­so­wy, a tym celem jest, co do zasa­dy, two­rzo­na lub zmie­nia treść (doku­ment, DataObject). Każdy pro­ces biz­ne­so­wy skła­da się z ele­men­tar­nych (ato­mo­wych) aktyw­no­ści tak­że mają­cych okre­ślo­ny cel (pro­dukt), są to ele­men­tar­ne (ato­mo­we) pro­ce­sy biz­ne­so­we. W mode­lach ana­li­tycz­nych model, szcze­gó­ły ele­men­tar­nych aktyw­no­ści (ato­mo­wych pro­ce­sów biz­ne­so­wych) doku­men­to­wa­ne są osob­no jako pro­ce­du­ry (mogą to być opi­sy, tabe­le, ale tak­że kolej­ne diagramy).

Niniejszy opis doty­czy wyłącz­nie mode­li analitycznych.

Podstawowe elementy

Istnieje pięć pod­sta­wo­wych kate­go­rii ele­men­tów BPMN. Każda z nich repre­zen­tu­je uni­kal­ny aspekt pro­ce­su biznesowego.

Pule i tory (swimlanes)

Swimlanes

Pule (Pool) i tory (lane) są gra­ficz­ny­mi kon­te­ne­ra­mi repre­zen­tu­ją­cy­mi uczest­ni­ków pro­ce­su. Istnieją dwa rodza­je kon­te­ne­rów: pule (pool) repre­zen­tu­ją­ce orga­ni­za­cje i pod­mio­ty (uczest­ni­cy pro­ce­su), oraz tory (lane, pasy wewnątrz puli), repre­zen­tu­ją­ce komór­ki orga­ni­za­cyj­ne, sta­no­wi­ska role.

Elementy przepływu – symbole

Flow Elements

Elementy prze­pły­wu to ele­men­ty, któ­re łączą się ze sobą two­rząc prze­pływ pra­cy. Symbolizują aktyw­ne ele­men­ty pro­ce­su. Elementy prze­pły­wu są pod­sta­wo­wy­mi ele­men­ta­mi, któ­re defi­niu­ją logi­kę i prze­bieg pro­ce­su. Mamy trzy rodza­je ele­men­tów prze­pły­wu: Zdarzenia (Start, Intermediate, End), Aktywności (Task, Sub-Process) i Bramki (Gateway). UWAGA! Na dia­gra­mach ana­li­tycz­nych nie uży­wa­my sym­bo­li ozna­cza­ją­cych ele­men­ty kodu (dodat­ko­we ikon­ki wewnątrz ele­men­tów Task, są one prze­zna­czo­ne dla mode­li wyko­ny­wal­nych zwa­nych Common Executable).

Co do zasa­dy wszyst­kie ele­men­ty mode­li BPMN, ele­men­ty prze­pły­wu tak­że, muszą mieć okre­ślo­ne uni­kal­ne ety­kie­ty (pod­pi­sy). W nota­cji BPMN ety­kie­ta ele­men­tu dia­gra­mu jest tak­że jego iden­ty­fi­ka­to­rem na mode­lu ana­li­tycz­nym. W kon­kret­nych mode­lach nie powin­ny to być start” czy stop” a fak­tycz­ne zda­rze­nia np. Odebrano zamó­wie­nie (ini­cju­ją­ce), Fakturę dorę­czo­no (pośred­nie) czy Zamówienie zre­ali­zo­wa­no (koń­czą­ce).

Elementy przepływu – łączniki

Connecting Objects

Łączniki to ele­men­ty, któ­re łączą ele­men­ty prze­pły­wu i są nazy­wa­ne ?obiek­ta­mi łączą­cy­mi?. Istnieją czte­ry rodza­je obiek­tów łączą­cych: prze­pły­wy sekwen­cji (Sequence flow), prze­pły­wy komu­ni­ka­tów (Message flow), powią­za­nia poję­cio­we (Association) i powią­za­nia danych (Data Association).

Dokumenty (Obiekt Danych)

Data

Dokumenty (dane) to infor­ma­cje wyma­ga­ne lub wytwa­rza­ne pod­czas reali­za­cji pro­ce­su biz­ne­so­we­go. Notacja BPMN nie słu­ży jed­nak do mode­lo­wa­nia struk­tur danych (doku­men­tów, te mode­lu­je­my w nota­cji UML np. dia­gra­mem struk­tur zło­żo­nych). Istnieją czte­ry rodza­je tych sym­bo­li: Obiekty danych (Data Object) repre­zen­tu­ją doku­men­ty, wej­ścia danych (Data Input), wyj­ścia danych (Data Output) oraz maga­zy­ny danych (Data Stor). W mode­lach ana­li­tycz­nych sto­su­je­my wyłącz­nie Data Object. Struktura doku­men­tów (treść, sza­blon for­mu­la­rza) mode­lo­wa­na jest odręb­nie z uży­ciem nota­cji UML (dia­gram struk­tur zło­żo­nych) .

BPMN – modelowanie

Obiekty typu swim­la­nes (pule i tory) w BPMN są pro­sto­kąt­ny­mi pola­mi, któ­re repre­zen­tu­ją uczest­ni­ków pro­ce­su biz­ne­so­we­go. Mogą one zawie­rać obiek­ty prze­pły­wu, któ­re są wyko­ny­wa­ne przez dany tor (uczest­ni­ka), z wyjąt­kiem tak zwa­nej ?czar­nej skrzyn­ki? (opi­sa­na w dal­szej czę­ści tego opi­su). Na typo­wym dia­gra­mie, pro­ces prze­pły­wa od lewej do prawej.

Pule

Pule repre­zen­tu­ją uczest­ni­ków pro­ce­su biz­ne­so­we­go (orga­ni­za­cje i/lub ich klien­tów, tak­że samo­dziel­ne oso­by np. klien­ta fir­my, peten­ta urzędu).

Wewnątrz puli znaj­du­ją się ele­men­ty prze­pły­wu pro­ce­su. Reprezentują one zada­nia (pra­ce), któ­re muszą być wyko­na­ne w ramach mode­lo­wa­ne­go pro­ce­su. Istnieje tak­że rodzaj puli, któ­ry nie posia­da żad­nej zawar­to­ści. Jest to tak zwa­na czar­na skrzyn­ka (black­box). Pula black­box jest czę­sto uży­wa­na przy mode­lo­wa­niu pod­mio­tów zewnętrz­nych w sto­sun­ku do mode­lo­wa­ne­go pro­ce­su biz­ne­so­we­go. Ponieważ jest ona poza obsza­rem ana­li­zy, jej wewnętrz­ny prze­pływ nie ma żad­ne­go wpły­wu na mode­lo­wa­ny pro­ces, może on zostać pomi­nię­ty. Poniższy BPD (Business Proces Diagram, dia­gram pro­ce­su biz­ne­so­we­go) przed­sta­wia przy­kład puli z pro­ce­sem i czar­nej skrzyn­ki. Klient (Customer) jest czar­ną skrzyn­ką. Ponieważ pro­ces kon­cen­tru­je się na tym, jak kuch­nia (Chef) przy­go­to­wu­je posi­łek, to co robi klient nie jest przed­mio­tem opi­su pro­ce­su. Użycie czar­nej skrzyn­ki zale­ży od per­spek­ty­wy, jaką przyj­mu­je­my mode­lu­jąc proces.

Black Box Pool
(real­ny model zawie­rał by pod­pis pod zda­rze­niem ini­cju­ją­cym i kończącym)

Pule moż­na dzie­lić na tory (linie), repre­zen­tu­ją one wte­dy wewnętrz­ny podział na komór­ki orga­ni­za­cyj­ne lub role i sta­no­wi­ska. Wewnątrz każ­de­go toru znaj­du­ją się ele­men­ty prze­pły­wu. Reprezentują one pra­ce, któ­re musi wyko­nać (za któ­re odpo­wia­da) okre­ślo­na komór­ka orga­ni­za­cyj­na lub rola w ramach mode­lo­wa­ne­go procesu.

Aktywności

Aktywności są pra­ca­mi (ich nazwa­mi) wyko­ny­wa­ny­mi w ramach pro­ce­su biz­ne­so­we­go. Są one przed­sta­wio­ne w posta­ci zaokrą­glo­nych pro­sto­ką­tów, z nazwa­mi opi­su­ją­cy­mi pra­ce do wyko­na­nia. Istnieją dwa rodza­je aktyw­no­ści: Zadanie i Podproces. 

Gdy chce­my zamo­de­lo­wać ato­mo­wą (ele­men­tar­ną) pra­cę, któ­rej nie da się (lub nie ma potrze­by) dalej roz­ło­żyć na deta­le, lub poszcze­gól­ne kro­ki są zna­ne ale nie są samo­dziel­ne (wte­dy osob­no powsta­je opis: pro­ce­du­ra), uży­wa­my zada­nia (task):

Activity Tasks
Zadania

Jeżeli chce­my poka­zać, że zamo­de­lo­wa­no osob­no okre­ślo­ną zło­żo­ną pra­cę, któ­ra może być roz­ło­żo­na na mniej­sze ale samo­dziel­ne pod­rzęd­ne zada­nia (każ­de two­rzy jakiś pro­dukt), uży­wa­my sym­bo­lu pod­pro­ce­su. Oznacza to, że powstał dodat­ko­wy model jako kolej­ny poziom szcze­gó­ło­wo­ści (odręb­ny, sko­ja­rzo­ny dia­gram BPD). Podproces zawie­ra więc inny, pod­le­gły mu, dia­gram BPD mode­lu­ją­cy jego szczegóły.

Activity Sub Processes
Podprocesy

Wybór meto­dy opi­su jest zwią­za­ny z tym, jak skom­pli­ko­wa­na może być to pra­ca, ale rów­nież z tym, jak szcze­gó­ło­wa wie­dza na jej temat jest w danym pro­jek­cie ana­li­tycz­nym potrzebna.

Zdarzenia

Zdarzenia to coś, do cze­go docho­dzi i może mieć wpływ na pro­ces biz­ne­so­wy. Zdarzenie może być zarów­no zewnętrz­ne jak i wewnętrz­ne. Jeśli tyl­ko mogą mieć wpływ na mode­lo­wa­ny pro­ces, powin­ny zostać zamo­de­lo­wa­ne. Zdarzenia przed­sta­wia­ne są w posta­ci kółek. W nie­któ­rych przy­pad­kach wewnątrz nich znaj­du­ją się iko­ny, któ­re repre­zen­tu­ją typ zdarzenia.

Istnieją trzy głów­ne typy zda­rzeń: zda­rze­nie począt­ko­we (ini­cju­ją­ce), zda­rze­nie pośred­nie (prze­chwy­ty­wa­ne lub gene­ro­wa­ne) i zda­rze­nie koń­czą­ce. Dla każ­de­go z nich moż­na okre­ślić typ wyzwa­la­cza, któ­ry wska­że co powo­du­je, że zda­rze­nie jest wyzwa­la­ne (ini­cjo­wa­ne).

Każdy pro­ces powi­nien posia­dać zda­rze­nie ini­cju­ją­ce go, któ­re poka­zu­je począ­tek pro­ce­su biz­ne­so­we­go. Pozwala to czy­tel­ni­ko­wi na zlo­ka­li­zo­wa­nie w BPD miej­sca roz­po­czę­cia pro­ce­su. Zdarzenie koń­czą­ce słu­ży do wska­za­nia miej­sca zakoń­cze­nia pro­ce­su biz­ne­so­we­go, a zda­rze­nie pośred­nie jest odpo­wie­dzial­ne za ste­ro­wa­nie prze­pły­wem wewnątrz pro­ce­su biz­ne­so­we­go. Zdarzenie pośred­nie może być dołą­czo­ne do zada­nia (na jego kra­wę­dzi) w celu zamo­de­lo­wa­nia fak­tu, któ­ry może wystą­pić W TRAKCIE wyko­ny­wa­nia tej czyn­no­ści, jak rów­nież może być połą­czo­ne przez obiekt łączą­cy (strzał­ka) w celu zamo­de­lo­wa­nia zda­rze­nia, któ­re może wystą­pić PO wyko­na­niu wcze­śniej­sze­go ele­men­tu prze­pły­wu. Więcej o tym przy­pad­ku w dal­szej części.

Poniższy przy­kład poka­zu­je spo­sób poka­za­nie zda­rze­nia wystę­pu­ją­ce­go w tra­cie zada­nia. Diagram poniż­szy poka­zu­je, że momen­cie gdy otrzy­mu­je­my zamó­wie­nie (order?), zaczy­na­my je prze­twa­rzać. Jeśli i tyl­ko wte­dy, gdy prze­kro­czo­ny jest limit kre­dy­to­wy (no cre­dit limit), spraw­dza­my ten pro­blem (Check?) prze­ry­wa­jąc pra­ce nad Zamówieniem. Proces koń­czy się, gdy Zamówienie zosta­ło zre­ali­zo­wa­ne albo nie, ale pro­blem został zidentyfikowany.

BPMN Event Example
(real­ny model zawie­rał by pod­pis pod zda­rze­niem kończącym)

Bramki

Bramki są odpo­wie­dzial­ne za zobra­zo­wa­nie kon­tro­li prze­pły­wu pro­ce­sów biz­ne­so­wych. Są one przed­sta­wia­ne w posta­ci rom­bów. W pro­ce­sie, pra­ce do wyko­na­nia i wyj­ście mogą się róż­nić w zależ­no­ści od róż­nych warun­ków. Na przy­kład, rabat będzie ofe­ro­wa­ny tyl­ko kupu­ją­ce­mu VIP. Bramkę umiesz­cza­my by poka­zać, że warun­ki były oce­nia­ne i jaka decy­zja zosta­ła pod­ję­ta w poprze­dza­ją­cej tę bram­kę aktywności.

Oto kil­ka typo­wych rodza­jów bramek:

Bramka danych wyłącz­nej alter­na­ty­wy XOR (exc­lu­si­ve) , zwa­na rów­nież bram­ką wyłącz­ną, słu­ży do ste­ro­wa­nia prze­pły­wem pro­ce­su na pod­sta­wie danych (zawar­tość doku­men­tów: Data Object, tu nie poka­za­no). Każdy wycho­dzą­cy z bram­ki prze­pływ odpo­wia­da okre­ślo­ne­mu warun­ko­wi. Jeżeli warun­ki te wyklu­cza­ją się (tyl­ko jeden waru­nek może być tu speł­nio­ny) jest to bram­ka XOR.

Data Based Exclusive Gateway

Bramka wybo­ru OR (inc­lu­si­ve) może być uży­ta do two­rze­nia róż­nych jed­no­cze­snych ście­żek. Warunki wszyst­kich wycho­dzą­cych prze­pły­wów nie muszą się tu wza­jem­nie wyklu­czać. Wszystkie prze­pły­wy z pozy­tyw­nym wyni­kiem ozna­cza­ją kon­ty­nu­ację pro­ce­su. Dlatego też, może to skut­ko­wać wyko­na­niem wie­lu prze­pły­wów jed­no­cze­śnie, jeśli jed­no­cze­śnie speł­nio­ne są róż­ne warunki.

Inclusive Gateway

Z uwa­gi na to, że prze­pły­wy zale­żą od warun­ków i ich kom­bi­na­cje mogą być róż­ne, obec­nie obu opi­sa­nych wyżej bra­mek nie roz­róż­nia się gra­ficz­nie na dia­gra­mach (obec­nie, w mode­lach ana­li­tycz­nych, w obu przy­pad­kach sto­su­je się pusty sym­bol rom­bu).

Bramka rów­no­le­gła słu­ży do mode­lo­wa­nia obli­ga­to­ryj­ne­go dzie­le­nia (roz­wi­dle­nia) prze­pły­wu bez spraw­dza­nia jakich­kol­wiek warun­ków. Innymi sło­wy, wszyst­kie wycho­dzą­ce z niej prze­pły­wy muszą być wykonane.

BPMN Parallel Gateway

Bramka zda­rze­nio­wa jest uży­wa­na do mode­lo­wa­nia alter­na­tyw­nych ście­żek, gdzie warun­ka­mi są nie dane a zaist­nia­łe fak­ty (zda­rze­nia). Na przy­kład ocze­ki­wa­nie na odpo­wiedź Tak lub Nie, gdzie każ­da odpo­wiedź ma inne kon­se­kwen­cje (prze­pływ). Bramka ta jest zatem ste­ro­wa­na przez alter­na­tyw­ne zda­rze­nia (poni­żej wyzwa­lacz ozna­cza­ją­cy wia­do­mość). Kiedy któ­re­kol­wiek z tych zda­rzeń wystą­pi, reali­zo­wa­ny jest prze­pływ, któ­ry nastę­pu­je po tym zda­rze­niu. Wszystkie inne zda­rze­nia i będą­ce za nimi prze­pły­wy, nie będą już reali­zo­wa­ne (nie ist­nie­ją w BPMN odręb­ne zda­rze­nia jed­no­cze­sne). Poniżej przy­kład trzech alter­na­tyw­nych zda­rzeń: dwa komu­ni­ka­ty i gra­nicz­ny czas jaki upłynął.

BPMN Event Based Gateway

Przepływ sterowania (sekwencji)

Przepływ jest uży­wa­ny do łącze­nia ele­men­tów pro­ce­su. Jest on przed­sta­wio­ny jako linia skie­ro­wa­na cią­gła z otwar­tym gro­tem strzał­ki. Pokazuje kolej­ność ele­men­tów przepływu.

BPMN Sequence Flow

Przepływu ste­ro­wa­nia (sekwen­cja) moż­na uży­wać tyl­ko do łącze­nia ele­men­tów prze­pły­wu w obrę­bie tej samej puli. Aby połą­czyć ele­men­ty pomię­dzy pula­mi, nie wol­no użyć sekwen­cji, nale­ży użyć prze­pły­wu komunikatów.

Przepływy komunikatów

W BPMN komu­ni­ka­cja pomię­dzy pula­mi (repre­zen­tu­je wymia­nę tre­ści mię­dzy róż­ny­mi pod­mio­ta­mi) odby­wa się za pomo­cą komu­ni­ka­tów. Przepływ komu­ni­ka­tów jest uży­wa­ny do poka­za­nia prze­pły­wu tre­ści pomię­dzy pula­mi (pod­mio­ta­mi). Przepływ komu­ni­ka­tów jest przed­sta­wio­ny w posta­ci linii prze­ry­wa­nej z zamknię­tym gro­tem strzał­ki. Przykłady komu­ni­ka­tów mię­dzy pod­mio­ta­mi: faks, tele­fon, ema­il, list, zawia­do­mie­nie itp..

BPMN Message Flow

Dokumenty (Obiekty Danych)

Podczas wyko­ny­wa­nia pro­ce­su biz­ne­so­we­go, zgod­nie z defi­ni­cją, są gene­ro­wa­ne dane, zarów­no w trak­cie jak i po zakoń­cze­niu pro­ce­su. Na przy­kład, pomyśl­ne wyko­na­nie zada­nia Złóż zamó­wie­nie spo­wo­du­je wytwo­rze­nie danych takich jak zamó­wie­nie zaku­pu, fak­tu­ra, para­gon, itp. W BPMN, w mode­lach ana­li­tycz­nych, dane są mode­lo­wa­ne jako Obiekt danych. Istnieje tu tak­że moż­li­wość zde­fi­nio­wa­nia zarzą­dza­nia sta­na­mi tych doku­men­tów (wte­dy [nazwa sta­nu] jest umiesz­cza­na pod nazwą dokumentu).

BPMN Data

Asocjacja pomię­dzy Zadaniem a Dokumentem może być dodat­ko­wo skie­ro­wa­na, wska­zu­je to wte­dy czy jest to wej­ścio­wy czy wyj­ścio­wy dokument.

Grupy

Grupa to ram­ka w posta­ci linii prze­ry­wa­nej, zapew­nia­ją­ca mecha­nizm gru­po­wa­nia kształ­tów według róż­nych kate­go­rii, w real­nych mode­lach muszą mieć one tak­że nazwy.

BPMN Group
(real­ny model zawie­rał by pod­pis pod zda­rze­niem ini­cju­ją­cym i kończącym)

Adnotacje tekstowe

Adnotacja tek­sto­wa może być uży­ta do doda­nia dodat­ko­wych szcze­gó­łów do obiek­tów prze­pły­wu w BPD. Nie ma ona wpły­wu na prze­pływ, ale poda­je szcze­gó­ły doty­czą­ce obiek­tów w ramach prze­pły­wu: komentarze.

BPMN Text Annotation

BPMN – przykład

Firma True Aqua Distilled Water Company jest mło­dym dostaw­cą wody desty­lo­wa­nej w mie­ście. Sprzedaje wodę desty­lo­wa­ną dla biz­ne­su i do użyt­ku domo­we­go. Obecnie fir­ma True Aqua Distilled Water Company chce zwięk­szyć swój udział w ryn­ku z 5% do 10% w cią­gu naj­bliż­szych 12 – 18 mie­się­cy. Aby osią­gnąć ten cel, fir­ma sta­ra się zna­leźć spo­so­by na zwięk­sze­nie efek­tyw­no­ści ope­ra­cyj­nej i osią­gnię­cie wyż­sze­go pozio­mu satys­fak­cji klientów.

W związ­ku z tym fir­ma True Aqua Distilled Water Company posta­no­wi­ła uspraw­nić pro­ces zama­wia­nia wody desty­lo­wa­nej. Jesteś teraz ana­li­ty­kiem biz­ne­so­wym odpo­wie­dzial­nym za tę misję. Po spo­tka­niu z fir­mą True Aqua Distilled Water Company zebra­łeś nastę­pu­ją­ce infor­ma­cje na temat pro­ce­su zama­wia­nia. Przyjrzyjmy się temu.

Poniższy rysu­nek przed­sta­wia sche­mat pro­ce­su biz­ne­so­we­go dla pro­ce­su dostar­cza­nia wody desty­lo­wa­nej w fir­mie The True Aqua Distilled Water Company.

BPMN Business Process Diagram
(real­ny model zawie­rał by pod­pis pod zda­rze­niem ini­cju­ją­cym i kończącym)

Zgodnie z dia­gra­mem, aby zamó­wić wodę desty­lo­wa­ną klien­ci mogą albo zadzwo­nić na info­li­nię, albo wysłać do nas e‑mail. Obecnie 90% zamó­wień pocho­dzi z roz­mów tele­fo­nicz­nych, pod­czas gdy 10% zamó­wień skła­da­nych jest za pomo­cą pocz­ty elek­tro­nicz­nej. Pracownik obsłu­gi klien­ta, któ­ry otrzy­ma zamó­wie­nie, spraw­dzi czy klient jest już ist­nie­ją­cym czy nowym klien­tem. Jeśli klient nigdy wcze­śniej nie skła­dał zamó­wie­nia, asy­stent obsłu­gi klien­ta utwo­rzy dla nie­go kon­to klien­ta przed reali­za­cją zamówienia.

Dostawa wody desty­lo­wa­nej jest reali­zo­wa­na raz w tygo­dniu w każ­dą śro­dę. W związ­ku z tym w każ­dą śro­dę rano pra­cow­nik dzia­łu obsłu­gi klien­ta prze­ka­zu­je zamó­wie­nia do dzia­łu logi­sty­ki w celu reali­za­cji dosta­wy. Po otrzy­ma­niu zamó­wień kie­row­nik w Dziale Logistyki orga­ni­zu­je dosta­wę, przy­dzie­la­jąc pra­cow­ni­ków do obsłu­gi róż­nych zamó­wień, dru­ku­jąc i wywie­sza­jąc har­mo­no­gram. Pracownicy odbie­ra­ją tele­fo­ny i odpo­wied­nio dostar­cza­ją wodę do klienta.

Uzupełnienie diagramów BPMN – dodatkowe diagramy

Jak widać mode­le pro­ce­sów poka­zu­ją tyl­ko prze­pływ pra­cy i doku­men­tów ale nie poka­zu­ją deta­li two­rzo­nej tre­ści. Dlatego mode­le BPMN muszą być uzu­peł­nia­ne opi­sa­mi (np. dia­gra­my lub listy wypunk­to­wa­ne) pro­ce­dur i makie­ta­mi doku­men­tów, co poka­za­no sche­ma­tycz­nie poniżej:

Struktura modeli procesów biznesowych: proces, procedura, dokument.
Struktura mode­li pro­ce­sów biz­ne­so­wych. pro­ces, pro­ce­du­ra, doku­ment (źr. Makieta doku­men­tu)

(oso­by zain­te­re­so­wa­ne szcze­gó­ła­mi takich pojęć jak pro­ces biz­ne­so­wy i pro­ce­du­ry, oraz tym jak są one mode­lo­wa­nie, pole­cam arty­kuł Procesy biz­ne­so­we a pro­ce­du­ry)

Szkolenia

Osoby zain­te­re­so­wa­ne szko­le­niem i warsz­ta­ta­mi z tego zakre­su zapra­szam na stro­nę Szkolenia.

Literatura

OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/

Ostatnia aktu­ali­za­cja: sty 21, 2022 @ 18:14

Dodaj komentarz

Twój adres email nie zostanie opublikowany

System komentarzy służy także do uzyskania konsultacji u autora tekstu, w przedmiocie treści artykułu.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.