Appearance
Simulation in plain words
Why it matters
A drawing tells you how many pallets fit. It does not tell you whether the trucks will queue at nine in the morning, or whether the six o'clock truck leaves on time. For that you have to run the warehouse, and since you cannot run a building that does not exist yet, you simulate it.
A board game with dice
Picture the warehouse as a board game.
- The board is your drawing: the doors, the floors, the racks, the aisles between them.
- The pieces are trucks, pallets, orders, people and forklifts.
- The rules are your operating profiles: "about 12 trucks a day, mostly in the morning", "a pallet takes about 40 seconds to unload", "the Early team works 06:00 to 14:30".
- The dice decide the details: this truck arrives at 07:12, the next at 07:31; this one carries 22 pallets, that one 19.
The computer plays the game for a whole simulated week in a few seconds, moving every piece by the rules and writing down everything that happens.
That is all a discrete-event simulation is: a very fast, very careful board game, played on your drawing.
Why the dice matter
Real warehouses are lumpy. Trucks bunch up. Orders spike. If you only ever used averages, every queue would vanish, because on average there is always enough of everything. Queues come from the lumps, so the simulation rolls dice.
But dice also mean luck. One week might be quiet by chance. So the platform plays the same week several times with different rolls. Each playing is a replication. Three replications give three answers, and the spread between them shows how much of the result was luck.
The seed is the number that starts the dice. The same seed gives the same rolls, so a run with seed 42 can be replayed exactly. Two scenarios run with the same seed see the same trucks and the same orders, until a change you made sends them down different paths. That is what makes a comparison fair.
Two ways to estimate the work
Warehouse Studio answers "how much work is this?" twice, on purpose:
| Labour estimate | Simulation run | |
|---|---|---|
| How | Volume × time per task, added up. | The board game, played out. |
| Speed | Instant, updates as you type. | A few seconds a run. |
| Sees queues? | No. | Yes. |
| Sees lateness? | No. | Yes, with its cause. |
| Use it for | Staffing and cost, early. | Peaks, bottlenecks and what-ifs. |
They are built from the same profiles and the same standard times. A run's busy hours agree with the estimate's hours to within one per cent. If they disagree, something is wrong, and the test suite says so.
Four rules the simulation never breaks
These come from how real warehouses work, and they are why the results can be trusted:
- Space before people. A truck reserves room on the staging floor before a crew starts unloading it. Otherwise crews would unload into a full floor and everything would jam.
- Stock before pickers. A picker is sent only once the order's stock is reserved.
- Nothing vanishes. Opening stock + received − shipped always equals what is on hand, checked at every shift change. The report says Reconciled.
- Paid time adds up. Every paid hour is busy, idle, on a paid break or overtime. Nothing is lost between them.
What the simulation does not model
It is honest about its limits. Not modelled today: truck appointments and dock schedules, one-way aisles, breakdowns, individual products (SKUs) in specific slots, and rolling a missed order onto the next truck. Each run's assumptions name what applied.
Words you just learned
Simulation · discrete-event · operating profile · replication · seed · labour estimate · reconciled.