When Simulation Makes Sense

I’ve been on a mission lately to promote a different way of thinking about simulation, talking about Simulation’s Place in BPM and Why We Should Reposition Simulation in BPM. However, unlike others, I’m not throwing out the baby with the bath water: the key to my argument is that simulation is extremely valuable, but maybe not as a process design tool in the scope of BPM, as is the traditional use case for simulation.

Process Design

This sort of begs the question: does business process simulation ever make sense as a process design tool. Of course it does, just maybe not in most cases of BPM implementations. Here’s a list of cases where business process simulation might be appropriate as a process design tool:

1. The process does not yet exist.
2. True business process reengineering where you are obliterating your existing processes and starting over.
3. Where you are not implementing a BPM/automation system.
4. Where the costs of automation are very high.

The above cases make sense when the cost of simulation is much less than the cost of automation. Consider cases (1) and (2) where you don’t even know what you’ll be automating (if in fact you will even be automating the resulting process). These are strategic cases, and a good candidate for using simulation where many what-if scenarios can be worked on with no actual implementation costs. In case (3), business process improvement initiatives will always incur a data acquisition cost for simulation analysis as automation will never provide the data to drive simulations. I would think that case (4) doesn’t even require comment.

Operational Decision Making

It has been suggested that maybe we are still in the early adopter stage of business process simulation. That, to me, is simply not true. Business process simulation has been around for ages, and even within business process management, simulation is considered a key feature of BPM suites (think Gartner’s magic quadrant). While part of the problem might be the actual simulation tools provided with BPM suites, one has to ask the obvious question: if business process simulation makes so much sense, why isn’t everybody using it? And why aren’t they using it all the time?

It seems to me that if there is a cost associated with simulation analysis (and there most certainly is), then reuse of the analysis is critical. Process design happens once, the process runs all the time. The cost of simulation makes sense when it is amortized across its continual use in production. Simulation models can be used to fill in the gaps in production reporting when a process is not, or is only partially, automated. That allows managers to make better decisions. When a process is automated, simulation can be used to augment production reporting by predicting near and mid term process outcomes based on the current state of the process. Better yet, use the predicted outcomes to suggest optimizations to management, such as resource scheduling or even changes to the process structure itself.

In conclusion, of course there is a place for simulation as a process design tool. I just think there is a much, much bigger opportunity for simulation as a decision support tool in the actual ongoing operation of business processes.

Simulation’s Place In BPM

In a somewhat controversial post at his Ground Floor BPM blog, Scott Menter of BPLogix suggested that simulation in the Business Process Management (BPM) world is a non-starter. While his claim that no one in BPM uses simulation is surely a dramatic generalization, he does offer some rationale for his assertion:

Simulation delays automation, and I don’t like to wait. There is an instant benefit from automation, even if the underlying process is not very efficient. To put it another way: I’d rather automate a poorly designed process today than spend six months analyzing, simulating, and optimizing it before automating.

For the simulation and business process design advocates out there, this amounts to paving the cow path, when what you should be doing is using simulation and/or other analyses to study and improve the process before automating it:

Scott’s article offended my sense of logic for exactly this reason, yet something about what he was saying resonated with me and my real world experience in applying simulation to business processes. My first reaction was that Scott was simply wrong. In fact my first encounter with automation, an imaging and workflow implementation, had been a complete failure which we attributed to not engineering or improving the process first. However, that was over 15 years ago. Times have changed, and the more diplomatic side of me tended to agree with some of the commentators: there is no right or wrong answer, sometimes simulation makes sense and sometimes, perhaps not. But then I got to thinking: of course there is a right answer. This is business after all, and the right answer will be dictated by cost benefit.

But why the strong feelings? Why is it that Scott’s article offends? I think one has to look at the history of BPM and simulation to understand this, and I’d like to consider a specific attribute of each:

1. Business Process Reengineering (BPR): Many still associate BPM with BPR. The mantra in BPR is that one does not pave the cow path. Analysis, engineering and improvement of the process comes first followed by automation. And simulation fits perfectly: it is less expensive to experiment with proposed process changes on a simulated system than the real thing!
2. Manufacturing: Computer simulation technology has it’s roots in manufacturing and the practitioners are traditionally of the industrial engineering type. While the technology has been adopted to handle simulating (service) business processes, the roots of simulation technology and the mindset around its use is often from a time and a place where the costs of automation were very high (think factories and plants with expensive super specialized hardware and proprietary domain specific systems).

Within the context of contemporary BPM, both of the above should be called into question. Let’s look at each in turn.

BPR

The desire not to pave the cow paths is so appealing because it is intuitive. It’s a key catchphrase of the business process reengineering movement, and the actual passage is from Hammer and Champy’s Reengineering the Corporation: A Manifesto for Business Revolution. However, “it’s time to stop paving the cow paths” is only part of the quote, and like anything taken out of context, it potentially misleads. The actual passage is:

It is time to stop paving the cow paths. Instead of embedding outdated processes in silicon and software, we should obliterate them and start over. We should “reengineer” our businesses.

BPR is about starting over: radical redesign where what replaces an existing process looks nothing like what is currently in place. I would argue that BPM really has little or nothing to do with BPR.  Global360 makes the following point:

…while BPR is meant to be disruptive and involves completely re-thinking processes, BPM has its roots in gentler methods. It’s intended for continuous improvement of processes and its evolution was driven by specific technologies. The focus today is on improving productivity of the workers you already have, and making it easier to roll out new business processes or new products while taking advantage of existing IT systems.

If anything, the desire is for business process improvement, incremental changes and optimizations to make the existing process run better. So yes, we are deliberately paving cow paths and there is no mandate to rip out the current process. BPM is not BPR. It’s not necessarily even business process improvement. The business case may be predicated on automation alone. The costs of experimentation in the real world have come way down. How is simulation a requirement for automation?

Manufacturing

The number of solutions and the relative ease of deployment (compared to yesteryear) of BPM systems have radically lowered the cost of BPM implementation. When the costs of automation, whether through poor processes or implementation, are perceived as so high in the traditional simulation mindset, the costs of developing and maintaining meaningful simulation models is not considered material in the big picture. However, there are definite costs associated with simulation:

• Analysis paralysis: this is where Scott was apparently coming from in his article. The desire to gold plate a process design can lead to a delay in automation and any associated benefits.
• Talent: there is specialized training and capabilities required to create meaningful simulation models.
• Data acquisition: while a process description is required for both automation and simulation, simulation also requires a typically large data set of parameters or inputs such as volumes and their arrival patterns, task durations, resource availability and so forth to ensure the model generates meaningful and accurate results.
• Model maintenance: if you are ever going to use the simulation model again, chances are you will have to actively update the parameters described above.

These costs are not trivial.

Repositioning Simulation

So at this point you may be thinking I have gone over to the dark side and joined forces with Mr. Menter. You’d be wrong. While, for example, the cost of data acquisition for analyzing processes is low for automation when compared to simulation, simulation has a much higher predictive capability. The kinds of future looking and what-if capabilities available in simulation are simply not available from automation alone (that’s not to say automation alone has no predicitive capabilities based on the data it provides, it is just less):

What this suggests to me is that the traditional use of simulation for process design is misplaced in the BPM context and that the real benefit of simulation within BPM is in the predictive capabilities and prescriptive analysis it provides as a consumer of automation data. When systems are already automated, data acquisition and simulation model maintenance costs come way down. In most cases it makes more sense to employ simulation after automation, not before it. While simulation may still offer benefits as a process design tool (for example, even with automation, if the process simply does not yet exist, the case for simulation as a design tool is strong), the real story is the use of simulation after automation:

In this configuration, the costs of simulation are driven down while the accuracy, and therefore predicitve ability, of simulation models increase:

Why is this so? Automation collects the data required by simulation models. Automating the collection of data and in some cases the baseline process definition itself through process discovery reduces the need for specialized talent. Automation also provides a means of providing the data required to maintain the models for ongoing use (both simulation parameters and process model extension). Lastly, data collected from an automated system is more accurate than data compiled by hand for static, steady state simulation models, which leads to better simulation results.

Simulation, when used in this way, is positioned to provide predictive capabilities for BPM systems that are extremely valuable to management. It’s also consistent with the latest trends in BPM: specifically the process prediction component of process mining and prescriptive analytics answering such questions as: When will my process end? How do I best schedule and assign my staff to handle the anticipated workload?

Events You Are And Events You Shall Return

This article is actually part 4 of my Process Event Streams: What You Need To Know series. I thought I’d be a little more creative with the title of this one. You might want to read part 1, part 2 and part 3 in the series before reading this post.

I’d like to make two propositions:

• Proposition 1: A simulation scenario can be defined entirely by a set of events.
• Proposition 2: The output of a simulation scenario is a set of events.

Taken together: a simulation model is a function of a set of events and results in a set of (virtual) events:

In this article, I’d like to discuss the first proposition. What this proposition says is that all the inputs or parameters required to specify a simulation model can be defined by a set of events. Practically speaking, some of the events will have been abstracted into a format that is more natural for describing some of the simulation model parameters, however, these abstractions have their basis in sets of events.

One way to explore this assertion would be to identify the components of a simulation model and see if they can each be related to a set of business process events. The Sim4BPM proposal formalizes what defines a simulation model and so we can explore each component of the Sim4BPM specification as a means of organizing our thoughts:

Process Model

This is specified as a diagram or formal description (e.g. a BPMN diagram) and represents a case where events have been abstracted into a more natural format that is easier to grasp and/or specify: a process model. To demonstrate that a process model is in reality ultimately defined by a set of events, we turn to process mining. One outcome of process mining is the use of process event logs for the purposes of process discovery. In this case, there is no existing description of the business process, so event logs are used to ascertain the structure or a description of the business process. In cases where process discovery is not, or cannot be used to define a business process, it seems reasonable to assume that our ability to manually model a process is based on a knowledge of the events that occur, or could occur in a business process. When someone manually creates a flowchart of a business process, I believe they are intuitively walking through the events that can occur in that process and abstracting that into a diagram or description.

Resource Parameters

It is not difficult to see that the availability of resources are based on events. For example, the events of coming on shift and going off shift. Proficiencies at a certain task or set of tasks is based on the historical productivity of the resource at a task or set of tasks. This is calculated based on a set of events corresponding to when work at these tasks was initiated and completed when being performed by each specific resource. Even the skill sets of resources can be ascertained by looking at the events corresponding to work of a given type at a given task being reserved by a specific resource.

Activity Parameters

Things like activity durations and the routing of completed work are based on the relationship between events. For example, activity duration can be calculated by using the initiation and completion of specific instances of the activity, and the relative number of post processing outcomes. Data associated with these events (or data associated with the process instances or activity instances associated with the event) suggest the condition or business rule for doing one thing vs. another after a given activity is completed.

Event Parameters

In the Sim4BPM specification, event parameters represent where tokens of work need to be injected into the simulation model. For example, the arrival pattern of work, and the initialization of the model with work in progress are all cases where tokens are injected into the model. The relationship to business process events should be obvious and is pretty much one to one. In particular, these parameters are based on events that originate outside the scope of the model, but effect processing inside the model.

Border Events vs. Modeling Events

One distinction that is useful to make is between events that originate outside the scope of the model, but whose occurrence directly effect processing inside the model, which I will call simulation border events, and events that are used to model the activities and processing rules inside the simulation model, which I will call simulation modeling events.

Keeping The End In Mind

I have advocated that the concept and potential value of business process simulation is easy to understand. Yet, if simulation makes so much sense intellectually, why aren’t business managers using simulation all the time? I’ve outlined the deficiencies of simulation, and the Sim4BPM effort is meant to help address these. In the current state of business process simulation, what managers ideally want is to do something as simple as click a button and automatically simulate their business processes. What they actually get is a rather non trivial exercise, requiring specific skills sets, to create and maintain meaningful simulation models.

If you step back, what one realizes is that managers don’t actually want a simpler way to simulate their process. Nor, I suspect, do they want a simpler was to automate their processes. What the really want, quite simply, is answers. How do I process this item at the least cost? How much staff do I need to manage the workload and meet my deadlines? What is the best way to order or schedule the work? Could I operate with less equipment, and if so, how much less? Etc.

Simulation, even if it was dead simple, is only a means to an end. So is BPM in general. Managers don’t actually want either of these. They want the easiest way to get answers to the specific problems and challenges of running their business. Failing that, they want the analytics capability to find those answers. Failing that, they’ll implement the tools to generate the data to get the analytics to get at the answers…

Simulation is but one tool, albeit a useful and powerful one, that generates the kind of data required to perform the analytics required to provide the answers business managers need. It’s kind of low on the food chain. It doesn’t mean it’s not important or useful, because it is both. It’s just that managers don’t want simulation, they want answers. They might need to use simulation (or job scheduling software, or statistical forecasts, or…), but they are a means to an end. Something to keep in mind.

Tools and technologies that provide business process answers and not just analytics can often be characterized by optimization methods that identify a best (optimal) configuration. Simulation, in and of itself, is not an optimization tool. Instead it measures how changes in a business process’ parameters affect the behavior of the process over time. However, simulation technology can be used as an input to optimization methods. For example, Meta Software aims to answer the question what is the optimal set of staff schedules given the business process and staffing constraints? This is accomplished by using simulation technology to model and predict workloads that are input into workforce management technology that optimizes scheduling against those workloads. Robert Shapiro and Hartmann Genrich have developed technology that can optimize process structure. Simulation as an enabler of their solution. In both cases, simulation is very important and useful, but it’s not really about the simulation.

For the purposes of full disclosure, you should know that I currently work for Meta Software. If you or your company is also using simulation as an input to optimization technology to provide answers as opposed to analytics, let me know and I’ll make sure it gets mentioned.

Photo Credit: Caro’s Lines.

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:

1. Control Flow
2. Data/Rules
3. 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:

1. Incoming Work
2. Activity Details
3. 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.

Simulation in BPM: What’s Really Missing

Denis Gagne at Trisotech up in the Great White North has a great presentation on the state of modeling and simulation in the business process management space. Besides presenting the usual rationale for business process simulation, namely the ability to try before you “buy” via what-if analysis, he also outlines three different types of business process simulations:

• Visual Depiction: Think of the flight simulator – this kind of simulation might include an animation and/or interactivity so that the business process is visually tangible to the audience. While Denis provides some fine examples of where this type of simulation is appropriate, in my experience this kind of simulation has tremendous sales value when you are trying to actually sell the idea of business process simulation! Visual depiction is often an add-on to the next two methods when you have to sell a result arrived at via simulation.
• Scenario Simulation: This is described as role play, where you see how actions or decisions you make as a character in the business process play out. Think of this as a business game. The one product specifically mentioned is actually marketed as a BPM simulation game.
• “Numeric” or Discrete Event Simulation: This is the space I’ve been working in the most. Given a real or imagined set of parameters and external events that drive a business process, one can analyze how a business process performs in terms of metrics such as resource utilization, cycle times, capacity, etc.

Denis hits the nail on the head by describing how the concept of business process simulation is easy to understand, but perhaps a little more difficult to successfully perform. While solution providers strive to create a world where we can take any business process model and click a button to make it simulate, the fact is a little bit of expertise of the industrial engineering sort is required to really generate meaningful results from business process simulation.

Lastly, he describes the state of simulation in BPM and his first observation is the following:

There are no specific standards for Business Process Model Simulation. Only XPDL can interchange some very limited simulation attributes.

That’s exactly the goal of Sim4BPM: to address this hole in business process simulation. Sim4BPM aims to provide a complete description of, and interchange format for, business process scenarios for the purposes of simulation.

Here’s the original presentation: