Tablice decyzyjne – siła reguł biznesowych

Regularnie widuję monstrualne diagramy, na których ich autorzy usiłują modelować decyzje podejmowane w toku przepływu pracy. Pierwsze nieporozumienie (i duży  błąd pojęciowy) na tych diagramach, to łączenie na jednym diagramie…

Czytaj dalej Tablice decyzyjne – siła reguł biznesowych

Tablice decyzyjne

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

[…] 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.

Czytaj dalej Tablice decyzyjne

Tablice decyzyjne – fakty a nie procesy

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.

Gdyby mode­lo­wać powyż­sze na dia­gra­mie np. BPMN, mie­li­by­śmy bram­kę 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 (np. w posta­ci maszy­ny sta­no­wej: regu­ły to zda­rze­nia a dzia­ła­nia do przejścia).

Czytaj dalej Tablice decyzyjne – fakty a nie procesy

Gdzie się realizują wymagania

Bardzo czę­sto spo­ty­kam, pew­nie nie ja jeden, spe­cy­fi­ka­cje wyma­gań zawie­ra­ją­ce zapi­sy ocze­ki­wań użyt­kow­ni­ków”. Bardzo czę­sto sły­szę tak­że, że to przy­szły użyt­kow­nik opro­gra­mo­wa­nia powi­nien być źró­dłem wyma­gań. nic bar­dziej błęd­ne­go.. […] Więc np. wyma­ga­nie sys­tem powi­nien pozwa­lać na budo­wa­nie dowol­nych raba­tów sprze­da­ży do sta­łych klien­tów” (tak­że cytat z pew­nej spe­cy­fi­ka­cji sys­te­mu CRM) jest pustym stwier­dze­niem. Po pierw­sze jak te raba­ty są nali­cza­ne, po dru­gie czy aby na pew­no mecha­nizm pozwa­la na dowol­ne raba­ty”… Jak to opi­sać? Tu powin­ny się poja­wić np. tabli­ce decy­zyj­ne a nie lako­nicz­ne dowol­ne rabaty”.

Na zakoń­cze­nie uwa­ga: jeże­li pla­nu­je­my kupić goto­we opro­gra­mo­wa­nie, to ono już (gdzieś tam) ist­nie­je, i spe­cy­fi­ko­wa­nie szcze­gó­łów opi­su­ją­cych dokład­nie ele­men­ty pra­cy z inter­fej­sem użyt­kow­ni­ka i enig­ma­tycz­ne opi­sy tego jak sys­tem liczy”, jest bez­war­to­ścio­we. Raczej wywo­ła listę tak zwa­nych kasto­mi­za­cji (zwa­nych gdzie­nie­gdzie zabój­ca­mi pro­jek­tów :)). Tak jed­nak wła­śnie wyglą­da­ją naj­czę­ściej spe­cy­fi­ka­cje pisa­ne ręka­mi przy­szłych użyt­kow­ni­ków: opi­szą oni to z czym się sty­ka­ją i co zna­ją ale w ogó­le nie opi­szą wnę­trza, któ­re­go naj­czę­ściej po pro­tu nie rozu­mie­ją (i nie muszą bo to nie ich rola), wte­dy spe­cy­fi­ka­cje sys­te­mów CRM pisa­ne ręka­mi przy­szłych użyt­kow­ni­ków – np. sprze­daw­ców – zawie­ra­ją wła­śnie bez­war­to­ścio­we zapi­sy w rodza­ju: sys­tem powi­nien pozwa­lać na budo­wa­nie dowol­nych raba­tów sprze­da­ży do sta­łych klien­tów” a nie zawie­ra­ją opi­su jak te raba­ty wyliczać.
Odpowiadając na tytu­ło­we pyta­nie: wyma­ga­nia (funk­cjo­nal­ne) reali­zu­ją się w mode­lu dzie­dzi­ny sys­te­mu, któ­re­go nie zawie­ra więk­szość zna­nych spe­cy­fi­ka­cji wyma­gań… a warun­kiem popraw­ne­go wybo­ru opro­gra­mo­wa­nia są ocze­ki­wa­nia co do efek­tów przetwarzania.

Czytaj dalej Gdzie się realizują wymagania

System Analizy Strukturalnej

Structured System Analysis tools & techniques by Chris Gane and Trish Sarson Dzisiaj nieco archeologii. Właśnie upolowałem książkę jak poniżej : Jednym z powodów był niedawny artykuł (Diagram Przepływu Danych...)…

Czytaj dalej System Analizy Strukturalnej

KPI a system zarządzania przez cele

We wtorek miałem referat na warsztatach zorganizowanych przez MMC Polska: KPI ? Zarządzanie wskaźnikami w praktyce. Mój referat i warsztat zarazem był zatytułowany: KPI a system zarządzania przez cele. Nie będę streszczał…

Czytaj dalej KPI a system zarządzania przez cele

Reguły biznesowe, decyzje i pojęcia

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ą przy­dat­ne. […] 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żą.

Czytaj dalej Reguły biznesowe, decyzje i pojęcia

Modelowanie biznesowe czyli sterowanie i mechanizmy

Równo 10 lat temu napisałem: Model firmy powinien w sposób jasny i zrozumiały dla pracowników firmy opisywać firmę, jej cel rynkowy oraz wszelkie jej wewnętrzne i zewnętrzne zachowania oraz reakcje.…

Czytaj dalej Modelowanie biznesowe czyli sterowanie i mechanizmy