Binomium | Revolutionize Your Supply Chain Operations

In many companies, and even more in consulting slideware, we still see RCCP treated as if it were a separate function from master planning.

You will hear things like:

master planning creates the plan
capacity planning checks whether it fits
then both "collaborate" to align supply and capacity

This sounds structured. It sounds mature. It sounds like good governance.

But at operational level, it is conceptually wrong.

Because master planning is precisely the combination of MPS and RCCP.

The moment you separate them too much, you are no longer talking about one integrated planning decision. You are talking about a handoff.

And a handoff is not a closed loop.

Why MPS and RCCP belong together

Let us make it concrete.

The MPS is not just a list of quantities. It is a proposal for what should be produced, when, and in what volume over a planning horizon.

RCCP is not some external audit step. It is the immediate test of whether that proposal is feasible at the rough cut resource level.

That already tells you something important:

you do not really have an MPS until you know whether it fits the available capacity.

Now take a very simple but very real situation.

You are planning in weekly buckets. One critical machine has five products running through it. The proposed plan overloads that machine in week 3.

At that point, RCCP is not just "informing" master planning that there is a problem.

A decision must be made.

Which product do you reduce?
Which one do you shift?
Do you split the correction across several products?
Do you protect one SKU because of customer commitments?
Do you delay a lower priority item?
Do you accept temporary undercoverage somewhere else?
Do you increase capacity through overtime or subcontracting?

This is not a neutral capacity check. This is master planning.

Because the moment you level capacity, you are changing the plan itself.

And that is exactly why separating MPS and RCCP into two operational roles makes little sense.

The key problem. Leveling is not neutral

This is where the conceptual confusion usually starts.

People imagine RCCP as if it were just a warning light:

"Machine X is overloaded in week 3."

Fine. But then what?

The moment you act on that overload, you are forced to make a trade-off between products, customers, timing, stock, and service.

That trade-off is not a pure capacity activity. It is a business planning decision.

If several products sit on the same machine in the same bucket, then reducing load means choosing which product absorbs the correction. And unless you have a formal optimisation engine doing that for you, the choice is partly arbitrary.

That is why, ideally, this should be supported by a solver or at least a strong optimisation heuristic. Not because the problem is magically "solved," but because the system can make those trade-offs less arbitrary and more consistent.

Still, whether a human does it or a solver supports it, the point remains the same:

MPS and RCCP are two communicating counterparts of the same planning problem.

They are not two separate operational functions that can be cleanly split between different planners.

They belong together, and for that reason they should normally be owned by one person:

the master planner.

One owner. One loop. No handoff.

Once you split the work between one person who creates the MPS and another who "does RCCP," several things happen immediately.

First, the loop slows down.

The first planner produces a plan. The second planner checks capacity. A conversation starts.

Changes come back. The first planner revises. The second planner checks again.

You now have latency by design.

Second, accountability becomes blurred.

Who owns the final feasible plan? The person who generated the volumes? Or the person who objected to the overload?

Third, local optimisation appears.

The MPS owner may push service and stock targets. The RCCP owner may push load realism and resource protection. Instead of one integrated decision, you get negotiation between two partial views.

That is not maturity. It is fragmentation.

The machine level reality exposes the flaw

This becomes even more obvious when you go closer to the bottleneck.

Suppose a filler, oven, reactor, or packaging line is overloaded in a week. The overload is caused by a mix of products, all competing for the same finite time.

RCCP at that point is not simply saying "too much load."

It is effectively asking:

which products survive unchanged?
which products move out?
how much is shifted?
where is service pain accepted?
where is inventory pain accepted?
what happens to downstream resources?
what happens next week if we move this load?

This is already plan design.

So the idea that one person "owns the plan" while another person "owns the capacity check" collapses under real world logic. The capacity check is interacting with the plan at every meaningful step.

Where industry sometimes does separate them

Now, to be fair, there are industries and environments where this clean ownership by one master planner becomes harder.

For example:

very large semiconductor environments
highly integrated chemical networks
steel or paper operations with shared bottlenecks across many product families
multi site pharma networks
environments where one constrained resource serves many business units
organizations with separate central planning and plant planning teams
companies where capacity decisions are tied to labor, campaigns, or regulatory constraints beyond the normal master planning scope

In such settings, you may find dedicated capacity-oriented roles or teams.

But that does not prove the conceptual separation is correct. It usually proves the opposite: the environment is so complex, politically fragmented, or structurally constrained that the company cannot keep the loop in one hand anymore.

And that has consequences.

What happens when it cannot be done by one person

When MPS and RCCP cannot practically be kept under one owner, the process usually starts to suffer from exactly the same problems every time:

Slower replanningEach overload becomes a conversation, not a direct adjustment.
More negotiation and politicsDifferent planners defend different objectives, often from different parts of the organization.
More arbitrary outcomesWithout integrated optimisation, the chosen correction is often based on who shouts loudest, legacy habits, or local convenience.
Weaker ownershipNo single person fully owns the feasible master plan end to end.
Reduced closed loop capabilityThe system becomes less able to react quickly to changes in demand, supply, or capacity.
Lower trust in the planExecution teams start treating the plan as provisional because they know feasibility is still being debated after publication.

So yes, there are environments where operational reality forces some form of split. But this should be seen as a limitation or compromise, not as the ideal model.

The real definition of master planning

This is the point we think many people miss.

Master planning is not just generating planned receipts. And RCCP is not some external reviewer standing next to it.

Master planning is the act of creating a supply plan that is both commercially meaningful and rough cut feasible.

That means:

deciding what to produce
deciding when to produce it
deciding how much to produce
checking whether it fits rough cut resources
adjusting the plan when it does not

That whole loop is master planning.

So when people speak about RCCP as a separate operational function from master planning, they are often creating an artificial split inside one and the same decision process.

Final thought

The best test is simple.

If a machine is overloaded next week and several products compete for that same capacity, who decides what gets reduced, shifted, or protected?

Whoever answers that question is doing master planning.

And if that same decision has to be bounced back and forth between one planner who owns MPS and another who owns RCCP, then the process is already weaker than it should be.

Because in operational planning, MPS and RCCP are not separate islands.

They are two communicating counterparts of the same decision. And that is why, in principle, they belong to one owner: