Pojawiła się polemika do mojego artykułu  Duży monolityczny ERP czy integracja (fragment, gorąco polecam cały wpis):

Witam Kolegę Blogera i na powitanie mam małą polemikę. Otóż nie mogę się zgodzić na tak szeroko postawione pytanie “Duży ERP, czy integracja” gdyż na nie odpowiedziała już Historia. Od ERP nie ma odwrotu! (RE: Duży ERP czy integracja – ERP -view.pl – System ERP, CRM, ERP, Business Intelligence, MRP).^?*?

Jako, że zostałem wywołany do tablicy :), odpisuję. Zakładam, że powyższą lekturę już Państwo mają za sobą, jeżeli jednak nie, cytuje treści, które omawiam.

Na początek proponuję uzgodnić jedną rzecz: definicję pojęcia System ERP. Skorzystam z sugestii adwersarza i zacytuję definicję z angielskiej WIKI:

Enterprise resource planning (ERP) systems integrate internal and external management information across an entire organization, embracing finance/accounting, manufacturing, sales and service, customer relationship management, etc. ERP systems automate this activity with an integrated software application. The purpose of ERP is to facilitate the flow of information between all business functions inside the boundaries of the organization and manage the connections to outside stakeholders.[źr. Bidgoli, Hossein, (2004). The Internet Encyclopedia, Volume 1, John Wiley & Sons, Inc. p. 707.]

Kluczem jest oczywiście to: “integrate internal and external management information across an entire organization” (integrować wewnętrzną i zewnętrzną informację zarządczą w całej organizacji). W efekcie każde oprogramowanie spełniające powyższe wymagania to system ERP. Co ciekawe definicja ta jawnie uznaje integrację: “..internal and external..”. Nigdzie autorzy wielu definicji ERP nie dodają słowa “monolithic”.

Tak wiec to co tu nazwano “ERP systems” to pewien określony zestaw funkcjonalności. W dalszej części będę używał z dużej litery pisanego System ERP w rozumieniu tak zwanego “monolitu”, a z małej, system ERP w rozumieniu pewnego “zestawu funkcjonalności” (abstrahując od tego czy jest to monolit czy zintegrowany pakiet aplikacji).  Dodam także jedna ważną rzecz: integracja to wymiana danych a nie “jakieś spinanie systemów”. Kiedyś “podpinano” się do bazy danych integrowanych systemów, to prehistoryczna i najgorsza metoda integracji. Obecnie systemy wymieniają między sobą dane tak wewnątrz jednej organizacji jak ze swoim otoczeniem (aplikacjami kontrahentów i urzędów).

Żaden System ERP (czym by w tym momencie nie był) nie jest samotną wyspą na oceanie, jest “czymś” zintegrowanym z innymi w jego otoczeniu systemami (np. z pomocą systemów EDI). Wniosek jest dość prosty: integracja z innymi (cudzymi) komponentami jest niejako “w standardzie”.  Pytanie brzmi: jakie ma znaczenie to, czy komponentów tych jest pięć czy sześć i gdzie on są, skoro i tak będą to odrębne komponenty, od czego i tak tego nie ma ucieczki z uwagi na wymaganą e-współpracę z innymi podmiotami.

Tak więc teza jakoby “system pointegrowany z komponentów dziedzinowych tylko teoretycznie mógłby być systemem ERP, w praktyce nie będzie nim – bo nie może.”  jest tu nie do obrony (i dlaczego nie może?).

Popatrzmy na poniższe kluczowe cechy, argumenty:

1. ?samo-uzgadnialność? systemów ERP
2. system standardowy i konfigurowalny
3. wiedza o uznanych bezpieczny ? wyposażony w standardowe narzędzia chroniące go i pozwalające rozwijać
4. ?Systemy ERP są systemami działającymi w czasie rzeczywistym (to dotyczy rejestrowanych zdarzeń ale już niekoniecznie skomplikowanych raportów).?

Każdy system rejestrujący zdarzenia pracuje (może) w czasie rzeczywistym, nie jest to cecha wyróżniająca ERP. Argumentowanie za monolitem słowami: “na koniec roku obrotowego i oznaczało, że bardzo wielu ludzi będzie siedzieć po nocach czasem nawet w Sylwestra aby tylko zapisy w księgach się zgodziły. To jest też cecha immanentna systemów pointegrowanych z komponentów dziedzinowych choć integratorzy dokonywali cudów aby to uzgadnianie jak najbardziej zautomatyzować.”

Nie mam pojęcia dlaczego siedzenie po nocach miało by być immanentną cechą systemów “pointegrowanych”. Powyższe siedzenie i błędy są cechą niezintegrowanego systemu niepowiązanych ze sobą aplikacji. Z mojego doświadczenia powyższe jest “immanentną” cechą kastomizowanych u klienta Systemów ERP.  W kwestii raportów: to piękny przykład porzekadła: “system od wszystkiego jest do niczego”. Nawet producent pakietu SAP uznał, że zewnętrzny zintegrowany z SAP, program Business Object (producent SAP kupił to oprogramowanie i oferuje jako osobną aplikację) sprawuje się lepiej.

Owa “uzgadnialność” to kwestia poprawności implementacji. Dokumenty i zdarzenia gospodarcze mojej firmy są rejestrowane w moim systemie, rozliczenia prowadzi mi biuro księgowe. Oba systemy są zintegrowane i nie mam problemu z “uzgadnialnością”. Panie z biura rachunkowego niczego po nocach nie uzgadniają, a prowadzą rachunkowość ponad stu firm na swoim systemie, systemy klientów i biura rachunkowego mogą być zintegrowane z sobą i dane są wymieniane (w czasie rzeczywistym). To działa i nie kosztowało majątku. Ale biuro rachunkowe nie każe swoim klientom koniecznie używać swojego systemu (kogo by na to namówili?).

Po drugie “każdemu działaniu związanemu z zasobami przedsiębiorstwa towarzyszy zapis w księgach wg ustalonych algorytmów, a księgi te są wspólne to żadnego uzgadniania nie trzeba już robić”. To argument dla mnie dziwny, bo chyba nikt przy zdrowych zmysłach nie dzieli księgi głównej na pół by ją potem integrować. Po drugie jedno przedsiębiorstwo ma jedną “księgę” a nie “księgi, które trzeba uzgadniać”, uzgadniania wymagają salda kont lub księgi holdingów. Obecnie jednak, w dobie rozbudowanych systemów kontrolingowych, tak zwana analityka, to dane przetwarzane w osobnych dziedzinowych systemach (metody pozabilansowe zarzadzania kosztami).

Ad.2. Cechą systemów ERP jest, że są to systemy zawierające standardowe funkcje biznesowe, których działanie determinowane jest poprzez ustawione parametry.

Po pierwsze pojęcie standardowej funkcji biznesowej, gdyby istniało, znaczyło by, że skoro jest taka standardowa to znaczy, że łatwo ją “wytworzyć” więc jej istnienie nie jest żadnym “osiągnięciem”.

Dopisywanie programów powinno być ściśle limitowane gdyż zawsze w istotny sposób zwiększa ryzyko błędów pomimo znacznie intensywniejszego testowania takich dodatków.

Dopisywanie owszem, ale kupno gotowych nie, w końcu System ERP to także kupione gotowe oprogramowanie. Kupno gotowego dziedzinowego oprogramowania nie generuje błędów.

Komponenty dziedzinowe mogą zapewne w podobny sposób być parametryzowane ale ich właściwe wzajemne działanie – ponieważ zostało indywidualnie skonstruowane -podlega ryzyku jak dla napisanych programów.

Nie rozumiem dlaczego. Komponent dziedzinowy to taki twór, który na zewnątrz postrzegany jest jako źródło standardowej informacji (danych). Cała specyfika (indywidualizm) jest w nim zamknięty. Standardową informacją jest np. treść faktury VAT, dokumentu WZ, PZ, zamówienia. Dokumenty te (te dane) są wytwarzane w jednych firmach i księgowane w innych, dzieje się to bez żadnego problemu, nie ma tu znaczenia czy odbywa się to poprzez przepisanie z papieru czy drogą elektroniczną po zintegrowaniu systemów kontrahentów. W ramach jednej firmy (wiele firm tak pracuje) faktury są wystawiane w systemach CRM i księgowane w systemach ERP w tej samej formie, faktury obce są często wprowadzane do systemu workflow, sprawdzane i zatwierdzane, a potem automatycznie (system zintegrowany!) lądują w księgach systemów ERP. Przykładów można przytaczać masę. Nie ma żadnego z tym problemu, wygoda jest taka, że w opisanym układzie każdy z tych systemów można w dowolnym momencie bez kłopotu wymienić na inny (ERP, workflow, CRM). Mając to wszystko w jednym Systemie ERP było by to niemożliwe, a nie raz zmiany w firmach wymuszają takie potrzeby. Kolejny przykład: producent SAP nie tylko sam oferuje odrębny system BI jakim jest Business Object (raportowanie) ale też zaleca używanie (i integrowanie) oprogramowania: OpenText, jako systemu workflow do obsługi zaawansowanych obiegów dokumentów. SAP ma już nawet specjalne do tego wbudowane interfejsy.

Ad.3. Wiedza na temat funkcjonowania znanych systemów staje się wiedzą publiczną co znacznie ułatwia szkolenie jak i pozyskiwanie już przeszkolonych pracowników. Syndrom pracownika posiadającego ogromną unikalna wiedzę, który znika z dowolnego powodu zabierając ją ze sobą przy używaniu systemu ERP we właściwy sposób nie ma prawa wystąpić.

Nie wiem co autor miał na myśli, jaką standaryzację, biorąc pod uwagę fakt, że Systemów ERP są na rynku setki. Zmiana miejsca pracy w zasadzie zawsze oznacza zmianę narzędzia pracy. Owa unikalna znikająca” z firmy wiedza to efekt złego zarządzania a nie takiego czy innego systemu ERP, zresztą nie dotyczy to ERP a procedur wewnętrznych (a raczej ich braku, skoro wiedza “opuściła” firmę).

Ad.4. No i tak dochodzimy do ważkiej kwestii odpowiedzialności za system: kto i w jakim zakresie ją za system ponosi.

To akurat jest proste: to zależy jak w firmie zdefiniowane są uprawnienia i obowiązki. To co adwersarz opisuje to nic innego jak poprawne zarządzanie prawami i Systemy ERP nie mają tu jakiejkolwiek wyłączności.

Boję się myśleć, dlaczego adwersarz porównuje obecne Systemy ERP z wadami produktów z początku lat 90-tych. Obecnie są to “wady” niespotykane. Owszem są na rynku produkty złe, z błędami itp. ale dotyczy to w równym stopniu Systemów ERP jak i systemów ERP.

Pojęcie “dłubaniny”, podobnie jak jakieś “pointegrowanie” systemów rozumiem jako pejoratywne określenie niskiej jakości usług i produktów ale nie o tym tu, mam nadzieję, mowa. Jeżeli jednak miało tu miejsce porównanie niskiej jakości systemów integrowanych z wysokiej jakości Systemem ERP to niestety jest to tylko demagogia. Obecnie dłubaniną jest raczej kastomizacja monolitycznego Systemu ERP.

Ku mojemu zaskoczeniu, na końcu lektury, znajduję:

Taką [dziedzinową] funkcjonalnością mogą pod pewnymi warunkami być systemy naliczania płac jako że ich integracja z resztą ERP podlega na księgowaniu listy płac co i tak zachodzi w postaci czegoś w rodzaju paczki.

Bingo! Tak właśnie się poprawnie integruje dziedzinowe systemy. Dodam jednak, że poza listą płac (jeden dokument) nie raz przenoszone są także dane o przelewach dla poszczególnych pracowników czyli poszczególne pozycje listy płac także. Podejrzewam, że to “przyznanie się do integracji” ma prosty powód: znakomita większość monolitów ERP nie ma modułu płacowego więc trzeba “przeprosić się z integracją”…

I dalej mamy: “Takich funkcjonalności, które wyodrębniają się z ERP lub do niego dołączają jest coraz więcej co owocuje powstawaniem architektur otwartych na taką integrację nazywanych SOA realizowanych w SAP poprzez SAP NetWeaver.? Bingo! Mamy jednak dobrze “pointegrowane” systemy!

Bardzo mi się podoba puenta adwersarza:

Architektura systemów biznesowych, których składnikiem jest ERP przypomina obecnie architekturę komputerów (przynajmniej tych sprzed 20 lat, które znałem) gdzie różne samodzielne lub “pół-samodzielne” komponenty typu ERP, BW, CRM itd. integrowane są za pomocą standardowej magistrali danych. Co jako elektronik z wykształcenia z pewnym rozbawieniem odnotowuję. Do czego to prowadzi? Czy pojawią się (a może już są) odpowiedniki mikroprocesorów wielordzeniowych albo super wypasionych kart graficznych, które wkłada się w “slot” ewentualnie wgrywa do tego jakieś sterowniki i już działa?.

Ja także jestem elektronikiem z wykształcenia i także podoba mi się to, że powstały standardowe interfejsy i modele danych, które podobnie jak “slot” służą do łatwej integracji systemów dziedzinowych. W inżynierii oprogramowania nazywa się to API i plug-and-play. Mamy standardowe protokoły: webservice czy REST i to są owe “szyny komunikacyjne”. Mamy standardowe struktury danych (standaryzowane modele np. na potrzeby EDI czy SCM).

Z lektury polemiki adwersarza wnioskuje, że pod pojęciem System ERP kryje się tak zwany “korzeń” biznesowy, finanse czyli szeroko rozumiane dowody księgowe i wszelkie operacje z nimi związane. Jest to nic innego jak system dziedzinowy (jeden z wielu). Faktem jest, że to centralny system biznesowy ale tego nikt nie neguje. Autor sam przytacza przykład SOA jako “kleju” do budowy zintegrowanych środowisk (ERP plus CRM, plus BI plus workflow itd.), ja jedynie zwracam uwagę, że SOA to model architektury a nie technologia. Technologią są raczej konkretne produkty z grupy ESB.  Tak pojmowanego Systemu ERP (finanse i okolice) nikt rozsądny nie będzie rozdzielał, ale pamiętajmy, że nowoczesne zarządzanie już dawno zaadaptowało pojęcie pozabilansowych metod zarządzania danymi (głównie koszty) w firmach, a to nic innego jak właśnie wydzielanie dziedzinowych “podsystemów” w obszarze firm i integrowanie ich przekazując standardowe, przetworzone dane “paczkami” do centralnej rachunkowości (dane bilansowe).

Takie podejście, dziedzinowe działy w firmach i dziedzinowe podsystemy dla nich, w ogóle umożliwia sprawne działanie. Coraz powszechniejsze staje wydzielanie podmiotów zależnych lub ich wchłanianie. Mając jeden wielki System ERP niemożliwe jest “proste” wydzielenie zależnej spółki logistycznej czy obsługi HR. Nie raz widywałem prawnicze łamanie głowy jako podzielić licencję ERP na kawałki lub połączyć w przypadku pączkowania czy fuzji spółek.

Praktyka pokazuje, że oprogramowanie jest tym lepsze im lepiej odwzorowuje świat rzeczywisty organizacji i firm, a ten nie jest monolityczny. Po drugie sam fakt rosnącego znaczenia elektronicznej wymiany danych pomiędzy firmami powoduje, że już nic nie będzie jednym monolitycznym systemem, a na integrację jesteśmy skazani. Czy ona jest zła? Nie, cieszymy się, że można już kupić atrament czy toner innego producenta do posiadanej drukarki, że można użyć uniwersalnej ładowarki do telefonu komórkowego, cieszmy się, że można użyć np. innego HR niż ten od naszego ERP?

Na początku swojego wywodu mój adwersarz pisze:

ERP jest obecnie powszechną technologią informacyjną pozwalającą ogarnąć zasoby firm i organizacji na całym Świecie. Czy te wszystkie firmy i organizacje mylą się i idą uwiedzione tylko jakąś nieracjonalna modą?

Tu moim skromnym zdaniem: ERP to nie technologia, to pewien pakiet funkcjonalności, co potwierdza definicja, na którą sam adwersarz się powołuje. Nie znam firmy, która nie miała by choć jednego dziedzinowego podsystemu zintegrowanego z posiadanym ERP.  Jeżeli ERP (czy ERP II) uznajemy za pewien zestaw funkcjonalności (są na rynku nawet do kupienia takie standardowe specyfikacje), to nie znam z praktyki ani z literatury, żadnego przypadku potwierdzającego tezę, że system ERP w firmie to jeden pakiet oprogramowania od jednego dostawcy, bo to raczej nazywało by się vendor lock, jest to coś czego większość firm raczej unika.

Czuje tu pewne nieporozumienie. Dlaczego? Autor polemiki sam pisze: “Architektura systemów biznesowych, których składnikiem jest ERP…”. Tak więc faktycznie, zawężając nieco pojęcie “system ERP”, jest on prawie zawsze składnikiem … większej – zintegrowanej – całości.

Na koniec polecam także mój wpis na podobny temat: Projektowanie czegoś dla gotowego ERP nie ma sensu?czy aby na pewno?

Koniec roku się zbliża, czas na podsumowania i prognozy :), pierwsze publikacje już są. Co się pisze o ERP:

Monolityczne rozwiązania wspierające zarządzanie to przeszłość. Dziś liczą się: wszechstronność, otwartość na zmiany, prostota obsługi, możliwości integracyjne. Wybór najlepszego systemu ERP staje się coraz trudniejszy. (za Biznes wychodzi z objęć systemu – Computerworld).

Jak osiągnąć “wszechstronność i otwartość na zmiany”? Na początek może małe review moich wcześniejszych tekstów na ten temat:

Przewiduję powolne odchodzenie od idei systemów zintegrowanych. Dotychczasowa ich zaleta czyli pełna integracja przestaje być zaletą a staje się garbem. System zintegrowany można już ?skleić? ze specjalizowanych aplikacji, komponentów. […] Drugim powodem przewidywanego odejścia od tej idei są ogromne kłopoty z oceną rentowności wdrożenia systemu ERP. Nie raz jest to po prostu wręcz niemożliwe z powodu braku możliwości oceny jakim kosztem wspieramy pojedynczy proces biznesowy bo trudno z jednego ogromnego systemu “wykroić” koszt wsparcia pojedynczego procesu. (Marzec 2007, Czy to już nadchodzący koniec zintegrowanych ERP?)

Jeżeli dostawca dużego ERP mówi, że duży ERP jest najlepszy to należy to traktować tak samo jak ofertę dostawcy dużego zestawu garnków ze stali nierdzewnej, z których i tak na co dzień używamy jednego a naleśniki i tak robimy z pomocą kupionej wcześniej dobrej teflonowej patelni bo do naleśników lepsza a zamiana jej na nową z nierdzewki tylko dlatego, że ?z kompletu? przeczy zdrowemu rozsądkowi i używa się jej mimo, że pokrywka z zestawu lekko wystaje ? ale przykrywa bo taki jest jej główny cel (w zasadzie tylko nie powinna być mniejsza ani zbyt duża). (Listopad 2009 Nigdy więcej ERP w jednym kawałku!).

Jak zacząć? Najpierw analiza tego co i jak robimy. Potem podział tego na obszary standardowe, które obsłużymy narzędziem uniwersalnym i pozostałe, których z reguły jest bardzo mało ale są bardzo ważne dla nas. te drugie obsłużmy po swojemu ale nie pakujmy się w niszowe lub przestarzałe technologie. Nie dawajmy także wiary w to, że kupno tego co ma (powielenie tego co robi) nasz konkurent uczyni nas bardziej konkurencyjnymi bo praktyka pokazuje coś zupełnie odwrotnego. (sierpień 2010, Wymagania na oprogramowanie ERP wspomagające zarządzanie: dwie kupki).

Nowe systemy zintegrowane ERP będą pewnymi zestawami gotowych funkcjonalności, zbudowanymi w oparciu o szkielety oprogramowania zaś integracja będzie bazowała nie na współdzieleniu danych, a na wymianie ich pomiędzy modułami i zewnętrznymi systemami na równych prawach. Rozwój systemu w takim przypadku polega na tworzeniu nowych modułów tym środowisku a nie na modyfikacji już istniejących. (Styczeń 2011, Frameworks Introduction ? czyli jak się psuje dobre ERP).¹

Bo niezależnie od tego jak ?uniwersalny? jest system ERP zawsze będzie gorszy od kilku dobrze dobranych ale niezależnych komponentów. Gorszy nie dlatego, że ?brzydszy? ale dlatego, że będzie kulą u nogi firmy, która powinna jednak reagować na zmiany na rynku w ciągu tygodni a nie lat? Po drugie modyfikacja jakiegokolwiek oprogramowania zawsze wymaga testowania całości, tak więc im mniejsze kawałki mamy tym szybciej i taniej wprowadza się do nich zmiany bo ich oddanie do użytku po modyfikacji jest łatwiejsze i szybsze zarazem. Pamiętajmy pewną starą reklamę: ?Banki od wszystkiego są do niczego??. (Kwiecień 2011, Czego najbardziej brakuje systemom klasy ERP?).

Od lat mówi się o SOA, jako o metodzie budowy i integracji systemów (tu już mamy integrację a nie tylko zdalne użycie). Jednak pojawia się tu potrzeba tworzenia pośredniczącego, kosztownego,  elementu architektury (ESB) co skutecznie ograniczyło zastosowanie tej metody (a raczej technologii) integracji systemów. Cloud Computing to zupełnie inne podejście. To komponentowa architektura znana od lat. (Październik 2011, Cloud Computing to architektura systemu).²

Pojawia się teza:

“ERP jest dziś narzędziem do gromadzenia i składowania wszelkich informacji potrzebnych do podejmowania decyzji w biznesie. Jako takie jest dziś ważniejsze niż kiedykolwiek wcześniej” – podkreśla Nidal Haddad.³ (za  Biznes wychodzi z objęć systemu – Computerworld).

Jeżeli faktycznie tak dostawcy postrzegają systemy ERP (co zresztą wydaje się być właściwe) to nie dziwi fakt, że np. zarządzanie dokumentami, wspomaganie przepływu pracy (workflow) czy wspomaganie podejmowania decyzji (systemy raportowe, business inteligence) to coraz częściej jednak odrębne, integrowane podsystemy. Widać ten trend już na rynku. Np. jeden z liderów rynku ERP, firma SAP, kupił produkt (firmę) Business Object włączając go do swojej oferty jako narzędzie BI,⁴  do zarządzania dokumentami i ich przepływem SAP poleca dedykowany do tego celu system OpenText. ⁵SAP nie jest tu jedynym dostawcą ERP. Podobną strategię zaczynają prezentować i inni liderzy rynku ERP. Tak więc już nie jeden ERP II… O czym to świadczy? O “rozpadzie” idei systemu zintegrowanego:

Uniwersalność oprogramowania wspierającego zarządzanie powoduje, że zacierają się historyczne podziały branżowe. “Wcześniej myślano o systemach klasy ERP jako o narzędziach dających przewagę konkurencyjną. Dzisiaj rozwiązania tego typu stały się bardziej powszechne. Standaryzacja poprzez ERP nie daje przewagi nad konkurencją” – podkreśla Tomasz Bejm, Technology Consulting Leader w firmie PrcewaterhouseCoopers.³.

I jak widać nie ja jeden tak uważam, powielanie rozwiązań nie daje przewagi a wręcz ją zabija.  wspominałem o tym już w 2007 roku (cytat na początku tekstu).

Pora na Cloud Computing:

Analitycy są zgodni, że szczególną rolę w zakresie rozwoju oprogramowania biznesowego odgrywać będzie technologia Cloud Computing. W miarę rozwoju technologii internetowych spodziewać się można wzrostu użyteczności oprogramowania biznesowego oferowanego w modelu usługowym.³ .

Jednak tu należy się pewne wyjaśnienie. Cloud Computing (CC) to nie zwykły outsourcing oprogramowania w postaci znanej od ponad 10 lat jako ASP czy ostatnie SaaS (osobiście nie widzę różnicy poza technologią).  CC to rozbudowane, oferowane na rynku, gotowe do użycia komponenty. Moim zdaniem podawanie jako przykładu CC rozwiązań, których używa się jak innych aplikacji jest błędem. CC to coś do poszerza możliwości posiadanego oprogramowania ale w tle:

Moim zdaniem każdy, chcący liczyć się na rynku dostawca ERP, w zasadzie musi się z tym pogodzić lub wypadnie z rynku. Najpierw rynek zmusił dostawców ERP do udostępnianie interfejsów integracyjnych, tak zwanych API (ang. application progamming interfejs) , choć nadal są oportuniści wśród dostawców tych systemów. Teraz pora pogodzić się z tym, że powstają (będą) komponenty rozszerzające funkcjonalności podstawowych wersji ERP a koszt udostępnienia API (licencjonowanie) będzie spadał. Możliwości udostępniane przez te API od pewnego czasu pozwalają już na budowanie ?chmur?⁶.

Podsumowanie

Rynek stale się rozwija i dojrzewa. Praktycznie każda większa firma doświadczyła w jakiejś formie wdrożenia gotowego, dostosowywanego do potrzeb, oprogramowania ERP. Warto jednak podkreślić, że idea jednego “super systemu” ERP II, odchodzi powoli do lamusa. Moim zdaniem to kwestia roku, dwóch. Pierwsze symptomy to zalecenia producentów dużych systemów: wdrażać gotowe oprogramowanie w postaci “gotowej” tylko tam gdzie pasuje, obszary specyficzne dla firmy opisać i zaprojektować dla nich dedykowane rozwiązanie i zintegrować. Dobry system ERP to środowisko programistyczne (tak zwany framework, szkielet). Systemy, nazwę je “zapóźnione”, nadal wymagają ingerencji w ich kod by cokolwiek osiągnąć. Kompromisem jest sytuacja, w której system ERP ma bogaty interfejs (tak zwane [[API, Application Programming Interface]]) pozwalający na integrację dedykowanych podsystemów lub właśnie zewnętrznych komponentów czyli korzystania z możliwości jakie daje Cloud Computing).  Przyszłość to komponenty…

(J.Ż. 2011)

Rok 2018

Polskie firmy odchodzą od wdrażania systemów monolitycznych. W czasach cyfrowej transformacji i dynamicznych zmian na rynku trwające ponad rok wdrożenia monolitycznych systemów ERP nie zapewniają dostatecznej elastyczności. Długotrwałe, często kastomizowane rozwiązania praktycznie uniemożliwiają wprowadzanie nowych funkcji czy zmianę logiki systemu w trakcie wdrożenia. Oznacza to duże ryzyko utraty jego zasadności przed zakończeniem prac, a jeszcze większe, zanim zakupiony sprzęt czy licencje zostaną zamortyzowane. Monolityczne systemy wiążą przedsiębiorstwo z określonym dostawcą, co w średniej i długiej perspektywie czasowej utrudnia wprowadzanie zmian i zwiększa koszty. ⁷

Przypisy