News and updates

Simulation in process improvement projects

Consultants use many tools for process improvement, but few know exactly when simulation earns its keep. After forty years of projects, here is the litmus test for choosing the right tool.

Choosing when to use process simulation on a process improvement project

Consultants use a variety of tools for their Six Sigma process improvement projects, but many get confused about when to bring in simulation and when to choose something else. Over the past forty years, one litmus test has held true on all of our consulting projects, and it has reliably guided the choice of tools for each one. Here is what that experience taught us.

Process simulation has proven valuable on many projects, yet it can be costly and time-consuming. Cost and time matter most when weighed against risk, return, and the chance of solving the problem another way. If a project could be worth $40 million and the system is hard to solve by traditional methods, simulation is very attractive. On the other hand, advanced analysis of any kind that saves only minutes out of a worker’s day is a waste of analysis time. So with that broad range of possibilities, how do you decide which tool to use?

Find the simulation sweet spot

On our process improvement projects, we found a sweet spot that offers the greatest opportunity. The areas that generate the highest consulting return share four traits:

  • Complexity, which usually means many steps or many options.
  • Variability in processing times, processing flows, or both.
  • Shared resources or interdependencies between parts of the system.
  • Potential return ten times greater than the cost of doing the project.

That sweet spot is also the prime territory for process simulation. It is the combination of complexity, variability, and interdependencies that makes process improvement nearly impossible to estimate with other methods.

Process simulation provides a framework for defining and solving those problems by tying all the information into a single interactive model. The main parts of a model include:

  • Data: the time to process at each step.
  • Resources: the people and equipment used in the process.
  • Flow diagram: the flow options through the system.
  • Shifts: when flow, people, and equipment are available.
  • Arrivals: the patterns of items entering the process.

How the data elements of a unified simulation model interact

Because the unified model holds very descriptive information about the system and links all of the data, a change in the model reflects what would happen if you made that change in the real system.

How simulation compares with a value stream map

It is like watching changes ripple through a spreadsheet, but with two important differences. A simulation model can represent complex and variable systems, and you can watch the processing in an animated, bird’s-eye view. That means process improvement changes can be tested by observing the model before anyone touches the real system.

Other analysis types either ignore many of the data elements a unified model uses or treat them in far less detail. A value stream map, for example, collects high-level data about queue sizes and average processing time. It is a picture of the current state of the system. That picture works well for changes to systems that are not complex, do not show much variability, and have few interdependencies. It is less effective on a complex system, because the result of a change cannot be predicted. Nothing in the picture is connected to make it behave like the real system.

Value stream mapping captures a snapshot, not a working model

There is another catch. When you change the real system, the value stream map becomes invalid, and all the information that defines it has to be recollected once the process settles. Why not just simulate a value stream map? Because you would have to add all the information a unified simulation model contains, and at that point it is no longer a value stream map.

If a problem is simple enough to solve with value stream mapping, do not waste time building a simulation model. Value stream mapping was developed for production lines with low complexity, low variability, and no shared resources, which is not the simulation sweet spot. Simulation takes more time, but it solves problems that cannot be resolved confidently any other way.

Does a project really need to be worth $40 million?

Of course not. Some projects have a potential of only $50,000 in savings, yet the model takes only hours to build. The point is not the dollar figure on its own. The point is the sweet spot: complexity, variability, and interdependencies, weighed against the return. When a problem lives there, simulation is usually the right call. To see how it works in practice, explore the product.

See your process clearly, then prove the fix

Build the model, run the simulation, find the constraint, and show the improvement before you change a thing.