Simulation for Business Process Management
Last week I presented the topic of Simulation for Business Process Management at the Workflow Management Coalition‘s annual global user group event for implementers, developers and practitioners of the XML Process Definition Language for BPM Notation (XPDL4BPMN).
Business process simulation allows one to estimate the behaviour of a process when experimentation with the
real system under study would be disruptive, cost prohibitive, or where a real process does not yet exist. It’s conceptually easy to understand, and a compelling tool for business management. My presentation was based on an question and an observation. The question: if simulation makes so much sense intellectually, why aren’t business managers using simulation all the time? The observation: standards exists for the process definitions required by simulation scenarios, but none exist for specifying the rest of the parameters required by simulation scenarios (like the volumes and arrival patterns of work, activity durations and resource availability).
The presentation tried to answer the above question by outlining the current deficiencies with business process simulation:
- A lack of suitable skills to develop meaningful simulation models.
- Inadequate simulation tools.
- Over simplified models.
- Indirect (or non) use of available artifacts.
I then described how a standard for specifying business process simulation scenarios could help address these issues. The slides from the presentation are below, however, these slides are more in the Presentation Zen style and are meant to be visual backdrop to my talk which was the actual content. Therefore there isn’t much content in the slides themselves. I’d like to make them available anyway.
Sim4BPM Featured in the BPMN 2.0 Handbook
Sim4BPM has been featured in the newly published BPMN 2.0 Handbook. Authored by key participants in the development of BPMN 2.0, the BPMN 2.0 Handbook brings together industry thought-leaders and experts in BPMN. The handbook introduces what is new in BPMN 2.0, and examines interchange, analytics, conformance, optimization, simulation and more from both a business and a technical perspective.
We’re thrilled to be a part of the book. Here’s the abstract from the chapter Simulation for Business Process Management:
Simulation is a traditional analysis technique in operations management. In the context of Business Process Management (BPM), simulation models can be used to perform “what-if” analysis of process designs before they are implemented, or test changes to processing parameters before they occur, such as an increase in the volume of work to be processed. Simulation in some form is supported by many Business Process Management Suites (BPMS), as well as other process oriented analysis tools. Besides process definitions, simulation models require additional data to define a scenario such as volumes of work and arrival patterns, task processing times, resource levels and availability, and descriptions of other external events that impact the work flow. Currently there are no specific standards for business process simulation.
This chapter provides an overview of business process simulation, the types of information required to define a business process scenario for the purpose of simulation, and a proposed standard for defining simulation scenarios that is compatible with the Business Process Modeling Notation (BPMN) and XML Process Definition Language (XPDL). The chapter also describes how a RESTful web services API can be developed to support the standard. By providing a standard interchange format and/or a standard API, various artifacts currently available in the event logs of BPM systems could be used to generate baseline simulation scenarios useful in operational decision making and addressing near term processing issues, as well as long term process design.
Using the Sim4BPM Client Libraries
We’ve started work on client libraries to help developers create applications that use the Sim4BPM schema. Currently, there is a .NET library. The library consists of an object model for the Sim4BPM schema. This allows developers to programmatically create business process scenario objects, or components of a business process scenario (for example, a set of activity parameters). It also allows developers to serialize their objects to xml that conforms to the Sim4BPM schema, as well as create objects from xml.
Here’s a quick and dirty sample: we’ll create a (very simple!) business process scenario in .NET and serialize it to an xml file. We’ll then read the resulting xml file into a new business process scenario object and read one of the properties of the scenario – it’s name:
1: using System;
2: using System.Collections.Generic;
3: using System.Text;
4: using System.IO;
5: using System.Xml.Serialization;
6: using Sim4bpm.ScenarioDefinition.ObjectModel;
7:
8: namespace Sim4bpm.Test {
9: class Program {
10: static void Main(string[] args) {
11:
12: // programmatically create a new scenario
13: Scenario testScenario = new Scenario();
14: testScenario.Name = "Test Sim4BPM Scenario";
15: testScenario.Author = "John Januszczak";
16:
17: // serialize the scenario to an xml file
18: XmlSerializer serializer = new XmlSerializer(typeof(Scenario));
19: TextWriter writer = new StreamWriter("testscenario.xml");
20: serializer.Serialize(writer, testScenario);
21: writer.Close();
22:
23: Console.WriteLine("Scenario serialized.");
24: Console.WriteLine("Press enter to continue.");
25: Console.ReadLine();
26:
27: // deserialize a scenario object from the xml file
28: TextReader reader = new StreamReader("testscenario.xml");
29: Scenario myScenario = (Scenario)serializer.Deserialize(reader);
30: reader.Close();
31:
32: Console.WriteLine(myScenario.Name);
33: Console.WriteLine("Press enter to quit.");
34: Console.ReadLine();
35: }
36: }
37: }
Here’s the xml that was generated by the above code:
1: <?xml version="1.0" encoding="utf-8"?>
2: <Scenario xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
3: <Name>Test Sim4BPM Scenario</Name>
4: <Author>John Januszczak</Author>
5: <Created>2010-10-06T13:17:51.3125-04:00</Created>
6: <Modified>2010-10-06T13:17:51.3125-04:00</Modified>
7: <Editor />
8: <Context IsCalendarBased="true">
9: <Start />
10: <End />
11: <ClockUnits>Minute</ClockUnits>
12: <SchedulingMethod>Concurrent</SchedulingMethod>
13: <ResourceSelection>Performance</ResourceSelection>
14: </Context>
15: <Simulation>
16: <Seed Type="System" Value="0" />
17: <Animation>Off</Animation>
18: <Initialization />
19: <Termination />
20: </Simulation>
21: <Events />
22: <Resourcing>
23: <Roles />
24: <Resources />
25: </Resourcing>
26: <Activities />
27: </Scenario>
Specification Update
A quick note regarding recent updates to the Sim4BPM specification: an XML schema has been initiated based on the draft specification. The schema is incomplete, however the following components of the specification are reflected in the schema:
- Scenario meta data
- Scenario Context
- Simulation Options
- Events
The schema does not as yet include the following components of the specification:
- Resources
- Activity Parameters
We’ll be working to complete the XML schema to reflect the entire draft specification in the next few days.
Update!
The XML schema is now complete and reflects the entire draft specification.
What Makes Up a Business Process Simulation Scenario
Given the goals of Sim4BPM, it is natural to ask what kind of information is required to adequately describe a business process scenario. What is the recipe for such a scenario? On approach is to look at how existing business process simulation software define scenarios. Another approach is to find out what experts in the field of business process management and simulation have to say about it. Call it empirical vs. theoretical. Thankfully both converge on a similar set of requirements. Since an enumeration of various simulation applications was the basis for the first draft of the Sim4BPM specification, I thought we might take a brief glance at the latter path.
In his paper Business Process Simulation Revisited [1], Wil M. P. van der Aalst suggests at least three sets of data (or perspectives) are required in order to simulate a business process:
- Control Flow
- Data/Rules
- Resource/Organization
The control flow perspective describes the ordering of activities. Activity order may be sequential, or depend on splits, joins and/or loops in the flow of work. The data/rules perspective describes decisions made within a process and the data upon which these decisions are made. The resource organization perspective describes the allocation of activities to resources, the availability and other properties of the resources and organizational boundaries.
In their paper Business Process Analytics [2], Michael zur Muehlen and Robert Shapiro also describe the requirements for simulating business processes. They describe the control flow perspective as the Process Definitions. Since resources may participate in more than one business process, it might be useful to include multiple processes in a simulation scenario. They also provide structure to the resource/organization perspective. Roles are used to describe functions performed and the skill required to carry out these functions. In this way, resources can be described as performing work in these roles, where resources could be human, equipment or systems. The availability of resources (and therefore roles) can be modeled by specifying shifts, as well as efficiencies for each resource. Finally, they expand the Data/Rules perspective and break that down into the following components:
- Incoming Work
- Activity Details
- Routing Information
Incoming work, or arrivals, describes when work to be processed arrives into a business process and the attributes of the work that will impact how the work is processed or routed through the process. Activity details describe additional properties of the activities not captured in the process definition, but pertinent to simulation such as the duration of an activity which may be a simple value, a complex expression based on the attributes of the work (originally defined in the incoming work and perhaps modified during the work flow), or based on some kind of distribution function. Routing information refers to information not included in the process definition that may further describe under which conditions certain paths in the work flow are taken. While routing information is usually based on rules specified in the process definition or control flow, these may instead be represented by percentages that reflect the likelihood of a certain result in a simulation model.
Sim4BPM builds upon the descriptions in its attempt to formalize the description of a business process (simulation) scenario. In fact the descriptions above can be readily mapped to sections in the Sim4BPM specification:
- Control Flow / Process Definitions = BPMN Process Model
- Incoming Work = Events
- Activity Details = Activity Parameters
- Routing Information = Activity Parameters
- Resource/Organization = Resources
Sim4BPM simply formalizes the definition of what is already accepted as the types of information required to define a business process simulation scenario.
Photo Credit: Mel B.
[1] Aalst, Wil M.P. “Business Process Simulation Revisited.” Enterprise and Organizational Modeling and Simulation 6th International Workshop, Eomas 2010, Held at Caise 2010, Hammamet, Tunisia, June 7-8, 2010, Revised Selected Papers. Springer Verlag, 2010.
[2] Zur Muehlen, Michael, and Robert Shapiro. “Business Process Analytics.” Handbook on Business Process Management. Berlin: Springer-Verlag GmbH, 2009.
What Didn’t Happen At Process.Gov
Back in April, I was scheduled to give a talk at process.gov on how to use simulation with BPMN based models: best practices, misperceptions & pitfalls. Part of that talk was about Sim4BPM and the effort to develop a standard for defining business process scenarios. Two days before the conference I broke my leg and alas, could not attend. So here are the slides and the speaking notes from the talk I was going to give. Enjoy!
There is much more detail in the speaking notes, which I recommend you download to accompany these slides. This material is very similar to the story behind Sim4BPM.
Welcome to Sim4BPM!
I’ve been involved in business process modeling and simulation for over 15 years, both as a business practitioner and software developer. While there has been attempts to standardize the way we capture and document business processes, from IDEF0 to BPMN, I’ve noticed that there has not been a similar attempt to try and standardize the kinds of data required to simulate a business process. Regardless of specific simulation tools, the types of data required to set up a working simulation are fairly consistent:
- a description of the process (this is the part that they have tried to standardize!)
- the business rules for processing work (in fairness, this can be, and often is, captured in a business process diagram)
- a description of the specific events that occur in a business process in a specific time frame
- a description of the work that will be processed
- a description of the resources that will be used to process the work
I’ve also noticed that other domains that traditionally fall outside of business process management (BPM), like workforce management and activity based costing consume the same, or a portion of the same kind of data that is required to simulate a business process. All three of these applications: simulation, workforce management, and activity based costing are all based on business process scenarios.
Business Process Scenarios consist of a business process definition and a set of scenario parameters that define the events that occur, the work that is processed and the resources that are used to process work during a specific time frame and/or within a specific context. BPM solutions that offer executable work flows often capture the historical and/or real time values of these parameters. For simulating “what-if” or forecast scenarios, these values are often based on historical data, but modified to test assumptions or speculations regarding the future state of a business operation.
While there has been considerable effort in standardizing process diagrams (e.g. BPMN), there has been little to no effort in standardizing the description of events and the other parameters that are required to completely define a scenario as described above. Sim4BPM is an attempt to standardize business process scenario definitions, specifically providing a formal way to describe the events, instances of work and resource instances that define a scenario.
For more background, please read The Story Behind Sim4BPM. In the mean time, you can subscribe to Sim4BPM or follow me on twitter to stay up to date on any developments regarding this standardization initiative. If you are involved in BPM, business process simulation, or other business scenario based applications like workforce management, you might like to get involved with Sim4BPM. It would be great to hear from you!