What simulation is

Simulation lets you run your process on a computer and watch what happens over time, so you can test a change before you ask anyone to try it for real.

Start with a waiting room

Picture a clinic check-in desk. One person works the desk. A patient turns up about every 5 minutes. Checking in a patient takes 4 minutes.

A spreadsheet says this is fine. The desk has 5 minutes for every 4 minutes of work, so it is 80% utilized. No overload, no problem.

Anyone who has stood in that waiting room knows better. Patients don't arrive every 5 minutes on the dot. Three come in together, then nobody comes for 15 minutes. The desk can't save up its quiet time and spend it on the rush, so a queue forms.

We ran this exact desk through Quodsi for an 8-hour day, 10 times over. The desk was busy about 79% of the time, just as the arithmetic predicts. But patients waited about 9 minutes on average for a 4-minute task. The average wait was under 4 minutes on the best day and almost 28 minutes on the worst.

The spreadsheet got the utilization right and still missed the wait. The wait comes from variability: arrivals and processing times that don't line up neatly. That is what simulation is for.

What a simulation does

A simulation follows each patient, order or call through your process, one at a time. It gives each one an arrival time and a processing time, drawn at random from the patterns you describe. It tracks who is waiting, who is being served and what is sitting idle. When the run ends, it reports what happened: cycle time, throughput, WIP, utilization and where the queues built up.

The model is a working copy of your process. You can add a second desk, change the arrival pattern or shorten a step, and run the day again. Nobody gets moved and no client is disrupted.

What "discrete event" means

You will see Quodsi described as discrete event simulation. The phrase sounds harder than it is.

An event is a moment when something changes: a patient arrives, the desk starts on someone, the desk finishes. Between those moments, nothing changes. The queue stays the same length and the desk stays busy.

So the simulation skips the empty time. It jumps from one event to the next, updating the state of the process each time, a bit like reading only the timestamps in a log. That is why a simulated day takes far less time than a real one.

Discrete just means the work comes in separate items and the changes happen at separate moments. That fits most service and production processes, which is why the method suits Lean and Six Sigma work so well.

Why one run isn't enough

Randomness means two simulated days differ, just as two real days do. So a simulation runs the same day many times and looks at the spread. Each of those runs is a replication. In the clinic example, the 10 replications gave very different average waits. If you had run it once, you could have told your client almost anything. See why one run can mislead.

What simulation won't do