Większość mode­li (sys­te­mów map) pro­ce­sów biz­ne­so­wych posłu­gu­je się trzy­ele­men­to­wym wzor­cem (prag­ma­ty­ką) bazu­ją­cym na defi­ni­cji pro­ce­su brzmią­cej mniej wię­cej tak: pro­ces to czyn­ność lub ich sekwen­cja prze­kształ­ca­ją­ca stan wej­ścia w stan wyj­ścia. Czasami doda­je się, że źró­dłem wej­ścia jest ​„dostaw­ca” a wyj­ścia ​„klient” (tak­że tak zwa­ny klient wewnętrz­ny). Wada tej defi­ni­cji pole­ga na tym, że jest zbyt ?mecha­nicz­na?. Co to zna­czy? Że trak­tu­je wej­ście i wyj­ście pro­ce­su jak ?poje­dyn­cze sta­ny cze­goś? łącz­nie (wytłu­ma­cze­nie kil­ka lini­jek dalej).

Klasycznym przy­kła­dem tego podej­ścia jest Six Sigma i model SIPOC:

Model SIPOC zakła­da ist­nie­nie osob­nej doku­men­ta­cji dla same­go pro­ce­su, nie pre­cy­zu­jąc jak ma zostać ona wyko­na­na (nie narzu­ca meto­dy doku­men­to­wa­nia procesu).

Nieco szer­sza defi­ni­cja pro­ce­su, miesz­czą­ca się poję­cio­wo w powyż­szej, mogła by brzmieć: pro­ces prze­kształ­ca stan wej­ścia w stan wyj­ścia, prze­kształ­ce­nie to jest ogra­ni­czo­ne okre­ślo­ny­mi zaso­ba­mi i regu­ła­mi (zaka­za­mi). Tu mamy do czy­nie­nia z pię­cio­ma ele­men­ta­mi to jest: wej­ście, wyj­ście, pro­ces, zaso­by, regu­ły. Przykładem tego podej­ścia jest star­szy od Six Sigma model opar­ty na wzor­cu [[ICOM]] (powstał w latach 60tych!):

Tu już widać, że pro­ces na tym pozio­mie jest pew­ną abs­trak­cją, defi­nio­wa­ne są (ICOM) czte­ry ​„sate­li­tar­ne” ele­men­ty defi­niu­ją­ce ​„co, z cze­go i dla­cze­go się dzieje”.

Można się tak­że dość czę­sto spo­tkać z defi­ni­cją sze­ścio­ele­men­to­wą Erikssona-Penkera ([[Eriksson-Penker Business Modeling Profile]]) . Tu mamy:

Powyższy model bazu­je na uzna­niu, że pro­ces biznesowy:

1. ma cel,
2. ma spe­cy­ficz­ne dane na wejściu,
3. ma spe­cy­ficz­ne dane na wyjściu,
4. wyma­ga zasobów,
5. sta­no­wi ​„wie­le czyn­no­ści do wykonania”,
6. anga­żu­je róż­ne ​„depar­ta­men­ty” w fir­mie (pozio­my przepływ),
7. two­rzy jakąś war­tość dla klien­ta (wewnętrz­ne­go lub zewnętrznego)

Problem jaki ja mam z tym wzor­cem to: wyma­ga nie­stan­dar­do­wych pojęć w UML. Profilowanie pole­ga na roz­bu­do­wie tak­so­no­mii zna­czeń (ste­reo­ty­py poka­zu­ją jakie pod­ty­py two­rzy­my dla dane­go typu), nie­ste­ty obiekt jako instan­cja kla­sy nie wytrzy­mu­je w moich oczach defi­ni­cji cze­goś tak abs­trak­cyj­ne­go jak cel biznesowy(«goal»). Symbol pro­ce­su (tak zwa­ny pagon) tak­że nie jest poję­ciem z UML. Pojęcie Information jest tak pojem­ne, że w moich oczach jest wor­kiem, któ­ry pomie­ści wszyst­ko, a cechą dobrej nota­cji (for­mal­ne­go języ­ka, tak­że otwar­te­go) jest jed­nak wza­jem­ne wyklu­cza­nie się defi­ni­cji pojęć danej prze­strze­ni nazw (czy­li jeże­li coś jest np. Wejściem to już nie może być Informacją), na tej zasa­dzie nie rozu­miem też róż­ni­cy pomię­dzy celem pro­ce­su a jego wyj­ściem albo Aktorem z Zasobem (w koń­cu ludzie to zaso­by ludzkie).

Od nie­daw­na UML for­mal­nie wpro­wa­dził nowy dia­gram Profile (jako wer­sji Beta uży­wam go od roku co naj­mniej) i zacho­wu­jąc seman­ty­kę tego dia­gra­mu trud­no było by taki pro­fil zbu­do­wać (mi nie wyszło). Jednak oce­nę przy­dat­no­ści tego sys­te­mu pozo­sta­wiam Państwu.

Definicja trzy­ele­men­to­wa trak­tu­je wszyst­kie dostęp­ne dane (infor­ma­cje) jako Wejście. Problem w tym, że prze­kształ­ca­na jest tyl­ko część z nich.

Jeżeli np. do reali­za­cji pro­ce­su fak­tu­ro­wa­nia, na jego wej­ściu potrzeb­ne są dane do fak­tu­ry oraz jej wzór i zna­jo­mość reguł nali­cze­nia podat­ku VAT (sto­sow­na Ustawa) to zwróć­my uwa­gę, że tak napraw­dę prze­kształ­ca­ne są (prze­twa­rza­ne) tyl­ko dane do fak­tu­ry, pozo­sta­łe dane to nie­mo­dy­fi­ko­wa­ne ogra­ni­cze­nia, wie­dza, któ­rą musi posia­dać Wykonawca. Tak wiec np. usta­wa o podat­ku VAT to nie prze­twa­rza­ne wej­ście tego procesu.

Aby pro­ces zaist­niał musi poja­wić się Osoba two­rzą­ca fak­tu­rę czy­li zaso­by, ów Wykonawca z jego wie­dzą i narzę­dzia­mi jaki­mi dys­po­nu­je. W efek­cie model nie­co się posze­rza: wej­ście, wyj­ście (dane do fak­tu­ry), pro­ces (jak powsta­je fak­tu­ra np. eta­py zatwier­dza­nia), zaso­by (oso­ba fak­tu­ru­ją­ca i narzę­dzia któ­rych uży­wa do tego), regu­ły (wewnętrz­ne pro­ce­du­ry oraz prawo).

Reguły roz­bi­ja­my na dwie czę­ści: regu­ły biz­ne­so­we (wewnętrz­ne pro­ce­du­ry i zarzą­dze­nia) oraz pra­wo czy­li ogra­ni­cze­nia zewnętrz­ne. Jaki cel przy­świe­ca takie­mu podzia­ło­wi? Wydzielenie spe­cy­fi­ki bada­nej orga­ni­za­cji. Jej spe­cy­fi­ka tkwi w wewnętrz­nych pro­ce­du­rach i zarzą­dze­niach a nie w mapie pro­ce­sów, ta jest raczej wewnętrz­nym łań­cu­chem war­to­ści (któ­ry nie powi­nien być zbyt skomplikowany).

Jeżeli chce­my ?odkryć? źró­dła prze­wa­gi ryn­ko­wej musi­my zde­fi­nio­wać to, co odróż­nia nas od kon­ku­ren­cji. Co to jest? Posiadane zaso­by i regu­ły biznesowe.

Tak opi­sa­ny model moż­na zobra­zo­wać w nota­cji BPMN:

Każdy pro­ces jest ini­cjo­wa­ny jakimś zda­rze­niem, w szcze­gól­no­ści poja­wie­niem się doku­men­tu do obsłu­że­nia np. Zamówieniem. Wyjście to pro­dukt tej pra­cy np. Faktura. I tyl­ko to pod­le­ga prze­twa­rza­niu. Reszta ​„danych wyma­ga­nych” to nie wej­ście pro­ce­su a jego ogra­ni­cze­nia w posta­ci: aktów praw­nych, pro­ce­dur, zarzą­dzeń wewnętrz­nych (reguł biz­ne­so­wych). Proces koń­czy się zda­rze­niem: ​„Dane wyj­ścio­we wytwo­rzo­no”, jest to ​„mani­fe­sta­cja”. W czym rzecz? otóż jeże­li pro­ces się skoń­czył: fak­tu­ra VAT zosta­ła wytwo­rzo­na ale do cza­su gdy nikt się o tym nie dowie (pro­dukt pro­ce­su nie zosta­nie dostar­czo­ny klien­to­wi lub nie zosta­nie od o tym poin­for­mo­wa­ny), pro­ces for­mal­nie trwa. To dla­te­go mówi się o BPMN (i o natu­rze pro­ce­sów) że są ste­ro­wa­ne zda­rze­nia­mi. Aktów praw­nych defi­nio­wać nie trze­ba, pro­ce­du­ra to okre­ślo­ny, narzu­co­ny spo­sób wyko­na­nia kon­kret­nej czyn­no­ści, regu­ła biz­ne­so­wa to ogra­ni­cze­nie doty­czą­ce całej orga­ni­za­cji (wię­cej o regu­łach w poprzed­nich wpi­sach).

Jaki z tego wnio­sek? Skuteczne zarzą­dza­nie, z peł­nym zro­zu­mie­niem skut­ków, wyma­ga mode­lu, któ­ry poka­że nam czym dys­po­nu­je­my, w czym jeste­śmy (chce­my być) lep­si i na co nie mamy wpły­wu, czy­li z czym wal­czy­my i my i kon­ku­ren­cja jednakowo.

Na tym eta­pie Analityk Biznesowy może dać mene­dże­rom dobry model biz­ne­so­wy symu­lu­ją­cy mode­lo­wa­ną orga­ni­za­cję, pod­sta­wę do podej­mo­wa­nia decy­zji organizacyjnych.

Co jeszcze?

Zasoby to coś, bez cze­go żad­na orga­ni­za­cja nie jest w sta­nie funk­cjo­no­wać. Wśród nich są ludzie i narzę­dzia pra­cy, któ­rych uży­wa­ją. Model ICOM trak­tu­je zaso­by ogól­nie, w BPMN zosta­ły one ​„ukry­te” w posta­ci abs­trak­cji jaką jest rola (lub wyko­naw­ca). Wykonawca ​„gru­pu­je” w sobie nie­zbęd­ną wie­dzę, umie­jęt­no­ści, narzę­dzia i mate­ria­ły potrzeb­ne do wyko­na­nia Czynności (dla­te­go obec­nie jako poważ­ny błąd postrze­gam mode­lo­wa­nie opro­gra­mo­wa­nia (Systemu) jako toru w pro­ce­sie, System to nie rola a narzę­dzie pra­cy no chy­ba, że mowa o robotach ;)).

Wśród tych narzę­dzi mogą być kom­pu­te­ry, a kon­kret­nie opro­gra­mo­wa­nie, któ­re wspie­ra Wykonawcę w reali­za­cji wybra­nych Czynności. Skoro tak, to opro­gra­mo­wa­nie po pro­stu świad­czy usłu­gi swo­im użyt­kow­ni­kom ([[model usłu­go­wy sys­te­mu informatycznego]]).

Tak rozu­mia­ne ?usłu­gi? to nic inne­go jak wyma­ga­nia na opro­gra­mo­wa­nie. Z uwa­gi na to, że wyma­ga­nia te dzie­li­my na usłu­gi (reali­za­cja wspar­cia jakiejś logi­ki biz­ne­so­wej) oraz jakość jej reali­za­cji, wyma­ga­nia dzie­li­my na funk­cjo­nal­ne oraz jako­ścio­we (poza-funk­cjo­nal­ne).

Systemy i oprogramowanie

Dotykamy tu więc opro­gra­mo­wa­nia np. sys­te­mów ERP, CRM, EOD (elek­tro­nicz­ny obieg doku­men­tów) lub dedy­ko­wa­ne­go (w zasa­dzie zawsze mamy do czy­nie­nia z sys­te­ma­mi dedy­ko­wa­ny­mi jeże­li tyl­ko pla­no­wa­na jest jaka­kol­wiek ich kastomizacja).

Na tym eta­pie powi­nien powstać pro­jekt archi­tek­tu­ry sys­te­mu. Wystarczy się rozej­rzeć wokół sie­bie by prze­ko­nać się, że mamy wokół wie­le róż­ne­go opro­gra­mo­wa­nia. Między baj­ki moż­na wło­żyć tezę, o jed­nym wiel­kim pakie­cie zin­te­gro­wa­nym ? nikt takie­go nie ma (tyl­ko jed­ne­go). To co nazy­wa­my Systemem Informatycznym to tak na praw­dę pakiet opro­gra­mo­wa­nia od róż­nych, mniej lub bar­dziej wyspe­cja­li­zo­wa­nych dostaw­ców. Integracja poszcze­gól­nych ele­men­tów tego pakie­tu (lub brak tej inte­gra­cji) zale­ży od pier­wot­ne­go pla­nu (archi­tek­tu­ry).

Teraz dopie­ro rysu­je się obraz Systemu: wie­le róż­ne­go rodza­ju opro­gra­mo­wa­nia, któ­re wspie­ra róż­nych pra­cow­ni­ków na róż­nych eta­pach ich pra­cy. Czy da się to opi­sać nie mając opi­sa­ne­go wyżej mode­lu biznesowego?

Czym jest piąty element?

To abs­trak­cja jaką jest pro­ces biz­ne­so­wy. Mało któ­ra fir­ma ma mode­le pro­ce­sów a każ­da jakoś ist­nie­je! Można żyć bez map pro­ce­sów, strasz­ne! Co więc ofe­ru­ją fir­my dorad­cze ​„sprze­da­ją­ce” mapo­wa­nie pro­ce­sów biz­ne­so­wych? Nie wiem.

Sedno spo­so­bu pra­cy orga­ni­za­cji to regu­ły biz­ne­so­we. One rzą­dzą tym, co jest wyko­ny­wa­ne i jak. Proces (to jak jest wyko­ny­wa­na pra­ca) to abs­trak­cja, efekt ist­nie­nia ogra­ni­czeń (w tym wła­śnie reguł biz­ne­so­wych). Tak wiec moż­na zarzą­dzać fir­mą nie mając mode­li pro­ce­sów podob­nie jak moż­na miesz­kać w mie­ście nie mając jego planu.

W czym pro­blem? Bez ​„mapy” nie rozu­mie­my wie­lu zja­wisk mimo, że wystę­pu­ją. Jednak przy­dat­ny model biz­ne­so­wy to model pro­ce­sów powią­za­ny z pozo­sta­ły­mi czte­re­ma skład­ni­ka­mi opi­su orga­ni­za­cji (ludzie, pra­wo, wewnętrz­ne zarzą­dze­nia i procedury).

Model biz­ne­so­wy to nie są dzie­siąt­ki i set­ki nie­czy­ta­nych dia­gra­mów, poka­zu­ją­cych szcze­gó­ło­wo to co robią pra­cow­ni­cy, bo mogą to robić na nie­skoń­cze­nie wie­le spo­so­bów (tą meto­dą pro­jekt mapo­wa­nie pro­ce­sów nie ma koń­ca!). Istotne jest to co powsta­je, po co i dla­cze­go aku­rat tak.

Na zakoń­cze­nie: np. model pra­cy ope­ra­cyj­nej każ­de­go urzę­du moż­na kom­plet­nie opi­sać jed­nym dia­gra­mem. Jeżeli chcesz na praw­dę poznać swo­ją fir­mę, opra­cuj jej model. Ale nie w posta­ci setek dia­gra­mów będą­cych suchym zapi­sem wywiadu.

Rozłóż fir­mę na czyn­ni­ki pierw­sze i zro­zum ją. Bez tego nie zarzą­dzasz a pró­bu­jesz zarządzać!

Wykonaj sfor­ma­li­zo­wa­ny nota­cja­mi i słow­ni­kiem pojęć, audyt fir­my, spo­so­bu funk­cjo­no­wa­nia i zro­zum jak na praw­dę dzia­ła. O wspól­nym słow­ni­ku pojęć biz­ne­so­wych, pod­sta­wą budo­wy reguł biz­ne­so­wych, innym razem.