Predictive Maintenance with SAP, Siemens and IBM

When an asset-heavy organisation decides it is ready for predictive maintenance, the shortlist converges quickly on three names: SAP, Siemens and IBM. Each of the three has a mature offering, a global delivery network and reference customers at serious scale. Each also arrives with an architecture that assumes something about where your asset master lives, where your maintenance transactions are recorded, and who owns the sensor layer. Those assumptions matter far more than the model accuracy on any vendor benchmark slide, because in almost every deployment I have been close to, the integration work and the data preparation dominated the effort, and the analytics itself was the smallest line in the plan.

The message up front: at most organisations the right choice among SAP, Siemens and IBM is whichever platform already owns your asset master and your maintenance transactions. The difference in model quality between the three is real but small next to the difference in integration cost. Choosing the vendor that already holds your system of record usually beats choosing the one with the better algorithm and then paying for two years of plumbing to feed it.

A note on naming: product names, bundles and licensing tiers in the enterprise predictive maintenance space are renamed and repackaged frequently, and several of the offerings discussed here have carried two or three different names within the last few years. This article describes capabilities and architecture rather than asserting current SKUs, tiers or version numbers. Where a product name appears, treat it as the name it has been marketed under, and verify current naming, packaging and licensing directly with the vendor before you build a business case on it.

1. Why the vendor choice is really an integration choice

There is a fantasy version of predictive maintenance procurement in which you evaluate three analytics engines on the quality of their failure prediction, pick the most accurate one, and plug it in. I have never seen a project that resembled that. What actually happens is closer to this: you discover that the asset hierarchy in the candidate platform does not match the one in your maintenance system, that the equipment identifiers differ, that the sensor tags carry no reliable link to the asset they belong to, that your failure history is coded inconsistently, and that the work order the prediction is supposed to generate has to land in a system the platform does not natively write to.

Every one of those problems is an integration and master data problem, not an analytics problem. And each of them costs more to solve than the difference between a good model and a very good model is worth. This is why I open every predictive platform conversation with an unglamorous question: where does your asset master live today, and where are your maintenance transactions recorded? The answer usually narrows the shortlist to one before anybody has seen a demo.

The underlying logic is the same one that governs any enterprise integration decision. Moving analytics to the data is cheap. Moving data to the analytics is expensive, ongoing, and fragile. For the general shape of this trade-off in asset-heavy organisations, see the ERP selection guide for asset-heavy operators and the CMMS to ERP integration pillar.

2. SAP: prediction anchored to the transaction layer

SAP's approach to predictive maintenance is best understood as an extension of the maintenance and finance transaction layer it already runs. If your organisation records equipment, functional locations, maintenance plans, notifications, work orders, spare parts and maintenance cost in SAP, then SAP's asset performance capability starts from a position no other vendor can match: it already holds the asset master, the maintenance history, the bill of materials, the inventory position and the cost of every past intervention, in one data model, with one set of identifiers.

The offering in this space has been marketed under several names, including Predictive Asset Insights and, more recently, Asset Performance Management, typically positioned alongside the S/4HANA maintenance functionality and delivered on the SAP Business Technology Platform. Names in this part of the SAP portfolio change often, so verify current naming and packaging with SAP rather than relying on any article, including this one. The architecture, however, has been consistent in shape: sensor and condition data is ingested into a platform layer, models score asset health and produce indicators, and those indicators are designed to raise notifications and maintenance orders back inside the core maintenance module where planners already work.

What it is genuinely good at. Closing the loop from prediction to executed, costed work. This is SAP's real differentiator and it is chronically underrated in vendor comparisons. A predicted failure that becomes a notification, then a maintenance order, then a reserved spare part, then a settled cost on a cost centre, without a single integration in between, is worth more operationally than a more accurate prediction that arrives as an email. If you run plant maintenance in SAP, the path from insight to work is short.

Data and licensing prerequisites. The assumption is that your SAP maintenance master data is in reasonable condition: equipment records exist, the functional location hierarchy is coherent, maintenance plans are in use, and notifications carry usable coding. Many SAP shops fall short on the last point in particular. Licensing in this area is a platform and consumption conversation rather than a simple per-asset figure, and it sits on top of your existing core entitlement. Establish exactly what your current agreement covers before you assume the capability is included.

Realistic integration effort. Light on the enterprise side, heavier on the operational technology side. You are not integrating the asset master or the work management, which removes the largest normal cost. But you are likely to be building the sensor ingestion path, mapping tags to equipment numbers, and doing the historian or gateway work to get condition data into the platform reliably. Expect the OT side to be where the schedule slips.

Who it is wrong for. Organisations that do not run maintenance in SAP. If your work orders live in Maximo, Hexagon EAM, Infor or a mid-market CMMS, SAP's main advantage evaporates and you are buying an analytics platform that now needs the same bidirectional integration as anyone else's, with the added weight of the SAP platform stack. It is also a poor fit where the asset population is small and highly bespoke, because the transactional depth that justifies SAP has nothing to work with. For background on how the SAP maintenance transaction layer itself is structured, see the SAP preventive plant maintenance walkthrough, and for SAP's own documentation, the SAP Help Portal is the only source I would trust for current module naming.

3. Siemens: prediction close to the machine

Siemens comes at predictive maintenance from the opposite end of the stack. Where SAP starts at the transaction and reaches down toward the sensor, Siemens starts at the machine and reaches up toward the enterprise. That difference in direction explains almost everything about where each one is strong.

The Siemens position in this space has been assembled from several lineages: the industrial IoT platform originally marketed as MindSphere and subsequently repositioned under the Insights Hub name within the broader Xcelerator portfolio, plus Senseye Predictive Maintenance, which came in through acquisition and is the piece most directly aimed at condition-based failure prediction on rotating and production equipment. As with SAP, the packaging here has been reorganised more than once, so confirm current naming and bundling with Siemens rather than assuming what is written here still holds.

What it is genuinely good at. Proximity to operational technology. Siemens builds the controllers, drives, motors and automation layer in a very large share of the world's industrial plant, and that shows in how little friction there is getting data out of the machine. If your production line is largely Siemens automation, the sensor and control data path is the part of the project that behaves. The predictive layer is also strongest where Siemens is strongest commercially: discrete and process manufacturing, fleets of similar production assets, rotating equipment with clear vibration and load signatures.

Data and licensing prerequisites. This approach assumes you have, or can install, real condition instrumentation and a viable path from the plant floor to a data platform. It is far less dependent on a clean enterprise asset master than SAP or IBM, which is both a strength and a trap: you can get a pilot running quickly without fixing your master data, and then discover at scale that the predictions cannot be reconciled to the assets your maintenance team actually manages. Licensing tends to be structured around connected assets and platform consumption; treat any figure you are quoted as specific to your deal.

Realistic integration effort. Low to moderate on the OT side, moderate to high on the enterprise side. Getting data in is comparatively easy. Getting a prediction to become a scheduled, resourced, closed-out work order in an EAM or CMMS that Siemens does not own is a genuine integration project, with all the usual questions about identifier mapping, duplicate work order suppression, and who owns the record of truth for asset health.

Who it is wrong for. Building and facilities portfolios. Predictive maintenance in an office tower, hospital or campus estate is a different problem from predictive maintenance on a production line: the assets are more varied, the failure consequences are usually lower per asset, and the value sits in the FM work management process rather than in production continuity. Siemens' industrial strength does not transfer cleanly to that world. It is also the wrong choice where your automation estate is a mixed bag of vendors and the OT-proximity advantage never materialises. Siemens' own material is at siemens.com .

4. IBM: prediction on top of a mature asset data model

IBM's position rests on Maximo, which has been the reference enterprise asset management system in utilities, transport, oil and gas and large public infrastructure for a long time. The predictive capability is delivered as part of the wider Maximo Application Suite, with components that have been marketed as Maximo Predict for failure prediction and remaining useful life, Maximo Health for asset health scoring and condition indices, and Maximo Monitor for sensor data ingestion and anomaly detection. Suite composition and how those components are licensed have changed over time, so verify current packaging with IBM.

What it is genuinely good at. Operating on a serious asset data model. Maximo's asset, location, classification, job plan, failure hierarchy and work order structures are among the most thoroughly developed in the industry, and thirty years of utility and infrastructure deployment has shaped them around how reliability work is actually done. When the predictive layer sits directly on that model, it inherits a genuinely usable asset context: classification, criticality, failure class, meter history, and a complete work order history with costs. That context is what distinguishes a health score that means something from a generic anomaly flag.

The second strength is that the loop closes inside the suite. A health index that degrades, a prediction that fires, a condition threshold crossed, all of these can generate Maximo work orders natively against the same asset record, with the same job plans and the same failure reporting. For organisations that already run Maximo as their EAM, this is the same argument I made for SAP, applied to a platform whose centre of gravity is asset management rather than finance.

Data and licensing prerequisites. The prerequisite is a well-populated Maximo: assets classified, criticality assigned, failure hierarchy in use, meters reading, and a history of work orders with coded failures. Maximo is capable of supporting all of that and many implementations use only a fraction of it. If your Maximo is essentially a work order logger with a flat asset list and no classification, the predictive components have much less to work with than the demo suggests. Suite licensing has historically been consumption-based across the components, which makes it flexible but also makes it easy to underestimate; model it against your actual asset and user counts before committing.

Realistic integration effort. Light on the asset and work management side if you already run Maximo, because you are configuring within a suite rather than integrating across vendors. Moderate on the sensor side: the monitoring component is designed to ingest time series, but the tag-to-asset mapping and the historian or gateway work is still real engineering. Heavier if finance and procurement live in SAP or Oracle, since cost and parts still have to flow across that boundary, which is a well-trodden but non-trivial integration.

Who it is wrong for. Organisations without Maximo and without the scale to justify adopting it. Maximo is a substantial platform with a substantial administration and configuration burden, and adopting the whole suite to obtain predictive maintenance is the tail wagging the dog. It is also a poor fit for lightweight facilities portfolios that would be better served by a modern CMMS with basic condition monitoring. IBM's material is at ibm.com .

5. The three-way comparison, side by side

The table below is the summary I would put in front of a steering committee. It deliberately says nothing about model accuracy, because in my experience that is not the variable that decides outcomes.

Read the last row carefully. Each vendor's typical failure mode is the mirror image of its strength. The transaction-strong platform struggles at the sensor boundary. The sensor-strong platform struggles at the work management boundary. The asset-model-strong platform struggles when the asset model turns out to be empty.

6. What all three actually require from you

Underneath the architectural differences, the three platforms make an almost identical set of demands, and the demands are the expensive part. Any of them will need:

• A single authoritative asset register. One list of equipment, with stable identifiers, a coherent hierarchy and no duplicates. This is the single most common blocker and the one nobody budgets for. See the asset master data management pillar.
• A reliable tag-to-asset mapping. Every sensor tag has to resolve to exactly one equipment record. In brownfield plant this mapping is frequently undocumented, partially wrong, and maintained in a spreadsheet by one person.
• Criticality classification. Predictive effort has to be concentrated, and concentration requires a ranking. Without one you will instrument whatever is easiest rather than whatever matters. See the asset criticality classification pillar.
• Usable failure history. Consistent failure coding and captured downtime. Every one of these platforms performs better with it and none of them can manufacture it.
• A closed work management loop. A prediction has to become a work order, get scheduled, executed and closed, with the outcome fed back. If it lands as a dashboard alert it will be ignored inside a month.
• Someone whose job it is. A reliability engineer or condition monitoring lead who owns thresholds, model tuning and the triage of alerts. Unowned predictive programs decay quietly.

None of that is vendor-specific, which is the point. If you are comparing three platforms and the comparison is mostly about features, you are comparing the wrong thing. The differentiator is which one lets you meet these six requirements with the least new integration. For the wider platform landscape beyond these three, including the mid-market options, see the predictive maintenance platforms comparison.

7. Choosing between them: the honest decision guide

Here is the decision logic I would actually apply, expressed as a table rather than a flowchart because the inputs are situational rather than sequential.

8. The shape of the cost, and what gets underestimated

I will not quote prices, partly because they are commercially specific and partly because any figure I published would be wrong within a year. What is stable, and more useful, is the relative shape of the cost. Across enterprise predictive maintenance deployments the pattern is consistent:

• Software licensing or subscription is the line everyone negotiates hardest and it is rarely the largest total.
• Instrumentation and installation is straightforward to estimate and usually estimated reasonably well, because it is physical and visible.
• Data preparation and master data remediation is routinely underestimated by a wide margin, because it is discovered rather than specified. This is where projects overrun.
• Integration to work management and finance is underestimated whenever the predictive platform is not the system that already owns those processes.
• Ongoing model and threshold tuning is frequently omitted from the business case entirely, then absorbed informally by someone with another full-time job.
• Change and adoption, meaning getting planners and technicians to trust and act on predictions, is the least funded and most decisive line item.

Notice that four of the six are independent of which vendor you pick. That is the strongest practical argument for choosing on integration proximity: it is the only lever that meaningfully reduces the lines that actually dominate the cost.

9. An evaluation checklist you can lift

If you are running a formal evaluation, these are the questions I would put to all three vendors, in writing, and score. They are deliberately weighted toward integration and data rather than features.

• Asset identity. How does your platform resolve a sensor tag to an equipment record in our system of record, and who maintains that mapping over time?
• Write-back. Show a prediction becoming a work order in the system where our technicians actually work, including job plan, assignment and closure, with our identifiers.
• Feedback loop. When a technician closes that work order with a failure code and a finding, how does that outcome reach the model?
• Cold start. What does the platform do on an asset with two years of patchy history and no run-to-failure examples? Be specific about what degrades.
• Confidence. Does any remaining useful life output carry a confidence range, and how is it presented to a planner?
• Alert volume. What is the expected alert rate per hundred monitored assets per month at default configuration, and what tuning is required to make that manageable?
• Data egress and portability. If we leave in five years, what do we take with us, in what format, and at what cost?
• Skills. What internal role, at what seniority, owns this platform day to day, and how many of them does a deployment our size need?
• Reference call. A reference customer in our sector, at our scale, running in production for at least two years, with the option to ask about what went badly.

The last one is the highest-yield question in the list. Two-year-old production references tell you what the second year looked like, which is when predictive programs either become routine or quietly stop being used. For the groundwork on how the prediction itself works, independent of vendor, see the failure prediction and RUL pillar and the condition-based versus predictive maintenance comparison.

10. How I would design the pilot, whichever vendor you pick

The pilot design matters more than the vendor selection, because a well-designed pilot will expose a bad vendor fit and a badly designed pilot will hide it. What I would insist on:

• Pick assets by consequence, not by convenience. The temptation is to instrument the machines that are easiest to reach. Instrument the ones whose failure actually hurts, even if the installation is harder.
• Include the work management crossing in scope. A pilot that stops at a dashboard proves the analytics and nothing else. Make the prediction generate a real work order in the real system.
• Baseline before you start. Record unplanned downtime, mean time between failures and emergency work percentage on the pilot assets for the period before the pilot. Without a baseline you cannot demonstrate anything afterwards.
• Keep it small and long rather than large and short. Ten assets for twelve months teaches you more than a hundred assets for eight weeks, because failure events are rare and you need to observe some.
• Track the false positives openly. The alert that sent a technician to a healthy machine is the most important data point you will collect, and the one most likely to be quietly dropped from the report.
• Name an owner with time allocated. Not a committee. One reliability engineer with explicit hours in their week.

If the sensor layer is the part you are least sure about, the IoT to CMMS integration pillar covers the architecture in more detail, and the CAFM versus CMMS versus EAM versus IWMS comparison is worth reading if you are not certain which category your system of record actually belongs to.

The idea to walk away with

SAP, Siemens and IBM are all genuinely capable predictive maintenance technologies, and the difference between them is not primarily a difference in analytical quality. It is a difference in where they sit relative to your data. SAP is strongest when the maintenance and cost transactions are already its own. Siemens is strongest when the machines and the automation layer are already its own. IBM is strongest when the asset register and the work management are already its own. In each case the strength is proximity, and proximity is what determines how much of the project is analytics and how much is plumbing.

So the honest answer to "which one should we choose" is usually not exciting. Choose the one that already holds your asset master and your maintenance transactions. If none of them does, the first project is not predictive maintenance, it is master data. And if your critical failure modes turn out to have no detectable warning, the right answer may be that none of these platforms should be bought at all, which is a conclusion worth reaching before the procurement rather than after it.

Final thoughts

A pattern I have watched repeat: an organisation runs a rigorous feature comparison, selects the platform that scored highest on analytics capability, and then spends the first two years of the programme building integrations and cleaning master data so the analytics has something to work on. The model was never the constraint. The plumbing was. A slightly less capable platform sitting on top of data it already owned would have delivered value a year and a half earlier.

That is not an argument against rigour in selection. It is an argument for weighting the selection correctly. Score integration proximity, data readiness and the closed work management loop heavily, score model sophistication lightly, and insist on production references with two years behind them. And before any of it, confirm that your critical failure modes are actually detectable, because predictive maintenance technologies of every brand share the same hard limit: they cannot predict what gives no warning. For the vendor-neutral grounding on that, the predictive maintenance practitioner's guide is the place to start.

Related reading: Predictive maintenance: a practitioner's guide, Predictive maintenance software and platforms compared, Condition-based vs predictive maintenance, SAP preventive plant maintenance: how it works, Master data management for assets, CMMS integration with ERP.