Koniec roku się zbli­ża, czas na pod­su­mo­wa­nia i pro­gno­zy :), pierw­sze publi­ka­cje już są. Co się pisze o ERP:

Monolityczne roz­wią­za­nia wspie­ra­ją­ce zarzą­dza­nie to prze­szłość. Dziś liczą się: wszech­stron­ność, otwar­tość na zmia­ny, pro­sto­ta obsłu­gi, moż­li­wo­ści inte­gra­cyj­ne. Wybór naj­lep­sze­go sys­te­mu ERP sta­je się coraz trud­niej­szy. (za Biznes wycho­dzi z objęć sys­te­mu – Computerworld).

Jak osią­gnąć wszech­stron­ność i otwar­tość na zmia­ny”? Na począ­tek może małe review moich wcze­śniej­szych tek­stów na ten temat:

Przewiduję powol­ne odcho­dze­nie od idei sys­te­mów zin­te­gro­wa­nych. Dotychczasowa ich zale­ta czy­li peł­na inte­gra­cja prze­sta­je być zale­tą a sta­je się gar­bem. System zin­te­gro­wa­ny moż­na już ?skle­ić? ze spe­cja­li­zo­wa­nych apli­ka­cji, kom­po­nen­tów. […] Drugim powo­dem prze­wi­dy­wa­ne­go odej­ścia od tej idei są ogrom­ne kło­po­ty z oce­ną ren­tow­no­ści wdro­że­nia sys­te­mu ERP. Nie raz jest to po pro­stu wręcz nie­moż­li­we z powo­du bra­ku moż­li­wo­ści oce­ny jakim kosz­tem wspie­ra­my poje­dyn­czy pro­ces biz­ne­so­wy bo trud­no z jed­ne­go ogrom­ne­go sys­te­mu wykro­ić” koszt wspar­cia poje­dyn­cze­go pro­ce­su. (Marzec 2007, Czy to już nad­cho­dzą­cy koniec zin­te­gro­wa­nych ERP?)

Jeżeli dostaw­ca duże­go ERP mówi, że duży ERP jest naj­lep­szy to nale­ży to trak­to­wać tak samo jak ofer­tę dostaw­cy duże­go zesta­wu garn­ków ze sta­li nie­rdzew­nej, z któ­rych i tak na co dzień uży­wa­my jed­ne­go a nale­śni­ki i tak robi­my z pomo­cą kupio­nej wcze­śniej dobrej teflo­no­wej patel­ni bo do nale­śni­ków lep­sza a zamia­na jej na nową z nie­rdzew­ki tyl­ko dla­te­go, że ?z kom­ple­tu? prze­czy zdro­we­mu roz­sąd­ko­wi i uży­wa się jej mimo, że pokryw­ka z zesta­wu lek­ko wysta­je ? ale przy­kry­wa bo taki jest jej głów­ny cel (w zasa­dzie tyl­ko nie powin­na być mniej­sza ani zbyt duża). (Listopad 2009 Nigdy wię­cej ERP w jed­nym kawał­ku!).

Jak zacząć? Najpierw ana­li­za tego co i jak robi­my. Potem podział tego na obsza­ry stan­dar­do­we, któ­re obsłu­ży­my narzę­dziem uni­wer­sal­nym i pozo­sta­łe, któ­rych z regu­ły jest bar­dzo mało ale są bar­dzo waż­ne dla nas. te dru­gie obsłuż­my po swo­je­mu ale nie pakuj­my się w niszo­we lub prze­sta­rza­łe tech­no­lo­gie. Nie dawaj­my tak­że wia­ry w to, że kup­no tego co ma (powie­le­nie tego co robi) nasz kon­ku­rent uczy­ni nas bar­dziej kon­ku­ren­cyj­ny­mi bo prak­ty­ka poka­zu­je coś zupeł­nie odwrot­ne­go. (sier­pień 2010, Wymagania na opro­gra­mo­wa­nie ERP wspo­ma­ga­ją­ce zarzą­dza­nie: dwie kup­ki).

Nowe sys­te­my zin­te­gro­wa­ne ERP będą pew­ny­mi zesta­wa­mi goto­wych funk­cjo­nal­no­ści, zbu­do­wa­ny­mi w opar­ciu o szkie­le­ty opro­gra­mo­wa­nia zaś inte­gra­cja będzie bazo­wa­ła nie na współ­dzie­le­niu danych, a na wymia­nie ich pomię­dzy modu­ła­mi i zewnętrz­ny­mi sys­te­ma­mi na rów­nych pra­wach. Rozwój sys­te­mu w takim przy­pad­ku pole­ga na two­rze­niu nowych modu­łów tym śro­do­wi­sku a nie na mody­fi­ka­cji już ist­nie­ją­cych. (Styczeń 2011, Frameworks Introduction ? czy­li jak się psu­je dobre ERP).1

Bo nie­za­leż­nie od tego jak ?uni­wer­sal­ny? jest sys­tem ERP zawsze będzie gor­szy od kil­ku dobrze dobra­nych ale nie­za­leż­nych kom­po­nen­tów. Gorszy nie dla­te­go, że ?brzyd­szy? ale dla­te­go, że będzie kulą u nogi fir­my, któ­ra powin­na jed­nak reago­wać na zmia­ny na ryn­ku w cią­gu tygo­dni a nie lat? Po dru­gie mody­fi­ka­cja jakie­go­kol­wiek opro­gra­mo­wa­nia zawsze wyma­ga testo­wa­nia cało­ści, tak więc im mniej­sze kawał­ki mamy tym szyb­ciej i taniej wpro­wa­dza się do nich zmia­ny bo ich odda­nie do użyt­ku po mody­fi­ka­cji jest łatwiej­sze i szyb­sze zara­zem. Pamiętajmy pew­ną sta­rą rekla­mę: ?Banki od wszyst­kie­go są do nicze­go??. (Kwiecień 2011, Czego naj­bar­dziej bra­ku­je sys­te­mom kla­sy ERP?).

Od lat mówi się o SOA, jako o meto­dzie budo­wy i inte­gra­cji sys­te­mów (tu już mamy inte­gra­cję a nie tyl­ko zdal­ne uży­cie). Jednak poja­wia się tu potrze­ba two­rze­nia pośred­ni­czą­ce­go, kosz­tow­ne­go, ele­men­tu archi­tek­tu­ry (ESB) co sku­tecz­nie ogra­ni­czy­ło zasto­so­wa­nie tej meto­dy (a raczej tech­no­lo­gii) inte­gra­cji sys­te­mów. Cloud Computing to zupeł­nie inne podej­ście. To kom­po­nen­to­wa archi­tek­tu­ra zna­na od lat. (Październik 2011, Cloud Computing to archi­tek­tu­ra sys­te­mu).2

Pojawia się teza:

ERP jest dziś narzę­dziem do gro­ma­dze­nia i skła­do­wa­nia wszel­kich infor­ma­cji potrzeb­nych do podej­mo­wa­nia decy­zji w biz­ne­sie. Jako takie jest dziś waż­niej­sze niż kie­dy­kol­wiek wcze­śniej” – pod­kre­śla Nidal Haddad.3 (za Biznes wycho­dzi z objęć sys­te­mu – Computerworld).

Jeżeli fak­tycz­nie tak dostaw­cy postrze­ga­ją sys­te­my ERP (co zresz­tą wyda­je się być wła­ści­we) to nie dzi­wi fakt, że np. zarzą­dza­nie doku­men­ta­mi, wspo­ma­ga­nie prze­pły­wu pra­cy (work­flow) czy wspo­ma­ga­nie podej­mo­wa­nia decy­zji (sys­te­my rapor­to­we, busi­ness inte­li­gen­ce) to coraz czę­ściej jed­nak odręb­ne, inte­gro­wa­ne pod­sys­te­my. Widać ten trend już na ryn­ku. Np. jeden z lide­rów ryn­ku ERP, fir­ma SAP, kupił pro­dukt (fir­mę) Business Object włą­cza­jąc go do swo­jej ofer­ty jako narzę­dzie BI,4 do zarzą­dza­nia doku­men­ta­mi i ich prze­pły­wem SAP pole­ca dedy­ko­wa­ny do tego celu sys­tem OpenText. 5SAP nie jest tu jedy­nym dostaw­cą ERP. Podobną stra­te­gię zaczy­na­ją pre­zen­to­wać i inni lide­rzy ryn­ku ERP. Tak więc już nie jeden ERP II… O czym to świad­czy? O roz­pa­dzie” idei sys­te­mu zintegrowanego:

Uniwersalność opro­gra­mo­wa­nia wspie­ra­ją­ce­go zarzą­dza­nie powo­du­je, że zacie­ra­ją się histo­rycz­ne podzia­ły bran­żo­we. Wcześniej myśla­no o sys­te­mach kla­sy ERP jako o narzę­dziach dają­cych prze­wa­gę kon­ku­ren­cyj­ną. Dzisiaj roz­wią­za­nia tego typu sta­ły się bar­dziej powszech­ne. Standaryzacja poprzez ERP nie daje prze­wa­gi nad kon­ku­ren­cją” – pod­kre­śla Tomasz Bejm, Technology Consulting Leader w fir­mie PrcewaterhouseCoopers.3.

I jak widać nie ja jeden tak uwa­żam, powie­la­nie roz­wią­zań nie daje prze­wa­gi a wręcz ją zabi­ja. wspo­mi­na­łem o tym już w 2007 roku (cytat na począt­ku tekstu).

Pora na Cloud Computing:

Analitycy są zgod­ni, że szcze­gól­ną rolę w zakre­sie roz­wo­ju opro­gra­mo­wa­nia biz­ne­so­we­go odgry­wać będzie tech­no­lo­gia Cloud Computing. W mia­rę roz­wo­ju tech­no­lo­gii inter­ne­to­wych spo­dzie­wać się moż­na wzro­stu uży­tecz­no­ści opro­gra­mo­wa­nia biz­ne­so­we­go ofe­ro­wa­ne­go w mode­lu usłu­go­wym.3 .

Jednak tu nale­ży się pew­ne wyja­śnie­nie. Cloud Computing (CC) to nie zwy­kły out­so­ur­cing opro­gra­mo­wa­nia w posta­ci zna­nej od ponad 10 lat jako ASP czy ostat­nie SaaS (oso­bi­ście nie widzę róż­ni­cy poza tech­no­lo­gią). CC to roz­bu­do­wa­ne, ofe­ro­wa­ne na ryn­ku, goto­we do uży­cia kom­po­nen­ty. Moim zda­niem poda­wa­nie jako przy­kła­du CC roz­wią­zań, któ­rych uży­wa się jak innych apli­ka­cji jest błę­dem. CC to coś do posze­rza moż­li­wo­ści posia­da­ne­go opro­gra­mo­wa­nia ale w tle:

Moim zda­niem każ­dy, chcą­cy liczyć się na ryn­ku dostaw­ca ERP, w zasa­dzie musi się z tym pogo­dzić lub wypad­nie z ryn­ku. Najpierw rynek zmu­sił dostaw­ców ERP do udo­stęp­nia­nie inter­fej­sów inte­gra­cyj­nych, tak zwa­nych API (ang. appli­ca­tion pro­gam­ming inter­fejs) , choć nadal są opor­tu­ni­ści wśród dostaw­ców tych sys­te­mów. Teraz pora pogo­dzić się z tym, że powsta­ją (będą) kom­po­nen­ty roz­sze­rza­ją­ce funk­cjo­nal­no­ści pod­sta­wo­wych wer­sji ERP a koszt udo­stęp­nie­nia API (licen­cjo­no­wa­nie) będzie spa­dał. Możliwości udo­stęp­nia­ne przez te API od pew­ne­go cza­su pozwa­la­ją już na budo­wa­nie ?chmur?6.

Podsumowanie

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 komponenty…

(J.Ż. 2011)

Rok 2018

Polskie fir­my odcho­dzą od wdra­ża­nia sys­te­mów mono­li­tycz­nych. W cza­sach cyfro­wej trans­for­ma­cji i dyna­micz­nych zmian na ryn­ku trwa­ją­ce ponad rok wdro­że­nia mono­li­tycz­nych sys­te­mów ERP nie zapew­nia­ją dosta­tecz­nej ela­stycz­no­ści. Długotrwałe, czę­sto kasto­mi­zo­wa­ne roz­wią­za­nia prak­tycz­nie unie­moż­li­wia­ją wpro­wa­dza­nie nowych funk­cji czy zmia­nę logi­ki sys­te­mu w trak­cie wdro­że­nia. Oznacza to duże ryzy­ko utra­ty jego zasad­no­ści przed zakoń­cze­niem prac, a jesz­cze więk­sze, zanim zaku­pio­ny sprzęt czy licen­cje zosta­ną zamor­ty­zo­wa­ne. Monolityczne sys­te­my wią­żą przed­się­bior­stwo z okre­ślo­nym dostaw­cą, co w śred­niej i dłu­giej per­spek­ty­wie cza­so­wej utrud­nia wpro­wa­dza­nie zmian i zwięk­sza kosz­ty. 7

Przypisy

1.
Frameworks… IT​-Consulting​.pl. https://it-consulting.pl//index.php/2011/02/03/frameworks-introduction-czyli-jak-sie-psuje-dobre-erp/. Published April 17, 2018. Accessed April 17, 2018.
2.
Cloud Computing. IT-Consulting. https://it-consulting.pl//index.php/2011/10/11/cloud-computing-to-architektura-systemu/. Published April 17, 2018. Accessed April 17, 2018.
4.
SAP Software Solutions | Business Applications and Technology. SAP. . Published April 17, 2018. Accessed April 17, 2018.
5.
SAP Software Solutions | Business Applications and Technology. SAP. . Published April 17, 2018. Accessed April 17, 2018.
6.
Zelinski J. Cloud com­pu­ting – czy aby na pew­no nowin­ka… | Jarosław Żeliński IT-Consulting. Jarosław Żeliński IT-Consulting – Analiza Biznesowa i Systemowa, Wymagania. https://it-consulting.pl//index.php/2010/11/25/cloud-computing-czy-aby-na-pewno-nowinka/. Published November 25, 2010. Accessed April 17, 2018.

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.

Ten post ma 7 komentarzy

  1. jacek2v

    Zgadzam się cał­ko­wi­cie. Modułowość + dobre API oraz przy­da­ło­by się tro­chę nie­za­leż­nych od plat­for­my stan­dar­dów: tak i w war­stwie trans­por­to­wej (WS, REST itp.) jak i biz­ne­so­wej (EDI, OAGIS itp.) Offtopic: Same stwier­dze­nie Przyszłość to kom­po­nen­ty?” jakoś dziw­nie zna­jo­mo brzmi 🙂 Echo sprzed kil­ku­na­stu lat :)?

    1. Jarek Żeliński

      Dokładnie, pierw­sza moja książ­ka o kom­po­nen­tach to lata 90te, nie­ste­ty wte­dy była raczej teo­rią i poboż­ny­mi życze­nia­mi 🙂 a dziś… się da…

  2. Jarek P.

    Panie Jarku,
    to wszyst­ko co Pan pisze jest brzmi mądrze i być może nawet mądre jest, tyl­ko, że zupeł­nie nie przy­sta­je do prak­ty­ki. Moim skrom­nym zda­niem Cloud Computing jest ideą i niczym wię­cej, a przy­naj­mniej przez dość wie­le (znacz­nie wię­cej niż rok czy dwa przez Pana pro­gno­zo­wa­ne). Nie ma moż­li­wo­ści aby istot­ne fir­my pozwo­li­ły sobie na dzia­ła­nie na czymś co porów­nam do Linuxa, z bar­dzo pro­stej przy­czy­ny – czas bie­gnie a clo­ud com­pu­ting to dekom­po­zy­cja, więc duże sys­te­my ERP (I czy II bez zna­cze­nia) póki co są jedy­ną przy­szło­ścią więk­szych przed­się­biorstw i kor­po­ra­cji. Rozbudowane API pro­wa­dzi do jed­ne­go – tak poważ­nej kasto­mi­za­cji, że w prze­strze­ni kil­ku lat nie­moż­li­wa będzie inte­gra­cja z now­szy­mi roz­wią­za­nia­mi i ten wysi­łek spa­da na ramio­na odbior­ców a nie dostaw­ców sys­te­mu = więk­sza fir­ma = softwa­re house. Z resz­tą jest to kom­plet­nie sprzecz­ne z Pańskimi wywo­da­mi na temat zarzą­dza­nia poprzez pro­ce­sy biz­ne­so­we. Przy oka­zji, mia­łem oka­zję zetknąć się z Pańskimi w tej dzie­dzi­nie kom­pe­ten­cja­mi i są one czy­sto teo­re­tycz­ne, w prak­ty­ce, po trzech tygo­dniach porzu­cił Pan zada­nie Panu powie­rzo­ne. Kończąc, książ­ki moż­na pisać o czym się chce ale dobrze jest się na tym odro­bi­nę znać.
    Pozdrawiam,
    Jarek Pawłowicz

    1. Jarek Żeliński

      Co do ERP zda­nia są podzie­lo­ne, powie­lam w tym arty­ku­le tren­dy u pro­du­cen­tów, nie są to moje wydu­ma­ne teo­rie (wystar­czy zapo­znać się z zale­ce­nia­mi Microsoft, SAP czy IFS oraz opi­sem archi­tek­tu­ry ich sys­te­mów ERP po refak­to­ry­za­cji: są wła­śnie dekom­po­no­wa­ne). CC to archi­tek­tu­ra a nie outo­so­ur­cing i co do tego mało kto ma wąt­pli­wo­ści (no może poza dzia­ła­mi mar­ke­tin­gu). Kastomizacja jest złem ERP” i nie ja to napi­sa­łem pierw­szy, co naj­wy­żej potwier­dza­ją to moje i nie tyl­ko moje doświad­cze­nia. Zresztą sami pro­du­cen­ci sys­te­mów wymie­nio­nych ERP odra­dza­ją grze­ba­nie w ich sys­te­mach co nagmin­nie robią nasi dostaw­cy. Zarządzanie zorien­to­wa­ne na pro­ce­sy nijak się ma do ERP (w zasa­dzie mało, któ­ry ERP je wspie­ra, one raczej obsłu­gu­ją sta­tu­sy doku­men­tów a to nie to samo co pro­ces), to nie przy­pa­dek, że np. SAP zale­ca OpenText” do tego celu. Nie jest przy­pad­kiem, że sys­te­my (roz­wią­za­nia) o wdzięcz­nej nazwie BPM to nie ERP. 

      Co do rze­ko­me­go moje­go porzu­ce­nia zadnia” jest Pan, o ile pamię­tam kie­row­nik tego pro­jek­tu, nie­do­in­for­mo­wa­ny: stwier­dzo­no (nie ja), że opra­co­wa­nie spe­cy­fi­ka­cji sys­te­mu IT nada­ją­cej się wyko­na­nia moje­go zda­nia” gra­ni­czy z nie­moż­li­wo­ścią i zarzu­co­no to, dla­te­go moja pra­ca stra­ci­ła sens z bra­ku danych. Nie jest to jed­nak miej­sce na roz­trzą­sa­nie tego, powiem tyl­ko, że mia­łem kon­takt z bene­fi­cjen­tem” jesz­cze ponad dwa lata i znam ciąg dal­szy. Nie ja powi­nie­nem mieć tu wyrzu­ty sumie­nia. Zresztą tak na mar­gi­ne­sie, podob­ny pro­jekt mia­łem nie­co póź­niej w fir­mie pokrew­nej (spon­sor pro­jek­tu ten sam i bran­ża ta sama) i jest to jed­na z moich naj­ład­niej­szych refe­ren­cji 🙂 nomen omen wysta­wio­no mi dru­gą tak­że przez póź­niej­sze­go dostaw­cę sys­te­mu wybra­ne­go i wdro­żo­ne­go na bazie mojej dokumentacji.

  3. Jarek P.

    Ponownie Panie Jarku,

    idea fak­tycz­nie pocho­dzi sprzed kil­ku­na­stu lat i nie­ste­ty do tej pory się nie spraw­dzi­ła, a powo­dy są bar­dziej niż oczy­wi­ste. Bardzo daw­no, daw­niej niż kil­ka­na­ście lat temu stwier­dzo­no, iż Standardization Accelerates Progess (SAP – to oczy­wi­ście inny SAP). Cloud Computing pro­wa­dzi wyłącz­nie do domi­na­cji Microsfotu” – dałem tu cudzy­słów, bo nie cho­dzi o fir­mę tyl­ko o ich dąże­nia. Każda inge­ren­cja w kod powo­du­je coraz bar­dziej posze­rza­ją­cą się lukę pomię­dzy sys­te­mem w wer­sji stan­dar­do­wej a w wer­sji uży­wa­nej przez kon­su­men­ta”- i to, wbrew pozo­rom nie odbie­ga od dzi­siej­szej rze­czy­wi­sto­ści ale róż­ni się od niej tym, że kosz­ta ewen­tu­al­nej inte­gra­cji prze­no­szo­ne są w cało­ści na użyt­kow­ni­ka a nie pro­du­cen­ta, jak było do tej pory. I do tego spro­wa­dził­bym swo­ją wypowiedź.
    Systemy modu­ło­we tak, ale utrzy­my­wa­ne i roz­wi­ja­ne przez pro­du­cen­ta a nie użyt­kow­ni­ka. W tym sen­sie się z Panem nie zgadzam.

    Ponownie pozdra­wiam,
    JP

    1. Jarek Żeliński

      Nie napi­sa­łem nigdzie, że użyt­kow­nik ma sobie coś sam robić. To dostaw­ca sys­te­mu ma sto­so­wać się się do zale­ceń pro­du­cen­ta ERP któ­re dostar­cza, a w zasa­dzie każ­dy pro­du­cent zale­ca pro­stą” ścież­kę: ana­li­za potrzeb, ana­li­za gap/fit sys­te­mu ERP (czy­li któ­re potrze­by reali­zu­je a któ­re nie), oce­na kosz­tów imple­men­ta­cji bra­ku­ją­cych funk­cji (ale nie jest to inge­ren­cja w sys­tem a dopro­jek­to­wa­nie bra­ku­ją­cych funk­cji w śro­do­wi­sku dane­go ERP albo z boku”), decy­zja o zakre­sie pro­jek­tu… Problem w tym, że każ­dy sys­tem ERP ma coś bar­dzo dobre­go i coś co zupeł­nie nie pasu­je”, dla­te­go wybór sys­te­mu (i jego dostaw­cy) powi­nien nastą­pić dopie­ro po doko­na­niu ana­li­zy potrzeb. Na koniec dodam: nie znam żad­nej fir­my, któ­ra nie mia­ła by poza posia­da­nym ERP, jesz­cze jakie­goś dedy­ko­wa­ne­go opro­gra­mo­wa­nia, wiec idea jed­ne­go zin­te­gro­wa­ne­go ERP w fir­mie” jest raczej nie do obro­ny. Nasz daw­ny wspól­ny klient jest tego dobit­nym przykładem. 

  4. Jaroslaw Zelinski

    Polskie fir­my odcho­dzą od wdra­ża­nia sys­te­mów mono­li­tycz­nych. W cza­sach cyfro­wej trans­for­ma­cji i dyna­micz­nych zmian na ryn­ku trwa­ją­ce ponad rok wdro­że­nia mono­li­tycz­nych sys­te­mów ERP nie zapew­nia­ją dosta­tecz­nej ela­stycz­no­ści. Długotrwałe, czę­sto kasto­mi­zo­wa­ne roz­wią­za­nia prak­tycz­nie unie­moż­li­wia­ją wpro­wa­dza­nie nowych funk­cji czy zmia­nę logi­ki sys­te­mu w trak­cie wdro­że­nia. Oznacza to duże ryzy­ko utra­ty jego zasad­no­ści przed zakoń­cze­niem prac, a jesz­cze więk­sze, zanim zaku­pio­ny sprzęt czy licen­cje zosta­ną zamor­ty­zo­wa­ne. Monolityczne sys­te­my wią­żą przed­się­bior­stwo z okre­ślo­nym dostaw­cą, co w śred­niej i dłu­giej per­spek­ty­wie cza­so­wej utrud­nia wpro­wa­dza­nie zmian i zwięk­sza koszty.”

    https://​www​.com​pu​ter​world​.pl/​n​e​w​s​/​P​o​l​s​k​i​-​r​y​n​e​k​-​E​R​P​-​d​o​j​r​z​e​w​a​,​4​1​0​0​2​7​.​h​tml

Dodaj komentarz

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