SAP Asset Performance Management – Optimize, Predict, Transform.

Challenge 1: Compliance with IT Policies
Involving the IT department is essential when implementing IoT projects. Software should never be purchased without their approval or involvement. While trade fairs often showcase attractive solutions, professional and stable operation within the company requires proper IT integration.

Challenge 2: Impact on Warranty and Maintenance Intervals
A critical challenge when adjusting maintenance schedules is warranty compliance. Manufacturers may reject changes to maintenance plans and refuse warranty coverage under such conditions. We therefore recommend either selecting equipment that is already out of warranty, or clarifying the planned maintenance intervals with the manufacturer in advance.

Some manufacturers allow extended maintenance cycles, for example after 4,000–8,000 operating hours instead of fixed annual intervals – similar to the automotive sector, where servicing is based on time or mileage.

Challenge 3: Reducing Complexity at the Start
The entry into IoT and machine learning projects should not be overly complex. It is advisable not to begin with a sophisticated algorithm or the most challenging use case. Instead, a proof of concept (PoC) should focus on a scenario that is easy to understand for all stakeholders – even without machine learning expertise.

The impact of an IoT project depends heavily on the individual role. For machine operators, very little changes at first – apart from the fact that the machine may need to be briefly taken out of operation during retrofitting. It is important that these employees are kept informed transparently.

Direct involvement becomes more relevant when, for example, OEE (Overall Equipment Effectiveness) tracking is planned – this affects production and supply chain management more than maintenance.

The most directly affected groups are maintenance technicians and planners. Their way of working changes, for instance through the shift from time-based to condition-based maintenance. Downtimes may then no longer occur at fixed intervals but on short notice based on sensor data. This transition requires new processes – and, above all, the early involvement of the teams concerned.

Our first recommendation is the use of the OPC standard (Open Platform Communications). We have had very good experiences with this approach, particularly when integrating different systems into a modern maintenance architecture.

If OPC is possible, we prefer to implement this protocol. However, it is not mandatory: for example, if an existing RASC interface is available, we can integrate that as well.

For older equipment – such as legacy Siemens controllers without OPC capability – we work with manufacturers that provide IoT connectors. These connectors communicate with the existing control system and act as an OPC client. This way, sensor data can be transferred to the server in a standardized data model – even without native OPC support.

In short: whether modern machinery or retrofit, we find a way to enable data collection and integration.

The integration of APM with the S/4 backend is typically handled via the Cloud Connector. Through event measurements, measurement documents from APM can be synchronized with the corresponding indicator values in S/4.
Classes, characteristics, and measurement points originate from the backend and are replicated into APM – supplemented, if necessary, by local APM attributes.

The core master data model is provided by SAP itself. In practice, however, there are differences, for example between vehicle types or manufacturers (BMW vs. Audi, combustion engine vs. electric vehicle).
The guiding principle is therefore: work as standardized as possible, but remain flexible where necessary. The goal is to use identical characteristics and measurement points for as many technical objects as possible – and only adapt where it is functionally required.

SAP APM works best for assets where failures have significant cost, safety or availability impact—such as production machines, turbines, compressors, rolling stock or critical infrastructure. The more data you can collect for these assets, the more value APM can deliver.

Sensor signals such as vibration, temperature or pressure are ingested, evaluated against rules or machine‑learning models, and turned into insights or alerts. These recommendations can then trigger maintenance in SAP EAM, allowing you to act before a failure impacts operations.

A common approach is to select a focused pilot scope—e.g., one asset type or production line—then combine existing SAP data with a small set of sensors. Evora typically helps define a use case that is easy to explain, like detecting early bearing failures, and validates value in a short proof‑of‑concept before scaling.

Master data is typically synchronized from S/4HANA EAM into APM, and measurement documents or events can be exchanged via cloud connectors. When a risk or condition threshold is reached, APM can trigger work in EAM, which technicians then execute using mobile tools such as SAP Service and Asset Manager.

We typically start by harmonizing equipment classes, characteristics and measurement points in SAP EAM. Where necessary, we introduce standard naming conventions for sensors and tags so data can be interpreted consistently across sites and manufacturers.