Integracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy

Artykuł ma dwie czę­ści. Pierwsza część jest adre­so­wa­na do kadr zarząd­czych, cały arty­kuł (obie czę­ści) do osób zaj­mu­ją­cych się pro­jek­to­wa­niem roz­wią­zań. (22.04.2022 dopi­sa­łem Dodatek).

Wstęp

Mamy ogól­no­świa­to­wą sieć Internet, apli­ka­cje lokal­ne i w chmu­rze, apli­ka­cje naszych kon­tra­hen­tów i apli­ka­cje cen­tral­nych urzę­dów. Wszystkie one współ­pra­cu­ją i wymie­nia­ją dane, czy­li są zin­te­gro­wa­ne. Dlatego inte­gra­cja sta­ła się cechą każ­de­go sys­te­mu infor­ma­tycz­ne­go. Obecnie klu­czo­wym pyta­niem jest: Jak zin­te­gro­wać, a nie: Czy zintegrować. 

Pogodzenie się z tym, że świat już nigdy nie będzie tak pro­sty jak 40 lat temu jest nie­unik­nio­ne. Podobnie jak pogo­dze­nie się z tym, że cza­sy jed­nej cen­tral­nej apli­ka­cji też ode­szły do lamu­sa. Czym jest inte­gra­cja? To wymia­na danych a nie współ­dzie­le­nie: dane z urzę­dem wymie­nia­my, dane z kon­tra­hen­tem wymie­nia­my, nie współ­dzie­li­my żad­nych danych z tymi pod­mio­ta­mi, każ­dy ma swo­je wła­sne, bez­piecz­ne, nie­udo­stęp­nia­ne bazy danych, i to wszyst­ko ład­nie dzia­ła! Idea zbu­do­wa­nia wszyst­kich funk­cjo­nal­no­ści jako zin­te­gro­wa­nej apli­ka­cji na jed­nej współ­dzie­lo­nej bazie danych jest uto­pią. Taką samą jak hipo­te­tycz­na cen­tral­na baza danych dla wszyst­kich skle­pów inter­ne­to­wych, firm kurier­skich i ban­ków, a one są jed­nak zin­te­gro­wa­ne: one wymie­nia­ją dane a nie współdzielą!

ERP to (ang.) Enterprise Resource Planning czy­li Planowanie Zasobów Przedsiębiorstwa. To sys­tem wyko­rzy­sty­wa­ny przez fir­my do zarzą­dza­nia i inte­gro­wa­nia waż­nych ele­men­tów ich dzia­łal­no­ści. Ale kto powie­dział, że to ma być mono­lit od jed­ne­go producenta? 

Nadal spo­ty­kam pejo­ra­tyw­ne okre­śle­nia sys­tem poin­te­gro­wa­ny” jako kry­ty­kę inte­gra­cji. Być może autor tego okre­śle­nia ma na myśli naj­gor­sze prak­ty­ki inte­gra­cji czy­li się­ga­nie do cudzej bazy” lub współ­dzie­le­nie pli­ków na wspól­nym zaso­bie dys­ko­wym”, opi­sa­łem je w dru­giej czę­ści. Pokazałem też jak to robić dobrze czy­li tanio, sku­tecz­nie i niezawodnie… 

Czytaj dalej… Integracja sys­te­mów ERP jako źró­dło prze­wa­gi ryn­ko­wej. Projektowanie REST API i sce­na­riu­szy”

Czy faktycznie powinieneś wdrożyć kompleksowe oprogramowanie?

O inte­gra­cji i uni­ka­niu kasto­mi­za­cji mono­li­tów poprzez wdra­ża­nie dzie­dzi­no­wych pod­sys­te­mów napi­sa­łem tu wie­le. Tym razem kil­ka komen­ta­rzy do krót­kie­go tek­stu pew­ne­go dostaw­cy mono­li­tu ERP. Tekst krót­ki więc cyto­wa­nie sta­no­wi nie­mal­że jego poło­wę ale cóż, pra­wo cyto­wa­nia tre­ści bez­po­śred­nio komentowanych… 

Artykuł

Choć wyspe­cja­li­zo­wa­ne pod kon­kret­ny obszar sys­te­my ofe­ru­ją sze­ro­kie moż­li­wo­ści i naj­ła­twiej je dopa­so­wać do potrzeb orga­ni­za­cji, może oka­zać się, że wraz z roz­wo­jem fir­my prze­sta­ną być efek­tyw­ne. (źr.: 6 prze­sła­nek, któ­re mogą wska­zy­wać, że powi­nie­neś wdro­żyć kom­plek­so­we opro­gra­mo­wa­nie)

Pierwsze zda­nie to praw­da, a dru­gie (zaczy­na­jąc sie od może”) suge­ru­je, że nie zawsze. Popatrzmy jak autor argu­men­tu­je dru­gie zda­nie, pisząc że sys­te­my wyspe­cja­li­zo­wa­ne wraz z roz­wo­jem fir­my prze­sta­ną być efek­tyw­ne” (wszyst­kie cyta­ty z powyż­sze­go źródła).

1. Nieefektywna inte­gra­cja danych
Stosowanie kil­ku roz­wią­zań infor­ma­tycz­nych wią­że się z koniecz­no­ścią zapew­nie­nia sku­tecz­nej wymia­ny danych pomię­dzy nimi. Zazwyczaj nie jest ona tak efek­tyw­na jak w przy­pad­ku jed­ne­go sys­te­mu z róż­ny­mi modułami. 

Niestety nie jest to praw­da. Poziom stan­da­ry­za­cji inter­fej­sów od daw­na pozwa­la robić to w spo­sób nie­zau­wa­żal­ny dla użyt­kow­ni­ka. Powiem tyl­ko tyle, że każ­dy zgod­ny z pra­wem sys­tem ERP/FK wysy­ła dane (JPK) do sys­te­mów rzą­do­wych, bez potzre­by żad­nej ręcz­nej inte­gra­cji, i nie ma z tym żad­ne­go pro­ble­mu. Dla czy­tel­ni­ków, któ­rzy tego nie wie­dzą, infor­ma­cja: każ­de pobra­nie gotów­ki z ban­ko­ma­tu czy też doko­na­nie płat­no­ści kar­tą płat­ni­czą w skle­pie, to każ­do­ra­zo­wo wynik współ­ra­cy (inte­gra­cja) co naj­mniej kil­ku­na­stu zin­te­gro­wa­nych sys­te­mów co naj­mniej kil­ku firm i insty­tu­cji. Warto też wie­dzieć, że dane z róż­nych dzie­dzin bar­dzo czę­sto nie są moż­li­we do umiesz­cze­nia w jed­nej i tej samej bazie danych (to zresz­tą głów­ne źró­dło pro­ble­mów kasto­mi­za­cji sys­te­mów mono­li­tycz­nych), for­so­wa­nie archi­tek­tu­ry mono­li­tycz­ne jest wręcz wyso­ce szko­dli­we .

Dostęp do wszyst­kich doku­men­tów i danych w jed­nym cen­tral­nym sys­te­mie pozwa­la księ­go­wo­ści na dokład­ną ana­li­zę w cza­sie zbli­żo­nym do rze­czy­wi­ste­go, a to umoż­li­wia lep­sze zarzą­dza­nie finan­sa­mi całej organizacji.

Dowody księ­go­we (pod­sta­wo­we doku­men­ty w FK/ERP) sta­no­wią mniej niż 20% wszyst­kich doku­men­tów ope­ra­cyj­nych, resz­ta i tak jest poza ERP. To co widzi­my jako doku­men­ty w sys­te­mach ERP (np. Faktura) to tak na praw­dę rapor­ty ad-choc z tych baz danych, nie ma tam ŻADNYCH doku­men­tów. Aby były, nale­ży jest dodat­ko­wo archi­wi­zo­wać jako pli­ki PDF i/lub XML. 

2. Błędy i opóź­nie­nia
W przy­pad­ku koniecz­no­ści ręcz­ne­go wpro­wa­dza­nia danych do kil­ku sys­te­mów, przed­się­bior­stwo nara­ża się na opóź­nie­nia, a tak­że błędy. 

Nie ma takiej potrze­by w śro­do­wi­sku zin­te­gro­wa­nym. Integracja kil­ku róż­nych dzie­dzi­no­wych sys­te­mów mię­dzy słu­ży temu, by nie wpro­wa­dzać doku­men­tów wię­cej niż raz. 

3. Systemy od róż­nych dostaw­ców
Choć w codzien­nej pra­cy może nie sta­no­wić to duże­go utrud­nie­nia, w przy­pad­ku jakiej­kol­wiek awa­rii sys­te­mów, fakt, że pocho­dzą od róż­nych dostaw­ców, może być kło­po­tli­wy. Wiąże się bowiem z koniecz­no­ścią skon­tak­to­wa­nia z kil­ko­ma oso­ba­mi, żeby móc roz­wią­zać problem. 

Jest dokład­nie odwrot­nie: jak sie zepsu­je mono­lit to NIC nie dzia­ła. Jak awa­rii ule­gnie jeden z pod­sys­te­mów dzie­dzi­no­wych, resz­ta dzia­ła popraw­nie, co jest dla odmia­ny OGROMNĄ zale­tą roz­pro­szo­nej archi­tek­tu­ry. Kontaktujemy się wyłącz­nie z admi­ni­stra­to­rem tego co nie dzia­ła. Poprawnie wyko­na­na inte­gra­cja to tak­że sepa­ra­cja skut­ków takich awarii. 

4. Utrudnienie dla pra­cow­ni­ków
Korzystanie z kil­ku sys­te­mów może sta­no­wić dodat­ko­we wyzwa­nie dla pra­cow­ni­ków, któ­rzy muszą nauczyć się pra­cy na zróż­ni­co­wa­nym opro­gra­mo­wa­niu, czę­sto z inny­mi funk­cjo­nal­no­ścia­mi, inter­fej­sem i spo­so­bem działania. 

To tak­że nie jest praw­da: sys­te­my dzie­dzi­no­we, jak sama nazwa wska­zu­je, są adre­so­wa­ne do okre­ślo­nych grup zawo­do­wych czy kom­pe­ten­cji. Jeżeli gdzie­kol­wiek poja­wia się wyżej opi­sa­na sytu­acja, to jest to raczej sku­tek bała­ga­nu, któ­ry nale­ży upo­rząd­ko­wać przed wdrożeniem. 

5. Nadmierne obcią­że­nie dzia­łów IT
Korzystając z wie­lu roz­wią­zań infor­ma­tycz­nych, koniecz­ne jest stwo­rze­nie zespo­łu IT, któ­ry będzie miał odpo­wied­nią wie­dzę i doświad­cze­nie w każ­dym z nich. 

Kolejna nie­praw­da: dział IT z zasa­dy zaj­mu­je się admi­ni­stra­cją a nie roz­wo­jem tych apli­ka­cji. Za utrzy­ma­nie i roz­wój odpo­wia­da dostaw­ca pro­gra­mo­wa­nia w ramach sta­łej corocz­nej opła­ty i licencji.

6. Utrudniona orga­ni­za­cja pra­cy z domu
Wciąż wie­le firm pra­cu­je w try­bie home offi­ce, co wyma­ga od przed­się­biorstw zapew­nie­nia dostę­pu do wszyst­kich koniecz­nych do pra­cy sys­te­mów, infor­ma­cji czy doku­men­tów. Nie wszyst­kie apli­ka­cje są dosto­so­wa­ne do pra­cy poza biurem. 

Owszem, sta­re i wie­ko­we sys­te­my ERP w archi­tek­tu­rze klient/serwer się do tego prak­tycz­nie nie nada­ją. Każdy nowo­cze­sny sys­tem, to w cało­ści dostęp­na przez prze­glą­dar­kę apli­ka­cja, z któ­rą pra­co­wać moż­na gdziekolwiek. 

Obserwujemy, że nie­któ­re fir­my oba­wia­ją się zmian, nawet gdy roz­wią­za­nia, z któ­rych korzy­sta­ją, nie w peł­ni speł­nia­ją ich potrze­by lub są już nie­co prze­sta­rza­łe. Często myślą o wyso­kich kosz­tach kom­plek­so­wych sys­te­mów. I choć rze­czy­wi­ście, koniecz­na jest inwe­sty­cja finan­so­wa i cza­so­wa, to utrzy­ma­nie jed­ne­go roz­wią­za­nia zamiast kil­ku mniej­szych jest w dłuż­szej per­spek­ty­wie kosz­to­wo bar­dziej opłacalne. 

To tak­że jest nie­praw­da, choć­by dla­te­go, że wdra­ża­nie dedy­ko­wa­nych pod­sys­te­mów dzie­dzi­no­wych nie wyma­ga żad­nych kasto­mi­za­cji dla­te­go i wdro­że­nie i póź­niej upgra­de są znacz­nie tań­sze niż wdro­że­nie i dosto­so­wa­nie monolitu. 

Podsumowanie

Nie raz myśla­łem, że nie będę już musiał pisać takich arty­ku­łów ale zno­wu jest oka­zja. Nie raz pisa­łem, że dostaw­cy sys­te­mów ERP, bar­dzo czę­sto, bez żad­nych skru­pu­łów wyko­rzy­stu­ją nie­wie­dzę swo­ich klien­tów. Tu mamy kolej­ny taki przy­kład. Nawet jeże­li ist­nie­ją tak złe wdro­że­nia, że arty­kuł ten mówi praw­dę, to jest to tyl­ko opis wyjąt­ko­wych złych wdrożeń. 

Pisanie, że Choć wyspe­cja­li­zo­wa­ne pod kon­kret­ny obszar sys­te­my ofe­ru­ją sze­ro­kie moż­li­wo­ści i naj­ła­twiej je dopa­so­wać do potrzeb orga­ni­za­cji, może oka­zać się, że wraz z roz­wo­jem fir­my prze­sta­ną być efek­tyw­ne.” jest szko­dli­wą manipulacją. 

Źródła

Martin Fowler. (2014). bli­ki: BoundedContext [Martinfowler​.com]. Martinfowler​.Com. https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​B​o​u​n​d​e​d​C​o​n​t​e​x​t​.​h​tml

Dyrektorzy mówią Dość! Biznes wychodzi z objęć monolitycznego systemu ERP

Krótki wstęp

Od cza­su do cza­su są takie momen­ty, że świat pod­su­wa mi goto­we tek­sty do publi­ka­cji. Każdy kto mnie zna i czy­ta wie, że od lat odra­dzam wdra­ża­nie wiel­kich mono­li­tów ERP, uza­sad­nie­nie tego z moich ust naj­czę­ściej jest jed­nak odbie­ra­ne jako moje spe­ku­la­cje (mimo, że zawsze uza­sad­niam swo­je zda­nie a przy­kła­dów nie bra­ku­je). A o tym sądzą dyrek­to­rzy firm?

Czytaj dalej… Dyrektorzy mówią Dość! Biznes wycho­dzi z objęć mono­li­tycz­ne­go sys­te­mu ERP”
SOA

Modelowanie w projektach integracyjnych

Projekty inte­gra­cyj­ne w śro­do­wi­sku zło­żo­nych (kil­ka­dzie­siąt apli­ka­cji) sys­te­mów nale­żą do bar­dzo trud­nych z uwa­gi na ich zło­żo­ność. Z pomo­cą przy­cho­dzi nam SOA jako model poję­cio­wy i ESB jako wzo­rzec archi­tek­tu­ry. Referat, wygło­szo­ny na kon­fe­ren­cji GigaCon, opi­su­je pro­ces ana­li­zy i mode­lo­wa­nia w toku spe­cy­fi­ko­wa­nia wyma­gań na ESB i interfejsy.

Poniżej struk­tu­ra archi­tek­tu­ry SOA na bazie stan­dar­dów OMG:

SOA_OMG_model

Kluczowe poję­cia:
– pro­ce­sy biz­ne­so­we, ele­men­tar­ne aktyw­no­ści, któ­ra wraz z wej­ściem i wyj­ściem sta­no­wią ele­men­tar­ny pro­ces biznesowy,
– usłu­ga biz­ne­so­wa (tak­że apli­ka­cyj­na) to przy­pa­dek uży­cia danej apli­ka­cji (apli­ka­cja świad­czy usłu­gi, każ­da usłu­ga ma stan począt­ko­wy, pro­dukt i sce­na­riusz realizacji),
– kom­po­nent, repre­zen­tu­je inte­gro­wa­ne aplikacje.

Treść pre­zen­ta­cji:

Polecam, kto nie czy­tał, ubie­gło­rocz­ny arty­kuł o integracji. 

Na koniec, dla zain­te­re­so­wa­nych SoaML (pro­fil UML do mode­lo­wa­nia integracji):
spe­cy­fi­ka­cja na stro­nie OMG
tuto­rial na stro­nie Visual-Paradigm

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