IRS-MT: Tool for Intelligent Resource Allocation. Piotr Chrza̧stowski-Wachtel1,2 and Jakub Rauch1 1 Institute of Informatics, Warsaw University, Banacha 2, PL 02-097 Warszawa, Poland 2 Warsaw School of Social Sciences and Humanities, Chodakowska 18/31, PL 03-815 Warszawa, Poland pch@mimuw.edu.pl, jakub.rauch@gmail.com Abstract. A tool for optimizing cost and time of a workflow execution with respect to allocation of multi-purpose resources is presented. The optimization is done as a result of simulations, which take into account the cost and time associated with each of the resources, when allocated to transitions in Petri nets representing a workflow. These attributes can be collected and updated based on the logs of the finished instances. The program suggests the best allocation procedures, giving the estimates of the performance of the whole run for all possible decisions. 1 Introduction Modeling processes as workflows has become quite popular and proved its use- fulness in practice. One of the problems associated with running a workflow is the resource management. By resources we mean all components required to run an activity. In our case, their necessity is described by certain requirements (e.g. skills or functions) associated with activities (transitions). With each resource we associate a bunch of skills, so we can choose, which of the resources are to be attached to certain activity at the workflow simulation run-time. The Petri net approach requires collecting all the resources necessary for a given transition before triggering an acitivity to run. One cannot reserve a resource, and keep it busy, while waiting for other resources necessary to run an activity. Only when all resources are available we can make a decision to run (fire) an activity. It often happens that a resource is requested by different activities. A resource conflict occurs, when a single resource is shared by two enabled transitions. We must make a decision, which activity will use the resource first. We assume here that the resources are re-usable, and that after finshing a transition the resource can be used by another activity. When we make a decision about the resource allocation, we should take into account several aspects. Usually we try to optimize some quality function, like time or cost of the workflow run. We assume here that during a workflow run we can perform several actions concurrently. Since some of them will be competing for resources, a proper allocation can improve the quality of workflow Recent Advances in Petri Nets and Concurrency, S. Donatelli, J. Kleijn, R.J. Machado, J.M. Fernandes (eds.), CEUR Workshop Proceedings, ISSN 1613-0073, Jan/2012, pp. 235–250. 236 Petri Nets & Concurrency Chrzastowski-Wachtel and Rauch run. Engaging proper resources can diminish for instance the delays caused by lack of the only resource requested by a concurrent action and hence waiting for this resource to be released. As described in [BPS09], there are many essential aspects of resources, which should be taken under consideration during workflow simulation. One of them is already mentioned: the multifunctionality of resources. Resources have attributes describing their skills. In other words these are the abilities to perform certain actions. Each resource is associated with the set of activities, in which it can be used. Other attributes taken under consideration are performance and cost associated with engaging the resource. So we know how fast a resource can do an activity and how much it costs to use it. By expense of a resource we mean here a value per time unit associated with involvement of the resource. A chief accountant probably has a driving license, but using him to drive the documents somewhere can be a waste of his time and precious skills. His cost per hour is much higher than that of a professional driver. Since workflows can be quite complex, the authors do not see any analitycal approach, which would be effective in the optimization of runs. It is hard to predict all the possible outcomes of the allocations decisions, when resources are in many conflicts. Instead, we propose an experimental approach, which involves the simulation of many runs, taking into account different allocations and estimating the desired measures as a result of allocation decisions. In our prototype IRS-MT (Intelligent Resource Sharing-Modelling Tool) the manager can edit a structured workflow net and set the number of experiments. The program makes random allocations reporting times and costs of the runs. Based on this knowledge the manager can use the suggestions of the program and get a picture of possible outcomes of the decisions taken. The decisions can be made incrementally. After each decision the workflow run advances its state, and when we come to the next decision, a separate simulation will be made, basing on the actual state of the system. 2 Basic definitions In our tool we consider resources (S), roles (R), requirements (Q) and activities (A). Resources and roles are finite and defined a priori (by designer). For each resource we define a set of skills (roles), which it can use. This is denoted by FSR : S → P (R) function. Additionally, for each role in a resource, its efficiency may differ. For every resource s ∈ S, we define the efficiency function Es : FSR (s) → R+ . This function describes how fast a resource performs each of its roles. The lower this value is, the higher is the efficiency (one is the base value). Additionaly, for every resource we define its use cost per time unit as a function C : S → N. On the other hand, for each activity in a workflow, a set of requirements needed to fire it, should be determined. Every requirement Q ∈ Q is a subset of roles. We define a function FAQ (a) which is a bag of requirements associated with the activity. It is important, that every activity has an expected duration time defined and its standard deviation value. Later, in the generation A tool for modeling resource allocation Petri Nets & Concurrency – 237 and simulation phase, only the available resources fulfilling these requirements will be considered for taking part in such activity. And so, s ∈ S is fulfilling q = hRq i, iff Rq ⊆ FSR (s). It is important, that if a resource is involved in some activity, it cannot be used by any other activity (there is one exception, which will be covered later in this section). Initially all the resources are free, available in a pool of idle resources. We assume, that all the resources are reusable, so at the beginning of activity exe- cution the needed resources are collected and at the end all the freed resources will be returned to the pool of idle resources and will be available for further use. The graphical representation of relations between the introduced notions is depicted on Fig 1. Fig. 1. Model Our workflows are Petri nets created using five basic refinement patterns, proposed in [PCh03]: sequential-split of a place or transition, parallel-split of a place, choice-split of a transition and loop-split which attaches the spawned transition with a self-loop to a place. The additional rule for attaching a resource place is dual to the loop-split. It just glues a freshly created (resource) place to a transition by a self-loop. From the Petri net perspective we assume here that such place will contain initially a token for each physical resource available. We call the places created by such splits resource places or activity places. One cannot refine resource places. Even if the transition is refined, the resource will be allo- cated at the beginning of its execution and released, when it is done. Moreover, every resource place will carry the set of requirements defined for corresponding 238 Petri Nets & Concurrency Chrzastowski-Wachtel and Rauch activity. If we match the resource places with activities accordingly, we will see, that the requirement assignments are defining the FAQ function. When we use activity refinement on a transition, which is inside some other activity, we will create a nested activity. By its ancestor activity we call every other activity, in which this one is nested. Such nested activities do not differ from any other activities, except for the fact, that these can use resources from its ancestors, as long, as the resource will not have one of its roles assigned to requirements in two different activities. 3 Tool overview The main goal of this work is to provide a a tool, which can be helpful in improving the resource management. We concentrate on optimization of the workflow execution by providing the user with relevant statistical information and letting him make decisions on resource-to-activity assignments. To achieve this, a Petri net defining a workflow with activities and resources, will be created. For this purpose we introduce a Workflow Designer. It is the editor for building workflows using refinement patterns. In the editor we create activities, declare the set of requirements and approximate execution duration. On the other hand, we have Resources Editor. We use it for defining a pool of resources, assigning roles to them, and determining their effectiveness in each role. The set of defined roles can be modified by an always-visible editor Roles Viewer. All these three editors form the static part of the tool. Its more detailed description is presented in section 3.1. After defining the model in the static part, we can proceed to the dynamic part of the tool. We will use Generator, to create sufficent number of random runs. When this is done, the Simulator, the Report Viewer and the Bucket Editor shows up. The first one displays a copy of our workflow, where resource places contain both the requirements and lists of currently available resources, fulfilling given requirements. Here, the tool provides us with information about expected time and cost of workflow completion for each of resource-to-requirement assign- ment we see. Basing on this knowledge we can decide, which resource should be assigned for current requirement. Every choice causes the expected values to be recalculated, so that we can run the workflow deciding, how resources should be used in the activities. The Report View presents detailed information about expected time and cost of workflow completion. It is synchronized with cur- rent simulator state, so all the values are always up-to-date. The Bucket Editor is a tool for storing, and presenting details of the runs, which were manually performed by user in the Simulator. For example, let us consider the following, simple case. There is a package, which must be delivered to the destination within an hour. We know, that stan- dard travel time by a scooter in current traffic would take around fifty minutes. We have two available scooter drivers: Evan and Gregory. Both of them can do the delivery, but Gregory has got his license for much longer time than Evan, and he shortens the expected delivery time by around 20 percent. Evan, on the A tool for modeling resource allocation Petri Nets & Concurrency – 239 other hand, is still afraid of driving fast and using tricky shortcuts, so his deliv- eries often take 20 percent longer than normal. However, Gregory’s earnings are twice the earnings of Evan. This is the classic case, where no optimal resolution to the problem exists. It must be up to user’s decision, whether time or cost is more important, and it is up to our tool to provide the user with information about expected cost and time consequences of each decision. We achieve it by simulating many thousands of runs and preparing the estimates with all aspects of the workflow taken into consideration, i.e.: activities order and dependencies, resources usage conflicts, possible time/cost variations. 3.1 Static Part To present the tool in more details, we introduce other, more complex example. Let us suppose, that we have two rooms: A and B. We need to plaster and paint both of them. Additionaly, room A needs to be decorated. Here we assume, that a room cannot be painted, unless it is plastered and it cannot be decorated, unless it is painted. Expected time units, required to complete these tasks for each room are following: – Room A — plastering: 20, painting: 10, decorating: 20; – Room B — plastering: 10, painting: 20. This process is presented on Fig. 2. We also need two resources, applicable for the work: Steven and Tom. Steven is an experienced painter, with a skill of plastering. Tom, on the other hand, is a decorator, who also can paint, but it takes him some more time that it does for Steven. The purpose of the static part of the tool is to model this situation, so that it can be then simulated and later analysed in the dynamic part. We will now explain, how it can be achieved using available functionalities. Resources Editor Defining resources consists of identifying the available set of people, machines and tools. For each of them, we can define a set of attributes like: use cost per time unit, collection of applicable roles (skills) and the effec- tiveness in each role. Every resource may have many skills, and many resources can have the same role. As it turns out, we often miss such knowledge during resources allocation planning and we do not take all the benefits from what a resource is capable of doing. Because of that, we can also miss the optimal reso- lution for given situation. Therefore we need to integrate all these aspects in the analysed context, so that we can consider consequences of particular situations with respect to most important factors. It is worth noticing, that in most popu- lar Human Workflow management tools like Tibco [BS07] or Corel iGraphix, as well as in some academical tools like Yasper [YA06], during the workflow design and simulation phase, the roles are treated as resources. No resource, can have two skills. This, for modelling purposes, is a major limitation. It means, that one resource will never be requested for two activities with different required roles, which tightly limits analysed possibilities. In our tool there are no such boundaries. 240 Petri Nets & Concurrency Chrzastowski-Wachtel and Rauch Fig. 2. Sample net A tool for modeling resource allocation Petri Nets & Concurrency – 241 Fig. 3. Resources edition Fig. 3 presents the pair of our resources: Steven and Tom. The interface is straightforward and it uses drag and drop features across almost every view. At the depicted state of modeling Steven lacks the plastering skill yet. In order to add it, we type plasterer in Roles View, press Add role button, drag the newly created role from this view and drop it over the Steven entry. New skill would get all of the necessary attributes initialized to default values. At the bottom of the window, we can see the Properties tab, which, as a context panel, allows us to modify attributes of currently selected object. The information about Steven’s efficiency as a painter (Time Cost row) is displayed here. To be consistent with the descritpion, we should change this value from 1.0 to 0.8. This indicates that activity performed by Steven in a role of painter could take 20 percent shorter than normal. We repeat similar scenario for Tom, associating with him the role of painter and decorator and setting the efficiency coefficients for each of these roles. Expenses for each person should be defined also here. Workflow Designer In the presented tool we can model sound workflows using refinement patterns presented in [PCh03]. To make this process easier it is pos- sible to apply these patterns to any node the refinement tree, including the inner ones. Each node can also have its subtree truncated. The structural approach has been chosen to simplify both the design process and the inner application processing engine. In this tool we introduced the basic set of six refinements. 242 Petri Nets & Concurrency Chrzastowski-Wachtel and Rauch These might be extended in future by other patterns like communication or synchronization patterns described in [PCh03]. Editor offers additional operations for collapsing and expanding nodes, ac- cording to the information held in the refinement tree, so we can view our net at desired level of detail. The application displays all the nodes automatically in the viewer, but we can also move them around manually. The process from the exam- ple, has been created using refinement patterns, as shown on Fig. 4. Currently the B:[[plasterer]] resource place is selected, so that we can see, which requirements are defined for this requirement place in the bottom right tab Requirements (in our case all resource places will be labelled hroom namei:[[hrequired rolei]]). As it was mentioned earlier, resource places are created by the ACTIVITY pattern, and cannot be further refined. Each resource place is associated with exactly one activity, so it is the right place to hold all the needed requirements for activity. The whole net has been built using only the SEQUENCE, CONCURRENCY and ACTIVITY patterns. On the Fig. 5, all possible refinement operations are presented both for each standard place (not resource place) and each transition. Every transition has got a special property, a measure, which describes its desire to be executed. We can modify this value to indicate transitions, which should have higher/lower probability of being executed, when in conflict with some other ones. This value is used only when at least two transitions are in conflict. By default this value is set to 1, but if we wish to make some transition to be executed more often, this value should be set accordingly. For instance if we have two active transitions, one with this value set to 3, and the second one to 1, then the first of them will be fired with 75% chance. This way we can declare, which actions are more probable or what kind of situations occur more often. 3.2 Dynamic Part Statistics Generation Generator is a tool for preparing a list of complete runs with respect to guidelines defined in a workflow project and resources set. For this purpose, a special, extended copy of the designed workflow is created. Apart from copies of all the elements created by the designer, there are additional resource places for automatic resource availability management. It is guaranteed, that before each run, the whole net will be reset. Allocation decisions taken between two different runs are then mutually independent. It can happen that two identical runs could be generated by chance. Each run is executed and recorded using the following algorithm. Initially, the in place of a workflow, is marked by a token, as well as there are tokens in the resource places. In a loop, a complete set of active transitions (activities) is constructed. If the set is empty, and the workflow is finished (a token is present on out place of the workflow), then the run is stored, the token from out place is moved to back in place. If there are at least two enabled tran- sitions, one of them is randomly chosen (according to its desire to be executed ). The selected enabled transition is fired and the loop is repeated. Note, that some A tool for modeling resource allocation Petri Nets & Concurrency – 243 Fig. 4. Designer of these transitions will indicate the begin or end of some activity. In such case an additional resource acquistion or return will be performed. When the generator attempts to start an activity, all the requirements are being covered by skills owned by resources assigned to it. When we start one ac- tivity, some other can also start or end, so the tool can model various concurrent situations. When an activity ends, assigned resources are freed, the generator updates the workflow timer, the amount of time and cost counters for later anal- ysis. A series of runs allows us to consider usefulness of certain choices in the context of further possible events. The working time of the generator is dependent mostly on the number of allocations and releases of resources, which corresponds to one run. The com- putation power is also very important. In our case the generation of 10000 (ten thousand) runs on a standard computer takes no more than a few seconds. 244 Petri Nets & Concurrency Chrzastowski-Wachtel and Rauch Fig. 5. Refinement patterns Simulator Taking into account possible allocation decisions, we analyse time and cost of a workflow run. A few similar simulation tools have been reviewed in [BPM05]. On that basis some of the functionalities have been adapted to this tool, and a few flaws have been evaded. As a result, the application provides the simulator of the given net, and gives us a browser of performed runs. In the report viewer (described later), we can browse all the runs created during generation. All these runs have been performed automatically, so using sorting capabilities of the report viever, we can easily find the optimal runs. Sometimes the differences in evaluation are very small, and the user may wish to examine the non-optimal allocation. For such purposes the simulator allows us to perform a step by step manual run of the designed net. An estimated time and cost of the run completion for every resource-to-requirement assignment at currently chosen state is presented. Thanks to this we know, which consequences are a result of our decision. The simulator remembers all the choices (resource assignments, order of activities start and end times) that a user makes during a simulation. It uses this knowledge to find all the statistical runs that are applicable to this situation, and then provides us with the estimates. Note, that in neither of Tibco, iGraphix nor Yasper, such manual interference in resource assignments is possible, because all resources in these simulators can have only one role. Moreover, up to the authors knowledge, there is no other tool, which supports simulation of resources with multiple roles, giving the user a chance to take part in a simulation at such informative level. Let us suppose that a simulation has come up to a situation shown on the Fig. 6. The tokens presence on places Room A and Room B means that the Initialization phase has already ended. As we can see, enabled transitions have double-lined border. At the moment both A:Plaster and B:Plaster transitions require the same skills (in our case: plasterer ), which have been defined in the corresponding places: A:[[plasterer]] and B:[[plasterer]]. Both places contain no tokens, which means, that no resources have been assigned to these activities yet. Currently selected place A:[[plasterer]] shows in the Properties View all the possible resource assignments for the plasterer skill. As it turns out, only Steven is suitable. Next to his name there is some information indicating the estimated cost and time of the run completion, with him taking part in this activity. In our example, Steven’s Cost : [1038 − 42.14] 970|1034|1050|1050|1084 T ime : [63 − 9.44] 50|56|70|70|72 means: A tool for modeling resource allocation Petri Nets & Concurrency – 245 Fig. 6. Simulator – average cost of completion is 1038 units with standard deviation of 42,14; – average costs of completion in five successive quantiles are: 970, 1034, 1050, 1050, 1084; – average time of completion is 63 units with standard deviation of 9.44; – average times of completion in five successive quantiles are: 50, 56, 70, 70, 72. When we select the B:[[plasterer]] place, the estimates for Steven’s change to Cost : [1004 − 44.44] 950|988|1000|1011|1075 T ime : [65 − 8.73] 60|60|60|69|80. So, starting work in room A will cost us more, but it will shorten the total execution time. Knowing this at such an early stage lets us undertake proper decisions from the very beginning. On that basis we may tend to choose room A first, if we want to save time. On the other hand, when cost is being considered crucial, we should choose beginning work from room B. 246 Petri Nets & Concurrency Chrzastowski-Wachtel and Rauch When all requirements are met, the corresponding activity becomes active. We can fire such enabled transition, and move to the next activity, where we will have more decisions to make. Note, that at every time, we make a decision or fire a transition, the estimates are being recalculated, to show the current situation in the net. This rule also applies to the Report Viewer. Report Viewer Much more information about current situation in the simu- lated net can be seen on additional report view. The sample screenshot on Fig. 7 presents the state of report viewer, when Steven has been assigned to A:Plaster activity in the simulator. Thanks to synchronization between these two tabs, we can always take a look at all the computed details and expected values. Diagrams on the 7 present: – Total cost distribution — average, cumulative cost of run performance in current simulator situation in 10 successive quantiles; – Resources cost distribution — as above, but for each of the resource; – Total time distribution — average time of run performance in current simulator situation in 10 successive quantiles; – Resources time distribution — as above, but for each of the resource. Diagrams of total cost and time provide us with information about differ- ences between optimistic and pessimistic run executions. When viewing costs of resources, we can see, which of them have major influence on the growth in pessimistic cases. In the example shown above it is a fact that, when considering cost, in the optimistic case (on the left side of the diagram), Steven involvement is minimal, and the cost of Steven’s work even goes below the cost of Tom’s work. On that basis we can conclude that the main way to cut the cost will be to maximize Tom’s involvement and minimize Steven’s. It can be seen that bigger involvement of Steven means smaller involvement of Tom and vice versa. So if time does not matter we will prefer the cheaper resource. The distribution of resource involvement time gives us somewhat different conclusions. It cannot be explicitly determined whether one of the resources should be favoured to improve the process duration. It may seem at a first glance, that in order to optimize the run we should always choose the fastest resource. But it is not the case, since it can slow down other parts of the workflow. The faster one can be the only one who can perform another action which should not be delayed. Two additional tables at the bottom of this view present: – list of runs, which are up to date with current situation in the simulator (including time and cost of them as well as pointing out the three most busy resources); – list of successive concurrent events for the run selected in the first table. A tool for modeling resource allocation Petri Nets & Concurrency – 247 Fig. 7. Report viewer 248 Petri Nets & Concurrency Chrzastowski-Wachtel and Rauch Bucket Editor To ease the efforts, and allow the user to store the most inter- esting runs for further analysis, a simple Bucket Editor has been created. After the simulation comes to an end, the user can store the run he has just performed manually. This run will be available for later view. The bucket presents informa- tion similar to the report viewer, but because it contains information for several, manually chosen runs (not thousands like report viewer), those can be presented in a slightly different form. Fig. 8. Bucket viewer Fig. 8 shows a screenshot of the bucket with two stored runs. As we can see it is organized similarly to the report viever, and the visible diagrams present the same information as those from report viewer: – Total cost — total cost of execution each of the stored runs separately; – Resources cost distribution — as above, but for each of resources; A tool for modeling resource allocation Petri Nets & Concurrency – 249 – Total time distribution — total time required to complete each of the stored runs separately; – Resources time distribution — as above, but for each of resources. The bottom tables represent information about stored runs, showing exactly the same attributes and properties, as the report viewer does. First of them (displayed on the left hand side of every diagram) has been performed with the goal to minimize the time. Second, though, was made to run the process as cheap as possible, ignoring the time at all. As we can see, the cost reduction requires extra time in workflow execution. Of course, increasing the execution speed increases the cost. Major differences can also be seen in the resource usage distribution in both of these cases. Cost reduction has led to a significant decrease of Steven’s involvement. In this case, Tom takes some of his responsibilities. When the time was the goal, the proportions has significantly changed. Steven became more desired, because Tom seemed cause the most delays. 4 Conclusions and future work The provided example shows, how largely the work organization can differ, de- pending on goals that we want to achieve. In many cases minor changes in the resource allocation can have large influence on the overall result and, conversely, sometimes major allocation changes result in very similar outcomes. Very often humans do not take under consideration all the aspects, which the presented tool does. Its role is to simplify this whole process and make it easier, to find a suitable organization plan that will fit our needs and fulfill the criteria. While the simplification of resource allocation planning is one point, the other one is the possibility to point out uncommon executions, which can lead to increased effectiveness and so increase our profits. Combining user’s knowledge and com- puter’s computation power could therefore lead to major design corrections, which would be a basis for further business improvements. The presented tool is still a prototype, and there are some practical and theoretical issues that need to be addressed. On the theoretical side additional extensions to resource and workflow definition language should be introduced. This includes further conformance to the form of resources described in [BPS09], because only a few resource attributes have already been implemented in this tool. There is also a big potential of the currently used workflow language, which can be further extended. In the context of statistical data tooling, some addi- tional information could be presented (e.g. the Student’s t-distribution, 3 − σ). Finally, no measure of reliability have yet been introduced and, in the sense of realism of modelled cases, this is one of the major flaws of the presented tool. On the more practical side, the integration with existing systems and methods should be made. First of all the statistical runs of the net could generate logs from the run to make them readable by other applications in the same way as the YAWL does [WS09]. The conformance with CPN seems attractive, because of its formal basis and constant development. Secondly, the integration with currently 250 Petri Nets & Concurrency Chrzastowski-Wachtel and Rauch used common tools is to be made as well. The LDAP for instance is a main source for human resource information. The reporting tools like Microsoft Dynamics AX (Microsoft Business Solutions – Axapta) can be a source of information about resource experience and effectivness of each of such resource. Any other form of gathering of knowledge about past and predictable future resource usefulness can become important in such case. Therefore more integration of this tool will be examinated and developed in the future. Acknowledgment The authors would like to thank the reviewers of this work for the effort they put into improving the paper by the constructive reviews, which resulted in a thorough revision of the paper. Tool description The tool is written in Java and can be run on any machine with Java (JRE 6.0) installed. It can be downloaded from the http://duch.mimuw.edu.pl/˜pch/IRSMT/irsmt.zip. The zip file contains a full version of the tool and a README file, which explains how to install and use the application. References [PCh03] Piotr Chrza̧stowski-Wachtel, Boualem Benatallah, Rachid Hamadi, Milton O’Dell, Adi Susanto, Top-down Petri Net Based Approach to Dynamic Workflow Modelling, Lecture Note in Computer Science. v2678. 336-353., 2003. [BPM05] M. Laugna, J. Marklund. Business Process Modeling, Simulation, and De- sign. Prentice Hall, Upper Saddle River, New Jersey, 2005. [YA06] Kees van Hee, Olivia Oanea, Reinier Post, Lou Somers, Jan Martijn van der Werf, Yasper: a tool for workflow modeling and analysis, Application of Concurrency to System Design, International Conference on, pp. 279-282, Sixth International Conference on Application of Concurrency to System Design (ACSD’06), 2006. [BS07] Bruce Silver, Bruce Silver Associates, The BPMS Report: TIBCO iProcess Suite 10.6, BPMS Watch www.brsilver.com/wordpress, 2007. [BPS09] W.M.P. van der Aalst, J. Nakatumba, A. Rozinat, and N. Russell. Business Process Simulation: How to get it right? In J. vom Brocke and M. Rosemann, editors, International Handbook on Business Process Management, Springer-Verlag, Berlin, 2009. [WS09] A. Rozinat, M. Wynn, W.M.P. van der Aalst, A.H.M. ter Hofstede, and C. Fidge., Workflow Simulation for Operational Decision Support., Data and Knowl- edge Engineering, 68(9):834-850, 2009.