SAP PM

PM manages the maintenance lifecycle: recording technical objects (equipment, functional locations), raising maintenance notifications and orders, planning preventive maintenance, and recording the work and costs. It keeps plant and equipment running and captures maintenance history.

• Technical Objects: equipment and functional locations.
• Maintenance Notifications & Orders: reporting and executing work.
• Preventive Maintenance: scheduled maintenance plans.
• Confirmation & Costs: recording work done.
• Maintenance history.

PM starts with the technical structure, and getting that right is most of a successful implementation.

A functional location is a place where something operates: a production line, a pump house, a section of pipeline. It is hierarchical and it does not move. Equipment is an individual asset with a serial number that can be installed at a functional location, removed and installed elsewhere. The distinction matters because history follows each differently: the location accumulates everything that happened there, the equipment carries its own record wherever it goes.

Transactions: IL01 creates a functional location, IE01 creates equipment. IW21 raises a notification, which is somebody reporting a problem. IW31 creates a maintenance order, which is the work and the cost. IW38 and IW28 are the order and notification worklists. IP10 schedules preventive maintenance plans.

The tables are IFLOT for functional locations, EQUI for equipment, QMEL for notifications and AUFK with AFIH for orders.

Half an hour, and it is the whole module in one pass.

1. Create a notification with IW21 against a piece of equipment. This is the report, and it costs nothing.
2. Convert it into an order with IW31. Add an operation with a work centre and hours, and a spare part on the components tab.
3. Release the order. The component becomes a reservation in MM, and if the part is not in stock a requisition can be generated.
4. Issue the part and confirm the hours. Costs accumulate on the order: material from the issue, labour from the confirmation at the work centre rate.
5. Technically complete the order, then settle it. The cost lands on the cost centre or asset it belongs to, and the equipment's history now shows the job.

Step five is what maintenance managers actually want: cost per asset, and a history that says what has been done to it.

PM integrates with MM (spare parts procurement and consumption), CO (maintenance costs), PP (production resources), and HR (labour). It ensures maintenance is planned, executed and costed within the integrated system, and is increasingly enhanced by IoT/predictive maintenance.

The join people underestimate is spare parts. Maintenance drives a large share of procurement, and a maintenance order that reserves a part it cannot get is a stopped job. Materials planning has to know about maintenance demand, which is why PM and MM are usually configured together. Costs settle into controlling, and where equipment is also an asset, finance has a view of the same object.

• How deep the functional location hierarchy goes. Too shallow and you cannot locate a fault. Too deep and nobody maintains the structure.
• Equipment or location. Serialised, movable, individually valuable things are equipment. Fixed positions are locations. Modelling everything as equipment loses the place-based history.
• Preventive strategy. Time based, such as every ninety days, or counter based, such as every thousand hours. Counter based needs readings, and readings need somebody to take them.
• How much detail on an order. Operations, components and permits give control and take time to enter. A technician who finds the order slower than the job will stop using it.

Reactive maintenance is somebody reporting a fault. Preventive maintenance is the system telling you before they do, and it is where PM stops being a work log and becomes a strategy.

A maintenance plan defines what should happen and how often. A task list defines the work itself, operations with times and materials, much as a routing does in production. The plan references the task list, so the work is defined once and scheduled many times.

Single cycle plans repeat on one interval, such as every ninety days. Strategy plans handle nested intervals: a small service monthly, a larger one quarterly, a full overhaul annually, with the packages defined once and scheduled together.

Scheduling can be time based, or performance based against a counter, such as running hours or kilometres. Counter based is more accurate for equipment whose wear follows use rather than the calendar, and it depends on somebody entering readings, which is the part that quietly fails.

When a plan is scheduled it generates call objects, usually maintenance orders, on the due date. The practical failure is generating more work than the team can do: the backlog grows, the plan is switched off to stop the noise, and the maintenance regime disappears with it. Scheduling to actual capacity is a decision, not an oversight to be corrected later.

New PM users conflate these two and it produces messy data, so the distinction is worth stating plainly.

A notification is a report. Something is wrong, or something should be looked at. It costs nothing, anybody can raise one, and it carries no work and no budget. It is the demand signal.

An order is the work. It has operations, materials, a work centre, a cost centre to settle to, and it consumes real money. Someone has to decide it should exist.

The healthy pattern is notifications raised freely by operators, then triaged by a planner who converts the ones worth doing into orders. That gives you two useful numbers: what people are reporting, and what the organisation chose to act on. The gap between them is the maintenance backlog, and it is a genuinely useful management figure.

Where every notification becomes an order automatically, the backlog is invisible and the order list becomes the to-do list. Where orders are raised without notifications, you lose the record of what was reported and by whom.

Learn PM by following its end-to-end process, its master data, its configuration (in SPRO), and its integration points with finance and neighbouring modules. Hands-on practice in a training system is essential.

• Learning screens, not the end-to-end process.
• Ignoring the finance integration that every logistics module has.
• Skipping master-data setup that the process depends on.

• Orders technically complete but never settled. The work is done and the cost is still sitting on the order.
• Preventive plans that generate orders nobody closes. The backlog grows until the plan is switched off, and the maintenance regime with it.
• Notifications used as a to-do list. See customer service for the closely related module that handles external service rather than internal maintenance.

• Structure built once and never revisited. Plants change, equipment moves, and a technical structure that no longer matches the site sends people to the wrong place.

• Confirmations entered days later. The cost and the history are both wrong until they are, and a week of memory is not a reliable source for hours worked.

Raising an order is straightforward, and building the technical structure and preventive strategy that make maintenance measurable is the part you do in the course.

The habit worth forming is reading the equipment history before diagnosing a fault. A pump that has failed the same way three times in a year is telling you something the current notification will not.