ISA – Interoperability Solution for European Public Administrations

Od cza­su do cza­su nawo­łu­ję” do for­ma­li­zo­wa­nia pro­jek­tów. Jak nie raz wspo­mi­na­łem, jest to pod­sta­wo­wa meto­da uczy­nie­nia pro­jek­tu (jego doku­men­ta­cji) przej­rzy­stym. Drugą waż­ną korzy­ścią z for­ma­li­za­cji jest tak zwa­na [[inte­ro­pe­ra­cyj­ność]], któ­ra ozna­cza moż­li­wość współ­dzia­ła­nia tech­no­lo­gii róż­nych dostaw­ców (pro­du­cen­tów).

Jak nie trud­no się domy­śleć, pro­blem doty­czy w szcze­gól­no­ści każ­dej więk­szej orga­ni­za­cji, nie­ja­ko ska­za­nej na posia­da­nie roz­wią­zań z róż­nych źró­deł. Klasycznym przy­kła­dem jest admi­ni­stra­cja publicz­na (z inte­ro­pe­ra­cyj­no­ścią, a raczej jej bra­kiem, w Polsce walczymy).

Tak więc pole­cam oso­bom zwią­za­nym z admi­ni­stra­cja publicz­ną i insty­tu­cja­mi publicz­ny­mi, zapo­zna­nie się z tą ini­cja­ty­wą. Moim zda­niem bar­dzo waż­na, dobrze że pod­ję­to ten temat gdyż kwe­stie inte­gra­cyj­ne sta­no­wią nie raz istot­ny koszt pro­jek­tów IT a bywa, że brak inte­ro­pe­ra­cyj­no­ści powo­du­je wręcz nie­moż­ność ich reali­za­cji (np. w Polsce inte­gra­cja reje­strów Państwowych). 

Czytaj dalej ISA – Interoperability Solution for European Public Administrations

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 analitycznych!).

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 notacje).

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…

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

Modelowanie biznesowe c.d. – know-how, gdzie ono jest?

Proces biz­ne­so­wy, nie pro­ce­du­ra i nie opis prze­pły­wu pra­cy, to pro­sty ciąg czyn­no­ści, któ­rych celem jest kon­kret­ny rezul­tat: pro­dukt pro­ce­su (jego wyjście). 

Proces ma cel, sta­no­wi pro­sty łań­cuch pra­cy wyko­naw­cy (Rola), radzi sobie z wyda­rze­nia­mi utrud­nia­ją­cy­mi”. Główny ciąg (ocze­ki­wa­ny) zazna­czo­no sza­rą strzał­ką. Pozostałe atrak­cje” to czyn­no­ści wymu­szo­ne pew­ny­mi nie ocze­ki­wa­ny­mi (a raczej nie chcia­ny­mi), ale prze­wi­dzia­ny­mi zda­rze­nia­mi. Tu nie ma rom­bów”, bra­mek decy­zyj­nych bo one są cechą pro­ce­sów decy­zyj­nych”, pro­ce­dur, a te to regu­ły biz­ne­so­we i wie­dza o biz­ne­sie” a nie pro­ces biz­ne­so­wy. Pewne czyn­no­ści mogą być ogra­ni­czo­ne Procedurą, któ­ra mówi, że tyl­ko tak wol­no tę pra­cę wykonać”.

Reguły biz­ne­so­we to wewnętrz­ne (np. zarzą­dze­nia) lub zewnętrz­ne (pra­wo) ogra­ni­cze­nia. Pojawia się rola czy­li wyko­naw­ca (tu rola dzia­łu HR – opis kom­pe­ten­cji pra­cow­ni­ków), on posia­da nie­zbęd­ną wie­dzą i umie­jęt­no­ści, potra­fi obsłu­gi­wać maszy­ny” (tak­że opro­gra­mo­wa­nie). Tak więc defi­ni­cja mówią­ca, że pro­ces wyko­nu­je się w w śro­do­wi­sku ogra­ni­czeń i wyma­ga zaso­bów tak wła­śnie wyglą­da: zaso­by to ludzie (role), ich wie­dza i narzę­dzia pra­cy, ogra­ni­cze­nia to regu­ły biz­ne­so­we i procedury.

Czytaj dalej Modelowanie biznesowe c.d. – know-how, gdzie ono jest?

Czym jest Piąty element – Audyt organizacji czyli analiza biznesowa

Mało któ­ra fir­ma ma mode­le pro­ce­sów a każ­da jakoś ist­nie­je! Można żyć bez map pro­ce­sów, strasz­ne! Co więc ofe­ru­ją fir­my dorad­cze sprze­da­ją­ce” usłu­gę mode­lo­wa­nia pro­ce­sów biznesowych?

Sedno spo­so­bu pra­cy orga­ni­za­cji to regu­ły biz­ne­so­we. One rzą­dzą tym, co jest wyko­ny­wa­ne i jak. Proces (to jak jest wyko­ny­wa­na pra­ca) to abs­trak­cja, efekt ist­nie­nia ogra­ni­czeń (w tym wła­śnie reguł biz­ne­so­wych). Tak wiec moż­na zarzą­dzać fir­mą nie mając mode­li pro­ce­sów podob­nie jak moż­na miesz­kać w mie­ście nie mając jego planu.

W czym pro­blem? Bez mapy” nie rozu­mie­my wie­lu zja­wisk mimo, że wystę­pu­ją. Jednak przy­dat­ny model biz­ne­so­wy to model pro­ce­sów powią­za­ny z pozo­sta­ły­mi czte­re­ma skład­ni­ka­mi opi­su orga­ni­za­cji (ludzie, pra­wo, wewnętrz­ne zarzą­dze­nia i procedury).

Model biz­ne­so­wy to nie są dzie­siąt­ki i set­ki nie­czy­ta­nych dia­gra­mów, poka­zu­ją­cych szcze­gó­ło­wo to co robię pra­cow­ni­cy bo mogą to robić na nie­skoń­cze­nie wie­le spo­so­bów. Istotne jest to co powsta­je, po co i dla­cze­go aku­rat tak.

Na zakoń­cze­nie: np. model pra­cy ope­ra­cyj­nej każ­de­go urzę­du moż­na kom­plet­nie opi­sać jed­nym dia­gra­mem. Jeżeli chcesz na praw­dę poznać swo­ją fir­mę, opra­cuj jej model. Ale nie w posta­ci setek dia­gra­mów będą­cych suchym zapi­sem wywiadu.

Rozłóż fir­mę na czyn­ni­ki pierw­sze i zro­zum ją. Bez tego nie zarzą­dzasz a pró­bu­jesz zarządzać!

Wykonaj sfor­ma­li­zo­wa­ny nota­cja­mi i słow­ni­kiem pojęć, audyt fir­my, spo­so­bu funk­cjo­no­wa­nia i zro­zum jak na praw­dę działa.

Czytaj dalej Czym jest Piąty element – Audyt organizacji czyli analiza biznesowa

Analiza biznesowa

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.

Czytaj dalej Analiza biznesowa

Czas nie jest aktorem dla Systemu c.d. czyli projekt

akto­rem abso­lut­nie nie jest Czas, akto­rem jest inny sys­tem, tu źró­dło sygna­łu cza­su. Diagram UC jest zgod­ny ze stan­dar­dem a my zro­zu­mie­li­śmy isto­tę rze­czy”. Stosowanie w ana­li­zie stan­dar­dów pro­wa­dzi do rozu­mie­nia i ma taką wła­śnie zale­tę: ana­li­za i mode­lo­wa­nie pro­wa­dzi do zro­zu­mie­nia pro­ble­mu, łama­nie zasad nota­cji ukry­wa nie­zro­zu­mie­nie pro­ble­mu (o co cho­dzi z tym ocze­ki­wa­nym przez klien­ta czasem).

Czytaj dalej Czas nie jest aktorem dla Systemu c.d. czyli projekt

Czas nie jest aktorem Systemu

Tak więc radzę ostroż­nie z Wikipedią. Wprowadzanie pojęć ukry­wa­ją­cych isto­tę rze­czy to moim zda­niem, ukry­wa­nie nie­wie­dzy na eta­pie ana­li­zy i pro­jek­to­wa­nia. To jed­na z przy­czyn złej jako­ści pro­ce­su two­rze­nia opro­gra­mo­wa­nia. Niezależnie od tego jak ład­nie umo­ty­wu­je­my ist­nie­nie akto­ra Czas, pro­gra­mi­sta i tak musi ten pro­blem roz­wią­zać i nie będzie to na pew­no inter­fejs inte­rak­cji Systemu z Czasem”… A co z cza­sem? No cóż, albo czło­wiek kli­ka co godzi­nę w coś, albo wewnątrz sys­te­mu jest moduł, któ­ry gene­ru­je zda­rze­nie wywo­łu­ją­ce te samo ope­ra­cję co kli­ka­ją­cy użyt­kow­nik… Moduł wewnętrz­ny sys­te­mu nie jest jego aktorem.

Jak w takim razie w ogól­no­ści mode­lo­wać cyklicz­ność? Np. pre­nu­me­ra­ta cza­so­pi­sma na okres 12 m‑cy”, codzien­ne gene­ro­wa­nie rapor­tu”, zbie­ra­nie wska­zań licz­ni­ka co N jed­no­stek cza­su” ? Po pierw­sze usłu­ga sys­te­mu to odpo­wied­nio: zarzą­dza­nie pre­nu­me­ra­ta­mi, gene­ro­wa­nie rapor­tów, prze­twa­rza­nie pomia­rów. Prenumerata to zapis mówią­cy, że mam otrzy­mać np. każ­de wyda­nie jakie­goś perio­dy­ka w cią­gu dane­go roku. Generowanie rapor­tów to czyn­ność czło­wie­ka (raport na życze­nie) albo auto­ma­tu reagu­ją­ce­go na zda­rze­nie kon­kret­ny czas”, zda­rze­nia takie gene­ru­je np. zegar sys­te­mo­wy. Zbieranie wska­zań licz­ni­ka to cyklicz­ne zda­rze­nie ini­cjo­wa­ne przez System. Implementacja tych wyma­gań to ele­ment pro­jek­to­wa­nia logi­ki biz­ne­so­wej i nie jest to już dia­gram przy­pad­ków uży­cia a model dzie­dzi­ny sys­te­mu bo to tu jest logi­ka biznesowa.

Czytaj dalej Czas nie jest aktorem Systemu

Reguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć

Mapa (model) pro­ce­sów oraz struk­tu­ra orga­ni­za­cyj­na, by były jed­no­znacz­ne, muszą być tak­że zesta­wem zde­fi­nio­wa­nych pojęć. Musimy wie­dzieć co zna­czy sło­wo: prze­ło­żo­ny, pod­wład­ny, komór­ka orga­ni­za­cyj­na czy jej kie­row­nik. Jeszcze więk­szym wyzwa­niem zde­fi­nio­wa­nie sys­te­mu pojęć dla mapy pro­ce­sów (pro­ces, czyn­ność, zda­rze­nie, doku­ment…). Budowanie sys­te­mów poję­cio­wych speł­nia­ją­cych powyż­sze warun­ki jest bar­dzo trud­ne dla­te­go dla mode­li pro­ce­sów biz­ne­so­wych naj­le­piej wyko­rzy­stać goto­wy model poję­cio­wy: jest nim nota­cja. Najlepiej obec­nie opra­co­wa­nym takim mode­lem poję­cio­wym jest goto­wa nota­cja [[BPMN]]. Tworzenie wła­snych jest kosz­tow­ne (czas i wie­dza oso­by opra­co­wu­ją­cej) i bar­dzo ryzy­kow­ne (może się nie udać). Dlatego uży­wa­nie dzi­siaj wła­snych lub innych (np. dosto­so­wy­wa­ne pro­fi­la­mi dia­gra­my UML) jest w moich oczach nie­ra­cjo­nal­nym podejściem.

Model pojęć spe­cy­ficz­ny dla danej orga­ni­za­cji nie­ste­ty musi powstać od zera”, podob­nie jak powią­za­na z nim spe­cy­fiak­cja reguł biz­ne­so­wych. Jest to trud­ne bo two­rze­nie prze­strze­ni nazw wyma­ga utrzy­ma­nia nie­za­leż­no­ści poszcze­gól­nych defi­ni­cji i spój­no­ści i zupeł­no­ści całe­go ich sys­te­mu. Niedochowanie tych wyma­gań pro­wa­dzi do nie­peł­no­ści a nawet sprzecz­no­ści reguł biz­ne­so­wych, któ­re w koń­cu są budo­wa­ne (odkry­wa­ne i doku­men­to­wa­ne) z pomo­cą tych pojęć. Zanim wiec zaan­ga­żu­jesz kogoś do mode­lo­wa­nia wła­snej fir­my, upew­nij się, komu zle­casz tę pracę… 

W bar­dzo dużym więc skrócie:

pro­ce­sy biz­ne­so­we to fak­tycz­ny, widocz­ny spo­sób pra­cy firm (ludzi w nich zatrudnionych),
pro­ce­sy to efekt funk­cjo­no­wa­nia ludzi w śro­do­wi­sku ograniczeń,
nale­ży poznać tych ludzi,
ogra­ni­cze­nia to: pro­ce­du­ry, pra­wo, zarzą­dze­nia wewnętrz­ne oraz spe­cy­ficz­ne dla fir­my wewnętrz­ne nor­my zwa­ne regu­ła­mi biznesowymi,
opra­co­wa­nie biz­ne­so­we­go mode­lu fir­my wyma­ga zro­zu­mie­nia i opi­sa­nia tego co powy­żej opisałem,
nie ist­nie­je dro­ga na skróty.

Czytaj dalej Reguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć