Problem the client was facing
A Industrial Goods manufacturer. 6 plants, 14 shipping points, roughly 2,500 shipments going out every month.
On paper, SAP TM planned their transport. In real life, two planners planned it and SAP TM went along with them.
The daily plan took about 9 hours to finish. Most of those hours were not spent in SAP. They were spent in a spreadsheet one of the planners had built years earlier and kept patching. He was the only person who fully understood how it worked.
Trucks were leaving with space still in them. Everybody in the team knew this. Nobody had time to stop and find out why.
Urgent shipments were not urgent any more. They booked so many that it had become a normal part of the week.
The thing that worried management most was not the cost. It was that only two people in the building could produce a working plan. When one of them took leave, everything slowed down. If both had left in the same month, nobody knew what they would have done.
What was causing the problem
When they called us, they were fairly sure the optimiser was broken.
It was not. The optimiser was doing exactly what somebody told it to do 7 years ago, and nobody had told it anything different since.
Four things had gone wrong, and all four had gone wrong slowly.
The master data was old. Lanes, transit times, truck capacities. It all described a network that no longer existed. Plants had been added, routes had changed, one site was not even in use any more. The system still believed the old version.
The plan knew nothing about the yard. Dock timings, how long unloading really takes, which products cannot go on the same truck. All of that was real, and all of it lived in people’s heads. None of it was in the system. So the plan looked correct on screen and then fell apart at the gate.
The cost settings did not match the invoices. The system was trying to save money using rates that carriers had stopped charging. It was heading towards the wrong answer, very efficiently.
Nothing was handled automatically. Every small exception landed on a planner’s desk. Once you override the system every day for a year, you stop believing in it. That is what had happened. The overrides were not the problem. They were the symptom.
How SCM Champs solved it
We did not change any configuration for the first 4 weeks.
Instead we took 6 months of their real shipments, ran them through again, and put the planned result next to what actually happened on the ground.
That ended most of the arguing. Once you can see load by load where the plan and reality split, nobody has to guess who is at fault.
After that we worked through it in order.
Master data first. Lanes, distances, durations, capacities, all checked against how the network runs now instead of how it ran in 2017.
Then the cost settings, rebuilt around the rates finance is actually paying today.
Then the constraints. Dock windows, handling time, products that cannot travel together. What had been sitting in people’s heads went into the system.
Then exception handling. The rule was simple. If the situation is normal, the system decides. If it is not, a planner decides. Planners now look at 30 loads a day instead of every single one.
And we wrote all of it down, then trained 5 planners on it. The plan does not sit with two people any more.
What changed for the client
6 months after go-live:
• Time to build the daily plan: 9 hours to 2 hours
• Plans going out without a manual override: 10% to 85%
• Average truck utilisation: 62% to 91%
• Difference between planned freight cost and the invoice: 11% to 1.5%
• Planners who can run the day on their own: 2 to 5