TECHNISCHE UNIVERSITEIT EINDHOVEN Department of Mathematics and Computer Science

Transcription

1 TECHNISCHE UNIVERSITEIT EINDHOVEN Department of Mathematics and Computer Science Modeling support for the Case Management paradigm and Expectations Management in process innovation By K. Kaan Supervisors: dr.ir. H.A. Reijers (TU/e, TM-IS) dr. M. Voorhoeve (TU/e, W&I-AIS) dr. W. van Eerde (TU/e, TM-HPM) E. Boender (GYATA BPI Consultants) Eindhoven, August 2005

2 Abstract Two subjects are covered by the research project described in this thesis. The first involves Case Management, an innovative approach to automated process support developed in industry. The second involves the management of expectations during business process improvement (BPR/BPM) projects. The objective of the first part is to connect the innovative concept of Case Management to the scientific field of business process management from a modeling perspective, and to enhance the ease and potentiality of process innovation using Case Management by proposing a suitable representation of business processes within this paradigm. We use a perspective of process support paradigms to describe the concepts of Case Management and relate it to the paradigms of Case Handling and Workflow Management. The central element of the Case Management paradigm is that the processing of cases by individuals is decoupled from the routing of the case through the enterprise. This decoupling allows the use of specialized automated support for both aspects of the business process. In the Case Management paradigm, the routing aspect is supported by Workflow Management and the case processing aspect is supported by Case Management. We propose a graphical modeling language which is inspired by an existing Case Management implementation. From the perspective of continuous redesign, implementation, enactment and evaluation of business processes within the BPM cycle, we argue that the structure of the process is best captured by focusing on the relevance of work in certain contexts. Our main interest goes out to visualizing the relations between the contexts of the several work activities in the process, using a concept inspired on Venn diagrams. In addition to the modeling language we have developed a software tool to illustrate the functionality needed to create and maintain models and have provided the functionality to automatically generate models from existing implementations. We conclude that it is valuable to use conceptual models in Case Management to increase the transparency of business processes. This view is supported by considering existing models and interviewing experts in the field. However, we have to be aware that the language has conceptual and practical limits, which have not been explored completely. Both further research and the practical application in pilot projects can help us to identify these issues and to refine the support of modeling languages in the field of case management. The second part involves the question how to measure and influence expectations in a process innovation project. From a literature review we conclude that the best target in expectations management is to establish realistic expectation levels. Inspired by the relative absence of empirical research directly focused on providing specific ways of managing user expectations, our objective has been to measure expectations at multiple times during a process innovation project and identify the management interventions that cause changes in expectation levels. We had the opportunity to perform a small survey and have constructed a limited measurement instrument accordingly. In our instrument, we measure the expectations towards several elements of the process, the perceived goals and expected outcomes of the project and the effects on the individual. During the survey we noticed that the time frame of our research project was too short to reach the objective of multiple measurements and the identification of underlying interventions. However, we were able to do some second-round interviews with a limited number of respondents. Also, we were able to collect some experiences with our measurement instrument during the survey, including some drawbacks concerning its validity. During the second interviews round, we observed that respondents could give very concrete reasons for their change in expectations, which indicates that future research aimed at identifying the interventions causing changes in expectations could use this approach. Also, it can help to identify specific elements of the process improvement project at which expectations are relatively low or identify teams with relatively low expectations. Future longitudinal field research to the validation of our assessment technique is needed, but our approach might be of interest to help identify the relation between management interventions and expectations, leading to best practices in the management of expectations. Eindhoven University of Technology Page 2 of 103

3 Preface This Master s Thesis is the result of a research project carried out from April 2004 to August 2005 at the sub department of Information Systems of the department of Technology Management at Eindhoven University of Technology. The research has been conducted in cooperation with GYATA BPI Consultants, a company specialized in Business Process Management. For me, this thesis is the final step to obtain the Master of Science degree in Computer Science. I would like to thank Hajo Reijers for his ideas and support during the last several years and I hope that we will find an opportunity to collaborate on publications in the near future. Also, I would like to thank my other supervisors Marc Voorhoeve and Wendelien van Eerde for their willingness to provide me with valuable feedback during my project. As my supervisors at GYATA BPI Consultants, I would like to thank Edwin Boender and Peter van der Molen for giving me the opportunity to conduct my research in a business setting and Gijs Spijkers for his supervision during the Expectations Management survey. During the project, my colleagues at GYATA BPI Consultants have been very supportive in sharing their knowledge with me and creating a nice work atmosphere, something for which I am very grateful. Finally, I would like to thank my friends, roommates and relatives for their support, especially during the last phase of the project. It would never have been finished without you. Kees Kaan, Urecht, August 16, Eindhoven University of Technology Page 3 of 103

4 Contents PART I: Developing a case management language and tool 1. INTRODUCTION RESEARCH OUTLINE ENTERPRISE MODELING IN THE BPM CYCLE PROCESS SUPPORT PARADIGMS CASE MANAGEMENT PARADIGM CONTEXT-BASED TASK MODELING LANGUAGE DRAWING MODELS FROM AN EXISTING IMPLEMENTATION VALIDATION FRAMEWORK LANGUAGE EXPRESSIVENESS SUITABILITY EVALUATION CONCLUSION / FUTURE WORK PART II: Expectations Management 12. INTRODUCTION RESEARCH OBJECTIVES EXPECTATIONS CONSTRUCT THEORETICAL FRAMEWORK MEASUREMENT INSTRUMENT EXPERIENCES AND RESULTS DISCUSSION CONCLUSION / FUTURE WORK Eindhoven University of Technology Page 4 of 103

5 PART I Developing a case management language and tool Eindhoven University of Technology Page 5 of 103

6 1. Introduction 1.1 Business Process Management (BPM) Business Process Management can be regarded as the field of designing and controlling business processes (Reijers, 2002) 1. This view, adopted from Leymann and Altenhuber (1994), distinguishes two fundamental aspects, namely the design (or build time) aspect and the control (or run time) aspect of managing business processes. The design aspect can be seen as a strategic issue involving decisions on process restructuring, the organization involved in executing the process and the objectives (in terms of costs, time, quality, etc.) for business processes. The control aspect can be seen as an operational or tactical issue involving decisions on production planning, resource assignment, budgeting and exception handling. This thesis focuses on the design aspect of Business Process Management and is targeted specifically at the concepts, methods and tools used for the automated support of business processes by information systems. In the next section, we give a brief overview of two process automation concepts which have a central position in this thesis: Workflow Management and Case Management. 1.2 Workflow Management (WFM) and Case Management (CM) Workflow Management can be defined as the automation of a business process, in whole or in part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules (P. Lawrence/Workflow Management Coalition, 1997). Van der Aalst and Van Hee (2002) describe Workflow Management in the following terms: Workflow Management refers to the ideas, methods, techniques and software used to support structured business processes. (p. 357). Clearly, there is some overlap between BPM and Workflow Management. However, there is a difference we wish to point at. We can see that WFM is aimed at the automation or support of business processes, while BPM is defined as the field of designing and controlling these processes. In this sense, the ideas, methods, techniques and software from the Workflow Management domain can be considered an element of the BPM field. Refer to 3 for a more detailed description of the concepts underlying Workflow Management. Two other process automation concepts are Case Handling and Case Management (CM) that both address the problem that processes may be too variable or complex to be handled by Workflow Management Systems. Typically, a normal execution route of a case is modeled but at the same time other routes are allowed if not explicitly excluded (see 2 Van der Aalst, Ter Hofstede, Weske, 2003). The focus is on the case as a whole rather than on individual actions being performed on the case. Case Handling (Van der Aalst, Berens, 2001) was introduced by Pallas-Athena in their product FLOWer. Case Management (also known as Activity Management) was introduced by Workflow Management Solutions and BPi (now GYATA BPI Consultants) in their product Activity Manager. Refer to chapter 3 for a more detailed description of the concepts underlying Case Handling and Case Management. 1.3 Research context The research project described in this report has been carried out in cooperation with GYATA BPI Consultants, a business consultancy company in The Netherlands. One of their focal areas is BPM, including the implementation of Workflow Management Systems. Their opinion on automating business 1 According to Reijers there is no agreement on the meaning of BPM, but there are topics with respect to business processes that are commonly gathered under this term, notably the design, analysis, modeling, implementation and control of business processes. 2 Note that Van der Aalst, Ter Hofstede and Weske formulate this problem in the specific context of Case Handling. We believe that the same formulation is applicable to the Case Management concept. Eindhoven University of Technology Page 6 of 103

7 processes is that Workflow Management Systems cannot be applied successfully in organizations without the use of Case Management. In the past years, their beliefs about process support led to the development of a Case Management software suite called the Activity Manager, which can be used in conjunction with a large range of Workflow Management products. In the opinion of GYATA BPI Consultants, Workflow Management Systems should be used only to automate the distribution of work through the organization. The actual handling of this work by individuals, should be supported by case-oriented tools (often referred to as Case Management or Case Handling tools). In this approach, one could think of Workflow Management Systems as systems managing the flow of work through the organization in solely logistical terms. The process definitions which drive the Workflow Management System, abstract from all case processing at the desk and focus entirely on the organizational routing of work from one role to another 3. For a more detailed description of this approach, refer to section 5. GYATA BPI Consultants has been applying the Case Management concept for the last 11 years. Over the last five years, they report a range of approximately 15 successful implementations of this concept. The reduced complexity of the Workflow models as a result of the specialized Case Management level in the process hierarchy led to shorter development times and a higher success rate of projects involving automated process support. Additionally, the Case Management approach is believed to provide more flexible support to autonomous workers and have a better fit with the organizational reality of task execution when it comes to the fine-grained support of work. The Case Management approach practiced by GYATA BPI has never been connected to the scientific field of Business Process Management. Also, GYATA BPI is the only company currently implementing the Activity Manager. Their specific expertise in this area has hardly been made visible by means of publications in scientific papers or business magazines. From a commercial point of view, it can be of great interest to increase the exposure of their ideas, tools and methods as they illustrate the expertise and innovative strength of GYATA BPI as a consultancy company. As far as the content of their ideas is concerned, cooperation with the scientific field gives them the opportunity to review, rethink and refine their methods, techniques and tools from a broader perspective. The scientific field itself can benefit from the knowledge and ideas on Case Management, which are the result of practical experience in the field. 3 This includes the routing from one organization to another, as contemporary Workflow Management Systems can be used across organizational boundaries. Eindhoven University of Technology Page 7 of 103

8 2. Research outline 2.1 Problem selection During the problem selection phase, we took a closer look at an implementation of the Activity Manager at a government agency responsible for administering subsidy legislation. We analyzed the business process and the implemented support by a Workflow Management System and the Activity Manager. As a start of our orientation we have modeled the implemented workflow model in terms of a high-level Petri Net and tried to understand the business process specified in the Activity Manager Buildtime 4. Inside the Buildtime, workflow steps are specified in more detail in terms of activities. See section 5.3 for more information on activities and the Activity Manager. The Buildtime contained 313 activities distributed over 17 workflow steps with a maximum of 53 activities within one single step and a minimum of 5 activities per step 5. In the Buildtime, each activity can be equipped with conditions to specify in which situations it is relevant (active), visible to the user, its execution is required and if it may be executed repeatedly. Our orientation study showed that roughly half of the activities had some relation to another activity (refer to chapters 8 and 9 for more details on our analysis of existing implementations). However, although we believe that the interrelation of activities is closely intertwined with the structure of the business process, the current view provided by the Buildtime does not provide an extensive insight into these relations. Based on our orientation study, we have defined and selected the following related problems as a starting point for our research project: In Activity Manager implementations, the knowledge about the structure of the business process on the Case Management level tends to be hidden inside the implemented system, as no methods, techniques or tools are available to support the representation of activities and their relations. In Activity Manager solutions, the absence of insight into the relations between activities, can require substantial maintainability efforts which compromise the opportunity to adapt business processes to the changing demands and requirements imposed by the continuous optimization of business processes in a BPM setting. We note at this point that systems based on the Activity Manager are not the only information systems carrying covert implementation-level representations of valuable business knowledge. In fact, the Workflow Management trend emerged in the nineties as an attempt to disentangle process and application functionality in information systems design (Van der Aalst, 2002), with the objective to solve problems comparable to the problems mentioned above. However, the question still remains how to represent this process knowledge after it has been separated from the applications. Extensive research has been done on the representation of workflow processes, resulting in various modeling languages and a framework to evaluate the expressive power of workflow modeling techniques by means of workflow patterns (Van der Aalst, Ter Hofstede, Kiepuszewski, Barros, 2003). As new paradigms for business process support (i.e. case handling or case management paradigms) emerge, obviously there is a need for new languages, tools and evaluation frameworks to support these paradigms. This thesis can be considered one of the steps in this process, as it is aimed at finding a suitable representation of business processes on the Case Management level, in close relation with the existing Activity Manager suite. 4 The Activity Manager Buildtime is the component in the Activity Manager suite used for design-time specification of the business process on the Case Management level. See section 5 for information on the Case Management level and the Buildtime component. 5 Workflow steps in the model without refinement into activities are left out of these statistics. Eindhoven University of Technology Page 8 of 103

9 2.2 Research Objectives Based on the research context (section 1.3) and our problem selection (section 2.1) described before, we can define the general objectives for our research project as: Connect the innovative concept of Case Management to the scientific field of managing business processes, using a modeling perspective. Enhance the ease and potentiality of process innovation using Case Management in a BPM setting by proposing a representation of business processes at the Case Management level of the process hierarchy. The latter objective has been specified as follows: Propose a representation of business processes at the Case Management level, which is able to o o facilitate insight into the structure of the process, in terms of activities and their relations; facilitate the reduction of design and maintenance efforts needed to support them. Develop a prototype of a software tool which illustrates the tooling support needed to design and maintain business processes using this representation. 2.3 Research Questions Several research questions arise from the objectives defined in the previous section. First, we specialize the objective of proposing a process representation into the question what modeling language is suitable for this job. By choosing a modeling perspective, we join the ontology used in the Workflow Management domain which was discussed briefly at the end of section 2.1. That is, in answering the question which methods, techniques and tools are suitable to support the design and control of business processes, frequently a systems modeling (Van Hee, 1994) approach is applied by studying modeling methods (how to design business process models?), modeling techniques (what are the notation and semantics of some modeling language?) and modeling tools (what software support is suitable for certain modeling purposes?). Other questions involve the functionality of a supporting tool and the fundamentals of Case Management. This provides us with three research questions: What are the fundamental properties of the Case Management paradigm from a business process modeling perspective? What process modeling language is suitable or can be developed to facilitate insight into the structure of business processes at the Case Management level and potentially reduce the design and maintenance efforts needed to support them? What are the functional properties of a modeling tool supporting this language? The last question is answered by developing a working prototype for illustration and demonstration purposes. 2.4 Research Design and Methodology In our research design, we distinguish the problem, analysis, design and validation elements and follow these in this thesis (see Figure 1). As the problem selection and research objectives have already been discussed in the previous sections, in this section we will now focus on the analysis, design and validation. Eindhoven University of Technology Page 9 of 103

10 Problem Analysis Design Validation Problem selection (2.1) Enterprise modeling in the BPM cycle (Chapter 3) Modeling language (Chapter 6) Validation framework (Chapter 8) Research objectives and questions ( ) Process support paradigms (Chapter 4) Modeling tool (Ch 6 and 7 implemented) Language expressiveness (Chapter 9) Research design (2.4) Case Management fundamentals (Chapter 5) Drawing models from an existing implementation (Chapter 7) Language suitability (Chapter 10) Figure 1 Four elements of the research projects In our analysis, we start by describing the notion of enterprise modeling (chapter 3) because one of our research questions involves the selection or development of a modeling language. We put enterprise modeling in the perspective of the BPM cycle, as this gives us some feeling for requirements related to the lifecycle of process models. Then we progress to process support paradigms (chapter 4) to clear out the concepts underlying Workflow and Case Management. Finally, we provide a more in-dept discussion on the fundamentals of Case Management (chapter 5), which we need to select or develop a modeling language that matches the underlying concepts of this paradigm. From the results of the analysis, we design a modeling language (chapter 6) and a supporting tool (which implements the constructs presented in chapter 6 and 7). Anticipating on the validation phase, we then design an algorithm to automatically draw models from Activity Manager implementations, using our proposed language (chapter 7). In our research design, we use this step to be able to collect data for validating the expressiveness and suitability of the language. In the validation step, we use the results from the previous three phases to check whether the proposed language and tool give us a satisfying solution of the original problem and to indicate which validation issues are left open for further research. We start by describing our validation model (chapter 8) and continue by discussing the expressiveness of our language (chapter 9) and its suitability in solving the problem (chapter 10). Eindhoven University of Technology Page 10 of 103

11 3. Enterprise Modeling in the BPM cycle 3.1 Enterprise modeling Models and enterprise modeling According to Kusters (2002), a model is a simplified representation of reality aimed at the understanding an control of this reality. More specific, a model is a formal representation of a limited number of aspects, from a certain perspective. An enterprise can be defined as the whole of unified models for representation of (aspects or parts of) an enterprise (Kusters, 2002). The construct enterprise does not necessarily has to coincide with an organization as some unified business activities are performed across bounds of organizations. More specifically, an enterprise can be defined as a system of processes, procedures, human, production, communication and control means organized as a distinguishable entity (Bernus, 1996) Process model hierarchy Van der Molen (2005) proposes the process hierarchy shown in Figure 2. The organization at the highest level, contains a large (in the order of to ) number of actions at the lowest level which can be grouped into activities, tasks, sub processes, processes and main processes Organization Main process Process Sub process Task Activity Action Figure 2 Process hierarchy In this hierarchy, one can think of tasks as those tasks modeled in a Workflow Management procedure. These tasks are refined into activities at the activity level 6. The research in this thesis is aimed specifically at the task and activity levels of this process hierarchy. That is, it addresses the models used for decomposition of tasks into activities. 3.2 BPM lifecycles The BPM cycle Various business process management life cycles have been proposed in the literature. Zur Muehlen proposes a model based on earlier work from Rolles (1998), Heilmann (1994) and several other authors (Zur Muehlen, 2004; pp. 85). In addition to this, we have the Quest BPM Cycle (Van der Molen, 1996). All these cycles have in common that some kind of analysis is followed by a process (re)design, implementa- 6 At some points in this thesis, we refer to the activity level as the Case Management level of the process hierarchy. Refer to section 5 for more detailed information on this subject. Eindhoven University of Technology Page 11 of 103

12 tion and enactment. During and/or after the enactment, the practical experiences with the process are evaluated and used as input to start a new cycle. The management-oriented process life cycle proposed by Zur Muehlen is given on the left-hand side of Figure 3. It is originally aimed at the development of business processes supported by workflow systems. The right-hand side shows the five phases used in the Quest methodology (Van der Molen, 1996). The cycle starts with the analysis of project goals, the environment of the future process and the organizational structures and rules that surround the new process. This is comparable to the Qualify and Unravel phases of the Quest methodology. The difference between both approaches is that the Qualify phase is positioned entirely at the organizational level, i.e. no choice for a specific process is made until the unravel phase. An import aspect of this phase is the definition of the organizational goals which the redesign is subjected to. During the unravel phase, the enterprise processes are identified and a selection is made which process to focus on. For this process, the goals on process-level are defined. These goals correspond to the project goals in Zur Muehlen s cycle. The process design and process implementation phases correspond to the Embed and Synthesis phases respectively. Process enactment and process evaluation, distinguished as separate steps by Zur Muehlen, correspond to the Turnaround phase of the Quest methodology. In Quest, continuous adjustment of the process during the Turnaround phase is proposed, comparable to the Flexibele Adjustment mentioned by Rolles (1998). The difference is however that Rolles like Zur Muehlen - distinguishes a separate Evaluation step following the enactment. It can be argued that the Process evaluation is in fact an activity that is performed in parallel with the process enactment. From a management perspective, Zur Muehlen states that the performance data collected during the Process Enactment phase is analyzed from an ex-post perspective during the Process Evaluation phase. The attention of the project team shifts from the daily execution (and possibly adjustment; although Zur Muehlen does not mention this aspect) of the process to in-depth animation and simulation of the process design alternatives. Qualify Turnaround Quest Unravel Synthesis Embed Figure 3 Life cycle models according to Zur Muehlen and the Quest methodology Eindhoven University of Technology Page 12 of 103

13 3.3 The need for process models in BPM cycles As the last section illustrates, an organization practicing Business Process Management will repeatedly iterate through some BPM cycle. In each iteration, the process is changed (redesigned), implemented, enacted and evaluated. This puts some demands on the process models used for understanding and controlling these processes (recall Kuster s definition of models in section 3.1.1). If these models provide insufficient support for frequent iterations through the BPM cycle, this compromises the potential gains from a BPM approach. In the worst case, it may only be feasible to make a single iteration through the cycle because the process models and their implementations are obscure to allow for a second iteration. In this scenario, the only option is to start a new project from scratch, including a thorough analysis of the process and its supporting information systems. If a second iteration is feasible, the costs compared to the first iteration may be equal or higher due to the lack of support by process models. Misunderstandings about the implemented process can take up valuable time during process redesign. It may be needed to reverse-engineer the existing previous iteration version of the process first, before being able to improve it. In our opinion, each new iteration through the BPM cycle should be quicker and less expensive than its predecessor until one reaches the optimal situation in which the cycle time is short enough to react to changing demands on the process and the efforts are low enough to be justified by the gains of each iteration. On a different level, one could think of the insufficient support provided by process models as leading to inadequate analysis of critical problems in the implemented processes. Process models can be thought of as means by which we understand, discuss, rethink and redesign business processes. In the process hierarchy (Figure 2), most entities reside on the lower levels. If we assume that changes in a higher level of the process hierarchy have more impact on the organization than changes in a lower level, it seems reasonable to believe that the change frequency of lower-level elements is relatively high. In other words: tasks, activities and actions are subject to change more than main processes, processes and sub processes. Similarly, we believe that activities change more frequently than tasks. Eindhoven University of Technology Page 13 of 103

14 4. Process support paradigms 4.1 Process-aware information systems Each information system in an organization can be considered as supporting one or many business processes. However, a limited class of these system is designed to contain knowledge of the business processes it supports. For example, a database management system will probably support many processes in storing or retrieving information, but does not contain any knowledge about the structure of these processes. We might think of database management systems as passive systems, continuously waiting for pieces of information to be offered for storage or requested for retrieval. In contrast, a Workflow Management System contains a model of a business process according to which it determines which person or group in the organization will be the next to receive a piece of work. Among other functions of a Workflow Management System, this illustrates the active involvement of this class of information systems with respect to the process it supports. The system is aware of the process as it contains process knowledge to control it behavior. For this reason, we refer to these systems as process-aware information systems. This term closely matches a definition for Business Process Management System as a generic software system that is driven by explicit process designs to enact and manage operational business processes (Van der Aalst, Ter Hofstede, Weske, 2003). Please note that the term process-aware information system was used in a personal view on BPM written by Van der Aalst (2004). In our opinion, the use of process-aware information systems is not limited to the operational level, though we must admit their application on tactical and strategic levels to be much more complicated and fairly uncommon. 4.2 Process support paradigms In the class of process-aware information systems, individual system types (e.g. Workflow or Case-oriented systems) can differ with respect to the storage and utilization of business process knowledge: What business process knowledge is stored inside the system. For example, this knowledge can be conceptualized in terms of actors, tasks, roles, process flows, case types, products, rules, etc. The representation of this knowledge. For example, this knowledge can be represented in terms of process models, formulas, programming languages, etc. The behavior exposed by the system, driven by its business process knowledge. For example, this behavior can include the presentation of work lists to workers, routing cases, deciding on work relevance, deciding on the status of work activities, etc. In Case Handling: A New Paradigm For Business Process Support (Van der Aalst, Weske, Grünbauer, 2005), which was inspired on the product FLOWer by Pallas-Athena, the authors present Case Handling as a new paradigm compared to the existing paradigm of Workflow Management. The article also mentions Vectus (London-Bridge/Hatton Blue) and the Activity Manager (described in section 5.3). As the focus of Vectus has shifted towards Customer Relationship Management, not much attention is paid to this product in the article. With respect to the Activity Manager, the authors remark that their meta model and formal framework on Case Handling do not apply, as the Activity Manager is process-driven and not data-driven. In this thesis, we adopt the word paradigm to refer to different approaches and concepts in supporting business processes by process-aware information systems. In our opinion, process support paradigms have a static aspect (what process knowledge is stored in which way?) and a dynamic aspect (what is being done with the stored knowledge?). The first two questions at the start of this section reflect the static aspect. The third question reflects the dynamic aspect. More precisely, we define process support paradigms as follows: Eindhoven University of Technology Page 14 of 103

15 A process support paradigm specifies (1) the entities and relations (between entities) that are used to represent a business process inside an information system and (2) the behavior that is exposed by the system to support business processes using these entities and relations. The first part of this definition refers to the static element of a paradigm by addressing the entities and relations that are used as a representation of the process knowledge stored inside the system. Note that the specification of a representation specifies both what knowledge is stored and in which way this knowledge is stored. The second part refers to the dynamic element of a paradigm by addressing the behavior that is based on the process representation and exposed by the supporting information system. The objective of this thesis is not to construct a taxonomy of process support paradigms, but we believe that this taxonomy could be valuable in estimating the suitability of certain paradigms for several kinds of business processes and for discovering or deriving new paradigms. We consider this to be an interesting subject for future research. 4.3 Workflow Management, Case Handling and Case Management Workflow Management paradigm In the typical Workflow Management (Van der Aalst, Van Hee, 2002) paradigm, a business process is recursively decomposed into sub processes and tasks, where the task is an atomic entity. The dynamic behavior of the process is conceptualized in terms of a case flowing through these tasks and sub processes according to a workflow model. This Workflow model specifies the flow of control of the process. A case can follow alternative (choice) or parallel (split) routes through the workflow model, where the split implies that the case can reside at several positions in the flow simultaneously. For a more elaborate description of possible control flow routings, refer to the Workflow Patterns by Van der Aalst et. al (2003). Each possible route of the case is represented in the workflow model, also known as explicit modeling. Tasks performed by humans are assigned roles to indicate which individuals or groups are authorized and responsible to perform the task. Roles are associated with work lists (also called work queues or inboxes), in which a work item appears as soon as a case is ready for processing. Users can pick up a work item from the work lists associated with their roles, which results in the start of an application to complete the task corresponding to the work item. Tasks can be performed automatically, which means that a self-contained (automatic) application and no role is associated with a task. Drawbacks associated with the Workflow paradigm are lack of flexibility, the atomicity of tasks, context tunneling and the mix-up of distribution and authorization (Van der Aalst, Weske, Grünbauer, 2005; Reijers, Rigter, Van der Aalst, 2003). The lack of flexibility refers to the push-oriented routing focusing on what should be done instead of what can be done, resulting in rigid inflexible workflows. The atomicity of tasks refers to the requirement that work should be straight-jacketed into atomic tasks, while user performs them at a much more fine-grained level. Context tunneling refers to the lack of context during the processing of a task by an individual, especially the processing history of a case. Finally, the mix-up between distribution and authorization refers to the problem that workers can see all the work they are authorized to do and are not authorized to do anything outside of their work list Case Handling paradigm The Case Handling 7 paradigm is an alternative to the Workflow Management paradigm. The central concept of case handling is the case and not the activities or the routing (Van der Aalst et. al, 2005; Reijers et. al, 2003). In contrast to the Workflow Management paradigm, the logistical state of the case is not 7 This paradigm is also referred to as Product-Driven Case Handling. In this report, we use the short-hand term Case Handling. Eindhoven University of Technology Page 15 of 103

16 determined by the control-flow status but by the presence of data objects. A typical property of Case Handling is the direct relation between activities and data. An activity can be bound to a data element by (orthogonal) mandatory and restricted relations. The semantic of the mandatory relation is that an activity is considered to be completed if and only if all of its related mandatory data elements have a value 8. The restricted relation can be used to specify that a data-element is restricted to be modified only from within a limited set of activities. The first of these relations deserves special attention, because the semantic of the mandatory relation implies that activities can be completed implicitly. For an example on implicit completion, in Figure 4 the Activity A has a mandatory data element Name and activity B has mandatory data elements Name and Address. The processing between activity A and B does not require the presence of the Address element. However, the processing performed after activity B does require this element. If the Name and Address are filled in during the execution of activity A, then activity B is completed implicitly as all of its data elements are present. If the Name without Address is provided at activity A, then the processing does not have to wait for the Address to become available but instead can continue until activity B is reached. This design allows flexible processing of cases for which certain data becomes available at an unknown point during the process. Activities: A Register information (some processing for which only the name is needed) B Complete information registration (some processing for which both name and address are needed) mandatory mandatory mandatory Data elements: Name Address Forms: Registration form Name: Address:... Registration form Name: Address:... Figure 4 Example of the mandatory relation in Case Handling Forms (also depicted in Figure 4) are related to activities and used solely to provide the user with an editable view on the data elements but are conceptually unrelated to the mandatory and restricted relations. However, some care in avoiding deadlocks must be taken if a data element mandatory for some activity is not present in its corresponding form (Van der Aalst et. al, 2005). Activities are assigned execute, redo and skip roles to specify which roles are authorized to carry out an activity (execute role), undo an activity (undo role) or skip and activity (skip role). This design relieves the problems associated with the mix-up of authorization and distribution in the Workflow Management paradigm. In summary, the main differences between Case Handling and Workflow Management are (according to Van der Aalst et. al, 2005) the focus on the case as a whole (avoiding context tunneling), the state of the case as primary driver to determine which activities are enabled, the interrelation between case data and process control in contrast to their separation in Workflow Management, the separation between authorization and distribution, and the distinction of the execute, redo and skip roles Case Management paradigm The Case Management paradigm can be considered as an extension or refinement of the Workflow Management paradigm as it is intended to combine Workflow Management with a case-oriented approach. 8 Note that skipping an activity is not the same as completing an activity, as a skipped activity may have mandatory data elements without a value. Eindhoven University of Technology Page 16 of 103

17 This combination is achieved by using the Workflow Management paradigm for the distribution of work between workers in the organization and using a case-approach for the actual processing of the case by individuals. Conceptually, two layers of process support are used: the Workflow Management layer and the Case Management layer. The process model driving the Workflow Management layer consists of relatively large tasks which are refined by the process specifications in the Case Management layer. This refinement is done in terms of activities which can or must be executed to complete the tasks. For each activity, conditions on the case attributes can be used to specify the situations in which it is enabled (active), required, visible or in which situation it can be executed repeatedly. In addition, activities can be started automatically or can be made active only if another activity is completed. Tasks Task A Register claim (routing by Workflow Management System) Task B Process claim Activities: Activity A-1 Register claim information Activity B-1 Contact originator condition: required only if claim amount exceeds Activity A-2 Estimate claim risk category Activity A-3 Review contact history condition: active only if work performer is a senior Activity B-2 Calculate proposed refund value Figure 5 Example the Workflow (Task) and Case Management (Activity) levels The example in Figure 5 shows two Workflow Management tasks A and B, refined into activities A-1, A-2, A-3 and B-1, B-2. We can see that reviewing the contact history (activity A-3) is enabled (active) only if the work performer is a senior worker. Similarly, contacting the originator of the claim (activity B-1) is required only if the amount of the amount exceeds a certain limit. Both examples assume that the corresponding information is available as a case attribute. The Case Management paradigm will be described in more detail in the upcoming chapter. Eindhoven University of Technology Page 17 of 103

18 5. Case Management paradigm In this chapter, we will describe the underlying concepts of Case Management. In section 5.1, we start with the distinction between process rules, work rules and product rules, that is used as a ground for multiple levels of tool support. Then, we describe the corresponding architecture and give an example of the distinction between process logistics and case processing. We continue by describing the use of conditions, precedence relations and automatic activities in the Case Management layer. As we use the notion of business rules in our description of Case Management, we consider its relation with the Business Rules approach (section 5.2). Then, we provide a quick overview of the Activity Manager (section 5.3). Finally, we address some fundamental properties of Case Management (section 5.4). 5.1 Case Management Multiple levels of process support Process-aware information systems can be thought of as incorporating a set of business rules 9 which define its behavior. The Case Management Paradigm is inspired on a categorization of these rules into three categories, proposed by Van der Molen (2005): Process rules These rules determine the logistics of process. That is, the flow of work through the organization from one role to another. This category of rules is closely related to the concept of office logistics, as it can be thought of as a flow of work from one desk to the other. Example rule: if the amount is more than , then proceed to task 3. Work rules These rules determine the content of the work carried out by one person. That is, the activities to be carried in some situation to complete a task. Example rule: if this case involves an existing client, then make a phone call, otherwise send a letter. Product rules These rules determine the shape of the product. In administrative organizations, products often consist of a set of information. From this perspective, the manipulation of information can be considered as adding value to the product. Example rule: if the risk of this insurance falls into the A-category, then increase the standard fee with 30%. Van der Molen proposes a process support architecture in which each rule is supported by its own specialized system. Figure 6 shows two contrary designs, where the left pane corresponds to a situation in which all business rules are supported by a Workflow Management System and the right pane shows the situation in which each business rule category is supported by a specialized system. In this scenario, the Workflow Management System is used exclusively for the support of process rules. 9 See section 5.2 for the relation between this notion of business rules and the concept of business rules used in the Business Rules Approach. Eindhoven University of Technology Page 18 of 103

19 Single tool design Tool specialization design Business Rules ICT Tools Business Rules ICT Tools Process Workflow Management Process Workflow Management Work Work Case Management Product Drawbacks: Product Business Systems Complexity issues Performance issues Maintainability issues Design principle: Specialized tools for specialized requirements Figure 6 Relation between business rules and ICT tools Van der Molen mentions three drawbacks of the single tool design. Several complexity issues arise from the incorporation of both process, work and product rules into a Workflow Management System. The process models defined within the Workflow Management System tend to become rather complex because of the abundance of rules that can be described while analyzing a business process. Even when using multiple hierarchical levels of processes, the workflow model will remain susceptible to design flaws and require a substantial amount of effort to implement. This directly effects the issue of maintainability. A workflow implementation will need to enable its business to flexibly adapt to new situations, which is more complicated when working with complex business rules models. Especially the lower-level rules (i.e. work and business rules) have a relatively short life-cycle. Another mentioned issue is the performance of Workflow Management System. Because of their distributed nature, these systems have a large task enactment overhead, which negatively affects the performance. This applies especially to the fine-grained workflow models needed to support work and product rules. In the tool specialization design, each rule category is supported by its own specialized tool. The design principle is that each type of rule has its own requirements for the system supporting it. For example, the process rules require task distribution and authorization. The work rules require flexible support of tasks, and in some situation require the system to leave the responsibility of task execution to the knowledge workers in the organization, which is hard to achieve with the traditional Workflow Management approach. The product rules require to be easily adjusted because their product-describing nature needs them to follow the business dynamics. The distinction between the support of the process and work rules can be considered to be the core element of Van der Molen s proposal. In our view, the product rules adding value to the product, can be separated from the Workflow system without altering the underlying process control paradigm. In this scenario, the Workflow Management System manages the execution of task and activities, while the specification and enactment of product rules is left to specialized systems. For example, when invoking some Office application script from a workflow, this is exactly what happens. The script determines the product shape, by for instance merging some texts into a letter, which adds value to the product. It seems reasonable to believe that a qualified workflow designer or engineer will attempt to separate the product rules from the workflow logic, without being obstructed by the workflow paradigm. As we believe the distinction of process and work rules is the most important difference between the case management and traditional workflow approach, we will focus on these two levels of process controlling Case Management architecture Figure 7 shows the architecture corresponding to the Case Management paradigm. The three layers in the figure correspond to the three levels depicted in Figure 6. As we can see, the functionality of the Workflow Eindhoven University of Technology Page 19 of 103

20 Management layer involves the logistic control of the process, the definition of tasks and roles, the enactment of task, task authorization and the invocation of the Case Management layer. This functionality is focused on the flow of control of the process. The functionality of the Case Management layer involves the flexible support of tasks carried out by workers (in terms of activities), the definition of activities, the enactment of activities and the invocation of business systems and applications. This functionality is focused on the content of the work carried out by workers. The business systems and applications layer contains functionality for the automation and support of logical units of work and the definition and enactment of product rules. This functionality is focused on adding value to the product. Workflow Management Layer Task Focus on flow and control of the process Role Functionality: Task Task Logistic control of the process Role Role Task and role definition Role Task Task enactment and authorization Case Management invocation Case Management Layer Focus on work contents Activity Activity Functionality: Activity Activity Flexible task support Activity Activity Activity definition Activity Activity Activity enactment Business systems and applications invocation and integration Business systems and applications layer Focus on adding value to the product Database and document management systems Transaction systems Customer Relations Management Knowledge Management Resource Planning Office applications Functionality: Automation and support of logical units of work, including (but not limited to) information storage, document editing, business transactions. Product rules definition and enactment Figure 7 Three layers of functionality in process support, according to the Case Management paradigm. Eindhoven University of Technology Page 20 of 103

21 5.1.3 An example of process logistics The process model used at the Workflow Management level, represents the logistic flow of work from one role to another. This logistic model is designed as a Workflow model and can be thought of as controlling the flow of work or the office logistics. The details about the work being carried out at each logistical node, is left open for further specification. As an example, we consider the processing of an order into a product shown in Figure 8. The upper part shows 5 logistic nodes labeled A through E at which some processing is applied to the case. The thick dotted arrows indicate the process flow through the enterprise (according to our figure, the entire enterprise is apparently seated in a single-floor building divided into four offices containing five employees 10 in total). A high level Petri Net using the workflow modeling concepts of Van der Aalst has been added to the picture to illustrate a model representing the logistics of this business process. This model abstracts from all processing performed within the logistical nodes of the process. We also included an example of the processing performed at logistic node D. At this node, the employee can perform several activities, such as judging the importance of the client, reviewing its transaction history, making some phone calls or performing additional research on this particular case. Also, at some point the employee has to make a decision either to reject or approve the case. As a result of this decision, the case will be routed either back to node B or forward to node E. Note that the model does not allow the case to be routed back to node C. On the one hand, this illustrates the notion of explicit modeling (it is not possible to take a route which is not explicitly part of the workflow model), on the other hand this illustrates the inability of the Case Management paradigm to solve problems related to the flow of control on the Workflow Management level 11. Handle first part ready for first handling Register start start Register Office logistics Office activities ready for second handling Handle second part B C Activities performed by one actor on a logistic node in the process D ready for approval decision: reject make phone call? reject approve Check approved choice: reject or approve? decision: approve additional client has a research? transaction history? A E Send end Order reception WFM Product delivery How to support it? Handle first part ready for second handling Handle second part ready for approval? CM How to model it? ready for first handling reject Check approve approved Send end Workflow Management Case Management important client? Figure 8 Example of the distinction between process logistics and process activities 10 In the same example, these 5 employees can be thought of as representing 5 user roles. 11 See the remarks in section about this inability. Eindhoven University of Technology Page 21 of 103

22 The question mark in Figure 8 illustrates a problem area addressed by the Case Management paradigm: how to support the processing of cases at the logistic nodes of the process? The question mark can also be used to illustrate a question addressed by this thesis: what modeling technique is suitable to model the processing of cases at the logistic nodes? In the next three sections, we discuss the concepts of conditions, precedence relations and automatic activities used by the Activity Manager (see section 5.3). These concepts are intended to allow flexible automated support of case processing by the worker Conditions The concept applied at the Case Management level is that the characteristics of a running case instance are used at run-time to determine if a piece of work is relevant, required, repeatable or visible for the worker to complete the Workflow task. By specifying the situations in which these properties apply, the process designer can guide and control the processing of the case. The situation-dependent work properties supported by the Activity Manager are Active, Required, Repeating and Visible (see the list below). Conditions in terms of the case attributes are used to specify in which situation each property applies (for example, claim_amount > 100 and claim_risk = high ). Each activity can be equipped with distinct conditions on each of the following four properties: Active: Specifies in which situation the activity is relevant. If an activity is not relevant, it is treated as if it does not exist. This implies that an activity which is required but not relevant at the same moment, is not needed to complete the task. Required: Specifies in which situation the activity is required to complete the workflow task. Repeating: Specifies in which situation the activity may be executed multiple times. That is, if an activity is not repeating in some situation, its execution is blocked after it has been executed once. Visible: Specifies in which situation the activity is visible to the end user Activity precedence relations To specify constraints on the sequential order of the execution of activities, the Activity Manager allows the process designer to specify precedence relations between activities. This relation is used to ensure that some activity can only be performed after another activity has been completed. In the Activity Manager, the After relation is used to specify precedence constraints: After: If a precedence relation ( After relation) exists between activities A and B (that is, B may only be executed after A), then activity B is relevant only if A has been completed Automatic activities To allow for the automatic execution of work, the Activity Manager supports three constructs. The first and last properties are used for the automatic execution of an activity. The parallel relation is used to start some activity automatically in parallel with another activity. That is: First: An activity labeled first is executed automatically as soon as the user picks up the work item from the work list. Last: An activity labeled last is executed automatically as soon as the user completes the work item in the work list. Eindhoven University of Technology Page 22 of 103

23 Parallel: If a parallel relation exists between activities A and B (that is, activity B is executed in parallel with activity A), then activity B is started automatically when activity A is started. Also, activity B is never visible. 5.2 Relation to the Business Rules Approach In section we described a categorization of business rules into process rules, work rules and product rules. The Business Rules Approach (BRA) concept was proposed in the eighties (e.g. Van Assche, Layzell, Loucopoulos, Speltincx, 1988) and has been subject of renewed attention in the last years (e.g. Business Rules Group, 2000; Seer/Business Rules Community, 2005). In this section, we discuss that the notion of business rules in section does not necessarily coincide with the idea of business rules used in BRA. The Business Rules Group (2000) defines a business rule as A statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. They distinguish a business and an information systems perspective. The business perspective includes any of the constraints that apply to the behavior of people in the enterprise (from restrictions on smoking to procedures for filling out a purchasing order). The information systems perspective includes the facts which are recorded as data and the constraints on changes to the values of those facts (what data may or may not be recorded in the information system). In this definition, the information system perspective is data-oriented. Consistent with this, the project GUIDE, from which this definition arises, did not deal with the issue of showing workflows or processes in terms of their relation with business rules (Business Rules Group, 2000, p.5). For these reasons, we can not directly relate the process-oriented Case Management paradigm to the data-oriented information systems perspective of the Business Rules Group. However, if we would generalize the information systems perspective to also include process models, then we can try to project the two perspectives onto Figure 6 (page 19). In this view, the business perspective has some correspondence with the process rules, work rules and product rules (left-hand side of each pane, under Business Rules ), and the information systems perspective has some correspondence with the facts represented in process models (Workflow and Case Management) or business systems (right-hand side of each pane, under ICT Tools ). An important note at this point however, is that the current version of the white paper of the GUIDE project is limited to the (data-oriented) information systems perspective only and has not been extended to the business perspective (Business Rules Group, 2000, p.5). The data orientation of business rules can also be found in Van Assche et. al (1988), who propose the construction of an entity/relationship model as the first phase to specify an information system according to their rule-based development environment RUBIC. Another illustration is an article on business rules specification (Herbst, Knolmayer, Myrach and Schlesinger, 1994) that is centered primarily around Database Management Systems. In our opinion, the incorporation of business rules inside information systems, is typically addressed from a data perspective by the Business Rules Approach. The definition of business rules by the Business Rules Group (2000) does cover the categorization of process rules, work rules and product rules proposed by Van der Molen (see page 18) as these rules define or constrain some aspect of the business. However, the incorporation of process rules, work rules and product rules into information systems does not correspond to the Business Rules Approach. For this reason, we do not use any techniques from BRA in this thesis. 5.3 Activity Manager The Activity Manager is the implementation of the Case Management paradigm by Workflow Management Solutions. This thesis discusses version 1.2 of the Activity Manager. Eindhoven University of Technology Page 23 of 103

24 5.3.1 Activity Manager in a Workflow Management architecture From the perspective of the Workflow Management System (WFMS), the Activity Manager (AM) is an application instantiated when the user picks up a task inside the WFMS. Within the AM, various activities are presented to the user. Each activity is related to an application 12. Interfaces exist between AM and a large number of WFM Systems, including FileNet eprocess, Staffware, COSA and IBM MQSeries. The interface between the WFMS and the AM allows the AM to access the case variables defined in the WFMS. To interface with other information system components (like databases, document management systems or transaction systems), small interface applications are used. These applications control the flow of information between the AM and the mentioned components. Some of these applications can be wrapper applications to interface with legacy systems. The Activity Management toolbox provided by GYATA BPI Consultants contains a set of generic plug-in applications to interface with various off-the-shelf system components. The functionality of these plug-ins varies from relatively lean (transferring data back and forth) to relatively rich (providing a user interface for viewing and modifying information from various systems). One example from the latter is a viewer application that enables users to view documents from the document management system, edit related case data and provide decision information through an integrated user interface. See appendix A for a detailed illustration on the Activity Manager architecture Activity Manager Buildtime and Client illustrations The process on the Case Management level is designed by using the Activity Manager Buildtime. Figure 9 shows a screenshot of this component. The right part of the screenshot shows the window in which the activity properties (and conditions) are edited. Figure 9 Activity Manager Buildtime 12 Each activity must be related to an application in the Activity Manager. Eindhoven University of Technology Page 24 of 103

25 The workers in the organization use the Activity Manager Client. Figure 10 shows a screenshot of this component. Figure 10 Activity Manager Client 5.4 Conceptual analysis of the Case Management fundamentals The inability to solve flow of control problems on the Workflow Management level During the discussion of our example, we mentioned the inability of the Case Management paradigm to solve problems related to the flow of control on the Workflow Management level. We have two remarks about this limitation. The first and most trivial remark is that in our example, the workflow model can be extended with a route from D to C if this would be required by the process design. If this is applied in an extreme fashion however, the workflow model ends up as a complete directed graph with an arc from each node to any other node probably resulting in complexity and maintainability problems. As a second remark, we note that most flow of control related problems found in contemporary Workflow Management Systems are not solved by simply adding an extra arrow to a workflow model (for these problems, refer to the Workflow Patterns by Van der Aalst et. al, 2003). Clearly, the automated support of a complex logistic process will still require a Workflow Management System with enough expressiveness to support them. However, by abstracting from the processing details inside the logistic nodes, is seems reasonable to believe that the reduced complexity of the workflow models leads to fewer problems related to the flow of control Relating activities and data through conditions The conditions used to specify the situation in which activities are active, required, repeating and visible (see section 5.1.4) are expressed in terms of the case attributes. Therefore, they specify a relation between the process and the case data. Each condition can be thought of as specifying some situation the case can reside in. Eindhoven University of Technology Page 25 of 103

26 5.4.3 Active condition versus other conditions The semantic of the active condition in specifying which activity is enabled in a certain situation, implies that it addresses the relevance of some piece of work in some situation. We believe that this relevance is crucial to the structure of the business process on the case management level. Therefore, we think that for identifying the structure of the process, the active condition has more importance than the required, visible and repeating conditions. If an activity is disabled (not active), it is treated as if it does not exist. This means that the other conditions are ignored. The work is always invisible, not required and the repeatable condition is not applicable. For this reason, we believe that the work relevance, is of a higher order than other work properties. Eindhoven University of Technology Page 26 of 103

27 6. Context-based Task Modeling Language In this chapter, we will use the analysis results of the previous section to construct a visual modeling language for the Case Management level. First, we will choose an appropriate abstraction level for our model and propose a visual modeling concept for our language (section 6.1). Then, we investigate the formal properties of this model by using Venn-diagrams as a reference (6.2), which brings us to some limitations of the approach (section 6.3). Finally, we add some refinements to the modeling technique (section 6.4). 6.1 Concepts and principles Choosing an abstraction A model is a formal representation of a limited number of aspects, from a certain perspective (Kusters, 2002; see 3.1.1). This implies that a model abstracts from elements that are considered less relevant for the purpose of the model. As we argued in section 3.3, the need for process models results from the continuous redesign, implementation, enactment and evaluation of business processes within the BPM cycle. We use this perspective to decide which process elements to abstract from. In our opinion, of all four conditions on activities, the active condition is most closely related to the structure of the process (see 5.4.3). Therefore, we abstract from the repeating, visible and required conditions in our visual model. As a refinement we will add some limited visual support for them (see section 6.4), but the core modeling concept will be based on the active conditions. Activities can be started manually or automatically. We state that the automatic start of activities is not necessarily a key element of the Case Management paradigm (5.1.6). In our design, we will focus on the activities started at the initiative of the workers. That is, activities which are never visible to the worker, do not necessarily need to be represented by the model. This includes activities which are executed in parallel with other activities. Analogous to the modeling techniques used in Workflow Management, we choose to abstract from the applications in our visual models. We realize that an overview of the applications used in by each activity can be of added value, but more strongly we believe that this aspect does not describe the structure of the business process and therefore should not be part of the model. We consider the time restrictions on activities ( valid from through ) to be a refinement rather than a structural element of the Case Management paradigm. For this reason, we will not use this aspect as a central element of our modeling language. Having abstracted from the secondary process aspects described above, we end up with the activities and their active conditions as the central perspective of our approach. In the next section, we describe our concept in representing them graphically, including their relations Visualization concept In Workflow Management, graphical languages have been used extensively to model business processes, both in commercial products and in the academic field. Visual models can provide intuitive insight a the process and can facilitate the communication about models between stakeholders from different disciplines. We consider this to be an argument to construct a visual concept for the Case Management level. The idea of expressing the relevance of certain pieces of work in certain situations is to think of overlapping contexts surrounding one or more activities. For example, in Figure 11 there are six activities involved in the processing of loan applications. Not all activities are relevant in every situation. If the Eindhoven University of Technology Page 27 of 103

28 application involves a foreign customer (that is, without an account), then the registration of its data and the preparation of a welcoming letter are relevant. Also, if a foreign customer requests a relatively high loan amount, some background investigation and the preparation of an additional appendix in the contract are relevant. In all cases where the loan amount is high (regardless of any account held by the customer), performing a risk analysis and informing a surveillance agency is relevant. Finally, for each application a contract is prepared. Example of activity context specification Example of conditions Customer without account Activity Active condition Register customer data High loan amount Register customer data cust_has_account = N Prepare welcome letter Prepare welcome letter cust_has_account = N Investigate customer background Investigate customer background cust_has_account = N AND loan_amount > 1000 Prepare contract appendix Prepare contract appendix cust_has_account = N AND loan_amount > 1000 Perform risk analysis Perform risk analysis loan_amount > 1000 Inform surveillance agency Inform surveillance agency loan_amount > 1000 Prepare contract Prepare contract (always active) Figure 11 Example of using contexts to specify the conditions of activities The right-hand of the figure shows the active conditions specified to express the relevance of the activities. The left-hand side of the figure shows the relevance specified in terms of contexts. The model expresses two situations: 1) the situation in which this case involves a customer without an account, and (2) the situation in which the loan amount is relatively high. Situation (1) corresponds with the predicate cust_has_account = N ; situation (2) corresponds with the predicate loan_amount > The activities Register customer data and Prepare welcome letter are relevant in the context of situation (1). The activities Perform risk analysis and Inform surveillance agency are relevant in the context of situation (2). The activities Investigate customer background and Prepare contract appendix are relevant in the context where the two situations coincide. That is, they are relevant only if situations (1) and (2) both apply to the case. For this reason, they are drawn in the intersection of situation (1) and (2). Finally, Prepare contract is not restricted to any situation, because it is relevant at all times. As its context is universal, we draw it at some point outside situations (1) and (2). 6.2 Formal semantics We use the sample model in Figure 12 to analyze the formal semantics of our modeling language. Eindhoven University of Technology Page 28 of 103

29 6.2.1 Venn-diagrams Context view Condition view a = 1 Activity Condition Act 1 b = 1 Act 1 a = 1 Act 2 Act 2 a = 1 b = 1 Act 3 Act 3 b = 1 Act 4 Act 4 true Figure 12 Example model with four activities and two intersecting situations The case attributes of a case type define a state space, which is a set containing each possible combination of values assigned to the case attributes. This state space can be formally defined as the Cartesian product of the domain of all attributes. For example, a case type with two binary attributes (i.e. with the domain {true, false}) has a state space of 4 elements. For a given case type, predicates can be used to define a subset on its state space. A case type with one variable n Ν (let Ν denote the set of natural numbers) has state space Ν on which the predicate n 10 defines the subset { n Ν n 10 } of all states where n is at least 10. A predicate can be specified by an expression in some formal language. For example, the Visual Basic expression a <> b specifies the same predicate as the expression a b in conventional mathematical notation. Refer to appendix B for an example of a state space containing 9 elements. The example of Figure 12 can be formalized in terms of a Venn diagram. The outside bound of this diagram is formed by the shape representing the entire state space. Inside the diagram, two shapes represent respectively the predicates a = 1 and b = 1, as illustrated in Figure 13. Figure 13 Activity positioning according to state space subset boundaries The conditions corresponding to the activities can be located in the Venn diagram as shapes or shape intersections. For example, the predicate used as condition for activity 1 corresponds to the left small ellipse and the predicate used for activity 2 corresponds to the shape which is the intersection of both small ellipses in the figure (this shape is drawn with a thick dotted line). Please note that the activity predicates Eindhoven University of Technology Page 29 of 103

30 do not necessarily correspond to a single area in the Venn diagram. For example, a = 1 corresponds to two adjacent areas in the diagram. Clearly, the predicates used as conditions for the activities correspond to shapes in the Venn diagram, not single areas. However, as we can see in Figure 12, we do not draw them on those shapes. If we would do this, we would need to uniquely mark each intersection shape representing a condition (like we did in Figure 13 with the thick dotted line). Instead, we draw the activities as illustrated in Figure 14. In this visualization approach, the semantics of activity positioning are that the activity s predicate is the conjunction of the predicates corresponding to the shapes which bound the graphical position. In other words, the condition of an activity is the logical conjunction of all the predicates associated with the shapes it is bounded by. In Figure 14, activity 1 is bounded by the shape corresponding to a = 1 and the shape corresponding to true, meaning that activity 1 has condition a = 1 true, which equals a = 1. Note that all activities are bounded by the shape representing true (that is, the entire state space). Figure 14 Illustration of the formal semantics of activity positioning Model semantics Based on the previous section, we now can define these semantics as follows: The context of an activity is the intersection of all contexts (graphically) bounding (the graphical position of) the activity. This allows us to implicitly define contexts from intersections of other contexts. In our example, activities 3 and 4 are bounded by the contexts a=1 and b=1, which implicitly defines their context (a=1 b=1). We must note at this point that the positioning of activities inside shapes can lead to misinterpretations if one forgets the restrictive nature of contexts. In our example, activity 1is restricted only by the context a=1 and totally independent of the context b=1. However, looking at the diagram one might mistakenly think that their context only holds if b=1 does not hold, as their graphical position lies outside of the b=1 context. To clear out this possible misunderstanding, we state: The context of an activity is restricted only by the shapes it is positioned in, not by any other shapes in the drawing. Or alternatively: an activity is relevant in the subset of the state space that consists of the intersection of all of its bounding shapes state space subset. A shape is a bounding shape of an activity if and only if the activity is positioned inside of the shape. Eindhoven University of Technology Page 30 of 103

31 6.3 Visualization limitations The conceptualization of Venn diagrams provides us with some interesting limitations to the models expressible in our modeling language. Figure 15 shows some known limitations in expressing set intersection by using Venn diagrams with circles, rectangles, ellipses and triangles. All examples are based on the requirement that all intersections of subsets must be present in the drawing. By using circles, the visualization is limited to three sets (a). By using rectangles, the visualization is limited to four sets (b). By using ellipses, the visualization is limited to five sets (c). By using triangles, the visualization is limited to six sets. (d). For all pictures shown, there is no known method to add another similar shape to the drawing (respectively a circle, rectangle, ellipse of triangle) while keeping the property intact that all subset intersections are visible in the drawing. ( a ) circles ( b ) rectangles (c) ellipses (d) triangles Figure 15 Drawing limitations using various shapes Although our modeling method is inspired on Venn diagrams, we only require the set intersections to be present in our diagram if there is some activity with a context specified by this intersection. As we can see in Figure 15b, a known limit when using rectangles is to combine four sets. It is important to note at this point, that the correspondence with Venn diagram imposes some restrictions on the situations that can be visualized by our modeling language. 6.4 Model refinements Logical OR construct: activity replication Comparable to the logical AND we define the logical OR as a context in which at least one of the involved contexts holds. However, in contrast with the intersection, Venn-diagrams provide us no suggestions to draw this construct. To allow the use of logical OR constructions, we allow activities to be replicated graphically. That is, they may be drawn multiple times in multiple contexts. The semantic of this construction is that the activity exists in the union of the contexts in which it appears. To clarify the replication, a dotted line is drawn between all replicated activities. Activity replication X Y Activity A Activity A Figure 16 Activity replication (logical OR construct) Eindhoven University of Technology Page 31 of 103