The single-ERP dream collapses in the maintenance module almost every time, and the pattern is now predictable enough to plan around. Finance goes live, then procurement, then HR.
Then the maintenance team gets handed a work-order screen built for cost accounting and told to run their shop through it. Within a quarter, somebody on the floor has retreated to a spreadsheet, a whiteboard, or a side app, and the clean one-platform story on the architecture slide has become two platforms with a brittle seam between them.
This is not a software defect. It’s a scoping problem that keeps repeating because the people who buy the ERP and the people who turn wrenches want fundamentally different things from the same screen. Understanding why the obvious fix doesn’t fix it is one of the more reliable ways to stop paying for the same mistake twice.
The Maintenance Module Is Where the Rollout Slips
Full ERP implementations typically run 6 to 18 months, and the maintenance module is almost always the last to be configured and tested, behind finance and procurement. By the time it reaches the shop floor, the budget is thin, the integration team has moved on, and the change-management budget has already gone to general ledger training.
The result is a module that captures what maintenance costs rather than how maintenance happens. Purchase orders flow and approvals flow, but work orders limp. Technicians get a form designed to feed cost centers, not a tool designed to dispatch a PM, log a fault code, or close out a safety-critical repair against a tag number. Adoption craters, and the data the finance team wanted out of the module never shows up either.
Maintenance leaders have been circling this point in the trade press for years. A long-running view in Plant Engineering is that ERP maintenance modules usually need expensive customization before they fit real asset workflows. The customization bill is often how organizations discover the mismatch, after signing.
Why Configuring It Harder Doesn’t Rescue the Project
The intuitive fix is to throw more consultants at the module. Custom fields, custom reports, a dedicated workstream to re-skin the work-order screen for the techs.
On paper this preserves the one-platform vision. In practice it extends the timeline, raises the risk profile, and still produces a screen the shop treats as a tax. Teams that have been through a cycle or two often end up pairing the ERP with purpose-built fleet maintenance software for the execution layer, rather than bending the ERP into a role it was never shaped for.
A few reasons this plays out the same way across industries:
- Different system jobs. The ERP is a system of record for transactions. Maintenance execution is engagement work: short, mobile, interrupt-driven, offline-tolerant. One codebase rarely does both well.
- Different update cadences. Finance logic changes once a year. Asset hierarchies, PM intervals, failure codes, and parts kits change constantly. Pushing every maintenance edit through ERP change control is how backlogs form.
- Different users. A controller will tolerate a six-click path to post a journal entry. A technician with greasy gloves and a 20-minute window will not. Mobile-first design is the difference between a log entry and no log entry.
- The seams get the junior team. The platform itself is usually competent. Maintenance sits downstream of almost every seam that gets shortchanged.
More configuration does not solve any of these. It usually sharpens them, because every custom object you bolt onto the ERP is one more thing the next upgrade has to carry forward.
The ERP Should Be the Backbone, Not the Whole Skeleton
The approach that holds up in production is narrower than the sales pitch and more honest about where each tool wins. Keep the ERP where its design pays off: the general ledger, procurement, HR, master vendor data, fixed-asset accounting. Run maintenance execution on a system built for it, with a disciplined integration between the two. A purpose-built execution system handles work orders, PM scheduling, fault codes, parts issue, and technician time on the terms the shop actually works in, and feeds the ERP the costs, receipts, and asset events it needs.
A few ground rules keep the two-system model from becoming its own mess:
- Decide the system of record for each object. Vendors and GL in the ERP. Assets, PMs, work orders, and labor in the maintenance system. Write it down before anyone configures anything.
- Budget the integration like a product, not a task. Assign an owner, a backlog, and a maintenance budget past go-live. The connections need a roadmap of their own.
- Pilot on the floor before finance signs off. If a technician can’t open, update, and close a work order on a phone in under two minutes, nothing downstream will be clean.
- Measure adoption, not licenses. Count work orders closed with real labor and parts data against work orders that got rubber-stamped. The second number tells you whether the rollout actually landed.
The one-platform pitch is appealing because it promises fewer vendors, one data model, and a tidy architecture diagram. Operations teams that have lived through a few of these rollouts have learned to trade the diagram for a system their technicians will open at the start of a shift. That trade is usually the difference between a maintenance program that produces data and one that produces excuses.