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.

Reguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć

Na temat reguł biz­ne­so­wych mówi­łem tak­że w refe­ra­cie na kon­fe­ren­cji BPM GigaCon rok temu. Definicja regu­ły biz­ne­so­wej na bazie Business Rules Manifesto (zapra­szam do letu­ry arty­ku­łu z przed roku: Reguły biz­ne­so­we ? czym są?):

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

Reguły biz­ne­so­we są jak kodeks dro­go­wy: dzia­ła­ją w całym kra­ju na wszyst­kich dro­gach a nie tyl­ko w kon­kret­nych miejscach.

Po kolei

O pro­ce­sach biz­ne­so­wych mówi się wie­le, ja w tym blo­gu tak­że nie mało napi­sa­łem. Jednak jest coś cie­ka­we­go: fir­my dorad­cze twier­dzą, że bez pro­ce­sów nie da się dobrze zarzą­dzać, a jak spoj­rzeć na fir­my, nawet na lide­rów ryn­ku, mało któ­ra ma te pro­ce­sy” udo­ku­men­to­wa­ne, a kie­dyś żad­na nie mia­ła i żyło im się cał­kiem nie­źle… Jak to jest?

Gdzie pod­stęp? Proces, jego prze­bieg, jest efek­tem a nie przy­czy­ną! Próby refor­mo­wa­nia firm poprzez mode­lo­wa­nie ich obec­nych pro­ce­sów i narzu­ca­nie nowych ich wer­sji po opty­ma­li­za­cji” są z góry ska­za­ne na nie­po­wie­dze­nie (mimo, że być może gdzieś się przy­pad­kiem uda­ło). Dotyczy to mię­dzy inny­mi wdro­żeń sys­tem work­flow z narzu­co­ny­mi (pre­de­fi­nio­wa­ny­mi) prze­pły­wa­mi pracy.

Wyobraźmy sobie, że wysy­ła­my jed­ną oso­bę z zada­niem dotar­cia w kon­kret­ne miej­sce. Mamy więc tyl­ko jed­ne­go wyko­naw­cę, może­my go pre­cy­zyj­nie poin­stru­ować, spo­koj­nie może­my nad­zo­ro­wać to co robi. W zasa­dzie pro­ble­mu z zarzą­dza­niem tym co robi nie mamy.

Firmy kil­ku­oso­bo­we funk­cjo­nu­ją w peł­nym wzro­ko­wym kon­tak­cie” i w sta­łej komu­ni­ka­cji, jej pra­cow­ni­cy nie potrze­bu­ją inne­go nadzoru.

Problem zaczy­na się gdy takich osób jest nie jed­na czy kil­ka, a dzie­siąt­ki lub set­ki, w dużych orga­ni­za­cjach poje­dyn­cze tysią­ce. Tu już nie mamy moż­li­wo­ści indy­wi­du­al­ne­go pokie­ro­wa­nia zacho­wa­niem (pra­cą) każ­dej oso­by, udzie­la­nia wska­zó­wek i obser­wa­cji. Owszem, może­my udzie­lić sto­sow­ne­go instruk­ta­rzu każ­dej, to jed­nak wyma­ga dużej dys­cy­pli­ny tego instru­owa­ne­go, jeże­li czu­je on wzrok” nad­zor­cy reali­zu­je zada­nia, jeże­li nie, pozo­sta­je wie­rzyć w jego zaan­ga­żo­wa­nie i uczci­wość. Proszę sobie wyobra­zić nie­na­dzo­ro­wa­ną mani­fe­sta­cję, któ­rej uczest­ni­cy zosta­li jedy­nie poin­stru­owa­ni, któ­rę­dy maja iść i jak się zachowywać.

Początkowo, roz­ra­sta­ją­ce się orga­ni­za­cje sta­ra­ją się pano­wać na zatrud­nio­ny­mi, sta­ra­ją się zatrud­niać ludzi zdy­scy­pli­no­wa­nych i wykwa­li­fi­ko­wa­nych. Tak jed­nak moż­na roz­wi­jać się do cza­su, jest to tak­że bar­dzo kosz­tow­ny roz­wój (dro­gie zaso­by). Po trze­cie każ­dy zatrud­nio­ny musi nauczyć się od prze­ło­żo­ne­go (wła­ści­cie­la) tego jak ma pra­co­wać. Każdorazowe anga­żo­wa­nie kadr wła­ści­ciel­skich do nauki pacy pro­wa­dzi do sytu­acji, w któ­rej nie mają cza­su już na nic inne­go poza ucze­niem nowych pra­cow­ni­ków i nad­zo­ro­wa­niem pra­cy pozo­sta­łych. To punkt kry­tycz­ny roz­wo­ju fir­my. Zarządzanie zaczy­na zamie­niać się w ręcz­ne zaga­nia­nie to zajęć”. W skraj­nym przy­pad­ku wyglą­da to jak per­ma­nent­na akcja porząd­ko­wa­nia mani­fe­sta­cji. W zasa­dzie docho­dzi to utra­ty peł­ne­go pano­wa­nia nad osią­ga­niem celu, zarzą­dza­nie zamie­nia się w zaga­nia­nie. Jeżeli nic się spo­sób zarzą­dza­nia fir­ma pozo­sta­je w sta­gna­cji roz­wo­jo­wej, nie jest w sta­nie osią­gnąć więk­szej sprawności.

Pojawia się idea: ustal­my spi­sa­ną listę obo­wiąz­ków dla każ­de­go. Zaczyna się for­ma­li­za­cja. Powstają zakre­sy obo­wiąz­ków, usta­la­nie reguł. Nadal każ­dy wie CO ma robić, ma pew­ną swo­bo­dę ale wia­do­my jest cel pra­cy (posta­wio­ne zada­nie). poja­wia się jed­nak ryzy­ko. Wiemy gdzie pój­dą ale nie mamy pew­no­ści któ­rę­dy, a bywa, że jest to bar­dzo istot­ne. Po dru­gie może się oka­zać, że każ­dy obrał inną dro­gę, nie koniecz­nie optymalną.

Pojawia się pomysł: regu­la­mi­ny i pro­ce­du­ry czy­li ogra­ni­cze­nia! Przyrównując fir­mę do ludzi w mie­ście, pano­wa­nie nad tra­są jaka poko­na tłum to barier­ki (ogra­ni­cze­nia). Są uni­wer­sal­ne, sta­wia­my je tam, gdzie chce­my wymu­sić poko­ny­wa­ną trasę.

Tą meto­dą może­my spo­koj­nie obmy­ślić plan dzia­ła­nia, opra­co­wać stra­te­gię, czy­li dro­gę doj­ścia do celu, ogło­sić ją i dla pew­no­ści jed­nak posta­wić barier­ki. Wielkość tere­nu nie pozwa­la nam nie­ste­ty na ogar­nię­cie wzro­kiem cało­ści, po dru­gie jak sku­pi­my się na sta­łej obser­wa­cji prze­sta­nie­my wyko­ny­wać pod­sta­wo­wy obo­wią­zek: zarzą­dza­nie cało­ścią. Co robi­my? Instalujemy sys­tem kamer moni­to­rin­gu. Jednak błę­dem było by mon­to­wa­nie ich na całej tra­cie, śle­dze­nie tylu obra­zów zje nam cały czas. Dlatego moni­to­ru­je­my tyl­ko spe­cjal­nie wybra­ne punk­ty, inte­re­su­je na nie to, co wszy­scy robią na całej tra­sie (to zwy­kłe pod­glą­da­nie ;)). Interesuje nas to, czy w new­ral­gicz­nych, naj­bar­dziej ryzy­kow­nych pun­kach, nie docho­dzi to łama­nia zasad.

Sprawny i sku­tecz­ny nad­zór nad orga­ni­za­cją to nic inne­go zna­ne nam KPI (Kluczowe wskaź­ni­ki wydaj­no­ści, ang. [[Key per­for­man­ce Indicator]]). Powinno ich być jak naj­mniej, by kosz­ty nad­zo­ru były moż­li­wie naj­niż­sze, a one same powin­ny pokry­wać” swo­im nad­zor­czym” dzia­ła­niem całą organizację.

A gdzie procesy?

Wracamy do maso­wych wycie­czek. Proces, czy­li to jak to się dzie­je” to jest to, co posta­ło wyko­naw­com: tra­sa do poko­na­nia, ogra­ni­cza­na barier­ka­mi. Procesem jest tra­sa, bez tych barie­rek, ale pamię­ta­my: mamy nie jed­ne­go czło­wie­ka do prze­pro­wa­dze­nia a dużą gru­pę, któ­rej człon­ków w więk­szo­ści nie zna­my oso­bi­ście. Określenie im celu jest dobrym pomy­słem, ale jeże­li tyl­ko ist­nie­je ryzy­ko , że mogą gdzieś zbo­czyć sta­wia­my barier­ki. Po trze­cie, barier­ki roz­wią­zu­ją pod­sta­wo­wy pro­blem: zatrud­nie­ni ludzie nie muszą mieć peł­nej wie­dzy o mie­ście by dotrzeć do celu.

Proces biz­ne­so­wy to nie przy­czy­na, to sku­tek, for­mal­nie lub nie­for­mal­nie, funk­cjo­nu­ją­cych w orga­ni­za­cji ograniczeń. 

Modelowanie organizacji

Jaką więc wie­dzę musi­my mieć by zro­zu­mieć orga­ni­za­cje i świa­do­mie nią zarzą­dzać? Przypomnę, że świa­do­me zarzą­dza­nie fir­mą to podej­mo­wa­nie decy­zji orga­ni­za­cyj­nych o wyso­ko prze­wi­dy­wal­nych skut­kach.

Żeby było to moż­li­we musi­my rozu­mieć dla cze­go orga­ni­za­cja wła­śnie tak a nie ina­czej się zacho­wu­je. Proste mapo­wa­nie pro­ce­sów, ryso­wa­nie dia­gra­mów przy­pły­wu pra­cy, to pra­ca porów­ny­wal­na z foto­gra­fo­wa­niem rze­ki z lotu pta­ka: wie­my któ­rę­dy pły­nie woda ale nie rozu­mie­my dla­cze­go aku­rat tak.

Pozostaje nam jed­no: pozna­nie i zro­zu­mie­nie ukształ­to­wa­nia tere­nu a potem zabra­nie się za two­rze­nie sztucz­nych wznie­sień i zagłę­bień. To jedy­ny spo­sób na zapa­no­wa­nie nad kory­tem rze­ki czy nawet tyl­ko małe­go stru­mie­nia. 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 prawo).

Przykładem takiej regu­ły jest np. każ­dy klient, któ­ry zło­ży zapy­ta­nie musi mieć przy­dzie­lo­ne­go opie­ku­na klien­ta”. Aby taka regu­ła mogła jed­nak sku­tecz­nie funk­cjo­no­wać klu­czo­we poję­cia takie jak klient, opie­kun czy zapy­ta­nie muszą zostać pre­cy­zyj­nie zde­fi­nio­wa­ne. Bez tego zacho­dzi poważ­ne ryzy­ko pro­ble­mów z komu­ni­ka­cją wewnątrz fir­my, a już pra­wie na pew­no z jej otoczeniem.

Narzędzia modelowania organizacji

Modelowanie orga­ni­za­cji to ele­ment ana­li­zy biz­ne­so­wej (jest to w pro­ce­sie [[MDA]] dostar­cza­nia opro­gra­mo­wa­nia model [[Model nie­za­leż­ny od sys­te­mu IT, CIM ang. [[Computation Independent Model]]). Model taki opi­su­je sed­no sys­te­mu jakim są ludzie, cele ich pra­cy oraz infor­ma­cje jakie im są do tego potrzeb­ne. Mamy tu listę narzę­dzi do biz­ne­so­we­go mode­lo­wa­nia orga­ni­za­cji w kon­wen­cji CIM:

  1. spe­cy­fi­ka­cja reguł biznesowych,
  2. słow­nik pojęć,
  3. mapa pro­ce­sów,
  4. struk­tu­ra orga­ni­za­cyj­na i spe­cy­fi­ka­cja zakre­sów obo­wiąz­ków i kompetencji.

Jednak wyko­na­nie powyż­szych spe­cy­fi­ka­cji w spo­sób zbyt swo­bod­ny (nie­for­mal­ny) dopro­wa­dzi do małej ich przy­dat­no­ści. Pojęcia zde­fi­nio­wa­ne w słow­ni­ku muszą speł­niać pew­ne wyma­ga­nia for­mal­ne: każ­de poję­cie powin­no być fun­da­men­tal­nym pro­stym i nie­za­leż­nym od innych poję­ciem, nie może być defi­nio­wa­ne z pomo­cą innych pojęć (defi­ni­cje pojęć nie mogą się wza­jem­nie do sie­bie odwo­ły­wać i w sobie zagnież­dżać). Pojęcia musza być pro­ste i poli­czal­ne (okre­śla­ją byty biz­ne­so­we). Pojęcie nie może być defi­nio­wa­ne przez pro­ce­du­rę lub pro­ces, nie może być czyn­no­ścią. Formalizacja doty­czy szcze­gól­nie punk­tów 3. i 4.

Bardzo dużym wyzwa­niem jest zde­fi­nio­wa­nie sys­te­mu pojęć dla mapy pro­ce­sów (pro­ces, czyn­ność, zda­rze­nie, doku­ment…). Mapa (model) pro­ce­sów oraz struk­tu­ra orga­ni­za­cyj­na, by były jed­no­znacz­ne, muszą być tak­że zesta­wem zde­fi­nio­wa­nych pojęć.

Tworząc model struk­tu­ry orga­ni­za­cyj­nej musi­my wie­dzieć co zna­czy sło­wo: prze­ło­żo­ny, pod­wład­ny, komór­ka orga­ni­za­cyj­na czy jej kie­row­nik. Struktura ta jest inte­gro­wa­na z mode­le pro­ce­sów: role w pro­ce­sie to sta­no­wi­ska służbowe.

Budowanie sys­te­mów poję­cio­wych speł­nia­ją­cych powyż­sze warun­ki jest bar­dzo trud­ne dla­te­go dla mode­li pro­ce­sów biz­ne­so­wych naj­le­piej wyko­rzy­stać goto­wy model poję­cio­wy. Najlepiej obec­nie opra­co­wa­nym takim mode­lem poję­cio­wym jest dostęp­na nota­cja [[BPMN]]. Tworzenie wła­snych nota­cji jest kosz­tow­ne (czas i wie­dza oso­by opra­co­wu­ją­cej) i bar­dzo ryzy­kow­ne (może się nie udać). Dlatego uży­wa­nie dzi­siaj wła­snych lub dosto­so­wy­wa­nych nota­cji (np. dosto­so­wy­wa­ne pro­fi­la­mi dia­gra­my UML) jest w moich oczach nie­ra­cjo­nal­nym podejściem.

Model pojęć spe­cy­ficz­ny dla danej orga­ni­za­cji (tak zwa­ny „[[busi­ness vova­bu­la­ry]]”) nie­ste­ty musi powstać od zera”, podob­nie jak powią­za­na z nim spe­cy­fiak­cja reguł biz­ne­so­wych. Jest to trud­ne bo two­rze­nie prze­strze­ni nazw wyma­ga utrzy­ma­nia nie­za­leż­no­ści poszcze­gól­nych defi­ni­cji, ich spój­no­ści i zupeł­no­ści całe­go ich sys­te­mu. Niedochowanie tych wyma­gań pro­wa­dzi nawet sprzecz­no­ści reguł biz­ne­so­wych, któ­re w koń­cu są budo­wa­ne (odkry­wa­ne i doku­men­to­wa­ne) z pomo­cą tych pojęć.

Narzędziem ana­li­tycz­nym poma­ga­ją­cym w ana­li­zie poję­cio­wej firm jest tak zwa­ny dia­gram fak­tów. Ale o nim innym razem :), tu tyl­ko mała zapowiedź:

Każda poję­cie (pro­sto­kąt) musi mieć ści­słą defi­ni­cję, defi­ni­cje muszą się wza­jem­nie wyklu­czać, a słow­nik musi pokry­wać zna­cze­nio­wo cały defi­nio­wa­ny obszar poję­cio­wy. Zdefiniowane poję­cia słu­żą nie tyl­ko do kumu­ni­ka­cji ale tak­że do budo­wy reguł biz­ne­so­wych: np.

  • defi­ni­cja poję­cia: Czytelnik – oso­ba upraw­nio­na do korzy­sta­nia z zaso­bów biblioteki,
  • regu­ła biz­ne­so­wa: Czytelnikowi wol­no posia­dać wyłącz­nie jed­ną książkę.

Uprzedzając pyta­nia: powyż­szy dia­gram to nie gram klas UML, gdyż poję­cie jest jedy­nie defi­ni­cją (nie ma ope­ra­cji jak kla­sa) zaś Fakt, jako for­ma cza­sow­ni­ko­wa opi­su­je to co może się dziać z defi­nio­wa­nym poję­ciem, nie ma ten zapis poję­cio­wy odpo­wied­ni­ka w mode­lu UML (ope­ra­cja na poję­ciu to nie to samo co odpo­wie­dzial­ność kla­sy). Po trze­cie obiek­to­wy [[para­dyg­mat]] poję­cio­wy nota­cji UML nie przy­sta­je do ste­ro­wa­ne­go regu­ła­mi sys­te­mu poję­cio­we­go obsza­ru zarzą­dza­nia przed­się­bior­stwa­mi: pro­ce­sów biznesowych.

Widać to zresz­tą w na stro­nie OMG​.ORG gdzie sys­tem reguł biz­ne­so­wych (źr. spe­cy­fi­ka­cja Semantics of Business Vocabulary and Business Rules) jest trak­to­wa­ny jako ele­ment ana­li­zy biz­ne­so­wej CIM:

Jak widać OMG, orga­ni­za­cja stan­da­ry­zu­ją­ca nota­cję UML, zale­ca jed­nak na pozio­mie ana­li­zy biz­ne­so­wej sto­so­wa­nie innych niż UML sys­te­mów poję­cio­wych i nota­cji. Polecam tak­że arty­kuł Dlaczego tyl­ko meto­dy formalne…

Zanim wiec zaan­ga­żu­jesz kogoś do mode­lo­wa­nia wła­snej fir­my, upew­nij się, komu zle­casz tę pracę…

Wersja mniej niszowa

Artykuł ten prze­czy­tał pewien zna­jo­my, i uznał, że powyż­sza wer­sja arty­ku­łu jest zbyt niszo­wa, roz­wle­kła i trud­na. Jeżeli ma trosz­kę racji to tu w bar­dzo dużym więc skrócie:

  1. pro­ce­sy biz­ne­so­we to fak­tycz­ny, widocz­ny spo­sób pra­cy firm (ludzi w nich zatrudnionych),
  2. pro­ce­sy to efekt funk­cjo­no­wa­nia ludzi w śro­do­wi­sku ograniczeń,
  3. nale­ży poznać tych ludzi,
  4. ogra­ni­cze­nia to: pro­ce­du­ry, pra­wo, zarzą­dze­nia wewnętrz­ne oraz spe­cy­ficz­ne dla fir­my wewnętrz­ne nor­my zwa­ne regu­ła­mi biznesowymi,
  5. opra­co­wa­nie biz­ne­so­we­go mode­lu fir­my wyma­ga zro­zu­mie­nia i opi­sa­nia tego co powy­żej opisałem,
  6. nie ist­nie­je dro­ga na skróty.

Za nie­dłu­go dal­szy ciąg tego arty­ku­łu w posta­ci przy­kła­du. Wyobraźmy sobie nie­du­żą bibliotekę.…

Nowa specyfikacja Business Motivation Model v.1.1 i modelowanie biznesu

Na stro­nach http://​www​.omg​.org/ poja­wi­ła się nowa spe­cy­fi­ka­cja nota­cji [[Business Motivation Model]] (BMM) (źr. BMM.) Notacja ta powsta­ła w celu umoż­li­wie­nia for­mal­ne­go mode­lo­wa­nia biz­ne­spla­nów, a kon­kret­nie mode­li biz­ne­so­wych. Notacja powsta­ła z ini­cja­ty­wy [[Business Rules Group]] (http://​www​.busi​nessru​les​gro​up​.org/​h​o​m​e​-​b​r​g​.​s​h​tml). Manifest tej orga­ni­za­cji zawie­ra tak zwa­ne Zasady Autonomii Reguł (tu w języ­ku pol­skim: http://​www​.busi​nessru​les​gro​up​.org/​b​r​m​a​n​i​f​e​s​t​o​/​B​R​M​a​n​i​f​e​s​t​o​P​L​.​pdf).

BMM ujmu­je wyma­ga­nia biz­ne­so­we w róż­nych wymia­rach, w celu uza­sad­nie­nia dla­cze­go biz­nes chce coś robić, do cze­go dąży, jak zamie­rza to osią­gnąć oraz jak oce­nia rezultaty.”

Po co nowa notacja?

Swego cza­su (rok 2006) pisa­łem o mode­lach biz­ne­so­wych w kon­tek­ście stra­te­gii ryn­ko­wej w arty­ku­le Model biz­ne­so­wy – co to za zwie­rze. Wtedy pisa­łem o tym, że stra­te­gia ma zna­cze­nie i wie­le tłu­ma­czy. Wtedy tak­że dotkną­łem pro­ble­mu słow­nic­twa i sys­te­mu pojęć. Samo zde­fi­nio­wa­nie stra­te­gii nie jest pro­ste, zde­fi­nio­wa­nie poję­cia stra­te­gii zmia­ny jest jesz­cze więk­szym wyzwaniem.

Obszar biz­ne­so­wy jest bar­dzo ubo­gi w [[meto­dy for­mal­ne]]: for­mal­ne nota­cje, sfor­ma­li­zo­wa­ne języ­ki opi­su. W zasa­dzie dys­po­nu­je­my tyl­ko [[nota­cją BPMN]] (mode­le pro­ce­so­we i mode­le współ­pra­cy pro­ce­sów) oraz [[nota­cją ArchiMate]] (mode­le archi­tek­tu­ry kor­po­ra­cyj­nej). [[Notacja eEPC]], koja­rzo­na głów­nie z [[narzę­dziem ARIS]] i fir­mą ISD Scherr odcho­dzi powo­li do histo­rii, o nota­cjach nie­stan­dar­do­wych nawet nie piszę bo od daw­na idą w zapomnienie.

Dla odmia­ny, w sze­ro­ko poję­tej dzie­dzi­nie inży­nie­rii opro­gra­mo­wa­nia, mamy [[nota­cje obiek­to­wą UML]] i jej trzy­na­ście typów dia­gra­mów, mamy nadal uży­wa­ne, zna­ne z ana­li­zy struk­tu­ral­nej nota­cje [[ERD]] i [[DFD]].

[[Notacja BMM]] uzu­peł­nia biz­ne­so­wy sys­tem nota­cyj­ny o obszar poję­cio­wy mode­li biz­ne­so­wych i biz­ne­spla­nów. Pozwala w spo­sób for­mal­ny je opi­sać. [[Przestrzeń nazw]], pod­sta­wo­we poję­cia opi­sa­ne w BMM:

  1. Ends (stan ocze­ki­wa­ny) iden­ty­fi­ku­ją cechy opi­su­ją­ce źró­dła moty­wa­cji (cele) two­rze­nia biznesplanu,
  2. Means (środ­ki) iden­ty­fi­ku­ją narzę­dzia i środ­ki jakich pla­nu­je­my użyć by dopro­wa­dzić do ocze­ki­wa­ne­go (pla­no­wa­ne­go) stanu.
  3. Assessement (uwa­run­ko­wa­nia, ogra­ni­cze­nia) iden­ty­fi­ku­ją wie­dzę o warun­kach pro­jek­tu (w szcze­gól­no­ści ana­li­za SWOT)
  4. Influence (wpływ) iden­ty­fi­ku­ją pozna­ne czyn­ni­ki mogą­ce mieć (mają­ce) wpływ na osią­gnie­cie celu,
  5. Organisation (orga­ni­za­cja) iden­ty­fi­ku­je zaso­by i pro­ce­sy zaan­ga­żo­wa­ne w osią­gnię­cie celu
Całość sta­no­wi rodzaj listy kon­tro­l­nej” zro­zu­mie­nia posta­wio­ne­go pro­ble­mu, jakim jest pro­jekt biz­ne­so­wy, pozwa­la upew­nić się, że zna­my i rozu­mie­my to co ma na nie­go wpływ:

Business Motivation Model (źr. wiki)

Notacja zawie­ra tak­że ele­men­ty ste­ru­ją­ce biz­ne­sem takie jak [[regu­ły biz­ne­so­we]] i zasa­dy zarzą­dza­nia. Zestaw pojęć defi­niu­ją­cych ele­men­ty biz­ne­spla­nów, cechu­je się neu­tral­no­ścią meto­do­lo­gicz­ną oraz pozwa­la jed­no­znacz­nie opi­sać nasza wie­dzę o pro­jek­cie. Oznacza to, że słow­nik pojęć nie jest dedy­ko­wa­ny żad­nej kon­kret­nej meto­dy­ce, a jest jedy­nie for­mal­nym słow­ni­kiem ([[seman­tycz­na prze­strze­nią nazw]]). Powyższe poję­cia są wywie­dzio­ne z zasad­ni­czych pojęć z dzie­dzi­ny mode­lo­wa­nia pro­ce­sów: pro­ces biz­ne­so­wy, regu­ła biz­ne­so­wa, jed­nost­ka orga­ni­za­cyj­na. Bazują one odpo­wied­nio na spe­cy­fi­ka­cjach: BPMN (nota­cja [[OMG Business Process Modeling Notation]]), spe­cy­fi­ka­cji [[OMG Semantics of Business Vocabulary and Business Rules]], oraz RFP [[OMG Organization Structure Metamodel]]. Oznacza to, że nota­cja BMM nie zastę­pu­je ich, a jest dla nich nad­rzęd­na abs­trak­cją. Tak więc pro­ces, jako poje­dyn­cze poję­cie na dia­gra­mie BMM, może zostać szcze­gó­ło­wo opi­sa­ny (model) na innym dia­gra­mie (doku­men­cie), jed­nak defi­ni­cja poję­cia pro­ces biz­ne­so­wy jest taka sama w obu nota­cjach (pro­ces biz­ne­so­wy zawsze musi zna­czyć to samo!).

Poniżej ogól­ny widok pojęć opi­sy­wa­nych nota­cją BMM:

przy­kład two­rze­nia dia­gra­my (klik­nij), oraz model seman­ty­ki i syntaktyki:

BMM nie jest żad­nym narzę­dziem ani meto­dy­ką zarzą­dza­nia czy mode­lo­wa­nia pro­ce­so­we­go, zarzą­dza­nia pro­jek­ta­mi ani spe­cy­fi­ka­cją wzor­co­we­go mode­lu biz­ne­so­we­go. To nota­cja, któ­ra sta­no­wi sobą dobrze zde­fi­nio­wa­ny słow­nik poję­cio­wy (seman­ty­kę) oraz związ­ki pomię­dzy tymi poję­cia­mi (syn­tak­ty­kę, pamię­taj­my, że połą­czo­ne poję­cia nabie­ra­ją kolej­ne­go nowe­go zna­cze­nia, np. kil­ka sko­ja­rzo­nych osób ozna­cza zespół, oso­ba to pro­ste poję­cie, oso­by połą­czo­ne jakimś związ­kiem to grupa).

Wśród wie­lu orę­dow­ni­ków nota­cji UML domi­nu­je teza, że owo Unified (Uniwersalna) w skró­cie UML czy­ni tę nota­cję zdol­ną do mode­lo­wa­nia wszyst­kie­go, jej kolej­ne zasto­so­wa­nia i roz­sze­rze­nia moż­na same­mu opra­co­wać w posta­ci tak zwa­ne­go [[pro­fi­lu UML]]. Owszem, w zasa­dzie teza ta jest praw­dzi­wa jed­nak jest pew­ne ale. Po pierw­sze taki pro­fil to prak­tycz­nie nowa nota­cja: nowe poję­cia (seman­ty­ka) i zasa­dy (syn­tak­ty­ka). Te wyma­ga­ją od stro­ny for­mal­nej wyka­za­nia, że poję­cia (obra­zo­wa­ne z pomo­cą sym­bo­li, zna­ków nota­cji) są roz­łącz­ne, i że seman­tycz­nie (zna­cze­nia­mi) pokry­wa­ją całą mode­lo­wa­ną dzie­dzi­nę. Zapewnienie tego nie jest try­wial­nym problemem.

Tak więc nie tak zno­wu nowa, nota­cja BMM jest przy­dat­na, a dla wie­lu sto­su­ją­cych [[meto­dy for­mal­ne ana­li­zy sys­te­mo­wej]] w tym mode­lo­wa­nie, wręcz potrzeb­na. Nie bra­ku­je gło­sów kry­tycz­nych na temat BMM (np. na blo­gu MSDN), jed­nak oso­bi­ście pod­kre­ślam: nota­cja to nie spo­sób na ana­li­zę a jej narzę­dzie. Notacja nie ma roz­wią­zy­wać wszyst­kich pro­ble­mów, to nie jest srebr­na kula (ang. [[silver bul­let solu­tion]]), któ­rej nie­ste­ty wie­lu nadal szu­ka. Notacja ma poma­gać w roz­wią­zy­wa­niu pro­ble­mów, a to ogrom­na różnica.

Jeżeli kogoś inte­re­su­je nie­co wię­cej szcze­gó­łów o nota­cjach i ich two­rze­niu zapra­szam do dal­szej lektury.

Po co trud­ne” nota­cje sko­ro moż­na pisać po ludzku”

Czy nota­cje mają za cel zastą­pie­nie popu­lar­nej pro­zy? Absolutnie nie! Notacje słu­żą do budo­wy mode­li, któ­re testu­je­my, wery­fi­ku­je, wali­du­je­my. To tak jak z naszym miesz­ka­niem: może­my je w dowol­ny spo­sób opi­sać, mniej lub naj­bar­dziej kwie­ci­stym języ­kiem. Jednak dobry archi­tekt zawsze, nawet na wła­sny uży­tek, stwo­rzy zestaw rysun­ków i wizu­ali­za­cji, by upew­nić się że o niczym nie zapo­mniał. Z pro­jek­tu tech­nicz­ne­go dopie­ro stwo­rzy ład­nie opi­sa­ną pro­zą (języ­kiem natu­ral­nym, zro­zu­mia­łym dla każ­de­go) listę czę­ści i pod­ze­spo­łów, jed­nak ryzy­ko, że tak stwo­rzo­na spe­cy­fi­ka­cja będzie nie­kom­plet­ne teraz jest minimalne.

Zapewne wie­lu z Państwa było w skle­pie IKEA po meble, być może ktoś z Państwa sam je mon­to­wał. Liczba ele­men­tów, łączeń, paso­wań, łącz­ni­ków itp. jest ogrom­na już w śred­niej wiel­ko­ści zesta­wie mebli kuchen­nych. Czy wyobra­ża­cie sobie Państwo zapro­jek­to­wa­nie takich mebli bez spraw­dze­nia na rysun­kach tech­nicz­nych czy nicze­go nie bra­ku­je i czy wszyst­ko do sie­bie pasu­je? A teraz wyobraź­cie sobie Państwo, że więk­szość firm w któ­rych pra­cu­je­cie jest dale­ko bar­dziej skom­pli­ko­wa­na, a mimo to wie­lu ana­li­ty­ków podej­mu­je pró­by opi­sa­nia ich pro­sty­mi sło­wa­mi… jest to nie­mal­że nie­moż­li­we bez popeł­nie­nia wie­lu błędów.

Czym są formalne notacje

Swego cza­su napi­sa­łem w arty­ku­le o nota­cjach i modelowaniu:

Jednym z tych [pod­sta­wo­wych w sto­sun­ku do mode­li i uży­wa­nych w nich nota­cji] wyma­gań jest spój­ny i peł­ny model poję­cio­wy. Tak zwa­na prze­strzeń nazw (w nota­cji jest to lista sym­bo­li i defi­ni­cje ich zna­czeń) powin­na być ?wypeł­nio­na? defi­ni­cja­mi cał­ko­wi­cie, zaś obsza­ry defi­nio­wa­nych pojęć nie mogą na sie­bie nacho­dzić. (źr. Modelowanie pro­ce­sów biz­ne­so­wych).

Nieco bli­żej o tym. Notacja to model poję­cio­wy, zestaw sym­bo­li i ich zna­czeń (seman­ty­ka) oraz gra­ma­ty­ka łącze­nia tych pojęć (tak zwa­na syn­tak­ty­ka czy­li dopusz­czal­ne związ­ki pomię­dzy poję­cia­mi i ich zna­cze­nia). W czym pro­blem? Poniżej dia­gram go obrazujący.

Slajd10

Zestaw wszyst­kich słów-sym­bo­li to lista dopusz­czal­nych w mode­lu (opi­sie) pojęć i jest to wła­śnie tak zwa­na seman­ty­ka nota­cji (prze­strzeń nazw). Koło ozna­cza wybra­ną dzie­dzi­nę (np. mode­le biz­ne­so­we i biz­ne­spla­ny). Kółeczka z krzy­ży­ka­mi to poję­cia (obra­zo­wa­ne w nota­cjach sym­bo­la­mi, iko­na­mi nota­cji), dopusz­czal­ne sło­wa ze słow­ni­ka, któ­re­go chce­my użyć do opi­sa­nia cze­goś w danej dzie­dzi­nie (zwa­nej tak­że domeną).

Po lewej stro­nie mamy namiast­kę nie­for­mal­ne­go, potocz­ne­go języ­ka: to co widzi­my, poję­cia, byty czy­li krzy­ży­ki oraz sło­wa pozwa­la­ją­ce na ich nazwa­nie (ciem­niej­sze obsza­ry). Język potocz­ny cha­rak­te­ry­zu­je się tym, że zawie­ra sło­wa okre­śla­ją­ce róż­ne poję­cia (dwa krzy­ży­ki w jed­nym polu zna­cze­nio­wym, np. zamek to budow­la ale tak­że mecha­nizm zamknię­cia drzwi), poja­wia­ją się róż­ne sło­wa na jed­no zna­cze­nie (krzy­żyk nale­żą­cy do dwóch róż­nych obsza­rów, np. gar­nek i saga­nek to nie raz to samo naczy­nie). Pojawiają się tak­że byty nie mają­ce ozna­cza­ją­cych je słów (w danym języ­ku oczy­wi­ście, krzy­żyk nie przy­po­rząd­ko­wa­ny do żad­ne­go pola, np. inter­fejs, któ­ry nie ma swo­je­go odpo­wied­ni­ka w języ­ku pol­skim, uży­wa­my sło­wa angielskiego).

Taka sytu­acja, opi­sa­ne nie­jed­no­znacz­no­ści, powo­du­je, że typo­wy prze­kaz tek­sto­wy jest prze­ka­zem nie­jed­no­znacz­nym: czy­ta­ją­cy może odczy­tać z tek­stu coś inne­go niż to co miał na myśli jego autor. Nie da się go, takie­go tek­stu, zwe­ry­fi­ko­wać od stro­ny spój­no­ści i kom­plet­no­ści opi­sy­wa­nej rzeczywistości.

Po pra­wej stro­nie mamy sytu­ację ide­al­ną: pojęć jest dokład­nie tyle ile zna­czeń (słów), każ­de poję­cie ma tyl­ko jed­no zna­cze­nie zaś tak zwa­na prze­strzeń nazw (obszar, do któ­re­go nale­żą, miesz­czą­cy wszyst­kie poję­cia danej dzie­dzi­ny) jest zupeł­nie opi­sa­ny (brak obsza­ru, zna­cze­nia, nie obję­te­go zadnym sło­wem). Opisanie cze­goś języ­kiem” (sło­wa­mi) z takiej prze­strze­ni nazw czy­ni prze­kaz jed­no­znacz­ny w 100% (nie ist­nie­ją w danej prze­strze­ni syno­ni­my i nie ma pojęć nie­zde­fi­nio­wa­nych). Jak być może nie trud­no się domy­śleć, opra­co­wa­nie sys­te­mu poję­cio­we­go speł­nia­ją­ce­go powyż­sze wyma­ga­nia, nie jest łatwe.

Dobra nota­cja ma jesz­cze jed­ną istot­ną cechę: sym­bo­le obra­zu­ją­ce poszcze­gól­ne poję­cia powin­ny się z nimi koja­rzyć nie­za­leż­nie od języ­ka natu­ral­ne­go. To nazy­wa­my [[semio­ty­ką]]. Jest to nauka o tym jak czło­wiek postrze­ga (rozu­mie, odbie­ra) poszcze­gól­ne zna­ki gra­ficz­ne (sym­bo­le, iko­ny). To tak­że powo­du­je, że dąży się do stan­da­ry­za­cji czy­li nie mno­że­nia nad­mia­ru sys­te­mów nota­cyj­nych (patrz [[brzy­twa Ockhama]]). To dla­te­go two­rze­nie wła­snych nota­cji jest trosz­kę pozba­wio­ne sen­su: jest bar­dzo trud­ne i odda­la nas od standardów.

Na zakończenie

Stosowanie ana­li­zy sys­te­mo­wej, mode­lo­wa­nia oraz for­mal­nych nota­cji do two­rze­nia mode­li, powo­du­je, że wyni­ki ana­liz są dale­ko bar­dziej wia­ry­god­ne. Z regu­ły celem pra­cy ana­li­ty­ka biz­ne­so­we­go czy pro­jek­tan­ta jest opra­co­wa­nie opi­su reko­men­do­wa­ne­go roz­wią­za­nia. Może nim być doce­lo­wy model orga­ni­za­cji czy też opis opro­gra­mo­wa­nia jakie nale­ży dostar­czyć (bo nie zawsze wytwo­rzyć!). W pro­ce­sie for­mal­nej ana­li­zy sys­te­mo­wej (nie jest to ana­li­za sys­te­mu infor­ma­tycz­ne­go, to ana­li­za dowol­ne­go sys­te­mu), powsta­ją mode­le, któ­re testujemy.

Taki model to naj­pierw hipo­te­za, a po wery­fi­ka­cji, jest to opis roz­wią­za­nia (pro­jekt tego co ma powstać). Idealną sytu­acją była by taka, a któ­rej mamy narzę­dzia do mode­lo­wa­nia każ­dej ana­li­zo­wa­nej dzie­dzi­ny. W kla­sycz­nej inży­nie­rii jest to rysu­nek tech­nicz­ny i zasa­dy obli­cza­nia wytrzy­ma­ło­ści, sfor­ma­li­zo­wa­ny sys­tem two­rze­nia sche­ma­tów elek­trycz­nych i elek­tro­nicz­nych i wie­le innych (zależ­nie od dzie­dzi­ny), nota­cje UML w inży­nie­rii opro­gra­mo­wa­nia. W sfe­rze zarzą­dza­nia mie­li­śmy do nie­daw­na bia­ła pla­mę, teraz mamy już BMM czy ArchiMate.

Moim zda­niem utrzy­my­wa­nie, że moż­na coś sku­tecz­nie ana­li­zo­wać meto­da­mi nie­for­mal­ny­mi świad­czy raczej o nie­wie­dzy i bra­ku kom­pe­ten­cji. Bo jak ina­czej nazwać nara­ża­nie adre­sa­ta pro­jek­tu (nie raz klien­ta) na masę nie­spój­no­ści owo­cu­ją­cych lawi­no­wo rosną­cy­mi kosz­ta­mi reago­wa­nia na nie­prze­wi­dzia­ne szcze­gó­ły? Nie raz sły­sza­łem, że to trud­ne, tyl­ko dla jajo­gło­wych, kosz­tow­ne. Owszem, ale nie zapo­mi­naj­my, że ana­li­za to nie coś co każ­dy sobie sam może zro­bić. Dobra ana­li­za nigdy nie jest kosz­tow­niej­sza niż poten­cjal­ne, ryzy­ko­wa­ne stra­ty – opła­ci się zawsze.

Prezentacja opi­su­ją­ca klu­czo­we ele­men­ty nota­cji BMM

Przykład uży­cia nota­cji BMM: spo­sób mode­lo­wa­nia.

Skrócony opis – klu­czo­we pojęcia.