Process aware information systems, such as Workflow Management Systems or ERP systems require process specifications for their implementation. Since many of those process specifications are similar for different companies, databases with so-called reference models, such as Aris for My-SAP, have been developed. These databases can be customized towards company-specific process specifications, thus keeping implementation costs down. To avoid costly problems with information systems on an operational level, it is of the utmost importance that the reference models used to design the information system are correct. In this paper, we analyze a selection of the reference models for SAP R/3 that are stored in the ARIS for MySAP database, and we verify whether they are correct. Since these models are stored as Event-driven Process Chains (EPCs), we use a verification approach tailored towards the verification of this language to check for errors in the models. We show that the reference models in ARIS for MySAP indeed contain some errors and we present the implications of those errors, if these models would be used for the execution of business processes.
Nowadays, more and more enterprise information systems rely on process models for their specification. Companies offering large information systems employ consultants who, together with the customer, make process specifications in terms of executable process models. These process models are then used to configure the final installation of the information system. Many of these process aware information systems (for example Enterprise Resource Planning (ERP) [KT98] systems and Workflow Management (WFM) [AH02, LR99]) are designed to support business processes on an operational level and to fully benefit from these systems, process models need to be specified as precise as possible. However, designing process models precisely is a complicated and error prone task. Fortunately, process models that are used in different companies, but with similar purposes, often have very similar designs. For this reason, databases have been developed that contain generic process models that can be customized towards company-specific business processes. These process models can serve as a guideline when designing process models to implement large information systems, i.e. they serve as a reference for the designer,
implementation
Model
process model design hence the term reference models.
For a large information system to support one process, the configuration can roughly be divided in two phases as shown in Figure 1. In the first phase, a reference model that best suits the process under consideration is selected (for example for a purchasing process, this should be the best purchasing reference model, such as vendor selection or internal procurement). Together with the business model of the specific organization, the reference model is customized, resulting in a process model. This process model is used in the implementation phase to configure a specific information system, such as SAP R/3. Although all the steps presented here are usually executed by trained professionals, still they are performed by humans, thus errors are likely to be introduced.
Using reference models in the process model design phase helps to avoid making too many errors. It does however not eliminate the possibility of errors being introduced completely. When using reference models, errors are likely to be introduced for two main reasons. First, errors that are already present in the reference models are likely to be copied into the final process model. Second, process models are designed for each process independently, while in real life, processes are mutually dependent. Any error in a process model used for the implementation phase has a high possibility of leading to severe operational consequences, once the information system is fully implemented. Since the costs of correcting operational errors by far exceeds the costs of correcting modelling errors, it is of the utmost importance that the reference models used are correct.
To find errors in process models, many authors have developed verification methods. Basically, all of these verification methods can be used to check whether a process model is correct, in other words, they can be used to check for correctness of a process model. In Section 2, we categorize verification methods and we show that some methods look on the level of the executable specification, some on level of the business model and some on process models or reference models.
In this paper, we focus on the correctness of reference models for a specific information system, SAP R/3. The reference models are available in the ARIS for MySAP database in the ARIS Toolset, a commercial product of IDS-Scheer. As a modelling language, the ARIS Toolset uses Event-driven Process Chains (EPCs) [KNS92, KT98, Sch94]. We selected SAP R/3, since EPCs are used in a large variety of systems, including SAP R/3. Moreover, SAP R/3 is market leader in the field of Enterprise Resource Planning systems. Many verification approaches exist for EPCs. The verification method we chose looks at verification from a designers point of view and assumes the process designer to know what he intends to model. In the field of software engineering, this could be seen as validation, i.e. does the software (in our case the model) do what it is intended to do (in our case, what the process designer intended to model). However, a process specification such as an EPC should not be seen as an executable specification. Instead, the EPC should be seen as the specification of the process. Using this specification an operational system can later be implemented in a company. The approach presented in this paper, verifies the process specification (the EPC) against the possible future behaviour of an operational system. Hence the term verification.
We take the SAP reference models as a starting point, and use the verification approach presented in [DVA05], as our verification method. We show that many of the SAP reference models are correct and can indeed be used without any problems. However, we also show that some of the models should be used with care, i.e., the environment in which they are used needs to satisfy certain conditions for them to be correct. Furthermore, we show that a small number of the reference models is structurally incorrect, i.e., they need to be revised before they can be used as executable models. With respect to these errors, we investigate some common causes, and show how designers could avoid these errors. The remainder of this paper is structured as follows. In Section 2 we discuss related work with respect to the verification of process models. In Section 3 we describe our domain of analysis: SAP R/3, the EPC modelling method and the reference models. Next, in Section 4, we describe the approach for the verification of these models as implemented in the ProM framework1, and described in [DMV+, DVA05]. Following this approach we are able to evaluate the SAP reference models in Section 5. This evaluation is based on two lines: the evaluation of one complete module (Section 5.1) and a guided search through the database with reference models (Section 5.2). Finally, in Section 6, we draw some conclusions.
A subset of the work presented here has been published at the International Conference on Business Process Management (BPM05) [DJV05]. That paper however deals mainly with the question if the verification approach of [DVA05] could be used for the verification of reference models. This paper extends [DJV05] by presenting the verification results for the whole module from Section 5.1. Furthermore, we present a guided search trough the reference model database in Section 5.2, illustrating some of the errors related to the independent modelling of dependent business processes. 2
Since the mid-nineties, a lot of work has been done on the verification of process models,
and in particular
semantical issues, i.e. “will the process specified always terminate” and similar questions. The work that has been conducted on verification in the last decade can roughly be put into three main categories, namely “verification of models with formal semantics”, “verification of informal models” and “verification by design”. In this section, we present these categories and give relevant literature for each of them. 2.1
Verification of models with formal semantics In the first category we consider the work that has been done on the verification of modeling languages with formal semantics. One of the most prominent examples of such a language are Petri nets [DE95, Mur89, RR98]. Since Petri nets have a formal mathematical definition, they lend themselves to great extent for formal verification methods. Especially in the field of workflow management, Petri nets have proven to be a solid theoretical foundation for the specification of processes. This, however, led to the need of verification techniques, tailored towards Petri nets that represent workflows. In the work of Van der Aalst and many others [Aal00, AH00, DR01, HSV03, VA00] these techniques are used extensively for verification of different classes of workflow definitions. However, the result is the same for all approaches. Given a process definition, the verification tool provides an answer in terms of “correct” or “incorrect”. However, not all modeling languages have a formal semantics. On the contrary, the most widely used modeling techniques, such as UML and EPCs are merely an informal representation of a process. These modeling techniques therefore require a different approach to verification. 2.2
Verification of informal models Modeling processes in a real-life situation is often done in a less formal language. People tend to understand informal models easily, and even if models are not executable, they can help a great deal when discussing process definitions. However, at some point in time, these models usually have to be translated into a specification that can be executed by an information system. This translation is usually done by computer scientists, which explains the fact that researchers in that area have been trying to formalize informal models for many years now. Especially in the field of workflow management, a lot of work has been done on translating informal models to Petri nets. Many people have worked on the translation of EPCs to Petri nets, cf., [Aal99, ADK02, DA04, LSW98]. The basic idea of these authors however is the same: “Restrict the class of EPCs to a subclass for which we can generate a sound Petri net”. As a result, the ideas are appealing from a scientific point of view, but not useful from a practical point of view.
Also non-Petri-net based approaches have been proposed for the verification of informal modeling languages. One of these ideas is graph reduction. Since most modeling languages are graph-based, it seems a good idea to reduce the complexity of the verification problem by looking at a reduced problem, in such a way that correctness is not violated by the reduction, i.e. if a model is not correct before the reduction, it will not be correct after the reduction and if the model is correct before the reduction, it will be correct after the reduction. From the discussion on graph reduction techniques started by Sadiq and Orlowska in 1999 [SO99, SO00] and followed up by many authors including Van der Aalst et al. in [AHV02] and Lin et al in [LZLC02], it becomes clear that again the modeling language is restricted to fit the verification process. In general this means that the more advanced routing constructs cannot be verified, while these constructs are what makes informal models easy to use.
The tendency to capture informal elements by using smarter semantics is reflected by recent papers, cf. [ADK02, DA04, Kin04]. In these papers, the problem is looked at from a different perspective. Instead of defining subclasses of models to fit verification algorithms, the authors try to give a formal semantics to an informal modeling language. Even though all these authors have different approaches, the goal in every case is similar: try to give a formal executable semantics for an informal model. 2.3
Verification by design The last category of verification methods is somewhat of a by-stander. Instead of doing verification of a model given in a specific language, it is also possible to give a language in such a way that the result is always correct. An example of such a modelling language is IBM MQSeries Workflow [LR99]. This language uses a specific structure for modelling, which will always lead to a correct and executable specification. However, modelling processes using this language requires advanced technical skills and the resulting model is usually far from intuitive.
In this section, we have presented an overview of the literature on process model verification. We have categorized the various methods in three main categories and pointed out why many of them are not used in practice. In this paper, we use the technique presented in [DVA05] that can be seen as a combination of the first two categories. It assumes the designer to be able to decide whether or not a specification is semantically correct. This technique has been implemented in the Process Mining (ProM) Framework2, that is able to import EPCs defined in the ARIS Toolset3 and provides the designer with feedback about possible problems. SAP reference models are available in the ARIS Toolset format, and the users of these reference models are typically consultants that have a deep knowledge about the process under consideration. Hence, we found the approach described in [DVA05] to be the best approach for the verification of the SAP R/3 reference models.
Several authors researched the area of reference models before, see e.g. [Ber, CK97, FL03, Ros03, RA03, Sch00, Sil01a, Sil01b, Fra99]. In this section we introduce reference models based on [RA03] and then explain Event-driven Process Chains (EPCs). 3.1
Reference models Reference models are generic conceptual models that formalize recommended practices for a certain domain [FL03, Fra99]. Reference models accelerate the modelling process by providing a repository of potentially relevant business processes and structures. With the increased popularity of business modelling, a wide and quite heterogenous range of purposes can motivate the use of a reference model. These purposes include software development, software selection, configuration of Enterprise Systems, workflow management, documentation and improvement of business processes, education, user training, auditing, certification, benchmarking, and knowledge management [RA03]. What we learn from previous authors is that we can distinguish two types of reference models: industry models and application models. Industry reference models are generally higher level models and they aim to streamline the design of enterprise-individual (particular) models by providing a generic solution. Application reference models describe the structure and functionality of business applications including Enterprise Systems. In these cases, a reference model can be interpreted as a structured semi-formal description of a particular application. This application can then be seen as an existing off-the-shelfsolution that supports the functionality and structure described in the reference model. Rosemann and van der Aalst explain in [RA03] that application reference models tend to be more complex than industry reference models. They explain that the SAP reference model is one of the most comprehensive models [CK97]. Its data model includes more than 4000 entity types and the reference process models cover more than 1000 business processes and inter-organizational business scenarios. In the early nineties, two companies called SAP and IDS Scheer, have developed an intuitive process modelling langauge, which resulted in the process modelling language Event-driven Process Chains (EPCs). This language has been used for the design of the reference process models in the ARIS for MySAP database that we consider in this paper. EPCs also became the core modelling language in the Architecture of Integrated Information Systems (ARIS) [Sch00, KNS92]. 3.2
Event-driven Process Chains (EPCs) The SAP R/3 reference models are modelled as Event-driven Process Chains, or EPCs, in the ARIS Toolset. An EPC consists of three main elements. Combined, these elements define the flow of a business process as a chain of events. The elements used are: Functions, which are the basic building blocks. A function corresponds to an activity (task, process step) which needs to be executed. A function is drawn as a box with rounded corners.
Events, which describe the situation before and/or after a function is executed. Functions are linked by events. An event may correspond to the position of one function and act as a precondition of another function. Events are drawn as hexagons. Connectors, which can be used to connect functions and events. This way, the flow of control is specified. There are three types of connectors: ∧ (and), × (xor) and ∨ (or). Connectors are drawn as circles, showing the type in the center of the circle. Functions, events and connectors can be connected with edges in such a way that (i) events have at most one incoming edge and at most one outgoing edge, but at least one incident edge (i.e. an incoming or an outgoing edge), (ii) functions have precisely one incoming edge and precisely one outgoing edge, (iii) connectors have either one incoming edge and multiple outgoing edges, or multiple incoming edges and one outgoing edge, and (iv) in every path, functions and events alternate (no two functions are connected and no two events are connected, not even when there are connectors in between).
In the ARIS for MySAP reference databases, there are hundreds of EPCs that can be used in many different situations, from “asset accounting” to “procurement” and “treasury”. Since we cannot discuss all these models here, we focus on one of the modules that can be considered to be a representative subset of all reference models, namely “procurement”. This is a set of some 40 EPCs, all in the area of procurement. They describe processes for (i) internal procurement, (ii) pipeline processing (iii) procurement of materials and external services, (iv) procurement on a consignment basis, (v) procurement via subcontracting, (vi) return deliveries, and (vii) source administration.
All 40 models were analyzed using the approach described in [DVA05]. Before we show the results of this verification process in Section 5, we first briefly introduce this verification approach in Section 4. 4
For the verification of the EPCs in our reference model database, we use the approach described in [DVA05]. This verification approach is tailored towards the verification of Event-driven Process Chains and it assumes the designer of an EPC to be able to decide whether or not the EPC is correct. The approach is implemented in the ProM framework ([DMV+]) and it is freely available for download.
The verification process described in [DVA05] consists of several steps. In the first step, the designer of the EPC has to provide the tool with all combinations of initial events that could initiate the modelled process. Using this, the tool calculates all the possible outcomes of the process (in terms of events that occurred and have not been dealt with). Then, the tool requires the designer to divide those outcomes in two groups, the first of which contains all the outcomes that represent the desired behavior of the process. The A X e2 e3 /\ C e1 /\ e4 /\ D
B X e5
A e2 second group contains the undesired behavior. Clearly, depending on the model, either of the two groups can be empty. 4.1
Semantically correct models Models that are semantically correct are models of processes that, when started in any allowed state, will always terminate in one of the allowed termination states. In other words, routing constructs do not have to be synchronized. Choices can be made locally, without any knowledge of the execution history. 4.2
Syntactically correct models Models that are syntactically correct are models of processes that, when started in any allowed state, will always have the possibility to terminate in one of the allowed termination states. In other words, routing constructs have to be synchronized. Not all choices can be made locally, instead, the execution history limits the available options. An example of such a construct can be found in Figure 2, where the choices after functions A and B have to be synchronized in order to allow function C or D to execute. However, at any point in time, there is always an option to complete in a correct way. For example enabling event e3 after doing function A requires that after function B event e4 is enabled. This can easily be enforced by an operational system. 4.3 Incorrect models The final class of models are the incorrect ones. These models contain syntactical errors, such as an AN D-split followed by an XOR-join or the other way around. An example of such an incorrect model is shown in Figure 3, where functions A and B originate from an AN D-split, and are later joined by an XOR-join. As a result, function C will be carried out twice based on the same case in event e1. 5
The application of the verification approach presented in Section 4 is based on a basic assumption: It assumes that the designer of a model has a good understanding of the actual business process that was modelled, and he knows which combinations of events may actually initiate the process in real life. Typically, reference models are used by consultants that do indeed have a good understanding of the process under consideration. Besides, they know under what circumstances processes can start, and which outcomes of the execution are desired and which aren’t. Therefore, the approach seems to be well suited for the verification of the SAP reference models. 5.1
Procurement module As stated in Section 3 we focus on the procurement module of the ARIS for MySAP reference model database, since it can be seen as a representative subset of all reference models. The procurement module contains several sub-modules and we analyzed all the models from these modules using the approach presented in Section 4. Surprisingly, already in the first model (Internal Procurement) there were structural errors. In Figure 4, we show a screenshot of the verification tool used. It shows part of an EPC in which an AN D-split is later joined by an XOR join. Recall Figure 3, where we have shown that this is clearly incorrectly modelled. As a result, if this model would not be repaired, payments could be made for goods that were never received. Obviously, this is not desirable. In Figure 5 we show the repaired model, i.e. the XOR-join has been changed into an AN D-join. Now, the model is semantically correct, which means that it can be used in a business environment without problems.
The results of our analysis of the whole procurement module are presented in Table 1, which contains three columns. The first column shows the name of the module. The second contains the verification result. We use “I” for incorrect models, “S” for syntactically correct models, and “C” for semantically correct ones. The final column gives the business-wise implication of the error found if this model would be translated into an executable specification, if applicable. From the previous section it seems that we can conclude that most errors are made in the higher level models. Using this as a guide, we tried to find problems in the reference models. In fact, in the high level models, it is not hard to find these mistakes, by manually browsing through the Aris for MySAP Reference model databases. These high level models are usually more complex then the lower level models (i.e. they contain more functions, events and connectors). Therefore, errors are more likely to be introduced there. We would like to mention two observations that we made during this guided model selection. The first observation is that often, one particular initial event is applied in several (sub)models. Take, for example, the event “Deliveries need to be planned”. This event occurs in 15 different models. Every time it occurs, it is joined with the event “delivery is relevant for shipment”. However, in some models this is done via an XOR-join, and in some models via an AN D-join. In Figure 6, we show these two events, used in the “Consignment Processing” module, where they are joined by an XOR-join. However, in Figure 7, we show the same two events in an AN D-join configuration. Since these two events are always followed by something that refers to transportation, it seems that they should always appear in an AN D-join configuration. However, only a designer with deep knowledge of the process that is modelled can decide if that is the case.
The second observation, that seems to be a common one, is the effect of re-use. Typically, many different organizations have very similar processes. Therefore, when building reference models, it is a good idea to use one model to create another one. The new model is then customized in such a way that it fits the needs of the new organization better. Figure 8 shows a screenshot of the ARIS toolset, showing two models, namely “Q-notification with Complaint Against Vendor” on top and “Internal Quality Notification” below. These two models are exactly alike, except that in the top-model, a vendors complaint score can be updated. Here, re-use has been applied correctly.
In Figure 9, two models are shown for which the re-use was performed incorrectly. The model on the left hand side represents the handling of a “Service Order” and on the right hand side it represents the handling of a “Maintenance Order”. They are very similar, except that the latter does not make a distinction between maintenance at a customer site and at an internal site. Both models however, contain the same mistake, which results from re-using one reference model to create the other model. When services are to be entered, the rightmost event called “Services are to be Entered” occurs. However, when that is the case, due to the XOR-split in front of it, the function “Overall Completion Confirmation” will never be able to execute. Solving this problem requires a good understanding of the modelled situation since many correct solutions are possible. It is important to realize that the changes made to the original model do not introduce the error. The error appears in both models.
Although we only looked at a small subset of the entire reference model database, we can draw some important conclusions. First of all, it seems that problems are more easily introduced into larger models than into smaller ones. The reason that we did not find many problems in low level models can probably be explained by the fact that these models are typically very small and thus easy to understand. Although this may seem trivial, it shows that even reference models should be kept small and understandable to the designers that use them.
When the smaller models that are usually correct, are connected by higher level models, errors are easily introduced as well. As we saw in Section 5, these errors can lead to severe complications, such as invoices being paid twice. Second, when the same, or similar events are used in several modules, special care has to be taken. As we saw for the events with respect to shipments, there was no consensus about the use of them in different modules. Finally, the errors we found with our verification approach were all trivial to repair. Therefore, we feel that the use of such a verification tool in the early stages of process modelling, or reference model development would greatly improve the effectiveness and applicability of these models in later stages.
At this moment, we see two interesting questions that we will follow up on. The first is the question of the involvement of the designer in the verification process. In Section 4, we have shown that the designer is involved in the verification process. However, some decisions were made by the verification tool itself (for example which reduction rules to use). It would be interesting to know to what extent designers want to be involved in the verification process, maybe up to the point where they can specify their own operational semantics for the models under consideration.
Secondly, the verification method selected relies on behavioral properties of the model under consideration. We are interested in a verification method that would include structural properties as well. Although in our analysis performance was never an issue, it could be for larger, more complicated models. [Aal99] [Aal00] [ADK02] [AH00] [AH02] [AHV02] [Ber] [CK97] W.M.P. van der Aalst. Formalization and Verification of Event-driven Process Chains. Information and Software Technology, 41(10):639–650, 1999.
W.M.P. van der Aalst. Workflow Verification: Finding Control-Flow Errors using
Petrinet-based Techniques. In W.M.P. van der Aalst, J. Desel, and A. Oberweis, editors,
Business Process Management: Models, Techniques, and Empirical Studies, volume
1806 of Lecture Notes in Computer Science, pages 161–183. Springer-Verl
W.M.P. van der Aalst, J. Desel, and E. Kindler. On the Semantics of EPCs: A Vicious Circle. In M. N u¨ttgens and F.J. Rump, editors, Proceedings of the EPK 2002: Business Process Management using EPCs, pages 71–80, Trier, Germany, November 2002. Gesellschaft f u¨r Informatik, Bonn.
W.M.P. van der Aalst and A.H.M. ter Hofstede. Verification of Workflow Task Structures: A Petri-net-based Approach. Information Systems, 25(1):43–69, 2000.
W.M.P. van der Aalst and K.M. van Hee. Workflow Management: Models, Methods, and Systems. MIT press, Cambridge, MA, 2002.
W.M.P. van der Aalst, A. Hirnschall, and H.M.W. Verbeek. An Alternative Way to Analyze Workflow Graphs. In A. Banks-Pidduck, J. Mylopoulos, C.C. Woo, and M.T. Ozsu, editors, Proceedings of the 14th International Conference on Advanced Information Systems Engineering (CAiSE’02), volume 2348 of Lecture Notes in Computer Science, pages 535–552. Springer-Verlag, Berlin, 2002.
P. Bernus. GERAM: Generalised Enterprise Reference Architecture and Methodology. T. Curran and G. Keller. SAP R/3 Business Blueprint: Understanding the Business Process Reference Model. Upper Saddle River, 1997. [DA04] [DE95] [DJV05] [DMV+] [DR01] [DVA05] [FL03] [Fra99] [HSV03] [Kin04] [KNS92] [KT98] [LR99]
J. Dehnert and W.M.P. van der Aalst. Bridging the Gap Between Business Models and Workflow Specifications. International Journal of Cooperative Information Systems, 13(3):289–332, 2004.
J. Desel and J. Esparza. Free Choice Petri Nets, volume 40 of Cambridge Tracts in Theoretical Computer Science. Cambridge University Press, Cambridge, UK, 1995. B.F. van Dongen and M.H. Jansen-Vullers. Verification of SAP reference models. In Business Process Management 2005, volume 3649 of Lecture Notes in Computer Science, pages 464–469. Springer-Verlag, Berlin, 2005.
B.F. van Dongen, A.K.A. de Medeiros, H.M.W. Verbeek, A.J.M.M. Weijters, and W.M.P. van der Aalst. The ProM framework: A new era in process mining tool support. In Application and Theory of Petri Nets 2005.
J. Dehnert and P. Rittgen. Relaxed Soundness of Business Processes. In K.R. Dittrich,
A. Geppert, and M.C. Norrie, editors, Proceedings of the 13th International Conference
on Advanced Information Systems Engineering (CAiSE’01), volume 2068 of Lecture
Notes in Computer Science, pages 157–170. Springer-Ver
B.F. van Dongen, H.M.W. Verbeek, and W.M.P. van der Aalst. Verification of EPCs: Using reduction rules and Petri nets. In Conference on Advanced Information Systems Engineering (CAiSE 2005), volume 3520 of Lecture Notes in Computer Science, pages 372–386. Springer-Verlag, Berlin, 2005.
P. Fettke and P. Loos. Classification of Reference Models - a methodology and its application. Information Systems and e-Business Management, 1(1):35–53, 2003.
U. Frank. Conceptual Modelling as the Core of Information Systems Discipline - Perspectives and Epistemological Challanges. In Proceedings of the America Conference on Information Systems - AMCIS ’99, pages 695–698, Milwaukee, 1999.
K. van Hee, N. Sidorova, and M. Voorhoeve. Soundness and Separability of Workflow Nets in the Stepwise Refinement Approach. In W.M.P. van der Aalst and E. Best, editors, Application and Theory of Petri Nets 2003, volume 2679 of Lecture Notes in Computer Science, pages 335–354. Springer-Verlag, Berlin, 2003.
E. Kindler. On the Semantics of EPCs: A Framework for Resolving the Vicious Circle. In J. Desel, B. Pernici, and M. Weske, editors, International Conference on Business Process Management (BPM 2004), volume 3080 of Lecture Notes in Computer Science, pages 82–97. Springer-Verlag, Berlin, 2004.
G. Keller, M. N u¨ttgens, and A.W. Scheer. Semantische Processmodellierung auf der Grundlage Ereignisgesteuerter Processketten (EPK). Ver o¨ffentlichungen des Instituts fu¨r Wirtschaftsinformatik, Heft 89 (in German), University of Saarland, Saarbr u¨cken, 1992.
G. Keller and T. Teufel. SAP R/3 Process Oriented Implementation. Addison-
F. Leymann and D. Roller. Production Workflow: Concepts and Techniques. PrenticeHall PTR, Upper Saddle River, New Jersey, USA, 1999. [Mur89]