AI in industrial maintenance can only be evaluated after the operational problem has been defined. Scheduling work orders against available capacity, retrieving technical knowledge, and forecasting future asset condition are different jobs, with their own data, risks, and validation criteria. Grouping all three under the same AI label hides exactly what a buyer needs to compare.
This guide organizes the decision by use case, shows what must be demonstrated before a purchase, and separates PM Run's documented scope from specialized applications that require a separate engineering project.
Start with the job AI is expected to improve
A technical evaluation starts with an observable task and a result that can be measured. “Using AI in maintenance” defines neither. “Reduce weekly scheduling time without assigning an operation to someone who lacks the required skill” already identifies the job, the constraint, and part of the test.
The NIST AI Risk Management Framework recommends evaluating AI systems within their specific context of use, with validation, monitoring, transparency, and human intervention proportional to risk. In maintenance, that context includes asset criticality, the consequence of a wrong decision, the quality of available data, and accountability for the final decision.
Three problems frequently appear in maintenance discussions. They should not be purchased or validated in the same way.
1. Work order scheduling and assignment
This is a combinatorial problem. Work orders have duration, priority, windows, and required skills, while the workforce has shifts, absences, capacity, and different qualifications. A tool can suggest a distribution that respects those constraints and leave the final decision with the planner.
This is the documented AI use case in PM Run. In the Planning module, Manu's assignment function suggests work order assignments based on skills, capacity, and availability. The planner defines the period, reviews the result, makes any necessary adjustments, and only integrates the schedule with SAP after confirmation. The scope is assignment recommendation, with no failure prediction and no autonomous asset decision.
A serious demonstration needs a set of work orders and resources that contains real conflicts. The test should answer:
- Did the recommendation respect skills, shifts, absences, and available capacity?
- Can the planner understand why a person received a given operation?
- Is a violated constraint visible before integration?
- Can the user change the recommendation and retain accountability for the schedule?
- Does the confirmed result reach SAP through the documented workflow?
The functional scope of this application is described on the PM Run Planning page.
2. Assistants for technical knowledge retrieval
An assistant can reduce the time spent searching procedures, manuals, and internal knowledge bases. Its value depends less on how fluent the answer sounds and more on the evidence it can show. In maintenance, a plausible answer without a reference can lead to an unsuitable intervention or an incorrect interpretation of a regulatory requirement.
The test should use questions with known, documented answers. For every response, verify whether the assistant:
- identifies the document and passage supporting its guidance;
- distinguishes an internal procedure, an OEM manual, and a regulatory requirement;
- states when the knowledge base does not contain enough information;
- respects document version, unit, site, and access profile;
- does not turn general information into authorization to perform a critical task.
The assistant supports retrieval. Procedure approval, regulatory interpretation, and asset decisions remain with the technical roles designated by the company.
3. Anomaly detection and condition forecasting
This use case requires a dedicated project. Before discussing a model, engineering must define the asset function, the failure mode, the variable capable of indicating degradation, the measurement technique, the available history, and the time required to respond. Vibration, oil, ultrasound, temperature, and process variables observe different phenomena. A set of closed SAP work orders does not replace those signals when the goal is to detect the physical condition of a component. The predictive maintenance guide explains this discipline in more detail.
The NASA Reliability-Centered Maintenance Guide treats predictive testing and inspection as a selection of tasks applicable to failure modes and their consequences. The technique and the interval depend on the equipment, application, environment, and ability to detect degradation with useful lead time.
For that reason, “ready-to-install predictive maintenance” is an incomplete description. A supplier must state:
- which failure mode the model is intended to detect;
- which signals are used and at what sampling frequency;
- how the reference condition was established;
- which false alarm and missed detection rates appeared in testing;
- how much useful time exists between an alert and the intervention;
- who validates the alert and which operational action it triggers.
PM Run does not offer predictive AI, sensors, or a digital twin as a documented module. When a plant has a specialized condition monitoring project, the resulting work order, schedule, and intervention record still need to enter the maintenance workflow and SAP PM.
Historical analysis does not become AI merely because it uses an algorithm
Work orders, notifications, causes, symptoms, durations, and costs support important analyses: recurrence by equipment class, repair time deviation, concentration of rework, and backlog by criticality. Many of these questions can be answered with statistics, rules, and well-designed analytics. Calling every analysis AI makes it harder to understand which decision improved and how the result was validated.
PM Run provides prepared and automated maintenance data so that each company can build its own indicator dashboard. This supports analyses of MTTR, MTBF, backlog, cost, resource loading, and productivity according to the operation's needs. This configurable dashboard should not be confused with a model that predicts failure.
The maintenance management guide in Portuguese explains how to organize this foundation before selecting an analytics layer.
Data requirements change with the use case
There is no single type of “data for AI.” Assignment needs work orders, duration, skills, capacity, shifts, and availability. An assistant needs controlled, current, and authorized documents. A condition model needs physical signals relevant to the failure mode, along with operating context.
Field reporting remains central because it closes the execution loop. It records when the work occurred, who performed it, what was found, and which action was taken. It improves indicators and allows teams to compare a recommendation with the outcome. This does not mean that every model must be trained on the plant's work order history.
If a work order is confirmed from memory at the end of a shift, cause and duration no longer represent the actual job. Before looking for an AI application, correct this flow within the maintenance planning and control process.
Validation checklist before purchase
- Define the decision. Write down which task will be supported, who decides, and which error would be unacceptable.
- Name the inputs. List fields, signals, documents, frequency, source, and data quality ownership.
- Establish a baseline. Compare the result with the current process and with cases whose answer is known.
- Test exceptions. Include absences, missing data, emergency work, an outlier asset, and a constraint conflict.
- Measure the relevant error. Time saved does not offset an invalid assignment, a missed alert, or unsupported guidance.
- Define oversight and feedback. Determine who confirms, how corrections are made, and how performance will be monitored after deployment.
The complete NIST AI RMF 1.0 reinforces that validity and reliability must be verified in the context of use and monitored throughout the lifecycle. A generic demonstration only confirms that the interface works in the scenario prepared by the supplier.
Frequently Asked Questions
Does PM Run offer predictive AI?
Not as a documented module. The documented AI application in PM Run is Manu, which suggests work order assignments in Planning based on skills, capacity, and availability. Sensors, automated failure prediction, and digital twins require specific solutions and projects.
Does Manu schedule work autonomously?
No. The planner selects the work orders and period, receives the recommendation, reviews the result, and can adjust it. Activities only proceed to SAP when the user initiates integration.
Is work order history enough to predict failure?
Not in every case. History helps analyze recurrence, durations, recorded causes, and intervention outcomes. Forecasting the physical condition of a component may require vibration, oil, ultrasound, temperature, or another variable tied to the failure mode.
How should two maintenance AI suppliers be compared?
Compare the same use case with the same inputs, constraints, and error criteria. Require documented scope, data provenance, exception handling, human oversight, and measurement of the result in the context of your plant.
Where should a company start?
Select a bounded decision, confirm that the required data exists, and build a test with a known result. For work order scheduling, the sample can be an actual week with skill and capacity conflicts. For asset condition, the sample starts with a failure mode and a detection technique defined by engineering.
PM Run Advanced Study Group
The PM Run Advanced Study Group, GEA, holds invitation-only sessions focused on customers and partners. Customers and partners can request an invitation from their account executive. Companies that are not yet customers can contact the commercial team to learn about the initiative.
