Wstęp

KLuczową ich wadą jest

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 (z tej nota­cji póź­niej zre­zy­gno­wa­łem z uwa­gi na jej nie­jed­no­znacz­ność i wpro­wa­dzo­ne licen­cjo­no­wa­nie), BMM, BPMN, UML.

Organizacji się nie opisuje”, organizacje się modeluje

Każda orga­ni­za­cja to bar­dzo zło­żo­ny orga­nizm. Stopień zło­żo­no­ści jest duży, szcze­gól­nie gdy wziąć pod uwa­gę fakt, że nie­jed­na zatrud­nia set­ki pra­cow­ni­ków, two­rzy tysią­ce doku­men­tów, obsłu­gu­je tysią­ce 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?

Ich mode­le to okre­ślo­ne ide­ali­za­cje, pozwa­la­ją­ce zro­zu­mieć spo­sób ich 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…

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma jeden komentarz

  1. Jarek Żeliński

    Z uwa­gi na dzia­ła­nia The Open Group zmie­rza­ją­ce do obło­że­nia ArchiMate opła­ta­mi licen­cyj­ny­mi podob­nie jak TOGAF, prze­sta­je korzyt­sać z tego sys­te­mu poję­cio­we­go. Dodatkową, nara­sta­ją­ca wadą tej nota­cji jest jej rosną­ca nie­spój­ność z doko­na­nia­mi OMG.

Dodaj komentarz

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