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