Diagram Przypadków Użycia UML

Wstęp

Jest to dia­gram, któ­ry na rów­ni z Diagramem Klas, budzi bar­dzo czę­sto ogrom­ne pro­ble­my inter­pre­ta­cyj­ne (patrz: Diagram klas…). Bardzo wie­lu auto­rów przy­pi­su­je temu dia­gra­mo­wi role, któ­rych on nie peł­ni, a nie raz pre­zen­to­wa­ne w sie­ci i lite­ra­tu­rze przy­kła­dy są nie­po­praw­ne. Znakomita więk­szość auto­rów tych dia­gra­mów uży­wa ich jako zbio­ru moż­li­wych klik­nięć” co jest cał­ko­wi­tym nie­zro­zu­mie­niem celu uży­cia i idei tego dia­gra­mu. Nawet jeże­li ktoś potrze­bu­je takiej mapy kli­ka­nia, to są do tego lep­szych narzę­dzia i meto­dy (przy­kład: Mapa ekra­nów apli­ka­cji – pod­sta­wa dobre­go UX/UI design). Tworzenie nie­zgod­nych z nota­cją dia­gra­mów przy­pad­ków uży­cia po pro­stu psu­je struk­tu­rę pro­jek­tu w narzę­dziach CASE, czy­niąc ją prak­tycz­nie bez­u­ży­tecz­ną w pro­jek­to­wa­nia archi­tek­tu­ry systemu. 

Najpierw opi­szę krót­ko dia­gram przy­pad­ków uży­cia posłu­gu­jąc sie cyta­ta­mi z ory­gi­nal­nej spe­cy­fi­ka­cji. Później opi­szę typo­we błędy. 

Czym jest Diagram Przypadków Użycia

Kluczowe są tu wyja­śnie­nia wstę­pu do roz­dzia­łu UseCases Specyfikacji UML :

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.
[…]
18.1.3 Semantics
18.1.3.1 Use Cases and Actors
A UseCase may apply to any num­ber of sub­jects. When a UseCase applies to a sub­ject, it spe­ci­fies a set of beha­viors per­for­med by that sub­ject, which yields an obse­rva­ble result that is of value for Actors or other sta­ke­hol­ders of the sub­ject. A UseCase is a kind of BehavioredClassifier that repre­sents a dec­la­ra­tion of a set of offe­red Behaviors. Each UseCase spe­ci­fies some beha­vior that a sub­ject can per­form in col­la­bo­ra­tion with one or more Actors. UseCases defi­ne the offe­red Behaviors of the sub­ject witho­ut refe­ren­ce to its inter­nal structure.

Powyższe wytłusz­cze­nia zebra­łem poni­żej, uwa­gi ozna­czo­ne „[…]” są moje:

  1. Przypadki uży­cia są spo­so­bem na uchwy­ce­nie [wska­za­nie] wyma­gań sta­wia­nych sys­te­mom, tzn. tego, co sys­te­my mają robić [powo­dy, dla któ­rych one powsta­ną, co będą reali­zo­wa­ły na rzecz i na żąda­nie Aktora].
  2. Każdy Przypadek Użycia repre­zen­tu­je okre­ślo­ny cel (powód), dla któ­re­go System jest projektowany. 
  3. Przypadek Użycia jest rodza­jem kla­sy­fi­ka­to­ra beha­wio­ral­ne­go, któ­ry repre­zen­tu­je dekla­ra­cję zbio­ru ofe­ro­wa­nych zacho­wań. [to zna­czy, że gru­pu­je okre­ślo­ny kon­tek­sto­wo powią­za­ny zbiór zacho­wań, są to alter­na­tyw­ne sce­na­riu­sze tego same­go przy­pad­ku użycia].
  4. Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia [mode­lo­wa­ne­go] sys­te­mu bez odwo­ły­wa­nia się do jego wewnętrz­nej struktury. (!)

Są to pryn­cy­pia budo­wy tych diagramów.

Związki między Przypadkami Użycia

Extend

Specyfikacja UML:

An Extend is a rela­tion­ship from an exten­ding UseCase (the exten­sion) to an exten­ded UseCase (the extendedCase) that spe­ci­fies how and when the beha­vior defi­ned in the exten­ding UseCase can be inser­ted into the beha­vior defi­ned in the exten­ded UseCase. The exten­sion takes pla­ce at one or more spe­ci­fic exten­sion points defi­ned in the exten­ded UseCase. Extend is inten­ded to be used when the­re is some addi­tio­nal beha­vior that sho­uld be added, possi­bly con­di­tio­nal­ly, to the beha­vior defi­ned in one or more UseCases.

Związku «extend» moż­na użyć do poka­za­nia, że pew­ne ele­men­ty zacho­wa­nia Systemu reali­zo­wa­ne są warun­ko­wo. Te dodat­ko­we zacho­wa­nia są jed­nak z zasa­dy czę­ścią bazo­we­go Przypadku Użycia.

Autorzy spe­cy­fi­ka­cji UML jasno piszą, że: Szczegółowy spo­sób okre­śla­nia poło­że­nia punk­tu roz­sze­rzeń jest celo­wo nie­okre­ślo­ny. Wynika to z fak­tu, że Przypadki uży­cia mogą być spe­cy­fi­ko­wa­ne w róż­nych for­ma­tach, takich jak język natu­ral­ny, tabe­le, drze­wa itp. […] Zazwyczaj, przy­pa­dek uży­cia z ExtensionPoints skła­da się z zesta­wu drob­no­ziar­ni­stych opi­sów frag­men­tów zacho­wa­nia (sce­na­riu­sze), któ­re są naj­czę­ściej wyko­ny­wa­ne w pew­nej sekwen­cji. Taka seg­men­to­wa struk­tu­ra tek­stu opi­su dane­go przy­pad­ku uży­cia pozwa­la na roz­sze­rze­nie pier­wot­ne­go opi­su zacho­wa­nia przez dołą­cza­nie dodat­ko­wych opi­sów, frag­men­tów zacho­wa­nia, w odpo­wied­nich punk­tach wsta­wia­ne pomię­dzy pier­wot­ne frag­men­ty (punk­ty roz­sze­rzeń). Tak więc, roz­sze­rze­nie UseCase skła­da się zwy­kle z jed­ne­go lub wię­cej opi­sów frag­men­tów zacho­wa­nia, któ­re mają być wsta­wio­ne w odpo­wied­nie miej­sca roz­sze­rza­ne­go przy­pad­ku uży­cia. Rozszerzenia są więc spe­cy­fi­ka­cją wszyst­kich róż­nych punk­tów roz­sze­rzeń w danym przy­pad­ku uży­cia, w któ­rych moż­na umie­ścić dodat­ko­we zachowania.”

Innymi sło­wy, for­mal­nie moż­na na Diagramie Przypadków Użycia poka­zać, to że sce­na­riusz przy­pad­ku uży­cia jest podzie­lo­ny na frag­men­ty, któ­re są wyko­ny­wa­ne warun­ko­wo. Jest to jed­nak mode­lo­wa­nie sce­na­riu­sza zawie­ra­ją­ce­go instruk­cje if … then”. Tu przy­po­mnę więc klu­czo­wą zasa­dę, zapi­sa­ną w spe­cy­fi­ka­cji UML: Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia [mode­lo­wa­ne­go] przed­mio­tu bez odwo­ły­wa­nia się do jego wewnętrz­nej struk­tu­ry”. Dlatego wie­lu auto­rów zwra­ca uwa­gę na pew­ne, takie jak ta, nie­kon­se­kwen­cje w specyfikacji. 

Include

Specyfikacja UML:

The Include rela­tion­ship is inten­ded to be used when the­re are com­mon parts of the beha­vior of two or more UseCases. This com­mon part is then extrac­ted to a sepa­ra­te UseCase, to be inc­lu­ded by all the base UseCases having this part in com­mon. As the pri­ma­ry use of the Include rela­tion­ship is for reu­se of com­mon parts, what is left in a base UseCase is usu­al­ly not com­ple­te in itself but depen­dent on the inc­lu­ded parts to be meaning­ful. This is reflec­ted in the direc­tion of the rela­tion­ship, indi­ca­ting that the base UseCase depends on the addi­tion but not vice versa.

Innymi sło­wy: jeże­li dwa Przypadki Użycia mają pew­ne wspól­ne frag­men­ty zacho­wa­nia, moż­na taki frag­ment wyjąć przed nawias”, ten frag­ment jest na dia­gra­mie repre­zen­to­wa­ny tak­że jako Przypadek Użycia, jed­nak jest to nie­sa­mo­dziel­ny frag­ment, sta­no­wią­cy część wspól­ną co naj­mniej dwóch PU bazo­wych i on sam z sie­bie nie repre­zen­tu­je samo­dziel­ne­go zacho­wa­nia. Ten wspól­ny, wyłą­czo­ny frag­ment, łączy­my z PU bazo­wy­mi związ­kiem «inc­lu­de».

Tak więc związ­ki «inc­lu­de» i «extend» owszem nadal są w spe­cy­fi­ka­cji UML, jed­nak Wynika to z fak­tu, że Przypadki uży­cia mogą być spe­cy­fi­ko­wa­ne w róż­nych for­ma­tach, takich jak język natu­ral­ny, tabe­le, drze­wa itp.” i ktoś może chcieć taki tek­sto­wy for­mat zobra­zo­wać na Diagramie. 

Konsekwencje

Diagram Przypadków uży­cia ma rodo­wód w meto­dy­ce struk­tu­ral­nej (sto­so­wa­nie instruk­cji go to” i sub­ro­uti­ne” w pro­gra­mo­wa­niu struk­tu­ral­nym). Związki «extend» i «inc­lu­de» mają wła­śnie taki rodo­wód i nadal są w nota­cji UML, gdyż Diagram Przypadków Użycia jest nadal popu­lar­nym narzę­dziem w meto­dach struk­tu­ral­nych. Jest też nie­kon­se­kwen­cją spe­cy­fi­ka­cji UML, co widać w jej tre­ści, gdzie na począt­ku roz­dzia­łu auto­rzy spe­cy­fi­ka­cji UML zwra­ca­ją jed­nak uwa­gę, że Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia przed­mio­tu bez odwo­ły­wa­nia się do jego wewnętrz­nej struk­tu­ry”. Więc sto­so­wa­nie powyż­szych związ­ków jest relik­tem metod struk­tu­ral­nych, i nie nale­ży ich sto­so­wać w pro­jek­tach zorien­to­wa­nych obiek­to­wo, tym bar­dziej, że jest to łama­nie pod­sta­wo­wej zasa­dy para­dyg­ma­tu obiek­to­we­go jaką jest hermetyzacja. 

Autorzy spe­cy­fi­ka­cji nota­cji UML, takim oto przy­kła­dem pod­su­mo­wu­ją roz­dział 18. Przypadki Użycia:

Jak widać celem pro­jek­to­wa­nia ban­ko­ma­tu są: Wypłata, Wpłata, Przelew, a tak­że: Rejestrowanie ban­ko­ma­tu (w sie­ci) i Udostępnianie listy trans­ak­cji. Detale tych dzia­łań i kolej­ność ich reali­za­cji nie są przed­mio­tem tego mode­lu, nie ma tu związ­ków «inc­lu­de» ani «extend», mimo, że np. trzy klu­czo­we ope­ra­cje wyma­ga­ją uży­cia kar­ty płat­ni­czej i kodu PIN (owszem, wspól­na część, ale są to jed­nak deta­le sce­na­riu­szy a nie osob­ne PU).

Traktując więc PU zgod­nie z jego pod­sta­wo­wą, przy­to­czo­ną powy­żej defi­ni­cją, jako: okre­ślo­ny cel (powód), dla któ­re­go System jest pro­jek­to­wa­ny”, uzna­je­my, że celem apli­ka­cji biz­ne­so­wej jest np. Rejestrowanie Zamówień czy Fakturowanie, a nie to, że Drukujemy doku­ment”, szu­ka­my fak­tu­ry” czy wpro­wa­dza­my NIP kon­tra­hen­ta”. Pokazanie dru­ko­wa­nia jako wyłą­czo­nej czę­ści wspól­nej, lub roz­sze­rze­nia, PU Faktura i Zamówienie (sto­su­jąc zwią­zek «inc­lu­de» lub «extend»), czy też wydzie­la­nie na dia­gra­mie PU Wybór klien­ta z listy kon­tra­hen­tów”, to pro­jek­to­wa­nie archi­tek­tu­ry i dro­ga do klę­ski tego dia­gra­mu. To, że kom­po­nent reali­zu­ją­cy dru­ko­wa­nie będzie osob­nym ele­men­tem archi­tek­tu­ry tego sys­te­mu zapew­ne jest praw­dą, ale Diagram PU, jak już wie­my, to nie jest model archi­tek­tu­ry sys­te­mu. Nie jest to tak­że spe­cy­fi­ka­cja pro­ce­su biznesowego.

Obiektowo-zorientowane modelowanie systemu

W arty­ku­le Use Case 2.0 opi­sy­wa­łem kon­cep­cję obiek­to­we­go podej­ścia w pro­jek­to­wa­niu zorien­to­wa­nym na Przypadki Użycia, opra­co­wa­ną przez jed­ne­go z współ­twór­ców UML: Ivara Jacobsona . W arty­ku­le Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych opi­sa­łem pro­jek­to­wa­nie opro­gra­mo­wa­nia opar­te na obiek­to­wym para­dyg­ma­cie i wzor­cach pro­jek­to­wych takich jak mikro­ser­wi­sy. Cytowałem mię­dzy inny­mi ten diagram:

Po pra­wej stro­nie powyż­sze­go widzi­my archi­tek­tu­rę zorien­to­wa­ną na mikro­ser­wi­sy. Jest to typo­we i zna­ne od lat kom­po­nen­to­we podej­ście z her­me­ty­za­cją kom­po­nen­tów, reali­zu­ją­cych usłu­gi apli­ka­cji . Bloki [MS] (micro­se­rvi­ces) to nic inne­go jak kom­po­nen­ty reali­zu­ją­ce Przypadki Użycia tego sys­te­mu. Każdy PU ma wła­sną imple­men­ta­cję (i bazę danych, dane [DB] tak­że nie są współ­dzie­lo­ne mię­dzy przy­pad­ka­mi uży­cia). Komponent [UI] to zagre­go­wa­ne na jed­nym ekra­nie wywo­ła­nia usług, czy­li głów­ne menu sys­te­mu. Tak więc Diagram Przypadków Użycia, to model tego głów­ne­go menu sys­te­mu, a nie model imple­men­ta­cji usług (nie archi­tek­tu­ra kodu i nie pro­ces biznesowy).

Podsumowanie

Na poniż­szym dia­gra­mie po lewej stro­nie, poka­za­no for­mal­nie popraw­ny dia­gram przy­pad­ków uży­cia. Z per­spek­ty­wy pro­jek­to­wa­nia zorien­to­wa­ne­go na kom­po­nen­ty, oraz zacho­wa­nia zasa­dy mówią­cej, że ten dia­gram nie słu­ży do mode­lo­wa­nia wewnętrz­nej archi­tek­tu­ry sys­te­mu, popraw­na pro­jek­to­wo jest wer­sja poka­za­na po pra­wej stronie:

Warto też wie­dzieć, że w kon­se­kwen­cji powyż­sze­go, łącze­nie Aktora z wydzie­lo­ny­mi, nie­sa­mo­dziel­ny­mi, opi­sa­mi zacho­wań repre­zen­to­wa­ny­mi przez przy­pad­ki uży­cia 4 i 5, jest pozba­wio­ne logi­ki (podob­nie jak tyl­ko jeden PU połą­czo­ny związ­kiem «inc­lu­de»).

Więc jak i gdzie poka­zać owe sce­na­riu­sze PU? Osobno na dia­gra­mach aktyw­no­ści (role kom­po­nen­tów) lub na dia­gra­mach sekwen­cji (wywo­ły­wa­ne ope­ra­cje inter­fej­sów). (Patrz arty­kuł: Diagram aktyw­no­ści – kie­dy).

Powyższa for­ma (dia­gram po pra­wej stro­nie) ma tak­że prak­tycz­ną zale­tę: Zamawiający zro­zu­mie ten dia­gram. Diagram o po lewej, jest już prak­tycz­ną utra­tą komu­ni­ka­cji z Zamawiającym, bo mało któ­ry z nich stu­diu­je spe­cy­fi­ka­cję UML. Specyfikacja po lewej pro­wa­dzi tak­że do ogrom­ne­go zawy­ża­nia osza­co­wa­nia wycen, gdyż mia­ry opar­te na tak zwa­nych punk­tach funk­cyj­nych, trak­tu­ją każ­dy PU jako samo­dziel­ną, kom­plet­ną jed­ną jed­nost­kę kosztową. 

A co może­my zna­leźć w sie­ci? Poniżej kil­ka przy­kła­dów wraz ze źró­dła­mi, ich oce­nę pozo­sta­wię czytelnikom. 

przykład 1

Major elements of business use case UML diagram.

(w nota­cji UML nie ma i nigdy nie było poję­cia biz­ne­so­wy przy­pa­dek uży­cia”, to poję­cie jest relik­tem meto­dy RUP, Rational Unified Process, z cza­sów gdy nie było nota­cji BPMN i BMM).

przykład 2

Major elements of UML use case diagram.

przykład 3

przykład 4

(źr.: Podstawy mode­lo­wa­nia w języ­ku UML, dr hab. Bożena Woźna-Szcześniak, prof. UJD, Uniwersytet Humanistyczno-Przyrodniczy im. Jana Długosza w Częstochowie, http://​www​.wozna​.org/​s​t​u​d​e​n​t​s​/​2​018 – 2019/uml/UML03.pdf)

Dla porów­na­nia do pobra­nia: Biblioteka

przykład 5

przykład 6

(źr.: Projektowanie Systemów Komputerowych, Laboratoria/Projekty, Krzysztof Regulski, AGH, WIMiIP, DIAGRAM PRZYPADKÓW UŻYCIA – USE CASE MODEL, https://home.agh.edu.pl/~regulski/psk/cw/01_UseCase.pdf)

___

Na koniec pole­cam też arty­kuł: Ile przy­pad­ków uży­cia?

Źródła

D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116.
OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Wzorce projektowe Książki

Wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

Analiza biz­ne­so­wa i projektowanie

Wstęp

W arty­ku­le o apli­ka­cjach webo­wych, ponad rok temu, pisałem:

Generalnie klu­czo­wą cechą micro-ser­wi­­sów, czy­nią­cą z nich tak zwa­ną zwin­ną archi­tek­tu­rę, jest cał­ko­wi­ta wza­jem­na nie­za­leż­ność imple­men­ta­cji poszcze­gól­nych usług apli­ka­cyj­nych. (źr.: Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych).

Przy innej oka­zji pisa­łem o wzorcach:

Wzorce pro­jek­to­we to bar­dzo waż­na część ??zawo­du? ana­li­ty­ka i archi­tek­ta opro­gra­mo­wa­nia. […] Generalnie wzor­ce są to ska­ta­lo­go­wa­ne stan­dar­dy i dobre prak­ty­ki . (Obiektowe wzor­ce projektowe ) 

Szkolenia dla ana­li­ty­ków poprze­dzam ankie­ta­mi przed szko­le­nio­wy­mi, jak do tej pory żad­na nie zawie­ra­ła pytań o wzor­ce pro­jek­to­we: ani tego że są uży­wa­ne ani tego, że są celem szko­le­nia, nie­mal­że każ­dy dekla­ru­je albo, że uży­wa UML lub, że chce zacząć uży­wać UML, nawet gdy są to pro­gra­mi­ści. Zauważyłem, że wzor­ce pro­jek­to­we w świa­do­mo­ści ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia (OOAD) nie ist­nie­ją”. Wśród pro­gra­mi­stów, jeże­li jest spo­ty­ka­na, to wie­dza o wzor­cach przy­dat­nych w two­rze­niu biblio­tek i narzę­dzi, czę­sto też powie­la­ne są wyuczo­ne sta­re i złe prak­ty­ki pro­gra­mi­stycz­ne rodem z lat 60-tych (np. prak­ty­ki SmallTalk, patrz dalej). 

Z dru­giej stro­ny od wie­lu lat zna­ne są tech­ni­ki MDA (Model Driven Architecture) czy MBSE (Model Based System Engineering), któ­re w róż­nych for­mach, ale jed­nak wska­zu­ją, że naj­sku­tecz­niej­sza for­ma wyra­ża­nia wyma­gań wobec roz­wią­za­nia to pro­jekt archi­tek­tu­ry i logi­ki dzie­dzi­no­wej (model) dzia­ła­nia apli­ka­cji . O pro­jek­to­wa­niu poprze­dza­ją­cym imple­men­ta­cję pisze sie od dość daw­na, meto­dy obiek­to­we i dobre prak­ty­ki zna­ne są od lat .

Autorzy BABoK prak­tycz­nie od począt­ku ist­nie­nia tego wydaw­nic­twa, zwra­ca­ją uwa­gę na tak zwa­ną bia­łą skrzyn­kę”, czy­li wyma­ga­nia wyra­żo­ne w posta­ci wewnętrz­nej struk­tu­ry pro­duk­tu, wska­zu­jąc, że to znacz­nie sku­tecz­niej­sza meto­da defi­nio­wa­nia wyma­gań wobec roz­wią­za­nia, niż tak zwa­na czar­na skrzyn­ka”, czy­li tra­dy­cyj­ne, i jed­nak mniej sku­tecz­ne, wyma­ga­nia wyra­żo­ne tyl­ko jako cechy funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Pamiętajmy, że adre­sa­tem wyma­gań jest zawsze dostaw­ca produktu!

Czytaj dalej… Wzorce pro­jek­to­we w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny sys­te­mu”

Diagram aktywności UML – kiedy

Wstęp

Od cza­su do cza­su jestem pyta­ny o to, kie­dy uży­wać dia­gra­mu aktyw­no­ści UML. Od 2015 roku spe­cy­fi­ka­cja UML wska­zu­je, że dia­gra­my te są narzę­dziem mode­lo­wa­nia metod czy­li logi­ki kodu (dla Platform Independent Model): aktyw­no­ści (acti­vi­ties) to nazwy metod, zadania/kroki (actions) to ele­men­ty kodu (przy­kła­dy w dal­szej części). 

Gdy powsta­wał UML, dia­gra­my aktyw­no­ści były uży­wa­ne tak­że do mode­lo­wa­nie pro­ce­sów biz­ne­so­wych. W roku 2004 opu­bli­ko­wa­no spe­cy­fi­ka­cję nota­cji BPMN, któ­ra w zasa­dzie do roku 2015 prze­ję­ła” po UML funk­cję narzę­dzia mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. W 2015 roku for­mal­nie opu­bli­ko­wa­no spe­cy­fi­ka­cję UML 2.5, gdzie gene­ral­nie zre­zy­gno­wa­no z uży­wa­nia UML do mode­li CIM. Obecnie Mamy usta­bi­li­zo­wa­ną sytu­ację w lite­ra­tu­rze przed­mio­tu: BPMN wyko­rzy­stu­je­my w mode­lach CIM (mode­le biz­ne­so­we), UML w mode­lach PIM i PSM jako mode­le opro­gra­mo­wa­nia (a mode­le sys­te­mów: SysML, pro­fil UML). 

Na prze­ło­mie lat 80/90-tych roz­po­czę­to pra­ce nad stan­da­ry­za­cję nota­cji mode­lo­wa­nia obiek­to­we­go, w 1994 opu­bli­ko­wa­no UML 0.9, w 2001 roku poja­wia­ją się pierw­sze publi­ka­cje o pra­cach nad nota­cją BPMN, jed­no­cze­śnie poja­wia się Agile Manifesto, od 2004 roku ma miej­sce spa­dek zain­te­re­so­wa­nia doku­men­to­wa­niem pro­jek­tów pro­gra­mi­stycz­nych, w 2004 rok publi­ko­wa­no spe­cyf­ka­cję BPMN 1.0, od tego roku ma miej­sce wzrost zain­te­re­so­wa­nia mode­lo­wa­niem pro­ce­sów biz­ne­so­wych, powo­li sta­bi­li­zu­je się obszar zasto­so­wa­nia nota­cji UML. W 2015 roku opu­bli­ko­wa­no UML 2.5, sto­so­wa­nie ana­li­zy (CIM) i i pro­jek­to­wa­nia (PIM), jako eta­pu poprze­dza­ją­ce­go imple­men­ta­cje, sta­ło się stan­dar­dem (źr. wykre­su: Google Ngram).

Tak więc obecnie: 

Nie uży­wa­my dia­gra­mów aktyw­no­ści do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Do tego słu­ży nota­cja BPMN!

Diagram aktyw­no­ści może być mode­lem kodu na wyso­kim lub niskim pozio­mie abs­trak­cji, ope­ru­je­my wte­dy odpo­wied­nio aktyw­no­ścia­mi (acti­vi­ty) lub dzia­ła­nia­mi (actions). Te ostat­nie to w zasa­dzie repre­zen­ta­cja pole­ceń programu. 

Nie ma cze­goś takie­go jak pro­ces sys­te­mo­wy”, opro­gra­mo­wa­nie reali­zu­je pro­ce­du­ry”.

Projektując opro­gra­mo­wa­nie zgod­nie ze SPEM , powsta­je Platform Independent Model. W prak­ty­ce już na tym eta­pie pro­gra­mu­je­my, bo two­rzy­my logi­kę i obraz przy­szłe­go kodu. Taka for­ma doku­men­to­wa­nia pozwa­la tak­że lepiej chro­nic war­to­ści inte­lek­tu­al­ne zamawiającego.

Czytaj dalej… Diagram aktyw­no­ści UML – kie­dy”

Studium wykonalności c.d. czyli analiza systemowa rozwiązania

Wprowadzenie

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

W roku 2014 w arty­ku­le Studium wyko­nal­no­ści pro­duk­tu – czym napraw­dę jest napi­sa­łem na zakończenie:

W lite­ra­tu­rze moż­na spo­tkać róż­ne ?defi­ni­cje? stu­dium wyko­nal­no­ści, jed­nak ta któ­rą opi­sa­łem, zda­je się być naj­bliż­sza defi­ni­cji, któ­rą przy­to­czy­łem na począt­ku: bazu­ją­cej na zna­cze­niu słow­ni­ko­wym. Praktyka poka­zu­je, że inten­cje spon­so­rów tych ana­liz są z nią zbież­ne: celem jest pod­ję­cie decy­zji o naj­mniej­szym ryzy­ku w świe­tle posia­da­nej na dany temat wiedzy.

Definicje bazu­ją­ce na tech­nicz­nej i finan­so­wej wyko­nal­no­ści dane­go pro­jek­tu, są spo­ty­ka­ne dość czę­sto i w lite­ra­tu­rze i na stro­nach wie­lu insty­tu­cji. Metoda pro­wa­dze­nia takich ana­liz, bazu­ją­ca na mode­lo­wa­niu czy­li na ana­li­zie sys­te­mo­wej, wyda­je się być jed­nak najwłaściwszą.

Warto jed­nak zwró­cić uwa­gę, że wyko­nal­ność tech­nicz­na a zdol­ność do sfi­nan­so­wa­nia to nie to samo? Studium wyko­nal­no­ści tech­no­lo­gicz­nej doty­czy pro­duk­tu pro­jek­tu lub efek­tu orga­ni­za­cyj­ne­go jakie­go ocze­ku­je­my. Ocena tego czy pozy­ska­my finan­so­wa­nie to nie wyko­nal­ność a zdol­ność do sfi­nan­so­wa­nia (stu­dium wyko­nal­no­ści finan­so­wo-eko­no­micz­nej). To są róż­ne analizy.

To był arty­kuł o ogól­nych zasa­dach reali­za­cji ana­li­zy jaką jest stu­dium wyko­nal­no­ści. Tym razem o tym, czym kon­kret­nie jest etap czę­sto nazy­wa­ny Identyfikacją pro­jek­tu i czym zaj­mu­je się jako ana­li­tyk w takich pro­jek­tach.

Struktura analizy

Kontynuując wątek stu­dium wyko­nal­no­ści, opra­co­wa­nie takie moż­na zobra­zo­wać tak:

Każda inwe­sty­cja ma cha­rak­ter mate­rial­ny i finan­so­wy. Materialny doty­czy przed­mio­tu inwe­sty­cji (nowy lub zmie­nia­ny sys­tem) zaś finan­so­wy doty­czy kosz­tu jego pozy­ska­nia lub zmiany. 

Moja pra­ca to opra­co­wa­nie Modelu sys­te­mu. Potrzebuję do tego eks­per­ta dzie­dzi­no­we­go. Analiza finan­so­wa i opis finan­so­wa­nia, powsta­ją na pod­sta­wie Modelu. Całość dopie­ro sta­no­wi sobą Studium Wykonalności (nie licząc oczy­wi­ście same­go wnio­sku, któ­ry opra­co­wu­je wnioskujący).

Wymagania formalne

Instrukcje dla wnio­sko­daw­ców (np. Instrukcja spo­rzą­dza­nia Studium Wykonalności Inwestycji (Projektu) dla wnio­sko­daw­ców ubie­ga­ją­cych się o wspar­cie z Europejskiego Funduszu Rozwoju Regionalnego w ramach Regionalnego Programu Operacyjnego Województwa Świętokrzyskiego na lata 2014 – 2020, dalej Instrukcja) zawie­ra­ją mię­dzy inny­mi takie zalecenia: 

Identyfikacja pro­jek­tu powin­na dostar­czyć zwię­złej i jed­no­znacz­nej infor­ma­cji na temat jego cało­ścio­wej kon­cep­cji i logicz­nych ram. Projekt powi­nien sta­no­wić samo­dziel­ną (pod kątem ope­ra­cyj­no­ści) jed­nost­kę ana­li­zy. Oznacza to, że powi­nien on obej­mo­wać wszyst­kie zada­nia inwe­sty­cyj­ne, któ­re spra­wia­ją, że efek­tem reali­za­cji pro­jek­tu jest stwo­rze­nie w peł­ni funk­cjo­nal­nej i ope­ra­cyj­nej infra­struk­tu­ry, bez koniecz­no­ści reali­za­cji dodat­ko­wych zadań inwe­sty­cyj­nych nie uwzględ­nio­nych w tym projekcie.

To ozna­cza, że musi powstać pro­jekt cało­ści roz­wią­za­nia. Studium wyko­nal­no­ści to opra­co­wa­nie poka­zu­ją­ce tak­że model roz­wią­za­nia będą­ce­go przed­mio­tem ana­li­zy, jego wewnętrz­ną struk­tu­rę i mecha­nizm działania. 

Podstawowym celem stu­dium wyko­nal­no­ści tech­nicz­nej jest uwia­ry­god­nie­nie tego, że sys­tem będą­cy przed­mio­tem wnio­sku, może powstać i speł­ni swo­ją rolę, tego że cel pro­jek­tu zosta­nie osią­gnię­ty. Celem pro­jek­tu nie może być samo tyl­ko pozy­ska­nie dotacji. 

Jak to uwia­ry­god­nić? Należy wyka­zać nie tyl­ko to, że posia­da się środ­ki na sfi­nan­so­wa­nie przed­się­wzię­cia, nale­ży przede wszyst­kim uwia­ry­god­nić to, że sys­tem powsta­nie i osią­gnię­te zosta­ną cele zapo­wia­da­ne efek­ty. Jak? Po pro­stu nale­ży opra­co­wać model sys­te­mu, nie raz wręcz od zera go zapro­jek­to­wać, i poka­zać, że rozu­mie­my to co chce­my wytwo­rzyć lub zmienić.

Studium wyko­nal­no­ści to naj­czę­ściej żąda­nie inwe­sto­ra, czy­li pod­mio­tu finan­su­ją­ce­go przed­się­wzię­cie. Celem inwe­sto­ra zaś nie jest samo tyl­ko wyda­wa­nie pie­nię­dzy. Jak już pisa­łem w arty­ku­le Studium wyko­nal­no­ści pro­duk­tu – czym napraw­dę jest, stu­dium wyko­nal­no­ści powin­no zawie­rać opis sta­nu przed­mio­tu ana­li­zy obec­ne­go i planowanego. 

Wymieniona na począt­ku Instrukcja jasno precyzuje: 

Opis sta­nu aktu­al­ne­go (przed reali­za­cją)
Elementem wyj­ścio­wym w popraw­nie spo­rzą­dzo­nej ana­li­zie jest rze­tel­ny i dokład­ny opis sta­nu aktu­al­ne­go inwe­sty­cji pla­no­wa­nej do reali­za­cji. Jasno i czy­tel­nie opi­sa­ny aktu­al­ny stan pozwa­la w spo­sób przej­rzy­sty przejść do iden­ty­fi­ka­cji ist­nie­ją­cych pro­ble­mów oraz potrzeb, a tym samym do uza­sad­nie­nia potrze­by reali­za­cji pro­jek­tu. Celem opi­su sta­nu obec­ne­go jest odda­nie peł­ne­go obra­zu sta­nu ist­nie­ją­ce­go i przed­sta­wie­nie oto­cze­nia, w któ­rym będzie reali­zo­wa­ny pro­jekt. Opis sta­nu obec­ne­go jest rów­nież pod­sta­wą oce­ny potrze­by reali­za­cji pro­jek­tu. […] Na tym eta­pie powin­ny być wska­za­ne obec­ne pro­ble­my wyni­ka­ją­ce ze sta­nu aktualnego.

Kolejna część opra­co­wa­nia powin­na zawierać:

Opis sta­nu pro­jek­to­wa­ne­go
Wymagane jest szcze­gó­ło­we dopre­cy­zo­wa­nie i uza­sad­nie­nie zakre­su rze­czo­we­go pro­jek­tu, pre­zen­tu­jąc jego cel, kwe­stie któ­rych będzie doty­czył, infra­struk­tu­rę jaka ma zostać stwo­rzo­na, itp. […] Dodatkowo, nale­ży prze­pro­wa­dzić ana­li­zę pro­jek­tu w kon­tek­ście całe­go ukła­du infra­struk­tu­ry, tj. funk­cjo­nal­ne i rze­czo­we powią­za­nia mię­dzy danym pro­jek­tem, a ist­nie­ją­cą infrastrukturą.

Zwieńczeniem cało­ści tej czę­ści Studium Wykonalności powin­na być: 

Definicja celów pro­jek­tu
Zdefiniowanie celów jest nie­zbęd­nym eta­pem słu­żą­cym iden­ty­fi­ka­cji i ana­li­zie pro­jek­tu. Stanowi ono punkt wyj­ścia do prze­pro­wa­dze­nia jakiej­kol­wiek oce­ny inwestycji.

oraz

Wskaźniki reali­za­cji celów pro­jek­tu
Realizacja celu musi być mie­rzo­na za pomo­cą przy­naj­mniej jed­ne­go wskaź­ni­ka rezultatu.

Zależnie od nabo­ru istot­ne są deta­le doty­czą­ce celów spon­so­ra, jed­nak co do zasa­dy stu­dium wyko­nal­no­ści to nie tyl­ko ana­li­za finan­so­wa. Kluczem jest wyka­za­nie, że otrzy­ma­ne środ­ki finan­so­we przy­nio­są ocze­ki­wa­ne efekty: 

Zgodnie z cyto­wa­na instruk­cją Wniosek o finan­so­wa­nie to opi­su okre­ślo­ne­go eta­pu roz­wo­ju orga­ni­za­cji (sys­te­mu): pomię­dzy Stanem aktu­al­nym a Stanem pla­no­wa­nym (patrz wykres powy­żej). Całość to nic inne­go jak stan­dar­do­wa pro­ce­du­ra tak zwa­nej ogól­nej ana­li­zy sys­te­mo­wej (któ­rej nie nale­ży utoż­sa­miać tyl­ko z sys­te­ma­mi informatycznymi):

Najpierw dowiedz­my się ?jak jest i dla­cze­go jest tak jak jest? a potem napisz­my ?jak powin­no być i co nale­ży uczy­nić, aby było tak jak być powin­no? .

W dal­szej czę­ści opi­szę pokrót­ce jak sfor­ma­li­zo­wa­ny­mi meto­da­mi i narzę­dzia­mi moż­na wyko­nać powyż­szą analizę.

Sformalizowane modelowanie systemów 

Nie tak daw­no, w arty­ku­le o mecha­tro­ni­ce (Inteligentna pral­ka) pre­zen­to­wa­łem meto­dę pro­jek­to­wa­nia sys­te­mów wyma­ga­ją­cych inter­dy­scy­pli­nar­nej wie­dzy. Prosty dia­gram poni­żej poka­zu­je struk­tu­rę opi­sa­ne­go tam systemu: 

Struktura taka jak ta, poka­zu­je ele­men­ty z jakich skła­da się roz­wią­za­nie i to jak owa całość jest skon­stru­owa­na, jak współ­dzia­ła­ją jej poszcze­gól­ne ele­men­ty. Taki model jest pierw­szym testem poka­zu­ją­cym, że to będzie dzia­ła­ło”. Modele takie moż­na testo­wać, bo ich two­rze­nie to sfor­ma­li­zo­wa­ny pro­ces. Wśród wie­lu cech ele­men­tów mode­lu jest (może być) tak­że koszt jego pozy­ska­nia. Dlatego model taki nie tyl­ko peł­ni rolę pro­jek­tu, peł­ni tak­że role szkie­le­tu wyce­ny: każ­dy ele­ment nale­ży wyce­nić czy­li podać koszt wytwo­rze­nia lub zaku­pu kom­po­nen­tów, koszt pra­cy zwią­za­nej z jego mon­ta­żem, koszt uru­cho­mie­nia całości. 

Najczęściej w doku­men­tach tego typu spo­ty­ka­my sche­ma­ty blo­ko­we, opra­co­wa­ne jako nie­for­mal­ne struk­tu­ry, np. takie jak poniższa: 

Zaletą takiej for­my pre­zen­ta­cji jest rela­tyw­na łatwość ich opra­co­wa­nia, pew­ne walo­ry este­tycz­ne, wadą zaś tej for­my jest to, że nie ist­nie­je żad­na moż­li­wość wali­da­cji takich dia­gra­mów (wery­fi­ka­cji popraw­no­ści, spój­no­ści i kom­plet­no­ści). Jako model są prak­tycz­nie nie­przy­dat­ne do innych celów niż nie­for­mal­na ilu­stra­cja. Niestety nie nada­ją się jako mate­riał badaw­czy do stu­dium wykonalności. 

Aby uzy­skać model do celów ana­li­zy, nale­ży sche­mat blo­ko­wy sfor­ma­li­zo­wać. Standardowym narzę­dziem for­ma­li­za­cji w inży­nie­rii są rysun­ki tech­nicz­ne, jed­nak te pozwa­la­ją jedy­nie na udo­ku­men­to­wa­nie struk­tu­ry konstrukcyjnej. 

W obec­nych cza­sach coraz wię­cej kon­struk­cji to wła­śnie kon­struk­cje mecha­tro­nicz­ne, czy­li struk­tu­ry skła­da­ją­ce się ele­men­tów nie tyl­ko mecha­nicz­nych. Elementy tych struk­tur nie tyl­ko są z sobą połą­czo­ne”, one na sie­bie oddzia­łu­ją, i to nie raz w bar­dzo wyra­fi­no­wa­ny spo­sób: wymie­nia­ją sygna­ły ste­ru­ją­ce. System grzew­czy – nie­for­mal­ny dia­gram – poka­za­ny powy­żej, w wer­sji sfor­ma­li­zo­wa­nej będzie wyglą­dał mniej wię­cej tak jak sche­mat poni­żej (to nie jest ten sam sys­tem, to wyłącz­nie przy­kła­dy dokumentów):

Formalizm tych sche­ma­tów pole­ga na pre­cy­zyj­nym opi­sie (mode­lo­wa­niu) nie tyl­ko samej kon­struk­cji, zawie­ra tak­że peł­ny opis mecha­ni­zmu działania. 

diagram_aspects_new.png
(https://​docs​.noma​gic​.com/​d​i​s​p​l​a​y​/​S​Y​S​M​L​P​1​9​0​/​D​i​a​g​r​a​m​+​a​s​p​e​cts)

Jak widać, szcze­gó­ło­wość opi­su moż­na dosto­so­wać do potrzeb: celu two­rze­nia modelu. 

Modele two­rzo­ne do celów stu­diów wyko­nal­no­ści cha­rak­te­ry­zu­ją się mniej­szą licz­ba szcze­gó­łów. Celem ich two­rze­nia jest raczej inwen­ta­ry­za­cja kom­po­nen­tów sys­te­mu, pozwa­la to łatwo uzu­peł­nić cechy kom­po­nen­tów np. o ich koszt pozy­ska­nia i pra­co­chłon­ność uru­cho­mie­nia (koszt pra­cy). Wtedy struk­tu­ra mode­lu ma postać np. jak poni­żej :

(https://​www​.scien​ce​di​rect​.com/​t​o​p​i​c​s​/​c​o​m​p​u​t​e​r​-​s​c​i​e​n​c​e​/​i​n​t​e​r​n​a​l​-​b​l​o​c​k​-​d​i​a​g​ram)

Podsumowanie

Korzystanie z ana­li­zy sys­te­mo­wej jako narzę­dzia i two­rze­nie sfor­ma­li­zo­wa­nych sche­ma­tów blo­ko­wych, na uży­tek ana­liz wyko­nal­no­ści, to nie tyko uwia­ry­god­nie­nie samej analizy. 

Studium wyko­nal­no­ści sta­no­wi sobą pre-pro­jek­to­wa­nie sys­te­mu będą­ce­go przed­mio­tem ana­li­zy. To począ­tek opra­co­wy­wa­nia rozwiązania.

,

To tak­że obni­że­nie ryzy­ka pro­jek­tu, gdyż mode­le sys­te­mo­we pozwa­la­ją na wery­fi­ka­cję pro­jek­tu już na eta­pie jego doku­men­to­wa­nia. Dodatkowo, uzu­peł­nia­jąc mode­le o kosz­ty kom­po­nen­tów, uwia­ry­gad­nia­my tak­że wyce­nę: mamy pew­ność, że nicze­go nie pomi­nę­li­śmy. .

Oferta

Osoby zain­te­re­so­wa­ne wyce­ną takiej usłu­gi (zawsze Analiza Biznesowa, cza­sa­mi tak­że Projekt Techniczny Rozwiązana) zapra­szam na stro­nę Regulamin świad­cze­nia usług.

Źródła

Arantes, M., Bonnard, R., Mattei, A. P., & de Saqui-Sannes, P. (2018). General archi­tec­tu­re for data ana­ly­sis in indu­stry 4.0 using SysML and model based sys­tem engi­ne­ering. 2018 Annual IEEE International Systems Conference (SysCon), 1 – 6. https://​doi​.org/​1​0​.​1​1​0​9​/​S​Y​S​C​O​N​.​2​0​1​8​.​8​3​6​9​574
Friedenthal, S., Moore, A., & Steiner, R. (2015). A prac­ti­cal guide to SysML: the sys­tems mode­ling lan­gu­age (Third edi­tion). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a‑practical-guide-to-sysml
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.
Camillus, J. C. (2008). Strategy as a Wicked Problem. Harvard Business Review, 11.
Mattei, A. P., Loures, L., de Saqui-Sannes, P., & Escudier, B. (2017). Feasibility stu­dy of a mul­ti­spec­tral came­ra with auto­ma­tic pro­ces­sing onbo­ard a 27U satel­li­te using model based spa­ce sys­tem engi­ne­ering. 2017 Annual IEEE International Systems Conference (SysCon), 1 – 8. https://​doi​.org/​1​0​.​1​1​0​9​/​S​Y​S​C​O​N​.​2​0​1​7​.​7​9​3​4​725
Koźmiński, A. K. (1979). Decyzje: ana­ly­za sys­te­mo­wa orga­ni­za­cji. Pánstwowe Wydawn. Naukowe.
Herrold, J. (2016). System Architecture using SysML – Despite the GAPS! 37.
Steimer, C., Fischer, J., & Aurich, J. C. (2017). Model-based Design Process for the Early Phases of Manufacturing System Planning using SysML. Procedia CIRP, 60, 163 – 168. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​p​r​o​c​i​r​.​2​0​1​7​.​0​1​.​036
Thramboulidis, K. (2013). Overcoming Mechatronic Design Challenges: the 3+1 SysML-view Model. 1, 10.
Ireland, C., & Bowers, D. (2015). Exposing the Myth: Object-Relational Impedance Mismatch is a Wicked Problem. 6. http://oro.open.ac.uk/43318/1/download.php_articleid%3Ddbkda_2015_2_10_50020
Mili, S., Nguyen, N., & Chelouah, R. (n.d.). Connected Systems Modeling and Validation. 5.

Procesy biznesowe a procedury

Wstęp

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

Wdrożenie zin­te­gro­wa­nych elek­tro­nicz­nych usług, infor­ma­cyj­nych na przy­kła­dzie porad­ni­ków przed­się­bior­cy, udo­stęp­nia­nych poprzez Punkt Kontaktowy w Polsce” (Elektroniczna gospo­dar­ka nr 4/2015, plik pdf).

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

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

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

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

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

Wyjaśnijmy sobie dla­cze­go nieprawdziwa.

Streszczenie

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

Procedura, proces i proces biznesowy

Autorzy piszą:

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

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

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

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

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

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

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

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

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

" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">pro­dukt i usłu­ga to coś co ma war­tość dla klien­ta”, to powsta­je pro­sta i praw­dzi­wa moim zda­niem defi­ni­cja opi­su­ją­ca sed­no spra­wy”. Ogólnie wymo­wa arty­ku­łu potwier­dza moją tezę o abs­trak­cyj­no­ści pro­ce­su”, nama­cal­ne są za to pozo­sta­łe jego ele­men­ty: wej­ście i wyj­ście (pro­duk­ty), zaso­by (ludzie i maszy­ny) oraz Szczegóły:
" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">regu­ły biz­ne­so­we (te są dokumentowane). 

Na zachę­tę cytat :):

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

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

Osobiście w swo­ich pro­jek­tach sto­su­ję defi­ni­cję brzmią­cą: Szczegóły:" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">Proces to prze­kształ­ce­nie wej­ścia pro­ce­su w jego wyj­ście, z uży­ciem okre­ślo­nych zaso­bów i w obec­no­ści okre­ślo­nych ograniczeń. 

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

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

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

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

Troszkę teorii

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

Business Process: A defi­ned set of busi­ness acti­vi­ties that repre­sent the steps requ­ired to achie­ve a busi­ness objec­ti­ve. It inc­lu­des the flow and use of infor­ma­tion and resources.

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

(ang. Proces biz­ne­so­wy: zde­fi­nio­wa­ny zestaw dzia­łań biz­ne­so­wych, któ­re repre­zen­tu­ją kro­ki wyma­ga­ne do osią­gnię­cia celu biz­ne­so­we­go. Obejmuje prze­pływ i wyko­rzy­sta­nie infor­ma­cji i zasobów.

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

Autorzy wycią­ga­ją wniosek:

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

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

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

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

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

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

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

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

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

Proces vs. procedura

W 2014 roku pisałem:

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

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

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

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

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

pro­ce­du­ra

1. ?okre­ślo­ne regu­ły postę­po­wa­nia w jakiejś spra­wie, zwy­kle o cha­rak­te­rze urzę­do­wym lub prawnym?
2. ?w języ­kach pro­gra­mo­wa­nia: wydzie­lo­ny frag­ment algorytmu?

regu­ła

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

Zaglądamy ponow­nie do słownika:

zasa­da

1. ?pra­wo rzą­dzą­ce jaki­miś pro­ce­sa­mi, zja­wi­ska­mi; też: for­mu­ła wyja­śnia­ją­ca to prawo?
Otrzymamy:
Procedura: okre­ślo­ne pra­wa rzą­dzą­ce postę­po­wa­niem, usta­lo­ne przez kogoś, w jakiejś spra­wie, zwy­kle o cha­rak­te­rze urzę­do­wym lub prawnym

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

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

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

Atomic Activity: An acti­vi­ty not bro­ken down to a finer level of Process Model deta­il. It is a leaf in the tree-struc­tu­re hie­rar­chy of Process acti­vi­ties. Graphically it will appe­ar as a Task
in BPMN.

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

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

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

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

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

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

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

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

Co z procedurą?

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

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

Proces biznesowy jako abstrakcja

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

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

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

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

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

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

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

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

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

Kluczowe pojęcia w modelowaniu

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

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

Model poję­cio­wy (dia­gram fak­tów, nota­cja SBVR, opra­co­wa­nie własne)

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

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

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

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

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

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

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

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

Podsumowanie

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

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

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

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

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

Warto tu zwró­cić uwa­gę na fakt, że mode­lo­wa­nie pro­ce­sów biz­ne­so­wych na pod­sta­wie wywia­dów i ankiet (pozy­ski­wa­nie infor­ma­cji o wyko­ny­wa­nych czyn­no­ściach) wpro­wa­dza ogrom­ną zależ­ność uzy­ska­nych wyni­ków od subiek­tyw­ne­go postrze­ga­nia orga­ni­za­cji przez zatrud­nio­nych w niej (i ankie­to­wa­nych) pra­cow­ni­ków. Powoli, od ponad deka­dy, prze­bi­ja­ją się do świa­do­mo­ści firm ana­li­tycz­nych, meto­dy opar­te na fak­tach, a są nimi tak zwa­ne «arte­fak­ty» czy­li nama­cal­ne śla­dy po wyko­na­nej pra­cy. W warun­kach biz­ne­so­wych są do doku­men­ty ope­ra­cyj­ne i ich treść. 

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

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

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

Źródła

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