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.

BPM vs. BPMS

Skróty te ozna­cza­ją odpo­wied­nio (w j.ang): Business Process Management oraz Business Process Management Software. Budzą one wie­le nie­po­ro­zu­mień i nie­zro­zu­mie­nia. Pierwsze to Zarządzanie pro­ce­sa­mi biz­ne­so­wy­mi” rozu­mia­ne jako dzia­łal­ność zwią­za­na z zarzą­dza­niem orga­ni­za­cją. Drugie to Oprogramowanie [słu­żą­ce] do zarzą­dza­nia pro­ce­sa­mi biz­ne­so­wy­mi” czy­li jakaś apli­ka­cja, któ­rej wewnętrz­ne dzia­ła­nie jest opi­sa­ne procesami.

Ten wpis zapew­ne wywo­ła wie­le kon­tro­wer­sji, gdyż opi­su­ję tu przy­czy­ny, dla któ­rych moim zda­niem, sys­te­my BPMS nie two­rzą war­to­ści doda­nej. Nie widzę sen­su ich sto­so­wa­nia w wer­sji pro­cess engi­ne”, moim zda­niem nie zastą­pią nawet czę­ści typo­wych aplikacji”.

Ale po kolei… Niedawno po raz kolej­ny zosta­łem zapy­ta­ny o… no wła­snie. O co?

[czy­tel­nik]:
Panie Jarosławie,
ostat­nio zda­rzy­ło mi się przejść przez parę ele­men­tar­nych pytań, któ­re przez wie­lu są pomi­ja­ne. Wszyscy mówią o sze­ro­kim spoj­rze­niu na biz­nes, o pro­jek­to­wa­niu pro­ce­sów, zależ­no­ści pomię­dzy nimi. Racja. To wszyst­ko da się zro­bić np. w Visual Paradigm. Później jed­nak chciał­bym przejść do BPMS i powo­łać do życia jeden z opi­sa­nych wcze­śniej pro­ce­sów. Jak utrzy­mać rela­cję pomię­dzy mode­lem pro­ce­sów np. w Visual Paradigm, a tym co się dzie­je w sil­ni­kach procesowych?

Jarosław Żeliński:
Przede wszyst­kim war­to pamię­tać, że:
– śro­do­wi­skiem (kon­tek­stem) dla mode­li ana­li­tycz­nych pro­ce­sów (non-exe­cu­ta­ble w BPMN) jest mode­lo­wa­na orga­ni­za­cja (w tym kon­tek­ście pule na mode­lu współ­pra­cy są organizacjami),
– śro­do­wi­skiem (kon­tek­stem) dla maszy­no­wych mode­li pro­ce­sów (exe­cu­ta­ble) jest ser­wer BPMS (tu na mode­lu współ­pra­cy pula­mi są ser­we­ry BPMS, moto­ry procesów”).

Powyższe powo­du­je, że dany model albo jest biz­ne­so­wy albo maszy­no­wy (wyko­ny­wal­ny). Często jest tak, że jed­na fir­ma (orga­ni­za­cja) ma tyl­ko jeden ser­wer BPMS, ale im więk­sza fir­ma tym bar­dziej praw­do­po­dob­ne, że będzie ich wię­cej (np. oddziałowe).

Tak więc pierw­szy krok to zade­kla­ro­wa­nie jaki kon­tekst mają dane mode­le (ich sys­tem z dekom­po­zy­cją). Jeżeli zade­kla­ru­je­my, że two­rzy­my mode­le wyko­ny­wal­ne, to w struk­tu­rze mode­li trze­ba trzy­mać dys­cy­pli­nę pre­cy­zji mode­lo­wa­nia by ich eks­port np. do XPDL gene­ro­wał popraw­ne pliki.

[czy­tel­nik]:
Chodziło mi o podej­ście BPM (jako spo­sób zarzą­dza­nia fir­mą) i o wyko­rzy­sta­nie narzę­dzi infor­ma­tycz­nych. W narzę­dziach BPMS nie ma moż­li­wo­ści zobra­zo­wa­nia wie­lu mode­li pro­ce­sów oraz śle­dze­nie zależ­no­ści mię­dzy nimi. Musimy to robić w innym narzę­dziu. Z Pana wypo­wie­dzi wyni­ka, że jeże­li nie wyko­rzy­stu­je­my żad­ne­go inne­go narzę­dzia oprócz BPMS, to nie jest moż­li­we mode­lo­wa­nie cało­ścio­we­go obra­zu przed­się­bior­stwa. Co jeże­li klient chce wpro­wa­dzać BPM (świa­do­mie) i zaczy­na od 1,2 pro­ce­sów – koń­czy na 50 pro­ce­sach. Powinienem utrzy­my­wać dodat­ko­wo archi­tek­tu­rę w VP? Czy trzy­mać po pro­stu odręb­ne pro­ce­sy w BPMS?

Jarosław Żeliński:
Teraz (chy­ba) rozu­miem, pozo­sta­je podzie­lić to na dwa pro­jek­ty (mode­le):
– ana­li­za i mode­lo­wa­nie pro­ce­sów w fir­mie (tu BPM rozu­mia­ny jako zarządzanie),
– wyma­ga­nia na opro­gra­mo­wa­nie worl­flow (tu BPMS jak aplikacja).

Pierwsze to mode­le ana­li­tycz­ne, wie­lo­po­zio­mo­we itp.. pro­ce­sów biz­ne­so­wych. Drugie to dia­gra­my przy­pad­ków uży­cia (UC) dla BPMS i pro­ce­so­wo (mode­le wyko­ny­wal­ne) opi­sa­na imple­men­ta­cja tych UC z uży­ciem BPMS.

Nie da się tego seman­tycz­nie mode­lo­wać na jed­nym spój­nym mode­lu procesów.

[czy­tel­nik]:
Jeżeli chcę mode­lo­wać szer­szy kon­tekst orga­ni­za­cji (wie­le powią­za­nych pro­ce­sów, top-down), to muszę użyć CASE i nic inne­go. Czyli do wdro­że­nia BPM (jako sty­lu zarzą­dza­nia fir­mą) muszę wyko­rzy­stać CASE (bo chcę i muszę mieć sze­ro­ki obraz). Błędem jest myśle­nie i pisa­nie o wyko­rzy­sta­niu w tym celu BPMS – widzia­łem dzie­siąt­ki arty­ku­łów o tym, że praw­dzi­wy BPM bez BPMS nie ist­nie­je, że są nie­roz­łącz­ne. BPMS jako two­rze­nie kon­kret­nej apli­ka­cji opar­tej na wybra­nej per­spek­ty­wie pro­ce­so­wej jest po pro­stu wyni­kiem ana­li­zy wyko­na­nej przy uży­ciu CASE. Nie ma rela­cji ani bez­po­śred­nie­go prze­ło­że­nia CASE na BPMS. Można oczy­wi­ście pró­bo­wać impor­to­wać, expor­to­wać, ale to zawsze wią­że się z ryzy­kiem pogu­bie­nia infor­ma­cji bądź przy­rzą­dze­nia pięk­ne­go spa­ghet­ti. Sprowadza się to do tego, że aktu­ali­za­cja i utrzy­ma­nie pro­ce­sów w dwóch narzę­dziach jest bar­dzo pra­co­chłon­ne i nikt zapew­ne tego nie robi:). Wizerunek CASE-owych narzę­dzi tra­ci tro­chę uro­ku w tym kontekście 😉

Jarosław Żeliński:
Nie tyl­ko moim zda­niem błę­dem jest utoż­sa­mia­nie BPM z BPMS, pierw­sze to stra­te­gia wewnętrz­na fir­my dru­gie to apli­ka­cja. Zresztą, każ­da apli­ka­cja reali­zu­je jakieś swo­je wewnętrz­ne sce­na­riu­sze, dru­go­rzęd­ne zna­cze­nie ma to czy to motor BPMN czy nie… (wie­le sys­te­mów BPMS korzy­sta z wła­snych, innych innych niż BPMN, notacji).

Co do uwa­gi o przy­dat­no­ści narzę­dzi CASE, nie zgo­dzę się. Jest bez­po­śred­nia rela­cja BPM a BPMS: aktyw­no­ści w mode­lach pro­ce­sów orga­ni­za­cji (BPM) to przy­pad­ki uży­cia apli­ka­cji BPMS, te są niczym innym jak zada­nia­mi użyt­kow­ni­ka” w BPMN. VP radzi sobie z tym bar­dzo dobre, jed­nak wyma­ga to popraw­ne­go mode­lu sys­te­mo­we­go a kon­kret­nie oddziel­ne­go mode­lo­wa­nia orga­ni­za­cji i oddziel­ne­go apli­ka­cji i jej wewnętrz­ne­go mecha­ni­zmu dzia­ła­nia. To razem moż­na śla­do­wać” ale trze­ba zbu­do­wać sobie dobry szkie­let dla całości.

Tyle dys­ku­sja. W czym pro­blem? Najpierw po raz kolej­ny model war­stwo­wy SOA:

SOA_OMG_model

Na naj­wyż­szym pozio­mie mamy mode­le pro­ce­sów biz­ne­so­wych (Business Proces, obec­nie mode­lo­wa­ne z regu­ły z uży­ciem dia­gra­mu pro­ce­sów nota­cji BPMN i reguł biz­ne­so­wych), niżej abs­trak­cje usług (Business Services, mode­lo­wa­ne z uży­ciem przy­pad­ków uży­cia UML), dalej kom­po­nen­ty apli­ka­cyj­ne (Components, obec­nie mode­lo­wa­ne z uży­ciem dia­gra­mu kom­po­nen­tów UML). Zasoby ope­ra­cyj­ne (Operational Resources, na samym dole), obec­nie mode­lu­je się je z uży­ciem dia­gra­mów wdro­że­nia UML.

Tak więc to co nazy­wa­my BPM, to zarzą­dza­nie orga­ni­za­cją. Tu mode­lu­je­my pro­ce­sy biz­ne­so­we w rozu­mie­niu mode­lu­je­my mecha­nizm dzia­ła­nia orga­ni­za­cji”. Część aktyw­no­ści w tych pro­ce­sach będzie (jest) wspie­ra­na apli­ka­cją (jej usłu­ga­mi). Od tego momen­tu może­my, roz­po­czy­na­jąc od przy­pad­ków uży­cia, zacząć mode­lo­wać apli­ka­cję (wyma­ga­nia na nią) idąc przez mode­le dzie­dzi­ny, sce­na­riu­sze aż do podzia­łu na kom­po­nen­ty. Możemy tak­że wybrać inną dro­gę: opro­gra­mo­wa­nie BPMS i zacząć mode­lo­wać logi­kę wyma­ga­nej apli­ka­cji z uży­ciem nota­cji BPMN i tak zwa­nych dia­gra­mów wyko­ny­wal­nych. Na tych dia­gra­mach poja­wią się nisko­po­zio­mo­we” zada­nia (skrypt, wysła­ne komu­ni­ka­tu, itp.) oraz zada­nia użyt­kow­ni­ka” (user task w BPMN), kto­re są inte­rak­cją tej apli­ka­cji z jej użytkownikiem.

Drugie podej­ście ma pew­ną wadę: abso­lut­nie nie usu­wa potrze­by napi­sa­nia kodu logi­ki biz­ne­so­wej (np. nali­cze­nie upu­stu, sco­ring kre­dy­to­bior­cy itp.) dla zadań BPMN typu busi­ness rule”. Dlatego nie wró­żę suk­ce­su ryn­ko­we­go tego typu apli­ka­cjom (BPMS). Stawiam raczej na dal­szy roz­wój typo­wych apli­ka­cji biz­ne­so­wych oraz sys­te­mów typu task mana­ge­ment” z wbu­do­wa­ny­mi moto­ra­mi reguł biz­ne­so­wych”. Niestety sys­te­my BPMS nie zwal­nia­ją z koniecz­no­ści napi­sa­nia kodu logi­ki biz­ne­so­wej i prze­cho­wy­wa­nia danych, za to dodat­ko­wo kom­pli­ku­ją cały pro­ces dostar­cze­nia opro­gra­mo­wa­nia potrze­bą pośred­nie­go two­rze­nia wyko­ny­wal­nych mode­li BPMN.

Owszem moż­na podej­mo­wać pró­by by pierw­sze trzy war­stwy SOA ująć w jed­nym mode­lu”, jed­nak poja­wi się pro­blem zarzą­dza­nia kon­tek­sta­mi (biz­ne­so­wy i maszy­no­wy) w ramach jed­ne­go mode­lu. Opis tego podej­ścia moż­na zna­leźć na blo­gu Bruce Silver’a:

One of the sin­gu­lar suc­ces­ses of BPM tech­no­lo­gy is a com­mon lan­gu­age ? BPMN ? used both for pro­cess mode­ling and exe­cu­ta­ble design. At least in the­ory?. (Źródło: Process-Driven Applications: A New Approach to Executable BPMN – Business Process Watch)

Co do tego czy apli­ka­cje CASE radzą sobie z tym… apli­ka­cje te bez pro­ble­mu, ale każ­dy pro­jekt wyma­ga nie­ste­ty indy­wi­du­al­ne­go podejścia.

ECM i EOD czyli od mody do realiów

Obydwa te, spo­ty­ka­ne czę­sto w pra­sie, skró­ty mają wie­le wspól­ne­go: ozna­cza­ją apli­ka­cje zarzą­dza­ją­ce obie­giem infor­ma­cji i jej maga­zy­no­wa­niem (ECM – Electronic Content Management czy­li zarzą­dza­nie tre­ścią w posta­ci elek­tro­nicz­nej oraz EOD – Elektroniczny Obieg Dokumentów). Cechą zawar­tą nie wprost” w tych nazwach jest zarzą­dza­nie tak­że skła­do­wa­niem i prze­pły­wem tej infor­ma­cji. Osiem lat temu pisa­łem o kwe­stiach poję­cio­wych (czym jest wie­dza, jej prze­twa­rza­nie, czym są dane):

Problematyka infor­ma­cji w fir­mach, jej kolek­cjo­no­wa­nia i prze­twa­rza­nia jest czę­stym tema­tem arty­ku­łów w pra­sie spe­cja­li­stycz­nej jak i opi­sem zakre­sów pro­jek­tów IT. Termin ten jest jed­nak nie raz nad­uży­wa­ny. W pra­sie moż­na pozwo­lić sobie na pew­ną dowol­ność jego inter­pre­ta­cji jed­nak w opi­sie zakre­su pro­jek­tu ana­li­tycz­ne­go pozy­cja o nazwie ?Zdefiniowanie potrzeb infor­ma­cyj­nych fir­my? może rodzić poważ­ne kło­po­ty z odbio­rem tej czę­ści pro­jek­tu gdyż tu na dowol­ność inter­pre­ta­cji nie powin­no być miej­sca. (Źródło: Zarządzanie Wiedzą | Jarosław Żeliński IT-Consulting)

Niedawno, 26 stycz­nia 2016, mia­łem refe­rat na kon­fe­ren­cji pod hasłem Business Process Management:

W trak­cie refe­ra­tu zwró­ci­łem uwa­gę na to, że to co czę­sto nazy­wa­my zarzą­dza­niem pro­ce­sa­mi (popu­lar­ny skrót [[BPM]]) biz­ne­so­wy­mi, tak na praw­dę jest zarzą­dza­niem prze­pły­wem pra­cy, zarzą­dza­niem infor­ma­cją i nad­zo­ro­wa­niem tych aktyw­no­ści. Tu zwró­cę uwa­gę na to, że prze­pływ pra­cy odwzo­ro­wy­wa­ny jest w apli­ka­cji jako ciąg rapor­tów i notatek:

prze­ło­żo­ny dowia­du­je się o wyko­pa­niu rowu nie z wła­snej obser­wa­cji a z rapor­tu swo­je­go podwładnego 

dla­te­go opro­gra­mo­wa­nie może ope­ro­wać wyłącz­nie udo­ku­men­to­wa­ny­mi fak­ta­mi a nie zja­wi­ska­mi w real­nym świe­cie: to są zapi­sy jaki­mi zarzą­dza opro­gra­mo­wa­nie zarzą­dza­ją­ce sze­ro­ko poję­tą tre­ścią. Tak więc

zarzą­dza­nie pro­ce­sa­mi biz­ne­so­wy­mi to nic inne­go jak zbie­ra­nie infor­ma­cji, prze­twa­rza­nie ich i decy­do­wa­nie o kolej­nych pra­cach do wyko­na­nia, infor­mu­jąc o tym wyko­naw­ców tych kolej­nych prac.

Aplikacja wspie­ra­ją­ca prze­pływ pra­cy to opro­gra­mo­wa­nie, któ­re pozwa­la na two­rze­nie for­mu­la­rzy (i zasad wery­fi­ka­cji ich popraw­no­ści) spe­cy­ficz­nych dla każ­de­go zada­nia, reguł biz­ne­so­wych narzu­ca­ją­cych opcjo­nal­ność i kolej­ność reali­za­cji zadań (aktyw­no­ści), kate­go­ry­zo­wa­nie tre­ści i zadań, udo­stęp­nia­nie powsta­łych treści:

ECM EOD Przypadki Użycia

Powyższy dia­gram przy­pad­ków uży­cia moż­na w zasa­dzie uznać za refe­ren­cyj­ny”, każ­da apli­ka­cja tego typu tak mogła by wyglą­dać, czy to wystar­czy dostaw­cy opro­gra­mo­wa­nia? Nie, bo cała wie­dza o kon­kret­nym wdro­że­niu tkwi w szcze­gó­łach. Gdzie one są? Pisałem o tym pra­wie rok temu:

Tu war­to na począ­tek wró­cić do kla­sy­fi­ka­cji wyma­gań. W arty­ku­le Inżynieria wyma­gań opi­sa­łem trzy ich rodza­je: (1) funk­cjo­nal­ne czy­li usłu­gi apli­ka­cji (przy­pad­ki uży­cia tej apli­ka­cji), (2) poza-funk­cjo­nal­ne czy­li cechy jako­ścio­we, (3) dzie­dzi­no­we czy­li logi­ka biz­ne­so­wa. I teraz bar­dzo waż­na rzecz: któ­re ele­men­ty archi­tek­tu­ry opro­gra­mo­wa­nia, za reali­za­cję któ­rych wyma­gań odpo­wia­da­ją? (Źródło: Gdzie są te cho­ler­ne szcze­gó­ły | | Jarosław Żeliński IT-Consulting)

Jak widać, klucz tkwi w mode­lu dzie­dzi­ny sys­te­mu czy­li w spe­cy­fi­ce bran­ży, kon­kret­nej fir­my lub orga­ni­za­cji. Powyższe przy­pad­ki uży­cia, jak wyżej, to opis dowol­ne­go ECM/EOD”. Referencyjna archi­tek­tu­ra takie­go sys­te­mu mogła by mieć taką postać:

EOD BPM Architektura referencyjna

Dlaczego tak? Komponent zarzą­dza­ją­cy pro­ce­sa­mi odpo­wia­da za logi­kę kolej­no­ści prze­twa­rza­nia tre­ści. Repozytorium odpo­wia­da za zacho­wy­wa­nie i udo­stęp­nia­nie tre­ści. Dodano tu kom­po­nent Filesystem, gdyż oso­bi­ście jestem zwo­len­ni­kiem podej­ścia, w któ­rym doku­men­ty elek­tro­nicz­ne są skła­do­wa­ne nie w bazie danych (tak zwa­ne BLOB) a na dys­kach, a logi­ka zarzą­dza­nia nimi to odręb­ne opro­gra­mo­wa­nie (patrz euro­pejk­sie zale­ce­nia Moreq). Dzięki temu utra­ta lub zmian apli­ka­cji (i bazy danych) nie powo­du­je utra­ty zasobów.

Na czym więc pole­ga ana­li­za biz­ne­so­wa przed wdro­że­niem EOD/ECM? Czym są tu wyma­ga­nia? Są nimi regu­ły biz­ne­so­we, wzo­ry doku­men­tów i słow­ni­ki pojęć (danych). To tu tkwi naj­więk­sze ryzy­ko wdro­że­nia, klu­czem jest tu zawsze tak zwa­ny model poję­cio­wy. Powyższa archi­tek­tu­ra jest prze­ze mnie trak­to­wa­na jako refe­ren­cyj­na, gdyż gwa­ran­tu­je moż­li­wość odwzo­ro­wa­nia dowol­ne­go sys­te­mu zarzą­dza­nia infor­ma­cją”, taką lub podob­ną zale­ca­ną archi­tek­tu­rę moż­na spo­tkać w wie­lu opra­co­wa­niach na temat ECM.

Manifest Procesu Biznesowego c.d.

?Wszystko powin­no być tak pro­ste jak jest to moż­li­we, ale nie prostsze.? 
(Albert Einstein)

Stosunkowo nie­daw­no (pia­łem o tym już) Roger Burlton (Chairman, Board of Advisors, BPTrends) opu­bli­ko­wał na stro­nie Business Process Trends Manifest Procesu Biznesowego. Podejrzewam, że to efekt lek­kiej” kon­ku­ren­cji z [[Business Rules Group]] i Ronaldem G. Rossem 😉 ale dobrze bo taka kon­ku­ren­cja jest twór­cza a ich (głów­nie Ronald G. Ross BRGroup oraz Paul Harmon z BPTrends) obec­ne ich pole­mi­ki na stro­nach LinkedIn są bar­dzo poucza­ją­ce i myślę, że obie stro­ny na tym zysku­ją, że nie wspo­mną o pozo­sta­łych uczest­ni­kach tych dys­ku­sji. Osobiście doce­niam doro­bek zarów­no Ronalda Rossa jak i Rogera Burltona czy Paula Harmona (ten dru­gi czę­ściej się udzie­la na LinkedIn). Burlton tak wyja­śnia potrze­bę jego – tego mani­fe­stu – powstania:

  • Istnieje wie­le nie­ja­sno­ści doty­czą­cych kon­cep­cji Procesu Biznesowego i jego terminologii.

  • Brakuje aktu­al­nych stan­dar­dów doty­czą­cych fun­da­men­tal­nych pojęć odno­śnie Procesu Biznesowego.

  • Zastosowania kon­cep­cji zwią­za­nych z Procesem Biznesowym sta­ły się zbyt zło­żo­ne, co unie­moż­li­wia ich łatwe zro­zu­mie­nie i sto­so­wa­nie w praktyce.

  • Błędy popeł­nia­ne we wdro­że­niach stra­te­gii Procesu Biznesowego, archi­tek­tu­ry pro­ce­sów, jak rów­nież w ana­li­zie i pro­jek­to­wa­niu Procesu Biznesowego, są rezul­ta­tem nie­zro­zu­mie­nia­po­jęć i prak­tyk doty­czą­cych Procesu Biznesowego.

  • Istnieje potrze­ba pro­fe­sjo­nal­ne­go, uży­wa­ne­go w spo­sób zdy­scy­pli­no­wa­ny, zin­te­gro­wa­ne­go i powta­rzal­ne­go zesta­wu prak­tycz­nych spo­so­bów postę­po­wa­nia doty­czą­cych Procesu Biznesowego.

  • Istnieje potrze­ba, aby Procesy Biznesowe były zarzą­dza­ne jako akty­wa orga­ni­za­cji, któ­re mogą być powszech­nie rozu­mia­ne, współ­dzie­lo­ne i wie­lo­krot­nie wykorzystywane.

  • Bez solid­nej, opar­tej na fun­da­men­tal­nych zasa­dach pod­sta­wy seman­tycz­nej nie może ist­nieć uży­tecz­ny zasób wie­dzy o Procesie Biznesowym.

(źr. BPYtends​.com, ? Prawa autor­skie BPTrends, LLC. – Opracował Roger Burlton. Niniejszym udzie­la się zgo­dy na nie­ogra­ni­czo­ne powie­la­nie i roz­po­wszech­nia­nie tego doku­men­tu pod nastę­pu­ją­cy­mi warun­ka­mi: (a) Umieszczenia w widocz­nym miej­scu praw autor­skich i niniej­szej noty praw­nej. (b) Zaznaczenia, że zawar­tość doku­men­tu jest wła­sno­ścią inte­lek­tu­al­ną BPTrends, LLC. © Żadna z czę­ści niniej­sze­go doku­men­tu, łącz­nie z tytu­łem, tre­ścią, pra­wa­mi autor­ski­mi i niniej­szą notą praw­ną nie może zostać zmie­nio­na, skró­co­na bądź posze­rzo­na w jaki­kol­wiek spo­sób. Komercyjne wyko­rzy­sta­nie tego doku­men­tu, w cało­ści lub czę­ścio­wo, jest ści­śle zabronione.)

Polecam cały doku­ment, do pobra­nia tu: BPManifesto_PL_A4.

Od sie­bie dodam, że moje pra­ce zwią­za­ne z mode­lo­wa­niem orga­ni­za­cji pro­wa­dzą do wnio­sku, że nie moż­li­we jest opi­sa­nie orga­ni­za­cji w jed­nym tyl­ko para­dyg­ma­cie, np. pro­ce­so­wym. W 2012 roku pisałem:

Cieszy mnie ten Manifest tak­że dla­te­go, że moje dąże­nie do pro­sto­ty i for­ma­li­za­cji w posta­ci prag­ma­ty­ki jaką sto­su­ję w swo­jej meto­dy­ce, są zgod­ne z tym Manifestem. (Źródło: Business Process Manifesto | Jarosław Żeliński IT-Consulting).

Skłaniam się ku tezie, że orga­ni­za­cja, jak każ­dy sys­tem otwar­ty, to kil­ka róż­nych aspek­tów jej dzia­ła­nia: struk­tu­ra, dyna­mi­ka, mecha­nizm dzia­ła­nia czy­li regu­ły. Obecne spo­ry pomię­dzy R.Rossem i śro­do­wi­skiem [[Busieness Ruless Group]] a P.Harmonem i Business Process Associates przy­po­mi­na­ją mi daw­ne spo­ry pomię­dzy trze­ma twór­ca­mi obec­ne nota­cji UML (pier­wot­nie każ­dy opra­co­wał swo­ją gru­pę modeli/diagramów dia­gra­mów z okre­ślo­nej per­spek­ty­wy, oryg. ang. [[The Three Amigos, a nick­na­me given to James Rumbaugh, Grady Booch and Ivar Jacobson, deve­lo­pers of Unified Modeling Language (UML)]]).

Wydaje mi się, że obec­ny stan nota­cji UML pozwa­la mode­lo­wać wszel­kie obiek­to­wo zorien­to­wa­ne aspek­ty orga­ni­za­cji sta­no­wią­ce nie­ja­ko mecha­nizm jej dzia­ła­nia, to model obiek­to­wy sys­te­my (w sumie nie ma zna­cze­nia czy będzie on odwzo­ro­wy­wa­ny w apli­ka­cji pod posta­cią Model Dziedziny czy nie). BPMN to nota­cja stric­te biz­ne­so­wa, słu­ży do mode­lo­wa­nia abs­trak­cji jaką jest łań­cuch war­to­ści doda­nej wewnątrz niej. Te mode­le są bar­dzo istot­ne dla zro­zu­mie­nia co i po co się dzie­je”. Nad tym wszyst­kim jest moty­wa­cja czy­li sfor­ma­li­zo­wa­ne pryn­cy­pia: model moty­wa­cji biz­ne­so­wej, są to te ele­men­ty któ­re na naj­wyż­szym pozio­mie opi­su­ją orga­ni­za­cję jako pod­miot na ryn­ku (nie zapo­mi­naj­my, że urzę­dy tak­że uczest­ni­czą w ryn­ku bo mają na nie­go wpływ lub wręcz kształ­tu­ją jako regulator).

Przepływ pracy i dokumentów – czego wymagać

Mój nie­daw­ny refe­rat na temat tren­dów w wybo­rze i wdra­ża­niu sys­te­mów work­flow i zapro­sze­nie na kolej­ną kon­fe­ren­cję z tego zakre­su, skło­ni­ły mnie do prze­rzu­ce­nia cię­ża­ru refe­ra­tu z isto­ty prze­pły­wu doku­men­tów, na prze­pływ doku­men­tów w kon­tek­ście wdro­że­nia narzę­dzia. któ­re w tym poma­ga. Poniżej pre­zen­ta­cja ilu­stru­ją­ca referat:

Na koniec tego krót­kie­go wpi­su dodam, że w swej głów­nej czę­ści, sys­tem obie­gu doku­men­tów to jeden przy­pa­dek uży­cia.

(refe­rat był wygło­szo­ny na kon­fe­ren­cji EOIF GigaCon, 9 Października 2014 we Wrocławiu).

Poziomy modelowania c.d. czyli How work gets done

How Work Gets Done

W kon­tek­ście pozio­mów mode­lo­wa­nia pole­cam książ­kę How Works Get Done , któ­rą wła­śnie koń­czę czy­tać. Bardzo dobre kom­pen­dium wie­dzy o mode­lo­wa­niu pro­ce­sów w kon­tek­ście tytu­ło­we­go jak ta pra­ca jest wykonywana”.

Nie będę tu pisał stresz­cze­nia ;). Książkę gorą­co pole­cam, jest napi­sa­na prag­ma­tycz­nie przez prak­ty­ka, któ­ry jed­nak zazna­cza, że sku­tecz­ne mode­lo­wa­nie, ana­li­za, uspraw­nia­nie pro­ce­sów i firm wyma­ga peł­ne­go zro­zu­mie­nia dzia­ła­nia tych firm, zro­zu­mie­nia wza­jem­ne­go wpły­wu ludzi, zaso­bów, mecha­ni­zmów, celów na pro­duk­ty pro­ce­sów, pod­kre­śla tak­że zna­cze­nie i wska­zu­je korzy­ści z for­mal­ne­go podej­ścia to ana­li­zy i mode­lo­wa­nia (z naci­skiem na sło­wo mode­lo­wa­nie a nie mapowanie).

Autor wska­zał w niej tak­że dru­gą, po mode­lo­wa­niu pro­ce­sów, waż­ną rzecz w pro­jek­tach tego typu: model danych. Nie cho­dzi to jed­nak o mode­le baz danych (choć wspo­mi­na o nich) a o model struk­tu­ry infor­ma­cji. Każdy obiekt danych (doku­ment itp.) na mode­lach BPMN to abs­trak­cja doku­men­tu” (zesta­wu danych). Prędzej czy póź­niej poja­wia się potrze­ba udo­ku­men­to­wa­nia: struk­tu­ry infor­ma­cji i tego czym ona jest.

To na czym chce się tu sku­pić to fakt, że autor opi­sał co rozu­mie pod poję­ciem pozio­mów mode­lo­wa­nia”, powo­łu­jąc się na takie nazwi­ska jak: Roger T. Burlton, G. A. Rummler i A. P. Brache , któ­rych spo­koj­nie moż­na już trak­to­wać jako auto­ry­te­ty, twór­ców pew­ne­go usta­lo­ne­go podej­ścia, nie raz zresz­tą nazy­wa­ne­go ich nazwiskami.

Diagram zaczerp­nię­ty z książki:

źr. How work gets done, Artie Mahal, Amazon.
źr. How work gets done, Artie Mahal, Amazon.

Poziomy te są bar­dzo wyczer­pu­ją­co opi­sa­ne, tu chce tyl­ko wska­zać na pew­ne pryn­cy­pia”, na któ­re wska­zy­wa­łem w moim nie­daw­nym arty­ku­le o pozio­mach mode­lo­wa­nia pro­ce­sów: Poziomy te to nie war­stwy zagnież­dża­nia” proces/podproces, pozio­my te to usta­lo­na ich szcze­gó­ło­wość. Idąc w gorę model sta­je się coraz bar­dziej abs­trak­cyj­ny, idąc w dół model zawie­ra coraz wię­cej szczegółów.

Najwyższy poziom to łań­cuch war­to­ści”, jest to odpo­wied­nik pro­ce­su end-2-end. łań­cuch war­to­ści poka­zu­je role mode­lo­wa­nej orga­ni­za­cji w ryn­ko­wym łań­cu­chu war­to­ści: co do niej wcho­dzi i co z niej wycho­dzi”. Poniżej są pro­ce­sy (i pod­pro­ce­sy) opi­su­ją­ce wewnętrz­ny łań­cuch war­to­ści fir­my. Najniżej mamy poziom zarzą­dza­nia: kon­kret­ne pra­ce i zada­nia do wyko­na­nia wraz ze szcze­gó­ło­wy­mi opi­sa­mi. regu­ły biz­ne­so­we są tu trak­to­wa­ne jako ele­ment ste­ru­ją­cy wyko­na­niem pracy.

Porównajmy to z tym, zna­nym nam już, modelem:

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

Poziom 0 (zero) to poziom stra­te­gi. Poziomy 1 i 2 to pro­ce­sy biz­ne­so­we, łań­cuch wejść i wyjść kolej­nych pro­ce­sów, abs­trak­cja opi­su­ją­ca jak fir­ma reali­zu­je swo­ją misję: dostar­cza pro­duk­ty na rynek. Poziomy 3, 4, 5, to naj­niż­szy poziom opi­su­ją­cy deta­licz­nie czyn­no­ści, zada­nia i pro­ce­du­ry oraz zaso­by. Liczba tych pozio­mów zale­ży już od tego jakie pro­por­cje przy­ję­to pomię­dzy pro­ce­du­ra­mi i regu­ła­mi biz­ne­so­wy­mi a kom­pe­ten­cja­mi i auto­ma­ty­za­cją. Poziomy te to sto­pień uszcze­gó­ło­wie­nia opi­su (mode­lu) pro­ce­su ale nie hie­rar­chia procesów.

Liczba pozio­mów mode­lo­wa­nia zale­ży od ska­li dzia­ła­nia fir­my, jak widać są zawsze trzy klu­czo­we pozio­my, w ramach każ­de­go z nich moż­na wydzie­lić ich szcze­gó­ło­we war­stwy (z moż­li­wo­ścią doda­wa­nia kolej­nych szcze­gó­łów 5+).

Na każ­dym pozio­mie uży­wa­my innych narzę­dzi, w szcze­gól­no­ści pozio­my 3 i niż­sze to raczej doku­men­ty: opi­sy pro­ce­dur i szcze­gó­ło­we instruk­cje a nie mode­le i dia­gra­my. Zaleca się na pozio­mie pro­ce­sów biz­ne­so­wych (poziom 1 i 2) sto­so­wa­nie nota­cji BPMN. Najwyższy poziom nie wyma­ga aż takich for­ma­li­zmów ale nic nie stoi na prze­szko­dzie by ich użyć.

Tyle moich komen­ta­rzy. Książkę pole­cam do prze­czy­ta­nia. Jak widać, pew­ne ele­men­ty ana­li­zy i mode­lo­wa­nia są swe­go rodza­ju kano­nem, wymy­śla­nie wła­snych może mieć sens ale wte­dy wyma­ga to umie­jęt­no­ści udzie­le­nia odpo­wie­dzi na pyta­nie dla­cze­go”. Od sie­bie mogę powie­dzieć, że podej­ście bar­dzo podob­ne do opi­sa­ne­go powy­żej sto­su­je od wie­lu lat, jako efekt wła­snych doświad­czeń i ana­liz, któ­re ku mojej rado­ści jak widać nie są odosob­nio­ne. Ich zbież­ność z cudzy­mi doko­na­nia­mi utwier­dza mnie tyl­ko w prze­ko­na­niu, że to wła­ści­wa droga.

A książ­kę pole­cam każ­de­mu kto ma do czy­nie­nia z pro­ce­so­wym podej­ściem do zarzą­dza­nia, jest napi­sa­na bar­dzo przy­stęp­nie, choć po angielsku.

Źródła

Mahal, A. (2010). How work gets done: busi­ness pro­cess mana­ge­ment, basics and bey­ond (First edi­tion). Technics Publications.
Rummler, G. A., & Brache, A. P. (2000). Podnoszenie efek­tyw­no­ści orga­ni­za­cji (Ł. Ludwicki, Trans.). Polskie Wydawnictwo Ekonomiczne.