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

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. ¹]

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

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.¹]

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 Architecture²) 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ą SBVR³ (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 UML⁴):

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:

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 Cywilnym⁵ (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:

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 Glossary¹):

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­wych³, tablic decy­zyj­nych (patrz arty­kuł SBVR…), tu jeden z wie­lu przy­kła­dów takich komen­ta­rzy:⁶.

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

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

Jarosław Żeliński

BIO: Od roku 1991 roku, nie­prze­rwa­nie, reali­zu­ję pro­jek­ty z zakre­su ana­liz i pro­jek­to­wa­nia sys­te­mów, dla urzę­dów, firm i orga­ni­za­cji. Od 1998 roku pro­wa­dzę tak­że samo­dziel­ne stu­dia i pra­ce badaw­cze z obsza­ru ana­li­zy sys­te­mo­wej i mode­lo­wa­nia (mode­le jako przed­miot badań: ORCID). Od 2005 roku, jako nie­eta­to­wy wykła­dow­ca aka­de­mic­ki, pro­wa­dzę wykła­dy i labo­ra­to­ria (onto­lo­gie i mode­lo­wa­nie sys­te­mów infor­ma­cyj­nych, aktu­al­nie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspi­cja­mi Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje bada­nia i publi­ka­cje nie mają finan­so­wa­nia z zewnątrz, jako ich autor dekla­ru­ję brak kon­flik­tu interesów.

it​-con​sul​ting​.pl/​f​i​r​m​a​-​i​t​-​c​o​n​s​u​l​t​i​n​g​-​j​a​r​o​s​l​a​w​-​z​e​l​i​n​s​k​i​/​j​a​r​o​s​l​a​w​-​z​e​l​i​n​s​ki/