Każdego roku pro­wa­dzę kil­ka, bywa że kil­ka­na­ście, szko­leń z zakre­su mode­lo­wa­nia pro­ce­sów biz­ne­so­wych z uży­ciem nota­cji BPMN. Do tego w ramach zająć jakie pro­wa­dzę na uczel­ni (stu­dia nie­sta­cjo­nar­ne) wykła­dy i labo­ra­to­ria z obsza­ru ana­liz i mode­lo­wa­nia z uży­ciem sfor­ma­li­zo­wa­nych nota­cji (UML, BPMN, SBVR). To zna­czy, że mam co roku kon­takt co naj­mniej z kil­ku­dzie­się­cio­ma oso­ba­mi zaj­mu­ją­cy­mi się prak­tycz­nym sto­so­wa­niem tych nota­cji. W ogrom­nej więk­szo­ści przy­pad­ków dostrze­gam ten sam pro­blem: brak wie­dzy i zro­zu­mie­nia poję­cia abs­trak­cji i umie­jęt­no­ści mode­lo­wa­nia war­stwy abs­trak­cyj­nej ana­li­zo­wa­ne­go podmiotu.

Tym tytu­ło­wym mitem jest teza, że zawsze moż­na uży­wać wszyst­kich dostęp­nych sym­bo­li i nale­ży two­rzyć dia­gra­my deta­licz­nie opi­su­ją­ce wszel­kie czyn­no­ści.

Na począ­tek cytat z ory­gi­nal­nej spe­cy­fi­ka­cji (Business Process Model and Notation (BPMN)
Version 2.0.2):

2.2.1 BPMN Process Types

The imple­men­ta­tions cla­iming Process Modeling Conformance MUST sup­port the fol­lo­wing BPMN packages:

• The BPMN core ele­ments, which inc­lu­de tho­se defi­ned in the Infrastructure, Foundation, Common, and Service pac­ka­ges (see Clause 8).
• Process dia­grams, which inc­lu­de the ele­ments defi­ned in the Process, Activities, Data, and Human Interaction pac­ka­ges (see Clause 10).
• Collaboration dia­grams, which inc­lu­de Pools and Message Flow (see Clause 9).
• Conversation dia­grams, which inc­lu­de Pools, Conversations, and Conversation Links (see Clause 9).

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 ConformanceClass. 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 DefenseArchitecture 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.

Mamy więc trzy typy modeli:

1. opi­so­we (descrip­ti­ve), wyko­rzy­stu­ją pod­sta­wo­we ele­men­ty nota­cji, tyl­ko ich gra­ficz­ne atry­bu­ty, poka­zu­ją pro­ce­sy na wyso­kim pozio­mie abs­trak­cji jako ich archi­tek­tu­rę (ogól­ny, abs­trak­cyj­ny prze­pływ pracy),
2. ana­li­tycz­ne (ana­ly­tic), poka­zu­ją­ce to co mode­le opi­so­we, te mode­le wyko­rzy­stu­ją już ok. poło­wy wszyst­kich zde­fi­nio­wa­nych ele­men­tów nota­cji (nadal bez ich wewnętrz­nych atry­bu­tów), słu­żą do ana­liz i mode­lo­wa­nia kon­kret­nych wzor­ców zacho­wań i pro­ce­sów, tak­że procedur,
3. wyko­ny­wal­ne (com­mon exe­cu­ta­ble), zorien­to­wa­ne na two­rze­nie deta­licz­nych mode­li, moż­li­wych do imple­men­ta­cji (uru­cho­mie­nia) w śro­do­wi­skach BPMS.

Wykonywalne ze swej natu­ry, two­rzo­ne są z uży­ciem wszyst­kich pojęć BPMN i ich atry­bu­tów. Celem ich two­rze­nia jest uru­cho­mie­nie pro­ce­sów w śro­do­wi­sku BPMS, jest pra­ca ana­lo­gicz­na do programowania.

Modele opi­so­we i ana­li­tycz­ne, to abs­trak­cyj­ne mode­le, a celem ich two­rze­nia jest udo­ku­men­to­wa­nie mecha­ni­zmów opi­su­ją­cych funk­cjo­no­wa­nie orga­ni­za­cji z per­spek­ty­wy prze­pły­wu pra­cy i powsta­ją­cych jej pro­duk­tów. Pozostaje więc powie­dzieć, że nie ma sen­su na mode­lach opi­so­wych i ana­li­tycz­nych uży­wa­nie pojęć i atry­bu­tów nie wno­szą­cych war­to­ści doda­nej do tych mode­li a prze­zna­czo­nych do two­rze­nia model wyko­ny­wal­nych. To dla­te­go na tych – ana­li­tycz­nych – mode­lach uży­wa się mak­si­mum ok. poło­wy ele­men­tów zde­fi­nio­wa­nych w nota­cji BPMN i to głów­nie te abstrakcyjne.

Typowym przy­kła­dem są zada­nia (task):

10.3.3.1 Types of Tasks
There are dif­fe­rent types of Tasks iden­ti­fied within BPMN to sepa­ra­te the types of inhe­rent beha­vior that Tasks might repre­sent. The list of Task types MAY be exten­ded along with any cor­re­spon­ding indi­ca­tors. A Task which is not fur­ther spe­ci­fied is cal­led Abstract Task (this was refer­red to as the None Task in BPMN 1.2). The nota­tion of the Abstract Task is shown in Figure 10.8.

Predefiniowane typy zadań (servi­ce task, send task, manu­al tast, itp.) to sym­bo­le repre­zen­tu­ją­ce kon­kret­ne wyko­ny­wal­ne ele­men­ty i para­me­try (atry­bu­ty) zadań na pozio­mie skryp­tów BPEL4WS czy XPDL. Stosowanie ich na opi­so­wych czy ana­li­tycz­nych mode­lach war­stwy abs­trak­cyj­nych nie ma więk­sze­go sen­su, zaciem­nia dia­gram, a u wie­lu ich adre­sa­tów pro­wo­ku­je ich intu­icyj­ne inter­pre­to­wa­nie, co dodat­ko­wo pro­wa­dzi do wie­lu nie­po­ro­zu­mień i pomy­łek. Innymi sło­wy sto­so­wa­nie na dia­gra­mach sym­bo­li prze­zna­czo­nych do inter­pre­to­wa­nia w śro­do­wi­skach BPMS (zapi­sa­ne jako BPEL4WS lub XPDL) na dia­gra­mach nie prze­zna­czo­nych do takiej inter­pre­ta­cji (opi­so­we i ana­li­tycz­ne), a tyl­ko do komu­ni­ko­wa­nia archi­tek­tu­ry pro­ce­sów lub mecha­ni­zmu dzia­ła­nia orga­ni­za­cji, po pro­tu nie ma sen­su i szkodzi.

Zjawisko nad­uży­wa­nia tych sym­bo­li jest nie­ste­ty dość powszech­ne na świe­cie, wie­lu auto­rów publi­ka­cji o sto­so­wa­niu BPMN, zwra­ca jed­nak uwa­gę na błęd­ne sto­so­wa­nia for­mal­nych nota­cji: jako biblio­te­ki (faj­nych) sym­bo­li. Notacje for­mal­ne to sfor­ma­li­zo­wa­ne sys­te­my poję­cio­we, mode­le te to nie info­gra­fi­ka pre­zen­ta­cyj­na, to języ­ki, któ­rych ele­men­ty cechu­je okre­ślo­na seman­ty­ka i syn­tak­ty­ka, któ­rych nale­ży po pro­stu prze­strze­gać, bo bez tego dia­gra­my te będą tyl­ko obraz­ka­mi a nie mode­la­mi a ich inter­pre­ta­cja będzie niejednoznaczna.

Nagminnie spo­ty­kam się z dia­gra­ma­mi podob­ny­mi do tego:

Biorąc pod uwa­gę to, że nie jest to model pro­ce­su do wyko­na­nia w śro­do­wi­sku BPMS, dia­gram jest typo­wym przy­kła­dem prze­ro­stu for­my nas tre­ścią, cze­goś co w lite­ra­tu­rze nazy­wa­ne jest ​„spa­ghet­ti-mode­lin­giem”. Myślę, że sama nazwa wyja­śnia co auto­rzy tego okre­śle­nia mie­li na myśli.

Diagramy opi­so­we i ana­li­tycz­ne repre­zen­tu­ją raczej poziom szcze­gó­ło­wo­ści jak poniżej:

Warto pamię­tać, że mode­le ana­li­tycz­ne to tak­że mode­le opi­so­we, jed­nak na tyle pre­cy­zyj­ne, że pozwa­la­ją np. na ana­li­zy moż­li­wych opty­ma­li­za­cji, ana­li­zy prze­pły­wu infor­ma­cji czy ana­li­zy wyma­gań na opro­gra­mo­wa­nie. Przykładem mode­lu opi­so­we­go jest np. ten diagram:

Source: BPM Professional: Using Extension Artefacts in BPMN Process Model

Warto pamię­tać, że sym­bol DataObject to abs­trak­cja repre­zen­tu­ją­ca okre­ślo­ny doku­ment, z regu­ły for­mu­larz. Słownik klu­czo­wych pojęć (Specyfikacja BPMN, doda­tek C) zawie­ra dwie waż­ne defi­ni­cje: ato­mic acti­vi­ty oraz busi­ness pro­cess. Proces biz­ne­so­wy to aktyw­ność (lub ich ciąg) pro­wa­dzą­ca do powsta­nia okre­ślo­ne­go biz­ne­so­we­go rezul­ta­tu. Atomowa (ele­men­tar­na) aktyw­ność to ele­ment, któ­ry nie jest już dalej dekom­po­no­wa­ny, gra­ficz­nie jest to Zadanie (Task) w nota­cji BPMN. Tak więc two­rząc na opi­so­we, a nawet ana­li­tycz­ne, mode­le pro­ce­sów biz­ne­so­wych, pod­sta­wo­wym blo­kiem kon­struk­cyj­nym jest Zadanie i Dokument jaki two­rzy (lub zmie­nia), nie ma więc sen­su ​„obraz­ko­we” opi­sy­wa­nie wypeł­nia­nia pól tego doku­men­tu w posta­ci dia­gra­mu i cią­gu zadań z warian­ta­mi na nim. Treść doku­men­tu (DataObject, w tym rygo­ry tre­ści jego pól) doku­men­tu­je się biz­ne­so­wym słow­ni­kiem pojęć i regu­ła­mi biz­ne­so­wy­mi np. war­tość upu­stu wybie­ra­my z tabli­cy pro­mo­cji, gdzie poję­cia upust i pro­mo­cja mają swo­je definicje.

Podobnie nie ma sen­su na mode­lach ana­li­tycz­nych umiesz­cza­nie ele­men­tów takich jak ​„sys­tem IT” bo mode­le opi­so­we i ana­li­tycz­ne, to mode­le biz­ne­so­we nazy­wa­ne CIM (Computation Independent Model) czy­li mode­le nie­za­leż­ne od opro­gra­mo­wa­nia (patrz OMG MDA).

O mode­lach wyko­ny­wal­nych (com­mon exe­cu­ta­ble) nie tu piszę, bo rośnie scep­ty­cyzm co do ich two­rze­nia. Dostawcy sys­te­mów BPMS (śro­do­wisk wyko­ny­wal­nych BPM) two­rzą wła­sne roz­sze­rze­nia nota­cji BPMN lub nie raz sto­su­ją wła­sne nota­cje, by moż­li­we było w peł­ni wyko­rzy­sta­nie dostar­cza­nych roz­wią­zań i uwzględ­nie­nie ich ograniczeń.

W latach 60-tych powsta­ła nota­cja IDEF0 (mode­lo­wa­nie pro­ce­sów biz­ne­so­wych do celów ana­li­tycz­nych), pod­sta­wo­wym zale­ce­niem meto­dycz­nym było tam mode­lo­wa­nie na takim pozio­mie abs­trak­cji, by poszcze­gól­ne dia­gra­my mie­ści­ły się na pozio­mo zorien­to­wa­nych kart­kach A4 i było czy­tel­ne, co gorą­co polecam.

A tu przy­kła­do­we zasto­so­wa­nie mode­lu ana­li­tycz­ne­go w nota­cji BPMN:

• tego, że zgod­nie z BPMN 2.0 moż­na do dia­gra­mów doda­wać inne elementy .…

• tego jak przejść, zgod­nie z defi­ni­cja­mi pro­ce­sów i przy­pad­ków uży­cia, od mode­lu pro­ce­su do mode­lu przy­pad­ków użycia:

Literatura

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/