01. At a glance
A warehouse needs to know the optimal headcount to run at (while balancing cost, delivery promises, cross-utilization, and overtime). I built a simulation model to find those numbers, and found 3 reasons that made it impossible: the model can't track individual orders, can't enforce priority, and has a unit mismatch with the real warehouse. I paused the project before it produced a false answer, documented exactly where and why the method breaks, and scoped the alternative that would actually work.
02. The problem
The Behrampur warehouse moves thousands of orders a day. Behind all of this are the workers who make everything happen. My question for the model was this: What is the optimal number of workers to run this warehouse?****
*at the lowest cost,
*without breaking any delivery promises,
*while considering how they can be cross-utilized over tasks,
*and also their overtime work.
This is the story of finding that answer, how I realized that we were doing the wrong thing, and what I did next.
03. The approach
I was building a digital twin: a simulation of the warehouse in Stella Architect that could be run to optimize for these numbers. The first step is to build the warehouse inside this software, and accuracy was the priority.
Over conversations with the team, visits to 2 warehouses located around Delhi, and some (beautifully dry) SOP reading, I built a stock and flow chain of every task that happened to bring something into or out of the warehouse. Then, data collection. Every single task needed numbers for an amount, a rate, a resource, and a cost attached. All the assumptions, detail loss, and other observations were documented.
Quite the process, but it did end in a model with all the major workings of the warehouse. Except…
04. The moments of doubt
3 moments in particular, and exactly what each moment broke.
The model doesn’t know which order it’s talking about.
This is called Individual entity tracking, and this tool doesn’t do it. Basically, all it knows, for example, is that there are 100 orders waiting for Packing, and if Packing happens at 50 orders/hour, we’ll need 2 hours to get them all to the delivery truck. No clue where Order #12345 specifically is in this process, so no clue what time it reaches that truck or if it’s too late.
This was the 1st dealbreaker: SLA breaches are impossible to calculate if the model can’t tell the difference between specific orders.
There’s no such thing as jumping the queue.
Urgent orders skip the line in the real warehouse, but they cannot in this model since all orders are treated the same. The best I can do is approximate the percentage of urgent orders that probably come at any time, which breaks the moment a peak or emergency happens.
This was the 2nd dealbreaker: Priorities are important, and a model that can’t handle it isn’t telling us how the most important items in the warehouse are handled.
Units: Workers don’t actually process what I was measuring.
I measured at the smallest possible scale: 1 unit. So one single bottle or pill strip. The workers rarely handle units though.
Invoice from the supplier, SKU on the shelf, order packed - all of these contain units, but are never processed as units by the actual workers. For eg: it doesn’t matter if an invoice that comes into the warehouse has 10 or 100 units in it, the worker processes it as 1 invoice.
This was the 3rd dealbreaker: the model's unit of work wasn't the warehouse's unit of work, and using an average here hides a highly variable number and changes the answer.
05. Pausing the project
None of these were fixable with a workaround. I tried: looking for directionally correct answers for SLA breaches, building 24-hour profiles for every variable I could, weighting the queue estimate harder during known peak hours, building correction factors for the unit mismatch by order type. Each fix roughly patched one symptom and left the problem untouched, because the problem wasn't in my model, it was in what this kind of model can represent at all.
It's easier to keep tuning a model that's producing numbers than to stop and say the numbers can't be trusted, 4 weeks in. But a wrong answer that looks confident is worse than no answer. So I stopped, and put the remaining time into documenting exactly where and why.
06. Defining the alternative
The next step was to find another solution. System dynamics didn't work, but there is another type of simulation that would: Discrete Event Simulation (DES).
Where this model only ever sees totals, DES tracks every order, worker, and invoice as its own entity, with its own timestamp and path through the warehouse. It solves all 4 problems above by design, not by workaround. It is also significantly more expensive to build, and usually means depending on an outside vendor rather than owning the model in-house.
07. The actual result
… was not the optimal headcount schedule. It was 2 things that are less clear, but still valuable:
The data: Exactly where system dynamics stops working, and all my explorations and insights in the process of turning a warehouse into system logic.
A changed question: We now know that DES modelling can add so much more to warehouse optimization. So the question becomes: When does it become worth it to invest in this, what affects that answer, and what would need to change on the ground before that expense is worth paying. My final documentation is a start on this.
08. My learning and reflection
Success here wasn’t building a specific model, but finding optimal solutions for the warehouse. Eliminating a method, finding the data, and scoping the alternative is a helpful deliverable to whoever works on this next.
The bigger lesson was about ambiguous projects generally: scope and question the method until proven innocent. This project could've failed in 3 weeks instead of 4, or never begun at all, if I'd spent 2 days upfront checking whether the tool I was told to use could even answer the question I was given.
09. Conclusion
I didn't leave this project with a working model that answers for what the headcount should be. I left it with a precise, evidence-backed answer to what it would take to actually find out. That's a smaller sounding result, but it's the one the next person can build on.
I wrote an article about more of what I learnt on my weekly newsletter, Canvas and Case notes.
Read this article
