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

Opis ten powstał dla adre­sa­tów doku­men­tów zawie­ra­ją­cych sche­ma­ty blo­ko­we wyko­na­ne z uży­ciem nota­cji BPMN (pier­wot­nie dla pra­cow­ni­ków firm moich klien­tów, dla nich zapo­zna­nie się z tym doku­men­tem jest nadal 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 .

Wprowadzenie

Stosowanie sfor­ma­li­zo­wa­nych nota­cji ma jeden pod­sta­wo­wy cel: jed­no­znacz­ne wyra­że­nie i prze­ka­za­nie adre­sa­tom mode­li okre­ślo­nej tre­ści. Tak zwa­ny język natu­ral­ny, nawet upo­rząd­ko­wa­ny w listy i tabe­le, jest boga­ty w nie­jed­no­znacz­no­ści bo taką ma natu­rę. W efek­cie opi­sy wyko­na­ne z uży­ciem natu­ral­ne­go języ­ka (listy wypunk­to­wa­ne i tabe­le tak­że) są z zasa­dy nara­żo­ne na nie­jed­no­znacz­ność, a nauko­we bada­nia doku­men­ta­cji w pro­jek­tach z obsza­ru ana­li­zy biz­ne­so­wej oraz spe­cy­fi­ko­wa­nia wyma­gań potwier­dza­ją to .

Dlatego, aby zagwa­ran­to­wać jed­no­znacz­ność tre­ści czę­sto w miej­sce tak zwa­nej pro­zy, sto­su­je się sfor­ma­li­zo­wa­ne sche­ma­ty blo­ko­we, zwa­ne tak­że czę­sto mode­la­mi (model: ?kon­struk­cja, sche­mat lub opis uka­zu­ją­cy dzia­ła­nie, budo­wę, cechy, zależ­no­ści jakie­goś zja­wi­ska lub obiek­tu?, SJP). Kluczową cechą popraw­nie wyko­na­ne­go sche­ma­tu blo­ko­we­go jest legen­da uży­tych sym­bo­li i kon­struk­cji na dia­gra­mie, czy­li opis tego jak JEDNOZNACZNIE zin­ter­pre­to­wać taki dia­gram (seman­ty­ka i syn­tak­ty­ka notacji). 

Legenda sym­bo­li (nota­cja) jako umo­wa mię­dzy nadaw­cą i adre­sa­tem tre­ści. Każde zła­ma­nie” zasad legen­dy sym­bo­li w toku kodo­wa­nia, wpro­wa­dzi w błąd adre­sa­ta, któ­ry – jako adresat/odbiorca – z zasa­dy będzie lite­ral­nie inter­pre­to­wał uzgod­nio­ną legen­dę sym­bo­li (kod). Opracowanie wła­sne na pod­sta­wie: .

Niektóre dzie­dzi­ny i obsza­ry wie­dzy, z uwa­gi na ich powszech­ność, zosta­ły obję­te stan­dar­da­mi. W przy­pad­ku sche­ma­tów blo­ko­wych są nimi sfor­ma­li­zo­wa­ne nota­cje. Tam gdzie sche­mat blo­ko­wy jest mode­lem cze­goś, zwa­ne tak­że języ­ka­mi modelowania. 

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

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.

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 ele­men­tar­ny (ato­mo­wy) ana­li­tycz­ny pro­ces biz­ne­so­wy

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”

ana­ly­tic non-exe­cu­ta­ble pro­cess, patrz spe­cy­fi­ka­cja BPMN 2.0.2., rozdz. 2.2.1

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 – rza­dziej – kolej­ne dia­gra­my). Innymi sło­wy: ato­mo­wa aktyw­ność na mapie pro­ce­su (task) to nazwa procedury.

UWAGA! Niezbędnym uzu­peł­nie­niem mode­li pro­ce­sów biz­ne­so­wych, wyko­na­nych z uży­ciem nota­cji BPMN, są biz­ne­so­wy słow­nik pojęć oraz regu­ły biz­ne­so­we budo­wa­ne z jego uży­ciem. Co do zasa­dy logi­ka biz­ne­so­wa powin­na być doku­men­to­wa­na jako pro­ce­du­ry i regu­ły biz­ne­so­we a nie jako pro­ce­sy, zaś wspól­ny biz­ne­so­wy słow­nik pojęć to narzę­dzie pozwa­la­ją­ce utrzy­mać jed­no­znacz­ność i spój­ność cało­ści doku­men­ta­cji. Notacja BPMN nie słu­ży do mode­lo­wa­nia logi­ki biz­ne­so­wej tyl­ko do mode­lo­wa­nia prze­pły­wu pra­cy i war­to­ści doda­nej .

UWAGA! Dalszy opis doty­czy wyłącz­nie mode­li ana­li­tycz­nych, bo tyl­ko takie są two­rzo­ne na eta­pie ana­li­zy biz­ne­so­wej. Modele te są ele­men­tem CIM (What is Computation Independent Model) .

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

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 (fir­ma, urząd, itp. to uczest­ni­cy pro­ce­su), oraz tory (lane, wydzie­lo­ne par­ty­cje wewnątrz puli), repre­zen­tu­ją­ce komór­ki orga­ni­za­cyj­ne, sta­no­wi­ska, role (zależ­nie od przy­ję­tej przez auto­ra mode­li kon­wen­cji). Torów uży­wa­my wyłącz­nie do orga­ni­za­cji i kate­go­ry­za­cji aktywności.

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, repre­zen­tu­ją pole­ce­nie w języ­ku BPEL).

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 w repo­zy­to­rium. 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 i łączniki

Connecting Objects

Łączniki (związ­ki) łą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) i prze­pły­wy komu­ni­ka­tów (Message flow), któ­re wyra­ża­ją następ­stwo, oraz powią­za­nia poję­cio­we (Association) i powią­za­nia danych (Data Association).

Dokument (Data Object) i Repozytorium (Data Stor)

Data

Dokumenty (struk­tu­ral­ne 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. Istnieją czte­ry rodza­je tych sym­bo­li: Obiekty danych (Data Object) repre­zen­tu­ją doku­men­ty, dane wej­ścio­we (Data Input), dane wyj­ścio­we (Data Output) oraz repo­zy­to­ria, maga­zy­ny danych/dokumentów (Data Stor). W mode­lach ana­li­tycz­nych sto­su­je­my wyłącz­nie Data Object. Struktury doku­men­tów (treść, sza­blon for­mu­la­rza) mode­lo­wa­ne są odręb­nie z uży­ciem np. nota­cji UML (dia­gram struk­tur zło­żo­nych) . Elementów Data Stor moż­na uży­wać w mode­lach ana­li­tycz­nych by poka­zać, że okre­ślo­ne tre­ści nie sta­no­wią odręb­nych doku­men­tów, a zapi­sy w reje­strach (wier­sze tabel, Data Stor repre­zen­tu­je wte­dy głów­kę takiej tabeli).

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 (orga­ni­za­cja) pro­ce­su biz­ne­so­we­go (pool). Mogą one zawie­rać obiek­ty prze­pły­wu, któ­re są wyko­ny­wa­ne przez rolę lub komór­kę orga­ni­za­cyj­ną (lane). Wyjątkiem jest pula, tak zwa­na czar­na skrzyn­ka” (opi­sa­na w dal­szej czę­ści tego opi­su). Na typo­wym dia­gra­mie BPMN, pro­ces prze­pły­wa od lewej do pra­wej (ale ryso­wa­nie z góry na dół jest dopuszczalne).

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­ną skrzyn­kę. Klient (Customer) jest tu taką 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 zain­te­re­so­wa­nia. 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, par­ty­cje), 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 zada­nia repre­zen­tu­ją 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 (dia­gram) 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
Aktywności z ozna­cze­niem Podprocesu

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 (fakt) i może to 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 (i tyl­ko wte­dy). 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, z zasa­dy prze­chwy­ty­wa­ne), zda­rze­nie pośred­nie (prze­chwy­ty­wa­ne lub gene­ro­wa­ne) i zda­rze­nie koń­czą­ce (z zasa­dy generowane). 

Każdy pro­ces powi­nien posia­dać zda­rze­nie ini­cju­ją­ce go, któ­re poka­zu­je począ­tek (przy­czy­nę ini­cja­cji) 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 (fak­tu) 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 dla­te­go bywa nazy­wa­ne kra­wę­dzio­we”) w celu zamo­de­lo­wa­nia fak­tu, któ­ry może wystą­pić W TRAKCIE reali­zo­wa­nia tej aktyw­no­ści i prze­rwać reali­za­cję Zadania, 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 w momen­cie gdy otrzy­mu­je­my zamó­wie­nie (order arri­ved), zaczy­na­my je prze­twa­rzać (Process Order). Jeśli i tyl­ko wte­dy, gdy prze­kro­czo­ny jest limit kre­dy­to­wy (no cre­dit limit) prze­ry­wa­my pra­ce nad dal­szym prze­twa­rza­niem zamó­wie­nia i spraw­dza­my ten pro­blem (Check Problem) (aktyw­ność Process Order nie zosta­nie wyko­na­na do koń­ca). 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 danych 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, UWAGA! bram­ki danych to warun­ki budo­wa­ne na bazie tre­ści doku­men­tów DataObject!).

Bramka rów­no­le­gła (w ory­gi­na­le «fork», roz­wi­dle­nie) 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 nie są dane (tre­ści zawar­te w Data Object) 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 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 róż­ny­mi orga­ni­za­cja­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ą, w ramach reali­zo­wa­nia aktyw­no­ści 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)

Powyższa kon­struk­cja jest popraw­na for­mal­nie: gór­ny tor – ostat­nim fak­tem jest wysła­ny komu­ni­kat, co w tym przy­pad­ku (jest to ostat­nie zada­nie) jest toż­sa­me ze zda­rze­niem koń­czą­cym pro­ces, komu­ni­kat ten w dru­giej puli jest pierw­szym fak­tem, któ­ry ini­cju­je pro­ces i jest to toż­sa­me z wystą­pie­niem zda­rze­nia inicjującego. 

Z uwa­gi na ryzy­ko błęd­nej inter­pre­ta­cji takich kon­struk­cji, zale­ca się jed­nak sto­so­wa­nie każ­do­ra­zo­wo zda­rzeń ini­cju­ją­cych i koń­czą­cych pro­ces w każ­dej puli (wyma­ga tego więk­szość ser­we­rów BPMS). Podobna kon­struk­cja jest poni­żej w czę­ści BPMN – Przykład. 

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 dodat­ko­we szcze­gó­ły doty­czą­ce wybra­nych ele­men­tów modeli.

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 (patrz komen­tarz powy­żej w rozdz. Grupy).

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.

Kluczowe cechy poprawności analitycznych modeli procesów biznesowych

Definicje w BPMN (doda­tek C spec. BPMN):

Proces Biznesowy: zde­fi­nio­wa­ny zestaw aktyw­no­ści, któ­re repre­zen­tu­ją kro­ki wyma­ga­ne do osią­gnię­cia celu biz­ne­so­we­go.
Atomowa aktyw­ność: dzia­ła­nie, któ­re nie zosta­ło podzie­lo­ne na bar­dziej szcze­gó­ło­wy poziom Modelu Procesu. Jest to liść w
drze­wia­stej hie­rar­chii aktyw­no­ści Procesu. Graficznie poja­wi się jako Zadanie
w BPMN.

Modele ana­li­tycz­ne to mode­le opi­su­ją­ce prze­pływ pra­cy i tre­ści a poziom szcze­gó­ło­wo­ści wyzna­cza pod­ręcz­ni­ko­wa defi­ni­cja pro­ce­su biz­ne­so­we­go brzmią­ca: aktyw­ność mają­ce wej­ście i wyj­ście (two­rzą­ca pro­dukt), anga­żu­ją­ca okre­ślo­ne zaso­by. Dlatego popraw­ny model ana­li­tycz­ny to dia­gram, na którym: 

  • każ­da aktyw­ność ma wska­za­ny jej pro­dukt (data object),
  • każ­da aktyw­ność repre­zen­tu­je okre­ślo­na pro­ce­du­rą lub zde­fi­nio­wa­ną kompetencję,
  • każ­dy data object” repre­zen­tu­je nazwa­ny typ (sza­blon) dokumentu.

Tak więc poza dia­gra­ma­mi BPMN doku­men­ta­cja taka powin­na zawie­rać załącz­ni­ki: pro­ce­du­ry, nazwy sta­no­wisk, sza­blo­ny doku­men­tów. Na dia­gra­mach nie powin­no być tak zwa­ny śmie­cio­wych czyn­no­ści” czy­li takich, dla któ­rych nie wska­za­no ich pro­duk­tu (data object). 

Dlatego popraw­ne mode­le ana­li­tycz­ne 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 ani logi­ki biz­ne­so­wej (to doku­men­tu­je­my jako regu­ły biz­ne­so­we). Dlatego mode­le BPMN muszą być uzu­peł­nia­ne opi­sa­mi pro­ce­dur (np. tabe­le, listy wypunk­to­wa­ne, pro­ste sche­ma­ty blo­ko­we) 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.
Od góry: pro­ces biz­ne­so­wy jako łań­cuch ele­men­tar­nych pro­ce­sów biz­ne­so­wych, jeden ele­men­tar­ny pro­ces biz­ne­so­wy (zada­nie, jego wej­ście i wyj­ście), pro­ce­du­ra opi­su­ją­ca reali­za­cję jed­ne­go (ato­mo­we­go) zada­nia. Wejściem i wyj­ściem każ­de­go ato­mo­we­go pro­ce­su jest zawsze doku­ment (jego treść jest mode­lo­wa­na osob­no) (ź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)

Dodatek: typowe i często popełniane błędy

Powyższa treść doty­czy inte­pre­to­wa­nia dia­gra­mów. Okazuje się jed­nak, że ten opis zyskał sobie dużą popu­lar­ność, bo czy­ta­nie doku­men­tów (w tym oce­na popraw­no­ści dia­gra­mów) to tak­że ele­ment ich odbio­ru, gdy opra­co­wa­nie doku­men­ta­cji pro­ce­sów było płat­ną usłu­gą. Poniżej więc dodat­ko­wo uwa­gi doty­czą­ce tego, cze­go tam być nie powinno… 

Modelowanie rzeczy oczywistych oraz niebędących procesem biznesowym czyli śmieciowe elementy na diagramach

Proces biz­ne­so­wy to aktyw­ność, lub ich łań­cuch, cechu­ją­ca się samo­dziel­no­ścią, okre­ślo­nym celem (jej produktem). 

Aktywności wcho­dzą­ce w skład pro­ce­su i zwa­ne ato­mo­wy­mi (zada­nia), two­rzą ato­mo­we pro­ce­sy biz­ne­so­wy, czy­li ele­men­tar­ne pary: nazwa­na pra­ca i jej efekt”: 

Atomic Activity: An acti­vi­ty not bro­ken down to a finer level of Process Model deta­il. It is a leaf in
the tree-struc­tu­re hie­rar­chy of Process acti­vi­ties. Graphically it will appe­ar as a Task in BPMN.
Business Process: A defi­ned set of busi­ness acti­vi­ties that repre­sent the steps requ­ired to achie­ve a
busi­ness objec­ti­ve. It inc­lu­des the flow and use of infor­ma­tion and resources.

(źr.: spe­cy­fi­ka­cja BPMN, Annex C, Glossary)

Atomowa aktyw­ność: Działanie, któ­re nie zosta­ło podzie­lo­ne na kolej­ne niż­sze pozio­my szcze­gó­ło­wo­ści mode­lu pro­ce­su. Jest to tak zwa­ny liść w drze­wia­stej hie­rar­chii aktyw­no­ści Procesu. Graficznie w BPMN będzie mode­lo­wa­ne jako Zadanie.
Proces biz­ne­so­wy: Zdefiniowany zestaw aktyw­no­ści biz­ne­so­wych, któ­re repre­zen­tu­ją kro­ki wyma­ga­ne do osią­gnię­cia celu biz­ne­so­we­go. Obejmuje on prze­pływ i wyko­rzy­sta­nie infor­ma­cji oraz zasobów.

BPMN: aktyw­no­ści czy­li zada­nie vs. pod-proces

Tak więc pro­ces biz­ne­so­wy (mode­lo­wa­ny w nota­cji BPMN) to aktyw­ność i jej okre­ślo­ny pro­dukt (Task->DataObject), lub ich łań­cuch, na jed­nym dia­gra­mie. Atomowa aktyw­ność w BPMN to Zadanie (Task).

Nie umiesz­cza­my więc na mode­lach ana­li­tycz­nych zadań któ­re nie two­rzą samo­dziel­nych pro­duk­tów, takich jak: prze­ka­za­nie doku­men­tu prze­ło­żo­ne­mu” czy zapo­zna­nie się z tre­ścią doku­men­tu”, tak­że dla­te­go, że są to rze­czy oczy­wi­ste, wyni­ka­ją­ce ze strza­łek i torów w base­nach na dia­gra­mach BPMN lub z same­go kon­tek­stu (akcep­ta­cja doku­men­tu z zasa­dy wyma­ga zapo­zna­nia się z nim). 

Nie rysu­je­my na mode­lu BPMN spo­so­bu wypeł­nia­nia for­mu­la­rza, np. wsta­wia­nie nume­ru NIP do fak­tu­ry”, wyli­cze­nie war­to­ści w polu upust”, bo to doku­men­tu­je­my osob­no jako sza­blon doku­men­tu np. Faktura i regu­ły jego popraw­ne­go wytworzenia.

Nie umiesz­cza­my na mode­lach pro­ce­sów biz­ne­so­wych ele­men­tów instruk­cji obsłu­gi sprzę­tu i opro­gra­mo­wa­nia, instruk­cji sta­no­wi­sko­wych i pro­ce­dur, np. zapi­sa­nie doku­men­tu jako pli­ku na dys­ku sie­cio­wym D:/”, wyeks­por­to­wa­nie tabe­li do for­ma­tu Excel”, wysła­nie umo­wy z uży­ciem ema­il do adre­sa­ta”, bo są to deta­le spe­cy­ficz­ne dla wdro­żo­nej meto­dy pra­cy, a nie dla pro­ce­su jako takie­go. Przywołujemy je tu (koja­rzy­my z Zadaniami na dia­gra­mie) jako osob­ne instruk­cje obsłu­gi opro­gra­mo­wa­nia, pro­ce­du­ry, instruk­cje sta­no­wi­sko­we itp.. Nieprzestrzeganie tych zasad szyb­ko pro­wa­dzi to zja­wi­ska zwa­ne­go spa­ghet­ti-mode­ling opi­sa­nej dalej. 

Używanie elementów specyficznych dla modeli wykonywalnych na modelach analitycznych

Notacja BPMN powsta­ła pier­wot­nie jako narzę­dzie do gene­ro­wa­nia skryp­tów BPEL4WS (Business Process Execution Language for Web-Services) wyko­ny­wa­nych na w śro­do­wi­sku BPMS (Business Process Management Systems). Dlatego pier­wot­na spe­cy­fi­ka­cja zawie­ra nie tyl­ko ele­men­ty ogól­ne (task, acti­vi­ti) ale też przede wszyst­kim ich spe­cja­li­za­cje ozna­czo­ne spe­cjal­ny­mi iko­na­mi, któ­re repre­zen­tu­ją okre­ślo­ne kon­struk­cje języ­ka BPEL. 

Po kil­ku latach uży­wa­nia nota­cji BPMN, prak­ty­cy zwró­ci­li uwa­gę na to, że zna­ko­mi­ta więk­szość powsta­ją­cych mode­li pro­ce­sów biz­ne­so­wych nie słu­ży do gene­ro­wa­nia skryp­tów BPEL, a jedy­nie do ana­li­zy biz­ne­so­wej, czy­li do two­rze­nia mode­li pro­ce­sów na wyż­szym pozio­mie abs­trak­cji (patrz wyżej: ato­mo­wa aktyw­ność – zada­nie), któ­re dodat­ko­wo muszą być zro­zu­mia­łe dla osób z tak zwa­ne­go biz­ne­su, bo to one są ich adre­sa­tem (a nie ser­we­ry BPMS/BPEL). Dlatego ostat­nie wyda­nie spe­cy­fi­ka­cji BPMN zawie­ra roz­dział 2.2.1. w któ­rym zwró­co­no na to uwa­gę. Generalnie wnio­sek jest pro­sty: nie uży­wa­my na mode­lach ana­li­tycz­nych sym­bo­li zadań z mały­mi iko­na­mi w rogu, bo one słu­żą do mode­lo­wa­nia deta­licz­nych linii pole­ceń skryp­tów BPEL. Używanie ich na mode­lach ana­li­tycz­nych wpro­wa­dza tyl­ko zamęt u ich adre­sa­tów (zamiast nauczyć się kil­ku pro­stych, pod­sta­wo­wych sym­bo­li nota­cji BPMN, muszą nauczyć się popraw­nie inter­pre­to­wać kil­ka­dzie­siąt ikon). Szczególnie poważ­nym błę­dem jest uzna­nio­we uma­wia­nie się” na to co ozna­cza­ją te ikonki. 

Obrazek posiada pusty atrybut alt; plik o nazwie image-15.pngObrazek posiada pusty atrybut alt; plik o nazwie image-16.png
Przykłady sym­bo­li BPMN dedy­ko­wa­nych dla mode­li wykonywalnych

Na mode­lach ana­li­tycz­nych, seman­tycz­nie mają sens i nie raz muszą być jed­nak uży­te (ini­cja­cja pro­ce­su lub bram­ka zda­rze­nio­wa) wybra­ne zda­rze­nia (wyzwa­la­cze): timer (ozna­cza moment w cza­sie a nie upływ cza­su!), speł­nie­nie okre­ślo­ne­go warun­ku (np. pro­ces uzu­peł­nie­nia sta­nu maga­zy­nu jest ini­cjo­wa­ny stwier­dze­niem fak­tu spad­ku ilo­ści towa­ru poni­żej 10 sztuk), stwier­dze­nie otrzy­ma­nia lub wyge­ne­ro­wa­nia komu­ni­ka­tu (ale na mode­lach wyko­ny­wal­nych są to ozna­czo­ne koper­tą aktyw­no­ści a nie wyzwalacze).

Pętle

To temat wie­lu kon­tro­wer­sji, dla­te­go opi­szę pro­blem i wyja­śnię dla­cze­go nie two­rzy­my pętli na mode­lach analitycznych. 

  1. Notacja BPMN wyma­ga zade­kla­ro­wa­nia czy model jest mode­lem ana­li­tycz­nym czy wyko­ny­wal­nym, są to odręb­ne mode­le (rozdz. 2.2.1. spec BPMN).
  2. W ana­li­zach biz­ne­so­wych two­rzy­my mode­le CIM (Computation Independent Model), któ­re cał­ko­wi­cie abs­tra­hu­ją od uży­tych technologii.
  3. Organizacja to nie kom­pu­ter więc pro­ces biz­ne­so­wy (jego model) to nie algo­rytm (algo­ryt­my to mode­le wyko­ny­wal­ne dla maszyn BPMS, patrz poprzed­ni rozdział).
  4. Aktywność (task) na ana­li­tycz­nym mode­lu pro­ce­su to nazwa procedury. 
  5. Proces biz­ne­so­wy to kolej­no reali­zo­wa­ne aktyw­no­ści, ich ścież­ki mogą się roz­wi­dlać i łączyć, ale nie cofa­ją nas w cza­sie wstecz.
  6. Jeżeli pro­ces jest reali­zo­wa­ny cyklicz­nie to powo­dem kolej­ne­go jego wyko­na­nia, jest ponow­ne wystą­pie­nie ini­cju­ją­ce­go go zda­rze­nia, a nie to co sie wyda­rzy­ło na koń­cu tego procesu.
  7. Jeżeli jakaś czyn­ność jest wyko­ny­wa­ny cyklicz­nie (np. napeł­nia­nie wia­der­ka pia­skiem z uży­ciem łyżecz­ki do her­ba­ty) to jest opis pro­ce­du­ry reali­za­cji tego zada­nia (napeł­nie­nie wia­der­ka) a nie cyklicz­nie wyko­ny­wa­ne w pętli zadanie.

Dlatego na mode­lach pro­ce­sów biz­ne­so­wych poka­zu­je­my dzia­ła­nie orga­ni­za­cji i nie rysu­je­my pętli. Jeżeli ktoś musi kil­ka­na­ście razy opra­co­wać ofer­tę, to nie dla­te­go, że skoń­czył poprzed­nią, a dla­te­go, że nadal cze­ka jakieś Zapytanie ofer­to­we” o sta­tu­sie [nowe]. Bo pro­ces opra­co­wa­nia ofer­ty jest ini­cjo­wa­ny zapy­ta­niem, a nie wysła­niem poprzed­niej ofer­ty. Nie ma tu żad­nej pętli. Są powta­rza­ją­ce się zda­rze­nia ini­cju­ją­ce ten sam proces. 

Używanie zdarzeń, bramek i obiektów danych jako aktywności

Powszechnym błę­dem na dia­gra­mach jest wyra­ża­nie pra­cy sym­bo­la­mi, któ­re tej pra­cy, w nota­cji BPMN, nie repre­zen­tu­ją. W nota­cji BPMN tyl­ko jeden sym­bol repre­zen­tu­je reali­zo­wa­ną pra­cę: jest to aktywność. 

Pozostałe sym­bo­le sta­no­wią sobą wyłącz­nie stwier­dze­nie fak­tu, że do cze­goś doszło, a fak­ty nie trwa­ją w cza­sie i nie są w BPMN seman­tycz­nie łączo­ne z rolą lub komór­ką orga­ni­za­cyj­ną (tory):

Lanes are used to orga­ni­ze and cate­go­ri­ze Activities.

(źr.: BPMN v.2.0.2. str. 27: Table 7.1 ? Basic Modeling Elements)

Tak więc zda­rze­nia repre­zen­tu­ją wyzwa­la­cze, po nich (zda­rze­nie prze­chwy­ty­wa­ne) lub przed nimi (zda­rze­nie gene­ro­wa­ne) MUSI poja­wić się aktyw­ność, bo wyzwa­lacz nie jest pra­cą (aktyw­no­ścią).

Przykłady kon­struk­cji na diagramach

Umieszczenie zda­rze­nia w torze nie zna­czy, że coś się zda­rzy­ło w miej­scu repre­zen­to­wa­nym przez ten tor, na zda­rze­nie MUSI ktoś dopie­ro zare­ago­wać i to jest dopie­ro wyko­na­na pra­ca (aktyw­ność). Miejsce: tor, umiesz­cze­nia sym­bo­li nie będą­cych aktyw­no­ścią, nie ma zna­cze­nia na mode­lach BPMN, umiesz­cza­my je (zale­ce­nie) kon­tek­sto­wo, łącz­nie z aktyw­no­ścia­mi któ­rych doty­czą, dla łatwo­ści per­cep­cji modeli. 

Więc na dia­gra­mie po lewej stro­nie (powy­żej): nie jest praw­dą, że Rola 1 zare­ago­wa­ła i zro­bi­ła cokol­wiek, i nie jest praw­dą że Rola 1 dosta­ła doku­ment wytwo­rzo­ny przez Rolę 2 i go np. prze­czy­ta­ła. Zależnie od tego jaki jest stan fak­tycz­ny, popraw­ne są dia­gra­my środ­ko­wy i po prawej. 

Utrata panowania nad złożonością

To mię­dzy inny­mi kon­se­kwen­cja, opi­sa­ne­go powy­żej, sto­so­wa­nia śmie­cio­wych ele­men­tów na dia­gra­mach. To tak­że jed­na z naj­częst­szych wad wie­lu dia­gra­mów (nie tyl­ko BPMN, np. UML tak­że). W lite­ra­tu­rze przed­mio­tu pro­blem ten jest czę­sto okre­śla­ny jako spa­ghet­ti mode­ling” czy­li nie­czy­tel­ne, zagma­twa­ne modele. 

Jednym z pod­sta­wo­wych zale­ceń, doty­czą­cych od dekad zarzą­dza­nia zło­żo­no­ścią sche­ma­tów blo­ko­wych, jest zasa­da mówią­ca, że:

jeże­li dia­gram jest nie­czy­tel­ny po wydru­ko­wa­niu na papie­rze for­ma­tu A4, jest to z zasa­dy źle wyko­na­ny diagram.

Poniżej zano­ni­mi­zo­wa­ne przy­kła­dy z audy­to­wa­nych dokumentów:

Przykład 1 prze­cią­żo­ne­go dia­gra­mu pro­ce­su biz­ne­so­we­go (źr.: frag­ment audy­to­wa­nej dokumentacji)
Przykład 2 prze­cią­żo­ne­go dia­gra­mu pro­ce­su biz­ne­so­we­go (źr.: frag­ment audy­to­wa­nej dokumentacji)

Jak widać są prak­tycz­nie nie­czy­tel­ne więc tak­że nie­przy­dat­ne, więc po co powstały?

Panowanie nad zło­żo­no­ścią mode­li (sche­ma­tów blo­ko­wych) ma dwa aspek­ty: uży­wa­nie wła­ści­wej for­my wyra­zu (nota­cja) oraz wła­ści­we­go pozio­mu abs­trak­cji, dobra­ne­go do wyar­ty­ku­ło­wa­nia okre­ślo­ne­go pro­ble­mu. Właściwa for­ma wyra­zu to np. decy­zja co wyra­zi­my nota­cją BPMN (pro­ces biz­ne­so­wy), co nota­cją UML (np. sza­blon tre­ści doku­men­tu), co tek­stem jako pro­ce­du­rę i co, tak­że tek­stem, jako regu­ły biz­ne­so­we. Mogą się poja­wić macie­rze RACI i itp. Poziom abs­trak­cji to wła­ści­wy dobór deta­li i ich licz­by, do kon­tek­stu dane­go dia­gra­mu i celu jego utwo­rze­nia: każ­dy dia­gram powi­nien mieć jeden cel i jeden kontekst.

Co do zasa­dy adre­sa­tem każ­de­go doku­men­tu jest czło­wiek z jego indy­wi­du­al­ną umie­jęt­no­ścią inter­pre­ta­cji (per­cep­cji) tego co czy­ta. Dokumenty te udo­stęp­nia­ne są im na ekra­nie kom­pu­te­ra lub na wydru­ku. Zapominanie o tym, jest poważ­nym błę­dem wie­lu ich autorów… 

Mieszanie kontekstu biznesowego i aplikacyjnego

Na koniec kolej­ny czę­sto popeł­nia­ny błąd na mode­lach BPMN: mie­sza­nie kon­tek­stów biz­ne­su i tech­no­lo­gii. Organizacja trzy­ma­ją­ca pie­czę nad nota­cją BPMN i stan­da­ry­zu­ją­ca tak­że inne (np. UML) czy­li OMG, opu­bli­ko­wa­ła zale­ce­nia Model Driven Architecture (MDA), czy­ta­my w nich:

Model Driven Architecture? (MDA?) is an appro­ach to softwa­re design, deve­lop­ment and imple­men­ta­tion spe­ar­he­aded by the OMG. MDA pro­vi­des guide­li­nes for struc­tu­ring softwa­re spe­ci­fi­ca­tions that are expres­sed as models. MDA sepa­ra­tes busi­ness and appli­ca­tion logic from under­ly­ing plat­form technology.

(Model Driven Architecture? (MDA?) jest podej­ściem do pro­jek­to­wa­nia, two­rze­nia i wdra­ża­nia opro­gra­mo­wa­nia, zaini­cjo­wa­nym przez OMG. MDA zawie­ra wytycz­ne doty­czą­ce struk­tu­ry­za­cji spe­cy­fi­ka­cji opro­gra­mo­wa­nia, któ­re są wyra­ża­ne jako mode­le. MDA oddzie­la logi­kę biz­ne­so­wą i apli­ka­cyj­ną od pod­sta­wo­wej tech­no­lo­gii platformy.)

Kluczem jest ostat­nie zda­nie: nie mie­sza­my logi­ki biz­ne­so­wej z fak­tem posia­da­nia i uży­wa­nia opro­gra­mo­wa­nia (sys­te­mów IT), bo te są jedy­nie narzę­dziem a nie sen­sem biz­ne­su. Dlatego z zasa­dy two­rzy­my dwa oddziel­ne mode­le dla orga­ni­za­cji: Computation Independent Model (CIM), czy­li model biz­ne­so­wy, nie­za­leż­ny od posia­da­nych sys­te­mów infor­ma­tycz­nych oraz te sys­te­my (pla­no­wa­ne lub posia­da­ne) jako Platform Independent Model (PIM) czy­li model logi­ki dzia­ła­nia sys­te­mów IT (opro­gra­mo­wa­nia) nie­za­leż­ny od uży­tych tech­no­lo­gii. Innymi sło­wy model biz­ne­so­wy orga­ni­za­cji i model wyko­rzy­sta­ne­go opro­gra­mo­wa­nia, to odręb­ne mode­le. Na mode­lach CIM nie umiesz­cza­my żad­nych wzmia­nek o opro­gra­mo­wa­niu (gene­ral­nie o narzę­dziach uży­tych w pro­ce­sach) . To, że jakimś momen­cie uży­wa­my jakie­goś opro­gra­mo­wa­nia jest tre­ścią instruk­cji sta­no­wi­sko­wej lub pro­ce­du­ry, ale 

umiesz­cza­nie toru sys­tem ERP” na mode­lu pro­ce­sów biz­ne­so­wych BPMN jest łama­niem pod­sta­wo­wej zasa­dy MDA: model pro­ce­sów biz­ne­so­wych abs­tra­hu­je od uży­tych narzędzi.

Więc jak i gdzie udo­ku­men­to­wać to, że coś robi­my z uży­ciem opro­gra­mo­wa­nia? Do tego słu­ży tak zwa­ne śla­do­wa­nie, czy­li koja­rze­nie aktyw­no­ści na mode­lach pro­ce­sów biz­ne­so­wych z przy­pad­ka­mi uży­cia (wię­cej w arty­ku­le: Transformacja mode­lu pro­ce­sów biz­ne­so­wych na model przy­pad­ków uży­cia) lub kom­po­nen­ta­mi na mode­lach UML. Stosowane są tak­że kon­wen­cje by nazwy aktyw­no­ści na mode­lach BPMN dodat­ko­wo uzu­peł­niać nazwa­mi przy­pad­ków uży­cia lub kom­po­nen­tów sys­te­mów IT: np. aktyw­ność Wystawienie fak­tu­ry [moduł FK ERP]”

Czy elementy na diagramach mogą się powtarzać

Tak. Nie ma w spe­cy­fi­ka­cji BPMN regu­ły mówią­cej, że jaki­kol­wiek ele­ment nie może się powtó­rzyć na jed­nym dia­gra­mie. Poniżej typo­wa sytu­acja: powta­rza się aktyw­ność Archiwizacja oraz doku­men­ty Zamówienie i Faktura: 

Teza, że jeden ele­ment moż­na tyl­ko raz nary­so­wać” na jed­nym dia­gra­mie nie znaj­du­je potwier­dze­nia w spe­cy­fi­ka­cji BPMN, a jak widać powy­żej, są to czę­ste sytuacje. 


Szkolenia

Przeczytałeś? Więc po co Ci szko­le­nie? Bo tu dowie­dzia­łeś naj­waż­niej­szych rze­czy by zro­zu­mieć te mode­le, a na szko­le­niu poznasz przy­czy­ny tego dla­cze­go tak a nie ina­czej i będziesz mógł w dowol­nym momen­cie o wszyst­ko zapytać.

Osoby zain­te­re­so­wa­ne posze­rze­niem wie­dzy i naby­ciem prak­ty­ki doty­czą­cej ana­li­zy i mode­lo­wa­nia pro­ce­sów biz­ne­so­wych zapra­szam na stro­nę Szkolenia.

Literatura

Danenas, P., Skersys, T., & Butleris, R. (2019). Enhancing the extrac­tion of SBVR busi­ness voca­bu­la­ries and busi­ness rules from UML use case dia­grams with natu­ral lan­gu­age pro­ces­sing. Proceedings of the 23rd Pan-Hellenic Conference on Informatics – PCI 19, 1 – 8. https://​doi​.org/​1​0​.​1​1​4​5​/​3​3​6​8​6​4​0​.​3​3​6​8​641
Danesi, M. (2004). Messages, signs, and meaning: a basic text­bo­ok in semio­tics and com­mu­ni­ca­tion the­ory (3rd edi­tion). Canadian Scholars’ Press Inc.
Eco, U. (1979). A the­ory of semio­tics.
Miller, J., & Mukerji, J. (2003). MDA Guide Version 1.0.1. 62.
Object Management Group. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Object Management Group. (2014, January). Business Process Model and Notation (BPMN). OMG​.Org. https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
Object Management Group. (2014, June 18). Model Driven Architecture (MDA). OMG​.Org. https://​www​.omg​.org/​m​da/
Object Management Group. (2014). Model Driven Architecture (MDA) MDA Guide rev. 2.0. Object Management Group. https://​www​.omg​.org/​c​g​i​-​b​i​n​/​d​o​c​?​o​r​m​s​c​/14 – 06-01.pdf
Object Management Group. (2019). Semantics of Business Vocabulary and Business Rules (SBVR). OMG​.Org. https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Skersys, T., Tutkute, L., Butleris, R., & Butkiene, R. (2012). Extending BPMN busi­ness pro­cess model with SBVR busi­ness voca­bu­la­ry and rules. Information Technology and Control, 41(4), 356 – 367.
Suriadi, S., Wynn, M., Ouyang, C., Ter, A., & Dijk, N. (2013). Understanding Process Behaviours in a Large Insurance Company in Australia: A Case Study. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑642 – 38709-8_29
Tax, N., Sidorova, N., Haakma, R., & Aalst, W. (2018). Event Abstraction for Process Mining Using Supervised Learning Techniques.
Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78 – 89). IGI Global. https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699

Dodaj komentarz

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