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:
- ?samo-uzgadnialność? systemów ERP
- system standardowy i konfigurowalny
- wiedza o uznanych bezpieczny ? wyposażony w standardowe narzędzia chroniące go i pozwalające rozwijać
- ?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?
- ?*?2019-05-12 niestety pierwotny artykuł został usunięty, dlatego jako materiał pozostają tu cytaty, można je jednak traktować jako „reprezentatywne zarzuty i argumenty”.
Bardzo ciekawa dyskusja. Szczególnie zaintregowało mnie w polemice stwierdzenie: „Od ERP nie ma odwrotu!”. Uczestniczyłem w projektach gdzie mogę z całą pewnością potwierdzić tą tezę. Z jedną poważną uwagą: niestety w projektach tych miałem doczynienia z tzw. decyzjami „politycznymi”. Nie wiedzieć czemu, pomimo twardych argumentów i solidnej analizy SWOT, Komitet Sterujący podejmował decyzję, że od ERP danego dostawcy nie ma odwrotu. Z tego też powodu pozwolę sobie sparafrazować zacytowane na wstępnie stwierdzenie na: „W niektórych projektach IT od polityki nie ma odwrotu”. Jak sobię z tym radzę? Dopisuje na listę ryzyk i zagrożeń projektowych następujący wpis: „Występowanie decyzji politycznych”. Żaden z tego typu projektów, w moim siedmioletnim doświadczeniu nie zakończył się sukcesem (przekroczono terminy i budżet).
Dążenie do jednego idealnego ERP, realizującego komplet procesów w firmie tak aby wszystkie działy firmy były z tego zadowolone, jest tak samo idealistyczne jak dążenie do konkurencji doskonałej w mikroekonomii. Czyli jest taki model teoretyczny opisany ale nieosiągalny.
Jeśli nie chcemy robić żadnych integracji z ERP, to jak to się ma do outsourcingu usług – innego popularnego zjawiska, często zbyt idealistycznie przedstawianego? Jeśli chcemy powierzyć część usług firmie zewnętrznej to często jest to niemożliwe bez udostępnienia naszych danych lub pobierania wyników ich pracy. Chodzi mi nie tylko o biuro księgowe podane w przykładzie ale także usługi call center, zewnętrzne zespoły handlowców.
Bardzo ciekawa dyskusja…Chciał bym zauważyć że również na gruncie administracji państwowej ma ona istotne znaczenie. Osobiście również jestem zwolennikiem integracji, nie tylko w zakresie systemów klasy ERP, a w przypadku administracji również innych systemów. Ponda to w przypadku administracji model integracyjny „działa antykorupcyjnie”. Łatwiej korumpować podczas zamówienia systemu za 20 mln niż zamówienia kilku zintegrowanych systemów za 2 czy 3 mln.
Przyznam się, że antykorupcyjność to faktycznie ciekawa, pozatechniczna, „zaleta” systemu wdrażanego relatywnie małymi etapami… Nie raz od zarządów prywatnych firm słyszałem, że dobry i skuteczny projekt mieści się w roku budżetowym, każdy większy tak należy „dzielić” bo po pierwsze łatwiej nim zarządzać, łatwiej rozliczać i łatwiej oceniać rentowność. Megaprojekty to w ogromnej większości nadużycia, nie tylko w w administracji publicznej.
https://www.iitrun.com/sap-erp-project-failure-lessons-learned-and-mini-case-studies-1/