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):
proceduraWIKI

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.

ISO_procedureWaż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

Definicja ta nie koli­du­je z moją, ma jed­nak pew­ną wadę: nie pre­cy­zu­je pozio­mu abs­trak­cji (lub szcze­gó­ło­wo­ści). Innymi sło­wy, czy obsłu­ga zamó­wie­nia opi­sa­na jako zare­je­stro­wa­nie doku­men­tu zamó­wie­nia, wysta­wie­nie listu prze­wo­zo­we­go wg. wzo­ru i zgod­nie z tre­ścią zamó­wie­nia oraz wysta­wie­nie fak­tu­ry sprze­da­ży” to pro­ce­du­ra czy sekwen­cja pro­ce­sów mają­cych dopie­ro swo­je pro­ce­du­ry (np. jak prze­bie­ga reje­stra­cja Zamówienia)? Moja defi­ni­cja jaw­nie wska­zu­je, że pro­ce­du­ra opi­su­je naj­niż­szy poziom szcze­gó­ło­wo­ści: ato­mo­wych pro­ce­sów biz­ne­so­wych. tak więc mamy to łań­cuch pro­ce­sów i wyma­ga­ny bra­ku­ją­cy opis pro­ce­du­ry reje­stra­cji Zamówienia”. 

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

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.

Dodaj komentarz

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