Przy czym rozumiem to raczej jasko „Cały ERP czy integracja (w domyśle podsystemów dziedzinowych)” – bo co to znaczy „Duzy”? Systemów ERP jest mnóstwo i każdy może sobie wybrać taki odpowiadający jego potrzebom i możliwościom. Jednak obecnie nie ma już alternatywy wobec systemu ERP dla firm liczących – strzelam – ponad 20 użytkowników funkcji standardowo przyjmowanych jako leżących w zakresie ERP. To wynika z przyczyn bardzo praktycznych i bardzo biznesowych. To wynika również z tego iż 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ą? Ależ skąd!

Staram się zrozumieć punkt widzenia Kolegi Blogera – z punktu widzenia analityka procesów taka koncepcja aby zamodelowaną strukturę firmy informatycy odwzorowali w system zintegrowany z dobranych komponentów dziedzinowych jest kusząca. Chylę czoła bo sam nie do końca ogarniam te diagramy i notacje. Jako praktyk na podstawie doświadczenia i wiedzy stwierdzam, że taki system pointegrowany z komponentów dziedzinowych tylko teoretycznie mógłby być systemem ERP – w praktyce nie będzie nim - bo nie może. A skoro nie byłby systemem ERP to nie jest to rozwiązanie.

W tej kwestii konieczne jest przypomnienie fundamentalnych zalet systemów ERP, (które przypomnę bardzo dobrze definiuje angielska strona Wikipedii w opisie tematu mojego blogu). Zalety te są wręcz tak trywialne, że aż zdaje się tracimy je z oka. W tak fundamentalnej sprawie trzeba je przypomnieć.

Mam o tyle łatwo w tej polemice, że temat ten mam przemyślany i przedyskutowany w trakcie wykładów jakie prowadziłem na podyplomowym studium menedżerskim na SGH „Efektywne zarządzanie IT” – zatem wrzucam 4 najważniejsze ze slajdów:

1. „samo-uzgadnialność” systemów ERP
2. system standardowy i konfigurowalny
3. wiedza o uznanych
4. bezpieczny - wyposażony w standardowe narzędzia chroniące go i pozwalające rozwijać

Zanim omówię to pokrótce chciałbym wspomnieć dyskusje jakie toczyliśmy na Politechnice Wrocławskiej coś koło 1990 roku: czy MS Windows ma jakąś przyszłość czy to tylko zabawka. Wtedy zazwyczaj z największą rezerwą o przyszłości „Okien” wypowiadali się koledzy obeznani z systemami UNIX porozumiewający się z nimi za pomocą długich linijek tajemniczych znaków. Inni korzystali z MS-DOS’a, który był bardziej przyjacielski dla użytkowników. To wspomnienie jest o tyle na miejscu, że dyskusja „ERP czy nie ERP” przypomina mi co do natury tamtą – jest to dyskusja pomiędzy „specjalistami” a „użytkownikami”. W tej dyskusji Ci drudzy bezpośrednio nie biorą udziału i nawet z zainteresowaniem (i z podziwem) słuchają i czytają wywody „specjalistów”: dlaczego to „Okna” wtedy a ERP teraz są „be”. Użytkownicy wypowiadają się nazwijmy to „rynkowo” kupując rozwiązania. I nawet jeśli słychać użytkowników niezadowolonych z ERP, to są to głosy wskazujące, że trzeba lepiej wdrażać ERP, a nie przeciwko niemu. Bo przecież aż tylu użytkowników ilu kupuje ERP nie może się mylić.

A teraz przechodzę do omówienia podstawowych zalet systemów ERP, których indywidualnie pointegrowane z komponentów dziedzinowych rozwiązanie nie ma szansy osiągnąć.

Ad. 1 Systemy ERP są systemami działającymi w czasie rzeczywistym (to dotyczy rejestrowanych zdarzeń ale już niekoniecznie skomplikowanych raportów). Czy ktoś pamięta magiczne słowo „uzgadnianie” które padało kiedyś zawsze przy omawianiu specyfiki księgowości w polskich przedsiębiorstwach? Słowo to brzmiało szczególnie złowieszczo 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ć. Ale skoro zbiory danych były rozłączne to i tak „paczki” się wysypywały i trzeba było je ręcznie uzgadniać. W systemie ERP ponieważ 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ć. Przepraszam, że mówię o takich banalnych rzeczach…

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. Parametry są pogrupowane i dostępne w postaci uporządkowanej w procesie budowani prototypu na systemie tzw. „rozwojowym” z którego przenoszone są na testowy a dopiero po pomyślnym przetestowaniu w całości przenoszone są na system produktywny. To zapewnia jasny zgodny z kompetencjami przebieg konfigurowania systemu. W trakcie przejścia na nowy system parametry te są zachowane i tylko w wyjątkowych przypadkach należy wykonywać przy nich jakieś dodatkowe działania. 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. To podkreśla niezwykle niskie ryzyko funkcjonowaniu systemu niezgodnie do oczekiwań. Wykrywane błędy są na bieżąco usuwane przez dostawcę i dostarczane w postaci pakietów serwisowych. Podobnie rzecz się ma przy zmianie przepisó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.

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ć.

Ad. 4 No i tak dochodzimy do ważkiej kwestii odpowiedzialności za system – kto i w jakim zakresie ją za system ponosi? „Monolityczny” system ERP jest jak sejf z zamkniętymi w nim algorytmami. Algorytmy w postaci ustawionych parametrów mogą być zmienione tylko w sposób kontrolowany przez użytkowników biznesowych (a nie informatyków w ich znany im wyłącznie sposób) i ich wydruk może służyć jednoznacznej dokumentacji systemu przyjętego do użytkowania. Odpowiedzialność za nie (za ich ustawienie i przetestowanie) ponoszą wg właściwości pracownicy, którzy brali udział we wdrożeniu, a sposób jej realizacji „zatrzaskuje” w sejfie kierownik jednostki gospodarczej podpisując stosowny dokument. Czegoś takiego w systemie „pointegrowanym” można dokonać tylko w teorii lub ogromnym wysiłkiem organizacyjnym.

Aby zilustrować ten ostatni przypadek posłużę się wspomnieniem dawnych czasów gdy w latach 90 królował u nas informatyczny dziki zachód i każdy kto miał komputer PC i narzędzie programowania systemów relacyjnych (np. Clipper) mógł być dostawca systemu dla biznesu. W polskich firmach królowały wtedy właśnie rozwiązania na różne sposoby pointegrowane z komponentów dziedzinowych czyli różnych efek (F-K) materiałówek i fakturowania. Co to się wtedy działo – tacy dostawcy pojawiali się i znikali, a systemy te regularnie miały awarie! Kto by się wtedy bawił w długie testowanie i dokumentację. Pewnie nikt nie pamięta, ale aby w jakiś sposób chronić użytkowników takich systemów Ustawodawca zawarł nieco kłopotliwe do dziś przepisy w Ustawie o rachunkowości jak np. ten wymóg opisu algorytmów przetwarzania.

Te czasy na szczęście minęły. Systemy ERP oferowane są z niezawodnym serwisem – wielu uważa, że jest drogi, bo już pamięć zanikła, co to oznacza mieć system bez serwisu i jasnej odpowiedzialności dostawcy.

Jak z powyższego widać jestem głęboko przekonany, że w obszarze „core” ERP nie może być mowy o żadnej „dłubaninie” gdyż jakościowo podważa ona sens ERP. Stawia pod znakiem zapytania fundamentalne jego zalety. Zastanówmy się zatem jakie funkcjonalności mogą być „dointegrowane” do ERP bez zagrożenia „zepsucia” go.

Taką 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. Na pewno do takich funkcjonalności należą przeróżne analityczne i prognostyczne czyli takie, w których przepływ informacji jest jednokierunkowy od ERP. Przykładem podręcznikowym takiej funkcjonalności którą wręcz należy „odintegrować” z ERP jest wielowymiarowe raportowanie. I tu wszyscy producenci ERP (ci najwięksi) zrozumieli to sami dawno temu i to doprowadziło do powstania systemów „hurtowni danych”.

Przypomnijmy ten proces: systemy ERP obrastały w nowe funkcje, ale okazało się, że pewne z nich zaczynają tak lawinowo obciążać serwery baz danych ERP, że zaczęło to zagrażać to ich fundamentalnej zalecie pracy w czasie rzeczywistym. Otóż zaczęło się zdarzać coraz częściej, że kiedy analityk (tak nazwijmy roboczo tą osobę) zapuścił raport ze szczególnie pomysłowo pozagnieżdżanymi kryteriami wyszukiwania, to na dłuższą chwilę „siadał” silnik bazy danych. W efekcie inni użytkownicy systemu oglądali przez dłuższy czas przekręcający się zegar piaskowy czyli tak zwaną klepsydrę. Jednych to cieszyło bo mogli pójść na kawę albo uciąć sobie pogawędkę, a innych nie cieszyło. Np. klient czekający na wydrukowanie faktury nie był zazwyczaj tą okolicznością tak ucieszony. W firmach mieszczących się w wielkich biurach typu „open space” prowadziło to do zabawnych i ciekawych dla badacza sytuacji kiedy po pewnej chwili oglądania klepsydry widać było kręcących się na swoich fotelach pracowników – to byli na pewno ci, którzy w danej chwili zajmowali się pracą w systemie. Potem wreszcie ktoś krzyczał na całe biuro pytanie – w wolnym tłumaczeniu: „kto zapuścił znowu ten długi raport” i robiło się ciekawie. Ale zostawmy to badaczom kultur biurowych. Kiedy pojawiły się dowcipy zagrażające pozycji marketingowej dostawców systemów ERP – np. skrót SAP tłumaczono „Sanduhr Anzaige Programm” – czyli program do wyświetlania zegara piaskowego - trzeba było działać i ten zbiorowy wysiłek dostawców systemów ERP zaowocował powstaniem hurtowni danych.

Innymi słowy ewolucyjne puchnięcie systemów ERP w funkcje i w dane zaowocowało ileś tam lat temu (to ile zostawiam już historykom informatyzacji biznesu) „wypączkowaniem” z systemów ERP osobnej bazy danych do której według schematów bardziej użytecznych dla analityków są kopiowane i agregowane dane z systemu ERP (i nie tylko co należy podkreślić), która wyposażona została w narzędzia do tworzenia analiz. Od razu widać, że to w pewnym sensie stanowiło ruch wbrew kierunkowi rozwoju ERP gdyż tak powstały osobny system pozbawiony był cechy dostępu do najbardziej aktualnych danych. O ile mi wiadomo takie replikacje danych wykonywane są nie częściej niż raz na dzień zatem dane są zdezaktualizowane o jeden dzień. Jednak to przeważnie celom analitycznym nie przeszkadza i jest kompromisowym rozwiązaniem, które zdaje się wszystkim na razie odpowiada.

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. 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 typy 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 – to już temat na zupełnie inny wątek.

zapraszam do dyskusji!