Bardzo czę­sto spo­ty­kam się z ogrom­ną zło­żo­no­ścią (licz­ba i ich podzia­ły) wyma­gań. Problem tkwi nie raz w tym, że naro­sła” przez lata ster­ta zarzą­dzeń”, któ­ra zamiast zostać naj­pierw upo­rząd­ko­wa­na, jest wprost” trak­to­wa­na jako wyma­ga­nia”. Takie podej­ście to krok w stro­nę klę­ski projektu.

W wyma­ga­niach” czę­sto poja­wia się coś co nazy­wa­my warun­kiem logicz­nym”, może on być zarów­no regu­łą biz­ne­so­wą, ele­men­tem pra­wa (rodzaj regu­ły ale z poza orga­ni­za­cji) jak i ele­men­tem dzie­dzi­ny sys­te­mu (np. czło­wiek może pod­nieść tyl­ko 20 kg).

W efek­cie czę­sto powsta­ją dzie­siąt­ki «bar­dzo istot­nych” szcze­gó­łów, któ­re nie powią­za­ne ze sobą, two­rzą pap­kę wyma­gań, któ­rych imple­men­ta­cja albo wyma­ga uprosz­czeń (brak defi­nio­wal­nej logi­ki pomię­dzy tymi wyma­ga­nia­mi) albo wręcz wyma­ga rezy­gna­cji z czę­ści z nich (a mogą być fak­tycz­nie waż­ne dla fir­my). Nieuporządkowane regu­ły takie trwa­ją w fir­mach, bo czło­wiek ma natu­ral­ną zdol­ność do radze­nia sobie z, nie raz sprzecz­ny­mi, ogra­ni­cze­nia­mi w swo­jej pra­cy: doko­nu­je wybo­ru ad-hoc a roz­li­cza­ny jest z efek­tów nie reguł. Czegoś takie­go nie da się zaim­ple­men­to­wać w oprogramowaniu.

Przykład dość typo­wy: w wie­lu róż­nych miej­scach orga­ni­za­cji ist­nie­ją ogra­ni­cze­nia mak­sy­mal­nej kwo­ty kosz­tu o jakim może zde­cy­do­wać oso­ba na okre­ślo­nym sta­no­wi­sku. Są to nie raz pro­gi usta­la­ne indy­wi­du­al­nie (lata­mi) dla kon­kret­nych typów kosz­tów, kon­kret­nych sta­no­wisk itp. Nie raz są ich nawet dzie­siąt­ki a ich wyso­kość jest róż­na, usta­la­na pod wpły­wem szko­dy, któ­ra była przy­czy­ną ich usta­le­nia lub żądań dane­go mene­dże­ra. Takich reguł” w dużej orga­ni­za­cji mogą być nie raz nawet set­ki. Są to pary w rodza­ju Dyrektor XXX w przy­pad­ku doku­men­tu typu YYY powy­żej kwo­ty ZZZ musi.….”. Reguły” takie war­to prze­ana­li­zo­wać i zamie­nić np. na kil­ka (albo i jed­ną!): każ­dy dyrek­tor śred­nie­go szcze­bla musi .… jeże­li koszt jaki wyge­ne­ru­je jego decy­zja prze­kro­czy kwo­tę ZZZ. Ustala się jed­ną kwo­tę dla kon­kret­ne­go szcze­bla mene­dże­rów (wszyst­kich). Tu czę­sto poja­wia się opór tych mene­dże­rów”, bo cięż­ko lata­mi wal­czy­li o swo­je kom­pe­ten­cje”. Niestety dla wie­lu mene­dże­rów próg ich decy­zji finan­so­wych ozna­cza ich kom­pe­ten­cje i wła­dze (a szko­da, że nie ich wie­dza i umiejętności).

Podczas wdro­żeń, np. sys­te­mów ERP, tego typu regu­ły” (ich licz­ba i brak logi­ki) sta­no­wią nie raz zmo­rę pro­jek­tu a bywa, że potra­fią taki pro­jekt zabić. A ja tyl­ko opi­sa­łem jed­ną z typów reguł, któ­rych są dzie­siąt­ki, a z opi­sa­ny­mi warian­ta­mi”, w dużej fir­mie, nawet tysiące…

Procesy biz­ne­so­we są kon­se­kwen­cją mię­dzy inny­mi reguł biz­ne­so­wych. Większość zarzą­dów firm nie ma na pół­kach rega­łów map pro­ce­sów, a fir­my dzia­ła­ją. Jednak każ­da fir­ma ma zarzą­dze­nia Zarządu i to one tak na praw­dę kształ­tu­ją pro­ce­sy biz­ne­so­we”. Podobnie jak np. w muze­ach: mamy duże sale i wie­le moż­li­wo­ści przejść przez nie. Co decy­du­je o tym, jaką dro­gę przej­dzie­my przez sale peł­ne eks­po­na­tów? Linia na pod­ło­dze? Nie! Barierki! Czym one są? To ogra­ni­cze­nia! Zarządzenia Zarządu stwa­rza­ją ogra­ni­cze­nia, ich kon­se­kwen­cją są takie a nie inne pro­ce­sy biz­ne­so­we. Dlatego zro­zu­mie­nie i upo­rząd­ko­wa­nie reguł biz­ne­so­wych jest waż­ne, a nie mode­lo­wa­nie pro­ce­sów. Te są ich skut­kiem. Modelowanie pro­ce­sów to odkry­wa­nie ście­żek wyzna­czo­nych ogra­ni­cze­nia­mi. Jeżeli jed­nak pozwo­li­my utrzy­mać opi­sa­ny bała­gan to mode­le pro­ce­sów biz­ne­so­wych (ścież­ki postę­po­wa­nia) przy­bio­rą postać zawar­to­ści mon­stru­al­ne­go tale­rza spaghetti.

A tak na praw­dę pole­cam wysta­wę w Zamku Królewskim (Warszawa): Polska za cza­sów Jagiellonów oraz dru­gą: Historia krzy­ża Maltańskiego. Powody są dwa: to co moż­na zoba­czyć na ścia­nach czy­li eks­po­na­ty oraz to w jaki spo­sób ten sam Zamek Królewski, tyl­ko z spra­wą barie­rek, moż­na zmie­niać w tra­sy dla zwie­dza­ją­cych nie naru­sza­jąc same­go Zamku.

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.

Ten post ma 14 komentarzy

  1. Bartek

    Podpisuję się pod tym wpi­sem ręka­mi i nogami.

    Jestem człon­kiem zespo­łu, któ­ry two­rzy opro­gra­mo­wa­nie na potrze­by wewnętrz­ne orga­ni­za­cji i rzad­ko korzy­sta­my z roz­wią­zań zewnętrz­nych. Liczba reguł jakie naro­sły w trak­cie dzia­ła­nia orga­ni­za­cji jest ogrom­na i pró­ba ich uprosz­cze­nia tra­fia na ogrom­ny opór. Skutkiem tego jest opro­gra­mo­wa­nie któ­re jest strasz­nie skom­pli­ko­wa­ne i posia­da wie­le cza­sem nawet nacho­dzą­cych na sie­bie pro­ce­sów. Nasz zespół widzi te pro­ble­my, ale mamy mały wpływ na decy­zje naszych szefów.

    1. Jarek Żeliński

      może war­to im to uzmy­sło­wić” 🙂 czy­li poka­zać skut­ki… Warto tak­że «lob­bo­wać» za wydzie­le­niem (wsta­wie­niem) eta­pu ana­li­zy wyma­gań i zarzą­dza­nia nimi, pomię­dzy biz­nes” a development.

    2. Bartek

      Niestety poku­tu­je tutaj sta­ra zasa­da, że użyt­kow­nik dosta­je to o czym mówił, ale nie to co chciał. Nie potra­fi zde­fi­nio­wać wyma­gań, no chy­ba, że to my zada­je­my złe pyta­nia 😉 Prawdę mówiąc wię­cej nasz zespół bazu­je na wła­snych obser­wa­cjach niż wyma­ga­niach użyt­kow­ni­ka. To jed­nak nie jest dobra dro­ga, gdyż czę­sto zda­rza się, że nasze prze­my­śle­nia nie są w 100% celne.

    3. Jarek Żeliński

      To nie­ste­ty czę­ste zja­wi­sko, więk­szość pro­jek­tów to kom­pu­te­ry­zo­wa­nie bała­ga­nu zama­wia­ją­ce­go” z cze­go mało któ­ra fir­ma (Zamawiający) sobie zda­je spra­wę… W zasa­dzie przy­stą­pie­nie do spe­cy­fi­ko­wa­nia wyma­gań bez wcze­śniej­sze­go upew­nie­nia się, że logi­ka dzia­ła­nia fir­my jest upo­rząd­ko­wa­na”, pra­wie zawsze koń­czy się pro­jek­tem któ­ry zawsze trwa dłu­żej i kosz­tu­je wię­cej niś planowano…

  2. Matuesz

    Coraz bar­dziej widzę olbrzy­mie zale­ty sto­so­wa­nia reguł biz­ne­so­wych, jed­nak ich ukła­da­nie”( po za przy­po­rząd­ko­wa­niem do kon­kret­ne­go pro­ce­su bądź jego czyn­no­ści) jest trud­ne. Nie uda­ło mi się zna­leźć innych spo­so­bów podzia­łu reguł biz­ne­so­wych . Czy Pan jest w sta­nie wska­zać takie metody ?

    1. Jarek Żeliński

      Robię to rów­no­le­gle z ana­li­zą doku­men­tów ope­ra­cyj­nych i mode­lo­wa­niem pro­ce­sów, one powsta­ją nie­ja­ko rów­no­le­gle. W pano­wa­niu nad tym bar­dzo poma­ga mi opro­gra­mo­wa­nie Agilian (pakiet fir­my Visual-Paradigm) oraz wbu­do­wa­ne narzę­dzia do ana­li­zy fak­tów i budo­wa­nia reguł (w tym kata­lo­go­wa­nie i testo­wa­nie). pole­cam sto­so­wa­nie tak zwa­ne­go dia­gra­mu fak­tów do iden­ty­fi­ko­wa­nia reguł biznesowych.

      Diagram fak­tów i regu­ły biznesowe

  3. RF

    Super arty­kuł. Niestety to pro­blem rów­nież w wie­lu moich pro­jek­tach a czy­ta­jąc – jak­bym widział swo­ich klien­tów mik­su­ją­cych wyma­ga­nia z pro­ce­sa­mi, pro­ce­sy z regu­ła­mi etc. Również bra­ku­je mi narzę­dzia”, w celu ogar­nię­cia całej masy tych reguł i będę musiał się uważ­niej przyj­rzeć VP. Zgłoszę się na szkolenie 😉

    Tymczasem, Szczęśliwego Nowego Roku!

    Pozdrawiam,
    RF

    1. Jarek Żeliński

      Także pozdra­wiam. W nowym roku życzę suk­ce­sów i … zapra­szam na szkolenie 🙂

  4. Sławek Ryszkowski

    Również uży­wam narzę­dzi Visual Paradigm do pra­cy z regu­ła­mi biz­ne­so­wy­mi i nie tyl­ko. Diagram fak­tów jako taki nie defi­niu­je reguł biz­ne­so­wych – jest on za to dobrym źró­dłem do ich iden­ty­fi­ka­cji oraz wery­fi­ka­cji. Narzędzia VP umoż­li­wią zde­fi­nio­wa­nie reguł biz­ne­so­wych na każ­dym rodza­ju dia­gra­mu, jed­nak w prak­ty­ce iden­ty­fi­ku­je się je głów­nie w dys­cy­pli­nie mode­lo­wa­nia dzia­łal­no­ści orga­ni­za­cji (pod­czas mode­lo­wa­nia słow­ni­ka orga­ni­za­cji, jej struk­tu­ry orga­ni­za­cyj­nej oraz pro­ce­sów biznesowych).
    Trzymanie się moc­no stan­dar­du SBVR oraz podej­ścia RuleSpeak przy defi­nio­wa­niu reguł biz­ne­so­wych łatwo pro­wa­dzi do powsta­nia setek a cza­sa­mi nawet tysię­cy reguł. Jak słusz­nie autor zauwa­żył – umie­jęt­ne zde­fi­nio­wa­nie reguł pozwa­ła ogra­ni­czyć ich licz­bę jed­nak to nie wszyst­ko. W sytu­acji kie­dy dalej zma­ga­my się z ogrom­ną licz­bą reguł z pomo­cą może przyjść model tabel decy­zyj­nych – Table Decision Model, któ­ry uwa­żam, że zna­ko­mi­cie pozwa­la zapa­no­wać nad zło­żo­no­ścią reguł prze­no­sząc cię­żar zarzą­dza­nia nimi na zarzą­dza­nie decy­zja­mi biz­ne­so­wy­mi, a nie ele­men­tar­ny­mi regu­ła­mi (co jest natu­ral­ne dla biz­ne­su). Narzędzia VP swo­je­go cza­su wspie­ra­ły ten model, ale autor TDM wpro­wa­dził na nie­go licen­cję, stąd wspar­cie zosta­ło wyco­fa­ne. Dobrą wia­do­mo­ścią jest to, że OMG pra­cu­je nad stan­dar­dem TDM i już w poło­wie roku powin­ni­śmy się docze­kać jakiejś jego wersji.

    1. Jarek Żeliński

      Osobiście trak­tu­je dia­gram fak­tów jako wery­fi­ka­cje słow­ni­ka. Z ilo­ścią reguł radzę sobie tak, że defi­niu­je wyłącz­nie te ziden­ty­fi­ko­wa­ne w pro­ce­du­rach i na pro­ce­sach, to pomaga.

  5. Sławek Ryszkowski

    Polecam rów­nież cie­ka­wy arty­kuł na witry­nie ModernAnalyst porów­nu­ją­cy tra­dy­cyj­ne podej­ście do zarzą­dza­nia regu­ła­mi biz­ne­so­wy­mi i TDM: We Already Have a BRMS, What are We Missing?

  6. Ja wciąż szu­kam sen­sow­ne­go spo­so­bu opi­su reguł biz­ne­so­wych. Reguły biz­ne­so­we ste­ru­ją prze­cież prze­pły­wem pro­ce­su oraz poje­dyn­czy­mi zada­nia­mi – jak je spój­nie opisywać?

    1. Jarek Żeliński

      Tu, tak sądzę, nale­ży zde­fi­nio­wać co jest tą regu­łą. Osobiście prak­ty­ku­ję podej­ście pole­ga­ją­ce na koja­rze­niu zasad” z obiek­tem, któ­re­go zasa­dy doty­czą: zasa­dy spe­cy­ficz­ne dla roli/stanowiska z ta rolą i te lądu­ją w zakre­sach obo­wiąz­ków ludzi. Zasady spe­cy­ficz­ne dla obiek­tów biz­ne­so­wych” koja­rzę z tym obiek­ta­mi (lądu­ją potem w kodzie). Pozostałe to zasa­dy ogól­no­kor­po­ra­cyj­ne” i te nazy­wam regu­ła biz­ne­so­wą” bo doty­czy całe­go biz­ne­su”, z tego co czy­tam to podob­ną meto­dę zale­ca Ron Rose, jed­nak on wię­cej paku­je” do biz­ne­su” , osią­ga wyni­ki nawet setek reguł biz­ne­so­wych w doku­men­ta­cji, chy­ba dla­te­go, że zali­cza do niech tak­że te, któ­re ja koja­rzę z zakre­sa­mi obo­wiąz­ków. Moje podej­ście pozwa­la her­me­ty­zo­wać” odpo­wie­dzial­ność za zasa­dy” już na pozio­mach śred­nich szcze­bli zarzą­dza­nia. Nie wyobra­żam sobie sku­tecz­ne­go (roz­sąd­na pra­co­chłon­ność) zarzą­dza­nia set­ka­mi reguł biz­ne­so­wych, nawet posia­da­jąc jakieś narzę­dzie do tego.

      A tak przy oka­zji: tu dosko­na­ły przy­kład budo­wy reguł biznesowych:
      http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​B​u​s​i​n​e​s​s​A​n​a​l​y​s​t​H​u​m​o​r​/​t​a​b​i​d​/​2​1​8​/​D​e​f​a​u​l​t​.​a​s​p​x​?​A​r​t​i​c​l​e​T​y​p​e​=​A​r​t​i​c​l​e​V​i​e​w​&​A​r​t​i​c​l​e​I​D​=​2​471

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.