Równo 10 lat temu napisałem:

Model fir­my powi­nien w spo­sób jasny i zro­zu­mia­ły dla pra­cow­ni­ków fir­my opi­sy­wać fir­mę, jej cel ryn­ko­wy oraz wszel­kie jej wewnętrz­ne i zewnętrz­ne zacho­wa­nia oraz reak­cje. Poza tym, jest nie­zbęd­ny do prze­wi­dy­wa­nia zacho­wań fir­my w tym tak­że do przy­go­to­wa­nia jej do wdro­że­nia sys­te­mów infor­ma­cyj­nych. Wiele firm dorad­czych i infor­ma­tycz­nych pod poję­ciem mapy i mode­lu pro­ce­sów biz­ne­so­wych dostar­cza nie­przy­dat­ne, utrwa­lo­ne na dzie­siąt­kach dia­gra­mów opi­sy czyn­no­ści reali­zo­wa­nych przez ankie­to­wa­nych pra­cow­ni­ków, któ­re nie wie­le mają wspól­ne­go z pla­no­wa­ny­mi zmia­na­mi na lepsze.Większość mode­li firm jakie widzia­łem to obraz­ki nie mają­ce wie­le wspól­ne­go z pro­ce­sa­mi. Zdarza mi się otrzy­my­wać zle­ce­nia, któ­rych głów­nym celem jest oce­na cudzej doku­men­ta­cji przed­wdro­że­nio­wej. Bardzo czę­sto jest to siecz­ka w posta­ci udo­ku­men­to­wa­nych życzeń i wyobra­żeń ankie­to­wa­nych pra­cow­ni­ków fir­my… (Źródło: Modelowanie biz­ne­so­we czy­li pil­no­wa­nie hochsztaplerów)

I nie­ste­ty nie wie­le w tym wzglę­dzie się zmie­ni­ło od tam­te­go cza­su. Zmieniło się jed­nak to, że funk­cyj­na idea mode­lo­wa­nia orga­ni­za­cji w posta­ci mode­lu pro­ce­sów biz­ne­so­wych ma już ugrun­to­wa­ną pozy­cję, i mamy postęp w posta­ci powsta­nia, i ugrun­to­wa­nia sobie pozy­cji jako stan­dar­du de» fac­to, nota­cji [cm_tooltip_parse]BPMN[/cm_tooltip_parse].

Wtedy powo­ły­wa­łem się na nota­cje IDEF0, w któ­rej fun­da­men­tem jest funk­cyj­ny blok konstrukcyjny:

Powyższy dia­gram to wyko­na­ny w nota­cji [[IDEF0]] model pro­ce­su jako funk­cji, jej wej­ścia, wyj­ścia, ste­ro­wa­nia i mecha­ni­zmu dzia­ła­nia. Systemowe (nauko­we, czy­li pozwa­la­ją­ce na testo­wa­nie mode­lu i jego fal­sy­fi­ka­cje) mode­lo­wa­nie orga­ni­za­cji nadal bazu­je na poję­ciach z tej (IDEF0) nota­cji i mode­lu pro­ce­su ICOM (ang. Input, Output, Controll, Mechanizm):

Idea ta bazu­je na uzna­niu, że każ­dy pro­ces biz­ne­so­wy to wno­szą­ce war­tość doda­ną funk­cja prze­kształ­ca­ją­ca wej­ście w wyj­ście pro­ce­su, prze­kształ­ce­nie to, spo­sób jego reali­za­cji, jest ogra­ni­czo­ne a dzia­ła­nia, ich mecha­nizm, mogą być defi­nio­wal­ne jako deter­mi­ni­stycz­ne. Notacja IDEF0 była dłu­go sto­so­wa­na jed­nak mia­ła pod­sta­wo­wą wadę: znacz­nie strza­łek (seman­ty­ka nota­cji) było uza­leż­nio­ne od ich poło­że­nia, co utrud­nia­ło wery­fi­ka­cję mode­li, utrud­nia­ło ich two­rze­nie i nara­ża­ło te mode­le na nie­jed­no­znacz­ność przy ich czy­ta­niu (pamię­ta­my, że model to tak­że treść czy­li komunikacja).

Notacja BPMN nie ma tej wady ale też nie zawie­ra takich pojęć jak Controll i Mechanizm. BPMN to przede wszyst­kim prze­pływ pra­cy oraz dane wej­ścio­we i wyj­ścio­we (dia­gram powy­żej). Jednak nota­cja ta pozwa­la na roz­sze­rza­nie seman­ty­ki o nowe sym­bo­le. Bardzo złą prak­ty­ką jest nano­sze­nie na mode­le pro­ce­sów (dia­gra­my BPMN dla tych pro­ce­sów) deta­li zwią­za­nych ze spo­so­bem dzia­ła­nia czy­li logi­ką biz­ne­so­wą i mecha­ni­zmem podej­mo­wa­nia decy­zji. Modele takie sta­ją się bar­dzo szcze­gó­ło­we a utrzy­ma­nie ich aktu­al­no­ści (sta­no­wią doku­men­ta­cję pro­ce­sów) prak­tycz­nie nie jest moż­li­we (każ­da zmia­na spo­so­bu dzia­ła­nia wyma­ga korek­ty tych dia­gra­mów). Tworzenie takich, zbyt szcze­gó­ło­wych, mode­li okre­śla­ne jest w lite­ra­tu­rze okre­śla­ne wręcz jako ​„utra­ta pano­wa­nia nad szcze­gó­ło­wo­ścią projektu”.

Od lat sto­so­wa­ne są, jako uzu­peł­nie­nie mode­lo­wa­nia orga­ni­za­cji, macie­rze [[RACI]], pozwa­la­ją one, jako uzu­peł­nie­nie np. mode­li BPMN, osob­no udo­ku­men­to­wać zło­żo­ne zależ­no­ści pomię­dzy rola­mi w pro­ce­sie (wię­cej o RACI.….). Takie ele­men­ty poję­cio­we ICOM jak Controll i Mechanizm moż­na (zale­ca się) mode­lo­wać jako sys­tem reguł biz­ne­so­wych i tabel decyzyjnych.

Model pro­ce­su wyko­na­ny w nota­cji BPMN, uzu­peł­nio­ny o ste­ro­wa­nie i mecha­nizm podej­mo­wa­nia decy­zji, wyglą­da tak:

Zadanie 1 zosta­ło tu sko­ja­rzo­ne z Reguła biz­ne­so­wą (Controll) i Tablicą decy­zyj­ną (mecha­nizm). Reguły biz­ne­so­we to sfor­ma­li­zo­wa­ne zapi­sy okre­śla­ją­ce ​„panu­ją­ce pra­wo” w orga­ni­za­cji (np. zarzą­dze­nia i regu­la­mi­ny). Tablice decy­zyj­ne to sfor­ma­li­zo­wa­ne macie­rze opi­su­ją­ce deter­mi­ni­stycz­ne decy­zje (kon­kret­na odpo­wiedź sys­te­mu w odpo­wie­dzi na kon­kret­ny zestaw bodź­ców). Wejście i wyj­ście to nic inne­go jak odpo­wied­nio ozna­czo­ne Dane (Obiekt danych w BPMN). Szczegóły wyko­na­nia Zadania to albo wie­dza i umie­jęt­no­ści wyko­naw­cy albo pro­ce­du­ra (np. ISO). W doku­men­ta­cji pro­jek­to­wej powo­łu­je­my się na (załą­cza­my) wyma­ga­ny zakres kom­pe­ten­cji wyko­naw­cy (rola na dia­gra­mie pro­ce­su) lub załą­cza­my sto­sow­ną pro­ce­du­rę (doku­ment, nie nano­si­my na dia­gram BPMN). Takie nie­po­dziel­ne już zada­nie, wraz z jego wej­ściem, wyj­ściem i ewen­tu­al­ny­mi regu­ła­mi to ele­men­tar­ny pro­ces biznesowy.

Tak więc zasa­dy nauko­we­go mode­lo­wa­nia (a wcze­śniej ana­li­zy) nie zmie­nia­ją się:

1. zde­fi­nio­wa­nie i okre­śle­nie problemu,
2. ana­li­za i opra­co­wa­nie hipo­te­zy (mode­lu, tu bada­nej orga­ni­za­cji czy­li jej mode­lu pro­ce­so­we­go: tak orga­ni­za­cja reali­zu­je swo­je cele),
3. testo­wa­nie (pró­ba fal­sy­fi­ka­cji mode­lu) w posta­ci spraw­dza­nia czy są w orga­ni­za­cji dane prze­twa­rza­ne ina­czej niż na modelu,
4. opra­co­wa­nie wyni­ków, lub korek­ta mode­lu w przy­pad­ku jego uda­nej fal­sy­fi­ka­cji (wte­dy powta­rza­my pkt 2. i 3.)
5. opra­co­wa­nie reko­men­da­cji czy­li odpo­wiedź na pyta­nie zada­ne w pkt. 1.

Notacja BPMN do duży krok do przo­du, bo narzę­dzie to ma pre­cy­zyj­ną (pod­da­ją­cą się wali­da­cji), seman­ty­kę i syn­tak­ty­kę, a moż­li­wość nada­nia mode­lom kon­tek­stu poprzez dodat­ko­we uży­cie macie­rzy RACI, reguł biz­ne­so­wych i tablic decy­zyj­nych, pozwa­la two­rzyć bar­dzo pre­cy­zyj­ne mode­le biz­ne­so­we moż­li­we do zarzą­dza­nia (nie obar­czo­ne nad­mia­rem szcze­gó­łów). Wydzielenie pozio­mu szcze­gó­ło­wo­ści zwią­za­ne­go z podej­mo­wa­niem decy­zji, poza dia­gra­my (jako załą­czo­ne ele­men­ty), pozwa­la po pierw­sze utrzy­mać roz­sąd­ny poziom szcze­gó­ło­wo­ści samych dia­gra­mów, ich czy­tel­ność i zarzą­dzal­ność, np. zmia­na mecha­ni­zmu podej­mo­wa­nia decy­zji nie wyma­ga aktu­ali­za­cji dia­gra­mów, bo prze­pływ pra­cy nie zmie­nia się. Poniżej wie­lo­krot­nie tu przy­ta­cza­ny model warstwowy;

Środkowa war­stwa to wskaź­ni­ki (np KPI), archi­tek­tu­ra pro­ce­sów, stra­te­gie itp. Najniższa war­stwa to wszel­kie szcze­gó­ły takie jak instruk­cje sta­no­wi­sko­we, pro­ce­du­ry, zakre­sy obo­wiąz­ków, opi­sy wyma­ga­nych umie­jęt­no­ści, instruk­cje dla użyt­kow­ni­ków urzą­dzeń i opro­gra­mo­wa­nia, wszel­kie inne szcze­gó­ły opi­su­ją­ce spo­sób pra­cy (nie raz mecha­nizm jej wyko­ny­wa­nia). Środkowa war­stwa to wła­śnie abs­trak­cja, jaką jest model pro­ce­sów biz­ne­so­wych, jest on opi­sem prze­pły­wu pra­cy. Na tym pozio­mie opra­co­wu­je­my model, któ­ry w lite­ra­tu­rze z zakre­su stra­te­gii i zarzą­dza­nia jest nazy­wa­ny wewnętrz­nym łań­cu­chem war­to­ści w orga­ni­za­cji. Na tym pozio­mie nie doku­men­tu­je­my żad­nych szcze­gó­łów (powo­łu­je­my się na nie, załą­cza­my je), na tym pozio­mie poka­zu­je­my wyłącz­nie CO i PO CO się dzie­je a nie JAK. Opis tego jak JAK to się dzie­je to wła­śnie owe Controll i Mechanizm.

Owszem wyma­ga to uży­cia dodat­ko­wych ele­men­tów na dia­gra­mach BPMN, wyma­ga tak­że tak­że odpo­wied­nie­go narzę­dzia CASE, któ­re na to pozwa­la, ale war­to bo doku­men­ta­cja taka sta­je się łatwa w korzy­sta­niu z niej, mamy zapew­nio­ny odpo­wied­ni poziom abs­trak­cji samych mode­li pro­ce­sów, mamy tak­że osob­no udo­ku­men­to­wa­ne szcze­gó­ły logi­ki biz­ne­so­wej, co bar­dzo uła­twia (w zasa­dzie prze­ka­zu­je­my jej bez mody­fi­ka­cji) posta­wie­nie wyma­gań przed opro­gra­mo­wa­niem, któ­re mia­ło by je imple­men­to­wać (regu­ły biz­ne­so­we i tabli­ce decy­zyj­ne sta­ją się w takim wypad­ku wymaganiem).