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

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 (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

Legenda symboli notacji EPC (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):

Syntaktyka eEPC (opr. własne)

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 :

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

Proces księgowania faktur kosztowych (opr. własne)

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:

Proces biznesowy nadrzędny Obsługa płatności: tu symbol Ścieżka Procesu pełni rolę funkcji dekomponowanej (opr. własne)

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

Struktura organizacyjna wyrażona z użyciem notacji eEPC (opr. autora)

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.

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

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako wykładowca akademicki wizytujący (nieetatowy), prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony). Konsultacje: wszelka pomoc i wyjaśnienia dotyczące treści artykułów autora bloga udzielana jest wyłącznie w ramach płatnych konsultacji.

Ten post ma 2 komentarzy

  1. MGX

    Świetny artykuł. Jedyna uwaga (niezmieniająca oceny artykułu):
    ?Możliwe jest tu tak­że auto­ma­tycz­ne wyge­ne­ro­wa­nie dia­gra­mów BPMN z dia­gra­mów EPC?.
    Tak, może być to możliwe, bo BPMN jest pełniejszym opisem procesu, ale z drugiej strony, zamiast mechanicznego eksportu, może warto przerysować modele z uwzględnieniem szerszego zakresu informacyjnego oferowanego przez BPMN i wiedzy o procesie, która zapewne wzrosła od czasu zamodelowania go w EPC. Wtedy eksport jest podstawą do opracowania uaktualnionego modelu.

    1. Jarosław Żeliński

      “ale z drugiej strony, zamiast mechanicznego eksportu, może warto przerysować modele z uwzględnieniem szerszego zakresu informacyjnego oferowanego przez BPMN i wiedzy o procesie” oczywiście, że warto, z powodów jakie podałeś. Firmy mające narzędzia takie jak ARIS w zasadzie tkwią w “vendor lock-in”.. jest nim brak XMI dla EPC. Eksport EPC -> BPMN to raczej metoda na “masową” migrację posiadanej dokumentacji, nie rozwiązuje to jednak problemu jakości modeli w EPC, a jedynie uwalnia od długu technologicznego czy raczej notacyjnego.

      Zdarza mi się stosować EPC jako proste szkice, bo EPC jest łatwiej przyswajalne przez ludzi nieobytych z formalizmami. Nadal EPC bywa wykorzystywane w projektach typu sixsigma, lean management czy ISO. No i nadal (chyba, bo wiem to tylko z relacji) EPC bywa forsowany we wdrożeniach SAP.

Możliwość dodawania komentarzy nie jest dostępna.