Deadline-based Escalation in Process-Aware Information Systems

Deadline-based Esalation in Proess-Aware Information Systems Wil M.P. van der Aalst 1,2, Mihael Rosemann 2, Marlon Dumas 2 1 Department of Tehnology Management Eindhoven University of Tehnology, The Netherlands w.m.p.v.d.aalst@tm.tue.nl 2 Centre for IT Innovation Queensland University of Tehnology, Australia m.rosemann,m.dumas@qut.edu.au Abstrat Proess-aware information systems are typially driven by proess models apturing an idealized view of the atual proesses. For example, most proess models assume that planned ativities happen within a reasonable period. In reality suh assumptions may not hold, and as a result workers may be fored to bypass the system or the designer is fored to expliitly model all exeptions that may our when ativities are not handled on time, leading to spaghetti-like models. In this paper, we aknowledge that proesses may hange when the organization is unable to meet deadlines and refer to suh hanges as esalations. Esalations may hange the routing of work (e.g., bypass tasks), hange the work distribution (e.g. allow other people to exeute delayed ativities), or hange the requirements with respet to available data (e.g. a deision is made before all information is available). This paper proposes the 3D (Detet, Deide, and Do) approah to deal with esalations and desribes a number of esalation mehanisms. The approah has been validated through ase studies and simulation experiments. 1 Introdution This paper fouses on deadline-based esalation, i.e., taking the appropriate ations when getting lose to a deadline or when it beomes lear that a deadline will not be met. One of the goals of deadline-based esalation is to let proess-aware information systems mimi human behavior when it omes to deadlines. Humans typially hange their behavior when onfronted with a deadline [11, 27, 31]. Consider for example the Yerkes-Dodson law [31] desribing that inreased pressure (e.g., an approahing deadline) will improve performane but too muh pressure will (eventually) degrade performane. In daily life it an also be observed that humans tend to take more risks when being late (e.g., driving a ar). For example, workers may skip tasks or require less information to make a deision. Clearly, suh flexibility is desired in in many situations but rarely supported by IT. Unlike humans, proess-aware information systems suh as workflow management systems, typially do not hange their behavior when onfronted with deadlines. As a result, these systems stik to an idealized view of the proess even when there is no time or it is even undesirable to stik to this idealized proess. Therefore, we introdue the onept of esalation in the ontext of proess-aware information systems. Just like a human would esalate (i.e., hange his behavior) whenever he is unable to meet ertain deadlines, we propose the information system to esalate in a similar fashion. Esalation ould imply the skipping of tasks, allowing less qualified people to do ertain tasks, or making deisions based on inomplete data. Note that esalations ould also be driven by the opposite problem, i.e., the resoures of an organization assigned to a proess are under-utilized. In this ase, esalation ould mean taking on 1

additional ativities (e.g. inreased pre-sales in a onsulting ompany). The fous of and examples within this paper will be foused on deadline-based esalations, but both ases are very similar. As a working example, we onsider the telelaims proess of a large Australian insurane ompany. 1 This proess deals with the handling of inbound phone alls, whereby different types of insurane laims (household, ar, et.) are lodged over the phone. The proess is supported by two separate all enters operating for two different organizational entities (Brisbane and Sydney). Both enters are similar in terms of inoming all volume (approx. 9,000 per week), average all handling time (550 seonds), number of all enter agents (90) and performane objetives (90% of all alls should be answered in less than 60 seonds). Differenes are the underlying IT systems, the physial loations and the modes of operation (24 hrs. versus 9-5). The telelaims proess model is shown in Figure 1. The two highlighted boxes at the top show the subproesses in the two all enters (Brisbane and Sydney). The lower part desribes the proess in the bak-offie. This proess model is expressed in terms of an Event-Proess Chain (EPC) [18, 26]. To introdue the notation let us onsider the subproess orresponding to the all enter in Brisbane. The proess starts with event Phone all reeived. This event triggers funtion Chek if suffiient information is available. This funtion is exeuted by a Call Centre Agent. Then a hoie is made. The irle represents a so-alled onnetor and the x inside the onnetor indiates that it is an exlusive OR-split (XOR). The XOR onnetor results in event Suffiient information is available or event Suffiient information is not available. In the latter ase the proess ends. If the information is available, the laim is registered (f. funtion Register laim also exeuted by a Call Centre Agent ) resulting in event Claim is registered. The all enter in Sydney has a similar subproess and the bak offie proess should be self-explaining after this short introdution to EPCs. One hallenge for the Australian insurane ompany handling the proess shown in Figure 1 is dealing with an inreasing number of inoming phone alls during the Australian storm season (Otober-Marh). Storms ause a higher number of damages, raising the number of inoming weekly phone alls to more than 20,000. This not only puts signifiant burden on both all enters, but also on the sueeding bak-offie proesses related to evaluating and managing these laims. Overtime as one way of adjusting the available resoures is applied, but typially an not ope with the entire demand. Thus, to ope with inreased all traffi, the insurane ompany operates an event-based response system that differentiates four ategories of situations based mainly on how severe the storms are. The first ategory inludes loalized storms and flooding and leads to a all volume of 10-50% above average for a period of at least two hours. Due to the inreased all volume, ustomers have to wait for 5-10 minutes in the queue. The seond ategory is triggered if strong winds, hail and strutural damage ours. This leads already to a wait time of 10-30 minutes and the all volume is 50-100% above the foreast for at least two hours. The third ategory overs wide-spread damage leading to waiting times of more than 30 minutes. The fourth and final ategory inludes extreme and rare ases, in whih more than 80 ustomers would wait on the phone for more than 30 minutes. Individual response strategies have been defined for eah of these four ategories. The responses utilize additional external resoures as well as a hange in the way laims are lodged. First, additional resoures are utilized through redeployment of employees from other departments (e.g. sales) and hiring of asual staff. While most of these people are trained, their performane in terms of average all handling time is lower than the performane of the professional all enter agents. Seond, a streamlined way of lodging the laims is applied in order to redue the average all handling time and to redue the waiting time in the queue. In this so-alled rapid lodgment proess, only a redued amount of information is olleted from the laimant. This leads to an average all handling time of 380 seonds. for experiened all enter agents, and 450 seonds. for the additionally employed agents, down from the usual average of 550 seonds. One mehanism to deal with the different performane of these two types of agents is all routing whih direts all new and straight-forward ases to the asual additional workfore, while the more ompliated follow-up alls are direted to 1 This ase study (inluding the data provided in this setion) is drawn from an interview with a all enter manager. 2

Call Centre Brisbane / 24x7 Call Centre Sydney / 5 days, 9-5 Frequeny, weekly: 9,000 Frequeny, weekly: 9,000 Phone all reeived Phone all reeived 30.00 Seond(s) Chek, if suffiient information is available Call Centre Agent 30.00 Seond(s) Chek, if suffiient information is available Call Centre Agent 90 90 0.90 0.10 0.90 0.10 Suffiient information is available Suffiient information is not available Suffiient information is available Suffiient information is not available 520.00 Seond(s) Register laim Call Centre Agent 520.00 Seond(s) Register laim Call Centre Agent 90 90 Claim is registered Claim is registered 20.00 Seond(s) Determine likelihood of laim Claims Handler 150 0.15 0.85 Insured ould not be iable Insured ould be liable 660.00 Seond(s) Assess laim Claims Handler 150 0.80 0.20 Claim has been aepted Claim has been rejeted 120.00 Seond(s) Initiate payment Claims Handler 180.00 Seond(s) Advise laimant on reimbursement Claims Handler 150 150 Payment has been initiated Caimant has been advised 30.00 Seond(s) Close laim Claims Handler 150 Claim has been losed Figure 1: Insurane laim handling senario (before esalation). 3

the experiened workfore. The four ategories of situations identified by the insurane ompany an be seen as four levels of esalation. All levels of esalation involve the rapid lodgment proess but the number of additional resoures varies per level. The manager in harge for laim servies together with managers in harge for the related bak-offie proesses personally evaluate the severane of the weather onditions and trigger the different esalation ategories. The telelaims proess model integrating the above esalation mehanisms (exept for the all routing step) is shown in Figure 2. In the situation shown there are 30 additional all enter agents. Moreover, for the bak-offie proess there are 50 additional laim handlers. Note that the four levels of esalation refer to the proess as a whole. In reality it an also be the ase that a single ase or a limited set of ases is esalated. For example, it ould be that different ases have different deadlines and that due to irumstanes some ases have been delayed more than others. Consider for example an insurane ase requiring medial information from some speialist and the information is still missing five days before some operation. There is no need to esalate the whole proess. It suffies to esalate the single ase, e.g., look for another speialist. Another example, would the reviewing proess for a onferene. If there is a paper that has not been reviewed by any PC member, the PC hair will esalate and try to find a last minute reviewer. If the paper is supposed to be reviewed by three reviewers and only one review is missing while the two reviews agree, the esalation ould be to just ontinue with one review missing. Although not expliitly mentioned by the people involved in the telelaims proess, we added an esalation mehanism to Figure 2 that esalates a ase in isolation if needed. In the original proess, funtion Assess laim would on average take 660 seonds. As shown in Figure 2 there are now two funtions: one taking 660 seond and one taking only 400 seonds. In a way this is similar to the rapid lodgment. However, the esalation does not depend upon the global level of esalation. Instead it depends on how long the ase is already in the proess. If it has been in the proess for more than 1 hour, a rapid assessment is done. In the remainder of this paper, the telelaims proess is used as a running example. Using this ase study we will illustrate the hallenges of workflow esalation, i.e., What are the available strategies to ope with an inreasing waiting time (i.e. esalation strategies)? What are the sope, tradeoffs and effetiveness of these esalation strategies? How to use simulation to support the seletion of the right level of esalation and esalation strategy? This paper is strutured as follows. The next setion provides an overview of proess-aware information systems and how esalations effet the main perspetives of these systems. Setion 3 introdues the 3D approah, i.e., detet, deide and do, as a way of ategorizing the main ativities of an esalation proess. Alternative esalation mehanisms are differentiated for eah of the perspetives in Setion 4. Setion 5 gives insights into the ontributions proess simulation an make for the evaluation of esalation mehanisms using the telelaims proess. Setion 6 desribes another ase using different esalation mehanisms. The paper ends with an overview of related work (Setion 7) and onlusions (Setion 8). 2 Proess-Aware Information Systems Proess-Aware Information Systems (PAISs) support business proesses in organizations based on expliit knowledge of both the organization and the proesses. Note that lassial appliations suh as e-mail, spreadsheets, and databases are unaware of the proesses at hand. As a result they do not 4

Call Centre Brisbane / 24x7 Call Centre Sydney / 5 days, 9-5 Frequeny, weekly: 20,000 Frequeny, weekly: 20,000 30.00 Seond(s) Phone all reeived Chek, if suffiient information is available 0.90 0.10 Call Centre Agent (Expert) Call Center Agent (Novie) 90 30 30.00 Seond(s) Phone all reeived Chek, if suffiient information is available 0.90 0.10 Call Centre Agent Call Center Agent (Novie) 90 30 Suffiient information is available (if expert) 350.00 Seond(s) (if novie) 420.00 Seond(s) Rapid Lodgement of laim Claim is registered Call Centre Agent (Expert) Call Center Agent (Novie) Suffiient information is not available 90 30 350.00 Seond(s) 420.00 Seond(s) Suffiient information is available Rapid lodegement of laim Claim is registered Call Centre Agent Call Center Agent (Novie) Suffiient information is not available 90 30 20.00 Seond(s) Determine likelihood of laim Claims Handler 200 0.15 0.85 The insured ould not be iable Insured ould be liable 5.00 Seond(s) Chek total proessing time of laim Claims Handler 200 0.60 0.40 Total proessing time > 60 mins. Total proessing time < 60 mins. 400.00 Seond(s) Assess laim (rapid method) Claims Handler 660.00 Seond(s) Assess laim Claims Handler 200 200 0.80 0.20 Claim has been aepted Claim has been rejeted 120.00 Seond(s) Initiate payment Advise laimant Claims 180.00 Handler Seond(s) on reimbursement Claims Handler 200 200 Payment has been initiated Caimant has been advised 30.00 Seond(s) Close laim Claims Handler 200 Claim has been losed Figure 2: Insurane laim handling senario inluding esalation mehanisms. 5

offer support for the definition, analysis, enatment, ontrol, and monitoring of business proesses. Traditionally, organizations hard-oded fragments of business proesses in dediated software. However, sine the nineties more and more organizations started to use generi software, e.g. Enterprise Resoure Planning (ERP) systems, Workflow Management (WFM) systems, Business Proess Management (BPM) systems, et. WFM systems suh as Staffware, MQSeries, and COSA are the most typial examples of a PAIS. Based on an expliit model a proess is enated, or as the Workflow Management Coalition (WfMC) defines it: A system that defines, reates and manages the exeution of workflows through the use of software, running on one or more workflow engines, whih is able to interpret the proess definition, interat with workflow partiipants and, where required, invoke the use of IT tools and appliations. [20]. BPM systems an be onsidered to be the next generation of workflow tehnology extending its funtionality beyond automation [30]. BPM systems inlude funtionality for monitoring, analysis, flexibility, and ross-organizational proesses. ERP systems are also proess aware but parts of the system are dediated to speifi proesses (e.g. prourement, sales, or finane). These parts an be onfigured within predefined boundaries. In addition most ERP systems inlude a workflow omponent to allow for arbitrary proesses. The workflow engines of SAP, Baan, PeopleSoft, Orale, and JD Edwards an be onsidered as integrated BPM systems. Note that the lass of PAISs is not restrited to ERP, WFM and BPM systems. There are many other systems supporting expliitly modeled proesses, e.g. Produt Data Management (PDM), Customer Relationship Management (CRM), and Case Handling (CH) systems. Note that systems like the PDM system Windhill and the CH system FLOWer provide a workflow omponent. Also note that, to date, many organizations still use self-developed PAISs. For example, many banks, insurane ompanies, governmental organizations have developed dediated PAISs whose funtionality is omparable to the systems just mentioned. The topi of this paper, i.e. dealing with esalation when getting loser to a deadline, is relevant to a wide range of PAISs. However, for presentation purposes we often fous on WFM systems as typial examples of PAISs. data perspetive resoure perspetive task perspetive proess perspetive Figure 3: Perspetives of models driving PAISs. PAISs are driven by models of proesses and organizations. By hanging these models, the behavior of the system adapts to its environment and hanging requirements. These models over different perspetives. Figure 3 shows some of the perspetives relevant for PAISs (for a detailed disussion of perspetives in the ontext of WFM systems we refer to [16]). The proess perspetive desribes the ontrol-flow, i.e., the ordering of tasks. The data perspetive, also referred to as information perspetive, desribes the data that are used. The resoure perspetive desribes the struture of the organization and identifies resoures, roles, and groups. The task perspetive desribes the ontent of individual steps in the proesses and thus onnets the other three perspetives. Esalations may impat one or more perspetives. Therefore, we elaborate a bit on the perspetives using the example shown in Figure 4. The figure shows four tasks: T1, T2, T3 and T4. The proess perspetive shows that the four tasks are exeuted in a sequene, i.e., first T1, followed by T2, et. Most real-life proesses are not simple sequential proesses but inlude parallel routing, 6

resoure perspetive R1 R2 proess perspetive T1 T2 T3 T4 data perspetive D1 D2 D3 D4 Figure 4: An example illustrating the proess, data, and resoure perspetives. onditional routing, and iteration. In fat, as shown in [1], at least 20 routing patterns an be identified. Also note that the sequene shown in Figure 4 is exeuted for any ase, i.e., the proess may be instantiated multiple times. If Figure 4 would model the reviewing proess for a onferene with steps T1 : register paper, T2 : send to reviewers, T3 : ollet reviews and T4 : deide and inform author, then these four tasks would be exeuted for all papers. We assume that the proess perspetive desribes the life-yle of a ase, and therefore we limit ourselves to ase-driven proesses. Approving loans, proessing insurane laims, billing, proessing tax delarations, handling traffi violations and mortgaging, are other examples of ase-driven proesses. While the proess perspetive is onerned with the ordering of tasks, the resoure perspetive fouses on the resoures needed to exeute these tasks. Resoures may be human (e.g. employee) or non-human (e.g. devie, software, hardware). Non-human resoures may be onsumable (e.g. energy) or not (e.g. a tool). In this paper, we will fous on human resoures also referred to as workers or users. To avoid the diret mapping of resoures to tasks, resoures are grouped into resoure lasses. An example of a resoure lass is a role, i.e., a group of workers having similar qualifiations. Another example of a resoure lass is an organizational unit (e.g. a department, a team, or a branh). Resoures lasses an be linked to tasks. For example, in Figure 4 tasks T1, T2, andt3 an be exeuted by any of the three workers having role R1 and T4 an only be exeuted by the worker having role R2. A worker may exeute multiple tasks and the same task may be exeuted by multiple workers, however for simpliity we assume that a worker annot work on two tasks at the same time and that for eah ase eah of the orresponding tasks is exeuted by a single resoure. For example, one resoure may exeute T1 for one ase while another resoure exeutes the same task for the next ase. Note that resoure lasses may overlap, e.g. Figure 4 ould be hanged suh that the fourth worker also has role R1 in addition to role R2. Tasks may produe or require information/data. The data perspetive is onerned with the data required to proess the ase. Figure 4 shows four data elements: D1, D2, D3 and D4. These data elements may refer to strutured (e.g. the name of a ustomer) or unstrutured (e.g. a Word doument) data. There are many ways to desribe data using tehniques ranging from UML lass diagrams to XML shemas. In a PAIS data elements may be linked to tasks as shown in Figure 4. T1 produes data element D1. This data element is again used by T3. Besides D1, task T3 also uses D3 and produes data element D4. T2 uses D2 and T4 uses D4. Note that D2 and D3 are external date elements, i.e., they are not produed by the proess shown in Figure 4 but need to be supplied by other soures (e.g. another proess or another organization). The task perspetive is not shown expliitly in Figure 4. This perspetive desribes the ontent of T1, T2, T3 and T4, i.e., a desription of the atual work done in eah of the steps. Although providing only a simplisti view of ase-driven proesses, Figure 4 niely illustrates the perspetives. In addition to these lassial perspetives of PAIS, it is important for the purpose of esalation to differentiate two more perspetives. First, the ontext perspetive desribes the environment for whih a proess model has been designed. The initial example inluded two ontexts: 7

storm and non-storm season. A hange in the ontext an motivate an esalation. Potential problems with deadlines an often be antiipated based on experienes and a sound understanding of how a speifi ontext orrelates with proess performane riteria. For example, it is known that a predited storm will ause a problem in a few hours or days. In suh a senario, it would be too reative to wait until the first deadline-related problems our. Seond, the performane perspetive inludes all relevant evaluation riteria for a ertain proess. Esalation may be required even if there are no problems with data, resoures or tasks, but instead the performane data has hanged, e.g. a ustomer wants delivery in two days instead of four days. On the other side, modifiations in the performane perspetive an be one esalation mehanism, e.g. the finish date for make-to-stok prodution orders an be extended if they ompete with problemati make-to-order proesses. The following disussions, however, will be foused on the lassial perspetives, i.e., data, resoure, task and proess. Before we start disussing the 3D approah to esalation, we would like to point out that Figure 4 shows a number of onstraints: All four tasks need to be exeuted for any ase. Task T2 an only be exeuted after T1 ompletes, et. Task T1 an only be exeuted by someone with role R1, et. Task T2 an only be exeuted if D2 is available, et. Typially, these onstraints are onsidered to be hard onstraints. In general, PAISs suh as WFM systems fous on supporting suh onstraints. However, under some irumstanes it may be useful to onsider some onstraints as soft onstraints, e.g. for some ases there may be good reasons to skip task T2, exeute T3 without D3, or allow someone with role R1 to exeute task T4. 3 Esalations: The 3D approah A PAIS deals with ase-driven proesses, i.e., ases are handled following the life-yle in the proess perspetive and using the data and resoures speified in the other perspetives. One of the pitfalls is that PAISs are typially onfigured on the basis of idealized models. As a result these systems have problems dealing with situations that do not onform with the normal flow. Often the term exeption handling is used to refer to the things that need to be done when there are deviations between what is planned and what is atually happening. Although many authors have published interesting results on exeption handling [5, 6, 10, 12, 13, 14, 19, 21, 25, 29] (f. Setion 7), today s PAISs still have problems dealing with exeptions. In this paper, we fous on a partiular kind of exeption: for one or more ases the organization annot meet its deadlines. We assume that eah ase has a deadline D. If some ases do not have a deadline, we simply set the deadline to infinity, i.e., D =. The deadline may be absolute or relative to the time the ase started. However, the result is an absolute timestamp. Similarly, tasks may have deadlines, e.g. D t is the deadline of task t for ase. 2 The ompletion time of a ase, denoted C, is the atual time the ase was ompleted. Similarly, C t is the ompletion time of task t for ase. Preferably, C D and C t D t for all ases and all tasks t. Aase is late if C >D and a task t is late for ase if C t >D. t Note that C and C t are only known after the ompletion of the ase or task. However, it is often possible to predit the ompletion time of a ase or task. For a given ase, let P be the predited ompletion time of and P t be the predited ompletion time of task t for ase. Case is predited to be late if P >D and a task t is predited to be late for ase if P t >D. t Setion 3.1 disusses how P and P t ould be omputed. 2 Note that the notation assumes that there are no loops, i.e., tasks annot be exeuted multiple times for the same ase. This an be solved in several was. For example, we an assume D t to be the deadline for the last iteration of t for. 8

Ifaaseortaskislateorpreditedtobelate,itmaybewiseorevenneessarytotakespeial measures. These measures are alled esalations. Consider for example the reviewing proess for a onferene. If lose to the deadline for informing the authors still many reviews are missing, then the program hairs may deide to ask additional reviewers, send reminders or base the deision on fewer reviews. To date, suh esalations are typially not supported by PAISs, i.e., workers have to work around the system to deal with esalations and are not supported at all. There may be several reasons for esalations, e.g. there may be seasonal influenes in the number of ases (e.g. in summer there will be more insurane laims related to fire), the number of available resoures may vary (e.g. during the Christmas holidays there are not enough workers to ope with the workload), or there may be some kind of emergeny (e.g. a atastrophe or a new law generating more work). These are only few examples of irumstanes that may ause ases or tasks to be late. Note that many organizations depend on other organizations (e.g. for information). As a result, a problem in one organization an ause esalations in other organizations. multi-ase, single-task single-ase, multi-task 1 2 3 4 T1 T2 T3 T4 T1 T2 T3 T4 T1 T2 T3 T4 T1 T2 T3 T4 Horizontal sope: Whih part of the proess is affeted by the esalation? Vertial sope: Whih ases are affeted by the esalation? Figure 5: Sope of esalations. Figure 5 shows that the sope of an esalation may vary in at least two dimensions. First of all, an esalation may involve a single ase or multiple ases. An example of single-ase esalation is a permit request that must be proessed within two weeks and a ouple of days before the deadline, it is found that there are still several tasks to be done, or worst, that the deadline has expired. On the other extreme, there is the multi-ase esalation that involves all ases of a given proess. An example is the introdution of a new law that fores organizations to handle ases within a ertain time-frame. Note that multi-ase esalation may also refer to seleted ases in a given proess, e.g., a ases involving a laim of more that one million euros. Seond, the sope of an esalation may refer to a single task or to multiple tasks (i.e. a portion of the proess). A single-task esalation fouses on a partiular task in the proess. For example, in the reviewing proess of a onferene a esalation may result in the skipping of a review step but the author will always be informed, i.e., the esalation is limited to the review task. On the other hand, an example of a multi-task esalation is that where the manager of the department is on holidays and he is responsible for a number of tasks while no other resoures are allowed to exeute these tasks. As a result some tasks are late and work is piling up. An esalation mehanism may be to delegate these tasks to another person. The telelaims ase desribed in the introdution proposes a multi-ase esalation. A severe storm 9

does not lead to the esalation of a single ase but of an entire proess. Note that in the introdution four possible esalation levels were mentioned. These refer to the whole proess. However, in the bak offie there is also a single-ase esalation: ases that are delayed more than one hour get a rapid assessment. The multi-ase esalation in the telelaims example is a single-task esalation senario sine it fouses on the initial lodgment task of the laim handling proess. The single-ase esalation (rapid assessment for delayed ases) is also an example of a single-task esalation. To support esalation resulting from ases and/or tasks that are too late (or are predited to be late), we propose the 3D approah: Detet, Deide, anddo. First, one needs to detet that there is a problem, i.e., that a ase or task is (expeted to be) late. Then one needs to make a deision on what to do (i.e., deide whih esalation to apply). Finally one needs to exeute the esalation that was seleted. There are some similarities between the 3D approah and the well-known ECA (Event-Condition-Ation) rules. In fat, ECA rules have often been proposed to deal with workflow exeptions [5, 6, 10, 12, 13, 14, 21, 25, 29]. However, the proposed 3D approah differs from the ECA rules approah in several ways. First of all, deteting whether there will be delayed ases is quite different from athing an event and evaluating a ondition. Seond, the deision proess may involve human judgment. Finally, as will be shown in the sequel, we onsider a speial kind of ations: mode swithing. The various parts of a proess (inluding all perspetives) may be in different modes. In ase of an esalation, the proess swithes from one mode to another. We refer to this mode as an esalation mode. Just like the US Homeland Seurity Advisory System with its alert levels green (low), blue (guarded), yellow (elevated), orange (high), and red (extreme), we envision proesses operating at various levels. Instead of a olor ode we use numbers where 0 is the normal mode of operation and higher numbers indiate modes orresponding to esalation. Consider for example task T 3 in Figure 4. This task should be exeuted by a person with role R1 and requires data elements D1 andd3. At level 0 the PAIS enfores that T 1 is indeed exeuted by a person having role R1 and that it an only start if both data elements D1 andd3 are available. Suppose that for a ase, task T 3 is not exeuted before its deadline. This is deteted and the mode is set to 1. In this mode, task T 3 may be exeuted, even if D3 is unavailable. If this does not help, i.e., after some time T 3is still not exeuted for ase, the mode is set to 2. In mode 2, T 3 is offered to all people having role R2 where R2 inludes role R1. If this does not help, the mode is set to 3. In mode 2, T 3issimply skipped. These examples illustrate the differenes between ECA rules and the 3D approah. Note that in the telelaims ase four levels of esalation were identified. These orrespond to esalation modes. Also note that an esalation mode has a ertain sope (f. Figure 5). A proess may swith from one esalation mode to another for a single ase or multiple ases and for an individual task or multiple tasks. In the remainder of this setion we disuss the three steps Detet, Deide, anddo in more detail. 3.1 Detet The goal of deadline-based esalations is to avoid ases or tasks that are too late, i.e. C >D or C t >D t, and if they happen to be too late to take retifiation measures. We onsider detetion at the level of a single ase and at the level of the proess or even the whole organization. As indiated, deteting also inludes monitoring the relevant ontext. However, this type of monitoring is outside the sope of this paper. Let us first onsider detetion at the level of a single ase. There are four possible situations that result in a deadline-based esalation. C >D or time()> D, i.e. the ase is ompleted too late. (Note that we use time() to denote the urrent time.) In this situation there is not muh that an be done, i.e. the ase is too late anyway and only retifiation measures to try and ompensate for this are possible. C t >D t or time()> D t, i.e. task t is exeuted too late. In this situation, the ase is delayed 10

with respet to task t. If t is not at the end of the proess, this may be a signal to try and speed-up the ase. For example, if t was not exeuted yet, it may be skipped. P >D, i.e. the ase is predited to omplete too late and an esalation may irumvent this. P t >D t, i.e. it is predited that task t is exeuted too late, and this may trigger some esalation. To be able to detet this we need to have onrete values for D, D t, C, C t, P,andP t. The first four values are easy to measure. The latter two estimates (P and P t ) may be alulated in various ways. Some examples: Based on histori information one an alulate the average time needed to exeute a task (waiting time + proessing time). By alulating the longest path from the urrent state of a ase to the desired state (i.e. ompletion of the whole ase or a speifi task), we get a rough estimate for the time needed to reah that state. The predition engine of Staffware [28] uses suh an approah to estimate the ompletion time of ases. A major drawbak of this type of approahes is that they do not take into aount the atual workload, i.e. if there are many ases in the pipeline, then preditions based on historial data of flow times may be too optimisti. Instead of using a stati alulation based on the longest path from the urrent state of a ase to the desired state, it is also possible to use more sophistiated tehniques suh as queueing analysis or simulation. This is more ompliated but the results will be more aurate. Most approahes based on queueing analysis or simulation fous on averages, i.e. the normal behavior of the flow in steady-state. However, these tehniques an also take the urrent state of the proess (i.e. all ases) into aount and do a transient analysis. For example, the urrent state of the proess an be used to initialize a simulation model. This approah has been suessfully applied using the WFM system COSA, the BPM tool Protos, and the simulation tool ExSpet [24]. It results in more aurate preditions for P and P t but is more involved. Fators resulting in delayed ases often do not delay a single ase but multiple ases at the same time. Therefore, it may be more suitable to onsider multiple ases at the same time for detetion purposes. There are two ways to ahieve this: (1) aggregate the results for individual ases (e.g. monitor the value of max((p D ), 0)); or (2) fous on monitoring the utilization of resoures relative to their apaity. The latter approah is attrative beause it is relatively simple (if people are too busy then esalate). It relies on the priniple that high utilization levels usually indiate that there is a lot of queueing and therefore this an serve as a trigger for resoure-based esalations (e.g. inreasing the number of staff). It must be noted though that this approah may not detet the need for esalation in some situations. Speifially, if ases are waiting exessively long for external data, then it may happen that the utilization is low and yet there is a need to esalate in order to prevent deadline violations. Just like the flow time of a ase, the expeted utilization an be predited using a wide range of tehniques. For example, based on the routing probabilities and the number of ases arriving one an alulate the number of times eah task needs to be exeuted. This ombined with histori information about the average proessing time an be used to estimate future utilization levels. Also more advaned tehniques are possible, e.g. a simulation based on the urrent state [24]. In Setion 2 we disussed a number of perspetives on workflows, inluding the ontext perspetive and the performane perspetive. In the general ase, predition tehniques need to take these two perspetives into aount. In the telelaims senario for example, the deision to do rapid lodgement is not based on the timing of a single ase but rather on a human interpretation of the weather foreast, whih is part of the ontext perspetive. Similarly, hanging performane targets an influene the ability to meet deadlines. 11

3.2 Deide Through the detetion mehanisms just desribed, the ases and/or tasks that are (predited to be) too late are identified. The detetion step is followed by a deision step were the esalation measure is seleted. There are three possible deision mehanisms: manual, automated, and semi-automated. For manual deision making, the fat that a ase or task is (predited to be) too late is forwarded to a human ator that deides on the ations that need to be taken. The ator an hoose from a wide range of ations as will be disussed in Setion 4 (e.g. skipping a delayed task). The advantage of human judgment is that a human an take into aount fuzzy information ranging from the weather foreast to gossip. Experiened workers an make exellent deisions and selet the right level of esalation. A drawbak is that the human ator may be unavailable or too busy. This way important deisions may be postponed. Note that for manual deision making it is important to forward the esalation detetion to the proper ators. Automati deision making results in esalations without any human involvement. Based on a set of rules, the right esalation is seleted. For example, if the head of the department does not onfirm within two weeks, the ase is routed to her replaement. Note that automati deision making requires a rule language, e.g. some variant of RuleML [4]. The advantage of automated deision making is that there are no delays and using the right set of rules the quality of the deision may be high and onsistent. The drawbak is that rules typially have problems interpreting the irumstanes of the esalation, e.g. is the delayed ase the tip of the ieberg or an isolated ase. To ombine the best of both worlds, semi-automated deision making may be used, e.g. if a ase or task is (predited to be) too late, first some automati deisions are made. If these esalations do not help and the situation gets worse, a human may get involved. It is also possible to do it the other way around, i.e. if a ase or task is (predited to be) too late, first a human ator is notified. If this ator does not respond in time, an automated rule is applied. 3.3 Do The last step in the esalation proess (i.e. the Do step ) is the atual esalation. In the next setion, we desribe possible esalation mehanisms. The intent is not to be omplete but rather to provide a framework that proess designers an apply to speifi senarios. 4 Esalation mehanisms An esalation is a deviation from a normal ourse of ation. In the ase of a priori esalation, an esalation mehanism implements a tradeoff between on the one hand the amount of time required to omplete a task, a ase, or a set of ases, and on the other hand the level of servie or the resoure utilization (e.g. an esalation may result in servie degradation or resoure redeployment). Different esalation mehanisms strike different tradeoffs. Aordingly, we adopt a model of esalation in whih eah task has an esalation mode and in eah mode the task may behave differently with respet to the proess perspetive, the data perspetive and the resoure perspetive. In the remainder of this setion, we examine some esalation mehanisms with respet to these perspetives. For eah mehanism, we provide an example and disuss its sope (i.e. single-ase and/or multi-ase), ost and tradeoffs. Though we will disuss in the following esalation strategies for eah perspetive separately, it is important to note that there are two types of interrelationships between the perspetives in terms of workflow esalation. First, a problem in one perspetive an trigger an esalation in another perspetive as a ompensation mehanism. For example, missing information in a lodged laim (e.g. no reports from witnesses of a ar aident), may require a speialist for the laim assessment. Seond, esalation mehanisms in two different perspetives an be alternatives. In our initial example, rapid 12

lodgement (proess perspetive) and the utilization of additional staff members (resoure perspetive) ould also be seen as alternatives. 4.1 Proess Perspetive 4.1.1 Alternative path seletion Desription When defining a proess it is possible to speify that ertain paths are onditional upon the potential violation of a deadline. In other words, there are different alternatives for performing a part of the proess: one orresponding to the normal ourse, and the others orresponding to different esalation modes striking different ost tradeoffs. Two partiular forms of this mehanism are: (i) alternative task seletion, where a hoie is made between exeuting a given task or exeuting an alternative (less desirable but faster) task; and (ii) task skipping (Figure 6) where a hoie is made between exeuting a task (or set of tasks) and doing nothing (i.e. the task(s) in question is/are optional). Example In the telelaims proess, the laim lodgment task is replaed by an alternative rapid laim lodgment task. This is an example of alternative task seletion. Sope This mehanism applies to both single-ase and multi-ase esalation. Cost and tradeoffs This mehanism aims at speeding up the proess exeution in exhange of a degraded level of servie (i.e. lower quality of servie) or to push some work to later stages of a proess (or to other proesses) in order to meet a deadline. A ost may be assigned to this mehanism to reflet the loss in quality of servie or the impat that it may have at later stages of the proess. R1 R2 R1 R2 T1 T2 T3 T4 T1 T3 T4 esalation D1 D2 D3 D4 D1 D2 D3 D4 Figure 6: An example of an esalation using task skipping. 4.1.2 Esalation sub-proess Desription When it is predited that a deadline will be violated, or when the deadline is atually violated, a sub-proess is spawned off to perform ations speifially related to the deadline violation, suh as notifying the appropriate stakeholders, re-negotiating a new deadline, or performing ompensation ations and anelling the ase. During the exeution of this sub-proess, the rest of the proess may be suspended. Example When a deadline violation ours, a proedure is spawned to notify the ustomer. The ustomer is offered the hoie to have the proess stopped and be reimbursed, or to ontinue with a new deadline (whih an be seen as a modifiation in the performane perspetive). Sope This is typially a single-ase esalation mehanism, however, one an also imagine that a sub-proess is spawned off to deal with multiple ases. 13

Cost and tradeoffs sub-proess. The osts of this mehanism are dependent on the nature of the esalation 4.1.3 Task pre-dispathing Desription Under some irumstanes, it is possible to start preparing for the exeution of a task prior to ompletion of a previous task. This idea an be found in modern omputer arhitetures, where instrutions may be started before ompletion or preeding instrutions in order to exploit otherwise idle resoures. Two forms of task pre-dispathing an be identified: pipelining and preditive branhing. In the pipelining mehanism, a task B that immediately follows another task A is enabled (i.e. plaed in the worklist) as soon as the exeution of A starts (i.e. after A has been piked from the worklist and the preparation phase for A has been ompleted). However, B is flagged as predispathed, in suh a way that whenever a resoure piks this task from the worklist, it will not be allowed to proeed up to ompletion until A has ompleted, thereby ensuring that the ontrol-flow dependeny (and any underlying data dependeny) is preserved. Preditive branhing applies when a deision point D that immediately follows a task C is reahed. The workflow system then attempts to guess whih branh will be taken (e.g. based on past history), and pre-dispathes the first task in the hosen branh. After ompletion of C, the branhing ondition is evaluated, leading to two possible senarios: (i) the previously hosen branh is the one that should be taken, in whih ase the branh is allowed to proeed; or (ii) a different branh is taken, in whih ase the pre-dispathed task needs to be retrated (i.e. the task is withdrawn from the worklist, and if a resoure has already piked it, the resoure is notified and any preparation ations are undone). A variant of preditive branhing is prediation 3, whereby all the branhes are taken in parallel, rather than a guess being made for one of them. In this ase, the first task of eah branh is pre-dispathed, and some of these tasks are retrated when the branhing ondition is evaluated. Example Before a lean-up team is authorized to enter an area it may be neessary to wait for approval from an inspetion team, however, the preparation of the lean-up (e.g. setting up the lean-up equipment) ould be pre-dispathed after a ertain point in the inspetion proess. Sope This mehanism applies to both single-ase and multi-ase esalation. The mehanism is only appliable when the tasks in the proess have an expliitly defined preparation phase and in the ase of preditive branhing and prediation, the resoures must be able to undo any preparation ations. Cost and tradeoffs The ost of this mehanism is determined by two fators: (i) heavier resoure utilization as resoures prepare tasks and then hold until they an start the atual exeution; and (ii) in the ase of failed preditive branhing, the ost of undoing the preparation ations. 4.1.4 Overlapping Desription Overlapping an be applied for workflow esalation in the ase of large bathes and involves two sequential ativities. The main idea behind overlapping is that two ativities an be aelerated, if they are parallelized. This goes further than pipelining as the following task will be started (not just prepared) while the preeding is still proessing. 3 This tehnique has parallels with the one used in the Intel Itanium proessor (http://www.devx.om/intel/ Artile/20218/2217). 14

Example A speialist works on 10 laims in one bath, before he forwards the entire bath for further proessing to the next resoure. Overlapping would mean, that he forwards smaller bathes, e.g. in the size of two eah. Sope This esalation mehanism is related to a single ase esalation. Cost and tradeoffs The benefit of an aelerated proessing of two sequential ativities has to be ompared with the inreasing osts related to inreased oordination efforts between these two ativities. 4.1.5 Prioritization Desription Higher priorities are given to ertain tasks or ases, letting them overtake other ases in the onsumption of resoures. Example If there are twenty ustomers with orders for a partiular servie and it is predited that half of them will result in deadline violation, the potentially late ases are given higher priority. Sope This is a multi-ase mehanism. Cost and tradeoffs Giving higher priorities to some tasks or ases neessarily means lowering the priorities of others. This may result in deadline violations for ertain tasks or ases that would not have ourred had the priorities been left unhanged. Apart from this, and the usual overhead on the proess exeution environment of deteting, deiding and triggering the esalation proedure, the ost of this mehanism is neutral. This mehanism may be attrative in ases where being late by a small amount of time or being late by a larger amount of time have more or less the same impliations. (Note that often servie levels are defined as the perentage of ases on time.) For example, if there are several ases running late, one may hoose to fous on some of them in order to meet their deadlines, and neglet the others, even if this makes these other ases violate the deadline by more time than they would otherwise have done. 4.2 Resoure Perspetive 4.2.1 Resoure redeployment Desription The idea of resoure redeployment is to inrease the apaity of the resoures assoiated to ases or tasks that are running late as illustrated in Figure 7. Resoure redeployment an take many forms inluding: adding more resoures (e.g. moving people between departments), extending the sope of the roles assoiated with a task (e.g. allow people with a lower role to exeute the task,), inreasing the apaity per resoure (e.g. overtime) or hanging the alloation of tasks to ahieve load balaning. Therefore the Resoure redeployment mehanism an be seen as a olletion of mehanisms aiming at ahieving an inrease in resoure apaity. Example In the telelaims proess, an esalation immediately leads to overtime being requested from the all enter operators. If this is not enough, employees from the sales and servie departments are redeployed to the telelaims proess, and if neessary, asual workfore is alled upon. Sope This is a multi-ase esalation mehanism. 15

R1 R2 R1 R2 T1 T2 T3 T4 T1 T2 T3 T4 esalation D1 D2 D3 D4 D1 D2 D3 D4 Figure 7: An example of esalation using resoure redeployment. Cost and tradeoffs Inreased osts inluding variable osts (overtime and hiring additional workfore) and fixed osts (need to train people to be able to be redeployed or to train a pool of potential asual workers). Furthermore, the average performane per resoure may be negatively impated as in the telelaims senario. Besides inreased osts there is the risk of lower quality levels. If resoures start doing tasks outside of their normal routine or expertise area, the impat on quality may be negative (e.g., more errors or a less professional servie to the ustomer). 4.2.2 Bathing Desription In some irumstanes it may be possible to group together tasks that would be more effiiently treated as a bath assigned to a single resoure. This approah an be effetive in reduing the number of deadline violations when the tasks being bathed are predited to have deadline violations. For example, in loation-based bathing, tasks from several proess instanes are lustered based on their assoiated loation and the loation of the available resoures. Task instanes lose to eah other in spae are exeuted in bath by a resoure, before the resoure moves to another loation. Example In the insurane laim handling proess, when an event takes plaes at a given loation (e.g. a bushfire), all on-site assessment tasks related this event are bathed and assigned to one or a group of dediated assessors. Sope This is a multi-ase esalation mehanism. Cost and tradeoffs Bathing aelerates ativities by eliminating setup times for individual ativities. Costs an our for the efforts related to bathing ativities. 4.2.3 Splitting Desription Splitting is the opposite of bathing and refers to the ase, in whih finalizing the work for an entire bath of ases would take too long. In these ases, it might be possible to split the bath into smaller bathes, whih are worked on in parallel. Example In a typial laims proess, legal experts are involved as speialist. However, suh an expert an easily beome the bottlenek. Instead of one full-time legal expert, it might be useful in some ase to have two (or more) experts working part-time and in parallel. Sope This esalation mehanism onverts a single ase esalation into multi-ase. 16

Cost and tradeoffs This approah redues the proessing time by splitting a bath over a number of resoures, who work in parallel. This benefit has to be ompared with the additional setup time/osts at eah resoure, possible additional transportation osts and the efforts related to onsolidating the ases again to one bath for the next ativity. 4.3 Data perspetive 4.3.1 Deferred data gathering Desription The gathering of ertain data is postponed until the point in the proess where it is atually needed. In other words, data items that would normally be produed by a given task are not produed when this task ompletes, but instead, they are gathered by the (first) task that needs them. Example esalation. In the telelaims senario, a simplified version of the laim reation form is used during Sope Applies both to single and multi-ase esalation. Cost and tradeoffs Deferred data gathering usually results in work being pushed to a later point in the proess. In the ase of the telelaims proess, when the simplified version of the laim reation form is used, some relevant data is not gathered. Some of these data is not neessary in some ases, and when it does beome neessary, a all is made by the relevant laim handling department to the ustomer. In the ase of laims where an on-site assessment needs to be made, the missing data may be gathered by the assessor. Note that data degradation an be used in onjuntion with alternative path seletion. For example, in the telelaims senario an alternative version of the lodge laim task is assoiated to the simplified version of the laim reation form. 4.3.2 Data degradation Desription Tasks are allowed to be exeuted with less or different data. For example, if a doument is not available, the deision an be taken without it. It is also possible to look for other soures of less reliable or more ostly data. Example During a paper review proess, the aeptane/rejetion deision is usually taken on the basis of three reviews. However, if one of the reviews is missing by a given deadline, the deision may be taken with only two reviews. Sope Applies both to single and multi-ase esalation. Cost and tradeoffs The strategy results in loss of quality of servie, and in ertain ases, it may result in some work being pushed to a later step in the proess. 5 Simulation study: Telelaims proessing in the storm season Let us now return to the telelaims proess shown in Figure 1. To illustrate the effet of different esalations, we take this proess and evaluate different senarios using simulation. Note that some of these senarios desribe the way the Australian insurane ompany is esalating during the storm season. Other senarios are merely used to provide a better overage of the esalation mehanisms disussed in the previous setion. 17

R1 R2 R1 R2 T1 T2 T3 T4 T1 T2 T3 T4 esalation D1 D2 D3 D4 D1 D2 D3 D4 D5 Figure 8: An example of an esalation in the data perspetive. For our simulation study we use CPN Tools [7] whih is based on Colored Petri Nets [17] as a modeling and analysis language. The reasons for using CPN Tools are its expressiveness (it is easy to model all esalation mehanisms), its theoretial basis (allowing for different types of analysis), and its simulation speed (lose to a lassial programming language). Let us first simulate the proess shown in Figure 1. We assume the arrival proess to be Poisson (i.e., negative exponential interarrival times). Sine the distribution of the all volume and number of resoures over the day was not given, we assumed these to be onstant over an 8 hour period per day. All ativities (i.e., the funtions in the EPC diagram) are assumed to have a negative exponential servie time. The average servie times are indiated in the diagram and so are the routing probabilities. For example, 10% of the inoming laims stop after the first step in the proess. The numbers of resoures are also shown in Figure 1: there are 90 all enter agents in eah all enter and 150 laims handlers in the bak offie. Note that the same resoure will exeute all steps in the proess for a given laim in one of the all enters or the bak offie, i.e., transfer of work only takes plae in between a all enter and the bak offie. Figure 9: A sreenshot of CPN showing the top-level model and the Brisbane all enter. 18

Figure 9 shows a sreenshot of the top-level model and the Brisbane all enter in CPN Tools while simulating the model. Figure 10 shows the CPN model of the bak offie. A detailed desription of the CPN models is outside of the sope of this paper. However, a superfiial omparison of Figure 1 and the figures 9 and 10 will assist in obtaining a basi understanding of the CPN models. laim is registered In Case input (); output (ran); ation (round(uniform(0.0,100.0))); if ran<85 then 1 (,r) else empty determine likelihood of laim @+delay(20) if ran>=85 then 1 (,r) else empty r SC insudered ould be liable CR SC insured ould not be liable CR (,r) ((i,l,t),r) input (); output (ran); ation (round(uniform(0.0,100.0))); assess laim @+delay(660) end1 input (t); output (); ation (measure("flow time",intinf.toint(time())-t); measure("flow time not insured",intinf.toint(time())-t)); if ran>=80 then 1 (,r) else empty if ran<80 then 1 (,r) else empty laim has been aepted CR (,r) laim has been rejeted ((i,l,t),r) CR r to payment Case AND-split (,r) to advie Case end2 r input (t); output (); ation (measure("flow time",intinf.toint(time())-t); measure("flow time rejetion",intinf.toint(time())-t)); 150 "Claims handler" resoures Resoure @+delay(120) (,r) initiate payment mutex CR (,r) advise laimant on reimbursement @+delay(180) payment has been initiated Case (,r) laimant has been advied Case (,r) lose laim @+delay(30) [(i,l,t)=] laim has been losed Case end3 input (t); output (); ation (measure("flow time",intinf.toint(time())-t); measure("flow time suess",intinf.toint(time())-t)); r Figure 10: The CPN model of the bak offie. For alulating onfidene intervals we assume a start run of 2 days and 10 subruns of 1 day (8 hours). The simulation shows that the average flow time is 1271 seonds, i.e., about 21 minutes. The variane of the flow time is 928266 (with a 95% onfidene interval of [911853,944679]), i.e., the standard deviation is approximately 963. This implies that there are onsiderable differenes between individual flow times. The average flow time of suessful ases is 1667 [1660,1673]. The utilization of the all enter agents is 0.26 and utilization of the laims handlers is 0.60. The proess shown in Figure 1 annot deal with the inoming laims in the storm season where the average number of laims per week goes up from 2*9000=18000 to 2*20000=40000. The utilization of the laims handlers would be more than 1.0 indiating that it is impossible to ope with the flow of work. Figure 2 shows the way the insurane ompany deals with 40000 per week. (Note that the model ontains both a single-ase and a multi-ase esalation.) The hanges are the addition of resoures to both the all enters and the bak offie (i.e., the Resoure redeployment mehanism), the rapid lodging (i.e., the Alternative path seletion mehanism), and rapid laim assessment (also 19

the Alternative path seletion mehanism but now applied as a single-ase esalation). As a result of these esalations, the organization an ope with the inoming laims and the average flow time is 937 seonds [932,943]. 6 Another simulation study: Reviewing journal papers The telelaims simulation study used the Resoure redeployment mehanism and Alternative path seletion mehanism to esalate. In the study no esalation mehanisms orresponding to the data perspetive were used. Moreover, the study was primarily a multi-ase esalation (during a storm the whole proess is esalated). Therefore, we provide another simulation study fousing on single-ase esalation and also inluding esalation mehanisms orresponding the data perspetive. In this setion, we onsider the proess of reviewing proess for a journal. Eah paper submission to the journal is registered by the editorial offier (this takes on average 2 hours). The editor of the journal will ask three reviewers to review eah submission. The request of the editor to the reviewer will generate a response of the reviewer who either aepts or delines the invitation. If the reviewer aepts to review the paper, the editorial offier wil send it to him/her. If the reviewer delines the invitation, the editor will invite another reviewer. This proess is repeated until for eah paper three people have aepted the invitation. A reviewer that aepts the invitation, will review the paper and propose to aept it or rejet it the paper. (For simpliity, we assume that the outome of any review is aept or rejet.) The editor will make a deision when all three review reports have been returned. As long as a review is missing, the deision is postponed. If two reviewers propose to aept, the editor will aept the paper. Otherwise, the paper is rejeted. The editorial offier will inform the author of the result (this takes on average 2 hours of working time). Finally, the ase is losed. For the simulation, we assume that on average 4 new papers arrive per week. The arrival proess is Poisson (i.e., negative exponential interarrival times with a mean of 7/4=1.75 days). The task exeution times are also sampled from a negative exponential distribution. Handling the response of a reviewer takes on average 1 hour of working time from the editorial offier. Reviewers on average reply to an invitation within one week (negative exponential distribution with mean of 1 week) and 70% aepts to review the paper. This implies that for the other 30% the editor appoints another reviewer, et. The average reviewing time is 6 weeks after aepting the invitation and sending the paper. On average, 60% of papers are rejeted by the reviewer. Sine the editor follows the reviewers, on average only 40% is aepted. The editorial offier is assumed to be ontinuously available. However, the editor only heks on the papers at the end of every month (every four weeks to be preise). At that point in time, he an deide to appoint new reviewers and aept/rejet papers. Figure 11 shows the top level of the CPN model. Note that the model has four subproesses: gen papers (for arrival of new papers), hek papers (the handling of the papers by the editor at the end of eah month), reviewer ontat (the ations related to the management of reviewer responses), and reviewers (an external proess modeling the reviewer base). In this paper, we will not show or desribe these subproesses in detail. The textual desription given above should resolve most ambiguities. For our simulation experiments we use a start run (to avoid start-up effets) and 10 subruns. Eah subrun takes one year (52 weeks) and the subruns are used to alulate 95% onfidene intervals. For the base senario (i.e., without esalation) the average flow time is 131 days (with a 95% onfidene interval of [129,133]), i.e., approximately 19 weeks. The average variane of the flow time is 2733 (with a 95% onfidene interval of [2587,2880]). This implies that frequently the review proess takes half a year or longer. Taking this base senario (without any form of esalation) as a point of departure, we now investigate the effets of various esalation mehanisms: 20

results submitted paper CIResults gen_papers Case measurement_system [(i,l,t)=] register submission @+delay(2*hour) r 1 "editorial offier" editoral offier Resoure measurement_system 1 "Editor" ps (i,t,0,0,0,0)::ps editor hek_papers request Resoure hek_papers [] ID papers aept_r ative ase Papers ID Case aept ID rejet ID r r reviewer_ontat rejet_r ID Reviewers [(i,l,t)=] i [(i,l,t)=] i reviewer_ontat paper ID Reviewers input (t); output (); ation aept @+delay(2*hour) @+delay(2*hour) (measure("flow time aept", IntInf.toInt(time())-t)); rejet input (t); output (); ation (measure("flow time rejet", IntInf.toInt(time())-t)); aept_p ID rejet_p ID ready [(i,l,t)=] Case lose input (t); ase output (); ation (measure("flow time",intinf.toint(time())-t)); Figure 11: The top-level CPN model of the reviewing proess. Esalation 1 For the first esalation, we invite an additional reviewer if the reviewing proess takes more than one month. This means that in the end 4 people may review the same paper, but after three reviews arrive a deision is made. If there happen to be 2 aepts and 2 rejets, the paper will still be aepted. Clearly, this esalation uses the Resoure redeployment mehanism desribed in Setion 4. Esalation 2 The seond esalation is similar to the first one but now up to two reviewers may be added if there is no onlusion after one month. Esalation 3 Again the Resoure redeployment mehanism is used to allow one additional reviewer. However, now, if needed, the additional reviewer is only invited after two months. Esalation 4 The fourth esalation is a ombination of the previous two: Potentially up to two additional reviewers are invited after two months. Esalation 5 Now we fous on the invitation of reviewers. If after one month there are still reviewers that have to aept or deline the invitation, we invite one additional reviewer. Esalation 6 Again we fous on the invitation of reviewers. If after one month there are still reviewers that have to aept or deline the invitation, we invite up to two additional reviewers. This means that in the end 5 people may review the same paper. Esalation 7 We now apply the Data degradation mehanism, i.e., make deisions with less information. Note that if a paper gets two positive reviews, it is ertain that it will get aepted. Therefore, two positive reviews or two positive reviews will result in a final deision and there is no need to wait for the third review. 21

Esalation 8 Esalation 7 may disard the third review even if the third reviewer only takes a bit longer than the other two. Therefore, we refine the Data degradation mehanism with a temporal omponent. Now two positive reviews or two negative reviews may trigger a final deision, but only after one month has passed. Esalation 9 Combines Esalation 1 and Esalation 7, i.e., a ombination of the Resoure redeployment mehanism and the Data degradation mehanismisused. Esalation 10 Combines Esalation 1 and Esalation 8, i.e., as in the previous esalation but now with the temporal omponent. For eah esalation we onduted a simulation experiment using CPN Tools. 4 shown in figures 12 and 13. The results are 140 130 120 Average flow time 110 100 90 80 no esalation esalation 1 esalation 2 esalation 3 esalation 4 esalation 5 esalation 6 esalation 7 esalation 8 esalation 9 esalation 10 Figure 12: The average flow time and 0.95 onfidene intervals for the base senario and the 10 esalations. Figure 12 shows the average flow time for the base senario and eah of the 10 esalations. In eah ase, the average and the 95% onfidene interval are given. The diagram shows that eah of the 10 esalations provides an improvement. However, for Esalation 5 and Esalation 6 the improvements are not signifiant, and at best only marginal. This shows that the problem is not in the first part of the proess, i.e., the invitation of reviewers. All other 8 esalations provide a lear improvement in terms of flow time. If we fous on the first four esalations, we see that the Resoure redeployment mehanism works. Moreover, the earlier and the more reviewers get involved, the better the end result. Esalation 7 and Esalation 8, i.e., the use of Data degradation, have a positive effet on the flow time. Combining the Resoure redeployment and Data degradation mehanisms, further redues the flow time. As ould be expeted, Esalation 9 is slightly more effetive than Esalation 10 beause in the first month one does not have to wait for the third review if the first two agree. Figure 13 shows the variane of the flow times for eah strategy. Here it is surprising to see that the Resoure redeployment mehanisms signifiantly redue the variane while the Data degradation mehanisms do not. For example, Esalation 7 and Esalation 8 have a variane omparable to the base senario and the less effetive strategies Esalation 5 and Esalation 6. This an be explained as follows. There will be ases with two positive or two negative reviews that are handled quikly. However, for ases with a positive and a negative review, the reviewing proess will take as long as 4 Note that a simulation run of 11 years only takes about 10 seonds on a laptop (Intel Pentium M Proessor, 1.40GHz, 512MB). 22

3500 3000 2500 Variene flow time 2000 1500 1000 500 no esalation esalation 1 esalation 2 esalation 3 esalation 4 esalation 5 esalation 6 esalation 7 esalation 8 esalation 9 esalation 10 Figure 13: The variane of the flow times for eah senario. in the base senario. Hene, there will be a ases that take a long time and that do not benefit from the esalation. The first four esalations are more robust beause one or two more reviewers are involved. Therefore, their variane is smaller. The above disussions illustrate the benefits of simulation as a tool to investigate the effets of the esalation mehanisms desribed in Setion 4 in a given senario. 7 Related work In soial sienes, researhers have investigated the effet of pressure (e.g., an approahing deadline) on the performane of people [11, 27, 31]. These studies suggest that workers hange the way of working when onfronted with a deadline. In most ases the effet is positive, i.e., people manage to get the work done in time. Unfortunately, urrent workflow management systems do not support or mimi human behavior in the presene of deadlines. A notable exeption is the the FlowConnet system of Shared Web Servies [15]. FlowConnet supports the definition of milestones that have planned values and atual values. These milestones are used to generate esalations and timeouts. An esalation in the ontext of FlowConnet means that a user is signaled that it is now ritial to perform an ation, i.e., the orresponding work-item is highlighted in the user s worklist. A time-out means that an ation is exeuted if a milestone was not reahed in time. Deadline esalation an be seen as a speial type of exeption handling. Many proposals have been put forward to address various aspets of exeption handling in workflow systems [5, 6, 10, 12, 13, 14, 19, 21, 25, 29]. Some of these previous proposals (e.g. [5]) advoate an ECA rules-based approah, whih we ontrasted with the 3D approah in Setion 3. Other proposals suh as [12] fous on failures and rare or unexpeted events rather than the ability to meet deadlines. Finally, a number of generi frameworks for struturing exeption handling knowledge have been put forward. In partiular, parallels an be drawn between the phases of the 3D approah (Detet, Deide and Do) and the phases for exeption handling proposed by Klein & Dellaroas [19], namely Preparing for exeptions, Diagnosing exeptions and Resolving exeptions. In this respet, the 3D approah an be seen as a refinement of the general exeption handling framework of Klein & Dellaroas. In the terminology of Klein & Dellaroas, what the 3D approah brings is an ontology (inluding resolution mehanisms) for a speifi sublass of exeptions (namely deadline esalations). Some researhers have proposed tehniques addressing the speifi issue of deadline esalation in workflow systems. For example, Panos & Rabinovih [22] desribe an approah to dynamially adjust 23

deadlines based on osts, expeted exeution times, and available slak time. In [23] this approah is refined and supported by simulation experiments. In [8] the topi of apturing time onstraints in workflow definitions is onsidered, and a PERT-like tehnique for the analysis of the temporal behavior of a workflow is proposed. This tehnique is similar to the one employed by the predition engine of Staffware [28]. Unfortunately, these tehniques impliitly assume that proessing times are independent of the workload and resoure apaity. The notion of proess fragments in Staffware [28] allows omposite ativities to be bound at runtime to speifi subproesses. This onept an be used to inorporate esalation mehanisms into a workflow desription. For example, based on the esalation level a speifi subproess may be seleted at a speifi point in a workflow. There is also a link between detetion for deadline-based esalation and Business Ativity Monitoring [9]. For example proess mining tehniques [2, 3] an be used to measure, predit and explain esalations. To the best of our knowledge, the appliation of these tehniques (generally aimed at offline analysis) to support the Deide phase of deadline esalation at runtime, is an open question. 8 Conlusion Although organizations are fored to esalate regularly, today s (proess-aware) information systems offer little support for this. In this paper, we foused on esalations triggered by the (predited) inability to meet deadlines. Using an example of the telelaims proess of an Australian insurane ompany, we identified and analyzed issues related to deadline-based esalation. We then proposed a general approah to deadline-based proess esalation and we presented various esalation mehanisms. The effetiveness of these mehanisms was evaluated through simulation studies. Future work will aim at designing and evaluating ost models for esalation. Suh ost models are key during the deision phase, when the ost of applying an esalation needs to be weighed against: (1) the extent to whih it dereases the probability of violating ertain deadlines (or violating them to lesser degrees than without esalation); and (2) the ost of these deadline violations. On the basis of suh model, it would then be possible to answer other key questions suh as: (1) when to apply a given esalation mehanism (individually); and (2) whih ombinations of mehanisms are most likely to work effetively together. Finally, it is neessary to design ways to seamlessly inorporate the ost model and the esalation mehanisms into existing proess-aware information systems, and in partiular workflow systems. Today s systems are typially unable to predit future problems and modeling the various esalation mehanisms result in spaghetti-like diagrams that annot be maintained easily. A proess modeling language that allows to learly distinguish between a base proess model and esalated versions of this model would be desirable. Aknowledgments The third author has been funded by a Queensland Govenerment Smart State Fellowship o-sponsored by SAP Australia Pty Ltd. The author would also like to thank Greg Bird from Advaned Data Integration for our fruitful disussions on deadline esalation mehanisms. Many thanks also to the anonymous organization that kindly provided the telelaims ase study. Referenes [1] W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros. Workflow Patterns. Distributed and Parallel Databases, 14(1):5 51, 2003. [2] W.M.P. van der Aalst, B.F. van Dongen, J. Herbst, L. Maruster, G. Shimm, and A.J.M.M. Weijters. Workflow Mining: A Survey of Issues and Approahes. Data and Knowledge Engineering, 47(2):237 267, 2003. 24

[3] W.M.P. van der Aalst and A.J.M.M. Weijters, editors. Proess Mining, Speial Issue of Computers in Industry, Volume 53, Number 3. Elsevier Siene Publishers, Amsterdam, 2004. [4] H. Boley. The Rule Markup Language: RDF-XML Data Model, XML Shema Hierarhy, and XSL Transformations. In O. Bartenstein, U. Geske, M. Hannebauer, and O. Yoshie, editors, Web Knowledge Management and Deision Support, 14th International Conferene on Appliations of Prolog, volume 2543 of Leture Notes in Computer Siene, pages 5 22. Springer-Verlag, Berlin, 2003. [5] F. Casati, S. Ceri, S. Paraboshi, and G. Pozzi. Speifiation and Implementation of Exeptions in Workflow Management Systems. ACM Transations on Database Systems, 24(3):405 451, 1999. [6] D. Chiu, Q. Li, and K. Karlapalem. A Meta Modeling Approah to Workflow Management Systems Supporting Exeption Handling. Information Systems, 24(2):159 184, 1999. [7] CPN Group, University of Aarhus, Denmark. CPN Tools Home Page. http://wiki.daimi.au.dk/pntools/. [8] J. Eder, E. Panagos, and M. Rabinovih. Time Constraints in Workflow Systems. In M. Jarke and A. Oberweis, editors, Proeedings of the 11th International Conferene on Advaned Information Systems Engineering (CAiSE 99), volume 1626 of Leture Notes in Computer Siene, pages 286 300. Springer-Verlag, Berlin, 1999. [9] Gartner. Gartner s Appliation Development and Maintenane Researh Note M-16-8153, The BPA Market Cathes another Major Updraft. http://www.gartner.om, 2002. [10] D. Georgakopoulos, M. Hornik, and A. Sheth. An Overview of Workflow Management: From Proess Modeling to Workflow Automation Infrastruture. Distributed and Parallel Databases, 3:119 153, 1995. [11] J.M.P. Gevers, W. van Eerde, and C.G. Rutte. Time pressure, poteny, and progress in projet groups. European Journal of Work and Organizational Psyhology, 10(2):205 221, 2001. [12] D. Grigori, F. Casati, U. Dayal, and M.C. Shan. Improving Business Proess Quality through Exeption Understanding, Predition, and Prevention. In P. Apers, P. Atzeni, S. Ceri, S. Paraboshi, K. Ramamohanarao, and R. Snodgrass, editors, Proeedings of 27th International Conferene on Very Large Data Bases (VLDB 01), pages 159 168. Morgan Kaufmann, 2001. [13] C. Hagen and G. Alonso. Flexible Exeption Handling in the OPERA Proess Support System. In International Conferene on Distributed Computing Systems, pages 526 533, 1998. [14] S.Y Hwang and J.Tang. Consulting Past Exeptions to Failitate Workflow Exeption Handling. Deision Support Systems, 37(1):49 69, 2004. [15] A. Iordahesu. FlowConnet: Proess Timing and Distribution Conepts. Shared Web Servies, Ultimo, NSW, Australia, 2004. [16] S. Jablonski and C. Bussler. Workflow Management: Modeling Conepts, Arhiteture, and Implementation. International Thomson Computer Press, London, UK, 1996. [17] K. Jensen. Coloured Petri Nets. Basi Conepts, Analysis Methods and Pratial Use. Volume 1. EATCS monographs on Theoretial Computer Siene. Springer-Verlag, Berlin, 1997. 25

[18] G. Keller, M. Nüttgens, and A.W. Sheer. Semantishe Proessmodellierung auf der Grundlage Ereignisgesteuerter Proessketten (EPK). Veröffentlihungen des Instituts für Wirtshaftsinformatik, Heft 89 (in German), University of Saarland, Saarbrüken, 1992. [19] M. Klein and C. Dellaroas. A Knowledge-Based Approah to Handling Exeptions in Workflow Systems. Journal of Computer-Supported Collaborative Work, 9( 3-4 ):399 412, 2000. [20] P. Lawrene, editor. Workflow Handbook 1997, Workflow Management Coalition. John Wiley and Sons, New York, 1997. [21] Z. Luo, A. Sheth, K. Kohut, and J. Miller. Exeption Handling in Workflow Systems. Applied Intelligene, 13(2):125 147, 2000. [22] E. Panagos and M. Rabinovih. Esalations in workflow management systems. In Proeedings of the workshop on Databases: Ative and Real Time (DART-96), pages 25 28. ACM Press, 1997. [23] E. Panagos and M. Rabinovih. Reduing Esalation-Related Costs in WFMSs. In Workflow Management Systems and Interoperability, pages 107 127. Springer-Verlag, Berlin, 1998. [24] H.A. Reijers and W.M.P. van der Aalst. Short-Term Simulation: Bridging the Gap between Operational Control and Strategi Deision Making. In M.H. Hamza, editor, Proeedings of the IASTED International Conferene on Modelling and Simulation, pages 417 421. IASTED/Ata Press, Anaheim, USA, 1999. [25] H. Saastamoinen and G.M. White. On handling exeptions. In Proeedings of the ACM Conferene on Organizational omputing systems, pages 302 310. ACM Press, 1995. [26] A.W. Sheer. ARIS: Business Proess Modelling. Springer-Verlag, Berlin, 2000. [27] A. Seers and S. Woodruff. Temporal paing in task fores: Group development or deadline pressure. Journal of Management, 23:169 187, 1997. [28] Staffware. Staffware Proess Suite Version 2 White Paper. Staffware PLC, Maidenhead, UK, 2003. [29] D.M. Strong and S.M. Miller. Exeptions and exeption handling in omputerized information proesses. ACM Transations on Information Systems, 13(2):206 233, 1995. [30] M. Weske, W.M.P. van der Aalst, and H.M.W. Verbeek. Advanes in Business Proess Management. Data and Knowledge Engineering, 50(1):1 8, 2004. [31] R.M. Yerkes and J.D. Dodson. The relation of strength of stimulus to rapidity of habit-formation. Journal of Comparative Neurology and Psyhology, 18:459 482, 1908. 26