Cztery lata temu, pisa­łem o regu­łach biz­ne­so­wych jako ele­men­cie mode­lu biz­ne­so­we­go i ich roli w zarządzaniu:

Na czym więc pole­ga sku­tecz­ne zarzą­dza­nie? Na zro­zu­mie­niu, posia­da­niu pla­nu dzia­ła­nia i prze­my­śla­nym two­rze­niu ograniczeń.Robi tak każ­da więk­sza fir­ma: powsta­ją zakre­sy obo­wiąz­ków, wewnętrz­ne zarzą­dze­nia i pro­ce­du­ry. To wszyst­ko to nic inne­go jak ograniczenia.Opracowanie mode­lu orga­ni­za­cji więc, to nie tyl­ko opi­sa­nie pro­ce­sów bo te są jedy­nie efek­tem ist­nie­ją­cych ogra­ni­czeń. Pełny model orga­ni­za­cji, dają­cy zro­zu­mie­nie tego jak ona dzia­ła, to kom­plet­ny model poję­cio­wy ? nazwy i defi­ni­cje pod­sta­wo­wych pojęć opi­su­ją­cych jej dzia­ła­nie (co to jest klient, pro­dukt, kon­tra­hent, ?), spe­cy­fi­ka­cja wszel­kich ogra­ni­czeń czy­li reguł biz­ne­so­wych oraz spe­cy­fi­ka­cji sta­no­wisk i wyma­ga­nych na każ­dym z nich umie­jęt­no­ści (pamię­ta­my, że ogra­ni­cze­niem jest tak­że obo­wią­zu­ją­ce pra­wo). (Źródło: Reguły biz­ne­so­we jako motor ste­ru­ją­cy orga­ni­za­cji: fak­ty + defi­ni­cje pojęć | Jarosław Żeliński IT-Consulting)

Dzisiaj o zarzą­dza­niu zorien­to­wa­nym na regu­ły biz­ne­so­we. Temat, z któ­rym pierw­szy raz zetkną­łem się jakieś 15 lat temu w jed­nym z wydaw­nictw Harvard Business Review. Nie będę tu stresz­czał tego tek­stu (pew­nie nawet nie mogę ;)), gene­ral­nie prze­sła­nie brzmiało:

orga­ni­za­cją moż­na zarzą­dzać two­rząc regu­ły a nie wyda­jąc pole­ce­nia przy każ­dym zdarzeniu.

Manifest reguł biznesowych

Poniżej frag­men­ty Manifestu Reguł Biznesowych (link do ory­gi­na­łu)

Manifest reguł biz­ne­so­wych, kil­ka klu­czo­wych ele­men­tów wyróż­ni­łem podkreśleniem:

Artykuł 2. [regu­ły biz­ne­so­we] Oddzielone od pro­ce­sów, a nie zawie­ra­ją­ce się w nich
2.1. Reguły są bez­po­śred­ni­mi ogra­ni­cze­nia­mi narzu­co­ny­mi na funk­cjo­no­wa­nie orga­ni­za­cji jak rów­nież mogą sta­no­wić wspar­cie dla jej funkcjonowania.
2.2. Reguły nie są pro­ce­sa­mi ani pro­ce­du­ra­mi. Nie powin­ny być w nich zawarte.
2.3. Reguły mają zasto­so­wa­nie ponad i pomię­dzy pro­ce­sa­mi i pro­ce­du­ra­mi. Powinny sta­no­wić jeden spój­ny orga­nizm, sto­so­wa­ny kon­se­kwent­nie w odpo­wied­nich obsza­rach aktyw­no­ści biznesowej.
Artykuł 3. Świadomie roz­wi­ja­na dzie­dzi­na wie­dzy, nie pro­dukt uboczny
3.1. Reguły budo­wa­ne są na fak­tach, a fak­ty budo­wa­ne są na kon­cep­cjach wyra­żo­nych poprzez ter­mi­ny [błąd tłu­ma­cze­nia, zama­ist ​„kon­cep­cjach” powin­no być ​„poję­ciach wyra­żo­nych odpo­wied­ni­mi słowami”].
3.2. Terminy wyra­ża­ją kon­cep­cje biz­ne­so­we [tu nie­ste­ty tak­że mamy błąd tłu­ma­cze­nia, cho­dzi poję­cia biz­ne­so­we a nie ​„kon­cep­cje”, w ory­gi­na­le jest sło­wo ​„con­cept”]; fak­ty dostar­cza­ją stwier­dzeń odno­śnie tych kon­cep­cji, regu­ły ogra­ni­cza­ją oraz wzbo­ga­ca­ją te fakty.
3.3. Reguły muszą być wyra­żo­ne expli­ci­te. Reguły nie sta­no­wią domnie­mań odno­śnie kon­cep­cji, czy faktów.
3.4. Reguły sta­no­wią pod­sta­wę tego, co biz­nes wie o sobie ? to zna­czy, pod­sta­wę wie­dzy biznesowej.
Artykuł 4. Deklaratywne, nie imperatywne
4.1. Reguły powin­ny być wyra­ża­ne dekla­ra­tyw­nie w for­mie zdań w języ­ku natu­ral­nym dla doce­lo­we­go odbior­cy biz­ne­so­we­go.
4.2. Jeżeli coś nie może być wyra­żo­ne, nie jest regułą.
4.3. Zbiór wyra­żeń uzna­je się za dekla­ra­tyw­ny, gdy wyra­że­nia w zbio­rze nie zależ­ne od jakie­go­kol­wiek uporządkowania.
4.4. Dowolne wyra­że­nie doty­czą­ce reguł, któ­re wyma­ga kon­struk­cji róż­nych od pojęć i fak­tów impli­ku­je zało­że­nia odno­śnie sys­te­mo­wej implementacji.
4.5. Reguła jest róż­na od jakie­go­kol­wiek zasto­so­wa­nia dla niej zde­fi­nio­wa­ne­go. Reguła oraz jej zasto­so­wa­nie powin­ny być roz­wa­ża­ne oddzielnie.
4.6. Reguły powin­ny być defi­nio­wa­ne nie­za­leż­nie od tego kto, gdzie, kie­dy i jak je zastosuje.
4.7. Wyjątki od reguł są wyra­ża­ne inny­mi regułami.
5.3. Logiki for­mal­ne, takie jak logi­ka pre­dy­ka­tów, są fun­da­men­tem dobrze wyra­żo­nych reguł, wyko­rzy­stu­ją­cych ter­mi­ny biz­ne­so­we oraz tech­no­lo­gii imple­men­tu­ją­cych reguły.
Artykuł 10. Zarządzanie logi­ką biz­ne­su, nie plat­for­ma­mi informatycznymi 
10.1. Reguły biz­ne­so­we są war­to­ścio­wym zaso­bem biznesowym.
10.2. W per­spek­ty­wie dłu­go­ter­mi­no­wej, regu­ły są dużo waż­niej­sze dla biz­ne­su od plat­form sprzę­to­wych i pro­gra­mo­wych.
10.3. Reguły biz­ne­so­we powin­ny być orga­ni­zo­wa­ne i prze­cho­wy­wa­ne w spo­sób umoż­li­wia­ją­cy ich póź­niej­sze łatwe osa­dze­nie na nowych plat­for­mach pro­gra­mo­wych i sprzętowych.
10.4. Reguły oraz moż­li­wość efek­tyw­ne­go zarzą­dza­nia ich zmia­na­mi są pod­sta­wą do uspraw­nie­nia zdol­no­ści orga­ni­za­cji do adap­ta­cji do nowych warunków.

Warto zwró­cić uwa­gę na klu­czo­we dla zarzą­dza­nia orga­ni­za­cją i klu­czo­we dla two­rze­nia mode­li biz­ne­so­wych elementy:

1. Reguły biz­ne­so­we to ogra­ni­cze­nia zacho­wań (pożą­da­ne, dopusz­czal­ne i nie­do­pusz­czal­ne fakty).
2. Reguły nie są ani pro­ce­sa­mi ani procedurami.
3. Reguły budo­wa­ne są w opar­ciu o fakty.
4. Reguły wyra­ża­ne są zda­nia­mi w języ­ku natu­ral­nym (muszą być zro­zu­mia­łe dla ich wykonawców).
5. Reguły są od sie­bie nie­za­leż­ne (nie ma zna­cze­nia kolej­ność ich użycia).
6. Wyjątki są tak­że regu­ła­mi (tu nie­ste­ty nale­ży wystrze­gać się bar­dzo głu­pie­go przy­sło­wia o ​„wyjąt­ku potwier­dza­ją­cym regułę”)

Zarządzanie zorientowane na reguły

Generalnie regu­ły biz­ne­so­we wyzna­cza­ją pożą­da­ne zacho­wa­nia (coś naka­zu­ją, cze­goś zaka­zu­ją). W fir­mach są zawar­te (ukry­te) w regu­la­mi­nach, sta­tu­tach, zakre­sach obo­wiąz­ków, bie­żą­cych zarzą­dze­niach, innych doku­men­tach o podob­nych cha­rak­te­rze. Wyzwaniem jest ich zebra­nie i upo­rząd­ko­wa­nie, gdyż to one tak na praw­dę sta­no­wią LOGIKĘ BIZNESOWĄ danej orga­ni­za­cji. Reguł tych w orga­ni­za­cji mogę być nie raz set­ki, dla­te­go bar­dzo waż­ne jest ich porząd­ko­wa­nie. W nota­cji BMM mamy dwa poję­cia z tym zwią­za­ne: poli­ty­ka i regu­ła biz­ne­so­wa. Polityka to nic inne­go jak okre­ślo­ny kon­tek­sto­wo zbiór reguł biz­ne­so­wych (np. Polityka Bezpieczeństwa), tak więc regu­ły biz­ne­so­we gru­pu­je­my w tak zwa­ne Polityki. Np. w ramach two­rze­nia Polityki Obsługi Klientów, moż­na stwo­rzyć regu­łę biznesową:

AKME Sp. z o.o. udzie­la odpo­wie­dzi na każ­de otrzy­ma­ne pismo nie zakla­sy­fi­ko­wa­ne jako spam.

Kursywą zazna­czo­no nazwę wła­sną nie wyma­ga­ją­cą defi­ni­cji. Podkreśleniem ozna­czo­no fak­ty, pogru­bie­niem ozna­czo­no poję­cia w słow­ni­ku (pre­dy­ka­ty). Określenie ​„każ­de” jest funk­cją zda­nio­wą. Jak widać np. sło­wo spam jest pew­nym kla­sy­fi­ka­to­rem, defi­ni­cja tego poję­cia powin­na być w słow­ni­ku, będzie narzę­dziem odróż­nia­nia (kla­sy­fi­ka­cji) pism war­to­ścio­wych od bez­war­to­ścio­wych. Definicja poję­cia to atry­bu­ty pozwa­la­ją­ce uznać dane ​„coś” za przy­na­leż­ne do tego poję­cia, np. spam to ​„każ­dy list mają­cy mają­cy w polu nadaw­ca war­tość ​„rekla​my​.pl” (defi­ni­cja poję­cia może być dłu­gą listą war­to­ści atry­bu­tów – cech). Definicja poję­cia to cechy jakie musi speł­nić coś by zosta­ło uzna­ne za ​„to”. Reguły biz­ne­so­we to sądy czy­li logicz­ne dania, poję­cia połą­czo­ne fak­ta­mi. Sądem jest tak­że uzna­nie cze­goś za zgod­ne z defi­ni­cją (że ma okre­ślo­ne cechy). Przypominam, że regu­ła biz­ne­so­wa opi­su­je zacho­wa­nia a nie poję­cia, te są tu jedy­nie narzę­dziem opi­su rze­czy­wi­sto­ści dla tego zdarzenia.

Tak więc zamiast brać na sie­bie, jako pre­zes fir­my, mene­dżer śred­nie­go szcze­bla itd. ogrom zda­rzeń w posta­ci podej­mo­wa­nia decy­zji za każ­dym razem, gdy jest taka wyma­ga­na, moż­na stwo­rzyć sys­tem poli­tyk, zesta­wów reguł biz­ne­so­wych, skut­kiem cze­go fir­ma będzie spraw­nie funk­cjo­no­wa­ła nie anga­żu­jąc, nawet do bar­dzo try­wial­nych zadań, wyso­kich ran­gą pra­cow­ni­ków. Nie jest to dele­go­wa­nie upraw­nień, poli­ty­ki i regu­ły biz­ne­so­we to rodzaj z góry pod­ję­tych decy­zji. Owszem żad­nej fir­my nie da się zal­go­ryt­mi­zo­wać, dla­te­go zawsze wyż­sze kadry będą potrzeb­ne jed­nak ich klu­czo­wą rolą jest usta­la­nie zasad i zarzą­dza­nie nimi a bez­po­śred­nie reago­wa­nie powin­no doty­czyć tego ​„nie­zal­go­ryt­mi­zo­wa­ne­go” zakre­su zda­rzeń (op. 20% :), regu­ła Pareto).

Zarządzanie zorien­to­wa­ne na regu­ły biz­ne­so­we to wła­śnie takie podej­ście: to cze­go moż­na się spo­dzie­wać, opi­su­je­my regu­ła­mi, zda­rze­nia wyjąt­ko­we obsłu­gu­je­my oso­bi­ście. Reguły biz­ne­so­we war­to zebrać w jed­no miej­sce, ​„wyjąć” je z prze­ro­śnię­tych opi­sów zakre­sów obo­wiąz­ków i kom­pe­ten­cji, upo­rząd­ko­wać zarzą­dze­nia zarządu.

Tu ktoś może powie­dzieć, że mało któ­ra fir­ma taki ​„porzą­dek” ma i mimo to cał­kiem spraw­nie one funk­cjo­nu­ją, i będzie mia­ła rację. Ludzie dosko­na­le sobie radzą z nie­jed­no­znacz­no­ścią i zaska­ku­ją­cy­mi zda­rze­nia­mi. pro­blem poja­wia się, gdy trze­ba spi­sać wyma­ga­nia na opro­gra­mo­wa­nie, i poja­wi się roz­dział o nazwie ​„Logika biz­ne­so­wa”. Tu nie­ste­ty albo poja­wi się spój­ny opis jed­no­znacz­nych reguł, albo

wdro­że­nie cze­ka­ją potęż­ne kło­po­ty bo żad­ne opro­gra­mo­wa­nie nie pora­dzi sobie z niejednoznacznością. 

Procesy biznesowe

O nich napi­sa­łem wie­le, tu tyl­ko sku­pię się na jed­nym: 2.2. Reguły nie są pro­ce­sa­mi ani pro­ce­du­ra­mi. Nie powin­ny być w nich zawar­te (Manifest). To klu­czo­wa teza w mode­lo­wa­niu pro­ce­sów. Innymi sło­wy, przy­to­czo­nej reguły:

AKME Sp. z o.o. udzie­la odpo­wie­dzi na każ­de otrzy­ma­ne pismo nie zakla­sy­fi­ko­wa­ne jako spam.

nie ​„rysu­je­my” na dia­gra­mie BPMN jako sekwen­cji kro­ków w rodzaju:

„weź pismo, sprawdź czy nie zawie­ra dome­ny rekla​my​.pl w adre­sie nadaw­cy, jeże­li tak to wyrzuć do kosza, jeże­li nie to opra­cuj odpowiedź”.

bo to pro­wa­dzi do masa­krycz­nej zło­żo­no­ści dia­gra­mów. Po dru­gie w każ­dym pro­ce­sie mają­cym ​„w sobie” zda­rze­nie zwią­za­ne z odpi­sa­niem na pismo musie­li­by­śmy ​„nary­so­wać” powyż­szy ciąg czyn­no­ści. Zarządzanie zmia­ną w takiej doku­men­ta­cji to kosz­mar. Model pro­ce­su powi­nien zawie­rać wyłącz­nie ele­men­tar­ne pro­ce­sy biz­ne­so­we (aktyw­no­ści z ich wej­ściem i wyjściem):

Wtedy będzie to bar­dzo tre­ści­wy i zro­zu­mia­ły dia­gram. Tworzenie mon­stru­al­nych, nafa­sze­ro­wa­nych szcze­gó­ła­mi dia­gra­mów prak­tycz­nie nicze­mu i niko­mu nie słu­ży. Modele zawie­ra­ją­ce wry­so­wa­ne ​„obraz­ko­wo” regu­ły biz­ne­so­we i pro­ce­du­ry to nie­ste­ty bar­dzo kosz­tow­ne i cał­ko­wi­cie nie­przy­dat­ne doku­men­ty. Jeżeli mają być ​„wsa­dem” do ana­li­zy wyma­gań są wręcz szko­dli­we bo ukry­wa­ją sens logi­ki biz­ne­so­wej w masie nad­mia­ro­wych szczegółów.

[przyp. 13.12.2015: bar­dzo cie­ka­wie o ​„zaszu­mie­niu mode­li pro­ce­sów” napi­sał Girish K C (Vice President, Process Reengineering and Implementation at HSBC) w arty­ku­le Reducing «Noise» in a Business Process]

Kilka słów o logice dla zainteresowanych

Ważnym ele­men­tem jest tu ​„nie­ste­ty” poję­cie pre­dy­ka­tu, któ­re jest fun­da­men­tem two­rze­nia reguł biz­ne­so­wych (patrz pkt 5.3 Manifestu). W zda­niu ​„Jarek Żeliński jest czło­wie­kiem” poję­cie ​„czło­wiek” jest pre­dy­ka­tem, sło­wo ​„jest” jest funk­cją zda­nio­wą, zaś ​„Jarek Żeliński” jej argu­men­tem. Predykat jest (może być) tak­że nazwą kla­sy (kla­sy­fi­ka­tor: desy­gnu­je gru­pę bytów mają­cych wspól­ne cechy, to zgod­ne z poję­ciem kla­sy w UML, cecha tak­że może być pre­dy­ka­tem, podob­nie jak atry­but kla­sy może być osob­ną klasą).

Możliwe są zda­nia z dwo­ma pre­dy­ka­ta­mi, np. ​„Każdy pra­cow­nik fir­my XXX jest praw­ni­kiem”. Mamy to dwa pre­dy­ka­ty wyma­ga­ją­ce zde­fi­nio­wa­nia w słow­ni­ku pojęć: ​„pra­cow­nik” i ​„praw­nik”. Słowo ​„jest” to funk­cja zda­nio­wa, sło­wo każ­dy to kwantyfikator.

To dla­te­go bar­dzo waż­ne jet two­rze­nie słow­ni­ka pojęć biz­ne­so­wych. Pojęcie to jest ​„to coś” o co nam w danym momen­cie cho­dzi, sło­wo takie jest desy­gna­tem (nazwą tego cze­goś), uży­cie sło­wa wska­zu­je, że ​„wła­śnie to poję­cie mam na myśli”. Jak widać klu­czem jest tu model poję­cio­wy, czy­li zbiór pre­dy­ka­tów i ich zna­czeń. Ważne jest tak­że to, że popraw­ny model poję­cio­wy ma kon­tekst, tu biz­ne­so­wy, dla­te­go defi­ni­cje pojęć powin­ny być two­rzo­ne w tym kon­tek­ście np. defi­ni­cja: czło­wiek to ​„oso­ba doro­sła” zamiast ?isto­ta żywa wyróż­nia­ją­ca się naj­wyż­szym stop­niem roz­wo­ju psy­chi­ki i życia spo­łecz­ne­go? (sł. j.polskiego). Bardzo waż­nym ele­men­tem jest tu tak­że pra­wo ​„wyłą­czo­ne­go środ­ka” w logi­ce, wyra­żo­ne języ­kiem natu­ral­nym brzmi: ​„jeże­li coś jest czymś, to nie jest niczym innym”. Innymi sło­wy, jeże­li coś ​„pasu­je” do okre­ślo­nej defi­ni­cji poję­cia, nie może paso­wać do żad­nej innej (jeże­li defi­ni­cje są popraw­nie zbu­do­wa­ne, tak się zresz­tą testu­je, tu pole­cam spe­cy­fi­ka­cję SBVR OMG (Semantics Of Business Vocabulary And Rules).

Jeżeli to zda­nie jest tak zwa­nym sądem, to zna­czy, że ​„praw­dą jest, że Jarek Żeliński jest czło­wie­kiem” (to zda­nie zawie­ra jeden pre­dy­kat i jeden argu­ment). Sądy, dla ich two­rze­nia, muszą być opar­ta na obser­wo­wal­nych fatach (porów­naj z Manifest pkt. 3.1.). Reguły biz­ne­so­we to wła­śnie tak zwa­ne ​„sądy bazo­we” opi­su­ją­ce daną orga­ni­za­cję (jej zacho­wa­nie się). O sądach bazo­wych i ich budo­wa­niu pisze [[Bertrand Russell]]:

To dla­te­go mię­dzy inny­mi [[logi­ka]] i [[epi­ste­mo­lo­gia]] nie powin­ny być obce dobre­mu analitykowi.