Digital Finance Excellence mówi…

Reguły biznesowe, decyzje i pojęcia

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

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 ogól­ny spo­sób postę­po­wa­nia, ogól­ny bo 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 to 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 to 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)

Warsztaty analityczne – czyli malowanie trawy

W koń­czą­cym się roku trzy razy mia­łem do czy­nie­nia z nie mały­mi (czy­taj kosz­tow­ny­mi) doku­men­ta­mi zawie­ra­ją­cy­mi mode­le pro­ce­sów biz­ne­so­wych” i spe­cy­fi­ka­cję wyma­gań”. Wszystkie trzy mia­ły pew­ne wspól­ne cechy:

  1. były pro­ble­my z przy­dat­no­ścią tych doku­men­tów, co było powo­dem popro­sze­nia mnie o oce­nę i reko­men­da­cje w kwe­stii ich naprawy,
  2. wszyst­kie były pro­duk­tem zbio­ro­wych warsz­ta­tów pro­ce­so­wych” i warsz­ta­tów wyma­gań” z pra­cow­ni­ka­mi mode­lo­wa­nej firmy,
  3. żaden nie nada­wał się do uży­cia jako mate­riał do stwo­rze­nia opro­gra­mo­wa­nia, mimo, że wszyst­kie one były pro­duk­tem pierw­sze­go eta­pu pro­jek­tu o nazwie ana­li­za przed-wdrożeniowa”,
  4. wszyst­kie cier­pia­ły na pro­blem nad­mia­ru szcze­gó­łów, nie­jed­no­znacz­no­ści i bra­ku spójności.

Jedenaście lat temu (tak jede­na­ście!) napisałem:

Często fir­my ofe­ru­ją usłu­gę i pro­dukt Model (mapę) Procesów Biznesowych. Co dają? Dają nie­udol­nie zro­bio­ny opis pro­ce­dur, nie­słusz­nie nazwa­nych pro­ce­sa­mi. Setki sche­ma­tów obra­zu­ją­cych kto, co i jak robi. A po co to robi? Tego tam z regu­ły nie opi­sa­no! Dziesiątki i set­ki stron dia­gra­mów, któ­re lądu­ją na pół­ce i nie są uży­wa­ne pod­czas wdro­że­nia. Powstaje opra­co­wa­nie, któ­re jest nie­zro­zu­mia­łe przez zarząd fir­my zle­ca­ją­cej tę pra­cę. Zarząd nie przy­zna się, że nie rozu­mie bo podob­no to zna­na fir­ma dorad­cza lub wdro­że­nio­wa opra­co­wa­ła. A moim zda­niem, jeże­li Zarząd nie potra­fi zro­zu­mieć udo­ku­men­to­wa­ne­go obra­zu wła­snej fir­my to doku­ment jest do kitu a nie Zarząd. (Modelowanie biz­ne­so­we czy­li pil­no­wa­nie hochsz­ta­ple­rów).

Dlaczego tak jest? Dlaczego tak bar­dzo popu­lar­ne są tego typu warsz­ta­ty a nie rze­tel­ne, dają­ce wyso­kiej jako­ści pro­duk­ty, analizy?

Obserwacja gry vs. reguły gry

To co się dzie­je na sto­le bilar­do­wym (meta­fo­ra z książ­ki M.Fowlera) moż­na opi­sać z pomo­cą praw fizy­ki i reguł gry w bilar­da. To co obser­wu­je­my na sza­chow­ni­cy (meta­fo­ra z blo­ga Paula Harmona) to wynik reguł gry, doświad­cze­nia i kla­sycz­nych zagry­wek. W obu przy­pad­kach docho­dzą też do gło­su wie­dza i umie­jęt­no­ści gra­czy. Piłka noż­na to regu­ły gry, pra­wa fizy­ki (tor pił­ki po kop­nię­ciu pił­ki) i umie­jęt­no­ści zawod­ni­ków. Można tu podać wie­le innych przy­kła­dów efek­tów łącz­ne­go ist­nie­nia okre­ślo­nych reguł oraz umie­jęt­no­ści ludzi.

Każda orga­ni­za­cja (fir­ma, urząd, inne) to ludzie z ich wie­dzą i umie­jęt­no­ścia­mi oraz regu­ły gry” czy­li obo­wią­zu­ją­ce Prawo i wewnętrz­ne regu­la­cje. I teraz poja­wia się pyta­nie: czym jest model orga­ni­za­cji? Przede wszyst­kim model to uprosz­cze­nie rze­czy­wi­sto­ści, jed­nak sto­pień tego uprosz­cze­nia nie jest przy­pad­ko­wy. To co uprasz­cza­my (pomi­ja­ne szcze­gó­ły) zale­ży od kon­tek­stu w jakim ten model będzie uży­ty, bo two­rze­nie mode­lu na jeden cel: uży­cie go w kon­kret­nym celu. Tu nie­ste­ty” wkra­cza nauka, mam na myśli podej­ście (meto­da nauko­wa w ana­li­zie).

Spójrzmy na to od koń­ca. Aby powsta­ło jakie­kol­wiek narzę­dzie wspo­ma­ga­ją­ce pra­cę np. ludzi wyko­nu­ją­cych swo­je obo­wiąz­ki w orga­ni­za­cji, narzę­dziem taki jest tak­że opro­gra­mo­wa­nie (czy­li apli­ka­cje), musi powstać opis tego narzę­dzia. Aplikacje to takie narzę­dzia, two­rzy­my je głów­nie z dwóch powo­dów: two­rzy­my elek­tro­nicz­ne wer­sje kar­to­tek (reje­strów) oraz two­rzy­my elek­tro­nicz­ne wer­sje okre­ślo­nych umie­jęt­no­ści (np. wyli­cza­nie pier­wiast­ków w kal­ku­la­to­rze). Tak więc aby zamó­wić u deve­lo­pe­ra Kartotekę musi ją opi­sać i to jest rela­tyw­nie pro­ste: two­rzy­my wzór Kartoteki, np. kar­to­te­ki pra­cow­ni­ka, książ­ki w biblio­te­ce itp. Nieco trud­niej jest opi­sać (udo­ku­men­to­wać) umie­jęt­ność, zresz­tą naj­pierw trze­ba ja jakoś zde­fi­nio­wać. Umiejętności, tu wyma­ga­ne, mogą być róż­ne: od umie­jęt­no­ści wery­fi­ka­cji danych wpro­wa­dza­nych do kar­to­tek aż do umie­jęt­no­ści wytwa­rza­nia nowych infor­ma­cji na bazie tych dostęp­nych w kar­to­te­kach. Np. utwo­rze­nie fak­tu­ry sprze­da­ży wyma­ga sko­rzy­sta­nia z kar­to­te­ki klien­tów, z kar­to­te­ki ofe­ro­wa­nych towa­rów i usług, kar­to­te­ki towa­rów dostęp­nych w maga­zy­nie, trze­ba tak­że posia­dać umie­jęt­ność popraw­ne­go wyli­cze­nia war­to­ści podat­ków na for­mu­la­rzu fak­tu­ry, mogą do tego dojść upu­sty zależ­ne od wie­lu czyn­ni­ków: war­to­ści zaku­pu, aktu­al­nych pro­mo­cji, sta­tus kupu­ją­ce­go i wie­le innych. Inny przy­kład: zare­je­stro­wa­nie nowe­go doku­men­tu w archi­wum wyma­ga sko­rzy­sta­nia z kar­to­te­ki doku­men­tów oraz umie­jęt­no­ści nada­nia doku­men­to­wi spe­cjal­ne­go zna­ku, sygnatury.

workshopI tu wpa­da­my w efekt krę­ce­nia fil­mu”. Najczęściej tak zwa­na ana­li­za wyglą­da tak, że pra­cow­ni­cy ana­li­zo­wa­nej fir­my, w toku warsz­ta­tów lub wywia­dów, opo­wia­da­ją z jaki­mi to sytu­acja­mi mają do czy­nie­nia, co robią, kie­dy i jak, opi­su­jąc kon­kret­ne przy­pad­ki z jaki­mi mie­li do czy­nie­nia i to, jak sobie z nimi pora­dzi­li. Do tego docho­dzą przy­pad­ki, w któ­rych sobie sła­bo pora­dzi­li, przy­pad­ki tego jak sobie radzą z tym, że cze­goś nie rozu­mie­ją, a to wszyst­ko jest okra­szo­ne spo­so­ba­mi pra­cy wyni­ka­ją­cy­mi nie raz z nie­wie­dzy, nie­zna­jo­mo­ści pra­wa czy wewnętrz­nych regu­la­cji. Na domiar złe­go, nie raz moż­na się spo­tkać z przy­pad­ka­mi, w któ­rych opo­wia­da­ją­cy o swo­je pra­cy wpla­ta ele­men­ty pozwa­la­ją­ce mu na dzia­ła­nia nie­po­żą­da­ne takie jak uprasz­cza­nie pro­ce­dur lub wręcz łama­nie pra­wa (np. swe­go cza­su pewien urzęd­nik na moich oczach w trak­cie warsz­ta­tów zgło­sił jako wyma­ga­nie wobec sys­te­mu obie­gu doku­men­tów, moż­li­wość pod­pi­sa­nia orze­cze­nia sędzie­go prze­ter­mi­no­wa­nym pod­pi­sem elektronicznym!).

Dokumenty, któ­re dosta­ję do recen­zji, to czę­sto wła­śnie zapi­sy, wręcz ste­no­gra­my z takich spo­tkań, i nie ma zna­cze­nia czy to zapi­sy pro­zą” czy zapi­sy w posta­ci obraz­ko­wej z uży­ciem nota­cji BPMN czy UML (gdzie nota­cja jest wyko­rzy­sty­wa­na raczej jako biblio­te­ka sym­bo­li a nie narzę­dzie z jego syn­tak­ty­ką i seman­ty­ką). To doku­men­ty, któ­re sta­no­wią rodzaj ste­no­gra­mu z roz­mów, są jak fil­my nakrę­co­ne pod­czas roz­gry­wa­nia par­tii sza­chów lub bilar­da: miłe w oglą­da­niu, dłu­gie, kosz­tow­ne i kom­plet­nie nie­przy­dat­ne do napi­sa­nia kom­pu­te­ro­wej gry.

Do opi­sa­nia każ­dej z tych gier, a tak­że do opi­sa­nia tego jak funk­cjo­nu­je orga­ni­za­cja, wystar­czy doku­ment opi­su­ją­cy zasa­dy gry (regu­ły biz­ne­so­we) oraz mini­mal­ną wie­dzę i umie­jęt­no­ści gra­czy oraz to jakie i w jakiej kolej­no­ści rze­czy maja powstać czy­li model pro­ce­sów biz­ne­so­wych. Model pro­ce­sów jed­nak to nie jest film” opi­su­ją­cy czy­jąś pra­cę a logicz­ny łań­cuch aktyw­no­ści two­rzą­cych, każ­da, przy­dat­ny biz­ne­so­wi produkt.

Jaki opis powsta­nie po prze­pro­wa­dze­niu kil­ku dni warsz­ta­tów z gra­cza­mi, któ­rzy gra­ją od lat, zasa­dy gry zna­ją na pamięć, bywa ze podej­mu­ją pró­by łama­nia zasad dla osią­gnię­cia doraź­nych efek­tów? To będą dłu­gie, nie raz nie­spój­ne wywo­dy. Każdą z wymie­nio­nych gier opi­su­ją jed­nak jed­no­znacz­nie dwa bar­dzo krót­kie doku­men­ty: regu­ły gry oraz mini­mal­ne umie­jęt­no­ści i wie­dza każ­de­go z gra­czy. Z takim doku­men­tem każ­dy pro­jek­tant opro­gra­mo­wa­nia sobie pora­dzi bez problemu.

Niestety wie­le pro­duk­tów eta­pu pro­jek­tu o nazwie ana­li­za przed-wdro­że­nio­wa to tak zwa­ne malo­wa­nie tra­wy: kawał kosz­tow­nej i niko­mu nie przy­dat­nej pra­cy. Jakiś temu pisa­łem z innej okazji:

Niestety, pod­czas tak zwa­nych typo­wych ana­liz, opar­tych na wywia­dach i spo­tka­niach warsz­ta­to­wych, im wię­cej inte­rak­cji tym więk­sze pole do mani­pu­la­cji i per­swa­zji (świa­do­mej lub nie, ale jed­nak). Po dru­gie, nie ma żad­nej gwa­ran­cji, że nicze­go nie pomi­nię­to (w takich roz­mo­wach w zasa­dzie oma­wia­ne są rze­czy cie­ka­we i rzad­kie a pra­wie nigdy oczywiste). […]

Drugim pro­ble­mem i poważ­nym błę­dem jest uzna­nie, że ?sko­ro te ana­li­zy to spo­tka­nia i zapi­sy­wa­nie ich wyni­ków, to może to robić nie­mal­że każ­dy byle był komu­ni­ka­tyw­ny?. Bzdura. Po pierw­sze takie dzia­ła­nie to nie są ana­li­zy a ste­no­gra­my ze spo­tkań, po dru­gie są one zapi­sem subiek­tyw­ne­go oglą­du sytu­acji, jaki mają odpy­ty­wa­ni pra­cow­ni­cy danej fir­my (do tego z ich tyl­ko per­spek­ty­wy). (Nowoczesne tech­no­lo­gie w służ­bie zdro­wia, czy­li tele­me­dy­cy­na w pro­jek­tach IT).

Dlatego rolą ana­li­ty­ka biz­ne­so­we­go nie jest spi­sa­nie prze­bie­gu dzie­sią­tek wywia­dów i setek indy­wi­du­al­nych wyma­gań. Nie mają więk­sze­go sen­su doku­men­ty na dwa, trzy tysią­ce stron (nikt ich nie czy­ta!). Rolą ana­li­ty­ka biz­ne­so­we­go jest prze­ana­li­zo­wa­nie dostęp­nych doku­men­tów, infor­ma­cji, i stwo­rze­nie opi­su mecha­ni­zmu dzia­ła­nia orga­ni­za­cji oraz opi­su roz­wią­za­nia, narzę­dzia mogą­ce­go uspraw­nić dzia­ła­nie orga­ni­za­cji. Opisu zawie­ra­ją­ce­go regu­ły biz­ne­so­we, prze­twa­rza­ne infor­ma­cje (wzo­ry doku­men­tów) oraz listą usług jakie ma świad­czyć pla­no­wa­na do wdro­że­nia apli­ka­cja wraz z opi­sem tego, jak te usłu­gi mają być reali­zo­wa­ne (umie­jęt­no­ści, któ­re moż­na zauto­ma­ty­zo­wać). Sens mają więc zwię­złe opi­sy i mode­le mecha­ni­zmów dzia­ła­nia orga­ni­za­cji oraz opi­sy tego jakie infor­ma­cje i jak mają być prze­twa­rza­ne z uwzględ­nie­niem tego, że część tych prac nadal będą wyko­ny­wa­li ludzie. Takie jak regu­ły gry w sza­chy: waż­ne są dwie stro­ny opi­su reguł gry a nie set­ki stron opi­sów przy­kła­do­wych partii.

klientsobiezyczyBardzo czę­sto sły­szę od deve­lo­pe­rów, ze więk­szość doku­men­tów jakie dosta­ją jest nie­przy­dat­na. Nie raz zasta­na­wiam się, dla­cze­go mimo to więk­szość usłu­go­daw­ców two­rzy tak nie­przy­dat­ne doku­men­ty? Najprawdopodobniej dla­te­go, że słu­cha­nie i ste­no­gra­fo­wa­nie jest łatwe… Z dru­giej stro­ny, nie raz nie­ste­ty sami zama­wia­ją­cy chcą takich wła­śnie doku­men­tów, Ci jed­nak są uspra­wie­dli­wie­ni, bo to nie oni są ana­li­ty­ka­mi. Ci ostat­ni sami decy­du­ją jaki­mi ana­li­ty­ka­mi są…

Drugim powo­dem jest dość powszech­ny brak umie­jęt­no­ści abs­trak­cyj­ne­go myśle­nia. Problem ten widać czę­sto na eta­pie mode­lo­wa­nia pro­ce­sów biz­ne­so­wych: zamu­la­nie zbęd­ny­mi szcze­gó­ła­mi. Bardzo wie­lu ana­li­ty­ków ma skłon­no­ści do wgłę­bia­nia się w nie­istot­ne szcze­gó­ły, to wła­śnie objaw bra­ku umie­jęt­no­ści two­rze­nia abs­trak­cji. Do tego stop­nia, że powstał pomysł na sfor­ma­li­zo­wa­nie zaj­mo­wa­nie się tymi szcze­gó­ła­mi (Case Management). Ciekawa dys­ku­sja na ten temat poja­wi­ła się na LinkedIn. Ja ze swej stro­ny pole­cam arty­kuł (Case Managemet) oraz wypo­wie­dzi Paula Harmona w dyskusji:

At the pro­cess level, we want the abi­li­ty to descri­be and orga­ni­ze a gene­ric set of acti­vi­ties. We might be con­cer­ned, for exam­ple, with how we orga­ni­ze Hotel Guest Services. To be cle­ar what we mean by orga­ni­zing Hotel Guest Services, we might talk abo­ut a spe­ci­fic instan­ce in which a hotel orga­ni­zed guest servi­ces. One of the things we might deci­de, for exam­ple, was that the hotel wan­ted eve­ry­one to use the guest’s name. Thus, we might think of all of the acti­vi­ties in which employ­ees might inte­ract, and pon­der how we would pro­vi­de each set of employ­ees with each guest’s name. It obvio­usly would­n’t be a mat­ter of sim­ply noti­fy­ing one gro­up – like tho­se who take restau­rant rese­rva­tions of who is in what room – sin­ce, as Roger sug­ge­sts, a hotel guest could pro­ce­ed in any order, going to the pool, or to a con­fe­ren­ce ses­sion, or pro­ce­eding to make a restau­rant rese­rva­tion. In this case we are pro­ba­bly tal­king abo­ut put­ting infor­ma­tion into a data­ba­se from which vario­us employ­ees could easi­ly retrie­ve it. Processes are dyna­mic and com­plex, in part, becau­se the gene­ric pro­cess descrip­tion isn’t as pre­scrip­ti­ve as it would be in a pro­duc­tion line, whe­re the sta­tions are set and the beha­viors expec­ted at each sta­tion are well defi­ned. They are cases” becau­se each instan­ce of the pro­cess uses a dif­fe­rent set of acti­vi­ties in a dif­fe­rent order – as in the Rescue Hostage exam­ple. When we plan for a Rescue Hostage case or pro­ject if you pre­fer, we deve­lop a series of sce­na­rios, and prac­ti­ce a lar­ge set of acti­vi­ties. When the time comes to exe­cu­te the pro­cess, we begin by plan­ning for the spe­ci­fic instan­ce case. The idea that we start the pro­cess with a gene­ric: Plan for the Specific Rescue Effort, acti­vi­ty may be gene­ric, but any deta­iled exam­ple of it will be an instan­ce, sin­ce in the very natu­re of the plan­ning we are tailo­ring to the spe­ci­fic instan­ce. (Case Management Approaches | LinkedIn).

Gdzie są te cholerne szczegóły

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

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

Jak definiować wymagania na walidacje”

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

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

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

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

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

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

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

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

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

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

Logika biznesowa

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

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

Communication with words isn?t always bridging the gap, komunikacja werbalna nie zawsze wypełni lukę komunikacyjną, luka komunikacyjna

Inżynieria wymagań

Wczoraj odby­ła się w Warszawie kon­fe­ren­cja Inżynieria Wymagań, na któ­rej mia­łem przy­jem­ność wygło­sić refe­rat o kla­sy­fi­ka­cji wyma­gań. Celem mojej pre­zen­ta­cji było zwró­ce­nie uwa­gi na to, że zarzą­dza­nie wyma­ga­nia­mi to nie tyl­ko ich zbie­ra­nie i kla­sy­fi­ko­wa­nie” oraz, że wyma­gań jest wię­cej niż tyl­ko funk­cjo­nal­ne i poza-funkcjonalne”.

Powszechny w lite­ra­tu­rze przed­mio­tu ter­min pozy­ski­wa­nie wyma­gań” jest bar­dzo róż­nie rozu­mia­ny. Można wyma­ga­nia pozy­ski­wać” pod­czas sesji warsz­ta­to­wych JAD, burz mózgów, z pomo­cą ankiet, pisa­nia user sto­ry” itp. Wszystkie te meto­dy mają jed­ną poważ­ną wadę: pro­du­ku­ją ogrom­ną ilość dekla­ra­tyw­nych, nie­we­ry­fi­ko­wal­nych tre­ści. Lista wyma­gań w posta­ci tabe­li z set­ka­mi wier­szy niko­go tu nie zaska­ku­je. To nie działa!

Inżynieria wymagań

Coraz czę­ściej zaczy­na poja­wiać się poja­wiać nie tyl­ko w pra­sie, poję­cie inży­nie­ria wyma­gań”. Dla zasa­dy popa­trz­my na zna­cze­nia słów (sł. j. polskiego):

inży­nie­ria ?pro­jek­to­wa­nie i kon­stru­owa­nie obiek­tów oraz urzą­dzeń technicznych?
wyma­ga­nie ?waru­nek lub zespół warun­ków, któ­rym ktoś lub coś musi odpowiadać?
wyma­ga­ny ?nie­zbęd­nie potrzebny?

Tak więc inży­nie­ria wyma­gań to pro­jek­to­wa­nie nie­zbęd­nych warun­ków, któ­rym coś [roz­wią­za­nie] musi odpo­wia­dać”. Moim zda­niem istot­ne jest jest uży­cie sło­wa pro­jek­to­wa­nie” a nie zbie­ra­nie”. Zbieranie to pra­ca ste­no­gra­fa. Projektowanie to już zupeł­nie inna pra­ca. Raz, że twór­cza, dwa że rzą­dzą­ca się pew­ny­mi pra­wa­mi: przede wszyst­kim spe­cy­fi­ka­cja wyma­gań to pew­na okre­ślo­na kon­struk­cja. Jaka? Zgodnie z zasa­da­mi: spój­na, nie­sprzecz­na, wery­fi­ko­wal­na i kom­plet­na. Czy takie cechy ma np. ste­no­gram z kil­ku­dnio­wych warsz­ta­tów JAD czy burzy mózgów albo dane zebra­ne z ankiet wśród przy­szłych użyt­kow­ni­ków dane­go roz­wią­za­nia? Szczerze wąt­pię.

Pojawia się kolej­ne pyta­nie: co z wyni­ka­mi ana­li­zy wyma­gań po zakoń­cze­niu pro­jek­tu wdro­że­nio­we­go? Niemalże w 100% przy­pad­ków są odkła­da­ne na pół­kę, a kolej­ne wdro­że­nie lub roz­bu­do­wa posia­da­nych narzę­dzi, to kolej­na, pro­wa­dzo­na od zera ana­li­za wyma­gań. Jak słusz­nie zauwa­żył jeden z pre­le­gen­tów, wyłą­cza­jąc start-up’y, pro­jek­ty wdro­że­nio­we (wybór, zakup, imple­men­ta­cja) to tak na praw­dę zarzą­dza­nie zmia­ną a nie nowe projekty”.

Wyobraźmy sobie, że zamiast odkła­dać doku­men­ta­cję wyma­gań do lamu­sa, utrzy­mu­je­my jej aktu­al­ność i wycią­ga­my ją za każ­dym razem, gdy roz­po­czy­na­my kolej­ny nowy pro­jekt, wyma­ga­ją­cy zmia­ny jakiejś funk­cjo­nal­no­ści lub pozy­ska­nia cał­kiem nowej. Wtedy, zamiast pro­wa­dzić kolej­ną kosz­tow­ną i dłu­gą ana­li­zę wyma­gań, ana­li­zu­je­my pla­no­wa­ne zmia­ny i nano­si­my je na posia­da­ną już i kon­ser­wo­wa­ną doku­men­ta­cję. Próby korzy­sta­nia z ana­liz poprzed­nich ad-hoc naj­czę­ściej koń­czą się fia­skiem, gdyż z regu­ły każ­dą robi inny dostaw­ca roz­wią­za­nia, więc każ­da jest inna i naj­czę­ściej nie­spój­na z innymi.

Spójrzmy teraz na poniż­szy diagram:

architektura korporacyjna rentowność

Na dia­gra­mie mamy dwie linie (linia prze­ry­wa­na to kosz­ty bie­żą­ce, cią­gła to kosz­ty nara­sta­ją­co): czer­wo­na to kosz­ty tra­dy­cyj­ne­go mode­lu pro­wa­dze­nia nie­za­leż­nych ana­liz, od zera” dla każ­de­go pro­jek­tu. Niebieska poka­zu­je kosz­ty mode­lu, w któ­rym zarzą­dza­my zmia­ną. Realia poka­zu­ją, że oszczęd­no­ści są jesz­cze więk­sze, gdyż w mode­lu ana­liz ad-hoc, pomniej­sze pro­jek­ty reali­zo­wa­ne są zwin­nie” bez żad­nej doku­men­ta­cji, gdyż albo nie ma na jej opra­co­wa­nie cza­su (bar­dzo czę­sto) albo wiel­kość (mały) pro­jek­tu skła­nia do podej­mo­wa­nia ryzy­ka pra­cy bez doku­men­ta­cji. Niestety pra­ca bez doku­men­ta­cji czę­sto pro­wa­dzi do odkry­wa­nia wyma­gań dość kosz­tow­ną meto­dą prób i błę­dów (pro­to­ty­po­wa­nie). Jak wie­my, pra­wie 80% pro­jek­tów to pro­jek­ty wadli­we, w 100% przy­pad­ków źró­dłem jest (mię­dzy inny­mi) zła spe­cy­fi­ka­cja wymagań.

Jak widać, z zupeł­nie z innej stro­ny odkry­li­śmy” coś co nazy­wa­my archi­tek­tu­rą kor­po­ra­cyj­ną. Skoro każ­da ana­li­za wyma­gań w ist­nie­ją­cej orga­ni­za­cji, to każ­do­ra­zo­wa ana­li­za od pozio­mu moty­wa­cji biz­ne­so­wej pro­jek­tu, przez wyma­ga­ne usłu­gi apli­ka­cyj­ne, inte­gra­cje aż do plat­form sprzę­to­wo-sys­te­mo­wych, to mamy nic inne­go, jak pro­jekt doku­men­to­wa­nia archi­tek­tu­ry kor­po­ra­cyj­nej. I na koniec bar­dzo waż­na moja uwa­ga: za jakość wyma­gań odpo­wia­da i pono­si kon­se­kwen­cje w 100% kupu­ją­cy, nigdy dostawca!

Ma sens? Ma!

Na koniec pole­cam bar­dzo cie­ka­wy arty­kuł Bogdana Berezy o inży­nie­rii opro­gra­mo­wa­nia w dzi­siej­szym (19 Marca 2014) nume­rze [[COMPUTERWORLD]].

Modelowanie obiektowe, procesy biznesowe, inżynieria oprogramowania

CASE czyli komputerowe wspomagania analizy i projektowania systemów

Od lat, pod­czas audy­tów i szko­leń, spo­ty­kam się z dziw­ny­mi dia­gra­ma­mi” two­rzo­ny­mi w celu… no wła­śnie. Ale po kolei…

Najpierw przy­po­mnę, bar­dzo tu pomoc­ne, poję­cie archi­tek­tu­ry kor­po­ra­cyj­nej, któ­ra – śle­dząc lite­ra­tu­rę przed­mio­tu – jest mode­lem (doku­men­ta­cją) wią­żą­cym model biz­ne­so­wy orga­ni­za­cji z jej zaso­ba­mi infor­ma­cyj­ny­mi i infra­struk­tu­rą słu­żą­cą do zarzą­dza­nia infor­ma­cją. Posiadanie takie­go mode­lu ma sens nie tyl­ko po to by, wie­dzieć co mamy” czy opi­sać wyma­ga­nia na to cze­go jesz­cze nie nie mamy a potrze­bu­je­my mieć”. Model taki pozwa­la ana­li­zo­wać posia­da­ne zaso­by, ale tak­że oce­nić ich wpływ na dzia­ła­nie orga­ni­za­cji, wza­jem­ny wpływ, prze­wi­dzieć reak­cje sys­te­mu na nowe bodź­ce (lub awarie).

W arty­ku­le opi­su­ją­cym pro­ces mode­lo­wa­nia od biz­ne­su do pro­jek­tu logi­ki sys­te­mu” opi­sa­łem prze­cho­dze­nie od mode­lu pro­ce­sów biz­ne­so­wych, przez przy­pad­ki uży­cia do mode­lu dzie­dzi­ny sys­te­mu (lub kom­po­nen­tów w przy­pad­ku zło­żo­nych sys­te­mów jak w arty­ku­le Przypadki uży­cia i gra­ni­ce sys­te­mu). Nie będę więc w tym miej­scu powta­rzał tych tre­ści, ale poka­że przykłady.

Opisywane tu podej­ście wyma­ga przy­ję­cia stan­dar­do­wych defi­ni­cji pojęć pro­ces biz­ne­so­wy i przy­pa­dek uży­cia oraz usłu­ga sys­te­mu (tak zwa­na prag­ma­ty­ka mode­li, powin­na być zawsze dołą­czo­na do doku­men­tów ana­li­zy). Dwie ostat­nie są w UML prak­tycz­nie toż­sa­me z pro­ce­sem biz­ne­so­wym (A use case is the spe­ci­fi­ca­tion of a set of actions per­for­med by a sys­tem, which yields an obse­rva­ble result that is, typi­cal­ly, of value for one or more actors or other sta­ke­hol­ders of the sys­tem – czyn­ność lub ich seria dają­ca jako efekt pro­dukt mają­cy war­tość dla akto­ra, źr. UML 2.4.1. 16.3.6 UseCase). W efek­cie zestaw dia­gra­mów opi­su­ją­cych orga­ni­za­cję z jej sys­te­mem infor­ma­cyj­nym, two­rzą Architekturę jak poniżej:

Model warstw AK

Usługa sys­te­mu (jego przy­pa­dek uży­cia) może wspie­rać jeden lub wie­le róż­nych pro­ce­sów biz­ne­so­wych, jed­nak na pozio­mie pro­ce­sów ele­men­tar­nych (tych któ­rych już nie dekom­po­nu­je­my), jeden pro­ces ele­men­tar­ny” może być wspie­ra­ny wyłącz­nie jed­nym przy­pad­kiem uży­cia (bo na tym pozio­mie powsta­je jeden pro­dukt). Przykładem jed­nej usłu­gi wyko­rzy­sty­wa­nej w kil­ku pro­ce­sach może być przy­pa­dek zwa­ny CRUD (Create, Retrieve, Update, Delete, czy­li Utwórz, Przywołaj, Aktualizuj, Usuń), taka usłu­ga (przy­pa­dek uży­cia typu CRUD) może wspie­rać pro­ce­sy: two­rze­nia, aktu­ali­za­cji (w tym zmia­ny sta­tu­su) i usu­wa­nia dokumentów.

Usługi są reali­zo­wa­ne przez okre­ślo­ne kom­po­nen­ty (apli­ka­cje), któ­re są insta­lo­wa­ne na kon­kret­nych plat­for­mach. Z uwa­gi na to, że kom­po­nen­ty mogą współ­pra­co­wać (wymie­niać mię­dzy sobą dane) mają udo­ku­men­to­wa­ne interfejsy.

Jak pokazać, które komponenty są wykorzystywane w określonych procesach?

Teraz przy­szedł moment, w któ­rym poja­wia­ją się czę­sto nie­stan­dar­do­we dia­gra­my wymy­śla­ne” w celu jakie­goś spo­so­bu” na poka­za­nie związ­ków pomię­dzy biz­ne­sem (pro­ce­sy biz­ne­so­we) a kom­po­nen­ta­mi opro­gra­mo­wa­nia. Poważną wadą tych pomy­słów jest przede wszyst­kim to, że są nie­stan­dar­do­we. Po dru­gie wyma­ga­ją ręcz­ne­go” wytwo­rze­nia, są pra­co­chłon­ne, mno­żą się dodat­ko­we stro­ny doku­men­ta­cji, pod­no­szą jej zło­żo­ność i pogar­sza­ją zro­zu­mia­łość całości.

Jak sobie z tym pora­dzić? Tu nie­oce­nio­ne są wła­śnie dobre pakie­ty opro­gra­mo­wa­nia CASE. Poniżej pro­sty przykład:

Model pro­ce­su biz­ne­so­we­go (pro­ces skła­da się z ele­men­tar­nych pro­ce­sów, każ­dy ma produkt):

Przykładowy proces biznesowy

Model przy­pad­ków uży­cia (zacho­wa­no nazwy z mode­lu pro­ce­sów dla orientacji):

Przypadki użycia aplikacji

Przykładowa reali­za­cja (sce­na­riusz) wybra­ne­go przy­pad­ku uży­cia (na pozio­mie kom­po­nen­tów, tu celem jest spe­cy­fi­ko­wa­nie inter­fej­su czy­li wywo­łań jed­ne­go kom­po­nen­tu przez drugi):

Czynność_4 - Scenariusz

Jak teraz spraw­dzić i poka­zać związ­ki pomię­dzy pro­ce­sa­mi, przy­pad­ka­mi uży­cia apli­ka­cji (usłu­ga­mi sys­te­mu) i kom­po­nen­ta­mi (apli­ka­cja­mi)? Zamiast two­rzyć nowe sztucz­ne i nie­stan­dar­do­we dia­gra­my znacz­nie lepiej jest poka­zać to w for­mie macie­rzy nie psu­jąc np. mode­li pro­ce­sów nie­for­mal­ny­mi zapi­sa­mi o systemach:

Macierz Procesy na uslugi

Macierz Uslugi na kommponenty

Gdyby potrzeb­ne były bar­dziej wyra­fi­no­wa­ne ana­li­zy zależ­no­ści, może­my stwo­rzyć, zamiast dwu­wy­mia­ro­wej macie­rzy, taki diagram:

Czynność_4 Analiza wpływu

I teraz sed­no czy­li co nam daje dobre narzę­dzie CASE? otóż powyż­sze macie­rze (takie i każ­dą inną) oraz model ana­li­zy wpły­wu, są gene­ro­wa­ne i aktu­ali­zo­wa­ne auto­ma­tycz­nie. Wystarczy opra­co­wać stan­dar­do­we mode­le w BPMN i UML jak powy­żej, wska­zać związ­ki pomię­dzy ele­men­ta­mi jako ich para­me­try (nie trze­ba do tego celu two­rzyć sztucz­nych dia­gra­mów) i sko­rzy­stać z moż­li­wo­ści auto­ma­tycz­ne doku­men­to­wa­nia tych związków.

Uzupełnieniem powyż­szych mode­li może być mapo­wa­nie doku­men­tów z dia­gra­mów pro­ce­sów biz­ne­so­wych na kla­sy (agre­ga­ty) repre­zen­tu­ją­ce je w opro­gra­mo­wa­niu (kom­po­nen­ty). Tu nie­ste­ty nie widzę sen­su mapo­wa­nia na dane w bazie danych” bo celem jest doku­men­to­wa­nie miej­sca prze­cho­wy­wa­nia infor­ma­cji (kom­po­nent) a nie imple­men­ta­cji (baza RDBMS, któ­ra jest jed­ną z wie­lu moż­li­wych imple­men­ta­cji utrwalania).

Ważne jest by narzę­dzie bar­dzo dobrze wspie­ra­ło spe­cy­fi­ka­cje nota­cji oraz meto­dy wery­fi­ko­wa­nia spój­no­ści mode­li takie jak śla­do­wa­nie, pod­le­głość mode­li, zależ­no­ści parent-child” i zagnieżdżanie.

(Artykuł powstał z uży­ciem opro­gra­mo­wa­nia Visual-Paradigm Agilian, pakiet ten ma moduł do pro­wa­dze­nia ana­liz wpły­wu i zależ­no­ści).