SAP capacity planning: work centres, requirements and levelling

What SAP capacity planning actually does

Capacity planning in SAP answers a narrow and practical question: given the operations sitting on our work centres, do we have enough capacity to execute them when they are scheduled, and if not, what has to move?

It is not demand planning and it is not scheduling in the sales sense. It works from the operations that production orders and planned orders generate, compares them against the capacity the work centre actually offers, and surfaces the overload so a planner can level it.

The four objects you need to understand

• Work centre. The resource that performs the operation, holding the capacity definitions used for planning. Its capacity can be pooled across several individual machines or people.
• Available capacity. What the work centre offers in a period, after the applicable factory calendar, shift pattern and any capacity interruptions. This is the supply side.
• Capacity requirements. The load the operations place on the work centre, derived from their duration and how that duration is distributed across periods. This is the demand side.
• Capacity levelling. The act of moving operations, or dispatching them into periods, so the requirement profile fits inside the available profile. Levelling is manual by design: SAP tells you it is overloaded, the planner decides what gives.

The transactions that do the work

These are the standard transactions planners use, and what each is for.

• CM01 - capacity planning, work centre load. The evaluation view: where the overload is.
• CM02 / CM03 - the same evaluation from the work centre orders and released orders angles.
• CM21 - capacity levelling, graphical planning table.
• CM22 - capacity levelling, tabular planning table.
• CM25 - capacity levelling, variable. The one to use when you want to choose the overall profile at runtime rather than living with whatever the transaction defaults to.

The planning table shows free capacity per period, which SAP calculates as available capacity minus the requirements of dispatched operations minus the requirements of operations not yet dispatched. Dispatched and undispatched requirements are displayed differently, which is how you tell a committed plan from an intention.

Configuration sits behind the transaction

Every one of those transactions is controlled by an overall profile, which is itself a bundle of subprofiles. If the planning table shows the wrong horizon, the wrong objects or the wrong period split, the cause is a profile, not the transaction.

• OPD0 - the overall profile, and the entry point for the rest.
• OPD1 - selection profile: which objects, filters and requirement groupings are shown.
• OPD2 - time profile: the planning horizon. Too short a horizon and orders will not be scheduled beyond it.
• OPDE - control profile: when orders lock, and whether the table presents graphically or tabularly.
• OPDB - strategy profile: dispatch sequence, finite scheduling and planning direction.
• OPD4 - period profile: required for the tabular planning table.

In S/4HANA, the Fiori apps for capacity scheduling are the modern front end, and the classic transactions remain available. The underlying model of available capacity against requirements is unchanged.

Where SAP capacity planning ends

SAP capacity planning is rigorous about the resource it can see: the work centre, and the operations routed through it. It is silent about everything else that consumes an organisation’s capacity - the approvals, the chasing, the rework, the maintenance planning done in a spreadsheet, the supervisor who spends a third of the week reconciling data.

That is the boundary worth understanding. Planning tells you whether the work centres can execute the plan. It does not tell you how much of the organisation’s actual working time is being consumed outside the plan. Closing that gap is what Capacity Intelligence is for, and it is what Zunox measures.

Common questions

Which transaction is used for capacity levelling in SAP?

CM21 for the graphical planning table, CM22 for the tabular planning table, and CM25 for the variable version where you choose the overall profile at runtime. CM25 is the flexible option and the one most planners use day to day.

What is the difference between available capacity and capacity requirements in SAP?

Available capacity is what the work centre offers in a period, after the factory calendar, shifts and interruptions. Capacity requirements are the load that operations place on it, derived from their duration and its distribution across periods. Capacity planning compares the two.

What controls the SAP capacity planning table?

An overall profile, which bundles subprofiles: selection (which objects and filters), time (the horizon), control (locking and presentation), strategy (dispatch sequence and finite scheduling), period and evaluation profiles. They are configured under OPD0 and the related OPDx transactions.

Does SAP capacity planning cover all of an organisation's capacity?

No. It covers the capacity of work centres and the operations routed through them. Work that happens outside those routings - approvals, rework, chasing, manual reconciliation - is not represented, and that is usually a substantial share of the total.

See what your organisation’s work actually looks like.

Zunox captures activity where it happens, attributes it, and turns it into evidence you can act on.