Wprowadzenie

Notacja EPC (Event-driven Process Chain) została opracowana w 1992 roku w ramach projektu badawczo-rozwojowego z udziałem SAP AG na University of Saarland w Niemczech, a jej twórcą jest dr August-Wilhelm Scheer. Stanowi ona kluczowy element koncepcji modelowania SAP R/3 w zakresie inżynierii biznesowej i dostosowania tego systemu do potrzeb klienta, została włączona także do systemu NetWeaver firmy SAP.

Ostatni duży projekt z jej użyciem realizowałem w 2008 roku dla polskiego oddziału niemieckiego banku WestLB Bank Polska SA. Później już jedynie okazjonalne wsparcie merytoryczne i audyty, nadal się zdarzają.

EPC to notacja modelowania wspierana przez narzędzie ARIS Process Platform, które zapewnia zintegrowany zestaw narzędzi do projektowania, wdrażania i kontrolowania procesów biznesowych. EPC opiera się na koncepcjach sieci stochastycznych i sieci Petriego, jednak stosowanie notacji EPC nie wymaga zbytniego formalizmu, notacja ta nie rozróżnia np. pojęcia produktu aktywności i elementu sterowania przepływem procesu, ponieważ występują one jako skonsolidowane Zdarzenie. [zotpressInText item=”{5085975:BKZ2EMGX}”].

Moim zdaniem jest to niestety powód, dla którego notacja ta nie pozwala na pokazanie np. tego, że produktem danej pracy (aktywność) jest faktura a elementem sterującym procesem jest jej wartość brutto. Wady tej nie ma opracowana później, otwarta notacja BPMN, gdzie operujemy i pojęciem obiektu danych i pojęciem zdarzenia, faktu, lub warunku.

Notacja EPC nie nakłada także sztywnych ograniczeń syntaktycznych, poza generalną zasadą, że na linii sterowania procesem funkcje muszą występować naprzemiennie ze zdarzeniami. W efekcie walidacja diagramów zawierających takie dodatkowe elementy jak: role, komórki organizacyjne, systemy i informacje, jest często uznaniowa.

Notacja EPC jest nadal spotykana w projektach, w których stosowane są system SAP ERP i narzędzie ARIS Toolset [zotpressInText item=”{5085975:C8MC6ZWR}”] (oferuje ono obecnie także możliwość korzystania z innych notacji, miedzy innymi BPMN i UML). Notację EPC można też nadal spotkać na niektórych uczelniach, oprogramowanie ARIS jest nadal dostępne na rynku. Notacja EPC to wartość intelektualna nadal chroniona jako własność firmy IDS Scheer.

Semantyka i syntaktyka eEPC

Notacja EPC pierwotnie zawierała tylko elementy przepływu (bramki logiczne, funkcje i zdarzenia) oraz sztywną syntaktykę (obligatoryjną przemienność funkcji i zdarzeń na linii przepływu sterowania i zdarzenie jako początek i koniec procesu). Szybko została wzbogacona o symbole pozwalające na modelowanie elementów organizacji (systemy, informacje, role, komórki organizacyjne). Dlatego obecnie można spotkać także skrót eEPC (extended EPC).

Przepływ sterowania jest modelowany jako linia kreskowa skierowana, przyporządkowanie funkcji jako zadania komórki organizacyjnej (linia ciągła nieskierowana) oraz przepływ informacji (linia ciągła skierowana). Symbol Ścieżka Procesu to wskazanie (link) na kolejny diagram stanowiący kontynuację procesu. Można tą metodą agregować diagram do symbolu na diagramie nadrzędnym, zachowując jednak zasadę przemienności funkcji i zdarzeń (symbol Ścieżka Procesu na diagramie ma wtedy taką samą syntaktykę jak funkcja na diagramie podrzędnym). Symbol Ścieżka Procesu bywa używany także jako przeniesienie/kontynuacja procesu na kolejnym diagramie, wtedy jest uznawany za zdarzenie (dlatego ikona ta, to właśnie złożenie funkcji i zdarzenia). Poniżej opisane symbole na przykładowym diagramie procesu (fragment diagramu):

Notacja pozwala na dość precyzyjne modelowanie procesów biznesowych co jednak wymaga pewnej dyscypliny. Notacja eEPC nie ma sformalizowanej specyfikacji, należy korzystać z opracowań firmowanych przez autora (AW. Scheer), który podejmuje próby porządkowania semantyki i syntaktyki [zotpressInText item=”{5085975:BKZ2EMGX}”]:

“Każdy model EPC musi od samego początku przestrzegać pewnych prostych zasad projektowania, aby uniknąć lub ograniczyć niepożądane zachowania, takie jak np. martwe punkty. Dlatego nie proponuje się rygorystycznego i złożonego systemu reguł i wzorców projektowych, ponieważ unikanie wszystkich możliwych konfliktów zbytnio ograniczałoby użytkownika. Reguły te są następujące:

1. Trzema podstawowymi węzłami w modelach EPC są aktywności (funkcje), zdarzenia i łączniki [bramki logiczne].
2. Nazwa zdarzenia powinna odzwierciedlać jego charakterystykę jako punktu w czasie, na przykład: “element ukończony”. Jest ono reprezentowane przez sześciokąt.
3. Nazwa aktywności powinna uwzględniać konsumpcje czasu, na przykład: “produkowanie przedmiotu”. Czynność jest przedstawiona w postaci prostokąta o zaokrąglonych rogach.
4. Łączniki [bramki logiczne] są reprezentowane przez okrąg. Wewnątrz okręgu typ łącznika [logika OR, XOR, AND] jest określony za pomocą odpowiedniego symbolu. Łącznik może być podzielony na część górną i dolną, by odzwierciedlić różnice między regułami połączeń przychodzących i wychodzących [lub łączymy kaskadowo proste pojedyncze bramki].
5. Aby jasno określić, kiedy proces biznesowy ma się rozpocząć i jaki jest jego wynik końcowy, każdy diagram EPC rozpoczyna się i kończy jednym lub kilkoma zdarzeniami.
6. Diagram EPC zawiera co najmniej jedną czynność.
7. Model EPC może składać się z kilku diagramów EPC.
8. Krawędzie [linie przepływu sterowania] są skierowane i zawsze łączą dwa elementy odpowiadające sekwencji aktywacji.
9. Zdarzenie nie może być poprzednikiem ani następnikiem innego zdarzenia.
10. Czynność nie może być poprzednikiem ani następnikiem innej czynności.
11. Każde zdarzenie i każda czynność mają tylko jedną krawędź [linia przepływu sterowania] przychodzącą i/lub jedną krawędź wychodzącą.”

Przykłady modeli

Poniżej przykładowy model procesu rejestracji faktur kosztowych.

Używanie elementów rozszerzających nie jest obligatoryjne, dlatego występują na diagramach tam gdzie autor modelu uzna, że chce je zobrazować. Notacja eEPC nie operuje pojęciem statusu więc faktura zaakceptowana i zaksięgowana to dwa osobne elementy informacyjne. Powyższy model procesu Księgowania faktur kosztowych może być podprocesem w procesie Obsługi płatności:

Symboli eEPC można formalnie użyć w innym kontekście, np. budując dodatkowy model struktury organizacyjnej;

Autor notacji proponuje wiele form stosowania swojej notacji, łącznie z wariantami nieuwzględniającymi zasady przemienności “funkcja-zdarzenie” (łamiąc własne zasady), co pokazuje dość swobodne podejście twórcy notacji do modelowania, jak np. na poniższym diagramie:

Podsumowanie

Notacja eEPC i metoda ARIS zdobyły sobie szybko dużą popularność w obszarze analiz i wdrożeń systemów ERP, za sprawą związków firmy IDS Scheer z firmą SAP AG. Jednak po ok. 10 latach istnienia EPC okazało się, że jej niedostatki formalizacyjne powodowały dość niską jakość modeli za sprawą ich niejednoznaczności (ww. brak formalizmu).

W odpowiedzi na powyższe powstała znacznie lepiej dopracowana notacja BPMN. Notacja BPMN została pierwotnie opracowany przez organizację Business Process Management Initiative (BPMI). Wersja 1.0 została udostępniona publicznie w maju 2004 roku. W czerwcu 2005 r. BPMI połączyło się z OMG (Object Management Group). Formalna specyfikacja BPMN została wydana przez OMG w lutym 2006 roku (https://www.omg.org/spec/BPMN/). Co ciekawe, w pracach nad BPMN brały udział, między innymi, firmy IDS Scheer, Software AG i SAP AG.

Moim zdaniem rozpoczynanie projektów z jej użyciem w obecnych czasach ma uzasadnienie tylko tam, gdzie wiele zainwestowano w zasoby i gromadzono kompetencje wokół narzędzi ARIS. Co jednak nie zmiania faktu, że pozostawanie w tej niszy rodzi poważne ryzyko budowania długu technologicznego i tak zwanego vendor lock-in.

Repozytoria ARIS budowane są w modelu relacyjnym a struktura bazy jest objęta tajemnicą producenta, do tego nie ma specyfikacji XMI dla eEPC (XML Metadata Interchange) więc migracja modeli do innych narzędzi jest praktycznie niemożliwa (można je “przerysować” w nowym narzędziu). Do tego wersje samego ARIS’a bywają niekompatybilne między sobą (przechodzenie na nowszą wersję wymagało już w historii stosowania skomplikowanych procedur). Nadal, od czasu do czasu podejmowane są próby naprawy tej sytuacji:

Mimo tego, że w ostatnich dekadach do modelowania procesów powszechnie stosuje się język EPC, brak oficjalnego standardu prowadzi do coraz częstszego jego pomijania. Spójny metamodel jest podstawą do określenia języków modelowania procesów. W związku z tym, niniejsza praca buduje podstawy dla dalszej standaryzacji poprzez dostarczenie zintegrowanego metamodelu dla EPC. Uzyskany w ten sposób metamodel wspiera ożywienie EPC poprzez ułatwienie przyszłych wysiłków standaryzacyjnych.

[zotpressInText item=”{5085975:MS742HBG}”]

Narzędzie ARIS to obecnie rozbudowany pakiet CASE, nadal obecny na rynku, między innymi jako kontynuacja wielu projektów zapoczątkowanych przed powstaniem notacji BPMN (z pomocą tego narzędzia powstało wiele dokumentacji projektowych, nadal utrzymywanych). Jednak, z uwagi na to, że notacja BPMN, jako znacznie lepiej dopracowana i funkcjonująca jako otwarty standard public domain, stała się szybko standardem de facto, eEPC to obecnie mała nisza i chyba już nic tego nie zmieni.

Notacja EPC jest dostępna nie tylko w narzędziu ARIS, powyższe diagramy powstały z użyciem Visual Paradigm, udostępniającym także (niestandardową) możliwość ich exportu do formatu XMI. Możliwe jest tu także automatyczne wygenerowanie diagramów BPMN z diagramów EPC.

Notacja eEPC, obok BPMN i UML, nadal jest przedmiotem nauczania na niektórych uczelniach w Polsce.

Źródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]

Krótki wstęp

Od czasu do czasu są takie momenty, że świat podsuwa mi gotowe teksty do publikacji.  Każdy kto mnie zna i czyta wie, że od lat odradzam wdrażanie wielkich monolitów ERP, uzasadnienie tego z moich ust najczęściej jest jednak odbierane jako moje spekulacje (mimo, że zawsze uzasadniam swoje zdanie a przykładów nie brakuje). A o tym sądzą dyrektorzy firm?

(more…)

Zbyt często nie czytamy takich gorących nowinek, jednak warto wiedzieć, że o większości takich porażek nigdy się nie dowiemy z powodu zapisów o poufności w umowach miedzy dostawcami oprogramowania a ich klientami. Tym bardziej taka informacja jak ta, jest warta uwagi z uwagi na sam fakt, że się pojawiła w prasie: najwyraźniej komuś puściły nerwy :):

Po siedmiu latach przygotowań, które pochłonęły 500 mln euro, największa w Europie sieć marketów spożywczych Lidl przerwała prace zmierzające do zaimplementowania systemu SAP do zarządzania towarem w sklepach. ?Strategicznych celów zdefiniowanych na początku nie dało się osiągnąć przy akceptowalnych kosztach? ? napisał w liście do pracowników szef koncernu Jesper Hoyer. ¹

Wiele gazet i portali opublikowało niemalże tę samą informację prasową, część redaktorów dodała komentarze od siebie. Tu kilka moich komentarzy.

W 2010 roku pisałem

celem dostawcy gotowego systemu ERP jest wdrożyć go bez żadnych modyfikacji bo (jej koszty) zjadają marżę dostawcy. Celem kupującego oprogramowanie ERP, jest wsparcie swoich procesów biznesowych a nie kopia cudzych. To dwa sprzeczne interesy. Silna firma wymusi na dostawcy ERP zmiany, słaba nie raz poddaje się wierząc tezom dostawcy, że nowy system uporządkuje stan ich organizacji i da przewagę nad konkurencją. Kto tu ma rację? ²

a artykuł kończyłem słowami:

To jest to co różni mnie od wielu dostawców ERP, ale też nie ja jeden tak uważam (polecam M.E.Porter ? Strategia konkurencji, napisał tam, że firmy kopiując technologie od kogoś tym samym podejmują decyzje że zrezygnowały już z konkurowania na rynku). Źródłem przewagi rynkowej jest tylko to co odróżnia firmę od jej konkurentów. Studiuje także literaturę z zakresu zarządzania i marketingu: nigdzie na świecie nie potwierdza się teza, że skopiowanie metod konkurenta daje cokolwiek poza ustawieniem się za nim.

Na stronie Hacker News, kilka dni temu, wywiązała się dyskusja na temat tej porażki (polecam całą dyskusję)³, pokazuje ona jak różne (i nie raz sprzeczne) są cele dostawców i odbiorców oprogramowania, ale tu także padło stwierdzenie:

Don’t customize software to your process unless the process is your competitive advantage. ³

(nie dostosowuj oprogramowania do swojego procesu, chyba że proces ten jest Twoją przewagą konkurencyjną).

Popatrzmy jak na tym tle wygląda przypadek LIDL’a. (cytaty pochodzą z COMPUTERWORLD¹).

Łącznie w prace zaangażowanych było przeszło 1000 specjalistów: pracowników Lidla, SAP, jego partnerów oraz zewnętrznych konsultantów. SAP miał zostać wdrożony we wszystkich oddziałach Lidla, także w Polsce.

Zawsze zastanawiała mnie w tego typu projektach taka armia osób zaangażowanych ludzi. Bardzo często widuję mega-zespoły pracujące z użyciem współdzielonych folderów na dysku, maila jak głównego narzędzia komunikacji w projekcie, armii studentów zatrudnionych jako młodszych konsultantów. Ich praca niemalże w całości opiera się na prowadzeniu wywiadów z pracownikami zamawiającego, spisywaniu ich treści, porządkowaniu i przekazywaniu jako wymagań swoim programistom. To droga do klęski. To moje obserwacje z audytowanych wdrożeń a nie opis tego projektu dla LIDLA (nie podano składu zespołu).

Dostawcy systemów ERP (SAP nie jest tu wyjątkiem) wysyłają w trakcie analizy i wdrożenia rzesze konsultantów, każdy wyspecjalizowany w swoim module (dziedzinie) i każdy pracujący niezależnie od pozostałych. Kastomizacje także są wprowadzane przez nich od siebie niezależnie, w efekcie nie raz bywają sprzeczne a błędy sypią się jak domino.

Czytam,  że:

W kwietniu 2017 roku SAP uhonorował Lidla nagrodą dla jednego z najlepszych klientów

Jak znam producentów systemów ERP, nagroda była wynikiem wartości kontraktu a nie merytorycznych osiągnięć w toku wdrożenia… Co widać i tu. Warto o tym wiedzieć, czytając w prasie o takich nagrodach.

Dziwi mnie, że nie wykonano analizy i projektu (gdyby powstał, wiadomo było by jakich funkcjonalności nie da się wdrożyć akceptowalnym kosztem), pilotowego wdrożenia w jednym, mało ryzykownym dla firmy oddziale, opracowaniu wniosków i procedury roll-up (parametryzowane powielanie). Wdrożony jednak osobno w kilku lokalizacjach i mimo kłopotów, nadal brnięto w projekt i koszty.

Według analityków zasadniczych przyczyn porażki należy szukać w nastawieniu Lidla, którego zarząd miał nie godzić się na jakiekolwiek zmiany w organizacji procesów firmy, tak aby dostosować je do architektury systemu SAP.

I tu widzę klucz do wyjaśnienia: z jednej strony zamawiający często bronią jak niepodległości tezy, że nie zmienią swoich dotychczasowych zwyczajów, z drugiej strony dostawcy forsują swoje rozwiązanie, ale też Ci dostawcy (znając potencjalne skutki!) godzą się na kastomizacje, pod warunkiem rozliczeń godzinowych za ich wprowadzanie, przerzucając tym samym wszelkie koszty i ryzyka z tego tytuły na zamawiającego.

Praktyka potwierdza, że:

Źródłem przewagi rynkowej jest tylko to co odróżnia firmę od jej konkurentów (M.E.Porter, Strategia konkurencji).

Dlatego przygotowanie firmy do wdrożenia jakiegokolwiek oprogramowania wspomagającego zarządzanie, to pewne minimalne kroki do wykonania:

1. Przeprowadzić analizę całej firmy i opracować model jej działania.
2. Wskazać obszary stanowiące o przewadze rynkowej, w pozostałych wprowadzić (zaplanować, opracować) standaryzację.
3. Opracować dokładne wymagania na oprogramowanie wspierające obszar budujący przewagę rynkową.
4. Zapomnieć, że jakikolwiek jeden wielki zintegrowany system sobie z tym poradzi.

O LIDL’u czytamy, że w końcu:

Zarząd koncernu zapowiedział, że nie tylko firma zostanie przy starym systemie Wawi, ale będzie on nadal rozwijany przez wewnętrzny dział IT, który zatrudnia ok 1200 osób, połowę poza Niemcami.

Jeżeli po całym tym okresie, wydaniu 500 mln EUR, firma dokonała porównania kosztów utrzymania własnego systemu z systemem GOTOWYM, oferowanym przez SAP, i doszła do wniosku że dedykowany jest bardziej rentowny to było to drogie badanie.

Od siebie na zakończenie mogę powiedzieć: nie znam przypadku by jakikolwiek gotowy system był tańszy we wdrożeniu i utrzymaniu, gdy wdrożenie dotyczy obszaru stanowiącego o przewadze rynkowej firmy, taki obszar to z zasady niestandardowe procesy i reguły. Co zrobić? Po zrozumieniu jak firma działa i wyróżnieniu w niej dziedzinowych obszarów specjalizacji (jest ich najwyżej kilka), wdrożyć w każdym z nich standardowe dziedzinowe oprogramowanie dostępne na rynku a obszar niestandardowy obsłużyć zamówionym, dedykowanym dla siebie, oprogramowaniem.

Ten wpis to nie jest analiza tego przypadku, za mało danych mamy i pewnie oficjalnie nigdy nie poznamy szczegółów. Ten wpis to raczej “memento”, dla kupujących systemy ERP, którzy:

1. wierzą, że dostawca jest bezstronny w toku prowadzenia analizy wymagań na wdrożenie tego co sam oferuje, że posiada właściwe kadry do wdrożenia,
2. wierzą, że jako kupujący zaawansowane usługi, sami sobie poradzą z nadzorem ich dostawcy (jak widać nawet własna armia 1200 specjalistów IT nie pomogła LIDL’owi).

W 2010 roku w artykule Kto jest winny porażki wdrożenia ERP, o przyczynach porażek wdrożeń ERP pisałem:

Po pierwsze: należy dobrze poznać własną firmę zanim cokolwiek, nie tylko wdrożymy, zanim podejmiemy decyzje by cokolwiek wdrażać.
Po drugie: należy wdrażać (kupować) system w ?kawałkach? po 20-50 funkcjonalności zamykających się w kilku całych procesach biznesowych (a nie działach czy pionach), zamiast setek funkcjonalności wraz z całym systemem ERP za jednym zamachem.
Po trzecie: z czystego bezpieczeństwa projektu i zarządzanie ryzykiem ? wymagania (a konkretnie specyfikacja tego co ma zostać dostarczone) i nadzór nad ich realizacją, to nie jest praca ani dla dostawcy ani dla kupującego, pierwszy najprawdopodobniej będzie koloryzował swój produkt a drugi posłuży się stereotypami.. ⁴

Ciśnie mi się na usta: A nie mówiłem? 🙂 Jednak nie cieszy mnie to, że mogę tak napisać.

Dziwi mnie, że wszystkie te, doświadczone porażką, firmy mają dostęp do tej samej wiedzy co np. ja, a mimo to zarządy tych firm wierzą bezgranicznie dostawcom oprogramowania i wierzą, że opisywane od lat przyczyny porażek u nich nie wystąpią…

Z polemiki rozwija się dialog, ja jednak zakończę to jako prezentacja poglądów. Adwersarz  pisze w odpowiedzi na moje uwagi:

Takim najbardziej podstawowym i niemal uniwersalnym zakresem podstawowym ERP, który jest absolutnie nierozdzielny są (przepraszam ? stosuję notację z SAP jako mi dobrze znaną):

1. FI (finansowo-księgowy),
2. AM (księga majątku trwałego)
3. CO (kontroling rozumiany jako kosztowa część ksiąg),
4. MM (gospodarka materiałowa i magazynowa w tym w znaczeniu księgi dostawców)
5. SD (sprzedaż i dystrybucja ? w tym w znaczeniu księgi odbiorców)

Wszelkie rozwiązania polegające na tym, że jakiś podzbiór funkcji z wyżej wymienionego jest osobnym systemem rejestrującym zdarzenia osobno od centralnej bazy danych i przesyłającym je później do niej w celu zarejestrowania upośledza system jako ERP. (za RE: Duży ERP, czy integracja ? Dwóch mówi co innego, a to jest to samo? – ERP -view.pl – System ERP, CRM, ERP, Business Intelligence, MRP).

Wydaje mi się, że powyższe tłumaczy chyba nieporozumienie. Dla mnie SAP nie jest referencyjną (o ile taka istnieje) implementacją systemu ERP, którego jedna z definicje (przytoczona przeze mnie z WIKI) opisuje ERP jako zakres funkcji a nie “coś z centralna bazą”. Przywołano “nierozerwalne” moduły systemu SAP. W tym momencie mogę jedynie powiedzieć, że: niewątpliwie księga główna jest centralnym elementem rachunkowości (bo słowo “finanse” ma szerze znaczenie). Pozostałe funkcjonalności od 2. do 5. (utożsamiam je z tym co napisano w nawiasach) to dostępne na rynku bez problemu dedykowane podsystemy, nie raz bardzo rozbudowane, doskonale sprawujące się jako  produkty niezależnych dostawców. Od siebie dodam, że zawężanie pojęcia kontrolingu do “kosztowej części ksiąg”, w sytuacji gdy dostawca SAP nabył system [[Business Object]], który jest miedzy innymi stosowany do “kontrolingu’ jest dziwne.

Pojęcie ERP samo z siebie nie ma ścisłej definicji więc nie ma mowy o “upośledzaniu czegoś jako ERP”. Komentując dalej: ERP dla mnie nie jest żadną religią, jest jednym z wielu dostępnych na rynku pakietów oprogramowania. Skór ERP występuje w tak wielu nazwach produktów, tak wielu dostawców, że traktowanie go, moim zdaniem, jako cokolwiek więcej niż “zestaw oprogramowania kompleksowo wspomagający zarządzanie organizacją” jest chyba trudne do uzasadnienia. A skoro i tak do “ERP” dodaje się dziedzinowe rozwiązania (logistyka, produkcja, HR, wiele innych) to chyba dowodzenie, że to “monolit” w jakiejkolwiek części do niczego nie prowadzi.

Z ust adwersarza padło stwierdzenie:

Wszelkie rozwiązania polegające na tym, że jakiś podzbiór funkcji z wyżej wymienionego jest osobnym systemem rejestrującym zdarzenia osobno od centralnej bazy danych i przesyłającym je później do niej w celu zarejestrowania upośledza system jako ERP.

Dziwi mnie to, bo np. prosty proces zatwierdzania kosztów mający co najmniej dwa etapy: rejestracja faktury obcej oraz jej zatwierdzenie (lub odrzucenie) i uznanie w księgach to co najmniej dwuetapowy proces i nie ma tu większego znaczenia miejsce przechowywania pośrednich statusów bo w rzeczywistości i tak “księgi” widzą efekt ostateczny (uznanie na kontach) a poprzedzające etapy weryfikacji kosztów (proces biznesowy) “dzieją się” poza księgami. Dziwi mnie ta opinia z ust Adwersarza tym bardziej, że sam SAP zaleca np. do obsługi procesów biznesowych, w tym takich jak wieloetapowe zatwierdzanie kosztów, stosowanie zewnętrznego oprogramowania typu worlflow (SAP dostarcza dedykowany interfejs dla OpenText).

Moim zdaniem brak ścisłej definicji pojęcia “System ERP” czy dalszą dyskusję bezwartościową. Oprogramowanie SAP nie jest żadnym referencyjnym produktem ERP (choć wielu próbuje tej tezy bronić) i posługiwanie się jego przykładem jako “wzorem” w moich oczach nie jest żadnym argumentem. Nie twierdze, ze SAP to produkt zły. To po prostu produkt jeden z wielu na rynku… ma swoje wdrożeniowe sukcesy i ma porażki jak inne.

Polecam cały artykuł, którego fragment przytoczyłem. Autorem jest osoba związana z produktem i firmą SAP. Poznanie poglądów innych niż np. moje jest na pewno cenne.

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?

---

1. ^?*?
   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”.