ERP Selection for Asset-Heavy Mid-Market Operators

If you own plant, field crews and a book of contracts, most ERP advice was not written for you. It was written for a mid-market manufacturer who buys material, makes a product and ships it. You do something harder: you win work, subcontract part of it, dispatch labour and equipment to site, issue parts against jobs, bill clients on progress, and defend a margin per work package. This framework is the requirements process I use with asset-heavy operators so that a slick demo cannot bury the questions that actually decide the outcome.

Why asset-heavy ERP selections fail

The pattern is depressingly consistent. A committee writes a long, flat requirements list. Vendors tick every box, because everyone ticks every box. Then the shortlist is decided by demo, and the demo is won on the smoothest dashboard and the most confident presenter. Six months into implementation the operator discovers that subcontract variations are a spreadsheet bolted onto the side, that timesheets do not flow to job cost without a nightly batch, and that the "field module" was a partner add-on the vendor forgot to mention.

The fix is not a longer list. It is a weighted list, grouped by capability area, where the areas that separate real contenders carry more points than the areas everyone can do. Financial core is table stakes; every serious ERP posts a ledger. Project costing, subcontract control and field operations are where products genuinely diverge, so that is where the weight has to sit. Weighting is what stops UI polish from winning.

For definitions and scope of ERP as a category, the Gartner ERP glossary is a reasonable neutral baseline. Treat any vendor-tier or quadrant claim you hear in a pitch as unverified until you read the current source yourself.

The weighted requirements framework

Below is the framework I score against: roughly forty criteria in seven groups, each carrying a weight from 1 (nice to have) to 5 (dealbreaker). Score every vendor 0 to 4 on each criterion, multiply by the weight, and sum. The weights, not the ticks, are what force honesty. Note where the fives cluster: project costing, subcontract, field operations and integration. Those are the groups a good demo tries to skate past.

Forty-two criteria in total. Adjust wording to your sector, but resist the urge to flatten the weights. The moment every line is a 3, the demo decides again.

How to weight so polish cannot win

The weighting logic is simple and it is deliberate. Anything a competent ERP does out of the box gets a 2 or a 3, because scoring it high just rewards the whole field equally and adds noise. The 4s and 5s go where products actually differ and where getting it wrong costs you money every month: costing to job level, subcontract variations, field timesheets that post to cost, and an integration model that survives an upgrade.

There is a second rule that matters more than the numbers. A criterion only scores if the vendor shows it on your data pattern, live, in one connected flow. A tick in a spreadsheet is a claim. A working demo of a subcontract variation flowing into the client invoice is evidence. This is why the next section exists.

The scripted live demo scenario

Hand every shortlisted vendor the same scenario in writing, a week ahead, and require them to run it live in their system, not narrate it over slides. One subcontracted work package, end to end. If a step cannot be shown, that is your answer for that step.

The work package: subcontract the mechanical scope of a plant shutdown, value 100,000 in your currency.

1. Requisition. A site engineer raises a requisition for the subcontracted scope against a specific job and cost code. Show the approval route and the budget check that fires before it is released.
2. Subcontract order. Convert the approved requisition into a subcontract order to a nominated subcontractor, with retention terms and a payment schedule. Show the committed cost land on the job the moment the order is issued.
3. Variation. The client instructs additional scope worth 15,000. Raise a variation against the same package. Show it update both the subcontract commitment and the job budget, and show the audit trail that ties it to the client instruction.
4. Part issue. Issue MRO spares from the site store to the work order for this package. Show the inventory value move to job cost, not to a suspense account you reconcile later.
5. Timesheet. Capture crew hours and subcontractor hours against the package, ideally from the mobile app, and show them post to job cost with the correct rate.
6. Client invoice. Generate a progress application to the client that includes the original scope plus the approved variation, applies retention, and reflects work certified to date.
7. Margin report. With no overnight batch and no export to a spreadsheet, produce a margin report for the package showing revenue, committed cost, actual cost, cost to complete and forecast final margin.

Judge the implementer, not just the software

Here is the truth few buyers internalise: on a mid-market ERP, the software is maybe forty percent of your outcome and the implementation team is the rest. Two operators can buy the identical product and one succeeds while the other writes off the project, and the difference is almost always the people who delivered it. So interrogate the delivery team as hard as you interrogate the software.

Questions that separate the implementer from the software:

• Who is the actual delivery team, by name, that will work on this account, not the pre-sales consultants in the room today?
• What is their consultant attrition over the last two years? A revolving door means your knowledge walks out mid-project.
• How many implementations of this exact scope has this specific team done in your sector, with subcontract and field costing live?
• Will the same lead consultant stay from design through go-live, or do you get handed off after signing?
• Is field and subcontract configuration delivered by them or subcontracted to yet another partner?
• Who owns integration to your existing EAM or field systems, and have they done that integration before?

Integration ownership is where projects quietly die, which is why I treat it as its own discipline; the reasoning is in my guide to enterprise system integrations.

The reference-call script

Vendor-supplied references are curated to say nice things. You still learn a great deal, if you ask questions that are hard to spin. Get two references in your sector, on a similar scope, live for at least a year. Then work this script.

1. Was the team you were sold in pre-sales the team that actually delivered? If not, when did it change?
2. What did the implementation cost against the original quote, and what drove the difference?
3. How long from kick-off to a genuine go-live, not the date on the plan?
4. Which capability did you assume was standard that turned out to need customisation?
5. How does subcontract variation and job costing behave in daily use, honestly?
6. What broke or slipped at your last product upgrade because of customisations?
7. How responsive is support when something breaks at month-end?
8. If you were selecting again tomorrow, would you buy the same product and use the same partner?
9. What is the one thing you wish someone had told you before you signed?

Question nine earns its place every time. People will not volunteer the buried problem, but they will answer it when asked directly.

Where the ERP genuinely stops

An honest framework has to name its own limit. A mid-market ERP is excellent at the commercial and financial spine of your business: contracts, costing, procurement, billing, the ledger. It is not, and should not pretend to be, a deep asset or field-service system. When your requirement crosses into reliability engineering, condition monitoring, complex preventive maintenance regimes, linear assets, or high-volume field scheduling with real-time optimisation, you have left ERP territory and entered specialist EAM, CMMS or field-service ground.

The mistake is at either extreme. Force all of it into the ERP and you get a weak maintenance module your engineers refuse to use. Buy a best-of-breed system for everything and you get an integration estate nobody can maintain. The right answer for most asset-heavy operators is a clear division of labour: the ERP owns the money and the contract, a specialist system owns the asset and the maintenance regime, and a well-owned integration keeps cost and status flowing between them. For a fuller treatment of that boundary, see my comparison of CAFM, CMMS, EAM and IWMS.

Where exactly the line sits depends on how asset-critical you are. A contractor with a light plant register may keep maintenance inside the ERP. An operator running regulated, safety-critical plant almost never should. Decide that boundary before you score vendors, because it changes which weight-5 criteria you even need.

Conclusion

Asset-heavy operators lose ERP selections not because they lack requirements but because their requirements are flat and their demos are unscripted. Weight the framework so project costing, subcontract, field operations and integration carry the points. Make every vendor run the same subcontracted work package live, from requisition to margin report, with no seams. Interrogate the delivery team as hard as the software, and work the reference script to question nine. Then be honest about where the ERP stops and a specialist system takes over. Do those five things and the demo can no longer be won on UI polish, which is exactly the point.