The maintenance order phase model in SAP S/4HANA

The phase model is SAP S/4HANA's way of describing where a maintenance request or order stands in plain, readable language — instead of forcing planners to decode cryptic system statuses. It splits the end-to-end maintenance process into nine phases, each broken down into subphases that are derived automatically from the underlying system statuses.

Why the phase model exists

For decades, the state of a maintenance order lived in a string of system statuses (CRTD, REL, TECO…) and user statuses. Powerful, but hard to read at a glance — especially for supervisors and technicians who don't live in the transaction codes all day.

The phase model adds a readable layer on top. Every notification, order, and operation always sits in exactly one phase and one subphase (for example "Approved (Order)" or "Work in execution"), and the system derives that subphase from the statuses underneath. The result: anyone can see at a glance what stage a job is in, while the familiar status logic keeps running underneath.

The nine phases

The reactive maintenance process runs through nine phases, each owned by a role:

1. Initiation (technician/employee) — someone observes a malfunction and submits a maintenance request.
2. Screening (supervisor) — the request is evaluated; only accepted requests move on to planning.
3. Planning (planner) — a maintenance order is raised against the accepted request and the work is planned.
4. Approval (person responsible) — the order is submitted for approval through a flexible workflow and is approved or rejected.
5. Preparation (planner) — the approved order is released, which kicks off procurement of the required materials and services.
6. Scheduling (scheduler) — work is scheduled and readiness is monitored across planning buckets.
7. Execution (technician) — the work is carried out.
8. Post-execution (technician) — work is finished or the main work is reported complete.
9. Completion (supervisor) — the order is technically completed and closed.

The proactive (preventive) maintenance process follows the same backbone, with some phases handled automatically by the maintenance plan.

Subphases and system statuses

Each phase contains subphases, and the system derives the active subphase from the system/user statuses on the object. A few concrete examples:

• A notification with Outstanding Notification + Approval Required sits in the subphase Submitted (Request); once Approval: OK + Notification in Process are set, it becomes Accepted (Request).
• An order in Created + Order Approval Required is In Planning (Order); after Order Approved it is Approved (Order); after Released it is In Preparation (Order).
• An operation that is partially confirmed (internally, externally, or via a lean service) is shown as Work in execution; once fully confirmed it moves to Work finished.

The benefit is readability: the subphase is far easier to interpret than the raw status combination behind it.

Phase control codes

Phase control codes give you control over when an order or operation may move to the next subphase. Technically they are implemented as user statuses — each phase control code is a single user status, with separate user status profiles for the order header and for operations.

Their job is to block a transition: an active phase control code stops the business transaction that would otherwise set the system status that advances the order to the next subphase. You can activate them automatically (for example on order creation or on order release), through the BAdI EAM_PHASE_CONTROL_ACTIVATION, via an OData service (from OP2022), or manually on the order. Deactivating one releases the block and lets the order continue.

Planning buckets in the scheduling phase

During scheduling, work is organised into planning buckets — each bucket is defined by plant, planner group, and a time period tied to the scheduling dates. Buckets let a scheduler see the maintenance backlog over time and spot procurement bottlenecks early, with readiness indicators showing whether the required materials and services are expected to be available.

Baseline cost and the approval phase

When an order is approved, SAP persists a baseline cost — a static snapshot of the planned cost that does not change afterwards, giving you a fixed reference to compare actuals against. For orders that run without an approval phase, the baseline cost is captured at the moment the order is released instead.

Configuration and constraints

The phase model ships with the standard scope items Reactive Maintenance Process (4HH) and Proactive Maintenance Process (4HI), which contain everything needed to run both processes. Important: SAP delivers the phase model configuration and does not support changing it — you deploy the delivered configuration rather than designing your own phases. Extensibility happens through the supported hooks (phase control codes, the activation BAdI, and business events) — not by editing the phase definitions.

Common questions

How is a phase model subphase different from a system status? The system status is the underlying technical state; the subphase is a readable label the system derives from it. Same truth, easier to read.

Can I define my own phases or subphases? No — the phase model configuration is SAP-delivered and not meant to be changed. You influence behaviour through phase control codes, the activation BAdI, and business events.

What does an active phase control code actually do? It blocks the transaction that would advance the order to the next subphase, until you deactivate it — useful for enforcing a gate (e.g. an extra check before scheduling).

---

Related: planning buckets · SAP EAM scope items · Resource Scheduling (RSH). Want to set up phase-based maintenance properly in S/4HANA? Explore our SAP PM training.