When to use simulation
You already have good tools. Use simulation when they cannot give you an answer you can defend, and skip it when they can.
The short version
Simulation earns its place when three things are true: the process has real variability, the parts of it affect each other, and the change is costly to get wrong. If any of those is missing, a simpler tool may well be enough.
How the tools compare
| Question | Value stream map | Spreadsheet | Simulation |
|---|---|---|---|
| What does the process look like, and where is the waste? | Best tool for this. It gets the team aligned. | Not really | Not its job. Start from your map. |
| Do we have enough capacity on average? | Takt versus cycle time gives a good first answer | Fast and accurate | Works, but it may be more than you need |
| How long will people or jobs wait at peak? | Shows a snapshot of queues on the day you walked it | Averages hide it. Queueing formulas need simple conditions. | Built for this |
| What happens if two steps share the same staff? | Hard to show | Gets complicated quickly | Built for this |
| Where will the bottleneck move after we fix this one? | A judgement call | Hard, because the steps interact | Run it and see |
| Which of these five options gives the best return? | No | Only with a lot of assumptions | Run each one and compare them |
| How sure are we? | No measure of spread | Only if you build it in | Replications show the range |
Signs you need simulation
- Utilization looks fine but the queue is real. A step at 80% can still build long waits when arrivals bunch up. Your spreadsheet can't show that.
- Demand varies through the day or week. Clinic mornings, call center lunchtimes, end-of-month order spikes.
- Resources are shared. One nurse covers triage and treatment, or one forklift serves three lines.
- The change is expensive. A new machine, more staff, a redesigned layout. Testing it on a model costs far less than finding out afterwards.
- You can't pilot it. You can't easily rebuild a line or close a ward to see what happens.
- You have to defend the answer. Someone will ask, "How do you know?"
When you don't need it
Be honest with your client and yourself. You can skip simulation when:
- The arithmetic already settles it. If demand is 120 units an hour and the line can make 100, you don't need a model to tell you it will fall behind.
- The process is steady. Little variability and few interactions mean averages describe it well.
- The fix is obvious, cheap and safe to try. If you can run a kaizen on Tuesday and undo it on Wednesday, try it on the floor.
- The decision is already made. A model built to justify a settled answer is a waste of your time and your client's.
- The problem isn't about flow. Quality escapes, training gaps and poor handoffs of information need other tools, unless they show up as rework or delay you want to measure.
- No one can supply even rough numbers, and nobody can observe the process. You may still get value from building the model, but say plainly that the results are directional. See Gather the data.
Simulation works with your other tools
It doesn't replace them. Your value stream map gives you the steps. Your spreadsheet gives you a sanity check on capacity, and a good model should agree with it on the averages. Your DMAIC work gives you the data and the problem statement. Quodsi starts from the process diagram you already draw, so you aren't building a separate model from scratch.