SAP PM (Plant Maintenance) is the module of the SAP ERP dedicated to maintenance management: it records and manages notifications, orders, maintenance plans and the history of a plant's assets. With SAP PM, the team plans, executes and reports interventions in the same system that already controls the company's purchasing, inventory, costs and finance.
In practice, this means that every failure, inspection and preventive service becomes a structured record, with cost charged to the correct asset. It is this traceability that makes SAP PM the maintenance management standard in the large industries running SAP in Brazil.
In this guide, you will understand what the SAP PM module is, how the notification and order flow works, which are the essential day-to-day transactions (with a reference table), where the module tends to get stuck in practice and how to unlock execution in the field.
What is the SAP PM module?
The abbreviation PM comes from Plant Maintenance. SAP PM is the module that structures maintenance processes inside the SAP ERP, covering three main fronts: inspection (assessing the real condition of the assets), preventive maintenance (preserving the condition, avoiding the failure) and repair (restoring the condition after the failure).
Because it lives inside the ERP, the module talks natively with the others: when a maintenance order needs a part, the reservation comes out of inventory (MM); when it consumes labor and materials, the cost is charged to the cost center and the asset (CO/FI). No isolated CMMS delivers this factory-wide accounting integration.
In the current versions of the platform, with SAP S/4HANA, maintenance processes have become part of the Asset Management area (EAM, Enterprise Asset Management). The logic of technical objects, notifications, orders and plans remains the same, and the market still calls the module SAP PM.
For management, SAP PM is the transactional backbone of Maintenance Planning and Control (PCM): it is where the planner materializes plans, schedules orders and extracts the history that feeds the industrial maintenance KPIs.
This point answers a frequent doubt of those evaluating tools: if the company already runs SAP, keeping maintenance in a disconnected parallel system means registering assets twice, reconciling costs manually and living with two histories that never match. The most solid path is to use SAP PM as the transactional core and solve the usability gaps with specialized layers on top, as we will see further on.
How SAP PM works: technical objects and structure
Before any order, SAP PM needs a faithful representation of the plant. That representation is made through the technical objects:
Functional location: the functional position in the plant (for example, filling line 2 or the boiler recirculation pump), organized in a hierarchy
Equipment: the individual physical asset, with its own number, which can be installed in or removed from a functional location
Work center: the team or shop responsible for execution (mechanical, electrical, instrumentation)
Task list: the standard routing of operations for a recurring service, reused by the maintenance plans
The master data is completed by the measurement points and documents (condition readings, such as temperature, vibration or hour meter, recorded on the asset), the performance counters (which allow preventive services to be triggered by usage, not just by calendar) and the bills of material (BOM), which relate the materials and spare parts of each piece of equipment and speed up the parts reservation when planning the order. The main SAP PM objects and the role of each one are detailed in a dedicated guide.
It is this structure that makes it possible to answer management questions: how much does the maintenance of that line cost per year, which piece of equipment fails the most, which shop is overloaded. Without a well-built register, the best order flow in the world produces empty reports. That is why serious implementation projects start with cleaning up the register: a location hierarchy consistent with the production process, equipment with manufacturer data filled in and work centers with realistic capacity.
The maintenance flow in SAP PM: from notification to closing
The core process of the module follows a well-defined cycle:
Maintenance notification: the operation or the inspection records the occurrence or the need for service. It is the demand entry document. There are different types of notification in SAP PM (malfunction, request, activity), and using the right type is what preserves the failure history. See the step by step of how to create a notification in SAP PM.
Maintenance order: the PCM triages the notification and converts it into an order, with operations, materials, tools and planned hours. The order is the cost document: everything the service consumes is charged to it.
Scheduling: the order receives a date, priority and work center, respecting the production window and the team's capacity.
Execution: the technician performs the service in the field.
Reporting (confirmation): the executor records hours worked, materials consumed and what was actually done.
Technical completion: the order is completed with cause, symptom and activity recorded, feeding back the asset history.
Throughout this cycle, the order changes system status: created when opened, released when it is ready for execution (with materials and permits resolved), technically completed when the service ends and business completed when the costs are settled. Tracking orders stuck in each status is one of the fastest ways to diagnose where the process jams: many orders open without release indicates a planning bottleneck; many orders released and not executed indicates a capacity or scheduling bottleneck.
Maintenance plans: automated preventive maintenance
Beyond this corrective flow, the maintenance plans automate recurring demand. There are two main modalities:
Single-cycle plan: one activity repeated at a single fixed interval, for example, lubrication every 30 days or inspection every 500 operating hours
Strategy plan: a package of activities with different intervals on the same object, for example, monthly inspection, semiannual overhaul and annual general replacement, with SAP combining the cycles automatically
The cycles can be based on time (calendar) or on performance (counters of hours, kilometers, operating cycles). With the deadline monitor running as a job, the module generates the period's preventive orders on the right date, with no manual intervention. The PCM's work becomes calibrating the cycles based on the failure history, rather than opening orders one by one.
SAP PM and PCM: who does what
A common confusion for those arriving in the area: SAP PM and PCM are not the same thing. PCM is the function (the process and the people who plan, schedule and control maintenance); SAP PM is the transactional system where that function records and executes the work. A mature PCM without a system lives on spreadsheets and memory; a SAP PM without disciplined PCM becomes a repository of bad data. The two support each other, and that is why the quality of field reporting matters so much to both.
Essential SAP PM transactions: reference table
In the SAP GUI, each action corresponds to a transaction code. The table below gathers the transactions that planners, schedulers and supervisors use the most in their daily work:
| Transaction | Function | Flow step |
|---|---|---|
| IW21 | Create maintenance notification | Demand |
| IW22 | Change maintenance notification | Demand |
| IW23 | Display maintenance notification | Demand |
| IW28 / IW29 | Change / display notifications in a list | Triage |
| IW31 | Create maintenance order | Planning |
| IW32 | Change maintenance order | Planning |
| IW33 | Display maintenance order | Planning |
| IW34 | Create order from the notification | Planning |
| IW38 / IW39 | Change / display orders in a list | Scheduling and backlog |
| IW41 | Report (confirm) order execution | Reporting |
| IW42 | Overall confirmation of the order | Reporting |
| IW45 | Cancel a confirmation | Reporting |
| IP41 | Create single-cycle maintenance plan | Preventive |
| IP42 | Create strategy maintenance plan | Preventive |
| IP10 | Schedule maintenance plan | Preventive |
| IP30 | Deadline monitor for the plans (job) | Preventive |
| IA05 | Create general task list | Preventive |
| IL03 | Display functional location | Technical objects |
| IE03 | Display equipment | Technical objects |
| IH01 | Display functional location structure | Technical objects |
Two practical observations: the IW38/IW39 and IW28/IW29 lists are the heart of backlog management in the module, because they allow orders and notifications to be filtered by status, work center and period. And the IP30 monitor usually runs as an automatic job, generating the period's preventive orders with no manual intervention.
Types of maintenance that SAP PM supports
The module accommodates the main industrial maintenance strategies, which evolved over the generations of maintenance:
1. Corrective maintenance: divided into planned (the failure was detected in advance and the repair enters the schedule) and unplanned (the breakdown surprises the team). In the SAP flow, it is born from a malfunction notification and becomes a corrective order.
2. Preventive maintenance: interventions at intervals defined by time or usage, generated automatically by the maintenance plans. It reduces prolonged shutdowns by anticipating the replacement of deteriorated components.
3. Predictive maintenance: based on the real condition of the equipment, with inspections and monitoring (vibration analysis, thermography, oil analysis). In SAP PM, measurement points and documents record these readings and can trigger maintenance when the parameter leaves the range. It is the strategy that contributes most to reducing MTTR and avoiding emergency corrective work.
The choice between the strategies is not exclusive: mature plants combine the three, calibrated by the criticality of each asset. A comparative guide to the types of maintenance helps define that yardstick.
Why use SAP PM: benefits for the company
When well implemented and fed, the module delivers benefits that go beyond the maintenance area:
History and traceability: each intervention is recorded on the asset, with cost, cause and solution, creating the plant's technical memory
Cost under control: charging by order makes it possible to know exactly how much it costs to maintain each piece of equipment and line
Integration with purchasing and inventory: reservations, requisitions and orders are born from the order itself, with no rework between areas
Safety and compliance: structured procedures, permits and records support audits and HSE requirements
Basis for indicators: MTBF, MTTR, availability, backlog and preventive compliance come from the module's transactional data
The sectors impacted go beyond maintenance: purchasing (quoting and replenishing parts), production (windows and equipment release), finance (costs and budget) and the plant management itself, which gains visibility to decide.
It is worth reinforcing the link with occupational safety: maintenance that is well recorded and executed on time reduces exposure to failures that cause accidents, and the module's structured history supports the records required in HSE audits. Industrial maintenance is not only about machine availability; it is about the integrity of people and process.
Where SAP PM gets stuck in practice (and why)
Those who operate the module every day know that the process design is rarely the problem. The classic bottleneck is in the last mile, between the field and the system. The symptoms repeat from plant to plant:
Reporting far from the asset: the technician performs the service in the field, notes it on paper or from memory, and only records it in SAP hours later, on a shared computer. The data arrives late and impoverished.
Batch closing at the end of the period: orders closed in bulk to "clean up" the backlog, with generic texts and prorated hours, destroy the failure history and distort the indicators.
Poorly classified notifications: a malfunction recorded as an activity, cause and symptom left blank, a one-line description. The module accepts it, but the reliability analysis becomes unfeasible.
Invisible backlog: without discipline in the IW38/IW28 lists and without stratification by work center, the service portfolio grows without anyone seeing where the capacity overrun is.
Usage friction for the executor: the SAP GUI was designed for the planner in the office, not for the maintainer with dirty hands in the field. Every minute of friction becomes an incentive not to record.
Configuration errors that charge interest later
Part of the jams are born back at implementation. The most recurring: an excess of notification types and mandatory fields, which pushes the user toward generic recording or out of the system; cause and symptom catalogs too extensive for the executor to navigate; work center capacity registered fictitiously (everyone available 8 hours a day, with no vacations or training), which turns scheduling into fiction; and asset criticality not configured, leaving order prioritization to the judgment of whoever shouts loudest. The practical rule is to design the process for the worst usage context (the technician in the field, in a hurry), not for the ideal office user.
To size the effect of the reporting bottleneck, consider a hypothetical example: a plant with 40 maintainers where each executor spends 30 minutes a day between walking to a terminal, remembering what they did and typing the report. That is 20 hours of labor a day consumed by bureaucracy, the equivalent of two or three maintenance orders that fail to be executed every day, without counting the loss of quality of the data recorded from memory.
The result is a vicious circle: bad data generates a bad indicator, which generates a bad decision, which reinforces the perception that "SAP does not work for maintenance". The module works; what is missing is closing the cycle in the field. We map these points in detail in the article on the main bottlenecks in maintenance management through SAP.
How to unlock SAP PM: mobility in execution
The mature answer to the last mile is to bring SAP PM to the technician, and not the technician to SAP. That is the role of mobility over the module: applications that run on the executor's smartphone or tablet, integrated in real time with the SAP backend. We explain the complete journey in the practical guide to mobility in maintenance with SAP PM and in the comparison of maintenance software for those who use SAP.
PM RUN Mobility was built exactly for this scenario, by people who implement mobility over SAP PM in Brazilian factories. In practice, the application allows you to:
Receive and execute the maintenance orders directly on the phone, working online and offline
Open notifications at the location of the occurrence, with the correct notification type and a photo of the problem
Report hours, materials and observations at the moment of execution, eliminating paper
Sync everything with SAP in real time, keeping the module as the single source of truth
Locate teams and services by geolocation
When evaluating a mobility layer over SAP PM, four criteria separate projects that unlock the operation from projects that end up on the shelf:
Real offline operation: a factory has areas with no signal; the app needs to operate disconnected and sync later, without losing a report
Native, real-time integration with SAP: the order the technician sees on the phone is the SAP order, with the same status, with no intermediate spreadsheet or double entry
Experience designed for the executor: few taps to report, mandatory fields that guarantee data quality (cause, symptom, activity) without adding bureaucracy
Process governance: the app must reinforce the PCM flow (correct notification types, complete technical completion), not create an uncontrolled parallel path
With reporting done next to the asset, the history becomes reliable again, the backlog reflects reality and the indicators start to support decisions. It was the path taken by industries such as Rivelli Alimentos, which implemented PM RUN to increase maintenance productivity, and Citrosuco, which optimized maintenance management with real-time tracking. The gains also appear in the productivity of the maintenance area as a whole: less walking, less administrative rework and more wrench time.
Frequently asked questions about the SAP PM module
What does SAP PM mean?
PM is the abbreviation of Plant Maintenance. SAP PM is the module of the SAP ERP responsible for maintenance management: asset registration, notifications, orders, preventive plans, execution reporting and failure history, integrated with the inventory, purchasing, cost and finance modules of the same system.
What does the SAP PM module do?
The module structures the entire maintenance cycle: it records demand in notifications, converts it into orders with materials and planned hours, schedules execution, receives the technician's report and closes with cause and symptom recorded. It also generates preventive orders automatically from maintenance plans based on time or counter.
What is the difference between a notification and an order in SAP PM?
The notification records the occurrence or the need for service: it is the demand document, opened by whoever detects the problem. The order is the execution and cost document: it defines operations, materials, hours and work center, and receives the charging of everything the service consumes. The healthy flow converts triaged notifications into planned orders.
Is SAP PM a CMMS?
Yes, SAP PM fulfills the role of a CMMS (computerized maintenance management system), with one important difference: it is born inside the ERP. That guarantees native integration with inventory, purchasing and finance, something that isolated maintenance systems have to build through interfaces.
What are the main SAP PM transactions?
In daily work, the most used are IW21/IW22/IW23 (create, change and display notifications), IW31/IW32/IW33 (orders), IW34 (order from the notification), IW38/IW39 (order lists and backlog), IW41 (execution reporting), IP41/IP42 (maintenance plans) and IP10/IP30 (scheduling and deadline monitor for the plans).
Does SAP PM exist in S/4HANA?
Yes. In SAP S/4HANA, maintenance processes are part of the Asset Management area (EAM), with more modern Fiori interfaces. The logic of technical objects, notifications, orders and plans remains, and the market keeps calling the module SAP PM or Plant Maintenance.
