Oracle Fusion Cloud Maintenance models vehicles perfectly well. Its own documentation says so — asset hierarchies can "model a plant, production line, vehicle fleet, customer, or location" — with work orders, work definitions, asset meters, and maintenance programs driven by calendar, interval or meter reading. Any evaluation that opens by claiming Fusion cannot handle fleet assets will be dismissed by the first person in the room who has configured one. The real gap is narrower and considerably more interesting: Fusion models the asset thoroughly, but not the regulated human operation wrapped around it — and for commercial vehicles that wrapper is where most of the compliance burden actually sits. Talk it through with a solutions engineer.
Fusion Models the Truck. It Does Not Model the Trucking.
Where Oracle Fusion SCM's maintenance capabilities genuinely end for fleet operators, the six concepts a plant asset model has no place for, and the coexistence pattern that adds them without touching your asset master.
What Fusion Maintenance Genuinely Covers
Stating the incumbent's real scope accurately is not a concession, it is the only way the rest of the argument survives contact with someone who uses the product.
Oracle's Maintenance Cloud provides asset hierarchy modelling, full work order lifecycle management, work definitions with resource and material assignment, asset meters, and maintenance programs that can be driven by calendar, by interval or by meter reading. Meter-based scheduling matters here: a fleet running mileage or engine-hour intervals is doing something Fusion explicitly supports. The documentation names vehicle fleet as a hierarchy you can model.
So if your requirement is asset records, preventive schedules, work orders and costing against vehicles, Fusion does that. The honest question for an RFP is not whether it can hold a truck. It is what else a truck needs that a pump does not.
Where the Asset Model Stops
Six concepts, none of which appear in Oracle's published Maintenance capability list — and none of which a maintenance system has any particular reason to carry.
Oracle's Maintenance Cloud documentation covers asset hierarchies, work orders, work definitions, asset meters and maintenance programs. It does not mention driver management, driver vehicle inspection reports, DOT or roadside inspection, or transportation-specific compliance reporting. That is not a defect in the product — it is a scope boundary, and it is exactly where the evaluation should focus. Confirm against current documentation for your own release.
A plant asset has an operator in the loosest sense. A commercial vehicle has a named, licensed person whose hours are regulated, whose certification expires, and whose conduct creates liability. Oracle's published Maintenance capability list does not mention driver management, because a maintenance system has no reason to.
A DVIR is performed by the operator at the start and end of a shift, raises defects that bind the workshop, and has its own retention requirements. It is an input to maintenance from a non-maintenance actor, which is a different shape from a technician raising a work order.
Nothing in a plant asset model anticipates an external inspector placing equipment out of service at a location you do not control. The event has to be recorded, it affects compliance scoring, and it arrives without warning from outside every system you own.
A tractor couples to a trailer and for the duration of a trip they are one operating unit with two maintenance histories. Modelling that as a hierarchy is possible; modelling it as a hierarchy that changes several times a day is not what hierarchies are for.
A tire's life depends on which axle position it ran in, and it moves between positions and between vehicles. The component's history is not the asset's history, and the relationship between them changes.
A production line is in the building. A truck's location, custody and condition between departure and return are unknown unless something observed them — which is the gap the whole operating layer exists to fill.
Put your Fusion asset hierarchy next to a fleet operating record
We will take one vehicle as it exists in Fusion today and show what sits beside it in an operating layer — the driver, the inspection, the defect, the roadside event, the tire position. No migration, no replacement, just the two models side by side so you can see which fields have nowhere to live.
Why This Decides an RFP Rather Than a Feature Score
The practical consequence is not that something is missing. It is where the missing thing ends up instead.
When a system cannot hold a concept, the concept does not disappear — it relocates to a spreadsheet, a shared drive, a paper file in the workshop, or somebody's memory. Driver certifications land in an HR folder. DVIRs accumulate in a binder or a separate app. Roadside events get recorded wherever the compliance manager keeps things. Tire positions live in a workshop whiteboard.
Each of those is individually manageable and collectively the reason nobody can answer a simple question like which vehicles are due an inspection, have an open defect, and are assigned to a driver whose certification expires this month. That query crosses four systems, so it is never run, so the answer is discovered rather than planned.
This is the test worth putting to any configuration during an evaluation: not whether the fields exist, but whether that single question can be answered from one query. If the answer involves exporting from two systems into a spreadsheet, the boundary is in the wrong place for your operation.
Six Requirements Worth Writing Into the RFP
These are deliberately written as tests rather than features, because every vendor will claim the feature and the test is what separates them. Swipe on mobile.
| Requirement | The test | What it actually reveals |
|---|---|---|
| The single-query test | Can one query return vehicles that are due an inspection, carry an open defect, and are assigned to a driver whose certification expires inside 30 days? | If this needs an export and a spreadsheet, the boundary is in the wrong place |
| Operator-originated inspection | Can a non-maintenance user complete a structured inspection that binds the workshop, with defects that cannot be closed without a recorded repair and certification? | Tests whether inspection is a first-class workflow or a form |
| Third-party events | Can a roadside out-of-service event be recorded against the vehicle, with its effect on availability and compliance visible without a manual update elsewhere? | Tests whether external actors exist in the model at all |
| Temporary asset pairing | Can a tractor and trailer be associated for a trip, each keeping its own maintenance history, and the pairing itself be queryable afterwards? | Tests whether the hierarchy handles relationships that change daily |
| Component position history | Can a tire be tracked by axle position, moved between positions and between vehicles, and its wear history follow the component rather than the asset? | Tests whether components are objects or attributes |
| Custody while away | For any period the vehicle was off site, can you show who held it and what was observed, without that answer coming from a person's memory? | Tests whether the system covers the time the asset is not where you left it |
Ask for each of these to be demonstrated in a configured system rather than described, and ask how many screens and systems the demonstration touched. The count is the answer. A requirement satisfied across three applications is a requirement your team will satisfy manually once the consultants leave.
How FleetRabbit Handles This
Four principles, and the first is the one that keeps this an integration conversation rather than a replacement project.
Asset records, costing, procurement, inventory and the financial close stay exactly where they are. Nothing about the system of record moves.
Driver identity and verification, daily inspections and the defects they raise, roadside events, coupling, position-level component history, and what was observed while the asset was away.
A defect files as a maintenance notification, an odometer or tread reading as a measurement against the asset, an arrival as a transport document — so Fusion receives properly typed records rather than a dump.
Per connection and per document type, after reading the message the sandbox built against your schema. The default is that nothing posts.
What This Does Not Do
Stated here rather than discovered in month four of an implementation.
- Creating transactions inside Oracle from Oneflow is not builtOneflow reports observed facts into Oracle. Originating documents there — a transfer order, for example — is roadmap rather than product today.
- The weighbridge is not yet a first-class stageCaptured, but not standing alongside the gate and the dock in the spine the way those do.
- On-site processing catches up after an outageCaptures queue locally and arrive batched with the time they were actually taken. Accurate, but not uninterrupted.
- 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.
Every stage of the spine states whether it is running automatically or still done by a person, on the same principle. If any of the limitations above is disqualifying for your programme, that is far better established during evaluation than after a contract exists, and we would rather lose the deal on an honest boundary than win it on an implied one.
Questions Evaluation Teams Ask
Can Oracle Fusion Maintenance handle a vehicle fleet?
Yes, as assets. Oracle's own documentation names vehicle fleet as something you can model in an asset hierarchy, with work orders and meter-based maintenance programs. What its published capability list does not cover is driver management, driver vehicle inspection reports, roadside inspections and transportation compliance reporting — the regulated operating layer rather than the asset itself. See what sits in that layer.
Are you proposing we replace Fusion?
No. The asset master, costing, procurement, inventory and financial close all stay. What gets added is the operating layer, posting typed facts back into Fusion. It is an integration project rather than a migration, which is a materially different risk and timeline. Scope it as an integration.
Could we just add custom fields in Fusion?
For some of it, yes — and plenty of organisations have. The question is what the customisation costs to maintain across upgrades, and whether a flexfield holding a DVIR actually gives you the workflow around it: operator capture, defect binding, certification of repair, retention. Fields are the easy part; the behaviour around them is the work. Compare against a built workflow.
How does meter-based maintenance interact between the two?
Readings observed in the operating layer post back as measurements against the asset, which is what Fusion's meter-based programs consume. You are not running two scheduling engines — you are giving the existing one better inputs than a technician typing an odometer reading from a photograph. Walk through the meter flow.
What is the smallest sensible starting scope?
One depot, capture only, write-back disabled. Run it alongside your current process for a month and compare what was observed with what was recorded. That comparison is usually the business case, and both sets of numbers are yours, which makes it hard to argue with in either direction. Trial it on one depot.
Who needs to be in the evaluation?
Whoever owns the Fusion configuration, plus whoever actually answers compliance questions today — often a workshop manager with a spreadsheet nobody has formally acknowledged exists. The gap between those two accounts of how things work is where the requirement really lives. Get both in the room.
How does this compare on TCO?
An integration that adds a layer costs less than a migration that replaces one, which is most of the answer. Beyond that it depends on which document types you enable and how many sites feed them, so a number quoted here would be fiction. We would rather scope it against your actual configuration, counting the maintenance workflows you already run. Check what Fusion would hold.
Keep the Asset Master. Add What Operates It.
Fusion holds the asset, the cost and the close. FleetRabbit holds the driver, the inspection, the defect, the roadside event and the position-level component history — and posts each one back as the document type it actually is.
One depot is enough to start · nothing posts until you enable it
