IBM Maximo Health is one of the few MAS-suite components that pays back on day one when there is a real capital or maintenance decision waiting on it. It is also one of the easiest to mis-cost. Suppliers tend to size the platform work cleanly and underestimate the data and criticality work that makes the platform meaningful. Buyers tend to size the platform work conservatively and forget that without a decision waiting on the score, the platform is an interesting dashboard nobody acts on.
This is how we work the cost-and-payback question with clients before scoping starts.
Start with the decision the score has to support
The first question is not “how do we deploy Health”. It is “what decision will the Health score change”. Without a decision waiting on it, the entire programme is a sunk cost. With a decision waiting on it, the cost is measured against the value of the better decision.
Decisions Health typically informs:
- A capital plan being built or defended at board level
- A maintenance budget being challenged in a year-on-year review
- An audit being prepared (ISO 55001, regulator, insurer)
- An asset class going off-warranty or off-OEM-support
- A renewal-versus-refurbishment decision on a population at end-of-life
- A risk re-rating on a critical asset class after an incident or a near-miss
If none of these is on the table in the next twelve months, defer the programme. The score will go stale before anyone uses it.
Size the platform work honestly
The platform work for a focused first Health programme — readiness assessment, scoring model design, configuration, integration into the planning process — typically falls into a four-to-six-month effort with a defined asset population. Multi-site rollouts compound that, but the per-site work is usually shorter once the model exists.
What inflates the platform cost on real engagements:
- Asset register cleanup if Manage data is not yet in shape. This is real work, but it is Manage work, not Health work, and it should be priced separately.
- Criticality framework design if no formal framework exists today. This is sometimes the biggest single cost on a Health programme — the senior engineer who has been the human criticality model for ten years has to be in the room, and the framework has to outlive their tenure.
- Condition-data integration if Health is feeding off Monitor signal as well as Manage data. Often worth doing — it makes Health dynamic — but it is its own work package.
- Integration into planning processes so the score actually drives the plan revisions. This is where the value is realised; cutting it to fit budget is a false economy.
A credible scoping conversation costs each of these as a separate work package, with explicit prerequisites and explicit value. Lumping them together is how programmes overspend.
Size the data and criticality work, not just the platform
The unglamorous reality is that the data and criticality work is typically a third to a half of the total programme cost on a first Health rollout. It is the work that makes the platform meaningful. It is also the work that pays back beyond Health — a defensible criticality framework benefits the maintenance plan, the insurer relationship, and the audit trail regardless of what platform sits on top of it.
Pricing this honestly up front avoids two failure modes:
- The platform-only project. Cost looks attractive, the platform goes live, the score reflects whatever was in Manage on day zero, the planners do not trust it, the programme dies quietly.
- The data-cleanup project that never reaches the platform. Budget is consumed on data work that nobody ties back to a decision, the platform never goes live, the executive sponsor concludes Health was not worth it.
The right shape is data work and platform work, scoped together, sequenced so the data is ready when the platform needs it.
Pay-back against the capital plan
The pay-back from Health is rarely “we saved X percent on maintenance spend”. It is “we changed the order of capital spending so the highest-consequence assets were addressed first, and the lowest-consequence assets were deferred”. On a five-year capital plan of meaningful size, even a modest re-prioritisation pays back the entire Health programme.
What this looks like in practice:
- A single capital decision deferred or accelerated by twelve months because the score changed the consequence picture
- A maintenance budget defended at a year-on-year review with explicit evidence rather than narrative
- An audit closed with documented, repeatable evidence rather than a forensic exercise
- A renewal-versus-refurbishment decision on a population taken with confidence rather than rounded conservatively
These are concrete, quantifiable outcomes. They are also the outcomes the executive sponsor recognises as worth the investment. A pay-back conversation framed in those terms tends to land. A pay-back conversation framed as “fewer breakdowns” tends not to.
A scoping rule of thumb
For a focused first Health programme on a defined asset class with a real decision in front of it:
- Platform work: a third to a half of the total cost, four to six months elapsed
- Data and criticality work: a third to a half of the total cost, often the longest lead time
- Integration into planning: the rest, but the most consequential
If a supplier proposal allocates significantly less than that to data and criticality, the proposal is probably underestimating the work that makes the platform meaningful. Push back.
Closing position
IBM Maximo Health pays back when there is a real decision waiting on the score and the data and criticality work is scoped honestly alongside the platform. Sizing the platform work alone is the most common mis-costing on these programmes. Sizing the decision the score has to support is the most common omission.
For the implementation pattern in detail, see IBM Maximo Health: asset health scoring and capital prioritisation. For how Health relates to ISO 55001, see ISO 55001 asset management system: what it really means.