Co jest wadą większości analiz biznesowych?

To, że są one tak na praw­dę tyl­ko upo­rząd­ko­wa­nym zapi­sem wywia­dów z klien­tem a nie fak­tycz­ną ana­li­zą orga­ni­za­cji i jej potrzeb (bo nie koniecz­nie jej pra­cow­ni­ków!) i celów biz­ne­so­wych. Jakie są tre­ści tek­sto­we­go lub tabe­la­rycz­ne­go zapi­su wywia­dów? NIEJEDNOZNACZNE! Jakie są nie­sfor­ma­li­zo­wa­ne, swo­bod­nie two­rzo­ne dia­gra­my pro­ce­sów? NIEJEDNOZNACZNE! Jakie są słow­ne opi­sy struk­tu­ry opro­gra­mo­wa­nia jakie ma powstać? NIEJEDNOZNACZNE!

Co zro­bić? Używać już na eta­pie ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia sfor­ma­li­zo­wa­nych narzę­dzi takich jak stan­dar­do­we nota­cje i meto­dy­ki, wte­dy opi­sy będą JEDNOZNACZNE. Czy to trud­ne? Tak, w koń­cu te 70% pora­żek to nie przy­pa­dek? ( czy­taj cały arty­kuł: Analityk biz­ne­so­wy czy­li wyple­nić dwu­znacz­ność z doku­men­tów ana­li­tycz­nych!).

Dlaczego tak jest? Bo opro­gra­mo­wa­nie jest two­rzo­ne z pomo­cą języ­ków pro­gra­mo­wa­nia a te SĄ sfor­ma­li­zo­wa­ne. Nie da się skom­pi­lo­wać do posta­ci sys­te­mu ERP luź­nej pro­zy”. Napisałem to w Listopadzie 2011, dzi­siaj ciąg dal­szy. Na począ­tek dodam jesz­cze moją kon­klu­zję z pew­nej konferencji:

Tak więc język for­mal­ny, uży­ta nota­cja, czy­ni pro­jekt war­to­ścio­wym [jed­no­znacz­nym]. Bez tego raczej nie zna­czy on po pro­tu nic. (Modelowanie pro­ce­sów biz­ne­so­wych – dla­cze­go mają sens tyl­ko meto­dy for­mal­ne i uzna­ne nota­cje).

Jak to mówią: moc­ne sło­wa, ale nie zapo­mi­naj­my, że mało któ­ry pro­jekt biz­ne­so­wy IT koń­czy się w ter­mi­nie i zamy­ka w zało­żo­nym budże­cie. Zastanówcie jak były doku­men­to­wa­ne Wasze nie­uda­ne” projekty…

O notacjach

Króciutko, żeby się nie powta­rzać. Notacja to pewien język wyra­zu, prze­strzeń nazw zawie­ra­ją­ca skoń­czo­ną licz­bę pojęć o ści­śle zde­fi­nio­wa­nych zna­cze­niach. Notacji mamy na ryn­ku wie­le. Czy to jakiś pro­blem? W pew­nym sen­sie tak, bo po pierw­sze języ­ki te nie­co nakła­da­ją się na sie­bie (nakła­da­ją się na sie­bie prze­strze­nie nazw) ale nie dają się na sie­bie w spo­sób jed­no­znacz­ny tłu­ma­czyć. Języki te nie zastę­pu­ją się wza­jem­nie. Są w uży­ciu” nota­cje (sys­te­my two­rze­nia dia­gra­mów) nie­sfor­ma­li­zo­wa­ne, trud­no je w ogó­le nazy­wać nota­cją. To po pro­tu biblio­te­ki sym­bo­li do two­rze­nia sche­ma­tów blo­ko­wych a te nie koniecz­nie są mode­la­mi”. Przykładem może być bar­dzo popu­lar­ny MS Visio z wie­lo­ma biblio­te­ka­mi sym­bo­li. Niestety tak powsta­ją­ce dia­gra­my są zapew­ne ilu­stra­cją dla tek­stu ale nie są żad­nym modelem.

Opisze tu wybra­ne nota­cje, te któ­rych uży­wam i uzna­je za pewien stan­dard de’fac­to. Nie będzie to żad­ne szko­le­nie z nota­cji”, bo nie jest to ani miej­sce ani dobry spo­sób na szko­le­nia (na te ser­decz­nie zapra­szam zain­te­re­so­wa­nych na sale wykła­do­wą :)). Powiemy sobie o [[ArchiMate]], [[BMM]], [[BPMN]], [[UML]].

Co, kiedy i do czego

To co tu teraz napi­szę nie jest żad­nym dogma­tem. To efekt doświad­czeń, prac badaw­czych i pew­nych przemyśleń.

Każda orga­ni­za­cja to bar­dzo zło­żo­ny orga­nizm. Stopień zło­żo­no­ści jest duży jeże­li wziąć pod uwa­gę fakt, że nie­jed­na zatrud­nia dzie­siąt­ki pra­cow­ni­ków, two­rzy tysią­ce doku­men­tów, obsłu­gu­je set­ki spraw i uży­wa dzie­sią­tek narzę­dzi (w tym opro­gra­mo­wa­nie) wspo­ma­ga­ją­cych tę pra­cę . Czy to w ogó­le da się jakoś opi­sać? Owszem. Jak?

Organizacje się nie tyle opi­su­je” co raczej mode­lu­je. Ich model to uprosz­cze­nie, pozwa­la­ją­ce zro­zu­mieć spo­sób jej dzia­ła­nia. Problem jed­nak w tym, że orga­ni­za­cja to wie­le róż­nych aspek­tów jej dzia­ła­nia. Dla każ­de­go z nich powstał inny język opi­su, powo­dem jest (tak sądzę), po pierw­sze róż­ny odbior­ca na każ­dym pozio­mie szcze­gó­ło­wo­ści, a po dru­gie róż­ne para­dyg­ma­ty (pro­ce­so­wy, obiek­to­wy czy sys­tem ana­liz wpły­wu). Kto inny czy­ta opis stra­te­gii biz­ne­so­wej a kto inny opis tech­nicz­ny sys­te­mu ERP, jed­nak oba te aspek­ty są jakoś powią­za­ne (powin­ny być ;)) i to tak­że powin­no dać się opi­sać. Z tego powo­du pierw­szym podzia­łem mode­li są: mode­le logicz­ne (abs­trak­cja) i wyko­naw­cze (spe­cy­fi­ka­cja). Na to nakła­da się sfe­ra biz­ne­so­wa (zarzą­dza­nie) oraz tech­nicz­na (zaso­by w tym narzędzia).

Nie znaj­dzie­cie tu pań­stwo defi­ni­cji tych nota­cji, odsy­łam na stro­ny orga­ni­za­cji stan­da­ry­zu­ją­cych ([[Object Management Group]] oraz [[The Open Group]]). Pokaże do cze­go dosze­dłem na bazie dzie­sią­tek pro­jek­tów małych i dużych, dla real­nych przed­się­biorstw i fik­cyj­nych badaw­czych. Posłużę się kla­sycz­nym chy­ba już mode­lem ana­li­zy zstę­pu­ją­cej, w posta­ci pira­mi­dy obra­zu­ją­ce trzy pozio­my abs­trak­cji opi­su orga­ni­za­cji (im niżej tym wię­cej szcze­gó­łów zawie­ra dokumentacja):

Na naj­wyż­szym pozio­mie abs­trak­cji mamy stra­te­gię, tu poja­wia się tak zwa­ny model moty­wa­cji i ana­li­za wpły­wu. Obecnie uży­wam na tym pozio­mie nota­cji (języ­ka mode­lo­wa­nia) [[Business Motivation Model]]. Zawiera takie poję­cia jak cel biz­ne­so­wy, środ­ki osią­ga­nia celu ale tak­że bar­dzo waż­ne na tym eta­pie takie ele­men­ty jak czyn­ni­ki wpły­wu, ana­liz a SWOT, ryzy­ka czy stra­te­gie i taktyki.

Na tym pozio­mie od tego roku moż­na sto­so­wać nota­cję [[ArchiMate]], jed­nak w moim prze­ko­na­niu jest ona w tym obsza­rze zbyt sil­nie ukie­run­ko­wa­na na meto­dy­kę i struk­tu­ry opi­su [[TOGAF]], jest w moich oczach w tej sfe­rze uboż­sza, bra­ku­je jej wie­lu pojęć obsłu­gi­wa­nych” przez BMM.

Jeżeli nie widzę nic złe­go w sto­so­wa­niu kil­ku nota­cji w jed­nym pro­jek­cie (jest to w zasa­dzie koniecz­ność), to z zasa­dy uży­wam wyłącz­nie jed­nej nota­cji na jed­nym pozio­mie abs­trak­cji (war­stwie jak wyżej). Używanie na jed­nym pozio­mie np. dwóch róż­nych nota­cji pro­wa­dzi co naj­mniej do bra­ku spój­no­ści mode­li gdyż poję­cia róż­nych nota­cji róż­nią się swo­im zasię­giem (poszcze­gól­ne poję­cia mają nie­co inne znaczenia).

Na pozio­mie pro­ce­sów biz­ne­so­wych, sto­su­ję zamien­nie BPMN albo ArchiMate. Z każ­dym kolej­nym pro­jek­tem skła­niam się jed­nak do uży­wa­nia na tym pozio­mie ArchiMate. Powodem jest to, że BPMN ofe­ru­je wyłącz­nie czy­ste poję­cia z defi­ni­cji pro­ce­su (czyn­ność, dane, zda­rze­nie, rola, pula, bram­ki). Na tym pozio­mie jed­nak nie raz nale­ży wyra­zić roz­dziel­nie takie poję­cia jak rola i aktor (np. klient i kon­tra­hent mogą peł­nić rolę zama­wia­ją­ce­go w pro­ce­sie) albo odręb­ne poję­cia takie jak funk­cje biz­ne­so­we (aktor wraz z zaso­ba­mi jakich uży­wa peł­ni funk­cję admi­ni­stra­cji wewnętrz­nej) albo usłu­gi powią­za­ne z pro­ce­sa­mi (pro­ces sprze­da­ży powią­za­ny z usłu­gą obsłu­gi klien­ta). Przykłady moż­na mnożyć.

Realizacja pro­ce­sów to suche” łań­cu­chy czyn­no­ści i twar­da logi­ka ich sce­na­riu­szy. Tu dosko­na­le spraw­dza się BPMN i pier­wot­ny cel powsta­nia tej nota­cji: mode­lo­wa­nie skryp­tów BPEL ([[Business Process Execution Language]], a obec­nie głów­nie [[XPDL]]). W tej war­stwie BPMN nie ma kon­ku­ren­cji, jest w 100% zgod­ny z XPDL (język opi­su pro­ce­sów zale­ca­ny przez [[Workflow Management Coalition, WfMC]]). Podejmowane są pró­by sto­so­wa­nia UML (Diagram czyn­no­ści) ale nie wró­żę tej meto­dzie suk­ce­su i nie pole­cam jej (powo­dy na koń­cu tekstu).

Tu dodat­ko­wa mała uwa­ga. Nawet na pozio­mie wyko­naw­czym pro­ce­su rzad­ko poja­wia się potrze­ba, mode­lo­wa­nia expli­ci­te” każ­dej czyn­no­ści, z dokład­no­ścią nie­mal­że algo­ryt­micz­ną. W więk­szo­ści wypad­ków zupeł­nie wystar­czy model celo­wo­ści dzia­łań” i ich sce­na­riu­sze, algo­rytm postę­po­wa­nia potrzeb­ny jest tyl­ko maszy­nie. Na stro­nach BPM Research dostęp­ne są wyni­ki badań poka­zu­ją­ce to zja­wi­sko: The ave­ra­ge sub­set of BPMN used in the­se models con­si­sted of just 9 dif­fe­rent sym­bols. That means that the ave­ra­ge BPMN model uses less than 20% of the ava­ila­ble voca­bu­la­ry. (Najczęściej uży­wa­ny w mode­lach zestaw pojęć BPMN to 9 sym­bo­li. Oznacza to, że w mode­lach BPMN uży­wa­nych jest nie­ca­łe 20% zde­fi­nio­wa­nych w tej nota­cji pojęć). Polecam dostęp­ny na tych stro­nach wykres.

Można się spo­tkać z poję­ciem trzech pozio­mów mode­lo­wa­nia pro­ce­sów (Bruce Silver blog): war­stwa opi­so­wa, war­stwa mode­li ana­li­tycz­nych, war­stwa mode­li wyko­naw­czych. w zasa­dzie nie odbie­ga to od powyż­sze­go mode­lu jed­nak autor pro­po­nu­je tu w war­stwie pierw­szej (opis) two­rze­nie ogól­nych mode­li z zanie­dba­niem reguł nota­cji. Tu jed­nak nie­ste­ty nara­ża­my się na nie­jed­no­znacz­no­ści. Ja widać nie ja jeden dostrze­gam potrze­bę podzia­łu na pozio­my abs­trak­cji w mode­lo­wa­niu i ana­li­zie. Propozycja Bruce’a Silvera jest jak naj­bar­dziej war­ta naśla­do­wa­nia, z tym jed­nak, że lep­szym pomy­słem jest, moim zda­niem, wybra­nie nota­cji dosto­so­wa­nej do pozio­mu abs­trak­cji, dla­te­go na pozio­mi opi­so­wym (ja jed­nak wole nazwę model biz­ne­so­wy lub łań­cuch war­to­ści, to nada­je kon­kret­ny sens temu mode­lo­wi) sto­su­ję oraz czę­ściej ArchiMate by nie musieć łamać zasad sys­te­mu poję­cio­we­go danej nota­cji (jak sam Bruce Silver przy­znał, wyma­ga to wyłą­cze­nia kon­tro­li popraw­no­ści modelu).

Warstwa archi­tek­tu­ry sys­te­mów IT. Tu w zasa­dzie rów­no­praw­nie moż­na uży­wać ArchiMate i UML (głów­nie dia­gram kom­po­nen­tów i dia­gram wdro­że­nia). Jednak koja­rząc logi­kę biz­ne­so­wą (poziom pro­ce­sów biz­ne­so­wych) z archi­tek­tu­rą apli­ka­cji (sys­tem IT), nale­ży zasto­so­wać jed­ną nota­cję dla obu warstw by zacho­wać spój­ność poję­cio­wą mode­lu, a to daje nam wła­śnie ArchiMate (to są już pro­jek­ty doty­ka­ją­ce” archi­tek­tu­ry korporacyjnej).

Najniżej mamy war­stwę spe­cy­fi­ka­cji sys­te­mu IT, jego struk­tu­rę (albo jak to woli model reali­za­cji sys­te­mu IT). Na tym pozio­mie w uży­ciu nota­cja UML, któ­ra do tego powsta­ła. Jeżeli uznać fakt, że meto­dy struk­tu­ral­ne ode­szły do lamu­sa (nota­cje DFD) a mode­le rela­cyj­nych baz danych są na zbyt niskim, inży­nier­skim pozio­mie (nota­cja ERD), to UML jako język obiek­to­wy, nie ma w tym obsza­rze kon­ku­ren­ta. Poniżej typo­wy zakres (pakie­ty, w nich są loko­wa­ne arte­fak­ty” pro­duk­tu ana­li­zy) moich projektów:

Powyższy dia­gram obra­zu­je struk­tu­rę mode­li (pod spodem odpo­wia­da­ją­ce mu drze­wo kata­lo­gów, dia­gram powyż­szy do dia­gram pakie­tów UML).

Powyższy dia­gram to tak­że podział z per­spek­ty­wy adre­sa­ta doku­men­ta­cji: dla tak zwa­ne­go biz­ne­su adre­so­wa­ne są trzy war­stwy licząc od góry. Dla wyko­naw­ców sys­te­mów ostat­nia: wykonawcza.

Na zakończenie kilka słów o UML

Notacja ta powsta­ła jako uni­wer­sal­na ([[Unified Modeling Language]], Uniwersalny Język Modelowania) jed­nak tu chy­ba auto­rzy tej nota­cji dotknę­li pro­ble­mu coś co jest do wszyst­kie­go jest do nicze­go”. Mimo tego, że z pomo­cą sys­te­mu tak zwa­nych pro­fi­li w UML moż­li­we jest wyra­że­nie w tej nota­cji pojęć każ­dej z pozo­sta­łych wymie­nio­nych, nie jest to dobry pomysł. Mam nadzie­ję, że nie zacho­ru­je na to” [[The Open Group i ArchiMate]] (poja­wi­ła się wspo­mnia­na ArchiMate 2.0).

Dlaczego UML nie powi­nien być uży­wa­ny do wszyst­kie­go? Notacja ta jest ska­żo­na” tak zwa­nym obiek­to­wym para­dyg­ma­tem, bar­dzo trud­nym do przy­swo­je­nia dla osób nie oby­tych z meto­da­mi obiek­to­wy­mi w inży­nie­rii opro­gra­mo­wa­nia. Po dru­gie sys­tem gra­ficz­ny w UML nie uła­twia odbio­ru, per­cep­cji mode­li gdyż więk­szość pojęć jest obra­zo­wa­na pro­sto­ką­tem z róż­ny­mi ety­kie­ta­mi. Zjawisko to (zro­zu­mia­łość gra­ficz­nych sys­te­mów komu­ni­ko­wa­ni tre­ści) opi­su­je nauka jaką jest [[Semiotyka]]. Nie jest to miej­sce na jej opis, jed­nak wyka­zu­je ona, że sto­so­wa­nie np. UML do komu­ni­ko­wa­nia cze­go­kol­wiek ludziom z tak zwa­ne­go biz­ne­su”, nie mają­cym nic wspól­ne­go z obiek­to­wym para­dyg­ma­tem, nie jest dobrym pomy­słem, a doku­men­ty opi­su­ją­ce orga­ni­za­cję w koń­cu mają im służyć.

Semiotyka uczy nas”, że każ­de poję­cie (kon­cept) dla moż­li­wie naj­lep­szej zro­zu­mia­ło­ści dla odbior­cy, powi­nien być repre­zen­to­wa­ny innym zna­kiem (kształ­tem), naj­le­piej koja­rzą­cym się z repre­zen­to­wa­nym zna­cze­niem (co zna­czy ten znak).

Innym razem na kil­ku przy­kła­dach, poka­żę mode­le w ArchiMate…

Agilian nowa wersja. Burza mózgów sformalizowana …

Niedawno napi­sa­łem:

Burze mózgów mają sens, jak naj­bar­dziej, ale w przy­pad­ku zespo­łu spe­cja­li­stów. Jeżeli zacho­dzi ryzy­ko, że jeden spe­cja­li­sta w danej dzie­dzi­nie, będzie pra­co­wał nad uzy­ska­niem roz­wią­za­nia zbyt dłu­go na co nie ma cza­su, zamiast jed­ne­go spe­cja­li­sty ?sadza­my? kil­ku (słyn­na sce­na w Apollo 13). Jest bar­dzo praw­do­po­dob­ne, że któ­ryś z nich wpad­nie na wła­ści­wy pomysł szyb­kiej niż kole­dzy. (Burza mózgów ? home­opa­tia w ana­li­zie).

I pro­szę pisze­my i roz­ma­wia­my o tym, z dru­giej stro­ny mamy for­mal­ne UML, BPMN itp. i jakoś sta­le bra­ku­je łącz­ni­ka”. Z zasa­dy nie rekla­mu­ję opro­gra­mo­wa­nia. Uważam, że jego sprze­da­wa­nie to inna kom­pe­ten­cja. Jednak nie da się ukryć, że jestem użyt­kow­ni­kiem cze­goś”. Czym to jest? Pakiet typu CASE ([[Computer-Aided Software Engineering, Computer-Aided Systems Engineering]]) jakim jest [[Visual-Paradigm Agilian]]. I co my tu mamy? Wczoraj dotarł do mnie upgra­de i… mamy burzę mózgów :):

Narzędzie przy­dat­ne bo mając rzut­nik moż­na spo­koj­nie zarzu­cić tabli­cę i jej fotografowanie :).

Od pew­ne­go już cza­su pakiet ten pozwa­la na two­rze­nie dia­gra­mów [[ArchiMate]]. Notacja ta, to narzę­dzie do mode­lo­wa­nia archi­tek­tu­ry kor­po­ra­cyj­nej. Co to? Ogólnie jest to odpo­wiedź na pyta­nie: jak zarzą­dzać zależ­no­ścia­mi pomię­dzy biz­ne­sem, pro­ce­sa­mi i infra­struk­tu­rą IT. Można np. tak:

Diagram ArchiMate Sprzedaż

Swego cza­su pisa­łem już o mode­lach BMM uży­wa­nych na eta­pie ana­li­zy biz­ne­so­wej i doku­men­to­wa­nia jej efektów:

BMMOvierwiev

Ktoś może zapy­tać po co to wszyst­ko w pakie­cie do ana­li­zy i mode­lo­wa­nia? Bo klu­czo­wym mier­ni­kiem jako­ści ana­li­zy, jej doku­men­ta­cji i mode­li jest spój­ność i pano­wa­nie nad cało­ścią. Jedynym spo­so­bem osią­gnię­cia tego, rela­tyw­nie niskim nakła­dem pra­cy, jest zbio­ro­we, spój­ne zarzą­dza­nie każ­dym ele­men­tem doku­men­ta­cji. Wtedy może­my zwe­ry­fi­ko­wać doku­men­ta­cję i zba­dać wpływ każ­de­go obiek­tu na inne w ramach całej dokumentacji:

Macierz procesu zadnia-role

Można tak­że zbu­do­wać macierz powią­zań pomię­dzy dowol­nie wybra­nym zesta­wem obiek­tów w całej dokumentacji.

To pozwa­la owe kar­tecz­ki powią­zać z mode­la­mi pro­ce­sów i dzie­dzi­ny, spraw­dzić czy potra­fi­my uza­sad­nić każ­dy ele­ment w wyma­ga­niach i wychwy­cić te nie­ob­słu­żo­ne. Do tego ana­li­za ryzyk (ana­li­zy wpły­wu) sta­ja wręcz banal­ne”, bo sta­no­wią po pro­tu raport z tak opra­co­wa­nej doku­men­ta­cji i mode­li. Jeżeli jest ona kom­plet­na i spój­na to mamy te dane na tacy”.

Po co nam CASE?

Bo

Dzięki narzę­dziom CASE pro­jek­ty two­rzy się dokład­niej, a pra­ca nad dia­gra­ma­mi, spraw­dza­nie ich popraw­no­ści oraz śle­dze­nie wyko­na­nych testów jest prost­sze i szyb­sze. (wie­cej: http://​www​.eio​ba​.pl)

Tak więc gorą­co pole­cam sto­so­wa­nie narzę­dzi (lista narzę­dzi CASE). Zaryzykował bym nawet tezę, że brak takich narzę­dzi u ana­li­ty­ka to jak by sto­larz pra­cu­ją­cy wyłącz­nie siekierą…

Epistemologia ? jak pomaga w analizie

Nie raz poja­wia się wątek filo­zo­ficz­ny” w pro­ce­sie ana­li­zy (a kon­kret­nie w roz­mo­wach o niej…;)). Jednym z klu­czo­wych ele­men­tów, celem, każ­dej ana­li­zy jest jej efekt czy­li pozna­nie cze­goś i prze­ka­za­nie tej wie­dzy komuś (naj­czę­ściej zle­ce­nio­daw­cy tej ana­li­zy). Rzecz w tym, że liczy się to czy zle­ce­nio­daw­ca nie tyl­ko otrzy­mał wyni­ki ana­li­zy a tak­że czy je sobie przyswoił…

W kwe­stii ana­li­zy poja­wia się poję­cie epistemologii:

Epistemologia (od gr. ????????, epi­ste­me ? ?wie­dza; umie­jęt­ność, zro­zu­mie­nie?; ?????, logos ? ?nauka; myśl?) teo­ria pozna­nia lub gno­se­olo­gia ? dział filo­zo­fii, zaj­mu­ją­cy się rela­cja­mi mię­dzy pozna­wa­niem, pozna­niem a rze­czy­wi­sto­ścią. Epistemologia roz­wa­ża natu­rę takich pojęć jak: praw­da, prze­ko­na­nie, sąd, spo­strze­ga­nie, wie­dza czy uza­sad­nie­nie. (za Epistemologia ? Wikipedia, wol­na ency­klo­pe­dia).

Kluczowe poję­cia to spo­strze­ga­nie (zbie­ra­nie infor­ma­cji) oraz rze­czy­wi­stość, czy­li umie­jęt­ność opi­sa­nia tego-co-ma-miej­sce. Całość to wie­dza o czymś (ana­li­zo­wa­nym przed­mio­cie). Dlaczego o tym piszę? Bardzo czę­sto spo­ty­kam się z wyni­ka­mi ana­li­zy sta­no­wią­cy­mi tyl­ko zapis tego-co-zoba­czo­no i tego-co-usły­sza­no. Nazywam to ana­li­za dyk­ta­fo­nem”. Sam zapis zebra­nych infor­ma­cji nie jest żad­na ana­li­zą, tak­że upo­rząd­ko­wa­nie zebra­nych danych w okre­ślo­ne struk­tu­ry tak­że nie jest ana­li­zą. To dopie­ro kolek­cjo­no­wa­nie danych.

Teraz pora na sto­so­wa­nie sfor­ma­li­zo­wa­nych mode­li poję­cio­wych. Należą do nich for­mal­ne nota­cje np. BPMN, UML, BMM czy ArchiMate. Analiza to nie tyl­ko zebra­nie danych ale tak­że ich poszu­flad­ko­wa­nie, zakwa­li­fi­ko­wa­nie każ­dej infor­ma­cji o czymś do skoń­czo­nej licz­by pojęć dane­go sys­te­mu poję­cio­we­go (nota­cji).

Przyjmując, że dany sys­tem poję­cio­wy jest kom­plet­ny (pozwa­la na zapi­sa­nie każ­dej infor­ma­cji z danej dzie­dzi­ny), ana­li­za pole­ga tu na roz­ło­że­niu tek­stu (danych) pozy­ska­nych np. z wywia­dów czy doku­men­tów, na skoń­czo­ną licz­bę pojęć i związ­ków pomię­dzy nimi. W efek­cie uzy­sku­je­my np. dia­gram pro­ce­su BPMN (jeże­li celem był model pro­ce­su biz­ne­so­we­go) lub dia­gram klas UML (jeże­li celem była np. ana­li­za poję­cio­wa i zbu­do­wa­nie taksonomii).

Tu doty­ka­my pro­ce­su komu­ni­ka­cji, czy­li prze­ka­za­nia pozy­ska­nej wie­dzy i wyni­ków ana­li­zy innej oso­bie. Przekaz nara­żo­ny jest zakłó­ce­nia (szum w kana­le infor­ma­cyj­nym) oraz błę­dy kodo­wa­nia i dekodowania.

Kodem jest wła­śnie sys­tem poję­cio­wy (nota­cja). Tak więc np. każ­de odstęp­stwo od reguł sto­so­wa­nia danej nota­cji to dro­ga w kie­run­ku pogor­sze­nia jako­ści (sku­tecz­no­ści) przekazu.

Więcej innym razem 😉

Plan rozwojowy - diagram BMM

Większa elastyczność i lepsza obsługa klienta na szczycie listy życzeń użytkowników systemów ERP

Sille Gavnholt Jygert, Konsultant i Kierownik Programów w fir­mie ana­li­tycz­nej Frost & Sullivan, potwier­dza: ?Jeżeli cho­dzi o wdro­że­nia sys­te­mów ERP, coraz więk­sze­go zna­cze­nia nabie­ra efek­tyw­ność, a nie kosz­ty; teraz cho­dzi bar­dziej o wyko­ny­wa­nie wła­ści­wych dzia­łań we wła­ści­wy spo­sób. Często ozna­cza to potrze­bę więk­szej ela­stycz­no­ści we wdro­że­niu i wyko­rzy­sta­niu sys­te­mu ERP. Uważamy, że ist­nie­ją trzy głów­ne obsza­ry, w któ­rych użyt­kow­ni­cy mogą odnieść korzy­ści ze zwięk­sze­nia ela­stycz­no­ści sys­te­mów ERP:

  1. Większa kon­cen­tra­cja na pro­ce­sach i zmia­nach, któ­re sys­tem ERP ma wspierać.
  2. Nowe mode­le usług wdro­że­nio­wych i wspar­cia: coraz czę­ściej dostaw­cy będą musie­li zapew­niać wspar­cie dla kon­kret­nych pro­ble­mów biz­ne­so­wych, a nie dla okre­ślo­nych tech­no­lo­gii, aby móc dzia­łać w coraz szyb­ciej zmie­nia­ją­cym się środowisku.
  3. Obsługa klien­tów: poja­wią się nowe mode­le pozwa­la­ją­ce reali­zo­wać pro­ces biz­ne­so­wy i sil­niej anga­żo­wać użyt­kow­ni­ków, poma­ga­jąc im przez to efek­tyw­niej wyko­rzy­sty­wać sys­tem w roz­wią­zy­wa­niu pro­ble­mów biznesowych.

Według Jamesa Greavesa, Dyrektora ds. IT w fir­mie pro­jek­to­wej Portsmouth Aviation, zdol­ność zacho­wa­nia ela­stycz­no­ści i reago­wa­nia na zmie­nia­ją­ce się wyzwa­nia biz­ne­so­we to jeden z klu­czo­wych atry­bu­tów poszu­ki­wa­nych u dostaw­ców i w sys­te­mach ERP. (źr. Większa ela­stycz­ność i lep­sza obsłu­ga klien­ta na szczy­cie listy życzeń użyt­kow­ni­ków sys­te­mów ERP).

Jeśli potrak­to­wać powyż­sze jako znak cza­su”, to ma to duże znacz­nie jako wpływ na spo­so­by i meto­dy pro­wa­dze­nia ana­liz wyma­gań i oce­ny potrzeb – narzu­ca duże wyma­ga­nia na jej jakość.

System ERP to przede wszyst­kim narzę­dzie. Jeżeli wdra­ża­my je, to z myślą o kon­kret­nych korzy­ściach. Popatrzmy na nie w kon­tek­ście warun­ków uzy­ska­nia powyż­szych korzyści:

Ad. 1. Nowe narzę­dzia IT wdra­ża­ne są (powin­ny) jako odpo­wiedź na potrze­bę nowych zaso­bów. Ta potrze­ba powin­na być uza­sad­nio­na biz­ne­so­wo. Praktyka poka­zu­je, że naj­efek­tyw­niej­sze wdro­że­nia to efekt zmian zapla­no­wa­nych jako ele­ment reali­za­cji nowej stra­te­gii fir­my. To z regu­ły nowe lub zmie­nio­ne pro­ce­sy biz­ne­so­we i mode­le biznesowe.

Ad.2. Tu nasu­wa się tyl­ko jed­no: ana­li­za sys­te­mo­wa i model usłu­go­wy sys­te­mu, nie tyle SOA jako [[Service Oriented Architecture]] ale tak­że jako poprze­dza­ją­ca to [[Service Oriented Analysis]]. Zidentyfikowany pro­blem biz­ne­so­wy na eta­pie ana­li­zy wyma­gań zamie­nia się (powi­nien) w wyma­ga­nie w spe­cy­fi­ka­cji wyma­gań na system.

Ad.3. Modele biz­ne­so­we zmie­rza­ją w kie­run­ku uczy­nie­nia klien­ta udzia­łow­cem, pro­gra­my lojal­no­ścio­we to pro­wa­dze­nie do tego, by klient czuł się zwią­za­ny z dostaw­cą, by czuł, że kupu­jąc utrzy­mu­je go, sta­je się źró­dłem gwa­ran­cji jego dal­sze­go ist­nie­nia. Przyczynia się do tego by ulu­bio­na mar­ka zacho­wa­ła się na ryn­ku. Tu wkra­cza­my w ele­men­ty pro­ce­sów biz­ne­so­wych powią­za­nych z sys­te­ma­mi CRM.

Nie da się tu, za mało miej­sca, opi­sać cało­ści szcze­gó­łów tych zagad­nień, mogę co naj­wy­żej wska­zać jak moż­na gryźć” pro­blem. A pro­blem tkwi w zło­żo­no­ści współ­ist­nie­nia: pro­ce­dur, ludzi, uży­wa­ne­go opro­gra­mo­wa­nia, pla­nów biz­ne­so­wych i mar­ke­tin­go­wych itp. Złożoność ta jest trud­na do ogar­nię­cia umy­słem czło­wie­ka, samo zapi­sa­nie w posta­ci tek­stu memo­ria­łu Tak będzie­my to robić” to sta­now­czo za mało. Dlaczego? Bo istot­ne jest nie tyl­ko to ile ele­men­tów wcho­dzi w skład pro­ble­mu” a to jak są ze sobą powią­za­ne oraz co i na co ma wpływ. Zrozumienie tkwi nie w tym, że wiem ile w lesie jest drzew i wil­ków a w tym, że wiem dla­cze­go i kie­dy wil­ki się cho­wa­ją za drze­wa­mi. Dlatego spis z inwen­ta­rza nie pomaga.

Poniżej dia­gram (a raczej jego namiast­ka) poka­zu­ją­cy jak opi­sać model poka­zu­ją­cy te oddzia­ły­wa­nia i wpływy:

Plan rozwojowy - diagram BMM
Plan roz­wo­jo­wy – dia­gram BMM

Celem takich dia­gra­mów nie jest tyl­ko two­rze­nie obraz­ków. To narzę­dzie ana­li­zy, któ­re zmu­sza do zada­wa­nia wła­ści­wych pytań, wła­ści­wym oso­bom. Jako, że model BMM sta­no­wi kom­plet­ny sys­tem poję­cio­wy a przy oka­zji tak­że ma swo­ją sym­bo­licz­ną wer­sje (nota­cja), pozwa­la two­rzyć nie­skom­pli­ko­wa­ne dia­gra­my i sku­pić się na tym co waż­ne a po dru­gie poka­zać sys­tem w spo­sób łatwy do wery­fi­ka­cji i zro­zu­mie­nia. Stworzenie spój­ne­go tek­stu na pod­sta­wie takie­go dia­gra­mu jest już łatwe, w dru­gą stro­nę to nie­ste­ty nie dzia­ła (łatwo jest słow­nie opi­sać skom­pli­ko­wa­ną tra­sę wyciecz­ki mając plan mia­sta w rękach, zro­bie­nie tego na bazie wyobraź­ni jest dużo trud­niej­sze, dla­te­go jed­nak war­to posia­dać mapę).

Powyższy dia­gram, model moty­wa­cji, tu two­rzo­ny jest w kon­tek­ście pro­jek­tu. Dlatego tu nie opi­su­je całej fir­my a jedy­nie zwią­za­ne z celem ele­men­ty. Cele jest reali­za­cja kon­kret­nej wizji.

Nowa specyfikacja Business Motivation Model v.1.1 i modelowanie biznesu

Na stro­nach http://​www​.omg​.org/ poja­wi­ła się nowa spe­cy­fi­ka­cja nota­cji [[Business Motivation Model]] (BMM) (źr. BMM.) Notacja ta powsta­ła w celu umoż­li­wie­nia for­mal­ne­go mode­lo­wa­nia biz­ne­spla­nów, a kon­kret­nie mode­li biz­ne­so­wych. Notacja powsta­ła z ini­cja­ty­wy [[Business Rules Group]] (http://​www​.busi​nessru​les​gro​up​.org/​h​o​m​e​-​b​r​g​.​s​h​tml). Manifest tej orga­ni­za­cji zawie­ra tak zwa­ne Zasady Autonomii Reguł (tu w języ­ku pol­skim: http://​www​.busi​nessru​les​gro​up​.org/​b​r​m​a​n​i​f​e​s​t​o​/​B​R​M​a​n​i​f​e​s​t​o​P​L​.​pdf).

BMM ujmu­je wyma­ga­nia biz­ne­so­we w róż­nych wymia­rach, w celu uza­sad­nie­nia dla­cze­go biz­nes chce coś robić, do cze­go dąży, jak zamie­rza to osią­gnąć oraz jak oce­nia rezultaty.”

Po co nowa notacja?

Swego cza­su (rok 2006) pisa­łem o mode­lach biz­ne­so­wych w kon­tek­ście stra­te­gii ryn­ko­wej w arty­ku­le Model biz­ne­so­wy – co to za zwie­rze. Wtedy pisa­łem o tym, że stra­te­gia ma zna­cze­nie i wie­le tłu­ma­czy. Wtedy tak­że dotkną­łem pro­ble­mu słow­nic­twa i sys­te­mu pojęć. Samo zde­fi­nio­wa­nie stra­te­gii nie jest pro­ste, zde­fi­nio­wa­nie poję­cia stra­te­gii zmia­ny jest jesz­cze więk­szym wyzwaniem.

Obszar biz­ne­so­wy jest bar­dzo ubo­gi w [[meto­dy for­mal­ne]]: for­mal­ne nota­cje, sfor­ma­li­zo­wa­ne języ­ki opi­su. W zasa­dzie dys­po­nu­je­my tyl­ko [[nota­cją BPMN]] (mode­le pro­ce­so­we i mode­le współ­pra­cy pro­ce­sów) oraz [[nota­cją ArchiMate]] (mode­le archi­tek­tu­ry kor­po­ra­cyj­nej). [[Notacja eEPC]], koja­rzo­na głów­nie z [[narzę­dziem ARIS]] i fir­mą ISD Scherr odcho­dzi powo­li do histo­rii, o nota­cjach nie­stan­dar­do­wych nawet nie piszę bo od daw­na idą w zapomnienie.

Dla odmia­ny, w sze­ro­ko poję­tej dzie­dzi­nie inży­nie­rii opro­gra­mo­wa­nia, mamy [[nota­cje obiek­to­wą UML]] i jej trzy­na­ście typów dia­gra­mów, mamy nadal uży­wa­ne, zna­ne z ana­li­zy struk­tu­ral­nej nota­cje [[ERD]] i [[DFD]].

[[Notacja BMM]] uzu­peł­nia biz­ne­so­wy sys­tem nota­cyj­ny o obszar poję­cio­wy mode­li biz­ne­so­wych i biz­ne­spla­nów. Pozwala w spo­sób for­mal­ny je opi­sać. [[Przestrzeń nazw]], pod­sta­wo­we poję­cia opi­sa­ne w BMM:

  1. Ends (stan ocze­ki­wa­ny) iden­ty­fi­ku­ją cechy opi­su­ją­ce źró­dła moty­wa­cji (cele) two­rze­nia biznesplanu,
  2. Means (środ­ki) iden­ty­fi­ku­ją narzę­dzia i środ­ki jakich pla­nu­je­my użyć by dopro­wa­dzić do ocze­ki­wa­ne­go (pla­no­wa­ne­go) stanu.
  3. Assessement (uwa­run­ko­wa­nia, ogra­ni­cze­nia) iden­ty­fi­ku­ją wie­dzę o warun­kach pro­jek­tu (w szcze­gól­no­ści ana­li­za SWOT)
  4. Influence (wpływ) iden­ty­fi­ku­ją pozna­ne czyn­ni­ki mogą­ce mieć (mają­ce) wpływ na osią­gnie­cie celu,
  5. Organisation (orga­ni­za­cja) iden­ty­fi­ku­je zaso­by i pro­ce­sy zaan­ga­żo­wa­ne w osią­gnię­cie celu
Całość sta­no­wi rodzaj listy kon­tro­l­nej” zro­zu­mie­nia posta­wio­ne­go pro­ble­mu, jakim jest pro­jekt biz­ne­so­wy, pozwa­la upew­nić się, że zna­my i rozu­mie­my to co ma na nie­go wpływ:
Business Motivation Model (źr. wiki)

Notacja zawie­ra tak­że ele­men­ty ste­ru­ją­ce biz­ne­sem takie jak [[regu­ły biz­ne­so­we]] i zasa­dy zarzą­dza­nia. Zestaw pojęć defi­niu­ją­cych ele­men­ty biz­ne­spla­nów, cechu­je się neu­tral­no­ścią meto­do­lo­gicz­ną oraz pozwa­la jed­no­znacz­nie opi­sać nasza wie­dzę o pro­jek­cie. Oznacza to, że słow­nik pojęć nie jest dedy­ko­wa­ny żad­nej kon­kret­nej meto­dy­ce, a jest jedy­nie for­mal­nym słow­ni­kiem ([[seman­tycz­na prze­strze­nią nazw]]). Powyższe poję­cia są wywie­dzio­ne z zasad­ni­czych pojęć z dzie­dzi­ny mode­lo­wa­nia pro­ce­sów: pro­ces biz­ne­so­wy, regu­ła biz­ne­so­wa, jed­nost­ka orga­ni­za­cyj­na. Bazują one odpo­wied­nio na spe­cy­fi­ka­cjach: BPMN (nota­cja [[OMG Business Process Modeling Notation]]), spe­cy­fi­ka­cji [[OMG Semantics of Business Vocabulary and Business Rules]], oraz RFP [[OMG Organization Structure Metamodel]]. Oznacza to, że nota­cja BMM nie zastę­pu­je ich, a jest dla nich nad­rzęd­na abs­trak­cją. Tak więc pro­ces, jako poje­dyn­cze poję­cie na dia­gra­mie BMM, może zostać szcze­gó­ło­wo opi­sa­ny (model) na innym dia­gra­mie (doku­men­cie), jed­nak defi­ni­cja poję­cia pro­ces biz­ne­so­wy jest taka sama w obu nota­cjach (pro­ces biz­ne­so­wy zawsze musi zna­czyć to samo!).

Poniżej ogól­ny widok pojęć opi­sy­wa­nych nota­cją BMM:

przy­kład two­rze­nia dia­gra­my (klik­nij), oraz model seman­ty­ki i syntaktyki:

BMM nie jest żad­nym narzę­dziem ani meto­dy­ką zarzą­dza­nia czy mode­lo­wa­nia pro­ce­so­we­go, zarzą­dza­nia pro­jek­ta­mi ani spe­cy­fi­ka­cją wzor­co­we­go mode­lu biz­ne­so­we­go. To nota­cja, któ­ra sta­no­wi sobą dobrze zde­fi­nio­wa­ny słow­nik poję­cio­wy (seman­ty­kę) oraz związ­ki pomię­dzy tymi poję­cia­mi (syn­tak­ty­kę, pamię­taj­my, że połą­czo­ne poję­cia nabie­ra­ją kolej­ne­go nowe­go zna­cze­nia, np. kil­ka sko­ja­rzo­nych osób ozna­cza zespół, oso­ba to pro­ste poję­cie, oso­by połą­czo­ne jakimś związ­kiem to grupa).

Wśród wie­lu orę­dow­ni­ków nota­cji UML domi­nu­je teza, że owo Unified (Uniwersalna) w skró­cie UML czy­ni tę nota­cję zdol­ną do mode­lo­wa­nia wszyst­kie­go, jej kolej­ne zasto­so­wa­nia i roz­sze­rze­nia moż­na same­mu opra­co­wać w posta­ci tak zwa­ne­go [[pro­fi­lu UML]]. Owszem, w zasa­dzie teza ta jest praw­dzi­wa jed­nak jest pew­ne ale. Po pierw­sze taki pro­fil to prak­tycz­nie nowa nota­cja: nowe poję­cia (seman­ty­ka) i zasa­dy (syn­tak­ty­ka). Te wyma­ga­ją od stro­ny for­mal­nej wyka­za­nia, że poję­cia (obra­zo­wa­ne z pomo­cą sym­bo­li, zna­ków nota­cji) są roz­łącz­ne, i że seman­tycz­nie (zna­cze­nia­mi) pokry­wa­ją całą mode­lo­wa­ną dzie­dzi­nę. Zapewnienie tego nie jest try­wial­nym problemem.

Tak więc nie tak zno­wu nowa, nota­cja BMM jest przy­dat­na, a dla wie­lu sto­su­ją­cych [[meto­dy for­mal­ne ana­li­zy sys­te­mo­wej]] w tym mode­lo­wa­nie, wręcz potrzeb­na. Nie bra­ku­je gło­sów kry­tycz­nych na temat BMM (np. na blo­gu MSDN), jed­nak oso­bi­ście pod­kre­ślam: nota­cja to nie spo­sób na ana­li­zę a jej narzę­dzie. Notacja nie ma roz­wią­zy­wać wszyst­kich pro­ble­mów, to nie jest srebr­na kula (ang. [[silver bul­let solu­tion]]), któ­rej nie­ste­ty wie­lu nadal szu­ka. Notacja ma poma­gać w roz­wią­zy­wa­niu pro­ble­mów, a to ogrom­na różnica.

Jeżeli kogoś inte­re­su­je nie­co wię­cej szcze­gó­łów o nota­cjach i ich two­rze­niu zapra­szam do dal­szej lektury.

Po co trud­ne” nota­cje sko­ro moż­na pisać po ludzku”

Czy nota­cje mają za cel zastą­pie­nie popu­lar­nej pro­zy? Absolutnie nie! Notacje słu­żą do budo­wy mode­li, któ­re testu­je­my, wery­fi­ku­je, wali­du­je­my. To tak jak z naszym miesz­ka­niem: może­my je w dowol­ny spo­sób opi­sać, mniej lub naj­bar­dziej kwie­ci­stym języ­kiem. Jednak dobry archi­tekt zawsze, nawet na wła­sny uży­tek, stwo­rzy zestaw rysun­ków i wizu­ali­za­cji, by upew­nić się że o niczym nie zapo­mniał. Z pro­jek­tu tech­nicz­ne­go dopie­ro stwo­rzy ład­nie opi­sa­ną pro­zą (języ­kiem natu­ral­nym, zro­zu­mia­łym dla każ­de­go) listę czę­ści i pod­ze­spo­łów, jed­nak ryzy­ko, że tak stwo­rzo­na spe­cy­fi­ka­cja będzie nie­kom­plet­ne teraz jest minimalne.

Zapewne wie­lu z Państwa było w skle­pie IKEA po meble, być może ktoś z Państwa sam je mon­to­wał. Liczba ele­men­tów, łączeń, paso­wań, łącz­ni­ków itp. jest ogrom­na już w śred­niej wiel­ko­ści zesta­wie mebli kuchen­nych. Czy wyobra­ża­cie sobie Państwo zapro­jek­to­wa­nie takich mebli bez spraw­dze­nia na rysun­kach tech­nicz­nych czy nicze­go nie bra­ku­je i czy wszyst­ko do sie­bie pasu­je? A teraz wyobraź­cie sobie Państwo, że więk­szość firm w któ­rych pra­cu­je­cie jest dale­ko bar­dziej skom­pli­ko­wa­na, a mimo to wie­lu ana­li­ty­ków podej­mu­je pró­by opi­sa­nia ich pro­sty­mi sło­wa­mi… jest to nie­mal­że nie­moż­li­we bez popeł­nie­nia wie­lu błędów.

Czym są formalne notacje

Swego cza­su napi­sa­łem w arty­ku­le o nota­cjach i modelowaniu:

Jednym z tych [pod­sta­wo­wych w sto­sun­ku do mode­li i uży­wa­nych w nich nota­cji] wyma­gań jest spój­ny i peł­ny model poję­cio­wy. Tak zwa­na prze­strzeń nazw (w nota­cji jest to lista sym­bo­li i defi­ni­cje ich zna­czeń) powin­na być ?wypeł­nio­na? defi­ni­cja­mi cał­ko­wi­cie, zaś obsza­ry defi­nio­wa­nych pojęć nie mogą na sie­bie nacho­dzić. (źr. Modelowanie pro­ce­sów biz­ne­so­wych).

Nieco bli­żej o tym. Notacja to model poję­cio­wy, zestaw sym­bo­li i ich zna­czeń (seman­ty­ka) oraz gra­ma­ty­ka łącze­nia tych pojęć (tak zwa­na syn­tak­ty­ka czy­li dopusz­czal­ne związ­ki pomię­dzy poję­cia­mi i ich zna­cze­nia). W czym pro­blem? Poniżej dia­gram go obrazujący.

Slajd10

Zestaw wszyst­kich słów-sym­bo­li to lista dopusz­czal­nych w mode­lu (opi­sie) pojęć i jest to wła­śnie tak zwa­na seman­ty­ka nota­cji (prze­strzeń nazw). Koło ozna­cza wybra­ną dzie­dzi­nę (np. mode­le biz­ne­so­we i biz­ne­spla­ny). Kółeczka z krzy­ży­ka­mi to poję­cia (obra­zo­wa­ne w nota­cjach sym­bo­la­mi, iko­na­mi nota­cji), dopusz­czal­ne sło­wa ze słow­ni­ka, któ­re­go chce­my użyć do opi­sa­nia cze­goś w danej dzie­dzi­nie (zwa­nej tak­że domeną).

Po lewej stro­nie mamy namiast­kę nie­for­mal­ne­go, potocz­ne­go języ­ka: to co widzi­my, poję­cia, byty czy­li krzy­ży­ki oraz sło­wa pozwa­la­ją­ce na ich nazwa­nie (ciem­niej­sze obsza­ry). Język potocz­ny cha­rak­te­ry­zu­je się tym, że zawie­ra sło­wa okre­śla­ją­ce róż­ne poję­cia (dwa krzy­ży­ki w jed­nym polu zna­cze­nio­wym, np. zamek to budow­la ale tak­że mecha­nizm zamknię­cia drzwi), poja­wia­ją się róż­ne sło­wa na jed­no zna­cze­nie (krzy­żyk nale­żą­cy do dwóch róż­nych obsza­rów, np. gar­nek i saga­nek to nie raz to samo naczy­nie). Pojawiają się tak­że byty nie mają­ce ozna­cza­ją­cych je słów (w danym języ­ku oczy­wi­ście, krzy­żyk nie przy­po­rząd­ko­wa­ny do żad­ne­go pola, np. inter­fejs, któ­ry nie ma swo­je­go odpo­wied­ni­ka w języ­ku pol­skim, uży­wa­my sło­wa angielskiego).

Taka sytu­acja, opi­sa­ne nie­jed­no­znacz­no­ści, powo­du­je, że typo­wy prze­kaz tek­sto­wy jest prze­ka­zem nie­jed­no­znacz­nym: czy­ta­ją­cy może odczy­tać z tek­stu coś inne­go niż to co miał na myśli jego autor. Nie da się go, takie­go tek­stu, zwe­ry­fi­ko­wać od stro­ny spój­no­ści i kom­plet­no­ści opi­sy­wa­nej rzeczywistości.

Po pra­wej stro­nie mamy sytu­ację ide­al­ną: pojęć jest dokład­nie tyle ile zna­czeń (słów), każ­de poję­cie ma tyl­ko jed­no zna­cze­nie zaś tak zwa­na prze­strzeń nazw (obszar, do któ­re­go nale­żą, miesz­czą­cy wszyst­kie poję­cia danej dzie­dzi­ny) jest zupeł­nie opi­sa­ny (brak obsza­ru, zna­cze­nia, nie obję­te­go zadnym sło­wem). Opisanie cze­goś języ­kiem” (sło­wa­mi) z takiej prze­strze­ni nazw czy­ni prze­kaz jed­no­znacz­ny w 100% (nie ist­nie­ją w danej prze­strze­ni syno­ni­my i nie ma pojęć nie­zde­fi­nio­wa­nych). Jak być może nie trud­no się domy­śleć, opra­co­wa­nie sys­te­mu poję­cio­we­go speł­nia­ją­ce­go powyż­sze wyma­ga­nia, nie jest łatwe.

Dobra nota­cja ma jesz­cze jed­ną istot­ną cechę: sym­bo­le obra­zu­ją­ce poszcze­gól­ne poję­cia powin­ny się z nimi koja­rzyć nie­za­leż­nie od języ­ka natu­ral­ne­go. To nazy­wa­my [[semio­ty­ką]]. Jest to nauka o tym jak czło­wiek postrze­ga (rozu­mie, odbie­ra) poszcze­gól­ne zna­ki gra­ficz­ne (sym­bo­le, iko­ny). To tak­że powo­du­je, że dąży się do stan­da­ry­za­cji czy­li nie mno­że­nia nad­mia­ru sys­te­mów nota­cyj­nych (patrz [[brzy­twa Ockhama]]). To dla­te­go two­rze­nie wła­snych nota­cji jest trosz­kę pozba­wio­ne sen­su: jest bar­dzo trud­ne i odda­la nas od standardów.

Na zakończenie

Stosowanie ana­li­zy sys­te­mo­wej, mode­lo­wa­nia oraz for­mal­nych nota­cji do two­rze­nia mode­li, powo­du­je, że wyni­ki ana­liz są dale­ko bar­dziej wia­ry­god­ne. Z regu­ły celem pra­cy ana­li­ty­ka biz­ne­so­we­go czy pro­jek­tan­ta jest opra­co­wa­nie opi­su reko­men­do­wa­ne­go roz­wią­za­nia. Może nim być doce­lo­wy model orga­ni­za­cji czy też opis opro­gra­mo­wa­nia jakie nale­ży dostar­czyć (bo nie zawsze wytwo­rzyć!). W pro­ce­sie for­mal­nej ana­li­zy sys­te­mo­wej (nie jest to ana­li­za sys­te­mu infor­ma­tycz­ne­go, to ana­li­za dowol­ne­go sys­te­mu), powsta­ją mode­le, któ­re testujemy.

Taki model to naj­pierw hipo­te­za, a po wery­fi­ka­cji, jest to opis roz­wią­za­nia (pro­jekt tego co ma powstać). Idealną sytu­acją była by taka, a któ­rej mamy narzę­dzia do mode­lo­wa­nia każ­dej ana­li­zo­wa­nej dzie­dzi­ny. W kla­sycz­nej inży­nie­rii jest to rysu­nek tech­nicz­ny i zasa­dy obli­cza­nia wytrzy­ma­ło­ści, sfor­ma­li­zo­wa­ny sys­tem two­rze­nia sche­ma­tów elek­trycz­nych i elek­tro­nicz­nych i wie­le innych (zależ­nie od dzie­dzi­ny), nota­cje UML w inży­nie­rii opro­gra­mo­wa­nia. W sfe­rze zarzą­dza­nia mie­li­śmy do nie­daw­na bia­ła pla­mę, teraz mamy już BMM czy ArchiMate.

Moim zda­niem utrzy­my­wa­nie, że moż­na coś sku­tecz­nie ana­li­zo­wać meto­da­mi nie­for­mal­ny­mi świad­czy raczej o nie­wie­dzy i bra­ku kom­pe­ten­cji. Bo jak ina­czej nazwać nara­ża­nie adre­sa­ta pro­jek­tu (nie raz klien­ta) na masę nie­spój­no­ści owo­cu­ją­cych lawi­no­wo rosną­cy­mi kosz­ta­mi reago­wa­nia na nie­prze­wi­dzia­ne szcze­gó­ły? Nie raz sły­sza­łem, że to trud­ne, tyl­ko dla jajo­gło­wych, kosz­tow­ne. Owszem, ale nie zapo­mi­naj­my, że ana­li­za to nie coś co każ­dy sobie sam może zro­bić. Dobra ana­li­za nigdy nie jest kosz­tow­niej­sza niż poten­cjal­ne, ryzy­ko­wa­ne stra­ty – opła­ci się zawsze.

Prezentacja opi­su­ją­ca klu­czo­we ele­men­ty nota­cji BMM

Przykład uży­cia nota­cji BMM: spo­sób mode­lo­wa­nia.

Skrócony opis – klu­czo­we pojęcia.