Gdzie są te cholerne szczegóły

Regularnie na moich szko­le­niach oraz w toku pro­jek­tów, dosta­je pyta­nia o wali­da­cje”. Z regu­ły spo­ty­kam spe­cy­fi­ka­cje wyma­gań (albo ocze­ki­wa­nia na takie), zawie­ra­ją­ce zesta­wie­nia doku­men­tów (i for­ma­tek ekra­no­wych), dla każ­de­go zesta­wie­nie pól, dla każ­de­go pola wali­da­cje”. Problem w tym, że:

  • mie­sza­ją się tu tak zwa­ne typy pro­ste danych (zna­ko­we, licz­bo­we, itp.), tak zwa­ne maski” (data, ema­il, itp.), oraz regu­ły biz­ne­so­we (np. wła­ści­wy rabat),
  • z uwa­gi na to, że doku­men­tów jest wie­le, a pola mogą się na nich powta­rzać, powsta­je duża licz­ba powtó­rzo­nych zapi­sów wali­da­cji”, nie­jed­no­krot­nie nie­spój­nych a bywa, że sprzecznych.
  • typy pro­ste oraz regu­ły biz­ne­so­we (logi­ka biz­ne­so­wa) to dwa zupeł­nie inne obsza­ry systemu.

Jak definiować wymagania na walidacje”

Tu war­to na począ­tek wró­cić do kla­sy­fi­ka­cji wyma­gań. W arty­ku­le Inżynieria wyma­gań opi­sa­łem trzy ich rodzaje:

  1. funk­cjo­nal­ne czy­li usłu­gi apli­ka­cji (przy­pad­ki uży­cia tej aplikacji),
  2. poza-funk­cjo­nal­ne czy­li cechy jakościowe,
  3. dzie­dzi­no­we czy­li logi­ka biznesowa.

I teraz bar­dzo waż­na rzecz: któ­re ele­men­ty archi­tek­tu­ry opro­gra­mo­wa­nia, za reali­za­cję któ­rych wyma­gań odpo­wia­da­ją? W arty­ku­le Gdzie się reali­zu­ją wyma­ga­nia opi­sa­łem ogól­nie wzo­rzec pro­jek­to­wy MVC. Pomijając sam wzo­rzec, istot­ne jest to, że tak zwa­ne wali­da­cje” są doko­ny­wa­ne w dwóch róż­nych ele­men­tach archi­tek­tu­ry. Tak zwa­ne typy pro­ste danych (np. pole zna­ko­we Nazwisko) są (mogą być) spraw­dzo­ne w momen­cie ich wpro­wa­dza­nia (np. for­mat­ka ekra­no­wa nie przyj­mu­je cyfr w polu nazwi­sko). Cała logi­ka biz­ne­so­wa jest wyko­ny­wa­na wewnątrz apli­ka­cji (infor­ma­cje o ewen­tu­al­nych błę­dach poja­wią się po zatwier­dze­niu for­mu­la­rza), np. upust może być spraw­dzo­ny (albo nali­czo­ny) dopie­ro po skom­ple­to­wa­niu danych wyma­ga­nych do jego wyli­cze­nia, czy­li będzie to kil­ka róż­nych pól (naj­mniej dwa :)). Bywa, że do wyli­cze­nia cze­goś potrzeb­ne będą dane nie wpro­wa­dza­ne do danej for­mat­ki fak­tu­ry, np. sal­do klienta.

Jedną z naj­gor­szych prak­tyk pro­gra­mi­stów jakie spo­ty­kam, jest umiesz­cza­nie logi­ki biz­ne­so­wej (a są nią np. meto­dy nali­cza­nia upu­stów) w for­mu­la­rzach ekra­no­wych. Po pierw­sze pro­wa­dzi to duże­go obcią­ża­nia kodu tych for­ma­tek, po dru­gie przy dużej ilo­ści doku­men­tów (for­ma­tek ekra­no­wych) logi­ka biz­ne­so­wa jest powie­la­na, co pro­wa­dzi do dużych pro­ble­mów z utrzy­ma­niem spój­no­ści spraw­dza­nych reguł biz­ne­so­wych w apli­ka­cji. Po trze­cie pró­by pisa­nia inter­fej­sów (API) do tych apli­ka­cji (np. przyj­mo­wa­nie doku­men­tów wysta­wio­nych poza apli­ka­cją) jest nie­moż­li­we bez kolej­ne­go powie­le­nia logi­ki biz­ne­so­wej w API (jeże­li chce­my wali­do­wać” przyj­mo­wa­ne tą dro­gą dane a z raczej chce­my). Jednym sło­wem masakra.

Sprawdzoną meto­dą sku­tecz­ne­go (spój­ność, kom­plet­ność, nie­sprzecz­ność) zapi­sy­wa­nia wyma­gań dzie­dzi­no­wych (w tym wali­da­cje”) jest wydzie­le­nie w dokumentacji:

  1. słow­ni­ka pojęć
  2. słow­ni­ka reguł biznesowych 
    1. spe­cy­fi­ka­cji tablic decy­zyj­nych jako uzu­peł­nie­nia reguł biznesowych.

Słownik pojęć powi­nien obej­mo­wać wszyst­ko to co stwa­rza ryzy­ko nie­jed­no­znacz­no­ści. Reguły biz­ne­so­we, wraz z tabli­ca­mi decy­zyj­ny­mi (jeże­li są wyma­ga­ne) zebra­ne w jed­nym miej­scu (spe­cy­fi­ka­cja reguł), są niczym innym jak wyma­ga­nia­mi dzie­dzi­no­wy­mi. Tak opra­co­wa­na doku­men­ta­cja ana­li­tycz­na pozwa­la deve­lo­pe­ro­wi na łatwe poru­sza­nie się po doku­men­cie, mamy moż­li­wość wery­fi­ka­cji wyma­gań, ich spój­no­ści i kom­plet­no­ści. Załączając spe­cy­fi­ka­cje wzo­rów doku­men­tów (mock-up’y ekra­nów czy­li for­mat­ki ekra­no­we) każ­dy obszar takie­go wzo­ru albo jest oczy­wi­sty, albo jest zde­fi­nio­wa­ny (jako nazwa) w słow­ni­ku pojęć. Cała nie­try­wial­na logi­ka dzia­ła­nia jest opi­sa­na regu­ła­mi biz­ne­so­wy­mi. Ogólne zasa­dy two­rze­nia takiej dokumentacji:

  1. W toku ana­li­zy opra­co­wu­je­my mode­le pro­ce­sów biz­ne­so­wych zawie­ra­ją­ce wyłącz­nie aktyw­no­ści i ich pro­duk­ty (czy­li pro­ce­sy biz­ne­so­we) i nic ponad to (dodat­ko­we szcze­gó­ły to albo pro­ce­du­ry albo sce­na­riu­sze przy­pad­ków uży­cia, to inne dokumenty).
  2. Na mode­lach pro­ce­sów zazna­cza­my wszyst­kie aktyw­no­ści zwią­za­ne ze sto­so­wa­niem reguł biz­ne­so­wych (kon­wen­cja doku­men­to­wa­nia reguł na mode­lach zale­ży od uży­te­go narzę­dzia CASE). Reguły biz­ne­so­we uzu­peł­nia­my o ewen­tu­al­ne kry­te­ria decy­zyj­ne (np. w posta­ci tablic decyzyjnych).
  3. Równolegle pro­wa­dzi­my słow­nik pojęć dla dokumentacji.
  4. Nie defi­niu­je­my (jako biz­nes, a nawet ana­li­tyk biz­ne­so­wy, zgła­sza­ją­cy wyma­ga­nia) typów pro­stych, one są albo oczy­wi­ste, albo wyni­ka­ją z defi­ni­cji pojęć (w razie wąt­pli­wo­ści pisze­my czym jest nazwi­sko w słowniku).

Ważna rzecz. Decyzje o tym jaki­mi typa­mi danych ope­ru­je apli­ka­cja, to decy­zje deve­lo­pe­ra (pro­gra­mi­sty). Moim zda­niem pro­gra­mi­sta żąda­ją­cy w wyma­ga­niach poda­nia mu typów danych, jest nie­ukiem albo leni­wym sabo­ta­ży­stą (uży­cie – wybór typów danych, w tym typów zło­żo­nych, to decy­zje i kom­pe­ten­cje developera!).

Poniżej opi­sa­ne ele­men­ty umiesz­czo­ne na jed­nym sche­ma­cie blokowym:

Logika biznesowa

Tak więc, war­to roz­wa­żyć sto­so­wa­nie reguł biz­ne­so­wych i słow­ni­ków pojęć (Semantics Of Business Vocabulary And Rules), gdyż jest to spraw­dzo­na i bar­dzo przy­dat­na tech­ni­ka ana­li­zy i doku­men­to­wa­nia logi­ki biz­ne­so­wej. Polecam tak­że stro­nę The Business Rules Group i zamiesz­czo­ny tam Manifest Reguł Biznesowych. Tworzenie mon­stru­al­nych doku­men­tów wyma­gań, zawie­ra­ją­cych dzie­siąt­ki razy powie­la­ne wali­da­cje” pro­wa­dzi do wie­lu kło­po­tów z utrzy­ma­niem spój­no­ści i kom­plet­no­ści takich spe­cy­fi­ka­cji. Pomijam już ich uciąż­li­wą obję­tość. Jako mate­riał dla pro­gra­mi­sty są one wte­dy trud­ne w uży­ciu, do tego skła­nia­ją do naj­gor­szych prak­tyk, jaki­mi jest mię­dzy inny­mi umiesz­cza­nie logi­ki biz­ne­so­wej w kodzie for­ma­tek ekranowych.

Na koniec pole­cam książ­kę Building Business Solutions poświę­co­na temu zagadnieniu.

GIODO: ceną za rozwój technologii nie może być handel danymi

Zrobienie zdję­cia czło­wie­ko­wi odbie­ra mu dusze”, tak przy­naj­mniej nadal uwa­ża­ją przed­sta­wi­cie­le wie­lu kul­tur nazy­wa­nych pier­wot­ny­mi”, któ­rzy boją się foto­gra­fów, ale to ludy pier­wot­ne i mogą tak myśleć. Dzisiaj, jak co dzień, zali­czam prze­gląd pra­sy czy­li prze­glą­dam swo­je sub­skryp­cje RSS i co czytam:

Ceną za roz­wój nowych tech­no­lo­gii komu­ni­ka­cyj­nych nie może być han­del dany­mi oso­bo­wy­mi, któ­ry jest nowo­cze­sną for­mą han­dlu ludź­mi – mówi w roz­mo­wie z PAP Generalny Inspektor Ochrony Danych Osobowych Wojciech Wiewiórowski.

Zdaniem GIODO Unia Europejska powin­na w cią­gu trzech lat wypra­co­wać nowe prze­pi­sy o ochro­nie danych oso­bo­wych, bo obec­nie nie są dopa­so­wa­ne do współ­cze­snych wyzwań. W ponie­dzia­łek w Warszawie roz­pocz­nie się mię­dzy­na­ro­do­wa kon­fe­ren­cja, poświę­co­na zagad­nie­niom ochro­ny danych oso­bo­wych i pry­wat­no­ści. (GIODO: ceną za roz­wój tech­no­lo­gii nie może być han­del dany­mi. wnp​.pl)

Rzeczą od pra­dzie­jów iden­ty­fi­ku­ją­cą czło­wie­ka była jego twarz (postać), w mia­rę roz­ro­stu licz­by popu­la­cji, z uwa­gi na rosną­ce praw­do­po­do­bień­stwo podo­bień­stwa, poja­wi­ło się imię, następ­nie dodat­ko­wo, do imie­nia doda­wa­no skąd pocho­dzi np. Zbyszko z Bogdańca. Rosnąca licz­ba ludzi oraz wymóg bez­błęd­no­ści iden­ty­fi­ka­cji zro­dził potrze­bę uży­cia cze­goś bar­dziej wyra­fi­no­wa­ne­go: poja­wi­ły się nume­ry oby­wa­te­li” (w Polsce PESEL).

Funkcjonuje rów­no­le­gle poję­cie prze­strze­ni publicz­nej, któ­rej naj­prost­sza moim zda­niem defi­ni­cja to opar­ta na pra­wie wyłą­czo­ne­go środ­ka” brzmią­ca: prze­strzeń publicz­na to każ­da prze­strzeń nie będą­ca zastrze­żo­ną prze­strze­nią pry­wat­ną” (prze­strzeń pry­wat­na to ta, któ­rą mamy pra­wo dys­po­no­wać i ogra­ni­czać do niej dostęp, żad­na zaś z nich nie jest prze­strze­nią niczy­ją). Definicje inne są moim zda­niem pró­ba­mi wyli­cze­nia czym prze­strzeń publicz­na jest”, co z góry ska­zu­je tę defi­ni­cje na potrze­bę ich aktu­ali­za­cji za każ­dym razem, gdy kto­kol­wiek wynaj­dzie” nowe zasto­so­wa­nie prze­strze­ni publicz­nej. Przykładem takiej sła­bej” defi­ni­cji jest moim zda­niem ta z usta­wy o zago­spo­da­ro­wa­niu prze­strzen­nym (to jako przy­kład, ta usta­wa to inny temat ;)):

?obszar prze­strze­ni publicz­nej? ? nale­ży przez to rozu­mieć obszar o szcze­gól­nym zna­cze­niu dla zaspo­ko­je­nia potrzeb miesz­kań­ców, popra­wy jako­ści ich życia i sprzy­ja­ją­cy nawią­zy­wa­niu kon­tak­tów spo­łecz­nych ze wzglę­du na jego poło­że­nie oraz cechy funk­cjo­nal­no-prze­strzen­ne, okre­ślo­ny w stu­dium uwa­run­ko­wań i kie­run­ków zago­spo­da­ro­wa­nia prze­strzen­ne­go gmi­ny; (źr. USTAWA, z dnia 27 mar­ca 2003 r. o pla­no­wa­niu i zago­spo­da­ro­wa­niu przestrzennym)

Każdy czło­wiek znaj­du­ją­cy się w prze­strze­ni publicz­nej jest w niej dostęp­ny”: wol­no się na nie­go patrzeć, wol­no zapa­mię­tać jego twarz (o to pyta­my potem świad­ków wyda­rzeń). Postęp tech­nicz­ny pozwo­lił zastą­pić ulot­ną pamięć czło­wie­ka, nie­ulot­ną i znacz­nie dokład­niej­szą foto­gra­fią. Nie zmie­nia to jed­nak fak­tu, że poja­wie­nie się foto­gra­fii nie zmie­nia defi­ni­cji prze­strze­ni publicz­nej. Tam gdzie zacho­dzi ryzy­ko, że nie zapa­mię­ta­my wszyst­kich twa­rzy, (np. nie zapa­mię­ta­my oso­by, któ­ra nam nie odda­ła poży­czo­nej książ­ki) poza twa­rzą”, żąda­my dodat­ko­wych danych iden­ty­fi­ku­ją­cych (zawar­tość kar­to­te­ki czy­tel­ni­ka w biblio­te­ce) oraz reje­stru­je­my je (utrwa­la­my, pamięć ludz­ka jest zawod­na). Należy zwró­cić uwa­gę, że Biblioteka Publiczna to tak­że prze­strzeń publicz­na podob­nie jak muzea czy stadiony.

Do rze­czy. Bardzo mi się nie spodo­ba­ła meta­fo­ra” uży­ta przez GIODO: han­del dany­mi oso­bo­wy­mi, któ­ry jest nowo­cze­sną for­mą han­dlu ludź­mi”. Jest ona w moich oczach świa­dec­twem zupeł­ne­go nie­zro­zu­mie­niem przez GIODO opi­sy­wa­ne­go zja­wi­ska. Handel ludź­mi to for­ma (ele­ment) nie­wol­nic­twa. To ostat­nie zaś, to zmu­sza­nie ludzi do rze­czy, któ­rych z wła­snej woli by nie czy­ni­li (w szcze­gól­no­ści do nie­wol­ni­czej pra­cy). Nikt nie może mi zaka­zać opo­wia­da­nia o tym kogo widzia­łem na spa­ce­rze w par­ku. Nikt nie może mi zaka­zać poka­za­nia komu­kol­wiek moich zdjęć z tego spa­ce­ru, na któ­rych uwiecz­ni­łem innych spa­ce­ro­wi­czów. Gdzie GIODO dostrze­ga tu jakie­kol­wiek nie­wol­nic­two? Rozumiem, że ktoś może nie chcieć, by wyda­ło się”, że był w tym par­ku ale to pro­blem tego kogoś: wsty­dzi się tego, że był? Okłamał kogoś, że był w tym cza­sie w innym miej­scu? To pro­blem ety­ki (cza­sem psy­chi­ki) tych kon­kret­nych osób, ale na pew­no nie jest to – rela­cja z wizy­ty w par­ku – upra­wia­niem nie­wol­nic­twa. Kto tu jest tym nie­wol­ni­kiem i dla­cze­go? Ja nie mam pojęcia.

Pojawiają się gło­sy, że tech­no­lo­gia dopro­wa­dzi­ła do sytu­acji, w któ­rej łatwość zapa­mię­ta­nia i prze­twa­rza­nia ogrom­nych ilo­ści takich fak­tów jest zła. Zła? Technologia tyl­ko uła­twi­ła tyl­ko to, co do nie­daw­no było tyl­ko bar­dzo trud­ne, cza­sem nie­moż­li­we, dla czło­wie­ka ale to – te moż­li­wo­ści – to tyl­ko więk­sza sku­tecz­ność z nie nowy byt”.

Handel dany­mi oso­bo­wy­mi (zbio­ra­mi takich danych) to była kwe­stia cza­su. To zwy­kły” han­del wie­dzą. Owszem, poja­wia się moim zda­niem pro­blem ety­ki w przy­pad­ku, gdy pewien bank ogła­sza, że zacznie han­dlo­wać dany­mi swo­ich klien­tów. Ale czy bank to prze­strzeń publicz­na? Myślę, że dekla­ra­cja prze­strze­ga­nia tajem­ni­cy ban­ko­wej przez bank, czy­ni z nie­go jed­nak prze­strzeń pry­wat­ną. Owszem, zapew­ne bank może prze­kwa­li­fi­ko­wać obszar swo­je­go dzia­ła­nia w prze­strzeń publicz­ną”, ale powi­nien to ogło­sić w nowym regu­la­mi­nie i prze­strze­gać zasa­dy, że nie dzia­ła on wstecz (regu­la­min jest ele­men­tem umo­wy z ban­kiem). Bank (nie tyl­ko) ma wie­dzę o nas, jed­nak nie jest wła­ści­cie­lem tej wie­dzy a jej depo­zy­ta­riu­szem. Nie ma więc pra­wa swo­bod­ne­go nią dys­po­no­wa­nia. Nasze dane w ban­ku nie są wła­sno­ścią ban­ku, są nadal naszą wła­sno­ścią. Dotyczy to każ­dej insty­tu­cji (fir­my) któ­rej powie­rza­my nasze dane (oso­bo­we) w celu uwia­ry­god­nie­nia swo­jej oso­by, w tym umoż­li­wie­nia kon­tak­tu z nami.

Moim zda­niem nicze­go nie trze­ba tu regu­lo­wać ani ogra­ni­czać. Fakty zare­je­stro­wa­ne na uli­cach (np. moni­to­ring w prze­strze­ni publicz­nej) nie pod­le­ga­ją dys­ku­sji, poja­wia­my się w prze­strze­ni publicz­nej i nie może zaka­zać reje­stro­wa­nia tego fak­tu. Dane oso­bo­we prze­ka­za­ne w okre­ślo­nym celu np. zało­że­nia rachun­ku ban­ko­we­go nie są publicz­ne. Nasze dane w Urzędzie mel­dun­ko­wym tak­że. Nie ma tu co dodat­ko­wo regulować.

Przyznam się, że nie rozu­miem celu reje­stro­wa­nia baz danych oso­bo­wych w GIODO czy opo­ru wie­lu ludzi przez moni­to­rin­giem miej­skim. Być może Ci ostat­ni to Ci, któ­rzy mają pro­blem z uczci­wo­ścią (bo psy­cho­zy wie­lu ludzi to odręb­ny temat). Nie rozu­miem jaki zwią­zek ma nie­wol­nic­two z postę­pem tech­nicz­nym (poza tym, ze wszy­scy w jakimś sen­sie jeste­śmy nie­wol­ni­ka­mi tech­no­lo­gii, ale każ­dy w takim zakre­sie w jakim do tego dopusz­cza). Rozumiem jed­nak, że nale­ży nas – oby­wa­te­li – chro­nić przez pozba­wio­ny­mi ety­ki kor­po­ra­cja­mi, dla któ­rych osią­ga­nie zysku uspra­wie­dli­wia każ­de dzia­ła­nie. Tu jed­nak mam na myśli spo­sób zmia­ny warun­ków umo­wy (bank i han­del dany­mi) a nie sam fakt, że bank te dane ma, bo ma je za naszą zgodą.

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.