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.

Inne artykuły na podobny temat

Komentarze

  1. Sławomir Niemiec 4 lipca 2013 at 13:09

    Sporo pra­cu­ję wyko­rzy­stu­jąc narzę­dzia z rodzi­ny ARIS. Pójdę jesz­cze dalej i wyróż­nię nawet 6 pozio­mów. Opiszę je jed­nak trosz­kę inna­czej niż robią to kole­dzy z Software AG. Mianowicie:
    I. Poziom 1 i 2 przed­sta­wia kon­tekst” (gdzie?). Poziom 1 opi­su­je glo­bal­ny kon­tekst orga­ni­za­cji, nato­miast poziom 2 roz­wi­ja mode­le pozio­mu 1 uka­zu­jąc jego dodat­ko­we moż­li­we warianty.
    II. Poziom 3 i 4 przed­sta­wia kon­cep­cje” (co?). Odpowiednio poziom 3 jest jak­by mostem pomię­dzy pozio­ma­mi 2 i 4 w przy­pad­ku gdy zawar­tość pro­ce­sów biz­ne­so­wych” jest zbyt roz­le­gła lub skom­pli­ko­wa­na. Z kolei poziom 4 opi­su­je esen­cje” wyja­śnia­jąc dzia­ła­nie biznesu”
    III. Poziom 5 i 6 przed­sta­wia imple­men­ta­cję” (jak?). Tutaj mamy nastę­pu­ją­cą sytu­acje: poziom 5 to jak­by ope­ra­cyj­na imple­men­ta­cja” zwią­za­na z czyn­no­ścia­mi i zda­rze­nia­mi wystę­pu­ją­cy­mi na mode­lu pozio­mu 4. Poziom 6 opi­su­je w deta­lach to co musi być zro­bio­ne aby wyko­nać pro­ce­sy opi­sa­ne na pozio­mie 4 i/lub 5.
    W swo­jej pra­cy zazwy­czaj ana­li­zę opie­ram na pozio­mach 1, 2, 4 i 5, nato­miast pozio­my 3 i 6 wystę­pu­ją cza­sa­mi opcjo­nal­nie (w zależ­no­ści od potrzeb). Pracując z klien­tem mam zatem hie­rar­chię 3 lub mak­sy­mal­nie 4 pozio­mów. Wszystko zale­ży od wiel­ko­ści orga­ni­za­cji i potrzeb, bo prze­cież pozio­my opi­su pro­ce­sów mają nam pomóc upo­rząd­ko­wać pra­cę a nie prze­szka­dzać oraz kom­pli­ko­wać życie.

    • Jarek Żeliński 4 lipca 2013 at 16:48

      Rozumiem. Mnie zawsze zasta­na­wia dla­cze­go tak mało firm dorad­czych zamiast korzy­sta­nia z ist­nie­nia doku­men­ta­cji HR, wtór­nie mode­lu­je” dia­gra­ma­mi (dublu­je) wie­dzę” wyni­ka­ją­cą z zakre­su obo­wiąz­ków, zarzą­dzeń i prze­pi­sów pra­wa zamiast się na nią w tych mode­lach powo­ły­wać? Tym bar­dziej, że i tak nie­moż­li­wa jest rezy­gna­cja z tych (zakre­sy obo­wiąz­ków, zarzą­dze­nia i prze­pi­sy pra­wa) dokumentów… 

      W sumie zacho­wu­jąc pew­ną kon­se­kwen­cję (pro­dukt lub stan biz­ne­so­wy) mamy kolej­ne pozio­my (szcze­gó­ło­wo­ści) pro­ce­sów biz­ne­so­wych (nie end-2-end i nie implementacja):
      – two­rze­nia doku­men­tów (np. wysta­wie­nie faktury),
      – zmian sta­tu­sów doku­men­tów (fak­tu­ra utwo­rzo­na, zatwier­dzo­na, zaksię­go­wa­na, doręczona),
      – dla każ­dej czyn­no­ści przy­po­rząd­ko­wu­je­my pro­ce­du­rę lub wyma­ga­ną umiejętność/wiedzę, te są dostęp­ne w HR i np. doku­men­ta­cji ISO,
      Ten naj­niż­szy to wspo­mnia­na imple­men­ta­cja i raczej nie BPMN a MS Word 😉 (z uwa­gą w arty­ku­le o zło­żo­nych jak algo­ryt­my pro­ce­du­rach, któ­re cza­sem fak­tycz­nie war­to narysować).

      Ale fak­tem jest, że nie ma jed­ne­go wzor­ca, każ­dy pro­jekt wyma­ga usta­le­nia kon­wen­cji dopa­so­wa­nej do aktu­al­nej kul­tu­ry fir­my i stop­nia jej (nie)uporządkowania 😉

  2. Sławek Ryszkowski 12 lipca 2013 at 11:25

    Zastanawiam się czy na naj­wyż­szym pozio­mie zawsze mamy do czy­nie­nia z pro­ce­sa­mi typu end-to-end, a na niż­szych pozio­mach uszcze­gó­ła­wia­my ich defi­ni­cję mode­lu­jąc sekwen­cje dzia­łań. Spotkałem się z mapą pro­ce­sów, na któ­rej są one podzie­lo­ne na obsza­ry, np.: Produkcja, Rozwój, Sprzedaż i Obsługa Klienta, Planowanie i kon­tro­la stra­te­gicz­na. Można by powie­dzieć że jest to pierw­szy poziom mode­lo­wa­nia pro­ce­sów. Procesów wyróż­nio­nych w ramach dane­go obsza­ru nie moż­na jed­nak uło­żyć w sekwen­cję, zgod­nie z defi­ni­cją pro­ce­su – obsza­ry nie są zatem pro­ce­sa­mi typu end-to-end. W ramach wyróż­nio­nych obsza­rów rów­nież mogą poja­wić się tak­że ?pro­ce­sy? nie pod­da­ją­ce się defi­ni­cji, nazy­wam je robo­czo ?cią­gły­mi?, czy­li taki­mi któ­re wyko­ny­wa­ne są w spo­sób nie­prze­rwa­ny, naj­czę­ściej posia­da­ją one w nazwie okre­śle­nie ?zarzą­dza­nie ??, np. Zarządzanie port­fe­lem pro­jek­tów, Zarządzanie jako­ścią, Zarządzanie port­fe­lem klientów.
    Jak sobie radzić z tego typu ?pro­ce­sa­mi? ? czy w ogól­ne moż­na je wyróż­niać na mapie pro­ce­sów, czy jed­nak dążyć do tego, aby każ­dy pro­ces miał swój począ­tek i koniec. Ich minus jest taki, że defi­ni­cja pro­ce­su na niż­szym pozio­mie może być tyl­ko enu­me­ra­tyw­ną listą pro­ce­sów typu end-to-end reali­zu­ją­cych poszcze­gól­ne dzia­ła­nia, wcho­dzą­ce w skład ?pro­ce­su cią­głe­go?. Co wię­cej taka mapa pro­ce­sów prze­sta­wio­na zosta­ła przez fir­mę kon­sul­tin­go­wą z BIG4, czy­li posia­da­ją­cej duże doświad­cze­nie, przy­naj­mniej w teo­rii. Z dru­giej stro­ny wyda­je się, że ist­nie­ją obsza­ry w orga­ni­za­cji, któ­ry nie moż­na zde­fi­nio­wać typo­we­go pro­ce­su, a któ­re pod­cho­dzą raczej pod coś co jest okre­śla­ne jak Case Management, czym ostat­nio zaj­mu­je się tak­że OMG (stan­dard CCMN).

    • Jarek Żeliński 12 lipca 2013 at 13:54

      Problem nie jest pro­sty, źró­dłem zła” jest w moich oczach bała­gan poję­cio­wy wpro­wa­dza­ny przez fir­my dorad­cze, wpro­wa­dza­ją one czę­sto, we wła­snych meto­dach pra­cy, defi­ni­cje pojęć odbie­ga­ją­ce od tych jakie są okre­ślo­ne w nota­cjach, któ­re te same fir­my sto­su­ją. Nie potra­fią też ich uza­sad­nić, sys­te­my poję­cio­we jakie widu­ję w pro­duk­tach wie­lu firm dorad­czych, nie tyl­ko BIG4, nie speł­nia­ją defi­ni­cji sys­te­mu poję­cio­we­go (roz­łącz­ność, nie­sprzecz­no­ści pojęć i zupeł­ność słownika). 

      Najpierw słow­nik (cyta­ty z PWN):
      zarzą­dzać: 1. ?wydać pole­ce­nie?, 2. zarzą­dzać ?spra­wo­wać nad czymś zarząd?
      pro­ces ?prze­bieg nastę­pu­ją­cych po sobie i powią­za­nych przy­czy­no­wo okre­ślo­nych zmian?

      Tak więc zarzą­dza­nie pro­ce­sem to wyda­wa­nie pole­ceń pod­czas prze­bie­gu nastę­pu­ją­cych po sobie i powią­za­nych przy­czy­no­wo okre­ślo­nych zmian” (domyśl­nie, pole­ceń mają­cych wpływ na dany pro­ces). Proces end-2-end ma pro­stą defi­ni­cję: począ­tek i koniec (wej­ście i wyj­ście) są na sty­ku orga­ni­za­cji z jej otoczeniem. 

      Planowanie i kon­tro­la. Najpierw musi być zde­fi­nio­wa­na by ją mode­lo­wać. Proces pla­no­wa­nia two­rzy plan, pro­ces kon­tro­li two­rzy zda­rze­nia (dane) opi­su­ją­ce to jak się ma stan rze­czy­wi­sty do sta­ny zapla­no­wa­ne­go. To pro­duk­ty tych pro­ce­sów: plan oraz dane o odstęp­stwach od pla­nu. Proces pla­no­wa­nia ini­cjo­wa­ny jest potrze­bą zbu­do­wa­nia pla­nu, potem sygna­łem o odstęp­stwach. Są to wewnętrz­ne pro­ce­sy, nie mają­ce z end-2-end nic wspól­ne­go. Na jakim są pozio­mie? W nie­któ­rych fir­mach nawet na każdym! 

      Terminy takie jak Rozwój czy Obsługa klien­ta to atry­bu­ty opi­su­ją­ce te pro­ce­sy tak samo jak kolo­ry: może­my pro­ce­sy gru­po­wać dowolnie. 

      Większości pro­ce­sów nie da się uło­żyć w jed­ną sekwen­cję, co czę­sto pró­bu­ją robić fir­my, bo pro­ce­sy – z defi­ni­cji – ini­cjo­wa­ne są zda­rze­nia­mi, a wie­le zda­rzeń wystę­pu­je loso­wo z per­spek­ty­wy orga­ni­za­cji: gene­ru­ją je ele­men­ty oto­cze­nia tych orga­ni­za­cji, a nie one, orga­ni­za­cje, same. 

      Proces cią­gły jest nadal pro­ce­sem (pro­ces desty­la­cji wody zamie­nia wodę zanie­czysz­czo­na w czy­stą). Każdy taki pro­ces jest mie­rzal­ny stop­niem czy­sto­ści i ilo­ścią litrów np. w jed­no­st­ce cza­su. Na pew­no nie ma taka desty­la­cja w pew­nym uprosz­cze­niu” począt­ku ani koń­ca, ale pro­ces to powta­rzal­na sekwen­cja”, każ­dy kolej­ny litr brud­nej wody jest pod­grze­wa­ny, odpa­ro­wy­wa­ny i skra­pla­ny. To, że jest to ciecz nie zmie­nia tego fak­tu. Proces kon­tro­li i zarzą­dza­nia? Nie ma takie­go! Zarządzanie to nie pro­ces, to w reak­cji na odstęp­stwo od pla­nu, ini­cjo­wa­nie korek­ty pla­nu. Faktem jest, że jest to tak czę­sto” jak dro­bin­ki wody w stru­mie­niu, ale nie jest to pro­ces cią­gły zarzą­dza­nia tyl­ko czę­sto wystę­pu­ją­cy pro­ces korek­ty planu. 

      Co do pro­duk­tów BIG4 mogę powie­dzieć tyl­ko tyle, że żad­na nie potra­fi w pro­jek­cie udo­wod­nić słusz­no­ści swo­jej meto­dy­ki, potra­fi napi­sać, że jakiś pro­ces jest lub nie jest czymś ale nie potra­fi już tego wyka­zać” (w każ­dym razie ja nie spo­tka­łem się).

  3. Sławek Ryszkowski 15 lipca 2013 at 13:11

    Również jestem zda­nia, że nie­któ­re z wymie­nio­nych przy­kła­dów pro­ce­sów (np. Produkcja, Rozwój) sta­no­wią raczej dodat­ko­wy atry­but pro­ce­su end-to-end ani­że­li odręb­ny pro­ces. Podobną kon­cep­cję przy­to­czył zresz­tą kole­ga w pierw­szej odpo­wie­dzi, czy­li atry­bu­ty: gdzie? i co?.
    Z dru­giej stro­ny nur­tu­je mnie przy­to­czo­na przez Ciebie defi­ni­cja pro­ce­su end-to-end. Czy tego typu pro­ces wystę­pu­je tyl­ko i wyłącz­nie na sty­ku orga­ni­za­cji z biz­ne­sem? Wstępnie wyda­je się że tak. Mam nato­miast pewien dyle­mat, spo­wo­do­wa­ny pew­nie dużą licz­bą pro­ce­sów iden­ty­fi­ko­wa­nych jako wewnętrz­ne (np. kadro­we, finan­so­wej, admi­ni­stra­cyj­ne), któ­re na pierw­szy rzut oka są nie­za­leż­ne, jed­nak po głęb­szym zasta­no­wie­niu moż­na dostrzec na niż­szych pozio­mach mode­lo­wa­nie jakieś powią­za­nia z pro­ce­sa­mi end-to-end.
    Zastanawiam się teraz jak wyglą­da­ją mapy pro­ce­sów w orga­ni­za­cjach, któ­rych zarzą­dza się pro­ce­sa­mi. Czy zawie­ra­ją one wyłącz­nie pro­ce­sy end-to-end, czy może utrzy­my­wa­nia jest tak­że osob­na mapa pro­ce­sów wewnętrz­nych, wyko­rzy­sty­wa­nych w pro­ce­sach end-to-end?
    I kolej­na nur­tu­ją­ca mnie kwe­stia. Przyjmując że pro­ces end-to-end okre­śla styk orga­ni­za­cji z oto­cze­niem, jak sobie radzić z wła­ści­ciel­stwem pro­ce­su sko­ro jego reali­za­cja roz­cią­ga się prze­waż­nie przez wie­le jed­no­stek organizacji.

    • Jarek Żeliński 15 lipca 2013 at 13:28

      Od koń­ca: jeże­li jakiś pro­ces end-2-end nie ma jed­ne­go wła­ści­cie­la to źle się dzie­je w fir­mie” ;). typo­wym pro­ce­sem end-2-end jest np. obsłu­ga zapy­tań ofer­to­wych czy zamó­wień. Jeżeli jesz­cze pierw­szy leży z regu­ły w cało­ści w gestii np. dyr. dz. sprze­da­ży, to dru­gi już w wie­lu fir­mach jest bez­pań­ski” i znam wie­le firm, któ­re zmie­nia­ją to po wpad­kach z jako­ścią obsłu­gi. Z regu­ły wła­ści­cie­lem pro­ce­su obsłu­gi zamó­wień sta­je się logistyk. 

      Co do pro­ce­sów zwa­nych wewnętrz­ny­mi. One dostar­cza­ją zaso­bów nie­zbęd­nych do funk­cjo­no­wa­nia takich jak ludzie (kadry), maszy­ny, środ­ki finan­so­we (finan­se) itp. W lite­ra­tu­rze zachod­niej na tema­ty BPM func­kjo­nu­je model IGOE lub ICOM pro­ce­su, opi­sa­ny np. tu: OGOE (opis na stro­nie BPTrends). Moja wer­sja tego gdzie są zaso­by opi­sa­na tutaj. Ludzie, maszy­ny, środ­ki finan­so­we itp, to tak zwa­ne ena­blers” czy­li ele­men­ty bez któ­rych pro­ce­sy głów­ne nie mogą funk­cjo­no­wać. pro­ce­sy dostar­cza­ją­ce owe ena­blers” są nie­wąt­pli­wie bar­dzo waż­ne ale nie są to mimo wszyst­ko pro­ce­sy naj­waż­niej­sze (end-2-end). Zresztą czę­sto są one outsoursowane.

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.