Notacja EPC

Wprowadzenie

Notacja EPC (Event-dri­ven Process Chain) zosta­ła opra­co­wa­na w 1992 roku w ramach pro­jek­tu badaw­czo-roz­wo­jo­we­go z udzia­łem SAP AG na University of Saarland w Niemczech, a jej twór­cą jest dr August-Wilhelm Scheer. Stanowi ona klu­czo­wy ele­ment kon­cep­cji mode­lo­wa­nia SAP R/3 w zakre­sie inży­nie­rii biz­ne­so­wej i dosto­so­wa­nia tego sys­te­mu do potrzeb klien­ta, zosta­ła włą­czo­na tak­że do sys­te­mu NetWeaver fir­my SAP. 

Ostatni duży pro­jekt z jej uży­ciem reali­zo­wa­łem w 2008 roku dla pol­skie­go oddzia­łu nie­miec­kie­go ban­ku WestLB Bank Polska SA. Później już jedy­nie oka­zjo­nal­ne wspar­cie mery­to­rycz­ne i audy­ty, nadal się zdarzają. 

EPC to nota­cja mode­lo­wa­nia wspie­ra­na przez narzę­dzie ARIS Process Platform, któ­re zapew­nia zin­te­gro­wa­ny zestaw narzę­dzi do pro­jek­to­wa­nia, wdra­ża­nia i kon­tro­lo­wa­nia pro­ce­sów biz­ne­so­wych. EPC opie­ra się na kon­cep­cjach sie­ci sto­cha­stycz­nych i sie­ci Petriego, jed­nak sto­so­wa­nie nota­cji EPC nie wyma­ga zbyt­nie­go for­ma­li­zmu, nota­cja ta nie roz­róż­nia np. poję­cia pro­duk­tu aktyw­no­ści i ele­men­tu ste­ro­wa­nia prze­pły­wem pro­ce­su, ponie­waż wystę­pu­ją one jako skon­so­li­do­wa­ne Zdarzenie. .

Moim zda­niem jest to nie­ste­ty powód, dla któ­re­go nota­cja ta nie pozwa­la na poka­za­nie np. tego, że pro­duk­tem danej pra­cy (aktyw­ność) jest fak­tu­ra a ele­men­tem ste­ru­ją­cym pro­ce­sem jest jej war­tość brut­to. Wady tej nie ma opra­co­wa­na póź­niej, otwar­ta nota­cja BPMN, gdzie ope­ru­je­my i poję­ciem obiek­tu danych i poję­ciem zda­rze­nia, fak­tu, lub warunku.

Notacja EPC nie nakła­da tak­że sztyw­nych ogra­ni­czeń syn­tak­tycz­nych, poza gene­ral­ną zasa­dą, że na linii ste­ro­wa­nia pro­ce­sem funk­cje muszą wystę­po­wać naprze­mien­nie ze zda­rze­nia­mi. W efek­cie wali­da­cja dia­gra­mów zawie­ra­ją­cych takie dodat­ko­we ele­men­ty jak: role, komór­ki orga­ni­za­cyj­ne, sys­te­my i infor­ma­cje, jest czę­sto uznaniowa.

Notacja EPC jest nadal spo­ty­ka­na w pro­jek­tach, w któ­rych sto­so­wa­ne są sys­tem SAP ERP i narzę­dzie ARIS Toolset (ofe­ru­je ono obec­nie tak­że moż­li­wość korzy­sta­nia z innych nota­cji, mie­dzy inny­mi BPMN i UML). Notację EPC moż­na też nadal spo­tkać na nie­któ­rych uczel­niach, opro­gra­mo­wa­nie ARIS jest nadal dostęp­ne na ryn­ku. Notacja EPC to war­tość inte­lek­tu­al­na nadal chro­nio­na jako wła­sność fir­my IDS Scheer.

Semantyka i syntaktyka eEPC

Legenda sym­bo­li nota­cji EPC (eEPC)

Notacja EPC pier­wot­nie zawie­ra­ła tyl­ko ele­men­ty prze­pły­wu (bram­ki logicz­ne, funk­cje i zda­rze­nia) oraz sztyw­ną syn­tak­ty­kę (obli­ga­to­ryj­ną prze­mien­ność funk­cji i zda­rzeń na linii prze­pły­wu ste­ro­wa­nia i zda­rze­nie jako począ­tek i koniec pro­ce­su). Szybko zosta­ła wzbo­ga­co­na o sym­bo­le pozwa­la­ją­ce na mode­lo­wa­nie ele­men­tów orga­ni­za­cji (sys­te­my, infor­ma­cje, role, komór­ki orga­ni­za­cyj­ne). Dlatego obec­nie moż­na spo­tkać tak­że skrót eEPC (exten­ded EPC).

Przepływ ste­ro­wa­nia jest mode­lo­wa­ny jako linia kre­sko­wa skie­ro­wa­na, przy­po­rząd­ko­wa­nie funk­cji jako zada­nia komór­ki orga­ni­za­cyj­nej (linia cią­gła nie­skie­ro­wa­na) oraz prze­pływ infor­ma­cji (linia cią­gła skie­ro­wa­na). Symbol Ścieżka Procesu to wska­za­nie (link) na kolej­ny dia­gram sta­no­wią­cy kon­ty­nu­ację pro­ce­su. Można tą meto­dą agre­go­wać dia­gram do sym­bo­lu na dia­gra­mie nad­rzęd­nym, zacho­wu­jąc jed­nak zasa­dę prze­mien­no­ści funk­cji i zda­rzeń (sym­bol Ścieżka Procesu na dia­gra­mie ma wte­dy taką samą syn­tak­ty­kę jak funk­cja na dia­gra­mie pod­rzęd­nym). Symbol Ścieżka Procesu bywa uży­wa­ny tak­że jako przeniesienie/kontynuacja pro­ce­su na kolej­nym dia­gra­mie, wte­dy jest uzna­wa­ny za zda­rze­nie (dla­te­go iko­na ta, to wła­śnie zło­że­nie funk­cji i zda­rze­nia). Poniżej opi­sa­ne sym­bo­le na przy­kła­do­wym dia­gra­mie pro­ce­su (frag­ment diagramu):

Syntaktyka eEPC (opr. własne)

Notacja pozwa­la na dość pre­cy­zyj­ne mode­lo­wa­nie pro­ce­sów biz­ne­so­wych co jed­nak wyma­ga pew­nej dys­cy­pli­ny. Notacja eEPC nie ma sfor­ma­li­zo­wa­nej spe­cy­fi­ka­cji, nale­ży korzy­stać z opra­co­wań fir­mo­wa­nych przez auto­ra (AW. Scheer), któ­ry podej­mu­je pró­by porząd­ko­wa­nia seman­ty­ki i syn­tak­ty­ki :

Każdy model EPC musi od same­go począt­ku prze­strze­gać pew­nych pro­stych zasad pro­jek­to­wa­nia, aby unik­nąć lub ogra­ni­czyć nie­po­żą­da­ne zacho­wa­nia, takie jak np. mar­twe punk­ty. Dlatego nie pro­po­nu­je się rygo­ry­stycz­ne­go i zło­żo­ne­go sys­te­mu reguł i wzor­ców pro­jek­to­wych, ponie­waż uni­ka­nie wszyst­kich moż­li­wych kon­flik­tów zbyt­nio ogra­ni­cza­ło­by użyt­kow­ni­ka. Reguły te są następujące:

  1. Trzema pod­sta­wo­wy­mi węzła­mi w mode­lach EPC są aktyw­no­ści (funk­cje), zda­rze­nia i łącz­ni­ki [bram­ki logiczne].
  2. Nazwa zda­rze­nia powin­na odzwier­cie­dlać jego cha­rak­te­ry­sty­kę jako punk­tu w cza­sie, na przy­kład: ele­ment ukoń­czo­ny”. Jest ono repre­zen­to­wa­ne przez sześciokąt.
  3. Nazwa aktyw­no­ści powin­na uwzględ­niać kon­sump­cje cza­su, na przy­kład: pro­du­ko­wa­nie przed­mio­tu”. Czynność jest przed­sta­wio­na w posta­ci pro­sto­ką­ta o zaokrą­glo­nych rogach.
  4. Łączniki [bram­ki logicz­ne] są repre­zen­to­wa­ne przez okrąg. Wewnątrz okrę­gu typ łącz­ni­ka [logi­ka OR, XOR, AND] jest okre­ślo­ny za pomo­cą odpo­wied­nie­go sym­bo­lu. Łącznik może być podzie­lo­ny na część gór­ną i dol­ną, by odzwier­cie­dlić róż­ni­ce mię­dzy regu­ła­mi połą­czeń przy­cho­dzą­cych i wycho­dzą­cych [lub łączy­my kaska­do­wo pro­ste poje­dyn­cze bramki].
  5. Aby jasno okre­ślić, kie­dy pro­ces biz­ne­so­wy ma się roz­po­cząć i jaki jest jego wynik koń­co­wy, każ­dy dia­gram EPC roz­po­czy­na się i koń­czy jed­nym lub kil­ko­ma zdarzeniami.
  6. Diagram EPC zawie­ra co naj­mniej jed­ną czynność.
  7. Model EPC może skła­dać się z kil­ku dia­gra­mów EPC.
  8. Krawędzie [linie prze­pły­wu ste­ro­wa­nia] są skie­ro­wa­ne i zawsze łączą dwa ele­men­ty odpo­wia­da­ją­ce sekwen­cji aktywacji.
  9. Zdarzenie nie może być poprzed­ni­kiem ani następ­ni­kiem inne­go zdarzenia.
  10. Czynność nie może być poprzed­ni­kiem ani następ­ni­kiem innej czynności.
  11. Każde zda­rze­nie i każ­da czyn­ność mają tyl­ko jed­ną kra­wędź [linia prze­pły­wu ste­ro­wa­nia] przy­cho­dzą­cą i/lub jed­ną kra­wędź wychodzącą.”

Przykłady modeli

Poniżej przy­kła­do­wy model pro­ce­su reje­stra­cji fak­tur kosztowych. 

Proces księ­go­wa­nia fak­tur kosz­to­wych (opr. własne)

Używanie ele­men­tów roz­sze­rza­ją­cych nie jest obli­ga­to­ryj­ne, dla­te­go wystę­pu­ją na dia­gra­mach tam gdzie autor mode­lu uzna, że chce je zobra­zo­wać. Notacja eEPC nie ope­ru­je poję­ciem sta­tu­su więc fak­tu­ra zaak­cep­to­wa­na i zaksię­go­wa­na to dwa osob­ne ele­men­ty infor­ma­cyj­ne. Powyższy model pro­ce­su Księgowania fak­tur kosz­to­wych może być pod­pro­ce­sem w pro­ce­sie Obsługi płatności:

Proces biz­ne­so­wy nad­rzęd­ny Obsługa płat­no­ści: tu sym­bol Ścieżka Procesu peł­ni rolę funk­cji dekom­po­no­wa­nej (opr. własne) 

Symboli eEPC moż­na for­mal­nie użyć w innym kon­tek­ście, np. budu­jąc dodat­ko­wy model struk­tu­ry organizacyjnej;

Struktura orga­ni­za­cyj­na wyra­żo­na z uży­ciem nota­cji eEPC (opr. autora)

Autor nota­cji pro­po­nu­je wie­le form sto­so­wa­nia swo­jej nota­cji, łącz­nie z warian­ta­mi nie­uwzględ­nia­ją­cy­mi zasa­dy prze­mien­no­ści funk­cja-zda­rze­nie” (łamiąc wła­sne zasa­dy), co poka­zu­je dość swo­bod­ne podej­ście twór­cy nota­cji do mode­lo­wa­nia, jak np. na poniż­szym diagramie:

Podsumowanie

Notacja eEPC i meto­da ARIS zdo­by­ły sobie szyb­ko dużą popu­lar­ność w obsza­rze ana­liz i wdro­żeń sys­te­mów ERP, za spra­wą związ­ków fir­my IDS Scheer z fir­mą SAP AG. Jednak po ok. 10 latach ist­nie­nia EPC oka­za­ło się, że jej nie­do­stat­ki for­ma­li­za­cyj­ne powo­do­wa­ły dość niską jakość mode­li za spra­wą ich nie­jed­no­znacz­no­ści (ww. brak formalizmu). 

W odpo­wie­dzi na powyż­sze powsta­ła znacz­nie lepiej dopra­co­wa­na nota­cja BPMN. Notacja BPMN zosta­ła pier­wot­nie opra­co­wa­ny przez orga­ni­za­cję Business Process Management Initiative (BPMI). Wersja 1.0 zosta­ła udo­stęp­nio­na publicz­nie w maju 2004 roku. W czerw­cu 2005 r. BPMI połą­czy­ło się z OMG (Object Management Group). Formalna spe­cy­fi­ka­cja BPMN zosta­ła wyda­na przez OMG w lutym 2006 roku (https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/). Co cie­ka­we, w pra­cach nad BPMN bra­ły udział, mię­dzy inny­mi, fir­my IDS Scheer, Software AG i SAP AG.

Moim zda­niem roz­po­czy­na­nie pro­jek­tów z jej uży­ciem w obec­nych cza­sach ma uza­sad­nie­nie tyl­ko tam, gdzie wie­le zain­we­sto­wa­no w zaso­by i gro­ma­dzo­no kom­pe­ten­cje wokół narzę­dzi ARIS. Co jed­nak nie zmia­nia fak­tu, że pozo­sta­wa­nie w tej niszy rodzi poważ­ne ryzy­ko budo­wa­nia dłu­gu tech­no­lo­gicz­ne­go i tak zwa­ne­go ven­dor lock-in. 

Repozytoria ARIS budo­wa­ne są w mode­lu rela­cyj­nym a struk­tu­ra bazy jest obję­ta tajem­ni­cą pro­du­cen­ta, do tego nie ma spe­cy­fi­ka­cji XMI dla eEPC (XML Metadata Interchange) więc migra­cja mode­li do innych narzę­dzi jest prak­tycz­nie nie­moż­li­wa (moż­na je prze­ry­so­wać” w nowym narzę­dziu). Do tego wer­sje same­go ARIS’a bywa­ją nie­kom­pa­ty­bil­ne mię­dzy sobą (prze­cho­dze­nie na now­szą wer­sję wyma­ga­ło już w histo­rii sto­so­wa­nia skom­pli­ko­wa­nych pro­ce­dur). Nadal, od cza­su do cza­su podej­mo­wa­ne są pró­by napra­wy tej sytuacji: 

Mimo tego, że w ostat­nich deka­dach do mode­lo­wa­nia pro­ce­sów powszech­nie sto­su­je się język EPC, brak ofi­cjal­ne­go stan­dar­du pro­wa­dzi do coraz częst­sze­go jego pomi­ja­nia. Spójny meta­mo­del jest pod­sta­wą do okre­śle­nia języ­ków mode­lo­wa­nia pro­ce­sów. W związ­ku z tym, niniej­sza pra­ca budu­je pod­sta­wy dla dal­szej stan­da­ry­za­cji poprzez dostar­cze­nie zin­te­gro­wa­ne­go meta­mo­de­lu dla EPC. Uzyskany w ten spo­sób meta­mo­del wspie­ra oży­wie­nie EPC poprzez uła­twie­nie przy­szłych wysił­ków standaryzacyjnych.

Narzędzie ARIS to obec­nie roz­bu­do­wa­ny pakiet CASE, nadal obec­ny na ryn­ku, mię­dzy inny­mi jako kon­ty­nu­acja wie­lu pro­jek­tów zapo­cząt­ko­wa­nych przed powsta­niem nota­cji BPMN (z pomo­cą tego narzę­dzia powsta­ło wie­le doku­men­ta­cji pro­jek­to­wych, nadal utrzy­my­wa­nych). Jednak, z uwa­gi na to, że nota­cja BPMN, jako znacz­nie lepiej dopra­co­wa­na i funk­cjo­nu­ją­ca jako otwar­ty stan­dard public doma­in, sta­ła się szyb­ko stan­dar­dem de fac­to, eEPC to obec­nie mała nisza i chy­ba już nic tego nie zmieni. 

Notacja EPC jest dostęp­na nie tyl­ko w narzę­dziu ARIS, powyż­sze dia­gra­my powsta­ły z uży­ciem Visual Paradigm, udo­stęp­nia­ją­cym tak­że (nie­stan­dar­do­wą) moż­li­wość ich expor­tu do for­ma­tu XMI. Możliwe jest tu tak­że auto­ma­tycz­ne wyge­ne­ro­wa­nie dia­gra­mów BPMN z dia­gra­mów EPC.

Notacja eEPC, obok BPMN i UML, nadal jest przed­mio­tem naucza­nia na nie­któ­rych uczel­niach w Polsce. 

Źródła

Jannaber, S., Karhof, A., Riehle, D. M., Thomas, O., Delfmann, P., & Becker, J. (2016). Invigorating Event-dri­ven Process Chains – Towards an inte­gra­ted meta model for EPC stan­dar­di­za­tion. 10.
Scheer, A.-W., & Emminghaus, F. (1994). ARIS-tool­set. IDS Prof. Scheer.
Scheer, A.-W., Thomas, O., & Adam, O. (2005). Process Modeling Using Event-Driven Process Chains.

Nowa specyfikacja Business Motivation Model v.1.1 i modelowanie biznesu

Na stro­nach http://​www​.omg​.org/ poja­wi­ła się nowa spe­cy­fi­ka­cja nota­cji [[Business Motivation Model]] (BMM) (źr. BMM.) Notacja ta powsta­ła w celu umoż­li­wie­nia for­mal­ne­go mode­lo­wa­nia biz­ne­spla­nów, a kon­kret­nie mode­li biz­ne­so­wych. Notacja powsta­ła z ini­cja­ty­wy [[Business Rules Group]] (http://​www​.busi​nessru​les​gro​up​.org/​h​o​m​e​-​b​r​g​.​s​h​tml). Manifest tej orga­ni­za­cji zawie­ra tak zwa­ne Zasady Autonomii Reguł (tu w języ­ku pol­skim: http://​www​.busi​nessru​les​gro​up​.org/​b​r​m​a​n​i​f​e​s​t​o​/​B​R​M​a​n​i​f​e​s​t​o​P​L​.​pdf).

BMM ujmu­je wyma­ga­nia biz­ne­so­we w róż­nych wymia­rach, w celu uza­sad­nie­nia dla­cze­go biz­nes chce coś robić, do cze­go dąży, jak zamie­rza to osią­gnąć oraz jak oce­nia rezultaty.”

Po co nowa notacja?

Swego cza­su (rok 2006) pisa­łem o mode­lach biz­ne­so­wych w kon­tek­ście stra­te­gii ryn­ko­wej w arty­ku­le Model biz­ne­so­wy – co to za zwie­rze. Wtedy pisa­łem o tym, że stra­te­gia ma zna­cze­nie i wie­le tłu­ma­czy. Wtedy tak­że dotkną­łem pro­ble­mu słow­nic­twa i sys­te­mu pojęć. Samo zde­fi­nio­wa­nie stra­te­gii nie jest pro­ste, zde­fi­nio­wa­nie poję­cia stra­te­gii zmia­ny jest jesz­cze więk­szym wyzwaniem.

Obszar biz­ne­so­wy jest bar­dzo ubo­gi w [[meto­dy for­mal­ne]]: for­mal­ne nota­cje, sfor­ma­li­zo­wa­ne języ­ki opi­su. W zasa­dzie dys­po­nu­je­my tyl­ko [[nota­cją BPMN]] (mode­le pro­ce­so­we i mode­le współ­pra­cy pro­ce­sów) oraz [[nota­cją ArchiMate]] (mode­le archi­tek­tu­ry kor­po­ra­cyj­nej). [[Notacja eEPC]], koja­rzo­na głów­nie z [[narzę­dziem ARIS]] i fir­mą ISD Scherr odcho­dzi powo­li do histo­rii, o nota­cjach nie­stan­dar­do­wych nawet nie piszę bo od daw­na idą w zapomnienie.

Dla odmia­ny, w sze­ro­ko poję­tej dzie­dzi­nie inży­nie­rii opro­gra­mo­wa­nia, mamy [[nota­cje obiek­to­wą UML]] i jej trzy­na­ście typów dia­gra­mów, mamy nadal uży­wa­ne, zna­ne z ana­li­zy struk­tu­ral­nej nota­cje [[ERD]] i [[DFD]].

[[Notacja BMM]] uzu­peł­nia biz­ne­so­wy sys­tem nota­cyj­ny o obszar poję­cio­wy mode­li biz­ne­so­wych i biz­ne­spla­nów. Pozwala w spo­sób for­mal­ny je opi­sać. [[Przestrzeń nazw]], pod­sta­wo­we poję­cia opi­sa­ne w BMM:

  1. Ends (stan ocze­ki­wa­ny) iden­ty­fi­ku­ją cechy opi­su­ją­ce źró­dła moty­wa­cji (cele) two­rze­nia biznesplanu,
  2. Means (środ­ki) iden­ty­fi­ku­ją narzę­dzia i środ­ki jakich pla­nu­je­my użyć by dopro­wa­dzić do ocze­ki­wa­ne­go (pla­no­wa­ne­go) stanu.
  3. Assessement (uwa­run­ko­wa­nia, ogra­ni­cze­nia) iden­ty­fi­ku­ją wie­dzę o warun­kach pro­jek­tu (w szcze­gól­no­ści ana­li­za SWOT)
  4. Influence (wpływ) iden­ty­fi­ku­ją pozna­ne czyn­ni­ki mogą­ce mieć (mają­ce) wpływ na osią­gnie­cie celu,
  5. Organisation (orga­ni­za­cja) iden­ty­fi­ku­je zaso­by i pro­ce­sy zaan­ga­żo­wa­ne w osią­gnię­cie celu
Całość sta­no­wi rodzaj listy kon­tro­l­nej” zro­zu­mie­nia posta­wio­ne­go pro­ble­mu, jakim jest pro­jekt biz­ne­so­wy, pozwa­la upew­nić się, że zna­my i rozu­mie­my to co ma na nie­go wpływ:

Business Motivation Model (źr. wiki)

Notacja zawie­ra tak­że ele­men­ty ste­ru­ją­ce biz­ne­sem takie jak [[regu­ły biz­ne­so­we]] i zasa­dy zarzą­dza­nia. Zestaw pojęć defi­niu­ją­cych ele­men­ty biz­ne­spla­nów, cechu­je się neu­tral­no­ścią meto­do­lo­gicz­ną oraz pozwa­la jed­no­znacz­nie opi­sać nasza wie­dzę o pro­jek­cie. Oznacza to, że słow­nik pojęć nie jest dedy­ko­wa­ny żad­nej kon­kret­nej meto­dy­ce, a jest jedy­nie for­mal­nym słow­ni­kiem ([[seman­tycz­na prze­strze­nią nazw]]). Powyższe poję­cia są wywie­dzio­ne z zasad­ni­czych pojęć z dzie­dzi­ny mode­lo­wa­nia pro­ce­sów: pro­ces biz­ne­so­wy, regu­ła biz­ne­so­wa, jed­nost­ka orga­ni­za­cyj­na. Bazują one odpo­wied­nio na spe­cy­fi­ka­cjach: BPMN (nota­cja [[OMG Business Process Modeling Notation]]), spe­cy­fi­ka­cji [[OMG Semantics of Business Vocabulary and Business Rules]], oraz RFP [[OMG Organization Structure Metamodel]]. Oznacza to, że nota­cja BMM nie zastę­pu­je ich, a jest dla nich nad­rzęd­na abs­trak­cją. Tak więc pro­ces, jako poje­dyn­cze poję­cie na dia­gra­mie BMM, może zostać szcze­gó­ło­wo opi­sa­ny (model) na innym dia­gra­mie (doku­men­cie), jed­nak defi­ni­cja poję­cia pro­ces biz­ne­so­wy jest taka sama w obu nota­cjach (pro­ces biz­ne­so­wy zawsze musi zna­czyć to samo!).

Poniżej ogól­ny widok pojęć opi­sy­wa­nych nota­cją BMM:

przy­kład two­rze­nia dia­gra­my (klik­nij), oraz model seman­ty­ki i syntaktyki:

BMM nie jest żad­nym narzę­dziem ani meto­dy­ką zarzą­dza­nia czy mode­lo­wa­nia pro­ce­so­we­go, zarzą­dza­nia pro­jek­ta­mi ani spe­cy­fi­ka­cją wzor­co­we­go mode­lu biz­ne­so­we­go. To nota­cja, któ­ra sta­no­wi sobą dobrze zde­fi­nio­wa­ny słow­nik poję­cio­wy (seman­ty­kę) oraz związ­ki pomię­dzy tymi poję­cia­mi (syn­tak­ty­kę, pamię­taj­my, że połą­czo­ne poję­cia nabie­ra­ją kolej­ne­go nowe­go zna­cze­nia, np. kil­ka sko­ja­rzo­nych osób ozna­cza zespół, oso­ba to pro­ste poję­cie, oso­by połą­czo­ne jakimś związ­kiem to grupa).

Wśród wie­lu orę­dow­ni­ków nota­cji UML domi­nu­je teza, że owo Unified (Uniwersalna) w skró­cie UML czy­ni tę nota­cję zdol­ną do mode­lo­wa­nia wszyst­kie­go, jej kolej­ne zasto­so­wa­nia i roz­sze­rze­nia moż­na same­mu opra­co­wać w posta­ci tak zwa­ne­go [[pro­fi­lu UML]]. Owszem, w zasa­dzie teza ta jest praw­dzi­wa jed­nak jest pew­ne ale. Po pierw­sze taki pro­fil to prak­tycz­nie nowa nota­cja: nowe poję­cia (seman­ty­ka) i zasa­dy (syn­tak­ty­ka). Te wyma­ga­ją od stro­ny for­mal­nej wyka­za­nia, że poję­cia (obra­zo­wa­ne z pomo­cą sym­bo­li, zna­ków nota­cji) są roz­łącz­ne, i że seman­tycz­nie (zna­cze­nia­mi) pokry­wa­ją całą mode­lo­wa­ną dzie­dzi­nę. Zapewnienie tego nie jest try­wial­nym problemem.

Tak więc nie tak zno­wu nowa, nota­cja BMM jest przy­dat­na, a dla wie­lu sto­su­ją­cych [[meto­dy for­mal­ne ana­li­zy sys­te­mo­wej]] w tym mode­lo­wa­nie, wręcz potrzeb­na. Nie bra­ku­je gło­sów kry­tycz­nych na temat BMM (np. na blo­gu MSDN), jed­nak oso­bi­ście pod­kre­ślam: nota­cja to nie spo­sób na ana­li­zę a jej narzę­dzie. Notacja nie ma roz­wią­zy­wać wszyst­kich pro­ble­mów, to nie jest srebr­na kula (ang. [[silver bul­let solu­tion]]), któ­rej nie­ste­ty wie­lu nadal szu­ka. Notacja ma poma­gać w roz­wią­zy­wa­niu pro­ble­mów, a to ogrom­na różnica.

Jeżeli kogoś inte­re­su­je nie­co wię­cej szcze­gó­łów o nota­cjach i ich two­rze­niu zapra­szam do dal­szej lektury.

Po co trud­ne” nota­cje sko­ro moż­na pisać po ludzku”

Czy nota­cje mają za cel zastą­pie­nie popu­lar­nej pro­zy? Absolutnie nie! Notacje słu­żą do budo­wy mode­li, któ­re testu­je­my, wery­fi­ku­je, wali­du­je­my. To tak jak z naszym miesz­ka­niem: może­my je w dowol­ny spo­sób opi­sać, mniej lub naj­bar­dziej kwie­ci­stym języ­kiem. Jednak dobry archi­tekt zawsze, nawet na wła­sny uży­tek, stwo­rzy zestaw rysun­ków i wizu­ali­za­cji, by upew­nić się że o niczym nie zapo­mniał. Z pro­jek­tu tech­nicz­ne­go dopie­ro stwo­rzy ład­nie opi­sa­ną pro­zą (języ­kiem natu­ral­nym, zro­zu­mia­łym dla każ­de­go) listę czę­ści i pod­ze­spo­łów, jed­nak ryzy­ko, że tak stwo­rzo­na spe­cy­fi­ka­cja będzie nie­kom­plet­ne teraz jest minimalne.

Zapewne wie­lu z Państwa było w skle­pie IKEA po meble, być może ktoś z Państwa sam je mon­to­wał. Liczba ele­men­tów, łączeń, paso­wań, łącz­ni­ków itp. jest ogrom­na już w śred­niej wiel­ko­ści zesta­wie mebli kuchen­nych. Czy wyobra­ża­cie sobie Państwo zapro­jek­to­wa­nie takich mebli bez spraw­dze­nia na rysun­kach tech­nicz­nych czy nicze­go nie bra­ku­je i czy wszyst­ko do sie­bie pasu­je? A teraz wyobraź­cie sobie Państwo, że więk­szość firm w któ­rych pra­cu­je­cie jest dale­ko bar­dziej skom­pli­ko­wa­na, a mimo to wie­lu ana­li­ty­ków podej­mu­je pró­by opi­sa­nia ich pro­sty­mi sło­wa­mi… jest to nie­mal­że nie­moż­li­we bez popeł­nie­nia wie­lu błędów.

Czym są formalne notacje

Swego cza­su napi­sa­łem w arty­ku­le o nota­cjach i modelowaniu:

Jednym z tych [pod­sta­wo­wych w sto­sun­ku do mode­li i uży­wa­nych w nich nota­cji] wyma­gań jest spój­ny i peł­ny model poję­cio­wy. Tak zwa­na prze­strzeń nazw (w nota­cji jest to lista sym­bo­li i defi­ni­cje ich zna­czeń) powin­na być ?wypeł­nio­na? defi­ni­cja­mi cał­ko­wi­cie, zaś obsza­ry defi­nio­wa­nych pojęć nie mogą na sie­bie nacho­dzić. (źr. Modelowanie pro­ce­sów biz­ne­so­wych).

Nieco bli­żej o tym. Notacja to model poję­cio­wy, zestaw sym­bo­li i ich zna­czeń (seman­ty­ka) oraz gra­ma­ty­ka łącze­nia tych pojęć (tak zwa­na syn­tak­ty­ka czy­li dopusz­czal­ne związ­ki pomię­dzy poję­cia­mi i ich zna­cze­nia). W czym pro­blem? Poniżej dia­gram go obrazujący.

Slajd10

Zestaw wszyst­kich słów-sym­bo­li to lista dopusz­czal­nych w mode­lu (opi­sie) pojęć i jest to wła­śnie tak zwa­na seman­ty­ka nota­cji (prze­strzeń nazw). Koło ozna­cza wybra­ną dzie­dzi­nę (np. mode­le biz­ne­so­we i biz­ne­spla­ny). Kółeczka z krzy­ży­ka­mi to poję­cia (obra­zo­wa­ne w nota­cjach sym­bo­la­mi, iko­na­mi nota­cji), dopusz­czal­ne sło­wa ze słow­ni­ka, któ­re­go chce­my użyć do opi­sa­nia cze­goś w danej dzie­dzi­nie (zwa­nej tak­że domeną).

Po lewej stro­nie mamy namiast­kę nie­for­mal­ne­go, potocz­ne­go języ­ka: to co widzi­my, poję­cia, byty czy­li krzy­ży­ki oraz sło­wa pozwa­la­ją­ce na ich nazwa­nie (ciem­niej­sze obsza­ry). Język potocz­ny cha­rak­te­ry­zu­je się tym, że zawie­ra sło­wa okre­śla­ją­ce róż­ne poję­cia (dwa krzy­ży­ki w jed­nym polu zna­cze­nio­wym, np. zamek to budow­la ale tak­że mecha­nizm zamknię­cia drzwi), poja­wia­ją się róż­ne sło­wa na jed­no zna­cze­nie (krzy­żyk nale­żą­cy do dwóch róż­nych obsza­rów, np. gar­nek i saga­nek to nie raz to samo naczy­nie). Pojawiają się tak­że byty nie mają­ce ozna­cza­ją­cych je słów (w danym języ­ku oczy­wi­ście, krzy­żyk nie przy­po­rząd­ko­wa­ny do żad­ne­go pola, np. inter­fejs, któ­ry nie ma swo­je­go odpo­wied­ni­ka w języ­ku pol­skim, uży­wa­my sło­wa angielskiego).

Taka sytu­acja, opi­sa­ne nie­jed­no­znacz­no­ści, powo­du­je, że typo­wy prze­kaz tek­sto­wy jest prze­ka­zem nie­jed­no­znacz­nym: czy­ta­ją­cy może odczy­tać z tek­stu coś inne­go niż to co miał na myśli jego autor. Nie da się go, takie­go tek­stu, zwe­ry­fi­ko­wać od stro­ny spój­no­ści i kom­plet­no­ści opi­sy­wa­nej rzeczywistości.

Po pra­wej stro­nie mamy sytu­ację ide­al­ną: pojęć jest dokład­nie tyle ile zna­czeń (słów), każ­de poję­cie ma tyl­ko jed­no zna­cze­nie zaś tak zwa­na prze­strzeń nazw (obszar, do któ­re­go nale­żą, miesz­czą­cy wszyst­kie poję­cia danej dzie­dzi­ny) jest zupeł­nie opi­sa­ny (brak obsza­ru, zna­cze­nia, nie obję­te­go zadnym sło­wem). Opisanie cze­goś języ­kiem” (sło­wa­mi) z takiej prze­strze­ni nazw czy­ni prze­kaz jed­no­znacz­ny w 100% (nie ist­nie­ją w danej prze­strze­ni syno­ni­my i nie ma pojęć nie­zde­fi­nio­wa­nych). Jak być może nie trud­no się domy­śleć, opra­co­wa­nie sys­te­mu poję­cio­we­go speł­nia­ją­ce­go powyż­sze wyma­ga­nia, nie jest łatwe.

Dobra nota­cja ma jesz­cze jed­ną istot­ną cechę: sym­bo­le obra­zu­ją­ce poszcze­gól­ne poję­cia powin­ny się z nimi koja­rzyć nie­za­leż­nie od języ­ka natu­ral­ne­go. To nazy­wa­my [[semio­ty­ką]]. Jest to nauka o tym jak czło­wiek postrze­ga (rozu­mie, odbie­ra) poszcze­gól­ne zna­ki gra­ficz­ne (sym­bo­le, iko­ny). To tak­że powo­du­je, że dąży się do stan­da­ry­za­cji czy­li nie mno­że­nia nad­mia­ru sys­te­mów nota­cyj­nych (patrz [[brzy­twa Ockhama]]). To dla­te­go two­rze­nie wła­snych nota­cji jest trosz­kę pozba­wio­ne sen­su: jest bar­dzo trud­ne i odda­la nas od standardów.

Na zakończenie

Stosowanie ana­li­zy sys­te­mo­wej, mode­lo­wa­nia oraz for­mal­nych nota­cji do two­rze­nia mode­li, powo­du­je, że wyni­ki ana­liz są dale­ko bar­dziej wia­ry­god­ne. Z regu­ły celem pra­cy ana­li­ty­ka biz­ne­so­we­go czy pro­jek­tan­ta jest opra­co­wa­nie opi­su reko­men­do­wa­ne­go roz­wią­za­nia. Może nim być doce­lo­wy model orga­ni­za­cji czy też opis opro­gra­mo­wa­nia jakie nale­ży dostar­czyć (bo nie zawsze wytwo­rzyć!). W pro­ce­sie for­mal­nej ana­li­zy sys­te­mo­wej (nie jest to ana­li­za sys­te­mu infor­ma­tycz­ne­go, to ana­li­za dowol­ne­go sys­te­mu), powsta­ją mode­le, któ­re testujemy.

Taki model to naj­pierw hipo­te­za, a po wery­fi­ka­cji, jest to opis roz­wią­za­nia (pro­jekt tego co ma powstać). Idealną sytu­acją była by taka, a któ­rej mamy narzę­dzia do mode­lo­wa­nia każ­dej ana­li­zo­wa­nej dzie­dzi­ny. W kla­sycz­nej inży­nie­rii jest to rysu­nek tech­nicz­ny i zasa­dy obli­cza­nia wytrzy­ma­ło­ści, sfor­ma­li­zo­wa­ny sys­tem two­rze­nia sche­ma­tów elek­trycz­nych i elek­tro­nicz­nych i wie­le innych (zależ­nie od dzie­dzi­ny), nota­cje UML w inży­nie­rii opro­gra­mo­wa­nia. W sfe­rze zarzą­dza­nia mie­li­śmy do nie­daw­na bia­ła pla­mę, teraz mamy już BMM czy ArchiMate.

Moim zda­niem utrzy­my­wa­nie, że moż­na coś sku­tecz­nie ana­li­zo­wać meto­da­mi nie­for­mal­ny­mi świad­czy raczej o nie­wie­dzy i bra­ku kom­pe­ten­cji. Bo jak ina­czej nazwać nara­ża­nie adre­sa­ta pro­jek­tu (nie raz klien­ta) na masę nie­spój­no­ści owo­cu­ją­cych lawi­no­wo rosną­cy­mi kosz­ta­mi reago­wa­nia na nie­prze­wi­dzia­ne szcze­gó­ły? Nie raz sły­sza­łem, że to trud­ne, tyl­ko dla jajo­gło­wych, kosz­tow­ne. Owszem, ale nie zapo­mi­naj­my, że ana­li­za to nie coś co każ­dy sobie sam może zro­bić. Dobra ana­li­za nigdy nie jest kosz­tow­niej­sza niż poten­cjal­ne, ryzy­ko­wa­ne stra­ty – opła­ci się zawsze.

Prezentacja opi­su­ją­ca klu­czo­we ele­men­ty nota­cji BMM

Przykład uży­cia nota­cji BMM: spo­sób mode­lo­wa­nia.

Skrócony opis – klu­czo­we pojęcia.

O błędach w modelowaniu

Kluczowe błę­dy jakie obser­wu­ję w pre­zen­to­wa­nych mi nie raz przez klien­tów do audy­tu cudzych opra­co­wa­niach i mode­lach to moim zda­niem zupeł­nie zbęd­ne opi­sy i mode­le czyn­no­ści oczy­wi­stych, będą­cych kom­pe­ten­cją pra­cow­ni­ka lub po pro­stu zwy­cza­jo­wych lub co gor­sza są to nie­po­trzeb­ne mode­le posia­da­nych instruk­cji obsłu­gi i pod­ręcz­ni­ków użyt­kow­ni­ka sprzę­tu lub uży­wa­ne­go opro­gra­mo­wa­nia. Drugim czę­sto spo­ty­ka­nym błę­dem jest zupeł­ny brak meto­dy­ki two­rze­nia mode­lu czy­li brak tego o czym już nie raz wspo­mi­na­łem: seman­ty­ki i syn­tak­ty­ki mode­lu. Inaczej mówiąc model musi mieć okre­ślo­ny słow­nik sym­bo­li i zasa­dy ich łącze­nia. Rozumiem, że błęd­ne mode­le wyko­nu­ją nie­do­świad­cze­ni ana­li­ty­cy. Jednak szkol­ne błę­dy obser­wu­ję w pra­cach ludzi i firm bio­rą­cych za to pie­nią­dze, nie raz bar­dzo duże. Nie raz są to nie­ste­ty posia­da­ją­ce świa­to­wą mar­kę fir­my doradcze.

Uważam, że naj­pro­ściej jest sto­so­wać stan­dar­dy. Np. do mode­lo­wa­nia pro­ce­sów uży­wać nota­cji BPMN a do ana­li­zy obiek­to­wej nota­cji UML, obie z okre­ślo­ną i dostęp­ną w sie­ci WWW meto­dy­ką mode­lo­wa­nia (http://​www​.omg​.org). Jeszcze sto­sun­ko­wo popu­lar­na jest w nie­któ­rych zasto­so­wa­niach nota­cja eEPC rodem z fir­my IDS Scheer. W uza­sad­nio­nych przy­pad­kach moż­na stwo­rzyć wła­sną pro­stą nota­cję. Sama nota­cja jed­nak nie chro­ni nas przed popeł­nia­niem błę­dów ana­li­tycz­nych podob­nie jak sama nor­ma opi­su­ją­ca wymia­ry i zasto­so­wa­nie gniazd­ka elek­trycz­ne­go w ścia­nie nie chro­ni niko­go przed wetknię­ciem tam goły­mi ręka­mi gwoź­dzia.

Jak, co i po co modelować

Poprawny model orga­ni­za­cji, w szcze­gól­no­ści mapa pro­ce­sów biz­ne­so­wych, powi­nien opi­sy­wać tyl­ko przed­miot ana­li­zy np. spe­cy­fi­kę orga­ni­za­cji będą­ca np. źró­dłem jej prze­wa­gi kon­ku­ren­cyj­nej i to jak orga­ni­za­cja tę spe­cy­fi­kę two­rzy. Model powi­nien się odwo­ły­wać do innych ist­nie­ją­cych już doku­men­tów, np. zakre­su kom­pe­ten­cji pra­cow­ni­ka czy instruk­cji sta­no­wi­sko­wej. Model zawsze powi­nien mieć jakiś cel swo­je­go powsta­nia i kontekst.

Poniżej ogól­na zasa­da mode­lo­wa­nia organizacji:

źr. Busnes Process Trends http://www.bptrendsassociates.com/
źr. Busnes Process Trends http://​www​.bptrend​sas​so​cia​tes​.com/

Diagram powyż­szy poka­zu­je trzy war­stwy, pozio­my szcze­gó­ło­wo­ści, mode­lo­wa­nia sta­no­wią­ce osob­ne eta­py pro­jek­tu mode­lo­wa­nia orga­ni­za­cji. Sam model nie powi­nien jed­nak być przed­mio­tem pro­jek­tu bo sam z sie­bie moim zda­niem prak­tycz­nie do nicze­go nie słu­ży poza poło­że­niem go na pół­ce. Model to narzę­dzie ana­li­tycz­ne wspo­ma­ga­ją­ce pra­ce nad reor­ga­ni­za­cją, oce­ną ren­tow­no­ści inwe­sty­cji, ana­li­zą wyma­gań na sys­te­my IT itp. Głównym celem jego wyko­na­nia jest zro­zu­mie­nie ana­li­zo­wa­ne­go przed­mio­tu i wypra­co­wa­nie rekomendacji.

Celowość każ­de­go mode­lu zale­ży od rodza­ju pro­jek­tu. Jeżeli two­rzy­my biz­ne­splan lub to wystar­czy model biz­ne­so­wy. Jeżeli pla­nu­je­my opty­ma­li­za­cję fir­my, ana­li­zę ren­tow­no­ści inwe­sty­cji lub wdro­że­nie Zrównoważonej Karty Wyników to nale­ży wyko­nać model pro­ce­sów biz­ne­so­wych. Jeżeli zaś inte­re­su­ją nas szcze­gó­ły anga­żo­wa­nych zaso­bów w pro­ce­sach, sce­na­riu­sze reali­za­cji poszcze­gól­nych pro­ce­sów itp. wyko­nu­je­my opi­sy wnę­trza pro­ce­sów czy­li doku­men­tu­je­my ich sce­na­riu­sze lub two­rzy­my tak zwa­ne procedury.

Jak nie trud­no sie domy­ślić w mia­rę prze­miesz­cza­nia się w dół pira­mi­dy pra­co­chłon­ność, a co za tym idzie i koszt, wyko­na­nia tych mode­li szyb­ko rośnie­dla­te­go nale­ży bar­dzo ostroż­nie decy­do­wać się na podej­mo­wa­nie sie ich reali­za­cji. Sugeruję przy­ję­cie zało­że­nia w któ­rym taka ana­li­za i model słu­żą obni­że­niu ryzy­ka podej­mo­wa­nych decy­zji. Przy takim podej­ściu moż­li­wa sta­je sie oce­na ren­tow­no­ści pro­jek­tu ana­li­tycz­ne­go i łatwiej jest okre­ślić budżet na taki pro­jekt. Konsultant powi­nien umieć taka oce­nę przeprowadzić.

W rapor­tach z ana­liz powin­na być utrzy­my­wa­na zasa­da, że dla jed­nej oso­by doku­men­ta­cja (lub jej część adre­so­wa­na do oso­by peł­nią­cej w fir­mie kon­kret­ną funk­cję) nie powin­na prze­kra­czać kil­ku­dzie­się­ciu stron łącz­nie z dia­gra­ma­mi (bez załącz­ni­ków). Dokumenty dłuż­sze z regu­ły nie są czy­ta­ne i moim zda­niem nicze­mu nie słu­żą, są kosz­tow­ne i nie­przy­dat­ne. Dokumentacja ana­li­zy, to sko­men­to­wa­ne dia­gra­my opi­su­ją­ce pro­blem i jego roz­wią­za­nie. Tekst sta­no­wi stresz­cze­nie i ewen­tu­al­ny opis tego co wyma­ga­ło by słow­ne­go prze­ka­zu. Wybrane dia­gra­my umiesz­cza­ne w tek­ście powin­ny sta­no­wić ilu­stra­cję jego tre­ści. Dokładne ich wer­sje nale­ży umiesz­czać w załącz­ni­kach do któ­rych zain­te­re­so­wa­na oso­ba zawsze może zaj­rzeć. Każdy raport powi­nien mieć na począt­ku jed­no­stro­ni­co­we stresz­cze­nie, pod­kre­ślam: JEDNOSTRONICOWE.Konieczność zamknię­cia stresz­cze­nia na jed­nej stro­nie zmu­sza do sku­pie­nia się na klu­czo­wym ele­men­cie pro­jek­tu bo tyl­ko ten jest istot­ny dla naj­wyż­szych władz w firmie.

O analizie wymagań na system IT

Projekt, któ­re­go celem jest okre­śle­nie wyma­gań na sys­tem infor­ma­tycz­ny wymaga:

  • ana­li­zy oto­cze­nia ryn­ko­we­go orga­ni­za­cji, w któ­rej ma być pro­wa­dzo­ne wdrożenie,
  • mode­lu wewnętrz­ne­go funk­cjo­no­wa­nia czy­li map pro­ce­sów biznesowych,
  • okre­śle­nia, któ­re pro­ce­sy biz­ne­so­we będą wspie­ra­ne nowym sys­te­mem czy­li okre­śle­nia zakre­su projektu
  • opi­sa­nia danych, któ­re sys­tem będzie prze­twa­rzał i wyko­na­nie ich modelu,

Celem ana­li­zy oto­cze­nia ryn­ko­we­go orga­ni­za­cji jest upew­nie­nie się, że rozu­mie­my spo­sób jej funk­cjo­no­wa­nia. Analiza powin­na poka­zać co jest głów­nym przed­mio­tem dzia­łal­no­ści orga­ni­za­cji. Wiedza ta umoż­li­wia okre­śle­nie prio­ry­te­tu każ­dej ocze­ki­wa­nej od nowe­go sys­te­mu funk­cjo­nal­no­ści i ewen­tu­al­ne świa­do­me ich mody­fi­ka­cje w przy­pad­ku gdy budżet pro­jek­tu nie pozwo­li zre­ali­zo­wać wszyst­kich ocze­ki­wań. Pozwala tak­że na wza­jem­ne zro­zu­mie­nie dzia­łal­no­ści Firmy przez wyko­naw­cę i zle­ce­nio­daw­cę, bez któ­re­go nie wyobra­żam sobie żad­ne­go sku­tecz­ne­go wdro­że­nia i analizy.

Wykonanie mode­lu funk­cjo­no­wa­nia orga­ni­za­cji to zbu­do­wa­nie mapy jej pro­ce­sów biz­ne­so­wych. Celem jest opi­sa­nie jak orga­ni­za­cja pra­cu­je (two­rzy war­tość ryn­ko­wą) i doko­na­nie ewen­tu­al­nych zmian w celu jej ulep­sze­nia. Jest to opis tego jak w fir­mie powsta­je war­tość dodana.

Kolejnym eta­pem jest okre­śle­nie, któ­re pro­ce­sy biz­ne­so­we chce­my wes­przeć nowym sys­te­mem i czy jest to ren­tow­ne. Uzyskujemy tą meto­dą defi­ni­cję zakre­su pro­jek­tu i jego ocze­ki­wa­ny gra­nicz­ny budżet. Metoda ta jest zgod­na z archi­tek­tu­ra SOA (Service Oriented Architekcture, ang. Architektura [sys­te­mu IT] Zorientowana na Usługi).

Jednocześnie ana­li­zu­je­my infor­ma­cje prze­twa­rza­ne w orga­ni­za­cji i two­rzy­my ich model (model danych). Stanie się on pod­sta­wą wyma­gań na bazę danych, któ­ra jest fun­da­men­tem każ­de­go sys­te­mu infor­ma­tycz­ne­go. Ten opis jest klu­czo­wym ele­men­tem spe­cy­fi­ka­cji wyma­gań. Błędy i nie­do­pa­trze­nia powsta­łe na tym eta­pie (zły opis prze­twa­rza­nych danych) powo­du­ją bar­dzo kosz­tow­ne mody­fi­ka­cje w trak­cie reali­za­cji i wdro­że­nia systemu.

Model pro­duk­tów takiej ana­li­zy moż­na zilu­stro­wać w nastę­pu­ją­cy sposób:

Projekt dla fikcyjnej firmy.

W odpo­wie­dzi na licz­ne pyta­nia opra­co­wa­łem przy­kład takiej ana­li­zy. Analiza ta pre­zen­to­wa­na jest w for­mie uprosz­czo­nej w celu zade­mon­stro­wa­nia jej tre­ści a nie obję­to­ści. Treść i sto­pień szcze­gó­ło­wo­ści każ­do­ra­zo­wo są usta­la­ne zależ­nie od kon­tek­stu i celu pro­jek­tu. Osoby zain­te­re­so­wa­ne tym doku­men­tem zapra­szam na kurs mode­lo­wa­nia: Projekt

Modelowanie biznesowe, czy to już dojrzała dyscyplina?

Na razie widzę, że kla­ru­ją się dwa podejścia:

- IDEF0 lub ICOM i pochod­ne (w tym EPC i eEPC)

- inne idą w kie­run­ku UML

IDEF0 to kom­plet­ny model logicz­ny uwzględ­nia­ją­cy zaso­by i cele biz­ne­so­we (któ­re nie­ste­ty czę­sto zatra­ca się w pro­ce­sie mode­lo­wa­nia!). UML to dro­ga do zapro­jek­to­wa­nia apli­ka­cji. Myślę, że tą dro­gą w środ­ku spo­tka­ją się ana­li­ty­cy i pro­gra­mi­ści. W miej­scu gdzie mamy model pro­ce­so­wy i pro­ce­du­ry (work­flow) na naj­niż­szym pozio­mie dekom­po­zy­cji pro­gra­mi­sta obiek­to­wy ma wszyst­kie infor­ma­cje by z pomo­cą UML zapro­jek­to­wać i napi­sać kod apli­ka­cji. Każdy pro­sty ?blo­czek? mode­lu oraz inter­fej­sy (for­mat­ki doku­men­tów) mogą teraz zostać zaim­ple­men­to­wa­ne w sys­te­mie. Być może od stro­ny mode­lo­wa­nia BPMN (Business Process Modeling Notation) a od stro­ny kodo­wa­nia BPEL wnio­są uła­twie­nie pole­ga­ją­ce na umoż­li­wie­niu pew­nej auto­ma­ty­za­cji two­rze­nia pro­gra­mów jed­nak w moim prze­ko­na­niu waż­niej­sze jest by pre­cy­zyj­nie wska­zać gra­ni­ce kom­pe­ten­cji pomię­dzy ana­li­ty­kiem a inży­nie­rem i dokład­nie na tej gra­ni­cy umie­ścić styk narzę­dzi ana­li­tycz­nych i inżynierskich.

Modelowanie to dzie­dzi­na pra­wie tak sta­ra jak sys­te­my infor­ma­tycz­ne dla biz­ne­su. Podstawowym celem mode­lo­wa­nia pro­ce­sów jest opi­sa­nie fir­my, okre­śle­nie celu pro­jek­tu reor­ga­ni­za­cyj­ne­go i jego zakre­su, okre­śle­nie wyma­gań na two­rzo­ne opro­gra­mo­wa­nia a wcze­śniej opty­ma­li­za­cji orga­ni­za­cji i przy­go­to­wa­nie jej do wdro­że­nia. Stworzenie opi­su funk­cjo­nal­ne­go tego co będzie­my opro­gra­mo­wy­wać zawsze było wyzwa­niem trud­nym. Drugim, być może jesz­cze trud­niej­szym jest (do dzi­siaj) nawią­za­nie nici poro­zu­mie­nia i zro­zu­mie­nia pomię­dzy sfe­rą biz­ne­su a inży­nie­ra­mi i programistami.

Jedna z ról jaką ma do ode­gra­nia wyko­na­ny przez ana­li­ty­ków model jest stwo­rze­nie szkie­le­tu apli­ka­cji lub przy­naj­mniej opi­su tego szkie­le­tu. Naturalnym dąże­niem jest tak­że pró­ba unik­nię­cia ręcz­ne­go prze­pi­sy­wa­nia” pra­cy ana­li­ty­ków biz­ne­so­wych mode­lu i wyge­ne­ro­wa­nie na jego pod­sta­wie kodu apli­ka­cji lub przy­naj­mniej jej mode­lu np. w posta­ci UML.

Notacje i meto­dy­ki mode­lo­wa­nia moż­na podzie­lić na dwie grupy:

  1. mode­lo­wa­nie do pro­wa­dze­nia ana­liz i opty­ma­li­za­cji pro­ce­sów i zda­rzeń gospo­dar­czych (pro­ce­sów biznesowych)
  2. mode­lo­wa­nie do celów two­rze­nia oprogramowania

Na świe­cie nadal naj­po­pu­lar­niej­sze są: IDEF wśród ana­li­ty­ków i UML wśród programistów.

Modele analityczne

Tu się nie­wie­le zmie­ni­ło. Nadal w uży­ciu jest IDEF0 i jego odmia­ny a raczej warian­ty czy­li ICOM i mniej zna­ny IGOE. Skrót ICOM to: Input, Controll, Output, Mechanizm czy­li Wejście, Sterowanie, Wyjście, Mechanizm (tu cho­dzi o zaso­by). Skrót IGOE ma roz­wi­nie­cie: Input, Guide (odpo­wied­nik ste­ro­wa­nia), Output, Enabler (tu cho­dzi o zaso­by w kon­tek­ście ini­cja­to­ra reali­za­cji danej funk­cji). W obu przy­pad­kach ogól­ny sche­mat pro­ce­su w tych kon­wen­cjach przed­sta­wia­ny jest za pomo­cą pro­sto­ką­ta sym­bo­li­zu­ją­ce­go funk­cję reali­zo­wa­ną przez pro­ces oraz strzał­ki obra­zu­ją­ce wymie­nio­ne czte­ry jego atrybuty :

Na tym pozio­mie powsta­ło wie­le pro­duk­tów, któ­re nie­ste­ty zawie­ra­ją swo­je uni­kal­ne roz­sze­rze­nia sym­bo­li i reguł. Doprowadziło to powsta­nia wie­lu narzę­dzi do mode­lo­wa­nia, któ­rych pro­duk­ty są ze sobą nie­kom­pa­ty­bil­ne już na pozio­mie uży­tych sym­bo­li. Nie wymie­nia­jąc ich tu napi­sze, tyl­ko, że w dość powszech­nym uży­ciu jest ich pra­wie dzie­sięć a Gartner ziden­ty­fi­ko­wał ich na ryn­ku trzy­dzie­ści sześć. Z tego też powo­du uży­wam w pra­cy sym­bo­li ICOM pro­stych i zro­zu­mia­łych dla biz­ne­su zaś w przy­pad­kach bar­dziej sfor­ma­li­zo­wa­nych” uży­wam IDEF0. Z uwa­gi na sta­ły roz­wój tak­że tych metod osta­nio zain­te­re­so­wą­łem się nota­cją BPMN.

Modelowanie do celów tworzenia oprogramowania

Ten temat jest dużo trud­niej­szy, gdyż dąże­nie do reali­za­cji sprzę­gu” pomię­dzy ana­li­ty­kiem a infor­ma­ty­kiem to temat ist­nie­ją­cy od począt­ku cza­sów two­rze­nia opro­gra­mo­wa­nia do celów biz­ne­so­wych. Krótka histo­ria narzę­dzi do mode­lo­wa­nia na potrze­by two­rze­nia opro­gra­mo­wa­nia (rok powsta­nia i nazwa metody):

  • 1962: sie­ci Petriego (Carl Petri Network)
  • 1970: ANSI Flow charts
  • 1979: DFD (Data Flow Diagram)
  • 1982: ISO TC87 (ISO Conceptual Schema Model)
  • 1992: Merise (Methode d’Etude et de Realisation Informatique pour les Systemes d’Enterprice)
  • 1992; EPC (Eventdriven Process Chains)
  • 1995: IDEF3 (Integrated Definition Method 3, Process Description Capture Method)
  • 2001: ebXML v.1.1 (elec­tro­nic busi­ness using eXtesible Markup Language)
  • 2002: BPML v.1.1 (Busines Process Modeling Language)
  • 2002: WSCi v.1.0
  • 2003: BPEL4WS (Business Process Execution Language for Web Services)
  • 2004: BPMN (Business Process Modeling Notation)

(na pod­sta­wie Process mode­ling – A Maturing Discipline?”, Michael Rosemann, Maria Indulska, Peter Green, Quinsland University of tech­no­lo­gy Information).

Sieci Petriego są nadal uwa­ża­ne za jed­no z naj­sku­tecz­niej­szych narzę­dzi do mode­lo­wa­nia jed­nak ich głów­nym ogra­ni­cze­niem jest dość skom­pli­ko­wa­ny model mate­ma­tycz­ny oraz brak hie­rar­chi­za­cji funk­cji jak to ma miej­sce w real­nych orga­ni­za­cjach. Nie zawie­ra też w sobie narzę­dzi do opi­su archi­tek­tu­ry obiek­to­wej opro­gra­mo­wa­nia. Metody two­rze­nia opro­gra­mo­wa­nia zorien­to­wa­ne obiek­to­wo dopro­wa­dzi­ły do powsta­nia narzę­dzi typu UML jed­nak są one bar­dzo trud­ne do zasto­so­wa­nia w mode­lo­wa­niu biz­ne­so­wym gdyż natu­ra orga­ni­za­cji jest hie­rar­chicz­na a nie obiek­to­wa. Modele obiek­to­we są po pierw­sze prak­tycz­nie nie­zro­zu­mia­łe dla biz­ne­su po dru­gie nie spraw­dza­ją się jako narzę­dzie do opi­su orga­ni­za­cji, któ­ra żyje i ewo­lu­uje. Stale roz­wi­ja­ją­ce się meto­dy zarzą­dza­nia ewo­lu­ują w stro­nę pro­ce­sów biz­ne­so­wych ich natu­ra zaś jest jest hie­rar­chicz­na. Kolejną pró­bą roz­wią­za­nia pro­ble­mu jest powsta­nie BPMN.

BPMN – Business Process Modeling Notation

Ideą twór­ców BPMN jest stwo­rze­nie narzę­dzia dla ana­li­ty­ków ale takie­go, któ­re­go pro­duk­ty da się tłu­ma­czyć” na BPEL4WS. Bazą dla BPMN są sie­ci Petriego i EPC. Dla tego z jed­nej stro­ny kom­plet­na lista sym­bo­li BPMN to 38 sym­bo­li obra­zu­ją­cych typo­we zda­rze­nia biz­ne­so­we dają­ce się odwzo­ro­wać za pomo­cą BPEL4WS, mode­lo­wać zaś moż­na już za pomo­cą sze­ściu pod­sta­wo­wych, któ­re pozwa­la­ją na zbu­do­wa­nie peł­ne­go mode­lu pro­ce­sów biz­ne­so­wych. Pozostałe sym­bo­le słu­żą do dodat­ko­we­go defi­nio­wa­nia zda­rzeń koniecz­nych z punk­tu widze­nia inży­nie­rii opro­gra­mo­wa­nia. Dlatego np. model wyko­na­ny za pomo­cą pod­sta­wo­we­go zesta­wu sym­bo­li przez ana­li­ty­ka da się łatwo uzu­peł­nić jako kon­ty­nu­acja pro­jek­tu o bra­ku­ją­ce ele­men­ty w celu wyge­ne­ro­wa­nia kodu dla BPEL. ten zaś być może będzie stan­dar­dem słu­żą­cych do gene­ro­wa­nia kodu apli­ka­cji jak daw­ne sys­te­mu typu CASE.

Notatka: W tym roku (2005) opu­bli­ko­wa­no wer­sję 1.0 nota­cji BPMN (Business Process Modeling Notation). 12 Września 2005 w Atlancie odby­ła się kon­fe­ren­cja BPMN Foundation na któ­rej mię­dzy inny­mi ogło­szo­no połą­cze­nie Notation Working Group z OMG i spe­cy­fi­ka­cję BPMN v.1.0. W pla­nie jest RFC.