Od cza­su do cza­su poja­wia­ją się w sie­ci woła­nia będą­ce czymś co ja nazy­wam anty refe­ren­cja­mi. W więk­szo­ści zna­nych mi przy­pad­ków jest to wina dostaw­cy, który:

1. zobo­wią­zał się do reali­za­cji wyma­gań nie testu­jąc ich wykonalności,
2. zobo­wią­zał się do wdro­że­nia ofe­ro­wa­ne­go roz­wią­za­nia bez wyko­na­nia (posia­da­nia) rze­tel­ne­go audy­tu biz­ne­so­we­go (kom­pu­te­ry­za­cja bała­ga­nu) u klienta.

Tłumaczenia w rodza­ju ​„bo klient nie wie cze­go chce” są jedy­nie wyra­zem nie­kom­pe­ten­cji dostaw­cy w obsza­rze ana­li­zy przed-wdro­że­nio­wej.

Oto przy­kład takie­go ​„woła­nia” z Lipca 2016 i pró­ba wyja­śnie­nia tych zgło­szo­nych pro­ble­mów (z oczy­wi­stych powo­dów zanonimizowane).

Od sierp­nia 2014 r. moja fir­ma – jako Zamawiający jest bene­fi­cjen­tem dofi­nan­so­wa­nia UE PARP 8.2 PO IG – dzia­ła­nie 8.2 i co za tym idzie kom­plek­so­we­go wdro­że­nia opro­gra­mo­wa­nia XXX kla­sy ERP dostar­czo­ne­go przez XXX. Za wdro­że­nie opro­gra­mo­wa­nia odpo­wie­dzial­na jest fir­ma XXX, któ­rej zespół do dnia dzi­siej­sze­go zma­ga się z wdro­że­niem oraz jego skut­ka­mi tech­nicz­ny­mi i eko­no­micz­ny­mi.
Poniżej załą­czam głów­ne tech­nicz­ne pro­ble­my, z któ­ry­mi spo­tka­li­śmy się pod­czas wdro­że­nia XXX:…

Architektura monolitycznych systemów ERP

Zanim jed­nak przy­stą­pi­my do wyja­śnień, kil­ka słów o archi­tek­tu­rze mono­li­tycz­nych sys­te­mów ERPII (taki jest tu wdra­ża­ny). Używam tu nazwy mono­lit, gdyż mimo dekla­ro­wa­ne­go podzia­łu na modu­ły, tych sys­te­mów, są one mono­li­tem zbu­do­wa­nym na jed­nej współ­dzie­lo­nej bazie danych. To co nazy­wa­ne jest tu modu­łem, to wydzie­lo­ne lecz nie roz­łącz­ne, ele­men­ty logi­ki biz­ne­so­wej. Poniżej uprosz­czo­na archi­tek­tu­ra sys­te­mu ERP dla fir­my pro­duk­cyj­nej (uprosz­cze­nie doty­czy wyłącz­nie gra­da­cji i ilo­ści modu­łów sys­te­mu ERPII).

Na dia­gra­mie po lewej poka­za­ne są pod­sys­te­my dzie­dzi­no­we, któ­re prak­tycz­nie nie wystę­pu­ją w ofe­ro­wa­nych na ryn­ku ERP. Prawa stro­na to typo­wa archi­tek­tu­ra mono­li­tycz­ne­go sys­tem ERPII. Jej klu­czo­we cechy to:

1. jed­na mono­li­tycz­na baza danych zawie­ra­ją­ca znor­ma­li­zo­wa­ną logi­kę związ­ków mię­dzy dany­mi i i ch współdzielenie,
2. modu­ły dzie­dzi­no­we zawie­ra­ją­ce wyłącz­nie logi­kę prze­twa­rza­nia tych danych,
3. jed­no­li­ty inter­fejs użytkownika.

Ważna, rzecz: Rachunkowość finan­so­wa to szkie­let bazy danych (dowo­dy księ­go­we i pozo­sta­łe zda­rze­nia gospo­dar­cze). Taka archi­tek­tu­ra powo­du­je, że:

1. modu­ły obsłu­gu­ją­ce zda­rze­nia gospo­dar­czej (co naj­mniej rachun­ko­wość, maga­zy­ny) są obli­ga­to­ryj­ne, czy­li zawsze muszą być wdro­żo­ne i zawsze jako pierwsze),
2. pew­ne ele­men­ty logi­ki są nie­mo­dy­fi­ko­wal­ne (logi­ka związ­ków pomię­dzy dany­mi jest w cen­tral­nej bazie danych, ta zaś jest prak­tycz­nie niemodyfikowalna),
3. mody­fi­ko­wa­nie logi­ki zwią­za­nej z prze­twa­rza­niem danych wyma­ga inge­ro­wa­nia w skom­pli­ko­wa­ny kod ist­nie­ją­cych modu­łu, skut­ki tych zmian mogą się prze­no­sić na pozo­sta­łe modu­ły (poprzez współ­dzie­lo­ne dane),
4. współ­dzie­le­nie danych (np. pomię­dzy zamó­wie­niem a fak­tu­rą) powo­du­je, że zmia­ny w zasad­ni­czej tre­ści doku­men­tów i ich logi­ka są prak­tycz­nie niemożliwe,
5. moż­li­we two­rze­nie (mody­fi­ko­wa­nie) nowej logi­ki biz­ne­so­wej jest ogra­ni­czo­ne do tego, co nie koli­du­je z mode­lem danych w cen­tral­nej bazie danych.

To tyl­ko klu­czo­we ogra­ni­cze­nia. Większe wdro­że­nia nie unik­ną inte­gra­cji z uwa­gi na to, że takie funk­cjo­nal­no­ści jak PLM (zarza­dza­nie cyklem życia pro­duk­tów), MES (moni­to­ro­wa­nie pro­duk­cji) czy APS (Advaced Planing System) nie są dostęp­ne w ramach ERPII, więc bar­dzo czę­sto nie jest praw­dą, że sam sys­tem ERPII wystarczy.

Skutki kastomizacji

Popatrzmy teraz na zgła­sza­ne problemy:

- wada nie­sta­bil­nych cen zaku­pu towa­rów, błąd ceny zej­ścia towa­ru na WZ, błęd­ne ceny na prze­su­nię­ciach i przy­ję­ciach na maga­zyn, błąd – ceny wyda­nia i przy­ję­cia na maga­zy­nach MM minus / MM plus. Przykładowo ten sam towar po prze­su­nię­ciu na inny maga­zyn z nie­wia­do­mych przy­czyn zmie­nia swo­ją cenę zaku­pu. Wada zwią­za­na z błęd­ny­mi cena­mi nie pozwa­la na pra­wi­dło­we usta­le­nie war­to­ści poszcze­gól­nych maga­zy­nów fir­my
- wada sald kon­tra­hen­tów zwią­za­na z poda­wa­niem błęd­nej wyso­ko­ści zadłu­że­nia klien­ta,
- wada nie­sta­bil­ne­go obsza­ru rapor­tów ? rapor­ty two­rzo­ne według tych samych para­me­trów przed­sta­wia­ją róż­ne dane, przy­kła­do­wo 3 rapor­ty doty­czą­ce sta­nu tego same­go maga­zy­nu przed­sta­wia­ją 3 róż­ne kwoty,

Są to naj­praw­do­po­dob­niej efek­ty tego, że inge­ren­cja w logi­kę poszcze­gól­nych modu­łów spo­wo­do­wa­ła błę­dy. Związki mię­dzy doku­men­ta­mi maga­zy­no­wy­mi i ich ewen­tu­al­ne współ­dzie­le­nie z inny­mi (np. PZ, MM, WZ) są wbu­do­wa­ne w bazę danych, wyli­cze­nia zaś tkwią w modu­łach dziedzinowych. 

Zmiany wpro­wa­dza­ne lokal­nie w poszcze­gól­nych modu­łach mogą burzyć logi­kę modu­łów współ­dzie­lą­cych te dane. Kolizja wyli­czeń i logi­ki danych w bazie danych z regu­ły wpły­wa destruk­cyj­nie na rapor­ty z tych danych.

Powyższe bra­ki i wady nie wyczer­pu­ją dłu­giej listy pro­ble­mów (ok. 200) spo­wo­do­wa­nych moim zda­niem niskim przy­go­to­wa­niem mery­to­rycz­nym spe­cja­li­stów z cen­tra­li XXX oraz z fir­my wdro­że­nio­wej XXX.

Naszym głów­nym pro­ble­mem w pra­cy na opro­gra­mo­wa­niu XXX, wie­lo­krot­nie prze­ja­wia­ją­cym się w cią­gu kil­ku ostat­nich mie­się­cy, jest brak sta­bil­no­ści opro­gra­mo­wa­nia, w szcze­gól­no­ści w pod­sta­wo­wych modu­łach jaki­mi są Sprzedaż i Zarządzanie Zapasami. Jedna z naj­waż­niej­szych wad opro­gra­mo­wa­nia mani­fe­stu­je się zja­wi­skiem nie­kon­tro­lo­wa­nej zmia­ny cen towa­rów w róż­nych loka­li­za­cjach maga­zy­no­wych, obja­wia­ją­cym się zwięk­sza­niem lub zmniej­sza­niem cen bez żad­ne­go logicz­ne­go powodu.

Powyższe potwier­dza skut­ki inge­ren­cji opi­sa­ne powyżej.

Prace mają­ce na celu usu­nię­cie tej wady nie przy­nio­sły dotąd spo­dzie­wa­nych efek­tów, pomi­mo zaan­ga­żo­wa­nia w nie rów­nież pro­du­cen­ta opro­gra­mo­wa­nia. Doraźne napra­wy nie pozwa­la­ły na korek­tę naro­słych wcze­śniej błę­dów w księ­go­wo­ści fir­my. Straty fir­my pole­ga­ją m. in. na błę­dach w sto­so­wa­nej mar­ży – utra­cie klien­tów lub zysku, koniecz­no­ści pro­wa­dze­nia cią­głych i absor­bu­ją­cych inwen­ta­ry­za­cji, błę­dach wysy­łek, dodat­ko­wych kosz­tach pra­cy, co wprost prze­kła­da się na spa­dek obro­tów oraz wzrost kosz­tów działalności.

Obawiam się, że powyż­sze pro­ble­my są nie do roz­wią­za­nia. Nieprzemyślana (a nie raz po pro­stu nie­moż­li­wa do wyko­na­nia) tak zwa­na kasto­mi­za­cja, to nic inne­go pró­ba bez­kar­ne­go wpro­wa­dza­nia lokal­nych zmian do kodu liczą­ce­go nie raz milio­ny linii.

Moim zda­niem opro­gra­mo­wa­nie XXX nie zosta­ło pra­wi­dło­wo przy­go­to­wa­ne do wpro­wa­dze­nia na rynek pol­ski. Po zain­sta­lo­wa­niu oka­za­ło się, że opro­gra­mo­wa­nie nie posia­da sze­re­gu funk­cjo­nal­no­ści przy­ję­tych jako stan­dar­do­we, nawet w pro­gra­mach niż­szej kla­sy. Przykładowo XXX w modu­le F‑K nie posia­da sze­re­gu zesta­wień wyma­ga­nych do pro­wa­dze­nia księ­go­wo­ści, a wypad­ku H‑M np. pra­wi­dło­we­go zesta­wie­nia sta­nów maga­zy­no­wych towa­rów wraz z ich cena­mi na poszcze­gól­nych maga­zy­nach, z któ­rych w spo­sób łatwy może sko­rzy­stać handlowiec.

Tu uwa­ga dot. zama­wia­ją­ce­go: nie­ste­ty nie ma cze­goś takie­go jak ​„funk­cjo­nal­no­ści przy­ję­te jako stan­dar­do­we”, co naj­wy­żej stan­dar­dem może być zgod­ność (nie­ko­li­do­wa­nie) z odpo­wied­ni­mi prze­pi­sa­mi (np. o rachun­ko­wo­ści). Bardzo czę­sto to Zamawiający jest sam sobie robi krzyw­dę, uwa­ża­jąc że coś jest oczy­wi­ste, nie­ste­ty nie ma rze­czy oczywistych. 

Jeżeli Zamawiający uwa­ża, że ana­li­za biz­ne­so­wa przed wybo­rem i wdro­że­niem sys­te­mu ERPII jest zbęd­na lub, że wyko­na ją popraw­nie dostaw­ca po zawar­ciu umo­wy, to nie­ste­ty szu­ka kłopotów. 

Poważnym pro­ble­mem utrud­nia­ją­cym roz­wią­za­nie trud­nej sytu­acji Zamawiającego są pró­by unik­nię­cia odpo­wie­dzial­no­ści za pro­dukt ze stro­ny pro­du­cen­ta XXX, któ­ry powo­łu­jąc się na zapi­sy umo­wy licen­cyj­nej sta­now­czo odrzu­ca odpo­wie­dzial­ność za wady pro­duk­tu. Zamiast rze­czy­wi­stych napraw ww. wad, moja fir­ma otrzy­mu­je jedy­nie dekla­ra­cje, mówią­ce o ?pod­cho­dze­niu ze zro­zu­mie­niem do pro­ble­mów? i ?goto­wo­ści do pomocy?.

Niestety po pod­pi­sa­niu umo­wy i pro­du­cent i dostaw­ca opro­gra­mo­wa­nia mają pra­wo się na te umo­wę powo­ły­wać. Odpowiedzialność pro­du­cen­ta jest wyłą­czo­na już po pierw­szej inge­ren­cji w kod, uda­ne kasto­mi­za­cje są z regu­ły nie­moż­li­we z powo­dów wyżej opi­sa­nych. Kupujący nie­ste­ty tak­że pono­si odpo­wie­dzial­ność za swo­je dzia­ła­nia. Co praw­da może i nale­ży ocze­ki­wać od dostaw­cy tak zwa­ne­go peł­ne­go pro­fe­sjo­na­li­zmu, jed­nak życie uczy, że to tak­że nale­ży sobie zapew­nić w umowie.

Produkt wpro­wa­dzo­ny do sprze­da­ży i użyt­ko­wa­nia powi­nien być wypo­sa­żo­ny w funk­cjo­nal­no­ści wyma­ga­ne na pol­skim ryn­ku oraz sta­bil­ne pod­sta­wy pro­gra­mi­stycz­ne, któ­re powin­ny gwa­ran­to­wać trwa­łość wpro­wa­dzo­nych danych i rze­tel­ność gene­ro­wa­nych rapor­tów i ana­liz. Niestety XXX nie oka­zał się rze­tel­nym, i co naj­waż­niej­sze, wia­ry­god­nym narzę­dziem słu­żą­cym zarzą­dza­niu wszyst­ki­mi pro­ce­sa­mi przedsiębiorstwa.

Tu nie­ste­ty łyż­ka dzieg­ciu zno­wu do becz­ki kupu­ją­ce­go: po ​„wyję­ciu z pudeł­ka”, prak­tycz­nie każ­de opro­gra­mo­wa­nie pra­cu­je popraw­nie. W ogrom­nej więk­szo­ści przy­pad­ków to pró­by jego ​„dosto­so­wa­nia” powo­du­ją skut­ki jak wyżej opi­sa­ne. Wdrożenie powin­no mieć dwa eta­py: testy wer­sji stan­dar­do­wej, wdro­że­nie, testy wer­sji wdro­żo­nej. Bez tego prak­tycz­nie nie ma praw­nej moż­li­wo­ści eska­la­cji żądań napra­wy błę­dów powsta­łych w toku kasto­mi­za­cji (czy­li inge­ren­cji w kod aplikacji).

Jak uniknąć kłopotów?

Wdrażanie mono­li­tycz­nych sys­te­mów ERP samo w sobie nie jest niczym złym. Powinno ono, wdro­że­nie, być jed­nak poprze­dzo­ne wni­kli­wą ana­li­zą uwzględ­nia­ją­cą stra­te­gię fir­my, ewen­tu­al­ne uspraw­nie­nia i zmia­ny orga­ni­za­cyj­ne, zmien­ność oto­cze­nia ryn­ko­we­go danej fir­my. Poprzedni nie­daw­ny arty­kuł koń­czy­łem słowami:

Każda fir­ma, szu­ka­jąc spo­so­bu na uzy­ska­nie prze­wa­gi ryn­ko­wej, sta­ra się pew­ne obsza­ry ope­ra­cyj­ne budo­wać wg, wła­snej stra­te­gii. To mię­dzy inny­mi powo­du­je, że każ­de wdro­że­nie jest inne i nie ma jed­nej jedy­nie-słusz­nej archi­tek­tu­ry IT. (Źródło: Podsystemy sys­te­mów ERP | | Jarosław Żeliński IT-Consulting)

W arty­ku­le tym opi­sa­łem ogól­ną, dzie­dzi­no­wą archi­tek­tu­rę fir­my produkcyjno‑, handlowo‑, usłu­go­wej (popu­lar­ne w Polsce PPHU). Wygląda ona tak:

Powyższy dia­gram to uprosz­czo­na dzie­dzi­no­wa archi­tek­tu­ra IT fir­my. Analiza biz­ne­so­wa powin­na dać rekomendacje:

• któ­re modu­ły są w ogó­le wyma­ga­ne w danej firmie,
• któ­re mogą być stan­dar­do­wy­mi ele­men­ta­mi będą­cy­mi ele­men­ta­mi sys­te­mu ERP,
• któ­re ele­men­ty są na tyle istot­ne i spe­cy­ficz­ne, że wybór roz­wią­za­nia spe­cja­li­zo­wa­ne­go da lep­sze efekty.

Biorąc pod uwa­gę fakt, że samo­dziel­ne sys­te­my rachun­ko­wo­ści finan­so­wej to raczej rzad­kość, moż­na zało­żyć, że wdra­ża­ny będzie zawsze (lub już jest) tak zwa­ny System ERP. Wersja mini­mal­na to modu­ły obsłu­gu­ją­ce dane bilan­so­we czy­li dowo­dy księ­go­we, środ­ki trwa­łe itp., oraz pła­ce, cza­sem tak zwa­ne kadry. To jest trzon opi­sa­ny pra­wem i w tym obsza­rze ​„ame­ry­ki nie odkryjemy”.

Reszta to już indy­wi­du­al­ne potrze­by danej fir­my, łatwiej dobrać i wdro­żyć bez kasto­mi­za­cji, kil­ka naj­bar­dziej pasu­ją­cych, dostęp­nych na ryn­ku kom­po­nen­tów spe­cja­li­zo­wa­nych, niż dosto­so­wy­wać wiel­ki mono­lit. Po dru­gie ewen­tu­al­ne zmia­ny wpro­wa­dza­ne w jed­nym z takich nie­za­leż­nych kom­po­nen­tów nie prze­nio­są się na pozo­sta­łe (bo nie współ­dzie­lą żad­nych ele­men­tów). Do tego kolej­ność ich wdra­ża­nia jest prak­tycz­nie dowol­na, więc wdro­że­nie jest cał­ko­wi­cie pod­po­rząd­ko­wa­ne bie­żą­cym potrze­bom fir­my (bar­dzo czę­sto naj­mniej­szym pro­ble­mem jest wła­śnie rachun­ko­wość, któ­rą moż­na wdra­żać na koń­cu). Możliwa jest tak­że przy­szła rezy­gna­cja, z któ­re­go­kol­wiek kom­po­nen­tu, bez potrze­by inge­ren­cji czy rezy­gna­cji z pozostałych.

Pięć lat temu pisałem:

Rynek sta­le się roz­wi­ja i doj­rze­wa. Praktycznie każ­da więk­sza fir­ma doświad­czy­ła w jakiejś for­mie wdro­że­nia goto­we­go, dosto­so­wy­wa­ne­go do potrzeb, opro­gra­mo­wa­nia ERP. Warto jed­nak pod­kre­ślić, że idea jed­ne­go ?super sys­te­mu? ERP II, odcho­dzi powo­li do lamu­sa. Moim zda­niem to kwe­stia roku, dwóch. Pierwsze symp­to­my to zale­ce­nia pro­du­cen­tów dużych sys­te­mów: wdra­żać goto­we opro­gra­mo­wa­nie w posta­ci ?goto­wej? tyl­ko tam gdzie pasu­je, obsza­ry spe­cy­ficz­ne dla fir­my opi­sać i zapro­jek­to­wać dla nich dedy­ko­wa­ne roz­wią­za­nie i zin­te­gro­wać. Dobry sys­tem ERP to śro­do­wi­sko pro­gra­mi­stycz­ne (tak zwa­ny fra­me­work, szkie­let). Systemy, nazwę je ?zapóź­nio­ne?, nadal wyma­ga­ją inge­ren­cji w ich kod by cokol­wiek osią­gnąć. Kompromisem jest sytu­acja, w któ­rej sys­tem ERP ma boga­ty inter­fejs (tak zwa­ne API, Application Programming Interface) pozwa­la­ją­cy na inte­gra­cję dedy­ko­wa­nych pod­sys­te­mów lub wła­śnie zewnętrz­nych kom­po­nen­tów czy­li korzy­sta­nia z moż­li­wo­ści jakie daje Cloud Computing). Przyszłość to kom­po­nen­ty? (Źródło: Biznes wycho­dzi z objęć sys­te­mu ? mono­li­tycz­ne­go ERP | | Jarosław Żeliński IT-Consulting)

I to się już dzieje.….