share

What a month of timestamps taught us about a plant everyone thought they understood. There is a particular kind of problem that everybody in a plant can see and nobody can quite name.

At one of India's large vehicle manufacturing sites, it looked like this: a long line of trucks, parked inside the fence, engines off, drivers waiting. Not for ten minutes. For hours. Every shift, every day, around the clock.

Ask ten people why, and you'd get three answers. Not enough docks. Suppliers turning up whenever they feel like it. Everyone arriving at once in the morning. All three were plausible. All three pointed at expensive fixes build more docks, renegotiate supplier schedules, redesign the arrival plan. We were asked to find out which one was right. It turned out to be none of them.

 

The Challenge

The brief was simple to state and hard to answer: why do trucks wait so long inside the plant, and what would actually fix it?

The difficulty wasn't a shortage of data. It was that the data lived in different places and had never been joined up. Gate systems knew when trucks arrived. Goods-receipt systems knew what came off them. The planning system knew what was supposed to arrive. Nobody had ever put a single truck's whole journey on one line arrived at this time, carried this material, went to this dock, left at that time. Without that, every explanation stayed an opinion.

 

The Solution

We didn't start with a solution. We started with a reconstruction.

The idea was to rebuild the journey of every single truck that entered the plant in one month — from the moment it hit the gate to the moment it left and then attach what it was carrying and where that material was headed. Not a sample. Every truck. That gave us something nobody in the plant had: a way to ask questions and get an arithmetic answer instead of an argument.

A three-hour visit, two hours of it spent parked.

The first answer was uncomfortable. A truck spent around three hours inside the plant, and roughly two of those were spent parked, waiting to be told where to go. Not queuing at a dock. Not being unloaded. Just waiting for someone to call it forward.

 

How We Went About it

Here's the part that mattered, and it wasn't clever analysis. It was refusing to accept a plausible answer.

We had a theory: if the plant is short of docks, then busy docks should have longer queues than quiet ones. That's how queues work everywhere the crowded checkout takes longer. So we tested it. We measured how loaded each dock was, and how long trucks waited for it.

There was no relationship at all. The busiest dock in the plant had one of the shortest waits. A dock running at a fraction of its capacity had one of the longest. Trucks waited about the same time whether their destination was hammered or idle.

Then we tested the second theory: if everyone arrives at once, waiting should spike at the peak hour. We split the day into quarters by how many trucks were arriving. The waiting time was flat near-identical in the quietest quarter and the busiest.

Then the third: if suppliers are undisciplined, deliveries should scatter around their promised dates. They didn't. The overwhelming majority landed on the day they had promised.

Which left an awkward question: if the wait doesn't change with volume, doesn't change with dock load, and isn't caused by late suppliers what is it? A delay that stays the same no matter what is happening around it isn't congestion. It's a process running at a fixed speed.

So, we went looking for the process. And we found it in a gap in the data rather than in the data itself. 

 

The Thing Nobody Had Noticed

Every truck's arrival at a dock was recorded. Almost none of their departures were. In the overwhelming majority of records, the moment a truck arrived at a dock and the moment it left were stamped as exactly the same instant. Which is impossible — no truck unloads in zero seconds. What it actually meant was that the departure scan wasn't being done.

And that one missing scan explained everything.

The loop had a broken link, and everything downstream reorganised itself around the gap.

The plant had a screen in the parking area that was supposed to call the next truck forward when a dock became free. But the system only knows a dock is free when someone records that the previous truck has left. Nobody was recording it. So the screen couldn't be trusted. So, drivers stopped watching it and started walking up to ask instead. So dispatchers called trucks manually, from memory, in no particular order which is why we found that the truck that had waited longest was frequently not the next one called.

The queue wasn't a capacity problem. It was a feedback problem.

 

The Impact

The engagement is still running the fixes are being designed with the plant's own cross-functional team, on the floor, where they should be. Three expensive projects got questioned before they were funded. Adding dock capacity, rebuilding the supplier delivery schedule, and redesigning the arrival profile were all on the table. The data said none of them addressed the actual constraint. That's a significant amount of capital and disruption re-pointed at the right target.

The problem got a lot cheaper. A scanning discipline change and a working call-forward sequence cost very little compared with concrete and steel.

The prize got sized. Because the whole journey is now measured, the waiting time can be converted into truck-hours, and truck-hours into a number the business recognises. Cutting the wait to a fraction of what it is today takes hundreds of trucks out of the yard at any given moment with no new dock, no new shift, no new equipment.

And the plant got an instrument, not just an answer. The same reconstruction now runs on any month of data. When something changes, they can see it. 

 

What We'd Take Away From it

Every operational problem gets explained before it gets measured. Someone walks the floor, sees the queue, and forms a view and because the view is reasonable, it hardens into fact long before anyone checks it.

The way out isn't more data. It's one question, asked early: does this get worse when we get busier? A capacity problem does. A process problem doesn't. That single test separated three years of assumption from the actual answer in an afternoon.

The queue was visible to everyone. The reason for it was visible to nobody, because it lived in a scan that wasn't happening — and absence doesn't show up on a walk round the plant.

Most operational problems have a version of this hiding in them: a step nobody owns, a loop that looks closed and isn't. It rarely shows up in a process map, because on paper the step exists. It only shows up when you measure what happened, truck by truck, and notice that a number is impossible.

If you're carrying a queue that nobody can explain, the first question isn't “how much capacity do we need?” It's “does the wait get worse when we get busier?” If the answer is no, you're not looking at a capacity problem and you'd want to know that before you build anything.

 

ANVI KISHOR INGLE SUPPLY CHAIN CONSULTANT

Author

We work faster than
you can even imagine


WhatsApp