When freight units from unrelated regions, flows, or planning requirements sit inside the same VSR optimization run, the optimizer still has to test whether each unit can be combined, sequenced, and routed with every other unit including pairs that could never share a vehicle in practice. Runtime is driven by the number of possible combinations, not the freight count. Segmenting the planning scope around freight that shares real operational relationships shrinks the search space and lets the optimizer spend its runtime on combinations worth evaluating.
What the Client Was Facing
The client was running SAP TM VSR (Vehicle Scheduling and Routing) optimizer across a large pool of freight units roughly 2,500 freight units per day across 8 distribution centers, in a grocery retail industry.
The optimizer had sufficient maximum runtime configured in the planning profile, yet several runs were taking too long or timing out before producing a usable plan. Planners were still waiting on results at 2:00 PM daily.
The pattern was most visible when freight from different regions, planning requirements, or operational flows landed in the same optimization run.
What Was Causing It?
The problem was not the volume of freight. It was the size of the search space the optimizer had to work through.
The VSR optimizer uses an iterated local search meta-heuristic. When unrelated freight sits inside the same run, the engine still has to evaluate whether each unit can be:
• Combined with others
• Assigned to shared resources
• Sequenced together
• Routed through compatible transshipment locations and time windows
If 500 freight units enter one run and only a fraction can realistically share vehicles, routes, or planning conditions, the optimizer still spends its cycles testing combinations with no operational payoff.
Complexity scales with the number of possible combinations, not the freight count itself. A VSR run is nearly never linear an increasing number of objects leads to a much faster increasing number of valid alternatives.
How SCM Champs Solved It
We reviewed the client’s planning scope and identified freight that had no realistic path to interact with anything else in the same run. Rather than feeding everything into one large optimization problem, we restructured the scope around freight that actually shared operational relationships grouped by region, route structure, planning requirements, and resource compatibility.
Concretely, this meant:
• Separate selection profiles so each run drew only the freight units that could plausibly plan together
• Dedicated planning profiles per segment, with runtime and constraint settings tuned to that segment’s size rather than to the largest one
• Incompatibility settings to rule out pairings the optimizer would otherwise keep testing
• A capped maximum number of transshipment locations, since network complexity has a disproportionate effect on calculation time
• Staggered background runs via /SCMTMS/VSR_OPT_BGD, so segments processed in sequence instead of competing for optimizer capacity
The segmentation shrank the search space without splitting apart freight that genuinely benefited from shared planning.
The Result
Runtime reduced from 90 minutes to 25 minutes. Timeouts eliminated. Plans available 3 hours before dispatch cutoff. Cost quality held within 2% of the original plan — or improved, because the optimizer now reached convergence instead of being cut off mid-search.
Planners now receive reliable, on-time plans before their daily cut-off, freeing them to handle exceptions instead of waiting on the optimizer.