From Pilot to Fleet: Exploring IBM Maximo Monitor at Scale

As we continue our exploration of the IBM Maximo Application Suite (MAS), our next stop takes us back to where the series started: Maximo Monitor. Last time we used derived metrics to catch air leaks in metro rail pneumatic systems. This time the question is not what Monitor can do, but how fast you can get it doing that across every plant you own.

I heard it again in a recent demo for a fast-growing energy company. They liked the dashboards. Then came the real question: "How long until this covers everything?"

What is Maximo Monitor?

Monitor is where sensor data from your assets lands in MAS. Similar devices share a device type that defines their metrics and dimensions (site, line, manufacturer), and you add functions from IBM's catalog: calculations, alerts and anomaly detectors. Dashboards sit on top, and an alert can become a work order.

Why Rollouts Stall After the Pilot

The pilot is rarely the problem. One line, a dozen devices, a few days of setup, and it looks great. Then someone says "now do the other 40 lines."

• Connecting equipment. Every site has its own mix of PLCs and protocols, and each connection can turn into a mini project.
• One screen at a time. Device types, functions and devices are set up by hand, so line 17 ends up slightly different from line 3.
• Models need history. New devices mean days or weeks of empty charts and no trends.
• The pilot does not copy itself. What worked on line 1 lives in someone's head, not in something you can rerun.

None of these are Monitor flaws. They are what happens when you scale any configurable product by hand.

The Device Library (formerly Edge Data Collector)

If you remember the Edge Data Collector (EDC) as a separate thing to set up, look again. Since Monitor 9.0 it is the device library, built into Monitor's add-device flow.

• What's in it - hundreds of manufacturer devices (ABB, Siemens, Schneider Electric, Rockwell Automation and more) with default metrics and dimensions, plus 120+ preconfigured connectors added in 9.1 for Modbus, OPC-UA, BACnet/IP and MTConnect.
• How it works - run the collector on a small gateway on the plant network, in Monitor pick the device model, enter its connection settings and choose the metrics. For PLCs and OPC UA servers it can discover devices by protocol and scan them for data points. It also buffers data through network outages.
• When your device is missing - since 9.1 you can add your own connector by importing device settings or scanning a protocol, and everyone can reuse it. Historians are covered too: once the connector is configured, devices are added automatically.

Why it scales: the connection work for a device model is done once and shared. The next site is deploy a gateway, discover, pick metrics.

What's New in Monitor 9.2

Shipped with MAS 9.2 in June 2026, and much of it helps at scale:

• Stand-alone Monitor - the IoT Platform is now optional (only for MQTT), and devices, gateways and API keys are managed in Monitor. Less to install at every site.
• CSV file ingestion - load data, including history, straight into Monitor.
• Fleet-friendly alerts - NoDataAlert catches a sensor that went silent; AlertByOccurrencesCount catches a condition that keeps repeating.
• Hierarchy dashboards - for Location, Asset, System, Site and Organization, with parents charting their children's metrics without new KPIs.
• Resource-level access - each site team can see just its own equipment.

Configure Once, Copy Everywhere

The device library gets data flowing. What Monitor does with it still has to be set up the same way everywhere. What we recommend,

1. Define each device type once in a template your reliability engineers can review: metrics, dimensions and which functions go on which metric.
2. Automate the setup from that template, so every line gets exactly the same configuration.
3. Load the history with its original timestamps, so anomaly scores and trends work from day one. 9.2's CSV ingestion makes this a built-in option.
4. Copy to the next line or plant: same template, new devices and site values.

At Interloc we packaged this into the APM Accelerator: ready templates for devices, metrics, anomaly detection and history loading, sample dashboards for day one, and the project plan to go with it. Define it once, then stop clicking.

Seamless Integration with Other MAS Applications

Manage: Alerts become work orders, and meter-metric mapping puts Monitor values on the asset record.

Health: Mapped meter data feeds condition scoring, so better Monitor coverage means better Health scores.

Predict: Predict learns from sensor history, so the history you load for Monitor does double duty.

Reliability Strategies: The subject of my previous post. Its failure modes make a good checklist for which metrics and anomaly functions to put in each template.

Where to Start

• Inventory first. List asset classes, protocols and where the history lives, check each model against the device library, and agree on device and site naming before the first device.
• Use the box first. Device library, 9.1 templates, 9.2 CSV ingestion and hierarchy dashboards. Automate only the gap.
• Ask for history in week one. Getting a historian export approved often takes longer than all the Monitor setup.
• Make the pilot your template. Build line one the way you will build line forty.

Final Thoughts

Monitor pays off at fleet scale: the one pump out of 600 that starts behaving oddly, or the sensor that went quiet last Tuesday. The device library, APM Accelerator and a leaner 9.2 shorten the road from one line to all of them. Automation handles the setup; your reliability engineers still choose the metrics, tune the thresholds. Let them spend their time there, not on data entry.

With that I will sign off for now - stay tuned for more insights into the innovative features and functionalities of the Maximo Application Suite!