Notacja EPC

Poziomy modelowania procesów

Kwestia licz­by pozio­mów mode­lo­wa­nia pro­ce­sów” poja­wia się na każ­dym moim szko­le­niu w posta­ci pytań uczest­ni­ków. Często tak­że spo­ty­kam się z tym zagad­nie­niem” w pro­jek­tach i w lite­ra­tu­rze. Można np. spo­tkać mode­le z pro­ce­sa­mi ponu­me­ro­wa­ny­mi pozio­ma­mi mode­lo­wa­nia: pro­ce­sy głów­ne 0.1; 0.2 itp., pro­ce­sy pierw­sze­go pozio­mu: 1.1; 1.2; 1.3, dalej 2.2.4 itd. W czym problem?

Po pierw­sze: pro­ces np. archi­wi­za­cji doku­men­tu może się poja­wić na każ­dym z tych pozio­mów, jaki numer mu nadać? Po dru­gie pew­ne obsza­ry dzia­ła­nia są mało zło­żo­ne i moż­li­we, że wystar­czy jeden poziom”, inne zło­żo­ne i potrzeb­ne będą może czte­ry poziomy?

Elementarny pro­ces, podob­nie jak klo­cek LEGO, może się poja­wić wszę­dzie, nie­za­leż­nie od pozio­mu, np. reali­za­cja zobo­wią­za­nia finan­so­we­go, czy­li zapła­ta za coś, może się poja­wić jako zapła­ta za fak­tu­rę wysta­wio­ną przez kan­ce­la­rię praw­ną w pro­ce­sie nego­cjo­wa­nia umo­wy han­dlo­wej (czy­li bar­dzo wyso­ko”) jak i w pro­ce­sie regu­lo­wa­nia zobo­wią­zań za dziur­ka­cze (raczej nisko w takiej hierarchii).

Najpierw dwie klu­czo­we defi­ni­cje za nor­mą ter­mi­no­lo­gicz­ną ISO 9000 (jakość zarządzania):

Proces to: każ­de dzia­ła­nie, któ­re prze­kształ­ca wej­ście (dane wej­ścio­we) na wyj­ście (dane wyj­ścio­we). Proces może w swo­im wnę­trzu” zawie­rać zbiór róż­nych ope­ra­cji (dzia­łań) wza­jem­nie ze sobą powią­za­nych i na sie­bie oddziałujących.

Procedura to: okre­ślo­ny spo­sób reali­za­cji dzia­łań lub procesów.

Powyższa defi­ni­cja jest łatwa do przy­ję­cia i czę­sto sto­so­wa­na, jed­nak jest zbyt ubo­ga (poję­cie pro­ces jest tu dość pojem­ne) by sta­no­wi­ła pod­sta­wę do for­mal­ne­go mode­lo­wa­nia orga­ni­za­cji, dla­te­go dodat­ko­wo przy­to­czę tę, nie­co pełniejszą:

(cytat, str. 41) Proces biz­ne­so­wy jest chro­no­lo­gicz­nym i logicz­nym cią­giem funk­cji (zadań) wyko­ny­wa­nych w toku pra­cy nad okre­ślo­nym obiek­tem w ramach racjo­nal­ne­go dzia­ła­nia.

(cytat, str. 431) Proces biz­ne­so­wy sta­no­wi zbiór powią­za­nych ze sobą czyn­no­ści ukie­run­ko­wa­nych na reali­za­cję okre­ślo­ne­go celu biz­ne­so­we­go w opar­ciu o wyko­rzy­sty­wa­ne zaso­by. Proces biz­ne­so­wy jest ste­ro­wa­ny poprzez stra­te­gię orga­ni­za­cji defi­niu­ją­cą cele oraz pro­duk­ty two­rzo­ne przez pro­ce­sy.

Przeglądając lite­ra­tu­rę przed­mio­tu (w tym powyż­sze) moż­na dojść do nastę­pu­ją­cej defi­ni­cji pro­ce­su biznesowego:

Proces biz­ne­so­wy: czyn­ność, lub logicz­nie powią­za­ny chro­no­lo­gicz­ny łań­cuch czyn­no­ści, prze­kształ­ca­ją­cy stan wej­ścia pro­ce­su w stan jego wyj­ścia, mają­cy war­tość dla odbior­cy. Proces do wyko­na­nia, wyma­ga okre­ślo­nych zaso­bów, spo­sób jego reali­za­cji może być ogra­ni­czo­ny. (opr. własne)

Do mode­lo­wa­nia pro­ce­sów obec­nie uży­wa się naj­czę­ściej nota­cji BPMN (obec­nie tak zwa­ny stan­dard de’fac­to), spe­cy­fi­ka­cja tej nota­cji tak defi­niu­je proces:

A Process descri­bes 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 Flows that defi­ne fini­te exe­cu­tion seman­tics. Processes can be defi­ned at any level from enter­pri­se-wide Processes to Processes per­for­med by a sin­gle per­son. Low-level Processes can be gro­uped toge­ther to achie­ve a com­mon busi­ness goal. 

Warto zwró­cić uwa­gę na fakt, że z per­spek­ty­wy nota­cji, ta jest jedy­nie języ­kiem wyra­zu, pro­ces to sekwen­cja aktyw­no­ści w orga­ni­za­cji, któ­rej celem jest dostar­cze­nie okre­ślo­ne­go efek­tu”. Dalej: pro­ces jest obra­zo­wa­ny z pomo­cą gra­fu zło­żo­ne­go z ele­men­tów o okre­ślo­nej seman­ty­ce (mają­cych sztyw­no okre­ślo­ne zna­cze­nia). Proces może być defi­nio­wa­ny na dowol­nym pozio­mie. Procesy na naj­niż­szym pozio­mie mogą być gru­po­wa­ne np. wspól­nym celem. Tyle nota­cja. Definicja pro­ce­su w BPMN jest zgod­na z ISO.

Tak więc pro­ce­sem jest tu każ­dy prze­pływ pra­cy, zaś pro­ce­sem biz­ne­so­wym są te prze­pły­wy, któ­rych gra­ni­ce (począ­tek i koniec) wyzna­cza­ją pro­duk­ty biz­ne­so­we (okre­ślo­ne obiek­ty, cele biznesowe). 

Co to ozna­cza? Oznacza to, że sko­ro celem biz­ne­so­wym jest np. wysta­wie­nie fak­tu­ry za doko­na­ną sprze­daż, zaś przy­go­to­wa­nie samej tre­ści fak­tu­ry jest jedy­nie jed­nym z eta­pów jej two­rze­nia (krok), pro­ce­sem biz­ne­so­wym jest wysta­wie­nie fak­tu­ry, ale nie jest nim samo jej zre­da­go­wa­nie (krok, kolej­ne zada­nie) bo poza reda­go­wa­niem mamy tak­że czyn­no­ści spraw­dze­nia, księ­go­wa­nia i wydru­ku. Tak więc na naj­niż­szym pozio­mie hie­rar­chii mamy pro­ces Fakturowanie, dal­sze szcze­gó­ły wysta­wie­nia fak­tu­ry to pro­ce­du­ra jej two­rze­nia skła­da­ją­ca się z kolej­nych, usta­lo­nych kro­ków (zadań do wykonania).

Proces biz­ne­so­wy Fakturowanie może być (i z regu­ły jest) czę­ścią nad­rzęd­ne­go pro­ce­su Realizacja zamó­wie­nia. Pierwszym pro­duk­tem tego pro­ce­su jest Zamówienie goto­we do wyko­na­nia, pro­ces ten to np. sekwen­cja Rejestracja Zamówienia i Weryfikacja Zamówienia. Cały pro­ces Realizacji zamó­wie­nia ma więc dwa pod­pro­ce­sy: Rejestracja zamó­wie­nia oraz nastę­pu­ją­cy po nim pro­ces biz­ne­so­wy Fakturowanie. Produktem pierw­sze­go jest Zatwierdzone zamó­wie­nie a pro­duk­tem dru­gie­go Faktura sprzedaży.

Poszczególne wewnętrz­ne kro­ki obu pro­ce­sów, same z sie­bie, nie two­rzą pro­duk­tu (np. zare­je­stro­wa­ne ale nie­spraw­dzo­ne Zamówienie nie ma war­to­ści biz­ne­so­wej, to krok któ­ry nale­ży wyko­nać ale nie jest to samo­dziel­ny pro­ces biznesowy).

Popatrzmy na poniż­szy diagram:

(źr. http://www.bptrendsassociates.com/)

Pokazuje trzy klu­czo­we pozio­my pro­ce­so­we­go opi­su orga­ni­za­cji: na samym dole mamy zaso­by, ich umie­jęt­no­ści wspie­ra­ne pro­ce­du­ra­mi. To war­stwa reali­za­cji, ta któ­ra jest udo­ku­men­to­wa­na w każ­dej nie­mal­że orga­ni­za­cji jako zakre­sy obo­wiąz­ków, pro­ce­du­ry i zarzą­dze­nia. Najwyższa war­stwa to klu­czo­we ele­men­ty stra­te­gii, archi­tek­tu­ra klu­czo­wych pro­ce­sów. Na tym pozio­mie moż­na mówić o tak zwa­nych pro­ce­sach end-2-end czy­li o tym jak orga­ni­za­cja reagu­je na bodź­ce zewnętrz­ne (np. na każ­de zapy­ta­nie ofer­to­we odsy­ła­na jest ofer­ta). Ten poziom tak­że jest pra­wie zawsze udo­ku­men­to­wa­ny jako stra­te­gia i plan mar­ke­tin­go­wy. Warstwa środ­ko­wa, pro­ce­sy biz­ne­so­we, to abs­trak­cja opi­su­ją­ca (mode­lu­ją­ca) logi­kę dzia­ła­nia orga­ni­za­cji – jej wewnętrz­ny łań­cuch war­to­ści.

Popatrzmy teraz na jeden ze spo­so­bów usta­le­nia licz­by pozio­mów mode­lo­wa­nia, bar­dzo czę­sto spotykany:

  1. Level 1 ? End-to-end pro­ces­ses: Span across func­tions, e.g. market-to-cash.
  2. Level 2 ? Main pro­cess are­as: Typically func­tion-spe­ci­fic, e.g. acco­unts receivables.
  3. Level 3 ? Sub-pro­ces­ses: Sequence of rela­ted acti­vi­ties, e.g. goods invoicing.
  4. Level 4 ? Activities: Key steps within sub-pro­cess, e.g. prin­ting invoices.
  5. Level 5 ? Tasks: Specific user actions or sys­tem trans­ac­tions, e.g. send invo­ice to print. A step con­ta­ins a descrip­tion of how to per­form the task.

(źr. Process Improvement at Carlsberg powe­red by ARIS from Software AG).

Poziom ozna­czo­ny Level‑1 jak naj­bar­dziej mamy zawsze”. Różnica pomię­dzy pozio­ma­mi 4 i 5 jest dla mnie nie­zro­zu­mia­ła. Angielskie sło­wa aci­ti­vi­ty i task to odpo­wied­nio czyn­ność i zada­nie. Trudno mi sobie wyobra­zić dru­ko­wa­nie fak­tu­ry bez wysła­nia fak­tu­ry do dru­ku. Czy to dwa pozio­my szcze­gó­ło­wo­ści? To co tu widzę, i nie tyl­ko tu, to mie­sza­nie obsza­ru dzia­ła­nia orga­ni­za­cji (ludzi) z obsza­rem reali­zo­wa­nym przez zaso­by”. To trosz­kę (poda­ne przy­kła­dy) jak by ktoś uznał, że czyn­ność (poziom 4) to zmia­na bie­gu w samo­cho­dzie a zada­nie (poziom 5) to zazę­bie­nie się wła­ści­wych kół zęba­tych w skrzy­ni bie­gów. Ma to sens?

Poziomy 2 i 3 to mode­le pro­ce­sów, licz­ba tych pozio­mów może być róż­na o czym dalej.

Przykład

Poniżej pro­ce­sy end-2-end (celo­wo nie nada­łem im rze­czy­wi­stych nazw by nie suge­ro­wać się kon­kret­ną fir­mą czy branżą):

Procesy end-2-end

Pokazuje jak orga­ni­za­cja reagu­je na zda­rze­nia gene­ro­wa­ne przez jej oto­cze­nie biz­ne­so­we. Kolejny etap (poziom ?) to model (dia­gram) dla każ­de­go tego procesu:

- pro­ces A

Proces A

- pro­ces B

Proces B

Proces A zawie­ra (two­rzy) pośred­ni pro­dukt (Dane 5) oraz pro­dukt Dane4. Zgodnie z defi­ni­cją pro­ce­su, ozna­cza to, że A skła­da się dwóch pod­pro­ce­sów, pierw­szy two­rzy pro­dukt Dane5 a dru­gi Dane4. Proces two­rzą­cy Dane5 jest wyko­ny­wa­ny np. na bazie wie­dzy wyko­naw­cy (rola), któ­ry posia­da wyma­ga­ną umie­jęt­ność, ta jest opi­sa­na w dzia­le HR więc powie­la­nie zapi­sów z kar­ty obo­wiąz­ków jest zbęd­ne, wystar­czy się na nią powo­łać w doku­men­ta­cji pro­ce­su. Czynność two­rzą­ca Dane4 jest na tyle zło­żo­na”, że wie­dza wyko­naw­cy to za mało (albo jest ryzy­ko, że się pomy­li) dla­te­go doku­men­tu­je­my (for­ma­li­zu­je­my) spo­sób two­rze­nia pro­duk­tu Dane4 jako pro­ces C skła­da­ją­cy się z okre­ślo­nych czynności:

Proces C

Proszę zwró­cić uwa­gę, że pro­ces B i C to pro­ce­du­ry (wewnątrz nie powsta­ją pro­duk­ty biz­ne­so­we), to tyl­ko opis kro­ków jakie nale­ży wyko­nać by powstał pro­dukt pro­ce­su. Procedury z powo­dze­niem moż­na, zamiast two­rzyć takie dia­gra­my, opi­sać zna­nym z pro­jek­tów ISO struk­tu­ral­nym tek­stem, dia­gram raczej nie wno­si tu war­to­ści doda­nej. Tworzenie dia­gra­mów dla pro­ce­dur mia­ło by sens, gdy­by zre­zy­gno­wać z pro­ce­dur w for­mie tek­sto­wej, w prze­ciw­nym wypad­ku two­rzy­my redun­dant­ne opi­sy wyma­ga­ją­ce syn­chro­ni­za­cji. W prak­ty­ce robi się tak, doku­men­tu­je pro­ce­du­ry dia­gra­ma­mi, w przy­pad­kach gdy pro­ce­du­ra jest zło­żo­na i jej opis tek­sto­wy może być nie­czy­tel­ny lub trud­ny w zro­zu­mie­niu. Analogicznie ma się sytu­acja w przy­pad­kach gdy spo­sób two­rze­nia pro­duk­tu (pro­ces biz­ne­so­wy) w 100% jest efek­tem wie­dzy posia­da­nej przez wyko­naw­ce (rola): tu powo­łu­je­my się wyłącz­nie na sto­sow­ne zapi­sy w dzia­le HR, nie two­rzy­my ich kopii w posta­ci diagramu.

Zobrazowanie powyż­szych dia­gra­mów, ich powiązań:

Struktura modelu procesów

Tu mamy dia­gram obra­zu­ją­cy pod­le­głość”, czy­li to jak się one wza­jem­nie zagnież­dża­ją i to jak naj­bar­dziej obra­zu­je struk­tu­rę całe­go mode­lu. Jednak pró­ba ponu­me­ro­wa­nia kon­kret­nych pro­ce­sów i zbu­do­wa­nia ich hie­rar­chii zacho­wu­ją­cej drze­wia­stą logi­kę jest nie­re­al­na z powo­du wła­snie tego, że pro­ce­sy są ini­cjo­wa­ne zda­rze­nia­mi, te zaś nie są pozio­mo­we” (np. pro­ces opi­sa­ny na począt­ku archi­wi­za­cji doku­men­tu może się poja­wić na każ­dym poziomie/diagramie). Numerować hie­rar­chicz­nie jed­nak moż­na dia­gra­my, któ­re jak widać, mają struk­tu­rę podob­ną do sys­te­mu folderów.

Ile więc mamy pozio­mów mode­lo­wa­nia orga­ni­za­cji? Trzy (patrz poka­za­ny wcze­śniej dia­gram BPTrends): naj­wyż­szy czy­li stra­te­gia i pro­ce­sy end-2-end, naj­niż­szy czy­li pro­ce­du­ry i instruk­cje sta­no­wi­sko­we (imple­men­ta­cja) oraz środ­ko­wy czy­li abs­trak­cję – model pro­ce­so­wy – opi­su­ją­cą jak to się wszyst­ko do sie­bie ma (środ­ko­wy poziom ma struk­tu­rę zagnież­dża­nia się diagramów/modeli pro­ce­sów jak wyżej ale pro­ce­sy mają jedy­nie swo­je nazwy jako identyfikatory).

Proszę zwró­cić uwa­gę, że:

  1. w zasa­dzie każ­da orga­ni­za­cja ma udo­ku­men­to­wa­ny poziom naj­wyż­szy (stra­te­gia) i naj­niż­szy (pro­ce­du­ry, zarzą­dze­nia, instrukcje)
  2. war­stwa środ­ko­wa jest two­rzo­na wte­dy, gdy chce­my zro­zu­mieć wewnętrz­ne zależ­no­ści, któ­rych może być dużo, i mogą być zło­żo­ne (zawi­łe); to ile pozio­mów” powsta­nie w war­stwie środ­ko­wej, zale­ży wyłącz­nie od stop­nia zło­żo­no­ści danej orga­ni­za­cji i zawsze jest to indy­wi­du­al­na jej cecha, tyl­ko w czę­ści zależ­na od wiel­ko­ści organizacji.

Często moż­na się spo­tkać z nie­for­mal­ny­mi (o nie­zde­fi­nio­wa­nych gra­ni­cach pro­ce­sów) dia­gra­ma­mi w postaci:

Poziom naj­wyż­szy:

Procesy end-2-end v.2

i pozio­my niższe:

Model łańcucha wartości A

Czy taki dia­gram nam coś nam daje? Jest w zasa­dzie gra­ficz­ną for­mą tek­sto­we­go (nie­jed­no­znacz­ne­go) opisu. 

Modelowanie pro­ce­sów biz­ne­so­wych to nie ryso­wa­nie dia­gra­mów, to two­rze­nie mode­li, któ­re pod­da­ją się wali­da­cji i testo­wa­niu zgod­no­ści z rze­czy­wi­sto­ścią. Poprawne mode­le pozwa­la­ją prze­wi­dy­wać reak­cję orga­ni­za­cji na pla­no­wa­ne zmiany. 

Na zakończenie

Modne ostat­nio pro­jek­ty mode­lo­wa­nia pro­ce­sów biz­ne­so­wych z regu­ły, jako pro­dukt, dostar­cza­ją nie­zli­czo­ne ilo­ści map pro­ce­sów”, któ­re koń­czą swój żywot na zaku­rzo­nych z cza­sem pół­kach, powsta­wa­ły zbyt dużym kosz­tem by je wyrzu­cić do kosza. Ich sta­łe utrzy­ma­nie (aktu­ali­za­cja) nie raz bywa kosz­tow­niej­sze od wytworzenia.

Po więc robi­my te mode­le? Przytoczę zno­wu cytat ini­cju­ją­cy pew­ną dys­ku­sję na forum: 

I think the only reason to con­duct any pro­ject is to impro­ve one or more pro­ces­ses. This means that if you don’t know which process(es) you are try­ing to impro­ve, you sho­uld not start the pro­ject. Comments? (Process befo­re pro­ject | LinkedIn).

W wol­nym tłumaczeniu ;):

jeże­li uzna­my, że jedy­nym powo­dem pro­wa­dze­nia pro­jek­tów jest uspraw­nia­nie okre­ślo­nych pro­ce­sów biz­ne­so­wych, to zna­czy, że uru­cha­mia­nie tych pro­jek­tów bez wie­dzy, któ­re to dokład­nie pro­ce­sy i bez peł­ne­go zro­zu­mie­nia ich wpły­wu na orga­ni­za­cję, pro­jek­tów tych nie nale­ży rozpoczynać.

Procesy 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 skutki.

Modelowanie, 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, to jest ste­no­ty­pia. Modelowanie to trud­ny pro­ces odkry­wa­nia praw­dzi­wej logi­ki dzia­ła­nia orga­ni­za­cji (i wypa­da mi teraz zapro­sić na moje szkolenia :)).

Polecam tak­że wcze­śniej­szy arty­kuł o mode­lo­wa­niu orga­ni­za­cji z per­spek­ty­wy sys­te­mów zarzą­dza­nia jako­ścią ISO, bo pro­jek­ty IT to nie jedy­ny przy­pa­dek gdy mode­lo­wa­nie orga­ni­za­cji bar­dzo pomaga.

Źródła

OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
BPTrends Associates. (2020). BPTrends Associates | BPM ana­ly­sis, opi­nion and insi­ght. http://​www​.bptrend​sas​so​cia​tes​.com/
Skersys, T., Tutkute, L., Butleris, R., & Butkiene, R. (2012). Extending BPMN busi­ness pro­cess model with SBVR busi­ness voca­bu­la­ry and rules. Information Technology and Control, 41(4), 356 – 367.

Bałagan w procesach i nadużycia czyli BPM

Należy stwier­dzić jed­ną rzecz: moim zda­niem panu­je strasz­ny bała­gan poję­cio­wy wywo­ła­ny tym, że mamy do czy­nie­nia nie­ste­ty z modą na pro­ce­sy i wie­lu pro­du­cen­tów apli­ka­cji ma ambi­cję użyć magicz­nej sekwen­cji słów busi­ness pro­cess mana­ge­ment” nawet, jeże­li to nie ma sensu.

W czym problem?

Po pierw­sze pro­ces biz­ne­so­wych to sekwen­cja zda­rzeń (czyn­no­ści) w fir­mie a nie w sys­te­mie IT. System co naj­wy­żej może poma­gać je śle­dzić i kon­tro­lo­wać. Po dru­gie: nie nale­ży mylić trzech rze­czy: mode­lo­wa­nia, zarzą­dza­nia i infor­ma­tycz­ne­go wspo­ma­ga­nia pro­ce­sów biznesowych.

Modelowanie lub mapo­wa­nie pro­ce­sów: pole­ga na stwo­rze­niu np. w posta­ci dia­gra­mów (moż­na tak­że je opi­sać tek­stem) doku­men­ta­cji pro­ce­sów w fir­mie t.j. gra­ficz­nej repre­zen­ta­cji w celu utrwa­le­nia ich na papie­rze. Zarządzanie pro­ce­sa­mi: to sta­łe śle­dze­nie mode­lu pro­ce­so­we­go fir­my i ulep­sza­nie go tak by fir­ma postę­pu­ją­ca zgod­nie z tym mode­lem moż­li­wie naj­efek­tyw­niej reali­zo­wa­ła swo­ją stra­te­gię roz­wo­ju. Informatyczne wspo­ma­ga­nie pro­ce­sów biz­ne­so­wych to po pro­stu wyko­rzy­sty­wa­nie narzę­dzi wspie­ra­ją­cych powyż­sze procesy.

Na ryn­ku, nie­za­leż­nie od tego jak same się okre­śla­ją, mamy do czy­nie­nia z roz­wią­za­nia­mi wspo­ma­ga­ją­cy­mi mode­lo­wa­nie pro­ce­sów i zarzą­dza­nie pro­ce­sa­mi, są to takie pakie­ty jak MS Visio, iGrafx, ARIS i wie­le innych. Pakiety takie jak Ultimus czy FileNet to sys­te­my zarzą­dza­nia obie­giem infor­ma­cji (w tym doku­men­tów) w fir­mach, choć same o sobie czę­sto mówią, że zarzą­dza­ją pro­ce­sa­mi biznesowymi.

Pamiętajmy, że pro­ces to czyn­no­ści a nie papier ani jego elek­tro­nicz­na repre­zen­ta­cja. Dokument lub plik, rekord bazy danych to co naj­wy­żej nama­cal­ne” pro­duk­ty procesów.

Zintegrowane sys­te­my infor­ma­tycz­ne coraz czę­ściej mają w nazwie sło­wa zorien­to­wa­ne pro­ce­so­wo” lub zorien­to­wa­ne na pro­ce­sy”. To już bliż­sze praw­dy stwier­dze­nia, gdyż są one wła­śnie tak zbu­do­wa­ne by imple­men­ta­cja sys­te­mu pole­ga­ła nie­mal­że wprost na prze­pi­sa­niu” do nich mode­li pro­ce­so­wych (map procesów).

Tak więc zorien­to­wa­ne na pro­ce­sy są: Ultimus, FileNet, SAP BusinessOne i inne. Wdrożenie tych sys­te­mów pole­ga (w dużym uprosz­cze­niu) na wpi­sa­niu” do nich map pro­ce­sów. Po tej czyn­no­ści sys­tem taki jest dopa­so­wa­ny do sty­lu pra­cy fir­my. Różnica mię­dzy nimi pole­ga np. na tym, ża sys­tem SAP to sys­tem ERPII, FileNet to sys­tem typu docu­ment flow mana­ge­ment” itp. czy­li każ­dy z nich wspie­ra nie­co inny obszar pra­cy w firmie.

A gdzie sys­te­my typu IBM WebSphere czy BizTalk? To są sys­te­my będą­ce w pew­nym sen­sie gene­ra­to­rem apli­ka­cji”. Mając model pro­ce­so­wy fir­my moż­na go ucie­le­śnić” wła­śnie z pomo­cą jed­ne­go z tych (są jesz­cze inne) sys­te­mów. Systemy tego typu są też uży­wa­ne jako narzę­dzie do inte­gra­cji innych sys­te­mów. W takim przy­pad­ku speł­nia­ją rolę sys­te­mów midl­le­wa­re. Dlaczego? Systemy takie to moto­ry apli­ka­cyj­ne. Zdefiniowane pro­ce­sy ubie­ra­ją” w cia­ło w ten spo­sób, że defi­niu­je się pro­ces (regu­łę), dane wej­ścio­we i ich źró­dło, dane wyj­ścio­we i ich cel. Jak widać defi­ni­cja bar­dzo ogól­na ale tak to wła­śnie wygląda.

Modelowanie biznesowe czyli pilnowanie hochsztaplerów

Jeżeli cze­goś nie moż­na nary­so­wać to zna­czy, że to nie ist­nie­je! To dewi­za, któ­ra przy­świe­ca mi w pra­cy jako doradcy.

Model fir­my powi­nien w spo­sób jasny i zro­zu­mia­ły dla pra­cow­ni­ków fir­my opi­sy­wać fir­mę, jej cel ryn­ko­wy oraz wszel­kie jej wewnętrz­ne i zewnętrz­ne zacho­wa­nia oraz reak­cje. Poza tym, jest nie­zbęd­ny do prze­wi­dy­wa­nia zacho­wań fir­my w tym tak­że do przy­go­to­wa­nia jej do wdro­że­nia sys­te­mów infor­ma­cyj­nych. Wiele firm dorad­czych i infor­ma­tycz­nych pod poję­ciem mapy i mode­lu pro­ce­sów biz­ne­so­wych dostar­cza nie­przy­dat­ne, utrwa­lo­ne na dzie­siąt­kach dia­gra­mów opi­sy czyn­no­ści reali­zo­wa­nych przez ankie­to­wa­nych pra­cow­ni­ków, któ­re nie wie­le mają wspól­ne­go z pla­no­wa­ny­mi zmia­na­mi na lepsze.

Większość mode­li firm jakie widzia­łem to obraz­ki nie mają­ce wie­le wspól­ne­go z pro­ce­sa­mi. Zdarza mi się otrzy­my­wać zle­ce­nia, któ­rych głów­nym celem jest oce­na cudzej doku­men­ta­cji przed­wdro­że­nio­wej. Bardzo czę­sto jest to siecz­ka w posta­ci udo­ku­men­to­wa­nych życzeń i wyobra­żeń ankie­to­wa­nych pra­cow­ni­ków fir­my, w któ­rej to wdro­że­nie ma nastą­pić. Jeżeli ktoś potem nazy­wa to mapą pro­ce­sów biz­ne­so­wych to krę­ci sznur na wła­sny kark bo jest to tyl­ko opis tego co się w fir­mie aktu­al­nie dzie­je. Czemu to jest złe? Wyobraźmy sobie, że chce­my zapro­jek­to­wać sku­tecz­ny sys­tem wyna­gro­dzeń a zacna fir­ma, któ­ra ma go wdro­żyć ankie­tu­je w tym celu pra­cow­ni­ków fir­my pyta­jąc jak są wyna­gra­dza­ni i jak chcą być wyna­gra­dza­ni. Życzę powo­dze­nia tak przy­go­to­wy­wa­ne­mu projektowi.

Często fir­my ofe­ru­ją jako usłu­gę Model (mapę) Procesów Biznesowych. Co dają? Dają nie­udol­nie zro­bio­ny opis pro­ce­dur, nie­słusz­nie nazwa­nych pro­ce­sa­mi. Setki sche­ma­tów obra­zu­ją­cych kto, co i jak robi. A po co to robi? Tego tam z regu­ły nie opi­sa­no! Dziesiątki i set­ki stron dia­gra­mów, któ­re lądu­ją na pół­ce i nie są uży­wa­ne pod­czas wdro­że­nia. Powstaje opra­co­wa­nie, któ­re jest nie­zro­zu­mia­łe przez zarząd fir­my zle­ca­ją­cej tę pra­cę. Zarząd nie przy­zna się, że nie rozu­mie bo podob­no to zna­na fir­ma dorad­cza lub wdro­że­nio­wa opra­co­wa­ła. A moim zda­niem, jeże­li Zarząd nie potra­fi zro­zu­mieć udo­ku­men­to­wa­ne­go obra­zu wła­snej fir­my to doku­ment jest do kitu a nie Zarząd.

Procesy

Proces: zbiór dzia­łań wza­jem­nie powią­za­nych lub wza­jem­nie oddzia­łu­ją­cych, któ­re prze­kształ­ca­ją wej­ścia w wyj­ścia (wg. PN-EN ISO 9000:2000, p.3.4.1). Rozszerzając to na pro­ce­sy biz­ne­so­we moż­na powiedzieć:

Proces (defi­ni­cja ICOM): zespół czyn­no­ści lub dzia­łań, któ­rych celem jest osią­gnię­cie ocze­ki­wa­ne­go rezul­ta­tu. Rezultat ten jest osią­ga­ny poprzez prze­two­rze­nie sta­nu wej­ścia pro­ce­su w stan wyj­ścio­wy. Przetworzenie to ste­ro­wa­ne jest za pomo­cą z góry usta­lo­nych reguł. Do osią­gnię­cia tak okre­ślo­ne­go rezul­ta­tu wyma­ga­ne okre­ślo­ne zaso­by. (ICOM: Input,Controll, Output, Mecha­nizm).

Proces biz­ne­so­wy: spój­ny zespół dzia­łań, któ­rych celem jest osią­gnię­cie okre­ślo­nej war­to­ści w posta­ci pro­duk­tu. Do wytwo­rze­nia pro­duk­tu wyma­ga­ne są: zaso­by, inne pro­duk­ty lub pół­pro­duk­ty (surow­ce) oraz regu­ły (zasa­dy) według któ­rych two­rzo­ny jest pro­dukt. Produkt musi dać się opi­sać (zde­fi­nio­wać) i być mierzalny.

Powyżej poka­za­no pod­sta­wo­wą gra­ficz­ną repre­zen­ta­cje pro­ce­su na bazie defi­ni­cji ICOM. Symbol ten wystar­czy do wyko­na­nia kom­plet­nej, popraw­nej mapy pro­ce­sów biz­ne­so­wych. Jedną z pro­stych metod oce­ny wyko­na­nej mapy pro­ce­sów biz­ne­so­wych jest spraw­dze­nie czy dia­gram zawie­ra sym­bo­le decy­zyj­ne (z regu­ły są to rom­by z odno­śni­ka­mi tak/nie). Jeżeli są to nie jest to model pro­ce­sów! Diagramy ze ścież­ka­mi decy­zyj­ny­mi to pro­ce­du­ry a nie pro­ce­sy. Cechą cha­rak­te­ry­stycz­ną pro­ce­su w biz­ne­sie jest jego obli­ga­to­ryj­ność i jed­no­znacz­ność. Czyli jeże­li uzna­je­my, że dany pro­ces w fir­mie jest to zna­czy, że jest a przed­mio­tem dys­ku­sji może być jego wewnętrz­na organizacja.

Przykład. Wykonujemy model Urzędu. Załóżmy, że jed­nym z celów funk­cjo­no­wa­nia tego Urzędu jest wyda­wa­nie decy­zji o malo­wa­niu tra­wy (Process). Na wej­ściu (Inputs) będzie proś­ba peten­ta (wraz z wyma­ga­ny­mi załącz­ni­ka­mi) o wyda­nie decy­zji a na wyj­ściu (Outputs) wyda­na decy­zja. Sposób podej­mo­wa­nia decy­zji okre­śla pro­ce­du­ra (!) i aktu­al­ny stan praw­ny (Control). Zasobem nie­zbęd­nym jest kom­pe­tent­ny pra­cow­nik (Resources). Decyzja jest zawsze, może zaś być pozy­tyw­na lub nega­tyw­na. Nie ma tu mowy o tym czy decy­zja jest w ogó­le wyda­wa­na bo JEST. Tak więc pro­ces jest zawsze, jego wynik może być róż­ny. Na popraw­nej mapie pro­ce­sów dla tego urzę­du będzie więc mię­dzy inny­mi sym­bol tego pro­ce­su ale żad­nych rom­bów”.

Romby są cechą opi­su prze­pły­wu pra­cy (pro­ce­dur). Znamy je mię­dzy inny­mi z doku­men­ta­cji pro­ce­dur ISO. Często spo­ty­ka­ne sche­ma­ty, na któ­rych pozio­me pasy ozna­cza­ją zaso­by a sym­bo­le podej­mo­wa­ne dzia­ła­nia wraz z warian­ta­mi. To nie są pro­ce­sy a pro­ce­du­ry! (work­flow). A to wła­śnie czę­sto oglą­dam na dzie­siąt­kach stron kosz­tow­nych opra­co­wań wie­lu zacnych lide­rów ryn­ku IT i kon­sul­tin­gu nazy­wa­nych model pro­ce­sów biznesowych”.

[przyp. auto­ra: cze­to mylo­ne są mapy pro­ce­sów z mode­la­mi pro­ce­sów, sto­su­je się poję­cie mapy pro­ce­sów dla dia­gra­mów poka­zu­ją­cych wza­jem­ne poło­że­nie pro­ce­sów wzglę­dem sie­bie, to jest ich ewen­tu­al­ne lub domnie­ma­ne następ­stwa, na tych dia­gra­mach raczej” nie sto­su­je się rom­bów” czy­li bra­mek decy­zyj­nych; nota­cja BPMN jako narzę­dzie do mode­lo­wa­nia i doku­men­to­wa­nia pro­ce­sów biz­ne­so­wych nie ope­ru­ję poję­cie mapy procesów”].

Jak zbu­do­wać peł­ny model firmy

Należy roz­róż­nić trzy głów­ne ele­men­ty mode­lo­wa­nia organizacji:

  1. model biz­ne­so­wy
  2. mapa pro­ce­sów biznesowych
  3. mapa prze­pły­wu pra­cy (pro­ce­du­ry, work­flow) dla poszcze­gól­nych procesów

Model biz­ne­so­wy

Model biz­ne­so­wy okre­śla inte­rak­cje z oto­cze­niem ryn­ko­wym. Jest to zwię­zły opis tego na czym i jak fir­ma zara­bia. Diagram powi­nien obra­zo­wać klu­czo­we pod­mio­ty na ryn­ku bio­rą­ce udział w two­rze­niu war­to­ści przez fir­mę, prze­pły­wy war­to­ści i prze­pły­wy pie­nię­dzy. Mówiąc ina­czej powi­nien obra­zo­wać kto, co i komu daje”. Dotyczy to zarów­no pro­duk­tów i pie­nię­dzy ale tak­że prze­ka­zy­wa­nych infor­ma­cji. Inaczej mówiąc model biz­ne­so­wy musi obra­zo­wać peł­ny prze­pływ korzy­ści. Korzyścią dla sprze­da­ją­ce­go jest zysk a korzy­ścią dla nabyw­cy jest pozy­ska­na funk­cjo­nal­ność lub inna cecha pro­duk­tu (nale­ży ją jasno okre­ślić). Jeżeli w tym obro­cie poja­wia się pośred­nik lub inny pod­miot mają­cy wpływ na ten obieg nale­ży go poka­zać i opi­sać jego rolę. Np. model biz­ne­so­wy pro­du­cen­ta sprzę­tu sie­cio­we­go powi­nien zawie­rać poza deale­ra­mi tak­że kanał infor­ma­cyj­ny, któ­rym prze­ka­zu­je­my spe­cjal­nie wyko­na­ne biblio­te­ki sym­bo­li dla pro­jek­tan­tów sie­ci, któ­rzy nie­ja­ko naga­nia­ją” popyt na nasze pro­duk­ty. Nie zapo­mi­naj­my też, że obsłu­ga ser­wi­so­wa to tak­że nasz produkt.

Mapa pro­ce­sów biznesowych

To obraz przed­sta­wia­ją­cy wszyst­kie funk­cje jakie wewnątrz orga­ni­za­cji są reali­zo­wa­ne w celu wytwo­rze­nia final­ne­go pro­duk­tu (lub pro­duk­tów). Do zobra­zo­wa­nia mapy pro­ce­sów powin­na wystar­czyć sym­bo­li­ka ICOM. Bardziej roz­bu­do­wa­ne sys­te­my mode­lo­wa­nia pozwa­la­ją dodat­ko­wo na zarzą­dza­nie takim pro­jek­tem, defi­nio­wa­nie szcze­gó­łów zaso­bów i opi­sa­nie ich kore­la­cji z procedurami.

Produktem może być przed­miot ale tak­że usłu­ga. Wszystko co ma cechy i cenę oraz przed­sta­wia jakąś war­tość dla kupu­ją­ce­go jest pro­duk­tem. Cechą funk­cji na mapie pro­ce­sów jest jej ist­nie­nie i brak moż­li­wo­ści pomi­nię­cia. Np. pro­ces wyda­wa­nia decy­zji w Urzędzie jest reali­zo­wa­ny bo decy­zja zawsze musi się poja­wić w odpo­wie­dzi na zło­że­nie poda­nie o jej wyda­nie. Może ona być pozy­tyw­na lub nega­tyw­na, może wyma­gać opi­nii bie­głe­go lub nie, może wyma­gać spraw­dze­nia wcze­śniej­szych innych decy­zji itp. To jed­nak okre­śla pro­ce­du­ra wyda­wa­nia decy­zji. Proces jest niezmienny.

Mapa prze­pły­wu pracy

Procedury to wła­śnie opi­sy spo­so­bu reali­za­cji funk­cji opi­sa­nych przez pro­ce­sy. Tu dopie­ro jest miej­sce na rom­by”. Procedurami defi­niu­je się np. spo­sób pra­cy sys­te­mów obie­gu doku­men­tów (infor­ma­cji) w fir­mach. Procedura to jeden z ele­men­tów nazy­wa­nych Controll w defi­ni­cji pro­ce­su. Procedury są opi­sy­wa­ne za pomo­cą sym­bo­li takich jak czyn­ność, decy­zja, doku­ment, inter­fejs itp.

Na zakoń­cze­nie

Ten krót­ki arty­kuł to przede wszyst­kim prze­stro­ga przed nad­mier­nym zaufa­niem dla nie­któ­rych firm ofe­ru­ją­cych usłu­gi wdro­że­nio­we i dorad­cze. Niestety na ryn­ku tym, jak na każ­dym innym, jest dużo niskiej jako­ści” a przede wszyst­kim chęć zara­bia­nia a nie­chęć do ucze­nia się i stu­dio­wa­nia. Modelowanie to dość trud­na dzie­dzi­na wie­dzy. Porównał bym ja do pra­cy copyw­ri­te­ra. Nie ma zna­cze­nia ile cza­su nad tym spę­dził zna­cze­nie ma jakiej jako­ści tekst napi­sał. Bywa, że po mie­sią­cu otrzy­ma­my rewe­la­cyj­ne jed­noz­da­nio­we hasło rekla­mo­we. W mode­lo­wa­niu biz­ne­so­wym mamy do czy­nie­nia z podob­nym zja­wi­skiem. Czasami wie­le dni cięż­kiej pra­cy owo­cu­je kil­ko­ma stro­na­mi kom­plet­ne­go, spój­ne­go i zro­zu­mia­łe­go dla kadry opi­su firmy.

Artykuł ten napi­sa­łem głów­nie po to by mogli Państwo tak­że sami oce­nić pra­cę firm, któ­rym pła­ci­cie za tego typu usłu­gi. Na pew­no mode­lo­wa­nie wyma­ga dłu­gich stu­diów i doświad­cze­nia ale efek­ty muszą być zro­zu­mia­łe. Nie jest ono moż­li­we bez udzia­łu wyż­szej kadry fir­my. Bieganie z ankie­ta­mi po fir­mie to doku­men­to­wa­nie sta­nu obec­ne­go a nie mode­lo­wa­nie. Dokumentowanie pro­ce­dur jest przy­dat­ne jako kolej­ny etap przy­go­to­wań do napi­sa­nia dedy­ko­wa­ne­go opro­gra­mo­wa­nia ale jest nie potrzeb­ne przed wdro­że­niem goto­we­go sys­te­mu, któ­ry tyl­ko pod­le­ga para­me­try­za­cji. Po dru­gie przed wdro­że­niem czy napi­sa­niem sys­te­mu koniecz­ne jest zbu­do­wa­nie mode­lu fir­my choć­by po to by upew­nić się, że jest on opty­mal­ny. W prze­ciw­nym wypad­ku może­my dopro­wa­dzić do utrwa­le­nia w sys­te­mie złych i nie­efek­tyw­nych pro­ce­sów a w skraj­nym przy­pad­ku panu­ją­ce­go w niej bałaganu.

W przy­go­to­wa­niu mam dla Państwa bogat­sze opra­co­wa­nie na temat mode­lo­wa­nia i metod sto­so­wa­nych do tego celu. Dodatkowe mate­ria­ły zgro­ma­dzi­łem dla Państwa tu: https://​it​-con​sul​ting​.pl/​p​u​b​/​C​a​s​e​S​t​u​dy/

Dostępne na ryn­ku narzę­dzia do modelowania

Na ryn­ku jest wie­le dobrych narzę­dzi wspie­ra­ją­cych two­rze­nie dia­gra­mów i mode­lo­wa­nie. W prost­szych przy­pad­kach z powo­dze­niem moż­na sto­so­wać np. pakiet MS Visio i biblio­te­kę IDEF0 lub audit dia­gram. Jednak do poważ­niej­szych pro­jek­tów dla dużych orga­ni­za­cji pro­wa­dzo­nych w gru­pach zada­nio­wych i wyma­ga­ją­cych kon­tro­li spój­no­ści dia­gra­mów wyma­ga­ne jest zasto­so­wa­nie narzę­dzi wspie­ra­ją­cych dodat­ko­wo pra­ce w gru­pie, wer­sjo­no­wa­nie, symu­la­cje oraz moż­li­wość inte­gra­cji w mode­lu tak­że pro­jek­tów zwią­za­nych z zarzą­dza­niem kosz­ta­mi pro­ce­sów. Cechą wie­lu sys­te­mów do wspo­ma­ga­nia mode­lo­wa­nia jest moż­li­wość ich inte­gra­cji z apli­ka­cja­mi ERP. Nowoczesne sys­te­mu kla­sy ERP to sys­te­my o pro­ce­so­wej orga­ni­za­cji. Pozwalają one na import wyko­na­nej mapy pro­ce­sów co zna­ko­mi­cie uspraw­nia i skra­ca wdro­że­nie sys­te­mu oraz obni­ża jego koszt. Można tu pole­cić pakiet ARIS opra­co­wa­ny i ofe­ro­wa­ny przez IDS Scheer.

Jako kon­sul­tant pro­wa­dzę tak­że pro­jek­ty zwią­za­ne z wybo­rem sys­te­mu infor­ma­tycz­ne­go nie wią­że się jed­nak z żad­nym z jego dostaw­ców na ryn­ku. Narzędzia słu­żą­ce do mode­lo­wa­nia wspie­ra­ją te dzia­ła­nia dla­te­go wymie­niam tu te, któ­rych uży­wam. Ich wybór jest podyk­to­wa­ny sku­tecz­no­ścią z jaką wspie­ra­ją pra­cę np. moją. Nie deter­mi­nu­ją one tego jakie­go sys­te­mu wspie­ra­ją­ce­go zarzą­dza­nie uży­je­my w przy­szło­ści po wyko­na­niu ana­li­zy i czy w ogó­le. Jako prak­tyk jed­nak spo­koj­nie mogę pole­cić pro­gra­my, któ­rych sam używam.

Na rynek wcho­dzi [[nota­cja BPMN]], wyglą­da na to, że sta­nie się standardem.