Enterprises rarely want an Oracle Transportation Management alternative. They want the thing OTM was never scoped to do. Oracle's own capability list for OTM Cloud covers transportation order management, carrier and rate management, fleet and driver management, shipment planning, booking and tendering, dock appointment scheduling, and freight audit and payment — a planning and settlement system, and a capable one. What no entry on that list claims is observation: knowing what time the truck actually reached the gate, what the weighbridge actually read, whether the dock was actually occupied when the appointment said it would be. That gap is usually bridged by a person with a keyboard. Book an architecture review of the gap.
Before You Replace the Planner, Check Whether Planning Is What Broke
Five factors worth settling before an RFP goes out — what OTM actually covers, where the real gap sits in most enterprises, and why the architecture that fits is usually coexistence rather than replacement.
What OTM Covers, Fairly Stated
Any honest comparison starts with the incumbent's real scope rather than a strawman. Oracle publishes it, and it is broad.
Oracle's OTM Cloud data sheet lists transportation procurement, transportation order management, carrier and rate management, fleet and driver management, order and shipment planning, shipment booking and tendering, visibility and event management, freight audit and payment, and reporting. Dock appointment scheduling appears under operational planning — "manage dock appointments for greater warehouse efficiency with advanced scheduling" — and fleet management covers "driver and equipment assignment, dispatch, asset tracking and event management." Yard management sits in Oracle's Warehouse Management product rather than in OTM. Check current documentation for your own release; capability sets move.
Note what that means for the common claim that OTM has no dock scheduling: it does. The distinction that actually matters is narrower and harder to argue with. OTM schedules the appointment. It does not watch the dock. The appointment exists as a plan, and whether the truck honoured it arrives later, from whatever somebody typed.
The Five Factors
These are the questions worth answering before a vendor shortlist exists, because the answers determine whether you are running a replacement project or an integration project. They are very different undertakings.
Before comparing vendors, establish which half is actually failing. If planning, routing, rating or tendering is the problem, that is OTM’s territory and a replacement is a real project. If the complaint is that the system’s numbers do not match what happened on site, you do not have a planning problem and replacing the planner will not fix it.
Most enterprises asking this question have the second problem.These are different products with different risk profiles. A replacement takes on the plan, the money and the master data, and the migration is the project. A layer underneath takes on observation and writes facts into what you already run — smaller blast radius, much shorter path to value, and your finance team keeps billing from the system they trust.
Ask which one the vendor is really proposing, because the pitch deck rarely says.Write-back is where integrations do damage. A system that posts into your ERP automatically from day one is a system that can post something wrong before anyone has validated the mapping. The safer posture is write-back disabled until an integration lead has read the actual messages and switched it on deliberately, document type by document type.
If a vendor cannot tell you how to turn write-back off, that is the answer.There is a meaningful difference between a sandbox that simulates an integration and one that builds the identical message and stops immediately before the network. The first shows you a vendor’s idea of your interface. The second lets your integration lead read the exact bytes that would have been sent.
Ask to see a message built against your own schema, not a sample.The question that separates a system of record from a dashboard. An uncertain reading can be guessed, rounded or quietly dropped — or it can be held, with the reason attached, and excluded from selection until a person resolves it. A guess in a system of record is worse than a gap, because a gap is visible and a guess is not.
Ask to see the held state. If there isn’t one, assume it guesses.Bring your architecture diagram and one real pain
Thirty minutes with an integration lead, not a sales engineer. We will mark where your current flow depends on somebody retyping an observed fact, and show you the message Oneflow would build against your schema — stopped before the network, so you read the actual bytes.
How FleetRabbit Handles This
The architecture is deliberately unambitious about scope and deliberately strict about evidence. Four principles, and the fourth is the one procurement should test hardest.
Nothing about tendering, rating, settlement or order management moves. The system your finance team bills from stays the system your finance team bills from.
Gate arrivals, weighbridge readings, dock occupied and released pairs, driver verification, inspection outcomes — captured where they happen rather than retyped afterwards.
An arrival files as a transport document, a defect as a maintenance notification, an odometer reading as a measurement against the asset, a put-away as a stock movement. Not everything into one record and sorted out later.
Per connection, per document type, after your integration lead has read the message the sandbox produced. The default position is that nothing posts.
The Write-Back Question, in Detail
Factor three deserves more than a line, because it is where most enterprise integrations earn their reputation.
The default position is that write-back is off. Nothing posts to your ERP until someone enables it, per connection and per document type. Until then the system still captures everything, still files it, and still shows you what it would have sent — which is the point of the sandbox.
That sandbox is not a mock. It builds the identical message it would send in production and stops immediately before the network, so an integration lead reads the real payload rather than a vendor's illustration of one. The difference matters at exactly the moment it is hardest to recover from: when a mapping is subtly wrong and the first evidence is a malformed document already sitting in the system of record.
When write-back is live, three states exist rather than a binary. Failed retries on a widening schedule. Blocked means there is no document to attach to yet — supply the number and it goes. Held means a reading was uncertain and needs a person. Held is the important one: the alternative to holding is guessing, and a guess in a system of record is worse than a gap because a gap is visible.
One structural detail worth raising in an architecture review: on a stock transfer, the shipment and the receipt deliberately file to different documents — a goods issue going out, a stock movement coming in. Filing both against a single record is a reliable indicator that a vendor has not actually run one.
What This Does Not Do
An architecture review is the wrong place to discover a limitation, so these are stated up front rather than in a footnote.
- Creating a transfer order inside Oracle from Oneflow is not builtIt is on the roadmap, not in the product. If your requirement is for Oneflow to originate transactions in Oracle rather than report facts to it, that requirement is not met today.
- The weighbridge is not yet its own connected stageIt is captured, but it does not yet stand as a first-class step in the spine the way the gate and the dock do.
- On-site processing catches up after an outage rather than continuing liveCaptures queue locally and arrive batched when the link returns, each carrying the time it was actually taken — which preserves accuracy but is not the same as uninterrupted operation.
- Two of six AI agents are triggered by real eventsThe other four propose work when a person opens a screen. Stating that plainly is more useful to an architecture review than implying six equivalent agents.
- Some modules run on sample dataLive monitoring, SLA monitoring and vehicle handover need a wired site and an agreed baseline before they run on anything real.
If any of these is disqualifying for your programme, that is better established now than in month four of an implementation. Every stage of the spine states whether it is running automatically or still done by a person, on the same principle — nothing on the screen claims to be automated that is not.
Questions Architecture Teams Ask
Is this a replacement for Oracle OTM?
No, and it is not positioned as one. OTM keeps the plan, the rating, the tendering, the settlement and the master data. Oneflow owns what was observed on the ground and getting those facts into your system automatically rather than through re-entry. If you genuinely need to replace transportation planning, this is not that product. Talk through the boundary.
Does OTM really lack dock scheduling?
It does not — Oracle's own data sheet includes managing dock appointments with advanced scheduling, and we would rather say so than make a claim you can disprove in one click. The gap is between scheduling an appointment and observing whether it was kept, and that distinction is both narrower and much harder to argue with. See what observation adds.
How long is an integration like this?
Shorter than a replacement, because nothing migrates. Scope depends on which document types you enable and how many sites feed them, and write-back starting disabled means the first phase is capture and validation rather than a cutover. We would rather scope it against your actual flow than quote a number here. Get it scoped properly.
What happens if the site loses connectivity?
Captures queue on site and arrive batched when the link returns, each carrying the time it was actually taken rather than the time it arrived. On-site processing catches up after an outage rather than continuing live through it — a real limitation, stated plainly, and one worth testing against your own site reliability. Review the offline behaviour.
Can we start with one site?
That is the sensible shape. One site, capture only, write-back disabled, and a comparison between what was observed and what your current process recorded for the same days — including whatever the driver inspection reported. That comparison is usually the business case, and it is one nobody can argue with because both numbers are yours. Start with one site.
How do we evaluate the accuracy claims?
Read them out of the record rather than the brochure. The screen shows how often each agent was right, computed from approvals and rejections in your own data, which means it starts empty and becomes meaningful after use. Any vendor quoting an accuracy figure on day one is quoting somebody else's. See where the number comes from.
Who should be in the architecture review?
Whoever owns the ERP integration, plus somebody who knows what actually happens at the gate — those two rarely have the same picture, and the gap between their accounts is usually where the business case is. A procurement lead is useful but not required for the first conversation. Book it with your integration lead.
The Cheapest Integration Is the One That Replaces Nothing
Oracle keeps the plan, the money and the master data. Oneflow captures what actually happened at the gate, the weighbridge and the dock, files each fact as the document type it really is, and posts nothing to your ERP until your integration lead has read the message and switched it on.
Write-back off by default · one site is enough to start
