Model to mechanizm

Wstęp

Niedawno pisa­łem o regu­łach biz­ne­so­wych i poli­ty­kach postę­po­wa­nia w zarządzaniu:

…zamiast brać na sie­bie, jako pre­zes fir­my, mene­dżer śred­nie­go szcze­bla itd. ogrom zda­rzeń w posta­ci podej­mo­wa­nia decy­zji za każ­dym razem, gdy jest taka wyma­ga­na, moż­na stwo­rzyć sys­tem poli­tyk, zesta­wów reguł biz­ne­so­wych, skut­kiem cze­go fir­ma będzie spraw­nie funk­cjo­no­wa­ła nie anga­żu­jąc, nawet do bar­dzo try­wial­nych zadań, wyso­kich ran­gą pra­cow­ni­ków. Nie jest to dele­go­wa­nie upraw­nień, poli­ty­ki i regu­ły biz­ne­so­we to rodzaj z góry pod­ję­tych decy­zji. Owszem żad­nej fir­my nie da się zal­go­ryt­mi­zo­wać, dla­te­go zawsze wyż­sze kadry będą potrzeb­ne jed­nak ich klu­czo­wą rolą jest usta­la­nie zasad i zarzą­dza­nie nimi a bez­po­śred­nie reago­wa­nie powin­no doty­czyć tego ?nie­zal­go­ryt­mi­zo­wa­ne­go? zakre­su zda­rzeń (op. 20% :), regu­ła Pareto). Zarządzanie zorien­to­wa­ne na regu­ły biz­ne­so­we to wła­śnie takie podej­ście: to cze­go moż­na się spo­dzie­wać, opi­su­je­my regu­ła­mi, zda­rze­nia wyjąt­ko­we obsłu­gu­je­my oso­bi­ście. Reguły biz­ne­so­we war­to zebrać w jed­no miej­sce, ?wyjąć? je z prze­ro­śnię­tych opi­sów zakre­sów obo­wiąz­ków i kom­pe­ten­cji, upo­rząd­ko­wać zarzą­dze­nia zarzą­du. (Reguły biz­ne­so­we i poli­ty­ki jako mecha­nizm dzia­ła­nia orga­ni­za­cji | | Jarosław Żeliński IT-Consulting)

W powyż­szym cyta­cie wytłu­ści­łem klucz dzi­siej­sze­go wpi­su: mecha­nizm (ale nie ma tego sło­wa w powyż­szym cytacie).

Czytaj dalej… Model to mecha­nizm”

Analiza procesowa a obiektowa czyli niedopasowanie oporu

Swego cza­su w arty­ku­le o Wścipskim Analityku uza­sad­nia­łem potrze­bę pano­wa­nia nad wyma­ga­nia­mi od momen­tu poja­wie­nia się potrze­by biz­ne­so­wej aż do jej imple­men­ta­cji. Nie zna­czy to abso­lut­nie, że ana­li­tyk ma pro­gra­mo­wać, zna­czy to jed­nak, że ana­li­tyk powi­nien doku­men­to­wać to cze­go żąda w wyma­ga­niach a potem nad­zo­ro­wać realizację.

Developerzy uzur­pu­ją sobie pra­wa do wszyst­kie­go co wią­że się z imple­men­ta­cją. Z jed­nej stro­ny czę­sto żąda­ją szcze­gó­ło­wych danych np. o danych z dru­giej stro­ny sami chcą opi­sać ich logi­kę biz­ne­so­wą (tak, bo dane biz­ne­so­we to logi­ka biz­ne­so­wa a nie tech­no­lo­gia). Do tego bar­dzo wie­lu deve­lo­pe­rów sto­su­je meto­dy pra­cy rodem z przed kil­ku­na­stu lat… We wspo­mnia­nym wyżej arty­ku­le napi­sa­łem mię­dzy inny­mi o tak zwa­nym para­dyg­ma­cie obiek­to­wym i wie­dzy o nim u deve­lo­pe­rów, szu­kam hasła ana­li­za pro­ce­so­wa” i para­dyg­mat obiektowy”:

Tradycyjnie idzie­my do WIKI:

Przepraszamy, ale nie ma jesz­cze arty­ku­łu ?Analiza pro­ce­so­wa? w Wikipedii. (24 Maj 2011)

No cóż, szu­ka­my dalej:

Process ana­ly­sis pre­sents a chro­no­lo­gi­cal sequ­en­ce of steps that expla­in how some­thing is done, how some­thing hap­pens, or how readers can do some­thing. (źr. http://​www​.tcc​.edu/​s​t​u​d​e​n​t​s​/​r​e​s​o​u​r​c​e​s​/​w​r​i​t​c​e​n​t​/​h​a​n​d​o​u​t​s​/​w​r​i​t​i​n​g​/​p​r​o​c​e​s​s​.​htm).

Coś mamy: ana­li­za pro­ce­so­wa pre­zen­tu­je w posta­ci chro­no­lo­gicz­nej sekwen­cji kro­ków, to jak coś powsta­je, co się wyda­rza lub jak moż­na coś zro­bić. Piękna defi­ni­cja. Ta pre­zen­ta­cja to, w kon­tek­ście biz­ne­so­wym, model (mapa) pro­ce­sów biznesowych.

Mamy wiec upo­rząd­ko­wa­ną wie­dzę o fir­mie (orga­ni­za­cji) zama­wia­ją­ce­go opro­gra­mo­wa­nie. Tu tak­że powsta­je opis tego po co i gdzie tego opro­gra­mo­wa­nia chce­my uży­wać: model procesowy.

Tak zwane niedopasowanie oporu

Tak jest nazy­wa­na w lite­ra­tu­rze róż­ni­ca pomię­dzy para­dyg­ma­tem pro­ce­so­wym a obiek­to­wym. Paradygmat pro­ce­so­wy ope­ru­je taki­mi poję­cia­mi jak: pro­ces, wej­ście pro­ce­su, wyj­ście pro­ce­su, zda­rze­nie, wyko­naw­ca pro­ce­su (zaso­by), czyn­ność (lub ich sekwen­cja). Paradygmat obiek­to­wy to wspo­mnia­ne współ­pra­cu­ją­ce obiek­ty. W czym pro­blem? W przej­ściu z mode­lu pro­ce­so­we­go na obiek­to­wy. Czy to łatwe? Nie. Jak to zro­bić? Hm… usiąść i popra­co­wać nad tym.

Należy prze­pro­wa­dzić ana­li­zę obiek­to­wą i wyko­nać model obiek­to­wy. Czego? Kodu? Nie! Logiki dzia­ła­nia i orga­ni­za­cji zamawiającego!

Tak wła­śnie jest: ana­li­za obiek­to­wa i mode­lo­wa­nie obiek­to­we to nie pro­gra­mo­wa­nie. Programowanie (wraz z pro­jek­to­wa­niem ele­men­tów czy­sto tech­nicz­nych) to imple­men­ta­cja modelu.

Jak moż­na radzić sobie z tym nie­do­pa­so­wa­niem”. Pomagają w tym zasa­dy SOLID (w szcze­gól­no­ści zasa­da otwar­to­ści na roz­sze­rze­nia i zamknię­cia na mody­fi­ka­cje oraz pro­jek­to­wa­nie zorien­to­wa­ne na zobo­wią­za­nia klas) oraz wzor­ce DDD w ana­li­zie i projektowaniu.

To co tu opi­szę nie jest pro­stym algo­ryt­mem mode­lo­wa­nia”, z pra­cy myślo­wej niko­go tu nie zwol­nię. Moim celem jest uzu­peł­nie­nie arty­ku­łu o sza­chow­ni­cy i arty­ku­łu o zbyt Niskim pozio­mie ana­li­zy o wska­za­nie, że model dzie­dzi­ny jest bar­dziej ele­men­tem ana­li­zy i mode­lo­wa­nia biz­ne­so­we­go niż pro­jek­to­wa­nia i imple­men­ta­cji. Model ten to jed­no z klu­czo­wych wyma­gań: sys­tem ma reali­zo­wać logi­kę opi­sa­ną w mode­lu dziedziny.

Jeżeli uzna­my, że moż­na (taki) model dzie­dzi­ny imple­men­to­wać to jego opra­co­wa­nie to tak­że pro­jek­to­wa­nie. Nadal uwa­żam, że nie jest to robo­ta dla pro­gra­mi­sty, bo na jakiej pod­sta­wie on miał by taki model opracować?

Jak wyglą­da więc pra­ca ana­li­ty­ka biz­ne­so­we­go zgod­nie z mode­lem kom­pe­ten­cyj­nym IIBA (IIBA com­pe­ten­cy model). Kluczowym ele­men­tem pra­cy Analityka Biznesowego (w kon­wen­cji IIBA) jest pro­wa­dze­nie (ana­li­za) wyma­gań od momen­tu okre­śle­nia potrze­by biz­ne­so­wej aż do imple­men­ta­cji uzy­ska­nia wła­ści­we­go roz­wią­za­nia. Jednak uzy­ska­nie to nie to samo co wła­sno­ręcz­ne wyko­na­nie. Znowu ana­lo­gia do budow­nic­twa: archi­tekt na bazie biz­ne­so­wych celów swo­je­go klien­ta opra­co­wu­je nie tyl­ko wizu­ali­za­cję budyn­ku ale tak­że jego kon­struk­cję, do takie­go pozio­mu by deve­lo­per miał jed­no­znacz­nie posta­wio­ne wyma­ga­nia, nie blo­ku­je to jed­nak deve­lo­pe­ro­wi reali­za­cji” wszel­kich poza-funk­cjo­nal­nych wymagań.

Więc po kolei, opracowujemy.

Model procesu biznesowego

Model procesuMamy tu pro­ces skła­da­ją­cy się z dwóch ele­men­tar­nych pro­ce­sów biz­ne­so­wych (czyn­no­ści). Każda czyn­no­ści, zgod­nie z defi­ni­cją pro­ce­su biz­ne­so­we­go, ma dane wej­ścio­we i dane wyj­ścio­we. Dokument 2 i Dokument 3 powsta­ją w tych pro­ce­sach. Mamy tak­że Procedury two­rze­nia doku­men­tów, czy­li jakąś logi­kę ich two­rze­nia. Pojawia się tak­że regu­ła biz­ne­so­wa. Jest to to ele­ment z poza nota­cji BPMN (nota­cja ta zawie­ra jed­nak moż­li­wość ozna­cza­nia czyn­no­ści wyma­ga­ją­cych uży­cia takiej regu­ły). Na dia­gra­mie poka­za­no, regu­łę biz­ne­so­wą oraz jej powią­za­nie z kon­kret­ną czynnością.

Czas zacząć ana­li­zo­wać czy­li pro­jek­to­wać nasz System. Założenie: wyma­ga­ne jest by System (opro­gra­mo­wa­nie) wspie­ra­ło oba pro­ce­sy: 1 i 2 (przy­po­mnę, że pro­ces biz­ne­so­wy to jed­na czyn­ność lub ich sekwen­cja, więc jed­ną czyn­ność mają­cą wej­ście i wyj­ście tak­że z defi­ni­cji, utoż­sa­mia­ny z pro­ce­sem biznesowym).

Usługi systemu

Usługi sys­te­mu to korzeń ana­li­zy obiek­to­wej. Stanowią szkie­let całe­go obiek­to­we­go pro­jek­tu. two­rzy­my bar­dzo waż­ny dia­gram: dia­gram przy­pad­ków użycia.

Usługi systemu

Często sły­szę, że ten dia­gram nic nie wno­si do pro­jek­tu. To nie praw­da. Wnosi klu­czo­wą infor­ma­cję: wyzna­cza gra­ni­ce Systemu i wska­zu­je ewen­tu­al­ne powią­za­nia z inny­mi sys­te­ma­mi. Ale też nie praw­dą jest, że słu­ży do poka­za­nia cze­go­kol­wiek ponad to, np. kolej­no­ści korzy­sta­nia z usług czy struk­tu­ry wewnętrz­nej. To ostat­nie robi­my w posta­ci mode­lu dziedziny.

Na powyż­szym dia­gra­mie udokumentowano:

  1. System ofe­ru­je użyt­kow­ni­ko­wi dwie usłu­gi (to wyma­ga­nie by Czynność 1 i Czynność 2 pro­ce­su były wspie­ra­ne przez System). 
  2. System będzie korzy­stał z danych inne­go opro­gra­mo­wa­nia (Zewnętrznego źró­dła danych), wyma­ga­na jest więc integracja.
  3. Usługa 2 jest reali­zo­wa­na w cało­ści przez inny, zewnętrz­ny sys­tem, wyma­ga­ne jest od sys­te­mu więc by obsłu­gi­wał prze­kie­ro­wa­nie na inny sys­tem (np. reali­za­cja płat­no­ści na stro­nie Banku).

Zakres pro­jek­tu to wyłącz­nie to co w środ­ku”, albo lepiej: wszyst­ko to co jest poza pro­sto­ką­tem System jest poza zakre­sem pro­jek­tu. Nie dostar­cza­my ani Zewnętrznego źró­dła danych ani Systemu Zewnętrznego usłu­go­daw­cy ale musi­my na liście wyma­gań zapi­sać, że inte­gra­cja z nimi jest wyma­ga­na i jaka ona ma być.

Logika działania Systemu – model dziedziny

Zabawa zaczy­na się tu: zamie­nia­my sce­na­riu­sze” na narzę­dzia i materiały”:

Model dziedziny

Celowo zacho­wa­łem nazwy tak by moż­li­we było śla­do­wa­nie” co z cze­go powsta­ło. Kilka komen­ta­rzy, czy­li dobre prak­ty­ki, wzor­ce i styl projektowania.

Każda usłu­ga ma swo­ją dedy­ko­wa­ną kla­sę, zmia­ny reali­za­cji jed­nej nie prze­nio­są się na inne. Usługi są więc od sie­bie nie­za­leż­ne. Oddzielono two­rze­nie doku­men­tów od ich prze­cho­wy­wa­nia, dzię­ki cze­mu łatwo w przy­szło­ści zmie­nić meto­dy ich two­rze­nia bez potrze­by inge­ren­cji w repo­zy­to­rium. Wszelkie regu­ły biz­ne­so­we (w tym vali­da­cji) są zamknię­te” w tak zwa­nych zło­żo­nych typach danych (valueObject, sytu­acja ide­al­na to cał­ko­wi­ty brak typów pro­stych (typy pro­ste, pri­mi­ti­ves) w pro­jek­cie, wyłącz­nie typy zło­żo­ne). W zasa­dzie zastą­pie­nie wszyst­kich typów pro­stych na zło­żo­ne w obsza­rze mode­lu dzie­dzi­ny, otwie­ra w przy­szło­ści dro­gę do ich roz­bu­do­wy bez potrze­by wpro­wa­dza­nia innych zmian w pro­gra­mie. Realnie pomię­dzy Aktorem a usłu­gą ist­nie­ją kla­sy wido­ku (GUI, View w MVC), tu nie umiesz­czo­ne, bo kla­sy te nie reali­zu­ją (nie powin­ny) żad­nej logi­ki biznesowej.

Powyższy model:

  1. Spełnia zasa­dy SOLID (w szcze­gól­no­ści System jest łatwy w roz­sze­rza­niu i nie wyma­ga w tym celu zmian)
  2. Jest zgod­ny z DDD czy­li struk­tu­ra mode­lu odwzo­ro­wu­je struk­tu­rę i poję­cia biznesowe.

Co zysku­je­my? Niskie kosz­ty dal­sze­go roz­wo­ju, łatwość wyce­ny pro­jek­tu przez deve­lo­pe­ra (zna archi­tek­tu­rę). Powstanie takie­go pro­jek­tu daje mi gwa­ran­cję, że panu­je nad nim. Owszem mogę zało­żyć, że deve­lo­per tak­że taki model opra­cu­je, jed­nak życie poka­zu­je, że pra­wie na pew­no nie…

Powyższe z oczy­wi­stych powo­dów (mało miej­sca i uogól­nie­nie) nie zawie­ra szcze­gó­łów, ale te nale­ży zawsze w pro­jek­cie odkła­dać na sam koniec. Dzięki temu może­my sku­pić się na rze­czach na praw­dę waż­nych (waż­ne jest by zro­zu­mieć cel two­rze­nia doku­men­tu a nie spi­sać jego zawar­tość, ta ostat­nia wyni­ka z tego do cze­go służy).

Ostatni wpis na blo­gu, o Niskim pozio­mie ana­li­zy zawie­ra akapit:

Istnieje nie­ste­ty tak­że bar­dzo duże ryzy­ko, któ­re­go źró­dłem jest sto­so­wa­nie sta­rych, struk­tu­ral­nych metod wytwa­rza­nia opro­gra­mo­wa­nia czy­li roz­biór” (i pro­jekt) sys­te­mu na bazę danych i pro­ce­du­ry. Ta prak­ty­ka (meto­da) nie­ste­ty daje jako efekt opro­gra­mo­wa­nie bar­dzo kosz­tow­ne w pro­jek­to­wa­niu i roz­wo­ju. Od metod struk­tu­ral­nych znacz­nie lep­sze są meto­dy obiek­to­we, nie­ste­ty samo dekla­ro­wa­nie korzy­sta­nia z .NET czy Java albo nota­cji UML nie czy­ni sto­so­wa­nych metod obiektowymi.

Właśnie dla­te­go ana­li­za i wyma­ga­nia powin­ny zawie­rać model dzie­dzi­ny wraz z zale­ce­nia­mi co do imple­men­ta­cji. Nie jest to doku­ment (ten model) dla spon­so­ra pro­jek­tu (w rozu­mie­niu do czy­ta­nia). Jego rola (war­tość jaką wno­si do pro­jek­tu) to mini­ma­li­za­cja ryzy­ka, że deve­lo­per wyko­na coś cze­go nie chcemy.

A gdzie baza danych? Nie tu! Implementacja prze­cho­wy­wa­nia danych to pra­ca deve­lo­pe­ra, nie wol­no mu jedy­nie znor­ma­li­zo­wać powyż­sze­go mode­lu. Zaprojektowanie rela­cyj­ne­go mode­lu i uży­cie mapo­wa­nia obiek­to­wo-rela­cyj­ne­go znisz­czy wszyst­kie zale­ty tego pro­jek­tu a dodat­ko­wo strasz­nie skom­pli­ku­je całość.

(prze­druk uka­zał się w ERP-View)

Semantic Core czyli bat na szczegóły

Bardzo czę­sto zasta­na­wiam się, nad przy­czy­na­mi pora­żek pro­jek­tów, przy­czy­na­mi tego, że jed­ne są lep­sze inne gor­sze, a gor­szy to taki, któ­ry wymy­ka się spod kon­tro­li a osta­tecz­ny efekt (pro­dukt), uzy­ska­ny po znacz­nie dłuż­szym cza­sie niż pla­no­wa­no, jest zasko­cze­niem dla wszyst­kich. Na to nakła­da się pro­blem prze­ka­zy­wa­nia wie­dzy pomię­dzy kolej­ny­mi eta­pa­mi pro­jek­tu, gdzie naj­więk­szym ryzy­kiem jest zro­zu­mie­nie pro­ble­mu i prze­ka­zy­wa­nie wie­dzy przez same­go zama­wia­ją­ce­go. Gdzie problem?

Ten arty­kuł pole­cam biz­ne­so­wi” któ­ry szu­ka przy­czyn swo­ich pro­ble­mów, i tym (nie tyl­ko ana­li­ty­kom), któ­rzy mają ambi­cje robić coś w kie­run­ku popra­wy tego sta­nu rze­czy, zamiast uzna­wać obec­ne sta­ty­sty­ki za pew­nik bo takie są fakty”.

Wpadłem jakiś czas temu na stro­nę SemanticCore​.ORG, oto krót­ki cytat z pierw­szej strony :

The seman­tic core repre­sents a vision of com­plex sys­tems that are defi­ned and pro­vi­sio­ned based on high-level models. This vision is being pur­su­ed by mul­ti­ple gro­ups in mul­ti­ple orga­ni­za­tions based on a varie­ty of para­digms such as UML, Ontologies, Business Rules, MOF, EDOC, Data Modeling, OWL, SQL, Etc.. It is the intent of the seman­tic core to inte­gra­te the­se diver­se para­digms into fami­ly of lan­gu­ages that leve­ra­ges the­ir com­mo­na­li­ty whi­le taking advan­ta­ge of the­ir uni­que capa­bi­li­ties. We will defi­ne nor­ma­li­zed Meta-Models cap­tu­ring uni­que seman­tics, inde­pen­dent of the nota­tion. […] It is our intent to cre­ate a com­bi­ned sub­mis­sion appro­pria­te for mul­ti­ple OMG ini­tia­ti­ves inc­lu­ding Ontologies, Business Rules, Business Process Modeling and a UML infra­struc­tu­re libra­ry.[…] the seman­tic core will defi­ne models for a fami­ly of onto­lo­gi­cal­ly gro­un­ded models defi­ning all aspects of sys­tems, inc­lu­ding the­ir requ­ire­ments, envi­ron­ment, spe­ci­fi­ca­tion and imple­men­ta­tion. This will ena­ble a trans­i­tion from tra­di­tio­nal and manu­al sys­tems buil­ding tech­ni­qu­es to an auto­ma­ted and human-focu­sed para­digm. (źr. Semantic Core).

Powyżej (moje wytłusz­cze­nia) głów­ne cele tej orga­ni­za­cji (pole­cam zapo­zna­nie się z całą stroną)

  • nasza wizja to zło­żo­ne sys­te­my opi­sy­wa­ne i przed­sta­wia­ne w posta­ci mode­li na wyso­kim pozio­mie abstrakcji,
  • w tym celu defi­niu­je­my znor­ma­li­zo­wa­ny meta­mo­del opi­sa­ny sys­te­mem zna­czeń (seman­ty­ka) nie­za­leż­nym od notacji,
  • two­rzy­my to w zgo­dzie z ini­cja­ty­wa­mi OMG (www​.omg​.org),
  • seman­tic core” okre­śla stan­dar­do­wy zestaw klu­czo­wych pojęć i ich zna­czeń, opi­su­ją­cych wszyst­kie aspek­ty sys­te­mów, w tym ich wyma­ga­nia, oto­cze­nie, spe­cy­fi­ka­cji i implementacje.

Wygląda jak baj­ka ale nie jest tak źle, a coś takie­go jest bar­dzo przy­dat­ne. Nie ma sen­su budo­wa­nie jed­nej mega-nota­cji do wszyst­kie­go, widać to po pra­cach OMG (i po tym, że UML jed­nak nie zastą­pił innych nota­cji, i nikt roz­sąd­ny chy­ba już tego nie pla­nu­je). Jednak uzna­jąc fakt, że uży­wa­my (dobra prak­ty­ka) nota­cji wła­ści­wych dla roz­wią­zy­wa­ne­go pro­ble­mu (zary­zy­ku­ję tezę: wła­ści­wa to moż­li­wie naj­prost­sza i wystar­cza­ją­ca) war­to jed­nak zadbać o ich kom­pa­ty­bil­ność”. Część wspól­na to nie nowa nota­cja, a utrzy­ma­nie spój­no­ści zna­czeń współ­dzie­lo­nych pojęć ist­nie­ją­cych już notacji.

SemanticCore
(źr. SemanticCore​.org)

O złożoności

Na co war­to zwró­cić uwa­gę? Otóż w pro­ce­sie każ­dej więk­szej ana­li­zy poja­wia się zło­żo­ność, nad któ­rą nale­ży zapa­no­wać. Bez tego opa­no­wa­nia poja­wia się coś co zabi­ja pro­jek­ty ana­li­tycz­ne: utra­ta pano­wa­nia nad zło­żo­no­ścią pro­ble­mu, poja­wia­ją się mega-dia­gra­my i mega for­mu­la­rze danych.

Kilka tygo­dni temu, w jed­nym z moich pro­jek­tów, mia­łem oka­zję wejść w mały spór na temat tego, kie­dy udo­ku­men­to­wać szcze­gó­ło­wo spo­sób kla­sy­fi­ka­cji (ozna­cza­nia) pozy­cji budże­to­wych w sys­te­mie zarzą­dza­nia pro­ce­sem two­rze­nia budże­tu i jego reali­za­cji. Zamawiający od razu wcho­dził (wręcz żądał) w szcze­gó­ły, czy­li naście rodza­jów każ­de­go z ogrom­nej licz­by typów wydat­ków. Jeszcze bym dobrze nie ruszył z miej­sca a już został bym zgnie­cio­ny licz­bą tych szcze­gó­łów. Do tego dorzu­ca­no mi peł­ną szcze­gó­ło­wość struk­tu­ry orga­ni­za­cyj­nej (tak­że prze­kła­da się na budżet jako miej­sca wyda­wa­nia środ­ków). Dodam, że struk­tu­ra orga­ni­za­cyj­na zmie­ni­ła się w cią­gu roku trzy razy.

Co z tym zro­bić? Wyrzucić” te szcze­gó­ły na sam koniec! One są na począt­ku zupeł­nie nie­istot­ne (nie licząc zapo­zna­nia się nimi jako obec­nie funk­cjo­nu­ją­cym sys­te­mem), każ­dy zaś kto twier­dzi, że jed­nak są istot­ne już teraz, po pro­stu jesz­cze nie zro­zu­miał ana­li­zo­wa­ne­go problemu.

Problemem są pryn­cy­pia czy­li co i po co” a nie jak”. Owo jak” to dopie­ro pro­jek­to­wa­nie. Tak więc np. budżet, pro­ces jego two­rze­nia a potem reali­za­cji, to jakiś sys­tem pozy­cji budże­to­wych” i zda­rzeń zwią­za­nych z jego reali­za­cją. Jakaś logi­ka tej cało­ści (dalej jako regu­ły biz­ne­so­we i decy­zyj­ne). To jak zosta­nie ozna­czo­na (jakim sym­bo­lem itp.) to efekt tego co chce­my osią­gnąć. Każdy kto chwy­ci się od razu za te szcze­gó­ły (jakieś one są, mamy je już więc dla­cze­go się za nie nie zabrać), zaczy­na od koń­ca i w zasa­dzie zarzu­cił ana­li­zę i odciął sobie (klien­to­wi) moż­li­wość zbu­do­wa­nia opty­mal­ne­go (nowe­go) roz­wią­za­nia (zapew­ne inne­go niż obec­ne) na rzecz obecnego.

Należy na począt­ku pra­co­wać na abs­trak­cji, uogól­nie­niu pozwa­la­ją­cym sku­pić się na kil­ku­na­stu pryn­cy­piach zamiast na tysią­cach szcze­gó­łów. To pierw­sze jest rela­tyw­nie łatwe, to dru­gie w zasa­dzie niemożliwe.

abstraction systemcore_org
(źr. SemanticCore​.org)

Modele

Jak wspo­mnia­no powy­żej, typów mode­li (nota­cji) mamy wię­cej niż jeden. Każdy model (rodzaj mode­lu) ma swój dedy­ko­wa­ny sys­tem pojęć, po ubra­niu go w iko­ny mamy nota­cję (język obraz­ko­wy), czy­li język opi­sa­ny seman­ty­ką (zna­cze­nia pojęć) i syn­tak­ty­ką (ich wza­jem­ne, dopusz­czal­ne rela­cje). Zestaw pojęć powi­nien być dobra­ny sto­so­wa­nie do roz­wią­zy­wa­ne­go pro­ble­mu (wybór wła­ści­wej do eta­pu pra­cy notacji).

Jak wska­za­no wyżej, mamy czte­ry klu­czo­we sys­te­my pojęciowe:

  1. UML czy­li obiek­to­wy para­dyg­mat opi­su i projektowania,
  2. Ontologia (biz­ne­so­wa, sys­te­mo­wa), któ­rą obec­nie repre­zen­tu­ją Model Motywacji Biznesowej (w mię­dzy cza­sie tak­że doro­bił się ikon), SBVR i sys­te­my poję­cio­we opi­sy­wa­nia archi­tek­tu­ry kor­po­ra­cyj­nej, struk­tu­ry organizacji,
  3. Procesy biz­ne­so­we,
  4. Reguły biz­ne­so­we.

Wspólny śro­dek ma już swo­je zarze­wie”. W 2010 roku wyda­no ostat­nią spe­cy­fi­ka­cję Modelu Motywacji Biznesowej (ang. BMM). Można przy­jąć, że ten sys­tem poję­cio­wy (teraz tak­że nota­cja) to ele­ment biz­ne­so­wej onto­lo­gii. Pojawił się w niej doda­tek F zaty­tu­ło­wa­ny Powiązane spe­cy­fi­ka­cje mode­lo­wa­nia w OMG. I co my tu mamy?

Ano mamy stwier­dze­nie, że ta kom­pa­ty­bil­ność jest potrzeb­na. Napisano, że BMM współ­dzie­li pew­ne poję­cia z taki­mi sys­te­ma­mi poję­cio­wy­mi jak:

  1. BPMN (w BMM poja­wia się poję­cie pro­ces biznesowy)
  2. SBVR (BMM tak­że ope­ru­je poję­ciem Reguła Biznesowa)
  3. OSM (Organization Structure Metamodel, BMM uży­wa poję­cia komór­ka organizacyjna”).

Co cie­ka­we poję­cia te mają w OMG wspól­ne defi­ni­cje (te same poję­cia lub poję­cia dają­ce się mapo­wać 1:1). Utrzyma jest zgod­ność roli w pro­ce­sie biz­ne­so­wym i roli jako ele­men­tu struk­tu­ry orga­ni­za­cyj­nej w tych sys­te­mach (OSM, BPMN, BMM).

W spe­cy­fi­ka­cji BMM v.1.1 znaj­dzie­my taki oto diagram:

BMMOvierwiev

Notacje, któ­re wpa­dły” w ręce OMG maja wła­śnie tę bar­dzo pożą­da­ną i przy­jem­ną cechę: są kom­pa­ty­bil­ne. Wspominałem swe­go cza­su o nota­cji ArchiMate (obec­nie nale­ży do The Open Group podob­nie jak i TOGAF). Niestety nie ma tu tej kom­pa­ty­bil­no­ści, mimo że TOGAF nie jest samo­wy­star­czal­nym mode­lem (wyma­ga sto­so­wa­nia innych nota­cji poza ArchiMate), w efek­cie nie widzę moż­li­wo­ści pro­ste­go” zasto­so­wa­nia ram TOGAF”a jako bazo­wej archi­tek­tu­ry kor­po­ra­cyj­nej, bo kolej­ne eta­py uszcze­gó­ła­wia­nia mode­li (a od tego nie ma uciecz­ki w pro­jek­tach) albo będą mia­ły kło­po­ty z jed­no­znacz­no­ścią albo będą wyma­ga­ły jakie­goś dedy­ko­wa­ne­go sys­te­mu tłu­ma­cze­nia pojęć TOGAF na UML, BPMN (BMM nie, bo TOGAF od ostat­niej wer­sji dublu­je – nie wiem czy w 100% i po co – poję­cia mode­lu moty­wa­cji biznesowej.

Nie wymie­ni­łem tu nota­cji UML bo ta słu­ży do obiek­to­we­go mode­lo­wa­nia (para­dyg­mat obiek­to­wy) sys­te­mów. Nie widzę sen­su wpy­cha­nia” jej w dzie­dzi­nę onto­lo­gii zarzą­dza­nia. Paradygmat obiek­to­wy to inne spoj­rze­nie, sys­te­mo­we, opi­su­ją­ce współ­dzia­ła­ją­ce obiek­ty”, jed­nak to wtór­ny model, bo te obiek­ty sys­te­mo­we repre­zen­tu­ją” komór­ki orga­ni­za­cyj­ne, stra­te­gie, regu­ły biz­ne­so­we, doku­men­ty itp. Modele obiek­to­we są dosko­na­łe jako wstęp do pro­jek­to­wa­nia opro­gra­mo­wa­nia imple­men­to­wa­ne­go z pomo­cą obiek­to­wo zorien­to­wa­nych narzę­dzi. Są kom­plet­nie nie­przy­dat­ne jako biz­ne­so­wy sys­tem poję­cio­wy. Owszem, nie raz tu wspo­mi­na­ny DDD (spo­sób mode­lo­wa­nia dzie­dzi­ny sys­te­mu) to pew­ne takie połą­cze­nie, ale to raczej most niż ekwi­wa­lent. Patrząc na ten pro­blem z per­spek­ty­wy MDA (OMG, Model Driven Architecture) model CIM (Computing Independent Model) to powyż­sze mode­le (BMM, BPMN), UML ma zasto­so­wa­nie dla czę­ści PIM (wstęp­ny model imple­men­ta­cji w posta­ci opro­gra­mo­wa­nia) i tu jest dopie­ro miej­sce na DDD.

Tak więc bat na szcze­gó­ły jest: to pro­sta zasa­da od ogó­łu do szcze­gó­łu”, na każ­dym eta­pie mamy sto­sow­ną nota­cję (pro­sty sys­tem pojęć). Należy uogól­niać i mode­lo­wać, i potem stop­nio­wo uszcze­gó­ła­wiać mode­le aż do momen­tu doj­ścia do imple­men­ta­cji dane­go systemu.

TheMetaModelArchitecture

Powyżej obraz z nanie­sio­ny­mi eta­pa­mi [[MDA]] (wię­cej o Model Driven Architecture oraz Meta Object Facility – powyż­szy rysu­nek – na stro­nach OMG). Core Semantic to szczyt (M3) powyż­sze­go. Wymienione wyżej nota­cje to war­stwa M2 (UML dodat­ko­wo obej­mu­je tak­że M1).

Konkluzja jest taka: bazy danych zawie­ra­ją­ce szcze­gó­ło­wość sys­te­mu, pro­jek­tu­je­my na koń­cu. Szczegóły ele­men­tów budże­tu (przy­ta­cza­ny przy­kład) opra­co­wu­je­my dopie­ro jako pomysł na imple­men­ta­cję, mamy to jed­nak dwa pozio­my implementacji:

  1. roz­wią­za­nie pro­ble­mu efek­tyw­ne­go zarzą­dza­nia budże­tem w nowej for­mie np. sys­tem zna­ko­wa­nia pozy­cji budżetowych,
  2. imple­men­ta­cja tego sys­te­mu jako opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go ten pro­ces w organizacji.

To wszyst­ko powin­no być jed­nak poprze­dzo­ne ana­li­zą. Analiza obec­nej sytu­acji nie pole­ga jed­nak na jej 100% odwzo­ro­wa­niu w doku­men­tach ana­li­tycz­nych, a jedy­nie na pozna­niu w celu zro­zu­mie­nia celu biz­ne­so­we­go, opra­co­wa­nie jego mode­lu, i potem dopie­ro roz­wią­zy­wa­nie pro­ble­mu: jak to osiągnąć.

Na koniec pew­na uwa­ga :). Ktoś może powie­dzieć: biz­nes tego (nota­cje, mode­le itp.) nie rozu­mie. I ma racje, bo to narzę­dzia a nie pro­duk­ty ana­liz. Produktem ana­li­zy dla biz­ne­su są zawsze reko­men­da­cje (wyma­ga­nia na opro­gra­mo­wa­nie to tak­że rodzaj reko­men­da­cji brzmią­cej: zale­cam by takie warun­ki speł­nia­ło to opro­gra­mo­wa­nie). Zamawianie przez biz­nes mode­li jako takich, to jakieś kosz­mar­ne nie­po­ro­zu­mie­nie. To tak jak by np. praw­nik, jako pro­dukt zle­ce­nia opi­nia praw­na” oddał wybra­ny stos kodek­sów z komen­ta­rza­mi. Nie, dobry praw­nik odda­je jed­na stro­nę reko­men­da­cji: opi­nie praw­ną. To, że sko­rzy­stał z tych kodek­sów to jego narzę­dzie pra­cy, moż­li­we, że załą­czy je do tej tej opi­nii (ale raczej jako mate­riał dla inne­go praw­ni­ka lub audytora).

Rachunek kosztów działań ABC ? model procesu niezbędny

O pro­ce­sach biz­ne­so­wych i ich mode­lo­wa­niu napi­sa­no już wie­le, jed­nak w więk­szo­ści przy­pad­ków pisze się o tym w kon­tek­ście albo wdro­żeń sys­te­mów IT albo w kon­tek­ście reorganizacji.

Jakiś czas temu zna­la­złem się na kon­fe­ren­cji zwią­za­nej z zarzą­dza­niem kon­tro­lin­giem i finan­sa­mi. Usłyszałem coś co mnie nie­co i zdzi­wi­ło, pew­na pani zaj­mu­ją­ca się wła­śnie meto­da­mi kon­tro­lin­gu, w swo­im refe­ra­cie, zwró­ci­ła uwa­gę na dziw­ne jej zda­niem zja­wi­sko: bar­dzo wie­le firm wdra­ża meto­dy zarzą­dza­nia kosz­ta­mi dzia­łań nie mając mode­lu pro­ce­sów biz­ne­so­wych, czy to nie jest wró­że­nie z fusów, zapytała?

Czym jest zarzą­dza­nie kosz­ta­mi dzia­łań albo ina­czej, na czym pole­ga meto­da ABC ([[Activity Based Costing]]) zarzą­dza­nia kosztami?

W sys­te­mie rachun­ku kosz­tów dzia­łań infor­ma­cje o kosz­tach muszą być zbie­ra­ne w prze­kro­ju pro­ce­sów i dzia­łań, a nie w prze­kro­ju rodza­jów i pod­mio­tów, dla­te­go nale­ży prze­or­ga­ni­zo­wać infor­ma­cje o kosz­tach z sys­te­mu finan­so­wo-księ­go­we­go w ten spo­sób, by umoż­li­wi­ły one przyj­rze­nie się kosz­tom fir­my z per­spek­ty­wy pro­ce­sów i dzia­łań. Aby wyod­ręb­nić pro­ce­sy lub dzia­ła­nia nale­ży zasto­so­wać ana­li­zę pro­ce­sów gospo­dar­czych. Polega ona na sys­te­ma­tycz­nym roz­pa­try­wa­niu czyn­no­ści koniecz­nych do wyko­na­nia wyro­bów lub usług. W wyni­ku tej ana­li­zy nastę­pu­je ziden­ty­fi­ko­wa­nie wszyst­kich dzia­łań, zarów­no tych któ­re zwięk­sza­ją war­tość wyro­bu lub usłu­gi dla klien­ta, jak też dzia­łań nie­przy­czy­nia­ją­cych się do wzro­stu war­to­ści. Identyfikacja dzia­łań koń­czy się utwo­rze­niem słow­ni­ka dzia­łań, wymie­nia­ją­ce­go i defi­niu­ją­ce­go naj­waż­niej­sze dzia­ła­nia wyko­ny­wa­ne w przed­się­bior­stwie. Działania opi­sy­wa­ne są za pomo­cą ter­mi­nów ozna­cza­ją­cych czyn­ność, połą­czo­nych z okre­śle­nia­mi. (za Rachunek kosz­tów dzia­łań ? Wikipedia, wol­na ency­klo­pe­dia).

Jak widać wyda­je się to wręcz nie­moż­li­we by taki sys­tem wdro­żyć nie mając ana­li­zy pro­ce­so­wej fir­my. Na moje pyta­nie (do tej Pani) jak te fir­my to robią bez mode­li pro­ce­sów, padła krót­ka odpo­wiedź: źle, bo przede wszyst­kim brak mode­lu pro­ce­sów powo­du­je, że nie mamy żad­nej pew­no­ści, że nicze­go nie pomię­to lub zbyt nie skom­pli­ko­wa­no. Dodam od sie­bie, że model pro­ce­sów jest bar­dzo pomoc­ny, z podob­nych powo­dów, pod­czas pro­jek­to­wa­nia hur­tow­ni danych.

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.