Planning Order Operations, Components, and Permits

Explanation

Once a maintenance order exists with a header (order type, functional location/equipment, priority), it is not yet executable. The real planning work happens at the operation and component level, and this is where most rework and delays occur in production if done poorly. Operations describe the actual work steps: inspect bearing, replace seal, calibrate sensor. Each operation carries a work center (the crew or resource pool), a control key that determines whether the operation is relevant for costing, capacity planning, printing, and confirmation, and a planned duration and number of persons. The control key is a frequently overlooked configuration point: if it does not allow confirmations, technicians cannot log time against that operation, and if it does not permit costing, the labor cost will silently not post even though time was confirmed. Getting the control key wrong is a common root cause of 'missing costs' tickets from finance. Components represent spare parts and materials needed for the work. They are assigned at the operation level and can be sourced from stock (with a reservation created automatically against a storage location) or as a direct/non-stock item that triggers external procurement. When a component is stock-sourced, the system creates a reservation the moment it is saved in most configurations, which reduces available stock visibility for other planners even before the parts are picked - this is intentional but must be understood, because it affects MRP and other orders competing for the same material. If a part is not available, the order can still be saved, but a missing parts check (which planners typically run before release) will flag the shortage so release can be deferred or expedited procurement triggered. Services are handled differently: external work such as scaffolding or specialized calibration is usually represented either as a service line linked to a purchase requisition, or as an operation flagged as an external operation, which generates a requisition automatically. This purchase requisition, once converted to a purchase order and goods/service receipt is posted, feeds actual costs back to the order - an important integration point for the costing lesson that follows. Permits (or permit-relevant data, depending on configuration) capture safety prerequisites: lockout/tagout, confined space entry, hot work authorization, or working-at-height clearance. In many implementations this is modeled through user status profiles, order/operation-level permit indicators, or industry-specific safety add-ons, and the exact mechanism varies by company - this is an area where I will not claim one universal SAP mechanism, because organizations implement it differently (some purely through custom status management, others through dedicated safety functionality). What is consistent is the principle: the order should not be released for execution until required permits or safety confirmations are recorded, and this is normally enforced through user status authorization or workflow rather than being hard-coded. Capacity planning ties into the work center's capacity category (persons, work centers, or a combination). Planners use capacity leveling tools to see overload across a work center for the week and shift or reschedule operations. In practice, many PM teams do lightweight capacity planning - checking backlog reports rather than using detailed capacity leveling - because full capacity leveling is more common in production planning contexts. Whether to invest in detailed PM capacity leveling is a scoping decision that should be made explicitly with the customer rather than defaulted to 'on'. By the time planning is complete, the order should have realistic operations with correct control keys, components with confirmed or at least checked availability, any necessary services requisitioned, and safety prerequisites documented, so that release genuinely means 'ready to execute,' not 'ready to plan some more.'

Code example

-- Illustrative planning checklist logic (pseudo-representation, not an SAP API)Order 000456789 planning review:1. Operation 0010 - Work center MECH01, control key PM01 (confirm+cost allowed), duration 4h, 2 persons2. Operation 0020 - Work center ELEC01, control key PM03 (external, cost relevant), triggers PR for calibration service3. Component 000010 - Material SEAL-2200, qty 2, stock storage location 0001 -> reservation created4. Component 000020 - Material GASKET-KIT, non-stock, direct procurement -> PR created for MM buyer5. Missing parts check -> SEAL-2200 available, GASKET-KIT PR not yet converted (flagged, release deferred)6. Permit check -> Lockout/tagout status not yet confirmed -> release blocked by user status authorization

Real project scenario

A refinery client complained that technicians frequently arrived at job sites without the correct gasket kit, causing repeat visits. Root cause analysis showed planners were assigning components as non-stock direct-procurement items without checking lead time, and the missing parts check was being overridden by a system status that allowed release regardless of shortages. The fix combined two changes: restricting which user roles could override the missing parts warning, and adding a mandatory planning review status before release for all corrective orders above a cost threshold. Rework visits dropped materially within two maintenance cycles, and the planner team gained a clear discipline point that a shortage warning at release is a stop, not a suggestion.

Common mistakes

• Assigning control keys that block confirmations or costing without realizing it, causing labor confirmations to be entered but never costed • Treating the missing parts check as informational and releasing orders anyway, leading to failed field visits • Modeling non-stock components without agreeing lead times with procurement, so 'planned' work is unexecutable for weeks • Assuming a single standard SAP permit mechanism exists across all industries when it is commonly a customer-specific status/workflow design • Ignoring work center capacity entirely and scheduling everything for the same crew on the same day

Best practices

• Standardize control keys by scenario (internal labor, external labor, inspection-only) and document what each allows • Run and respect the missing parts check before release; restrict override authorization to a small planner group • Agree non-stock procurement lead times with purchasing and build them into scheduling buffers • Use user status or workflow to make safety/permit confirmation a hard prerequisite for release on relevant order types • Review work center backlog regularly even if full capacity leveling is not in scope, to catch obvious overloads early

Interview angle

Interviewers probe whether you understand that operations and components are where planning quality is actually determined, not just order header fields. Be ready to explain the role of the control key in enabling confirmation and costing, how stock components generate reservations versus how non-stock components trigger procurement, and why missing parts checks and safety/permit status should gate release. Strong candidates also acknowledge that permit handling is often customer-specific rather than reciting one 'correct' SAP mechanism.