Why does SAP TM route optimisation fail in real operations?
In our experience, the optimiser is rarely the first thing that needs fixing. The problem usually sits around it. Master data nobody checks. Systems that share information late. Constraints set too tight. A transport network that does not match how freight actually moves. And planners who do not trust the routes they are handed.
The result is a plan that looks correct on screen and falls apart on the road.
Late deliveries and rising freight costs are usually the first sign.
5 signs your SAP TM route optimisation is not delivering
Run through this list before you blame the software.
- Your planners change the optimised route almost every day.
- Routes look clean inside SAP TM but break during execution.
- Freight cost per delivery has barely moved since go-live.
- Warehouse delays keep pushing the transport plan off schedule.
- Nobody on your team can explain why SAP TM picked one route over another.
If three or more sound familiar, look at your setup before you look at the software.
What this looks like from the top floor
Most leaders never see the routing screen. They see the results of it.
- Delivery windows slipping during peak season
- Freight costs rising faster than revenue
- Trucks running empty on the return leg
- Poor vehicle utilisation
- Planners overriding the system by hand
- Customer service handling the same complaints every week
Each of these traces back into the planning setup. Below are the eight causes we run into most often.
Why it happens: 8 root causes
- Planning data that nobody validates
Drivers get wrong building numbers, missing gate codes, or half an address. One bad record is nothing. Multiply it across a few hundred stops and you get extra miles, failed deliveries, redelivery attempts, restocking cost, and a phone call from an unhappy customer. Your original savings case quietly disappears.
Then there is stale map data. This is old road and location information that no longer matches what is out there. A route that made sense last year now runs into a new weight limit on a bridge, a construction zone that has been active for months, or a low clearance system that does not know about. A clean route on paper becomes a twenty minute detour in real life. It happens when map data is refreshed slowly instead of continuously.
- Systems that share information too late
Picture three systems. Your ERP holds the order. Your CRM holds the customer’s delivery instructions. Your warehouse knows when the pallet is actually staged and ready to load.
SAP TM needs the right order, customer and warehouse information at the right point in the planning process. In many landscapes it does not get that. The data arrives through batch interfaces, through a file drop overnight, or through someone re-keying it by hand. By the time SAP TM sees it, the situation on the floor has already moved on.
Older ERPs, CRMs & warehouse systems were built in different years by different vendors, long before anyone designed around APIs. Closing the gap is integration work, not configuration work, and it is the part most projects underestimate.
- Constraints set too tight
Not every rule deserves the same weight.
Weight limits, vehicle capacity and legal driving hours are hard constraints. They cannot be broken. But customer preferences, driver familiarity and internal habits often get entered as hard constraints too.
Over-constrain the model, and it hands you a plan that is technically valid and expensive to run.
- A network that does not match how freight really moves
The transport network is the boundary of what the optimiser can see. If your lanes, transshipment points, carrier capabilities and operating calendars are incomplete, SAP TM is choosing from a short list.
A thin network limits the result before planning even starts. A properly built one gives the optimiser real alternatives to compare.
- Warehouse readiness disconnected from planning
Optimisation is only useful if it reflects what can actually leave the building.
When SAP TM and SAP EWM are not properly integrated, transport planning ends up running on warehouse information that is incomplete or out of date. A pick, staging or loading delay then breaks a plan that looked perfectly valid an hour earlier. This gap is where a large share of “the optimiser is wrong” complaints actually come from.
- Planners and drivers who do not trust the plan
This is not a people problem, and it is not bad faith. It is a trust and usability problem.
Some veteran drivers with twenty years on the road will take their own route no matter what the screen says. Some feel that live tracking is surveillance rather than support. Others take detours for reasons the system will never know about, like avoiding an area they do not feel safe in.
Dispatchers do the same thing in their own way. If a sequence looks odd at first glance and nobody can explain the logic behind it, they override it out of habit. Most dispatch teams know their routes, drivers and customers extremely well but were never trained to read what the optimiser is doing.
Every override chips away at the efficiency you paid for, and it never shows up as a line item anywhere.
- No room in the plan for a bad day
Every route plan is based on the information you have at that moment, but things can change quickly. An important customer may suddenly place a last-minute order, and the sales team expects it to go out on a truck that is already full.
The driver might then spend two hours waiting at the customer’s dock because the receiving team is short-staffed. And just when everything seems under control, a highway could close because of an accident.
That is the reality of transportation. Plans change, and your operation needs to be able to respond.
Roads flood. Snow shuts down half a corridor. A plan built on tight back-to-back timing has nowhere to put that shock. One delay in the morning turns into six late deliveries by evening.
- Costs that only counted the licence
Licensing is the visible number. It is rarely the one that hurts.
The costs that get missed are onboarding, hardware, telematics, driver training, and the unglamorous integration work needed to connect the routing setup to an ERP or WMS that has been running for a decade.
There is also a scale problem. An approach that works well for ten trucks will not behave the same way at five hundred. As the fleet, stops and constraints grow, the number of possible combinations grows much faster, and planning runs need to be designed with that in mind.
How to check your own setup?
Good optimisation depends on good data. Validate it before the routing logic runs. Do not assume a field is correct just because it is filled in.
| What to check | What good looks like |
| Freight units | Match the actual shipment profile |
| Delivery locations | Correct addresses, correct time zones |
| Vehicles and equipment | Capacities match what is really in service |
| Loading and unloading times | Based on real observed times, not system defaults |
| Transportation lanes | Match the carrier service you actually buy |
| Delivery windows | Reflect what the customer agreed to, not a rounded guess |
| Constraints | Hard rules and soft preferences kept separate |
| SAP TM to EWM link | Warehouse status visible before dispatch, not after |
Anything on this list you cannot confidently validate is worth investigating first.
A real example
A mid-sized food and beverage distributor in the Midwest, running 45 vehicles across three distribution centers, was planning routes the way most mid-sized distributors do. One static plan, built each morning, based on yesterday’s assumptions.
It held up fine until order volume grew by 30% over two years. Then four things started going wrong every quarter:
- Delivery windows slipping during peak periods
- Freight costs rising faster than revenue
- Trucks running empty on return legs
- Customer service flooded with delivery complaints
We put SAP TM with the VSR optimiser at the centre of the redesign and connected it to their existing SAP EWM, so orders were planned against actual warehouse readiness rather than assumed readiness.
The change for the dispatch team was the important part. They moved from planning one leg at a time to a network-wide view of loads, backhauls and route plans, with the ability to rebuild a plan mid-day when something went wrong.
Results within 10 months of go-live:
- Late deliveries during peak season dropped from 35% to 10%
- Freight costs fell by 15%, which freed up budget for expansion
- Delivery complaints fell by 40%
What SCM Champs actually does about it
We do not start by changing the optimiser. In our experience SAP TM is one part of a larger picture that includes data quality, integration, budget planning, and how people behave when the plan meets reality.
An SAP TM Route Optimisation Assessment covers:
- Master data review — locations, lanes, resources and equipment checked against what is actually in service
- Order and freight unit check — how orders become freight units and where that logic breaks
- Transportation network review — whether the network gives the optimiser real alternatives
- VSR configuration analysis — optimiser profile, cost settings and run parameters
- Constraint review — separating hard rules from preferences that should be costs
- SAP TM to SAP EWM integration check — where warehouse status is lost before dispatch
- Planner override analysis — where manual changes happen, how often, and why
- Written findings — a prioritised list of fixes, with the ones that pay back first at the top
We also build slack into the schedule instead of planning for a perfect day, and we budget the integration work honestly up front, because that is the line item that usually blows up later.
One thing we are clear about. Technology does not replace the dispatcher. Planners need to understand why a route was selected and when to intervene. The point is not to push every decision through the optimiser. It is to give planners a stronger starting point and a clear view, so their judgement gets used where it actually adds value.
Find out which part of your setup is causing the problem
If SAP TM is producing valid routes but your business is still seeing late deliveries, high freight costs and daily planner overrides, the optimiser is probably not what is broken.
Book a free 45-minute SAP TM Route Optimisation Review Call.
In 45 minutes we will walk through your symptoms, point to the most likely source of the problem & tell you which areas deserve a deeper look. If a full assessment makes sense after that, we will scope it with you. If it does not, we will say so.
Frequently asked questions
Why does SAP TM route optimisation fail? It usually fails because of the setup around the optimiser rather than the optimiser itself. The common causes are unreliable master data, information reaching SAP TM too late, constraints set too tightly, an incomplete transport network, weak SAP TM to EWM integration, and planners who override routes they do not trust.
What is VSR optimisation in SAP TM? VSR stands for Vehicle Scheduling and Routing. It is the SAP TM optimiser that assigns freight units to available capacity while respecting your constraints, then works out the delivery sequence and timing. Its output is only as good as the master data and constraint settings behind it.
How does SAP TM and SAP EWM integration improve route planning? The integration lets transport planning information flow into the warehouse and warehouse execution information flow back into planning. Planners can see whether goods are actually picked and staged before dispatch is confirmed, instead of finding out afterwards, which cuts down on trucks waiting at the dock.
What data do you need for SAP TM route optimisation to work? At minimum you need accurate delivery locations and time zones, correct vehicle and equipment capacities, realistic loading and unloading times, transportation lanes that match your actual carrier services, precise customer delivery windows, and freight units that reflect the real shipment profile.
How long does an SAP TM Route Optimisation Assessment take? The free review call takes 45 minutes. A full technical assessment is scoped after that call, since the timeline depends on fleet size, how many systems are connected, and how much of your setup is in scope. You receive written findings and a prioritised fix list at the end.
About SCM Champs
SCM Champs is a supply chain consulting firm specialising in SAP TM and SAP EWM implementations. As an SAP services partner with deep expertise in transportation management and warehouse execution, we work with distribution and logistics businesses across the USA and Europe.
Our focus is on the full picture the configuration, the master data, the integration points & the way planners and drivers actually use the system day to day. We deliver end-to-end transportation planning & warehouse execution projects that hold up under real operational pressure not just during the blueprint workshop.
If your team is dealing with late deliveries, rising freight costs, or planners overriding SAP TM on a daily basis, we can help you trace the problem back to its source and fix it where it counts.