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:
- 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!
- 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?
Well said!
Like you, I will provide a more comprehensive response directly via my blog. But we are actually in agreement, once one defines and positions simulation as you have done. I’m not sure which of us has gone over to the dark side, but I’m happy not to be alone.
[...] 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 [...]