Modele as-is i to-be, czy warto je robić?

Z zamia­rem napi­sa­nia tego tek­stu noszę się już od kil­ku lat i za każ­dym razem mówi­łem sobie: ok, jesz­cze tyl­ko skoń­czę ten jeden pro­jekt i zoba­czy­my czy fak­tycz­nie ma to sens”. I tak od kil­ku lat. W koń­cu jed­nak uda­ło się.

Wprowadzenie

Popularność podej­ścia do mode­li pro­ce­sów biz­ne­so­wych, pole­ga­ją­ce­go na poka­za­niu róż­ni­cy”, trwa od cza­sów popu­la­ry­za­cji re-inży­nie­rii pro­ce­sów biz­ne­so­wych (lata 90-te) . Umowy na usłu­gi, zawie­ra­ją­ce w zakre­sie opra­co­wa­nie mode­lu «as-is» i «to-be» nadal są pod­pi­sy­wa­ne. Zakładam, że decy­zje o zakre­sie pro­jek­tu to indy­wi­du­al­ne potrze­by zama­wia­ją­cych. Ja opi­szę swo­je doświad­cze­nia i wnioski.

Głównym dekla­ro­wa­nym celem two­rze­nia obu tych mode­li jest zawsze porów­na­nie sta­nu obec­ne­go i pla­no­wa­ne­go, a następ­nie zde­cy­do­wa­nie o tym «co dalej». Zakłada się, że te mode­le powin­ny poka­zać war­tość doda­ną pro­jek­to­wa­nych zmian. Pierwszy pro­blem to koniecz­ność stwo­rze­nia dwu­krot­nie więk­szej ilo­ści doku­men­ta­cji, to zaś prze­kła­da sie na czas i koszt. W kon­se­kwen­cji wdro­że­nie pla­no­wa­nej zmia­ny bar­dzo odsu­wa się w cza­sie. Wynik każ­dej pier­wot­nie wyko­na­nej ana­li­zy dez­ak­tu­ali­zu­je się wraz z upły­wem cza­su, tym szyb­ciej im wię­cej szcze­gó­łów ona zawie­ra. Wpadamy tu w «kwa­dra­tu­rę koła». W arty­ku­le Cykl życia… zapy­ta­łem: Czego ocze­ku­je biz­nes: efek­tu czy pro­duk­tu? Wyniki ana­liz i reko­men­da­cje to pro­duk­ty pra­cy ana­li­ty­ka, wdro­żo­ne zmia­ny orga­ni­za­cyj­ne czy opro­gra­mo­wa­nie to tak­że pro­duk­ty. Te zawsze moż­na kupić i mieć. A czym jest efekt? Np. zwięk­sze­niem efek­tyw­no­ści… A to ozna­cza, że etap ana­li­zy i potem wdra­ża­nia roz­wią­za­nia, tak­że powi­nien cecho­wać się efektywnością!

W cza­sach zmian ryn­ko­wych zacho­dzą­cych w okre­sie poni­żej roku, każ­da stra­ta cza­su jest szko­dą, dwu­krot­ne wydłu­że­nie pro­ce­su ana­li­zy i opra­co­wa­nia reko­men­da­cji szczególnie.

Więc jak, sko­ro nie dwa mode­le: «as-is» i «to-be»?

Metody

Tu posłu­żę się pro­sty­mi meto­da­mi czy­li sche­ma­ty blo­ko­we i rzad­ko sto­so­wa­na a bar­dzo sku­tecz­na: ide­ali­za­cja . Nawiążę tak­że do mało popu­lar­nej a cie­ka­wej i bar­dzo sku­tecz­nej meto­dy­ki uspraw­nia­nia orga­ni­za­cji, tak­że opar­tej na ide­ali­za­cji, opi­sa­nej przez Ackof’a .

Rezultaty

Kluczem sku­tecz­ne­go pla­no­wa­nia roz­wo­ju orga­ni­za­cji jest stu­dium wyko­nal­no­ści pla­no­wa­nych zmian, a do tego bar­dzo przy­dat­na jest ide­ali­za­cja jako metoda.

Wytyczenie kierunku działań

Każda orga­ni­za­cja kie­dyś powsta­ła i od tego momen­tu zaczy­na żyć (co – uwa­ga – nie jest toż­sa­me z jej roz­wo­jem). Jeżeli podej­mu­je­my decy­zję o wpro­wa­dza­niu zmia­ny (a na począt­ku raczej tyl­ko dekla­ru­je­my taki zamiar) pierw­szy­mi rze­cza­mi jakie nale­ży okre­ślić są: cel i kie­ru­nek zmian. Jak już to wie­my, kolej­nym kro­kiem jest okre­śle­nie tego co i w jakim cza­sie chce­my osią­gnąć. Pamiętajmy, że ide­ał może nie być osią­gal­ny, jest jed­nak zawsze dosko­na­łym wyznacz­ni­kiem kie­run­ku (podob­nie jak rekor­dy olim­pij­skie dla spor­tow­ców, któ­rzy wie­dzą, że nigdy ich nie prze­kro­czą, ale mimo to wie­dzą co i po co tre­no­wać). Dlaczego? Bo klu­czo­wą wie­dzą jest zawsze to, ile mnie dzie­li od ide­ału i czy jest sens go osią­gać, bo roz­wią­za­nia powin­ny być wystar­cza­ją­cą dobre, a nie zawsze naj­lep­sze (co naj­wy­żej moż­li­wie najlepsze). 

Projektowanie ide­ału jest takim spo­so­bem myśle­nia o zmia­nie, któ­ry moż­na przed­sta­wić w pro­sty spo­sób: w roz­wią­zy­wa­niu pro­ble­mów, prak­tycz­nie dowol­ne­go rodza­ju, moż­na uzy­skać naj­lep­sze wyni­ki dzię­ki wyobra­że­niu sobie ide­al­ne­go roz­wią­za­nia, a następ­nie cof­nię­ciu się aż do miej­sca, w któ­rym znaj­du­jesz się w chwi­li obec­nej. Dzięki temu unik­niesz uro­jo­nych przez sie­bie prze­szkód, zanim jesz­cze w ogó­le poj­miesz, jak osią­gnąć ideał.

Poniższy dia­gram poka­zu­je klu­czo­we punk­ty planu:

I teraz: Czy dokład­ny opis sta­nu aktu­al­ne­go jest potrzeb­ny, sko­ro klu­czo­we pyta­nie zawsze brzmi: co zmie­nić? Sprawdźmy. 

Wyobraźmy sobie, że robi­my porząd­ki w sta­rej piw­ni­cy a celem jest pozby­cie się rze­czy nie­po­trzeb­nych. Identyczną sytu­ację mamy z ple­ca­kiem, gdy dość regu­lar­nie wyjeż­dża­my np. w góry, nie chce­my jed­nak nosić zbęd­nych rze­czy. Są dwa moż­li­we podej­ścia do tego zadania:

  1. prze­glą­da­my wszyst­ko i zasta­na­wia­my się cze­go się pozbyć,
  2. odkła­da­my wszyst­ko na bok, i wybie­ra­my tyl­ko to o czym wie­my, że na pew­no nadal będzie potrzeb­ne i wie­my do cze­go, resz­ta zosta­je (z piw­ni­cy: wyrzucona). 

Można pró­bo­wać bro­nić każ­dej z tych metod, pro­blem w tym, że pierw­sza powo­du­je (prak­ty­ka to poka­zu­je), że zawsze zosta­je pra­wie wszyst­ko, a przy­by­wa nowego. 

Modelowanie organizacji

Natura czło­wie­ka to emo­cjo­nal­ne przy­wią­za­nie do tego co się już posia­da, a z natu­rą (emo­cje) trud­no wal­czyć. Dlatego war­to cza­sa­mi ją wspo­ma­gać (z tego same­go powo­du nie nale­ży same­mu nego­cjo­wać tego co jest dla nas bar­dzo waż­ne, a jak musi­my to robić sami, to nale­ży zre­zy­gno­wać z nego­cja­cji i z góry usta­lić korzyst­ne warun­ki lub zre­zy­gno­wać ).

Popatrzmy na zna­ny, nie tyl­ko moim czy­tel­ni­kom, od lat diagram:

(źr. http://​www​.bptrend​sas​so​cia​tes​.com/)

Pokazuje on trzy pod­sta­wo­we pozio­my opi­su (doku­men­to­wa­nia) orga­ni­za­cji. Najwyższy poziom to model biz­ne­so­wy, czy­li opis stra­te­gii (z regu­ły mie­ści się na jed­nej stro­nie maszy­no­pi­su). Najniższy to szcze­gó­ło­we opi­sy wyma­ga­nych kom­pe­ten­cji, zakre­sy obo­wiąz­ków, instruk­cje sta­no­wi­sko­we, pro­ce­du­ry i zarzą­dze­nia, instruk­cje itp. Te dwa rodza­je opi­sów ma prak­tycz­nie każ­da orga­ni­za­cja bo nawet, jeże­li nie wyma­ga tego pra­wo, to wyma­ga­ją tego pod­sta­wy zarządzania. 

Środkowa war­stwa to coś, cze­go więk­szość orga­ni­za­cji nadal nie ma, bo uwa­ża­ją że nie jest to potrzeb­ne do bie­żą­ce­go, ope­ra­cyj­ne­go zarzą­dza­nia. Czym jest ten środ­ko­wy model? To jest tak zwa­ny wewnętrz­ny łań­cuch war­to­ści orga­ni­za­cji, czy­li opis tego jak powsta­ją jej pro­duk­ty i usłu­gi, i jaką poszcze­gól­ne pra­ce wno­szą war­tość doda­ną do cało­ści . Dokumentujemy go jako Model (mapa) Procesów Biznesowych, jest to abs­trak­cyj­ny model, pozba­wio­ny szcze­gó­łów, poka­zu­je to «co» robi­my i po co a nie «jak». Warto tu zwró­cić uwa­gę na waż­ną rzecz: 

Nie ma żad­ne­go sen­su odwzo­ro­wy­wa­nie na sche­ma­tach blo­ko­wych szcze­gó­łów trze­ciej naj­niż­szej war­stwy, bo powsta­ją mon­stru­al­ne licz­by dia­gra­mów, któ­re nicze­go nie wno­szą do pro­jek­tu, bo ich przy­dat­ność jest co naj­mniej wątpliwa.

To «jak» to robi­my zawie­ra posia­da­na już doku­men­ta­cja w war­stwie trze­ciej, naj­niż­szej; nie ma więc sen­su powtór­ne jej doku­men­to­wa­nie na dia­gra­mach, powo­łu­je­my się na nią mode­lu­jąc pro­ce­sy (wię­cej w arty­ku­le Analiza, wyma­ga­nia i uspraw­nia­nie orga­ni­za­cji).

Czy war­to mieć taki model pro­ce­sów? Owszem, bo podej­mo­wa­nie decy­zji o zmia­nach bez takie­go mode­lu to lote­ria. Jednak jeże­li model jest zbyt szcze­gó­ło­wy (patrz powyż­sza uwa­ga), to nie tyl­ko opra­co­wa­nie go jest kosz­tow­ne i trwa dłu­go, ale zapo­zna­nie się z nim zaj­mu­je zbyt dużo cza­su, więc nikt tego nie robi. W efek­cie decy­zje są podej­mo­wa­ne tak, jak by tego mode­lu nie było. Kiedyś decy­zje o zmia­nach podej­mo­wa­no rzad­ko i każ­do­ra­zo­we, poprze­dza­ją­ce te decy­zje dłu­gie ana­li­zy, mia­ły sens. Obecnie decy­zje takie podej­muj­my nie raz «znie­nac­ka”, i nawet jeże­li nie są czę­ste, to nie ma cza­su na poprze­dza­nie ich ana­li­za­mi, a bez ana­li­zy skut­ków decy­zje ope­ra­cyj­ne są lote­rią. W efek­cie utrzy­my­wa­nie aktu­al­ne­go, ale bez zbęd­nych deta­li, mode­lu orga­ni­za­cji jest moż­li­we, opła­cal­ne i ma ogrom­ne zna­cze­nie (patrz Audyt orga­ni­za­cji, model Architektury Korporacyjnej).

Poprawnie opra­co­wa­ne mode­le (mapy) pro­ce­sów biz­ne­so­wych pozwa­la­ją zro­zu­mieć orga­ni­za­cję i prze­wi­dy­wać efek­ty pla­no­wa­nych zmian. 

(patrz: Audyt orga­ni­za­cji, pod­no­sze­nie efek­tyw­no­ści)

Wdrażanie zmian

Popatrzmy na poniż­szy diagram:

(J. Żeliński, 2012)

Rozwój orga­ni­za­cji, poza bar­dzo rzad­ki­mi przy­pad­ka­mi, nie jest (nie powi­nien być) rewo­lu­cją. Pisali o tym nie raz kry­ty­cy przy­wo­ły­wa­nej na począt­ku Radykalnej Reorganizacji Procesów Biznesowych (mało któ­ra orga­ni­za­cja ją prze­trwa­ła) . Więc co zmie­niać i jak? Powyższy dia­gram mówi, że gene­ral­nie zmia­ny doty­czą naj­niż­szej war­stwy, ale żeby wie­dzieć gdzie jest jej gra­ni­ca, trze­ba mieć udo­ku­men­to­wa­ną tak­że tę środ­ko­wą. Zmiany pro­ce­sów biz­ne­so­wych są rzad­kie, doty­czą poje­dyn­czych pro­ce­sów, i nie są to rewolucje.

Przejście od lewej do pra­wej stro­ny to nasz ple­cak w góry: albo prze­glą­da­my wszyst­ko i pró­bu­je­my odrzu­cać nad­miar, albo wybie­ra­my tyl­ko to, o czym wie­my że będzie potrzeb­ne. Skąd mamy wie­dzieć, co będzie potrzeb­ne? Jeżeli wyko­na­my model pro­ce­sów biz­ne­so­wych jako model wewnętrz­ne­go łań­cu­cha war­to­ści, to zna­czy, że dosko­na­le wie­my co i po co robi­my, pozo­sta­je jedy­nie okre­śle­nie tego jak. I tu wła­śnie poja­wia się moment, w któ­rym okre­śla­my jak coś zro­bić naj­le­piej, a potem patrzy­my czy to jak to teraz robi­my jest takie jak być powin­no. Jeżeli tak, kon­ty­nu­uje­my (zabie­ra­my to ze sobą w kolej­ną podróż), jeże­li nie – zarzu­ca­my i sta­je sie to wyma­ga­niem, wobec nowe­go roz­wią­za­nia (bez roz­pa­mię­ty­wa­nia histo­rii, sen­ty­men­ty nie­ste­ty znisz­czy­ły już nie­jed­ną firmę).

W pro­jek­cie ana­li­zy i uspraw­nie­nia powsta­ją więc:

  1. Dokumentacja ryn­ko­we­go mode­lu biz­ne­so­we­go, czy­li opis stra­te­gii (w tym tak­że misja i wizja organizacji).
  2. Model moty­wa­cji biz­ne­so­wej pla­no­wa­nych zmian (wyty­cza­my kierunek).
  3. Model pro­ce­sów biz­ne­so­wych jako model wewnętrz­ne­go łań­cu­cha war­to­ści (to jest kil­ka­na­ście dia­gra­mów a nie kilkaset!).
  4. Analiza prze­twa­rza­nych infor­ma­cji i jej stan­da­ry­za­cja (ana­li­za doku­men­tów, biz­ne­so­wy słow­nik pojęć, regu­ły biz­ne­so­we, stan­da­ry­za­cja tre­ści doku­men­tów, są to pro­duk­ty aktyw­no­ści na mode­lach procesów).
  5. Wymagania biz­ne­so­we (czym ma się cha­rak­te­ry­zo­wać nowe rozwiązanie).
  6. Opis (model) roz­wią­za­nia, sta­no­wią­cy sobą tak na praw­dę wyma­ga­nie dla jego dostaw­cy (wyko­naw­cy).

Jeżeli pozbę­dzie­my sie nad­mia­ro­wych, o wąt­pli­wej war­to­ści doda­nej dla tego pro­jek­tu, prac, to całość trwa od dwóch do sze­ściu mie­się­cy, zależ­nie od wiel­ko­ści orga­ni­za­cji. W dużych orga­ni­za­cjach łatwo jest podzie­lić mode­le na dzie­dzi­no­we obsza­ry, w któ­rych wdra­ża się lokal­ne samo­dziel­ne roz­wią­za­nia, wystar­czy zapla­no­wać ich inte­gra­cję. Mając model infor­ma­cyj­ny (doku­men­ty i ich wza­jem­ne zależ­no­ści) nie jest to trud­ne. Wbrew temu co mówią, dostaw­cy kom­plek­so­wych mono­li­tycz­nych sys­te­mów, nie jest żad­nym ryzy­kiem to że kil­ka dzia­łów prze­twa­rza te same dane, waż­ne jest zagwa­ran­to­wa­nie stan­da­ry­za­cji tych danych oraz ich nośni­ków czy­li doku­men­tów . Jeżeli bez pro­ble­mu mogą współ­pra­co­wać ze sobą dwie odręb­ne fir­my, to podob­nie mogą to robić wydzia­ły tej samej fir­my, tym bar­dziej że w dowol­nym momen­cie taki wydział może zostać wydzie­lo­ny jako osob­ny pod­miot, i po tej prze­mia­nie to wszyst­ko nadal dalej dzia­łać. Włączenie do wnę­trza orga­ni­za­cji innej fir­my podob­nie, nigdy nie powin­na to być rewo­lu­cja infor­ma­tycz­na i wymia­na wszystkiego. 

Podsumowanie

Praktyka poka­zu­je, że powyż­sze spraw­dza sie dosko­na­le. Rezygnacja z deta­licz­nych mode­li as-is nie przy­no­si stra­ty jako­ści pro­jek­tu, nie pod­no­si też jego ryzy­ka, a zna­ko­mi­cie skra­ca czas i tym samym obni­ża koszt tego eta­pu pra­cy (mode­lo­wa­nie pro­ce­sów). Owszem, nie raz na począt­ku sły­sza­łem od spon­so­ra pro­jek­tu: chce­my zoba­czyć te zmia­ny, chce­my widzieć róż­ni­ce”. Jednak ofer­ta wyko­na­nia takiej usłu­gi w dwóch warian­tach: zawie­ra­ją­ca model «as-is» i bez tego mode­lu (ofer­ta fixed-pri­ce bo innych niż umo­wa o dzie­ło na tym eta­pie od lat nie skła­dam: klien­ci chcą znać kosz­ty przed a nie po pro­jek­cie), od kil­ku lat w 100% przy­pad­ków koń­czy się rezy­gna­cją z doku­men­to­wa­nia deta­li i mode­li pro­ce­sów as-is”. Więcej w arty­ku­le Audyt orga­ni­za­cji, pod­no­sze­nie efek­tyw­no­ści.

Uważam, że w cza­sach gdy czas to pie­niądz”, a czas ten liczy­my obec­nie w tygo­dniach a nie w latach, pro­jek­ty ana­li­tycz­ne trwa­ją­ce ponad kwar­tał (czy pół roku w bar­dzo dużej orga­ni­za­cji) są stra­tą cza­su i środków. 

Kluczowe pyta­nie na koniec: 

Kiedy powsta­ją szcze­gó­ły nowe­go roz­wią­za­nia? W toku pro­jek­to­wa­nia i wdrożenia…

…i jest to bar­dzo bez­piecz­ne i zara­zem efek­tyw­ne, bo mając archi­tek­tu­rę roz­wią­za­nia (wewnętrz­ny model łań­cu­cha war­to­ści i model archi­tek­tu­ry roz­wią­za­nia) wie­my «co» ma powstać, pozo­sta­je już tyl­ko na bie­żą­co podej­mo­wać decy­zje «jak» ma to wyglądać. 

Problemy, w któ­rych roz­wią­za­niu mają pomóc budo­wa­ne zło­żo­ne sys­te­my są zwy­kle ?pro­ble­ma­mi zło­śli­wy­mi?. ?Problem zło­śli­wy? to taki skom­pli­ko­wa­ny pro­blem, w któ­rym jest tak wie­le powią­za­nych ze sobą bytów, że nie ist­nie­je jego osta­tecz­na spe­cy­fi­ka­cja. Prawdziwy cha­rak­ter pro­ble­mu obja­wia się dopie­ro w mia­rę opra­co­wy­wa­nia rozwiązania.

Sprawując ze swo­jej stro­ny nad­zór nad dostaw­cą roz­wią­za­nia, jego nabyw­ca panu­je nad wszyst­kim. Mogę tyl­ko pod­su­mo­wać to tak: to co napi­sał Ackoff 15 lat temu i ponad 20 lat temu : podej­ście takie spraw­dza sie doskonale. 

(tak reali­zo­wa­ne były moje pro­jek­ty dla wie­lu małych firm, kil­ku insty­tu­cji publicz­nych, w tym Kancelarii Senatu i Żandarmerii Wojskowej, a tak­że dla KGHM SA)

Źródła

Cohen, H. (2006). Wynegocjuj to! (T. Misiorek, Trans.). Wydawnictwo Helion.
McMullin, E. (1985). Galilean ide­ali­za­tion. Studies in History and Philosophy of Science Part A, 16(3), 247 – 273. https://​doi​.org/​1​0​.​1​0​1​6​/​0​039 – 3681(85)90003 – 2
Ackoff, R. L., Magidson, J., & Addison, H. J. (2006). Idealized design: cre­ating an organization’s futu­re. Wharton School Pub.
Rittel, H. W. J., & Webber, M. M. (2014). Dylematy ogól­nej teo­rii pla­no­wa­nia. Zarządzanie publicz­ne, 1, 13.
Weisberg, M. (2007). Three Kinds of Idealization: The Journal of Philosophy, 104(12), 639 – 659. https://​doi​.org/​1​0​.​5​8​4​0​/​j​p​h​i​l​2​0​0​7​1​0​4​1​240
Rittel, H. W. J., & Webber, M. M. (1973). Dilemmas in a gene­ral the­ory of plan­ning. Policy Sciences, 4(2), 155 – 169. https://​doi​.org/​1​0​.​1​0​0​7​/​B​F​0​1​4​0​5​730
Coffey, B. (2017). Unpacking the impli­ca­tions of label­ling envi­ron­men­tal issu­es as wic­ked pro­blems.’ 16.
Subbotin A.L. (1970). Idealization as a Method of Scientific Knowledge. In Tavanec P.V. (eds) Problems of the Logic of Scientific Knowledge. Synthese Library.
Ackoff, R. L. (1999). From data to wis­dom. In Ackoff’s Best (pp. 170 – 172). John Wiley & Sons.
Porter, M. E. (1998). Competitive advan­ta­ge: cre­ating and susta­ining supe­rior per­for­man­ce: with a new intro­duc­tion (1st Free Press ed). Free Press.
Rummler, G. A., & Brache, A. P. (2000). Podnoszenie efek­tyw­no­ści orga­ni­za­cji (Ł. Ludwicki, Trans.). Polskie Wydawnictwo Ekonomiczne.
Rupper, P., & Muler, R. (1996). Process Reengineering (T. Soróbka, Trans.). ASTRUM.

Czym nie jest poprawna analiza i modelowanie procesów

Wstęp

Jako ana­li­tyk i pro­jek­tant, w pro­jek­tach któ­re nad­zo­ru­ję to ja jestem auto­rem doku­men­tów, moje pro­ble­my to raczej tłu­ma­cze­nie deve­lo­pe­rom tre­ści tych doku­men­tów (mimo tego, że każ­dy(!) deve­lo­per skła­da­jąc ofer­tę, oświad­cza że zna i posłu­gu­je się nota­cja­mi BPMN ?(?Business Process Model and Notation,? 2014)? i UML ?(?Unified Modeling Language,? 2017)?, prak­ty­ka jed­nak poka­zu­je, że bar­dzo czę­sto kłamią).

Jako wykła­dow­ca aka­de­mic­ki, oso­ba pro­wa­dzą­ca bada­nia nad two­rze­niem i sto­so­wa­niem mode­li, a tak­że jako oso­ba audy­tu­ją­ca cudze doku­men­ty, lub udzie­la­ją­ca po pro­stu kon­sul­ta­cji stu­den­tom innych uczel­ni, mam poważ­ny pro­blem z argu­men­ta­mi a tu (jakaś publi­ka­cja) jest tak napi­sa­ne”. Przywykłem do tego, że tam fak­tycz­nie jest tak napi­sa­ne”. Problem poja­wia się gdy oka­zu­je się, że auto­rem tego co tak jest napi­sa­ne” jest uty­tu­ło­wa­ny pra­cow­nik uczel­ni lub uty­tu­ło­wa­na fir­ma doradcza. 

Ten arty­kuł będzie o niskiej jako­ści nie­któ­rych doku­men­tów. W czym pro­blem z kiep­skiej jako­ści ana­li­za­mi i mode­la­mi? W tym, że ich auto­rzy podej­mu­ją pró­by doda­wa­nia nowych sym­bo­li do nota­cji, psu­jąc spój­ność i jed­no­znacz­ność dia­gra­mów, sto­su­ją sym­bo­le nota­cji nie­zgod­nie z nada­ny­mi im zna­cze­nia­mi, czy­li łamią zasa­dy seman­ty­ki i syn­tak­ty­ki nota­cji, albo łamią zasa­dę wyłą­czo­ne­go środ­ka mówią­cą w uprosz­cze­niu, że jeże­li coś jest czymś to zna­czy, że nie jest już niczym innym (np. jeże­li coś jest zda­rze­niem to na pew­no nie jest ani czyn­no­ścią, ani dany­mi, ani regu­łą decy­zyj­ną).?(Żeliński, 2011)?

W cią­gu dosłow­nie dwóch dni, wpa­dły mi w ręce trzy, dostęp­ne publicz­nie, opracowania:

  • doc.1. Analiza pro­ce­sów biz­ne­so­wych pew­ne­go urzę­du, wyko­na­na przez dużą, zna­ną fir­mą dorad­czą, jest to załącz­nik do SIWZ (publi­ka­cja na BIP tego urzę­du), opra­co­wa­nie z 2012 roku,
  • doc.2. Wynik i opis mapo­wa­nia pro­ce­sów biz­ne­so­wych, któ­re­go celem było przy­go­to­wa­nie do wdro­że­nia zin­te­gro­wa­ne­go sys­te­mu zarzą­dza­nia w pew­nej fir­mie, publi­ka­cja nauko­wa oso­by z tytu­łem dok­to­ra inż. pew­nej zna­nej poli­tech­ni­ki, publi­ka­cja z 2018 r. 
  • doc.3. Wynik i opis mapo­wa­nia pro­ce­sów biz­ne­so­wych, któ­re­go celem było wspar­cie ana­li­zy kon­ku­ren­cyj­no­ści i ryzy­ka, publi­ka­cja nauko­wa oso­by z tytu­łem dok­to­ra inż. pew­nej zna­nej poli­tech­ni­ki, publi­ka­cja z 2016 r.

Nie jest tu moim celem recen­zo­wa­nie tych prac, celem jest wska­za­nie dość powszech­nie popeł­nia­nych błę­dów. Do celów tego arty­ku­łu zano­ni­mi­zo­wa­łem te pra­ce (choć cyta­ty są nie do uniknięcia). 

Doc.1.

Słownik pojęć zawie­ra jedy­nie osiem pozy­cji, w tym: czym jest BPMN, czym jest IT, defi­ni­cję pro­ce­su i pro­ce­su biz­ne­so­we­go, zbli­żo­ną do defi­ni­cji umiesz­czo­nej w Dodatku C spe­cy­fi­ka­cji nota­cji BPMN ?(?Business Process Model and Notation,? 2014)?, zde­fi­nio­wa­no poję­cia Wykonawca i Zamawiający. 

Dokument zawie­ra listę pro­ce­sów uzna­nych za klu­czo­we, pogru­po­wa­ną w obsza­ry tema­tycz­ne, jed­nak nie poda­no ani źró­dła tej listy ani meto­dy jej opra­co­wa­nia ani opi­su meto­dy gru­po­wa­nia i selek­cji. Innymi sło­wy treść ta nie może pod­le­gać żad­nej oce­nie popraw­no­ści, po pro­stu jest dobra” z powo­du, że ją poda­no. Jedyne poda­ne uza­sad­nie­nie kształ­tu tej lisy jest pod­ję­ta decy­zja” (czy­li dowód z auto­ry­te­tu). Dokument ma 55 stron, powstał w 5 tygo­dni, mode­le i opi­sy pro­ce­sów sta­no­wią ok. poło­wę obję­to­ści. W czę­ści Metodyka nie opi­sa­no metod, poda­no wła­sne defi­ni­cje ele­men­tów nota­cji BPMN, nie­zgod­ne nie raz z ory­gi­na­łem: poję­cie pro­ces w BPMN ozna­cza popraw­ny dia­gram BPMN a nie logicz­ny ciąg czyn­no­ści nie­zbęd­nych do prze­kształ­ce­nia sta­nu wej­ścio­we­go w wyj­ścio­wy”, to doda­tek C zawie­ra definicję: 

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 reso­ur­ces. (ang. Proces biz­ne­so­wy: zde­fi­nio­wa­ny zestaw aktyw­no­ści biz­ne­so­wych, któ­re repre­zen­tu­ją kro­ki wyma­ga­ne do osią­gnię­cia celu biz­ne­so­we­go. Obejmuje prze­pły­wy, wyko­rzy­sta­nie infor­ma­cji i zasobów.)

Warto wie­dzieć, że nota­cja BPMN nie zawie­ra sym­bo­lu defi­nio­wa­ne­go jako pro­ces biz­ne­so­wy”. I dalej: doku­ment zawie­ra definicję: 

Czynność (acti­vi­ty) ? jeden ele­ment dia­gra­mu pro­ce­su, repre­zen­tu­ją­cy
jeden krok w pro­ce­sie; łączy się z inny­mi czyn­no­ścia­mi poprzez połą­cze­nia (con­nec­tion lines) opi­su­ją­ce kie­ru­nek prze­pły­wu transakcji,

Oryginał w BPMN:

An Activity is a gene­ric term for work that com­pa­ny per­forms (see page 151) in a Process. An Activity can be ato­mic or nona­to­mic (com­po­und). The types of Activities that are a part of a Process Model are: Sub-
Process and Task, which are roun­ded rec­tan­gles. (ang. Aktywność jest pod­sta­wo­wym pro­stym ter­mi­nem okre­śla­ją­cym pra­cę jaką w fir­mie się wyko­nu­je (patrz stro­na 151) w ramach pro­ce­su. Aktywność może być ato­mo­wa lub nie­ato­mo­wa (zło­żo­na). Typy aktyw­no­ści wcho­dzą­ce w skład mode­lu pro­ce­su to: Sub-Proces (pod-pro­ces) i zada­nie, któ­re są zobra­zo­wa­ne jako zaokrą­glo­ne prostokąty.

A Task is an ato­mic Activity that is inc­lu­ded within a Process (see page 156). A Task is used when the work in the Process is not bro­ken down to a finer level of Process deta­il. (ang. Zadanie jest ato­mo­wą (ele­men­tar­ną, nie­po­dziel­ną) aktyw­no­ścią zawar­tą w pro­ce­sie (patrz stro­na 156). Zadanie jest uży­wa­ne [w mode­lu] , gdy dana pra­ca w [mode­lo­wa­nym] pro­ce­sie nie jest już dzie­lo­na na kolej­ne pod pozio­my procesu.)

Dla wyja­śnie­nia z dodat­ku C:

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ść ato­mo­wa: Aktywność nie­dzie­lo­na na kolej­ne pozio­my szcze­gó­łów mode­lu pro­ce­su. Jest liściem w hie­rar­chii struk­tu­ry aktyw­no­ści dane­go pro­ce­su. Graficznie jest to zada­nie [task] w BPMN).

Warto wie­dzieć, że poję­cie trans­ak­cja (autor tego doku­men­tu uży­wa go zamien­nie z poję­ciem pro­ces) w BPMN jest zastrze­żo­ne (dla mode­li wyko­ny­wal­nych), i oznacza: 

A trans­ac­tion is a Sub-Process that is sup­por­ted by a spe­cial pro­to­col that insu­res that all par­ties invo­lved have com­ple­te agre­ement that the acti­vi­ty sho­uld be com­ple­ted or can­cel­led (see page 178). (ang. Transakcja to pod­pro­ces obsłu­gi­wa­ny przez spe­cjal­ny pro­to­kół [w sys­te­mie BPMS, przyp. mój], któ­ry zapew­nia, że ??wszyst­kie aktyw­no­ści będą zakoń­czo­ne lub nie, i wte­dy ich pośred­nie efek­ty zosta­ną anu­lo­wa­ne (patrz stro­na 178). 

Definicja poję­cia zda­rze­nie w oryginale:

An Event is some­thing that ?hap­pens? during the cour­se of a Process (ang. Wydarzenie to coś [fakt], co ?wyda­rzy­ło się? w trak­cie procesu).

zaś auto­rzy doku­men­tu piszą: Zdarzenie (event) ? stan jaki poja­wia się pod­czas prze­bie­gu pro­ce­su biz­ne­so­we­go. I w takim samym sty­lu przede­fi­jio­wa­no” BPMN w pozo­sta­łej czę­ści opra­co­wa­nia. Stwierdzenie zaś, że Czynnościami w mode­lu pro­ce­su mogą być: Proces, Podproces, Zadanie.” to już czy­sta here­zja (w BPMN nie ma sym­bo­lu o nazwie pro­ces). W dodat­ku C mamy:

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 seman­tics. (ang. Proces: sekwen­cja lub prze­pływ dzia­łań w orga­ni­za­cji mają­ca na celu dostar­cze­nie efek­tu pra­cy. W BPMN pro­ces jest przed­sta­wia­ny jako dia­gram zło­żo­ny z ele­men­tów prze­pły­wu, któ­re są zesta­wem dzia­łań, zda­rzeń, bra­mek i sekwen­cji prze­pły­wu, któ­re są zgod­ne z [okre­ślo­ną] seman­ty­ką reali­za­cji procesu.)

Innymi sło­wy pro­ces w BPMN to popraw­ny dia­gram (sche­mat blo­ko­wy zgod­ny z seman­ty­ką i syn­tak­ty­ką notacji). 

Diagramy czy­li igno­ro­wa­ne defi­ni­cje. Najpierw jed­nak pew­na uwa­ga, już w 2013 roku pisałem: 

Pro­ce­sy mode­lu­je­my więc po to, by zro­zu­mieć jak dzia­ła orga­ni­za­cja oraz po to, by prze­wi­dzieć jak się ona zacho­wa, jeże­li jakiś pro­ces zmie­ni­my, bo może się nie raz oka­zać, że nie war­to się pew­nych pro­jek­tów podej­mo­wać z uwa­gi na skut­ki. Mode­lo­wa­nie, jak widać, nie jest pro­ce­sem obraz­ko­we­go zapi­su tego co wie­my od pra­cow­ni­ków tej czy innej fir­my, bo to jest ste­no­ty­pia. Mode­lo­wa­nie to trud­ny pro­ces odkry­wa­nia praw­dzi­wej logi­ki dzia­ła­nia orga­ni­za­cji. ?(Żeliński, 2013)?

Co do zasa­dy, zgod­nie z przy­to­czo­ny­mi defi­ni­cja­mi, mamy pew­ne wbu­do­wa­ne ogra­ni­cze­nie na poziom szcze­gó­ło­wo­ści mode­li. Te ogra­ni­cze­nia to defi­ni­cje ato­mo­wej aktyw­no­ści (zada­nie) i pro­ce­su biz­ne­so­we­go (aktyw­ność two­rzą­ca pro­dukt). Innymi sło­wy model pro­ce­su powi­nien się skła­dać z ele­men­tar­nych aktyw­no­ści, z któ­rych każ­da ma wska­za­ny pro­dukt (ocze­ki­wa­ny efekt). W BPMN jedy­nym ele­men­tem mode­lu­ją­cym (słu­żą­cym do zobra­zo­wa­nia) jakich­kol­wiek efek­tów zadań (pro­duk­tów pra­cy) jest Data Object (Obiekt Danych, gene­ral­nie repre­zen­tu­je zestaw danych czy­li doku­ment), któ­ry to – naj­waż­niej­szy – ele­ment, auto­rzy pomi­nę­li przy opi­sie nota­cji. Rozbudowane dia­gra­my w oma­wia­nym doku­men­cie, zawie­ra­ją wie­le róż­nych pro­stych aktyw­no­ści i bar­dzo mało ich efek­tów. Na jed­nym z dia­gra­mów mamy np. Zadanie Powzięcie infor­ma­cji o błęd­nej dekla­ra­cji” nie mają­ce żad­ne­go wej­ścia ani pro­duk­tu! (a jest tam takich sytu­acji wie­le). Takie ele­men­ty na dia­gra­mach, w lite­ra­tu­rze przed­mio­tu (auto­rzy piszą­cy o BPMN), są nazy­wa­ne śmie­cio­we czyn­no­ści na dia­gra­mach”, są to ele­men­ty dia­gra­mu nie wno­szą­ce żad­nej war­to­ści doda­nej w łań­cu­chu pro­ce­su, sta­no­wią­ce oczy­wi­ste stwier­dze­nia (jak np. prze­ka­za­nie doku­men­tu”). Więcej o tym pisa­łem w arty­ku­le Poziomy mode­lo­wa­nia pro­ce­sów ?(Żeliński, 2013)?. Wszystkie mode­le pro­ce­sów w tej doku­men­ta­cji zawie­ra­ją zada­nia w więk­szo­ści nie sko­ja­rzo­ne z żad­nym infor­ma­cja­mi. Jeżeli tytuł opra­co­wa­nia zawie­ra Analiza pro­ce­sów biz­ne­so­wych […] zwią­za­nych z prze­twa­rza­niem infor­ma­cji […]” to nie wiem cze­go się dowie adre­sat tego doku­men­tu o tych­że infor­ma­cjach i ich przetwarzaniu. 

Kwiatkiem na sam koniec, jest zastrze­że­nie praw autor­skich do doku­men­tu (bene­fi­cjent, któ­ry pokrył kosz­ty tej ana­li­zy nie dostał praw mająt­ko­wych do jej efek­tu). Dokument nie zawie­ra imion i nazwisk auto­ra (auto­rów).

Dok.2.

Zacznijmy od popraw­no­ści cyto­wa­nia źró­deł: autor poda­je: Strona domo­wa fir­my XXX, www​.XXX​.com​.pl, dostęp 08.01.2018, rzecz w tym, że to stro­na tytu­ło­wa, dotar­cie do miej­sca skąd pobra­no cyto­wa­ną treść gra­ni­czy z cudem. Po dru­gie autor piszą­cy o nota­cjach, uży­wa­ją­cy defi­ni­cji nota­cyj­nych, któ­ry to autor nie powo­łu­je się na (i nie umiesz­cza w spi­sie lete­ra­tu­ry!) ich ory­gi­nal­nej spe­cy­fi­ka­cji wyka­zu­je poważ­ne bra­ki metodologiczne. 

Dokument zaty­tu­ło­wa­ny jest Mapowanie pro­ce­sów przy­go­to­wa­nia ofer­ty… a jego celem jest opi­sa­nie metod (meto­dy?) mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Z uwa­gi na ano­ni­mi­za­cję nie wkle­ję z ory­gi­na­łu, ale: przy­to­cze­nie jako przy­kła­du dwóch dia­gra­mów UML bez poda­nia ich nazwy (UML to trzy­na­ście nazwa­nych typów dia­gra­mów, ?(?Unified Modeling Language,? 2017)?) jest poważ­nym uchy­bie­niem. Publikacja trak­tu­je o mode­lo­wa­niu pro­ce­sów, a autor jako przy­kła­dy poda­je nota­cję UML, a jako przy­kła­do­we mode­le UML podał aku­rat te, nie­ma­ją­ce z mode­lo­wa­niem pro­ce­sów nic wspól­ne­go (maszy­na sta­no­wa i dia­gram komu­ni­ka­cji), war­to też wie­dzieć, że od 2015 jaw­nie w spe­cy­fi­ka­cji UML zosta­ło napi­sa­ne, że ta nota­cja słu­ży wyłącz­nie do mode­li sys­te­mów ?(?Meta Object Facility,? 2016)?, i nie nale­ży jej uży­wać do mode­li biz­ne­so­wych. Modele biz­ne­so­wa CIM, (Computation Independent Model, ?(?MDA Foundation Model,? 2006)?) od tego są nota­cje BPMN ?(?Business Process Model and Notation,? 2014)? oraz SBVR ?(?Semantics Of Business Vocabulary and Rules,? 2017)?.

W tej pra­cy, na dia­gra­mach mode­li pro­ce­sów, popeł­nio­no wszyst­kie błę­dy opi­sa­ny dla Doc.1., ale poja­wił kolej­ny, wręcz kurio­zal­ny: autor naniósł (roz­cią­gnął) jed­ną aktyw­ność na dwa tory (jed­no zada­nie ma dwo­je odpo­wie­dzial­nych??) co jest nie­do­pusz­czal­ne w BPMN. 

źr. publi­ka­cja nauko­wa, zano­ni­mi­zo­wa­ny autor.

Doc.3.

W tytu­le tej pra­cy mamy: Mapowanie pro­ce­sów biz­ne­so­wych jako tech­ni­ka wspie­ra­ją­ca… „. W roz­dzia­le Metoda badaw­cza, nie ma ani sło­wa o meto­dzie mapo­wa­nia pro­ce­sów (?) a następ­ny roz­dział jest zaty­tu­ło­wa­ny Mapowanie pro­ce­sów biz­ne­so­wych. Rozdział ten zawie­ra sche­ma­ty blo­ko­we pozba­wio­ne legen­dy a więc nie­czy­tel­ne i raczej trud­ne do inter­pre­ta­cji. Jeżeli autor two­rzy wła­sną nota­cją, to tym bar­dzie nale­ży ją zde­fi­nio­wać przed uży­ciem. Schematy blo­ko­we (bez opi­su i legen­dy!) kształ­tem nawią­zu­ją do tak zwa­nej meto­dy swim lanes” mode­lo­wa­nia prze­pły­wu pra­cy, gdzie tory repre­zen­tu­ją oso­by odpo­wie­dzial­ne lub fizycz­nych wyko­naw­ców, cza­sa­mi komór­ki orga­ni­za­cyj­ne. ?(Rummler & Brache, 2000)?. Jednak i tu jed­na aktyw­ność roz­cią­gnię­ta na twa tory co jest łama­niem zasad. 

Poziom mery­to­rycz­ny (sto­so­wa­nie metod a raczej ich brak), brak cyto­wa­nia kano­nu lite­ra­tu­ry na temat pro­ce­sów biz­ne­so­wych i ich mode­lo­wa­nia, zasto­so­wa­nie, bez uza­sad­nie­nia, wła­snej i nie­zde­fi­nio­wa­nej nota­cji, w XXI wie­ku, w zesta­wie­niu z tym, że jest to pro­dukt dok­to­ra inży­nie­ra zna­nej uczel­ni tech­nicz­nej w roku 2015, sta­wia tak­że tego auto­ra w sła­bym świetle. 

Podsumowanie

Jak już wspo­mnia­łem na począt­ku, celem moim było poka­za­nie tego, że pra­ce zali­cza­ne do pro­fe­sjo­nal­nych pro­duk­tów firm dorad­czych, czy też będą­ce tak zwa­ny­mi publi­ka­cja­mi nauko­wy­mi, powin­ny cecho­wać się tym samym wyso­kim pozio­mem mery­to­rycz­nym, a nauko­we tak­że meto­do­lo­gicz­nym. Z przy­kro­ścią muszę tu napi­sać, że recen­zje jak powyż­sza, są moim sta­łym zaję­ciem zarów­no jako bie­głe­go jak i nauczy­cie­la aka­de­mic­kie­go. Bo nie ma dla mnie zna­cze­nia to, czy doku­men­ty, takie jak powy­żej, przy­wo­łu­je mój dyplo­mant czy też robi stro­na skar­żą­ca usłu­go­daw­cę. Znaczenie ma to, że one powsta­ją, a ich auto­rzy otrzy­mu­ją za nie, nie raz sowi­te, wynagrodzenie. 

Często sły­szę od auto­rów: bo klient chciał żeby tak nary­so­wać”. Wiem, klien­ci nie raz tak chcą, ale zada­niem pro­fe­sjo­na­li­sty jest zagwa­ran­to­wać poziom mery­to­rycz­ny swo­ich doku­men­tów i ich jakość, a przede wszyst­kim ich póź­niej­szą przy­dat­ność, a ta w takich sytu­acjach bywa bar­dzo wątpliwa. 

Klient nasz Pan? Często to sły­szę. Otóż nie. Klient zama­wia pro­dukt, jeże­li jest nim opra­co­wa­nie eks­perc­kie, to nie klient a expert, jest jego auto­rem i to eks­pert decy­du­je o tre­ści (pod któ­rą praw­dzi­wy eks­pert pod­pi­su­je się imie­niem i nazwi­skiem!). Taksówkarze też dzie­lą się na dwie gru­py: Ci któ­rzy łamią prze­pi­sy ruchu dro­go­we­go jak klient pro­si (bo się np. spie­szy) i Ci, któ­rzy tego nie robią. Warto pamię­tać, że ewen­tu­al­ne man­da­ty pła­cą kie­row­cy a nie pasażerowie. 

Źródła

  1. Business Process Model and Notation. (2014). Retrieved 2019, from OMG​.org websi­te: https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
  2. MDA Foundation Model. (2006). Retrieved 2019, from OMG​.org websi­te: https://​www​.omg​.org/​c​g​i​-​b​i​n​/​d​o​c​?​o​r​m​s​c​/10 – 09-06
  3. Meta Object Facility. (2016). Retrieved 2019, from OMG​.org websi­te: https://​www​.omg​.org/​s​p​e​c​/​MOF
  4. Rummler, G. A., & Brache, A. P. (2000). Podnoszenie efek­tyw­no­ści orga­ni­za­cji. Jak zarzą­dzać ?bia­ły­mi pla­ma­mi? w struk­tu­rze orga­ni­za­cyj­nej? Warszawa: Polskie Wydawnictwo Ekonomiczne.
  5. Semantics Of Business Vocabulary and Rules. (2017). Retrieved 2019, from OMG​.org websi­te: https://​www​.omg​.org/​s​p​e​c​/​S​B​V​R​/​A​b​o​u​t​-​S​B​VR/
  6. Unified Modeling Language. (2017). Retrieved 2019, from OMG​.org​.pl websi­te: https://​www​.omg​.org/​s​p​e​c​/​U​M​L​/​A​b​o​u​t​-​U​ML/
  7. Żeliński, J. (2011, November 15). Logika wnio­sko­wa­nia deduk­cyj­ne­go czy­li czym jest popraw­na ana­li­za i mode­lo­wa­nie. Retrieved September 13, 2019, from IT​-Consulting​.pl websi­te: https://it-consulting.pl//2011/11/15/trzy-zasady-nazywane-czasem-najwyzszymi-prawami-myslenia-czyli-czym-jest-poprawna-analiza/
  8. Żeliński, J. (2013). Poziomy mode­lo­wa­nia pro­ce­sów. Retrieved 2019, from IT​-Consulting​.pl websi­te: https://it-consulting.pl//2013/07/04/poziomy-modelowania-procesow/

Mit o notacji BPMN i modelach procesów

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

OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
Bouzidi, A., Haddar, N., & Haddar, K. (2019). Traceability and Synchronization Between BPMN and UML Use Case Models. Ingénierie Des Systèmes d Information, 24(2), 215 – 228. https://​doi​.org/​1​0​.​1​8​2​8​0​/​i​s​i​.​2​4​0​214
Suchenia, A., Kluza, K., Wiśniewski, P., Jobczyk, K., & Ligęza, A. (2019). Towards know­led­ge inte­ro­pe­ra­bi­li­ty betwe­en the UML, DMN, BPMN and CMMN models. MATEC Web of Conferences, 252, 02011. https://​doi​.org/​1​0​.​1​0​5​1​/​m​a​t​e​c​c​o​n​f​/​2​0​1​9​2​5​2​0​2​011

Modele informacyjne

Dziesięć lat temu pisa­łem o infor­ma­cji i jej struk­tu­ral­nym cha­rak­te­rze, wpis koń­czył się zdaniem:

czym więc jest Zarządzanie Wiedzą (mil­czą­co zakła­dam, że zarzą­dzać moż­na czymś mate­rial­nym)? Jest to ?prze­cho­wy­wa­nie danych jed­no­znacz­nie zro­zu­mia­łych, opi­su­ją­cych okre­ślo­ne i ogra­ni­czo­ne licz­bą fak­ty inter­pre­to­wa­ne jako poj­mo­wal­na przez adre­sa­ta informacja?.Przemyślenia zwią­za­ne z tą ostat­nią defi­ni­cją pozo­sta­wiam Państwu. Ciąg dal­szy może nastą­pi? (źr. : Potrzeby infor­ma­cyj­ne fir­my ? Zarządzanie wie­dzą | Jarosław Żeliński IT-Consulting) 

Kontynuacją cyto­wa­ne­go tek­stu będzie dzi­siaj kwe­stia infor­ma­cji i powią­za­nych z nią wyma­gań na opro­gra­mo­wa­nie. Każdy pro­jekt wytwo­rze­nia, lub nawet tyl­ko dostar­cze­nia goto­we­go, opro­gra­mo­wa­nia powi­nien mieć co naj­mniej dwie war­stwy opi­su: (1) co chce­my stwo­rzyć i (2) jak to chce­my stwo­rzyć. Pierwsza to tak zwa­na war­stwa abs­trak­cyj­na opi­su­ją­ca mecha­nizm funk­cjo­no­wa­nia sys­te­mu. Druga to logicz­na archi­tek­tu­ra sys­te­mu czy­li pomysł na reali­za­cję (model Platform Independent). Na pod­sta­wie mode­lu PIM deve­lo­per pro­jek­tu­je opro­gra­mo­wa­nie, któ­re wyko­na (Platform Specific Model). Jednak czę­sto dostaw­ca ist­nie­ją­ce­go opro­gra­mo­wa­nia chce porów­nać logi­kę opro­gra­mo­wa­nia, któ­re ofe­ru­je, z logi­ką opi­sa­ną jako wyma­ga­ną. Tu potrzeb­ny jest nie model archi­tek­tu­ry PIM a model infor­ma­cyj­ny opi­su­ją­cy logi­kę biz­ne­so­wą ale nie narzu­ca­ją­cy archi­tek­tu­ry (bo ta już istnieje).

Bardzo czę­sto głów­nym celem biz­ne­so­wym, i zara­zem wyma­ga­niem, jest zarzą­dza­nie infor­ma­cją czy­li skoń­czo­ną licz­bą typów doku­men­tów o usta­lo­nej (lub wyma­ga­ją­cej usta­le­nia) tre­ści i struk­tu­rze. Niestety czę­sto jest tak, że struk­tu­ra doku­men­tów ule­ga pew­nym zmia­nom przy zacho­wa­niu głów­ne­go celu dla jakie­go powsta­ły, co utrud­nia zada­nie ale nie jest praw­dę, że jest to powód do per­ma­nent­ne­go mody­fi­ko­wa­nia opro­gra­mo­wa­nia. Odporność (goto­wość) apli­ka­cji na zmien­ność tre­ści jest tu wyma­ga­niem i sys­tem powi­nien sobie z tym poradzić.

W takich przy­pad­kach mode­lu­jąc sys­tem war­to sku­pić się wyłącz­nie na infor­ma­cji i na tym jak jest ona zarzą­dza­na, pozo­sta­wia­jąc pew­ne deta­le archi­tek­tu­ry dostaw­cy, któ­ry z zasa­dy – jako deve­lo­per – dys­po­nu­je więk­szą wie­dzą o dostęp­nych na ryn­ku tech­no­lo­giach i narzę­dziach. W takich przy­pad­kach war­to opra­co­wać tak zwa­ny model infor­ma­cyj­ny. Nie jest on jed­nak ani bazą danych ani mode­lem dzie­dzi­ny (przy­po­mi­nam, że obiek­to­wy model dzie­dzi­ny to kom­po­nent archi­tek­to­nicz­ny wzor­ca MVC). Jest to model związ­ków logicz­nych mię­dzy doku­men­ta­mi opi­su­ją­cy mecha­ni­zmy korzy­sta­nia z nich.

O informacji

Kluczowymi poję­cia­mi w tym obsza­rze ana­liz są: nośnik, doku­ment, infor­ma­cja, treść, dane, wia­do­mość, któ­re moż­na zobra­zo­wać w posta­ci związ­ków poję­cio­wych (dia­gram fak­tów SBVR):

Dokument elek­tro­nicz­ny (obec­ny jako poję­cie od kil­ku lat w pol­skim pra­wie) jest defi­nio­wa­ny jako
sta­no­wią­cy odręb­ną całość zna­cze­nio­wą zbiór danych upo­rząd­ko­wa­nych w okre­ślo­nej struk­tu­rze wewnętrz­nej i zapi­sa­ny na infor­ma­tycz­nym nośni­ku danych (na pod­sta­wie usta­wy KPA1 i SJP PWN). Innymi sło­wy: doku­ment elek­tro­nicz­ny to (upo­rząd­ko­wa­ne) infor­ma­cje zapi­sa­ne na elek­tro­nicz­nym nośni­ku, jed­nak nośni­kiem może być nadal np. papier, więc gene­ral­nie pod poję­ciem doku­ment moż­na (nale­ży) rozu­mieć utrwa­lo­ną odręb­ną całość zna­cze­nio­wą, zbiór danych upo­rząd­ko­wa­nych w okre­ślo­nej struk­tu­rze wewnętrz­nej”. Skoro odręb­ną, to tak­że mają­cą uni­kal­ną nazwę, bez cze­go nie­moż­li­we było by odwo­ła­nie się do takie­go doku­men­tu. Kolejna waż­na rzecz: zna­cze­nie i struk­tu­ra. Strukturę doku­men­tu okre­śla jego sza­blon, treść zaś to to co zosta­nie zapi­sa­ne z uży­ciem tego sza­blo­nu. Przykład: sło­wo fak­tu­ra ozna­cza obo­wią­zu­ją­cy sza­blon doku­men­tu mogą­ce­go, po wypeł­nie­niu, zawie­rać infor­ma­cje o tym, kto, komu, co, kie­dy i za jaką kwo­tę sprzedał.

Generalnie infor­ma­cje są orga­ni­zo­wa­ne w nazwa­ne struk­tu­ry czy­li doku­men­ty. Tu waż­na uwa­ga: ludzie w pro­ce­sie komu­ni­ka­cji zawsze ope­ru­ją infor­ma­cją o okre­ślo­nej struk­tu­rze, bywa, że jest ona – struk­tu­ra – pro­sta, struk­tu­rą jest tak­że podział wymia­ny infor­ma­cji na odręb­ne komu­ni­ka­ty, gdzie jeden komu­ni­kat to jed­no pole for­mu­la­rza”. Nie zmie­nia to fak­tu, że taki komu­ni­kat to struk­tu­ra zawie­ra­ją­ca auto­ra i nadaw­cę komu­ni­ka­tu, odbior­cę komu­ni­ka­tu oraz jego treść, jest to for­mu­larz – struk­tu­ra – jaką widzi­my pisząc np. kolej­ne­go maila.

W efek­cie moż­na przy­jąć, że wszel­kie infor­ma­cje w orga­ni­za­cjach są zor­ga­ni­zo­wa­ne z uży­ciem okre­ślo­nej licz­by for­mu­la­rzy, z któ­rych każ­dy ma okre­ślo­ną struk­tu­rę. Struktury te nazy­wa­my sza­blo­na­mi doku­men­tów (for­mu­la­rzy). Nie jest nie­ste­ty praw­dą, że infor­ma­cje są zor­ga­ni­zo­wa­ne w bazach danych rozu­mia­nych jako sys­tem rela­cyj­nych tablic. Model rela­cyj­ny jest nie­na­tu­ral­ny i strat­ny. Człowiek nie jest w sta­nie korzy­stać z nie­go wprost, jest to tyl­ko jakaś tech­no­lo­gicz­na meto­da zapi­su danych.

Model informacyjny organizacji

W związ­ku z tym, mamy pra­wo uznać, że wszyst­kie infor­ma­cje w fir­mie są zor­ga­ni­zo­wa­ne w uży­ciem skoń­czo­nej licz­by struk­tur i nie są to struk­tu­ry zna­ne z rela­cyj­nych baz danych, są to odręb­ne i nie­po­łą­czo­ne (nie­współ­dzie­lą­ce danych) for­mu­la­rze, czy­li po pro­stu odręb­ne doku­men­ty. Formularze te mogą być jaw­nie logicz­nie sko­ja­rzo­ne np. na fak­tu­rach są nano­szo­ne nume­ry zamó­wień. Mogą być sko­ja­rzo­ne nie wprost, z uży­ciem okre­ślo­nych reguł np. poda­tek za dany mie­siąc nali­cza­my na pod­sta­wie fak­tur wysta­wio­nych w tym mie­sią­cu albo dany refe­rent ma dostęp do doku­men­tu, jeże­li ten zwią­za­ny jest ze spra­wą aktu­al­nie przy­dzie­lo­ną temu refe­ren­to­wi. Ostatni przy­kład to typo­we dyna­micz­ne powią­za­nie gdyż przy­dział refe­ren­ta do spra­wy, a więc tak­że doku­men­tów z nią powią­za­nych, może ule­gać zmia­nie w czasie.

Formularze te, ich zawar­tość oraz logi­ka powią­zań pomię­dzy nimi, to sys­tem infor­ma­cyj­ny orga­ni­za­cji. Każda orga­ni­za­cja cechu­je się wła­snym, indy­wi­du­al­nym sys­tem infor­ma­cyj­nym, gdyż tyl­ko część doku­men­tów ma z góry narzu­co­ną struk­tu­rę np. pra­wem lub stan­dar­dem bran­żo­wym. Reszta, struk­tu­ra wewnętrz­nych doku­men­tów, to decy­zje wewnętrz­ne organizacji.

Postrzegam jako poważ­ny błąd uzna­nie, że model infor­ma­cyj­ny to jed­no­li­ta rela­cyj­na struk­tu­ra danych (pojęć) podob­na do (budo­wa­na na wzór) onto­lo­gii2. Po pierw­sze rela­cyj­ny model danych prze­cho­wu­je nie doku­men­ty a poję­cia, uzna­jąc związ­ki mię­dzy poję­cia­mi za sta­łe rela­cje (co nie zawsze jest praw­dą). Po dru­gie usu­wa­nie redun­dan­cji w pro­ce­sie zapi­su danych z for­mu­la­rzy wyma­ga ich odtwo­rze­nia przy każ­dej pró­bie odtwo­rze­nia kon­kret­ne­go doku­men­tu. Tak więc taka rela­cyj­na baza danych nie prze­cho­wu­je żad­nych doku­men­tów a jedy­nie zbiór trwa­le powią­za­nych pojęć. Bardzo czę­sto mówi się, że infor­ma­cje i wie­dza to onto­lo­gia. Niestety tak nie jest, onto­lo­gia to sys­tem pojęć powią­za­nych związ­ka­mi seman­tycz­ny­mi, sta­no­wi opis języ­ko­wa ale nie jest to wie­dza o świe­cie a wie­dza o języku.

Generalnie uwa­żam, że nie jest infor­ma­cją poję­cie, jego defi­ni­cja i seman­tycz­ne powią­za­nie z innym poję­ciem. To tyko model syn­tak­ty­ka i seman­ty­ka pojęć. Faktura zaś to zbiór pojęć mają­cych okre­ślo­ną struk­tu­rę i treść, war­tość ma to – wie­dza – kto, co kie­dy i od kogo kupił, a nie to co zna­czy sło­wo pro­dukt czy nabyw­ca i jak jest seman­tycz­nie on powią­za­ny z poję­ciem sprze­daw­ca. To co naj­wy­żej pozwo­li nam zro­zu­mieć jaką treść zawie­ra faktura.

Kolejną wadą podej­ścia rela­cyj­ne­go jest to, że baza taka sta­no­wi nie­po­dziel­ny mono­lit, w efek­cie to co jest moż­li­we w rze­czy­wi­sto­ści (np. pra­ca z fak­tu­rą w cał­ko­wi­tym ode­rwa­niu od odpo­wia­da­ją­cych jej zamó­wień) jest nie­moż­li­we w sys­te­mie rela­cyj­nym. Usuwanie redun­dan­cji powo­du­je tak­że powsta­wa­nie duże­go narzu­tu na zarzą­dza­nie histo­rią zmian pól baz danych, co nie ma miej­sca w rze­czy­wi­stych doku­men­tach (kar­to­te­ka klien­ta zawie­ra wyłącz­nie aktu­al­ne dane adre­so­we, histo­rycz­ne są dostęp­ne w histo­rycz­nych doku­men­tach, np. aktu­al­ne dane adre­so­we klien­ta są w jego kar­to­te­ce, jego adres z ubie­głe­go roku znaj­dzie­my na doku­men­tach wysta­wio­nych temu klien­to­wi w ubie­głym roku).

Rok temu pisa­łem przy podob­nej okazji:

war­to zauwa­żyć, że zmien­ność śro­do­wi­ska biz­ne­so­we­go powo­du­je, że żad­ne decy­zje o logi­ce biz­ne­so­wej nie są osta­tecz­ne, jed­nak są ele­men­ty nie­zmien­ne takie jak np. nasze dane oso­bo­we. Tak więc to, co powszech­nie nazy­wa­ne jest ?mode­lem danych? (busi­ness data dia­gram) w rozu­mie­niu opi­sa­nym przez autor­ki arty­ku­łu, nie ma racji bytu. Ma sens zacho­wa­nie zamó­wie­nia i osob­no fak­tu­ry, ale to czy regu­łą jest jed­no zamó­wie­nie do jed­nej fak­tu­ry, pod­le­ga zmia­nom wyni­ka­ją­cym i ze zmien­no­ści pra­wa i ze zmien­no­ści mode­li biz­ne­so­wych. Nie widzę żad­ne­go powo­du dekla­ro­wa­nia już na począt­ku pro­jek­tu, tego by nie wię­cej niż 5 osób mogło korzy­stać z jed­ne­go kon­ta i sub­skryp­cji. W szcze­gól­no­ści nie widzę powo­du by taka zasa­da była zawar­ta w samym kodzie apli­ka­cji. (źr. : Biznesowy model danych ? nie chce­my | | Jarosław Żeliński IT-Consulting).

Problemy jakie wno­si do pro­jek­tu opar­cie się na jed­nym rela­cyj­nym mode­lu danych dla całej apli­ka­cji, są zna­ne od lat:

(źr. Designing Objects Systems, Steve Cook, John Daniels, 1994 rok.)

a mimo to nadal jest on sto­so­wa­ny w spo­sób sta­no­wią­cy zagro­że­nie dla całe­go projektu.

Czym więc jest model infor­ma­cyj­ny orga­ni­za­cji? Jest to sys­tem sza­blo­nów doku­men­tów czy­li usta­lo­nych struk­tur infor­ma­cyj­nych wraz z logi­ką ich wza­jem­nych powią­zań czy­li aso­cja­cji, świa­do­mie uni­kam poję­cia rela­cji. Relacja to trwa­ły zwią­zek, zaś aso­cja­cja to sko­ja­rze­nie budo­wa­ne na bazie okre­ślo­nej logi­ki czy zacho­dzą­ce­go fak­tu. Przykład: fak­tu­ra sko­ja­rzo­na jest z oso­bą, któ­ra doko­na­ła sprze­da­ży, jed­nak w momen­cie gdy upły­nie ter­min waż­no­ści i fak­tu­ra nie jest opła­co­na, jest ona auto­ma­tycz­nie koja­rzo­na z win­dy­ka­to­rem i sprze­daw­ca prze­sta­je być za nią odpo­wie­dzial­ny (być może nawet tra­ci dostęp do jej tre­ści, zgod­nie z zasa­dą bez­pie­czeń­stwa mówią­cą, że pra­cow­ni­cy mają dostęp wyłącz­nie do infor­ma­cji potrzeb­nej do reali­zo­wa­nia ich bie­żą­cych zadań i obo­wiąz­ków).

Jak podejść do opra­co­wa­nia i udo­ku­men­to­wa­nia sys­te­mu infor­ma­cyj­ne­go, czy­li jak wyko­nać jego model? Pierwszy krok to ziden­ty­fi­ko­wa­nie doku­men­tów. Podstawą będzie tu ana­li­za pro­ce­sów biz­ne­so­wych i opra­co­wa­nie ich mode­li. Elementarny (ato­mo­wy) pro­ces biz­ne­so­wy to aktyw­ność mają­ca wej­ście i wyj­ście, a kon­kret­nie dane wej­ścio­we i dane, któ­ry powsta­ją jako pro­dukt tej aktyw­no­ści. Te dane to nic inne­go jak infor­ma­cje o okre­ślo­nej struk­tu­rze. Oznacza to, że na mode­lu pro­ce­sów (tu w nota­cji BPMN) każ­da aktyw­ność musi mieć sko­ja­rzo­ny doku­ment wej­ścio­wy i wyj­ścio­wy (ele­ment o nazwie DataObect w nora­cji BPMN), w prze­ciw­nym razie taka aktyw­ność nie powin­na się poja­wić na modelu.

Powyższy dia­gram zawie­ra mode­le dwóch odręb­nych pro­ce­sów: obsłu­ga zapy­tań ofer­to­wych oraz obsłu­ga zamó­wień. Oba dia­gra­my to naj­niż­szy poziom mode­lo­wa­nia pro­ce­sów, poziom ele­men­tar­nych (ato­mo­wych) pro­ce­sów biz­ne­so­wych. Pozwala ziden­ty­fi­ko­wać wszyst­kie doku­men­ty i ich statusy.

Tu mała uwa­ga: nie ma żad­ne­go sen­su umiesz­cza­nie na takich mode­lach deta­licz­nych prac takich jak wpro­wa­dze­nie danych zama­wia­ją­ce­go” czy spraw­dze­nie sal­da” bo to są ele­men­ty (kro­ki) pro­ce­dur. Innymi sło­wy nie rysu­je­my” na dia­gra­mach tego jak i w jakiej kolej­no­ści wypeł­nić pola for­mu­la­rza. Po pierw­sze zaciem­ni to obraz, po dru­gie pro­ce­dur, reguł biz­ne­so­wych i słow­ni­ków nie mode­lu­je­my z uży­ciem BPMN. Robi się to w posta­ci odręb­nych doku­men­tów lub diagramów.

Powyższy model obra­zu­je sytu­ację, w któ­rej pew­na fir­ma odsy­ła ofer­ty na zapy­ta­nia, otrzy­mu­jąc zaś zamó­wie­nie, spraw­dza je od stro­ny for­mal­nej i reali­zu­je. Każdy taki model, dla peł­nej zro­zu­mia­ło­ści, MUSI mieć załą­czo­ne (dia­gra­my, wzo­ry wydru­ków, inne) struk­tu­ry tych doku­men­tów. Dodatkiem będzie wła­śnie model infor­ma­cyj­ny czy­li logicz­na struk­tu­ra powią­zań logicz­nych mię­dzy doku­men­ta­mi (korzy­sta­ją z niej oso­by pra­cu­ją­ce z tymi dokumentami).

Prosta wer­sja takie­go mode­lu infor­ma­cyj­ne­go może zostać wyko­na­ną tak­że w nota­cji BPMN:

Tu jed­nak moż­li­we jest poka­za­nie jedy­nie związ­ków jaki­mi są tak zwa­ne refe­ren­cje, czy­li wza­jem­ne jaw­ne odwo­ła­nia (np. for­mu­larz ofer­ty zawie­ra pole z nume­rem zapy­ta­nia). Pełny model infor­ma­cyj­ny moż­na wyko­nać z uży­ciem nota­cji UML:

Powyższy dia­gram to kla­sy repre­zen­tu­ją­ce nazwa­ne struk­tu­ry doku­men­tów (ich typy) oraz związ­ki logicz­ne mię­dzy nimi (aso­cja­cje w UML to nie są trwa­łe rela­cje zna­ne z baz danych a jedy­nie związ­ki seman­tycz­ne). Związki te moż­na zobra­zo­wać jeże­li są to trwa­łe (wbu­do­wa­ne w treść) binar­ne powią­za­nia (zwią­zek pomię­dzy dwo­ma kla­sa­mi). Jednak związ­ki dyna­micz­ne, defi­nio­wa­ne przez regu­ły biz­ne­so­we, nie dają się zobra­zo­wać dla­te­go poprze­sta­je­my na wyspe­cy­fi­ko­wa­niu takiej reguły.

Powyższy dia­gram mówi nam, że:

  • powią­za­nie pomię­dzy ory­gi­na­łem zapy­ta­nia (np. jego skan na dys­ku) a wewnętrz­nym doku­men­tem Zapytanie od klien­ta, jest zawar­te w doku­men­cie (for­mu­larz) Metadane zapy­tań (jest to kla­sa aso­cja­cyj­na UML), któ­ry (hipo­te­tycz­ny sza­blon był­by w załą­cze­niu) zawie­ra infor­ma­cje o poło­że­niu pli­ku na dys­ku i przy­dzie­lo­nym mu np. wewnętrz­nym nume­rze Zapytania,
  • powią­za­nie pomię­dzy Ofertą han­dlo­wą a Zapytaniem jest wbu­do­wa­ne w Oferty w posta­ci nume­ru zapy­ta­nia, jako jed­ne­go z atry­bu­tów doku­men­tu Oferta (Oferta w swo­jej tre­ści powo­łu­je się na numer Zapytania, zobra­zo­wa­no to aso­cja­cją kwa­li­fi­ko­wa­ną UML),
  • zwią­zek pomię­dzy doku­men­tem a oso­bą, któ­ra ma dostęp do jego tre­ści opi­su­je regu­ła biz­ne­so­wa mówią­ca, że Sprzedawca ma dostęp do doku­men­tów klien­tów, któ­rych jest opie­ku­nem”, regu­ła ta zosta­ła zaim­ple­men­to­wa­na w posta­ci doku­men­tu Opiekun (kla­sa aso­cja­cyj­na UML) , zakła­da­my że jest to for­mu­larz zawie­ra­ją­cy nazwę klien­ta i nazwę jego opie­ku­na (np. udo­ku­men­to­wa­na decy­zja dyr. dzia­łu sprze­da­ży), te doku­men­ty mogą być w dowol­nej chwi­li zmie­nia­ne, doda­wa­ne i usuwane.

Jak widać dia­gram nie zawie­ra aso­cja­cji pomię­dzy Sprzedawcą a doku­men­ta­mi (dostęp Sprzedawcy do tre­ści dane­go doku­men­tu), gdyż ich sen­sow­ne zobra­zo­wa­nie na dia­gra­mie jest prak­tycz­nie niemożliwe.

Taki dia­gram zawie­ra pre­cy­zyj­ne infor­ma­cje o tym jakie i jak powią­za­ne z sobą infor­ma­cje prze­twa­rza orga­ni­za­cja. Nie jest to abso­lut­nie coś co nale­ży odwzo­ro­wać jako model kodu, nie ma tu żad­nych licz­no­ści klas, bo te tak­że są (poten­cjal­nie zmien­ny­mi) regu­ła­mi biz­ne­so­wy­mi (np. regu­ła: jeden sprze­daw­ca nie może się opie­ko­wać wię­cej niż dzie­się­cio­ma klien­ta­mi). Nie jest to żaden model danych, struk­tu­ry for­mu­la­rzy doku­men­tu­je­my osob­no. Nie jest też powie­dzia­ne, że imple­men­ta­cja for­mu­la­rzy to tabli­ce z kolum­na­mi odpo­wia­da­ją­cy­mi polom for­mu­la­rzy (to zresz­tą bar­dzo kiep­ski pomysł).

Pełna doku­men­ta­cja powin­na zawie­rać w załą­cze­niu deta­licz­ne struk­tu­ry tych for­mu­la­rzy (dia­gra­my przed­sta­wia­ją­ce struk­tu­ry XML, lub sko­men­to­wa­ne mock-up’y doku­men­tów). Taka spe­cy­fi­ka­cja zawie­ra wszyst­kie infor­ma­cje pozwa­la­ją­ce deve­lo­pe­ro­wi stwo­rzyć opro­gra­mo­wa­nie słu­żą­ce do zbie­ra­nia i zarzą­dza­nia infor­ma­cją. Jako model wyma­gań na sys­te­my typu EOD3 jest wystarczająca.

Gdyby było praw­dą, że wyma­ga­my od opro­gra­mo­wa­nia tak­że, by zawar­tość wybra­nych pól tych for­mu­la­rzy była wyli­cza­na lub wery­fi­ko­wa­na, musi­my dodat­ko­wo udo­ku­men­to­wać zależ­no­ści mię­dzy tymi pola­mi. Model taki czę­sto war­to uzu­peł­nić wyma­ga­ną archi­tek­tu­rą opro­gra­mo­wa­nia, bo od niej zale­żą cechy jako­ścio­we apli­ka­cji, tak zwa­ne poza­funk­cjo­nal­ne. Będzie to wła­śnie model dzie­dzi­ny sys­te­mu, opi­sy­wa­ny na moim blo­gu wielokrotnie. 

Poniżej cel i pro­ces budo­wy mode­li poję­cio­wych :

M. van Sinderen and P. Johnson (Eds.): IWEI 2011, LNBIP 76, pp. 146?162, 2011. ? IFIP International Federation for Information Processing 2011
M. van Sinderen and P. Johnson (Eds.): IWEI 2011, LNBIP 76, pp. 146?162, 2011. ? IFIP International Federation for Information Processing 2011

Zapraszam tak­że do lek­tu­ry kon­ty­nu­acji tego zagad­nie­nia w arty­ku­le Bazy Dokumentowe.

Źródła

van Sinderen, M., & Johnson, P. (Eds.). (2011). Enterprise Interoperability: Third International IFIP Working Conference, IWEI 2011, Stockholm, Sweden, March 23 – 24, 2011. Proceedings (Vol. 76). Springer Berlin Heidelberg. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑642 – 19680‑5
Usman, Z., Young, R. I. M., Chungoora, N., Palmer, C., Case, K., & Harding, J. (2011). A Manufacturing Core Concepts Ontology for Product Lifecycle Interoperability. In M. van Sinderen & P. Johnson (Eds.), Enterprise Interoperability (pp. 5 – 18). Springer. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑642 – 19680-5_3

Analityczne i wykonywalne modele

Obserwuję wie­le nie­po­ro­zu­mień z two­rze­niem mode­li i samym mode­lo­wa­niem. Generalnie mode­le mogą być mode­la­mi abs­trak­cyj­ny­mi lub wyko­ny­wal­ny­mi. Te pierw­sze są tak­że nazy­wa­ne ana­li­tycz­ny­mi. Większość nota­cji ma dodat­ki (roz­sze­rze­nia) zaty­tu­ło­wa­ne Execution Semantics (lub podob­nie). Generalnie są to opi­sy warun­ków jakie musi speł­nić model by był wyko­ny­wal­ny (pozwa­la na reali­za­cje – uru­cho­mie­nie – tego co mode­lu­je). Zapewnienie wyko­ny­wal­no­ści wyma­ga poda­nia dodat­ko­wych ele­men­tów do mode­lu. Zbliża go to do mode­li PSM (MDA, Platform Specific Model). Np. dla nota­cji BPMN jest to roz­sze­rze­nie [[BPEL]].

W poprzed­nim arty­ku­le napi­sa­łem, że…

Modele wyko­ny­wal­ne, w tym te two­rzo­ne auto­ma­tycz­nie na bazie mode­li abs­trak­cyj­nych, to narzę­dzia do two­rze­nia wyko­ny­wal­ne­go kodu. Nie tyl­ko w moim mnie­ma­niu, jest to albo dale­ka przy­szłość (mam na myśli komer­cyj­ne zasto­so­wa­nia) albo wyłącz­nie aka­de­mic­kie bada­nia. Wiem, że są uda­ne pró­by gene­ro­wa­nia dzia­ła­ją­ce­go kodu z mode­li, jed­nak wyma­ga­nia na ilość deta­li, jakie trze­ba zade­kla­ro­wać w tych mode­lach, zbli­ża ich zło­żo­ność do zło­żo­no­ści kodu jaki powsta­je. Nie będzie­my się tu zaj­mo­wa­li mode­la­mi wyko­ny­wal­ny­mi. (Źródło: MDA ? Cztery pro­duk­ty czy­li dwa eta­py: wyma­ga­nia i pro­dukt | | Jarosław Żeliński IT-Consulting)

Modele ana­li­tycz­ne, jak sama nazwa wska­zu­je, to mode­le któ­rych celem jest stwo­rze­nie abs­trak­cji, mode­lu pozwa­la­ją­ce­go na pro­wa­dze­nie ana­liz a nie uru­cha­mia­nie czy nawet symu­la­cja mode­lo­wa­nych kon­struk­cji. Każda ana­li­za to pra­ca z uprosz­cze­nia­mi. Te uprosz­cze­nia mają na celu pozby­cie się zbęd­nych szcze­gó­łów, tych nie­istot­nych dla dane­go bada­ne­go zagad­nie­nia. W nauce krą­ży powie­dze­nie „[[all models are wrong but some are use­ful]]” (każ­dy model jest zły ale nie­któ­re są przy­dat­ne), rzecz w tym, że model z zasa­dy jest uprosz­cze­niem czy­li w jakimś sen­sie jest to zepsu­ta rze­czy­wi­stość”. Jednak mode­le słu­żą do ana­liz tyl­ko w okre­ślo­nych kon­tek­stach, np. do bada­nia współ­czyn­ni­ka opo­ru powie­trza model samo­cho­du nie musi mieć sil­ni­ka, nawet nie musi nada­wać się do jeż­dże­nia, zaś rysu­nek tech­nicz­ny stro­pu wystar­czy do ana­li­zy jego wytrzymałości.

Popatrzmy na mode­le pro­ce­sów biz­ne­so­wych. Abstrakcją pro­ce­su biz­ne­so­we­go jest aktyw­ność mają­ca wej­ście i wyj­ście, to trzy ele­men­ty. Reszta szcze­gó­łów jest zbęd­na”, jeże­li celem ana­li­zy jest zro­zu­mie­nie mecha­ni­zmu funk­cjo­no­wa­nia orga­ni­za­cji. Detale reali­za­cji pro­ce­su pomi­ja­my, pozo­sta­wia­my w sfe­rze umie­jęt­no­ści wyko­naw­cy i ewen­tu­al­nych spi­sa­nych pro­ce­dur. Liczy się fakt wyko­ny­wa­nia nazwa­nej pra­cy (aktyw­ność) i jej cel oraz to co ją zaini­cjo­wa­ło. Na dia­gra­mie BPMN wej­ście i wyj­ście pro­ce­su biz­ne­so­we­go repre­zen­tu­je abs­trak­cja jaką jest sym­bol kart­ki z zagię­tym rogiem, abs­trak­cją pra­cy: aktyw­no­ści w pro­ce­sie, jest pro­sto­kąt z zaokrą­glo­ny­mi roga­mi. Analogicznie uprasz­cza­my rze­czy­wi­stość z uży­ciem innych nota­cji. Każda nota­cja ma swo­je prze­zna­cze­nie, każ­da nota­cja to okre­ślo­ny, dedy­ko­wa­ny sys­tem pojęciowy.

Poniżej dia­gram poka­zu­ją­cy, któ­re nota­cje mają roz­sze­rze­nia do budo­wa­nia wyko­ny­wal­no­ści oraz do cze­go i kie­dy są sto­so­wa­ne (i przeznaczone).

modele-analityczne-vs-wykonywalne

Na dia­gra­mie po pra­wej stro­nie umie­ści­łem dość popu­lar­ny obraz trzech pozio­mów mode­lo­wa­nia orga­ni­za­cji, ten pocho­dzi ze stro­ny (http://​www​.bptrend​sas​so​cia​tes​.com/). Wszystkie trzy pozio­my to abs­trak­cyj­ne mode­le budo­wa­ne z uży­ciem nota­cji wska­za­nych strzałkami.

Notacje zobra­zo­wa­ne na dia­gra­mie pozwa­la­ją na budo­wę mode­li ana­li­tycz­nych, koniecz­nych i wystar­cza­ją­cych zara­zem, do ana­liz o jakich tu pisze­my. Modele poję­cio­we i regu­ły biz­ne­so­we (SBVR) to szkie­let każ­de­go mode­lu ana­li­tycz­ne­go, ta nota­cja nie ma roz­sze­rzeń do budo­wy mode­li wyko­ny­wal­nych. Podobnie nota­cja BMM, któ­ra sta­no­wi model poję­cio­wy do opi­su stra­te­gii firm. BPMN na pozio­mie ana­li­zy biz­ne­so­wej, to model prze­pły­wu pra­cy a nie deta­licz­ny opis każ­dej czyn­no­ści. Celem mode­lo­wa­nia pro­ce­sów biz­ne­so­wych w ana­li­zie orga­ni­za­cji, jest ziden­ty­fi­ko­wa­nie prze­pły­wów pra­cy, ich pro­duk­tów i miejsc podej­mo­wa­nia decy­zji. CMMN (będzie o tej nota­cji za nie­dłu­go arty­kuł) to narzę­dzie doku­men­to­wa­nia warian­to­wych deta­li wybra­nych aktyw­no­ści w pro­ce­sach biz­ne­so­wych. UML to uni­wer­sal­na nota­cja (przy­po­mi­nam, że to to 13 typów dia­gra­mów), na eta­pie ana­liz i pro­jek­to­wa­nia sto­so­wa­na jest do two­rze­nia struk­tu­ral­nych mode­li sys­te­mów i mode­lo­wa­nia ich dynamiki.

Ten arty­kuł miał za zada­nie jedy­nie zwró­ce­nie uwa­gi na to, że wyko­ny­wa­nie zbyt szcze­gó­ło­wych mode­li w ana­li­zach i pro­jek­to­wa­niu nie jest koniecz­ne, a naj­czę­ściej bywa wręcz szko­dli­we. Stosowanie w mode­lach ana­li­tycz­nych, kon­struk­cji i ele­men­tów prze­zna­czo­nych do two­rze­nia mode­li wyko­ny­wal­nych, w zasa­dzie nale­ży uznać za błąd w uży­ciu nota­cji. Znanym z lite­ra­tu­ry przed­mio­tu powo­dem wie­lu pora­żek pro­jek­tów ana­li­tycz­nych jest mię­dzy inny­mi utra­ta pano­wa­nia nad szcze­gó­ło­wo­ścią pro­jek­tu. Warto o tym pamiętać…

Na koniec pole­cam wpis na blo­gu Martina Fowlera UML Mode

UML a modelowanie procesów biznesowych

Niedawno pisa­łem o UML v.2.51 i zasy­gna­li­zo­wa­łem, że

dia­gram aktyw­no­ści daje kon­tekst dla pojęć z gru­py ?acti­vi­ties? (aktyw­no­ści i czyn­no­ści oraz ich syn­tak­tycz­ne aso­cja­cje), dia­gram klas daje kon­tekst dla ?kla­sy­fi­ka­to­rów struk­tu­ral­nych?, itd. (Źródło: UML ver­sion 2.5 | | Jarosław Żeliński IT-Consulting)

Dzisiaj kil­ka słów na temat mode­lo­wa­nia pro­ce­sów biz­ne­so­wych w UML.

Cztery lata temu poru­sza­łem temat uży­cia UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych z uży­ciem mode­lu Eriksson-Penker’a:

Można się tak­że dość czę­sto spo­tkać z defi­ni­cją sze­ścio­ele­men­to­wą Erikssona-Penkera ([[Eriksson-Penker Business Modeling Profile]]). Tu mamy: Powyższy model bazu­je na uzna­niu, że pro­ces biz­ne­so­wy: ma cel, ma spe­cy­ficz­ne dane na wej­ściu, ma spe­cy­ficz­ne dane na wyj­ściu, wyma­ga zaso­bów, sta­no­wi ?wie­le czyn­no­ści do wyko­na­nia?, anga­żu­je róż­ne ?depar­ta­men­ty? w fir­mie (pozio­my prze­pływ), two­rzy jakąś war­tość dla klien­ta (wewnętrz­ne­go lub zewnętrz­ne­go). Problem jaki ja mam z tym wzor­cem to: wyma­ga nie­stan­dar­do­wych pojęć w UML. Profilowanie pole­ga na roz­bu­do­wie tak­so­no­mii zna­czeń (ste­reo­ty­py poka­zu­ją jakie pod­ty­py two­rzy­my dla dane­go typu), nie­ste­ty obiekt jako instan­cja kla­sy nie wytrzy­mu­je w moich oczach defi­ni­cji cze­goś tak abs­trak­cyj­ne­go jak cel biz­ne­so­wy(<>). Symbol pro­ce­su (tak zwa­ny pagon) tak­że nie jest poję­ciem z UML. Pojęcie Information jest tak pojem­ne, że w moich oczach jest wor­kiem, któ­ry pomie­ści wszyst­ko, a cechą dobrej nota­cji (for­mal­ne­go języ­ka, tak­że otwar­te­go) jest jed­nak wza­jem­ne wyklu­cza­nie się defi­ni­cji pojęć danej prze­strze­ni nazw (czy­li jeże­li coś jest np. Wejściem to już nie może być Informacją), na tej zasa­dzie nie rozu­miem też róż­ni­cy pomię­dzy celem pro­ce­su a jego wyj­ściem albo Aktorem z Zasobem (w koń­cu ludzie to zaso­by ludz­kie). (Źródło: Czym jest Piąty ele­ment ? Audyt orga­ni­za­cji czy­li ana­li­za biz­ne­so­wa | | Jarosław Żeliński IT-Consulting)

Generalnie więc jest to pomysł łamią­cy zasa­dy nota­cji… (pro­mo­wa­ny przez fir­mą SPARX, pro­du­cen­ta apli­ka­cji Enterprise Architect). Dość czę­sto spo­ty­kam się z tezą, że: UML posia­da bar­dzo istot­ną w kon­tek­ście prak­tycz­ne­go zasto­so­wa­nia cechę ? jest ela­stycz­ny. W zależ­no­ści od potrze­by, każ­de­mu jego ele­men­to­wi może zostać nada­ne nowe zna­cze­nie, two­rząc tym samym nowy ele­ment moż­li­wy do wyko­rzy­sta­nia pod­czas mode­lo­wa­nia.2 Niestety jest to bzdu­ra. UML ma bar­dzo ści­śle zde­fi­nio­wa­na seman­ty­kę. Owszem jest roz­sze­rzal­ny, ale roz­sze­rze­nie nota­cji to nie zmia­na zna­cze­nia sym­bo­li. Teza, że każ­de­mu jego ele­men­to­wi nota­cji UML może zostać nada­ne nowe zna­cze­nie” to cięż­ka here­zja (zresz­tą doty­czy to każ­dej notacji).

Popatrzmy jed­nak na UML, wer­sja 2.5 po upo­rząd­ko­wa­niu (wcze­śniej też dostęp­ne były te moż­li­wo­ści). Mamy w w niej dwa rodza­je pojęć mode­lu­ją­cych zacho­wa­nia”: aktyw­no­ści i czyn­no­ści (zada­nia). Oba poję­cia uży­wa­ne na Diagramach Aktywności. Aktywność jest poję­ciem szer­szym, ogól­niej­szym, zada­nie to ele­men­tar­ny krok jakiejś pro­ce­du­ry” (podob­nie zresz­tą jak w BPMN). W UML poję­cie aktyw­no­ści jest prze­zna­czo­ne do mode­lo­wa­nia pro­ce­dur w opro­gra­mo­wa­niu. Może tak­że być wyko­rzy­sty­wa­ne do mode­lo­wa­nie pro­ce­sów biz­ne­so­wych w orga­ni­za­cjach (patrz wytłuszczenia):

15 Activities
15.1 Summary
An Activity is a kind of Behavior (see sub clau­se 13.2) that is spe­ci­fied as a graph of nodes inter­con­nec­ted by edges. […] Activities may descri­be pro­ce­du­ral com­pu­ta­tion, for­ming hie­rar­chies of Activities invo­king other Activities, or, in an object-orien­ted model, they may be invo­ked indi­rec­tly as methods bound to Operations that are direc­tly invo­ked. Activities may be applied to orga­ni­za­tio­nal mode­ling for busi­ness pro­cess engi­ne­ering and work­flow. In this con­text, events often ori­gi­na­te from insi­de the sys­tem, such as the fini­shing of a task, but also from out­si­de the sys­tem, such as a custo­mer call. Activities can also be used for infor­ma­tion sys­tem mode­ling to spe­ci­fy sys­tem level pro­ces­ses. […]
15.6.3.1 Activity Partitions
An ActivityPartition is a kind of ActivityGroup for iden­ti­fy­ing ActivityNodes that have some cha­rac­te­ri­stics in com­mon. ActivityPartitions can sha­re con­tents. They often cor­re­spond to orga­ni­za­tio­nal units in a busi­ness model. They may be used to allo­ca­te cha­rac­te­ri­stics or reso­ur­ces among the nodes of an Activity.

W UML 2.5 jaw­nie roz­dzie­lo­no poję­cia Activities i Actions. Aktywności nale­ży rozu­mieć jako pro­ce­du­ry (abs­trak­cje jakichś dzia­łań), czyn­no­ści zaś jako ato­mo­we ope­ra­cje (kolej­ne kro­ki pro­ce­dur). Dla porów­na­nia kolej­ny frag­ment spe­cy­fi­ka­cji UML:

16 Actions
16.1 Summary
An Action is the fun­da­men­tal unit of beha­vior spe­ci­fi­ca­tion in UML. An Action may take a set of inputs and pro­du­ce a set of out­puts, tho­ugh either or both of the­se sets may be emp­ty. Some Actions may modi­fy the sta­te of the sys­tem in which the Action exe­cu­tes. Actions are con­ta­ined in Behaviors, spe­ci­fi­cal­ly Activities (as ExecutableNodes, see Clause 15) and Interactions (see Clause 17). These Behaviors deter­mi­ne when Actions exe­cu­te and what inputs they have. However, the abs­tract syn­tax and seman­tics of Actions are very depen­dent on Activities, becau­se they spe­cia­li­ze ele­ments and seman­tics from Activities to accept inputs and pro­vi­de out­puts and to defi­ne Actions that coor­di­na­te other Actions (Structured Actions, see sub clau­se 16.11). In addi­tion, the con­cre­te syn­tax for Actions only appe­ars in Activity dia­grams (all the exam­ples in this Clause use Activity nota­tion), and some of the nota­tion for Actions is spe­ci­fied in Clause 15. This Clause focu­ses on the syn­tax and seman­tics of Actions spe­ci­fi­cal­ly, rather than the Behaviors that con­ta­in them, but must be read in con­junc­tion with Clause 15.

Tak więc jeże­li chce­my legal­nie” mode­lo­wać pro­ce­sy biz­ne­so­we z uży­ciem UML, to był­by to dia­gram aktyw­no­ści z uży­ciem pojęć Activities i ActivityPartitions. Procedury (i algo­ryt­my) mode­lu­je­my z uży­ciem poję­cia Action. Porównując ten dia­gram i te poję­cia z BPMN widać wyż­szość tej dru­giej nota­cji. Po pierw­sze BPMN, ope­ru­jąc poję­cia­mi zda­rze­nie i bram­ka zda­rze­nio­wa, dosko­na­le daje sobie radę z mode­lo­wa­niem fak­tów w biz­ne­sie, po dru­gie – jak poka­zu­je prak­ty­ka – seman­ty­ka i gra­fi­ka BPMN jest łatwa do zro­zu­mie­nia dla odbior­cy biz­ne­so­we­go, cze­go dowo­dzi szyb­ki wzrost popu­lar­no­ści BPMN wśród ludzi biz­ne­su” i nadal zni­ko­my zakres sto­so­wa­nia UML w tej grupie.

Na koniec jesz­cze jed­na rzecz: kom­plet­nie nie rozu­miem uży­wa­nia poję­cia Przypadków Użycia UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Nie znaj­du­je ono żad­ne­go uza­sad­nie­nia w seman­ty­ce UML. W spe­cy­fi­ka­cji UML czytamy:

18 UseCases
18.1 Use Cases
18.1.1 Summary UseCases are a means to cap­tu­re the requ­ire­ments of sys­tems, i.e., what sys­tems are sup­po­sed to do. The key con­cepts spe­ci­fied in this clau­se are Actors, UseCases, and sub­jects. Each UseCase?s sub­ject repre­sents a sys­tem under con­si­de­ra­tion to which the UseCase applies. Users and any other sys­tems that may inte­ract with a sub­ject are repre­sen­ted as Actors. A UseCase is a spe­ci­fi­ca­tion of beha­vior. An instan­ce of a UseCase refers to an occur­ren­ce of the emer­gent beha­vior that con­forms to the cor­re­spon­ding UseCase. Such instan­ces are often descri­bed by Interactions.

Tak więc Przypadek Użycia to WYŁĄCZNIE kon­kret­ne zacho­wa­nie (reak­cja na bodziec) sys­te­mu defi­nio­wa­ne­go (spe­cy­fi­ko­wa­ne­go). Specyfikacje tych zacho­wań to inte­rak­cje. Ciągnące się od lat w krę­gach wywo­dzą­cych się z metod RUP (Rational Unified Process3) poję­cie Biznesowych Przypadków Użycia jest w moich oczach, i nie tyl­ko, zaka­łą bran­ży. Od cza­su gdy powstał UML 0.9 jako jeden zestaw metod mode­lo­wa­nia, nigdy w spe­cy­fi­ka­cji UML OMG nie było mowy o Biznesowych Przypadkach Użycia. Pojęcia te są tak samo nie­zgod­ne z UML jak wcze­śniej wymie­nio­ne pomy­sły SPARX i pro­fil Eriksson-Penker’a. Jeżeli może­my coś ze sobą porów­nać to ele­men­tar­ny pro­ces biz­ne­so­wy i przy­pa­dek uży­cia, ale pod jed­nym warun­kiem: że odwzo­ro­wu­je­my (mapu­je­my) kon­kret­ny ele­men­tar­ny (ato­mo­wy) pro­ces biz­ne­so­wy w apli­ka­cji na kon­kret­ny przy­pa­dek uży­cia, o czym pisa­łem w arty­ku­le o trans­for­ma­cji pro­ce­sów biz­ne­so­wych na przy­pad­ki uży­cia.

Tak więc sto­so­wa­nie UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych jest moż­li­we z uży­ciem dia­gra­mu aktyw­no­ści i pojęć acti­vi­ties. Stosowanie przy­pad­ków uży­cia UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych nie ma żad­ne­go seman­tycz­ne­go uza­sad­nie­nia, co widać jak na dło­ni w spe­cy­fi­ka­cji UML. Tak więc zostaw­my UML do zorien­to­wa­ne­go obiek­to­wo mode­lo­wa­nia sys­te­mów i BPMN do pro­ce­so­wo zorien­to­wa­nych mode­li orga­ni­za­cji. Obiektowe mode­le orga­ni­za­cji jak naj­bar­dziej mają sens, są to mode­le dzie­dzi­ny mode­lo­wa­nej orga­ni­za­cji, wyko­rzy­sty­wa­ne jako model logi­ki biz­ne­so­wej w two­rze­niu oprogramowania.