EPC: Event-driven Process Chain

The EPC (Event-driven Process Chain) (Davis, 2001) (Scheer, 2000) is the diagrammatic language of the control view of ARIS framework for modeling business processes within the enterprise model. The importance of EPCs in the practice of business process modeling can be attested by the existence of several successful commercial tools which offer support for these diagrams, e.g., IDS Scheer’s ARIS Toolset, Microsoft’s Visio and BOC’s ADONIS. Further, EPCs have been used in the documentation of the widely-employed SAP R/3 enterprise resource planning system, which has led to the SAP Reference Model with over 600 EPCs (Mendling, 2008).

Due to the economic value of EPCs, several academic studies have considered different aspects of the language. For example, (Kern, et al., 2007) (Mendling, et al., 2004) (Mendling, et al., 2005) (Mendling, et al., 2005) have proposed transformations between EPCs and other (platform-independent or platform-specific) models using Model-Driven Development techniques.

In addition, several studies in the literature propose formal execution semantics for EPCs using Petri nets (Kindler, 2006) (Rosemann, et al., 2007) (Van der Aalst, 1998) (Van Dongen, et al., 2005), with the purpose of demonstrating the absence of structural problems within the language and its models and to assure that the business processes specified in EPCs are prone to unambiguous execution and automation. In EPCs, the dynamic behaviour of business processes is modeled in terms of three main modeling elements: functions, events, rule elements (or logical operators). These concepts are showed in figure 1.

Figure 1 - Business Process 

Functions are the basic elements for EPC process modeling. They represent either technical activities or activities performed on some objects with the purpose of achieving one or more business goals (Scheer, 2000). An activity can be performed by either a person or an application system (Scheer, 2000), and has inputs – such as information or raw material – and outputs, such as new information or products. Furthermore, activities can consume and create organizational resources during their execution (Davis, 2001). In figure 1, the notational elements used to represent Functions are green rectangles. Examples of Functions are “Request purchase” and “Analyze purchase request”.

An event represents a state which is relevant to the process management and affects the flow of execution. They may be originated either internally in the execution of some business process or may be created by actors which are external to the process (Davis, 2001) (Scheer, 2000). When internally originated, events are said to establish the preconditions and postconditions for each stage of the process (Davis, 2001). Preconditions represent a state of reality which triggers one or more activities, while postconditions, in their turn, represent a state of reality that exists only after the activity has been performed. In other words, an activity is triggered by one or more events and one or more activities can trigger one or more events. In figure 1, events are illustrated by pink hexagons (e.g. “Need of Purchase identified” and “Request approved”). While both Scheer (Scheer, 2000) and Davis (Davis, 2001) defend that every relation between functions in EPCs should be mediated by an event as a form of representing situations in the business processes, this restriction is not enforced by the ARIS Toolset (i.e., it is not enforced in the language’s meta-model).

Rule elements (or logical operators) control the flow of the process model on the basis of the results and effects of its preceding tasks. These rules (as explained in Table 1) are used for creating “joins” and “splits” in the business process. The join connectors have multiple incoming branches and one single outgoing branch and the split connectors have one incoming branch and multiple outgoing branches. As syntax rule, splits from functions are only allowed since the function is linked to a connector and each arc which leaves the connector is linked to an event to represent the condition where the control flow must follow (conversely, splits to functions are only allowed when the function is preceded by a connector and each arc which reaches the connector is linked to an event). Splits from events to functions are forbidden because it does not become explicit the arc where the control flow must follow.

There are three types of logical operators (AND operator, XOR operator and OR operator) that
determines the execution flow. The AND-split triggers all outgoing branches concurrently and AND-join propagates control only if all incoming branches have already finished. XOR-split choices among one of multiple exclusive branches and XOR-join waits for only one of the incoming branches. OR-split activates one or more of multiple branches accordingly events while OR-join waits for one or more of the incoming branches. Figure 1 presents an example of an XOR “split”, indicating that the “Analyze purchase” can be followed by either “Finalize purchase” or “Inform client”, but not both.

Rule	Symbol	Join	Split
OR		Any incoming branch, or a combination of incoming branches, will initiate the outgoing branch	One or more outgoing branches will be enabled after the incoming branch finishes
XOR		One, and only one, incoming branch will initiate the outgoing branch1	One, and only one, outgoing branch will be enabled after the incoming branch finishes
AND		The outgoing branch initiates only after all the incoming branches have been executed	Two or more outgoing branches are enabled after the incoming branch finishes

In addition to the three basic elements of EPCs (functions, events and rules), there can exist other elements in EPCs. These elements in fact belong to the ARIs Organizational Model and are referenced in an EPC to describe participants in organizational activities. Figure 1 depicts the elements “Client” and “Seller”. These elements indicate that the participants of the business process are responsible for performing the functions in their swimlanes. In figure 1, Client” is responsible for carrying out “Request purchase”, while “Seller” is responsible for carrying out “Analyze purchase request”, “Finish purchase” and “Inform client”.

References

• Davis, Rob. 2001. Business Process Modelling with ARIS - A Practical Guide. s.l. : Springer, 2001.
• Kern, H. and Kühne, S. 2007. Model Interchange between ARIS and Eclipse EMF. 7th OOPSLA Workshop Domain-Specific Modeling, Computer Science and Information System Reports. 2007.
• Kindler, E. 2006. On the Semantics of EPCs: A Framework for Resolving the Vicious Circle. Technical Report. University of Paderborn, Computer Science Department at Germany. 2006.
• Mendling, J. and Nüttgen, M. 2004. Transformation of ARIS Markup Language to EPML. In Proceedings of the 3rd GI Workshop on Event-Driven Process Chains. 2004.
• Mendling, J., Neumann, G. and Nüttgens, M. 2005. Towards Workflow Pattern Support of Event-Driven Process Chains (EPC). In Proceedings of the 2nd GI Workshop XML4BPM - XML for Business Process Management. 2005.
• Yet Another Event-Driven Process Chain. Technical Report. University of Economics and Business Administration at Vienna. 2005.
• Mendling, Jan. 2008. Metrics for Process Models - Empirical Foundations of Verification, Error Prediction, and Guidelines for Correctness. s.l. : Springer, 2008. p. 193. Vol. 6.
• Rosemann, M. and Van der Aalst, W. 2007. A Configurable Reference Modelling Language. Information Systems. 2007, Vol. 32.
• Scheer, A. W. 2000. Aris – Business Process Modeling,. s.l. : Springer, 2000.
• Van der Aalst, W. 1998. Formalization and Verification of Event-driven Process Chains. s.l. : Computing Science Reports. Eidhoven University of Technology at Eindhoven, 1998.
• Van Dongen, B., Van der Aalst, W. and Verbeek, H. 2005. Verification of EPCs: Using Reduction Rules and Petri Nets. In Proceedings of the 17th Conference on Advanced Information Systems Engineering (CAiSE 2005). 2005.