Back to Insights

Insight

EAM procurement is still scoring CMMS features

EAM procurement still scores CMMS-era feature checklists while the platforms have moved on to consumption pricing, embedded AI, and managed delivery. Buyers are picking the wrong fight.

By Mark Seymour
Cover image — EAM procurement is still scoring CMMS features
AnalysisEAM ProcurementMarket TrendsVendor SelectionOperating Model

Most enterprise asset management tenders that cross a buying desk today still look like they were written for a CMMS replacement in 2015. A long feature schedule, a weighted scoring sheet, a per-user pricing model to compare, three reference calls, a scripted demo. The rubric rewards platforms that can put a tick in every box. EAM procurement has not moved with the platforms it is supposedly procuring, and the gap is starting to show up in stalled programmes, surprise bills, and renewal conversations that go badly for the buyer.

The position here is straightforward. Asset-intensive organisations procuring EAM today are scoring the wrong attributes. The feature parity question is largely settled at the top of the market. The decisions that determine whether a programme delivers are about platform commitment, delivery operating model, and consumption profile. None of those decisions is well represented in a typical RFP.

What CMMS-era procurement looks like

A recognisable EAM tender has roughly the same shape across utilities, transport, public sector, and manufacturing buyers in the UK, USA, and Europe. The buyer issues an ITT or RFP built around a requirements catalogue, often sourced from a template. Vendors respond with a compliance matrix. A panel scores responses against weighted criteria, almost always heavily weighted toward functional fit. Shortlisted vendors demo to a script. Pricing is normalised to a per-named-user or per-concurrent-user figure for comparison, and the lowest defensible bid wins.

That process was reasonable when an EAM selection was, in substance, a CMMS selection. Functional fit varied meaningfully between products. Pricing models were comparable. The implementation was mostly a configuration exercise against a known scope. The risk that mattered was picking a product that could not do the work.

The risk profile has changed. The functional gap between IBM Maximo Application Suite, SAP S/4HANA Asset Management, Oracle Fusion Cloud Maintenance, and the established mid-market platforms is narrow for the work most operators actually do. Verdantix and Gartner have been making this point for several review cycles. The decisions that now separate a successful programme from an expensive one sit upstream of the feature schedule.

What has changed under the platforms

Three shifts have happened under the bonnet of the EAM market while procurement practice has stood still.

The product has become a platform. Maximo Manage inside MAS is no longer just the work and asset management application. It sits alongside Health, Monitor, Predict, Assist, and Visual Inspection, on a Red Hat OpenShift footprint, with embedded AI capabilities being added on a continuous delivery cadence. The buying decision is no longer “which CMMS”. It is which platform an organisation is willing to commit to for the next decade of asset intelligence work. A per-user licence comparison cannot capture that decision.

Pricing models have moved. IBM’s AppPoints model, SAP’s RISE-style commercial constructs, Oracle’s universal credits, and the consumption-based pricing now standard across cloud-hosted EAM platforms all break the per-user comparability the old RFP rubric relied on. Two bids that look comparable on a per-seat basis can produce very different five-year totals once monitoring volumes, AI inference, environment counts, and storage are layered in. The buyer who scores only the headline number is taking on an unbudgeted consumption risk.

Delivery is now a separable decision. The platform vendor is rarely the implementer, and the implementer is increasingly not the long-term operator. A modern MAS estate is typically licensed from IBM, implemented by a partner, hosted on a managed cloud service, and operated by a support partner under a defined release cadence. The procurement function that bundles all of this into a single award misses the point that the long-run cost and risk of an EAM estate sits in the operating contract, not the licence.

The three decisions procurement should be scoring instead

If feature scoring is not the discriminator, what is. Three decisions deserve most of the weight in an EAM tender today.

1. Platform commitment

The platform commitment is the longest-lived decision in the tender. Moving off Maximo, S/4HANA, or Fusion once an estate is established is a multi-year programme with material risk. The procurement panel should be scoring vendor stability, investment trajectory, roadmap credibility, the legibility of the AI strategy, and the realism of the upgrade path from where the buyer is today. IBM’s own documentation on the MAS continuous delivery cadence is a more useful artefact for this scoring than any feature matrix.

2. Operating model

The operating model decision is the one most procurement processes barely score. Who runs the platform on day 401, after the implementation partner has demobilised. What does the release cadence look like. Where does the buyer’s internal team end and the managed service begin. How are environments structured, how are upgrades absorbed, how is configuration debt kept in check. A vendor or partner that can answer these questions concretely, with named operating commitments, is worth more than one that scores higher on functional compliance.

3. Consumption profile

The consumption profile is the question every CFO will be asked to defend at year three. What does usage look like at scale. How does the AppPoint or credit consumption move as monitoring volume grows, as users add to the estate, as Predict and Health are switched on. What is the cost of an additional environment, an additional integration, an additional ten thousand assets onboarded to monitoring. A procurement process that models the consumption envelope, rather than the headline number, gives the sponsor a defensible budget.

What this means for the RFP

None of this requires throwing out the procurement playbook. It requires adjusting where the weight sits.

  • Cut the functional schedule down to the items that are genuine differentiators for the operator’s actual work, not the union of every CMMS feature ever shipped. The rest can be tested in a short proof of value, not scored on paper.
  • Add a section that scores the platform commitment explicitly, with named scoring on roadmap, AI strategy, and upgrade path. The reference calls should test these, not just functional fit.
  • Add a section on the operating model, with vendors required to put forward a named delivery and operate construct, including release cadence and environment design. Where the licence and operate decisions are separable, separate them in the procurement.
  • Replace the per-user pricing comparison with a consumption model, built against the buyer’s three-year asset, user, and monitoring volumes. Make the model an artefact of the contract, not just of the evaluation.

This is the same operating logic that runs through MaxIron’s managed Maximo work and the argument set out in the EAM cloud trade-off. A procurement that scores the right attributes ends with a contract that holds up against the way the platforms actually behave at scale.

The position

The honest position for an asset management leader sitting in front of a draft EAM RFP is this. The CMMS-era rubric, with feature scoring and per-user pricing comparison, will reliably pick a vendor. It will not reliably pick the right vendor, because the decisions that determine outcomes are no longer the ones being scored. The platform commitment, the operating model, and the consumption profile are where the value and the risk now sit.

Buyers that restructure their EAM procurement around those three decisions tend to award contracts they are still comfortable with at year three. Buyers that do not tend to spend year three renegotiating, replatforming, or quietly running a parallel programme to fix what the original tender did not buy. Neither outcome is a feature problem. Both are procurement problems.

Sources