Capacity Evaluation and Leveling in Classic PP
Learn how planners evaluate capacity load at work centers and perform manual or graphical leveling to resolve overloads before production order release.
Explanation
Once planned orders and production orders exist with routing-derived operations, SAP calculates capacity requirements against the available capacity of each work center (defined via the capacity header and shift sequences in the work center master). Capacity evaluation is the process of comparing these requirements to available capacity over a time horizon, typically using the standard capacity evaluation transaction (CM01) for a work center view, or CM50 for a plant-level cross-work-center view. The evaluation shows load percentage per period (day, week, or period defined by the planning calendar), highlighting where requirements exceed available capacity. Capacity requirements are generated from two sources: planned orders (from MRP, dependent on the planning strategy and lot size) and production/process orders (after order creation, based on the operations in the routing or master recipe). Each operation carries a formula-based duration (setup, machine, labor) that SAP multiplies by the operation quantity to derive load in capacity category units (usually hours). The work center's available capacity is defined by capacity category (machine, labor, setup) with shift definitions, breaks, and a capacity utilization percentage that accounts for planned downtime or efficiency loss. When overloads appear, planners use capacity leveling to shift, split, or reassign operations. CM21 provides a detailed, order-by-order leveling view (table or graphical Gantt-style) where operations can be dispatched, moved to different dates, or moved to alternate work centers if capacity is unavailable. CM25 offers a plant-level overall profile for cross-work-center leveling. Leveling in classic PP is a planner-driven, largely manual activity, though SAP provides sorting and strategy profiles to prioritize which orders get dispatched first (for example, by earliest finish date, priority, or setup-time minimization). Finite scheduling, triggered from within capacity leveling or during order scheduling, moves operations to periods where capacity is genuinely available, converting infinite scheduling results (which allow overload) into a feasible plan. This differs by order type and configuration: production orders can be finitely scheduled at release, while planned orders are typically evaluated but not finitely scheduled until converted. A critical design decision is which capacity category drives leveling (machine vs. labor) and whether pooled or individual capacities are used, since pooled capacities (shared across several work centers) require different evaluation logic. In practice, capacity planning is most effective when work center master data (available capacity, shift definitions, formulas) is accurate; inaccurate setup or run-time formulas are the most common root cause of misleading overload signals. In S/4HANA, this classic capacity evaluation and leveling functionality remains available and largely unchanged in on-premise and private cloud editions, though many organizations layer PP/DS on top for finite, constraint-based scheduling (covered in the next lesson). Public cloud editions generally push customers toward PP/DS-based capacity management rather than classic CM01/CM21 leveling, so verify current scope in your specific cloud release before designing a rollout around classic transactions.
Real project scenario
A discrete manufacturing client running S/4HANA private cloud found that a bottleneck work center consistently showed 150% load in CM01 for the next two weeks. The root cause investigation revealed the work center's shift sequence had not been updated after a recent shift-pattern change (they had moved from two shifts to three), so available capacity was understated in the system even though physical capacity had increased. After correcting the shift definition and capacity utilization percentage, load dropped to a realistic 95%, and the planning team then used CM21 to manually redistribute a handful of remaining overloaded operations to a secondary work center with idle capacity.
Common mistakes
• Assuming CM01 overload automatically means physical capacity is insufficient without first checking work center master data accuracy • Ignoring the capacity utilization/efficiency factor, leading to overstated available capacity • Leveling orders manually without considering downstream operations, creating new bottlenecks later in the routing • Not distinguishing between planned order load (which is speculative until firmed) and production order load (which is committed) • Using CM25 plant-level leveling without understanding it aggregates across work centers, potentially masking a single overloaded resource
Best practices
• Validate work center shift sequences and capacity utilization percentages whenever physical shift patterns change • Use CM01/CM50 as a regular monitoring cadence (daily or weekly) rather than only reacting to shortage messages • Document a leveling priority strategy (e.g., customer priority, due date, setup minimization) so leveling decisions are consistent across planners • Separate planned order capacity review from production order capacity review since one is speculative and one is committed • Coordinate capacity leveling decisions with MRP controllers so rescheduled operations do not silently violate material availability dates
Interview angle
Interviewers commonly ask how you would investigate an unexpected overload shown in capacity evaluation, expecting you to check work center capacity header, shift definitions, formula accuracy, and order quantities before concluding a genuine resource shortage exists. They may also probe your understanding of the difference between infinite and finite scheduling and when each is appropriate during the planning cycle.