SAP PM explained: functional locations and equipment, task lists and maintenance plans, the work order cycle and statuses, and the master data that makes it work
SAP PM, SAP Plant Maintenance, from the maintenance side: the master data objects from functional locations and equipment to task lists, maintenance plans, measuring points and catalogs, the work order cycle from notification to settlement with its system statuses and classic transaction codes, notification types and codes, plans and scheduling, and the master data problems that spoil the history. With a drawing of the master data and work cycle.
Key takeaways
- SAP PM, plant maintenance, is the maintenance module of SAP ERP and of asset management in S/4HANA. It holds the asset structure, the job plans and schedules, and the work order history.
- The master data is a hierarchy of functional locations with equipment installed in them, plus bills of materials, task lists, maintenance plans, measuring points and catalogs.
- Work runs from a notification to an order that is planned, released, done, confirmed, technically completed and settled. Each step has a status that reports can rely on.
- Most SAP PM problems are master data problems: a flat hierarchy, equipment never created, catalogs nobody uses, task lists without durations or parts.
- The system works when the process around it does. A notification with good codes, an order with a real plan and a confirmation with what was found are what make the history worth having.
A site runs SAP PM for ten years and has a quarter of a million closed orders. Someone asks which pumps fail most and why. The answer is not in the system, because most orders were raised against the area rather than the pump, the damage and cause codes were left blank or set to 'other', and the pumps themselves were never created as equipment. The system did everything it was asked to. It was never asked for the right things.
This guide covers SAP PM, also called SAP Plant Maintenance, from the maintenance side: the master data objects and how they fit together, the work order cycle and its statuses, notification types, and the master data problems that spoil the history. It is written for planners, engineers and supervisors rather than SAP configurers. Enco is not affiliated with SAP, and the transaction codes named are the classic ones, with S/4HANA offering Fiori apps for the same steps.
Master data and the work cycle
SAP PM has two halves. The master data describes the plant and the standard work: where everything is, what it is made of, what maintenance it needs and when. The transactional data is the work itself: notifications, orders, confirmations and their costs. The master data is set up once and maintained, and the transactional data is created every day from it.
Each half depends on the other. A maintenance plan calls a task list for a piece of equipment and generates an order. A notification raised against equipment carries its catalog codes into the history. If the master data is thin, every order is planned from scratch, and the history cannot be read by asset, failure mode or cost.
SAP PM records what it is given. The quality of the history is set by the master data and the codes.
The master data objects
The functional location hierarchy is the backbone. It is usually built to a structure such as ISO 14224, from site and area down through system and unit to the maintainable item positions, with tags that match the drawings. Equipment is installed at those positions, so a gearbox that moves to the workshop and back keeps its own history.
| Object | Classic transaction | What it is | Why it matters |
|---|---|---|---|
| Functional location | IL01 | A place in the plant hierarchy where equipment is installed, such as a conveyor drive position | The structure the work and cost history hang from |
| Equipment | IE01 | An individual, serialised item that can be installed at a functional location and moved | Keeps its own history wherever it is installed |
| Bill of materials | IB01 | The spare parts that make up a piece of equipment, linked to material numbers | Lets planners pick parts onto an order |
| Task list | IA05, IA01, IA11 | The operations, trades, durations and parts for a job, general or for one equipment or location | The standard job plan, reused by orders and plans |
| Maintenance plan | IP41, IP42 | When a task list is called, by time, counter or a strategy of packages | Generates preventive orders on schedule |
| Measuring point and counter | IK01 | A reading taken on an object, such as run hours or a thickness | Drives counter-based plans and condition records |
| Catalogs | QS41 | Damage, cause, object part and activity codes used on notifications | What makes failure history countable |
The work order cycle
Work in SAP PM follows the same work order cycle as any CMMS, with a system status at each step. The statuses are what reports, backlogs and KPIs rely on, so an order left released after the work is done counts as backlog, and an order closed without confirmations shows no labour. Most sites add user statuses, such as awaiting approval, awaiting parts or ready to schedule, to show where work is held between creation and release.
| Step | Classic transaction | What happens | Status |
|---|---|---|---|
| Notification | IW21 | A malfunction or request is raised against a functional location or equipment | Notification outstanding (OSNO) |
| Order created | IW31, or from the notification | The planner creates an order, adds operations, trades, durations and components | Created (CRTD) |
| Released | IW32 | The order is approved and released, reservations and purchase requisitions go out | Released (REL) |
| Scheduled and done | Capacity planning, or a separate scheduling tool | The order is put in the weekly schedule and the work is done | Released (REL) |
| Confirmed | IW41 | Hours, actual work and completion are confirmed against each operation | Partly confirmed (PCNF), Confirmed (CNF) |
| Technically complete | IW32 | The notification is completed with its codes and the order closed for work | Technically completed (TECO), notification completed (NOCO) |
| Settled and closed | KO88, IW32 | Costs settle to the cost centre or project and the order is closed | Closed (CLSD) |
Notifications and codes
The notification is where the failure history starts. A malfunction report carries the object part, damage and cause codes from the catalogs, and those codes are the only way to count failures by mode across hundreds of assets. A catalog that is too long, too vague or optional produces codes nobody trusts. A short catalog built from the site's equipment classes and failure modes, with the codes completed when the order is technically complete by someone who saw the job, produces history that root cause analysis and reliability engineering can use.
| Type | Name | Used for |
|---|---|---|
| M1 | Maintenance request | Work wanted that is not a failure, such as an improvement or a minor job |
| M2 | Malfunction report | Something has failed or is failing, with damage and cause codes |
| M3 | Activity report | A record of work already done, such as an inspection result |
Plans, task lists and scheduling
Preventive work comes from maintenance plans. A single cycle plan calls a task list every so many weeks or run hours. A strategy plan calls packages of tasks at different intervals from one plan. The plan generates orders ahead of their due date by a call horizon, which gives the planner time to prepare them. The task list carries the operations, trades, durations and parts, so the generated order arrives already planned, which is the point of the preventive maintenance program.
Scheduling is where many sites go outside the core module. The weekly schedule, with its capacity by trade and frozen list, is often built in a separate scheduling tool or spreadsheet fed from SAP, and the results go back as dates on the orders. However it is done, the planning and scheduling process and its measures, such as backlog in crew-weeks, need the order durations and statuses to be right.
Where SAP PM goes wrong
Most SAP PM complaints are not about the software. They come from master data that was loaded once at go-live and never maintained, and from a process where the system is filled in after the work rather than used to run it. Master data is a maintained asset, with an owner, a standard and a change process, and an asset hierarchy rebuild is often the single change that makes the history usable.
| Problem | What it costs |
|---|---|
| Flat or inconsistent functional locations | Cost and history cannot be rolled up by area, system or equipment class |
| Equipment never created, work raised on locations only | No history follows a motor or gearbox when it is changed out |
| Catalogs too long, too vague, or optional | Damage and cause codes are skipped or always 'other', so failures cannot be counted |
| Task lists without durations, trades or parts | Orders cannot be scheduled or kitted, and planners rebuild each one |
| Maintenance plans with stale intervals | Preventive work that no longer matches the strategy, or plans calling work for removed equipment |
| Orders left open after the work | Backlog that is not real, and costs that never settle |
Common mistakes
- Raising work against an area or system instead of the equipment or position.
- Catalog codes optional, or completed by someone who did not see the job.
- Task lists with no durations, so the backlog cannot be counted in hours.
- Orders technically completed weeks after the work, or never.
- Maintenance plans left calling work for equipment that was removed.
- User statuses added for every possible state, so nobody keeps them current.
- Treating master data as a go-live task rather than an ongoing one.
Common questions
What is SAP PM?
SAP PM, or SAP Plant Maintenance, is the part of SAP's ERP software that manages maintenance. It holds the technical structure of the plant as functional locations and equipment, the job plans as task lists, preventive schedules as maintenance plans, and the work itself as notifications and maintenance orders, with costs flowing to finance. In S/4HANA it sits under asset management, with Fiori apps beside the classic transactions.
What is the difference between a functional location and equipment in SAP?
A functional location is a place in the plant where a function is performed, such as the drive position on a conveyor. Equipment is an individual physical item, such as a particular motor with a serial number, that is installed at a functional location. When the motor is changed out, the new one is installed at the same location and the old one keeps its own history, so the history of the position and of each item are both kept.
What is the difference between a notification and an order in SAP PM?
A notification records that something needs attention: a malfunction, a request or a record of work done, with codes for the object part, damage and cause. A maintenance order is the plan and record of the work: its operations, trades, hours, parts, costs and confirmations. One notification usually leads to one order, and the notification's codes are completed when the order is technically complete.
What are the order statuses in SAP PM?
The main system statuses are created (CRTD), released (REL), partly confirmed (PCNF), confirmed (CNF), technically completed (TECO) and closed (CLSD). Notifications move through outstanding (OSNO), in process (NOPR) and completed (NOCO). Sites usually add user statuses on top, such as awaiting parts or ready to schedule, to show where work is held up.
What are the main SAP PM transaction codes?
Commonly used classic transactions include IW21 to create a notification, IW31 to create an order and IW32 to change it, IW41 to confirm time, IL01 to create a functional location, IE01 to create equipment, IA05 for a general task list, IP41 and IP42 for maintenance plans, IK01 for a measuring point, and IW38 or IW39 to list orders. S/4HANA also offers Fiori apps for the same steps.
Key terms
Plain-language definitions from our glossary for the concepts this article leans on.
Standards and further reading
Related case studies and tools
Related reading
Working through something like this?
See how we approach these initiatives, or tell us what you are dealing with.