Jeśli histo­ria uczy cze­go­kol­wiek, to tyl­ko tego, że ludzie nigdy nicze­go się nie nauczy­li z historii.

Aleksander Krawczuk, Poczet cesa­rzy rzymskich

Wprowadzenie

Duże pro­jek­ty tech­no­lo­gicz­ne naj­czę­ściej koń­czą się nie­po­wo­dze­niem. Czy ist­nie­je spo­sób na zmniej­sze­nie praw­do­po­do­bień­stwa nie­po­wo­dze­nia? Tak: nale­ży przyj­rzeć się pro­ble­mom zwią­za­nym z defi­ni­cją, zakre­sem i zarzą­dza­niem, ale nie nale­ży zbyt uważ­nie przy­glą­dać się pro­ble­mom zwią­za­nym z talen­ta­mi, wspar­ciem kadry kie­row­ni­czej i kul­tu­rą kor­po­ra­cyj­ną. Są one pra­wie nie­moż­li­we do rozwiązania.

https://www.forbes.com/sites/steveandriole/2021/03/25/3‑main-reasons-why-big-technology-projects-fail — why-many-companies-should-just-never-do-them/

Przyczyny pora­żek wdro­żeń sys­te­mów ERP są sta­le te same od lat: łama­nie zasad. Jakie to zasa­dy? Generalnie:

  1. dostaw­ca ERP nie powi­nien zarzą­dzać całym pro­jek­tem ani zakre­sem pro­jek­tu (kon­flikt interesu),
  2. nie nale­ży inge­ro­wać w struk­tu­rę kodu mono­li­tycz­ne­go sys­te­mu (kasto­mi­za­cja),
  3. nie nale­ży udo­stęp­niać bazy danych innym apli­ka­cjom, inte­gra­cje nale­ży reali­zo­wac wyłącz­nie poprzez API,
  4. nale­ży chro­nić swo­je know-how zapew­nia­jąc sobie pra­wa mająt­ko­we­go do każ­dej dedy­ko­wa­nej czę­ści systemu/kodu.

I nie­ste­ty za każ­dym razem wnio­sek jest ten sam: nie bra­ku­je dostę­pu do wie­dzy jak tego nie robić, a mimo to nabyw­cy sys­te­mów ERP (ich praw­ni­cy tak­że) popeł­nia­ją wszyst­kie klu­czo­we błę­dy .

Pierwszy punkt jest klu­czo­wy, dla­te­go na czas pro­jek­tu nale­ży zaan­ga­żo­wać eks­per­ta po swo­jej stro­nie. Często moż­na usły­szeć: zatrud­nij­cie kon­sul­tan­ta ERP”, jed­nak poja­wia sie pyta­nie kto to taki? Pod poję­ciem kon­sul­tant ERP” bar­dzo czę­sto spo­ty­ka się oso­by spe­cja­li­zu­ją­ce się we wdra­ża­niu jed­ne­go kon­kret­ne­go sys­te­mu. Taka oso­ba raczej sprze­da­je kon­kret­ny sys­tem, bo nie poma­ga w wybo­rze naj­wła­ściw­sze­go spo­śród wie­lu dostęp­nych na ryn­ku. Jeżeli kon­sul­tan­ta ERP” zapew­nia od razu skła­da­ją­cy ofer­tę dostaw­ca okre­ślo­ne­go sys­te­mu ERP, jest to po pro­stu wdrożeniowiec. 

Wybór odpo­wied­nie­go sys­te­mu ERP i jego dostaw­cy jest kry­tycz­nym kro­kiem w każ­dym pro­jek­cie trans­for­ma­cji cyfro­wej. Powinien to jed­nak być dru­gi krok. Pierwszym jest ana­li­za biz­ne­so­wa i przy­go­to­wa­nie wymagań. 

Najczęstszą przy­czy­ną kło­po­tów jest uzna­nie, że dostaw­ca opro­gra­mo­wa­nia sam wyko­na ana­li­zę przed­wdro­że­nio­wą, opra­cu­je wyma­ga­nia i potem wdro­ży system. 

W efek­cie pro­jekt taki sku­pia się od począt­ku na dopa­so­wy­wa­niu przed­wcze­śnie wybra­ne­go sys­te­mu, zamiast naj­pierw opra­co­wać wyma­ga­nia i przy­go­to­wać się wewnętrz­nie do wdro­że­nia. Kilka spo­strze­żeń na ten temat w arty­ku­le: Kto winien poraż­ki projektu?

Jeżeli wdrożenie jest w toku…

…kolej­ny raz prze­kro­czo­no ter­min i budżet, to masz pro­blem. Nadal coś nie dzia­ła tak jak powin­no, to masz problem. 

Niestety pro­ble­ma­tycz­ne wdro­że­nia sys­te­mów ERP, nie są rzad­ko­ścią. Wiele moich zle­ceń od klien­tów to wypro­wa­dza­nie ich z impa­su spo­ru z dostaw­cą a potem kon­ty­nu­acja wdro­że­nia lub zmia­na sys­te­mu bo cza­sa­mi naj­lep­szym wyj­ściem oka­zu­je się wyj­ście z posiadanego/wdrażanego sys­te­mu ERP z mini­mal­ny­mi stratami. 

Co moż­na wte­dy zro­bić? Proponuję:

  1. Zrewidowanie dotych­cza­so­we­go podej­ścia do wdro­że­nia i zarzą­dza­nia zmia­ną (jeden mono­li­tycz­ny ERP to myśle­nie życze­nio­we, uzna­nie, że jeden sys­tem nada­je sie do wszyst­kie­go w fir­mie, jest w obec­nych cza­sach jest uto­pią).
  2. Przygotowanie cze­goś wię­cej niż tyl­ko jego luź­ny szkic sta­nu docelowego.

Na pyta­nie Co Pan pro­po­nu­je na począ­tek, zawsze odpowiadam:

Najogólniej trze­ba by oprzeć sie na doku­men­tach ope­ra­cyj­nych, na to nało­żyć ich treść (dane) i zma­po­wać na posia­da­ne apli­ka­cje (i ich dostaw­ców, to są ich obo­wiąz­ki). Być może wystar­czy tyl­ko upo­rząd­ko­wać aktu­al­ny stan wdro­że­nia i integracji.

Masz ochotę jeszcze czytać? Skąd te problemy…

Architektura opro­gra­mo­wa­nia, jej pro­jek­to­wa­nie, to doko­ny­wa­nie fun­da­men­tal­nych wybo­rów struk­tu­ral­nych, któ­rych zmia­na po wdro­że­niu jest kosz­tow­na. Wybory archi­tek­tu­ry opro­gra­mo­wa­nia obej­mu­ją okre­ślo­ne opcje struk­tu­ral­ne z moż­li­wo­ści w pro­jek­cie oprogramowania. 

Architektura sys­te­mu opro­gra­mo­wa­nia jest meta­fo­rą, ana­lo­gicz­ną do archi­tek­tu­ry budynku[3]. Funkcjonuje ona jako plan sys­te­mu i pro­jek­tu dewe­lo­per­skie­go, któ­ry kie­row­nic­two pro­jek­tu może póź­niej wyko­rzy­stać do eks­tra­po­la­cji zadań nie­zbęd­nych do wyko­na­nia przez zaan­ga­żo­wa­ne zespo­ły i ludzi.

Typowy sys­tem ERP to milio­ny linii kodu pro­gra­mu i set­ki sko­ja­rzo­nych wza­jem­nie tabel baz danych. Takie sys­te­my powsta­ją lata­mi, testo­wa­nie ich u pro­du­cen­ta trwa mie­sią­ca­mi. Każda inge­ren­cja w struk­tu­rę tego kodu i tabel baz danych to ryzy­ko zabu­rze­nia sta­bil­no­ści sys­te­mu i ogrom­na pra­co­chłon­ność usu­wa­nia skut­ków tych ingerencji. 

Najbardziej zna­ne na ryn­ku sys­te­my ERP maja archi­tek­tu­rę z cza­sów gdy powsta­wa­ły (lata 80-te):

Architektura mono­li­tycz­nych sys­te­mów ERP pro­jek­to­wa­nych w latach 70/80/90-tych (opra­co­wa­nie wła­sne autora)

Są to sys­te­my budo­wa­ne w opar­ciu o cen­tral­ną bazę danych, bar­dzo skom­pli­ko­wa­ne, z sil­nie powią­za­ny­mi ze sobą kom­po­nen­ta­mi. Typowe pro­ble­my w toku wdro­żeń takich systemów:

  • każ­da mody­fi­ka­cja kosz­tu­je kil­ka-kil­ka­na­ście tysię­cy zł,
  • każ­da mody­fi­ka­cja to ryzy­ko naru­sze­nia inte­gral­no­ści całości,
  • każ­da lokal­na mody­fi­ka­cja prze­no­si sie na resz­tę sys­te­mu (wspól­na baza danych),
  • nie da się oddzie­lić od sie­bie modułów,
  • mono­pol jed­ne­go dostaw­cy, któ­ry zacznie Ci dyk­to­wać ceny,
  • wspól­na baza danych (model danych) jest kom­pro­mi­sem, dla­te­go bar­dzo czę­sto pew­nych funk­cjo­nal­no­ści jest po pro­stu niemożliwe.

Już od koń­ca lat 90-tych mówi się o odej­ściu od tej archi­tek­tu­ry, gdyż jaka­kol­wiek inge­ren­cja w taki sys­tem to ogrom­ne ryzy­ko jego desta­bi­li­za­cji. Na ryn­ku od lat powsta­ją dzie­dzi­no­we spe­cja­li­zo­wa­ne sys­te­my z wbu­do­wa­ny­mi opcja­mi inte­gra­cji (inter­fej­sy API: RPC, REST, SOAP itp.). Dlatego popu­lar­ną i sku­tecz­ną for­mą wdra­ża­nia sta­rych” ERP jest wyko­rzy­sty­wa­nie ich tyl­ko w wąskim zakre­sie (cen­tral­ne ope­ra­cje admi­ni­stra­cyj­ne). Podobnie wyglą­da rato­wa­nie” tych wdro­żeń: rezy­gnu­je­my z modu­łów wyma­ga­ją­cych kasto­mi­za­cji na rzecz wol­no­sto­ją­cych inte­gro­wa­nych spe­cja­li­zo­wa­nych, dzie­dzi­no­wych apli­ka­cji dobra­nych do naszych potrzeb. Architektura taka wyglą­da jak poniżej:

Najnowocześniejszym podej­ściem jest to, co dziś nazy­wa­my fede­ra­cyj­nym wdro­że­niem dzie­dzi­no­wych kom­po­nen­tów: zestaw zin­te­gro­wa­nych apli­ka­cji dobra­nych do potrzeb kon­kret­nej fir­my. Na ryn­ku jest obec­nie ogrom­ny wybór spe­cja­li­zo­wa­nych apli­ka­cji bar­dzo łatwych do inte­gra­cji. Architektura takie­go sys­tem wyglą­da jak poniżej:

Taki sys­tem moż­na wdra­żać stop­nio­wo, decy­zje o wybo­rze kolej­nych modu­łów podej­mo­wa­ne są na ostat­ni moment”, czy­li wte­dy gdy mamy naj­więk­szą wie­dzę. Bardzo czę­sto oka­zu­je się też, że posia­da­ny i wdro­żo­ny sys­tem FK nie wyma­ga wymia­ny (jeden z moich klien­tów ma potęż­ny sys­tem pro­duk­cyj­ny MES-APS zin­te­gro­wa­ny z poczci­wą Comarch OPTIMA). 

Oferta

Polecam opis: Jak wyjść z dłu­gu tech­no­lo­gicz­ne­go jakim jest cen­tral­ny mono­li­tycz­ny sys­tem.

Umowa ze mną obejmuje:

  1. audyt: opra­co­wa­nie mode­li pro­ce­sów biz­ne­so­wych fir­my i wska­za­nie na nich wyma­gań biz­ne­so­wych i zakre­su wdrożenia,
  2. ana­li­za fit-gap: oce­nić róż­ni­cę pomię­dzy pla­no­wa­nym sta­nem, ide­al­nym” a aktu­al­nym fak­tycz­nym, opra­co­wa­nie pro­jek­tu rozwiązania,
  3. usta­le­nie z dostaw­cą for­my zamknię­cia aktu­al­ne­go sta­nu: anek­su lub nowej umo­wy na dal­sze pra­ce (załącz­ni­kiem jest co do zasa­dy pro­dukt pierw­sze­go i dru­gie­go eta­pu powy­żej: model pro­ce­sów biz­ne­so­wych i pro­jekt roz­wią­za­nia jako wymaganie),
  4. prze­ję­cie zarzą­dza­nia zakre­sem pro­jek­tu (wyma­ga­nia i pro­jek­to­wa­nie ich reali­za­cji): (mój) nad­zór autor­ski na bazie opra­co­wa­nej mapy pro­ce­sów i wyma­gań, dostaw­ca reali­zu­je wyłącz­nie imple­men­ta­cję i wdro­że­nie pod dyk­tan­do Zamawiającego (czy­li tak­że moje).
  5. może to być umo­wa z dowol­ną ze stron lub wyżej opi­sa­na umo­wa trójstronna. 

Poniżej pro­sty for­mu­larz, któ­ry pomo­że sfor­mu­ło­wać Wasze ocze­ki­wa­nia i pyta­nie do mnie.

Zapytanie

Źródła

Baumann, B. (2021, July 7). Top 10 ERP Failures Of The Last Three Decades (yes, They’re Still Relevant). https://​www​.pano​ra​ma​-con​sul​ting​.com/​t​o​p​-​1​0​-​e​r​p​-​f​a​i​l​u​r​es/
Gillmann, M., Hertel, J., Jung, C. G., Kaufmann, G., & Wolber, M. (2002). Cooking the Web-ERP. In R. Meersman & Z. Tari (Eds.), On the Move to Meaningful Internet Systems 2002: CoopIS, DOA, and ODBASE (Vol. 2519, pp. 602 – 617). Springer Berlin Heidelberg. https://​doi​.org/​1​0​.​1​0​0​7/3 – 540-36124 – 3_41

Ten post ma jeden komentarz

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.