Zintegrowany ERP: postęp czy cofanie?

Kolejne ana­li­zy przed­się­biorstw za mną, a wraz z nimi obser­wo­wa­ne ste­reo­ty­py i kon­for­mizm wie­lu moich klien­tów. Tym razem kil­ka słów o tym co to jest sys­tem zin­te­gro­wa­ny”. Otóż bar­dzo wie­lu ludzi utoż­sa­mia to poję­cie z współ­dzie­le­niem danych”. Sprzedawcy opro­gra­mo­wa­nia ERP jak man­trę powta­rza­ją nasz sys­tem jest zin­te­gro­wa­ny bo wszyst­kie dane są wspól­ne, więc wszyst­kie infor­ma­cje wpro­wa­dza­ny tyl­ko raz i są wszę­dzie dostęp­ne”. O ERP i inte­gra­cji pisa­łem w Duży ERP czy inte­gra­cja, o idei i wyż­szo­ści inte­gra­cji na pozio­mie usług zamiast współ­dzie­le­nia danych pisa­łem w Wymagania poza­funk­cjo­nal­ne … Teraz popa­trz­my na to od stro­ny archi­tek­tu­ry biznesowej.

Nie ule­ga wąt­pli­wo­ści, że np. pra­co­daw­ca potrze­bu­je danych o nas, o naszym wykształ­ce­niu. Czy to zna­czy, że opty­mal­ne jest, by sys­te­my kadro­wo-pła­co­we współ­dzie­li­ły wszyst­kie dane z urzę­da­mi sta­nu cywil­ne­go i ze szko­ła­mi? Wszyscy wie­my, że po wie­lu latach spę­dzo­nych w szko­łach, mimo ogrom­nej ilo­ści danych szcze­gó­ło­wych o naszej edu­ka­cji, zebra­nych w tych szko­łach, pra­co­daw­cy wystar­czy wyma­ga­ne świa­dec­two jej ukoń­cze­nia oraz nasze imię, nazwi­sko, data i miej­sce uro­dze­nia. Zarówno Szkoła jak i Urząd Stanu Cywilnego mają znacz­nie bogat­sze dane na nasz temat, co nie zna­czy, że inne pod­mio­ty” powin­ny je współ­dzie­lić. Szkoła na żąda­nie wyda odpis świa­dec­twa a Urząd odpis aktu uro­dze­nia (bo nawet nie poszcze­gól­ne oce­ny czy poszcze­gól­ne dane oso­bo­we). Pisząc wcze­śniej o inte­gra­cji wska­zy­wa­łem na korzy­ści mini­ma­li­za­cji inter­fej­sów i sepa­ra­cji danych.

Tak więc mitycz­na inte­gra­cja w sys­te­mach ERP” w rozu­mie­niu wspól­ne dane” to może jed­nak relik­ty tech­no­lo­gii z przed 30/40 lat, kon­for­mizm kupu­ją­cych i opór przed zmia­ną u dostaw­ców? Zaryzykuję tu tezę, że dostaw­cy wie­lu sys­te­mów ERP fun­du­ją nam po pro­stu dług tech­no­lo­gicz­ny. Czy mam rację? Popatrzmy na jed­ne z ostat­nich badań Gartnera:

Omawiając stra­te­gie firm, Gaughan pod­kre­ślił rów­nież zna­cze­nie dzia­ła­ją­cych przy nich ośrod­ków badaw­czych. Ich nad­rzęd­nym celem jest two­rze­nie inno­wa­cji w takich spo­sób, aby ? zacho­wu­jąc pozo­ry roz­wo­ju ? utrzy­my­wać ist­nie­ją­cy stan rze­czy tak dłu­go, jak to tyl­ko moż­li­we.(Czego naj­więk­sze fir­my tech­no­lo­gicz­ne nie mówią swo­im klien­tom?)

O co tu chodzi?

Model rynku i przedsiębiorstwa

Najpierw dla porząd­ku przy­po­mnę poję­cie war­to­ści doda­nej Michaela Portera:

Wartość doda­na pra­cy, to róż­ni­ca postrze­ga­nej war­to­ści ryn­ko­wej pro­duk­tu przed i po wyko­na­niu nad nim pra­cy. Skoro war­tość ryn­ko­wa to kon­se­kwen­cja powsta­ją­cej war­to­ści doda­nej, nie trud­no się domy­ślić, że cena ryn­ko­wa pro­duk­tu tak­że wzro­śnie po jego prze­two­rze­niu”. Powyższy dia­gram poka­zu­je ogól­ną zasa­dę war­to­ści postrze­ga­nej: doko­nu­ją­cy wybo­ru Nabywca wie, że cena towa­ru prze­two­rzo­ne­go jest wyż­sza od ceny towa­ru uzy­ska­ne­go bez­po­śred­nio ze Źródła zaopa­trze­nia. Jeżeli mimo to decy­du­je się na ten droż­szy, ozna­cza to, że dostrze­ga war­tość tego prze­two­rze­nia i jest skłon­ny za to zapła­cić. Przykładem może być to, że dla rowe­rzy­sty stos żela­za i gumy ma jed­nak mniej­szą war­tość niż rower, ryba dostęp­na w skle­pie 800 km od morza ma więk­szą war­tość niż ta sama ryba w tak odda­lo­nym por­cie. Tyle w kwe­stii war­to­ści dodanej.

Popatrzmy teraz na to co się dzie­je w powyż­szym Podmiocie gospo­dar­czym”. Powyższy Podmiot gospo­dar­czy to taka oto struktura:

Przepływ produktów

Podmiot gospo­dar­czy two­rzy war­tość doda­ną poprzez prze­miesz­cze­nie pro­duk­tu w prze­strze­ni i cza­sie (ten sam pro­dukt zosta­je dostar­czo­ny w okre­ślo­ne miej­sce, np. sie­ci dys­try­bu­cji) oraz (lub) wytwa­rza­jąc lub prze­twa­rza­jąc okre­ślo­ne pro­duk­ty (tu pół­pro­duk­ty) lub surow­ce. Generalizując: pod­mio­ty gospo­dar­cze to zło­że­nie (kom­bi­na­cje) wytwa­rza­nia i dys­try­bu­cji. Aby moż­li­we było wytwa­rza­nie, potrzeb­na jest aktyw­ność pole­ga­ją­ca na pro­jek­to­wa­niu. Na dia­gra­mie połą­czo­no to wszyst­ko w pewien okre­ślo­ny ciąg logicz­ny dzia­łań. Z uwa­gi na to, że pro­jek­to­wa­nie z regu­ły nie odby­wa się w spo­sób przy­pad­ko­wy, w spo­sób prze­my­śla­ny zbie­ra­ne są infor­ma­cje z ryn­ku na temat potrzeb Nabywców (ryn­ku).

System informacyjny

Aby moż­li­we było zarzą­dza­nie tym wszyst­kim, koniecz­ne jest śle­dze­nie tych aktyw­no­ści, ich skut­ków i przy­czyn. Śledzenie to nic inne­go jak zbie­ra­nie danych o tym co chce­my wie­dzieć”. Jak mawia­ją spe­cja­li­ści z dzie­dzi­ny zarzą­dza­nia: zarzą­dzać moż­na tyl­ko tym co potra­fi­my mie­rzyć”. O czym mowa? O faktach:

Zarządzanie informacją

Wszystkie aktyw­no­ści pod­mio­tu gospo­dar­cze­go, two­rzą okre­ślo­ne fak­ty, jest nim np. sprze­daż (moment prze­nie­sie­nia wła­sno­ści pro­duk­tu na nabyw­cę), ten fakt jest doku­men­to­wa­ny fak­tu­rą VAT. Oczywiście wie­le takich fak­tów ma miej­sce wewnątrz pod­mio­tu (np. prze­ka­za­nie wytwo­rzo­ne­go pro­duk­tu do maga­zy­nu wyro­bów goto­wych itp.).

Takich fak­tów w fir­mach jest wie­le, jed­nak do celów zarzą­dza­nia nią, kolek­cjo­nu­je­my ich ści­śle okre­ślo­ną licz­bą. To, któ­re fak­ty reje­stru­je­my (zbie­ra­my dane) zale­ży od przy­czy­ny np. pra­wo i podat­ki są przy­czy­ną dokład­ne­go śle­dze­nia fak­tów zwią­za­nych z wszel­ki­mi ope­ra­cja­mi doty­czą­cy­mi kosz­tów dzia­łal­no­ści i przy­cho­dów. Wewnętrzne potrze­by zwią­za­ne z zarzą­dza­niem, są przy­czy­ną zbie­ra­nia (moni­to­ro­wa­nia) kolej­nych szczegółów.

Poza opi­sem fak­tów, kolek­cjo­nu­je­my w róż­nej for­mie, zasa­dy regu­lu­ją­ce to jakie fak­ty mają pra­wo lub muszą zajść: to regu­ły biz­ne­so­we. Zbiór tych danych (opi­sy fak­tów) i ich wza­jem­nej zależ­no­ści to sys­tem infor­ma­cyj­ny: infor­ma­cje o tym co się wyda­rzy­ło. Czego nam tu trosz­kę” bra­ku­je? Tego co nazy­wa­my np. księ­go­wo­ścią czy zarzą­dza­niem kadra­mi (w tym wyna­gro­dze­nia). Jednak one wła­śnie są tyl­ko” narzę­dziem do prze­twa­rza­nia danych o fak­tach. Celowo nie umie­ści­łem na dia­gra­mach tych aktyw­no­ści” bo one są pra­ca­mi pole­ga­ją­cy­mi na śle­dze­niu i moni­to­ro­wa­niu, na spra­woz­daw­czo­ści. Tak na praw­dę wysta­wie­nie fak­tu­ry VAT (opis fak­tu sprze­da­ży) jest czę­ścią aktyw­no­ści jaką jest sprze­daż. Do celów podat­ko­wych potrzeb­ne są tyl­ko zagre­go­wa­ne dane z fak­tur. Itd.

Architektura biznesowa

Wiemy więc już, że Podmiot gospo­dar­czy to okre­ślo­ne aktyw­no­ści: pro­jek­to­wa­nie, wytwa­rza­nia, sprze­daż, zaopa­trze­nie, obsłu­ga pytań” czy­li tak na praw­dę róż­nych spraw” (mogą być jesz­cze inne, zależ­nie od spe­cy­fi­ki pod­mio­tu i bran­ży, np. zarzą­dza­nie pro­jek­ta­mi w fir­mie usłu­go­wej). Każda z tych aktyw­no­ści two­rzy okre­ślo­ne fak­ty, pew­na część danych o nich – bo nie wszyst­kie – mogą być potrzeb­ne na zewnątrz”. Np. spo­śród wszyst­kich szcze­gó­ło­wych infor­ma­cji o reali­za­cji duże­go pro­jek­tu, do roz­li­cze­nia jego koszów i wysta­wie­niu fak­tu­ry, potrzeb­ne są wyłącz­nie okre­ślo­ne zagre­go­wa­ne dane a nie wszyst­kie jakie zna­my. Dotyczy to prak­tycz­nie każ­dej z wymie­nio­nych aktyw­no­ści. Jaki z tego wnio­sek? Nie musi­my współ­dzie­lić w jed­nym miej­scu wszyst­kich danych o poszcze­gól­nych aktyw­no­ściach. Poszczególne aktyw­no­ści prze­ka­zu­ją pomię­dzy sobą tyl­ko swo­je pro­duk­ty, i tyl­ko prze­ka­zy­wa­nie danych je opi­su­ją­ce ma sens. Zarządzanie każ­da aktyw­no­ścią odby­wa się lokal­nie (w niej) i tyl­ko tu jest potrzeb­na peł­na wie­dza”, każ­da z tych aktyw­no­ści to zamknię­ty i względ­nie nie­po­dziel­ny pro­ces two­rze­nia war­to­ści doda­nej (her­me­ty­za­cja) od któ­re­go na zewnątrz wyma­ga­my wyłącz­nie zagre­go­wa­nej infor­ma­cji, udo­stęp­nia­nie nad­mia­ru szcze­gó­łów na zewnątrz nicze­mu nie słu­ży (poza przy­pad­ka­mi gdy część z nich udo­stęp­nia­my do do szcze­gó­ło­wych ana­liz, te jed­nak tak­że wyko­na zewnętrz­ny dedy­ko­wa­ny pod­sys­tem. Prowadzenie roz­li­czeń i spra­woz­daw­czość to kolej­na aktyw­ność, któ­ra tak­że wyma­ga tyl­ko okre­ślo­nych zagre­go­wa­nych danych a nie wszyst­kich jaki­mi dysponujemy”.

Systemy ERP (pier­wot­nie tyl­ko FK, potem MRP i MRPII) powsta­wa­ły jako sys­te­my reje­stru­ją­ce dla okre­ślo­nych pod­mio­tów. W latach 80-tych i 90-tych (wte­dy one powsta­wa­ły), fir­my raczej się roz­ra­sta­ły, ich wewnętrz­na zmien­ność była bli­ska zeru, dla­te­go archi­tek­tu­ra w posta­ci jed­nej dużej rela­cyj­nej bazy danych i zesta­wu funk­cji je prze­twa­rza­ją­cych, mia­ła swo­je uza­sad­nie­nie. Rozwój fir­my wyma­gał prak­tycz­nie tyl­ko doda­wa­nia nowych funk­cji, cza­sem zmia­ny już ist­nie­ją­cych, raczej nie wyma­gał zmian w mode­lu danych.

Opisane wyżej aktyw­no­ści mogą być reali­zo­wa­ne w jed­nym pod­mio­cie, ale mogą to być odręb­ne pod­mio­ty. Dotyczy to tak­że aktyw­no­ści, jaką jest pro­wa­dze­nie roz­li­czeń (np. zewnętrz­ne biu­ro rachun­ko­we, spół­ka zależ­na itp.). Zmienność sytu­acji ryn­ko­wej, zmia­na stra­te­gii, prze­ję­cia, wydzie­la­nie spół­ek zależ­nych, to wszyt­ko ma pra­wo przy­tra­fić się każ­dej fir­mie i orga­ni­za­cji. To zna­czy, że pod­miot gospo­dar­czy może być zło­żo­ny z dowol­ne­go, zmie­nia­ją­ce­go się, zesta­wu powyż­szych aktyw­no­ści. Jaki z tego wniosek?

Skoro powyż­sze aktyw­no­ści są od sie­bie nie­za­leż­ne, takie też powin­no być opro­gra­mo­wa­nie, któ­re pozwa­la nimi zarzą­dzać. Zakup opro­gra­mo­wa­nia, któ­re sta­no­wi jeden, zin­te­gro­wa­ny współ­dzie­le­niem danych, mono­lit to nic inne­go jak zafun­do­wa­nie sobie dłu­gu tech­no­lo­gicz­ne­go w momen­cie pod­ję­cia decy­zji o takim zaku­pie. Żadna fir­ma, dzia­ła­ją­ca w obec­nych cza­sach, nie da sama sobie gwa­ran­cji, że jej wewnętrz­ne aktyw­no­ści nie zmie­nią się co do ich spe­cy­fi­ki, że nie przy­bę­dzie nowych, nie zre­zy­gnu­je z nie­któ­rych. Monolityczny cało­ścio­wy sys­tem ERP sta­no­wi hamu­lec każ­dej takiej zmia­ny. Oparcie cało­ści na cen­tral­nym , współ­dzie­lo­nym modu­le reje­stru­ją­cym (jest z nim z regu­ły księ­go­wość) to nie­mal­że zabe­to­no­wa­nie” archi­tek­tu­ry biz­ne­so­wej firmy.

Skomplikowana sieć aplikacji to kula u nogi działów IT

Bardzo czę­sto spo­ty­kam się w fir­mach z wyma­ga­niem by ana­li­za zawie­ra­ła opis inte­gra­cji”. Brzmi ład­nie jed­nak pod maską” czai się dia­beł”:

Obraz gęstej i coraz bar­dziej sie­ci apli­ka­cji wyła­nia się z bada­nia ponad tysią­ca dyrek­to­rów dzia­łów IT przez fir­mę Capgemini. Taki stan rze­czy obcią­ża depar­ta­men­ty IT i hamu­je trans­for­ma­cję cyfro­wą. (źr. Skomplikowana sieć apli­ka­cji to kula u nogi dzia­łów IT. wnp​.pl | Informatyka. Informatyka dla prze­my­słu.).

Opisze to krót­ko i od końca.

W ofer­tach i pre­zen­ta­cjach dostaw­ców tech­no­lo­gii inte­gra­cyj­nych nie raz zoba­czy­my pięk­ny obra­zek poka­zu­ją­cy jakie to zba­wie­nie nas cze­ka po wdro­że­niu magicz­nie brzmią­ce­go ESB ([[Enterprise Service Bus]]). Z regu­ły ma to taką lub podob­ną postać:

Złożoność systemów IT2

Na dia­gra­mie tym jed­nak spryt­nie” poka­za­łem wyłącz­nie odwo­ła­nia pomię­dzy kom­po­nen­ta­mi uło­żo­ny­mi w gwiaz­dę”, któ­rej cen­trum sta­no­wi ESB, a nie fak­tycz­ny prze­pływ danych. Diagram taki jest ład­ny bo pro­sty a do tego nie kła­mie”. Na czym pole­ga pod­stęp? Na tym, że ESB to wyłącz­nie pośred­nik” w mode­lu komu­ni­ka­cji [[publish-sub­scri­be]].

Tak na praw­dę inte­gra­cja taka pole­ga nie na samym zain­sta­lo­wa­niu ESB i pod­łą­cze­niu” kom­po­nen­tów, to samo z sie­bie nic nie wno­si i nie jest łatwe. Integracja z uży­ciem ESB, to po pierw­sze stwo­rze­nie (lub uży­cie jeże­li ist­nie­je) dla każ­de­go kom­po­nen­tu odpo­wied­nie­go adap­te­ra i API, po dru­gie zapro­jek­to­wa­nie sche­ma­tu (sce­na­riu­szy) komu­ni­ka­cji. Na tym eta­pie jesz­cze nie widać pod­stę­pu. Widać go dopie­ro po odkry­ciu (udo­ku­men­to­wa­niu), z regu­ły, bała­ga­nu archi­tek­to­nicz­ne­go. Bardzo czę­sto komu­ni­ka­cja w takich sie­ciach ma taką postać (poka­za­no tak­że użytkowników):

Złożoność systemów IT22

Tu bar­dzo deli­kat­nie chcia­łem poka­zać coś w rodza­ju nie­mal­że każ­dy z każ­dym”, a mamy tu tyl­ko pięć kom­po­nen­tów (apli­ka­cji). A jak jest ich wię­cej? Bardzo czę­sto kolej­ne nowe apli­ka­cje w fir­mach są kupo­wa­ne i inte­gro­wa­ne cha­otycz­nie, bez prze­my­śla­nej wizji cało­ści archi­tek­tu­ry. Mści się to w póź­niej­szym okre­sie, przy każ­dej pró­bie inge­ren­cji w taką struk­tu­rę (znam przy­pad­ki gdy tak bano się takiej inge­ren­cji, że zanie­cha­no roz­wo­ju IT). To powód, dla któ­re­go wie­le takich wdro­żeń koń­czy się prze­rwa­niem ich (czy­li poraż­ką). Jest to – poraż­ka – pra­wie pew­ne, gdy jako meto­dy inte­gra­cji uży­to współ­dzie­le­nia danych (opi­sa­łem to tu).

W takich pro­jek­tach pierw­szą rze­czą jaką nale­ży zro­bić, to wyko­nać ana­li­zę i opra­co­wać model infor­ma­cyj­ny fir­my, czy­li model tego jakie infor­ma­cje są two­rzo­ne, po co i jak są ze sobą sko­ja­rzo­ne, prze­twa­rza­ne i prze­ka­zy­wa­ne. W dru­gim kro­ku nale­ży usta­lić gdzie są ich wer­sje pier­wot­ne (źró­dło­we, refe­ren­cyj­ne) a gdzie wtór­ne (np. kopie wyko­rzy­sty­wa­ne). Kolejny krok to upo­rząd­ko­wa­nie wymia­ny danych, dopro­wa­dze­nie struk­tu­ry sie­ci do posta­ci hie­rar­chicz­nej (źró­dło refe­ren­cyj­ne i użyt­kow­ni­cy), któ­ra bar­dzo upro­ści powyż­szy model, z regu­ły do postaci:

Złożoność systemów IT

Taka ana­li­za i opty­ma­li­za­cja pozwo­li po pierw­sze w ogó­le opa­no­wać nara­sta­ją­cy lata­mi cha­os, a po dru­gie nie raz odkry­wa się sta­re i nie­uży­wa­ne apli­ka­cje czy dublu­ją­ce się co do ich funk­cjo­nal­no­ści, któ­re po pro­tu wyłą­cza się. Po takich porząd­kach wdro­że­nie ESB owszem wyglą­da jak na pierw­szym dia­gra­mie, jed­nak pro­jekt ma duże szan­se powo­dze­nia, znacz­nie więk­sze w porów­na­niu z inte­gra­cją cha­osu”. Podejście takie nazy­wa­ne jest [[Enterprise appli­ca­tion integration]].

Co cie­ka­we, po takim pro­jek­cie pozo­sta­nie nam doku­men­ta­cja sys­te­mu, któ­rą wystar­czy kon­ser­wo­wać (to nie jest aż tak kosz­tow­ne ale zawsze znacz­nie tań­sze niż kolej­na ana­li­za od zera przy kolej­nym wdro­że­niu). Z taką doku­men­ta­cją już tyl­ko krok do SOA i archi­tek­tu­ry korporacyjnej :).

Bardzo cie­ka­wy arty­kuł doty­czą­cy utrzy­ma­nia lub rezy­gna­cji ze sta­rych apli­ka­cji” zawie­ra COMPUTERWORLD nr 9/2014