User Story i Story Mapping czyli jak podnieść koszty

Tytułowe User Story i Story Mapping mia­ły (mają) być reme­dium na pro­ble­my z wyma­ga­nia­mi. Czy są nim? Słownik Języka polskiego: 

roz­wią­za­nie: ?pro­jekt i reali­za­cja zało­żeń archi­tek­to­nicz­nych, kon­struk­cyj­nych, pla­stycz­nych itp.?

Innymi sło­wy roz­wią­za­nie to okre­ślo­ne narzę­dzia pra­cy. W tym przy­pad­ku narzę­dziem jest apli­ka­cja (opro­gra­mo­wa­nie).

Nadal popu­lar­ne wśród deve­lo­pe­rów user sto­ry, jako narzę­dzie opi­su wyma­gań poka­za­ło swo­je wady, lekar­stwem na nie ma (mia­ło) być sto­ry mapping. 

Kluczową wadą tego (użyt­kow­nik opi­su­je apli­ka­cję) podej­ścia jest zało­że­nie, że użyt­kow­nik ma racje (wie cze­go chce). Problem w tym, że nawet jeże­li użyt­kow­ni­ka wie co robi, to mało real­ne jest by wie­dział cze­go (jakie roz­wią­za­nie) potrze­bu­je. Zauważają to nawet entu­zja­ści metod zwinnych:

Do cze­go User Story się nada­ją? Mówiąc krót­ko, do krót­ko­ter­mi­no­we­go prze­cho­wy­wa­nia wyma­gań ze zwró­ce­niem szcze­gól­nej uwa­gi na dostar­cza­ną war­tość. Ponadto słu­żą jako wstęp do dal­szej dys­ku­sji mają­cej na celu wypra­co­wa­nie wspól­ne­go zro­zu­mie­nia zagad­nie­nia i dal­sze pra­ce nad mode­lo­wa­niem roz­wią­za­nia. (źr.: User Story – choć przy­dat­ne, nie zawsze opty­mal­ne)

Niewątpliwie są wstę­pem i chy­ba na tyle. Co do wspól­ne­go zro­zu­mie­nia oso­bi­ście mam wąt­pli­wo­ści, by przy­szły użyt­kow­nik miał kom­pe­ten­cje do bycia pro­jek­tan­tem roz­wią­zań. Gdyby je miał, po pro­stu by to roz­wią­za­nie zaprojektował. 

Swego cza­su (2016) pisa­łem o user story:

Wszelkie meto­dy zakła­da­ją­ce, że użyt­kow­nik wie cze­go chce i jest naj­lep­szym źró­dłem ??wyma­gań? bazu­ją na zaufa­niu dla tych opi­sów (źr. : User Story c.d. – Jarosław Żeliński IT-Consulting).

Z tym zaufa­niem jest jed­nak pro­blem, bo użyt­kow­nik bar­dzo czę­sto ma kon­flikt inte­re­su ze spon­so­rem pro­jek­tu: nikt roz­sąd­ny nie budu­je wię­zie­nia na pod­sta­wie pomy­słów i zale­ceń przy­szłych więź­niów. Czy to krzyw­dzą­ca ana­lo­gia? Nie sądzę: sklep inter­ne­to­wy nie chce być oszu­ka­ny przez kupu­ją­cych, sys­tem reje­stra­cji cza­su pra­cy też nie powi­nien dać się oszu­kać, sys­tem zarzą­dza­nia prze­pły­wem pra­cy nie powi­nien być podat­ny na symu­la­cję pra­cy, itp. itd. 

Jako inży­nie­ro­wi, przy­świe­ca mi raczej myśl przy­pi­sy­wa­nia Henry’emu Fordowi (pro­du­cent samo­cho­dów mar­ki Ford):

Gdybym na począt­ku swo­jej karie­ry, jako przed­się­bior­ca, zapy­tał klien­tów, cze­go chcą, wszy­scy byli­by zgod­ni: chce­my szyb­szych koni. Więc ich nie pytałem.”

I uwa­żam, że jest w tym wie­le racji. Idea powyż­sze­go cyta­tu zasa­dza sie na tym, że ludzie chcą szyb­kiej i wygod­niej podró­żo­wać, i to powin­no być ich wyma­ga­niem”. pozwo­lić im powie­dzieć Jako kow­boj, chcę szyb­sze­go i wygod­niej­sze­go konia, bym mógł lepiej wypa­sać sta­do”, to nic inne­go jak pozwo­lić mu (use­ro­wi) pro­jek­to­wać roz­wią­za­nie. I dokład­nie na to nie przy­stał H.Ford. Z per­spek­ty­wy cza­su widać, że miał rację.

User sto­ry po pol­sku” brzmi: ?Jako <kto?> chcę <co?>, po to aby <po co?>?

I tu poja­wia się idea podej­ścia inży­nier­skie­go MBSE (Model Based System Engineering): nie pozwa­la­my użyt­kow­ni­ko­wi powie­dzieć <co> chce. Bo to jest nie jest jego kom­pe­ten­cja (zapew­ne będzie chciał szyb­sze­go konia). Projekty opar­te na user sto­ry są czę­sto komen­to­wa­ne: Dostaliśmy dokład­nie to co chcie­li­śmy, a nie to co jest nam potrzeb­ne”. Inżynierskie user sto­ry” to raczej: Jako <kto?> chce uzy­skać <po co>”, czy­li pozwo­li­my powie­dzieć: Jako kow­boj, chcę lepiej wypa­sać stado”.

Lekarstwem na user sto­ry ma być sto­ry map­ping. Jeden z auto­rów blo­ga na ten temat poda­je przykład:

W wiel­kim skró­cie jest to mapo­wa­nie User Stories (lub opcjo­nal­nie wyma­gań w innej for­mie) na kro­ki pro­ce­su. Musimy zatem okre­ślić pro­ces, jego poszcze­gól­ne kro­ki i przy­pi­sać im okre­ślo­ne Historyjki Użytkownika.

Schemat Story Map (źr.: Story map­ping – nie­co szer­sze spoj­rze­nie – Analiza Biznesowa, dostęp 2020.12.14)

Zamawianie Produktu to pro­ces biz­ne­so­wy, nad tą linią jest opis pro­ce­su, pod nią histo­ryj­ki użyt­kow­ni­ka, usze­re­go­wa­ne wg. kolej­no­ści wdrożenia.

W tym momen­cie przy­to­czę dia­gram z art­ku­łu jaki napi­sa­łem trzy lata temu:

(źr. https://it-consulting.pl//2017/06/04/ile-przypadkow-uzycia/)

Po lewej stro­ny są kon­tek­sty użyt­kow­ni­ka (namiast­ka user sto­ry), po pra­wej roz­wią­za­nie. Czy widać pro­blem? User sto­ry to kon­tekst i per­spek­ty­wa użyt­kow­ni­ka, jego intu­icja („wie” co chce mieć). Oddany spra­wie i klien­to­wi deve­lo­per” jest w sta­nie przy­go­to­wać sześć narzę­dzi pra­cy (opcji w apli­ka­cji) i to na koszt zama­wia­ją­ce­go! Dobry ana­li­tyk pro­jek­tant poświę­ci czas na zro­zu­mie­nie i zapro­jek­tu­je mło­tek (to dla­te­go kod apli­ka­cji wyko­na­nych zwin­nie potra­fi być o rząd wiel­ko­ści bar­dziej zło­żo­ny niż pro­jek­ty apli­ka­cji zbu­do­wa­ne w opar­ciu o ana­li­zę i mode­le, a to zna­czy, że zwin­ne meto­dy tu dadzą pro­dukt 10-ktot­nie droż­szy po dzie­się­cio­krot­nie dłuż­szym czasie!).

Jak ina­czej? Posłużę się przy­kła­dem cyto­wa­ne­go wyżej auto­ra piszą­ce­go o sto­ry map­pin­g’u.

Proces biz­ne­so­wy, zgod­nie z defi­ni­cją, to aktyw­ność wień­czo­na pro­duk­tem. Tym pro­duk­tem jest okre­ślo­ny, mają­cy war­tość biz­ne­so­wą, doku­ment (zestaw danych, for­mu­larz). Tak więc ana­li­tycz­na” wer­sja wyżej pre­zen­to­wa­ne­go dia­gra­mu Schemat sto­ry map, wyglą­da­ła by tak:

Proces biz­ne­so­wy i struk­tu­ra doku­men­tu Koszyk. 

Operujemy doku­men­tem Oferta (lista pro­duk­tów, w tym opi­sy i ceny), Koszyk (kolek­cja wybra­nych pro­duk­tów, osob­ny doku­ment), Zamówienie (kolek­cja pro­duk­tów uzu­peł­nio­na dany­mi nabyw­cy, adre­sem dosta­wy, for­mą płat­no­ści), Zlecenie prze­le­wu (zawie­ra dane dla ban­ku, do wyko­na­nia ręcz­nie lub poprzez inte­gra­cję z usłu­gą płat­no­ści), List prze­wo­zo­wy (dane dla kurie­ra). Diagram zawie­ra przy­kła­do­wą struk­tu­rę jed­ne­go z tych dokumentów. 

Dla wygo­dy czy­ta­nia powtó­rzę tu dia­gram zawie­ra­ją­ce user story:

Obrazek posiada pusty atrybut alt; plik o nazwie StoryMapping2-1.png
  • Wyszukiwanie pro­duk­tu, to pra­ca z doku­men­tem Oferta (wyszu­ki­wa­nie poza MVP?),
  • Zarządzanie koszy­kiem, to kom­ple­to­wa­nie listy wybo­ru z ofer­ty, doda­nie nowej pozy­cji to klik­nię­cie na ofer­cie zaś usu­nię­cie pozy­cji to klik­nię­cie «usuń” w koszy­ku, to ta sama praca,
  • Konfiguracja dosta­wy to po pro­stu wypeł­nie­nie Zamówienia (ten for­mu­larz zawie­ra wszel­kie dane i do opłat­no­ści i dostawy),
  • Płatność to for­mu­larz przelewu,
  • Potwierdzenie zamó­wie­nia? Nie wiem co autor ma tu na myśli (moż­na roz­wi­jać ten pro­ces o komu­ni­ka­cję ema­il z zama­wia­ją­cym, nie ma jed­nak takiej potrze­by), jeże­li ktoś doko­na prze­le­wu to de fac­to auto­ry­zu­je to zamó­wie­nie, owszem moż­na wysłać mailem dane do prze­le­wu i link do aktyw­ne­go for­mu­la­rza Zamówienia (będzie zachowany).

A teraz user story:

  • wyświe­tla­nie pro­duk­tów to pre­zen­ta­cja Oferty,
  • nie wiem czym się róż­ni wyszu­ki­wa­nie od fil­tro­wa­nia, jed­nak warian­to­wa pre­zen­ta­cja Oferty to cały czas pra­ca z Ofertą, sor­to­wa­nie także,
  • zarzą­dza­nie koszy­kiem to try­wial­na pra­ca z for­mu­la­rzem Koszyk, nie rozu­miem sen­su tego podzia­łu (patrz przy­kład z młotkiem),
  • kon­fi­gu­ra­cja dosta­wy to dane na for­mu­la­rzu Zamówienie, czy na praw­dę ma on powsta­wać w kawał­kach? I tak do nicze­go nie posłu­ży jeże­li nie bez­ie kompletny, 
  • płat­no­ści są albo na stro­nie, albo poza stro­ną, czy­li samodzielnie,
  • nie wiem jak i po co moż­na roz­dzie­lić wypeł­nia­nie Zamówienia od pre­zen­ta­cji wypeł­nio­ne­go zamówienia. 

Moje wra­że­nia:

  • każ­dy pro­ces to pra­ca i jej efekt w posta­ci popraw­nie wypeł­nio­ne­go formularza
  • roz­bi­ja­nie opi­su na user sto­ry, któ­re tak na praw­de jest albo kolej­nym kon­tek­stem użyt­kow­ni­ka, albo wręcz wypeł­nia­niem kon­kret­nej czę­ści for­mu­la­rza (np. wpro­wa­dza­nie adres, a może be tego???) nie ma więk­sze­go sensu. 

Co obser­wu­ję na ryn­ku? Nie tak daw­no mia­łem w ręku wyce­nę pew­nej apli­ka­cji opra­co­wa­ną przez pew­ne­go deve­lo­pe­ra: naj­pierw sto­ry map” (ok. 60 user sto­ry!) potem wyce­na na ok. 300 tys. zł. pro­blem w tym, że apli­ka­cja (dosta­li pro­jekt ode mnie) mia­ła 6 (sześć!) for­mu­la­rzy po maks. 20 pól każ­dy, na moje pyta­nie skąd u nich tyle user sto­ry (bo w wyce­nie poda­li koszt za user sto­ry) nie ode­zwa­li się do do dzisiaj.

Tak więc user sto­ry, zasto­so­wa­ne w opi­sa­ny wyżej spo­sób, nie wno­szą żad­nej war­to­ści do pro­jek­tu a kom­pli­ku­ją postrze­ga­nie zakre­su. Analiza i opra­co­wa­nie sfor­ma­li­zo­wa­ne­go mode­lu pro­ce­su będą zawsze prost­sze jako dia­gram. Specyfikacja apli­ka­cji opar­ta na for­mu­la­rzach i ich logi­ce jest znacz­nie wygod­niej­sza, bo zama­wia­ją­cy wie co dosta­nie, a deve­lo­per ma pre­cy­zyj­ną infor­ma­cję i nie ma moż­li­wo­ści zawy­ża­nia ceny. Pomijam, że user sto­ry to nie­ste­ty tyl­ko wyobra­że­nia zama­wia­ją­ce­go, któ­re potrak­to­wa­ne bez­kry­tycz­nie jako wyma­ga­nia, zaowo­cu­ją jedy­nie szyb­szy­mi koń­mi” a nie samo­cho­dem. Dlatego User Story to dobry pomysł na zebra­nie potrzeb języ­kiem zama­wia­ją­ce­go i bar­dzo zły jako bez­po­śred­nia meto­da spe­cy­fi­ko­wa­nia wyma­gań wobec sys­te­mu. (Patrz: https://​it​-con​sul​ting​.pl/​c​z​y​m​-​p​r​a​c​u​j​e​-​c​z​y​l​i​-​v​i​s​u​a​l​-​p​a​r​a​d​i​g​m​/​#​S​p​e​c​y​f​i​k​a​c​j​a​-​p​o​t​r​zeb – User-Story)

Na koniec na popra­wę humo­ru sys­tem ocza­mi zama­wia­ją­ce­go (po lewej) i ocza­mi pro­jek­tan­ta ( po prawej):

Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]
Booch, G. (1994). Object-orien­ted Analysis and Design with Applications. 2nd Edition, the Benjamin/Cummings Publishing Company, Inc.

UML a modelowanie procesów biznesowych

Niedawno pisa­łem o UML v.2.51 i zasy­gna­li­zo­wa­łem, że

dia­gram aktyw­no­ści daje kon­tekst dla pojęć z gru­py ?acti­vi­ties? (aktyw­no­ści i czyn­no­ści oraz ich syn­tak­tycz­ne aso­cja­cje), dia­gram klas daje kon­tekst dla ?kla­sy­fi­ka­to­rów struk­tu­ral­nych?, itd. (Źródło: UML ver­sion 2.5 | | Jarosław Żeliński IT-Consulting)

Dzisiaj kil­ka słów na temat mode­lo­wa­nia pro­ce­sów biz­ne­so­wych w UML.

Cztery lata temu poru­sza­łem temat uży­cia UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych z uży­ciem mode­lu Eriksson-Penker’a:

Można się tak­że dość czę­sto spo­tkać z defi­ni­cją sze­ścio­ele­men­to­wą Erikssona-Penkera ([[Eriksson-Penker Business Modeling Profile]]). Tu mamy: Powyższy model bazu­je na uzna­niu, że pro­ces biz­ne­so­wy: ma cel, ma spe­cy­ficz­ne dane na wej­ściu, ma spe­cy­ficz­ne dane na wyj­ściu, wyma­ga zaso­bów, sta­no­wi ?wie­le czyn­no­ści do wyko­na­nia?, anga­żu­je róż­ne ?depar­ta­men­ty? w fir­mie (pozio­my prze­pływ), two­rzy jakąś war­tość dla klien­ta (wewnętrz­ne­go lub zewnętrz­ne­go). Problem jaki ja mam z tym wzor­cem to: wyma­ga nie­stan­dar­do­wych pojęć w UML. Profilowanie pole­ga na roz­bu­do­wie tak­so­no­mii zna­czeń (ste­reo­ty­py poka­zu­ją jakie pod­ty­py two­rzy­my dla dane­go typu), nie­ste­ty obiekt jako instan­cja kla­sy nie wytrzy­mu­je w moich oczach defi­ni­cji cze­goś tak abs­trak­cyj­ne­go jak cel biz­ne­so­wy(<>). Symbol pro­ce­su (tak zwa­ny pagon) tak­że nie jest poję­ciem z UML. Pojęcie Information jest tak pojem­ne, że w moich oczach jest wor­kiem, któ­ry pomie­ści wszyst­ko, a cechą dobrej nota­cji (for­mal­ne­go języ­ka, tak­że otwar­te­go) jest jed­nak wza­jem­ne wyklu­cza­nie się defi­ni­cji pojęć danej prze­strze­ni nazw (czy­li jeże­li coś jest np. Wejściem to już nie może być Informacją), na tej zasa­dzie nie rozu­miem też róż­ni­cy pomię­dzy celem pro­ce­su a jego wyj­ściem albo Aktorem z Zasobem (w koń­cu ludzie to zaso­by ludz­kie). (Źródło: Czym jest Piąty ele­ment ? Audyt orga­ni­za­cji czy­li ana­li­za biz­ne­so­wa | | Jarosław Żeliński IT-Consulting)

Generalnie więc jest to pomysł łamią­cy zasa­dy nota­cji… (pro­mo­wa­ny przez fir­mą SPARX, pro­du­cen­ta apli­ka­cji Enterprise Architect). Dość czę­sto spo­ty­kam się z tezą, że: UML posia­da bar­dzo istot­ną w kon­tek­ście prak­tycz­ne­go zasto­so­wa­nia cechę ? jest ela­stycz­ny. W zależ­no­ści od potrze­by, każ­de­mu jego ele­men­to­wi może zostać nada­ne nowe zna­cze­nie, two­rząc tym samym nowy ele­ment moż­li­wy do wyko­rzy­sta­nia pod­czas mode­lo­wa­nia.2 Niestety jest to bzdu­ra. UML ma bar­dzo ści­śle zde­fi­nio­wa­na seman­ty­kę. Owszem jest roz­sze­rzal­ny, ale roz­sze­rze­nie nota­cji to nie zmia­na zna­cze­nia sym­bo­li. Teza, że każ­de­mu jego ele­men­to­wi nota­cji UML może zostać nada­ne nowe zna­cze­nie” to cięż­ka here­zja (zresz­tą doty­czy to każ­dej notacji).

Popatrzmy jed­nak na UML, wer­sja 2.5 po upo­rząd­ko­wa­niu (wcze­śniej też dostęp­ne były te moż­li­wo­ści). Mamy w w niej dwa rodza­je pojęć mode­lu­ją­cych zacho­wa­nia”: aktyw­no­ści i czyn­no­ści (zada­nia). Oba poję­cia uży­wa­ne na Diagramach Aktywności. Aktywność jest poję­ciem szer­szym, ogól­niej­szym, zada­nie to ele­men­tar­ny krok jakiejś pro­ce­du­ry” (podob­nie zresz­tą jak w BPMN). W UML poję­cie aktyw­no­ści jest prze­zna­czo­ne do mode­lo­wa­nia pro­ce­dur w opro­gra­mo­wa­niu. Może tak­że być wyko­rzy­sty­wa­ne do mode­lo­wa­nie pro­ce­sów biz­ne­so­wych w orga­ni­za­cjach (patrz wytłuszczenia):

15 Activities
15.1 Summary
An Activity is a kind of Behavior (see sub clau­se 13.2) that is spe­ci­fied as a graph of nodes inter­con­nec­ted by edges. […] Activities may descri­be pro­ce­du­ral com­pu­ta­tion, for­ming hie­rar­chies of Activities invo­king other Activities, or, in an object-orien­ted model, they may be invo­ked indi­rec­tly as methods bound to Operations that are direc­tly invo­ked. Activities may be applied to orga­ni­za­tio­nal mode­ling for busi­ness pro­cess engi­ne­ering and work­flow. In this con­text, events often ori­gi­na­te from insi­de the sys­tem, such as the fini­shing of a task, but also from out­si­de the sys­tem, such as a custo­mer call. Activities can also be used for infor­ma­tion sys­tem mode­ling to spe­ci­fy sys­tem level pro­ces­ses. […]
15.6.3.1 Activity Partitions
An ActivityPartition is a kind of ActivityGroup for iden­ti­fy­ing ActivityNodes that have some cha­rac­te­ri­stics in com­mon. ActivityPartitions can sha­re con­tents. They often cor­re­spond to orga­ni­za­tio­nal units in a busi­ness model. They may be used to allo­ca­te cha­rac­te­ri­stics or reso­ur­ces among the nodes of an Activity.

W UML 2.5 jaw­nie roz­dzie­lo­no poję­cia Activities i Actions. Aktywności nale­ży rozu­mieć jako pro­ce­du­ry (abs­trak­cje jakichś dzia­łań), czyn­no­ści zaś jako ato­mo­we ope­ra­cje (kolej­ne kro­ki pro­ce­dur). Dla porów­na­nia kolej­ny frag­ment spe­cy­fi­ka­cji UML:

16 Actions
16.1 Summary
An Action is the fun­da­men­tal unit of beha­vior spe­ci­fi­ca­tion in UML. An Action may take a set of inputs and pro­du­ce a set of out­puts, tho­ugh either or both of the­se sets may be emp­ty. Some Actions may modi­fy the sta­te of the sys­tem in which the Action exe­cu­tes. Actions are con­ta­ined in Behaviors, spe­ci­fi­cal­ly Activities (as ExecutableNodes, see Clause 15) and Interactions (see Clause 17). These Behaviors deter­mi­ne when Actions exe­cu­te and what inputs they have. However, the abs­tract syn­tax and seman­tics of Actions are very depen­dent on Activities, becau­se they spe­cia­li­ze ele­ments and seman­tics from Activities to accept inputs and pro­vi­de out­puts and to defi­ne Actions that coor­di­na­te other Actions (Structured Actions, see sub clau­se 16.11). In addi­tion, the con­cre­te syn­tax for Actions only appe­ars in Activity dia­grams (all the exam­ples in this Clause use Activity nota­tion), and some of the nota­tion for Actions is spe­ci­fied in Clause 15. This Clause focu­ses on the syn­tax and seman­tics of Actions spe­ci­fi­cal­ly, rather than the Behaviors that con­ta­in them, but must be read in con­junc­tion with Clause 15.

Tak więc jeże­li chce­my legal­nie” mode­lo­wać pro­ce­sy biz­ne­so­we z uży­ciem UML, to był­by to dia­gram aktyw­no­ści z uży­ciem pojęć Activities i ActivityPartitions. Procedury (i algo­ryt­my) mode­lu­je­my z uży­ciem poję­cia Action. Porównując ten dia­gram i te poję­cia z BPMN widać wyż­szość tej dru­giej nota­cji. Po pierw­sze BPMN, ope­ru­jąc poję­cia­mi zda­rze­nie i bram­ka zda­rze­nio­wa, dosko­na­le daje sobie radę z mode­lo­wa­niem fak­tów w biz­ne­sie, po dru­gie – jak poka­zu­je prak­ty­ka – seman­ty­ka i gra­fi­ka BPMN jest łatwa do zro­zu­mie­nia dla odbior­cy biz­ne­so­we­go, cze­go dowo­dzi szyb­ki wzrost popu­lar­no­ści BPMN wśród ludzi biz­ne­su” i nadal zni­ko­my zakres sto­so­wa­nia UML w tej grupie.

Na koniec jesz­cze jed­na rzecz: kom­plet­nie nie rozu­miem uży­wa­nia poję­cia Przypadków Użycia UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Nie znaj­du­je ono żad­ne­go uza­sad­nie­nia w seman­ty­ce UML. W spe­cy­fi­ka­cji UML czytamy:

18 UseCases
18.1 Use Cases
18.1.1 Summary UseCases are a means to cap­tu­re the requ­ire­ments of sys­tems, i.e., what sys­tems are sup­po­sed to do. The key con­cepts spe­ci­fied in this clau­se are Actors, UseCases, and sub­jects. Each UseCase?s sub­ject repre­sents a sys­tem under con­si­de­ra­tion to which the UseCase applies. Users and any other sys­tems that may inte­ract with a sub­ject are repre­sen­ted as Actors. A UseCase is a spe­ci­fi­ca­tion of beha­vior. An instan­ce of a UseCase refers to an occur­ren­ce of the emer­gent beha­vior that con­forms to the cor­re­spon­ding UseCase. Such instan­ces are often descri­bed by Interactions.

Tak więc Przypadek Użycia to WYŁĄCZNIE kon­kret­ne zacho­wa­nie (reak­cja na bodziec) sys­te­mu defi­nio­wa­ne­go (spe­cy­fi­ko­wa­ne­go). Specyfikacje tych zacho­wań to inte­rak­cje. Ciągnące się od lat w krę­gach wywo­dzą­cych się z metod RUP (Rational Unified Process3) poję­cie Biznesowych Przypadków Użycia jest w moich oczach, i nie tyl­ko, zaka­łą bran­ży. Od cza­su gdy powstał UML 0.9 jako jeden zestaw metod mode­lo­wa­nia, nigdy w spe­cy­fi­ka­cji UML OMG nie było mowy o Biznesowych Przypadkach Użycia. Pojęcia te są tak samo nie­zgod­ne z UML jak wcze­śniej wymie­nio­ne pomy­sły SPARX i pro­fil Eriksson-Penker’a. Jeżeli może­my coś ze sobą porów­nać to ele­men­tar­ny pro­ces biz­ne­so­wy i przy­pa­dek uży­cia, ale pod jed­nym warun­kiem: że odwzo­ro­wu­je­my (mapu­je­my) kon­kret­ny ele­men­tar­ny (ato­mo­wy) pro­ces biz­ne­so­wy w apli­ka­cji na kon­kret­ny przy­pa­dek uży­cia, o czym pisa­łem w arty­ku­le o trans­for­ma­cji pro­ce­sów biz­ne­so­wych na przy­pad­ki uży­cia.

Tak więc sto­so­wa­nie UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych jest moż­li­we z uży­ciem dia­gra­mu aktyw­no­ści i pojęć acti­vi­ties. Stosowanie przy­pad­ków uży­cia UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych nie ma żad­ne­go seman­tycz­ne­go uza­sad­nie­nia, co widać jak na dło­ni w spe­cy­fi­ka­cji UML. Tak więc zostaw­my UML do zorien­to­wa­ne­go obiek­to­wo mode­lo­wa­nia sys­te­mów i BPMN do pro­ce­so­wo zorien­to­wa­nych mode­li orga­ni­za­cji. Obiektowe mode­le orga­ni­za­cji jak naj­bar­dziej mają sens, są to mode­le dzie­dzi­ny mode­lo­wa­nej orga­ni­za­cji, wyko­rzy­sty­wa­ne jako model logi­ki biz­ne­so­wej w two­rze­niu oprogramowania.

Model to mechanizm

Wstęp

Niedawno pisa­łem o regu­łach biz­ne­so­wych i poli­ty­kach postę­po­wa­nia w zarządzaniu:

…zamiast brać na sie­bie, jako pre­zes fir­my, mene­dżer śred­nie­go szcze­bla itd. ogrom zda­rzeń w posta­ci podej­mo­wa­nia decy­zji za każ­dym razem, gdy jest taka wyma­ga­na, moż­na stwo­rzyć sys­tem poli­tyk, zesta­wów reguł biz­ne­so­wych, skut­kiem cze­go fir­ma będzie spraw­nie funk­cjo­no­wa­ła nie anga­żu­jąc, nawet do bar­dzo try­wial­nych zadań, wyso­kich ran­gą pra­cow­ni­ków. Nie jest to dele­go­wa­nie upraw­nień, poli­ty­ki i regu­ły biz­ne­so­we to rodzaj z góry pod­ję­tych decy­zji. Owszem żad­nej fir­my nie da się zal­go­ryt­mi­zo­wać, dla­te­go zawsze wyż­sze kadry będą potrzeb­ne jed­nak ich klu­czo­wą rolą jest usta­la­nie zasad i zarzą­dza­nie nimi a bez­po­śred­nie reago­wa­nie powin­no doty­czyć tego ?nie­zal­go­ryt­mi­zo­wa­ne­go? zakre­su zda­rzeń (op. 20% :), regu­ła Pareto). Zarządzanie zorien­to­wa­ne na regu­ły biz­ne­so­we to wła­śnie takie podej­ście: to cze­go moż­na się spo­dzie­wać, opi­su­je­my regu­ła­mi, zda­rze­nia wyjąt­ko­we obsłu­gu­je­my oso­bi­ście. Reguły biz­ne­so­we war­to zebrać w jed­no miej­sce, ?wyjąć? je z prze­ro­śnię­tych opi­sów zakre­sów obo­wiąz­ków i kom­pe­ten­cji, upo­rząd­ko­wać zarzą­dze­nia zarzą­du. (Reguły biz­ne­so­we i poli­ty­ki jako mecha­nizm dzia­ła­nia orga­ni­za­cji | | Jarosław Żeliński IT-Consulting)

W powyż­szym cyta­cie wytłu­ści­łem klucz dzi­siej­sze­go wpi­su: mecha­nizm (ale nie ma tego sło­wa w powyż­szym cytacie).

Czytaj dalej… Model to mecha­nizm”

KPI a system zarządzania przez cele

We wto­rek mia­łem refe­rat na warsz­ta­tach zor­ga­ni­zo­wa­nych przez MMC Polska: KPI ? Zarządzanie wskaź­ni­ka­mi w prak­ty­ce. Mój refe­rat i warsz­tat zara­zem był zaty­tu­ło­wa­ny: KPI a sys­tem zarzą­dza­nia przez cele.

Nie będę stresz­czał 1,5 godzin­ne­go warsz­ta­tu, raczej zapra­szam na następ­ne. Tu zwró­cę uwa­gę na kil­ka cie­ka­wych i waż­nym moim zda­niem kwestii.

Niestety w lite­ra­tu­rze i w sie­ci jest wie­le dziw­nych, moim zda­niem tez, np.

  1. Punktem wyj­ścia do dobo­ru wskaź­ni­ków powin­na być stra­te­gia orga­ni­za­cji. Dlaczego stra­te­gia? Wskaźnik opi­su­je jakiś para­metr obsza­ru dzia­ła­nia orga­ni­za­cji, z regu­ły jest mier­ni­kiem wska­zu­ją­cym to czy zre­ali­zo­wa­no jakieś zada­nie. Strategii nie oce­nia­my wskaźnikami.
  2. Liczba wskaź­ni­ków nie powin­na być więk­sza niż 20. Tej tezy nie wyja­śnio­no a ja nie potra­fię sobie jej uza­sad­nić w żaden sposób.
  3. Wybrane do pro­gra­mu KPI powin­ny uwzględ­niać naj­waż­niej­sze procesy/obszary funk­cjo­nal­ne fir­my. A resz­ta fir­my jest poza kon­tro­lą? Tego też nie rozumiem.
  4. Dobrą meto­dą dobie­ra­nia wskaź­ni­ków dla fir­my są warsz­ta­ty i burze mózgów. To jest dla kurio­zum, jak moż­na uznać, że KPI fir­my to zle­pek pomysłów…

Popatrzmy na to co nazy­wa­ne jest Systemowym podej­ściem do zarządzania”:

  1. W prak­ty­ce ozna­cza to iden­ty­fi­ka­cje, zro­zu­mie­nie i zarzą­dza­nie wza­jem­nie powią­za­ny­mi pro­ce­sa­mi orga­ni­za­cji w spo­sób sys­te­mo­wy, co przy­czy­nia się do sku­tecz­ne­go i efek­tyw­ne­go osią­ga­nia jej celów.

  2. Podejście sys­te­mo­we wymu­sza logicz­ną ana­li­zę reali­zo­wa­nych przez przed­się­bior­stwo dzia­łań, pro­po­nu­jąc tzw. podej­ście pro­ce­so­we oraz obli­gu­je w prak­ty­ce do okre­śle­nia i kon­se­kwent­ne­go wyko­rzy­sty­wa­nia reguł, któ­re powin­ny towa­rzy­szyć tym działaniom.

  3. Model pro­ce­su biz­ne­so­we­go sta­no­wi szcze­gó­ło­wy opis pro­ce­su. Pokazuje, jakie czyn­no­ści są wyko­ny­wa­ne w ramach pro­ce­su oraz w jakiej kolej­no­ści (to opi­su­ją pro­ce­du­ry). Zawiera infor­ma­cje na temat wyko­naw­ców poszcze­gól­nych czyn­no­ści, doku­men­tów wyko­rzy­sty­wa­nych w ramach pro­ce­su, zaso­bów nie­zbęd­nych do reali­za­cji pro­ce­su (w tym sys­te­mów IT) oraz wskaź­ni­ków KPI (Key Performance Indicators)

    (Piotr Miller, Systemowe zarzą­dza­nie jako­ścią. , Difin, Warszawa 2011, ISBN: 978 – 83-7641 – 382‑2)

Wytłuszczenia moje, rzecz w tym, że klu­czem jest zro­zu­mie­nie logi­ki dzia­ła­nia orga­ni­za­cji. Zaryzykowałem tezę, że

Brak mode­lu pro­ce­sów biz­ne­so­wych prak­tycz­nie nie pozwa­la opra­co­wać popraw­nych wskaź­ni­ków KPI

Dlaczego? Bo wskaź­ni­ki te powin­ny mieć takie cechy:

  1. Kompletność: zawsze opi­su­ją całą fir­mę (jako jeden lub gru­pa wskaźników),
  2. Wskaźniki czę­ścio­we (pod­rzęd­ne) są roz­łącz­ne (nie współ­dzie­lą danych źródłowych),
  3. Wskaźniki czę­ścio­we łącz­nie sta­no­wią okre­ślo­na całość.

Patrząc na orga­ni­za­cję od ogó­łu do szcze­gó­łu”, czy­li od góry w dół”, na każ­dym pozio­mie powin­ni­śmy mieć okre­ślo­ny wskaź­nik, i jego – ewen­tu­al­ne – czę­ści skła­do­we ana­lo­gicz­nie do: pro­ces end-to-end i jego pod-pro­ce­sy. Wskaźnik KPI powi­nie poka­zy­wać coś co jest kom­plet­ne” w swej formie:

Trzy pozio­my zarzą­dza­nia a KPI (BPTrends)

Dalej sku­pi­my się na war­stwie pro­ce­sów. Wspomnę tyl­ko, że wskaź­ni­ki cało­ścio­we są dobrze zna­ne, wskaź­ni­ki efek­tyw­no­ści też są dość czę­sto w uży­ciu (z regu­ły po wdro­że­niu Lean Management czy Six Sigma).

A pro­duk­to­we czym są? To mier­ni­ki opi­su­ją­ce pro­duk­ty pro­ce­sów biz­ne­so­wych, bo tak na praw­dę celem jest infor­ma­cja zarząd­cza, infor­ma­cja do bie­żą­ce­go podej­mo­wa­nia decy­zji. Menedżerowie usta­la­ją zasa­dy o kory­gu­ją je lub dzia­ła­nia w odpo­wie­dzi na war­to­ści okre­ślo­nych mier­ni­ków”. Gdy cze­goś jest za mało”, jest zbyt kosz­tow­ne”, jest «zbyt złe”, itp.. reagu­ją tak by sytu­ację napra­wić”. Nie mam tu na myśli tego co nazy­wa­my gasze­niem poża­rów” bo to doty­czy raczej sytu­acji zwa­nej musz­tar­da po obie­dzie”. Nie mam tez na myśli korzy­sta­nia z wskaź­ni­ków do pre­mio­wa­nia lub kara­nia pra­cow­ni­ków (to w moich oczach jed­no z gor­szych ich zasto­so­wań). Rzecz w tym, by nad­zo­ro­wać pro­duk­ty, ich jakość i zgod­ność fak­tycz­ne­go pro­duk­tu z pla­no­wa­nym. Wskaźniki to nie tyl­ko war­to­ści walu­to­we (wskaź­nik finan­so­wy), to mogą być tak­że mia­ry ilo­ścio­we, pro­cen­to­we, jako­ścio­we itp.

Cel ich two­rze­nia i miej­sca spraw­dza­nia. Dobrym mode­lem jest tu Model Motywacji biznesowej:

KPI a Model Motywacji Biznesowej BMM
KPI a Model Motywacji Biznesowej BMM

Jak wspo­mnia­łem, sta­wia­my cele i oce­nia­my zada­nia. Tą oce­ną jest wła­śnie okre­ślo­ny wskaź­nik – jego pożą­da­na war­tość: tak spraw­dza­my, czy cel został osią­gnię­ty. Co ma wpływ na war­tość wskaź­ni­ka? Praca czy­li pro­ces biz­ne­so­wy. Aby zapew­nić spój­ność i kom­plet­ność wskaź­ni­ków a tak­że (może nawet przede wszyst­kim) ich roz­łącz­ność (żaden wskaź­nik nie może współ­dzie­lić z innym danych źró­dło­wych czy­li zmia­na jakie­goś para­me­tru bazo­we­go nie może zmie­nić wię­cej nić jed­ne­go wskaź­ni­ka na danym pozio­mie) nie pozo­sta­je nam nic inne­go jak zbu­do­wa­nie mode­lu pro­ce­sów (na okre­ślo­nym pozio­mie abstrakcji):

Procesy i podprocesy

Powyższy model to przy­kład dość wyso­kie­go pozio­mu abs­trak­cji, wskaź­nik opi­su­ją­cy Proces biz­ne­so­wy 1 będzie będzie wyli­cza­ny z ana­lo­gicz­nych wskaź­ni­ków skła­do­wych czy­li pod­pro­ce­sów 1.1. i 1.2. itd. Najniższy, pod­sta­wo­wy poziom szcze­gó­ło­wo­ści wyglą­da tak:

Model pro­ce­su biznesowego

Ten poziom pozwa­la już na wyli­cza­nie wskaź­ni­ków efek­tyw­no­ści. Wspomniane wcze­śniej wskaź­ni­ki to:

  1. Całościowe: wyni­ki finan­so­we, udział w ryn­ku, pozy­cja w ran­kin­gu, wiel­kość pro­duk­cji ilo­ścio­wo, sprze­daż cał­ko­wi­ta ilo­ścio­wo i war­to­ścio­wo, itp..
  2. Produktowe: ren­tow­ność pro­duk­tu, odse­tek rekla­ma­cji (jakość), koszt eta­pu, war­tość doda­na etapu, ?
  3. Efektywność: wydaj­ność maszy­ny, robot­ni­ka, sta­no­wi­ska pra­cy, koszt sta­no­wi­ska, koszt ope­ra­cji, jakość, ?
    Wskaźnikami tego rodza­ju są tak­że kosz­ty na kon­tach gru­py 4 (MPK) i 5 (ABC). Tu jed­nak nale­ży pamię­tać, by kon­ta (źró­dła war­to­ści zapi­sów) w tych gru­pach speł­nia­ły warun­ki, spój­no­ści, kom­plet­no­ści i niesprzeczności.

Czym więc tu jest zarzą­dza­nie przez cele?

  • Dla każ­de­go pozio­mu zarzą­dza­nia moż­na wyzna­czyć cele
  • Dla każ­de­go pro­ce­su na danym pozio­mie moż­na wyzna­czyć cele
  • Cele powi­nien usta­lać wła­ści­ciel pro­ce­su nadrzędnego
  • Celem może być zarów­no nowa, lep­sza war­tość wskaź­ni­ka jak i jego utrzy­ma­nie (nie­po­gor­sze­nie).
  • Zarządzanie przez cele to dele­go­wa­nie odpo­wie­dzial­no­ści: mene­dżer sam decy­du­je jak osią­gnie cel. W prze­ciw­nym wypad­ku nie może być obcią­ża­ny odpo­wie­dzial­no­ścią za wyniki!

Tak wiec widać, że zarzą­dza­nie przez cele pole­ga na zapro­jek­to­wa­nie sku­tecz­ne­go mecha­ni­zmu reali­za­cji, zde­fi­nio­wa­nie pro­duk­tu pro­ce­su i jego wskaź­ni­ka” (lub wskaź­ni­ków dany pro­dukt może być oce­nia­ny zarów­no kosz­tem jed­nost­ko­wym jak i wskaź­ni­kiem usterek).

Na koniec inna waż­na rzecz: zarzą­dza­nie zorien­to­wa­ne na cele (wskaź­ni­ki) a ilość wskaź­ni­ków. teza, że nie powin­no ich być wię­cej niż 20 jest moim zda­niem z księ­ży­ca. Będzie ich nawet ponad sto. Jak sobie z tym radzić sko­ro czło­wiek nie jest w sta­nie śle­dzić takie ilo­ści danych w cza­sie rze­czy­wi­stym? Można je agre­go­wać ale jak np. zagre­go­wać odse­tek rekla­ma­cji z kosz­tem jed­nost­ko­wym pro­duk­cji i śred­nim czas wytwo­rze­nia? Jak to mówią spe­cja­li­ści od kon­tro­lin­gu nie dzie­li­my kro­wy przez licz­bę rowe­rów”. Bardzo czę­sto nie ma moż­li­wość nor­ma­li­za­cji kil­ku roż­nych wskaź­ni­ków do jed­nej jed­nost­ki mia­ry. Tu z pomo­cą przy­cho­dzą tabli­ce decy­zyj­ne. Pozawalają one nie tyl­ko dać jeden wynik” z kil­ku nawet skraj­nie róż­nych war­to­ści wskaź­ni­ków skła­do­wych, ale tak­że auto­ma­ty­zo­wać reak­cję na tę wartość.

Tablica decy­zyj­na jako auto­mat agregujący

Jako warun­ki (zda­rze­nia) wpi­su­je­my okre­ślo­ne war­to­ści (lub ich prze­dzia­ły) war­to­ści kon­kret­nych wskaź­ni­ków. Jak widać nie ma żad­ne­go zna­cze­nia jed­nost­ka mia­ry. Tablica defi­niu­je regu­ły, czy­li obsłu­gi­wa­ne kon­kret­ne kom­bi­na­cje wskaź­ni­ków, na któ­re chce­my reago­wać (Działania). Reakcją może być natych­mia­sto­we pod­ję­cie dzia­ła­nia w fir­mie (auto­ma­ty­za­cja nad­zo­ru) lub sto­sow­ny monit dla mene­dże­ra. Jak widać tych wskaź­ni­ków (warun­ków) może być dowol­nie wie­le, defi­niu­je­my skoń­czo­ną ilość reak­cji na kon­kret­ne kom­bi­na­cje wskaź­ni­ków. W warun­kach biz­ne­so­wych reagu­je­my na rela­tyw­nie mają licz­bę kom­bi­na­cji wskaź­ni­ków w sto­sun­ku to wszyst­kich moż­li­wych kom­bi­na­cji, dla­te­go tabli­ce decy­zyj­ne – jako narzę­dzie wspo­ma­ga­ją­ce mene­dże­ra – spraw­dza­ją się tu doskonale.

Tyle w tele­gra­ficz­nym skrócie…

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.

http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471

Reguły biznesowe i polityki jako mechanizm działania organizacji

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

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

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

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

Manifest reguł biznesowych

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

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

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

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

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

Zarządzanie zorientowane na reguły

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

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

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

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

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

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

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

Procesy biznesowe

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

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

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

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

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

Diagram procesu biznesowego BPMN
Proces biz­ne­so­wy w nota­cji BPMN z wydzie­lo­ny­mi pro­ce­du­rą i regu­ła biznesową.

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

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

Kilka słów o logice dla zainteresowanych

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

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

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

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

B. Russell: Badania dotyczące znaczenia prawdy
B. Russell: Badania doty­czą­ce zna­cze­nia prawdy

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