Abstrakcja w Architekturze Biznesowej

W poprzed­nim arty­ku­le, Czy sys­tem peł­ni rolę w pro­ce­sie?, poja­wi­ła się pole­mi­ka, któ­ra jest dość powszech­nym problemem:

[czy­tel­nik] Są to pro­ce­sy (lub pod­pro­ce­sy), któ­re zosta­ły zastą­pio­ne w 100% i alter­na­tyw­na ich obsłu­ga będzie moż­li­wa tyl­ko w przy­pad­ku wystą­pie­nia jakie­goś błędu.

Przykładem takie­go pro­ce­su jest zauto­ma­ty­zo­wa­nie reje­stra­cji doku­men­tów (wpro­wa­dze­nie kana­łu mailo­we­go, odcię­cie cał­ko­wi­te moż­li­wo­ści wyko­rzy­sta­nia papie­ro­wych doku­men­tów). Test odłą­cze­nia prą­du ode­tnie orga­ni­za­cję od świa­ta zewnętrz­ne­go. Wyobrażam sobie wie­le biz­ne­sów opie­ra­ją­cych się w więk­szo­ści o chmu­ry, usłu­gi, któ­rych wycię­cie spro­wa­dzi ten aku­rat biz­nes do pozio­mu średniowiecznego.

[moja odpo­wiedź] odłą­cze­nie prą­du spo­wo­du­je zmu­sze­nie do prze­my­śle­nia i nazwa­nia pro­ce­su ?przyj­mo­wa­nie doku­men­tów? a mail to tyl­ko przy­ję­ta meto­da, tu błę­dem było nazwa­nie pro­ce­su biz­ne­so­we­go ?odbie­ra­ni maili? zamiast nazwa­nie go ?tym czym jest? czy­li ?przyj­mo­wa­nie korespondencji?.

Jest to kla­sycz­ny przy­kład bra­ku uogól­nień i abs­trak­cji w mode­lach, co pro­wa­dzi do zamu­la­nia” ich nad­mia­rem szcze­gó­łów, masko­wa­nia praw­dzi­we­go sen­su (isto­ty) zja­wi­ska. Problem sto­so­wa­nia abs­trak­cji w mode­lo­wa­niu a kon­kret­nie, pro­blem nie radze­nia sobie z abs­trak­cją, jest czę­sto w lite­ra­tu­rze nazy­wa­ny utra­tą pano­wa­nia nad szcze­gó­ło­wo­ścią pro­jek­tu”. Monstrualne ilo­ści dia­gra­mów pro­ce­sów, mon­stru­al­ne ilo­ści deta­li na dia­gra­mach, to efekt bra­ku abstrakcji.

Warto pamię­tać, że mode­le pro­ce­sów biz­ne­so­wych to ele­ment opi­su archi­tek­tu­ry biz­ne­so­wej. Po raz kolej­ny przy­po­mnę diagram:

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

Najniższa war­stwa to imple­men­ta­cja pro­ce­sów, tu dopie­ro mamy wszel­kie szcze­gó­ły takie jak: zakre­sy obo­wiąz­ków, instruk­cje sta­no­wi­sko­we i pod­ręcz­ni­ki użyt­kow­ni­ków, pro­ce­du­ry, wyma­ga­ne umie­jęt­no­ści, kon­kret­ne roz­wią­za­nia np. opro­gra­mo­wa­nie. Są to te ele­men­ty, któ­rych nie umiesz­cza­my na mode­lu pro­ce­sów, bo pro­ce­sy biz­ne­so­we to czyn­no­ści prze­kształ­ca­ją­ce stan wej­ścia w stan wyj­ścia”. Proces biz­ne­so­wy to jeden blo­czek” wraz z jego wej­ściem i wyj­ściem (pro­ces defi­niu­ją te trzy ele­men­ty) na sche­ma­cie blo­ko­wym będą­cym mode­lem (mapą) pro­ce­sów. Bloczek repre­zen­tu­ją­cy czyn­ność (aktyw­ność, kwe­stia nazew­nic­twa), jest abs­trak­cją pro­ce­du­ry, umie­jęt­no­ści, instruk­cji obsłu­gi, itp. W doku­men­ta­cji więc powo­łu­je­my się na te np. pro­ce­du­ry (sto­sow­ne doku­men­ty), a nie odtwa­rza­my ich obraz­ko­wo” na mode­lu pro­ce­sów, bo to pro­wa­dzi po pierw­sze do dublo­wa­nia ist­nie­ją­cej doku­men­ta­cji oraz do strasz­nej kom­pli­ka­cji dia­gra­mów obra­zu­ją­cych procesy.

Problem ten dobrze opi­su­je autor tego artykułu:

One of the key cha­rac­te­ri­stics of archi­tec­tu­re is looking at the ?big pic­tu­re?, but a major chal­len­ge is that we can?t pre­sent the big pic­tu­re on one gre­at big pie­ce of paper ? it has to fit on a sin­gle she­et or model. In order to do that, we have to come up with new con­cepts that sum­ma­ri­ze the ove­rall pic­tu­re into a small num­ber of ele­ments and rela­tion­ships. We can do this thro­ugh a varie­ty of tech­ni­qu­es, like divi­de-and-conqu­er, cate­go­ri­za­tion, gene­ra­li­za­tion, and so on. (BPTrends | Business Archicture: Abstraction in Business Architecture).

Tak więc brak (umie­jęt­no­ści) sto­so­wa­nia abs­trak­cji w mode­lo­wa­niu czy­ni te i inne mode­le (tak­że UMl itp.) nie­czy­tel­ny­mi, trud­ny­mi do inter­pre­ta­cji, kosz­tow­ny­mi w wytwo­rze­niu i potem w utrzy­ma­niu. To ostat­nie powo­du­je, że więk­szość takich doku­men­tów szyb­ko koń­czy życie na pół­kach, bo dez­ak­tu­ali­zu­ją się jak tyl­ko doj­dzie do jakiej­kol­wiek, nawet naj­drob­niej­szej, zmia­ny w orga­ni­za­cji. Co cie­ka­we, bio­rąc pod uwa­gę czas trwa­nia prze­cięt­ne­go wdro­że­nia opro­gra­mo­wa­nia, taki zbyt szcze­gó­ło­wy model nie ma szans być przy­dat­nym w toku takie­go pro­jek­tu, tu rację mają deve­lo­pe­rzy, któ­rzy twier­dzą, że im takie doku­men­ty im w niczym nie pomagają.

No ale te szcze­gó­ły są potrzeb­ne. Owszem pyta­nie: któ­re oraz czy na pew­no musi­my je obraz­ko­wo prze­pi­sy­wać np. z doku­men­tów dzia­łu HR czy jako­ści. W doku­men­to­wa­niu (mode­lo­wa­niu) orga­ni­za­cji sto­su­je­my róż­ne per­spek­ty­wy”, kil­ka pro­stych sche­ma­tów lepiej mode­lu­je orga­ni­za­cję niż jed­ne, na któ­rych ktoś upy­cha wszyst­ko co wie” (jak to robić lepiej opi­sa­łem w arty­ku­le Gdzie są te … szcze­gó­ły).

Tak więc doku­men­to­wa­nie szcze­gó­łów” owszem jest potrzeb­ne, ale nie na dia­gra­mie pro­ce­su. Umiejętności i wie­dza wyko­naw­cy to rola w pro­ce­sie: każ­da powin­na mieć osob­ną doku­men­ta­cję (lub odwo­ła­nie do doku­men­tów w HR). Szczegóły reali­za­cji zadań (czyn­no­ści, aktyw­no­ści) to pro­ce­du­ry, na któ­re zno­wu się powo­łu­je­my, lub takie doku­men­ty jak macierz RACI i spe­cy­fi­ka­cja poli­tyk i reguł biz­ne­so­wych (opi­sa­łem to w arty­ku­le RACI … i wcze­śniej­szym RACI i SIPOC).

I tu mały przty­czek dla spon­so­rów pro­jek­tów zle­ca­ją­cych takie ana­li­zy: żąda­nia wobec ana­li­ty­ka w rodza­ju a ja chcę zoba­czyć jesz­cze to … na tym sche­ma­cie” to zabi­ja­nie pro­jek­tu. Są uzna­ne dobre prak­ty­ki, mię­dzy inny­mi mode­lo­wa­nie od ogó­łu do szcze­gó­łu, sto­so­wa­nie abs­trak­cji i per­spek­tyw. Nikt roz­sąd­ny nie będzie podej­mo­wał prób two­rze­nia pla­nu mia­sta, na któ­rym będą wszyst­kie te rze­czy, któ­re w danym mie­ście są np. przy­stan­ki środ­ków komu­ni­ka­cji publicz­nej, pod­mio­ty gospo­dar­cze, ale tak­że wyso­kość grun­tu, zna­ki dro­go­we, skle­py itp. Taka mapa, zakła­da­jąc jej roz­sąd­ną wiel­kość, była by nie­przy­dat­na, więc żąda­nie takiej od ana­li­ty­ka tak­że nie ma żad­ne­go sensu.

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.

Business Process Manifesto

Na stro­nach [[Business Process Trends]] uka­zał się cie­ka­wy doku­ment autor­stwa Rogera Burltona, o wdzięcz­nym tytu­le: Business Process Manifesto. Jego autor pisze, że

The Business Process Manifesto is the result of over 20 years of expe­rien­ce wor­king as a Business Process con­sul­tant along­si­de friends and col­le­agu­es wor­king as aca­de­mics, con­sul­tants and busi­ness pro­cess prac­ti­tio­ners. I have long belie­ved that a com­mon under­stan­ding of the foun­da­tion of Business Process would bene­fit all of us in the field of Business Process. (za Business Process Trends :: BP Manifesto ::).

Ogólnie rzecz bio­rąc ponad 20 let­nie doświad­cze­nie ana­li­ty­ków aka­de­mi­ków i prak­ty­ków zaowo­co­wa­ło pró­bą upo­rząd­ko­wa­nia tej, jak­że popu­lar­nej i nie­mal­że nie­sfor­ma­li­zo­wa­nej a bar­dzo potrzeb­nej wie­dzy. Kluczem mani­fe­stu jest defi­ni­cja pro­ce­su biz­ne­so­we­go:

Working defi­ni­tion of Business Process: An orga­ni­za­tio­n’s Business Processes cle­ar­ly descri­be the work per­for­med by all reso­ur­ces invo­lved in cre­ating out­co­mes of value for its custo­mers and other stakeholders

Proces biz­ne­so­wy opi­su­je pra­cę wyko­ny­wa­ną przez wszyst­kie zaan­ga­żo­wa­ne w nie­go zaso­by tej orga­ni­za­cji, two­rzą­cą pro­dukt, mają­cy war­tość dla klien­tów lub innych zain­te­re­so­wa­nych podmiotów.

Podejmowano wie­le prób upo­rząd­ko­wa­nia ter­mi­no­lo­gii w tym obsza­rze ana­li­zy, powyż­sza wyda­je się naj­lep­sza bo jest pro­sta, zgod­na (kom­pa­ty­bil­na) z uzna­ny­mi meto­da­mi mode­lo­wa­nia procesów.

Nie ukry­wam, że cie­szy mnie ta pró­ba stan­da­ry­za­cji” bo bez stan­dar­dów lub co naj­mniej uzna­nych prak­tyk i metod, ana­li­za biz­ne­so­wa i mode­lo­wa­nie pro­ce­sów, jako pod­sta­wo­we narzę­dzie tej ana­li­zy, są nie porów­ny­wal­ne mię­dzy sobą. W efek­cie pro­jek­ty o wdzięcz­nej nazwie mode­lo­wa­nie pro­ce­sów biz­ne­so­wych” były, są mono­po­lem każ­dy sam dla sie­bie. W efek­cie nie da się zmie­nić wyko­naw­cy w trak­cie pro­jek­tu, a pro­duk­ty pra­cy nie raz są nie­przy­dat­ne innym usłu­go­daw­com niż autor mode­li, np. kon­ty­nu­ują­cym projekt.

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 metodyce:

proces biznesowy i jego otoczenie (c) Jarosław Żeliński 2010

są zgod­ne z tym Manifestem.

Uzupełnieniem defi­ni­cji pro­ce­su w Manifeście są defi­ni­cje klu­czo­wych jej pojęć. Praca to prze­twa­rza­nie rze­czy fizycz­nych lub infor­ma­cji. Produkt pro­ce­su to efekt pra­cy o mie­rzal­nej war­to­ści. Zasoby to ludzie i wszel­kie ich narzę­dzia pra­cy. Kontekst biz­ne­so­wy, musi wska­zy­wać na jasno okre­ślo­ne gra­ni­ce orga­ni­za­cji, zda­rze­nia ini­cju­ją­ce i koń­czą­ce każ­dą pra­cę (pro­ces). Proces musi mieć cel biz­ne­so­wy, któ­ry reali­zu­je lub wspie­ra. Model pro­ce­su to róż­ne per­spek­ty­wy, nota­cje i dia­gra­my (w zasa­dzie stan­dar­dem jest sto­so­wa­nie gra­ficz­nych nota­cji mode­lo­wa­nia pro­ce­su, opi­su struk­tu­ry orga­ni­za­cyj­nej, sys­tem reguł biz­ne­so­wych i słow­nik pojęć, przyp. mój). Model pro­ce­su to tak­że wszel­kie ogra­ni­cze­nia takie jak regu­ły biz­ne­so­we i obo­wią­zu­ją­ce prawo.

Cieszę, że postę­pu­je pro­ces for­ma­li­za­cji i porząd­ko­wa­nia tego obsza­ru ana­li­zy, cie­szę się tym bar­dziej, że swe­go cza­su obra­łem taki sam kie­ru­nek, meto­dy­ka któ­rą sto­su­ję wpi­su­je się w 100% w ten Manifest.

Modelowanie biznesowe c.d. – know-how, gdzie ono jest?

W 2005 roku napi­sa­łem dosyć radykalnie:

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 (Constraints). 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?. (pole­cam lek­tu­rę całe­go arty­ku­łu Modelowanie biz­ne­so­we czy­li pil­no­wa­nie hochsz­ta­ple­rów).

Nie raz spo­ty­ka­łem się kry­ty­ką tej tezy, no bo jak to, ma nie być rom­bów decy­zyj­nych w pro­ce­sie”? Otóż od daw­na jestem zwo­len­ni­kiem mode­lo­wa­nia z uży­ciem reguł biz­ne­so­wych i sepa­ro­wa­nie ich od mode­lu pro­ce­su. Na stro­nie Business Rules Group publi­ko­wa­ny jest mię­dzy inny­mi tak zwa­ny Business Rules Manifesto (Manifest Reguł Biznesowych, jest tak­że do pobra­nia wer­sja pol­ska), któ­ry zawie­ra mię­dzy inny­mi defi­ni­cję reguł biznesowych:

Artykuł 2. [regu­ły biz­ne­so­we są ] Oddzielone od pro­ce­sów, a nie zawie­ra­ją­ce się w nich. 2.1. Reguły są bez­po­śred­ni­mi ogra­ni­cze­nia­mi narzu­co­ny­mi na funk­cjo­no­wa­nie orga­ni­za­cji jak rów­nież mogą sta­no­wić wspar­cie dla jej funk­cjo­no­wa­nia. 2.2. Reguły nie są pro­ce­sa­mi ani pro­ce­du­ra­mi. Nie powin­ny być w nich zawar­te. 2.3. Reguły mają zasto­so­wa­nie ponad i pomię­dzy pro­ce­sa­mi i pro­ce­du­ra­mi. Powinny sta­no­wić jeden spój­ny orga­nizm, sto­so­wa­ny kon­se­kwent­nie w odpo­wied­nich obsza­rach aktyw­no­ści biznesowej.

Definicja pro­ce­su, któ­rą nie raz tu przytaczałem:

Proces to prze­kształ­ce­nie wej­ścia w wyj­ście, z uży­ciem pew­nych zaso­bów w obec­no­ści pew­nych ograniczeń.

Proces biz­ne­so­wy to powyż­sze, wzbo­ga­co­ne o „… gdzie wyj­ście (pro­dukt) pro­ce­su sta­no­wi dla odbior­cy więk­szą war­tość w sto­sun­ku do jego wejścia”.

Metod mode­lo­wa­nia pro­ce­sów jest wie­le, ja uży­wam nota­cji BPMN. Jest to dobrze opi­sa­ny sys­tem poję­cio­wy i wygod­ny w sto­so­wa­niu. Z pomo­cą nota­cji BPMN moż­na mode­lo­wać pro­ce­sy na dowol­nym pozio­mie abs­trak­cji. Notacja ta powsta­ła i jest roz­wi­ja w celu opi­su pro­ce­sów wyko­ny­wal­nych, jed­nak to zasto­so­wa­nie nazwał bym mimo wszyst­ko niszo­wym. System poję­cio­wy BPMN jed­nak dosko­na­le nada­je się do mode­lo­wa­nia na wyż­szym, niż wyko­na­nie, pozio­mie abstrakcji.

Zanim poka­żę przy­kład, przy­to­czę inny popu­lar­ny obra­zek”, a mia­no­wi­cie struk­tu­rę pira­mi­dy obra­zu­ją­cą trzy pozio­my mode­lo­wa­nia orga­ni­za­cji. Żeby nie było nud­no nie będzie to mój dia­gram, zna­ny z poprzed­nich moich wpi­sów na tym blo­gu, a model a zapo­ży­czo­ny ze stro­ny Business Process Trends. Robię to celo­wo, by zwró­cić uwa­gę na to, że to powszech­nie przy­ję­ty podział, spo­ty­ka­ny tak­że u kla­sy­ków reor­ga­ni­za­cji Rumllera i Brache’a i Rogera Burltona.

Model ze stron BPTrends ma nastę­pu­ją­cą postać:

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

Jak widać tu tak­że pro­ces biz­ne­so­wy to abs­trak­cja środ­ko­wej war­stwy. Modele wyko­naw­cze to cią­gi czyn­no­ści reali­zo­wa­nych przez ludzi (nie koniecz­nie z pomo­cą sys­te­mu kom­pu­te­ro­we­go, tak­że pro­ce­du­ral­ne). Na naj­niż­szym pozio­mie mamy ludzi, ich wie­dzę i umie­jęt­no­ści (pra­ca i szcze­gó­ło­wość jej opi­su zale­ży od wie­dzy i umie­jęt­no­ści wyko­naw­cy). Mamy tak­że IT bo pro­ce­sy wyko­ny­wal­ne (ich mode­le) mogą być imple­men­to­wa­ne w sys­te­mach workflow.

Proces biz­ne­so­wy, nie pro­ce­du­ra i nie opis prze­pły­wu pra­cy, to pro­sty ciąg czyn­no­ści, któ­rych celem jest kon­kret­ny rezul­tat: pro­dukt pro­ce­su (jego wyj­ście). Tu pomi­nę doku­men­ty (pro­duk­ty czyn­no­ści) by upro­ścić diagram.

Proces ma cel, sta­no­wi pro­sty łań­cuch pra­cy wyko­naw­cy (Rola), radzi sobie z wyda­rze­nia­mi utrud­nia­ją­cy­mi”. Główny ciąg (ocze­ki­wa­ny) zazna­czo­no sza­ra strzał­ką. Pozostałe atrak­cje” to czyn­no­ści wymu­szo­ne pew­ny­mi nie ocze­ki­wa­ny­mi (a raczej nie chcia­ny­mi), ale prze­wi­dzia­ny­mi zda­rze­nia­mi. Tu nie ma rom­bów”, bra­mek decy­zyj­nych bo one są cechą pro­ce­sów decy­zyj­nych”, pro­ce­dur, a te to regu­ły biz­ne­so­we i wie­dza o biz­ne­sie” a nie pro­ces biz­ne­so­wy. Pewne czyn­no­ści mogą być ogra­ni­czo­ne Procedurą, któ­ra mówi, że tyl­ko tak wol­no tę pra­cę wykonać”.

Kilka lat temu na jed­nej z kon­fe­ren­cji, opi­sy­wa­łem zakres pra­cy nad wdro­że­niem sys­te­mu ERP:

Analiza i zakres pro­jek­tu to opis stra­te­gii. Jest to głów­ny, sta­ły ele­ment pro­jek­tu: stra­te­gia fir­my musi być usta­lo­na przed jakim­kol­wiek pro­jek­tem wdra­ża­nia zmian. Procesy biz­ne­so­we opi­su­ją jak to robi­my. Tu jest miej­sce na ewen­tu­al­ne opty­ma­li­za­cje (mody­fi­ka­cje wewnątrz łań­cu­cha war­to­ści. I najważniejsze:

Opracowywanie wyma­gań to pla­no­wa­nie zmian. Nie ma sen­su spi­sy­wa­nie szcze­gó­łów tej pra­cy, jeże­li wdra­ża­ne zmian spo­wo­du­je powsta­nie np. nowych pro­ce­dur, wyni­ka­ją­cych z celu pro­jek­tu. Zupełnie wystar­czy posia­da­nie wie­dzy o pro­ce­sach i ich pro­duk­tach (co i po co robi­my). To jak one będą powsta­wa­ły (w jaki spo­sób) będzie efek­tem wdro­że­nia np. nowe­go sys­te­mu ERP i ist­nie­ją­cych ogra­ni­czeń, reguł biznesowych.

Kluczem jest posia­da­nie spe­cy­fi­ka­cji reguł biz­ne­so­wych i mode­lu pro­ce­sów na opi­sa­nym środ­ko­wym” poziomie.

Reguły biz­ne­so­we to wewnętrz­ne (np. zarzą­dze­nia) lub zewnętrz­ne (pra­wo) ogra­ni­cze­nia. Na poprzed­nim dia­gra­mie poja­wia się rola czy­li wyko­naw­ca (tu rola dzia­łu HR – opis kom­pe­ten­cji pra­cow­ni­ków czy­li spe­cy­fi­ka­cja ról), Wykonawca posia­da nie­zbęd­ną wie­dzą i umie­jęt­no­ści, potra­fi obsłu­gi­wać maszy­ny” (tak­że opro­gra­mo­wa­nie). Tak więc defi­ni­cja mówią­ca, że pro­ces wyko­nu­je się w śro­do­wi­sku ogra­ni­czeń i wyma­ga zaso­bów tak wła­śnie wyglą­da: zaso­by to ludzie (role), ich wie­dza i narzę­dzia pra­cy, ogra­ni­cze­nia to regu­ły biz­ne­so­we i procedury.

To, opi­sa­ne tu podej­ście, to jed­no z moż­li­wych podejść. Praktyka poka­zu­je, że rzad­ko sto­so­wa­ne (wyma­ga doświad­czo­nych kon­sul­tan­tów i zna­jo­mo­ści tych metod pra­cy) ale też naj­sku­tecz­niej­sze. Modele pro­ce­sów są rela­tyw­nie pro­ste, sztu­ką takiej ana­li­zy jest wyod­ręb­nie­nie reguł biz­ne­so­wych. Co otrzy­ma­my? Biznesowy know-how – naj­cen­niej­szą rzecz w fir­mie. I po to war­to wyko­nać ana­li­zą biz­ne­so­wą: poznać i udo­ku­men­to­wać swo­ją prze­wa­gę czy­li fir­mo­we know-how.

Jeżeli wple­cie­my regu­ły biz­ne­so­we i pro­ce­du­ry w model (mapy) pro­ce­sów, to po pierw­sze powsta­ną wiel­kie i trud­ne w odbio­rze dia­gra­my a po dru­gie zatra­ci­my (ukry­je­my w gąsz­czu obiek­tów na dia­gra­mie) całą war­tość fir­my czy­li jej nagro­ma­dzo­ną wie­dzę. Po trzecie…

… pro­jek­ty zwią­za­ne z wyma­ga­nia­mi na opro­gra­mo­wa­nie to defi­nio­wa­nie wyma­gań na narzę­dzie pra­cy. Jeżeli nie będzie moż­li­we, czy nawet łatwe, wyod­ręb­nie­nie tego co musi umieć czło­wiek a co powi­nien robić pro­gram, pro­jekt cze­ka­ją kło­po­ty bo będzie to odkry­wa­ne dopie­ro w trak­cie wdro­że­nia – a to bar­dzo kosz­tow­na metoda.