SAP Capacity planning

MRP plans what and when, but assumes infinite capacity; capacity planning then checks the load it creates against each work center’s available capacity, highlighting overloads, and lets planners level the load (reschedule) so the plan is executable. It turns a materials-feasible plan into a capacity-feasible one.

Worth stating the default plainly, because it surprises people: standard MRP and standard order scheduling assume capacity is unlimited unless finite scheduling is switched on. So a plan that looks complete and achievable has usually not been checked against capacity at all, and the check is a separate step somebody has to take.

• Work-center capacity: available hours/output.
• Capacity requirements from planned/production orders (via routings).
• Capacity evaluation: load vs available.
• Capacity leveling: rescheduling to remove overloads.

One distinction that matters when reading an evaluation: capacity requirements come from both planned and production orders. So a load figure includes work that has not been converted into an order yet, which is what makes it useful for medium-term planning and also means it changes every time MRP runs.

Capacity planning is three activities and most implementations do the first and stop, which is why the data exists and nobody uses it.

Requirements are generated automatically. Every planned and production order that uses a work centre creates a capacity requirement on the days its operations are scheduled. Nobody has to do anything for this to happen.

Evaluation compares requirements against available capacity and shows the result, usually as a percentage load per work centre per period. This is where overload becomes visible, and it is visible nowhere else: the orders themselves look fine.

Levelling is resolving it. Move an order earlier or later, split it across periods, send it to an alternative work centre, add a shift, or accept the overload and let the plant work it out. Some of this can be automated with a levelling profile and much of it is a planner deciding which customer waits.

The gap that matters is between the second and the third. A business that generates requirements and runs evaluation and never levels has bought visibility without acting on it, and the planners keep using a spreadsheet because the system tells them there is a problem and not what to do about it.

Half an hour, and it shows why infinite scheduling is comfortable and misleading.

1. Check a work centre's available capacity: hours per shift, shifts, utilisation.
2. Create several production orders needing that work centre in the same week, more than the hours allow.
3. Look at each order. They all scheduled successfully, with sensible dates, because scheduling was infinite.
4. Run capacity evaluation for that work centre. The week is over a hundred per cent, and that is the first place the problem appears.
5. Level it: move one order to the following week and watch the requirement redistribute.
6. Now switch the order type to finite scheduling and repeat. The orders schedule differently, because the system refuses to plan beyond available capacity.

Step three is the point. Nothing warned you at order creation, and nothing will unless somebody looks at evaluation or finite scheduling is switched on.

Without capacity planning, MRP can propose more production than the plant can perform, leading to missed dates and firefighting. Capacity planning gives realistic, achievable schedules. It relies on accurate routings (operation times) and work-center capacities, and is central to reliable production planning.

It also decides whether the dates in the system are believed. A plant whose schedule regularly asks for more than it can produce learns to treat SAP dates as advisory and to plan on a whiteboard, and once that happens the data going back in degrades too, because confirmations follow the whiteboard rather than the plan.

• Which work centres are constraints. Not every one needs capacity planning. The bottleneck does, and modelling capacity on machines that are never the constraint is maintenance for no benefit.
• Utilisation factor. The honest allowance for breaks, changeovers and downtime. Setting it at a hundred per cent guarantees the plan is wrong.
• Finite scheduling or evaluation only. Finite produces executable plans and needs accurate data. Evaluation is easier and depends on somebody looking.
• Who levels. A named planner per area, or nobody, and the second is the usual answer.

Capacity is answered at three levels and confusing them is why capacity conversations go in circles.

Long term, rough-cut. Months out, at product family level: do we have roughly enough plant and people for the demand plan. This belongs with sales and operations planning rather than with production orders, and the answer is investment or hiring.

Medium term. Weeks out, against planned orders from MRP: is the plan feasible on the constrained resources. This is where levelling earns its keep, because there is still time to move work.

Short term, sequencing. Days and hours, against released production orders: what order do we run these in, given changeovers and what is set up now. Standard capacity planning handles this poorly, which is why plants with genuine sequencing complexity use detailed scheduling tooling.

The mistake is expecting one mechanism to serve all three. Capacity evaluation in PP is a medium-term tool. Using it to answer a long-term investment question gives false precision, and using it to sequence a shift gives a planner a percentage where they needed an order.

The comparison is only as good as the availability side, and that is built from a few fields worth knowing.

Operating time per day, from the shift definition: start, finish and breaks.

Number of individual capacities, which is how a work centre representing three identical machines offers three times the hours.

Utilisation rate, the percentage of the operating time genuinely available for production. This is where changeovers, maintenance and the fact that nobody works at full rate all day are admitted, and setting it at a hundred is the most common way to make evaluation useless.

The factory calendar, which removes weekends and holidays.

Capacity intervals override the standard availability for a period, which is how a planned shutdown or an extra shift is modelled rather than being remembered by somebody.

The practical test of whether availability is honest: compare a week's available hours against what the plant actually produced in a comparable week. If the system thinks there were forty per cent more hours than were worked, every evaluation is optimistic by that much and nobody will trust it.

• Ignoring capacity, infeasible plans.
• Inaccurate routings/work-center data, wrong load.
• Not leveling known overloads.

• Capacity maintained and never evaluated. The data is accurate and unused.
• Modelling every work centre. Effort spread across resources that are never the constraint.
• Available capacity that has not changed since go-live. See work centres, bills of material and confirmations for the data this depends on.

• Overload shown for months and never acted on. The evaluation becomes wallpaper, and the next real overload is indistinguishable from it.

Reading an evaluation is straightforward, and setting capacity honestly and levelling a real overload is the part you do in the course.

The question to ask before configuring any of this: which work centre is the constraint. Capacity planning on the bottleneck is valuable, and capacity planning on everything is maintenance nobody sustains.