V článku Možnosti prekladu modelov BPMN do Petriho sietí bola popísaná syntax a sémantika Petriho sietí (PS) i štandardu BPMN. Druhá časť článku sa venovala transformácii BPMN modelov do PS. V tomto pokračovaní bude predstavený ďalší významný modelovací štandard, a tým je EPC (Event-driven Process Chain). Takisto bude navrhnutý aj jeho preklad do PS.

1. EPC (Event-Driven Process Chain)

EPC je modelovacia metóda používaná na modelovanie biznis procesov hlavne pri implementáciách ERP systémov. Použitím diagramu sa dá prehľadne definovať pomocou akých aktivít bude proces realizovaný. Takisto je definovaná sekvencia a koordinácia pre jednotlivé aktivity. Event-driven (udalostne riadená) kvôli tomu, že popisuje dynamiku biznis procesov. To znamená, že popisuje ako a v aký čas sa má objaviť akcia alebo reakcia, ktorá spôsobí zmenu.

EPC bol vyvinutý ako súčasť platformy ARIS. Jeho autorom je Prof. Wilhelm-August Scheer z Inštitútu pre hospodársku informatiku v roku 1990. ARIS je dnes jedným z najpoužívanejších nástrojov na modelovanie biznis procesov a EPC je jeho kľúčovou súčasťou. Publikácia [1] venujúca sa EPC hovorí nasledovné: “EPC je usporiadaný graf udalostí a funkcií. Poskytuje viacero spojení a dovoľuje alternatívne aj paralelné vykonávanie procesov. Navyše je špecifikované použitie logických operátorov ako AND, OR a XOR. Hlavnou výhodou EPC je jeho jednoduchosť a pre používateľa zrozumiteľná notácia. To robí z EPC široko akceptovanú metódu na modelovanie biznis procesov.”

1.1. Syntax EPC

Udalosť (Event) – sú to pasívne elementy. Popisujú pri akých podmienkach sú funkcia alebo proces vykonané alebo do akého výstupu funkcia resp. proces vyústia. Napríklad udalosť môže byť “Tovar na sklade” t.j. ak je tovar na sklade, vykoná sa určitá funkcia. Každý EPC diagram musí začínať a končiť udalosťou.

Funkcia (Function) – je aktívny EPC element. Modeluje úlohy alebo aktivity v rámci firmy (organizácie, v rámci ktorej sa proces modeluje). Funkcia popisuje transformáciu z vstupného do výstupného stavu. V prípade rozdielnych možností výstupných stavov, výber stavu môže byť namodelovaný ako rozhodovacia funkcia použitím logických spojení. Príkladom funkcie je aktivita “Skontroluj stav materiálu” a podobne.

Organizačná jednotka (Organization unit) – určuje, aká osoba alebo organizačná jednotka podniku je zodpovedná pre danú funkciu. Napríklad: Oddelenie predaja, obchodný manažér a podobne.

Informácia, materiál, zdrojový objekt (Information, material, resource object) – mapujú objekty skutočného sveta, ktoré môžu byť zdrojom dát pre funkciu alebo cieľom dát vytvorených funkciou. Napríklad materiál, objednávka a podobne.

Rozhranie procesu ( Process path ) – viac menej rovnaký element ako funkcia. EPC môže byť hierarchicky popísané. Na začiatku veľmi abstraktný popis a potom viac do hĺbky. Niekedy spája viacero funkcií.

Logické operátory (Logical connector) – v EPC sú logické spojenia medzi objektmi kontrolného toku, ktorými sú udalosti a funkcie realizované logickými operátormi. Pomocou logických operátorov je možné vetvenie z jedného toku do viacerých tokov a taktiež je možné spojenie (aj synchronizované) z viacerých tokov do jedného.

EPC podporuje tri druhy logických operátorov:

• XOR vetvenie / spojenie aktivuje práve jednu vetvu, ktorou pokračuje proces a druhá je deaktivovaná. Takisto pri spojení prejde spojením práve jedna vetva. XOR vetvenie presne korešponduje s matematickým popisom operácie XOR. V angličtine sa pre takéto spojenie používa termín “Branch/Merge“.
• AND vetvenie / spojenie aktivuje všetky vetvy v kontrolnom toku paralelne. Vetvenie má jeden vstup a dva alebo viac výstupov. Spojenie opačne, spája viacero aktívnych vetiev paralelne do jednej. V angličtine sa pre takéto spojenie používa termín “Fork/Join“.
• OR vetvenie / spojenie aktivuje jednu alebo všetky vetvy. Takisto pri spojení stačí, aby dobehla aspoň jedna vetva, aby sa spustilo OR spojenie. Môže sa však uzavrieť aj pre všetky vetvy súčasne.

Obrázok 1 – XOR, AND, OR

Kontrolný tok (Control flow) – spája udalosti s funkciami, procesnými cestami alebo logickými konektormi vytvárajúc chronologickú sekvenciu a logické závislosti medzi týmito elementmi. Kontrolný tok je graficky reprezentovaný šípkou, ktorá spája zdroj s cieľom.

Informačný tok (Information flow) – spája funkcie so vstupnými alebo výstupnými dátami z ktorých funkcia dáta číta alebo ich tam zapisuje. Je reprezentovaný čiarou, ktorá spája funkciu s príslušným dátovým objektom.

Pridelenie organizačnej jednotky (Organization unit assignment) – spája organizačnú jednotku a funkciu, za ktorú je zodpovedná. Takisto ako informačný tok, aj pridelenie organizačnej jednotky je realizované pomocou čiary.

Zásady EPC modelov:

• EPC model by mal začínať udalosťou.
• EPC model by mal končiť udalosťou.
• Funkcia a udalosti sa musia striedať.
• Čo sa týka spojenia funkcií a udalostí, každá udalosť a funkcia by mali mať len jeden vstupný a výstupný konektor (okrem začiatočnej a koncovej udalosti).
• Každá hrana kontrolného toku musí spájať dva rozdielne objekty (udalosť a funkciu).
• Udalosť je pasívny komponent, ktorý nemá rozhodovaciu schopnosť. Túto schopnosť majú len funkcie.
• Logické operátory majú viacero vstupov (spojenie) alebo viacero výstupov (vetvenie) ale nikdy nie viac vstupov aj výstupov.
• Výstupy operátora musia byť vždy všetky rovnakého typu (buď udalosti alebo funkcie)

Hierarchické EPC

Syntakticky, relácia hierarchie spája funkciu alebo procesné rozhranie s inými EPC procesmi. Sémanticky je v podstate volanie podprocesu. EPC teda okrem jednoduchých modelov umožňuje aj hierarchické spájanie, teda volanie iného EPC procesu v rámci vykonania funkcie alebo procesného rozhrania. Pri exporte do AML súboru v nástroji ARIS je možné definovať počet hierarchií, ktoré sa dostanú do exportu.

1.2. AML( ARIS Markup Language ) a EPML ( EPC Markup Language)

V súčasnosti je na trhu veľa väčších nástrojov na modelovanie biznis procesov. Najväčšie sú ARIS, Visio do spoločnosti Microsoft (množstvo firiem vyvíja nadstavby nad Visio ako napríklad Semtalk), IBM Websphere Modeler, Netbeans, Eclipse (rôzne pluginy) a iné. Väčšina procesných editorov na trhu podporuje i modelovanie EPC modelov. Preto je nutné vyvíjať výmenné formáty pre tieto nástroje. Niektoré firmy totiž nie sú naklonené výmenným formátom a držia si tak klientov tým, že ich procesy otvorí len daný editor. Používanie takýchto formátov však znižuje potrebu implementácie transformácií z O(n²) na O(n) [2].

Práve EPML je takýmto výmenným formátom pre modely EPC. Umožňuje export a import EPC modelov medzi rôznymi nástrojmi na modelovanie, ktoré tento štandard podporujú. Hoci ARIS a spoločnosť IDS Scheer AG sú v podstate tvorcami EPC formátu a jeho najväčším podporovateľom, nástroj ARIS exportuje modely len do formátu AML. Tento formát je však oveľa komplikovanejší na porozumenie i transformáciu.

Formátmi AML a EPML sa zaoberá vedecký článok Transformation of ARIS Markup Language to EPML[3]. Jedným z autorov je Jan Mendling, ktorý aj implementoval transformáciu z AML do EPML.

2. Transformácia EPC do PS

2.1. Návrh pravidiel prekladu

V tejto časti sú popísané pravidlá pre preklad EPC modelov do PS. Podobne ako pri BPMN, i preklad EPC do PS nie je jednoduchý, pretože v PS treba používať konštrukty ako OR, AND alebo XOR. Keďže v PN editore ešte nie je implementovaný PNML import podporujúci podsiete, nebudem brať do úvahy hierarchické EPC. V podstate to ani nie je potrebné, pretože nástroje ako ARIS umožňujú export modelov a ich hierarchií do viacerých súborov, ktoré potom možno preložiť v prekladači samostatne.

Tento návrh sa do veľkej miere zhoduje s prekladom navrhnutým v článku Bridging The Gap Between Business Models And Workflow Specifications[4] . Tento článok, však navrhuje preklad do WF sietí, môj návrh je do PS.

EPC element – Element PS

I. Udalosť – Miesto

Udalosť v EPC vyjadruje statický subjekt, vstup alebo výstup funkcie. Preto je v PS úplne jednoznačne najvhodnejší element miesto.

Obrázok 2 – Mapovanie udalosti

II. Funkcia – Prechod

Funkcia vyjadruje dynamický subjekt, vykonanie určitej činnosti alebo výkonu. Vstupmi do funkcie a výstupmi z funkcie sú udalosti (miesta). V PS takýto element jednoznačne vystihuje prechod.

Obrázok 3 – Mapovanie funkcie

III. Spojenie – Hrana

Spojenie elementov v EPC je realizované pomocou šípok, ktoré predstavujú kontrolný tok. Teda tok zo začiatočných udalostí až po koniec. Tok presne definuje chod procesu. V PS na prepojenie elementov slúžia hrany, preto budem prekladať spojenia kontrolného toku z EPC ako hrany.

IV. Brána AND – Prechod–Miesto–Miesto

Brána AND predstavuje synchrónne paralelné vetvenie alebo spojenie. V PS sa synchronizácia dá dosiahnuť spojením miest s jedným prechodom, takže prechod je spustiteľný až keď je token vo všetkých miestach, ktoré do neho vchádzajú a po spustení prechodu sa token prenesie do všetkých výstupných miest. Pri preklade treba brať do úvahy počet vstupných a výstupných vetiev. Každú vetvu predstavuje jedno miesto. Hore uvedený obrázok znázorňuje vetvenie a spojenie pre dve vetvy – pre každú je jedno miesto. Pre N vetiev vchádzajúcich do alebo vychádzajúcich z AND brány sa vytvorí jeden prechod a N miest.

Obrázok 4 – Návrh mapovania brány AND

V. Brána XOR – Miesto–Prechod–Prechod

Brána XOR predstavuje exkluzívne alebo. Teda musí byť reprezentovaná samostatnými prechodmi v PS. XOR sa prekladá ako miesto. Každá vetva brány sa potom pripojí na toto miesto samostatným prechodom. Na obrázku je znázornené XOR vetvenie a spojenie pre dve vetvy. Pre N vetiev sa preloží jedno miesto a N prechodov. XOR by sa podľa štandardu EPC mal vetviť len z funkcie, pretože len tá má rozhodovaciu schopnosť. Keďže niektoré editory dovolia modelovať aj XOR vetvenie z udalosti, ja prekladám akýkoľvek XOR.

Obrázok 5 – Návrh mapovania brány XOR

VI. Brána OR – Miesto–Prechody-Miesta

Brána OR je v podstate kombináciou XOR a AND. Môže sa buď spustiť len jedna vetva samostatne alebo všetky súčasne. OR prekladám ako konštrukciu obsahujúcu jedno miesto, jeden prechod (ten spúšťa všetky vetvy paralelne) a ďalších N miest a prechodov pre N vetiev.

Obrázok 6 – Návrh mapovania brány OR

Syntax EPC obsahuje viac elementov. Do PS sa však zmysluplne prekladá len táto základná syntax. Rozšírená syntax má opisný význam pre tok dát, participáciu ľudí a OJ v rámci procesu. Cieľom mojej práce je však preložiť WF modely do PS za účelom analýz, pre ktoré je podstatná len základná časť EPC. Pre každý element, pokiaľ to pôjde sa prenesie aj informácia o polohe a textový popis.

2.1. Overenie prekladu z EPC do PS

Proces – Obstaranie firemného vozidla

Jednoduchý proces obstarania vozidla. Auto slúži buď na firemné účely, alebo na súkromné účely, alebo oboje. Pri firemných účeloch je vstupom do funkcie zohľadniť predpis dokument smernice. Na funkcii zohľadniť požiadavky zamestnanca participuje i samotný zamestnanec. Keďže ide o OR vetvenie a spojenie, vybraté môžu byť až dve autá. V ďalších krokoch by sa potom v prípade dvoch ponúk museli spojiť požiadavky. Proces bol zvolený len ako ukážka prekladu OR brány. Preklad bol realizovaný pomocou prekladača, ktorý som implemetoval ako súčasť diplomovej práce[5].

Obrázok 7 – Proces BPMN

Obrázok 8 – Proces PS

Proces bol preložený správne. Preložila sa iba základná syntax presne podľa návrhu. OR brány sa preložili správne. Ignorovali sa elementy rozšírenej syntaxe. Textové popisy boli prenesené a takisto spojenie duplicitných elementov je v poriadku. Po pridaní tokenu bolo otestované správanie procesu.

3. Záver

V súčasnosti sú EPC a BPMN najpoužívanejšie štandardy na modelovanie biznis procesov. BPMN vyhráva lepšou grafickou prepracovanosťou a bohatšou syntaxou, čo je hlavne pri obrovských procesoch výhodou. EPC vyniká svojou jednoduchosťou, presne definovanou sémantikou, znovupoužitelsťou procesov, ale i začlenením do ERP systému SAP.

Preklady predstavené v mojich článkoch sú i implementované v jednoduchom prekladači, ktorý bol takisto súčasťou diplomového projetku[5]. Tento prekladač, ale i ďalšie možnosti prekladu, problémy s ním súvisiace a plány ďalšieho rozvoja tejto problematiky rád priblížim v pokračovaní tohto článku.

4. Zdroje

1. Tsai A. et al.: EPC Workflow Model to WIFA Model Conversion: In: 2006 IEEE International Conference on Systems, Man, and Cybernetics, Taipei, Taiwan, pp. 2758-2763
2. Wustner, Hotzel E., a.i.: Converting Business Documents: A Classification of Problems and Solutions using XML/XSLT: In Proceedings of the 4th International Workshop on on Advanced Issues of E-Commerce and Web-based Systems,2002, s. 61-68.
3. Mendling J., Markus Nuttgensz: Transformation of ARIS Markup Language to EPML, Vienna University of Economics and BA
4. Dehnert J., Aalst M.P.: Bridging The Gap Between Business Models And Workflow Specifications: Int. J. Cooperative Inf. Syst, 2004, s. 289-332.
5. Savka A., Možnosti prekladu modelov WF do Petriho sietí, Diplomová práca, 2009