Pisząc recen­zję książ­ki Modelowanie biz­ne­so­we napi­sa­łem, że kom­plet­ny model orga­ni­za­cji to:

słow­nik pojęć (Glossary), model struk­tu­ry orga­ni­za­cyj­nej, regu­ły biz­ne­so­we (spe­cy­fi­ka­cja) oraz model pro­ce­sów biz­ne­so­wych korzy­sta­ją­cy z trzech poprzed­nich. Całość sta­no­wi dopie­ro kom­plet­ny model organizacji.

W Listopadzie ubie­głe­go roku tak­że pisa­łem o mode­lo­wa­niu struk­tu­ry organizacyjnej.

Osobiście uwa­żam, że mode­lo­wa­nie struk­tu­ry orga­ni­za­cyj­nej w UML nie jest dobrym pomy­słem. Są do tego ?prost­sze? narzę­dzia, nie przy­pad­kiem te lep­sze narzę­dzia CASE mają do tego dedy­ko­wa­ny dia­gram. Niestety nie ma tu dedy­ko­wa­nej nota­cji, dla­te­go bar­dzo waż­ne jest by słow­nik pojęć w mode­lu zawie­rał takie poję­cia jak pra­cow­nik, komór­ka orga­ni­za­cyj­ne itp. Dobrym pomy­słem jest zde­fi­nio­wa­nie wła­snej kon­wen­cji (dia­gram, sym­bo­le, defi­ni­cje pojęć) np. jak ta na począt­ku arty­ku­łu. (Modelowanie struk­tu­ry orga­ni­za­cyj­nej).

Są wido­ki by ten brak został uzu­peł­nio­ny. OMG pra­cu­je nad for­mal­nym meta­mo­de­lem ([[Organisation Structure Metamodel]]) do mode­lo­wa­nia struk­tur orga­ni­za­cyj­nych. Specyfikacja jesz­cze nie zosta­ła opu­bli­ko­wa­na, jest na eta­pie RFP, ale mamy przecieki :).

Ogólnie szkie­let tego meta­mo­de­lu ma nastę­pu­ją­cą postać:

Powyższy dia­gram przed­sta­wia pro­fil czy­li model poję­cio­wy, któ­ry może słu­żyć do budo­wy dia­gra­mu struk­tu­ry orga­ni­za­cyj­nej. Powyższe poję­cia to sys­tem ste­reo­ty­pów, czy­li ​„znacz­ni­ków”. Przykładowy sche­mat struk­tu­ry orga­ni­za­cyj­nej z uży­ciem tych ste­reo­ty­pów mógł­by mieć poniż­szą postać (dia­gram więk­sze są dzie­lo­ne na pod­rzęd­ne struktury):

Kilka słów komen­ta­rza. Szkieletem każ­dej takiej struk­tu­ry jest sys­tem komó­rek orga­ni­za­cyj­nych. Ta część z regu­ły nie budzi wąt­pli­wo­ści i nie stwa­rza pro­ble­mów, do cza­su gdy zacho­wu­je drze­wia­stą struk­tu­rę (każ­dy ma tyl­ko jed­ne­go prze­ło­żo­ne­go). Problemem poja­wia się, gdy zaczy­na­my mówić o kom­pe­ten­cjach, rolach i funk­cjach osób zaj­mu­ją­cych poszcze­gól­ne sta­no­wi­ska i pró­bie mode­lo­wa­nie funk­cjo­no­wa­nia organizacji.

Typowym pro­ble­mem, z jakim spo­ty­kam się poma­ga­jąc two­rzyć lub audy­tu­jąc mode­le pro­ce­sów biz­ne­so­wych czy np. ana­li­zy cią­gło­ści dzia­ła­nia, jest mapo­wa­nie ról w pro­ce­sach na struk­tu­rę orga­ni­za­cyj­ną oraz zarzą­dza­nie kompetencjami.

Mamy tu do czy­nie­nia z pro­ble­mem jakim jest to, że jed­ną rolę w pro­ce­sie może peł­nić wie­le osób (sta­no­wisk). Klasyką jest np. to, że fak­tu­rę może wysta­wić nie tyl­ko Fakturzysta ale np. każ­dy pra­cow­nik dzia­łu księ­go­wo­ści i dyr. sprze­da­ży. Porażką ​„mode­la­rza” będzie nary­so­wa­nie dia­gra­mu, na któ­rym będzie, dla każ­de­go z powyż­szych sta­no­wisk, dedy­ko­wa­ny tor w pro­ce­sie i jakaś ​„logi­ka bra­mek” poka­zu­ją­ca kie­dy kto wysta­wi tę fak­tu­rę. Z dru­giej stro­ny z regu­ły nie­praw­dą jest, że nikt poza fak­tu­rzy­stą nie może wysta­wić fak­tu­ry. Wystarczy jed­nak stwo­rzyć ​„blo­czek” Rola lub Kompetencje (zależ­nie od sytuacji)->Wystawianie fak­tur i sko­ja­rzyć z wła­ści­wy­mi sta­no­wi­ska­mi, a blo­czek ten dopie­ro mapo­wać na role w pro­ce­sach. Uzyskamy dzię­ki temu ​„praw­dziw­szy” model, uzy­sku­je­my moż­li­wość jed­no­znacz­ne­go mapo­wa­nia (śla­do­wa­nie: «tra­ce») ele­men­tów struk­tu­ry orga­ni­za­cyj­nej na model pro­ce­sów biz­ne­so­wych, być może na model dzie­dzi­ny. Możliwe sta­nie się testo­wa­nie popraw­no­ści modelu.

Praktycznie żaden dia­gram struk­tu­ry orga­ni­za­cyj­nej, jaki moż­na spo­tkać w doku­men­tach więk­szo­ści firm i spół­ek, nie nada­je się do nicze­go poza ilu­stro­wa­niem doku­men­tów w jakich jest umiesz­cza­ny. Nie ma w tym nic złe­go, do cza­su gdy nie docho­dzi do ana­li­zy funk­cjo­no­wa­nia takiej organizacji.

Ktoś zapy­ta: po co te zaba­wy, komu to prze­szka­dza? Odpowiedź jest pro­sta: dia­gram, któ­ry nie pozwa­la na ana­li­zę zależ­no­ści, ana­li­zę wpły­wu, testo­wa­nie jed­no­znacz­no­ści nie jest żad­nym mode­lem, nie jest przy­dat­ny do ana­li­zy. Można nim co naj­wy­żej ład­nie zilu­stro­wać doku­men­ty ale na pew­no nie nada­je się do ana­li­zy a przy­po­mnę, że:

nauka mówi dość jasno: aby prze­wi­dy­wać reak­cje bada­ne­go przed­mio­tu nale­ży zro­zu­mieć jak funk­cjo­nu­je i opra­co­wać jego model. Po dro­dze nale­ży udo­wod­nić, praw­dzi­wość modelu.

Zaś:

Samo utwo­rze­nie map (bo nie mode­li) w posta­ci dia­gra­mów z pomo­cą wywia­dów, sesji warsz­ta­to­wych i obser­wa­cji, da pro­dukt podob­ny do zdję­cia lot­ni­cze­go rze­ki: wie­my któ­rę­dy pły­nie, ale kom­plet­nie nie rozu­mie­my dla­cze­go aku­rat tak.

Tak więc, jeże­li ana­li­za ma posłu­żyć wdro­że­niu jakie­go­kol­wiek opro­gra­mo­wa­nia czy zmian orga­ni­za­cyj­nych, to pomo­gą nam w tym tyl­ko mode­le a nie ​„obraz­ki”…

Na kon­fe­ren­cjach i forach toczą się sta­le dys­ku­sje na ten temat. Większość firm dorad­czych, infor­ma­tycz­nych oraz ich ana­li­ty­cy bro­nią tezy, że celem ana­li­zy jest zebra­nie infor­ma­cji w posta­ci doku­men­tów i zesta­wień. Niestety takie doku­men­ty są kom­plet­nie nie­przy­dat­ne, mają war­tość nagra­nia (patrz wyżej zdję­cie lot­ni­cze), nie da się na ich posta­wie wycią­gać żad­nych pozwa­la­ją­cych na dowo­dze­nie ich słusz­no­ści, wnio­sków nie licząc może oce­ny este­ty­ki edytorskiej.

Wiele się pisze o tym, że mode­lo­wa­nie słu­ży do doku­men­to­wa­nia pro­jek­tów. Otóż nie. Do doku­men­to­wa­nia pro­jek­tów słu­ży ryso­wa­nie, mode­lo­wa­nie słu­ży do pro­wa­dze­nia ana­liz poprzez testy mode­li, symu­la­cje i ana­li­zę sce­na­riu­szy. (Sabotaż doku­men­ta­cyj­ny).

Niewątpliwą zale­tą takiej pisa­nej obraz­ko­wej ​„ana­li­zy” jest to, że nie wyma­ga ona abso­lut­nie żad­nych kom­pe­ten­cji poza umie­jęt­no­ścią komu­ni­ka­cji. Takim ana­li­ty­kiem może być nie­mal­że każ­dy (łatwa rekru­ta­cja, niski koszt), ale czy taki jest cel ana­liz poprze­dza­ją­cych pro­jek­ty, war­te set­ki tysię­cy zło­tych a nie raz miliony?

Na zakoń­cze­nie dodam, że naj­gor­szym spo­so­bem jaki znam i jaki nie­ste­ty czę­sto spo­ty­kam, na mode­lo­wa­nie struk­tu­ry orga­ni­za­cyj­nej, jest uży­cie dia­gra­mu klas lub dia­gra­mu przy­pad­ków uży­cia i mode­lo­wa­nie z zasto­so­wa­niem dzie­dzi­cze­nia (klas lub aktorów).

Studiowanie zakre­sów obo­wiąz­ków pra­cow­ni­ków firm jaw­nie poka­zu­je, że to nie praw­da. Wielu mene­dże­rów dzia­łów nie ma kom­pe­ten­cji swo­ich pod­wład­nych, nie raz szef dzia­łu praw­ne­go nie ma, i nie musi mieć, upraw­nień rad­cow­skich czy adwo­kac­kich, w wie­lu więk­szych sekre­ta­ria­tach, upo­waż­nie­nia do pew­nych pod­pi­sów są przy­dzie­la­ne indy­wi­du­al­nie i szef (sze­fo­wa) tego dzia­łu nie ma tych wszyst­kich upo­waż­nień. Szef kan­ce­la­rii taj­nej może mieć upraw­nie­nia do infor­ma­cji taj­nej nada­ne przez ABW, któ­rych to upraw­nień nie ma nie raz, jego prze­ło­żo­ny. Przykładów na fał­szy­wość dzie­dzi­cze­nia upraw­nień w struk­tu­rze orga­ni­za­cyj­nej moż­na podać tak ogrom­ną ilość, że dość czę­ste sto­so­wa­nie tej kon­struk­cji wyda­je mi się niezrozumiałe.

W efek­cie pro­jek­tu­jąc opro­gra­mo­wa­nie i sto­su­jąc meto­dę dzie­dzi­cze­nia dla akto­rów sys­te­mu powie­la­my te nie­praw­dę w sys­te­mie co rodzi nie raz ogrom­ne kło­po­ty. (Modelowanie struk­tu­ry orga­ni­za­cyj­nej).

Na zakoń­cze­nie pole­cam cie­ka­wy arty­kuł na temat mode­lo­wa­nia ról w opro­gra­mo­wa­niu.