Modern Business Process Automation

The area of Business Process Management (BPM) has received considerable attention in recent years due to its potential for significantly increasing productivity and saving cost. In BPM, the concept of a process is fundamental and serves as a starting point for understanding how a business operates and what opportunities exist for streamlining its constituent activities. It is therefore not surprising that the potential impact of BPM is wide-ranging and that its introduction has both managerial as well as technical ramifications. While benefits can be derived from BPM even when its application is restricted to what can be described as “pen-and-paper” exercises, such as the visualization of business process models in order to discuss opportunities for change and improvement, there is potentially much more to be gained if such an analysis serves as the blueprint for subsequent automation of key business processes. In the area of Business Process Automation (BPA), sometimes referred to as workflow management, precise business process descriptions are used to guide the performance of business activities. Work is delivered to selected resources, which can be either humans or software applications, when it needs to be executed. Progress can be monitored and may give rise to the escalation of certain tasks where their deadline has passed or is not likely to be met. Events, such as the completion of a certain task by a certain resource, are logged and the resulting log files can be exploited for analysis purposes, an area of interest in its own right typically referred to as process mining.

The Business Process Management domain has evolved at a dramatic pace over the past two decades and the notion of the business process has become a ubiquitous part of the modern business enterprise. Most organizations now view their operations in terms of business processes and manage these business processes in the same way as other corporate assets. In recent years, an increasingly broad range of generic technology has become available for automating business processes. This is part of a growing trend in the software engineering field throughout the past 40 years, where aspects of functionality that are potentially reusable on a widespread basis have coalesced into generic software components. Figure 2.1 illustrates this trend and shows how software systems have evolved from the monolithic applications of the 1960s developed in their entirety often by a single development team to today’s offerings that are based on the integration of a range of generic technologies with only a small component of the application actually being developed from scratch. In the 1990s, generic functionality for the automation of business processes first became commercially available in the form of workflow technology and subsequently evolved in the broader field of business process management systems (BPMS). This technology alleviated the necessity to develop process support within applications from scratch and provided a variety of off-the-shelf options on which these requirements could be based. The demand for this technology was significant and it is estimated that by 2000 there were well over 200 distinct workflow offerings in the market, each with a distinct conceptual foundation. Anticipating the difficulties that would be experienced by organizations seeking to utilize and integrate distinct workflow offerings, the Workflow Management Coalition (WfMC), an industry group formed to advance technology in this area, proposed a standard reference model for workflow technology with an express desire to seek a common platform for achieving workflow interoperation.

The OR-join is one of the three synchronization constructs supported in YAWL and the only one that depends on non-local semantics, that is, not only the current state but also possible future states need to be considered. The other two synchronization constructs are the XOR-join and the AND-join. Both have local semantics, that is, it suffices to consider the current state without extrapolating to possible future states when making a firing decision. An XOR-join requires no synchronization, that is, as soon as there is a token in one of its input conditions, an XOR-join is enabled. An AND-join requires full synchronization, that is, it is enabled when there is at least one token each in all of its input conditions. The drawback of using an AND-join construct is that a workflow can deadlock when all paths leading to the input conditions of the AND-join are not active. On the other hand, an OR-join construct allows more flexibility as it supports only the synchronization of active paths. Hence, the use of an OR-join construct in process models is desirable and necessary in situations where it is not possible to know in advance which paths will be active in a particular workflow instance (e.g., paths coming out of a multi-choice construct). To determine whether an OR-join should be enabled at a particular state of a workflow, we need to look ahead to see if there are other active paths for which we should wait in future states of the workflow. Hence, the OR-join semantics are non-local and the analysis required to decide whether an OR-join should be enabled at a particular workflow state is non-trivial. The decision requires an awareness of the current state as well as possible future states of the workflow. Defining the nonlocal semantics of an OR-join is difficult even when a workflow language does not support complex constructs (e.g., cancelation) and/or puts certain restrictions on the models (e.g., no loops or only allow structures where an OR-join is preceded by an OR-split). This analysis becomes even more complicated when there are multiple OR-joins in the workflow or when other complex constructs such as cancelation and loops are present in the workflow.

Translating abstract concepts and descriptions of business practices and rules into process models is a far from trivial exercise. Even for highly structured processes (such as medical and banking environments), it is difficult (if not impossible) to successfully capture all work activities, and in particular all of the task sequences possible, in a workflow model, at least not without producing some very complex models. In fact, it is because of the discrepancies between real-world activities and formal representations of them that workflow process instances typically experience exceptions during their execution.¹ Traditionally, exceptions are understood to be events that by definition occur rarely. But in a workflow process, an exception can be described as an event that is deemed to be outside “normal” behavior for that process. Rather than being an error, it is simply an event that is considered to be a deviation from the expected control-flow or was unaccounted for in the original process model. Such events happen frequently in real working environments. Exceptions are a fundamental part of most organizational processes; in fact, a substantial proportion of the everyday tasks carried out in a business can be categorized as exception handling work. Consequently, every executing instance of a work process will be likely to incorporate some deviation from the plan. In this sense, a work plan can be seen to be just another resource or tool that mediates the activities of workers towards their objective, rather than a prescriptive blueprint that must be strictly adhered to. Such deviations from the plan should not be considered as errors, but as a natural and valuable part of the work activity, which provides the opportunity for learning and thus evolving the plan for future instantiations. Historically, exception handling within PAIS has fallen well short, particularly after execution has commenced. It is assumed that if an exception is expected, or even could conceivably have been anticipated, then the modeler has a priori knowledge of such an event, and it should therefore have been built into the model. However, if a modeler builds all possible a priori exception scenarios into a model, it can lead to very complex models, much of which will never be executed in most cases. Also, mixing business logic with exception handling routines complicates the verification and modification of both, in addition to rendering the model almost unintelligible to most stakeholders.

During the design of any information system, it is important to balance between flexibility and support. This is of particular importance when designing process-aware information systems. On the one hand, userswant to have support from the system to conduct their daily activities in a more efficient and effective manner. On the other hand, the same users want to have flexibility, that is, the freedom to do whatever they want and without being “bothered” by the system. Sometimes it is impossible to provide both flexibility and support because of conflicting requirements. The continuous struggle between flexibility and support is illustrated by Fig. 6.1. The right-hand-side of Fig. 6.1 shows the part of the spectrum covered by classical workflow management systems. These systems focus on processes that are repeatedly executed in some predefined manner and are driven by procedural languages. Note that in procedural workflow models there may be alternative paths controlled by (X)OR-splits/joins. However, the basic idea is that the completion of one task triggers other tasks. The YAWL nets described in earlier chapters provide such a procedural language. Although the YAWL language is highly expressive, its token-based semantics is most suitable for repetitive processes with tight control. The left-hand-side of Fig. 6.1 shows the other end of the spectrum. Here processes are less repetitive and the emphasis is on flexibility and user empowerment. Here it is difficult to envision all possible paths and the process is driven by user decisions rather than system decisions. Groupware systems (e.g., “enhanced” electronic mail, group conferencing systems, etc.) support such processes and focus on supporting human collaboration and co-decision. Groupware systems do not offer supportwhen it comes to ordering and coordination of tasks. Instead, the high degree of flexibility of these systems allows users to control the ordering and coordination of tasks while executing the process (i.e., “on the fly”).

The YAWL System is structured as a service-oriented architecture. It is composed of an extensible set of YAWL Services (see, for example Chaps. 10–12), each of which is deployed at a certain endpoint and offers one or multiple interfaces. Some of these services are user-facing, meaning that they offer interfaces to end users, while others offer interfaces to applications or other services. Among the different styles of service-oriented architectures, the YAWL System adopts the Representational State Transfer (REST) style. In line with the principles of REST (or RESTful) architectures, YAWL services provide access to resources, each with a Unique Resource Identifier (URI). For example, each workflow specification is exposed by the Engine as a resource, and when an instance of a workflow specification (i.e., a case) is created, this case is also represented as a resource. Also, in line with the principles of RESTful architectures, YAWL services interact with one another using the basic operations defined by the HyperText Transfer Protocol (HTTP). Specifically, YAWL services interact by means of HTTP’s GET and POST operations:GET being used to obtain information about a given resource, and POST being used to create resources and to update existing resources.Messages exchanged through these operations are encoded using the eXtensible Markup Language (XML) and (with some exceptions) conform to predefined XML schemas. Messages may contain references to resources, which are concretely represented as Uniform Resource Locators (URLs).

The core modeling component of the YAWL System is the Editor. This tool enables workflow designers to graphically define complex process models, and to analyze and export these models to the Engine. Specifically, the Editor is a rich client application offering visual support for the definition of the process control logic, the data associated with the process and its tasks, and the organizational resources participating in the process. An important aspect of the Editor is the provision of sophisticated logic to verify the produced models. Through this capability, a designer can pinpoint syntactical and semantic issues at a mouse click, so as to avoid potentially costly mistakes before deploying a process to a workflow engine. The main driver behind the development of a visual editor for YAWL was the necessity to speed up the creation of process models and to foster the uptake of the language by nontechnical users. In light of this, the Editor had to fulfill the requirements of free availability, portability, ease of use, and interoperability. The tool had to be freely available; therefore, it was decided to release it under the open source LGPL license. Portability was guaranteed by developing the Editor in Java^TM and avoiding any code dependency on OS-specific libraries. Ease of use was achieved by providing the Editor with an intuitive user interface on top of a core graphical component based on extensions to the JGraph libraries.¹ Interoperability was supported by the definition of a common XML format and a set of API calls for the exchange of workflow specifications between an editor and the runtime environment (cf. Chap. 9). The interaction between design and runtime environment in the YAWL System is depicted in Fig. 8.1.

A workflow comprises three main perspectives: control-flow, data, and resources. The resource perspective is particularly important because, for the most part, workflow tasks are designed to be performed by people, and so a workflow environment should support efficient and flexible ways to associate work with the people who have the required skills and authorizations to carry it out. Thus, the resource perspective is primarily responsible for modeling an organizational structure, and the people who populate it, in a computational form, so that a person may be coupled with tasks and data emanating from the control-flow and data perspectives. While control-flow and data-flow are necessarily tightly coupled within a workflow enactment engine, in the YAWL environment the resource perspective is supported by a discrete Custom Service called the Resource Service, in line with YAWL’s Service Oriented Architecture. Consequently, the Engine is oblivious to the assignment of resources to tasks (i.e., it is said to be agnostic with regards to resourcing). The YAWL Resource Service provides full support for 37 of the 43 identified resource patterns (the remaining six being particular to the case-handling paradigm) and so may be considered the preeminent implementer of workflow resource pattern support.

This chapter discusses the implementation and use of the Worklet Service (a conceptual overview of the service can be found in Chaps. 4 and 5). The Worklet Service has been implemented as a YAWL Custom Service (cf. Chap. 7). In the discussion that follows, a reference to the “Worklet Service” applies to the entire Custom Service, while a reference to the “Selection Service” or the “Exception Service” applies to that particular subcomponent of the service. All of the worklet processmodels in this chapter are expressed using YAWL notation – the language is used to model static YAWL processes, and the worklets used both for selection and exception compensations – thus, all worklet specifications are examples of standard, complete YAWL process models. The Worklet Service comprises two discrete but complementary subservices: a Selection Service, which enables dynamic flexibility for process instances, and an Exception Service, which provides facilities to handle both expected and unexpected process exceptions (i.e., events and occurrences that may happen during the life of a parent process instance that are not explicitly modeled) at runtime.

The Declare Service is a YAWL Custom Service that enables decomposing YAWL tasks into DECLARE workflows, that is, workflows supported by the workflow management system (WfMS) called DECLARE. The goal of this service is to enable a particular kind of flexibility. Chapter 6 describes a constraint-based approach to workflow models and the ConDec language. This approach, supported by the DECLARE WfMS, allows for more flexibility, that is, execution of tasks is allowed if it is not explicitly forbidden by some constraint. This chapter describes DECLARE and the Declare Service for YAWL. Sometimes it is easier to express a process in a procedural language (e.g., the native workflow language of YAWL) and sometimes a declarative approach is more suitable. Moreover, in a larger process it may be useful to express parts of the process in a procedural language and specify other parts in terms of constraints. Using the service-oriented architecture of YAWL, this can easily be realized. A YAWL task may decompose into a DECLARE process and a task in DECLARE can be decomposed into a YAWL process. Arbitrary decompositions of DECLARE and YAWL models allow for the integration of declarative and YAWL workflows on different abstraction levels.¹ This way the designer is not forced to make a binary choice between a declarative and a procedural way of modeling. Hence, a seamless integration can be achieved, where parts of the workflow that need a high degree of flexibility are supported by declarative DECLARE models, and parts of the processes that need centralized control of the system are supported by YAWL models.

Business processes may be analyzed and designed at different levels of abstraction. In this respect, it is common to distinguish between business process models intended for business analysis and improvement, and those intended for automation by means, for example, of a workflow engine such as YAWL. At the business analysis level, stakeholders focus on strategic and tactical issues such as cost, risks, resource utilization, and other nonfunctional aspects of process models. At the automation level, stakeholders are interested in making their models executable, which entails the need to provide detailed specifications of data types, data extraction and conversion steps, application bindings, resource allocation, and distribution policies, among others. The requirements for process modeling notations at these two levels of abstraction are significantly different. This in turn has resulted in different languages being advocated at the business analysis level and at the execution level. Common languages used at the business analysis level include flowcharts, UML activity diagrams, the Business ProcessModeling Notation (BPMN), and Event-driven Process Chains (EPCs). In this chapter, we consider BPMN, and specifically, version 1.0 of the BPMN standard specification. In general, the main purpose of BPMN models is to facilitate communication between domain analysts and to support decision-making based on techniques such as cost analysis, scenario analysis, and simulation. However, BPMN models are also used as a basis for specifying software system requirements, and in such cases, they are handed over to software developers. This handover raises the following question: How can developers fully exploit BPMN process models produced by domain analysts?

This chapter discusses the relationship between YAWL and Event-Driven Process Chains (EPCs). EPCs were introduced in the early 1990s when major software vendors identified the need for a business-oriented representation of system functionality in order to speed up the rollout of business software in companies. Back then, the Institute of Information Systems (IWi) in Saarbrücken, Germany, collaborated with SAP on a project to define a suitable business process modeling language for documenting processes of the SAP R/3 enterprise resource planning system. There were two results from this joint effort: the definition of EPCs as a modeling language and the documentation of the SAP system in the SAP Reference Model as a collection of EPC process models. This SAP Reference Model had a huge impact on industry and research, with several publications referring to it. It also motivated the creation of further EPC reference models, for example, in computer integrated manufacturing, logistics, and retail. EPCs are frequently used in real-world projects due to a high user acceptance and extensive tool support. Some examples of tools that support EPCs are ARIS Toolset by IDS Scheer AG, ADONIS by BOC GmbH, and Visio by Microsoft Corp. There is also a tool-neutral interchange format called EPC Markup Language (EPML). While EPCs and YAWL share most of their simple and advanced routing elements, there are some subtle differences that are important to know before mapping them. The aim of this chapter is to clarify commonalities and differences and to discuss how transformations can be specified. Against this background, it is organized as follows. Section 14.2 revisits the Carrier Appointment process as an example to introduce EPCs. Section 14.3 then uses the 20 original workflow patterns to highlight commonalities and some important differences between both languages. Section 14.4 presents how a mapping from EPCs to YAWL can be specified, while Sect. 14.5 discusses the transformation in the reverse direction. An alternative to these mappings using concepts from Petri net synthesis is presented in Sect. 14.6. Section 14.7 summarizes the chapter.

The goal of this chapter is to broaden the reader’s knowledge in the area of open sourceWfMS. To achieve this we introduce three other open sourceWfMSs. These are OpenWFE, jBPM and Enhydra Shark, which according to download statistics (July 2008) are the open source systems with the largest number of downloads (closely followed by YAWL). The purpose of the presentation is not to provide detailed insight into each of these systems, but rather to expose the reader to different approaches and to discuss the similarities and differences of these approaches with regard to YAWL. The chapter is divided into three parts, each describing one system. The descriptions follow the same format as much as possible. First, some background information is given. Subsequently, the architecture is described. Then an introduction to the underlying process modeling language is given from control-flow, data, and resource perspectives. After that, a part of the Order Fulfillment case is modeled and the solution briefly discussed. Each description concludes with a brief comparison of the system and YAWL. All files containing the discussed examples are distributed for test-runs with the electronic supplement of the book.

So far we have seen how workflow models can be defined in YAWL and how the YAWL workflow engine allows a model to drive business processes. Once such a model becomes operational, the Engine automatically logs activity, keeping track of task start and completion events, their time of occurrence, the resources involved, and so on (cf. Chap. 9, Sect. 9.7). These logs are a valuable source of information about the way a business process actually performs in practice, and can be used as a basis for operational decision making. Process mining is a technology that uses event logs (i.e., recorded actual behaviors) to analyze workflows. This is a valuable outcome in its own right, because such dynamically captured information can alert us to practical problems with the workflow model, such as “hotspots” or bottlenecks, that cannot be identified by mere inspection of the static model alone. Further, the information extracted through process mining can be used to calibrate simulations of the workflow’s potential future behaviors. In effect, this gives us a “fast forward” capability, which allows future activity to be predicted from the current system state and explored for various anticipated scenarios. In this chapter, we explain how YAWL’s logs can be mined, and how the information extracted from them can be used to calibrate simulations of expected future behavior. This is done using two additional tools: the process mining tool ProM and the modeling and simulation package CPN Tools.

The Order Fulfillment process of Genko Oil was set up based on recommendations from the Voluntary Inter-industry Commerce Solution Association (VICS).¹ These recommendations are best practices derived from the experience of hundreds of organizations in the area of logistics and supply chain management. Although these companies offer products varying in many aspects, they all have similar order fulfillment processes in place. For this process, an efficient collaboration with many trading partners is very important. Thus, companies prefer to use standards and suggestions, such as the VICS recommendations, for setting up their workflows instead of trying to innovate in executing these processes. Of course, not all companies have the same requirements on order fulfillments. For example, Zula Exquisite might only provide Full Truck-Load and Single Package Shipments and neglect Partial Truck-Loads. Contrary to Genko Oil, they therefore do not need to implement those parts of the Carrier Appointment subprocess dealing with Partial Truck-Loads. Still, there will be many commonalities with the order fulfillment process deployed at Genko Oil. Thus, instead of reimplementing this process from scratch, it is far more attractive for Zula Exquisite to amend the YAWL workflow model deployed at Genko Oil to their needs. Process configuration can prove beneficial when process adaptations are needed to suit specific requirements, for example, if a process model that depicts a certain business process in a general manner should be adapted to the requirements of an individual organization. It restricts the possible behaviorwith respect to a previously built process model in a controlled way before the process’ execution. The configuration of a process model therefore takes place in an adaptation phase between build time and runtime of a process model. Hence, at build time process, designers can integrate several variants of how a particular process can be executed into a single process model. Afterwards, the model user selects those parts relevant to the specific setting (e.g., an organization or project). All irrelevant model parts can then be automatically removed before the process is executed at runtime. This approach not only allows organizations like Zula Exquisite to adapt an existing model for the same process to individual needs, but it also enables organizations like VICS to provide templates for workflow models that are easily adaptable to user requirements while still conforming to their recommendations. These templates are called configurable reference process models. Furthermore, process configuration decisions can be mapped to domain related, natural language questions. In this way, users who are not very proficient in workflow modeling can adapt a process model through simply answering a questionnaire.

Distributed architectures depending on their nature require different forms of coupling.Web-solutions with a database back-end are traditionally tightly coupled with one another. Meanwhile, the transaction processing systems running in banks rely on loose couplings with the systems in other banks. This can be observed in the tendency for inter-bank transactions to be reconciled overnight. The nature of any business problem that brings about integrating distributed resources dictates the format and style of their coupling. The same goes for integrating processes. Business processes depending on the business problem they solve will require the whole range of coupling styles usually observable in distributed applications. Furthermore, the fact that there are usually many instances of any business process running in parallel means that a whole range of challenges that commonly do not occur in distributed applications always occur. Terms such as “synchronous,” “asynchronous,” “blocking,” “nonblocking,” “directed,” and “nondirected” are often used to refer to the degree of coupling required by an architecture or provided by a middleware. However, these terms are used with various connotations. Although various informal definitions have been provided, there is a lack of an overarching formal frame work to unambiguously communicate architectural requirements with respect to (de-)coupling. This chapter does not propose a solution to process integration. It does not discuss the range of modeling elements that would allow us to model an integrated process. Nor, does it discuss an implementation that solves process integration. What it does is define and frame the problems of process integration. This way we can understand what a solution must be able to do in order to support the modeling and execution of integrated process models. This way we can measure and evaluate some of the “solutions” based on their real merits rather than the claims of the creators of those solutions.

Chapter 2 introduced the soundness property on a special class of Petri nets called WF-nets (WorkFlow nets). To reiterate, a WF-net is sound if and only if the following requirements are met: Any executing instance of the WF-net must eventually terminate At the moment of termination, there must be precisely one token in the end place and all other places are empty No dead tasks Van der Aalst has shown that soundness of a WF-net corresponds to boundedness and liveness of an extension of that WF-net. As boundedness and liveness of Petri nets are both decidable, soundness ofWF-nets is also decidable. Based on this observation, theWoflan tool was built, which uses standard Petri-net techniques to decide soundness. However, as Chap. 1 has already mentioned, the class of WF-nets is not sufficient to reason about YAWL nets. For this, we need to extend the WF-nets with the concept of reset arcs, yielding RWF-nets (Reset WorkFlow nets). Using reset arcs, the cancelation features of YAWL can be captured in a natural way: if some task or condition is canceled by some task, then the corresponding place is reset by the corresponding transition. Unfortunately, soundness of an RWF-net does not correspond to boundedness and liveness of an extension of this net, as the example RWF-net in Fig. 20.1 shows. Although this RWF-net is sound, it is unbounded as the place p may contain an arbitrary number of tokens. Furthermore, the reachability problem is undecidable for reset nets. As the liveness property corresponds to a reachability problem, the liveness property cannot be decided for arbitrary reset nets. On top of this, YAWL also includes the OR-join construct, which has been neglected so far in this chapter.

Hospitals face increasing pressure to both improve the quality of the services delivered to patients and to reduce costs. As a consequence of the open-market approach adopted in healthcare provision, hospitals must compete with each other on the basis of performance indicators such as total treatment costs for a patient, waiting time before treatment can start, etc. Patients visiting the hospital will no longer accept long waiting times, and increasingly have specific demands with respect to the planning of their appointments and quality of services they will receive. The aforementioned issues place significant demands on hospitals in regard to how the organization, execution, and monitoring of work processes is performed. Workflow Management Systems (WfMSs) offer a potential solution as they support processes by managing the flow of work, such that individual work items are done at the right time by the proper person. The main benefit of utilizing these kinds of systems is that processes can be executed faster and more efficiently. In addition, these processes can be closely monitored, potentially enhancing patient safety. It is generally agreed that WfMSs are mature enough to support administrative processes that are relatively stable and fixed in form. However, hospital processes are typically diverse, require flexibility, and often involve multiple medical departments in diagnostic and treatment processes. Even for patients who have the same condition, the actual diagnostic and treatment process that they undergo may vary considerably. Furthermore, it is often necessary to change the course of the treatment process based on the results of tests performed and the way in which a patient responds to individual treatments.

In recent years, business process management (BPM) and workflow technology has reached a certain level of maturity, with a great potential to deliver benefits in a wide range of application areas. Nevertheless, it is typically applied by companies with a high adoption level of information technology. As part of the Australian Research Council Centre of Excellence for Creative Industries and Innovation, the BPM Group at Queensland University of Technology decided to explore the potential of applying BPM and workflow technology to the field of screen business. The field of screen business is characterized by business processes with high demands for creativity and flexibility. These processes span a value chain consisting of four major phases: development, preproduction, production, and postproduction. Out of these four phases, production is the most expensive phase in screen business as it is when the movie is actually created and shot. Also, it is during production that the majority of cast and crew are contracted and the majority of equipment and resources utilized. At present, a film production is a highly manual process that requires handling large amounts of heterogeneous data on a daily basis and coordinating many geographically distributed stakeholders. Not surprisingly, such a process is time-consuming and error-prone, and can easily increase the risk of delays in the schedule. Applying a workflow system can provide benefits to the film production process by automating, streamlining, and optimizing the process. YAWL offers such capabilities and moreover its service-oriented architecture facilitates the development of sophisticated extensions to tailor workflow systems to the needs of screen business.

This book presents both the YAWL language and the supporting toolset. YAWL fits well in the transition from workflow management systems focusing on automation of structured processes to Business Process Management (BPM) systems aiming at a more comprehensive support of a wider variety of business processes. The development of YAWL was triggered by limitations of existing software for process automation. Although much has been written about business processes, there is a lack of consensus about how they are best described for the purposes of analysis and subsequent enactment. This has resulted in a plethora of approaches for capturing business processes. Despite an abundance of standardization initiatives, there is no common agreement on the essential concepts. Standardization processes are mainly driven by vested business interests. The large and influential software companies in the BPM area are involved in multiple standardization processes (to keep all options open), but do not wholeheartedly commit to any of them. The inherent complexity of business processes and the question of what fundamental concepts are necessary for business process modeling, enactment, and analysis gave rise to the development of a collection of workflow patterns. These patterns describe process modeling requirements in a language-independent manner. The Workflow Patterns Initiative started in the late nineties when the first set of 20 control-flow patterns were identified. These patterns where inspired by the design patterns for object-oriented design by Gamma et al. and focused on the ordering of tasks in business processes (e.g., parallelism, choice, synchronization, etc). Later this set of patterns was extended to more than 40 patterns. Moreover, driven by the success of the control-flow patterns, also other perspectives were analyzed using a patterns-based approach. This resulted in data patterns (dealing with the passing of information, scoping of variables, etc.), resource patterns (dealing with roles, task allocation, work distribution, delegation, etc.), exception handling patterns (dealing with exceptional situations), flexibility patterns (to make processes more adaptive and adaptable), interaction patterns (formodeling the “glue” between processes), and so on. All of these patterns resulted in a systematic overview of the possible, and maybe also expected, functionality of an ideal BPM solution.

This appendix describes the Order Fulfillment process followed by a fictitious company named Genko Oil. The process is freely inspired by the VICS (Voluntary Inter-industry Commerce Solutions) reference model1 and provides a demonstration of YAWL’s capabilities in modeling complex control-flow, data, and resourcing requirements.