Strategia… w przypadku 90% małych i średnich firm w Polsce bazowałby Pan na niczym

Tym razem natchnie­niem do napi­sa­nia tego tek­stu była krót­ka dys­ku­sja w inter­ne­cie i to stwier­dze­nie jed­ne­go z jej uczestników:

„…stra­te­gia budo­wa­na przez Zarząd”. Gdyby chciał Pan na tym bazo­wać to w przy­pad­ku 90% małych i śred­nich firm w Polsce bazo­wał­by Pan na niczym. Nawet jeśli któ­raś z tych firm ma stra­te­gię (lub wyda­je się jej, że ma) brzmi ona mniej wię­cej tak: W naj­wyż­szym moż­li­wym stop­niu zaspo­ko­ić potrze­by klien­tów przy mini­mal­nych moż­li­wych kosz­tach wła­snych”. Obaj wie­my, że to nie jest żad­na stra­te­gia. Trzeba szu­kać inne­go fundamentu.
Autor tej wypo­wie­dzi ma wie­le racji, o ile tyl­ko uzna­my, że stra­te­gia to doku­ment”. Ja odpowiedziałem: 
…nie zgo­dzę się. Firma i jej wła­ści­ciel, któ­ra ist­nie­je na ryn­ku kil­ka lat ma stra­te­gię tyle, że bar­dzo intu­icyj­ną i nie uświa­do­mio­ną. Tu ana­li­za pole­ga na zro­zu­mie­niu tego, dla­cze­go dana fir­ma, mimo prze­ciw­no­ści losu, nie upa­dła i ist­nie­je np. 10 lat .… Co do zaś W naj­wyż­szym moż­li­wym stop­niu zaspo­ko­ić potrze­by klien­tów przy mini­mal­nych moż­li­wych kosz­tach wła­snych” to pro­szę poczy­tać pro­spek­ty emi­syj­ne spół­ek gieł­do­wych, jest dokład­nie to samo …  … a ten tekst nie jest stra­te­gią a raczej mani­fe­stem mak­sy­ma­li­za­cji zysków , który upra­wia więk­szość kor­po­ra­cji, dla­te­go w toku ana­li­zy war­to po pro­stu pochy­lić się nad fir­mą i zro­zu­mieć jakim cudem uda­ło się jej nie zban­kru­to­wać
Niestety kolej­ny raz muszę powie­dzieć: ana­li­za nie pole­ga na słu­cha­niu! (wyobra­ża­cie sobie lecze­nie w któ­rym dia­gno­zy sta­wia­ją pacjen­ci?). Nie raz tu pisa­łem i kolej­ny raz powtórzę: 

Analiza opar­ta na zezna­niach i życze­niach jej pra­cow­ni­ków jest bar­dzo nara­żo­na na fia­sko, gdyż subiek­tyw­na wie­dza pra­cow­ni­ków oraz ich spe­ku­la­cje, mogą nie mieć wie­le wspól­ne­go z rze­czy­wi­sto­ścią lub pożą­da­nym sta­nem (co nie musi być ich złą wolą). Analiza orga­ni­za­cji nie może więc pole­gać tyl­ko na zapi­sa­nych subiek­tyw­nych prze­ko­na­niach jej pra­cow­ni­ków. Powinna w być 100% opar­ta na fak­tach oraz na kon­tek­ście jaki two­rzy stra­te­gia budo­wa­na przez Zarząd. 

(ten mój wpis był przy­czyn­kiem do tej dyskusji). 
Cztery lata temu napisałem:

Strategia ryn­ko­wa orga­ni­za­cji to gene­ral­nie sens jej ist­nie­nia, reali­za­cja mode­lu biz­ne­so­we­go. Organizacja ma stra­te­gię wewnętrz­ną: jak jest wewnętrz­nie zor­ga­ni­zo­wa­na, by stra­te­gia ryn­ko­wa była sku­tecz­nie reali­zo­wa­na. (wię­cej tu: Proces to stra­te­gia nie tak­ty­ka | | Jarosław Żeliński IT-Consulting

Innymi sło­wy: jeże­li jakaś fir­ma ist­nie­je na ryn­ku i ma się dobrze” to zna­czy, że ma stra­te­gię. Osobną kwe­stią jest to czy jest ona dzie­łem przy­pad­ku czy świa­do­mą decyzją.

Przypomnę teraz za słownikiem:

stra­te­gia: prze­my­śla­ny plan dzia­łań w jakiejś dzie­dzi­nie (s.j.p. PWN);

Zwodnicze jest tu uży­cie słów prze­my­śla­ny plan dzia­łań” i w tych kate­go­riach fak­tycz­nie wie­le firm nie ma stra­te­gii”. Ale idź­my dalej.

Od pew­ne­go cza­su moż­na sie spo­tkać z ter­mi­nem: eko­no­mia ewo­lu­cyj­na. Jest to kon­cep­cja eko­no­micz­na roz­wi­ja­na od począt­ków XX wie­ku, któ­ra dopusz­cza moż­li­wość wyja­śnia­nia pro­ce­sów gospo­dar­czych przez ana­lo­gię z pro­ce­sem ewo­lu­cji, zacho­dzą­cym w śro­do­wi­sku przy­rod­ni­czym. Co cie­ka­we w latach 60-tych Ludwig Von Bertalanffy opu­bli­ko­wał swo­ją Ogólną Teorię Systemów bazu­ją­cą na bio­lo­gii a sto­so­wa­ną tak­że do ana­li­zy orga­ni­za­cji (cze­go jestem jed­nym z wie­lu przy­kła­dów). Pojęcie stra­te­gii jest tak­że sto­so­wa­ne w teo­rii gier (i przy­ro­dzie, do któ­rej bada­nia tak­że sto­su­je się teo­rię gier).

Czym więc jest stra­te­gia? Są to okre­ślo­ne, powta­rzal­ne dzia­ła­nia podej­mo­wa­ne w celu mak­sy­ma­li­za­cji praw­do­po­do­bień­stwa suk­ce­su (wygra­nej, prze­ży­cia)… Czy musi być ona prze­my­śla­na i zapla­no­wa­na”? Nie musi. Oczywiście świa­do­me jej two­rze­nie jest jak naj­bar­dziej prze­my­śla­ne”, jed­nak nie musi być świa­do­me. Każdy z lek­cji przy­ro­dy pamię­ta, że zwie­rzę­ta mają stra­te­gie prze­ży­cia”, mają np. stra­te­gię polo­wa­nia”. Czy ta stra­te­gie jest tu prze­my­śla­nym pla­nem”? Nie… To efekt ewo­lu­cji, pamię­cią jest instynkt czy wręcz wbu­do­wa­ne w sys­tem ner­wo­wy zacho­wa­nia (rośli­ny i owa­dy tak­że mają swo­je, róż­ne, stra­te­gie prze­ży­cia, w ewo­lu­cji jed­nak mówi się stra­te­gie mają gatun­ki a nie poszcze­gól­ne egzem­pla­rze”). Zadaniem nauki (tu bio­lo­gii) jest mię­dzy inny­mi odkry­wa­nie tych stra­te­gii czy­li nic inne­go jak zro­zu­mie­nie dla­cze­go dany gatu­nek nadal trwa.

A Ekonomia ewo­lu­cyj­na? Powstała mię­dzy inny­mi w celu wyja­śnie­nia tego, że na ryn­ku funk­cjo­nu­je ogrom­na licz­ba pod­mio­tów gospo­dar­czych i jakoś jed­ne ban­kru­tu­ją (trwa­ją) a inne nie. Przemyślane stra­te­gie” ryn­ko­we ma tak na praw­dę mały uła­mek z nich. A resz­ta? Reszta żyje bo zacho­wu­je się kon­for­mi­stycz­nie: wystar­czy naśla­do­wać tych, któ­rzy odno­szą suk­ce­sy (kon­for­mizm to naj­star­sza stra­te­gia w przy­ro­dzie, wbu­do­wa­na w nasze geny). Inna stra­te­gią jest powta­rza­nie tych dzia­łań, któ­re w prze­szło­ści przy­nio­sły suk­ce­sy”. Patrząc więc na stra­te­gię: W naj­wyż­szym moż­li­wym stop­niu zaspo­ko­ić potrze­by klien­tów przy mini­mal­nych moż­li­wych kosz­tach wła­snych”, jest to kla­sycz­ny kon­for­mizm pole­ga­ją­cy na intu­icyj­nym zacho­wa­niu przed­się­bior­ców. I tu nie­ste­ty pierw­sze roz­cza­ro­wa­nie: nie jest praw­dą, że Ci któ­rzy gło­szą taką stra­te­gię fak­tycz­nie zawsze taką mają. Mało któ­ry przed­się­bior­ca zaspo­ka­ja wszel­kie potrze­by klien­tów naj­niż­szym kosz­tem. Mało kto kupu­je naj­tań­sze surow­ce czy zatrud­nia do odpo­wie­dzial­nych zadań naj­tań­szych pra­cow­ni­ków. Jednak fak­tycz­nie ta stra­te­gia” ma się dobrze w umy­słach więk­szo­ści przed­się­bior­ców. To – domi­nu­ją­ce – podej­ście, to podej­ście induk­cyj­ne: doszu­ki­wa­nie sie reguł w powtarzalności. 

Tak więc każ­da fir­ma ma jakąś stra­te­gie”, nie koniecz­nie pro­stą” jak ta powy­żej. Ale sku­tecz­niej­sza w nauce jest deduk­cja. Dlatego… 

…sys­te­mo­we bada­nie orga­ni­za­cji ma w sobie wie­le z odkry­wa­nia w nauce: nale­ży poznać pod­sta­wo­we fak­ty, zro­zu­mieć mecha­nizm funk­cjo­no­wa­nia orga­ni­za­cji, udo­ku­men­to­wać go i wyka­zać jego popraw­ność. Opracowanie mode­lu orga­ni­za­cji wyma­ga pozna­nia ogra­ni­czeń i reguł oraz fak­tów. Należy spraw­dzić, czy poja­wia­ją się fak­ty nie­zgod­ne z regu­ła­mi, zro­zu­mieć tę sytu­ację i wska­zać przy­czy­ny. Kolejny krok to reko­men­da­cje: co zro­bić by dopro­wa­dzić do sta­nu pożą­da­ne­go. (Źródło: Jarosław Żeliński – Analizy i Badania Systemowe orga­ni­za­cji). 

Analiza i reko­men­do­wa­nie zmian to bar­dzo odpo­wie­dzial­na rola. Złe reko­men­da­cje mogą wyrzą­dzić bar­dzo wie­le szkód. Rekomendacjami nie raz są wyma­ga­nia na opro­gra­mo­wa­nie, a raczej (o czym nie raz pisa­łem) pro­jekt tego, jaką logi­kę powin­no reali­zo­wać opro­gra­mo­wa­nie by było przy­dat­ne i … wspie­ra­ło stra­te­gię rynkową. 

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

Piraci drogowi i limit prędkości – droga jako system

Najpierw kil­ka faktów:

(źr. pred­kosc) oraz pew­na statystyka:

infografika_fotoradary_predkosc_2

Pisałem już nie raz o heu­ry­sty­kach jaki­mi posłu­gu­je się mózg czło­wie­ka i o tym, że ich celem jest rato­wa­nie życia poprzez zwol­nie­nie mózgu czło­wie­ka z myśle­nia (gdy nie ma na to cza­su). Przytoczę jed­ną z definicji:

Heurystyki wyda­wa­nia sądów ? uprosz­czo­ne regu­ły wnio­sko­wa­nia. Ludzie auto­ma­tycz­nie i bez­wied­nie posłu­gu­ją się nimi po to, aby wyda­wać szyb­kie sądy. Stosowanie heu­ry­styk czę­sto pro­wa­dzi do wystą­pie­nia błę­dów poznaw­czych. (wię­cej: Heurystyki wyda­wa­nia sądów ? Wikipedia, wol­na ency­klo­pe­dia).

Problem w tym, by abso­lut­nie nie uży­wać heu­ry­styk (tego trze­ba się nauczyć!) w ana­li­zie (tu trze­ba aku­rat dużo myśleć). Jak one wypa­cza­ją osą­dy? Posłużę się przy­kła­dem foto­ra­da­rów, a kon­kret­nie ogra­ni­czeń pręd­ko­ści i osą­dów o ich zasadności:

Piractwo to cham­skie inte­rak­cje z inny­mi użyt­kow­ni­ka­mi dro­gi, a limit pręd­ko­ści moż­na prze­kro­czyć będąc abso­lut­nie same­mu na dro­dze, niko­mu w żaden spo­sób nie szko­dząc.  (cytat z komen­ta­rza pod arty­ku­łem: Piraci dro­go­wi nie oszu­ka­ją nowe­go pręd­ko­ścio­mie­rza z WAT).

Większość ludzi wycią­ga taki oto wnio­sek: sko­ro niko­go nie widzę przed sobą to zna­czy, że w niko­go nie wja­dę (to jest heu­ry­sty­ka). I jest to pra­wie” praw­da czy­li czę­sto ale nie zawsze.

wlaczanie sie do ruchu

Powyższy dia­gram” to pro­sty rysu­nek obra­zu­ją­cy czę­sto spo­ty­ka­ną sytu­ację: dro­ga, w poło­wie łuku skrzy­żo­wa­nie (mia­łem kie­dyś stłucz­kę wła­śnie jako włą­cza­ją­cy się do ruchu, ten co we mnie wje­chał też uwa­żał, że pusta dro­ga ozna­cza moż­na jechać szyb­ko”, mimo że było ogra­ni­cze­nie jak wyżej). 

Przed łukiem (dia­gram) jest ogra­ni­cze­nie do 40km/h. Kierowca pojaz­du włą­cza­ją­ce­go się do ruchu (dro­ga idą­ca od dołu na rysun­ku) musi mieć czas na rusze­nie z miej­sca, wje­cha­nie na wła­ści­wy pas i nabra­nie żąda­nej pręd­ko­ści. Zrobi to, jeże­li zoba­czy, że nikt nie nad­jeż­dża i zdą­ży się włą­czyć do ruchu. Jego widocz­ność to odci­nek ozna­czo­ny strzał­ka­mi (linia pod zna­kiem), aby zdą­żył, nad­jeż­dża­ją­ce pojaz­dy nie mogą jechać szyb­kiej niż 40km/h (wyli­czo­ne dla tego odcin­ka i jego dłu­go­ści). To pra­wa fizy­ki, są takie same w połu­dnie i o północy.

Poniżej, dla zilu­stro­wa­nia, bada­nia dro­gi hamowania:

predkosc jazdy

Tak więc, mam nadzie­ję, że widać, że znak ogra­ni­cze­nia do 40km/h ma tu sens, bez zmniej­sze­nie pręd­ko­ści przez pojaz­dy nad­jeż­dża­ją­ce głów­na dro­gą, nikt nie włą­czy się bez­piecz­nie do ruchu z tej pod­po­rząd­ko­wa­nej drogi. 

Tu widać, że heu­ry­sty­ka będąc abso­lut­nie same­mu na dro­dze, niko­mu w żaden spo­sób nie szko­dzę” nie ma żad­ne­go sen­su. Powyższy przy­kład to dość try­wial­na sytu­acja i mam nadzie­je poka­zu­ją­ca, że sto­pień pusto­ści dro­gi” nie ma tu żad­ne­go zna­cze­nia, to ogra­ni­cze­nie pręd­ko­ści ma głę­bo­ki sens nawet w środ­ku nocy. Nie ma żad­ne­go zna­cze­nia jakie jest praw­do­po­do­bień­stwo wyje­cha­nia na dro­gę kogoś z tej bocz­nej dro­gi, bo dla oso­by jadą­cej tą głów­ną dro­gą (tu z lewej stro­ny), to jest rzut mone­tą (nie zna histo­rii na tym odcin­ku więc nie wie nic). Poniżej obszer­ne opra­co­wa­nie na ten temat. 

https://it-consulting.pl//wp-content/uploads/2013/06/zasady_uspokajania_ruchu-EKKOM.pdf

A teraz system, reguły biznesowe i kryteria decyzji

Nasz sys­te­mem to jest to, co zna­my z Kodeksu dro­go­we­go: uczest­ni­cy ruchu i ich oto­cze­nie. Model tego co zna każ­dy kie­row­ca, wyglą­da np. tak:

Ruch drogowy

Przypuszczam, że wie­lu z czy­tel­ni­ków jest zasko­czo­nych jego pro­sto­tą 🙂 (do utwo­rze­nia mode­lu tego sys­tem uży­to dia­gra­mu klas nota­cji UML, jest to obiek­to­wy model ruchu dro­go­we­go). Złożoność nie tkwi w tym co na dro­dze: mamy jedy­nie uczest­ni­ków ruchu i śro­do­wi­sko, w któ­rym ten ruch się odby­wa. Czy uczest­ni­cy są jakość ze sobą sko­ja­rze­ni? Nie, dla­te­go dia­gram nie zawie­ra nic ponad to co widać :). Tu mała uwa­ga: inni uczest­ni­cy ruchu dla sie­bie nawza­jem to ele­ment śro­do­wi­ska jakie postrze­ga każ­dy kon­kret­ny uczest­nik, nie wyróż­nia­my tu żad­nych aso­cja­cji” pomię­dzy wie­lo­ma uczest­ni­ka­mi ruchu bo ich nie ma. Uczestników ruchu może być cała masa, ale każ­dy z nich żyje wła­snym życiem” czy­li jedzie i reagu­je na otoczenie.

Gdzie tkwi zło­żo­ność? W Operacjach. Mamy tu meto­dę ope­ra­cji reakcjaNaStanŚrodowiska, oto opis jej metody:

reakcjaNaStanSrodowiska

Tak więc cała wie­dza” to wła­śnie powyż­sza tabli­ca (model został uprosz­czo­ny, cały Kodeks był­by tu nie­co więk­szy” ale obję­to­ścio­wo mniej­szy niż ory­gi­nal­ny Kodeks ;)).

Typowa heu­ry­sty­ka to Reguła 1. i 2. Gdzie pro­blem? Problem w tym, że Działanie A2. u więk­szo­ści kie­row­ców nie ozna­cza pręd­ko­ści dopusz­czal­nej zgod­nie z Kodeksem Drogowym (Warunek C2) na danym odcin­ku dro­gi, a pręd­kość mak­sy­mal­na dopusz­czal­na” z ich subiek­tyw­ne­go punk­tu widze­nia. Problem w tym, że ten punkt widze­nia (ludz­ka heu­ry­sty­ka) ma wady opi­sa­ne powyżej.

Na zakończenie

Artykuł ten napi­sa­łem z dwóch powo­dów. Pierwszy to odpo­wiedź na cyto­wa­ną tezę, pocho­dzą­cą z komen­ta­rzy pod arty­ku­łem o rada­rach lase­ro­wych rodem z mojej Alma Mater (WAT). Sugeruję kie­row­com nie uży­wać na dro­dze pro­stych heu­ry­styk tyl­ko prze­strze­gać zna­ków dro­go­wych, z dwoj­ga złe­go lepiej zwol­nić na źle ozna­ko­wa­nej dro­dze niż kogoś zabić lub okaleczyć.

Drugi powód to prze­strzec przed pro­wa­dze­niem ana­liz wyma­gań meto­dą wywia­dów wie­rząc, że sko­ro klient mówi to wie i tak chce”, bo nie­ste­ty w więk­szo­ści przy­pad­ków jest to nie­praw­da (żąda­nie zama­wia­ją­ce­go wobec roz­wią­za­nia to jego wizja roz­wią­za­nia pro­ble­mu, nale­ży zama­wia­ją­ce­go pytać nie co” chce, a po co” to chce). Niestety więk­szość zna­nych mi ana­li­ty­ków w fir­mach IT i nie tyl­ko, to ludzie posłu­gu­ją­cy się w swej pra­cy tym czym nie powin­ni: heu­ry­sty­ka­mi, któ­rych jed­nak tu nale­ży się wyzbyć (po raz kolej­ny przy­po­mnę: dobry ana­li­tyk to nie dyk­ta­fon czy sekre­tar­ka od noto­wa­nia tego co Klient mówi).

____

2018 rok…

O wpły­wie pręd­ko­ści na licz­bę wypad­ków dro­go­wych oraz na licz­bę ofiar tych wypad­ków napi­sa­no bar­dzo dużo, prze­pro­wa­dzo­no set­ki badań. W bez­pie­czeń­stwie ruchu dro­go­we­go na pod­sta­wie wie­lo­let­nich badań okre­ślo­no model zależ­no­ści mię­dzy pręd­ko­ścią a licz­bą wypad­ków dro­go­wych. Według tzw. power model, opra­co­wa­ne­go jesz­cze w XX w. przez szwedz­kie­go naukow­ca Gorana Nilssona, zwią­zek mię­dzy pręd­ko­ścią a wskaź­ni­kiem wypad­ków dro­go­wych nie ma cha­rak­te­ru linio­we­go, ale nara­sta­ją­cy wykład­ni­czo. Warto rów­nież wspo­mnieć, że w ostat­nim rapor­cie IRTAD zapre­zen­to­wa­no sku­mu­lo­wa­ne wyni­ki z wie­lu badań, z któ­rych wyni­ka, że obni­że­nie pręd­ko­ści pojaz­dów do 45 km/h na dro­gach miej­skich, do 75 km/h na dro­gach poza­miej­skich i do 115 km/h na auto­stra­dach zmniej­szy licz­bę wypad­ków z ofia­ra­mi śmier­tel­ny­mi o 28 proc. Podsumowując: maso­we prze­strze­ga­nie limi­tów pręd­ko­ści mia­ło­by bar­dzo pozy­tyw­ny wpływ na reduk­cję licz­by wypad­ków dro­go­wych i ich ofiar. (źr: Prędkość. Czy to jedy­na przy­czy­na wypad­ków? – Motoryzacja w INTERIA​.PL)

Modelowanie biznesowe

Tym razem o pew­nej książ­ce: [[Business mode­ling David M. Bridgeland, Ron Zahavi]]. Najpierw cytat:

A busi­ness model is a sim­ple repre­sen­ta­tion of the com­plex reali­ty of a busi­ness. The pri­ma­ry pur­po­se of a busi­ness model is to com­mu­ni­ca­te some­thing abo­ut the busi­ness to other people, to employ­ees, custo­mers, part­ners, or sup­pliers. A busi­ness model can be ana­ly­zed, for exam­ple to under­stand the impacts of a chan­ge. A model can be simu­la­ted, sho­wing how things chan­ge over time, and sup­por­ting expe­ri­men­ta­tion with dif­fe­rent alter­na­ti­ve futu­re chan­ges. And some models can be exe­cu­ted by softwa­re appli­ca­tions, allo­wing models cre­ated by busi­ness mode­lers to sub­sti­tu­te for code cre­ated by softwa­re engi­ne­ers. (Business mode­ling ? Bridgeland and Zahavi on Business Modeling).

Ta książ­ka spa­dła mi z nie­ba. Własnie tak. W pra­cy nad dok­to­ra­tem utrwa­la mi się obraz, jaki pre­zen­tu­je od kil­ku lat na moich autor­skich szko­le­niach: model orga­ni­za­cji to nie tyl­ko model pro­ce­su czy danych. Model orga­ni­za­cji, czy­li to co ją two­rzy i decy­du­je o tym jak reagu­je na rynek, to kom­pleks skła­da­ją­cy się z ludzi, reguł jakim pod­le­ga­ją w pra­cy oraz tego czym obra­ca­ją” w swo­jej pra­cy czy­li infor­ma­cja: doku­men­ty i ich treść, zarów­no ta for­mal­na jak i nie­for­mal­na czy­li wyko­rzy­sty­wa­na a nie utrwa­la­na. Mamy więc struk­tu­rę orga­ni­za­cyj­ną, pra­wo i wewnętrz­ne zarzą­dze­nia i ludzi z ich umie­jęt­no­ścia­mi i obowiązkami.

A gdzie procesy? Hm… a ile firm ma je w postaci udokumentowanej?

Często jestem pyta­ny o to, po co mode­lo­wać pro­ce­sy biz­ne­so­we. Na stro­nach wie­lu firm dorad­czych i wdro­że­nio­wych moż­na zna­leźć w tre­ści ofer­ty, mode­lo­wa­nie pro­ce­sów biz­ne­so­wych. Niemalże żad­na nie zawie­ra infor­ma­cji: po co.

Nie raz tu pisa­łem, że woda pły­nie z góry na dół zgod­nie z ukształ­to­wa­niem tere­nu a nie odwrot­nie. Obserwując fir­mę z boku, widać, że pra­cu­je i to nie raz bar­dzo spraw­nie, więc po co te modele.

Model pro­ce­su biz­ne­so­we­go nie jest nam do nicze­go potrzeb­ny do cza­su, gdy nie chce­my w nie­go ingerować.

Tu zno­wu pora na jeden z moich ulu­bio­nych cytatów:

Modelowanie przed­się­bior­stwa stwa­rza dobrą moż­li­wość ana­li­zy oraz kształ­to­wa­nia pro­ce­sów dzia­ła­nia. Dzięki temu moż­na unik­nąć pro­ble­mów przy wpro­wa­dza­niu zmian. (Hubert H. Zimmermann).

To kwin­te­sen­cja celu mode­lo­wa­nia biz­ne­so­we­go: zanim zacznie­my inge­ro­wać w żywy orga­nizm, jakim jest każ­da orga­ni­za­cja, war­to opra­co­wać jego model i na nim ćwi­czyć” pla­no­wa­ne zmia­ny. Dlaczego? Bo ryzy­ko, że coś pój­dzie nie tak” jest bar­dzo duże.

Tu dopie­ro poja­wia się pro­blem: czym jest model orga­ni­za­cji? Jaki musi być, by fak­tycz­nie model poka­zał jak w przy­szło­ści zare­agu­je orga­ni­za­cja na kon­kret­ne, pla­no­wa­ne zmiany.

Nauka mówi dość jasno: aby prze­wi­dy­wać reak­cje bada­ne­go przed­mio­tu nale­ży zro­zu­mieć jak funk­cjo­nu­je i opra­co­wać jego model. Po dro­dze nale­ży udo­wod­nić, praw­dzi­wość modelu.

Model orga­ni­za­cji to: opis moty­wa­cji jej dzia­ła­nia, opis ludzi, jacy reali­zu­ją wewnętrz­ne zada­nia, opis reguł jakie regu­lu­ją ich zacho­wa­nia­mi. Całość (model) powin­na być na tyle upo­rząd­ko­wa­na, by model był w 100% jed­no­znacz­ny, czy­li klu­czo­we poję­cia w nim uży­te powin­ny być zebra­ne w jeden wewnętrz­ny, spój­ny biz­ne­so­wy słow­nik tej orga­ni­za­cji. To wszyst­ko dopie­ro pozwo­li stwo­rzyć model pro­ce­sów biz­ne­so­wych, czy­li wewnętrz­ne sce­na­riu­sze zachowania.

Samo utwo­rze­nie map (bo nie mode­li) w posta­ci dia­gra­mów pro­ce­sów z pomo­cą wywia­dów, sesji warsz­ta­to­wych i obser­wa­cji, da pro­dukt podob­ny do zdję­cia lot­ni­cze­go rze­ki: wie­my któ­rę­dy pły­nie, ale kom­plet­nie nie rozu­mie­my dla­cze­go aku­rat tak. Mamy jedy­nie udo­ku­men­to­wa­ny stan obecny.

Ingerencja w ten stan rze­czy, bez zro­zu­mie­nia reguł rzą­dzą­cych tym jak i któ­rę­dy pły­nie woda, koń­czy się nie raz kata­stro­fa­mi jakie zna­my z donie­sień o powo­dziach i zala­niach ostat­nich lat. Bez pozna­nia zasad rzą­dzą­cych zacho­wa­niem się orga­ni­za­cji moż­na nie unik­nąć pro­ble­mów przy wpro­wa­dza­niu zmian”.

Każda reor­ga­ni­za­cja, a w szcze­gól­no­ści jest nią wdra­ża­nie nowe­go opro­gra­mo­wa­nia, jest taką zmia­ną. Ta książ­ka jest o mode­lo­wa­niu orga­ni­za­cji. Model taki ma czte­ry zasad­ni­cze, powią­za­ne z sobą obsza­ry, z kórych żaden nie jest samowystarczalny:

Metamodel projektu

Mamy na nim: słow­nik pojęć (Glossary), model struk­tu­ry orga­ni­za­cyj­nej, regu­ły biz­ne­so­we (spe­cy­fi­ka­cja) oraz model pro­ce­sów biz­ne­so­wych korzy­sta­ją­cy z trzech poprzed­nich. Całość sta­no­wi dopie­ro kom­plet­ny model organizacji.

Procesy biznesowe lepiej z regułami biznesowymi i zasobami

Kolejne szko­le­nia za mną, pro­jek­ty tak­że. Od cza­su do cza­su audyt (lub ciche opi­nie) cudzych pro­jek­tów. Stale widzę dwa poważ­ne pro­ble­my w wie­lu tych dokumentach:

  1. utra­ta pano­wa­nia nad złożonością,
  2. algo­ryt­mi­za­cja.

W 2005 roku napi­sa­łem na zakoń­cze­nie arty­ku­łu dot. modelowania:

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ła­ga­nu. ( Modelowanie biz­ne­so­we czy­li pil­no­wa­nie hochsz­ta­ple­rów).

od tam­tej pory nie­ste­ty w zasa­dzie nic sie nie zmie­ni­ło na rynku.

Pierwszy pro­blem obja­wia się lawi­no­wo rosną­cą licz­bą deta­li na dia­gra­mach i licz­bą dia­gra­mów. Są nawet tacy, któ­rzy uwa­ża­ją, że popraw­ny model pro­ce­sów biz­ne­so­wych całej fir­my, to set­ki dia­gra­mów. Bzdura. Dlaczego?

Czym jest model?

Model [łac. modu­lus ?mia­ra?, ?wzór?], meto­dol. poję­cie ozna­cza­ją­ce zarów­no teo­re­tycz­ny, jak i fizycz­ny obiekt, któ­re­go ana­li­za lub obser­wa­cja umoż­li­wia pozna­wa­nie cech inne­go bada­ne­go (mode­lo­wa­ne­go) zja­wi­ska, pro­ce­su lub obiek­tu. (źr. słow­nik j.p. PWN).

Tak więc cechą dobre­go mode­lu jest moż­li­wość jego testo­wa­nia. Dobry model to uprosz­cze­nie rze­czy­wi­sto­ści odwzo­ro­wu­ją­ce jej ogra­ni­cze­nia w wybra­nym aspek­cie. Jeżeli więc testu­je­my np. współ­czyn­nik opo­ru powie­trza pro­jek­to­wa­ne­go samo­cho­du, wyma­ga­ny (i wystar­cza­ją­cy) model, to repre­zen­ta­cja kształ­tu karo­se­rii a nie kom­plet­na minia­tu­ra z sil­ni­kiem i siedzeniami.

Analizując orga­ni­za­cję, two­rzy­my model w celu… i tu powin­na paść nazwa kon­kret­ne­go aspek­tu, per­spek­ty­wy, któ­rą chce­my badać. Analiza orga­ni­za­cji to ele­ment np.:

  1. pla­nu budo­wy nowe­go sys­te­mu zarzą­dza­nia kosz­ta­mi (np. [[meto­da ABC t.j. zarzą­dza­nia kosz­ta­mi działań]]),
  2. pla­nu wdro­że­nia sys­te­mu Business Inteligence ([[model biz­ne­so­wy jako narzę­dzie pro­jek­to­wa­nia wie­lo­wy­mia­ro­we­go mode­lu hur­tow­ni danych]]),
  3. [[opra­co­wa­nia wyma­gań na opro­gra­mo­wa­nie wspo­ma­ga­ją­ce zarzą­dza­nie]] (ma dwa głów­ne aspek­ty: [[wybór goto­we­go opro­gra­mo­wa­nie]] oraz [[spe­cy­fi­ka­cja wyma­gań na opro­gra­mo­wa­nie dedykowane]]).

Podstawową decy­zją jaką nale­ży pod­jąć jest to, cze­go nie ujmo­wać na tych mode­lach, a każ­dy powy­żej ma inny kon­tekst. Każdy pro­jekt, zawie­ra­ją­cy etap mode­lo­wa­nia (mode­lo­wa­nie nie jest celem samym w sobie!) war­to roz­po­czy­nać od audy­tu. Jego celem jest spraw­dze­nie jaką wie­dzę o sobie samej posia­da orga­ni­za­cja czy­li ile z tego, co się dzie­je w orga­ni­za­cji, jest udo­ku­men­to­wa­ne. Nie musi to być wszyst­ko. Dobrze zarzą­dza­na orga­ni­za­cja panu­je nad swo­ją cią­gło­ścią dzia­ła­nia”, to jest rozu­mie jak dzia­ła i nie posia­da punk­tu, któ­ry jako jeden decy­du­je o być albo nie być fir­my. Typowym przy­kła­dem takie­go pun­ku jest jeden czło­wiek, sku­pia­ją­cy na sobie klu­czo­we dla funk­cjo­no­wa­nia fir­my, kom­pe­ten­cje (np. szef pro­duk­cji). Z natu­ry rze­czy ma to miej­sce w każ­dej małej fir­mie, jed­nak im więk­sza fir­ma tym ryzy­ko jej funk­cjo­no­wa­nia powin­no być mniej­sze. Podstawowym ele­men­tem zro­zu­mie­nia mecha­ni­zmu funk­cjo­no­wa­nia orga­ni­za­cji są regu­ły biz­ne­so­we i zdol­no­ści (wie­dza) posia­da­nych zaso­bów. Opisałem to tak­że w arty­ku­le Jak wyłu­skać isto­tę rze­czy.

Złożoność i algo­ryt­mi­za­cja. Typowy anty-przy­kład: pro­ces zawar­cia umo­wy, w któ­rym udział bie­rze mię­dzy inny­mi praw­nik oraz Zarząd. Celem jest (mię­dzy inny­mi) opi­nia praw­na o tre­ści umo­wy, uzgod­nie­nie jej tre­ści, na koń­cu pozy­ska­nie wła­ści­wych pod­pi­sów (np. wyma­ga­ne dwa a mamy pię­ciu człon­ków zarzą­du). W tym miej­scu poja­wia­ją się zawi­łe dia­gra­my opi­su­ją­ce jaki­mi to ścież­ka­mi prze­miesz­cza się doku­ment (nie ma uwag – OK, są uwa­gi, ode­ślij do praw­ni­ka, uzu­peł­nij, prze­ślij zno­wu do Zarządu, …, następ­nie pozy­skaj pod­pis Prezesa, jeże­li pre­zes jest nie­do­stęp­ny, to…). Nawet nie mam ambi­cji nary­so­wa­nia tego potwo­ra, jakim był­by taki dia­gram. Jak to mogło by wyglą­dać? Po pierw­sze potrzeb­na jest spe­cy­fi­ka­cja sta­no­wisk (ról w pro­ce­sach) i kom­pe­ten­cji tych ludzi. Po dru­gie lista reguł (pra­wo, zarzą­dza­nia wewnętrz­ne, pro­ce­du­ry itp.). W efek­cie powyż­szy pro­ces to pro­sty prze­pływ: kon­sul­ta­cja tre­ści umo­wy (praw­nik ma wie­dzę praw­ni­czą, w ramach swo­ich upraw­nień ma pra­wo do spo­tkań z Zarządem np. w celu skon­sul­to­wa­nia tre­ści umo­wy. Po uzgod­nie­niu tre­ści umo­wy, np. Asystent Zarządu, który(a) zna pro­ce­du­ry i pra­wo (kolej­na rola i kom­pe­ten­cje) zdo­by­wa wła­ści­we pod­pi­sy na umo­wie. Koniec! Gdzie szcze­gó­ły? Są! Proces jest, zakre­sy kom­pe­ten­cji są, pra­wo i zarzą­dze­nia są. Tą meto­dą, wte­dy jest to audyt, moż­na spraw­dzić spój­ność zakre­sów obo­wiąz­ków i zarzą­dzeń wewnętrz­nych z pra­wem oraz stra­te­gią firmy.

W wie­lu fir­mach sys­tem zarzą­dza­nia jest tak nie­spój­ny, że jedy­nym spo­so­bem funk­cjo­no­wa­nia tych firm, jest łama­nie zasad przez jej pra­cow­ni­ków. Niestety pierw­sza wpad­ka czę­sto powo­du­je zała­ma­nie się całe­go sys­te­mu (a nie raz i fir­my). Wiele Zarządów firm nie zda­je sobie nawet spra­wy z tego, jak duże jest ryzy­ko cią­gło­ści funk­cjo­no­wa­nia ich firm. 

Tak więc model pro­ce­su to nie algo­rytm dzia­ła­nia fir­my, wyka­za­no nie raz, że algo­ryt­mi­za­cja pra­cy ludzi jest nie­ce­lo­wa (wte­dy sto­su­je­my roboty).

Znaczna część tego co robią ludzie to efekt ich kom­pe­ten­cji, wie­dzy i doświad­cze­nia, a nie dyk­to­wa­nia im jak mają wyko­ny­wać swo­ja pracę.

Jeżeli wybie­rze­my dro­gę mode­lo­wa­nia tego wszyst­kie­go dia­gra­ma­mi, to ilość tych dia­gra­mów szyb­ko prze­kro­czy gra­ni­cę sen­sy całe­go pro­jek­tu: nie będą czy­ta­ne. Ich war­tość będzie żadna.

W pro­ce­sie dobrze przy­go­to­wa­nej ana­li­zy (jakiej­kol­wiek) mode­le two­rzy się by je badać, a nie tyl­ko po to by powsta­ły za pie­nią­dze spon­so­ra projektu.

Na koniec cie­ka­wy arty­kuł, opi­su­ją­cy jak sto­so­wać regu­ły biz­ne­so­we w mode­lo­wa­niu procesów.

In cre­ating a via­ble busi­ness solu­tion, you need both a busi­ness pro­cess model and busi­ness rules ? not just one or the other. The trick is not to get them entan­gled, to rema­in cle­ar abo­ut which is which. The good news is that by sepa­ra­ting them you can sim­pli­fy your busi­ness pro­cess models dra­ma­ti­cal­ly ? often by an order of magni­tu­de or more. This discus­sion expla­ins how. (za Business Processes: Better with Business Rules).

P.S.

Widzę pew­ną kore­la­cję: naj­czę­ściej obec­ni lub daw­ni pro­gra­mi­ści robią naj­gor­sze mode­le orga­ni­za­cji: mają ten­den­cje to tech­no­kra­tycz­nej algo­ryt­mi­za­cji opi­su pra­cy ludzi, igno­ru­ją czyn­nik ludz­ki w mode­lach, patrzą na pro­ce­sy w fir­mach przez pry­zmat ogra­ni­czeń roz­wią­zań i tech­no­lo­gii, któ­re ofe­ru­ją ich pra­co­daw­cy. Podobne ten­den­cje mają tak­że ci, któ­rzy pod­cho­dzą do two­rze­nia mode­li pro­ce­sów jak do spi­sa­nia meto­da­mi obraz­ko­wy­mi tego co mówią pra­cow­ni­cy pod­czas wywia­dów”. To tak­że bar­dzo złe mode­le, zary­zy­ku­ję tezę, że gor­sze od tych z rąk programistów.

Należy też nabrać poko­ry: więk­szość orga­ni­za­cji spraw­nie funk­cjo­nu­je nie mając żad­nych mode­li pro­ce­sów, więc teza, że ich brak szko­dzi jest nie do obro­ny. Po co więc te mode­le? Żeby zro­zu­mieć dla­cze­go tak jest i co się sta­nie, gdy zechce­my wpro­wa­dzać zmiany.