Time Management in Work ow Systems

AT&T Labs { Research Florham Park, NJ 07932
hans@research.att.com

Johann Eder

AT&T Labs { Research Florham Park, NJ 07932

Euthimios Panagos

thimios@research.att.com

Department of Informatics Systems AT&T Labs { Research University of Klagenfurt, Austria Florham Park, NJ 07932
hepo@ifi.uni-klu.ac.at misha@research.att.com

Heinz Pozewaunig

Michael Rabinovich

Management of work ow processes is more than just enactment of process activities according to business rules. Time management functionality should be provided to control the lifecycle of processes. Time management should address planning of work ow executions in time, provide various estimates about activity execution durations, avoid violations of deadlines assigned to activities and the entire process, and react to deadline violations when they occur. In this paper, we describe how time information can be captured in the work ow de nition, and we propose a technique for calculating internal activity deadlines with the goal to meet the overall deadlines during process execution.

Abstract

1 Introduction
Time plays an important role in the management of business processes. For instance, business process re-engineering projects typically try to reduce turnaround times and improve process execution duration estimates in order to improve competitiveness. In addition, many business processes have time-related restrictions, including bounded execution durations for
eder@ifi.uni-klu.ac.at

On leave from Department of Informatics Systems, University of Klagenfurt, Austria,

1

activities and sub-processes and absolute deadlines associated with activities and sub-processes. Consequently, time management should be part of the core management functionality provided by work ow systems to control the lifecycle of business processes. Even though existing work ow management systems o er sophisticated modeling tools to specify and analyze work ows, their time management functionality is rudimentary PEL97, JZ96]. In particular, their time management functionality mainly addresses process simulations (to identify process bottlenecks, analyze the execution durations of activities, etc.), assignment of activity deadlines, and triggering of process-speci c exceptionhandling activities (called escalations) when deadlines are missed during run time LR94, InC, Flo, Ult, CS96, CSE98, SAP97]. Moreover, few research activities about work ow and time management exist in the literature. For process-centered organizations, time management is essential for the management of the processes themselves. Typically, time violations increase the cost of a business process because they lead to some form of exception handling. Therefore, a work ow management system should provide the necessary information about processes and their time requirements. In particular, the following requirements should be satis ed. Work ow modelers need means to represent time relevant aspects of business processes (e.g., duration of activities, time constraints, etc.) and means to check these timing conditions; Process managers need support to adjust time plans (e.g., extend deadlines) according to time constraints, and they need means to be warned of possible violation of time constraints so early that they can act accordingly to avoid time failures; Work ow participants need information about urgencies of the tasks assigned to them to manage their personal work plans; If time failures (i.e., deadline misses) occur, the work ow system should trigger exception handling to regain a consistent state of the work ow instance; Business process re-engineers need information about the time consumption of work ow executions to improve business processes; Also controllers and quality managers need information about when and for how long activities of a work ow instance were performed.

Section 2 describes the work ow model we use in this paper. discuss assignment of activity and process deadlines. time calculations are rough. In particular. addresses activity durations and deadlines. For highly structured production work ows with only inter-organizational events. management of time. and whether there are external causes for time relevant events. The remainder of the paper is structured as follows. we are mainly interested in the rst three aspects. Our approach tries to model and represent the knowledge about time issues and make the best use of existing time knowledge during the execution of work ows. In administrative work ows. Nevertheless. time behavior and consumption of a work ow can be calculated precisely. 2 Time Information in Work ow Schemas In this section. Pro-active time calculation to raise alerts in case of potential future time violations. Time management during the execution of a process becomes even more important in such an environment. waiting for a costumer to reply). which span di erent organizations with several external events (e. Section 5 o ers a comparison with related work and. Section 6 concludes our presentation. In this paper. and present the various points . Section 3 presents the time calculations at process build time. Section 4 presents the time calculations at process instantiation and the actions taken during runtime.The latter two aspects are usually provided by work ow systems via work ow documentation (also referred to as work ow history or work ow log ) and monitoring interfaces. where time monitoring is essential for adjusting plans to avoid deadline misses.. and. how detailed its description is. nally. a word of caution ahead: the e ectiveness of time management depends of the nature of the work ow. Handling of time errors. Time monitoring and deadline checking at runtime. However. we address the following issues.g. we describe the work ow model we use in this paper. Typically. Modeling of time at process build time to capture the available time information. time planning and controlling has to be done. to our experience. it is being done in current business processes. and covers the phases when time calculations take place. time planning relies on estimates based on experience.

Dependencies determine the execution sequence of activities and the data ow between these activities.e. In addition. and they may be software systems (e.g. agents. they may be dropped during the execution of a particular work ow instance when existing time constraints can only be satis ed by omitting the execution of some activities. There is an important di erence between conditional execution and alternative execution of activities.during the lifecycle of a process where time calculations can take place. durations. In order to represent time information.. i. database application programs) or humans (e.1 Work ow model .g. and dependencies between activities.e. a work ow is a collection of activities. and the possible parallel executions are: unconditional . For build time and work ow schemas. and deadlines. i. Activities correspond to individual steps in a business process. Optional activities are typically executed during the execution of work ow instances. This means that any alternative will lead to a correct work ow execution... time information is always given relative to the beginning of a work ow. this time information is mapped to an actual calendar.. a work ow may contain optional activities. conditional . the activity that is executed next depends on policies and information that is shared by all instances of the same work ow process. We use a generic work ow model that employs the structures typically found in existing work ow models.. and alternative . the time information has to be given in application speci c temporal units.e. we need to augment our work ow model with the following basic temporal types: time points. i. In particular. However. all activities are executed. For work ow instances. when the schedule is tight. customer representatives). the activity that is executed next depends on data and state that are generated during the execution of the work ow process instance. any activity among many alternative activities can be executed. For the sake of simplicity we assume that all time information is given in some basic time units. the alternative with the shortest execution time can always be chosen. and for time management. In the former case. In the latter case. For applications. 2. Agents are responsible for the enactment of activities. only the activities that satisfy a given condition are executed. Activities can be executed sequentially or in parallel.

rollback of the entire process). The most compelling reason for doing so is the monitoring of the execution progress of activities and processes containing these activities so that pre-emptive actions are taken when delays are developed. execution durations correspond to estimated or projected activity execution times. are computed at process build and instantiation times and how we use them at run time in later sections of this paper. These durations can be either calculated from past executions. called internal deadlines . it is bene cial to associate deadlines with activities. which is how they are always treated by some of the existing work ow management systems. We present how these deadlines. time calculations are needed for computing optimistic and pessimistic start . no deadlines may be assigned to activities at all. the most common duration values used include minimum. In addition. Flo]. when an activity takes longer to execute than the duration assigned to it in the work ow schema. In the remainder of this paper. In such cases. a work ow designer can assign execution durations and deadlines to individual activities and to the whole work ow process LR94. Deadlines do not have to be associated with every activity in a given work ow schema. we refer to these deadlines as explicit deadlines. Typically. on the other hand. and alert appropriate agent(s) and process manager(s). respectively. Activity and process deadlines.. pre-emptive steps can be taken to assess deadline satis ability. correspond to maximum allowable execution times for activities and processes. or assign new deadlines. It is important to note that activity durations and deadlines may not be the same. At process instantiation time. a calendar is used to convert all relative deadlines to absolute time points. Usually. many duration values may be speci ed for activities and used during simulation. and most frequent execution times.2 Execution Durations and Deadlines 2.Given a work ow schema. these deadlines are speci ed relative to the beginning of the process. 2. modify work ow parameters. Distinguishing between the two is extremely bene cial for cases where the actions taken when a deadline is missed may have considerable costs associated with them (e. InC. At process build time.g.3 Time Calculations Given the activity durations and deadlines assigned in a work ow schema. In fact. or they can be assigned by specialists based on their experience and expectations. modify the assigned deadlines. However. maximum.

and use it for multiplication with the duration of the loop body. and mean number of iterations to calculate expectancy and variance as above. At run time. the duration of complex activities or sub-processes consisting of sequences. The designer can provide this information in three ways. the designer might modify the work ow structure. This information is subsequently used to adjust internal deadlines when activities are launched to worklists. At build time. converting time information to absolute time points. the assignment of external deadlines is an iterative process. Furthermore. optional. conditional. and so on. This information can be used by the process designer(s) to locate temporal bottlenecks and candidates for further optimization e orts. The designer can provide minimum. Typically. and parallel executions can be calculated as we show in the sequel. However. time information (durations and external deadlines) is recorded. The designer rst assigns activity durations. In particular. 1. a deadline for the entire process is speci ed and internal activity deadlines are computed. and general time information on the work ow type is computed. and the time information is mapped to absolute time points using a calendar. the following three phases are used for these time calculations. updating existing deadlines. . alternative. 2. the execution progress of a process is monitored and activity execution times are recorded together with the decisions made at various conditional and alternative execution points. we need additional information about the number of iterations. From this information. The designer can then choose to set external deadlines to some of the activities and recompute the time information. maximum. If external deadlines cannot be met. At process instantiation time. a process instance and its own time information are created. several start and nish activity times are computed based on the above time information and the process structure. available slack time for activities. The time calculations at process build time are then used to compute the duration of the whole process and the relative position of all activities. For a xed number of iterations. the designer assigns exactly this number. for loops.and nish times of activities within processes. Furthermore. or change the deadlines.

there is a conditional split. In the remainder of the section. projections. Finally. These durations are either assigned by the process modeler(s) based on various estimates.B 4 D 3 o H 2 J 3 A 2 C I 10 E 10 o A L 10 K G 5 20 C 5 F 20 Figure 1: Example work ow process schema 3. . there is an unconditional split (parallel execution). as well as the nish time of the entire process. we describe how such calculations are carried out and how they can be used. there is an alternative split. and expectations or derived from past process executions. execution durations for activities are available at process build time. The loop can be considered as a complex activity and the designer de nes the duration of this whole complex activity. we can calculate the relative start and end times for all activities (with respect to the beginning of the process). 3 Time Management at Build Time Typically. Activities D and I are optional. but assume that they are treated as (complex) activities. L corresponds to the nal activity of the work ow. Using the work ow process schema and the durations assigned to the activities in the schema. i.. After A. either J or K will be executed (both are valid choices).e. In the following we will not consider loops in detail. and after activity C . Activity A is the start activity and its duration is set to 2 time units. After I . Figure 1 shows an example work ow schema having durations attached to activities.

At the beginning of this traversal. there exist no time constraints between activities (e. LBS . EWS corresponds to the earliest point in time A may end when in the preceding process execution the worst conditional branches were followed. LWS . EWS . we extend their work and associate the following relative time information with the end event of an activity A: EBS . activity B can start 5 time units after activity A ends). EWF . dummy activities can be used to make the end event of an activity be the same as the start event of the next activity. A For example. and LWS . all optional activities were executed. the authors used the PERT-net technique to formulate time constraints in work ow systems. In PEL97]. Finally. LA corresponds to the latest possible WS point in time activity A has to nish in order to minimize the execution of the entire process. F corresponds to an execution where optional activities are not executed and the fastest alternative is always selected. Therefore. the end event of an activity and the start event of all its successor activities are the same. LBF . all optional activities will be executed. EBS . we use B to denote the best case and W to denote the worst case. and the slowest alternatives were chosen. Assuming that any start-up costs are already incorporated in activity durations and. EWS . The start event denotes the start of the activity. EBF . First. In the above time information. Depending on the control dependencies between activities. LBS . the L-values of all activities . we only consider end events for the remainder of the paper. while the end event denotes the completion of the activity. When start-up costs exists or external timing constraints are present. the Evalues of all activities without predecessors are set to 0. Next. LWF . LWF . On the other hand. Here. and any alternative can be selected in the remaining of the process. EBS . optional and alternative activity executions are \captured" by F and S . and LWS are computed in the following way. EBF . LBF . and EWS .3. Since conditional branches may require di erent execution times. EWF . in addition. a backward traversal of the work ow schema is required for computing LBF . E stands for the earliest point in time A may end. a forward traversal of the work ow schema is required for computing EBF . while L stands for the latest possible point in time A can nish to ensure minimal execution time for the entire process. and LWF .1 Timed Graph Construction Every work ow activity A has a start and an end event associated with it. EWF .g. S corresponds to an execution where all optional activities are executed and any alternative can be selected.. assuming that the worst conditional branches will be followed. At the beginning of this traversal. LBS .

EWF . i ! j ) BF LiBS = Lj ? d(j ). j ) j 8i : i ! j g j i conditional EBF = minfEBF + d0(j ) j 8i : i ! j g j = minfE i + d(j ) j 8i : i ! j g EBS BS j i EWF = maxfEWF + d0(j ) j 8i : i ! j g j i EWS = maxfEWS + d(j ) j 8i : i ! j g j = minfE i + d0 (j ) j 8i : i ! j g alternative EBF BF j i EBS = maxfEBS + d(j ) j 8i : i ! j g j = minfE i + d0 (j ) j 8i : i ! j g EWF WF j i EWS = maxfEWS + d(j ) j 8i : i ! j g Backward Computation Procedure sequential LiBF = Lj ? d0(j. i ! j EBS BS j i EWF = EWF + d0(i. i ! j j = E i + d(j ). j ). LBS . i ! j WS unconditional LiBF = minfLj ? d0 (j ) j 8i : i ! j g BF LiBS = minfLj ? d(j ) j 8i : i ! j g BS LiWF = minfLj ? d0(j ) j 8i : i ! j g WF LiWS = minfLj ? d(i. LBF .LWF Table 1: Computations of EBS . EBF . EWS . i ! j EWS WS j i unconditional EBF = maxfEBF + d0 (j ) j 8i : i ! j g j i EBS = maxfEBS + d(j ) j 8i : i ! j g j = maxfE i + d0 (j ) j 8i : i ! j g EWF WF j i EWS = maxfEWS + d(i. i ! j WF LiWS = Lj ? d(j ). i ! j BS LiWF = Lj ? d0(j ). and Forward Computation Procedure j i sequential EBF = EBF + d0(j ). j ) j 8i : i ! j g WS conditional LiBF = maxfLj ? d0(j ) j 8i : i ! j g BF LiBS = maxfLj ? d(j ) j 8i : i ! j g BS LiWF = minfLj ? d0(j ) j 8i : i ! j g WF LiWS = minfLj ? d(j ) j 8i : i ! j g WS alternative LiBF = minfLj ? d0(j ) j 8i : i ! j g BF LiBS = maxfLj ? d(j ) j 8i : i ! j g BS LiWF = minfLj ? d0(j ) j 8i : i ! j g WF LiWS = maxfLj ? d(j ) j 8i : i ! j g WS . i ! j j = E i + d(i. LWS . j ).

EBF EBS EWS . For clarity. If during the backward traversal external deadlines are assigned to activities with successors. and EBS LBS . Alternatively. Figure 2 shows the meaning of these values for each activity node. we assume that execution durations correspond to average execution times. the E-values of activity L. the execution duration of an activity can be set to the minimum. the L-values of these activities are set to their respective deadlines when there are greater than these deadlines. If activity j is optional. Figure 3 shows the result of calculating the E. or average execution duration. It is easy to see. thus. For the remainder of the paper. d0(j ) is set to d(j ). its termination 3.Activity duration Ebf Ebs Ewf Ews opt. maximum. we have omitted external deadlines from these formulas.and L-values for the work ow schema shown in Figure 1. Otherwise. that the following invariants hold: EBF EWF EWS . Lbf Lbs Lwf Lws Figure 2: An activity node in the timed work ow graph without successors are set to their corresponding E-values. The notation i ! j is used to represent the fact that j is an immediate successor of i. The most important information present in this timed graph is the activity E-values and. Table 1 illustrates the formulas used for the above computations. These values can be computed from the log records generated by existing work ow systems. This is because L is the last activity to be executed and. In this case. in particular. In addition. unless external deadlines are assigned to these activities. For the calculations presented in Table 1. which are assumed to be relative to the beginning of the process. d(j ) denotes the execution duration of activity j . they can be assigned by process modelers and be part of the work ow-speci c data. all L-values are set to these deadlines.2 Interpretation of the Timed Graph . d0(j ) is set to 0. or to a duration that corresponds to some percentage of the already executed process instances.

the earliest possible time for the entire work ow to terL minate is 21. J is selected instead of K . EWS conditional branch followed. if all optional activities L are executed. On the other hand. then there exist paths that may lead to time violations. if C is executed at run time and the deadline of the entire process is set to 21.. EBS ) and as late L ). there exist execution paths containing this activity that are likely to avoid time violations. activity C has negative LBF and LBS values in Figure 3. the work ow can nish as early as 51 (i.e. and the conditional branch containing B is followed. For example. depending on the alternative activity selection and the as 72 (i. which corresponds to EBF . if all L-values of an activity are greater than their corresponding E-values. the deadline will be violated. However..B 4 6 6 6 A 2 2 2 2 2 2 2 2 2 10 17 17 17 C 5 7 7 7 7 -17 -13 7 7 20 27 27 27 27 17 6 6 6 30 27 3 6 9 6 9 D O 6 9 30 30 2 8 11 8 11 H 3 8 11 32 32 10 8 I O 8 21 32 42 20 28 G 5 32 8 11 32 42 41 52 62 11 24 35 45 J 11 41 35 62 10 21 51 45 K 11 41 35 62 72 21 51 45 72 L C E 3 6 27 27 A 21 32 42 F 3 6 27 27 32 32 32 Figure 3: Work ow timed graph after the build-time calculations time point corresponds to the termination time point for the entire process. . In particular. they indicate whether there is a path containing this activity that may lead to a time error at process execution. Therefore. if there exist L-values that are less than their matching E-values. In particular.e. Regarding the L-values of an activity. This can happen when activities D and I are not executed.

an actual calendar is used to transform all relative time information to absolute time points. internal activity deadlines are monitored. we can conclude that it is possible to meet all deadlines. 4.1 Time Fixing at Process Instantiation At process instantiation time. However. we address these issues in depth. and G have been given externally. In the remainder of the section. the timed graph may have to be recomputed if external. H: 25. relative time information contained in the timed graph created during build time is transformed into absolute time points. hence.B 4 6 6 6 A 2 2 2 2 2 19 11 17 -10 10 17 17 17 C 5 7 7 7 7 22 -5 22 -5 20 27 27 27 27 17 6 23 15 23 15 3 6 9 6 9 D O 23 18 23 18 2 8 11 8 11 H 3 25 20 25 20 10 8 I O 47 30 47 30 20 28 G 5 32 47 20 47 20 41 52 62 11 24 35 45 J 50 50 50 50 10 21 51 45 K 50 50 50 50 72 60 60 60 60 L C E 42 15 42 15 A 21 32 42 F 42 15 42 15 32 32 32 Deadlines: L: 60. In addition. When we look at the values for activity A. and remedial actions are taken when deadlines are violated. then it is necessary to skip optional activities or select faster alternatives. Figure 4 shows the work ow graph after deadlines for the activities L. If all L-values are negative. if at conditional branches longer paths are followed. G: 50 Figure 4: Example work ow process schema after process instantiation 4 Time Management at Run-Time At run-time. we cannot make it and we should raise a time . the re-computation only a ects the L-values and. However. we only have to repeat the backward traversal of the work ow schema. H . absolute deadlines are assigned to activities.

4. and the L-values for this activity. In addition to the slack time that is generated when activities take less time to nish. it might be necessary to drop some optional activities or chose faster alternatives. At this point. the average duration of an activity A. slack is generated from the di erence in the duration of di erent paths. slack time may be available due to the following. they have no successors. This can be done by checking the activities that are/will be assigned to an agent and the E-values for these activities. we can assess the state of the work ow instance containing A with respect to its execution progress as follows. not discussed further in this paper.exception. Given the current absolute time point. the process is running smoothly and WS all deadlines will be met. when the execution takes longer that the average execution time. If LA now + duration(A) LA . However. is subject of ongoing research to improve the forecast of delays in work ow executions. If now + duration(A) LA . shorter branches have slack available to them.2 Internal Deadline Calculation . slack time becomes available. i. This topic. During the execution of a work ow instance. E-values are not really needed since the L-values are a ected by the external deadlines. the execution durations of activities may vary considerably from their average values. slack time for future activities may be reduced. When the execution takes less than the average execution time. Activities belonging to parallel branches may have di erent execution characteristics.. In conditional and alternative structures. 4. given that the remaining activities take the expected execution time. 3. E-values could be used for performing agent load analysis. now. On the other hand. 1. the process can still meet WS WF all deadlines. However. Since the longest branch determines the execution of all parallel branches belonging to the same unconditional split point. 2. The deadline assigned to the entire work ow process is greater than the L-values of all activities that signal the end of the process. When an optional activity is not executed. its average execution time becomes the available slack for its successor activities.e.

there is still a chance that the work ow BF nishes in time.e. Similarly. However. Default values for these thresholds are set as follows: LA = LA and LA R = LA . where no risk concerning alternative paths is taken. Green: We expect to nish the work ow in time without dropping any of the optional activities or changing the alternative selection policies. If LA now + duration(A). The rest of the activities are executed normally in this state. a decision needs to be made regarding the selection of the alternative activity to execute next. To monitor the state at which a process instance is currently operating. thus. we use two threshold values for each activity. These values are conservative GY WS Y WF choices. we may have to eliminate some of the optional activities or select speci c alternatives. are in uenced by more information than is usually available in work ow systems. before launching an optional activity. The above thresholds could be treated as internal activity deadlines (i.If now + duration(A) LA . LGY signals the change from a green state to a yellow state. In particular. It is an important tuning knob for the time management system. Yellow: Although we may still be able to nish in time. In particular. then it is only possible to meet the BF deadlines if the remaining activities nish faster than expected. the . If LBF is missed. LY R signals the change from a yellow state to a red state. Red: The threat of missing a deadline is great and a time error should be raised to trigger escalation actions. Based on the above observations.. a decision has to be made whether the activity should be executed. and we believe that it should be the responsibility of a process manager to set these values and adjust them accordingly. the proportion of best and worst cases. However. and the willingness to accept risks and. we can summarize the status of a work ow using the following states. these threshold values should take into account the variance in activity durations. this depends on which conditional branches are followed. deadlines not assigned at build or instantiation times). LGY and LY R . we do not have to consider these deadlines as long as LBF can be met. escalation is invoked. We should note that since externally de ned deadlines are already taken into account during the construction of the timed graph.

This policy corresponds to the total slack policy presented in PR97b]. the deadline is only necessary to determine when an escalation has to be raised. For optional activities.deadlines of all non-optional activities could be set to LY R . or red). the duration is extended by a fraction of the available slack according to the proportion of the duration of the actual activity to the duration of the rest of the work ow. the deadline may be extended. the upper bound for the new internal deadline is LY R. the upper bound for 4. For instance. in work ow systems where the shortest deadline rst scheduling policy is used by the engine or the work ow participants can choose the next activity to execute from their worklists. If the internal deadline does not in uence the order in which activities are selected from worklists. For non-optional activities. If these deadlines cannot be met. deadline extension can be granted based on the current state of the process and the available slack. and some of the possible alternatives are the following. a time failure is generated and escalation actions are taken. it may be bene cial to assign di erent internal activity deadlines than the above threshold values when these deadlines can in uence the sequence in which activities are selected from worklists and. the internal deadline is set to the duration of the activity. However. In the later case. Possible alternatives for computing these internal deadlines are the no slack and proportional slack policies described in PR97b]. while the deadlines of optional activities could be set to LGY . yellow. the internal deadline are not necessary and the threshold values introduced above can be used. therefore. When a deadline is missed. Deadline Extension: When an internal deadline is missed while the process is in either the green or the yellow state. strict internal deadlines can be used to accelerate process execution and create slack that can be used to address unexpected delays and exceptions in the future. These escalation actions depend on the state of the work ow process (green. in uence when activities are executed. In the former case. which is the case when FIFO is used.3 Handling Missed Deadlines . according to the discussion presented in the description of the yellow state. Note that for optional activities we use LGY because a decision has to be made before launching such activities. For these worklist selection strategies.

The escalation strategy tries to avoid higher escalations as long as possible. When such pro-active means are taken. these optional activities are marked as dropped. the above is bene cial only when the process deadline can be met with these changes. Pro-active actions like avoiding alternative branches or skipping optional activities are delayed as long as possible. future optional activities can be eliminated. Extending internal deadlines is helpful when the proportional slack or the no slack strategies are followed during deadline assignment. 5 Related Work Assignment of internal deadlines di ers from dynamic work ow modi cation that is supported by some existing work ow products and research . according to the discussion presented in the previous section. as we discussed in the previous section. or deadlines can be renegotiated. The threshold values between the timing states de ned above are again used for determining the escalation level. Alternative Selection: When the process is in the yellow state and its internal deadline is missed. recovery may be automatically invoked (ala EL96]) or human interaction may be required to proceed. Time Error: If the process is in the red state. The pre-emptive escalation work of PR97a. The work ow schema can be dynamically changed (e. PR97b] can be used for determining this.. by parallelizing sequential activities). besides extending its deadline (as in the previous case). In the latter case.the new internal deadline is LY R. and the decision to drop them is made when they are about to be scheduled for execution. there are several options available to process managers in order to regain a valid work ow state. Here. the selection policy for future alternative activities may be changed to favor alternatives with faster execution times. Of course. the timed graph has to be recomputed to re ect the changed work ow. a timing exception has to be raised to escalate the problem. Actually. activity priorities can be raised to speed up execution. Option Removal: If no deadline extension can be granted and no alternative selection policy can be altered to preserve the process deadline.g.

worst. Each sub-task deadline is assigned just before the sub-task is submitted for execution. and concurrent executions of activities. conditional. we treat alternative. Finally. agent work-list length) for adjusting activity deadlines and estimate the remaining execution time for work ow instances. nor does it consider alternative activity executions and optional activities. alternative. average activity execution time and probability of executing a conditional activity). our work does not concentrate on CPU scheduling. the authors studied the problem of how the deadline of a real-time activity is automatically translated to deadlines for all sequential and parallel sub-tasks constituting the activity. and react to time failures without modifying the business process model. PR97a. alternative. our algorithms are not restricted to transactional work ows. Our work is related to the work described in MN95]. We view scheduling and internal deadline assignment and adjustment as complimentary mechanisms.g. the authors presented an extension to the net-diagram technique PERT to compute internal activity deadlines in the presence of sequential. and the algorithms for deadline assignment assume that the earliest deadline rst scheduling policy is used. there are several important di erences. While our work has similarities with the above work. it is somewhat similar to scheduling in real-time systems LL73.. real-time systems use deadlines for scheduling system components such as CPU and I/O.g. In contrast to these algorithms. PR97b]. In this. and optional activities. our goal is to capture time information at build time. Each work ow process consists of several sequential tasks. In PR96. and me- . HSTR89]. In KGM93a. the authors proposed the use of static data (e. In particular. In MN95]. escalation costs). we o er techniques for building the timed graph at process build time and using the graph for arriving at a process deadline. Under this technique. and they allow both sequential. business analysts provide estimates of the best. conditional. However. and optional execution of tasks. In addition. this work does not address time management at process build time. statistical data (e. However.g.. AGM88. the authors presented priority-driven CPU scheduling algorithms for transactional work ows. The assignment of priorities is based on the performance of the tasks relative to their original response time goals. In PEL97]. KGM93b]. Also. monitor process execution at run time. In contrast. Each task is an ACID transaction having an average response time goal. our work supports the assignment of external deadlines to individual activities as well as to the entire process. The latter is done to re ect changes in the model of the business process or a particular instance of the process..prototypes. parallel. and run-time information (e.

and the -distribution is used to compute activity execution times as well as shortest and longest process execution times. This information allows users to make priority decisions between activities based on the urgency of activities in the global process and their deadlines to avoid time errors. The time information is also used to inform work ow users about time constraints about the activities in their worklists. In particular.g. 1988. CSE Systems. our work enables process managers to plan work ows along the time dimension and to be alerted about potential time error. we extended the net diagram technique PERT to handle alternatives and optional activities in the process de nition. the PERT-diagram supports the work ow scheduler in nding optimized work ow executions. 1996. Los Angeles. early on so that they can take steps to avoid the con icts or to escalate in order to minimize operational costs. References AGM88] R. . At run time. e.. Our work extends this work by providing a technique for handling optional activity executions. Austria.. An important advantage of our work in the explicit treatment of time during work ow de nition and execution. time constraints are checked at build time and escalations are monitored at run-time. The idea is to enrich a work ow speci cation by time information for activities. started or nished) to satisfy the overall time constraints of the work ow. CS96] CSESystems. we presented a method for incorporating time aspects into work ow management. Computer & Software Engineering GmbH. and addressing the computation of internal deadlines under various circumstances. missed deadlines. and to translate such a work ow description into a PERT-diagram that shows for each activity the time when the activity has to be at a speci c state (e. In Proceedings of the 14th International Conference on Very Large Data Bases. For these calculations. Abbott and H.1 Work ow. Having done that. pages 1{ 12. Benutzerhandbuch V 4. Klagenfurt. 6 Conclusion In this paper.dian execution times for activities. CA.g. Garcia-Molina. Scheduling real-time transactions: a performance evaluation.

California. San Francisco.CSE98] CSE Systems Homepage. KGM93a] B. 1993. Zeitaspekte bei der Modellierung und Ausfuhrung von Work ows. February 1998. Kao and H. and W. In Proceedings of the 39th IEEE Computer Society International Conference. Business process management with owmark. Leymann and D. Garcia-Molina.software. February 1994.com. Brussels. Groiss. In Proceeding of the 10th Real-Time Systems Symposium. LL73] C. http://www. Kao and H.L.co.ibm. Lin and J. pages 230{233. Stanford University. Jablonski. IEEE Computer Society Press.O. Subtask deadline assignment for complex distributed soft real-time tasks. Helsinki. Roller. 3400 Hillview Avenue. Journal of the Association of Computing Machinery.csesys. In First IFCIS International Conference on Cooperative Information Systems (CoopIS 96). Stankovic. Liebhart. Scheduling algorithms for multiprogramming in hard real-time environments. Box 780. Experimental evaluation of real-time transaction processing. KGM93b] B. Garcia-Molina. a division of xerox. volume 2 of Proceedings Reihe der Informatik '96. editors. D. EL96] Johann Eder and Walter Liebhart. January 1973. Jun 1996. Deadline assignment in a distributed soft real-time system. Work ow recovery.xsoft. 26121 Oldenburg. pages 109 { 119. Kaschek. P. 1996. December 1989.com/workgroup. Escherweg 2. FIN-00101. Technical product overview. 1993.A. Belgium. Palo Alto. Huang. Finland. 20(1):46{61. pages 428{437. Technical Report 931491. . http://www. CA 94304. In S. J. and K. H. Geschaftsproze modellierung und Work owsysteme. In Proceedings of the 13th International Conference on Distributed Computing Systems. Ramamritham. Layland. HSTR89] J. XSoft. Towsley.at/. JZ96] Heinrich Jasper and Olaf Zukunft. LR94] F. http://www. R. InC] InConcert. Flo] TeamWare Flow. Collaborative work ow system for the way people work.

C. August 1997. Pozewaunig. SAP Business Work ow c OnlineHelp. Sept. 1997. Towards adaptive scheduling of tasks in transactional work ows. Washington D. E. In First EastEuropean Symposium on Advances in Database and Information Systems ADBIS 97. Liebhart. Istanbul. Rabinovich. In Proceedings of the 3rd International Workshop on Next Generation Information Technologies and Systems. Rockville.. editor. J. Rabinovich. Nikolaou.. Springer. St. Russia. Germany. SAP Walldorf. Raleigh. Reducing escalation-related costs in WFMSs. June 1997. Maryland. In Winter Simulation Conference. 1995. In DART Workshop. Suite 135. Business work ow automation. November 1996. Escalations in work ow management systems. Panagos and M. and W. H. 4915 Waters Edge Dr. In A. Ultimus. E. Panagos and M. 1997. NC 27606.. Rabinovich. Dogac et al. Turkey. NATO Advanced Study Institue on Work ow Management Systems and Interoperability. ISRAEL. .ultimus1. Neve Ilan. E. http://www. Marazakis and C. Predictive work ow management. Petersburg. ePERT: Extending PERT for Work ow Management Systems. Eder. Work ow suite.com. Panagos and M. Part of the SAP System.MN95] PEL97] PR96] PR97a] PR97b] SAP97] Ult] M.

Sign up to vote on this title
UsefulNot useful