W poprzed­nim arty­ku­le, Czy sys­tem peł­ni rolę w pro­ce­sie?, poja­wi­ła się pole­mi­ka, któ­ra jest dość powszech­nym problemem:

[czy­tel­nik] Są to pro­ce­sy (lub pod­pro­ce­sy), któ­re zosta­ły zastą­pio­ne w 100% i alter­na­tyw­na ich obsłu­ga będzie moż­li­wa tyl­ko w przy­pad­ku wystą­pie­nia jakie­goś błędu.

Przykładem takie­go pro­ce­su jest zauto­ma­ty­zo­wa­nie reje­stra­cji doku­men­tów (wpro­wa­dze­nie kana­łu mailo­we­go, odcię­cie cał­ko­wi­te moż­li­wo­ści wyko­rzy­sta­nia papie­ro­wych doku­men­tów). Test odłą­cze­nia prą­du ode­tnie orga­ni­za­cję od świa­ta zewnętrz­ne­go. Wyobrażam sobie wie­le biz­ne­sów opie­ra­ją­cych się w więk­szo­ści o chmu­ry, usłu­gi, któ­rych wycię­cie spro­wa­dzi ten aku­rat biz­nes do pozio­mu średniowiecznego.

[moja odpo­wiedź] odłą­cze­nie prą­du spo­wo­du­je zmu­sze­nie do prze­my­śle­nia i nazwa­nia pro­ce­su ?przyj­mo­wa­nie doku­men­tów? a mail to tyl­ko przy­ję­ta meto­da, tu błę­dem było nazwa­nie pro­ce­su biz­ne­so­we­go ?odbie­ra­ni maili? zamiast nazwa­nie go ?tym czym jest? czy­li ?przyj­mo­wa­nie korespondencji?.

Jest to kla­sycz­ny przy­kład bra­ku uogól­nień i abs­trak­cji w mode­lach, co pro­wa­dzi do zamu­la­nia” ich nad­mia­rem szcze­gó­łów, masko­wa­nia praw­dzi­we­go sen­su (isto­ty) zja­wi­ska. Problem sto­so­wa­nia abs­trak­cji w mode­lo­wa­niu a kon­kret­nie, pro­blem nie radze­nia sobie z abs­trak­cją, jest czę­sto w lite­ra­tu­rze nazy­wa­ny utra­tą pano­wa­nia nad szcze­gó­ło­wo­ścią pro­jek­tu”. Monstrualne ilo­ści dia­gra­mów pro­ce­sów, mon­stru­al­ne ilo­ści deta­li na dia­gra­mach, to efekt bra­ku abstrakcji.

Warto pamię­tać, że mode­le pro­ce­sów biz­ne­so­wych to ele­ment opi­su archi­tek­tu­ry biz­ne­so­wej. Po raz kolej­ny przy­po­mnę diagram:

(źr.
(źr. Business Process Trends Associations)

Najniższa war­stwa to imple­men­ta­cja pro­ce­sów, tu dopie­ro mamy wszel­kie szcze­gó­ły takie jak: zakre­sy obo­wiąz­ków, instruk­cje sta­no­wi­sko­we i pod­ręcz­ni­ki użyt­kow­ni­ków, pro­ce­du­ry, wyma­ga­ne umie­jęt­no­ści, kon­kret­ne roz­wią­za­nia np. opro­gra­mo­wa­nie. Są to te ele­men­ty, któ­rych nie umiesz­cza­my na mode­lu pro­ce­sów, bo pro­ce­sy biz­ne­so­we to czyn­no­ści prze­kształ­ca­ją­ce stan wej­ścia w stan wyj­ścia”. Proces biz­ne­so­wy to jeden blo­czek” wraz z jego wej­ściem i wyj­ściem (pro­ces defi­niu­ją te trzy ele­men­ty) na sche­ma­cie blo­ko­wym będą­cym mode­lem (mapą) pro­ce­sów. Bloczek repre­zen­tu­ją­cy czyn­ność (aktyw­ność, kwe­stia nazew­nic­twa), jest abs­trak­cją pro­ce­du­ry, umie­jęt­no­ści, instruk­cji obsłu­gi, itp. W doku­men­ta­cji więc powo­łu­je­my się na te np. pro­ce­du­ry (sto­sow­ne doku­men­ty), a nie odtwa­rza­my ich obraz­ko­wo” na mode­lu pro­ce­sów, bo to pro­wa­dzi po pierw­sze do dublo­wa­nia ist­nie­ją­cej doku­men­ta­cji oraz do strasz­nej kom­pli­ka­cji dia­gra­mów obra­zu­ją­cych procesy.

Problem ten dobrze opi­su­je autor tego artykułu:

One of the key cha­rac­te­ri­stics of archi­tec­tu­re is looking at the ?big pic­tu­re?, but a major chal­len­ge is that we can?t pre­sent the big pic­tu­re on one gre­at big pie­ce of paper ? it has to fit on a sin­gle she­et or model. In order to do that, we have to come up with new con­cepts that sum­ma­ri­ze the ove­rall pic­tu­re into a small num­ber of ele­ments and rela­tion­ships. We can do this thro­ugh a varie­ty of tech­ni­qu­es, like divi­de-and-conqu­er, cate­go­ri­za­tion, gene­ra­li­za­tion, and so on. (BPTrends | Business Archicture: Abstraction in Business Architecture).

Tak więc brak (umie­jęt­no­ści) sto­so­wa­nia abs­trak­cji w mode­lo­wa­niu czy­ni te i inne mode­le (tak­że UMl itp.) nie­czy­tel­ny­mi, trud­ny­mi do inter­pre­ta­cji, kosz­tow­ny­mi w wytwo­rze­niu i potem w utrzy­ma­niu. To ostat­nie powo­du­je, że więk­szość takich doku­men­tów szyb­ko koń­czy życie na pół­kach, bo dez­ak­tu­ali­zu­ją się jak tyl­ko doj­dzie do jakiej­kol­wiek, nawet naj­drob­niej­szej, zmia­ny w orga­ni­za­cji. Co cie­ka­we, bio­rąc pod uwa­gę czas trwa­nia prze­cięt­ne­go wdro­że­nia opro­gra­mo­wa­nia, taki zbyt szcze­gó­ło­wy model nie ma szans być przy­dat­nym w toku takie­go pro­jek­tu, tu rację mają deve­lo­pe­rzy, któ­rzy twier­dzą, że im takie doku­men­ty im w niczym nie pomagają.

No ale te szcze­gó­ły są potrzeb­ne. Owszem pyta­nie: któ­re oraz czy na pew­no musi­my je obraz­ko­wo prze­pi­sy­wać np. z doku­men­tów dzia­łu HR czy jako­ści. W doku­men­to­wa­niu (mode­lo­wa­niu) orga­ni­za­cji sto­su­je­my róż­ne per­spek­ty­wy”, kil­ka pro­stych sche­ma­tów lepiej mode­lu­je orga­ni­za­cję niż jed­ne, na któ­rych ktoś upy­cha wszyst­ko co wie” (jak to robić lepiej opi­sa­łem w arty­ku­le Gdzie są te … szcze­gó­ły).

Tak więc doku­men­to­wa­nie szcze­gó­łów” owszem jest potrzeb­ne, ale nie na dia­gra­mie pro­ce­su. Umiejętności i wie­dza wyko­naw­cy to rola w pro­ce­sie: każ­da powin­na mieć osob­ną doku­men­ta­cję (lub odwo­ła­nie do doku­men­tów w HR). Szczegóły reali­za­cji zadań (czyn­no­ści, aktyw­no­ści) to pro­ce­du­ry, na któ­re zno­wu się powo­łu­je­my, lub takie doku­men­ty jak macierz RACI i spe­cy­fi­ka­cja poli­tyk i reguł biz­ne­so­wych (opi­sa­łem to w arty­ku­le RACI … i wcze­śniej­szym RACI i SIPOC).

I tu mały przty­czek dla spon­so­rów pro­jek­tów zle­ca­ją­cych takie ana­li­zy: żąda­nia wobec ana­li­ty­ka w rodza­ju a ja chcę zoba­czyć jesz­cze to … na tym sche­ma­cie” to zabi­ja­nie pro­jek­tu. Są uzna­ne dobre prak­ty­ki, mię­dzy inny­mi mode­lo­wa­nie od ogó­łu do szcze­gó­łu, sto­so­wa­nie abs­trak­cji i per­spek­tyw. Nikt roz­sąd­ny nie będzie podej­mo­wał prób two­rze­nia pla­nu mia­sta, na któ­rym będą wszyst­kie te rze­czy, któ­re w danym mie­ście są np. przy­stan­ki środ­ków komu­ni­ka­cji publicz­nej, pod­mio­ty gospo­dar­cze, ale tak­że wyso­kość grun­tu, zna­ki dro­go­we, skle­py itp. Taka mapa, zakła­da­jąc jej roz­sąd­ną wiel­kość, była by nie­przy­dat­na, więc żąda­nie takiej od ana­li­ty­ka tak­że nie ma żad­ne­go sensu.

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

Dodaj komentarz

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