Wstęp

Powodem napi­sa­nia tego arty­ku­łu była publikacja:

„Wdrożenie zin­te­gro­wa­nych elek­tro­nicz­nych usług, infor­ma­cyj­nych na przy­kła­dzie porad­ni­ków przed­się­bior­cy, udo­stęp­nia­nych poprzez Punkt Kontaktowy w Polsce” .

Autorzy Mgr Szymon Mamrot, dok­to­rant na Wydziale Informatyki i Gospodarki Elektronicznej Uniwersytetu Ekonomicznego w Poznaniu, głów­ny spe­cja­li­sta w Centrum Elektronicznej Gospodarki Instytutu Logistyki i Magazynowania (e‑mail: szymon.mamrot@ilim.poznan.pl). Mgr Magdalena Stachowicz, absol­went­ka stu­diów dok­to­ranc­kich na Wydziale Politologii Uniwersytetu Marii Curie-Skłodowskiej w Lublinie, star­szy spe­cja­li­sta w Centrum Elektronicznej Gospodarki Instytutu Logistyki i Magazynowania (e‑mail: magdalena.stachowicz@ilim.poznan.pl). Artykuł był recenzowany.

Autorzy cytu­ją mię­dzy inny­mi mój arty­kuł, a kon­kret­nie defi­ni­cję pro­ce­su biz­ne­so­we­go, piszą tak­że o mode­lo­wa­niu pro­ce­sów i o nota­cji BPMN. Autorzy piszą:

W arty­ku­le auto­rzy pod­ję­li pró­bę zgłę­bie­nia pro­ble­mu badaw­cze­go, jakim jest zasto­so­wa­nie nota­cji Business Process Modeling Notation ( BPMN) do two­rze­nia z inte­gro­wa­nych elek­tro­nicz­nych usług infor­ma­cyj­nych. Posługując się przy­kła­dem porad­ni­ków przed­się­bior­cy, udo­stęp­nia­nych na por­ta­lu Punktu Kontaktowego (PK), udo­wod­ni­li, że nota­cja BPMN pozwa­la budo­wać skom­pli­ko­wa­ne mode­le pro­ce­sów, uwzględ­nia­ją­cych wie­le powią­za­nych ze sobą zadań i infor­ma­cji. Tworzenie zin­te­gro­wa­nych elek­tro­nicz­nych usług infor­ma­cyj­nych, cie­ka­wych w for­mie i obszer­nych w pomoc­ne tre­ści mery­to­rycz­ne, jest przy­szło­ścią współ­cze­snej e‑administracji, nie tyl­ko w Polsce, ale i w Europie.

Jednak w tre­ści, jest nie­praw­dzi­wa teza:

Nie ma w tym przy­pad­ku ogra­ni­cze­nia, że pro­ces musi coś wytwarzać.

Wyjaśnijmy sobie dla­cze­go nie­praw­dzi­wa. Przytoczę na wstę­pie frag­ment wcze­śniej­szej publikacji:

Niekończące się dys­ku­sje o licz­bie pozio­mów dekom­po­zy­cji pro­ce­sów, ich zmien­no­ści, adap­ta­cyj­no­ści itp. zale­wa­ją fora inter­ne­to­we. Wydaje mi się, że nie­po­trzeb­nie – o ile wysi­li­my się na pew­ną małą analizę…

Proces to stra­te­gia nie tak­ty­ka – Jarosław Żeliński IT-Consulting

Streszczenie

Jako, że zosta­łem zacy­to­wa­ny przez ww. auto­rów, arty­kuł ten sta­no­wi moją odpo­wiedź do tej publi­ka­cji. Autorzy pod­wa­ży­li defi­ni­cję, mówią­cą, że pro­ces biz­ne­so­wy two­rzy pro­dukt. Skupiłem się tu na for­mal­nym wywo­dzie pro­wa­dzą­cym do defi­ni­cji pojęć: pro­ces, pro­ces biz­ne­so­wy i pro­ce­du­ra, na tle nota­cji BPMN, na któ­rą auto­rzy się powo­łu­ją. Wykazałem, że poję­cie pro­duk­tu pro­ce­su jest fun­da­men­tem defi­ni­cji poję­cia pro­ces biz­ne­so­wy nie tyl­ko w nota­cji BPMN. Wskazałem tak­że błęd­ne uży­cie przez auto­rów powią­za­ne­go z poję­ciem pro­ces poję­cia bram­ki (ang. gateway).

Wskazałem też, że doj­rza­ła (pro­ce­so­wo) może być orga­ni­za­cja. Żadnej fir­my, jako cało­ści, nie da się opi­sać algo­ryt­mem, dla­te­go opi­su­je­my ja na trzech pozio­mach:
1. pro­ce­sy (kolej­ność prac),
2. pro­ce­du­ry (jak te pra­ce wyko­ny­wać),
3 zaso­by (co i kogo zaangażować).

Na koń­cu doda­tek poka­zu­ją­cy jak to robić z uży­ciem Visual Paradigm.

Procedura, proces i proces biznesowy

Autorzy piszą:

Według defi­ni­cji języ­ko­wej, zawar­tej w Słowniku Języka Polskiego PWN, pro­ce­du­ra to: 1. okre­ślo­ne regu­ły postę­po­wa­nia w jakiejś spra­wie, zwy­kle o cha­rak­te­rze urzę­do­wym lub praw­nym; 2. w języ­kach pro­gra­mo­wa­nia: wydzie­lo­ny frag­ment algorytmu.

W arty­ku­le auto­rzy posłu­gu­ją się pierw­szym zna­cze­niem uży­tym w Słowniku (pro­ce­du­ra jako okre­ślo­ne regu­ły postę­po­wa­nia), przy czym istot­na jest lista czyn­no­ści i sama kolej­ność ich wykonania.

Przyjmowanie naj­ogól­niej­szych defi­ni­cji jest ryzy­kow­ne, tym bar­dziej, że celem publi­ka­cji było

…przed­sta­wie­nie nowej meto­dy two­rze­nia zin­te­gro­wa­nych elek­tro­nicz­nych usług infor­ma­cyj­nych, przy zasto­so­wa­niu nota­cji BPMN.

Zastosowanie sfor­ma­li­zo­wa­nej nota­cji, jaką jest BPMN, i jed­no­cze­sne ujmo­wa­nie poję­cia pro­ce­su naj­ogól­niej jak się da i w ode­rwa­niu od tej nota­cji, jest ryzy­kow­ne. Już tu: ​„pro­ce­du­ra jako okre­ślo­ne regu­ły postę­po­wa­nia, przy czym istot­na jest lista czyn­no­ści i sama kolej­ność ich wyko­na­nia” widać, że ogól­na defi­ni­cja zosta­ła uzu­peł­nio­na o istot­ność listy czyn­no­ści i ich kolej­no­ści, czym auto­rzy zbli­ży­li się jed­nak do poję­cia ​„algo­ryt­mu”. W dal­szej czę­ści piszą:

Według nor­my ISO 9000, pro­ces to: każ­de dzia­ła­nie, któ­re prze­kształ­ca wej­ście (dane wej­ścio­we) na
wyj­ście (dane wyj­ścio­we). Proces może w swo­im ?wnę­trzu? zawie­rać zbiór róż­nych ope­ra­cji (dzia­łań) wza­jem­nie ze sobą powią­za­nych i na sie­bie oddzia­łu­ją­cych. Jarosław Żeliński w swo­jej pra­cy, jako ana­li­tyk biz­ne­so­wy i sys­te­mo­wy, sto­su­je nastę­pu­ją­cą defi­ni­cję pro­ce­su: pro­ces to prze­kształ­ce­nie wej­ścia pro­ce­su w jego wyj­ście, z uży­ciem okre­ślo­nych zaso­bów i w obec­no­ści okre­ślo­nych ogra­ni­czeń.

Autorzy nie­ste­ty wyję­li to zda­nie z kon­tek­stu, cały mój zapis brzmiał:

Jeśli uzna­my, że pro­dukt i usłu­ga to ​„coś co ma war­tość dla klien­ta”, to powsta­je pro­sta i praw­dzi­wa moim zda­niem defi­ni­cja opi­su­ją­ca ​„sed­no spra­wy”. Ogólnie wymo­wa arty­ku­łu potwier­dza moją tezę o abs­trak­cyj­no­ści ​„pro­ce­su”, nama­cal­ne są za to pozo­sta­łe jego ele­men­ty: wej­ście i wyj­ście (pro­duk­ty), zaso­by (ludzie i maszy­ny) oraz regu­ły biz­ne­so­we (te są dokumentowane). 

Na zachę­tę cytat :):

The term ?pro­cess? is used in a wide varie­ty of ways. The first defi­ni­tion offe­red by MerriamWebster Online is (1) a natu­ral phe­no­me­non mar­ked by gra­du­al chan­ges that lead toward a par­ti­cu­lar result (e.g. the pro­cess of growth). In order to avo­id con­fu­sing our use of the term ?pro­cess? with any other possi­ble usa­ge, we will con­si­sten­tly use the term Business Process.

źr. http://​www​.bptrends​.com/​p​u​b​l​i​c​a​t​i​o​n​f​i​l​e​s​/​a​d​v​i​s​o​r​2​0​1​0​1​2​1​4​.​pdf

Osobiście w swo­ich pro­jek­tach sto­su­ję defi­ni­cję brzmią­cą: Proces to prze­kształ­ce­nie wej­ścia pro­ce­su w jego wyj­ście, z uży­ciem okre­ślo­nych zaso­bów i w obec­no­ści okre­ślo­nych ograniczeń. 

(https://it-consulting.pl//2010/12/17/co-to-jest-proces-biznesowy-po-raz-kolejny/)

Tak więc gene­ral­nie cho­dzi o roz­róż­nie­nie pojęć: pro­ces i pro­ces biz­ne­so­wy. Na moim blo­gu pro­wa­dzę tak­że słow­nik, jego celem jest zapew­nie­nie jed­no­znacz­no­ści arty­ku­łów, któ­re publi­ku­ję. Publikowane tam defi­ni­cje opie­ra­ją się na dostęp­nych źró­dłach, speł­nia­ją też pod­sta­wo­wą zasa­dę budo­wy słow­ni­ka (name­spa­ce): defi­ni­cje pojęć dzie­dzi­no­wych muszą się wza­jem­nie wyklu­czać i obej­mo­wać sobą wszyst­kie desy­gna­ty z opi­sy­wa­nej dzie­dzi­ny: każ­dy nazwa­ny byt dzie­dzi­ny (desy­gnat) speł­nia tyl­ko jed­ną defi­ni­cję, popraw­nie opi­sa­na dzie­dzi­na pro­ble­mu nie ma bytów nie­zde­fi­nio­wa­nych czy­li nie­na­zwa­nych (co ozna­cza, że popraw­ny słow­nik zawie­ra poję­cia pozwa­la­ją­ce jed­no­znacz­nie nazwać wszyst­ko w danej dzie­dzi­nie), poję­cie spe­cja­li­zu­ją­ce są typa­mi swo­ich uogól­nień i łącz­nie sta­no­wią tak­że popraw­ny słow­nik (na pod­sta­wie OMG spe­cy­fi­ka­cja nota­cji SBVR³).

Autorzy piszą, że z defi­ni­cja­mi jak wyżej, nie zga­dza się Object Management Group (OMG​.org), stwier­dze­nie to co mnie zaskoczyło.

Jednak z powy­żej przy­to­czo­ny­mi defi­ni­cja­mi nie zga­dza się orga­ni­za­cja Object Management Group (OMG), któ­ra w opra­co­wa­nej przez sie­bie defi­ni­cji pod­kre­śla, że pro­ces biz­ne­so­wy nie zawsze musi być upo­rząd­ko­wa­ny; co wię­cej – nie zawsze jego wyni­kiem jest wytwo­rze­nie jakie­goś dobra (towa­ru, usłu­gi, itp.). 

Troszkę teorii

Powołując się na spe­cy­fi­ka­cję nota­cji BPMN czytamy:

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.

Process: A sequ­en­ce or flow of Activities in an orga­ni­za­tion with the objec­ti­ve of car­ry­ing out work. In BPMN, a Process is depic­ted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and Sequence Flow that adhe­re to a fini­te exe­cu­tion semantics.

(ang. Proces biz­ne­so­wy: zde­fi­nio­wa­ny zestaw dzia­łań 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 prze­pływ i wyko­rzy­sta­nie infor­ma­cji i zasobów.

Proces: sekwen­cja lub prze­pływ dzia­łań w orga­ni­za­cji w two­rzą­ca efekt pra­cy. W BPMN pro­ces jest przed­sta­wio­ny jako graf obra­zu­ją­cy prze­pływ ele­men­tów, któ­re są zbio­rem dzia­łań, zda­rzeń, bra­mek i prze­pły­wu, któ­re są zgod­ne z okre­ślo­ną seman­ty­ką ich realizacji).

Autorzy wycią­ga­ją wniosek:

Nie ma w tym przy­pad­ku ogra­ni­cze­nia, że pro­ces musi coś wytwa­rzać, gdyż ? jak zauwa­żo­no ? we wszyst­kich orga­ni­za­cjach reali­zu­je się sze­reg prac, któ­re nie zawsze przy­no­szą jakie­kol­wiek efek­ty (nie­któ­re zada­nia są reali­zo­wa­ne, mimo, iż nie mają biz­ne­so­we­go uza­sad­nie­nia). Według OMG, pro­ces biz­ne­so­wy to sekwen­cja lub prze­pływ czyn­no­ści w jakiejś orga­ni­za­cji, któ­rych celem jest wyko­na­nie jakiejś pra­cy. Zatem pro­ce­sem jest nie tyl­ko sekwen­cja czyn­no­ści, ale tak­że sam prze­pływ czynności.

Prawdą jest więc, że pro­ces biz­ne­so­wy wg. OMG to pra­ca jako okre­ślo­ny łań­cuch czyn­no­ści, ale nie zro­zu­mia­łe jest dla mnie ostat­nie zda­nie: pro­ce­sem jest nie tyl­ko sekwen­cja czyn­no­ści, ale tak­że sam prze­pływ czyn­no­ści. OMG w spe­cy­fi­ka­cji BPMN (patrz wyżej) jasno defi­niu­je poję­cie pro­ce­su (sekwen­cja ele­men­tów, któ­re są zbio­rem dzia­łań, zda­rzeń, bra­mek i prze­pły­wu, ten ostat­ni jest rów­no­praw­nym ele­men­tem a nie jakimś innym, osob­nym czymś).

Zajrzyjmy do spe­cy­fi­ka­cji nota­cji BPMN: Powyższy dia­gram, to tak zwa­ny dia­gram pro­fi­lu (UML), pro­fil to gra­ficz­na for­ma słow­ni­ka pojęć i ich syn­tak­ty­ki⁵. Profil (dia­gram pro­fi­lu) to dia­gram klas w nota­cji UML (patrz spe­cy­fi­ka­cja OMG: MOF), zawie­ra­ją­cy związ­ki struk­tu­ral­ne (kom­po­zy­cja) oraz poję­cio­we (aso­cja­cja i gene­ra­li­za­cja). Powyższe czytamy:

1. ele­men­ty prze­pły­wu w pro­ce­sie to: Obiekt Danych, Węzeł Przepływu, prze­pływ (może zawie­rać waru­nek prze­pły­wu), Odnośnik Do Składu danych, prze­pływ to ele­ment sta­no­wią­cy wyma­ga­ny łącz­nik pomię­dzy węzłami,
2. typy węzłów prze­pły­wu: Aktywność, Zdarzenie, Bramka, Aktywność choreografii.

Na tle powyż­sze­go, teza auto­rów publikacji:

Nie ma w tym przy­pad­ku ogra­ni­cze­nia, że pro­ces musi coś wytwa­rzać. […] Zatem pro­ce­sem jest nie tyl­ko sekwen­cja czyn­no­ści, ale tak­że sam prze­pływ czynności.

jest nie­praw­dzi­wa. Proces to okre­ślo­na sekwen­cja ale pro­ces biz­ne­so­wy z zasa­dy coś two­rzy, jest to sku­tek (efekt, pro­dukt) wyko­na­nia tej sekwen­cji czyn­no­ści. Stanowi więc zmia­nę okre­ślo­ne­go sta­nu rze­czy (pro­ces, jako coś co zaszło, z zasa­dy zmie­nia śro­do­wi­sko w jakim zacho­dził). Teza, mówią­ca że coś zaszło bez skut­ków jest nie­lo­gicz­na. Definicja pro­ce­su biz­ne­so­we­go w BPMN (doda­tek) zawie­ra w sobie pro­dukt tego procesu.

(wię­cej o nota­cji BPMN w arty­ku­le Notacja BPMN ? Jak czy­tać diagramy)

Proces vs. procedura

W 2014 roku pisałem:

…kil­ka klu­czo­wych defi­ni­cji (słow­nik języ­ka pol­skie­go PWN):

pro­ces: prze­bieg nastę­pu­ją­cych po sobie i powią­za­nych przy­czy­no­wo okre­ślo­nych zmian

pro­ce­du­ra: okre­ślo­ne regu­ły postępowania

(https://it-consulting.pl//2014/10/05/sekwencje-a-procesy/)

przy­po­mnij­my defi­ni­cje słow­ni­ko­we⁷:

pro­ce­du­ra

1. ?okre­ślo­ne regu­ły postę­po­wa­nia w jakiejś spra­wie, zwy­kle o cha­rak­te­rze urzę­do­wym lub prawnym?

2. ?w języ­kach pro­gra­mo­wa­nia: wydzie­lo­ny frag­ment algorytmu?

Zaglądamy ponow­nie do słownika:

zasa­da

1. ?pra­wo rzą­dzą­ce jaki­miś pro­ce­sa­mi, zja­wi­ska­mi; też: for­mu­ła wyja­śnia­ją­ca to prawo?

Innymi sło­wy pro­ce­du­ra to zbiór praw (zasad) a nie prze­pływ zda­rzeń (ale ich kolej­ność może wyni­kać z tych praw lub może być tym pra­wem). Potocznie poję­cie pro­ce­du­ry fak­tycz­nie jest uży­wa­ne do nazwa­nia dowol­ne­go opi­sa­ne­go (pro­ce­du­rą) spo­so­bu postę­po­wa­nia (tak­że w nor­mach jako­ści ISO) jed­nak poja­wie­nie się poję­cia pro­ces biz­ne­so­wy wyma­ga już dopro­wa­dze­nia tych defi­ni­cji do posta­ci, w któ­rej defi­ni­cje te speł­nia­ją wyma­ga­nia wobec słow­ni­ka: defi­ni­cje muszą się wyklu­czać i jed­no­cze­śnie pokry­wać sobą wszyst­kie desy­gna­ty danej dzie­dzi­ny (patrz trój­kąt seman­tycz­ny nota­cja SBVR ).

Jednym z ele­men­tów pro­ce­su w BPMN jest tak zwa­na aktyw­ność⁴.

Activity: Work that a com­pa­ny or orga­ni­za­tion per­forms using busi­ness pro­ces­ses. An acti­vi­ty can be ato­mic or non-ato­mic (com­po­und). The types of acti­vi­ties that are a part of a Process Model are: Process, Sub-Process, and Task.

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.

(ang. Aktywność: pra­ca wyko­ny­wa­na przez fir­mę lub orga­ni­za­cję w toku (przy uży­ciu) pro­ce­sów biz­ne­so­wych. Aktywność może być ato­mo­wa lub nie­ato­mo­wa (zło­żo­na). Rodzaje aktyw­no­ści wcho­dzą­cych w skład Modelu Procesu to: Proces, Podproces i Zadanie.

Aktywność ato­mo­wa: aktyw­ność nie dzie­lo­na na mniej­sze czę­ści jako kolej­ne pozio­my szcze­gó­łów mode­lu pro­ce­su. Jest to liść w hie­rar­chii drze­wia­stej w pro­ce­sach. Graficznie poja­wi się jako zada­nie w BPMN.)

Nie tyl­ko w języ­ku pol­skim, aktyw­no­ścią nazy­wa­my każ­de podej­mo­wa­ne dzia­ła­nie (czy­jeś postę­po­wa­nie). Tak więc w BPMN mamy:

1. Każda sekwen­cja okre­ślo­nych aktyw­no­ści to pro­ces, taka któ­ra ma okre­ślo­ne kon­se­kwen­cje: two­rzy pro­dukt (w BPMN zda­rze­nie lub obiekt danych), to pro­ces biz­ne­so­wy (nota­cja BPMN nie zawie­ra sym­bo­lu: pro­ces biznesowy!).
2. Najniżej w hie­rar­chii pro­ce­sów i skła­da­ją­cych się na nie aktyw­no­ści jest zada­nie (ato­mo­wa aktywność).

Aktywności w BPMN opi­su­je poniż­szy profil:

Czytamy dia­gram tak (związ­ki słow­ni­ko­we generalizacji):

1. Aktywność jest typem węzła, czy­li ele­men­tem prze­pły­wu (patrz poprzed­ni profil),
2. Aktywność to poję­cie abs­trak­cyj­ne, typa­mi aktyw­no­ści są zada­nia, odwo­ła­nia do zadań oraz pod-procesy.

Warto tu zwró­cić, uwa­gę na to, że pod-pro­ces to tak zwa­ny kon­te­ner. Kontener to zasob­nik na ele­men­ty, for­mal­nie w BPMN takim zasob­ni­kiem jest dia­gram. Innymi sło­wy: jeże­li na dia­gra­mie poja­wi się ele­ment pod-pro­ces, to musi z nim być sko­ja­rzo­ny okre­ślo­ny dia­gram BPMN sta­no­wią­cy jego dekom­po­zy­cję. Innymi sło­wy jeże­li aktyw­ność jest zada­niem (ato­mo­wa aktyw­ność) nie ma ona już dal­szych pod-pro­ce­sów. Aktywność będą­ca pod-pro­ce­sem musi być opi­sa­na z pomo­cą kolej­ne­go dia­gra­mu BPMN. Najniżej w hie­rar­chii aktyw­no­ści BPMN są zada­nia (task). Zgodnie z przy­to­czo­nym defi­ni­cja­mi, zada­nie i jego pro­dukt to «ato­mo­wy pro­ces biz­ne­so­wy» (w lite­ra­tu­rze moż­na tak­że spo­tkać alter­na­tyw­ne poję­cie: pro­ces elementarny).

Co z procedurą?

W BPMN to poję­cie for­mal­nie nie wystę­pu­je, poja­wia się jed­nak w więk­szo­ści narzę­dzi do mode­lo­wa­nia i symu­lo­wa­nia pro­ce­sów. Tam pro­ce­du­ra jest defi­nio­wa­na jako spo­sób postę­po­wa­nia w ramach aktyw­no­ści. Ma to głę­bo­ki sens, bo uzna­nie, że pro­ce­du­ra jest na szczy­cie hie­rar­chii pro­ce­sów pro­wa­dzi­ło by do sytu­acji, w któ­rej wszyst­ko jest pro­ce­du­rą, co prze­czy zasa­dzie wyłącz­no­ści w budo­wa­niu słow­ni­ków (pro­ces nie może być typem lub czę­ścią pro­ce­du­ry). W ramach norm ISO jest wymóg by pro­ce­du­ry two­rzy­ły sobą spój­ne pro­ce­sy biz­ne­so­we. Innymi słowy, 

Proces biznesowy jako abstrakcja

Proces biz­ne­so­wy to aktyw­ność jako abs­trak­cja okre­ślo­nej pra­cy oraz powią­za­ne z nią jej wej­ście i wyj­ście . Proces jest ste­ro­wa­ny (ma ogra­ni­cze­nia), wyma­ga zaso­bów. Graficzna postać tej definicji:

Powyższe moż­na przed­sta­wić tak:

Z powyż­sze­go wyni­ka, że 

To dla­te­go orga­ni­za­cje mają udo­ku­men­to­wa­ne: wzo­ry doku­men­tów, zarzą­dze­nia, pro­ce­du­ry, zakre­sy obo­wiąz­ków, instruk­cje sta­no­wi­sko­we i instruk­cje użyt­kow­ni­ka wyko­rzy­sty­wa­ne­go wypo­sa­że­nia, nad tym wszyst­kim jest obo­wią­zu­ją­ce pra­wo. Rzadko kie­dy mają jed­nak mapy i mode­le pro­ce­sów poka­zu­ją­ce to w jakiej kolej­no­ści i dla­cze­go to wszyst­ko sie odbywa. 

Z per­spek­ty­wy metod ana­li­zy MBSE: spoj­rze­nia przez pry­zmat tech­no­lo­gii i ludzi wyglą­da to tak: 

Podsumowując: pro­ces jako ele­ment mode­lu to abs­trak­cja pra­cy: aktyw­ność wraz z okre­śle­niem ​„co powsta­je” (pro­dukt). Sposób wyko­na­nia tej pra­cy: meto­da, to narzu­co­na okre­ślo­na pro­ce­du­ra. Procedura może wska­zy­wać na potrze­bę uży­cia okre­ślo­nych narzę­dzi. Całość reali­zo­wa­na jest w okre­ślo­nym śro­do­wi­sku: orga­ni­za­cja i narzę­dzia, w tym opro­gra­mo­wa­nie (np. ERP). 

Kluczowe pojęcia w modelowaniu

W nota­cji BPMN ele­men­tar­ny pro­ces biz­ne­so­wy to nie­po­dziel­na Aktywność (Zadanie) i jej Wejście i Produkt (w BPMN są ele­men­ty typu DataObject). W przy­pad­ku mode­lo­wa­nia wewnętrz­ne­go zacho­wa­nia się sys­te­mu (logi­ka biz­ne­so­wa reali­zo­wa­na przez opro­gra­mo­wa­nie) z uży­ciem nota­cji UML, mamy odpo­wied­nio aktyw­ność oraz jej pro­ce­du­rę jako ciąg zadań (linii kodu). 

Poniżej model poję­cio­wy dla opi­sy­wa­ne­go powy­żej zbio­ru pojęć.

Model powyż­szy poka­zu­je, że umiesz­cze­nie poję­cia pro­ce­du­ra gdzie­kol­wiek wyżej w hie­rar­chii pojęć BPMN jest prak­tycz­nie nie­moż­li­we przy zacho­wa­niu zasa­dy logi­ki zwa­nej zasa­dą wyłą­czo­ne­go środ­ka: pro­ce­du­ra nie jest pro­ce­sem a pro­ces nie jest pro­ce­du­rą. Tak więc pro­ce­sy biz­ne­so­we, jako łań­cu­chy zadań i ich pro­duk­tów, może­my dekom­po­no­wać aż do pozio­mu pro­ce­sów ato­mo­wych, a pro­ce­du­ra to spo­sób postę­po­wa­nia w reali­zo­wa­niu zada­nia (ato­mo­wej aktyw­no­ści w pro­ce­sie). Umieszczenie poję­cia pro­ce­du­ra w innym miej­scu dopusz­cza­ło by praw­dzi­wość stwier­dze­nia: pro­ce­du­ra skła­da się pro­ce­sów, co nie­ste­ty prze­czy logice.

Na zakoń­cze­nie waż­na uwa­ga na temat mode­li pro­ce­sów z uży­ciem BPMN. Jednym z ele­men­tów prze­pły­wu są tak zwa­na bram­ki (ang. gate­way). Dość czę­stym błę­dem jest przy­po­rząd­ko­wy­wa­nie bram­kom jakiej­kol­wiek pra­cy. Specyfikacja BPMN mówi:

8.4.9 Gateways
Gateways are used to con­trol how the Process flows (how Tokens flow) thro­ugh Sequence Flows as they conver­ge and diver­ge within a Process. If the flow does not need to be con­trol­led, then a Gateway is not needed. The term ?gate­way? implies that the­re is a gating mecha­nism that either allows or disal­lows pas­sa­ge thro­ugh the Gateway; that is, as tokens arri­ve at a Gateway, they can be mer­ged toge­ther on input and/or split apart on out­put as the Gateway mecha­ni­sms are invoked.

Gateways, like Activities, are capa­ble of con­su­ming or gene­ra­ting addi­tio­nal con­trol tokens, effec­ti­ve­ly con­trol­ling the exe­cu­tion seman­tics of a given Process. The main dif­fe­ren­ce is that Gateways do not repre­sent ?work? being done and they are con­si­de­red to have zero effect on the ope­ra­tio­nal measu­res of the Process being exe­cu­ted (cost, time, etc.).

Ostatnie, wytłusz­czo­ne zda­niem mówi:

Główną róż­ni­cą jest to, że bram­ki nie repre­zen­tu­ją ​„pra­cy”, mają więc zero­wy wpływ na mia­ry ope­ra­cyj­ne wyko­ny­wa­ne­go pro­ce­su (koszt, czas itp.).

Innymi sło­wy jaka­kol­wiek pra­ca, np. z ana­li­zą danych i podej­mo­wa­niem decy­zji, jest reali­zo­wa­na w aktyw­no­ściach poprze­dza­ją­cych bram­kę, ta (bram­ka) sta­no­wi sobą wyłącz­nie mecha­nizm prze­pusz­cza­nia lub blo­ko­wa­nia (toke­na), opar­ty na tre­ści (typo­wa bram­ka to bram­ka danych, np. jakiś atry­but toke­nu zawie­ra okre­ślo­ną treść i ta jest wyma­ga­na, to bram­ka prze­pu­ści taki token). Innymi sło­wy bram­ka danych jest mani­fe­sta­cją decy­zji jaka zosta­ła pod­ję­ta w aktyw­no­ści poprze­dza­ją­cej ją.

To ozna­cza, że auto­rzy nie­po­praw­nie uży­wa­ją bra­mek XOR (cyto­wa­na pra­ca, Rys.3.), pisząc, że repre­zen­tu­je ona pra­cę czy­li zada­nie pyta­nia (dia­log) i ocze­ki­wa­nie odpo­wie­dzi. Poprawne podej­ście w BPMN: pew­na okre­ślo­na aktyw­ność zbie­ra dane (ankie­ta) i dane te (pro­dukt aktyw­no­ści ankie­to­wa­nia), w posta­ci ele­men­tu DataObject (lub jako token) tra­fia­ją na bram­kę XOR, a ta np. prze­pusz­cza dalej wyłącz­nie token repre­zen­tu­ją­cy ankie­tę zawie­ra­ją­ca odpo­wiedź TAK na okre­ślo­ne pytanie.

Podsumowanie

Generalizując, powyż­sze moż­na zebrać w posta­ci struk­tu­ry poka­za­nej poniżej:

Na powyż­szym dia­gra­mie pokazano:

• W cen­tral­nej czę­ści poka­za­no ele­men­tar­ny (ato­mo­wy) pro­ces biz­ne­so­wy (może on być czę­ścią więk­szej całości).
• Nad nim poka­za­no model (mapę) pro­ce­sów biz­ne­so­wych (może to być nad­rzęd­ny pro­ces) poka­zu­ją­cych jak pro­ce­sy biz­ne­so­we po sobie następują.
• Pod nim pro­ce­du­ra i róż­ne for­my ich doku­men­to­wa­nia (tekst, tabe­la, sche­mat blo­ko­wy, może zawie­rać regu­ły biz­ne­so­we, macie­rze RACI itp.).
• Po pra­wej stro­nie struk­tu­ra doku­men­tu (arte­fakt), jest on nośni­kiem danych, jest przy­wo­ły­wa­ny na każ­dym pozio­mie mode­lo­wa­nia (na mode­lach pro­ce­sów BPMN jest to kar­tecz­ka z zagię­tym rogiem, w pro­ce­du­rach powo­łu­je­my się na nazwy doku­men­tów) .

Warto tu zwró­cić uwa­gę na fakt, że mode­lo­wa­nie pro­ce­sów biz­ne­so­wych na pod­sta­wie wywia­dów i ankiet (pozy­ski­wa­nie infor­ma­cji o wyko­ny­wa­nych czyn­no­ściach) wpro­wa­dza ogrom­ną zależ­ność uzy­ska­nych wyni­ków od subiek­tyw­ne­go postrze­ga­nia orga­ni­za­cji przez zatrud­nio­nych w niej (i ankie­to­wa­nych) pracowników. 

Z per­spek­ty­wy samych pojęć mamy: 

Co pozwa­la tak­że wyka­zać, że łącz­ni­kiem mię­dzy aktyw­no­ścia­mi na mode­lach pro­ce­sów a zaso­ba­mi są procedury.

Powoli, od ponad deka­dy, prze­bi­ja­ją się do świa­do­mo­ści firm ana­li­tycz­nych, meto­dy opar­te na fak­tach, a są nimi tak zwa­ne «arte­fak­ty» czy­li nama­cal­ne śla­dy po wyko­na­nej pra­cy. W warun­kach biz­ne­so­wych są do doku­men­ty ope­ra­cyj­ne i ich treść. 

„Każda fir­ma, nie­za­leż­nie od tego, jakie fizycz­ne towa­ry lub usłu­gi wytwa­rza, opie­ra się na doku­men­ta­cji han­dlo­wej. Musi ona zapi­sy­wać szcze­gó­ły tego, co wytwa­rza w posta­ci kon­kret­nych infor­ma­cji. Artefakty biz­ne­so­we są mecha­ni­zmem zapi­su tych infor­ma­cji w jed­nost­kach, któ­re są kon­kret­ne, iden­ty­fi­ko­wal­ne, samo­opi­su­ją­ce się i niepodzielne.” 

„W cią­gu ostat­nich kil­ku lat, coraz więk­sze wyma­ga­nia sta­wia­ne są efek­tyw­nym podej­ściom do pro­jek­to­wa­nia, mode­lo­wa­nia i wdra­ża­nia mię­dzy­or­ga­ni­za­cyj­nych pro­ce­sów biz­ne­so­wych. W pro­ce­sie współ­pra­cy ponad gra­ni­ca­mi orga­ni­za­cyj­ny­mi, orga­ni­za­cje nadal pozo­sta­ją auto­no­micz­ne, co ozna­cza, że każ­da z nich może dowol­nie mody­fi­ko­wać swo­je wewnętrz­ne ope­ra­cje, aby osią­gnąć swo­je pry­wat­ne cele, jed­no­cze­śnie speł­nia­jąc wza­jem­ne cele swo­ich part­ne­rów. Ostatnio udo­wod­nio­no, że mode­lo­wa­nie pro­ce­sów skon­cen­tro­wa­ne na arte­fak­tach zapew­nia więk­szą ela­stycz­ność w mode­lo­wa­niu i reali­za­cji pro­ce­sów niż tra­dy­cyj­ne meto­dy mode­lo­wa­nia skon­cen­tro­wa­ne na działaniach.” 

Dlatego mode­lo­wa­nie orga­ni­za­cji bazu­ją­ce na defi­ni­cji pro­ce­su postrze­ga­ne­go jako dzia­ła­nia two­rzą­ce pro­dukt (arte­fakt), wyda­je się być obec­nie naj­lep­szą prak­ty­ką ana­li­zy biznesowej. 

Dodatek: dokumentowanie procedur w BPMN z użyciem Visual Paradigm

Podział na pozio­me pro­ce­sów i pro­ce­dur bar­dzo dobrze reali­zu­je narzę­dzie Visual Paradigm (patrz Jak pisać pro­ce­du­ry zadań). Poniżej pokaz video jak to robić: 

Źródła