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

Domain-Specific Conceptual Modeling czyli logika wydzielona z modelu procesu

Tę recen­zje książ­ki zacznę nie­co ina­czej. Swego cza­su pisa­łem, że war­to sto­so­wać regu­ły biz­ne­so­we w mode­lo­wa­niu pro­ce­sów. Zwracałem uwa­gę na to, że nie ma sen­su mode­lo­wa­nie decy­zji w BPMN…

… 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):Proces biz­ne­so­wy w nota­cji BPMN z wydzie­lo­ny­mi pro­ce­du­rą i regu­ła biznesową.

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

(Źródło: Reguły Biznesowe | Jarosław Żeliński IT-Consulting

Nie jest ta kon­klu­zja spe­cjal­ną nowością:

Powyższy cytat pocho­dzi z książki: 

? 2016 Domain-Specific Conceptual Modeling, Concepts, Methods and Tools Herausgeber: Karagiannis, Dimitris, Mayr, Heinrich C., Mylopoulos, John (Eds.) Presents nume­ro­us doma­in-spe­ci­fic con­cep­tu­al mode­ling methods by respec­ted tho­ught leaders (Domain-Specific Conceptual Modeling – Concepts, Methods | Dimitris Karagiannis | Springer

I w ten zawo­alo­wa­ny spo­sób recen­zu­je tę książ­kę. Książka do tanich nie nale­ży. Zawiera arty­ku­ły nauko­we na temat sze­ro­ko poję­te­go mode­lo­wa­nia. Materiał bar­dzo aka­de­mic­ki, jed­nak sta­no­wi pew­ne pod­su­mo­wa­nie obec­ne­go sta­nu wie­dzy. Warto jed­nak mieć wie­dzę o tym co się dzie­je na świe­cie i w nauce by po pierw­sze nie wywa­żać otwar­tych drzwi, po dru­gie by nie bro­nic tez daw­no obalonych.…

W książ­ce jest wie­le odnie­sień do narzę­dzia i nota­cji ADOnis. Autorzy podej­mu­ją pró­by two­rze­nia nowych nota­cji, co jest minu­sem tej pozy­cji. Jednak jeże­li abs­tra­ho­wać o tych pomy­słów to moż­na się zapo­znać z aktu­al­nym sta­nem podej­ścia do mode­lo­wa­nia organizacji. 

Źródło

Karagiannis, D., Mayr, H. C., & Mylopoulos, J. (Eds.). (2016). Domain-Specific Conceptual Modeling: Concepts, Methods and Tools (1st ed. 2016). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 39417‑6

Metareguły i zasady budowy cyfrowych usług publicznych

Kolejne pro­jek­ty IT zali­cza­ją kolej­ne wpad­ki i wśród przy­czyn pra­wie zawsze poja­wia się utra­ta pano­wa­nia nad zło­żo­no­ścią pro­jek­tu. Jednym z klu­czo­wych ele­men­tów ana­li­zy, tak­że sys­te­mo­wej, jest redu­ko­wa­nie zło­żo­no­ści. Robi się to budu­jąc mode­le i meta­mo­de­le ana­li­zo­wa­nej rze­czy­wi­sto­ści, a na wstęp­nych eta­pach pro­jek­to­wa­nia abs­tra­hu­je się od szcze­gó­łów. Jak? Operując wła­śnie mode­la­mi i meta­mo­de­la­mi. Od daw­na noszę się z zamia­rem napi­sa­nia cze­goś o zarzą­dza­niu zło­żo­no­ścią i spój­no­ścią doku­men­tów. W koń­cu nawi­nął” się doku­ment, na któ­rym moim zda­niem war­to poćwi­czyć”. Jest to cie­ka­wy doku­ment zatytułowany:

Metareguły i zasa­dy budo­wy cyfro­wych usług publicznych

We wstę­pie pozna­je­my cel i (chy­ba) misję projektu:

?Obywatel jest anga­żo­wa­ny w naj­mniej­szym moż­li­wym stop­niu w pro­ces świad­cze­nia usług publicz­nych, zaś usłu­gi rozu­mia­ne są jako pro­ces zaspo­ka­ja­nia potrzeb obywateli.? 

Często zamiast nowo­cze­snej usłu­gi cyfro­wej efek­tem prac jest ?zelek­tro­ni­zo­wa­na? pro­ce­du­ra, któ­ra tym róż­ni się od tra­dy­cyj­ne­go spo­so­bu zała­twia­nia spra­wy, że wnio­sek wypeł­nia­ny jest przy pomo­cy kom­pu­te­ra. Stosuje się róż­ne stan­dar­dy budo­wy usług cyfro­wych, jak i ich roz­wo­ju, co wpły­wa bez­po­śred­nio na róż­ni­ce w jako­ści, dostęp­no­ści i uży­tecz­no­ści tych usług. Aby unik­nąć takich nega­tyw­nych efek­tów, w wie­lu miej­scach na świe­cie wdro­żo­no wytycz­ne do budo­wy i utrzy­ma­nia usług cyfro­wych, gwa­ran­tu­ją­ce ustan­da­ry­zo­wa­ne podej­ście nie­za­leż­nie od pod­mio­tu wdra­ża­ją­ce­go usłu­gę. Głównym bene­fi­cjen­tem takie­go podej­ścia jest użyt­kow­nik końcowy.
Postawienie użytkownika?klienta admi­ni­stra­cji i jego potrzeb w cen­trum ozna­cza, że tech­no­lo­gie infor­ma­cyj­ne i komu­ni­ka­cyj­ne poma­ga­ją admi­ni­stra­cji w zała­twie­niu SPRAWY KLIENTA, a nie zała­twie­niu SPRAWY PRZEZ KLIENTA. Podejście to zakła­da, że oby­wa­tel jest anga­żo­wa­ny w naj­mniej­szym moż­li­wym stop­niu w pro­ces świad­cze­nia usług publicz­nych, zaś usłu­gi rozu­mia­ne są jako pro­ces zaspo­ka­ja­nia potrzeb oby­wa­te­li. (Źródło: Metareguły i zasa­dy budo­wy cyfro­wych usług publicz­nych | Ministerstwo Cyfryzacji, plik  metareguly_i_zasady_budowy_uslug_cyfrowych_ready)

Postanowiłem na przy­kła­dzie tego opra­co­wa­nia poka­zać na czym pole­ga redu­ko­wa­nie szcze­gó­łów w ana­li­zie. Dokument ten jest trud­ny do oce­ny i zro­zu­mie­nia w przy­pad­ku czy­ta­nia go wprost, z uwa­gi na to, że nie zawie­ra żad­nych uogól­nień, a mało któ­ry czy­tel­nik jest w sta­nie zbu­do­wać sobie w myśli taki pro­sty” model cało­ści. W tytu­le poja­wia dość trud­ne nie tyl­ko dla laika, poję­cie meta­re­gu­ły”. Czym one są? Najpierw kil­ka słow na temat tego czym są poję­cia z przed­rost­kiem meta-.

Meta- czyli co…

Zacznijmy od zna­cze­nia przed­rost­ka meta-” (sł. j. pol­skie­go PWN):

meta- ?pierw­szy człon wyra­zów zło­żo­nych wska­zu­ją­cy na wyż­szy sto­pień, następ­stwo lub zmien­ność czegoś?

W ramach OMG funk­cjo­nu­je spe­cy­fi­ka­cja Meta-Object Facility”. Zawiera ona mię­dzy inny­mi takie o to wyjaśnienie:

7.3 How Many Meta Layers?
One of the sour­ces of con­fu­sion in the OMG suite of stan­dards is the per­ce­ived rigid­ness of a ?Four lay­ered meta­mo­del archi­tec­tu­re? that is refer­red to in vario­us OMG spe­ci­fi­ca­tions. Note that key mode­ling con­cepts are Classifier and Instance or Class and Object, and the abi­li­ty to navi­ga­te from an instan­ce to its meta­object (its clas­si­fier). This fun­da­men­tal con­cept can be used to han­dle any num­ber of lay­ers (some­ti­mes refer­red to as metalevels).

Wytłuściłem klu­czo­we ele­men­ty tego opi­su. Podstawowymi poję­cia­mi są kla­sy­fi­ka­tor i instan­cja” lub zna­ne z UML kla­sa i obiekt” oraz moż­li­wość nawi­ga­cji (śla­do­wa­nie) od instan­cji do jej meta­obiek­tu” (czy­li kla­sy­fi­ka­to­ra tej instan­cji). Na stro­nach WIKI jest dość popu­lar­ny w sie­ci przy­kład w posta­ci czte­ro­war­stwo­we­go modelu:

metamodel-layers

Tych warstw nie nie zawsze jest (musi być) tyle, ale tu cho­dzi o zasa­dę. Każda sąsia­du­ją­ca z sobą para warstw to (licząc od dol­nej) obiekt (instan­cja) i jego kla­sy­fi­ka­tor (meta­obiekt). Para obiekt-kla­sy­fi­ka­tor łączo­na jest związ­kiem «instanceOf» wska­zu­ją­cym na kla­sy­fi­ka­tor (czy­ta­my: obiekt jest instan­cją kla­sy­fi­ka­to­ra). Powyższy przy­kład zawie­ra tak­że związ­ki «snap­shot» i pro­ste aso­cja­cje (np. clas­si­fier), któ­re zaciem­nia­ją jego głów­ny sens. Zawiera tak­że moim zda­niem błąd: zależ­ność pomię­dzy rze­czy­wi­sty­mi byta­mi a ich abs­trak­cja­mi to «Abstraction» a nie «instanceOf».

Przygotowałem więc, mam nadzie­ję, mniej abs­trak­cyj­ny przykład :):

mof-layers-package-diagram

Jak czy­tać ten dia­gram? Realny świat to Byty rze­czy­wi­ste, np. bier­ki do gry w sza­chy. Abstrakcja bytów rze­czy­wi­stych to zobra­zo­wa­nie ich w posta­ci nazwa­nych pro­sto­ką­tów: dia­gram z tymi pro­sto­ką­ta­mi to model kon­kret­nej rze­czy­wi­sto­ści ze zdję­cia. Każdy taki pro­sto­kąt to abs­trak­cja odpo­wied­niej bier­ki, czy­li pozby­cie się wszel­kich szcze­gó­łów (mate­riał z jakie­go są wyko­na­ne, kształt, itp.) nie potrzeb­nych do ana­li­zy np. reguł gry w sza­chy. Aby opi­sać w doku­men­ta­cji gry w sza­chy jej zasa­dy, i unik­nąć koniecz­no­ści czę­ste­go uży­wa­nia nazw poszcze­gól­nych bie­rek, tam gdzie nie ma zna­cze­nia to jak dana bier­ka może się poru­szać po sza­chow­ni­cy, korzy­sta­my z kla­sy­fi­ka­to­ra: kolej­ne­go uogól­nie­nia jakim jest Bierka repre­zen­tu­ją­ca wszyst­kie dopusz­czal­ne figu­ry na sza­chow­ni­cy. Diagram z jed­nym pro­sto­ką­tem, kla­sy­fi­ka­to­rem, to metamodel.

Biorąc pod uwa­gę fakt, że bar­dziej zło­żo­ne rze­czy­wi­sto­ści” mogły by wyma­gać bar­dzo dużej licz­by obiek­tów (pro­sto­ką­tów) na mode­lu, z regu­ły sto­su­je się w dal­szych eta­pach ana­liz meta­mo­de­le a nie abs­trak­cje. Te słu­żą raczej do two­rze­nia i testo­wa­nia meta­mo­de­li. Tak więc jeże­li wśród obiek­tów na mode­lu moż­na wyróż­nić gru­py o pew­nych podob­nych cechach, zastę­pu­je się je jed­nym kla­sy­fi­ka­to­rem. Reprezentuje on wszyst­kie te obiek­ty. W tym przy­pad­ku jeden kla­sy­fi­ka­tor Bierka zastę­pu­je na dia­gra­mie wszyst­kie kon­kret­ne bier­ki”. Możemy też powie­dzieć, że: obiekt Pion jest instan­cją kla­sy Bierka (podob­nie Wieża itd.). Konkretne rze­czy­wi­sta bier­ka np. Goniec, na kon­kret­nej sza­chow­ni­cy kon­kret­ne­go zesta­wu do gry w sza­chy, jest instan­cją obiek­tu Goniec z dia­gra­mu obiektów.

Tak więc model mode­lu to meta­mo­del, czy­li meta­me­ta­mo­del rze­czy­wi­sto­ści :). Czym więc będą meta­re­gu­ły? Niestety nie ma defi­ni­cji w tym opra­co­wa­niu. Poszukajmy.

Metareguły cha­rak­te­ry­zu­ją sta­łość lub zmien­ność w cza­sie wcze­śniej odkry­tych wzor­ców czy reguł (mogą to być regu­ły aso­cja­cyj­ne, kla­sy­fi­ku­ją­ce, opi­su­ją­ce lub inne). (źr. Barbara Łopusiewicz (red.), Zarządzanie wie­dzą w sys­te­mach infor­ma­cyj­nych. , Wydawnictwo Akademii Ekonomicznej, Wrocław 2004, ISBN: 83 – 7011-722 – 8 (34+16) (cytat, str. 216)).

Innymi sło­wy meta­re­gu­ły to regu­ły (two­rze­nia) reguł (tak jak meta­mo­del to model mode­lu). Trochę dzi­wi mnie, że wpro­wa­dzo­no poję­cie meta­re­gu­ły”. Pojęcie poli­ty­ki” było by moim zda­niem bliż­sze praw­dy: Polityka budo­wy cyfro­wych usług publicz­nych”, ale to tyl­ko dywa­ga­cje, nie chce two­rzyć wąt­ku ja bym to zro­bił ina­czej” ;). Warto jed­nak pod­su­mo­wać, że meta regu­ła to wzo­rzec budo­wy reguł a nie to cze­go one mają doty­czyć”… stąd moje zdzi­wie­nie uży­ciem poję­cia meta­re­gu­ły” w kon­tek­ście dziedzinowym.

Ten wpis to jed­nak pró­ba wzię­cia otwar­te­go udzia­łu w tych kon­sul­ta­cjach. Celem moim jest zło­że­nie ewen­tu­al­nych uwag, zastrze­żeń i ich uzasadnienie.

Metareguły i zasady budowy cyfrowych usług publicznych

Kilka klu­czo­wych pojęć w dokumencie:

1 Wstęp

We wstę­pie czytamy:

? zerwa­nie z dotych­cza­so­wym para­dyg­ma­tem ucy­fro­wie­nia (infor­ma­ty­za­cji) usług świad­czo­nych dotąd dro­gą tra­dy­cyj­ną; usłu­ga nie może być utoż­sa­mia­na z for­mu­la­rzem, poda­niem czy doku­men­tem, nawet elek­tro­nicz­nym, z moż­li­wo­ścią prze­sła­nia przez inter­net (zarzą­dze­nie infor­ma­cją, a nie jej nośnikiem),

Informacja to okre­ślo­ny, nazwa­ny zestaw danych. Zarządzanie infor­ma­cją jest moż­li­we pod warun­kiem, że zosta­nie utrwa­lo­na a jej struk­tu­ra okre­ślo­na (zde­fi­nio­wa­na). Struktura danych sta­no­wią­cych infor­ma­cję w posta­ci utrwa­lo­nej to nic inne­go jak for­mu­larz. Ustawodawca już jasno okre­ślił czym jest treść, nośnik a czym doku­ment. Innymi sło­wy: samo wyra­że­nie chę­ci sko­rzy­sta­nia z Usługi wyma­ga wyar­ty­ku­ło­wa­nia tego żąda­nia i prze­ka­za­nia w jakiejś utrwa­lo­nej for­mie. Nie da się zażą­dać od Państwa cze­goś nie mają moż­li­wo­ści wyra­że­nia tego żąda­nia. Tak wiec nie wiem z czym chce zry­wać autor doku­men­tu, ale usłu­ga: musi mieć nazwę, opis tego czym jest i musi ist­nieć spo­sób zle­ce­nia Państwu jej wyko­na­nia na rzecz oby­wa­te­la chcą­ce­go sko­rzy­stać z tej usługi.

? pro­ces świad­cze­nia usłu­gi odby­wa się na pozio­mach back-offi­ce i mid­dle-offi­ce, poziom front-offi­ce to ini­cjo­wa­nie usłu­gi i uzy­ski­wa­nie korzy­ści (zała­twie­nie spra­wy). Proces świad­cze­nia usłu­gi prze­su­wa­ny jest w stro­nę usłu­gi typu A2A, zaś rela­cja A2C sku­pia się na potrze­bach i korzy­ściach obywatela,

Powyższe jest więc potwier­dze­niem tego co napi­sa­łem… Z per­spek­ty­wy Obywatela poję­cia back-offi­ce i mid­dle-offi­ce nie mają żad­ne­go zna­cze­nia (i skąd wia­do­mo, ze aku­rat dwa??). Za to ów front-offi­ce” to nic inne­go jak punkt kon­tak­tu” a komu­ni­ka­cja z Obywatelem to nie­ste­ty jakiś for­mu­larz”. Proces (wy)świadczenia usłu­gi jest (powi­nien być, zgod­nie z tre­ścią wstę­pu) cał­ko­wi­cie ukry­ty przed Obywatelem.

? otwar­cie i inte­gra­cja reje­strów publicz­nych przy zapew­nie­niu bez­pie­czeń­stwa danych obywateli.

Rejestry publicz­ne to wnę­trze sys­te­mu”, z per­spek­ty­wy Obywatela nie ist­nie­ją” bo jaką usłu­gą (spra­wą mają­cą war­tość dla Obywatela) jest dostęp do reje­stru”? Jeżeli mam w kie­sze­ni Dowód Osobisty, to czym tu jest dostęp do Rejestru”?

2 Metareguły usług cyfrowych dla obywatela

Metareguły doty­czą spo­so­bu funk­cjo­no­wa­nia admi­ni­stra­cji publicz­nej w kon­tek­ście świad­cze­nia usług w sfe­rze cyfro­wej. Są one klu­czo­we pod­czas budo­wy i świad­cze­nia cyfro­wych usług publicznych.

Traktuję to jako preambułę.

? Potrzeby i korzy­ści oby­wa­te­la są w cen­trum ? na każ­dym eta­pie pro­ce­su świad­cze­nia usłu­gi punk­tem odnie­sie­nia jest potrze­ba oby­wa­te­la, mia­rą suk­ce­su jest korzyść uzy­ska­na przez obywatela.

Rozumiem, że usłu­ga to odpo­wiedź na potrze­bę (jej zaspo­ko­je­nie), pro­duk­tem usłu­gi jest coś” z cze­go oby­wa­tel odno­si korzyść. Jednak korzyść oby­wa­tel nie powin­na być przed­mio­tem zain­te­re­so­wa­nia Państwa bo z jakie­go powo­du? Jeżeli chcę doku­ment potwier­dza­ją­cy coś” lub będą­cy decy­zją admi­ni­stra­cyj­ną” to to, jaką korzyść ja odnio­sę zale­ży ode mnie i kon­tek­stu. Np. wypis z kata­stru to pro­dukt usłu­gi, ale moja korzyść z jego posia­da­nia (może chce sprze­dać nie­ru­cho­mość, a może się zało­ży­łem z kimś, że jest moja i chce to udo­wod­nić). Wprowadzanie tu poję­cia korzyść oby­wa­te­la” jest moim zda­niem nadmiarowe.

? Usługi są świad­czo­ne w tle ? mini­ma­li­za­cja wyma­gań wobec klien­ta, ogra­ni­cze­nie eta­pów pro­ce­su admi­ni­stra­cyj­ne­go do mini­mum, oso­bi­ste sta­wien­nic­two wnio­sko­daw­cy jako wyjątek.

Jeżeli uma­wia­my się, że celem jest zała­twie­nie SPRAWY KLIENTA, a nie zała­twie­nie SPRAWY PRZEZ KLIENTA” to powyż­sze jest jej łama­niem, mini­ma­li­za­cja wyma­gań wobec klien­ta” powin­na być raczej zastą­pio­na albo bra­kiem wyma­gań albo (co bar­dziej praw­do­po­dob­ne) okre­ślo­ny­mi kon­kret­ny­mi wyma­ga­nia­mi (a takie są zawsze, np. tytuł praw­ny do nie­ru­cho­mo­ści w przy­pad­ku żąda­nia wypi­su z księ­gi wieczystej).

? Administracja jest pod­sta­wo­wym źró­dłem danych ? pobie­ra­nie danych z reje­strów pań­stwo­wych; zakaz wyma­ga­nia od oby­wa­te­la infor­ma­cji będą­cych już w posia­da­niu admi­ni­stra­cji, moż­li­wych do uzy­ska­nia auto­ma­tycz­nie dro­gą elek­tro­nicz­ną bądź wyni­ka­ją­cych z pro­ce­su świad­cze­nia usług.

To już mamy za sobą: urząd (Państwo) nie może żądać od oby­wa­te­la danych, któ­ry­mi juz dysponuje.

? Dokumenty skie­ro­wa­ne do oby­wa­te­la umiesz­cza­ne są w repo­zy­to­rium? w sytu­acji, w któ­rej oby­wa­tel nie potrze­bu­je (nie zwra­ca się o wyda­nie) doku­men­tu koń­czą­ce­go świad­cze­nie usłu­gi (postę­po­wa­nie admi­ni­stra­cyj­ne), ma moż­li­wość pobra­nia go w dowol­nym momencie.

To jest już imple­men­ta­cja, oso­bi­ście uwa­żam, że na pozio­mie meta­re­guł (meta­mo­de­li) nie ope­ru­je się imple­men­ta­cją (repo­zy­to­rium), suge­ru­ję poję­cie archi­wum” i tecz­ka sprawy”.

? Dostęp do infor­ma­cji o sta­nie spra­wy jest moż­li­wy na każ­dym eta­pie ? sys­tem trans­ak­cyj­ny obsłu­gu­ją­cy usłu­gę daje oby­wa­te­lo­wi moż­li­wość spraw­dze­nia sta­tu­su zała­twia­nej spra­wy i sza­cun­ko­we­go cza­su do jej zakoń­cze­nia, na klu­czo­wych eta­pach spra­wy użyt­kow­nik otrzy­mu­je powiadomienia;

Tu jak wyżej… sko­ro oby­wa­tel ma moż­li­wość pobra­nia go [doku­men­tu] w dowol­nym momen­cie” to chy­ba mamy tu zbęd­ne powtó­rze­nie treści.

? Usługi łączo­ne są w pakie­ty ? powią­za­nie usług wyni­ka­ją­cych z danej potrzeby/zdarzenia życio­we­go (np. naro­dzi­ny dziec­ka, beci­ko­we, Rodzina 500+ – użyt­kow­nik ma moż­li­wość zała­twie­nia ich wszyst­kich w jed­nej transakcji).

To chy­ba ktoś popły­nął. O jakiej trans­ak­cji mowa” (zno­wu imple­men­ta­cja na pozio­mie meta­re­guł). Usługi są auto­no­micz­ne i nie­za­leż­ne, jeże­li ktoś uzna, ze chce sko­rzy­stać z kil­ku” (pakiet) to jest to kon­tekst klien­ta a nie sys­te­mu. Próba two­rze­nia nazwa­nych pakie­tów” pro­wa­dzi do nie­wy­obra­żal­nej licz­by kom­bi­na­cji (zakła­dam, że usług będzie nie kil­ka a znacz­nie więcej).

? Projektowanie uni­wer­sal­ne ? respon­syw­ność, dostęp­ność z róż­nych plat­form sprzę­to­wych oraz dla osób nie­peł­no­spraw­nych ? uwzględ­nie­nie wytycz­nych WCAG 2.0.

Znowu imple­men­ta­cja.

? Interfejs użyt­kow­ni­ka ? zasto­so­wa­nie wytycz­nych doty­czą­cych wyglą­du stron inter­ne­to­wych i apli­ka­cji udo­stęp­nia­ją­cych e‑usługi.

Znowu imple­men­ta­cja.

? Bezpieczeństwo i nie­za­wod­ność ? zapew­nie­nie bez­pie­czeń­stwa danych w war­stwie tech­no­lo­gicz­nej oraz pew­no­ści pra­wa w trak­cie świad­cze­nia usługi.

Tego nie rozu­miem. Co ma Obywatel do danych w war­stwie tech­no­lo­gicz­nej”, jak mam rozu­mieć poję­cie pew­no­ści pra­wa w trak­cie świad­cze­nia usługi”?

? Otwartość na inte­gra­cje ? dostar­cze­nie API, któ­re pozwo­li wpiąć Twoją usłu­gę do więk­sze­go pakie­tu i/lub zin­te­gro­wać ją z por­ta­lem GOV​.PL

Integrację z czym sko­ro oby­wa­tel to aktor” sys­te­mu? Czy cho­dzi o to, że pań­stwo ma świad­czyć usłu­gi nie tyl­ko Obywatelom ale tak­że zewnętrz­nym sys­te­mom”? Może war­to to doprecyzować?

3 Zasady budowy cyfrowych usług publicznych

Tu poja­wia­ją się ele­men­ty dla mnie nie­zro­zu­mia­łe, któ­re skomentuję.

1. Sprawdź, cze­go potrze­bu­ją odbior­cy (pro­jek­to­wa­nie usług)

Odbiorcy, czy­li rozu­miem Obywatele/Klienci (słow­nik pojęć by się przy­dał). Tak się skła­da, że Urzędy dzia­ła­ją na pod­sta­wie pra­wa więc nie bar­dzo wiem co tu jesz­cze z nimi ustalać?

2. Minimalizuj obcią­że­nia po stro­nie użyt­kow­ni­ka (pro­jek­to­wa­nie usług)

To bar­dzo ogól­nie sfor­mu­ło­wa­ne wyma­ga­nia poza­funk­cjo­nal­ne”, jed­nak brak kry­te­rium pozwa­la­ją­ce­go stwier­dzić czy zosta­ło wyko­na­ne, pozo­sta­je oświad­cze­nie mini­ma­li­zo­wa­li­śmy”.

3. Pamiętaj, że usłu­ga jest pro­ce­sem (pro­jek­to­wa­nie usług)

Jeżeli na począt­ku czy­ta­my, że zała­twia­niu SPRAWY KLIENTA, a nie zała­twie­niu SPRAWY PRZEZ KLIENTA” to tu autor zaprze­cza sam sobie.

4. Pozyskuj od klien­tów tyl­ko nie­zbęd­ne dane (pro­jek­to­wa­nie usług)

Jeżeli wcze­śniej napi­sa­no, że Państwo nie może żądać od Obywatela danych któ­re juz posia­da, to ten zapis jest chy­ba zbędny.

5. Projektuj uni­wer­sal­ne usłu­gi dla wszyst­kich odbior­ców (pro­jek­to­wa­nie usług)

To tak­że chy­ba oczywistość?

Podsumowanie

Niestety nie było moim celem komen­to­wa­nie cało­ści, były­by to zbli­żo­ne do powyż­szych komen­ta­rze. Cały doku­ment wyglą­da trosz­kę jak atra­pa Manifestu Agile”. Dokument jest nie­pre­cy­zyj­ny i nie wiem jak wyglą­da­ło by korzy­sta­nie z nie­go. Warto zwró­cić uwa­gi na potrze­bę upo­rząd­ko­wa­nia pojęć i dome­ny problemu:

model-pojeciowy-uslugi-publiczne

Takie poję­cia jak korzyść oby­wa­te­la czy potrze­ba oby­wa­te­la są nie tyl­ko nie­pre­cy­zyj­ne ale i nad­mia­ro­we w moich oczach. System świad­czą­cy oby­wa­te­lo­wi usłu­gi to, z per­spek­ty­wy tego oby­wa­te­la, coś” co wyda z sie­bie coś na żąda­nie, któ­re to żąda­nie nale­ży popraw­nie sfor­mu­ło­wać. I nic więcej.

system-uslug-publicznych

Powyższe to szkie­let takie­go sys­te­mu. Co do zasa­dy mamy tu metau­słu­gę mają­cą jako instan­cje kon­kret­ne usłu­gi, meta­klien­ta mają­ce­go dwie instan­cje: czło­wie­ka korzy­sta­ją­ce­go z GUI oraz apli­ka­cje korzy­sta­ją­cą z API.

Konkluzja 1.: usłu­gę świad­czy Państwo więc nie widzę innej moż­li­wo­ści by zło­że­nie poda­nia mia­ło sie odbyć ina­czej niż przez GUI.

Konkluzja 2.: reje­stra­mi są tak­że Archiwa, więc śle­dze­nia sta­nu spraw nie powin­no być kłopotem.

Konkluzja 3.: sko­ro pro­ces wewnętrz­ny ma być ukry­ty przez Obywatelem, to zna­czy że nie bie­rze on w ogó­le z nim udzia­łu, czy­li te System nie jest apli­ka­cją work­flow” z per­spek­ty­wy Obywatela.

Na zakończenie

W pro­jek­tach, któ­rych celem jest z jed­nej stro­ny porząd­ko­wa­nie opi­su sys­te­mów od stro­ny wyma­gań na nie, a z dru­giej narzu­ce­nie pew­nych rygo­rów na ich pro­jek­to­wa­nie, wygod­ną meto­dą jest uży­cie mode­li kon­tek­sto­wych (tu przy­pad­ki uży­cia) oraz two­rze­nie tak zwa­nych poli­tyk, czy­li zesta­wu reguł, zasad narzu­ca­ją­cych ogra­ni­cze­nia np. na archi­tek­tu­rę, meto­dy inte­gra­cji itp. Do tego korzy­sta­nie na tym eta­pie z meta­mo­de­li sko­ja­rzo­nych z tymi poli­ty­ka­mi, powin­no pomóc w utrzy­ma­niu pro­sto­ty doku­men­tu. Obecna postać doku­men­tu sta­no­wi pew­ne prze­mie­sza­nie tych tre­ści. Wstęp to w zasa­dzie rodzaj pre­am­bu­ły. Kolejny roz­dział nazwał bym raczej wyma­ga­nia­mi biz­ne­so­wy­mi a nie meta­re­gu­ła­mi”, z powo­du opi­sa­ne­go wyżej. Rozdział 3. to jakaś nie­do­pre­cy­zo­wa­na for­ma prze­ka­za­nia dobrych prak­tyk i wzor­ców oraz, co wska­za­łem, tak­że tych mniej dobrych. Bardzo zasko­czy­ła mnie algo­ryt­mi­za­cja” pro­jek­to­wa­nia, któ­ra nota­be­ne kłó­ci się z zasa­dą: usłu­ga a nie anga­żo­wa­nie oby­wa­te­la w pro­ces. Ten algo­rytm” (cze­mu algo­rytm a nie pro­ces?) anga­żu­je oby­wa­te­la w pro­ces reali­zo­wa­nia usłu­gi w kil­ku miejscach.

c.d.n.

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”

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.