Simulation is widely used as a tool for analyzing business processes but is mostly focused on examining rather abstract steady-state situations. Such analyses are helpful for the initial design of a business process but are less suitable for operational decision making and continuous improvement. Here we describe a simulation system for operational decision support in the context of workflow management. To do this we exploit not only the workflow’s design, but also logged data describing the system’s observed historic behavior, and information extracted about the current state of the workflow. Making use of actual data capturing the current state and historic information allows our simulations to accurately predict potential near-future behaviors for different scenarios.
Figure 1 provides an overview about the data sources and steps involved in generating a simulation model with the ProM framework. There are three types of simulation-relevant information that can be extracted from a workflow system like YAWL: (1) design information that is used to configure the information system and enact the operational process (i.e., a process model including data flow specifications and roles required to perform certain tasks), (2) historic information (i.e., an event log containing recordings about activities and cases that were executed for this process in the past), and (3) information about the current state of the workflow system (i.e., cases that are currently being handled by the system, people that are currently available etc.).
As shown in Figure 1, we use the design and historic information to generate a simulation model in terms of a Coloured Petri Net (CPN). We then support the direct loading of the current state into that model by an external file (ProM generates an empty initial state file that simply needs to be replaced by the actual current state file that should be loaded).
To generate the model, four basic steps need to be performed within ProM:
- The workflow, the organizational model and the event log are imported from the YAWL workflow system and analyzed.
- Simulation-relevant information from the organizational model and log analysis are integrated into the YAWL model.
- The YAWL model is converted into a Petri net model (because our simulation tool is based on Coloured Petri Nets).
- Finally, the integrated and converted model is exported as a CPN model.
Figure 2 depicts four selected steps of the simulation model creation in ProM.
It shows the log window after importing the MXML log (bottom-right), and the result view of the Basic Log Statistics plug-in, which extracts case arrival rates, execution time statistics, and data value range distributions from the log (top-right).
The extracted information is then provided as a so-called high-level process. With high-level information we refer to process information beyond the pure control flow, i.e., additional information like data and time that can be either attached to the process as a whole, or to certain elements in the process. It can also be manually adjusted by a plug-in called View/Edit High level Process. These three parts are then merged and the YAWL control flow structure is transformed into a Petri net representation. The result of the integrated and converted data is shown in window (top-left).
The last step is the actual simulation model generation based on the integrated high-level process model in ProM (bottom-left). Several options are available to configure the CPN model such as providing current state support, including monitors for auxiliary analysis etc.
Note that the CPN models can be generated with the capability of recording MXML logs during simulation, which enables the analysis of both actual process logs and simulation logs in a unified manner (represented by the arc from CPN Tools back to ProM in Figure 1).
Note also that both the MXML format (used for event logs) and the OrgModel format (used to store organizational models) are standardized and could be exported by other operational systems. Only the YAWL import would need to be replaced by a custom import component to support the approach for, e.g., another type of workflow system. Furthermore, missing design information can be approximated by mining techniques (e.g., discovering process models, decision rules, and organizational roles from the event log only).
TutorialYou can follow the approach based on the running example as described in the Tutorial Section of our technical report.
Example filesYou can download these example files and follow the steps described in the tutorial. The archive contains the following files:
- WorkflowModel.ywl is the YAWL editor file.
- WorkflowModel.xml is the YAWL engine file (exported from the editor).
- YAWLOrgModel.xml is the Organizational model file (extracted from the YAWL engine).
- YawlLog.mxml is an Event log that has been extracted from the YAWL engine. Since our running example has been manually enacted to produce these logs, there are not too many cases and it lacks realistic timing behavior. Therefore, we also have this SimulatedLog.mxml.
- The initialstate.sml is the Current state file (extracted from the YAWL engine). As described in the tutorial, it needs to be renamed according to the name of the generated CPN model before it can be loaded.
-
Workflow Simulation for Operational Decision Support using YAWL and ProM
A. Rozinat, M. T. Wynn, W. M. P. van der Aalst, A. H. M. ter Hofstede2, and C. J. Fidge
BPM Center Report BPM-08-04, BPMCenter.org, 2008 -
Workflow Simulation for Operational Decision Support Using Design, Historic and State Information
A. Rozinat, M.T. Wynn, W.M.P. van der Aalst, A.H.M. ter Hofstede and C.J. Fidge.
In M. Dumas, M. Reichert, and M.-C. Shan (Eds.): BPM 2008, LNCS 5240, pp. 196–211, Springer-Verlag Berlin. -
Workflow Simulation for Operational Decision Support
A. Rozinat, M.T. Wynn, W.M.P. van der Aalst, A.H.M. ter Hofstede, and C.J. Fidge
Data & Knowledge Engineering, Vol. 68, pp. 834-850, 2009