Reguły biznesowe, decyzje i pojęcia

Wprowadzenie

Ten arty­kuł powstał w odpo­wie­dzi na wie­le pytań o regu­ły biz­ne­so­we, defi­ni­cje pojęć w słow­ni­kach pojęć i regu­ły decyzyjne.

W arty­ku­le Tablice decy­zyj­ne a regu­ły biz­ne­so­we pisa­łem o róż­ni­cy pomię­dzy regu­łą a decy­zją. Przypomnę jesz­cze raz defi­ni­cje ze słow­ni­ka j.polskiego (PWN):

regu­ła: <zasa­da postę­po­wa­nia usta­lo­na przez kogoś lub przy­ję­ta na mocy zwyczaju>

decy­zja: <posta­no­wie­nie będą­ce wyni­kiem doko­na­nia wyboru>

idzie­my dalej:

zasa­da: <pra­wo rzą­dzą­ce jaki­miś pro­ce­sa­mi, nor­ma postępowania>

wybór: <wybra­nie jed­nej z kil­ku możliwości>

Kluczem jest tu to, że regu­ła to zasa­da postę­po­wa­nia a decy­zje to kon­kret­ne posta­no­wie­nie, doko­na­nie kon­kret­ne­go wybo­ru w okre­ślo­nej kon­kret­nej sytu­acji. Można więc napi­sać, że regu­ła biz­ne­so­wa to usta­lo­na zasa­da postę­po­wa­nia, zaś decy­zja biz­ne­so­wa to doko­na­nie wybo­ru jed­nej spo­śród dostęp­nych moż­li­wo­ści w kon­kret­nej okre­ślo­nej sytuacji.

Reguły, pojęcia i decyzje biznesowe

We wczo­raj­szym arty­ku­le o zarzą­dza­niu zorien­to­wa­nym na regu­ły biz­ne­so­we poda­łem pewien przykład:

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 (pre­dy­ka­ty), pogru­bie­niem ozna­czo­no poję­cia w słow­ni­ku. Określenie każ­de” jest pre­dy­ka­tem, ele­men­tem zda­nio­twor­czym (doda­nie pre­dy­ka­tu do poję­cia lub połą­cze­nie nim dwóch pojęć two­rzy z nich zda­nie: np. pies to poję­cie, ale pies szcze­ka” lub pies szcze­ka na listo­no­sza” to zda­nia, szcze­ka na” to predykat). 

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 okre­ślo­ne cechy (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). Tak zwa­na atry­bu­to­wa (real­na) defi­ni­cja poję­cia to cechy jakie musi speł­nić coś by zosta­ło uzna­ne za to coś”. Reguły biz­ne­so­we to sądy czy­li dania. Sądem jest np. 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 ele­men­ta­mi rze­czy­wi­sto­ści opi­sy­wa­nej przez to zdanie.

Aby upo­rząd­ko­wać nie­co powyż­sze, bo w tej for­mie fak­tycz­nie może to być nie­ja­sne, posłu­ży­my się defi­ni­cja­mi poda­ny­mi na począt­ku. Popatrzmy jesz­cze raz na zdanie:

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.

Jest to spo­sób postę­po­wa­nia, pomię­to kwan­ty­fi­ka­tor zawsze” bo regu­ła z zasa­dy jest gene­ral­na, więc doty­czy każ­de­go pisma. Więc regu­ła ta znaj­dzie zasto­so­wa­nie i w dzia­le sprze­da­ży w sto­sun­ku np. do napły­wa­ją­cych zapy­tań ofer­to­wych czy rekla­ma­cji, jak też w dzia­le księ­go­wym do obsłu­gi pism z urzę­dów czy innych firm. Ta regu­ła usta­la zacho­wa­nia w całej orga­ni­za­cji, jest napi­sa­na na tyle ogól­nie, by nie zamy­kać” się np. tyl­ko w dzia­le sprze­da­ży, ale na tyle kon­kret­nie, by nie było wąt­pli­wo­ści kie­dy musi być uży­ta. To dla­te­go regu­ły biz­ne­so­we są regu­ła­mi postę­po­wa­nia” a nie regu­ła­mi podej­mo­wa­nia decy­zji”. Decyzja to kon­kret­ne posta­no­wie­nie, zacho­wa­nie się w kon­kret­nej sytu­acji i kon­kret­nych warun­kach. Podejmowanie decy­zji może być opi­sa­ne pro­ce­du­rą, sekwen­cją kro­ków, moż­na je zapi­sać w posta­ci tabli­cy decyzyjnej.

Bardzo waż­ne jest poję­cie ter­min”, jest to defi­ni­cja pozwa­la­ją­ca na zakla­sy­fi­ko­wa­nie cze­goś jako tego co okre­ślo­no nazwą ter­min” (ter­min czy­li poję­cie w słow­ni­ku ter­mi­nów, pojęć). Słownik pojęć to lista ter­mi­nów będą­cych kla­sy­fi­ka­to­ra­mi. Np. ter­min pismo musi mieć defi­ni­cję pozwa­la­ją­ca odróż­niać pisma od nie­pism” a spam od nie­spa­mu”.

Prosty przy­kład:

tabo­ret: mebel mają­cy czte­ry nogi, o wyso­ko­ści nie prze­kra­cza­ją­cej 50 cm

ta defi­ni­cja nie jest może szczy­tem pre­cy­zji ale jej cel jest inny: poka­zać, że złą defi­ni­cją jest

tabo­ret: coś na czym moż­na usiąść

jak nie trud­no się domy­śleć, że usiąść moż­na tak­że na kocu (na sto­le też). Pojęcia z zasa­dy defi­niu­je­my z pomo­cą cech bo kla­sy­fi­ka­cja cze­goś jako cze­goś” musi być nie­za­leż­na od oto­cze­nia i dzia­łań. Taboret jest tabo­re­tem nawet wte­dy gdy nikt w danym przy­pad­ku nie podej­mu­je prób sia­da­nia na nim. Na tej samej zasa­dzie pismo to nie jest coś na co moż­na odpi­sać”, pismo to treść zawie­ra­ją­ca dane nadaw­cy, z któ­rej to tre­ści wyni­ka, że nadaw­ca ocze­ku­je okre­ślo­nej odpo­wie­dzi od adre­sa­ta”. Definicja powsta­ła ad-hoc więc i tu nie sądzę by był to szczyt pre­cy­zji ale zno­wu cho­dzi tu tyl­ko o zasadę.

Gdyby teraz pró­bo­wać spi­sy­wać zasa­dy dobre­go zacho­wa­nia, a zasa­dy postę­po­wa­nia to wła­śnie regu­ły biz­ne­so­we”, to moż­na by napi­sać, że

aby zjeść posi­łek nale­ży usiąść na taborecie”.

Oznacza to, że zjeść kul­tu­ral­nie (regu­ła ta jest tu czę­ścią poli­ty­ki kul­tu­ral­ne­go zacho­wa­nia) to zjeść na sie­dzą­ca a nie na sto­ją­co. Zachowanie opi­sa­ne tą regu­łą ozna­cza koniecz­ność sie­dze­nia na tabo­re­cie. Reguła jest dość restryk­cyj­na: nic poza tabo­re­tem nie wcho­dzi w grę. Lepsza była reguła:

dopusz­cza­my wyłącz­nie kul­tu­ral­ne spo­ży­wa­nie posiłków”

tak zabrzmi ona w języ­ku potocz­nym i na razie nie budzi obaw, bo chy­ba każ­dy czło­wiek rozu­mie­ją­cy język pol­ski wie jak ma się tu zacho­wać. Wie bo zna pew­ne ste­reo­ty­py, np. z grzecz­no­ści nie sia­da się na dywa­nie. Jednak logi­ka oraz potrze­ba jed­no­znacz­no­ści wyma­ga­ją by zapis był peł­ny”, to zna­czy że odrzu­ca­my domy­sły (nie liczy­my na nie). Powyższe zawiera:

  1. poję­cie posi­łek” (zakła­da­my, że nie jest nim np. lizak)
  2. fakt spo­ży­wa­nia”, czy­li to co się wydarzy
  3. funk­cję zda­nio­wą wyłącz­nie”
  4. poję­cie kul­tu­ral­ny spo­sób” (bo moż­na niekulturalnie)

Największy pro­blem będzie z ostat­nim czy­li poję­ciem kul­tu­ral­ny”. W życiu codzien­nym zda­my się na decy­zje intu­icyj­ną, być może bazu­ją­ca na opa­słym porad­ni­ku savo­ir vivre. Jednak w biz­ne­sie będzie­my dąży­li do moż­li­wo­ści wyko­na­nia kon­tro­li, będzie­my chcie­li mieć moż­li­wość zde­cy­do­wa­nia czy kon­kret­ne zacho­wa­nie jest kul­tu­ral­ne czy nie. Może to być np. jeże­li ktoś, ma na sobie gar­ni­tur jeże­li jest męż­czy­zną, lub sukien­kę jeże­li jest kobie­tą, sie­ci przy sto­le, lub stoi gdy stół jest wyso­ki przy­sto­so­wa­ny do spo­ży­wa­nia posił­ków na sto­ją­co, w trak­cie spo­ży­wa­nia nie uży­wa rąk tyl­ko sztuć­ców, w trak­cie spo­ży­wa­nia nie wyda­je dźwię­ków powszech­nie nazy­wa­nych mla­ska­niem i nie ude­rza sztuć­ca­mi o talerz, to zna­czy że ten ktoś spo­ży­wa posi­łek kul­tu­ral­nie”. Ta defi­ni­cja tak­że dale­ka jest od ide­ału ale i tu ma ona za zada­nie zilu­stro­wać tyl­ko spo­sób jej two­rze­nia. Mamy więc do spraw­dze­nia, wie­le czę­sto alter­na­tyw­nych, zda­rzeń (fak­tów) i uznać ich kon­kret­ny zestaw za wła­ści­we. Tych zesta­wów jest wię­cej niż jeden (np. kobie­ta lub męż­czy­zna albo sie­dząc lub sto­jąc). Taką pro­ce­du­rę moż­na udo­ku­men­to­wać tabli­cą decy­zyj­ną. Forma tabli­cy jest znacz­nie czy­tel­niej­sza i znacz­nie łatwiej wychwy­ty­wać wszel­kie powtó­rze­nia i sprzecz­no­ści w porów­na­niu do for­my w posta­ci opi­su słownego.

Tak więc decy­zja to posta­no­wie­nie. Decyzje podej­muj­my uzna­jąc, że coś speł­nia defi­ni­cję poję­cia, decy­zje podej­mu­je­my tak­że wybie­ra­jąc wła­ści­we zacho­wa­nie spo­śród wszyst­kich moż­li­wych. Uznanie, że coś jest czymś to sto­so­wa­nie słow­ni­ka pojęć, tu jest tyl­ko jed­na decy­zja wła­ści­wa (jeden sąd: przed­miot któ­ry widzę to tabo­ret bo jest to [przed­miot mają­cy czte­ry nogi, nie wyż­szy niż 50cm]”). Jednak kie­ru­jąc fak­tu­rę kosz­to­wą do akcep­ta­cji we wła­ści­we miej­sce w fir­mie, mamy wybór, np. bez­po­śred­ni prze­ło­żo­ny lub samo­dziel­na decy­zja (ina­czej dodat­ko­wa akcep­ta­cja nie jest wyma­ga­na): jeże­li fak­tu­ra ma war­tość prze­kra­cza­ją­cą 1000 zł nale­ży ją prze­ka­zać do prze­ło­żo­ne­go, jeże­li jest to jed­nak fak­tu­ra na kwo­tę więk­szą ale doty­czą­cą zaku­pu środ­ka trwa­łe­go, na któ­ry to zakup wyda­no zgo­dę, fak­tu­ra nie wyma­ga dodat­ko­wej akcep­ta­cji, jeże­li jed­nak war­tość fak­tu­ry jest niż­sza niż 1000 zł a doty­czy ona wydat­ków zwią­za­nych z dele­ga­cją, musi być prze­ka­za­na prze­ło­żo­ne­mu do akcep­ta­cji”. Taki zapis zaczy­na być trud­ny w uży­ciu, łatwo coś prze­oczyć i może być nie­spój­ny a nawet sprzecz­ny co będzie bar­dzo trud­ne do wychwy­ce­nia. W takich przy­pad­kach bar­dzo dobrym roz­wią­za­niem jest uży­cie tabli­cy decyzyjnej:

TablicaDecyzyjnaKoszty

Tablica taka zawiera:

  1. skoń­czo­ną listę warun­ków (zda­rzeń) jakich nale­ży się spo­dzie­wać (lub tyl­ko takich na któ­re chce­my reagować)
  2. skoń­czo­ną listę dzia­łań (podej­mo­wa­nych zacho­wań, akcji)
  3. skoń­czo­ną listę reguł, to jest kom­bi­na­cji na któ­re chce­my zare­ago­wać (pod­jąć okre­ślo­ne działanie)

Powyższa tabli­ca pozwa­la wychwy­cić np. to, że nie wprost” kosz­ty dele­ga­cji wcze­śniej zabu­dże­to­wa­ne moż­na roz­li­czyć samo­dziel­nie (to może wyni­kać z nie opi­sa­nych tu reguł zwią­za­nych z pro­ce­sem budże­to­wa­nia czy­li zgo­dy na wyda­tek a prio­ri), Tablica ta może zostać zop­ty­ma­li­zo­wa­na, np. jeże­li wyda­tek jest zabu­dże­to­wa­ny, to pozo­sta­łe warun­ki igno­ru­je­my (tu nie poka­za­no). Tablica taka jest bar­dzo czy­tel­na, czy­tel­niej­sza niż zawi­łe zda­nie opi­su­ją­ce zasa­dy zatwier­dza­na fak­tur kosz­to­wych. Inny przy­kład uży­cia tabe­li decy­zyj­nej tu na stro­nie Visual-Paradigm.

Przyjmowanie faktur kosztowych

Powyższy dia­gram:

  1. zawie­ra ele­men­tar­ne aktyw­no­ści (ato­mo­we pro­ce­sy) czy­li two­rzą­ce pro­dukt biz­ne­so­wy (w odpo­wie­dzi na wej­ścio­we informacje),
  2. każ­da aktyw­ność jest reali­zo­wa­na zgod­nie z wie­dzą posia­da­ną przez wyko­naw­cą, jego zakre­sem obo­wiąz­ków lub wg. pro­ce­du­ry, jeże­li zosta­ła spi­sa­na (pro­ce­du­ra to osob­ny doku­ment, lista kro­ków do obo­wiąz­ko­we­go wyko­na­nia, taka nie­po­dziel­na aktyw­ność to ato­mo­wy pro­ces biz­ne­so­wy), ele­men­tem takiej pro­ce­du­ry jest tu obo­wią­zek odno­to­wa­nia fak­tu­ry i jej sta­tu­su w Rejestrze fak­tur (któ­ry zobra­zo­wa­no na mode­lu jako coś co jest” w fir­mie), tu pod­ję­cie decy­zji o tym czy prze­ka­zać fak­tu­rę prze­ło­żo­ne­mu czy nie, jest opi­sa­ne tabli­cą decy­zyj­ną Zatwierdzanie fak­tur kosz­to­wych, tabli­cę zobra­zo­wa­no powyżej.
  3. Każdy nośnik danych (tu Faktura i Rejestr fak­tur) ma swój wzór tre­ści i jej struk­tu­ry, spo­sób wypeł­nie­nia takie­go nośni­ka może wyni­kać z defi­ni­cji pojęć (np. w polu sta­tus doku­men­tu wpi­su­je­my etap zatwier­dza­nia faktury”)

Dokumentacja tego pro­ce­su zawie­ra: dia­gram (poka­za­ny model pro­ce­su) oraz (nie poka­za­ne) załą­czo­ne pro­ce­du­ry, zakre­sy obo­wiąz­ków, wzo­ry doku­men­tów, regu­ły biz­ne­so­we i słow­nik pojęć. Powyższy model pro­ce­su, w tej posta­ci, pozwa­la na mapo­wa­nie aktyw­no­ści na przy­pad­ki uży­cia. W innej posta­ci (bar­dziej szcze­gó­ło­wej) jest to prak­tycz­nie nie­moż­li­we. Wyobraźmy sobie ten dia­gram z nanie­sio­ny­mi deta­licz­nie kro­ka­mi” podej­mo­wa­nia decy­zji o tym czy daną fak­tu­rę prze­ka­zać prze­ło­żo­ne­mu czy nie… nie mia­łem nawet ambi­cji poka­zać tu takie­go przy­kła­du. Widuję jed­nak takie regu­lar­nie w wie­lu audy­to­wa­nych doku­men­tach i to co rzu­ca się od razu w oczy to błąd pole­ga­ją­cy na «wry­so­wy­wa­niu” w model pro­ce­sy całych drzew decy­zyj­nych, kto­re albo nale­ży zastą­pić tabli­cą decy­zyj­ną albo udo­ku­men­to­wać osob­no jako drze­wo decy­zyj­ne a nie pro­ces biz­ne­so­wy (sto­so­wa­nie drzew decy­zyj­nych w do mode­lo­wa­nia decy­zji biz­ne­so­wych jest jed­nak bar­dzo nieefektywne).

Swego cza­su zosta­łem zapytany:

Dlaczego oddzie­la Pan regu­ły biz­ne­so­we od reguł decy­zyj­nych, regu­ła biz­ne­so­wa nie powie mi jak ma to zro­bić”? Jakie zna­cze­nie ma regu­ła biz­ne­so­wa bez kry­te­riów decy­zyj­nych? (pyta­ją­cy jest programistą).

Powód jest bar­dzo pro­sty: to co tu opi­sa­no to nie model opro­gra­mo­wa­nia” a model orga­ni­za­cji a w tej pra­cu­ją ludzie. Reguła biz­ne­so­wa może być reali­zo­wa­na (i naj­czę­ściej tak jest) przez czło­wie­ka mają­ce­go okre­ślo­ne umie­jęt­no­ści i kom­pe­ten­cje, ten do dzia­ła­nia potrze­bu­je wyłącz­nie reguł biz­ne­so­wych. Dopiero tam gdzie jest ryzy­ko popeł­nie­nia błę­du lub tam gdzie regu­łę ma reali­zo­wać maszy­na (algo­rytm) nale­ży udo­ku­men­to­wać spo­sób (pro­ce­du­rę) podej­mo­wa­nia decy­zji. To natu­ral­ny podział: na sta­no­wi­sko opie­ku­na klien­ta pry­zmu­je­my oso­bę mają­ca za sobą kurs savo­ir vivre, dopie­ro gdy chce­my udo­ku­men­to­wać to jak kie­dy się zacho­wać, opi­sze­my regu­ły decy­zyj­ne, na co dzień decy­zje podej­mu­je czło­wiek sam i robi wedle swo­jej naj­lep­szej wie­dzy co w ogrom­nej więk­szo­ści wypad­ków wystar­czy. Patrz powyż­szy przy­kład z kul­tu­ral­nym spo­ży­wa­niem posił­ków. Oddzielanie zasad postę­po­wa­nia od spo­so­bu podej­mo­wa­nia decy­zji ma głę­bo­ki sens.

Podsumowanie

Analizując i mode­lu­jąc orga­ni­za­cję war­to roze­brać ją” na odręb­ne kloc­ki”, są nimi poję­cia biz­ne­so­we, regu­ły biz­ne­so­we, pro­ce­du­ry postę­po­wa­nia. Te ostat­nie to usta­lo­ne sekwen­cje kro­ków lub tabli­ce decy­zyj­ne. Każde zacho­wa­nie kogoś w orga­ni­za­cji to jakaś aktyw­ność”. Ale aktyw­ność to: zacho­wa­nie się zgod­nie z obo­wią­zu­ją­cą regu­łą, wyko­na­nie pro­ce­du­ry, pod­ję­cie okre­ślo­nej decy­zji. Jeżeli uzna­my, że mode­lo­wa­nie zacho­wa­nia orga­ni­za­cji w posta­ci mode­lu pro­ce­sów pole­ga wyłącz­nie na two­rze­niu dia­gra­mów zawie­ra­ją­cych kolej­no wyko­ny­wa­ne deta­licz­ne czyn­no­ści, to zna­czy że wszel­kie powy­żej opi­sa­ne zacho­wa­nia znaj­dą się jako rów­no­praw­ne” aktyw­no­ści na tych dia­gra­mach. Powstają mon­stru­al­ne nie­czy­tel­ne sche­ma­ty blo­ko­we, zawie­ra­ją­ce set­ki deta­li, trud­ne do inter­pre­ta­cji, trud­ne i kosz­tow­ne w utrzy­ma­niu (aktu­ali­za­cja), i przede wszyst­kim nie pozwa­la­ją­ce na wypro­wa­dze­nie wprost z nich wyma­gań na opro­gra­mo­wa­nie. Można w zasa­dzie zary­zy­ko­wać tezę, że tak two­rzo­ne mode­le, w któ­rych cała wie­dza o orga­ni­za­cji zosta­ła zapi­sa­na jako łań­cu­chy deta­licz­nie zobra­zo­wa­nych czyn­no­ści, tak na praw­dę do nicze­go nie są przydatne.

Tu przy­to­czę frag­ment inne­go moje­go artykułu:

licz­ba moż­li­wych sce­na­riu­szy par­tii sza­chów dla czło­wie­ka jest nie­wy­obra­żal­na jed­nak zasa­dy gry w sza­chy decy­du­ją­ce o tych sce­na­riu­szach miesz­czą się na dwóch stro­nach A4. Podobnie ma się rzecz z więk­szo­ścią gier. Czemu o tym piszę? To co się z dnia na dzień dzie­je w fir­mach i orga­ni­za­cjach to kolej­ne roz­gryw­ki tej samej gry. Reguły są sta­łe: pra­wo i wewnętrz­ne regu­la­cje, licz­ba moż­li­wych sce­na­riu­szy nie­skoń­czo­na? Czemu więc słu­żą żmud­ne wywia­dy, warsz­ta­ty, burze mózgów w toku ana­liz firm? Zaryzykuję, tezę, że nicze­mu nie słu­żą. (Źródło: SBVR czy­li regu­ły biz­ne­so­we i słow­nik | Jarosław Żeliński IT-Consulting)

Dodatek

[2022 – 08-02]

Padają pyta­nia o to jak sobie radzić, bo tych reguł są .. i tu jakaś ogrom­na licz­ba. Gdyby te regu­ły spi­sać jed­na pod dru­gą fak­tycz­nie było by ich dużo, wiec jak zarzą­dzać regu­ła­mi biz­ne­so­wy­mi? Tak samo jak zarzą­dza się Prawem w Państwie: dzie­li­my je na dzie­dzi­no­we gru­py, a w ramach dzie­dzin, na tre­ści któ­rych doty­czą, a są nimi doku­men­ty: for­mu­la­rze i szablony. 

Tu zazna­czę, że for­mu­larz to doku­ment zbu­do­wa­ny z pól czy­li ety­kiet i miej­sca­mi na wpi­sa­nie war­to­ści (może zawie­rać komen­ta­rze). Szablon ma mniej sfor­ma­li­zo­wa­ną struk­tu­rę. Przyjmuje się, że for­mu­larz to w 100% ustruk­tu­ry­zo­wa­ne dane: zawar­tość nazwa­nych pól (ety­kie­ty) to okre­ślo­ne war­to­ści. Natomiast sza­blon to nie­co ogól­niej­sza struk­tu­ra, gdzie w pola, a raczej obsza­ry doku­men­tu, wpi­su­je się okre­ślo­ne nie­struk­tu­ral­ne tre­ści. Oczywiście doku­ment może zawie­rać oba rodza­je pól, np. for­mu­larz opi­su szko­dy będzie zawie­rał pola typu «imię», «nazwi­sko» ale tak­że pole «opis zdarzenia». 

Słownik j. polskiego:

for­mu­larz: blan­kiet doku­men­tu z miej­sca­mi do wypełnienia

sza­blon: for­ma, wzór, według któ­rych wyra­bia się seryj­nie przed­mio­ty (przed­mio­tem może być też dokument)

Oba te poję­cia w języ­ku pol­skim sto­so­wa­ne są czę­sto zamien­nie w sto­sun­ku do doku­men­tów, jed­nak ja będę uży­wał poję­cia for­mu­larz w sto­sun­ku do doku­men­tów któ­rych treść jest sfor­ma­li­zo­wa­na w 100%, oraz sza­blon w sto­sun­ku do pozostałych.

W pro­jek­tach z obsza­ru ana­li­zy biz­ne­so­wej moż­na bez­piecz­nie przy­jąć zało­że­nie, że regu­ły biz­ne­so­we słu­żą wyłącz­nie do stwier­dza­nia popraw­no­ści tre­ści doku­men­tów biz­ne­so­wych, gdyż to osta­tecz­nie jedy­ne pro­duk­ty pro­ce­sów biznesowych. 

Procesy biz­ne­so­we rozu­mia­ne jako model wyko­na­ny z uży­ciem BPMN to prze­pły­wy pra­cy ste­ro­wa­ne albo tre­ścią doku­men­tów (bram­ka danych) albo fak­ta­mi (bram­ka zda­rze­nio­wa) przy czym fak­ty są odno­to­wy­wa­ne (jako treść nowe­go lub ist­nie­ją­ce­go dokumentu). 

Opisane w pierw­szej czę­ści regu­ły biz­ne­so­we to zda­nia twier­dzą­ce (sądy). Jeżeli zgo­dzi­my się, że ety­kie­ty pól doku­men­tów i ich war­to­ści to nazwy (zde­fi­nio­wa­ne poję­cia) to regu­ły biz­ne­so­we są zasa­da­mi okre­śla­nia ich popraw­no­ści (potocz­nie zwa­ne walidacjami).

Algorytm kon­tro­li popraw­no­ści tre­ści doku­men­tu – mecha­nizm kon­tro­li reguł biz­ne­so­wych (regu­ła może łączyć ze sobą róż­ne pola, np. dla klien­tów z Warszawy [pole adres nabyw­cy] upust [pole w linii pro­duk­tu] nie może prze­kra­czać 3%). 

Cechą reguł biz­ne­so­wych jest więc ich nie­za­leż­ność od doku­men­tów i pro­ce­sów. To pro­ce­sy i doku­men­ty są zależ­ne od reguł. Dlatego lista reguł biz­ne­so­wych to for­mal­nie jed­na tabe­la”, jed­nak dla wygo­dy dzie­li­my ją na dzie­dzi­no­we obsza­ry, a na mode­lach może­my, dla wygo­dy czy­ta­ją­ce­go” zobra­zo­wać te, któ­re doty­czą dane­go pro­ce­su biz­ne­so­we­go (BPMN) lub struk­tu­ry doku­men­tu (UML). Wymagana jest tu zade­kla­ro­wa­na kon­wen­cja ich zobra­zo­wa­nia zgod­nie z rozdz. 2.2.3. spe­cy­fi­ka­cji BPMN v.2.0.2. lub pro­fil dla UML. Jest to stan­dar­do­we podej­ście, zgod­ne z MOF (OMG​.org) a np. Visual Paradigm ma wbu­do­wa­ne narzę­dzia do tego.

Jako kon­ty­nu­acje tego wąt­ku pole­cam arty­kuł Reguły biz­ne­so­we i poli­ty­ki jako mecha­nizm dzia­ła­nia orga­ni­za­cji.

Modelowanie biznesowe czyli sterowanie i mechanizmy

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

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

IDEF0
Draft Federal Information Processing Standards Publication 183 1993 December 21 Announcing the Standard for INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0)

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

Model ICOM

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:

Model procesów biznesowych

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;

(źr. http://www.bptrendsassociates.com/)
(źr. http://​www​.bptrend​sas​so​cia​tes​.com/)

Najwyższa 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 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).

Tablice decyzyjne – siła reguł biznesowych

Regularnie widu­ję mon­stru­al­ne dia­gra­my, na któ­rych ich auto­rzy usi­łu­ją mode­lo­wać decy­zje podej­mo­wa­ne w toku prze­pły­wu pra­cy. Pierwsze nie­po­ro­zu­mie­nie (i duży błąd poję­cio­wy) na tych dia­gra­mach, to łącze­nie na jed­nym dia­gra­mie ele­men­tów pro­ce­su biz­ne­so­we­go, z tym jaka pra­ca myślo­wa” wyko­naw­cy ma być w danym pro­ce­sie (aktyw­no­ści) wyko­na­na. Drugi błąd to mie­sza­nie pozio­mów abs­trak­cji: pro­ces biz­ne­so­wy to dość duży poziom ogól­no­ści (uogól­nie­nia), jego celem jest poka­za­nie celo­wo­ści łań­cu­cha pra­cy (pro­ce­sy biz­ne­so­we to aktyw­no­ści two­rzą­ce pro­duk­ty) a nie tego, jak jest w deta­lach wyko­ny­wa­na: wnę­trze tych aktyw­no­ści – ich szcze­gó­ły – na tym pozio­mie są nieistotne.

BPMN-Graphical-Representation-spaghettiKolejną przy­czy­ną powsta­wa­nia tak zwa­nych spa­ghet­ti mode­li” jest ryso­wa­nie” na dia­gra­mach reguł biz­ne­so­wych zamiast powo­ły­wać się na nie. O tym pisa­łem już wcze­śniej (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).

Tak więc osob­na spe­cy­fi­ka­cja reguł biz­ne­so­wych sta­no­wi sys­tem reguł dla całej orga­ni­za­cji. Nie musi­my dzie­siąt­ki razy nano­sić na dia­gra­my sym­bo­li wyja­śnia­ją­cych deta­licz­nie, dla każ­de­go pro­ce­su i roli, że np. fak­tu­ra zaku­po­wa o war­to­ści prze­kra­cza­ją­cej 1000zł musi być dodat­ko­wo zatwier­dzo­na .. i tu ścież­ka zatwier­dzeń, bo takich sytu­acji mogą być w więk­szej fir­mie nawet set­ki. Wystarczy, że raz zde­fi­niu­je­my (lub poma­ga­my ana­li­zo­wa­nej fir­mie zde­fi­nio­wać w toku ana­li­zy i pisa­nia reko­men­da­cji) regu­łę brzmią­ca np. że żaden pra­cow­nik śred­nie­go szcze­bla nie może samo­dziel­nie zatwier­dzać kosz­tów prze­kra­cza­ją­cych dwu­krot­ność jego wyna­gro­dze­nia net­to”. Takiej regu­le w doku­men­ta­cji nada­je­my iden­ty­fi­ka­tor i nazwę, i powo­łu­je­my się na nią w mode­lu pro­ce­sów. Skutek jest taki, że dia­gra­my sta­ją się prost­sze, zaś zmia­na tej regu­ły nie wyma­ga prze­glą­du wszyst­kich mode­li i ich aktu­ali­za­cji, wystar­czy korek­ta w spe­cy­fi­ka­cji tych reguł. Dodatkowo, w przy­pad­ku pisa­nia wyma­gań na opro­gra­mo­wa­nie, wystar­czy załą­czyć spe­cy­fi­ka­cje reguł biz­ne­so­wych zamiast wypi­sy­wać nie raz set­ki tak zwa­nych case­’ów”.

Na pyta­nie klien­tów: ile pra­cy trze­ba żeby utrzy­my­wać aktu­al­ność opra­co­wa­nych mode­li pro­ce­sów biz­ne­so­wych? Odpowiadam: bar­dzo mało, wystar­czy zarzą­dzać regu­ła­mi biz­ne­so­wy­mi a te są w Zarządzaniach Zarządu.

Tablice decy­zyj­ne są kolej­nym narzę­dziem w mode­lo­wa­niu orga­ni­za­cji, z jed­nej stro­ny porząd­ku­ją­cym wie­dzę o niej, z dru­giej uprasz­cza­ją­cą dia­gra­my mode­li pro­ce­sów. Diagramy prze­sta­ją być tak zwa­ny­mi spa­ghet­ti mode­la­mi”, a zaczy­na­ją być zwię­zły­mi, miesz­czą­cy­mi się na stro­nie A4, dia­gra­ma­mi mode­lu­ją­cy­mi pro­ce­sy biz­ne­so­we. Przykładem dość czę­sto spo­ty­ka­ne­go boju ze zło­żo­no­ścią” są pro­ce­sy, w któ­rych poja­wia się rabat. Widuję je na dia­gra­mach mode­lu­ją­cych pro­ce­sy (np. w nota­cji BPMN) jako mon­stru­al­ne drze­wa decy­zyj­ne” i nie­koń­czą­ce się ścież­ki opi­su­ją­ce przy­pad­ki, w któ­rych komuś nale­ży się okre­ślo­ny rabat. O tabli­cach pisa­łem już kil­ka razy, jed­nak tym razem chcia­łem zwró­cić uwa­gę na pew­ną przy­pa­dłość bar­dzo wie­lu pro­jek­tów: utra­ta pano­wa­nia nad zło­żo­no­ścią opi­su (mode­lu) i pły­nię­cie” w tak zwa­ny case mana­ge­ment”. Pierwsze to umiesz­cza­nie na dia­gra­mach wszel­kich pozna­nych szcze­gó­łów wie­dzy o danym pro­ce­sie (mie­sza­nie pozio­mów abs­trak­cji), dru­gi to opi­sy­wa­nie kon­kret­nych przy­pad­ków zamiast poprze­stać na zasa­dach (regu­łach) (do opi­su, zamo­de­lo­wa­nia, gry w sza­chy nale­ży spi­sać tyl­ko regu­ły gry, a nie two­rzyć opi­su setek pozna­nych par­tii, gdzie i tak wszyst­kich moż­li­wych nie opiszemy).

Zamiast opi­sy­wać skom­pli­ko­wa­ne pro­ce­sy decy­zyj­ne” w posta­ci nie­mal­że algo­ryt­mi­za­cji świa­ta” (model pro­ce­su wyglą­da jak roz­bu­do­wa­ne drze­wo decy­zyj­ne z dzie­siąt­ka­mi warian­tów) , lepiej sku­pić się (i poprze­stać) w mode­lu na tym, jakie decy­zje są fak­tycz­nie podej­mo­wa­ne, i na skut­kach”, któ­re mają zna­cze­nie w pro­ce­sie biznesowym.

Bardzo czę­sto mamy do czy­nie­nia z dzie­siąt­ka­mi moż­li­wo­ści, duży­mi ilo­ścia­mi poten­cjal­nych fak­tów, jed­nak obsłu­gi­wa­ne są” (mają zna­cze­nie, reagu­je­my na) tyl­ko nie­któ­re z nich lub ich kom­bi­na­cje. Jak już w innym arty­ku­le wspo­mi­na­łem: ilość moż­li­wych kom­bi­na­cji trzech kolo­rów sygna­li­za­to­ra na krzy­żo­wa­niu jest więk­sza niż kom­bi­na­cje opi­sa­ne (mają­ce zna­cze­nie) w Kodeksie Drogowym, kie­row­ca reagu­je na okre­ślo­ną kom­bi­na­cję, nie ana­li­zu­je w myślach tego, jak mogą być ze sobą sko­ja­rzo­ne poszcze­gól­ne kolo­ry i w jakiej kolej­no­ści się poja­wiać – to zbyt absor­bu­ją­ce. Tak samo dzia­ła” biz­nes: reagu­je­my na kon­kret­ne fak­ty lub ich kom­bi­na­cje, pozo­sta­łe po pro­stu igno­ru­je­my bo nie mają zna­cze­nia, nie ma więc sen­su zaj­mo­wa­nie się nimi i doku­men­to­wa­nie ich (mode­lo­wa­nie).

Przypuśćmy, że nasi klien­ci są podzie­le­ni na czte­ry gru­py doce­lo­we, a do tego każ­dy z nich, zależ­nie od histo­rii obro­tów, może być skla­sy­fi­ko­wa­ny jak Platynowy, Złoty, Srebrny i Ołowiany (:)). I teraz załóż­my, że mamy pro­mo­cję, ta jed­nak obej­mu­je wyłącz­nie klien­tów Srebrnych z seg­men­tu 2, o ile mają sie­dzi­by w woj. Mazowieckim oraz klien­tów Ołowianych z seg­men­tu 3 o ile mają sie­dzi­bę w woj. Podkarpackim. Innymi sło­wy, z pośród setek moż­li­wych kom­bi­na­cji obsłu­gu­je­my wyłącz­nie dwie. Tworzenie dia­gra­mu w spo­sób: czy klient jest Platynowy? Nie, Czy jest Srebrny, Tak, Czy jest z woje­wódz­twa.…… pro­wa­dzi do mega dia­gra­mu. Zamiast tego two­rzy­my pro­stą tabli­cę decy­zyj­ną, któ­ra zawie­ra wyłącz­nie obsłu­gi­wa­ne w pro­ce­sie poje­dyn­cze fak­ty lub ich kom­bi­na­cje (regu­ły) oraz przy­po­rząd­ko­wa­ne im akcje (dzia­ła­nia w posta­ci kon­kret­ne­go upu­stu), nic ponad to (resz­tę kom­bi­na­cji po pro­stu igno­ru­je­my, nie ma potrze­by ich opi­sy­wa­nia). Takie decy­zje są podej­mo­wa­ne w jed­nym kro­ku”. Tak jak kie­row­ca: reagu­je natych­miast na okre­ślo­ną kom­bi­na­cję kolo­rów na sygna­li­za­to­rze, nie ana­li­zu­je tego jakie inne w ogó­le są moż­li­we. Gdyby ktoś z nas zoba­czył na sygna­li­za­to­rze zapa­lo­ne świa­tło czer­wo­ne i zie­lo­ne jed­no­cze­śnie, raczej uzna to za awa­rię i zigno­ru­je, niż zacznie ana­li­zo­wać jak się to ma do innych moż­li­wych kom­bi­na­cji i co ma z tym począć (inny, bar­dziej praw­dzi­wy” przy­kład).

Modele pro­ce­sów, w któ­rych zło­żo­ne decy­zje są mode­lo­wa­ne z uży­ciem reguł biz­ne­so­wych i tablic decy­zyj­nych, a nie z pomo­cą kaskad dzie­siąt­ków bra­mek decy­zyj­nych, są prost­sze w zro­zu­mie­niu, kon­tro­la ich spój­no­ści i popraw­no­ści jest znacz­nie łatwiej­sza. Reguły biz­ne­so­we i tabli­ce decy­zyj­ne pozwa­la­ją na ich bez­po­śred­nią imple­men­ta­cję w apli­ka­cjach, a same dia­gra­my są znacz­nie łatwiej­sze w czy­ta­niu i aktu­ali­za­cji. Ich zło­żo­ność nie zabi­ja wzroku ;).

Tablice decy­zyj­ne, jako narzę­dzie na eta­pie ana­li­zy, pozwa­la­ją tak­że na bar­dzo łatwe wychwy­ty­wa­nie reguł nad­mia­ro­wych, sprzecz­nych i innych pozba­wio­nych sensu.

Na koniec kil­ka obra­zo­wych przy­kła­dów, któ­re nawet dla osób sła­bo zna­ją­cych język angiel­ski powin­ny być łatwe do zrozumienia.

Decision table pro­vi­des a han­dy way to repre­sent busi­ness logic. Check out what is a deci­sion table, what deci­sion table can do and learn how to draw pro­fes­sio­nal deci­sion table with deci­sion table software.
(źr. http://​www​.visu​al​-para​digm​.com/​p​r​o​d​u​c​t​/​a​r​t​i​c​l​e​s​/​d​e​c​i​s​i​o​n​-​t​a​b​l​e​-​e​x​p​l​a​i​n​ed/)

Na zakoń­cze­nie zary­zy­ku­ję tezę, że autor dia­gra­mu nie miesz­czą­ce­go się na stro­nie A4, utra­cił pano­wa­nie na zło­żo­no­ścią pro­jek­tu.… i dia­gram pły­nie w stro­nę tale­rza spaghetti…

Tablice decyzyjne

Po dłu­gich poszu­ki­wa­niach w anty­kwa­ria­tach mam: Tablice decy­zyj­ne . Książka opi­su­je tabli­ce decy­zyj­ne jako narzę­dzie do mode­lo­wa­nia zacho­wa­nia sys­te­mów deterministycznych. 

Tablice te w peł­ni zastę­pu­ją znacz­nie bar­dziej skom­pli­ko­wa­ne drze­wa decy­zyj­ne, mode­lu­ją decy­zję (jej pod­ję­cie) jako jeden fakt a nie zło­żo­ny, kaska­do­wy pro­ces decy­zyj­ny . W dal­szej opis two­rze­nia i czę­ści przy­kła­dy uży­cia takich tablic.

Tablica decyzyjna

Odpowiadając na pyta­nia pod arty­ku­łem Tablice decy­zyj­ne ? fak­ty a nie pro­ce­sy, napi­sa­łem mię­dzy inny­mi, że regu­ła biz­ne­so­wa to nie regu­ła decy­zyj­na. Jeden z czy­tel­ni­ków podał jako przy­kład regu­ły biz­ne­so­wej wybór zwro­tu do osoby:

  • Płeć: męż­czy­zna ? powi­ta­nie: Pan;
  • Płeć: kobie­ta oraz Stan: mężat­ka ? powi­ta­nie: Pani;
  • Płeć: kobie­ta oraz Stan: wol­ny ? powi­ta­nie: Panna;

Powyższe to zbiór decy­zji podej­mo­wa­nych w odpo­wie­dzi na okre­ślo­ne zda­rze­nie. Takie decy­zje (i regu­ły ich podej­mo­wa­nia) moż­na zapi­sać w posta­ci tabli­cę decy­zyj­nej, powyż­sze nie jest regu­łą biz­ne­so­wą. Regułą biz­ne­so­wą było by: ?w listach adre­so­wa­nych imien­nie zawsze poprze­dza się imię i nazwi­sko oso­by wła­ści­wym zwro­tem grzecz­no­ścio­wym?. Reguły biz­ne­so­we to regu­ły zacho­wa­nia (się) systemu.

Powyższe to sys­tem podej­mo­wa­nia decy­zji o tym, jaki to powi­nien być zwrot. Jest to o tyle istot­ne, że regu­ła biz­ne­so­wa, jako regu­ła zacho­wa­nia, w nie­zmie­nio­nym brzmie­niu może obo­wią­zy­wać np. wszyst­kie oddzia­ły fir­my w innych kra­jach, ale tabli­ca decy­zyj­na to pro­ce­du­ra doko­na­nia wybo­ru wła­ści­we­go zwro­tu, będzie inna dla każ­de­go kra­ju (a kon­kret­nie każ­de­go języ­ka). Poniżej tabli­ca decy­zyj­na dla tego przy­kła­du (dla j.polskiego ;)):

DecyzjaPanPaniPanna

Tablica ta zosta­ła pod­da­na nor­ma­li­za­cji, to jest usu­nię­to waru­nek Jest płci męskiej, gdyż wiersz ten zawie­rał pro­stą nega­cje wier­sza Jest płci żeń­skiej (zakła­da­my, że nie roz­pa­tru­je­my rodza­ju nija­kie­go). Tablica taka (po nor­ma­li­za­cji) jest, jak widać, prost­sza od trzech warun­ków z przy­kła­du opi­so­we­go” sys­te­mu decy­zji. Powyższa tabli­ca jest tabli­ca zupeł­ną (wyszcze­gól­nio­no wszyst­kie kom­bi­na­cje Warunków) wiec moż­na jej użyć do auto­ma­ty­za­cji pro­ce­su np. adre­so­wa­nia kore­spon­den­cji (wię­cej o tym w dal­szej czę­ści). Wersja rów­no­waż­na uprosz­czo­na tej samej tablicy:

TabDecUprZwrot

Proponuję czy­tel­ni­kom same­mu zna­leźć zasa­dę doko­na­ne­go uprosz­cze­nia :). Ciekawe omó­wie­nie i przy­kła­dy tablic decyzyjnych:

Przykład korzy­ści z uży­cia tablic decy­zyj­nych zamiast opisu:

https://​www​.visu​al​-para​digm​.com/​p​r​o​d​u​c​t​/​a​r​t​i​c​l​e​s​/​d​e​c​i​s​i​o​n​-​t​a​b​l​e​-​e​x​p​l​a​i​n​ed/

Reguły biznesowe a reguły decyzyjne

W grud­niu ubie­głe­go roku pisałem:

Bardzo czę­sto spo­ty­kam się z ogrom­ną zło­żo­no­ścią (licz­ba i ich podzia­ły) wyma­gań. Problem tkwi nie raz w tym, że ?naro­sła? przez lata ?ster­ta zarzą­dzeń?, któ­ra zamiast zostać naj­pierw upo­rząd­ko­wa­na, jest ?wprost? trak­to­wa­na jako ?wyma­ga­nia?. Takie podej­ście to krok w stro­nę klę­ski pro­jek­tu. (Reguły biz­ne­so­we ? pro­jekt zabi­ja ich bez­sen­sow­na ilość? ).

W tam­tym tek­ście nie opi­sa­łem jed­nak o róż­ni­cy pomię­dzy regu­łą a decy­zją. Przyszła pora i na to.

Postaram się zwró­cić uwa­gę na to, że mode­lo­wa­nie biz­ne­so­we z peł­nym zro­zu­mie­niem, to nie suchy zapis wie­dzy pozy­ska­nej w roz­mo­wach czy wywia­dach. To dąże­nie do zro­zu­mie­nia. Powyższe poka­zu­je, że jest róż­ni­ca pomię­dzy regu­łą a decy­zją, nawet jeże­li ta dru­ga jest naka­za­na” tą pierw­szą. Czy to ważne?

Wiele firm ma pro­ble­my zarząd­cze nie dla­te­go, że są źle zarzą­dza­ne, ale dla­te­go, że sto­pień zło­żo­no­ści tych firm jest zbyt duży by podej­mo­wać je na wyczu­cie. W obec­nych cza­sach decy­zje muszą być podej­mo­wa­ne w rela­tyw­nie krót­kim cza­sie bo rynek nie cze­ka, jed­nak jakość tych decy­zji nie powin­na być zła. Dlaczego bywa zła? Bo decy­zje są nie raz podej­mo­wa­ne z nie­peł­nym zro­zu­mie­niem sytu­acji. Podejmowana decy­zja, by była moż­li­wie naj­lep­sza, wyma­ga peł­ne­go zro­zu­mie­nia, tego cze­go doty­czy (co chy­ba nie jest dziw­ne). Jeżeli doty­czy fir­my, nie powin­no się podej­mo­wać decy­zji bez peł­ne­go zro­zu­mie­nia poten­cjal­ne­go wpły­wu tej decy­zji na fir­mę. W prze­ciw­nym wypad­ku skut­ki są dość loso­we, czy­li nie zarzą­dza­my a sta­ra­my się zarządzać.

Przytoczony na począt­ku przy­kład doty­czą­cy zwro­tów grzecz­no­ścio­wych, poka­zu­je cien­ką gra­ni­cę pomię­dzy regu­łą a decy­zją. Jak zwy­kle u mnie ;), naj­pierw patrzy­my do słow­ni­ka j.polskiego (PWN):

regu­ła: <zasa­da postę­po­wa­nia usta­lo­na przez kogoś lub przy­ję­ta na mocy zwyczaju>

decy­zja: <posta­no­wie­nie będą­ce wyni­kiem doko­na­nia wyboru>

idzie­my dalej:

zasa­da: <pra­wo rzą­dzą­ce jaki­miś pro­ce­sa­mi, nor­ma postępowania>

wybór: <wybra­nie jed­nej z kil­ku możliwości>

Mamy bazę poję­cio­wą. Można więc napi­sać, że regu­ła biz­ne­so­wa to usta­lo­na zasa­da postę­po­wa­nia, zaś decy­zja biz­ne­so­wa to doko­na­nie wybo­ru jed­nej spo­śród zna­nych moż­li­wo­ści wybo­ru. Nie jest to to samo, co, mam nadzie­ję, obra­zu­je przy­kład ze zwro­ta­mi grzecz­no­ścio­wy­mi. Tak więc obli­ga­to­ryj­ne uży­wa­nie zwro­tów grzecz­no­ścio­wych to obo­wią­zu­ją­ca zasa­da – regu­ła biz­ne­so­wa (zacho­wa­nie). Wybór wła­ści­we­go zwro­tu spo­śród zna­nych moż­li­wych, to decy­zja o wybo­rze. Może być ona wyni­kiem wie­dzy posia­da­nej lub udo­ku­men­to­wa­nej (w posta­ci np. tabli­cy decyzyjnej).

Proszę zwró­cić uwa­gę, że jeże­li regu­ła decy­zyj­na nie jest oczy­wi­sta to war­to ją narzu­cić” w fir­mie, wte­dy wybór wła­ści­we­go zwro­tu jest już ele­men­tem pew­nej wie­dzy fir­mo­wej. Tę wie­dzę jed­nak moż­na posia­dać lub nie. Jeżeli tyl­ko ist­nie­je ryzy­ko wybo­ru (przez np. pra­cow­ni­ków) złej for­my grzecz­no­ścio­wej, to nale­ży ją wła­śnie z góry narzu­cić (tabli­ca decy­zyj­na czy­li wie­dza udo­ku­men­to­wa­na). W przy­pad­ku imple­men­to­wa­nia tego mecha­ni­zmu, np. w sys­te­mie CRM, musi­my tę wie­dzę udo­ku­men­to­wać w spo­sób jed­no­znacz­ny, a do takich wła­śnie spo­so­bów nale­ży narzę­dzie jakim jest tabli­ca decyzyjna.

Analiza firmy

Po co się robi ana­li­zy biz­ne­so­we orga­ni­za­cji? Nie po to by zapi­sać set­ki stron! Analizę pro­wa­dzi­my by zro­zu­mieć te ana­li­zo­wa­ne orga­ni­za­cje. Po co? By następ­ne podej­mo­wa­ne decy­zje byłe mniej ryzy­kow­ne, bar­dziej świa­do­me. Taką decy­zją jest wpro­wa­dze­nie zmia­ny orga­ni­za­cyj­nej, okre­śle­nie wyma­ga­nia na opro­gra­mo­wa­nie, zawar­cie nowej umo­wy anga­żu­ją­cej zaso­by orga­ni­za­cji, wie­le innych.

Podejmijmy pró­bę upo­rząd­ko­wa­nia opi­sa­nych tu pojęć:

reguły a decyzje i procesy

Diagram ten (tzw. dia­gram fak­tów dla sys­te­mu poję­cio­we­go, słu­ży mię­dzy inny­mi do testo­wa­nia spój­no­ści sys­te­mu poję­cio­we­go – prze­strze­ni nazw) poka­zu­je (mam nadzie­ję jasno) poję­cia i wią­żą­ce je fak­ty (kształ­to­wa­nie, two­rze­nie cze­goś itp. to fak­ty zwią­za­ne z tymi poję­cia­mi). Zaznaczyłem dodat­ko­wo linię podzia­łu (kre­ska prze­ry­wa­na) pomię­dzy tym co jest opi­sem (mode­lem) pro­ce­su (spe­cy­fi­ka orga­ni­za­cji) oraz tym cze­go ocze­ku­je się od zaan­ga­żo­wa­nych zaso­bów. Nietrudno się domy­ślić, że regu­ły biz­ne­so­we to zasa­dy orga­ni­za­cyj­ne, spe­cy­ficz­ne dla niej. Decyzje to pra­ca ludzi, któ­rzy tych zasad muszą prze­strze­gać a decy­zje te muszą, w związ­ku z tym, być podejmowane.

Obecnie nie raz pla­nu­je­my auto­ma­ty­za­cję wybra­nych czyn­no­ści. Na czym ona pole­ga? Na tym, że tam gdzie regu­ły decy­zyj­ne moż­na opi­sać w posta­ci zupeł­nej (zna­my wszyst­kie moż­li­we sytu­acje i przy­po­rząd­ko­wu­je­my im kon­kret­ne decy­zje – [[tabli­ca decy­zyj­na zupeł­na]]), moż­na sobie pozwo­lić na zastą­pie­nie czło­wie­ka maszy­ną. Tą maszy­ną może być oczy­wi­ście np. kom­pu­ter i odpo­wied­nie oprogramowanie.

Proszę zwró­cić tak­że uwa­gę na to, że linia podzia­łu pomię­dzy pro­ce­sa­mi a zaso­ba­mi to tak­że linia podzia­łu pomię­dzy pro­ce­sa­mi a ich imple­men­ta­cją. Podział zna­ny już z poniż­sze­go dia­gra­mu (źr. http://​www​.bptrend​sas​so​cia​tes​.com/):

Na zakończenie

Analiza biz­ne­so­wa orga­ni­za­cji poprze­dza­ją­ca np. wdro­że­nie nowe­go opro­gra­mo­wa­nia, powin­na pole­gać na wyko­na­niu audy­tu i upo­rząd­ko­wa­niu reguł decy­zyj­nych oraz opra­co­wa­niu mode­li pro­ce­sów biz­ne­so­wych by je zwe­ry­fi­ko­wać. Drugi krok to oce­na, jakiej wie­dzy ocze­ku­je­my od ludzi (ich umie­jęt­no­ści i wie­dza). Dokumentujemy ją z oba­wy przed błę­dem ludz­kim”. Tu zwra­cam uwa­gę na to, że wyma­ga­niem na opro­gra­mo­wa­nie może być tabli­ca decy­zyj­na, jeże­li pla­nu­je­my auto­ma­ty­za­cję jakiejś czyn­no­ści. Proces biz­ne­so­wy nie jest wyma­ga­niem, to co naj­wy­żej kon­tekst wyko­ny­wa­nych czynności.

Know-how

Swego cza­su, w arty­ku­le o mode­lo­wa­niu pro­ce­sów biz­ne­so­wych napi­sa­łem, że:

Biznesowy know-how ? naj­cen­niej­szą rzecz w fir­mie. I po to war­to wyko­nać ana­li­zą biz­ne­so­wą: poznać i udo­ku­men­to­wać swo­ją prze­wa­gę czy­li fir­mo­we know-how. (Modelowanie biz­ne­so­we c.d. ? know-how, gdzie ono jest?).

Jednym z klu­czo­wych ele­men­tów owe­go know-how jest wła­śnie wie­dza będą­ca wyni­kiem zbie­ra­ne­go doświad­cze­nia. Znajomość swo­jej histo­rii i wycią­ga­ne z niej wnio­ski to bar­dzo czę­sto wie­dza o tym, któ­re decy­zje jakie skut­ki dla fir­my przy­nio­sły. Kolekcjonowanie tej wie­dzy to nic inne­go jak budo­wa­nie i kon­ser­wo­wa­nie” tablic decy­zyj­nych. Typowym przy­kła­dem takich pil­nie strze­żo­nych tablic są sys­te­mu sco­rin­go­we ban­ków i ubez­pie­czy­cie­li, sys­te­my oce­ny wia­ry­god­no­ści kon­tra­hen­tów i wie­le innych. Nie nale­ży zapo­mi­nać, że sys­te­my decy­zyj­ne wyma­ga­ją okre­śle­nia reguł (biz­ne­so­wych) mówią­cych kie­dy je stosować.

Jeszcze o systemach

Dla przy­po­mnie­nia przy­to­czę pro­stą defi­ni­cje systemu:

System ? obiekt fizycz­ny lub abs­trak­cyj­ny, w któ­rym moż­na wyod­ręb­nić zespół lub zespo­ły ele­men­tów wza­jem­nie powią­za­nych w ukła­dy, reali­zu­ją­cych jako całość funk­cję nad­rzęd­ną lub zbiór takich funk­cji (funk­cjo­nal­ność). Z uwa­gi na fakt, że wyod­ręb­nie­nie wszyst­kich ele­men­tów przy­na­le­żą­cych do sys­te­mu bywa w prak­ty­ce nie­kie­dy bar­dzo trud­ne, dla­te­go do bada­nia sys­te­mów wyko­rzy­stu­je się ich uprosz­czo­ne mode­le. Elementy przy­na­le­żą­ce do jed­ne­go sys­te­mu nie mogą jed­nak sta­no­wić jed­no­cze­śnie ele­men­tów przy­na­leż­nych do inne­go sys­te­mu (na pod­sta­wie: Bertalanffy, L. von, Ogólna teo­ria sys­te­mów. Podstawy, roz­wój, zasto­so­wa­nia. PWN, Warszawa 1984).

Tu, orga­ni­za­cje, bada­nym sys­te­mem są zaso­by i tre­ści jakie są w nich prze­twa­rza­ne czy­li wza­jem­nie powią­za­ni ludzie, maszy­ny i doku­men­ty. Organizacje np. na ryn­ku, to tak­że sys­tem, sys­tem nad­rzęd­ny, któ­ry tak­że nale­ży rozu­mieć. Ten mode­lu­je­my jed­nak na eta­pie ana­li­zy stra­te­gii np. ryn­ko­wej. Po co to wszyst­ko? Poprawny model zbu­do­wa­ny sfor­ma­li­zo­wa­ny­mi meto­da­mi to narzę­dzie podej­mo­wa­nia decy­zji, tym lep­szych im lep­szy model.

Nie jest to, mode­lo­wa­nie, łatwe jak widać. Wymaga, poza samą umie­jęt­no­ścią ana­li­zy i sfor­ma­li­zo­wa­ne­go jej doku­men­to­wa­nia, tak­że duże­go doświad­cze­nia oraz zna­jo­mo­ści i rozu­mie­nia pro­ce­su zarzą­dza­nia orga­ni­za­cją. Tam gdzie dana orga­ni­za­cja jest pod­mio­tem ryn­ko­wym, tak­że zasad rzą­dzą­cych rynkiem.

Najważniejsze w tym jest to, że samo udo­ku­men­to­wa­nie cze­goś np. na pod­sta­wie czy­je­goś opi­su, bez spraw­dze­nia czy opis jest jed­no­znacz­ny, nie ma w nim sprzecz­no­ści i czy jest zupeł­ny (opi­su­je wszyst­ko), nie nie­sie żad­nej war­to­ści, a nie raz nawet wpro­wa­dza w błąd.

TabliceDecyzyjnePWN1971

(UWAGA! Artykuł to część mojej pra­cy nauko­wej, wszel­kie pra­wa do jego tre­ści są zastrze­żo­ne, wni­kli­wym ana­li­ty­kom do poczy­ta­nia: Solomon L. Pollack, Harry T. Hicks, Jr, William J. Harrison: Tablice decy­zyj­ne, PWN Warszawa 1975).

Literatura

Vasilecas, O., & Smaizys, A. (2007). Business Rule Based Configuration Management and Software System Implementation Using Decision Tables. Local Proceedings of ADBIS, 2007, 27 – 37.
Pollack, S. L., Hicks, H. T., & Harrison, W. J. (1975). Tablice decy­zyj­ne. PWN.
Vanthienen, J. A. N., & Dries, E. (1992). Developments in deci­sion tables: Evolution, appli­ca­tions and a pro­po­sed stan­dard. DTEW Research Report 9227.
Vanthienen, J., & Wets, G. (1992). Mapping Decision Tables to Expert System Shells: An Implementation in AionDS. Onderzoeksrapport 9228.
zmiany vs. stagnacja

Tablice decyzyjne – fakty a nie procesy

O regu­łach biz­ne­so­wych już nie raz tu napi­sa­łem, mię­dzy inny­mi to, że

Regułą biz­ne­so­wą jest ogra­ni­cze­nie spe­cy­ficz­ne dla danej orga­ni­za­cji, zde­fi­nio­wa­ne dla całe­go jej obsza­ru funk­cjo­no­wa­nia. (Reguły biz­ne­so­we ? czym są?).

Jednym z punk­tów Business Rules Manifesto jest bar­dzo waż­ny zapis: Reguły nie są pro­ce­sa­mi ani pro­ce­du­ra­mi”, o któ­rym tak­że już wspo­mi­na­łem, a wie­lu mode­lu­ją­cych pro­ce­sy zapo­mi­na o tym. Dzięki tej zasa­dzie”, mode­le (dia­gra­my) pro­ce­sów sta­ją się prost­sze i przy­swa­jal­ne. Przyszła kolej na kolej­ne waż­ne uprosz­cze­nie”.

Tablice decyzyjne

Cóż to takiego?

Tablice decy­zyj­ne sta­no­wią, jed­ną z pod­sta­wo­wych tech­nik sto­so­wa­nych w roz­wią­zy­wa­niu pro­ble­mów i podej­mo­wa­niu decy­zji. Dzięki tabli­com decy­zyj­nym moż­na w zwię­zły spo­sób okre­ślić, przy speł­nie­niu z góry okre­ślo­nych warun­ków, jakie czyn­no­ści nale­ży pod­jąć. Tablica decy­zyj­na jest okre­ślo­ną struk­tu­rą opi­su zbio­ru zwią­za­nych ze sobą reguł decy­zyj­nych. (Tablica decy­zyj­na ? Encyklopedia Zarządzania).

Z per­spek­ty­wy mate­ma­ty­ki” war­to wie­dzieć, że tabli­ce decy­zyj­ne to łatwa dro­ga do uprosz­cze­nia opi­sów logi­ki zacho­wań systemu:

Decision tables are a pre­ci­se yet com­pact way to model com­pli­ca­ted logic. (Decision table – Wikipedia, the free encyc­lo­pe­dia).

I bar­dzo waż­ne: regu­ła decy­zyj­na to nie regu­ła biz­ne­so­wa. Ale naj­pierw pro­sty przykład:

Tablica decyzyjna

Tablica decy­zyj­na skła­da się z:

  1. Listy ele­men­tar­nych warun­ków (testów). 
  2. Listy ele­men­tar­nych, moż­li­wych do pod­ję­cia działań.
  3. Tablicy testów – regu­ły decyzyjne.
  4. Tablicy dzia­łań – zacho­wa­nia w odpo­wie­dzi na speł­nio­ne reguły.

Reguły muszą się wza­jem­nie wyklu­czać (jeże­li dopusz­cza­my jed­no­cze­sne zapa­le­nie się świa­teł żół­te­go i czer­wo­ne­go jest to kolej­na, czwar­ta regu­ła czy­li czwar­te inter­pre­to­wa­ne zda­rze­nie). Wystąpienie sytu­acji speł­nia­ją­cej regu­ły, to zdarzenia.

Warto zwró­cić uwa­gę na fakt, że kom­bi­na­cji trzech kolo­rów jest wię­cej, obsłu­gu­je­my” (reagu­je­my na) jed­nak jedy­nie część z nich. Ogólna zasa­da jest taka, że kom­bi­na­cje nie­udo­ku­men­to­wa­ne są igno­ro­wa­ne, jed­nak w warun­kach np. biz­ne­so­wych, chro­ni­my się nie raz przez bez­czyn­no­ścią usta­na­wia­jąc np. regu­łę, jeże­li żad­ne z tych to…” (albo two­rzy­my tak zwa­na tabli­ce zupeł­ną). Często jed­nak dopusz­cza­my brak dzia­ła­nia”, bo gdy na skrzy­żo­wa­niu zapa­lą się jed­no­cze­śnie świa­tło zie­lo­ne i czer­wo­ne, raczej zigno­ru­je­my taki sygnał trak­tu­jąc go jako awa­rię systemu.

Powyższy przy­kład to zestaw dozwo­lo­nych zacho­wań na skrzy­żo­wa­niu o ruchu kie­ro­wa­nym sygna­li­za­cją świetl­ną. Przykład pro­sty ale pro­szę sobie wyobra­zić, że widu­ję mode­le pro­ce­sów biz­ne­so­wych, na któ­rych podob­ne regu­ły” są mode­lo­wa­ne z pomo­cą bra­mek decy­zyj­nych i prze­pły­wów. Nie podej­mę się tu nawet nary­so­wa­nia tego jako przy­kła­du, zda­ję się na Państwa wyobraźnię :).

Tak więc, regu­ły biz­ne­so­we to ogól­no-orga­ni­za­cyj­ne ogra­ni­cze­nia. Tablice decy­zyj­ne to rodzaj wie­dzy” wpi­sa­nej w punk­ty podej­mo­wa­nia decy­zji. Na mode­lach (dia­gra­mach) pro­ce­sów biz­ne­so­wych mode­lu­je­my jedy­nie skut­ki, czy­li reak­cje na pod­ję­te – zgod­nie z tabli­cą – decyzje.

Użycie opi­sa­nej tabli­cy na dia­gra­mie np. BPMN, pole­ga­ło by na uży­ciu bram­ki XOR z czte­re­ma wyj­ścia­mi, każ­de wyj­ście repre­zen­to­wał by wiersz Działań. Jak widać spo­dzie­wać się nale­ży tu bra­mek XOR (alter­na­ty­wa wyłącz­na) lub OR (alter­na­ty­wa zwy­kła”). Na dia­gra­mach BPMN za bram­ką były­by czyn­no­ści nazwa­ne tak jak dzia­ła­nia w wier­szach. Aby nie kom­pli­ko­wać nazew­nic­twa tych dia­gra­mów, tabli­ca decy­zyj­na uży­ta z dia­gra­mem BPMN mia­ła by wier­sze Działań nazwa­ne np. odpo­wied­nio Wariant‑1, Wariant‑2 itd. a czyn­no­ści były by umiesz­czo­ne już na diagramie.

Tego typu tabli­ce dosko­na­le nada­ją się do mode­lo­wa­nia sys­te­mów raba­to­wych, lojal­no­ścio­wych, war­to­ści kre­dy­tów kupiec­kich, wag sco­rin­gu kre­dy­tów i wie­lu innych, w któ­rych kom­bi­na­cje skoń­czo­nej licz­by czyn­ni­ków two­rzą deter­mi­ni­stycz­ną, skoń­czo­ną licz­bę dopusz­czal­nych zacho­wań. Na dia­gra­mie pro­ce­su powo­łu­je­my się wyłącz­nie na nazwę tabli­cy (np. koja­rząc ją z kon­kret­ną czyn­no­ścią) zamiast mode­lo­wać skom­pli­ko­wa­ne prze­bie­gi. Dlaczego? Bo war­to pamię­tać, że

decy­zja – nawet bar­dzo skom­pli­ko­wa­na – nie jest pro­ce­sem a zaist­nia­łym fak­tem, odpo­wie­dzią na zasta­ne warunki

Jak widać, reak­cja kie­row­cy na sygna­li­za­tor, to nie pro­ces a fakt. Jest to kon­kret­na reak­cja na kon­kret­ną kom­bi­na­cję kolo­rów świa­teł na sygnalizatorze.

W przy­pad­ku ana­li­zy wyma­gań, sto­so­wa­nie tablic decy­zyj­nych, jako narzę­dzia spe­cy­fi­ko­wa­nia pew­nych zacho­wań sys­te­mu, jest bar­dzo wygod­ne bo po pierw­sze: jest jed­no­znacz­ne, po dru­gie tabli­ce decy­zyj­ne to już stan­dar­do­we narzę­dzie w inży­nie­rii opro­gra­mo­wa­nia i nie trze­ba wymy­ślać ich imple­men­ta­cji (sto­su­je się np. maszy­nę sta­no­wą: regu­ły to zda­rze­nia a dzia­ła­nia do przej­ścia). Tablice te jed­nak, by je popraw­nie two­rzyć, wyma­ga­ją wni­kli­wej ana­li­zy i wie­dzy z zakre­su logi­ki. Zapewne jesz­cze o nich tu napiszę.

(war­to mieć narzę­dzie CASE wspie­ra­ją­ce budo­wa­nie tablic decy­zyj­nych i koja­rze­nie ich z mode­la­mi pro­ce­sów czy mode­la­mi dzie­dzi­ny, pakiet Visual-Paradigm ma takie narzędzie)

(na pod­sta­wie: Solomon L. Pollack, Harry T. Hicks, Jr, William J. Harrison: Tablice decy­zyj­ne, PWN Warszawa 1975, oraz: Tablice decy­zyj­ne | | Jarosław Żeliński IT-Consulting)