Generalnie mode­le refe­ren­cyj­ne mają i dobrą i złą sła­wę. Nie są to wzor­ce pro­jek­to­we, czy­li dobre prak­ty­ki w posta­ci uni­wer­sal­nych abs­trak­cyj­nych meta-mode­li, są to naj­czę­ściej narzu­ca­ne goto­we archi­tek­tu­ry, pozo­sta­je pyta­nie: kto narzuca?. 

Procesy refe­ren­cyj­ne kry­ty­ko­wa­łem nie raz (Procesy refe­ren­cyj­ne czy­li kto żyw niech ucie­ka), refe­ren­cyj­ny model ERP ozna­czał­by, że ist­nie­je jakaś jedy­nie słusz­na archi­tek­tu­ra sys­te­mu ERPII. I wła­śnie dostaw­cy wie­lu sys­te­mów ERPII (szcze­gól­nie ci duzi, któ­rych pro­duk­ty mają wie­le lat) pro­mu­ją model opar­ty o jed­ną wspól­ną rela­cyj­ną bazę danych, wokół któ­rej są osa­dzo­ne dzie­dzi­no­we modu­ły, nazy­wa­ją taki model mode­lem refe­ren­cyj­nym. Biorąc pod uwa­gę fakt, że sys­te­my te wszyst­kie tak dzia­ła­ją, moż­na taki model nazwać refe­ren­cyj­nym w tej kate­go­rii. Promowana jest tu inte­gra­cja poprzez współ­dzie­le­nie danych. Taka inte­gra­cja jest nie­ste­ty kry­ty­ko­wa­nym od lat mono­li­tem, któ­ry jest też przy­czy­ną wie­lu nie­po­wo­dzeń wdro­żeń: wpro­wa­dza­nie jakich­kol­wiek zmian do takie­go sys­te­mu jest zawsze inge­ren­cją w cały sys­tem. Zarówno na moim blo­gu jak i w sie­ci zna­leźć moż­na wie­le mate­ria­łów na ten temat (np. Monolity vs. …).

Więc jak inaczej?

Wewnętrzny łańcuch wartości

Zacznijmy od przy­po­mnie­nia, uzna­wa­ne­go nadal za stan­dard, mode­lu wewnętrz­ne­go łań­cu­cha war­to­ści M.E.Portera :

Model ten dzie­li pro­ce­sy wewnątrz orga­ni­za­cji na dwie gru­py: wspie­ra­ją­ce i ope­ra­cyj­ne. Procesy wspie­ra­ją­ce to pro­ce­sy zapew­nia­ją­ce orga­ni­za­cji zaso­by nie­zbęd­ne do dzia­ła­nia. Procesy ope­ra­cyj­ne, to pro­ce­sy two­rzą­ce war­tość doda­ną pro­duk­tów i usług w ryn­ko­wym łań­cu­chu war­to­ści (to jaką war­tość doda­ną wno­si dana orga­ni­za­cja na ryn­ku). Schematycznie przed­sta­wio­no to poniżej: 

Marża budo­wa­na jest zarów­no w obsza­rze pro­ce­sów wspie­ra­ją­cych (mini­ma­li­zu­jąc kosz­ty sta­łe) jak i w obsza­rze pro­ce­sów ope­ra­cyj­nych (mar­ża na pro­duk­tach i usłu­gach czy­li wła­snej inwen­cji two­rzą­cej war­tość doda­ną na ryn­ku). W obsza­rze pro­ce­sów wspie­ra­ją­cych może­my kon­ku­ro­wać prak­tycz­nie tyl­ko w wewnętrz­nej efek­tyw­no­ści. W tym obsza­rze pro­ce­sy biz­ne­so­we i infor­ma­cje są dość ści­śle regu­lo­wa­ne pra­wem (księ­go­wość i finan­se, zatrud­nie­nie i wyna­gro­dze­nia, itp.). Zbudowanie tu prze­wa­gi ryn­ko­wej jest bar­dzo trud­ne, gdyż pra­wo doty­czy wszyst­kich pod­mio­tów – czy­li kon­ku­ren­tów tak­że – w jed­na­ko­wym stopniu. 

W obsza­rze pro­ce­sów ope­ra­cyj­nych mamy jed­nak nie­mal­że peł­ną swo­bo­dę. To tu budu­je­my war­tość doda­ną jaką jest ofe­ro­wa­ny pro­dukt lub usłu­ga (być może są one uni­kal­ne, chro­nio­ne pra­wem autor­skim lub paten­tem). Na pod­sta­wie powyż­sze­go moż­na stwo­rzyć pewien wzo­rzec: meta-model pro­ce­sów biz­ne­so­wych organizacji. 

Meta-model ten zbu­do­wa­ny został jako sys­tem pro­ce­sów end-2-end, czy­li pro­ce­sów, gdzie wej­ścia i wyj­ścia to zda­rze­nia na sty­ku orga­ni­za­cji z jej oto­cze­niem. W tej lub podob­nej posta­ci, dia­gram ten był nie raz oma­wia­ny na tym blo­gu, dla­te­go tu tyl­ko kil­ka ogól­nych uwag. 

W zależ­no­ści od spe­cy­fi­ki danej orga­ni­za­cji, poka­za­ne tu pro­ce­sy mogą wystę­po­wać jako mniej lub bar­dziej wewnętrz­nie roz­bu­do­wa­ne (mode­lu­je­my je pre­cy­zyj­nie z uży­ciem nota­cji BPMN), nie­któ­re mogą nie wystą­pić (np. fir­ma usłu­go­wa nie ma pro­duk­cji). Gdyby był to urząd, w miej­scu Obsługi zamó­wień poja­wi się obsłu­ga podań i decy­zje admi­ni­stra­cyj­ne (i podob­ne). To pro­ce­sy ope­ra­cyj­ne. Procesy wspie­ra­ją­ce, w tym obsłu­ga rachun­ko­wo­ści i zaso­by oso­bo­we, to cecha każ­dej orga­ni­za­cji czy urzę­du. Nawiązując do archi­tek­tu­ry biz­ne­so­wej, powyż­szy model to war­stwa środ­ko­wa na poniż­szym dia­gra­mie obra­zu­ją­cym pozio­my opi­su orga­ni­za­cji .

System informacyjny

Pewnym zasko­cze­niem dla czy­tel­ni­ka naj­praw­do­po­dob­niej będzie to, że archi­tek­tu­ra opro­gra­mo­wa­nia wca­le nie musi odwzo­ro­wy­wać powyż­szej mapy pro­ce­sów. Zaryzykuje tezę, że nie mia­ło by to sen­su. Dlaczego? Bo apli­ka­cje to narzę­dzia prze­twa­rza­ją­ce dane a nie uczest­ni­cy pro­ce­sów. pro­ce­sy biz­ne­so­we są nie­za­leż­ne od sys­te­mów IT .

Modelowanie sys­te­mów IT jako torów w mode­lach pro­ce­sów to jeden z naj­częst­szych błę­dów w analizach!

Po dru­gie pro­ce­sy biz­ne­so­we sku­pia­ją się na tre­ści doku­men­tów i celu ich two­rze­nia, apli­ka­cje trak­tu­ją je ina­czej: ich deta­licz­na treść ma zna­cze­nie tyl­ko cza­sa­mi i rzad­ko kie­dy cała. Dokumenty two­rzo­ne są w apli­ka­cjach dzie­dzi­no­wych, bar­dzo czę­sto, po powsta­niu, ich treść prze­twa­rza­na jest w innym pro­ce­sie i w innym celu. Nie każ­dy doku­ment ma ści­słą struk­tu­rę. Np. dowo­dy księ­go­we to ści­śle struk­tu­ral­ne doku­men­ty i powsta­ją w dedy­ko­wa­nych apli­ka­cjach, jed­nak zarów­no zapy­ta­nia, ofer­ty czy rekla­ma­cje, tak­że np. umo­wy (w tym umo­wy o pra­cę), to doku­men­ty o dość swo­bod­nej struk­tu­rze i zarzą­dza­my nimi raczej z pomo­cą wybra­nych ich cech (meta­da­ne), bar­dzo rzad­ko ktoś poza czło­wie­kiem wczy­tu­je się w ich treść (maszy­na nie). W efek­cie archi­tek­tu­ra sys­te­mu infor­ma­tycz­ne­go nie będzie odwzo­ro­wy­wa­ła mapy pro­ce­sów, mimo tego, że intu­icyj­nie takie są ocze­ki­wa­nia od dostaw­ców analiz

Narzędzia w skrzyn­ce narzę­dzio­wej sto­la­rza nie noszą nazw eta­pów pro­duk­cji mebli! Aplikacje to dzie­dzi­no­we narzę­dzia pra­cy, przy czym dzie­dzi­ną nie są tu pro­ce­sy biz­ne­so­we (cel biz­ne­so­wy) a struk­tu­ra danych i ich zna­cze­nie. Innymi sło­wy zarów­no wnio­ski urlo­po­we jak i zapy­ta­nia od klien­tów, to prze­pływ pra­cy i archi­wum doku­men­tów. Wystawienie fak­tu­ry czy doku­men­tu maga­zy­no­we­go, to two­rze­nie spe­cja­li­stycz­nych for­mu­la­rzy, jed­nak ich dal­sze prze­ka­zy­wa­nie (albo przyj­mo­wa­nie np. fak­tur kosz­to­wych) to już tak­że prze­pływ pra­cy i zarzą­dza­nie doku­men­ta­mi jako byta­mi archi­wal­ny­mi. Tu dzie­dzi­no­wość nie pole­ga na tym co i po co robi­my (pro­ce­sy biz­ne­so­we) a na tym, jakie­go rodza­ju dane prze­cho­wu­je­my i prze­twa­rza­my (meta­da­ne). Np. Faktura dla klien­ta, ramo­wa umo­wa na raba­ty z nim, jego rekla­ma­cje, to histo­ria kon­tak­tów z tym klien­tem. Detale struk­tur tych doku­men­tów nie maja tu zna­cze­nia (nie są po raz dru­gi ani zmie­nia­ne ani wery­fi­ko­wa­ne, te doku­men­ty już powsta­ły w apli­ka­cjach im dedy­ko­wa­nych). Dlatego pew­nym ogól­nym wzor­cem archi­tek­tu­ry sys­te­mu IT orga­ni­za­cji, będzie poniż­szy dia­gram :

Można to z powo­dze­niem nazwać: System ERP II. Nie jest to mono­lit, wdra­żać moż­na te modu­ły prak­tycz­nie w dowol­nej kolej­no­ści, są zin­te­gro­wa­ne, dane wpro­wa­dza­my tyl­ko raz. Obecna na ryn­ku stan­da­ry­za­cja powo­du­je, że inte­gra­cja nie sta­no­wi pro­ble­mu. Modułów tych może być wię­cej, a wdro­że­nie takie na pew­no moż­na nazwać zwinnym. 

Na zakończenie

Obserwacja ryn­ku poka­zu­je, że podaż dedy­ko­wa­nych modu­łów jest bar­dzo duża, wybór jed­ne­go mono­li­tycz­ne­go sys­te­mu – mimo, że nadal popu­lar­ny – jest dzi­siaj nie­ra­cjo­nal­ny, choć­by z uwa­gi na zmien­ność i ryn­ku i pro­fi­li dzia­ła­nia firm oraz zmien­ność pra­wa. Drugim powo­dem, dla któ­re­go decy­do­wa­nie się na mono­li­tycz­ne sys­te­my jest dużym ryzy­kiem, jest to, że jest to tak­że decy­zja o ​„wdra­ża­niu wszyst­kie­go naraz i z jed­ne­go źró­dła”, co bar­dzo rzad­ko ma obec­nie sens i sta­no­wi ogrom­ne ryzy­ko .

Źródła