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.