Pojawiła się pole­mi­ka do moje­go arty­ku­łu Duży mono­li­tycz­ny ERP czy inte­gra­cja (frag­ment, gorą­co pole­cam cały wpis):

Witam Kolegę Blogera i na powi­ta­nie mam małą pole­mi­kę. Otóż nie mogę się zgo­dzić na tak sze­ro­ko posta­wio­ne pyta­nie ​„Duży ERP, czy inte­gra­cja” gdyż na nie odpo­wie­dzia­ła już Historia. Od ERP nie ma odwro­tu! (RE: Duży ERP czy inte­gra­cja – ERP ‑view​.pl – System ERP, CRM, ERP, Business Intelligence, MRP).^?*?

Jako, że zosta­łem wywo­ła­ny do tabli­cy :), odpi­su­ję. Zakładam, że powyż­szą lek­tu­rę już Państwo mają za sobą, jeże­li jed­nak nie, cytu­je tre­ści, któ­re omawiam.

Na począ­tek pro­po­nu­ję uzgod­nić jed­ną rzecz: defi­ni­cję poję­cia System ERP. Skorzystam z suge­stii adwer­sa­rza i zacy­tu­ję defi­ni­cję z angiel­skiej WIKI:

Enterprise reso­ur­ce plan­ning (ERP) sys­tems inte­gra­te inter­nal and exter­nal mana­ge­ment infor­ma­tion across an enti­re orga­ni­za­tion, embra­cing finance/accounting, manu­fac­tu­ring, sales and servi­ce, custo­mer rela­tion­ship mana­ge­ment, etc. ERP sys­tems auto­ma­te this acti­vi­ty with an inte­gra­ted softwa­re appli­ca­tion. The pur­po­se of ERP is to faci­li­ta­te the flow of infor­ma­tion betwe­en all busi­ness func­tions insi­de the boun­da­ries of the orga­ni­za­tion and mana­ge the con­nec­tions to out­si­de stakeholders.[źr. Bidgoli, Hossein, (2004). The Internet Encyclopedia, Volume 1, John Wiley & Sons, Inc. p. 707.]

Kluczem jest oczy­wi­ście to: ​„inte­gra­te inter­nal and exter­nal mana­ge­ment infor­ma­tion across an enti­re orga­ni­za­tion” (inte­gro­wać wewnętrz­ną i zewnętrz­ną infor­ma­cję zarząd­czą w całej orga­ni­za­cji). W efek­cie każ­de opro­gra­mo­wa­nie speł­nia­ją­ce powyż­sze wyma­ga­nia to sys­tem ERP. Co cie­ka­we defi­ni­cja ta jaw­nie uzna­je inte­gra­cję: „..inter­nal and exter­nal..”. Nigdzie auto­rzy wie­lu defi­ni­cji ERP nie doda­ją sło­wa ​„mono­li­thic”.

Tak wiec to co tu nazwa­no ​„ERP sys­tems” to pewien okre­ślo­ny zestaw funk­cjo­nal­no­ści. W dal­szej czę­ści będę uży­wał z dużej lite­ry pisa­ne­go System ERP w rozu­mie­niu tak zwa­ne­go ​„mono­li­tu”, a z małej, sys­tem ERP w rozu­mie­niu pew­ne­go ​„zesta­wu funk­cjo­nal­no­ści” (abs­tra­hu­jąc od tego czy jest to mono­lit czy zin­te­gro­wa­ny pakiet apli­ka­cji). Dodam tak­że jed­na waż­ną rzecz: inte­gra­cja to wymia­na danych a nie ​„jakieś spi­na­nie sys­te­mów”. Kiedyś ​„pod­pi­na­no” się do bazy danych inte­gro­wa­nych sys­te­mów, to pre­hi­sto­rycz­na i naj­gor­sza meto­da inte­gra­cji. Obecnie sys­te­my wymie­nia­ją mię­dzy sobą dane tak wewnątrz jed­nej orga­ni­za­cji jak ze swo­im oto­cze­niem (apli­ka­cja­mi kon­tra­hen­tów i urzędów). 

Żaden System ERP (czym by w tym momen­cie nie był) nie jest samot­ną wyspą na oce­anie, jest ​„czymś” zin­te­gro­wa­nym z inny­mi w jego oto­cze­niu sys­te­ma­mi (np. z pomo­cą sys­te­mów EDI). Wniosek jest dość pro­sty: inte­gra­cja z inny­mi (cudzy­mi) kom­po­nen­ta­mi jest nie­ja­ko ​„w stan­dar­dzie”. Pytanie brzmi: jakie ma zna­cze­nie to, czy kom­po­nen­tów tych jest pięć czy sześć i gdzie on są, sko­ro i tak będą to odręb­ne kom­po­nen­ty, od cze­go i tak tego nie ma uciecz­ki z uwa­gi na wyma­ga­ną e‑współpracę z inny­mi podmiotami.

Tak więc teza jako­by ​„sys­tem poin­te­gro­wa­ny z kom­po­nen­tów dzie­dzi­no­wych tyl­ko teo­re­tycz­nie mógł­by być sys­te­mem ERP, w prak­ty­ce nie będzie nim – bo nie może.” jest tu nie do obro­ny (i dla­cze­go nie może?).

Popatrzmy na poniż­sze klu­czo­we cechy, argumenty:

1. ?samo-uzgad­nial­ność? sys­te­mów ERP
2. sys­tem stan­dar­do­wy i konfigurowalny
3. wie­dza o uzna­nych bez­piecz­ny ? wypo­sa­żo­ny w stan­dar­do­we narzę­dzia chro­nią­ce go i pozwa­la­ją­ce rozwijać
4. ?Systemy ERP są sys­te­ma­mi dzia­ła­ją­cy­mi w cza­sie rze­czy­wi­stym (to doty­czy reje­stro­wa­nych zda­rzeń ale już nie­ko­niecz­nie skom­pli­ko­wa­nych raportów).? 

Każdy sys­tem reje­stru­ją­cy zda­rze­nia pra­cu­je (może) w cza­sie rze­czy­wi­stym, nie jest to cecha wyróż­nia­ją­ca ERP. Argumentowanie za mono­li­tem sło­wa­mi: ​„na koniec roku obro­to­we­go i ozna­cza­ło, że bar­dzo wie­lu ludzi będzie sie­dzieć po nocach cza­sem nawet w Sylwestra aby tyl­ko zapi­sy w księ­gach się zgo­dzi­ły. To jest też cecha imma­nent­na sys­te­mów poin­te­gro­wa­nych z kom­po­nen­tów dzie­dzi­no­wych choć inte­gra­to­rzy doko­ny­wa­li cudów aby to uzgad­nia­nie jak naj­bar­dziej zautomatyzować.”

Nie mam poję­cia dla­cze­go sie­dze­nie po nocach mia­ło by być imma­nent­ną cechą sys­te­mów ​„poin­te­gro­wa­nych”. Powyższe sie­dze­nie i błę­dy są cechą nie­zin­te­gro­wa­ne­go sys­te­mu nie­po­wią­za­nych ze sobą apli­ka­cji. Z moje­go doświad­cze­nia powyż­sze jest ​„imma­nent­ną” cechą kasto­mi­zo­wa­nych u klien­ta Systemów ERP. W kwe­stii rapor­tów: to pięk­ny przy­kład porze­ka­dła: ​„sys­tem od wszyst­kie­go jest do nicze­go”. Nawet pro­du­cent pakie­tu SAP uznał, że zewnętrz­ny zin­te­gro­wa­ny z SAP, pro­gram Business Object (pro­du­cent SAP kupił to opro­gra­mo­wa­nie i ofe­ru­je jako osob­ną apli­ka­cję) spra­wu­je się lepiej.

Owa ​„uzgad­nial­ność” to kwe­stia popraw­no­ści imple­men­ta­cji. Dokumenty i zda­rze­nia gospo­dar­cze mojej fir­my są reje­stro­wa­ne w moim sys­te­mie, roz­li­cze­nia pro­wa­dzi mi biu­ro księ­go­we. Oba sys­te­my są zin­te­gro­wa­ne i nie mam pro­ble­mu z ​„uzgad­nial­no­ścią”. Panie z biu­ra rachun­ko­we­go nicze­go po nocach nie uzgad­nia­ją, a pro­wa­dzą rachun­ko­wość ponad stu firm na swo­im sys­te­mie, sys­te­my klien­tów i biu­ra rachun­ko­we­go mogą być zin­te­gro­wa­ne z sobą i dane są wymie­nia­ne (w cza­sie rze­czy­wi­stym). To dzia­ła i nie kosz­to­wa­ło mająt­ku. Ale biu­ro rachun­ko­we nie każe swo­im klien­tom koniecz­nie uży­wać swo­je­go sys­te­mu (kogo by na to namówili?).

Po dru­gie ​„każ­de­mu dzia­ła­niu zwią­za­ne­mu z zaso­ba­mi przed­się­bior­stwa towa­rzy­szy zapis w księ­gach wg usta­lo­nych algo­ryt­mów, a księ­gi te są wspól­ne to żad­ne­go uzgad­nia­nia nie trze­ba już robić”. To argu­ment dla mnie dziw­ny, bo chy­ba nikt przy zdro­wych zmy­słach nie dzie­li księ­gi głów­nej na pół by ją potem inte­gro­wać. Po dru­gie jed­no przed­się­bior­stwo ma jed­ną ​„księ­gę” a nie ​„księ­gi, któ­re trze­ba uzgad­niać”, uzgad­nia­nia wyma­ga­ją sal­da kont lub księ­gi hol­din­gów. Obecnie jed­nak, w dobie roz­bu­do­wa­nych sys­te­mów kon­tro­lin­go­wych, tak zwa­na ana­li­ty­ka, to dane prze­twa­rza­ne w osob­nych dzie­dzi­no­wych sys­te­mach (meto­dy poza­bi­lan­so­we zarza­dza­nia kosztami). 

Ad.2. Cechą sys­te­mów ERP jest, że są to sys­te­my zawie­ra­ją­ce stan­dar­do­we funk­cje biz­ne­so­we, któ­rych dzia­ła­nie deter­mi­no­wa­ne jest poprzez usta­wio­ne parametry.

Po pierw­sze poję­cie stan­dar­do­wej funk­cji biz­ne­so­wej, gdy­by ist­nia­ło, zna­czy­ło by, że sko­ro jest taka stan­dar­do­wa to zna­czy, że łatwo ją ​„wytwo­rzyć” więc jej ist­nie­nie nie jest żad­nym ​„osią­gnię­ciem”.

Dopisywanie pro­gra­mów powin­no być ści­śle limi­to­wa­ne gdyż zawsze w istot­ny spo­sób zwięk­sza ryzy­ko błę­dów pomi­mo znacz­nie inten­syw­niej­sze­go testo­wa­nia takich dodatków.

Dopisywanie owszem, ale kup­no goto­wych nie, w koń­cu System ERP to tak­że kupio­ne goto­we opro­gra­mo­wa­nie. Kupno goto­we­go dzie­dzi­no­we­go opro­gra­mo­wa­nia nie gene­ru­je błędów. 

Komponenty dzie­dzi­no­we mogą zapew­ne w podob­ny spo­sób być para­me­try­zo­wa­ne ale ich wła­ści­we wza­jem­ne dzia­ła­nie – ponie­waż zosta­ło indy­wi­du­al­nie skon­stru­owa­ne ‑pod­le­ga ryzy­ku jak dla napi­sa­nych programów.

Nie rozu­miem dla­cze­go. Komponent dzie­dzi­no­wy to taki twór, któ­ry na zewnątrz postrze­ga­ny jest jako źró­dło stan­dar­do­wej infor­ma­cji (danych). Cała spe­cy­fi­ka (indy­wi­du­alizm) jest w nim zamknię­ty. Standardową infor­ma­cją jest np. treść fak­tu­ry VAT, doku­men­tu WZ, PZ, zamó­wie­nia. Dokumenty te (te dane) są wytwa­rza­ne w jed­nych fir­mach i księ­go­wa­ne w innych, dzie­je się to bez żad­ne­go pro­ble­mu, nie ma tu zna­cze­nia czy odby­wa się to poprzez prze­pi­sa­nie z papie­ru czy dro­gą elek­tro­nicz­ną po zin­te­gro­wa­niu sys­te­mów kon­tra­hen­tów. W ramach jed­nej fir­my (wie­le firm tak pra­cu­je) fak­tu­ry są wysta­wia­ne w sys­te­mach CRM i księ­go­wa­ne w sys­te­mach ERP w tej samej for­mie, fak­tu­ry obce są czę­sto wpro­wa­dza­ne do sys­te­mu work­flow, spraw­dza­ne i zatwier­dza­ne, a potem auto­ma­tycz­nie (sys­tem zin­te­gro­wa­ny!) lądu­ją w księ­gach sys­te­mów ERP. Przykładów moż­na przy­ta­czać masę. Nie ma żad­ne­go z tym pro­ble­mu, wygo­da jest taka, że w opi­sa­nym ukła­dzie każ­dy z tych sys­te­mów moż­na w dowol­nym momen­cie bez kło­po­tu wymie­nić na inny (ERP, work­flow, CRM). Mając to wszyst­ko w jed­nym Systemie ERP było by to nie­moż­li­we, a nie raz zmia­ny w fir­mach wymu­sza­ją takie potrze­by. Kolejny przy­kład: pro­du­cent SAP nie tyl­ko sam ofe­ru­je odręb­ny sys­tem BI jakim jest Business Object (rapor­to­wa­nie) ale też zale­ca uży­wa­nie (i inte­gro­wa­nie) opro­gra­mo­wa­nia: OpenText, jako sys­te­mu work­flow do obsłu­gi zaawan­so­wa­nych obie­gów doku­men­tów. SAP ma już nawet spe­cjal­ne do tego wbu­do­wa­ne interfejsy.

Ad.3. Wiedza na temat funk­cjo­no­wa­nia zna­nych sys­te­mów sta­je się wie­dzą publicz­ną co znacz­nie uła­twia szko­le­nie jak i pozy­ski­wa­nie już prze­szko­lo­nych pra­cow­ni­ków. Syndrom pra­cow­ni­ka posia­da­ją­ce­go ogrom­ną uni­kal­na wie­dzę, któ­ry zni­ka z dowol­ne­go powo­du zabie­ra­jąc ją ze sobą przy uży­wa­niu sys­te­mu ERP we wła­ści­wy spo­sób nie ma pra­wa wystąpić.

Nie wiem co autor miał na myśli, jaką stan­da­ry­za­cję, bio­rąc pod uwa­gę fakt, że Systemów ERP są na ryn­ku set­ki. Zmiana miej­sca pra­cy w zasa­dzie zawsze ozna­cza zmia­nę narzę­dzia pra­cy. Owa uni­kal­na zni­ka­ją­ca” z fir­my wie­dza to efekt złe­go zarzą­dza­nia a nie takie­go czy inne­go sys­te­mu ERP, zresz­tą nie doty­czy to ERP a pro­ce­dur wewnętrz­nych (a raczej ich bra­ku, sko­ro wie­dza ​„opu­ści­ła” firmę).

Ad.4. No i tak docho­dzi­my do waż­kiej kwe­stii odpo­wie­dzial­no­ści za sys­tem: kto i w jakim zakre­sie ją za sys­tem ponosi.

To aku­rat jest pro­ste: to zale­ży jak w fir­mie zde­fi­nio­wa­ne są upraw­nie­nia i obo­wiąz­ki. To co adwer­sarz opi­su­je to nic inne­go jak popraw­ne zarzą­dza­nie pra­wa­mi i Systemy ERP nie mają tu jakiej­kol­wiek wyłączności.

Boję się myśleć, dla­cze­go adwer­sarz porów­nu­je obec­ne Systemy ERP z wada­mi pro­duk­tów z począt­ku lat 90-tych. Obecnie są to ​„wady” nie­spo­ty­ka­ne. Owszem są na ryn­ku pro­duk­ty złe, z błę­da­mi itp. ale doty­czy to w rów­nym stop­niu Systemów ERP jak i sys­te­mów ERP.

Pojęcie ​„dłu­ba­ni­ny”, podob­nie jak jakieś ​„poin­te­gro­wa­nie” sys­te­mów rozu­miem jako pejo­ra­tyw­ne okre­śle­nie niskiej jako­ści usług i pro­duk­tów ale nie o tym tu, mam nadzie­ję, mowa. Jeżeli jed­nak mia­ło tu miej­sce porów­na­nie niskiej jako­ści sys­te­mów inte­gro­wa­nych z wyso­kiej jako­ści Systemem ERP to nie­ste­ty jest to tyl­ko dema­go­gia. Obecnie dłu­ba­ni­ną jest raczej kasto­mi­za­cja mono­li­tycz­ne­go Systemu ERP. 

Ku moje­mu zasko­cze­niu, na koń­cu lek­tu­ry, znajduję: 

Taką [dzie­dzi­no­wą] funk­cjo­nal­no­ścią mogą pod pew­ny­mi warun­ka­mi być sys­te­my nali­cza­nia płac jako że ich inte­gra­cja z resz­tą ERP pod­le­ga na księ­go­wa­niu listy płac co i tak zacho­dzi w posta­ci cze­goś w rodza­ju paczki. 

Bingo! Tak wła­śnie się popraw­nie inte­gru­je dzie­dzi­no­we sys­te­my. Dodam jed­nak, że poza listą płac (jeden doku­ment) nie raz prze­no­szo­ne są tak­że dane o prze­le­wach dla poszcze­gól­nych pra­cow­ni­ków czy­li poszcze­gól­ne pozy­cje listy płac tak­że. Podejrzewam, że to ​„przy­zna­nie się do inte­gra­cji” ma pro­sty powód: zna­ko­mi­ta więk­szość mono­li­tów ERP nie ma modu­łu pła­co­we­go więc trze­ba ​„prze­pro­sić się z integracją”… 

I dalej mamy: ​„Takich funk­cjo­nal­no­ści, któ­re wyod­ręb­nia­ją się z ERP lub do nie­go dołą­cza­ją jest coraz wię­cej co owo­cu­je powsta­wa­niem archi­tek­tur otwar­tych na taką inte­gra­cję nazy­wa­nych SOA reali­zo­wa­nych w SAP poprzez SAP NetWeaver.? Bingo! Mamy jed­nak dobrze ​„poin­te­gro­wa­ne” systemy!

Bardzo mi się podo­ba puen­ta adwersarza:

Architektura sys­te­mów biz­ne­so­wych, któ­rych skład­ni­kiem jest ERP przy­po­mi­na obec­nie archi­tek­tu­rę kom­pu­te­rów (przy­naj­mniej tych sprzed 20 lat, któ­re zna­łem) gdzie róż­ne samo­dziel­ne lub ​„pół-samo­dziel­ne” kom­po­nen­ty typu ERP, BW, CRM itd. inte­gro­wa­ne są za pomo­cą stan­dar­do­wej magi­stra­li danych. Co jako elek­tro­nik z wykształ­ce­nia z pew­nym roz­ba­wie­niem odno­to­wu­ję. Do cze­go to pro­wa­dzi? Czy poja­wią się (a może już są) odpo­wied­ni­ki mikro­pro­ce­so­rów wie­lor­dze­nio­wych albo super wypa­sio­nych kart gra­ficz­nych, któ­re wkła­da się w ​„slot” ewen­tu­al­nie wgry­wa do tego jakieś ste­row­ni­ki i już działa?.

Ja tak­że jestem elek­tro­ni­kiem z wykształ­ce­nia i tak­że podo­ba mi się to, że powsta­ły stan­dar­do­we inter­fej­sy i mode­le danych, któ­re podob­nie jak ​„slot” słu­żą do łatwej inte­gra­cji sys­te­mów dzie­dzi­no­wych. W inży­nie­rii opro­gra­mo­wa­nia nazy­wa się to API i plug-and-play. Mamy stan­dar­do­we pro­to­ko­ły: webse­rvi­ce czy REST i to są owe ​„szy­ny komu­ni­ka­cyj­ne”. Mamy stan­dar­do­we struk­tu­ry danych (stan­da­ry­zo­wa­ne mode­le np. na potrze­by EDI czy SCM).

Z lek­tu­ry pole­mi­ki adwer­sa­rza wnio­sku­je, że pod poję­ciem System ERP kry­je się tak zwa­ny ​„korzeń” biz­ne­so­wy, finan­se czy­li sze­ro­ko rozu­mia­ne dowo­dy księ­go­we i wszel­kie ope­ra­cje z nimi zwią­za­ne. Jest to nic inne­go jak sys­tem dzie­dzi­no­wy (jeden z wie­lu). Faktem jest, że to cen­tral­ny sys­tem biz­ne­so­wy ale tego nikt nie negu­je. Autor sam przy­ta­cza przy­kład SOA jako ​„kle­ju” do budo­wy zin­te­gro­wa­nych śro­do­wisk (ERP plus CRM, plus BI plus work­flow itd.), ja jedy­nie zwra­cam uwa­gę, że SOA to model archi­tek­tu­ry a nie tech­no­lo­gia. Technologią są raczej kon­kret­ne pro­duk­ty z gru­py ESB. Tak poj­mo­wa­ne­go Systemu ERP (finan­se i oko­li­ce) nikt roz­sąd­ny nie będzie roz­dzie­lał, ale pamię­taj­my, że nowo­cze­sne zarzą­dza­nie już daw­no zaadap­to­wa­ło poję­cie poza­bi­lan­so­wych metod zarzą­dza­nia dany­mi (głów­nie kosz­ty) w fir­mach, a to nic inne­go jak wła­śnie wydzie­la­nie dzie­dzi­no­wych ​„pod­sys­te­mów” w obsza­rze firm i inte­gro­wa­nie ich prze­ka­zu­jąc stan­dar­do­we, prze­two­rzo­ne dane ​„pacz­ka­mi” do cen­tral­nej rachun­ko­wo­ści (dane bilansowe).

Takie podej­ście, dzie­dzi­no­we dzia­ły w fir­mach i dzie­dzi­no­we pod­sys­te­my dla nich, w ogó­le umoż­li­wia spraw­ne dzia­ła­nie. Coraz powszech­niej­sze sta­je wydzie­la­nie pod­mio­tów zależ­nych lub ich wchła­nia­nie. Mając jeden wiel­ki System ERP nie­moż­li­we jest ​„pro­ste” wydzie­le­nie zależ­nej spół­ki logi­stycz­nej czy obsłu­gi HR. Nie raz widy­wa­łem praw­ni­cze łama­nie gło­wy jako podzie­lić licen­cję ERP na kawał­ki lub połą­czyć w przy­pad­ku pącz­ko­wa­nia czy fuzji spółek.

Praktyka poka­zu­je, że opro­gra­mo­wa­nie jest tym lep­sze im lepiej odwzo­ro­wu­je świat rze­czy­wi­sty orga­ni­za­cji i firm, a ten nie jest mono­li­tycz­ny. Po dru­gie sam fakt rosną­ce­go zna­cze­nia elek­tro­nicz­nej wymia­ny danych pomię­dzy fir­ma­mi powo­du­je, że już nic nie będzie jed­nym mono­li­tycz­nym sys­te­mem, a na inte­gra­cję jeste­śmy ska­za­ni. Czy ona jest zła? Nie, cie­szy­my się, że moż­na już kupić atra­ment czy toner inne­go pro­du­cen­ta do posia­da­nej dru­kar­ki, że moż­na użyć uni­wer­sal­nej łado­war­ki do tele­fo­nu komór­ko­we­go, ciesz­my się, że moż­na użyć np. inne­go HR niż ten od nasze­go ERP?

Na począt­ku swo­je­go wywo­du mój adwer­sarz pisze:

ERP jest obec­nie powszech­ną tech­no­lo­gią infor­ma­cyj­ną pozwa­la­ją­cą ogar­nąć zaso­by firm i orga­ni­za­cji na całym Świecie. Czy te wszyst­kie fir­my i orga­ni­za­cje mylą się i idą uwie­dzio­ne tyl­ko jakąś nie­ra­cjo­nal­na modą?

Tu moim skrom­nym zda­niem: ERP to nie tech­no­lo­gia, to pewien pakiet funk­cjo­nal­no­ści, co potwier­dza defi­ni­cja, na któ­rą sam adwer­sarz się powo­łu­je. Nie znam fir­my, któ­ra nie mia­ła by choć jed­ne­go dzie­dzi­no­we­go pod­sys­te­mu zin­te­gro­wa­ne­go z posia­da­nym ERP. Jeżeli ERP (czy ERP II) uzna­je­my za pewien zestaw funk­cjo­nal­no­ści (są na ryn­ku nawet do kupie­nia takie stan­dar­do­we spe­cy­fi­ka­cje), to nie znam z prak­ty­ki ani z lite­ra­tu­ry, żad­ne­go przy­pad­ku potwier­dza­ją­ce­go tezę, że sys­tem ERP w fir­mie to jeden pakiet opro­gra­mo­wa­nia od jed­ne­go dostaw­cy, bo to raczej nazy­wa­ło by się ven­dor lock, jest to coś cze­go więk­szość firm raczej unika.

Czuje tu pew­ne nie­po­ro­zu­mie­nie. Dlaczego? Autor pole­mi­ki sam pisze: ​„Architektura sys­te­mów biz­ne­so­wych, któ­rych skład­ni­kiem jest ERP…”. Tak więc fak­tycz­nie, zawę­ża­jąc nie­co poję­cie ​„sys­tem ERP”, jest on pra­wie zawsze skład­ni­kiem … więk­szej – zin­te­gro­wa­nej – całości.

Na koniec pole­cam tak­że mój wpis na podob­ny temat: Projektowanie cze­goś dla goto­we­go ERP nie ma sensu?czy aby na pewno?