rfc2119 – Słowa kluczowe reguł

Od cza­su do cza­su spo­ty­kam się z zasko­cze­niem, gdy mówię, że pew­ne sło­wa klu­czo­we w spe­cy­fi­ka­cjach są stan­da­ry­zo­wa­ne”. Otóż spe­cy­fi­ka­cje nota­cji na OMG​.org mają narzu­co­ne pew­ne słow­nic­two. Przykładem niech będzie spe­cy­fi­ka­cja nota­cji BPMN v.2.0.2, zawie­ra ona taki oto roz­dział :

3.2 Normative
OMG UML
? OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 -
(jest już UML 2.5.)
OMG MOF
? Object Management Group – Meta Object Facility (MOF) Core Specification, V2.0
http://​www​.omg​.org/​s​p​e​c​/​M​O​F​/​2.0
RFC-2119
? Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, IETF RFC 2119, March 1997
http://​www​.ietf​.org/​r​f​c​/​r​f​c​2​1​1​9​.​txt

Oznacza to, że do popraw­nej inter­pre­ta­cji spe­cy­fi­ka­cji nota­cji nale­ży znać spe­cy­fi­ka­cje: MOF, UML oraz tak­że RFC-2119. O MOF i UML pisa­łem nie raz, dzi­siaj kil­ka słów o tej ostatniej. 

Jest to doku­ment opi­su­ją­cy reko­men­do­wa­ny spo­sób for­mu­ło­wa­nia wyma­gań (np. w sto­sun­ku do ele­men­tów dia­gra­mu i ich uży­cia). Wymagania są tu rozu­mia­ne sze­ro­ko, jako sfor­mu­ło­wa­nia nor­ma­tyw­ne. Słowa klu­czo­we do wyko­rzy­sta­nia, w RFC do wska­za­nia pozio­mów wyma­gań” to sło­wa i zwro­ty o tu usta­lo­nym zna­cze­niu :

This docu­ment spe­ci­fies an Internet Best Current Practices for the Internet Community, and requ­ests discus­sion and sug­ge­stions for impro­ve­ments. Distribution of this memo is unli­mi­ted.?(?Key words for use in RFCs to Indicate Requirement Levels,? 1997)?

Wymienione sło­wa klu­czo­we odno­szą się do for­mu­ło­wa­nia reguł (przy sto­so­wa­niu okre­ślo­nych zasad będą­cych wyma­ga­nia­mi) i oznaczają:

  1. MUSI (oryg. MUST) ozna­cza, że to zacho­wa­nie (okre­ślo­na regu­ła, wyma­ga­nie) jest abso­lut­nym wymo­giem, alter­na­tyw­nie: WYMAGA SIĘ, NALEŻY 
  2. NIE MOŻE (oryg. MUST NOT) ozna­cza, że okre­ślo­ne zacho­wa­nie jest abso­lut­nie zaka­za­ne, alter­na­tyw­nie: NIE NALEŻY
  3. POWINIEN (oryg. SCHOULD) ozna­cza, że okre­ślo­ne zacho­wa­nie jest reko­men­do­wa­ne, a więc jedy­nie w ści­śle okre­ślo­nych oko­licz­no­ściach, jeże­li ist­nie­ją okre­ślo­ne powo­dy, okre­ślo­ne zacho­wa­nie może być pomi­nię­te, alter­na­tyw­nie: REKOMENDUJE SIĘ,
  4. NIE POWINIEN (oryg. SHOULD NOT) ozna­cza, że pew­ne zacho­wa­nia odra­dza się (reko­men­du­je się nie wyko­ny­wać okre­ślo­ne­go zacho­wa­nia), a więc zacho­wa­nie to jest dopusz­czal­ne jedy­nie w okre­ślo­nych oko­licz­no­ściach, alter­na­tyw­nie: ODRADZA SIĘ, NIE REKOMENDUJE SIĘ, 
  5. MOŻE (oryg. MAY) ozna­cza, że okre­ślo­ne zacho­wa­nie jest opcjo­nal­ne, a więc skut­ki tego reali­za­cji lub pomię­cia okre­ślo­ne­go zacho­wa­nia są cał­ko­wi­cie neu­tral­ne, alter­na­tyw­nie: OPCJONALNIE

Powyższe odno­si się do wszel­kich wyma­gań, do decy­zji o zasto­so­wa­niu cze­goś (np. okre­ślo­nej kon­struk­cji w danej nota­cji). Pod poję­ciem zacho­wa­nia (się)” rozu­mie­my inter­pre­ta­cję zapi­sów np. o sto­so­wa­niu lub wyma­ga­niu cze­goś lub nie. 

Biorąc pod uwa­gę fakt, że defi­ni­cje pojęć to kla­sy­fi­ka­to­ry i sta­no­wią one sobą regu­ły (coś jest lub nie jest czymś) sło­wa te sta­no­wią tak­że bazo­wy ele­ment skład­ni tre­ści reguł biz­ne­so­wych (ele­men­ty pre­dy­ka­tów), np. kie­row­ca NIE MOŻE prze­kra­czać dozwo­lo­nej pręd­ko­ści”, kie­row­ca POWINIEN zacho­wać bez­piecz­ną odle­głość od poprze­dza­ją­ce­go go pojaz­du”, kie­row­ca MOŻE prze­wo­zić pasa­że­rów”, a ogól­nie rzecz bio­rąc kie­row­ca MUSI prze­strze­gać zasad Kodeksu Drogowego”, a ten to nic inne­go jak wła­śnie zbiór reguł.

Źródła

OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
Network Working Group. (1997, March). Key words for use in RFCs to Indicate Requirement Levels. Https://​Www​.Ietf​.Org/. https://​www​.ietf​.org/​r​f​c​/​r​f​c​2​1​1​9​.​txt
Reguły biznesowe

Rola reguł biznesowych i polityk w dużej organizacji

Dwa mie­sią­ce temu pisa­łem o zarzą­dza­niu z per­spek­ty­wy two­rze­nia reguł biznesowych:

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:organizacją moż­na zarzą­dzać two­rząc regu­ły a nie wyda­jąc pole­ce­nia przy każ­dym zda­rze­niu. (Źródło: 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)

Dzisiaj o roli tych reguł w rozu­mie­niu poli­ty­ki i pro­ce­dur wpły­wa­ją­cych na cią­głość dzia­ła­nia. Czytaj dalej… Rola reguł biz­ne­so­wych i poli­tyk w dużej 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.

Tablice decyzyjne – siła reguł biznesowych

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

BPMN-Graphical-Representation-spaghettiKolejną przy­czy­ną powsta­wa­nia tak zwa­nych spa­ghet­ti mode­li” jest ryso­wa­nie” na dia­gra­mach reguł biz­ne­so­wych zamiast powo­ły­wać się na nie. O tym pisa­łem już wcze­śniej (Reguły biz­ne­so­we jako motor ste­ru­ją­cy orga­ni­za­cji: fak­ty + defi­ni­cje pojęć | Jarosław Żeliński IT-Consulting).

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

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

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

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

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

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

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

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

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

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

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

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

Reguły – jakie nie powinny być…

Kolejny arty­kuł z gatun­ku prze­my­śle­nia i rady na koniec roku” 🙂

Często spo­ty­kam się trak­to­wa­niem reguł biz­ne­so­wych jak jakie­goś pią­te­go koła u wozu (o ile w ogó­le się ktoś nimi zaj­mu­je w pro­jek­cie). Pół roku temu pisa­łem, że regu­ły biz­ne­so­we to, jeże­li sta­ją się wyma­ga­niem, sta­no­wią klu­czo­wy ele­ment reali­zo­wa­nej logi­ki biznesowej:

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

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

(Gdzie są te cho­ler­ne szcze­gó­ły).

Jest jed­nak dru­gi, nie mniej waż­ny, ele­ment każ­de­go pro­jek­tu zwią­za­ne­go z audy­tem i mode­lo­wa­niem orga­ni­za­cji: zasa­dy jej dzia­ła­nia czy­li wła­śnie regu­ły biz­ne­so­we. Taki audyt, ukie­run­ko­wa­ny na kon­tro­lę spój­no­ści i kom­plet­no­ści, pra­wie zawsze ujaw­nia luki. Pewnie zna­cie Machiavelliczną zasa­dę wol­no wszyst­ko to cze­go nie zabro­nio­no”? Należy się z tym liczyć zawsze, wręcz zało­żyć, że zosta­ną pod­ję­te pró­by szu­ka­nia luki w systemie”.

Analiza reguł biz­ne­so­wych w wie­lu orga­ni­za­cjach, w zasa­dzie prak­tycz­nie w każ­dej, pozwa­la odkryć oso­bli­we luki”. Zarządzenia wewnętrz­ne, regu­la­mi­ny upu­stów, pro­gra­my pro­mo­cyj­ne, te i wie­le innych to nic inne­go jak pakie­ty reguł biz­ne­so­wych. Często, szcze­gól­nie wła­śnie w posta­ci regu­la­mi­nu pro­mo­cji, sta­ra­my się zwięk­szyć obro­ty, zmniej­szyć stra­ty itp. Co się dzie­je jeże­li źle o opra­cu­je­my regu­ły? Tu np. opi­sa­no jed­ną z typo­wych takich wpadek:

Prokuratura oskar­ży­ła ich o oszu­stwo i haker­stwo, ale sąd ich unie­win­nił, bo prze­cież nigdzie nie jest napi­sa­ne, że nie wol­no wci­skać pew­nej kon­kret­nej sekwen­cji przy­ci­sków w auto­ma­cie. Ani też nie jest napi­sa­ne, że jeśli auto­mat nie­spo­dzie­wa­nie roz­da­je kar­ty tak samo jak wcze­śniej, to nale­ży natych­miast prze­rwać grę i zgło­sić obsłu­dze kasy­na, że chy­ba jest jakiś błąd w sys­te­mie. (Wielkie linie lot­ni­cze kon­tra chło­pak, któ­ry wyszu­ku­je ludziom tanie bile­ty… Pozywają go do sądu).

Inny, nie­co podob­ny przy­pa­dek opi­sa­łem kie­dyś tu:

Słowa ?brzyd­ko jest być nie­uczci­wym? pły­ną­ce z ust sta­no­wią­cych pra­wo, raczej roz­śmie­sza, bo to praw­da, że brzyd­ko, ale nie zmie­nia to fak­tu, że eko­no­mia jest bez­li­to­sna i na pew­no ludzie (wie­lu) znaj­dą ?wygry­wa­ją­cą? stra­te­gię, jeże­li tyl­ko taka ist­nie­je. Innymi sło­wy sko­ro mia­sto pobie­ra dwie róż­ne opła­ty za tę sama usłu­gę (z karą i bez), wybra­na zosta­je wer­sja o niż­szej opła­cie. (W stre­fie par­ko­wa­nia man­dat się opła­ca ? czy­li ana­li­za sys­te­mo­wa ? nie wyko­na­na).

Warto prze­czy­tać oba powyż­sze arty­ku­ły w cało­ści, może natchnie to Was to pochy­le­nia się nad regu­ła­mi w Waszych fir­mach, na Waszych por­ta­lach, sys­te­mach CRM i nie tylko.

Semantic Core czyli bat na szczegóły

Bardzo czę­sto zasta­na­wiam się, nad przy­czy­na­mi pora­żek pro­jek­tów, przy­czy­na­mi tego, że jed­ne są lep­sze inne gor­sze, a gor­szy to taki, któ­ry wymy­ka się spod kon­tro­li a osta­tecz­ny efekt (pro­dukt), uzy­ska­ny po znacz­nie dłuż­szym cza­sie niż pla­no­wa­no, jest zasko­cze­niem dla wszyst­kich. Na to nakła­da się pro­blem prze­ka­zy­wa­nia wie­dzy pomię­dzy kolej­ny­mi eta­pa­mi pro­jek­tu, gdzie naj­więk­szym ryzy­kiem jest zro­zu­mie­nie pro­ble­mu i prze­ka­zy­wa­nie wie­dzy przez same­go zama­wia­ją­ce­go. Gdzie problem?

Ten arty­kuł pole­cam biz­ne­so­wi” któ­ry szu­ka przy­czyn swo­ich pro­ble­mów, i tym (nie tyl­ko ana­li­ty­kom), któ­rzy mają ambi­cje robić coś w kie­run­ku popra­wy tego sta­nu rze­czy, zamiast uzna­wać obec­ne sta­ty­sty­ki za pew­nik bo takie są fakty”.

Wpadłem jakiś czas temu na stro­nę SemanticCore​.ORG, oto krót­ki cytat z pierw­szej strony :

The seman­tic core repre­sents a vision of com­plex sys­tems that are defi­ned and pro­vi­sio­ned based on high-level models. This vision is being pur­su­ed by mul­ti­ple gro­ups in mul­ti­ple orga­ni­za­tions based on a varie­ty of para­digms such as UML, Ontologies, Business Rules, MOF, EDOC, Data Modeling, OWL, SQL, Etc.. It is the intent of the seman­tic core to inte­gra­te the­se diver­se para­digms into fami­ly of lan­gu­ages that leve­ra­ges the­ir com­mo­na­li­ty whi­le taking advan­ta­ge of the­ir uni­que capa­bi­li­ties. We will defi­ne nor­ma­li­zed Meta-Models cap­tu­ring uni­que seman­tics, inde­pen­dent of the nota­tion. […] It is our intent to cre­ate a com­bi­ned sub­mis­sion appro­pria­te for mul­ti­ple OMG ini­tia­ti­ves inc­lu­ding Ontologies, Business Rules, Business Process Modeling and a UML infra­struc­tu­re libra­ry.[…] the seman­tic core will defi­ne models for a fami­ly of onto­lo­gi­cal­ly gro­un­ded models defi­ning all aspects of sys­tems, inc­lu­ding the­ir requ­ire­ments, envi­ron­ment, spe­ci­fi­ca­tion and imple­men­ta­tion. This will ena­ble a trans­i­tion from tra­di­tio­nal and manu­al sys­tems buil­ding tech­ni­qu­es to an auto­ma­ted and human-focu­sed para­digm. (źr. Semantic Core).

Powyżej (moje wytłusz­cze­nia) głów­ne cele tej orga­ni­za­cji (pole­cam zapo­zna­nie się z całą stroną)

  • nasza wizja to zło­żo­ne sys­te­my opi­sy­wa­ne i przed­sta­wia­ne w posta­ci mode­li na wyso­kim pozio­mie abstrakcji,
  • w tym celu defi­niu­je­my znor­ma­li­zo­wa­ny meta­mo­del opi­sa­ny sys­te­mem zna­czeń (seman­ty­ka) nie­za­leż­nym od notacji,
  • two­rzy­my to w zgo­dzie z ini­cja­ty­wa­mi OMG (www​.omg​.org),
  • seman­tic core” okre­śla stan­dar­do­wy zestaw klu­czo­wych pojęć i ich zna­czeń, opi­su­ją­cych wszyst­kie aspek­ty sys­te­mów, w tym ich wyma­ga­nia, oto­cze­nie, spe­cy­fi­ka­cji i implementacje.

Wygląda jak baj­ka ale nie jest tak źle, a coś takie­go jest bar­dzo przy­dat­ne. Nie ma sen­su budo­wa­nie jed­nej mega-nota­cji do wszyst­kie­go, widać to po pra­cach OMG (i po tym, że UML jed­nak nie zastą­pił innych nota­cji, i nikt roz­sąd­ny chy­ba już tego nie pla­nu­je). Jednak uzna­jąc fakt, że uży­wa­my (dobra prak­ty­ka) nota­cji wła­ści­wych dla roz­wią­zy­wa­ne­go pro­ble­mu (zary­zy­ku­ję tezę: wła­ści­wa to moż­li­wie naj­prost­sza i wystar­cza­ją­ca) war­to jed­nak zadbać o ich kom­pa­ty­bil­ność”. Część wspól­na to nie nowa nota­cja, a utrzy­ma­nie spój­no­ści zna­czeń współ­dzie­lo­nych pojęć ist­nie­ją­cych już notacji.

SemanticCore
(źr. SemanticCore​.org)

O złożoności

Na co war­to zwró­cić uwa­gę? Otóż w pro­ce­sie każ­dej więk­szej ana­li­zy poja­wia się zło­żo­ność, nad któ­rą nale­ży zapa­no­wać. Bez tego opa­no­wa­nia poja­wia się coś co zabi­ja pro­jek­ty ana­li­tycz­ne: utra­ta pano­wa­nia nad zło­żo­no­ścią pro­ble­mu, poja­wia­ją się mega-dia­gra­my i mega for­mu­la­rze danych.

Kilka tygo­dni temu, w jed­nym z moich pro­jek­tów, mia­łem oka­zję wejść w mały spór na temat tego, kie­dy udo­ku­men­to­wać szcze­gó­ło­wo spo­sób kla­sy­fi­ka­cji (ozna­cza­nia) pozy­cji budże­to­wych w sys­te­mie zarzą­dza­nia pro­ce­sem two­rze­nia budże­tu i jego reali­za­cji. Zamawiający od razu wcho­dził (wręcz żądał) w szcze­gó­ły, czy­li naście rodza­jów każ­de­go z ogrom­nej licz­by typów wydat­ków. Jeszcze bym dobrze nie ruszył z miej­sca a już został bym zgnie­cio­ny licz­bą tych szcze­gó­łów. Do tego dorzu­ca­no mi peł­ną szcze­gó­ło­wość struk­tu­ry orga­ni­za­cyj­nej (tak­że prze­kła­da się na budżet jako miej­sca wyda­wa­nia środ­ków). Dodam, że struk­tu­ra orga­ni­za­cyj­na zmie­ni­ła się w cią­gu roku trzy razy.

Co z tym zro­bić? Wyrzucić” te szcze­gó­ły na sam koniec! One są na począt­ku zupeł­nie nie­istot­ne (nie licząc zapo­zna­nia się nimi jako obec­nie funk­cjo­nu­ją­cym sys­te­mem), każ­dy zaś kto twier­dzi, że jed­nak są istot­ne już teraz, po pro­stu jesz­cze nie zro­zu­miał ana­li­zo­wa­ne­go problemu.

Problemem są pryn­cy­pia czy­li co i po co” a nie jak”. Owo jak” to dopie­ro pro­jek­to­wa­nie. Tak więc np. budżet, pro­ces jego two­rze­nia a potem reali­za­cji, to jakiś sys­tem pozy­cji budże­to­wych” i zda­rzeń zwią­za­nych z jego reali­za­cją. Jakaś logi­ka tej cało­ści (dalej jako regu­ły biz­ne­so­we i decy­zyj­ne). To jak zosta­nie ozna­czo­na (jakim sym­bo­lem itp.) to efekt tego co chce­my osią­gnąć. Każdy kto chwy­ci się od razu za te szcze­gó­ły (jakieś one są, mamy je już więc dla­cze­go się za nie nie zabrać), zaczy­na od koń­ca i w zasa­dzie zarzu­cił ana­li­zę i odciął sobie (klien­to­wi) moż­li­wość zbu­do­wa­nia opty­mal­ne­go (nowe­go) roz­wią­za­nia (zapew­ne inne­go niż obec­ne) na rzecz obecnego.

Należy na począt­ku pra­co­wać na abs­trak­cji, uogól­nie­niu pozwa­la­ją­cym sku­pić się na kil­ku­na­stu pryn­cy­piach zamiast na tysią­cach szcze­gó­łów. To pierw­sze jest rela­tyw­nie łatwe, to dru­gie w zasa­dzie niemożliwe.

abstraction systemcore_org
(źr. SemanticCore​.org)

Modele

Jak wspo­mnia­no powy­żej, typów mode­li (nota­cji) mamy wię­cej niż jeden. Każdy model (rodzaj mode­lu) ma swój dedy­ko­wa­ny sys­tem pojęć, po ubra­niu go w iko­ny mamy nota­cję (język obraz­ko­wy), czy­li język opi­sa­ny seman­ty­ką (zna­cze­nia pojęć) i syn­tak­ty­ką (ich wza­jem­ne, dopusz­czal­ne rela­cje). Zestaw pojęć powi­nien być dobra­ny sto­so­wa­nie do roz­wią­zy­wa­ne­go pro­ble­mu (wybór wła­ści­wej do eta­pu pra­cy notacji).

Jak wska­za­no wyżej, mamy czte­ry klu­czo­we sys­te­my pojęciowe:

  1. UML czy­li obiek­to­wy para­dyg­mat opi­su i projektowania,
  2. Ontologia (biz­ne­so­wa, sys­te­mo­wa), któ­rą obec­nie repre­zen­tu­ją Model Motywacji Biznesowej (w mię­dzy cza­sie tak­że doro­bił się ikon), SBVR i sys­te­my poję­cio­we opi­sy­wa­nia archi­tek­tu­ry kor­po­ra­cyj­nej, struk­tu­ry organizacji,
  3. Procesy biz­ne­so­we,
  4. Reguły biz­ne­so­we.

Wspólny śro­dek ma już swo­je zarze­wie”. W 2010 roku wyda­no ostat­nią spe­cy­fi­ka­cję Modelu Motywacji Biznesowej (ang. BMM). Można przy­jąć, że ten sys­tem poję­cio­wy (teraz tak­że nota­cja) to ele­ment biz­ne­so­wej onto­lo­gii. Pojawił się w niej doda­tek F zaty­tu­ło­wa­ny Powiązane spe­cy­fi­ka­cje mode­lo­wa­nia w OMG. I co my tu mamy?

Ano mamy stwier­dze­nie, że ta kom­pa­ty­bil­ność jest potrzeb­na. Napisano, że BMM współ­dzie­li pew­ne poję­cia z taki­mi sys­te­ma­mi poję­cio­wy­mi jak:

  1. BPMN (w BMM poja­wia się poję­cie pro­ces biznesowy)
  2. SBVR (BMM tak­że ope­ru­je poję­ciem Reguła Biznesowa)
  3. OSM (Organization Structure Metamodel, BMM uży­wa poję­cia komór­ka organizacyjna”).

Co cie­ka­we poję­cia te mają w OMG wspól­ne defi­ni­cje (te same poję­cia lub poję­cia dają­ce się mapo­wać 1:1). Utrzyma jest zgod­ność roli w pro­ce­sie biz­ne­so­wym i roli jako ele­men­tu struk­tu­ry orga­ni­za­cyj­nej w tych sys­te­mach (OSM, BPMN, BMM).

W spe­cy­fi­ka­cji BMM v.1.1 znaj­dzie­my taki oto diagram:

BMMOvierwiev

Notacje, któ­re wpa­dły” w ręce OMG maja wła­śnie tę bar­dzo pożą­da­ną i przy­jem­ną cechę: są kom­pa­ty­bil­ne. Wspominałem swe­go cza­su o nota­cji ArchiMate (obec­nie nale­ży do The Open Group podob­nie jak i TOGAF). Niestety nie ma tu tej kom­pa­ty­bil­no­ści, mimo że TOGAF nie jest samo­wy­star­czal­nym mode­lem (wyma­ga sto­so­wa­nia innych nota­cji poza ArchiMate), w efek­cie nie widzę moż­li­wo­ści pro­ste­go” zasto­so­wa­nia ram TOGAF”a jako bazo­wej archi­tek­tu­ry kor­po­ra­cyj­nej, bo kolej­ne eta­py uszcze­gó­ła­wia­nia mode­li (a od tego nie ma uciecz­ki w pro­jek­tach) albo będą mia­ły kło­po­ty z jed­no­znacz­no­ścią albo będą wyma­ga­ły jakie­goś dedy­ko­wa­ne­go sys­te­mu tłu­ma­cze­nia pojęć TOGAF na UML, BPMN (BMM nie, bo TOGAF od ostat­niej wer­sji dublu­je – nie wiem czy w 100% i po co – poję­cia mode­lu moty­wa­cji biznesowej.

Nie wymie­ni­łem tu nota­cji UML bo ta słu­ży do obiek­to­we­go mode­lo­wa­nia (para­dyg­mat obiek­to­wy) sys­te­mów. Nie widzę sen­su wpy­cha­nia” jej w dzie­dzi­nę onto­lo­gii zarzą­dza­nia. Paradygmat obiek­to­wy to inne spoj­rze­nie, sys­te­mo­we, opi­su­ją­ce współ­dzia­ła­ją­ce obiek­ty”, jed­nak to wtór­ny model, bo te obiek­ty sys­te­mo­we repre­zen­tu­ją” komór­ki orga­ni­za­cyj­ne, stra­te­gie, regu­ły biz­ne­so­we, doku­men­ty itp. Modele obiek­to­we są dosko­na­łe jako wstęp do pro­jek­to­wa­nia opro­gra­mo­wa­nia imple­men­to­wa­ne­go z pomo­cą obiek­to­wo zorien­to­wa­nych narzę­dzi. Są kom­plet­nie nie­przy­dat­ne jako biz­ne­so­wy sys­tem poję­cio­wy. Owszem, nie raz tu wspo­mi­na­ny DDD (spo­sób mode­lo­wa­nia dzie­dzi­ny sys­te­mu) to pew­ne takie połą­cze­nie, ale to raczej most niż ekwi­wa­lent. Patrząc na ten pro­blem z per­spek­ty­wy MDA (OMG, Model Driven Architecture) model CIM (Computing Independent Model) to powyż­sze mode­le (BMM, BPMN), UML ma zasto­so­wa­nie dla czę­ści PIM (wstęp­ny model imple­men­ta­cji w posta­ci opro­gra­mo­wa­nia) i tu jest dopie­ro miej­sce na DDD.

Tak więc bat na szcze­gó­ły jest: to pro­sta zasa­da od ogó­łu do szcze­gó­łu”, na każ­dym eta­pie mamy sto­sow­ną nota­cję (pro­sty sys­tem pojęć). Należy uogól­niać i mode­lo­wać, i potem stop­nio­wo uszcze­gó­ła­wiać mode­le aż do momen­tu doj­ścia do imple­men­ta­cji dane­go systemu.

TheMetaModelArchitecture

Powyżej obraz z nanie­sio­ny­mi eta­pa­mi [[MDA]] (wię­cej o Model Driven Architecture oraz Meta Object Facility – powyż­szy rysu­nek – na stro­nach OMG). Core Semantic to szczyt (M3) powyż­sze­go. Wymienione wyżej nota­cje to war­stwa M2 (UML dodat­ko­wo obej­mu­je tak­że M1).

Konkluzja jest taka: bazy danych zawie­ra­ją­ce szcze­gó­ło­wość sys­te­mu, pro­jek­tu­je­my na koń­cu. Szczegóły ele­men­tów budże­tu (przy­ta­cza­ny przy­kład) opra­co­wu­je­my dopie­ro jako pomysł na imple­men­ta­cję, mamy to jed­nak dwa pozio­my implementacji:

  1. roz­wią­za­nie pro­ble­mu efek­tyw­ne­go zarzą­dza­nia budże­tem w nowej for­mie np. sys­tem zna­ko­wa­nia pozy­cji budżetowych,
  2. imple­men­ta­cja tego sys­te­mu jako opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go ten pro­ces w organizacji.

To wszyst­ko powin­no być jed­nak poprze­dzo­ne ana­li­zą. Analiza obec­nej sytu­acji nie pole­ga jed­nak na jej 100% odwzo­ro­wa­niu w doku­men­tach ana­li­tycz­nych, a jedy­nie na pozna­niu w celu zro­zu­mie­nia celu biz­ne­so­we­go, opra­co­wa­nie jego mode­lu, i potem dopie­ro roz­wią­zy­wa­nie pro­ble­mu: jak to osiągnąć.

Na koniec pew­na uwa­ga :). Ktoś może powie­dzieć: biz­nes tego (nota­cje, mode­le itp.) nie rozu­mie. I ma racje, bo to narzę­dzia a nie pro­duk­ty ana­liz. Produktem ana­li­zy dla biz­ne­su są zawsze reko­men­da­cje (wyma­ga­nia na opro­gra­mo­wa­nie to tak­że rodzaj reko­men­da­cji brzmią­cej: zale­cam by takie warun­ki speł­nia­ło to opro­gra­mo­wa­nie). Zamawianie przez biz­nes mode­li jako takich, to jakieś kosz­mar­ne nie­po­ro­zu­mie­nie. To tak jak by np. praw­nik, jako pro­dukt zle­ce­nia opi­nia praw­na” oddał wybra­ny stos kodek­sów z komen­ta­rza­mi. Nie, dobry praw­nik odda­je jed­na stro­nę reko­men­da­cji: opi­nie praw­ną. To, że sko­rzy­stał z tych kodek­sów to jego narzę­dzie pra­cy, moż­li­we, że załą­czy je do tej tej opi­nii (ale raczej jako mate­riał dla inne­go praw­ni­ka lub audytora).