A po co nam ten SWOT

W poprzed­nim arty­ku­le (Ile jest tych wyma­gań na sys­tem ERP) pisa­łem, że nad­mier­ne sku­pia­nie się na szcze­gó­łach nie tyl­ko nie wno­si nicze­go do pro­jek­tu ale nie raz wręcz go nisz­czy. Dotyczy to zresz­tą ogól­nie pro­jek­tów ana­li­tycz­nych, nie tyl­ko w dzie­dzi­nie IT.

Na stro­nach jed­ne­go z bar­dziej poczyt­nych ser­wi­sów o ana­li­zie IT – http://​www​.moder​na​na​lyst​.com – poja­wił się jakiś czas temu cie­ka­wy arty­kuł o ana­li­zie SWOT. Autor opi­su­je jak tę ana­li­zę prze­pro­wa­dzić, ja opi­szę jak jej użyć w ana­li­zie sys­te­mo­wej orga­ni­za­cji i spe­cy­fi­ko­wa­niu wyma­gań. We wstę­pie arty­ku­łu czytamy:

Much of the busi­ness of busi­ness ana­ly­sis is in the deta­ils, and most busi­ness ana­ly­sts are by natu­re deta­iled, sys­te­ma­tic thin­kers. Occasionally most orga­ni­za­tions, tho­ugh, have times when they can?t see the forest for the tre­es. That is when the high-level, bro­ad-ran­ge view that SWOT Analysis affords is just as use­ful in avo­iding costly errors as unam­bi­gu­ous requ­ire­ments. (What is SWOT Analysis?).

W dużym uprosz­cze­niu: wie­lu ana­li­ty­ków sku­pia się od razu na szcze­gó­łach, bo to natu­ral­ne ele­men­ty nasze­go bez­po­śred­nie­go oto­cze­nia, nie potra­fią spoj­rzeć na orga­ni­za­cję z dale­ka, nie potra­fią dostrzec lasu patrząc na poje­dyn­cze drze­wa”. Analiza SWOT pozwa­la spoj­rzeć na pro­blem z innej, wyż­szej per­spek­ty­wy, sze­rzej, dzię­ki cze­mu jest bar­dzo uży­tecz­na w uni­ka­niu kosz­tow­nych błę­dów jaki­mi są nie­jed­no­znacz­ne wymagania. 

Jednym z zabój­ców pro­jek­tów” (a kon­kret­nie ich budże­tów i har­mo­no­gra­mów) są tak zwa­ne wyma­ga­nia osie­ro­co­ne i wyma­ga­nia nie­od­kry­te na eta­pie ana­li­zy. Są to odpo­wied­nio wyma­ga­nia zgło­szo­ne do spe­cy­fi­ka­cji i zre­ali­zo­wa­ne, z któ­rych następ­nie nikt nie korzy­sta, oraz te odkry­wa­ne dopie­ro na eta­pie wdro­że­nia. Nie da się zapro­jek­to­wać” lasu myśląc o drze­wach bo celem jest las, a nie kon­kret­ne drzewa. 

Jeden pro­jekt może mieć jeden cel, jeże­li jed­nak celem” ma być każ­dy kolej­ny krok, podróż nigdy się nie kończy.

Wymagania o jakich pisa­łem w poprzed­nim arty­ku­le to wyma­ga­nia wobec roz­wią­za­nia, któ­rym było jakieś opro­gra­mo­wa­nie”. Jednak to dru­gi etap ana­li­zy. Generalnie naj­pierw ana­li­zu­je się i defi­niu­je wyma­ga­nia biz­ne­so­we, a potem dopie­ro wyma­ga­nia wobec roz­wią­za­nia, wie­dząc już jakie warun­ki musi ono speł­niać. Przykładowym wyma­ga­niem biz­ne­so­wym może być pod­nie­sie­nie jako­ści obsłu­gi klien­ta (co by to tu teraz nie mia­ło zna­czyć), a dopie­ro reko­men­do­wa­nym roz­wią­za­niem może być, np. opro­gra­mo­wa­ne CRM albo reor­ga­ni­za­cja dzia­łu sprze­da­ży (co z resz­tą wie­le firm robi znacz­nie czę­ściej niż kupu­je nowy CRM ;)).

Wiele firm rzu­ca się na pro­jek­ty od razu z zało­że­niem, że musi­my mieć nowe opro­gra­mo­wa­nie”. Co nie raz bywa dużym błę­dem i masą zmar­no­wa­nych środ­ków. Jak się przed tym ustrzec?

Warto popa­trzeć na orga­ni­za­cję i kon­kret­ny pro­blem z pew­nej per­spek­ty­wy, z wyż­sze­go pozio­mu abs­trak­cji, niż tyl­ko sto­jąc mię­dzy biur­ka­mi widząc kon­kret­ne spra­wy i ludzi się nimi zaj­mu­ją­cy­mi. Narzędziem pozwa­la­ją­cym wznieść” się na wyż­szy poziom abs­trak­cji jest wła­śnie ana­li­za SWOT. Analiza ta pole­ga na ziden­ty­fi­ko­wa­niu czte­rech klu­czo­wych ele­men­tów wpły­wa­ją­cych na orga­ni­za­cję : czyn­ni­ki zewnętrz­ne jaki­mi są oka­zje i zagro­że­nia oraz czyn­ni­ki wewnętrz­ne czy­li sil­ne i sła­be stro­ny orga­ni­za­cji. Tu waż­na infor­ma­cja, ana­li­za SWOT to ana­li­za cze­goś kon­kret­ne­go” w okre­ślo­nym śro­do­wi­sku”. Czynniki wewnętrz­ne opi­su­ją to coś”, zaś czyn­ni­ki zewnętrz­ne opi­su­ją śro­do­wi­sko tego cze­goś”. Można tak ana­li­zo­wać orga­ni­za­cję (np. fir­ma i jej oto­cze­nie ryn­ko­we) czy też pro­duk­ty pro­jek­tów (np. kon­kret­ne opro­gra­mo­wa­nie w fir­mie) ale nie sam pro­jekt wdro­że­nio­wy czy pro­ces (one nie są czymś”).

Analiza SWOT może być ele­men­tem ana­li­zy sys­te­mo­wej orga­ni­za­cji. Analiza SWOT to np. wstęp do opra­co­wa­nia reko­men­da­cji w odpo­wie­dzi na pro­blem biz­ne­so­wy. SWOT to iden­ty­fi­ka­cja i wpływ okre­ślo­nych ele­men­tów, pozo­sta­je oce­na tego jaki, i na co. Dlatego ana­li­za SWOT sta­ła się czę­ścią tak zwa­ne­go Modelu Motywacji Biznesowej (BMM). Model ten pozwa­la lepiej zro­zu­mieć oto­cze­nie pro­ble­mu” oraz śla­do­wać” ele­men­ty ziden­ty­fi­ko­wa­ne w ana­li­zie SWOT na kon­kret­ne pro­ce­sy biz­ne­so­we i struk­tu­rę organizacyjną.

SWOT

(dia­gram BMM: ana­li­za SWOT i przej­ście na pro­ce­sy biz­ne­so­we opr. wła­sne autora).

Z poprzed­nich moich arty­ku­łów wie­my, że wyma­ga­nia wobec roz­wią­za­nia (w tym wobec opro­gra­mo­wa­nia) mają swo­je źró­dło w pro­ce­sach biz­ne­so­wych i ich wyko­naw­cach. Jednak spi­sa­nie ich w posta­ci dekla­ra­tyw­nej listy pod­czas warsz­ta­tów i wywia­dów, pro­wa­dzi do powsta­nia dłu­giej i prak­tycz­nie nie­we­ry­fi­ko­wal­nej listy o jakiej pisa­łem w Ile jest tych wyma­gań na sys­tem ERP.

Lekarstwem na pro­blem jest wery­fi­ka­cja (two­rze­nie) listy wyma­gań wobec roz­wią­za­nia. Weryfikacja (dia­gram powy­żej) pole­ga na tak zwa­nym śla­do­wa­niu. Śladowanie to wywo­dze­nie każ­de­go wyma­ga­nia z pier­wot­nej potrze­by, jaką jest tak­ty­ka, któ­rą przy­ję­to by osią­gnąć cel. Taktyka ma swo­je źró­dło w stra­te­gii (tak­ty­ka imple­men­tu­je stra­te­gię). Strategia (jej skon­stru­owa­nie) jest odpo­wie­dzią na oka­zję ryn­ko­wą, któ­ra jest przy­czy­ną, dla któ­rej podej­mu­je­my dzia­ła­nia ryn­ko­we. Okazja ryn­ko­wa daje szan­sę na zysk” (pro­dukt dają­cy docho­dy) w posta­ci dostar­cze­nia swo­je­mu oto­cze­niu war­to­ści doda­nej. Warto tu zwró­cić uwa­gę na to, że ele­men­ty ana­li­zy SWOT tak­że powin­ny mieć swo­je uza­sad­nie­nie w posta­ci iden­ty­fi­ka­cji zewnętrz­nych i wewnętrz­nych czyn­ni­ków wpły­wu. Słabe stro­ny oraz zagro­że­nia powin­ny iden­ty­fi­ko­wać ryzy­ka pro­jek­tu. Analizę uzna­je­my za zakoń­czo­ną po ziden­ty­fi­ko­wa­niu wszyst­kich zna­nych klu­czo­wych czyn­ni­ków wpły­wu i ryzyk. Analiza taka jest ele­men­tem ana­li­zy sys­te­mo­wej orga­ni­za­cji.

Wielu wła­ści­cie­li firm, ich zarzą­dy, pomi­ja ten etap w pro­jek­tach z uwa­gi na swo­je prze­ko­na­nie, że ich dotych­cza­so­we dzia­ła­nia i chęć ich kon­ty­nu­acji, nie wyma­ga­ją żad­nej korek­ty, ocze­ku­ją poda­nia na tacy opi­su narzę­dzia, któ­re­go – jak sądzą – potrze­bu­ją. Zachowują się jak pacjen­ci, któ­rzy mimo, że ostat­nie bada­nia robi­li wie­le lat temu, nie dopusz­cza­ją myśli, że lekarz może im prze­pi­sać na gorącz­kę coś inne­go niż kolej­ną aspi­ry­ną. Bywa, że zbyt póź­no odkry­wa­ją, że tym razem to nie było kolej­ne przeziębienie.

Praktyka poka­zu­je, coś bar­dzo cie­ka­we­go: zamiast pro­wa­dzić żmud­ne i kosz­tow­ne wywia­dy, sesje warsz­ta­to­we, burze mózgów, któ­rych pro­duk­tem jest dłu­ga lista dość przy­pad­ko­wych pomy­słów na wyma­ga­nia”, war­to docho­dzić do listy wyma­gań meto­dą od ogó­łu do szcze­gó­łu, wła­śnie od pozio­mu ana­li­zy SWOT (opar­tej na wizji i misji orga­ni­za­cji). Takie podej­ście od razu, naj­krót­szą dro­gą, pro­wa­dzi – przez model pro­ce­sów biz­ne­so­wych – do bar­dzo spój­nej i kom­plet­nej, bez nad­mia­ro­wych (osie­ro­co­nych) wyma­gań, spe­cy­fi­ka­cji wyma­gań wobec roz­wią­za­nia. Każde wyma­ga­nie ma swo­je uza­sad­nie­nie (śla­do­wa­nie) w stra­te­gii, nie ma ryzy­ka, że coś pomi­nie­my, bo tu wery­fi­ka­to­rem jest model pro­ce­su (kom­plet­na i spraw­dzo­na lista czyn­no­ści). Koszty uzy­ska­nia spe­cy­fi­ka­cji wyma­gań tą meto­dą, są znacz­nie niż­sze niż tra­dy­cyj­ny­mi (wywia­dy) meto­da­mi bo: nie anga­żu­je­my cza­su całych zespo­łów pra­cow­ni­ków na wywia­dy i warsz­ta­ty, ryzy­ko bar­dzo kosz­tow­nych pomi­nięć i nad­mia­rów jest mini­mal­ne, licz­ba ite­ra­cji w takim pro­jek­cie zbli­ża się do JEDNEJ! i nie trze­ba odkry­wać wyma­gań meto­dą kosz­tow­nych pro­to­ty­pów na eta­pie przed­wcze­snej imple­men­ta­cji. Jedyny pro­blem” to jej prze­pro­wa­dze­nie, mimo poku­sy”, roz­po­czę­cia pro­jek­tu od razu bo nie ma cza­su na ana­li­zę, i szko­da na to pieniędzy”.

Modelowanie struktury organizacyjnej – widać światełko w tunelu

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ć:

Profil Organisation Structure Metamodel

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):

Model Struktury Organizacyjnej

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.

Architektura korporacyjna z OMG​.org

Swego cza­su, gdy dowie­dzia­łem się, że nota­cja ArchiMate ma jed­nak być chro­nio­na pra­wa­mi autor­ski­mi przez The Open Group a koszt cer­ty­fi­ka­cji TOGAF to cał­kiem nie­zły haracz, napisałem:

Przyznaję, że rezy­gnu­ję z tej nota­cji jak i z TOGAF?a jako meto­dy­ki. W dwóch pro­jek­tach spraw­dzi­ła się moja hipo­te­za: mode­lo­wa­nie i ana­li­za war­stwy biz­ne­so­wej i IT oraz oce­na wza­jem­nych zależ­no­ści nie wyma­ga nowej nota­cji a dobrze wyko­na­ne­go mode­lu w już zna­nych, wystar­czą nota­cje BMM, BPMN, UML oraz narzę­dzie potra­fią­ce zarzą­dzać rela­cja­mi pomię­dzy obiek­ta­mi na tych mode­lach? zary­zy­ku­ję tezę, że jest to efek­tyw­niej­sze niż two­rze­nie kolej­nych dzie­sią­tek dia­gra­mów ArchiMate. (Pokazać wię­cej z sen­sem? ).

Podstawowym powo­dem jest to, że skąd­inąd dobry pomysł, jakim jest sama archi­tek­tu­ra kor­po­ra­cyj­na, jest obkła­da­ny ide­olo­gią (mar­ke­ting?!) i opła­ta­mi, któ­rych nie rozu­miem (albo raczej rozu­miem, ale nie mam ocho­ty ich pono­sić ;)), moi klien­ci nie raz tak­że nie).

Cóż to jest ta Architektura Korporacyjna (dalej Architektura lub AK)? Ogólnie:

Based on this bro­ade­ning of sco­pe, Enterprise Architecture now covers:

  • Business Architecture
  • Data Architecture
  • Application Architecture
  • Infrastructure Architecture

(pole­cam cały, krót­ki wpis na Business Analyst Interview Questions | Modern Analyst > What is Enterprise Architecture?).

Przytoczę tu pro­stą i bar­dzo dobrą moim zda­niem defi­ni­cję zaczerp­nię­tą z refe­ra­tu [[dr. Andrzeja Sobczaka (SGH)]]:

Architektura kor­po­ra­cyj­na – for­mal­ny opis struk­tu­ry i funk­cji kom­po­nen­tów kor­po­ra­cji (obej­mu­ją­cych ludzi, pro­ce­sy, infor­ma­cje i tech­ni­kę), wza­jem­nych rela­cji pomię­dzy tymi kom­po­nen­ta­mi oraz pryn­cy­pia i wytycz­ne odno­śnie do zarzą­dza­nia pro­jek­to­wa­niem i zarzą­dza­nia zmia­ną tych kom­po­nen­tów w czasie.

Moim zda­niem nie trze­ba nic wię­cej doda­wać. Dla porząd­ku przy­to­czę defi­ni­cję sło­wa pryn­cy­pium ze słow­ni­ka j.polskiego:

pryn­cy­pium, prin­ci­pium [wym. princ-ipium] ?naj­waż­niej­sza dla kogoś lub dla cze­goś zasa­da albo war­tość? (Portal Wiedzy PWN – słow­ni­ki, ency­klo­pe­die, pod­ręcz­ni­ki aka­de­mic­kie, książ­ki spe­cja­li­stycz­ne, repe­ty­to­ria, porad­ni­ki, prze­wod­ni­ki).

Te pryn­cy­pia, to moim zda­niem uzna­nie for­ma­li­zmu w budo­wie mode­li i sfor­ma­li­zo­wa­ne zarzą­dza­nie ich zmianą.

Narzędzia OMG​.org

Co mamy w skrzyn­ce narzę­dzio­wej OMG” (www​.omg​.org)? Ludzie i pro­ce­sy to nic inne­go jak BPMN i struk­tu­ra orga­ni­za­cyj­na (ta dru­ga w BPMN lub jako sfor­ma­li­zo­wa­ny [[orga­ni­gram]]). Informacje i tech­ni­ka to nic inne­go jak UML i dia­gra­my struk­tu­ral­ne. Nie roz­wo­dząc się, całość wyglą­da ogól­nie tak:

Architektura korporacyjna - struktura

Powyższy dia­gram obrazuje:

  • kolej­ne wyma­ga­ne w AK war­stwy (doda­no na szczy­cie tak zwa­ną moty­wa­cję biznesową),
  • mapo­wa­nie zstępujące

W efek­cie, mają zasto­so­wa­nie wska­za­ne narzę­dzia (dia­gra­my, mode­le). Z ich pomo­cą może­my nie tyl­ko opra­co­wać model Architektury Korporacyjnej ale tak­że nad­zo­ro­wać go, budu­jąc macie­rze mapowania.

Tu poja­wia się poję­cie prag­ma­ty­ki w sto­so­wa­niu języ­ka (nota­cji). Ta prag­ma­ty­ka to wspo­mnia­ne już pryn­cy­pia pro­ce­so­we i obiek­to­we, oraz wska­za­ne na dia­gra­mie powy­żej uży­cie pojęć w każ­dej z wymie­nio­nych nota­cji, czy­li co i na co mapu­je­my. Mapowanie wyma­ga dopre­cy­zo­wa­nia seman­ty­ki mode­li czy­li defi­ni­cji pojęć. Jak? Najprościej nie kom­bi­no­wać np. z przy­pad­ka­mi uży­cia na biz­ne­so­we, sys­te­mo­we i inne bo to zupeł­nie nie potrzeb­ne i nie pozwa­la na pro­ste mapowanie.

Jawne mapowanie na diagramach pomiędzy warstwami

Notacja ArchiMate ma moż­li­wość (taki jest jej pośred­ni cel) jaw­ne­go poka­za­nia mapo­wa­nia pomię­dzy obiek­ta­mi warstw na dia­gra­mach. W przy­pad­ku UML też jest to for­mal­nie moż­li­we od wer­sji 2.0, zaś mapo­wa­nia BPMN->UML doko­nu­je się w doku­men­ta­cji (typo­we śla­do­wa­nie Czynność -> Przypadek użycia).

Otóż mapo­wa­nie moż­na poka­zać na wie­le spo­so­bów. Moim zda­niem robie­nie tego na dia­gra­mach, po pierw­sze nie­co je zaciem­nia, po dru­gie i tak nie eli­mi­nu­je przy­dat­no­ści stwo­rze­nia macie­rzy mapo­wa­nia. Ta dru­ga może być wyge­ne­ro­wa­na auto­ma­tycz­nie, jeże­li tyl­ko uży­wa­my dobre­go narzę­dzia CASE (bez nie­go zresz­tą nie wyobra­żam sobie wyko­na­nia żad­ne­go więk­sze­go mode­lu przy zacho­wa­niu roz­sąd­nej pracochłonności).

Po dru­gie nawet śred­ni model, mają­cy kil­ka­dzie­siąt obiek­tów, będzie wyma­gał dużej ilo­ści dodat­ko­wych dia­gra­mów obra­zu­ją­cych samo mapo­wa­nie, któ­re to dodat­ko­we dia­gra­my nie wno­szą war­to­ści doda­nej do pro­jek­tu, bo macierz gene­ro­wa­na auto­ma­tycz­nie z repo­zy­to­rium narzę­dzia CASE i tak jest łatwiej­sza w uży­ciu i per­cep­cji, sta­no­wi też nie­ja­ko auto­ma­tycz­ny wali­da­tor” czy jest ono – mapo­wa­nie – popraw­ne i kompletne.

TOGAF – subiektywnych słów kilka

O tym krót­ko. Wiem, że sta­no­wi swe­go rodza­ju gotow­ca”, ale czy skór­ka war­ta wypraw­ki? Celem budo­wa­nia AK nie jest wdro­że­nie TOGAF”a” (czy też Siatki Zachmann’a), celem jest … no wła­śnie co? O tym na końcu.

W przy­pad­ku TOGAF v 8.x mamy czte­ry obsza­ry modelowania:

  • Business Architecture
  • Data Architecture
  • Applications Architecture
  • Technology Architecture

(źr. The Open Group Architecture Framework Version 8.1.1., nowa wer­sja TOGAF 9, w porów­na­niu z powyż­szym, roz­cią­ga się na ele­men­ty moty­wa­cji biznesowej).

Nie będę się roz­pi­sy­wał na temat wszyst­kich warstw. Kilka słów o jed­nej: Architektura Danych.

TOGAF i ArchiMate (jak ja rozu­miem obie spe­cy­fi­ka­cje) ope­ru­je poję­ciem danych, oddzie­lo­nych od logi­ki biz­ne­so­wej. Obecnie sto­so­wa­ne meto­dy i narzę­dzia w pro­ce­sie wytwa­rza­nia opro­gra­mo­wa­nia opar­te są na para­dyg­ma­cie obiek­to­wym, któ­ry kom­plet­nie igno­ru­je poję­cie wydzie­lo­nych danych jako takich. Mam tu na myśli bazy danych (w szcze­gól­no­ści rela­cyj­ne). Bazy danych, w meto­dach obiek­to­wych, to ele­men­ty imple­men­ta­cji, więc są one poza obsza­rem ana­li­zy i pro­jek­to­wa­nia. Przedmiotem prze­twa­rza­nia w para­dyg­ma­cie obiek­to­wym są obiek­ty biz­ne­so­we wraz z ich wewnętrz­ną logi­ką i zachowaniami.

Jaki jest więc sens brnię­cia wstecz do cza­sów ana­li­zy struk­tu­ral­nej (odręb­nie ana­li­zo­wa­ne i imple­men­to­wa­ne dane i funk­cje ich przekształcania)?

Przypomnę tu tyl­ko deli­kat­nie, że np. celem pro­ce­su sprze­da­ży nie są dane zapi­sa­ne na Fakturze VAT a pozy­ska­nie środ­ków ze sprze­da­ży pro­duk­tów, obiekt biz­ne­so­wy Faktura VAT wraz z regu­ła­mi nali­cza­nia podat­ku, to jakaś mate­ria­li­za­cja tego fak­tu a nie cel sam w sobie. Powoływanie się więc na dane” w moich oczach nie jest żad­nym postę­pem”.

Na zakończenie

Mamy więc pomysł o wdzięcz­nej nazwie Architektura Korporacyjna. Jej defi­ni­cję, moim zda­niem, moż­na spro­wa­dzić do treści:

Architektura Korporacyjna to model i jego doku­men­ta­cja, zawie­ra­ją­cy całą i wystar­cza­ją­cą wie­dzę o tym, co ma wpływ na dostar­cza­nie pro­duk­tu (J.Żeliński)

Po nam to? Po co nam taka doku­men­ta­cja? Przykłady korzy­ści z jej posiadania:

  • mamy na tacy” model sys­te­mu zależ­no­ści (w tym ana­li­za wpły­wu) pozwa­la­ją­cy natych­miast oce­nić ryzy­ka zwią­za­ne z wza­jem­nym wpły­wem na sie­bie pro­ce­sów, ludzi, zaso­bów (np. jakie skut­ki będzie mia­ło wyłą­cze­nie kon­kret­ne­go ser­we­ra czy spóź­nie­nie do pra­cy kon­kret­ne­go pracownika),
  • mamy na tacy” wyma­ga­nia na opro­gra­mo­wa­nie, bez nie­po­trzeb­ne­go zwin­ne­go” ich poszu­ki­wa­nia meto­dą prób i błę­dów, nie­za­leż­nie od tego czy kupu­je­my nowe czy wymie­nia­my (nie­ste­ty, tak zwa­ne zwin­ne meto­dy to nie raz bar­dzo duże kosz­ty zarzu­co­nych bocz­nych ście­żek” odkry­wa­nych burzą mózgów),
  • od razu zauwa­ży­my, że idea posia­da­nia mono­li­tycz­ne­go sys­te­mu ERP II nie bar­dzo ma sens, usztyw­nia orga­ni­za­cje oraz two­rzy potęż­ny [[„sin­gle point of failu­re”]] (zło­śli­wi doda­ją sin­gle point of big cost” :)),
  • i naj­waż­niej­sze: jak tyl­ko prze­pro­wa­dzi­my ana­li­zę i wyko­na­my model AK, szyb­ko wychwy­ci­my tak zwa­ne osie­ro­co­ne wyma­ga­nia na opro­gra­mo­wa­nie, osie­ro­co­ne sta­no­wi­ska pra­cy, osie­ro­co­ne pro­ce­du­ry, … (osie­ro­co­ne: nie­wy­ko­rzy­sty­wa­ne), to nie raz źró­dło samo w sobie – eli­mi­na­cja sie­rot” – ogrom­nych oszczęd­no­ści juz na samym począt­ku projektu,
  • i inne …

Jak tym zarzą­dzać? Na pew­no nie ręcz­nie, bez opro­gra­mo­wa­nia CASE w zasa­dzie nie­re­al­ne. Czy to kosz­tow­ne? Hm… kła­nia się ana­li­za ROI, każ­da orga­ni­za­cja ma swój próg ren­tow­no­ści. Jednak od sie­bie powiem tak: oszczęd­no­ści poja­wia­ją się natych­miast w posta­ci iden­ty­fi­ka­cji sie­rot”. Kolejny etap oszczęd­no­ści to reor­ga­ni­za­cja kosz­tów i ryzyk zarzą­dza­nia orga­ni­za­cją, kosz­tów posia­da­nia opro­gra­mo­wa­nia, kosz­tów jego roz­wo­ju, kosz­tów zaku­pu i two­rze­nia. Dobra wia­do­mość: począ­tek każ­dy już ma w posta­ci pro­wa­dzo­nej doku­men­ta­cji w dzia­le HR.

Jak więc wyglą­da­ją narzę­dzia rodem z OMG, któ­re w zupeł­no­ści wystarczą??

Jest to zestaw nota­cji (BMM, BPMN, UML), któ­ry ma nie­mal­że każ­dy pakiet CASE. Notację ArchiMate mają nie­ste­ty tyl­ko nie­któ­re z nich, a jak The Open Group zacznie egze­kwo­wać opła­ty licen­cyj­ne to będzie chy­ba tyl­ko gorzej (co cie­ka­we sami twó­cy ArchiMate piszą, że uszcze­gó­ło­wie­nie mode­lu AK wyko­na­ne­go z pomo­cą ArchiMate wyma­ga uży­cia nota­cji UML). Koszty jed­nej licen­cji pakie­tu CASE (nie raz wystar­czy mieć jed­ne­go Architekta w orga­ni­za­cji) w wie­lu przy­pad­kach nie prze­kra­cza­ją 1000USD. Jeżeli więc uda się unik­nąć kolej­nej ana­li­zy wyma­gań za kil­ka­dzie­siąt tysię­cy to już ROI mamy w kieszeni.

A po co te for­ma­li­zmy (pryn­cy­pia)? Na eta­pie ana­li­zy i mode­lo­wa­nia pozwa­la­ją wery­fi­ko­wać popraw­ność mode­li i całej struk­tu­ry. Na eta­pie zarzą­dza­nia zmia­ną pano­wać nad kosz­ta­mi zmian i ryzy­ka­mi w rodza­ju i czasopisma”…:)

Druga dobra wia­do­mość: spo­koj­nie moż­na to (rola Architekta) out­so­ur­so­wać, będzie jesz­cze taniej.

Analiza oddziaływania i jakość modelowania

Dziś mia­ła miej­sce kon­fe­ren­cja Virtu GigaCon. Mój refe­rat doty­czył wpły­wu wir­tu­ali­za­cji (jej wpro­wa­dze­nia jako narzę­dzia pra­cy) na ryzy­ka zwią­za­ne z dzia­ła­niem sys­te­mu IT w orga­ni­za­cji. Tu podzie­lę się kil­ko­ma jed­nak nie całym refe­ra­tem (zapra­szam na następ­ne kon­fe­ren­cje ;)) a wąt­kiem doty­czą­cym ana­li­zy oddzia­ły­wa­nia. Analiza taka pole­ga na opra­co­wa­niu np. listy tego na co w orga­ni­za­cji ma wpływ coś, np. na co ma wpływ Proces XXX albo na co ma wpływ Pracownik JK czy tez na co w orga­ni­za­cji ma wpływ Serwer XXX.

Analizy takie robi się naj­czę­ściej w pro­jek­tach zwią­za­nych z oce­ną ryzy­ka funk­cjo­no­wa­nia, jed­nak jest to bar­dzo przy­dat­ne narzę­dzie w pra­cy nad wyma­ga­nia­mi na opro­gra­mo­wa­nie i opra­co­wy­wa­nie wyma­gań poza-funk­cjo­nal­nych. Podam pro­sty przy­kład: dobrą prak­ty­ką jest prio­ry­te­ty­za­cja przy­pad­ków uży­cia, na jakiej pod­sta­wie nada­je­my te prio­ry­te­ty? Najczęściej na bazie dekla­ra­cji zama­wia­ją­ce­go, jed­nak nie raz oka­zu­je się, że pozor­nie mało istot­na usłu­ga sys­te­mu jako sama w sobie, jest w pew­nych sytu­acjach klu­czo­wym ele­men­tem. Po pierw­sze war­to znać prze­bieg pro­ce­su w jakim dana usłu­ga jest wyko­rzy­sty­wa­na, tu mam sytu­ację rela­tyw­nie pro­stą bo łań­cuch jest tak dobry jak naj­słab­sze ogni­wo. Jeżeli jakiś pro­ces ma wyso­ki prio­ry­tet to zna­czy, że wszyst­kie przy­pad­ki uży­cia (wyma­ga­ne funk­cjo­nal­no­ści) zwią­za­ne w tym pro­ce­sem tak­że. dekla­ra­tyw­na lista przy­pad­ków uży­cia raczej nam tego nie powiem.

Ale to dość pro­sta ana­li­za”, wystar­czy mieć mode­le pro­ce­sów i wypro­wa­dzo­ne z nich przy­pad­ki uży­cia. Zaczynają się pro­ble­my przy pró­bie oce­ny zwią­za­nej np. ze sta­no­wi­skiem zaj­mo­wa­nym przez akto­ra (role w pro­ce­sie. Można domnie­my­wać, że pew­ne funk­cjo­na­li­ści są waż­ne, nie z powo­du udzia­łu w waż­nym pro­ce­sie, ale z powo­du tego, że ich użyt­kow­ni­kiem jest waż­na oso­ba w fir­mie. Inny rodzaj zależ­no­ści: któ­re apli­ka­cje powin­ny mieć wyso­ką nie­za­wod­ność a któ­re nie, wie­dząc, że cześć z nich współ­dzie­li plat­for­mę sprzę­to­wą czy sys­te­mo­wą z innym, pro­ce­sy są wspie­ra­ne przez wie­le posia­da­nych systemów.

Tu daje o sobie znać meto­da spe­cy­fi­ko­wa­nia wyma­gań poza-funk­cjo­nal­nych jako osob­nej listy dla całe­go sys­te­mu (i tu pyta­nie co nazy­wa­my tu sys­te­mem, kon­kret­ne opro­gra­mo­wa­nie czy wszyst­kie zaso­by IT jakie mamy). Pokaże to na przykładzie.

Podstawą dobrze opra­co­wa­ne­go mode­lu jest two­rze­nie go od ogó­łu do szcze­gó­łu i śla­do­wa­nie to jest wypro­wa­dza­nie każ­de­go szcze­gó­łu z nad­rzęd­ne­go mode­lu uogól­nio­ne­go lub powiązanego.

Po lewej stro­nie pira­mi­da”, stan­dar­do­wy trój­war­stwo­wy model orga­ni­za­cji, od góry:

  1. war­stwa strategii
  2. war­stwa łań­cu­cha war­to­ści doda­nej i pro­ce­sów biznesowych
  3. war­stwa wyko­naw­cza i zasoby

Warstwa pierw­sza to stra­te­gia i tak­ty­ka dzia­ła­nia fir­my. Tu może sie poja­wić ogól­na archi­tek­tu­ra pro­ce­sów (tak­ty­ka dzia­ła­nia). Kolejna to klu­czo­wy ele­ment, abs­trak­cja opi­su­ją­ca jak fir­ma budu­je war­tość, jak powsta­ją jej pro­duk­ty (tak­że pośred­nie). Najniżej mamy zaso­by: ludzie, IT, inne. Taki model to nic inne­go jak model archi­tek­tu­ry kor­po­ra­cyj­nej (tyle, że jak widać nie musi to być nota­cja [[ArchiMate]] a wystar­czy BPMN i UML).

Kompletny opis (model) orga­ni­za­cji to:

  1. mode­le opi­su­ją­ce cele biz­ne­so­we i klu­czo­we dzia­ła­nia (archi­tek­tu­ra procesów),
  2. mode­le pro­ce­sów biznesowych,
  3. mode­le struk­tu­ry orga­ni­za­cyj­nej wraz z opi­sa­mi kom­pe­ten­cji oraz mode­le archi­tek­tu­ry sys­te­mu IT.

Model zawie­ra­ją­cy wyżej opi­sa­ne śla­do­wa­nia (i tyl­ko taki!) pozwa­la na ana­li­zę zale­zno­ści, np. chce­my dowie­dzieć się na co ma wpływ Proces_2, wte­dy powi­nien powstać np. taki diagram:

Jak widać, śla­do­wa­nie jest tu warun­kiem koniecz­nym dla­cze­go? Taki model może powstać auto­ma­tycz­nie” (narzę­dzie do mode­lo­wa­nia musi posia­dać taka funk­cjo­nal­ność). jed­nak to nie jedy­ny waru­nek: model musi zacho­wy­wać for­mal­na popraw­ność, czy­li nie uży­wa­my poję­cia Rola (pas na mode­lu pro­ce­sów) do symu­lo­wa­nia sys­te­mu” któ­ry coś robi, bo opro­gra­mo­wa­nie to narzę­dzie czło­wie­ka (rola w pro­ce­sie), spe­cy­fi­ka uży­cia dane­go narzę­dzia to umie­jęt­no­ści akto­ra (użyt­kow­ni­ka) i jest to co naj­wy­żej pro­blem sko­ja­rze­nia danej czyn­no­ści (pro­ce­su) z doku­men­tem opi­su­ją­cym pro­ce­du­rę lub instruk­cję użyt­kow­ni­ka (to tak­że narzę­dzie powin­no umożliwiać).

Wszelkie łama­nie for­ma­li­zmów nota­cji odno­si taki sam sku­tek jak np. wyko­rzy­sty­wa­nie pól w bazie danych do prze­cho­wy­wa­nia innych danych niż te z nagłów­ka np. wpi­sy­wa­nie dru­gie­go imie­nia do pola Nazwisko czy nazwy dziel­ni­cy w pole Miasto. Z takiej bazy danych żaden sen­sow­ny raport już nie powsta­nie. Jeżeli na mode­lu pro­ce­sów uży­to sym­bo­li w innych zna­cze­niach niż to wyni­ka z uży­tej nota­cji żad­nej sen­sow­nej infor­ma­cji też nie uzy­ska­my… to już nie mode­le tyl­ko zwy­kłe obrazki.

Nieudane wdrożenie wielkiego systemu informatycznego w USA – a co u nas?

Jakiś czas temu pisa­łem o swo­ich prze­my­śle­niach po roz­mo­wie z pew­nym dyrek­to­rem finan­so­wym jed­ne­go z moich klien­tów. Powiedział mię­dzy inny­mi, że albo pro­jekt zosta­nie zre­ali­zo­wa­ny w roku jed­nym budże­to­wym, albo on nie wyda na zgo­dy na jego roz­po­czę­cie. W czym pro­blem? Ano w tym, że przy obec­nym tem­pie zmian na ryn­ku, pro­gno­za wykra­cza­ją­ca w przy­szłość dalej niż rok to wró­że­nie z fusów… Skutek? Jak oce­nić sto­pę zwro­tu z inwe­sty­cji w coś, co jest naj­bar­dziej płyn­nym, podat­nym na zmia­ny wyma­gań, zaso­bem w orga­ni­za­cji, czy­li sys­tem wspo­ma­ga­ją­cy zarzą­dza­nie nią?

Rynek sta­le się roz­wi­ja i doj­rze­wa. Praktycznie każ­da więk­sza fir­ma doświad­czy­ła w jakiejś for­mie wdro­że­nia goto­we­go, dosto­so­wy­wa­ne­go do potrzeb, opro­gra­mo­wa­nia ERP. Warto jed­nak pod­kre­ślić, że idea jed­ne­go ?super sys­te­mu? ERP II, odcho­dzi powo­li do lamu­sa. Moim zda­niem to kwe­stia roku, dwóch. Pierwsze symp­to­my to zale­ce­nia pro­du­cen­tów dużych sys­te­mów: wdra­żać goto­we opro­gra­mo­wa­nie w posta­ci ?goto­wej? tyl­ko tam gdzie pasu­je, obsza­ry spe­cy­ficz­ne dla fir­my opi­sać i zapro­jek­to­wać dla nich dedy­ko­wa­ne roz­wią­za­nie i zin­te­gro­wać. (czy­taj Biznes wycho­dzi z objęć sys­te­mu ? mono­li­tycz­ne­go ERP).

Co z tym zro­bić? Dzielić, jak to mawia­ją nie­któ­rzy kie­row­ni­cy pro­jek­tów: czło­wiek może zjeść nawet sło­nia, jak? Kęs po kęsie. Tak więc duży pro­jekt nale­ży podzie­lić na samo­dziel­ne” pod­sys­te­my, jed­nak ta samo­dziel­ność ma dwa aspek­ty: każ­dy pod­sys­tem musi sam z sie­bie do cze­goś słu­żyć, powi­nien wno­sić war­tość doda­ną. Drugi: każ­dy pro­jek­to­wa­ny pod­sys­tem powi­nien być zapla­no­wa­ny jako poten­cjal­nie samo­dziel­ne narzę­dzie (inwe­sty­cja) na wypa­dek gdy­by pozo­sta­łe nie zosta­ły nigdy wytwo­rzo­ne np. z powo­du zmian na rynku.

Ale o tym pisa­łem wię­cej już wcze­śniej. Kolejnym pro­ble­mem jest nie­ste­ty jakość projektowania:

Według fir­my ana­li­tycz­nej Gartner oko­ło 60 proc. wdro­żeń wiel­kich sys­te­mów infor­ma­tycz­nych koń­czy się klę­ską. Przyczyną jest m.in. nie­umie­jęt­ność prze­ło­że­nia pro­ce­sów dzia­ła­ją­cych w fir­mie na dzia­ła­nie sys­te­mu infor­ma­tycz­ne­go, brak dosta­tecz­ne­go wspar­cia ze stro­ny pra­cow­ni­ków i kie­row­nic­twa fir­my (cza­sem nawet jaw­ny opór), złe przy­go­to­wa­nie wdro­że­nia lub jego pro­wa­dze­nie. (za Serwis Nauka w Polsce – PAP SA).

Jak widać, jakość pro­jek­to­wa­nia jest klu­czem, zresz­tą nie tyl­ko w przy­pad­ków dużych sys­te­mów ale w każ­dym przy­pad­ku. Różnica jest taka, że jeże­li nie­jed­na fir­ma świa­do­mie ryzy­ku­je kil­ka­set tysię­cy rezy­gnu­jąc z eta­pu nie­za­leż­nej ana­li­zy i pro­jek­to­wa­nia war­tej ok. 10 – 20% tej kwo­ty, to podob­ne podej­ście pro­jek­ty war­te milio­nów jest już raczej nieracjonalne…

Po raz kolej­ny już spraw­dza się teza, że wdra­ża­nie jed­ne­go wiel­kie­go ERP inte­gru­ją­ce­go wszyst­ko” jest mrzon­ką… prak­ty­ka poka­zu­je, że kil­ka sys­te­mów dzie­dzi­no­wych, zin­te­gro­wa­nych ze sobą jest po pierw­sze mniej ryzy­kow­ne a po dru­gie, para­dok­sal­nie, tańsze.

Tak więc: jak dostaw­ca duże­go ERP mówi, że duży ERP jest naj­lep­szy to nale­ży to trak­to­wać tak samo jak ofer­tę dostaw­cy duże­go zesta­wu garn­ków ze sta­li nie­rdzew­nej, z któ­rych i tak na co dzień uży­wa­my jed­ne­go a nale­śni­ki i tak robi­my z pomo­cą kupio­nej wcze­śniej dobrej teflo­no­wej patel­ni bo do nale­śni­ków lep­sza a zamia­na jej na nową z nie­rdzew­ki tyl­ko dla­te­go, że ?z kom­ple­tu? prze­czy zdro­we­mu roz­sąd­ko­wi i uży­wa się jej mimo, że pokryw­ka z zesta­wu lek­ko wysta­je ? ale przy­kry­wa bo taki jest jej głów­ny cel (w zasa­dzie tyl­ko nie powin­na być mniej­sza ani zbyt duża). (Nigdy wię­cej ERP w jed­nym kawał­ku!).

Raport z Badania polskich projektów informatycznych 2010

Na stro­nie PMResearch​.pl poja­wi­ło się cie­ka­we bada­nie Raport zawie­ra rezul­ta­ty ana­li­zy 80 sta­ran­nie wyse­lek­cjo­no­wa­nych pro­jek­tów IT. Wyniki pre­zen­tu­je w zwię­zły, syn­te­tycz­ny spo­sób. Pobierz raport (za Informacje o wyni­kach bada­nia pol­skich pro­jek­tów infor­ma­tycz­nych).

Wyniki bada­nia bar­dzo pole­cam, uczą poko­ry. Pytanie moje do auto­rów: jak zde­fi­nio­wa­no meto­dy­kę Agile? Pobieżna nawet bada­nie” zaso­bów w Internecie poka­zu­je, że nie ist­nie­je jed­na defi­ni­cja tego podej­ścia”. Na stro­nie agi​le​ma​ni​fe​sto​.org czytamy:

Wytwarzając opro­gra­mo­wa­nie i poma­ga­jąc innym w tym zakresie,

odkry­wa­my lep­sze spo­so­by wyko­ny­wa­nia tej pracy.

W wyni­ku tych doświad­czeń przedkładamy:

Ludzi i inte­rak­cje ponad pro­ce­sy i narzę­dzia.

Działające opro­gra­mo­wa­nie ponad obszer­ną doku­men­ta­cję.

Współpracę z klien­tem ponad for­mal­ne usta­le­nia.

Reagowanie na zmia­ny ponad podą­ża­nie za pla­nem.

Doceniamy to, co wymie­nio­no po pra­wej stronie,

jed­nak bar­dziej ceni­my to, co po lewej.

Można by odnieść wra­że­nie, że igno­ro­wa­ne jest wszyst­ko co naka­zu­je roz­są­dek (pogru­bie­nie moje). Paradoksalnie, obser­wu­jąc pro­jek­ty, mam wra­że­nie, że zwin­ność jest jed­nak czę­sto ina­czej rozu­mia­na, nie jako igno­ro­wa­nie zło­te­go trój­ką­ta” pro­jek­to­we­go (zakres, ter­min, budżet). Ja w każ­dym razie zawsze pytam: czym jest tu Agile. Niestety sły­szę nie raz, ze tego się nie defi­niu­je”… co wywo­łu­je u mnie odruch nie defi­niu­je się zakre­su pro­jek­tu” a to pro­wa­dzi do wnio­sku, że suk­ce­sem jest sam fakt roz­po­czę­cia projektu…

Analiza biznesowa

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.