SAP PM Maintenance Order Process Tutorial (Part 1)

A maintenance order is the central document in SAP Plant Maintenance (PM) used to plan, execute, track, and cost maintenance work on technical objects such as equipment and functional locations. Before an order exists, a problem or maintenance need is usually captured in a notification, but the order is where real work planning happens: operations are defined, resources are assigned, materials are reserved, and costs accumulate against a settlement receiver.

Why it matters: without orders, organizations have no structured way to authorize labor and material consumption, track actual versus planned costs, or maintain a history of what was done to an asset. Auditors, cost controllers, and maintenance planners all rely on the order as the single source of truth for a maintenance job.

Structure: an order header carries the technical object reference (equipment or functional location), order type (which drives numbering, screen layout, and settlement rules), planning plant, main work center, and dates. Below the header, one or more operations describe the actual work steps, each with a work center, control key (which determines whether the operation is costed, capacity-planned, or externally processed), and duration. Operations can have sub-operations and can reference maintenance task lists for standardized, repeatable jobs. Components (spare parts) can be assigned to operations, either reserved from stock or procured externally via purchase requisitions generated automatically from the order.

Lifecycle: an order typically starts in a created status, often linked to a notification. During planning, the planner adds operations, assigns work centers and components, and may run a costing simulation to see estimated costs. Once planning is complete, the order is released, which is a control gate—many systems restrict material withdrawals, time confirmations, and printing until release. After release, technicians confirm time and material consumption against operations. When physical work is finished, the order is set to technically complete (TECO), which stops further planning changes but still allows cost postings to flow in. Finally, after settlement to a cost center, asset, or order, and once no further costs are expected, the order reaches business completion, which usually locks it from further postings.

The notification-to-order relationship is important: notifications capture the 'what and why' (malfunction description, damage codes, priority), while orders capture the 'how and how much' (execution plan and costs). A single notification can be linked to one order, and in some scenarios multiple notifications can reference the same order when several issues are addressed in one job.

In S/4HANA, the underlying order concept remains, but the user experience shifts toward Fiori apps for order management, and some analytical and mobile capabilities are enhanced. The core data model and lifecycle states are conceptually consistent with ECC, though exact app names and navigation differ.

A manufacturing plant experiences a pump failure on the production line. The operator raises a notification describing the malfunction. The maintenance planner reviews it, creates a maintenance order referencing the pump equipment master, adds an operation for mechanical repair with an internal work center, assigns a replacement seal kit as a component from warehouse stock, and releases the order. A technician confirms two hours of labor and withdraws the seal kit against the order. Once the pump is running again, the planner sets the order to technically complete, and at month-end the costs settle to the production cost center for management reporting.

• Confusing notifications with orders and trying to record costs directly on a notification, which does not support cost collection.
• Releasing orders too early before operations and components are fully planned, leading to incomplete work instructions for technicians.
• Forgetting to technically complete orders after work finishes, causing them to remain open indefinitely in reporting and blocking accurate backlog analysis.
• Assuming settlement happens automatically without running the periodic settlement process, resulting in costs stuck on the order.
• Not distinguishing between order status changes that are system-driven (like release restrictions) versus user-driven (like TECO), causing confusion about who can perform which action.

• Always link orders to notifications where a malfunction or request exists, preserving the audit trail of why work was performed.
• Complete planning (operations, work centers, components) before releasing the order so technicians have clear instructions.
• Use technical completion promptly after physical work finishes to keep backlog and history reporting accurate.
• Review planned versus actual costs before final settlement to catch discrepancies early.
• Standardize repeatable jobs using task lists referenced by operations to reduce planning time and improve consistency.

Interviewers often ask candidates to explain the difference between a notification and an order, and to walk through the order status lifecycle from creation to business completion. Be ready to explain why release is a control point, what technical completion versus business completion means for cost postings, and how components and operations relate to the order structure.