Po uka­za­niu się arty­ku­łu Reguły biz­ne­so­we jako motor.. czę­sto jestem pyta­ny dla­cze­go restryk­cyj­nie pil­nu­ję for­mal­nych zasad ana­li­zy w pro­jek­cie. Powód jest tyl­ko jeden: to jedy­ny spo­sób na osią­gnie­cie spój­no­ści i kom­plet­no­ści w pierw­szym podejściu.

Iteracyjne dopro­wa­dza­nie doku­men­tu (opra­co­wa­nia) do wyma­ga­ne­go pozio­mu jego jako­ści jest bar­dzo kosz­tow­ne. Zaryzykuje tezę, że jeden dobry ana­li­tyk (na umo­wę o dzie­ło ;)) wyko­na tę samą pra­ce znacz­nie szyb­ciej, taniej i lepiej niż prze­cięt­ny zespół z pro­ce­sem kon­tro­li jako­ści w posta­ci recen­zen­tów”. Nawet jeden ana­li­tyk z tra­dy­cyj­nym podej­ściem plus jeden recen­zent to pro­ces kosz­tow­niej­szy (dru­ga oso­ba w pro­jek­cie) i trwa­ją­cy znacz­nie dłu­żej (kolej­ne ite­ra­cje recen­zji, to tak­że koszt). Dyskusje pozo­sta­wiam Państwu, ja nie znam przy­pad­ku by powyż­sze się nie spraw­dzi­ło. Warunek: wła­ści­we sto­so­wa­nie wła­ści­wych narzę­dzi analitycznych.

Typowe zadanie: model organizacji

Model orga­ni­za­cji to doku­ment opi­su­ją­cy ją w spo­sób pozwa­la­ją­cy na zro­zu­mie­nie przy­czyn tego co i jak sie w niej dzie­je oraz na prze­wi­dy­wa­nie skut­ków pla­no­wa­nych dzia­łań (np. orga­ni­za­cyj­nych). Kluczowym, osta­tecz­nym narzę­dziem pra­cy jest model pro­ce­sów biz­ne­so­wych ale on jest efek­tem wie­lu rze­czy, w tym reguł biz­ne­so­wych (z regu­ły for­ma zarzą­dzeń itp.), kom­pe­ten­cji pra­cow­ni­ków. Reguły i kom­pe­ten­cje powin­ny być spój­ne i jed­no­znacz­ne stąd poja­wia się potrze­ba posia­da­nia w orga­ni­za­cji wspól­ne­go słow­ni­ka ter­mi­nów (ostat­nio spo­tka­łem fir­mę, w któ­rej nowe pro­jek­ty mają for­mal­ną wewnętrz­ną nazwę Temat a nie Projekt) .

Model taki to tak­że jedy­ny spo­sób za udo­ku­men­to­wa­nie i zatrzy­ma­nie w fir­mie Wiedzy o tym jak funk­cjo­nu­je i dla­cze­go aku­rat tak, mimo rota­cji pra­cow­ni­ków, od któ­rej nie jest wol­na żad­na fir­ma. Na począ­tek mała burza mózgów, czy­li cze­go oba­wia­ją się zarzą­dy firm:

Biblioteka

Jak roz­wią­zać te problemy?

Zakres projektu analitycznego

Jak wspo­mnia­no model pro­ce­sów jest koń­co­wym efek­tem pra­cy jed­nak nie jest on zawie­szo­ny w powie­trzu”. Aby wyko­nać go popraw­nie i sku­tecz­nie” (mieć moż­li­wość auto­au­dy­tu i wery­fi­ka­cji) nale­ży mieć: słow­nik pojęć biz­ne­so­wych (ang. glos­sa­ry, obej­mu­je swo­im zasię­giem obiek­ty biz­ne­so­we np. klu­czo­we doku­men­ty), model struk­tu­ry orga­ni­za­cyj­nej oraz spe­cy­fi­ka­cje reguł biznesowych.

Metamodel projektu

Słownik pojęć

Jest pod­sta­wo­wym wery­fi­ka­to­rem i gwa­ran­tem jed­no­znacz­no­ści wszel­kich zapi­sów, w tym nazw na mode­lach pro­ce­sów, pojęć uży­tych w regu­łach biz­ne­so­wych (w tym np. w wewnętrz­nych zarzą­dze­niach, pro­ce­du­rach itp.), nazw uży­tych w struk­tu­rze orga­ni­za­cyj­nej . Pojęcia te nie powin­ny być wza­jem­nie sprzecz­ne ani zazę­bia­ją­ce się” (każ­da rzecz w fir­mie powin­na paso­wać tyl­ko do jed­nej defi­ni­cji), nie powin­ny być defi­nio­wa­ne przez sie­bie same (jed­no z pomo­cą dru­gie­go). Zbudowanie popraw­ne­go (czy­taj bez­piecz­ne­go dla pro­jek­tu) słow­ni­ka jest trud­nym zada­niem. Tu for­ma­li­zmem jest utrzy­ma­nie powyż­szych zasad oraz sto­so­wa­nie odpo­wied­nich narzę­dzi ana­li­tycz­nych (spo­so­bów iden­ty­fi­ka­cji i weryfikacji).

Słownik reguł biznesowych

To kolej­ny ele­ment, któ­re­mu poma­ga­ją for­ma­li­zmy. Zgodnie z defi­ni­cją Reguła biz­ne­so­wa to ogra­ni­cze­nie obej­mu­ją­ce całą orga­ni­za­cję, regu­ła nie jest pro­ce­sem ani pro­ce­du­rą. Reguły (ich treść i spo­sób zapi­su) muszą być jasne (zro­zu­mia­łe), spój­ne i wery­fi­ko­wal­ne. Ich two­rze­nie, kon­tro­la nie­sprzecz­no­ści i kom­plet­no­ści wyma­ga tak­że prze­strze­ga­nia pew­nych zasad (for­ma­li­zów). W prze­ciw­nym wypad­ku ska­za­ni jeste­śmy na ich wery­fi­ka­cję poprzez wdro­że­nie i obser­wo­wa­nie skut­ków czy­li efek­tów ubocz­nych w orga­ni­za­cji po wpro­wa­dze­niu np. nowych zaka­zów lub obo­wiąz­ków, co jest dłu­go­trwa­łe i bar­dzo kosztowne.

Narzędziem do wychwy­ty­wa­nia” i wery­fi­ka­cji logi­ki poję­cio­wej reguł biz­ne­so­wych (te są for­mu­ło­wa­ne z uży­ciem słow­ni­ka pojęć) jest tak zwa­ny dia­gram faktów:

Model faktow Biblioteka

Diagram ten (nie da się go zastą­pić ani dia­gra­mem klas UML ani mode­lem danych!) ma pew­ną spe­cy­fi­kę poję­cio­wą: skła­da się wyłącz­nie z pojęć zde­fi­nio­wa­nych w słow­ni­ku (pro­sto­ką­ty) oraz ze zda­rzeń zwa­nych fak­ta­mi, któ­re je opi­su­ją (a nie wią­żą!) zde­fi­nio­wa­ne poję­cia. W ten spo­sób opi­su­je­my (testu­je­my, ana­li­zu­je­my) klu­czo­wą, spe­cy­ficz­ną, sfe­rę dzia­ła­nia orga­ni­za­cji. Powyższe nie zastę­pu­je mode­lu pro­ce­sów, któ­ry opi­su­je powsta­wa­nie war­to­ści jako prze­pływ pra­cy. Tu mamy do czy­nie­nia z ele­men­tar­ny­mi fak­ta­mi opi­su­ją­cy­mi pod­sta­wo­we dzia­ła­nia w orga­ni­za­cji (model ten nie ope­ru­je poję­ciem kla­sa, zda­rze­nie ani produkt).

Po wyko­na­niu i prze­te­sto­wa­niu powyż­sze­go dys­po­nu­je­my słow­ni­kiem pojęć i spe­cy­fi­ka­cją reguł biz­ne­so­wych speł­nia­ją­cą powyż­sze wymagania:

Zestawienie regul i pojec

Struktura organizacyjna

W brew pozo­rom jej opra­co­wa­nie nie jest łatwe. Struktura orga­ni­za­cyj­na okre­śla pod­le­głość i zara­zem odpo­wie­dzial­ność. Powinna być jed­no­znacz­na. Jako model sta­no­wi pew­ną hie­rar­chię, któ­rej szczy­tem jest pod­miot mode­lo­wa­ny (na szczy­cie jest to orga­ni­za­cja, w pew­nym sen­sie obra­zu­je to oso­bę praw­ną). Celem jest okre­śle­nie jed­no­znacz­nej pod­le­gło­ści i odpo­wie­dzial­no­ści każ­de­go pra­cow­ni­ka. Pracownik peł­ni funk­cje zde­fi­nio­wa­ną przez jego umo­co­wa­nie w tej struk­tu­rze, dopusz­czal­ne jest to, że jakaś oso­ba zaj­mu­je wię­cej niż jed­no sta­no­wi­sko (wte­dy nazy­wa­my to PO czy­li peł­nią­cy obo­wiąz­ki). W efek­cie pozwa­la to na jed­no­znacz­ne przy­po­rząd­ko­wa­nie oso­by do roli w pro­ce­sie (o tym w dal­szej części).

Model struktury organizacyjnej

Powyższy dia­gram jest try­wial­ny ale obra­zu­je tę hie­rar­chię. Gdyby z jakie­goś powo­du Kierownik biblio­te­ki miał wypo­ży­czać jeden dzień książ­ki, to zna­czy, że kon­kret­ny Kowalski (ten kie­row­nik) tego dnia będzie peł­nił obo­wiąz­ki (rolę) Bibliotekarza. System peł­nią­ce­go obo­wiąz­ki” poma­ga w utrzy­ma­niu prząd­ku organizacyjnego.

Każdy ele­ment na takim dia­gra­mie (ele­ment struk­tu­ry orga­ni­za­cyj­nej) powi­nien mieć okre­ślo­ne: wyma­ga­ne umie­jęt­no­ści oraz zakres obo­wiąz­ków. Zakres obo­wiąz­ków to odpo­wie­dzial­ność, zaś umie­jęt­no­ści okre­śla­ją co kon­kret­na oso­ba musi umieć albo inny­mi sło­wy cze­go kon­kret­nej oso­bie nie trze­ba mówić (instru­ować jej) by wyko­na­ła swo­ją pra­cę popraw­nie. Poprawnie ozna­cza tu: w ocze­ki­wa­ny spo­sób. Im mniej­sze umie­jęt­no­ści tym bar­dziej szcze­gó­ło­wy musi być opis pra­cy jaką dana oso­ba ma wyko­ny­wać by robi­ła to zgod­nie z ocze­ki­wa­nia­mi (jest to ści­sła zależność).

Jak widać jest to obszar ana­li­zy, któ­ry przy oka­zji porząd­ku­je kwe­stie zarzą­dza­nia zaso­ba­mi ludzkimi. 

W wie­lu fir­mach obser­wu­ję w tej sfe­rze bała­gan i z jed­nej stro­ny Zarząd nie dopusz­cza myśli o napra­wie­niu” struk­tu­ry orga­ni­za­cyj­nej, a z dru­giej w nie­skoń­czo­ność szu­ka przy­czyn kło­po­tów orga­ni­za­cyj­nych wymy­śla­jąc kolej­ne nowe, nie roz­wią­zu­ją­ce pro­ble­mu, zarządzenia.

Model procesów biznesowych

Pora na kon­kre­ty. Model (mapa) pro­ce­sów biz­ne­so­wych to efekt powyż­szych ogra­ni­czeń (tak: regu­ły biz­ne­so­we oraz struk­tu­ry orga­ni­za­cyj­ne i zakre­sy obo­wiąz­ków to ogra­ni­cze­nia). Dobrze opra­co­wa­ny model pro­ce­su jest kon­kret­ny, nie roz­wle­kły i czy­tel­ny. Opisuje (obra­zu­je) prze­pływ pracy:

Model procesow

Model pro­ce­sów biz­ne­so­wych bywa nazy­wa­ny (zgod­nie z teo­rią łań­cu­cha war­to­ści M.E.Portera) mode­lem wewnętrz­ne­go (fir­mo­we­go) łań­cu­cha war­to­ści. Model taki powi­nien być w 100% zgod­ny z defi­ni­cją pro­ce­su biz­ne­so­we­go, naj­czę­ściej przy­ta­cza­ną jest: pro­ces biz­ne­so­wy to czyn­ność lub łań­cuch czyn­no­ści, zamie­nia­ją­cy infor­ma­cje – stan wej­ścia w stan wyj­ścia, two­rząc war­tość doda­ną. Model taki powi­nien wiec obli­ga­to­ryj­nie zawie­rać: opis i stan wej­ścia, wyj­ścia, listę czyn­no­ści. Czynnikami opi­su­ją­cy­mi szcze­gó­ły wyko­na­nia każ­dej czyn­no­ści są: regu­ły biz­ne­so­we (w tym pro­ce­du­ry) oraz kom­pe­ten­cje wykonawcy.

W efek­cie otrzy­mu­je­my spój­ny i czy­tel­ny model pro­ce­su, nie prze­ła­do­wa­ny zbęd­ny­mi szcze­gó­ła­mi, zarzą­dza­ny i łatwy w uży­ciu. Korzyści z takie­go modelu:

  1. zmia­ny zakre­sów obo­wiąz­ków nie wyma­ga­ją jego aktualizacji
  2. zmia­ny reguł biz­ne­so­wych nie wyma­ga­ją jego aktualizacji
  3. zmia­na przy­po­rząd­ko­wa­nia kon­kret­nej oso­bie peł­nio­nych obo­wiąz­ków nie wyma­ga jego aktualizacji
  4. jest dosko­na­łym narzę­dziem do ana­li­zy wyma­gań na sys­te­my IT

To efek­ty utrzy­ma­nia for­mal­nej zasa­dy mówią­cej, że każ­da infor­ma­cja jest utrzy­my­wa­na w jed­nym miej­scu ze wska­za­niem gdzie jest wyko­rzy­sty­wa­na. Pozwala to tak­że wyko­nać szyb­ko tak zwa­na ana­li­zę wpły­wu (ryzyk) czy­li na co ma wpływ poten­cjal­na inge­ren­cja w jakiś ele­ment modelu:

wypozyczenie-ksiazki-analysis-diagram

Na zakończenie

Źródła stan­dar­dów na eta­pie ana­li­zy biz­ne­so­wej czy­li mode­lo­wa­nia struk­tur zarząd­czych organizacji:

  1. Semantics Of Business Vocabulary And Business Rules
  2. RuleSpeak
  3. BPMN
  4. Business Rules Group (w tym Business Motivation Model)

Stosowanie opi­sa­nych tu for­ma­li­zmów to uzna­nie, że dobre i spraw­dzo­ne stan­dar­dy pozwa­la­ją zmi­ni­ma­li­zo­wać ryzy­ko pro­jek­tów analitycznych.

Analiza to nie zbie­ra­nie danych o fir­mie i ich sor­to­wa­nie, bo czy to nie brzmi jak eko­lo­gicz­ne zbie­ra­nie śmie­ci? Analiza to porząd­ko­wa­nie zebra­nej wie­dzy o orga­ni­za­cji, korzy­sta­jąc z wypra­co­wa­nych sys­te­mów poję­cio­wych, czy­li przy­po­rząd­ko­wy­wa­nie wszyst­kie­go co wie­my do skoń­czo­nej licz­by pojęć, oraz uzu­peł­nia­nie lub napra­wia­nie wszyst­kie­go cze­go zabra­nie w tak opra­co­wa­nym mode­lu. Kluczem dobrej ana­li­zy jest uogól­nia­nie czy­li wychwy­ty­wa­nie rze­czy istot­nych oraz odsie­wa­nie infor­ma­cji zbęd­nych, nie mają­cych wpły­wu na cel pro­jek­tu a zaciem­nia­ją­cych go. Analiza to odkry­wa­nie i rozu­mie­nie reguł, pano­wa­nie nad zło­żo­no­ścią organizacji.

Większość pro­jek­tów takich jak np. wdra­ża­nie nowych metod kon­tro­lin­gu, zrów­no­wa­żo­nej kar­ty wyni­ków, nowych sys­te­mów IT itp. cier­pi głów­nie z powo­du posia­da­nia nad­mia­ru infor­ma­cji z jed­nej stro­ny i kom­plet­ne­go jej nie­zro­zu­mie­nia z dru­giej. Sławne już w bada­niach złe i nie­kom­plet­ne wyma­ga­nia” czy zmia­ny zakre­su pro­jek­tu w trak­cie jego trwa­nia” to kla­sycz­ne skut­ki złej (a czę­sto pomi­ja­nia!) ana­li­zy biz­ne­so­wej. Koszty tych pora­żek wie­lo­krot­nie prze­wyż­sza­ją koszt takich analiz.

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.

Dodaj komentarz

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