Tag: BPMN

SPEM czyli Software & Systems Process Engineering

1 komentarz

Tym razem arty­kuł adre­so­wa­ny do zaawan­so­wa­nych analityków. 

Ta spe­cy­fi­ka­cja (SPEM) jest dato­wa­na na 2008 rok. Stanowi sobą tło dla MDA oraz uza­sad­nia wzor­ce pro­jek­to­wa­ne opar­te na przy­pad­kach uży­cia (mikro­ser­wi­sy, Use Case 2.0, inne podob­ne). Podstawowa róż­ni­ca mię­dzy spe­cy­fi­ka­cją SPEM a spe­cy­fi­ka­cją UML pole­ga na tym, że UML to pro­fi­le MOF sta­no­wią­ce opi­sy nota­cji i sys­te­mów poję­cio­wych. SPEM to meta­mo­del pro­ce­su wytwór­cze­go opro­gra­mo­wa­nia czy­li gene­ral­ne zasa­dy budo­wa­nia pro­ce­sów wytwa­rza­nia i dostar­cza­nia oprogramowania. 

Czytaj dalej… ​„SPEM czy­li Software & Systems Process Engineering” →
http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471

Zwinna analiza biznesowa to mit czy fakt?

4 komentarze

Agile busi­ness ana­lyst has the capa­bi­li­ty to keep the whe­el rol­ling. They?re a trans­for­ma­ti­ve fun­nel thro­ugh which a requ­ire­ment pas­ses down to the deli­ve­ry path towards an expec­ted out­co­me. This SDLC machi­ne needs con­ti­nu­ous fuel in the form of well-defi­ned and infor­med infor­ma­tion which is pro­vi­ded by an agi­le busi­ness ana­lyst. As long as an agi­le busi­ness ana­lyst does the job, this machi­ne will rema­in on its cour­se to deli­ver gre­ater solutions.Coming to our ori­gi­nal question, is an agi­le busi­ness ana­lyst a myth or a reali­ty? There is a cle­ar answer. It is a reali­ty if an orga­ni­za­tion reali­zes the value, but it is a myth for imma­tu­re orga­ni­za­tions who­se pro­ces­ses are ill-defi­ned and are nowhe­re on a path towards best prac­ti­ces. (Is Agile Business Analyst a Myth or a Reality? )

Tak więc (zwin­ny) ana­li­tyk biz­ne­so­wy to model pra­cy pole­ga­ją­cy na sta­łym dostar­cza­niu (na eta­pie imple­men­ta­cji) kolej­nych infor­ma­cji. Projekt two­rze­nia apli­ka­cji zawsze trwa w cza­sie, więc w toku two­rze­nia opro­gra­mo­wa­nia zmie­nia się biznes. 

Developerzy czę­sto mówią, że klient zmie­nia im wyma­ga­nia, a tak na praw­dę ktoś zbyt wcze­śnie zapi­sał zbyt wie­le szcze­gó­łów. Implementacja dedy­ko­wa­ne­go opro­gra­mo­wa­nia to tak na praw­de pętla ite­ra­cyj­no-przy­ro­sto­wa: zbie­ra­my infor­ma­cje potrzeb­ne do wytwo­rze­nia jed­nej usłu­gi apli­ka­cyj­nej i imple­men­tu­je­my ją, wszel­kie szcze­gó­ły odkła­da­my na ostat­ni moment. Wymaga to jed­nak zmia­ny podej­ścia. Trzy lata temu pisa­łem na tym blogu:

Rynek zmie­nia się szyb­ko, więc nie ma sen­su szcze­gó­ło­we pro­jek­to­wa­nie cze­go­kol­wiek z uwa­gi na czas jaki zaj­mie takie pro­jek­to­wa­nie i ryzy­ko, że taki pro­jekt sta­nie się szyb­ko nie­ak­tu­al­ny. Nikt roz­sąd­ny nie nama­wia dzi­siaj do cze­goś o wdzięcz­nej nazwie ??water­fall?. Co więc zro­bić? Dla dużych pro­jek­tów two­rzy­my archi­tek­tu­rę, opi­su­je­my mecha­ni­zmy dzia­ła­nia, poli­ty­kę roz­bu­do­wy i opis cyklu życia. Czyli to co pozwo­li roz­wi­jać roz­wią­za­nie meto­dą ite­­ra­­cy­j­no-przy­­ro­­sto­­wą, w razie potrze­by pozwo­li na prze­pro­jek­to­wa­nie, ale jako całość nadal będzie spój­ne, nie będzie wyma­ga­ło wymia­ny cało­ści gdy zmie­nią się warun­ki na ryn­ku.Można w tym miej­scu zary­zy­ko­wać tezę, że nie ma cze­goś takie­go jak ??inży­nie­ria wyma­gań? bo czym ona jest i co jest jej pro­duk­tem? Uporządkowany spis życzeń? Mamy nato­miast na pew­no ??inży­nie­rię sys­te­mów?.? sys­te­ma­mi są orga­ni­za­cje a tak­że narzę­dzia jakich uży­wa­ją np. opro­gra­mo­wa­nie? (Wymagania umar­ły. Rozwiązaniem jest cykl życia pro­duk­tu | | Jarosław Żeliński IT-Consulting)

Z cze­go nale­ży więc od razu zre­zy­gno­wać? Z opra­co­wa­nia rela­cyj­ne­go mode­lu (bazy) danych dla całej apli­ka­cji, i prze­sta­wić sie na idee mikro-ser­wi­sów, czy­li uzna­nia, że apli­ka­cja nie jest mono­li­tem a zesta­wem kom­po­nen­tów reali­zu­ją­cych usłu­gi apli­ka­cyj­ne. Usługi apli­ka­cyj­ne mode­lu­je­my jako Przypadki Użycia (nota­cja UML) i to sta­no­wi kon­takt z dostaw­cą. Jednak ​„czar­na skrzyn­ka” (opis nie zawie­ra­ją­cy mecha­ni­zmu dzia­ła­nia) jest bar­dzo ryzy­kow­ny, dla­te­go sku­tecz­ne meto­dy doku­men­to­wa­nia wyma­gań, to meto­dy zorien­to­wa­nie na mode­le (MDA) opi­su­ją­ce logi­kę dzia­ła­nia sys­te­mu (model jako wyma­ga­nie), a zamiast two­rze­nia kor­po­ra­cyj­ne­go rela­cyj­ne­go mode­lu danych, zamy­ka­my się w doku­men­tach jako ele­men­tar­nych nośni­kach danych (i nie boimy sie redun­dan­cji danych w całym sys­te­mie). Ogromne i szcze­gó­ło­we doku­men­ty i mode­le są wyłącz­nie stra­tą cza­su i pieniędzy:

(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))
(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))

Dlatego od lat fascy­nu­je mnie nie­kon­se­kwen­cja wie­lu deve­lo­pe­rów: naj­pierw wie­sza­ją psy na meto­dach nazy­wa­nych ​„water­fall”, a już chwi­lę potem zaczy­na­ją pro­jek­to­wa­nie jed­ne­go rela­cyj­ne­go mode­lu danych dla całe­go projektu! 

Zwinny Analityk Biznesowy utrzy­mu­je pętlę ite­ra­cji przy­ro­stu zakre­su pro­jek­tu: mając opra­co­wa­ną archi­tek­tu­rę cało­ści i para­dyg­mat (poli­ty­kę) pro­jek­to­wa­nia (np. obiek­to­wy), dostar­cza cyklicz­nie i zawsze na ostat­ni moment, kolej­ne szcze­gó­ły, bo wte­dy ma naj­więk­szą wie­dzę, i ryzy­ko zmia­ny zakre­su jest naj­mniej­sze. To się nazy­wa «nad­zór autorski».

Tak więc klu­czem do suk­ce­su, w dzi­siej­szych warun­kach, jest model opar­ty na kom­po­nen­to­wej archi­tek­tu­rze i ite­ra­cyj­nym dostar­cza­niu kolej­nych usług apli­ka­cyj­nych . Jak? Analiza, pro­jek­to­wa­nie i implementacja:

  • Analiza biz­ne­so­wa (pro­ce­sy biz­ne­so­we) i sys­te­mu infor­ma­cji w orga­ni­za­cji, i decy­zja o ewen­tu­al­nej stan­da­ry­za­cji doku­men­tów i pro­ce­sów. (nota­cje BMM, SBVR, BPMN, UML)
  • Opracowanie mode­lu infor­ma­cyj­ne­go czy­li sza­blo­nów doku­men­tów, ich wza­jem­nych powią­zań i słow­ni­ka pojęć. (nota­cja UML, SBVR)
  • Opracowaniu archi­tek­tu­ry cało­ści i opi­sa­nie cyklu życia pro­jek­tu (nota­cja UML).
  • Przejścia do fazy imple­men­ta­cji z nad­zo­rem autor­skim auto­ra pro­jek­tu (zarzą­dza­nie zmia­ną, sta­ła aktu­ali­za­cja doku­men­ta­cji systemu).

Pierwsze przy punk­ty, ich reali­za­cja, nie powin­ny nigdy trwać dużej niż kwar­tał, a doku­men­ta­cja pier­wot­na raczej nie powin­na prze­kro­czyć nigdy 100 stron, bez wzglę­dy na wiel­kość pro­jek­tu! Im więk­szy pro­jekt tym bar­dziej doku­men­ta­cja począt­ko­wa powin­na być abs­trak­cyj­nym mode­lem. Innymi sło­wy: im więk­szy i dłu­żej trwa­ją­cy pro­jekt, tym bar­dziej jego opis powi­nien być stra­te­gią jego reali­za­cji, a nie taktyką. 

Czy zwin­ny ana­li­tyk biz­ne­so­wy jest mitem czy rze­czy­wi­sto­ścią? Istnieje jasna odpo­wiedź: to rze­czy­wi­stość, jeśli orga­ni­za­cja zda­je sobie spra­wę z war­to­ści takiej pra­cy, ale jest mitem dla nie­doj­rza­łych orga­ni­za­cji, któ­rych pro­ce­sy są źle zdefiniowane.

Źródła

Steve Burbeck (2012) How to use Model-View-Controller (MVC). Available at: https://web.archive.org/web/20120729161926/http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html (Accessed: 5 January 2020).
Jenney, J. et al. (2010) Modern methods of sys­tems engi­ne­ering: with an intro­duc­tion to pat­tern and model based methods. Erscheinungsort nicht ermit­tel­bar: Joe Jenney.
Awaysheh, F.M. et al. (2019) ​‘Next-Generation Big Data Federation Access Control: A Reference Model’, arXiv:1912.11588 [cs] [Preprint]. Available at: http://​arxiv​.org/​a​b​s​/​1​9​1​2​.​1​1​588 (Accessed: 4 January 2020).
Garland, J. and Anthony, R. (2003) Large-sca­le softwa­re archi­tec­tu­re: a prac­ti­cal guide using UML. Chichester ; New York: J. Wiley.
Kumar, R.N.P. and Patil, S. (2019) ​‘A System and Method for impro­ving the Model Based Systems Engineering Environment capa­bi­li­ty’, INCOSE International Symposium, 29(S1), pp. 277 – 290. Available at: https://​doi​.org/​1​0​.​1​0​0​2​/​j​.​2​334 – 5837.2019.00685.x.

Czym nie jest poprawna analiza i modelowanie procesów

Dodaj komentarz

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/

Czy Bizagi nam pomoże?

7 komentarzy

Od cza­su do cza­su jestem pyta­ny o narzę­dzie Bizagi. Jest to kom­plet­ny sys­tem BPMS?*? skła­da­ją­cy się z narzę­dzi do mode­lo­wa­nia pro­ce­sów i ser­we­ra sta­no­wią­ce­go dla tych mode­li śro­do­wi­sko wyko­naw­cze ?(?Bizagi Overview,? n.d.)?. Narzędzie do mode­lo­wa­nia, Bizagi Modeler, to bar­dzo popu­lar­ne, dar­mo­we, narzę­dzie do doku­men­to­wa­nia mode­li pro­ce­sów biz­ne­so­wych z uży­ciem nota­cji BPMN???.

Często wyszu­ki­wa­nym hasłem na moim blo­gu jest enig­ma­tycz­ne: ​„biza­gi”, od cza­su do cza­su jestem pyta­ny: ​„Co sądzę o Bizagi, bo roz­wa­ża­my jego wyko­rzy­sta­nie w naszej fir­mie do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych?” Ten arty­kuł nie będzie jed­nak roz­bu­do­wa­ną opi­nią czy ana­li­zą moż­li­wo­ści tego narzę­dzia, sku­pię się na opi­sie przy­dat­no­ści Bizagi do okre­ślo­ne­go celu jakim są ana­li­zy biznesowe. 

Trzeba zacząć od tego, czym jest to narzę­dzie. Otóż jest to przede wszyst­kim narzę­dzie do two­rze­nia gra­ficz­nej for­my mode­li pro­ce­sów, któ­rych celem jest ich uru­cha­mia­nie na plat­for­mie Bizagi Automation. Bizagi to roz­bu­do­wa­ne plat­for­ma do mode­lo­wa­nia i uru­cha­mia­nia sys­te­mu wspo­ma­ga­nia pro­ce­sów biz­ne­so­wych. Są to trzy narzę­dzia: Bizagi Modeler, Bizagi Studio i Bizagi Automation. Pierwsze to dar­mo­we narzę­dzie do two­rze­nia gra­ficz­nej wer­sji mode­li pro­ce­sów biz­ne­so­wych. Pozostałe dwa to płat­ne narzę­dzia do two­rze­nia i uru­cha­mia­nia apli­ka­cji imple­men­tu­ją­cej mode­lo­wa­ne procesy. 

Bizagi Modeler pozwa­la jedy­nie na opra­co­wa­nie gra­ficz­nych mode­li pro­ce­sów (sche­ma­tów blo­ko­wych) z uży­ciem nota­cji BPMN. Wspiera tę nota­cje bar­dzo dobrze. Pozwala na two­rze­nie roz­bu­do­wa­nych dia­gra­mów, a tak­że na ich współ­dzie­le­nie w gru­pie (wspól­ny dysk lub w chmu­rze np. Dropbox). Pozwala gene­ro­wać ich doku­men­ta­cję, jed­nak doku­men­ta­cja ta, to raport a nie samo­dziel­ny doku­ment korzy­sta­ją­cy z dia­gra­mów, dla­te­go wpływ na kształt tych doku­men­tów jest ogra­ni­czo­ny. Narzędzie to przy­da się, jeże­li jedy­nym celem pro­jek­tu jest opra­co­wa­nie doku­men­ta­cji pro­ce­sów biz­ne­so­wych w nota­cji BPMN i nic ponad to. 

Czy Bizagi pomo­że w ana­li­zie biz­ne­so­wej? Jeżeli pod poję­ciem Analiza Biznesowa rozu­mie­my pra­cę, któ­rej celem jest opra­co­wa­nie wyma­gań na opro­gra­mo­wa­nie to nie­ste­ty, poza opra­co­wa­niem mode­li pro­ce­sów biz­ne­so­wych, nie pomo­że. Kluczowym pro­ble­mem jest tu to, że do pozo­sta­łych prac (eta­pów pra­cy) w ana­li­zie biz­ne­so­wej, ana­li­zie wyma­gań, i pro­jek­to­wa­niu opro­gra­mo­wa­nia, trze­ba korzy­stać z innych narzę­dzi. W efek­cie zarzą­dza­nie całą doku­men­ta­cją sta­je się bar­dzo trudne.

Bizagi Modeler jest narzę­dziem dar­mo­wym i łatwym w naucze­niu się korzy­sta­nia z nie­go, więc dobrze spraw­dza się jako notat­nik dla człon­ków zespo­łu po stro­nie fir­my ana­li­zo­wa­nej, o ile oczy­wi­ście dys­po­nu­je­my po tej stro­nie oso­ba­mi potra­fią­cy­mi uży­wać nota­cji BPMN. W prak­ty­ce wyglą­da to tak, że po prze­szko­le­niu, zespół pra­cow­ni­ków fir­my ana­li­zo­wa­nej, wg. ​„naj­lep­szej swo­jej wie­dzy” opi­su­je okre­ślo­ne pro­ce­sy biz­ne­so­we, korzy­sta­jąc z Bizagi Modeler, i prze­ka­zu­je efek­ty pra­cy ana­li­ty­ko­wi. Te mode­le, jako szki­ce pro­ce­sów, ana­li­tyk impor­tu­je do swo­je­go narzę­dzia CASE (pli­ki Bizagi są łatwe w impor­cie) i kon­ty­nu­uje pra­ce, two­rząc już oso­bi­ście popraw­ne, pro­fe­sjo­na­le mode­le tych procesów.

Tu uwa­ga prak­tycz­na: odra­dzam podej­ście, pole­ga­ją­ce na wysła­niu zespo­łu pro­jek­to­we­go na kil­ku­dnio­we szko­le­nie i prze­ka­za­niu mu zada­nia ​„opra­cuj­cie mode­le pro­ce­sów biz­ne­so­wych” np. przed wdro­że­niem sys­te­mu ERP, czy zamó­wie­niem dedy­ko­wa­ne­go opro­gra­mo­wa­ni. Po takim kur­sie pro­duk­ty pra­cy takie­go zespo­łu mogą być dobrym punk­tem star­tu dla doświad­czo­ne­go ana­li­ty­ka, ale nie znam przy­pad­ku by sta­no­wi­ły jaki­kol­wiek war­to­ścio­wy mate­riał końcowy. 

Trzeba mieć świa­do­mość, że ana­li­za i mode­lo­wa­nie wyma­ga umie­jęt­no­ści, dużej wie­dzy i doświad­cze­nia, a pla­no­wa­ne tak oszczęd­no­ści (pój­dzie­my na szko­le­nie i sami zro­bi­my taniej) szyb­ko się msz­czą. Celem szko­leń jest zdo­by­wa­nie wie­dzy. Doświadczenie i umie­jęt­no­ści zdo­by­wa się już samo­dziel­nie w trak­cie kolej­nych projektów. 

Na zakoń­cze­nie. Bizagi jako narzę­dzie dar­mo­we i wygod­ne na pew­no pomo­że wejść niskim kosz­tem w nowy obszar wie­dzy i pra­cy, jest to narzę­dzie, któ­re powsta­ło tyl­ko w jed­nym celu: doku­men­to­wa­nie pro­ce­sów na uży­tek okre­ślo­nej plat­for­my BPMS. Owszem, tam gdzie celem jest jedy­nie udo­ku­men­to­wa­nie pro­ce­sów, jego sto­so­wa­nie nie jest pozba­wio­ne sen­su. Jednak zakres dzi­siej­szych pro­jek­tów ana­li­tycz­nych bar­dzo rzad­ko zamy­ka się w obsza­rze mode­lo­wa­nia pro­ce­sów. Warto pamię­tać, że peł­na doku­men­ta­cja pro­ce­sów to tak­że pro­ce­du­ry (zło­żo­ne listy i sce­na­riu­sze) oraz struk­tu­ry doku­men­tów biz­ne­so­wych (tu XML, UML), two­rze­nia któ­rych Bizagi już nie wspiera.

Bizagi z zasa­dy słu­ży do two­rze­nia mode­li wyko­ny­wal­nych (BPMN rozdz.2: Common Execution Models), dla­te­go w pro­jek­tach trze­ba przy­jąć okre­ślo­ną kon­wen­cję two­rze­nia mode­li ana­li­tycz­nych, a tu wali­da­tor Bizagi (narzę­dzie poma­ga­ją­ca w utrzy­ma­niu zgod­no­ści dia­gra­mów z zasa­da­mi nota­cji) nie raz raczej będzie prze­szka­dzał niż pomagał.

Artykuł jest krót­ki i na pew­no nie wyczer­pu­je listy pro­ble­mów i nie­ja­sno­ści w wybo­rze narzę­dzia, dla­te­go zachę­cam do zada­wa­nia pytań poni­żej. Postaram się odpo­wie­dzieć wedle naj­lep­szej swo­jej wie­dzy i doświadczenia. 

  1. ?*?
    BPMS – ang. Business Process Management System, cza­sa­mi też roz­sze­rza­ny jako Business Process Management Server
  2. ???
    BPMN – Business Process Modeling and Notation, stan­dard nota­cyj­ny (http://​www​.bpmn​.org)

Źródła

  1. Bizagi Overview. (n.d.). Retrieved June 23, 2019, from Bizagi websi­te: https://​www​.biza​gi​.com/​e​n​/​p​r​o​d​u​cts

rfc2119 – Słowa kluczowe reguł

Dodaj komentarz

Od cza­su do cza­su spo­ty­kam się z zasko­cze­niem, gdy mówię, że pew­ne sło­wa klu­czo­we w spe­cy­fi­ka­cjach są ​„stan­da­ry­zo­wa­ne”. Otóż spe­cy­fi­ka­cje nota­cji na OMG​.org mają narzu­co­ne pew­ne słow­nic­two. Przykładem niech będzie spe­cy­fi­ka­cja nota­cji BPMN v.2.0.2, zawie­ra ona taki oto roz­dział :

3.2 Normative
OMG UML
? OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 -
(jest już UML 2.5.)
OMG MOF
? Object Management Group – Meta Object Facility (MOF) Core Specification, V2.0
http://​www​.omg​.org/​s​p​e​c​/​M​O​F​/​2.0
RFC-2119
? Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, IETF RFC 2119, March 1997
http://​www​.ietf​.org/​r​f​c​/​r​f​c​2​1​1​9​.​txt

Oznacza to, że do popraw­nej inter­pre­ta­cji spe­cy­fi­ka­cji nota­cji nale­ży znać spe­cy­fi­ka­cje: MOF, UML oraz tak­że RFC-2119. O MOF i UML pisa­łem nie raz, dzi­siaj kil­ka słów o tej ostatniej. 

Jest to doku­ment opi­su­ją­cy reko­men­do­wa­ny spo­sób for­mu­ło­wa­nia wyma­gań (np. w sto­sun­ku do ele­men­tów dia­gra­mu i ich uży­cia). Wymagania są tu rozu­mia­ne sze­ro­ko, jako sfor­mu­ło­wa­nia nor­ma­tyw­ne. ​„Słowa klu­czo­we do wyko­rzy­sta­nia, w RFC do wska­za­nia pozio­mów wyma­gań” to sło­wa i zwro­ty o tu usta­lo­nym zna­cze­niu :

This docu­ment spe­ci­fies an Internet Best Current Practices for the Internet Community, and requ­ests discus­sion and sug­ge­stions for impro­ve­ments. Distribution of this memo is unli­mi­ted.?(?Key words for use in RFCs to Indicate Requirement Levels,? 1997)?

Wymienione sło­wa klu­czo­we odno­szą się do for­mu­ło­wa­nia reguł (przy sto­so­wa­niu okre­ślo­nych zasad będą­cych wyma­ga­nia­mi) i oznaczają:

  1. MUSI (oryg. MUST) ozna­cza, że to zacho­wa­nie (okre­ślo­na regu­ła, wyma­ga­nie) jest abso­lut­nym wymo­giem, alter­na­tyw­nie: WYMAGA SIĘ, NALEŻY 
  2. NIE MOŻE (oryg. MUST NOT) ozna­cza, że okre­ślo­ne zacho­wa­nie jest abso­lut­nie zaka­za­ne, alter­na­tyw­nie: NIE NALEŻY
  3. POWINIEN (oryg. SCHOULD) ozna­cza, że okre­ślo­ne zacho­wa­nie jest reko­men­do­wa­ne, a więc jedy­nie w ści­śle okre­ślo­nych oko­licz­no­ściach, jeże­li ist­nie­ją okre­ślo­ne powo­dy, okre­ślo­ne zacho­wa­nie może być pomi­nię­te, alter­na­tyw­nie: REKOMENDUJE SIĘ,
  4. NIE POWINIEN (oryg. SHOULD NOT) ozna­cza, że pew­ne zacho­wa­nia odra­dza się (reko­men­du­je się nie wyko­ny­wać okre­ślo­ne­go zacho­wa­nia), a więc zacho­wa­nie to jest dopusz­czal­ne jedy­nie w okre­ślo­nych oko­licz­no­ściach, alter­na­tyw­nie: ODRADZA SIĘ, NIE REKOMENDUJE SIĘ, 
  5. MOŻE (oryg. MAY) ozna­cza, że okre­ślo­ne zacho­wa­nie jest opcjo­nal­ne, a więc skut­ki tego reali­za­cji lub pomię­cia okre­ślo­ne­go zacho­wa­nia są cał­ko­wi­cie neu­tral­ne, alter­na­tyw­nie: OPCJONALNIE

Powyższe odno­si się do wszel­kich wyma­gań, do decy­zji o zasto­so­wa­niu cze­goś (np. okre­ślo­nej kon­struk­cji w danej nota­cji). Pod poję­ciem ​„zacho­wa­nia (się)” rozu­mie­my inter­pre­ta­cję zapi­sów np. o sto­so­wa­niu lub wyma­ga­niu cze­goś lub nie. 

Biorąc pod uwa­gę fakt, że defi­ni­cje pojęć to kla­sy­fi­ka­to­ry i sta­no­wią one sobą regu­ły (coś jest lub nie jest czymś) sło­wa te sta­no­wią tak­że bazo­wy ele­ment skład­ni tre­ści reguł biz­ne­so­wych (ele­men­ty pre­dy­ka­tów), np. ​„kie­row­ca NIE MOŻE prze­kra­czać dozwo­lo­nej pręd­ko­ści”, ​„kie­row­ca POWINIEN zacho­wać bez­piecz­ną odle­głość od poprze­dza­ją­ce­go go pojaz­du”, ​„kie­row­ca MOŻE prze­wo­zić pasa­że­rów”, a ogól­nie rzecz bio­rąc ​„kie­row­ca MUSI prze­strze­gać zasad Kodeksu Drogowego”, a ten to nic inne­go jak wła­śnie zbiór reguł.

Źródła

OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
Network Working Group. (1997, March). Key words for use in RFCs to Indicate Requirement Levels. Https://​Www​.Ietf​.Org/. https://​www​.ietf​.org/​r​f​c​/​r​f​c​2​1​1​9​.​txt

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

8 komentarzy

Wprowadzenie

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

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

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

Notacja BPMN a MDA i UML

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

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

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

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

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

  • Descriptive
  • Analytic
  • Common Executable

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

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

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

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

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

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

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

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

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

Rys. Semantic are­as of UML 2.5.1

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

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

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

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

Proces realizacji potrzeb przedsiębiorstwa

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

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

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

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

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

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

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

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

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

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

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

Podsumowanie

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

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

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

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

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

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