IBM Maximo Monitor is one of the easier MAS suite components to scope on paper and one of the hardest to land in practice. The supplier deck is straightforward — live operating data flows in, anomalies are spotted, dashboards appear — but the deck is not the project. The project is a connectivity programme across SCADA, historians, edge gateways and the OT/IT boundary, with Manage as the asset and work spine underneath.
This guide is for the executive sponsor or programme lead who has been asked to evaluate Monitor. It sets out when Monitor pays off, what readiness honestly looks like, and the questions that separate a credible supplier from a hopeful one.
What Monitor actually does
Monitor ingests live operating data from SCADA, historians, edge gateways and other operational sources. It scores that data against asset and work context held in Maximo Manage, surfaces anomalies and KPIs to operations teams and planners, and feeds back into the work record so the operating loop closes. It is the part of the MAS suite that brings the plant into the asset world.
It is not a SCADA system, a BI tool, or a generic IoT platform. SCADA controls. BI reports on what already happened. Monitor sits between them: an operational signal turned into something a planner can act on, with the asset and work context already attached.
When Monitor pays off
Three conditions usually have to be true at once.
The asset register in Manage is in good enough shape to be the system of truth. Monitor surfaces anomalies against assets and locations. If those records are incomplete, duplicated or inconsistently coded, the dashboards either highlight phantom equipment or miss real signals. Stabilising Manage first is not a delaying tactic; it is the condition for Monitor producing decisions you can trust.
Operational data is available, reliable, and accessible without breaking the OT estate. SCADA and historian data ownership, sample rates, retention and tagging discipline are all part of the project. So is the OT/IT boundary. If those conversations have not started, Monitor is at least a quarter further out than the supplier slide says.
There is a class of equipment where unplanned downtime costs more than the cost of seeing it sooner. This is the business case. It needs a number, not a vibe. If the asset class is not picked deliberately, Monitor produces a great-looking platform with no measurable return.
Where any of those is missing, the project produces dashboards that look right and decisions that are wrong.
Readiness checklist
Before you commit to scope:
- Is the asset hierarchy in Manage complete and consistent for the candidate asset class?
- Is criticality assigned and meaningful, not just populated?
- Are work history and failure codes coded well enough that a planner can trust the operational picture they support?
- Is OT data ownership clear? Who is allowed to consume what data, where, and how often?
- Is there an agreed pattern at the OT/IT boundary, or is that a conversation still to start?
- Is there a named asset class with a quantified business case for Monitor — downtime cost, missed-inspection cost, regulatory exposure?
- Is there an operations and reliability function that will use the output, not just receive it?
If most of those answers are “no” or “we don’t know”, the next three months are about readiness, not about Monitor.
Questions to ask a supplier
The following questions separate a credible supplier from a confident one.
On readiness. “What would have to be true in our Manage estate before you would scope Monitor?” A credible answer talks about asset hierarchy, criticality, work coding and OT data ownership before talking about dashboards.
On the OT cybersecurity boundary. “How do you propose to get operational data out of our OT estate without breaking the cybersecurity boundary?” A credible answer involves the OT team from the beginning and an explicit edge or DMZ pattern. A bad answer assumes the OT team will get out of the way. (Our position is set out in OT cybersecurity is now an asset management problem.)
On scope. “Which asset class would you start on, and why that one?” A credible answer picks one asset class with a clear business case and good data, not “all critical assets” or “the whole estate”.
On Manage integration. “How does an anomaly become a work order?” If Monitor produces a parallel dashboard that nobody links back to Manage, you have built a second system of record. The answer should describe how anomalies create or enrich work in Manage automatically, with rules the operations team owns.
On hosting and operations. “Who runs Monitor after go-live, on what platform, and how does it sit alongside Manage hosting?” A credible answer treats Monitor as part of the same operations platform as Manage, not as an isolated bolt-on. (We host both on the same managed cloud — see managed Maximo and MAS hosting.)
On exit. “If we stop the programme after the first asset class, what do we have?” A credible answer leaves you with a working capability on one class, not a half-finished platform that needs another six months to do anything useful.
Sequencing inside the wider suite
Monitor is the natural first step beyond Manage for most asset-intensive operators. It sits underneath Predict and Health, both of which assume reliable operational signal. The full sequencing argument lives in sequencing Monitor and Predict after Manage.
Closing position
IBM Maximo Monitor pays off when the asset spine in Manage is honest, the OT estate is engaged on its own terms, and the asset class is chosen for a quantified business case. The technology is mature. The programme around it is what gets it adopted.
For the broader picture of how the MAS suite components fit together, the MAS suite overview sets out where Monitor sits alongside Predict, Health, Visual Inspection and the IoT layer underneath them.
Talk to the people who would actually deliver it
No pitch deck, no pressure. A direct conversation with one of our senior consultants.