Why OTM Multi-Stop Optimization Isn’t Working

It’s a Feasibility Problem, Not an Algorithm Problem

Across multiple Oracle Transportation Management (OTM) implementations, teams often enable multi-stop consolidation expecting immediate shipment consolidation after go-live. The common assumption is that turning on optimization will automatically convert standalone LTL or TL shipments into consolidated routes.

In practice, OTM works differently. Before optimization can create a consolidated route, shipments must first meet a set of feasibility conditions, including compatible time windows, equipment capacity, locations, service requirements, and other planning constraints.

When these conditions are too restrictive, only a small number of shipments qualify for consolidation. The result is that most shipments continue to appear as standalone TL movements even though the optimization logic is active and functioning as designed.

Misunderstanding About Multi-Stop Planning:

When multi-stop planning is enabled in OTM, the expected outcome is straightforward:

• Reduce transportation cost
• Combine nearby shipments
• Improve truck utilization
• Reduce empty miles

But what users often see is

• Shipments continue to be created as separate TL moves
• Few or no meaningful multi-stop consolidations are generated
• Optimization results appear to have little or no impact

As a result, what looks like an optimization problem is often a feasibility problem. The system is not failing to consolidate shipments, it simply has nothing it can realistically combine.

What Actually Happens Inside OTM

One of the most important things to understand about multi-stop planning is that OTM does not jump straight into optimization.

Before it starts looking for the best combination of shipments, OTM first checks whether those shipments can actually be combined into a feasible route.

It looks at things like:

• Pickup and delivery time windows — Can the shipments be picked up and delivered within their required time windows? 
• Equipment capacity — Can the combined weight, volume, and other equipment requirements fit? 
• Location and service compatibility — Do the shipments make sense to move together based on their locations and service requirements? 
• Carrier and routing restrictions — Are there any carrier, routing, or service rules that prevent consolidation? 
• Shipment duration — Can the complete multi-stop route be completed within the allowed time? 

If a shipment fails one of these checks, it may never become a candidate for consolidation.

Why this matters in Production ?

When only a few shipments qualify for consolidation, all optimization methods tend to produce similar results because they are working with the same limited set of consolidation opportunities. The below 3 algorithms represent the major optimization approaches used by OTM.

Savings Algorithm

Normally, saving algorithm typically works on Concurrent, Sequential and look ahead savings,

In theory, combining S1 + S2 gives good savings

S2 + S3 gives good savings

S1 + S2 + S3 = even better savings

But in reality,

S1 + S2 = time window mismatch

S2 + S3 = capacity exceeded

S1 + S3 = location or service restriction

Result: OTM Algorithm is working as expected, but no feasible shipment qualified for consolidation

Column Generation Algorithms

The column generation algorithm is used for large networks creating many possible route combinations. Processing hundreds or thousands of orders.

When it has more feasibility constraints which results in few or single valid route instead of thousands of route combinations.

Think of Column Generation as building a large number of possible routes before choosing the best one.

Available Orders,

O1 = Orlando to Miami

O2 = Orlando to Tampa

O3 = Orlando to Tallahassee

O4 = Orlando to Jacksonville

O5 = Orlando to St. Augustine

In theory, OTM generates many route options,

Route A = O1 + O2

Route B = O1 + O3

Route C = O1 + O2 + O4

Route D = O2 + O3 + O5

Route E = O1 + O2 + O3 + O4

Route F = O3 + O4 + O5

Potentially hundreds or thousands of combinations exist in large networks.

After applying constraints:

Route A returns time window violation

Route B returns capacity violation

Route C returns carrier restriction

Route D returns service incompatibility

Route E returns duration exceeded

Only Route F returns feasible

This algorithm is valid only when you have many alternative routes

Result: The planning solver has only one feasible route to choose from. Column Generation is working as expected, but there are no meaningful alternatives to optimize.

Iterative Savings Algorithms

The iterative saving algorithm are typically faster planning and are used by most customers, as it can generate different routes, rebuilds new combinations and multiple iterations. But with limited feasibility set, like constraints and restrictions, the algorithm will not be able to come up with new possible combinations.

Think of Iterative Savings as repeatedly trying different combinations to improve the solution.

Iteration #1: OTM tries S1 + S2

Result: Time window conflict

Iteration #2: OTM tries S1 + S3

Result: Capacity exceeded

Iteration #3: OTM tries S2 + S3

Result: Service restriction

Iteration #4: OTM rebuilds and attempts new combinations.

Result: Same constraints still exist

Final result: No new feasible combinations are found

Why Multi-stop shipments appear rarely or not at all ?

For the multistop shipments to appear, they will require atleast 2 to 5 compatible orders with same equipment feasibility and compatible time windows and compatible locations. 

If the constraint filer is applied, orders remain isolated and only direct shipments are created. 

From a business perspective, this looks like underperformance.

From a system perspective, it is a constraint problem, not an algorithm problem.

How mature implementations handle this?

Strong OTM implementations don’t start with tuning optimization algorithms.

They start by fixing feasibility. That means ensuring the system has enough flexibility for consolidation to happen.

1. Time Window Strategy

• Slight relaxation of delivery constraints where operationally possible
• Standardization of appointment windows across similar customer types or regions
• Validation of overlapping time windows before expecting consolidation

Goal : create enough time overlap for multi-stop sequencing to work.

2. Location data setup

Most consolidation issues come from inconsistent location design rather than optimization.

Common problems include:

• Inconsistent service definitions: Different calendars, operating hours, appointment rules, and delivery windows for similar facilities
• Artificial location separation: Same geography but different hierarchies, roles, or service or rate rules preventing grouping
• Over specific location attributes: Too many unique constraints per location, making each one behave like a standalone entity

Goal: make similar locations behave consistently so they can be grouped logically.

3. Equipment constraints

• Align equipment capacity definitions with real operational usage
• Avoid overly restrictive equipment profiles that unnecessarily block consolidation
• Ensure weight, volume, and utilization rules reflect actual carrier capabilities

Goal: prevent valid consolidation from being filtered out early.

4. Pre Consolidation Design

• Structure order flow to have good grouping opportunities: Release orders together and plan once a day or less frequently.
• Avoid different Planning Dates: Orders belong to different planning windows.
• Avoid excessive order splitting: Orders having different delivery dates, different priorities, and appointment windows.
• Avoid fragmented order release patterns that break consolidation potential: Same delivery location but different orders created several hours apart.

Goal: feed OTM with data that is naturally consolidation ready.

Final Thought

Multistop optimization in OTM is not something that “turns on” and immediately changes the outcomes. It only works when the underlying shipment data supports consolidation. If the constraints are too tight the system will behave restrictively and continue producing standalone shipments, even though optimization is fully active.

Real improvement does not come from tuning algorithms, it comes from designing cleaner, more flexible and consolidation friendly data and constraints. Once that operational alignment is in place, OTM consistently produces the expected multistop behavior and without it, even the best optimization logic has very limited scope to act.

About Author

Gnanasoundar Selvamveluchamy is OTM Solution Architect with 18+ years of experience designing, implementing, and optimizing Oracle Transportation Management (OTM) solutions for complex domestic and international transportation operations. Strong expertise in OTM Cloud architecture, transportation planning and execution, carrier sourcing and rating, shipment consolidation, freight settlement, integrations, Fusion Transportation Intelligence (FTI) analytics, and Oracle BI reporting. Proven ability to translate complex business requirements into scalable, maintainable enterprise solutions and lead initiatives from solution architecture and design through implementation, deployment, and production support. Experienced in technical leadership, stakeholder management, and cross-functional team leadership, with enterprise OTM experience supporting complex global transportation operations.