Tag: proces biznesowy

Od docflow do workflow, czyli o skutecznym modelowaniu i czynnikach warunkujących sukces wdrożenia

Dodaj komentarz

Od lat nie cich­nie dys­ku­sja na temat prze­pły­wu pra­cy i doku­men­tów oraz zarzą­dza­nia pro­ce­sa­mi biz­ne­so­wy­mi zacho­dzą­cy­mi w fir­mach. Nierzadko wie­le pojęć z tego zakre­su sto­su­je­my błęd­nie, dla­te­go war­to usys­te­ma­ty­zo­wać sobie wie­dzę o nich, wska­zać róż­ni­ce mię­dzy nimi i osta­tecz­nie odpo­wie­dzieć na pyta­nie, czy opro­gra­mo­wa­nia wspo­ma­ga­ją­ce ten obszar moż­na z suk­ce­sem wdro­żyć we wszyst­kich przed­się­bior­stwach. To klu­czo­we, jeśli chce­my sku­tecz­nie zarzą­dzać pro­ce­sa­mi w firmie.

Dokumenty i procesy

Demagogią jest twier­dze­nie, że koszt prze­cho­wy­wa­nia doku­men­tu elek­tro­nicz­ne­go to tyl­ko kil­ka mikro­me­trów dys­ku i koszt tego miniob­sza­ru. Prawdziwym kosz­tem prze­cho­wa­nia takie­go doku­men­tu jest bowiem koszt całej infra­struk­tu­ry wraz z jej zabez­pie­cze­niem. Gdyby było ina­czej, każ­dy z nas miał­by już w fir­mie elek­tro­nicz­ne superarchiwum.

Co wię­cej, obieg doku­men­tów to nie ? jak się myl­nie sądzi ? zarzą­dza­nie pro­ce­sa­mi. Dokumenty są tyl­ko jed­nym z ele­men­tów mapy pro­ce­sów orga­ni­za­cji, a zatem sys­te­my obie­gu doku­men­tów to wspar­cie zarzą­dza­nia zorien­to­wa­ne­go na pro­ce­sy, nie zaś sys­te­my zarzą­dza­nia pro­ce­sa­mi biznesowymi.

Wielu utoż­sa­mia poję­cie obie­gu doku­men­tów, obie­gu infor­ma­cji z pro­ce­sa­mi biz­ne­so­wy­mi i ich zarzą­dza­niem. Jest to moim zda­niem klu­czo­we nie­po­ro­zu­mie­nie, żeby nie powie­dzieć błąd.

Proces biz­ne­so­wy to dzia­ła­nie cha­rak­te­ry­zu­ją­ce się przede wszyst­kim wno­sze­niem war­to­ści doda­nej i posia­da­nie papie­ru czy doku­men­tu w wer­sji elek­tro­nicz­nej nie ma tu nic do rze­czy. Na mapie pro­ce­sów biz­ne­so­wych doku­men­ty i ich kolej­ne wer­sje sta­no­wią pro­duk­ty pro­ce­sów (nie­je­dy­ne zresz­tą). Proces pole­ga­ją­cy na pod­ję­ciu decy­zji to pra­ca czło­wie­ka nio­są­ca dużą war­tość doda­ną, ale nie obieg doku­men­tów będą­cych śla­da­mi po nie­któ­rych tyl­ko pro­ce­sach w fir­mie. Dla przy­kła­du pro­ce­sem jest wypro­du­ko­wa­nie pod­ze­spo­łu i nie ma to nic wspól­ne­go z sys­te­mem obie­gu doku­men­tów. Gdzieś po dro­dze powsta­nie doku­men­ta­cja tech­nicz­na, ale jeden z ele­men­tów sys­te­mu zarzą­dza­nia pro­ce­sa­mi w fir­mie, jego podsystem.

Systemy obie­gu doku­men­tów i obie­gu infor­ma­cji są waż­ny­mi ele­men­ta­mi w każ­dej orga­ni­za­cji, ale są to tyl­ko pro­duk­ty i to nie wszyst­kie na mapie pro­ce­sów biz­ne­so­wych fir­my, dla­te­go wła­śnie nazy­wa­nie sys­te­mów, zali­cza­nych do kla­sy work­flow, sys­te­ma­mi BPM (Business Process Management) uwa­żam za poważ­ne nadużycie.

Kolejną śle­pą ulicz­ką jest trak­to­wa­nie sys­te­mów kla­sy work­flow jako narzę­dzi ści­słej kon­tro­li poczy­nań pra­cow­ni­ków. Nie znam przy­pad­ku wdro­że­nia sys­te­mu zakoń­czo­ne­go suk­ce­sem, któ­re­go głów­nym celem było kon­tro­lo­wa­nie pra­cow­ni­ków (np. cza­su ich pra­cy). Znacznie sku­tecz­niej­sze są sys­te­my infor­ma­tycz­ne zapro­jek­to­wa­ne tak, by poma­ga­ły pra­cow­ni­kom osią­gać ich cele. Takie nie­ja­ko wdra­ża­ją się same. Z kolei sys­te­my kon­tro­li i restryk­cji, nawet jeże­li uda­je się je wdro­żyć, są bar­dzo kosz­tow­ne i czę­sto boj­ko­to­wa­ne przez pracowników.

Jednak coś w tym jest, że obieg doku­men­tów (infor­ma­cji) cza­sa­mi sta­je się mode­lem procesów.

Kiedy i co modelować

Jeżeli cze­goś nie moż­na nary­so­wać, to zna­czy, że to nie ist­nie­je! To stwier­dze­nie odno­si się do isto­ty pro­ce­sów i zarzą­dza­nia nimi. Aby czym­kol­wiek zarzą­dzać, nale­ży to naj­pierw opi­sać, czy­li udo­ku­men­to­wać. Takim opi­sem będzie mapa pro­ce­sów biz­ne­so­wych, któ­ra sta­no­wi model fir­my z per­spek­ty­wy jej funk­cjo­no­wa­nia. Jak ją pra­wi­dło­wo wykonać?

Model fir­my powi­nien w spo­sób jasny i zro­zu­mia­ły dla jej pra­cow­ni­ków opi­sy­wać fir­mę, jej cel ryn­ko­wy oraz wszel­kie jej aktyw­no­ści wewnętrz­ne i zewnętrz­ne. Jest on nie­zbęd­ny do prze­wi­dy­wa­nia zacho­wań fir­my, ale tak­że do przy­go­to­wa­nia jej na wdro­że­nia sys­te­mów informacyjnych.

Cała publi­ka­cja w ostat­nim nume­rze Informacja Zarządcza 18/2019. 

Od zapytania do realizacji zamówienia czyli jak to się robi z BPMN

8 komentarzy

Wprowadzenie

Ostatnio poja­wi­ła się w pra­sie i mediach inter­ne­to­wych dys­ku­sja na temat tego czym jest fak­tu­ra, nie­ste­ty bar­dzo wie­le z tych opi­nii jest pozba­wio­na pod­staw mery­to­rycz­nych i praw­nych, są nie­jed­no­krot­nie po pro­stu nie­praw­dzi­we. Biorąc pod uwa­gę fakt, że wie­le tych opi­nii to opi­nie wygła­sza­ne przez przed­się­bior­ców, wyła­nia się smut­ny obraz jako­ści infor­ma­cji zbie­ra­nej meto­dą wywia­dów w toku ana­liz biz­ne­so­wych. Studiowanie lite­ra­tu­ry, cudzych opra­co­wań w roli audy­to­ra, ana­li­za pytań i uwag moich klien­tów to ogrom­ne doświad­cze­nie. Rok temu w arty­ku­le Mit o nota­cji BPMN pisa­łem o szko­dli­wo­ści nad­mia­ru szcze­gó­łów na mode­lach. To wszyst­ko razem skło­ni­ło mnie tym razem do opra­co­wa­nia przy­kła­du dia­gra­mu obra­zu­ją­ce­go pro­ces biz­ne­so­wy wyko­na­ny w nota­cji BPMN1.

Celem tego arty­ku­łu jest poka­za­nie jak opra­co­wać model pro­ce­su biz­ne­so­we­go bazu­jąc wyłącz­nie na pra­wie i tego jak to zro­bić zgod­nie z nota­cją BPMN. Pokazano tak­że, że nota­cja BPMN nie jest narzę­dziem doku­men­to­wa­nia ​„wszyst­kie­go co wie­my o pro­ce­sie”. Istotne jest tak­że to, że nota­cja BPMN to język wyra­zu – narzę­dzie – a nie meto­dy­ka, oraz to że spe­cy­fi­ka­cja BPMN to nie pod­ręcz­nik mode­lo­wa­nia a jedy­nie opis pojęć i ich zna­czeń oraz przy­kła­dy kon­struk­cji (seman­ty­ka i syn­tak­ty­ka nota­cji) co nie zna­czy, że są to wzor­ce pro­jek­to­we. Uważam, że wzor­ców takich nie ma takich w biz­ne­sie, pro­ce­sów ​„refe­ren­cyj­nych” też nie ma. Biznes to pra­wo oraz indy­wi­du­al­ne wewnętrz­ne regulacje.

W ramach wpro­wa­dze­nia opi­sa­no naj­pierw zasa­dy two­rze­nia mode­li ana­li­tycz­nych z uży­ciem nota­cji BPMN.

Notacja BPMN a MDA i UML

Kilka uwag na temat nota­cji BPMN i klu­czo­wych jej cech. Celem stwo­rze­nia tej nota­cji była komunikacja:

The pri­ma­ry goal of BPMN is to pro­vi­de a nota­tion that is readi­ly under­stan­da­ble by all busi­ness users, from the busi­ness ana­ly­sts that cre­ate the ini­tial dra­fts of the pro­ces­ses, to the tech­ni­cal deve­lo­pers respon­si­ble for imple­men­ting the tech­no­lo­gy that will per­form tho­se pro­ces­ses, and final­ly, to the busi­ness people who will mana­ge and moni­tor tho­se pro­ces­ses. Thus, BPMN cre­ates a stan­dar­di­zed brid­ge for the gap betwe­en the busi­ness pro­cess design and pro­cess imple­men­ta­tion.[BPMN c.1.1. 1]

Generalnie rzecz bio­rąc (patrz moje wytłusz­cze­nie): dia­gra­my te powin­ny być zro­zu­mia­łe dla tak zwa­nych ludzi biz­ne­su (bo jeże­li nie są, to są bez­u­ży­tecz­ne), sta­no­wią (sfor­ma­li­zo­wa­ny) szkic dla ludzi odpo­wie­dzial­nych za ich imple­men­ta­cję. Modele pro­ce­sów biz­ne­so­wych sta­no­wią ele­ment mode­li CIM (Computational Independent Model, model nie­za­leż­ny od tech­no­lo­gii IT2).

Poniżej cytu­ję aka­pit opi­su­ją­cy isto­tę podzia­łu mode­li na pozio­my abs­trak­cji (dokład­no­ści).

As an alter­na­ti­ve to full Process Modeling Conformance, the­re are three con­for­man­ce sub-clas­ses defined:

  • Descriptive
  • Analytic
  • Common Executable

Descriptive is con­cer­ned with visi­ble ele­ments and attri­bu­tes used in high-level mode­ling. It sho­uld be com­for­ta­ble for ana­ly­sts who have used BPA flow­char­ting tools.

Analytic con­ta­ins all of Descriptive and in total abo­ut half of the con­structs in the full Process Modeling Conformance Class. It is based on expe­rien­ce gathe­red in BPMN tra­ining and an ana­ly­sis of user-pat­terns in the Department of Defense Architecture Framework and plan­ned stan­dar­di­za­tion for that framework.

Both Descriptive and Analytic focus on visi­ble ele­ments and a mini­mal sub­set of sup­por­ting attributes/elements.

Common Executable focu­ses on what is needed for exe­cu­ta­ble pro­cess models.

Elements and attri­bu­tes not in the­se sub-clas­ses are con­ta­ined in the full Process Modeling Conformance class. The ele­ments for each sub-class are defi­ned in the next sub clau­se. [BPMN c.2.2.1.1]

Istotą mode­lo­wa­nia pro­ce­sów z uży­ciem BPMN jest więc wła­ści­wy dobór pozio­mu szcze­gó­ło­wo­ści. Powyższe ma zna­cze­nie w kon­tek­ście umiesz­cze­nia tych typów mode­li na tle MDA (Model Driven Architecture2) i sko­re­lo­wa­nia z mode­la­mi UML.

Na pozio­mie CIM powsta­ją mode­le opi­su­ją­ce mecha­nizm dzia­ła­nia orga­ni­za­cji w cał­ko­wi­tym ode­rwa­niu od tech­no­lo­gii IT wspie­ra­ją­cych tę orga­ni­za­cję. Notacja BPMN jest tu wspie­ra­na spe­cy­fi­ka­cją SBVR3 (biz­ne­so­wy słow­nik pojęć i regu­ły biz­ne­so­we). Są to wyłącz­nie mode­le poglą­do­we i analityczne.

Kolejny krok to opra­co­wa­nie mode­li wyko­ny­wal­nych czy­li mode­li imple­men­ta­cji pro­ce­sów (wyra­żo­nych w BPMN) z uży­ciem sys­te­mów BPMS (Business Process Management Systems, są to śro­do­wi­ska wyko­naw­cze mode­li BPMN com­mon exe­cu­ta­ble). W prak­ty­ce te mode­le mają wer­sję PIM (wyko­na­ne na bazie stan­dar­du BPMN/BPEL/XPDL) i PSM czy­li dosto­so­wa­ne do śro­do­wi­ska BPMS kon­kret­ne­go pro­du­cen­ta plat­for­my. Jest to ścież­ka bazu­ją­ca cał­ko­wi­cie na nota­cji BPMN i plat­for­mach wyko­naw­czych BPMS.

Proces ​„tra­dy­cyj­ny” inży­nie­rii opro­gra­mo­wa­nia opar­ty na MDA tak­że zaczy­na się powsta­nia mode­lu CIM. Kolejny etap (model) to zawar­cie umo­wy na zakres pro­jek­tu czy­li okre­śle­nie wyma­gań. Do tego słu­ży model przy­pad­ków uży­cia (w UML od wer­sji 2.5 jest jaw­nie okre­śla­ny jako ​„dodat­ko­wy”, patrz Figure 6.1 Semantic Areas of UML4):

Rys. Semantic are­as of UML 2.5.1

Biorąc pod uwa­gę zmia­ny jakie wpro­wa­dzo­no do UML w v.2.5. w zasa­dzie książ­ki i pod­ręcz­ni­ki UML napi­sa­ne przed 2015 rokiem (wej­ście 2.5. UML), moż­na wyrzu­cić do kosza.

Po okre­śle­niu zakre­su pro­duk­tu, powsta­je model PIM sta­no­wią­cy model mecha­ni­zmu dzia­ła­nia opro­gra­mo­wa­nia. Ten model to spe­cy­fi­ka­cja logi­ki dzia­ła­nia (czę­sto sta­no­wi know-how zama­wia­ją­ce­go). Po doko­na­niu wybo­ru dostaw­cy, ten – mając na uwa­dze tech­no­lo­gię któ­rej uży­je, two­rzy model PSM i reali­zu­je imple­men­ta­cję (w prak­ty­ce, pomi­ja się model PSM, naj­czę­ściej powsta­je od razu kod na bazie archi­tek­tu­ry opi­sa­nej w mode­lu PIM).

Zostało to zobra­zo­wa­ne na dia­gra­mie poniżej:

Rys. Struktura mode­li zgod­nie z MDA.

Proces realizacji potrzeb przedsiębiorstwa

Proces reali­za­cji potrzeb przed­się­bior­stwa (orga­ni­za­cji) jest ini­cjo­wa­ny stwier­dze­niem owej potrze­by (wyma­ga­na usłu­ga, przed­miot, inne) a koń­czy się roz­li­cze­niem jej reali­za­cji (dostar­cze­nia). Standardowy pro­ces świad­cze­nia usłu­gi lub dostar­cze­nia pro­duk­tu jest opi­sa­ny w Kodeksie Cywilnym5 (zle­ce­nie lub dzie­ło). Co do zasa­dy więc, na pew­nym okre­ślo­nym pozio­mie szcze­gó­ło­wo­ści, pro­ces ten jest moż­li­wy do opi­sa­nia bez jakich­kol­wiek kon­sul­ta­cji z kim­kol­wiek, treść usta­wy wystarczy.

Opis pro­ce­su: Pojawianie się potrze­by skut­ku­je opra­co­wa­niem zapy­ta­nia ofer­to­we­go (opis przed­mio­tu zamó­wie­nia jakim może być usłu­ga lub pro­dukt). Z regu­ły przy­bie­ra for­mę Zapytania ofer­to­we­go. Zapytanie takie prze­ka­zy­wa­ne jest poten­cjal­ne­mu dostaw­cy, któ­ry opra­co­wu­je ofer­tę na reali­za­cję tego co opi­sa­no w Zapytaniu. Oferta taka jest ana­li­zo­wa­na, jeże­li zosta­nie przy­ję­ta, sta­je się umo­wą pomię­dzy Nabywcą a Dostawcą. Umowa ta sta­no­wi pod­sta­wę Realizacji zamó­wie­nia (jakim jest zaak­cep­to­wa­na ofer­ta). Po zre­ali­zo­wa­niu Zamówienia Dostawca zgła­sza goto­wość prze­ka­za­na przed­mio­tu zamó­wie­nia, nastę­pu­je odbiór. Po odbio­rze jest wysta­wia­na fak­tu­ra na kwo­tę wska­za­ną w Ofercie, w okre­ślo­nym ter­mi­nie ma miej­sce płat­ność. Zamówienie jest zre­ali­zo­wa­ne i rozliczone.

Opisane aktyw­no­ści są uza­leż­nio­ne od okre­ślo­nych ter­mi­nów. Biorąc pod uwa­gę fakt, że udział bio­rą w tym pro­ce­sie dwa pod­mio­ty, a całość jest syn­chro­ni­zo­wa­na ter­mi­na­mi (muszą one być usta­la­ne) pro­ces ten moż­na opi­sać takim modelem:

Rys. Proces reali­za­cji potrze­by w orga­ni­za­cji. Notacja BPMN.

Powyższy dia­gram to model ana­li­tycz­ny. Model poglą­do­wy były­by uprosz­czo­ny do aktyw­no­ści i doku­men­tów, zapew­ne były by to dwa odręb­ne pro­ste mode­le (dla Dostawcy i dla Zamawiającego).

Jak widać uwzględ­nio­no na tym mode­lu (model ana­li­tycz­ny) klu­czo­we fak­ty jaki­mi są ter­mi­ny i momen­ty dorę­cze­nia. Wszelkie deta­le poszcze­gól­nych aktyw­no­ści sta­no­wią naj­czę­ściej spe­cy­fi­kę kon­kret­nych pod­mio­tów i są opi­sa­ne pro­ce­du­ra­mi (np. pro­ce­du­ra­mi ISO z god­nie ze sto­sow­ną nor­mą). Dokumentowanie tych deta­li z uży­ciem kolej­nych, szcze­gó­ło­wych dia­gra­mów w nota­cji BPMN z regu­ły nie ma sen­su, gdyż ich adre­sa­ta­mi (recen­zen­ta­mi) byli by (są) wyko­naw­cy tych prac, a Ci raczej bez pro­ble­mu posłu­gu­ją się pro­ce­du­ra­mi w typo­wej posta­ci zna­nej z norm (testy), a nie dia­gra­ma­mi BPMN. Umieszczanie dodat­ko­wych deta­li wprost na tym dia­gra­mie dopro­wa­dzi do powsta­nia mon­stru­al­ne­go arku­sza, trud­ne­go w użyciu.

Na mode­lach ana­li­tycz­nych posłu­gu­je­my dwo­ma klu­czo­wy­mi poję­cia­mi (BPMN, Annex C Glossary1):

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.

Atomowym zada­niem, sta­no­wią­cym abs­trak­cję całej aktyw­no­ści biz­ne­so­wej pro­wa­dzą­cej do osią­gnię­cia celu tej pra­cy, jest aktyw­ność two­rzą­ca okre­ślo­ny pro­dukt, mode­lo­wa­ny w BPMN jako DataObject (nota­cja BPMN jest opar­ta na zało­że­niu, że wszel­kie efek­ty pra­cy są doku­men­to­wa­ne). Innymi sło­wy nie umiesz­cza­my na mode­lach pro­ce­sów deta­licz­nych skła­do­wych zadań sta­no­wią­cych ele­men­ty pro­ce­du­ry danej aktyw­no­ści. Procedury mode­lu­je­my na osob­nych dia­gra­mach lub po pro­stu opi­su­je­my tek­stem w odręb­nej doku­men­ta­cji i powo­łu­je­my się na nie.

Co do zasa­dy na mode­lach ana­li­tycz­nych sto­su­je­my pod­sta­wo­wy, mini­mal­ny zestaw sym­bo­li opi­sa­ny w spe­cy­fi­ka­cji, co gwa­ran­tu­je ich czy­tel­ność i zro­zu­mia­łość przez typo­we­go adre­sa­ta jakim jest oso­ba, któ­rej pra­cę opi­sa­no. Korzystanie z roz­sze­rzo­ne­go zesta­wu sym­bo­li (np. sym­bo­le deta­licz­nych zadań z iko­na­mi w lewym gór­nym roku, dodat­ko­we zda­rze­nia itp.) nie ma sen­su na pozio­mie mode­li ana­li­tycz­nych, gdyż sym­bo­le te powsta­ły dla mode­li wyko­ny­wal­nych, prze­cięt­ny adre­sat doku­men­ta­cji ana­li­tycz­nej nie pora­dzi sobie z ich inter­pre­ta­cją. W efek­cie po pro­stu utra­ci­my komu­ni­ka­cję w pro­jek­cie, co jest nie­ste­ty bar­dzo czę­stym zja­wi­skiem i przy­czy­ną więk­szo­ści pro­ble­mów w projektach.

Podsumowanie

Na począt­ko­wym, biz­ne­so­wym, eta­pie pro­jek­tów ana­li­tycz­nych celem doku­men­ta­cji pro­ce­sów biz­ne­so­wych jest opi­sa­nie mecha­ni­zmu dzia­ła­nia orga­ni­za­cji bez zbęd­nych deta­li (te zmie­nia­ją się dość czę­sto). Jeżeli doku­men­ta­cja pro­ce­sów biz­ne­so­wych wyma­ga aktu­ali­za­cji czę­ściej niż raz w roku (a lepiej raz na pięć lat) jest to sygnał, że jest to zła, zbyt szcze­gó­ło­wa dokumentacja.

Literatura nauko­wa jest peł­na opra­co­wań wska­zu­ją­cych, że pro­ce­sy biz­ne­so­we i logi­ka biz­ne­so­wa to odręb­ne obsza­ry opi­su i mode­lo­wa­nia. Notacja BPMN słu­ży do mode­lo­wa­nia pro­ce­sów. Logikę biz­ne­so­wą opi­su­je­my z uży­ciem reguł biz­ne­so­wych3, tablic decy­zyj­nych (patrz arty­kuł SBVR…), tu jeden z wie­lu przy­kła­dów takich komen­ta­rzy:6.

Model pro­ce­sów biz­ne­so­wych jest czę­sto, w lite­ra­tu­rze przed­mio­tu, nazy­wa­ny mode­lem wewnętrz­ne­go łań­cu­cha war­to­ści, a nie raz po pro­stu wewnętrz­ną stra­te­gią reali­za­cji celów ryn­ko­wych. Skoro jest to stra­te­gia, to nie powin­na się ona czę­sto zmie­niać. W powyż­szym mode­lu, uszcze­gó­ło­wie­nia może wyma­gań aktyw­ność reali­za­cji zamó­wie­nia, gdyż w zależ­no­ści od pod­mio­tu, może to być reali­za­cja nie­try­wial­nej usłu­gi lub wytwo­rze­nia pro­duk­tu. Była by to tak zwa­na dekom­po­zy­cja i powsta­nie dru­gi poziom szcze­gó­ło­wo­ści. Pozostałe aktyw­no­ści to two­rze­nie okre­ślo­nych doku­men­tów, a spo­sób ich powsta­wa­nia jest okre­ślo­ny pro­ce­du­rą i tym jakie pola zawie­ra dana for­mat­ka DataObject. Ten poziom szcze­gó­łów opi­su­je­my słow­ni­kiem i regu­ła­mi biz­ne­so­wy­mi (SBVR3).

Biorąc pod uwa­gę fakt, że ser­we­ry BPMS są bar­dzo rzad­ko wyko­rzy­sty­wa­ne, dia­gra­my BPMN na pozio­mie com­mon exe­cu­ta­ble prak­tycz­nie nie są two­rzo­ne. Jeżeli celem two­rze­nia mode­li pro­ce­sów biz­ne­so­wych jest ana­li­za przed­wdro­że­nio­wa, po mode­lu ana­li­tycz­nym powsta­je umo­wa w posta­ci dia­gra­mu Przypadków Użycia. Przypadek uży­cia (patrz arty­kuł Transformacja…) to odpo­wied­nik ato­mo­wej aktyw­no­ści. Innymi sło­wy Przypadki Użycia (UML), jako usłu­gi apli­ka­cyj­ne, wspie­ra­ją okre­ślo­ne aktyw­no­ści (a kon­kret­nie powsta­wa­nie lub prze­twa­rza­nie kon­kret­nych doku­men­tów mode­lo­wa­nych w BPMN jako obiek­ty DataObject), co opi­sa­no na pierw­szym diagramie.

Faktura. Diagram pro­ce­su biz­ne­so­we­go poka­zu­je tak­że, że fak­tu­ra jako doku­ment, nie jest zobo­wią­za­niem. Zobowiązaniem Dostawcy jest zawar­ta umo­wa na dosta­wę a zobo­wią­za­niem Nabywcy jest płat­ność po otrzy­ma­niu przed­mio­tu zamó­wie­nia. Zobowiązanie Nabywcy powsta­je dopie­ro po (z regu­ły pisem­nym) ode­bra­niu przed­mio­tu zamó­wie­nia, fak­tu­ra jest wyłącz­nie tak zwa­nym dowo­dem księ­go­wym, czy­li doku­men­tem stwier­dza­ją­cy jakie kwo­ty zaksięgować.

________________________________
1.
About the Business Process Model And Notation Specification Version 2.0.2. OMG​.org. https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/. Published January 13, 2014. Accessed February 10, 2019.
2.
MDA Specifications | Object Management Group. https://​www​.omg​.org/​m​d​a​/​s​p​e​c​s​.​htm. Published June 1, 2014. Accessed February 11, 2019.
3.
About the Semantics Of Business Vocabulary and Rules Specification Version 1.4. OMG​.org. https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/. Published May 1, 2017. Accessed February 11, 2019.
4.
About the Unified Modeling Language Specification Version 2.5.1. OMG​.org. https://​www​.omg​.org/​s​p​e​c​/​U​ML/. Published December 1, 2017. Accessed February 11, 2019.
6.
Domain-Specific Conceptual Modeling Concepts, Methods and Tools, Herausgeber: Karagiannis, Dimitris, Mayr, Heinrich C., Mylopoulos, John (Eds.), ISBN 978 – 3‑319 – 39417‑6, str. 405.

Procesy biznesowe a procedury

Dodaj komentarz

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” (Elektroniczna gospo­dar­ka nr 4/2015, plik pdf).

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

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

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

Polecam cie­ka­wy arty­kuł na temat defi­ni­cji pro­ce­sów, w szcze­gól­no­ści Procesu Biznesowego. Zestawiono ze sobą roż­ne defi­ni­cje na prze­strze­ni ostat­nich nie­mal 20 lat. Najbardziej podo­ba mi się pro­sto­ta: ?a busi­ness pro­cess is a series of steps desi­gned to pro­du­ce a pro­duct or servi­ce? (Szczegóły:" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">pro­ces biz­ne­so­wy to Szczegóły:" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">sekwen­cja dzia­łań zapro­jek­to­wa­nych w celu wytwo­rze­nia pro­duk­tu lub Szczegóły:" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">usłu­gi).

Jeśli uzna­my, że Szczegóły:

" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">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 Szczegóły:
" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">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ą: Szczegóły:" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">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 SBVR3).

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­ki5. 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.

ele­men­tar­ny pro­ces biz­ne­so­wy to okre­ślo­ne zada­nie wraz z jego pro­duk­tem, mogą one two­rzyć łań­cu­chy pro­ce­sów poka­za­ne jako ich mapy (mode­le)

(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

Szczegóły:">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­we7:

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?

regu­ła

1. ?zasa­da postę­po­wa­nia usta­lo­na przez kogoś lub przy­ję­ta na mocy zwyczaju?
Zgodnie z zasa­dą logi­ki zdań (i cech popraw­ne­go słow­ni­ka), mówią­cą że zastą­pie­nie poję­cia w zda­niu jego defi­ni­cją nie może zmie­nić sen­su całe­go zda­nia otrzymamy:
Procedura: okre­ślo­ne zasa­dy postę­po­wa­nia, usta­lo­ne przez kogoś, w jakiejś spra­wie, zwy­kle o cha­rak­te­rze urzę­do­wym lub prawnym

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?
Otrzymamy:
Procedura: okre­ślo­ne pra­wa rzą­dzą­ce postę­po­wa­niem, usta­lo­ne przez kogoś, w jakiejś spra­wie, zwy­kle o cha­rak­te­rze urzę­do­wym lub prawnym

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ść4.

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, 

pro­ce­du­ra to spe­cy­fi­ka­cja reali­za­cji (postę­po­wa­nia w ramach) okre­ślo­nej aktywności

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:

(źr.: Jarosław Żeliński, mate­ria­ły kon­fe­ren­cyj­ne) Proces biz­ne­so­wy jako aktyw­no­ści i jej otoczenie.

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

poję­cie ​„pro­ces biz­ne­so­wy” to abs­trak­cja łączą­ca w sobie: aktyw­ność, jej wej­ście i wyj­ście, ogra­ni­cze­nia i regu­ły, oraz nie­zbęd­ne zasoby

(źr. Jarosław Żeliński, mate­ria­ły konferencyjne)

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 poję­cio­wy (dia­gram fak­tów, nota­cja SBVR, opra­co­wa­nie własne)

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

[2021 – 06-22] Po wie­lu pyta­niach i dys­ku­sjach, uzu­peł­ni­łem artykuł: 

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

Struktura mode­li pro­ce­sów biznesowych

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) pra­cow­ni­ków. 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. 

Źródła

Estefan, J. A. (2008). INCOSE MBSE Initiative Survey of Model-Based Systems Engineering (MBSE) Methodologies.
Gerede, C. E., Bhattacharya, K., & Su, J. (2007). Static ana­ly­sis of busi­ness arti­fact-cen­tric ope­ra­tio­nal models. IEEE International Conference on Service-Oriented Computing and Applications (SOCA’07), 133 – 140.
Nigam, A., & Caswell, N. S. (2003). Business arti­facts: An appro­ach to ope­ra­tio­nal spe­ci­fi­ca­tion. IBM Systems Journal, 42(3), 428 – 445. https://​doi​.org/​1​0​.​1​1​4​7​/​s​j​.​4​2​3​.​0​428
OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
Walden, D. D., Roedler, G. J., & Forsberg, K. (2015). INCOSE Systems Engineering Handbook Version 4: Updating the Reference for Practitioners. INCOSE International Symposium, 25(1), 678 – 686. https://​doi​.org/​1​0​.​1​0​0​2​/​j​.​2​334 – 5837.2015.00089.x
Yongchareon, S., liu, C., Yu, J., & Zhao, X. (2015). A view fra­me­work for mode­ling and chan­ge vali­da­tion of arti­fact-cen­tric inter-orga­ni­za­tio­nal busi­ness pro­ces­ses. Information Systems, 47, 51 – 81. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​s​.​2​0​1​4​.​0​7​.​004