This document discusses business process simulation and proposes a standards-based approach. It summarizes key criteria for effective simulation called the "Silver Criteria" and argues that most BPMS tools provide limited, unrealistic simulation capabilities. The document proposes defining simulations using a process model like BPMN coupled with a standard scenario definition language to specify parameters. This would provide a vendor-neutral API and allow simulations to be defined and shared independently of specific tools.

2. The Simulation Summit
At 8,848 m (29,029 ft), Mount Everest is the highest point on earth. Once simply known
as "Peak 15", the mountain was named after Sir George Everest in 1865 ,the once
British surveyor-general of India. In 1953, the New Zealander Edmund Hillary and Tenzig
Norgay of Nepal became the first to ascent to the top of the world. Since then, there
have been 4,102 ascents, and Everest has claimed 216 lives.
Mount Everest also sits on the border between China and Nepal. Most people climbing
Everest follow the southeast ridge from Nepal. It is technically easier, and is in fact the
route that was used by Hillary and Norgay. However, this route was dictated more by
politics than by design as the Chinese border was closed to the western world in the
1950's. It turns out that Everest can also be climbed along the northeast ridge from
China. In fact, since there has been access to the Chinese side, many ascents start from
there.
This provides a decent metaphor for business process simulation. The ascent to this
capability has typically been made by business process management suite (BPMS)
vendors wishing to satisfy the criteria of Gartner's "Magic Quadrant" for BPM suites
which includes the following requirement:
Process simulation and optimization using real-time, historical and estimated
1
data values.

3. A Fake Feature
In attempting to provide simulation functionality, it would appear that most BPMS and
BPMN process modeling tool vendors have taken the apparently logical (or perhaps
technically convenient) route of starting from an existing BPMN process model editor and
adding on simulation features. The result is often a simulation capability of limited value,
to the point where BPM commentator Bruce Silver describes simulation provided by BPM
2
vendors as a fake feature .
Bruce goes on to articulate some of the criteria under which simulation could be
considered a real feature of BPMN process modeling software. According to Bruce, BPMN
tools with simulation capabilities support the following to varying degrees, but none
3
appear to support a critical mass of what I will call the Silver Criteria :
Activity Duration
Actual activity duration consists of the actual time spent processing an item of work at
an activity (the "active time") and the time an item of work waits (the "lag time") at an
activity before being processed due to a queue of waiting work, limited processing
1. Magic Quadrant for Business Process Management Suite, 2007. Gartner Core
Research.
2. See Is Simulation Fake? by Bruce Silver, BPMS Watch (http://www.brsilver.com/
wordpress/2007/03/08/is-simulation-fake/)
3. This list has been compiled based on various posts in Bruce Silver's BPMS Watch. For
example, see http://www.brsilver.com/wordpress/2007/03/08/is-simulation-
fake/ and http://www.brsilver.com/wordpress/2009/02/15/making-simulation-useful/

4. capacity at an activity (e.g. a physical constraint) or the required processing resources
being unavailable. The ability to both model and report on both of these components of
the activity's total duration is a real world requirement, often ignored by many
simulation tools.
Events
Simulation needs to model event probability and time of occurrence. In BPMN, events
provide a visual representation for describing the exceptions that occur in real life
processes. Such exceptions are often the root of performance issues in existing
processes. To accurately model what-if scenarios, the ability to assign a probability and
mean time of occurrence for events defined in the process model is a requirement. Most
simulation tools simply ignore events.
Iterative Activities
BPMN supports two types of repeating activities: looping and multi-instance that
represent feedback based on a condition or size/components of the item of work.
Simulation must model the number of iterations based on a parameter or property of the
work being processed.
Instance Attributes
In most simulation tools, probabilities assigned at various nodes (e.g. activities or
gateways) are uncorrelated. In actuality, these probabilities are usually highly correlated
in real world business processes. Specifically, the duration of a particular activity, the
probability of a particular gateway output, and/or the probability of some event
occurring are often related to each other. For example, the longer an activity takes (e.g.
scanning documents), the more likely an exceptional event might occur (e.g. a jam).
One needs to be able to specify simulation parameters as an expression of one or more
instance attributes, such as "size" or "claim value", which could take specific values
rather than simple numbers like an absolute value or a mean and standard deviation.
While this makes defining a scenario to simulation more complex, it stands to provide
more realistic output.
Schedules & Resource Contention
In business processes, an activity will only be executed when work and resources are
available for the activity in question. The availability of specific resources, whether
human, machine or otherwise, is driven by their schedules and contention for equivalent
resources by other activities. Simulation software should accurately model resource
contention and allow detailed schedules to be defined for all resources which show when
they are available to work in specific roles, or specific sets of activities.
Contingent Resource Assignment
Most simulation tools let you assign roles to activities. However, business processes are
often characterized by contingent resource assignment. For example, an activity may
assign Role A as the primary resource, but if no member of Role A is available, the
activity may pull a resource from Role B.

5. Priorities
It should be possible to base resource acquisition at various steps in a process based on
priorities, or some kind of priority logic. For example, oldest item in the pipeline gets
worked on first, of items get worked on based on an attribute of the work items. Priority
could be based on activity or an attribute of the items to be processed.
Pre-Population of Work in Progress
Simulation models generally start empty, reflecting no work present initially in the
system. This causes a distortion in the simulation results at the beginning of the
simulation period. Continuous processes are always in a state where resources are
already constrained by the work in progress. One method to address this situation is
with a warm up period where results are not collected until the system is "loaded" with
work. However, populating the simulation model with work in progress at the various
activities at the beginning of the simulation period best reflects reality.
Detailed Reporting & Data Access
Simulation results should provide breakdown of metrics at the process, activity, resource
and potentially work attribute level. Resource utilization and excess capacity should be
reported for any given period. There should also be access to the raw simulation output.
Pre-built metrics and charts provided by simulation tools are convenient but they rarely
provide the detail you need for real analysis. One should be able to access records for
each process instance, and for each activity or event instance. It should be possible to
import this data into a spreadsheet or a database.
Serious Simulation
Just like climbing Everest from the northeast ridge, there is another approach to
business process simulation. One starts on the other side: from the domain of serious,
robust simulation software that satisfies the "Silver" criteria a priori and then build in
support for authoring these simulations using BPMN process models.

6. This approach is similar to what Meta Software did in 1989. Meta developed a capability
to generate simulation models for their pre-existing industrial simulation software from
4
IDEF0/SADT process models . IDEF0 is a graphical modeling notation that provides the
syntax and semantics to diagram the decisions, actions, and activities of an organization
or system. A common application of IDEF0 was to document business processes, in the
same way that BPMN is used today. In 1989 IDEF0 was a promising emerging standard
for drawing business process diagrams. Perhaps, if this work had been done today, Meta
would have chosen BPMN as the process modeling methodology.
We can look to Meta's experience in developing IDEF0/SADT support for authoring
simulation models to understand how robust BPMN based simulation models that satisfy
the Silver Criteria can be made possible. The lessons learned in providing a way to
generate business process simulations from IDEF0 business process models can easily be
5
applied to BPMN . There are two significant considerations that have to be made when
exposing simulation through a process model diagram:
• There must be a generalized mapping of process diagram work flow patterns to
the underlying simulation code.
• Process models must be extended to include the specific assumptions that define
a scenario.
4. See: Modeling an NORAD Command Post Using SADT and Colored Petri Nets by
Valerio Pinci and Robert Shapiro.
5. In fact, this has been done. Meta Software's METAFORE supports simulation of
process models defined in BPMN via an XPDL interface.

7. Process Definition
Process model diagrams will support varying numbers of work flow patterns such as
sequential flows, exclusive gates, parallel processing, matching, etc. The work flow
patterns supported by the diagramming methodology have to be mapped to simulation
code in a generalized way. This usually results in code that is parameterized to reflect
the basic work flow pattern, yet support variation and correlation amongst the various
process instances (e.g. tokens of work) which will be populated into the simulation
model.
Scenario Definition
Secondly, the parameters and placeholders in the resulting simulation code have to
specified for each specific process instance. Common resources used to perform
activities in the process model need to be specified so that semaphores in the simulation
code constrain the availability of these resources to reflect schedules and resource
contention. These constitute a set of business process assumptions built into a given
scenario, and these parameters have a definite business sense, representing items that
would not be foreign to the average business user.

8. For example, we need to know when and where items of work will enter or "arrive" in
the process. To specify this, we need to capture the following types of data:
• The process the work item will arrive in.
• The destination activity. This is usually the model start or input point, but may
be any process activity when we are trying to simulate work in progress at the
beginning of the simulation period.
• Arrival times.
• Quantity if more than one unit of work item is arriving at this particular time with
the same attributes.
• Data field values. These represent the properties of the work item (process
instance) arriving into the process.
A Standards Based API for Simulation
Assuming that a mapping between process diagram work flow patterns and simulation
code exists, what we find is that a simulation model can be defined by a process diagram
and a complete set of scenario parameters. Critically, if the process diagram and the
scenario parameters are both specified using a standard, we have a vendor neutral,
standards based API for simulation.

9. While there has been considerable effort in standardizing process diagrams (e.g. BPMN),
there has been little to no effort in standardizing the scenario parameters described
above. The Scenario Definition Language is an attempt to standardize scenario
parameters. For example, the Scenario Definition Language describes the following
format for process instances:
Schema Representation
Notes
Item (XPath)
Arrival ID //arrivals/arrival/@id A unique identifier for the arrival.
Process //arrivals/arrival/ The work flow process name or id (e.g.
Name process as defined in the process model).
//arrivals/arrival/ Specifies the source system or scenario
Data Source
datasource for the arrivals.
The activity in the process where the
arrival takes place. Arrivals may occur at
activities other than the start of a
Destination
//arrivals/arrival/activity process to represent the work in
Activity
progress at the start date/time of the
scenario. In general, this is a reference
to an activity in the process model.

10. //arrivals/arrival/ The date and time at which the arrival
Arrival Time
arrivalTime into the process takes place.
//arrivals/arrival/ How many times the arrival occurs. This
Occurrences
occurrences could be a statistical distribution.
//arrivals/arrival/ The time between occurrences. This
Frequency
frequency could be a statistical distribution.
Allows multiple arrivals of entities with
//arrivals/arrival/ the same attributes to occur at the
Quantity
quantity arrival time. This could be a statistical
distribution.
//arrivals/arrival/
Field Values Data field values for the arrival
fieldValues
See the complete Scenario Definition Language specification for a complete description
of this business process scenario schema. Given support for a standards based API,
exposing the API via web services makes vendor neutral simulation as a service possible.
Simply imagine http://www.mysimulationservice.com/myscenario/arrivals.xml
returning a list of arrivals defined according to the Scenario Definition Language
described above.
BPMN Necessarily But Not Necessarily BPMN
One last item worth discussion is the loose coupling between the process modeling
standard and the proposed Scenario Definition Language (SDL). While elements in the
SDL schema will reference items in the BPMN diagram, SDL remains separate from
BPMN. The path of not extending BPMN to support simulation directly is chosen on
purpose. BPMN is used for many applications besides simulation, and benefits from a
process centric purity. By only loosely coupling SDL to BPMN, the two standards used for
simulation can evolve separately. SDL can survive a change to a new modeling notation
standard and vice versa for BPMN.
Secondly, there are other consumers of the scenario parameters defined in SDL that
may not require a process model, or even use simulation for that matter. For example,
activity based costing, and workforce management for simple processes.