Jednym z zabój­ców pro­jek­tów zwią­za­nych z mode­lo­wa­niem pro­ce­sów biz­ne­so­wych, jest ich nad­mier­na szcze­gó­ło­wość. Ktoś może powie­dzieć, że ​„o te szcze­gó­ły wła­śnie cho­dzi”. Jeżeli tak mówi, to nie rozu­mie czym jest model pro­ce­sów biz­ne­so­wych, bo taki model to nie miej­sce na takie szcze­gó­ły w ana­li­zie. Jeżeli jed­nak prze­for­so­wa­na zosta­nie w pro­jek­cie teza mówią­ca, że ​„mode­le pro­ce­sów mają zawie­rać wszyst­kie szcze­gó­ły”, otrzy­mu­je­my ster­ty nie­czy­tel­nych dia­gra­mów, nie pod­da­ją­cych się jakiej­kol­wiek dal­szej obróbce.

W arty­ku­le Poziomy mode­lo­wa­nia… opi­sa­łem hie­rar­chię szcze­gó­ło­wo­ści mode­li pro­ce­sów. Tu sku­pi­łem się na wal­ce z nad­mia­rem szcze­gó­łów na nich.

Diabeł tkwi w szczegółach

To czę­sty argu­ment za tym, by te szcze­gó­ły umiesz­czać na dia­gra­mach. Czym są te szczegóły?

Pojęcie pro­ce­du­ry. W popu­lar­nym pol­skim WIKI nie ma nie­ste­ty roz­wi­nię­tej defi­ni­cji poję­cia pro­ce­du­ra (stan na 24.09.2013):

Pozostaje mi więc przy­jąć nie­co ści­ślej­szą niż powyż­sza, defi­ni­cję ze sł. j. pol­skie­go PWN jako bazę do dal­szych dywa­ga­cji (waż­na uwa­ga: słow­nik pojęć w doku­men­ta­cji pro­jek­to­wej pisa­nej po pol­sku, nie może być nie­zgod­ny ze słow­ni­kiem języ­ka pol­skie­go, może być co naj­wy­żej uszczegółowieniem):

Procedura: 1. okre­ślo­ne regu­ły postę­po­wa­nia w jakiejś spra­wie, zwy­kle o cha­rak­te­rze urzę­do­wym lub praw­nym, 2. w języ­kach pro­gra­mo­wa­nia: wydzie­lo­ny frag­ment algorytmu.

Ważne jest tu to, że pro­ce­du­ra to gene­ral­nie okre­ślo­ne regu­ły postę­po­wa­nia (przy­po­mi­nam, że regu­łą postę­po­wa­nia jest tak­że lista czyn­no­ści i sama kolej­ność ich wyko­na­nia). Wskazówką by tę defi­ni­cję dopre­cy­zo­wać jest tak­że nawią­za­nie (2. zna­cze­nie) to pro­gra­mo­wa­nia: wydzie­lo­ny frag­ment algo­ryt­mu. Powyższe pozwa­la uznać, że kon­kret­na pro­ce­du­ra to postę­po­wa­nie w jed­nej spra­wie (jed­nym celu). Czy postę­po­wa­nie w spra­wie (albo wydzie­lo­ny frag­ment algo­ryt­mu) da ocze­ki­wa­ny rezul­tat jeże­li je prze­rwie­my? Nie. Tak więc defi­ni­cja pro­ce­du­ry, któ­ra się tu sama wręcz narzu­ca (i taką przyj­mu­ję w pro­jek­tach) brzmi:

pro­ce­du­ra – ciąg czyn­no­ści (kro­ków postę­po­wa­nia), któ­re­go prze­rwa­nie pro­wa­dzi do utra­ty celo­wo­ści wyko­ny­wa­nia tych czynności

Popatrzmy też jak pro­ce­du­rę defi­niu­ję nor­ma tech­no­lo­gicz­na ISO9000:

pro­ce­du­ra: okre­ślo­ny spo­sób reali­za­cji dzia­łań lub procesów

Model procesów biznesowych

Czy przy­pad­kiem nie dzie­lę wło­sa na czwo­ro? Moim zda­niem nie. Dzięki powyż­sze­mu moż­li­we jest zapa­no­wa­nie nad szcze­gó­ło­wo­ścią pro­jek­tu ana­li­zy pro­ce­sów biz­ne­so­wych. Mając defi­ni­cję pojęć pro­ces biz­ne­so­wy, pod­pro­ces (dekom­po­zy­cja pro­ce­su) oraz pro­ce­du­ra mam dosko­na­łe narzę­dzie do kwa­li­fi­ko­wa­nia ele­men­tów wie­dzy o tym ​„co się dzie­je” jako pro­ce­sy, pod-pro­ce­sy czy wła­snie procedury.

Zwróćmy uwa­gę, pro­ces biz­ne­so­wy naj­wyż­sze­go pozio­mu to tak zwa­ny pro­ces end-to-end. Jego dekom­po­zy­cja (kolej­ne dekom­po­zy­cje) dopro­wa­dzą nas do ele­men­tar­nych (ato­mo­wych) pro­ce­sów biz­ne­so­wych. Atomowy pro­ces biz­ne­so­wy jest doku­men­to­wa­ny (to jak prze­bie­ga) jako pro­ce­du­ra. Procedury, z regu­ły, nie są już dia­gra­ma­mi a wypunk­to­wa­ny­mi lista­mi, ​„recep­ta­mi” dzia­ła­nia. Wszystkie szcze­gó­ły wyko­ny­wa­nych czyn­no­ści są zawar­te, nie na dia­gra­mie pro­ce­su, a wła­śnie w tre­ści pro­ce­du­ry (tu pole­cam arty­kuł: Co to jest pro­ces biz­ne­so­wy).

Mając więc powyż­szą defi­ni­cję pro­ce­du­ry, łatwiej nam teraz jest zakwa­li­fi­ko­wać infor­ma­cję to tym, że nale­ży zeska­no­wać przy­cho­dzą­cy doku­ment, jako ele­ment (krok) pro­ce­du­ry a nie jako pro­ces biz­ne­so­wy. Samo ska­no­wa­nie, bez nastę­pu­ją­cych po nim dal­szych kro­ków postę­po­wa­nia z doku­men­tem, do nicze­go nie słu­ży, więc nie może być (w myśl powyż­szych defi­ni­cji) pro­ce­sem biz­ne­so­wym. Jest zapi­sem w tre­ści pro­ce­du­ry opi­su­ją­cej spo­sób reali­za­cji pro­ce­su przy­ję­cia dokumentu.

Bez tej for­ma­li­za­cji (ści­słe sto­so­wa­nie zde­fi­nio­wa­nych pojęć, tak­że tych z uży­tej nota­cji) pró­by mode­lo­wa­nia pro­ce­sów pro­wa­dzą naj­czę­ściej do powsta­wa­nia mon­stru­al­nych ilo­ści nie­czy­tel­nych dia­gra­mów (widy­wa­łem doku­men­ta­cje, gdzie było dla jed­nej fir­my powsta­łe bli­sko tysiąc stron! Masakra). To kom­plet­nie nie­przy­dat­ne dokumenty.

Co jesz­cze nam daje sto­so­wa­nie powyż­szych defi­ni­cji? Możliwość jed­no­znacz­ne­go ​„przej­ścia” (śla­do­wa­nie) z mode­li pro­ce­sów biz­ne­so­wych na mode­le przy­pad­ków uży­cia bo ato­mo­wy pro­ces, zakwa­li­fi­ko­wa­ny do zakre­su pro­jek­tu jako wyma­ga­na usłu­ga opro­gra­mo­wa­nia, to przy­pa­dek uży­cia nowe­go opro­gra­mo­wa­nia, zaś pro­ce­du­ra tego pro­ce­su to nic inne­go jak sce­na­riusz tego przy­pad­ku uży­cia lub jak ktoś woli: user sto­ry. Z innej stro­ny: jeże­li mamy wdro­żo­ną pro­ce­so­wą nor­mę np. ISO9000, to mode­lu­jąc pro­ce­sy biz­ne­so­we i ​„pod­pi­na­jąc” do nich pro­ce­du­ry z księ­gi jako­ści, szyb­ko się prze­ko­na­my, czy nasze ISO to nie jest przy­pad­kiem fikcją.