Process Modeling Using Event-Driven Process Chains

Process Modeling Using Event-Driven Process Chains Jan Kramer 323356 TA: Daniel Alami Department of Information and Computing Sciences Utrecht University Introduction Event-Driven Process Chains (EPC) is a business process modeling language developed in a joint effort between SAP and the Institute of Information Systems of Saarbrücken in the context of the Architecture of Integrated Information Systems (ARIS) framework (Keller, Scheer, & Nüttgens, 992). As EPC is aimed at regular users, it is designed to be intuitive and easy to understand, in contrast to more formal languages such as Petri nets which have a stronger focus on correctness (Aalst, 999). Process modeling can be used for a variety of goals. Curtis, Kellner, and Over (992) distinguished five basic uses. First, process modeling facilitates human understanding and communication. Secondly, it supports business process improvements, since process models can serve as a basis for analysis. Thirdly, by modeling a process, it becomes possible to manage it, because behaviors from practice can be compared to a defined process. Fourthly, process executions can be guided by an automated system using process models, e.g. by providing humans with suggestions or instructions. Lastly, in some cases process models can be used to fully automate the execution of a process, or a part of it. Given these goals of process modeling, the EPC notation is found to be unsuitable for the latter two, since it lacks formally defined semantics, which is required for automated reasoning about processes (Aalst, 999). However, an example of an application of process modeling using EPC is the ARIS enterprise modeling framework where it plays a central role since process models are used to integrate the various perspectives of the enterprise (Mendling, 2008). No standardized procedure exists for producing EPC models, but Scheer, Thomas, and Adam (2005, pp. 36 37) describe a set of steps that help create EPC in a structured manner:. Define a unique title of the business process, to make clear which process is modeled. 2. Derive initial and final events from the process title. 3. Look for relevant verbs in the process description, translate them to a function flow, consisting of functions, logical connectors and process interfaces where applicable. The elements should be arranged in the order they are

executed in. Where necessary, add logical connectors to split or join the execution. 4. For each transition between two functions, define one or more events in such way that the preceding function produces the event, and the event triggers the next event. 5. Verify the model for structural correctness, and perform validation with key stakeholders in the process. Please note that one of the original steps described by Scheer et al. requires the use of other aspects of the ARIS framework. Since this paper focuses on EPC as a process modeling language, this step has been omitted here. As the original paper (Keller et al., 992) does not include a formal definition of the syntax, multiple variations and extensions of the notation have emerged over time. Mendling (2008) compared these variations in an effort to develop a unified syntax, which will be used in the remainder of this paper. Note that while other literature also includes additional elements such as organizational units and IT systems (e.g. Becker, Rosemann, & Uthmann, 2000; Nüttgens, Feld, & Zimmermann, 998), this paper focuses on the elements presented by Mendling. According to Mendling, an EPC consists of the following elements, of which the graphical representation is shown in Figure : Function: Represents an activity or task. Event: Describes the situation before and/or after a function. Control flow: A directed arc which connects two EPC elements. Logical connector: Connects three or more functions and events. Each connector can either be a split (multiple outbound flows), or a join (multiple inbound flows). The connector type defines the number of flows activated (split) or waited for (join): exactly one for exclusive OR (XOR), one or more for OR, and all flows for ALL connectors. Process interface (optional): Represents another EPC that is consecutively executed in relation to the current EPC. Can be placed at either the start or the end of the EPC. One of the key people in developing EPC, Professor August-Wilhelm Scheer, has both a background in business and academia. He was chair of the Institute for Information Systems at Saarland University in Germany from 975 to 2005, and founded the software and consulting company IDS Scheer AG in 984. Currently he resides as a consulting professor at the German Research Centre for Artificial Intelligence (DFKI) (Institut für Wirtschaftsinformatik, n.d.). 2 Example In the following section, the procedure of process modeling using EPC is explained by applying the steps as described by Scheer et al. (2005, pp. 36 37) to a fictional process description. Consider a product software development company that has defined the following process for handling bug reports: 2

Event Function Process interface X V Exclusive OR connector OR connector V AND connector Control flow Figure. Syntax elements of Event-Driven Process Chains All bugs that are encountered by both customers and internal stakeholders should be filed as an issue in our issue tracker. When a bug report is filed, the product manager (PM) checks whether the issue is reproducible and valid. If it is not reproducible or in fact not a bug, the PM discards the issue and notifies the user that the issue was discarded. Otherwise, the bug is assigned to the development team. As soon as the development team has resolved the issue, the PM updates the release notes of the upcoming product release and informs the user that the bug will be resolved in the next version. The issue is considered to be handled when no further action is required. Applying the aforementioned steps to this description results in the EPC as depicted in Figure 2. The remainder of this section discusses how this model has been established. From the description, it becomes clear that the process is concerned with the workflow to handle bugs. Therefore, the name of this process is defined as Bug Handling Workflow. The process appears to be triggered when a user or developer encounters a bug, so the initial event of the process is Bug encountered. Furthermore, the process ends after an issue is handled, so this process has one final event named Issue handled. With the initial and final events in place, the process description is scanned for relevant verbs which are translated to functions. From the example, the fol- 3

Bug encountered File issue PM notified of issue Check issue X Valid issue Invalid issue Not reproducible Assign issue Issue assigned X Issue resolved Resolve issue Discard issue V Issue discarded Inform user on upcoming release Update release notes Notify user of discarded issue User informed Release notes updated User notified V X Issue handled Figure 2. Event-Driven Process Chain of the process Bug Handling Workflow 4

lowing functions are derived: File issue, Check issue, Discard issue, Notify user, Assign issue, Resolve issue, Update release notes and Inform user. Additionally, logical connectors are added in several places to specify the control flow. After Check issue, it is either valid, invalid or not reproducible. Because only a single flow is possible, this is represented by a XOR connector. Note that a second XOR connector is added before the final Issue handled event, in order to synchronize the multiple flows. Also, the Issue resolved event has multiple outbound flows, but in this case all functions should be triggered and therefore an AND connector is appropriate. After the functions and connectors have been added, only the events remain to be added. Between each two consecutive functions, at least one event is added. Often the event is straightforward, such as the function Discard issue resulting in the event Issue discarded which in turn triggers Notify user of discarded issue. While this one-to-one mapping is prevalent in simple models, events can in fact trigger multiple functions, as seen after Issue resolved, which triggers both Inform user on upcoming release and Update release notes. At the current stage, a full EPC has been modeled. After verifying the syntax of the model, as a final step it should be conferred with key stakeholders in order to validate whether the model corresponds to reality. In this case, a PM might for example feel that the scenario of duplicate issues is insufficiently handled, which after discussion could result in the addition of an event after Check issue. Finally, when all key stakeholders agree on the EPC, it is ready to use. 3 Process-Deliverable Diagram This section describes a meta-model for Process Modeling Using EPC, which is represented as a Process-Deliverable Diagram (PDD) in Figure 3. A PDD is the result of a meta-modeling technique in which both the activities, and concepts of a method or technique are described. The activities represent the process and are depicted on the left-hand side of the PDD in the form of a UML activity diagram, while the concepts represent the deliverables and are depicted on the right-hand side represented as a UML class diagram. This metamodel allows method engineers to assemble situational methods by analyzing and selecting relevant method fragments (Weerd & Brinkkemper, 2008). The PDD has been created based on both the work of Scheer et al. (2005) and Mendling (2008), where the former mainly provided input on the procedural aspect, while the latter source provided a comprehensive description of the notational aspects of Process Modeling using EPC. In general, the activities of the technique are divided in three main phases: Analysis, Design and Evaluation. In the Analysis phase, the process to be modeled is analyzed and translated to EPC on a conceptual level. The Design phase is concerned with drawing the actual process model, while finally during the Evaluation phase, the produced model is verified and validated. The main de- 5

liverable of the process is the EPC model, which comprehensively describes a specific business process. The activities and concepts shown in Figure 3 are described in more detail in respectively Table and 2. 4 Related Literature As briefly mentioned before, EPC was first introduced by Keller et al. (992) in the context of the ARIS framework. The ARIS framework aims to describe enterprises by integrating five perspectives: data, function, organisation, output and process. Within this context, Keller et al. developed EPC as the language to model the process views of an organization. The EPC language is originally based on the concepts of Petri nets and stochastic networks, but is less rigid than those methods as it does not require a formal framework (Scheer et al., 2005). As a consequence, EPC models based on the original description are not easily verified. However, multiple efforts have been made to address this issue by formalizing the EPC. Examples of such efforts include Aalst (999), Mendling and Aalst (2007), and Mendling (2008). In all cases, formal definitions of the syntax are defined using logic and set theory from mathematics. Comparing EPC to UML State Diagrams (SD) and BPM, two other process modeling languages, Söderström, Andersson, Johannesson, Perjons, and Wangler (2002) found as a key difference that EPC does not explicitly use the concept of state. SD and BPM include various event types that represent a state change, however this is not the case in EPC. As a result, the EPC syntax requires less symbols, at the cost of being more implicit. In an experiment to compare EPC and Petri net models from an end-user perspective, Sarshar and Loos (2005) found that the perceived ease-of-use was highest for EPC end-users. However, the non-local semantics of the OR connector, i.e. the OR connector depends on information from other parts of the model than its direct neighbours, negatively impacted the model s comprehensibility. Finally, an interesting use of EPC models has been introduced by Dongen, Dijkman, and Mendling (2008). In their paper, Dongen et al. describe the situation of large organizations that have thousands of process models. To increase the quality of the overall set of models, duplication in models should be prevented. To assist maintainers of such repositories, they propose a novel approach to detect similarity between process models such as EPC, based on comparing abstract representations of EPC, i.e. causal footprints. 6

Analysis Rule: An EPC consists of at least one start event, one end event and one function Acquire process description Define unique title PROCESS DESCRIPTION EVENT describes Title EPC Derive start and end events Name Type Translate verbs to functions and process interfaces Design Process modeler Name FUNCTION PROCESS INTERFACE EPC title 0.. refers to d Draw nodes EPC NODE 3..* Draw logical connectors LOGICAL CONNECTOR d flows from flows to Draw intermediate events OR AND XOR Draw control flows 0..* 0..* CONTROL FLOW 2..* Process modeler Evaluation Verify structural correctness Process modeler SYNTAX ERROR Error type 0..* applies to Validate EPC Stakeholders APPROVAL 0.. approves [else] Rule: It is allowed to skip sub activities in order to go directly to the sub-activity that is concerned with the error. [EPC approved] Figure 3. Process-Deliverable Diagram of Process Modeling using EPC 7

Table. Activity table for the PDD of Process Modeling using EPC Activity Sub-Activity Description Analysis Acquire process description The business process to be modeled is described by a PROCESS DESCRIPTION in natural language, which has to be acquired by the process modelers to base the EPC on (Scheer, Thomas, & Adam, 2005). It is unknown how the process description should be acquired exactly, since this may vary from organization to organization, therefore it is modeled as a closed activity. Define unique title A unique title is required to distinguish the EPC from other EPC models. A good title also makes it clear to everyone involved what the topic of the process is (Scheer, Thomas, & Adam, 2005). Derive start and end events By defining the start and end EVENTs, the context of the process becomes clear. Each EPC has at least one start EVENT and at least one end EVENT (Mendling, 2008). Translate verbs to functions and process interfaces In additon to EVENTs, an EPC also consists of one or more FUNCTIONs and zero or more PROCESS INTERFACEs which represent the activity of the actors in the process. These can be discovered by identifying relevant verbs from the PROCESS DE- SCRIPTION. A PROCESS INTERFACE differs from a FUNC- TION in that it represents another process that is in turn described by an EPC (Mendling, 2008). Design Draw nodes After the analysis phase is finished, the identified nodes, i.e. EVENTs, FUNCTIONs and PROCESS INTERFACEs must be drawn using the EPC notation. The nodes must be arranged according to the order of execution (Scheer, Thomas, & Adam, 2005). Draw logical connectors Use LOGICAL CONNECTORs to properly model the control flow, i.e. AND where all branches, XOR where one, and OR where at least one branch must be executed (Scheer, Thomas, & Adam, 2005). Draw intermediate events For each transition from one FUNCTION to another, determine at least one EVENT that describes the post-conditions of the source FUNCTION and the pre-conditions of the target FUNC- TION (Scheer, Thomas, & Adam, 2005). Draw control flows Model all transitions between the EPC NODEs using CON- TROL FLOWs. Evaluation Verify structural correctness After the EPC is finished, the process modeler should inspect the model for any SYNTAX ERROR(s). Validate EPC At this stage, APPROVAL from the stakeholders of the process should be acquired to validate the EPC (Scheer, Thomas, & Adam, 2005). The validation process itself differs between organisations and processes, and is outside the scope of this document. If both the EPC is structurally verified, and the stakeholders have approved the model, it is ready. Otherwise, the process modeler should go back to one or more of the previously described sub-activities to fix the model. 8

Concept Table 2. Concept table for the PDD of Process Modeling using EPC Description PROCESS DESCRIPTION A PROCESS DESCRIPTION is a comprehensive description of the business process to be modeled in natural language (Scheer, Thomas, & Adam, 2005). The specific form is not relevant in this context, as it may differ from organization to organization. EPC An EPC in this context is defined as the end result of the process modeling procedure (Scheer, Thomas, & Adam, 2005), i.e. a process model that adheres to the notation of the Event-Driven Process Chains. The EPC has a title that is defined in the activity Define unique title. EVENT An EVENT is an EPC NODE that through its name describes the postconditions for the preceding FUNCTION(s), and the pre-conditions for the succeeding FUNCTION(s) (Mendling, 2008). FUNCTION A FUNCTION is an EPC NODE that captures a task or activity that is performed as part of the business process to be modeled (Mendling, 2008). The name is typically in the form of a verb and an object. PROCESS INTERFACE A PROCESS INTERFACE is an EPC NODE that refers to another EPC that describes a process that is either executed before or after the process of the subject EPC (Mendling, 2008). The attribute EPC title refers to the title of the other EPC. LOGICAL CONNECTOR A LOGICAL CONNECTOR is an EPC NODE that connects three or more FUNCTION(s) and EVENT(s). Each LOGICAL CONNECTOR is either an OR, a XOR, or an AND connector, and can either be a split (one inbound and multiple outbound control flows), or a join (multiple inbound flows and one outbound flow). OR An OR-type LOGICAL CONNECTOR activates or waits for one or more flows from the set of connected control flows (Mendling, 2008). XOR A XOR-type LOGICAL CONNECTOR activates or waits for exactly one flow from the set of connected control flows (Mendling, 2008). AND An AND-type LOGICAL CONNECTOR activates or waits for all flows from the set of connected control flows (Mendling, 2008). EPC NODE An EPC NODE is a generic concept that represents either an EVENT, a FUNCTION, a PROCESS INTERFACE or a LOGICAL CONNECTOR. It is not defined in the main literature sources used to create the diagram, but has been introduced to increase the clarity of the Process-Deliverable Diagram. CONTROL FLOW A CONTROL FLOW is a directed arc in an EPC which connects two EPC NODEs (Mendling, 2008). SYNTAX ERROR A SYNTAX ERROR is defined as a violation of the structural or grammatical rules defined for a language (ISO/IEC/IEEE, 200), which in this case is the EPC modeling language. APPROVAL The APPROVAL deliverable is obtained from the stakeholders and indicates the EPC is conform their understanding of the process (Scheer, Thomas, & Adam, 2005). 9

5 References Aalst, W. van der. (999). Formalization and verification of event-driven process chains. Information and Software technology, 4 (0), 639 650. doi:0. 06/S0950-5849(99)0006-6 Becker, J., Rosemann, M., & Uthmann, C. (2000). Guidelines of Business Process Modeling. In W. Aalst, J. Desel, & A. Oberweis (Eds.), Business Process Management: Models, Techniques, and Empirical Studies (pp. 30 49). Berlin, Heidelberg: Springer Berlin Heidelberg. doi:0. 007/ 3-540- 45594-9 3 Curtis, B., Kellner, M. I., & Over, J. (992). Process modeling. Communications of the ACM, 35 (9), 75 90. doi:0.45/30994.30998 Dongen, B., Dijkman, R., & Mendling, J. (2008). Measuring Similarity between Business Process Models. In Z. Bellahsène & M. Léonard (Eds.), Advanced Information Systems Engineering: 20th International Conference, CAiSE 2008 Montpellier, France, June 6-20, 2008 Proceedings (pp. 450 464). Berlin, Heidelberg: Springer Berlin Heidelberg. doi:0. 007/ 978-3- 540-69534-9 34 Institut für Wirtschaftsinformatik. (n.d.). Prof. Dr. Dr. hc mult. August-Wilhelm Scheer Curriculum Vitae. Retrieved February 7, 206, from http://www. uni-saarland.de/lehrstuhl/loos/team/prof-a-w-scheer.html ISO/IEC/IEEE. (200). ISO/IEC/IEEE 24765:200 Systems and software engineering Vocabulary. Geneva, Switzerland: ISO/IEC/IEEE. Keller, G., Scheer, A.-W., & Nüttgens, M. (992). Semantische Prozeßmodellierung auf der Grundlage Ereignisgesteuerter Prozeßketten (EPK). In A.-W. Scheer (Ed.), Veröffentlichungen des instituts für wirtschaftsinformatik (89). Saarbrücken: Universität des Saarlandes. Retrieved from http : / / www. uni - saarland. de / fileadmin / user upload / Fachrichtungen / fr3 BWL/professuren/PDF/heft89.pdf Mendling, J. (2008). Event-Driven Process Chains (EPC). In W. Aalst, J. Mylopoulos, N. M. Sadeh, M. J. Shaw, & C. Szyperski (Eds.), Metrics for Process Models: Empirical Foundations of Verification, Error Prediction, and Guidelines for Correctness (pp. 7 57). Berlin, Heidelberg: Springer Berlin Heidelberg. doi:0.007/978-3-540-89224-3 2 Mendling, J. & Aalst, W. van der. (2007). Formalization and Verification of EPCs with OR-Joins Based on State and Context. In J. Krogstie, A. Opdahl, & G. Sindre (Eds.), Advanced Information Systems Engineering: 9th International Conference, CAiSE 2007, Trondheim, Norway, June -5, 2007. Proceedings (pp. 439 453). Berlin, Heidelberg: Springer Berlin Heidelberg. doi:0.007/978-3-540-72988-4 3 Nüttgens, M., Feld, T., & Zimmermann, V. (998). Business Process Modeling with EPC and UML: Transformation or Integration? In M. Schader & A. Korthaus (Eds.), The Unified Modeling Language: Technical Aspects and Applications (pp. 250 26). Heidelberg: Physica-Verlag HD. doi:0.007/ 978-3-642-48673-9 7 0

Sarshar, K. & Loos, P. (2005). Comparing the Control-Flow of EPC and Petri Net from the End-User Perspective. In W. Aalst, B. Benatallah, F. Casati, & F. Curbera (Eds.), Business Process Management: 3rd International Conference, BPM 2005, Nancy, France, September 5-8, 2005. Proceedings (pp. 434 439). Berlin, Heidelberg: Springer Berlin Heidelberg. doi:0.007/ 538394 36 Scheer, A.-W., Thomas, O., & Adam, O. (2005). Process modeling using eventdriven process chains. In M. Dumas, W. Aalst, & A. H. Ter Hofstede (Eds.), Process-aware information systems (pp. 9 46). Hoboken, New Jersey: John Wiley & Sons, Inc. doi:0.002/04774442.ch6 Söderström, E., Andersson, B., Johannesson, P., Perjons, E., & Wangler, B. (2002). Towards a Framework for Comparing Process Modelling Languages. In A. B. Pidduck, M. T. Ozsu, J. Mylopoulos, & C. C. Woo (Eds.), Advanced Information Systems Engineering: 4th International Conference, CAiSE 2002 Toronto, Canada, May 27 3, 2002 Proceedings (pp. 600 6). Berlin, Heidelberg: Springer Berlin Heidelberg. doi:0.007/3-540- 4796-9 4 Weerd, I. van de & Brinkkemper, S. (2008). Meta-Modeling for Situational Analysis and Design Methods. In M. R. Syed & S. N. Syed (Eds.), Handbook of Research on Modern Systems Analysis and Design Technologies and Applications (pp. 35 54). Hershey, Pennsylvania: Idea Group Publishing. doi:0.408/978--59904-887-.ch003