IPCIntegrated Planning & Control
An operating system for steering a supply chain

An operating system, not a methodology

Six principles, a twelve stage decision chain running from structural design through execution feedback to the data foundation underneath it, and a control layer of architecture, policy, people, measurement and proof. Select any node to open its definition, worked example and self test.

Layer 1 · Principles

the behavioural base

Layer 2 · The decision chain

how decisions flow

Layer 3 · Control layer

what holds it together
Guided sequence

Twenty steps, in dependency order

Not the order of the process. The order in which the model becomes understandable: outcome first, then its control mechanism, then its precondition, then the machinery.

0 / 20
Four simulations

Move the input, watch the system answer

Each model is illustrative and deliberately simple. The point is the direction and the shape of the response, not a forecast of your own numbers.

How far ahead of the requested delivery the change reaches planning.
As a share of the monthly plan volume for the family.
Longest procurement path through to finished goods. Sets the planning fence.
The execution window in which the schedule is committed.
Where the change lands
Planning horizon, counted backwards from the requested delivery date
Applied cumulatively across the twelve month horizon.
From the routing. Recalibrate from demonstrated performance, not the engineering estimate.
Real conditions versus standard: changeovers, deviations, cleaning.
What the resource has actually produced, not what is installed.
Two weeks of the month unavailable.
Planned load ratio by month
Planned load ÷ demonstrated capacity. Above 100% the plan is not executable as it stands.
Feasible, under 85% Tight, 85 to 100% Infeasible, over 100% Demonstrated capacity
Show the numbers
How often the released schedule is executed as planned.
Expediting, buffers and heroics that catch failures before the customer sees them. The lever most organisations pull instead of fixing the cause.
How a data defect becomes a service failure
Illustrative propagation model. Direction and shape, not your numbers.

Definitions

The working vocabulary

Terms and metric abbreviations as the model uses them. Metric definitions and targets are organisation specific unless stated.

Twenty four metrics

What each KPI measures, and how it is counted

Metrics are diagnostic instruments, not scorecards. Each entry gives the definition, the counting logic, and the distortion that most often makes the number lie. Read the set as a stack: master data feeds plan performance, plan performance feeds execution, execution feeds customer service.

Working definitions. Calculation rules, tolerances and targets are organisation specific, so verify each against your own metrics handbook before using it in a review. Targets are deliberately not printed here: a threshold that is right for a stable make to stock network is wrong for a constrained launch portfolio, and a number carried over from someone else's scorecard is the fastest way to make a metric meaningless.
Eight patterns

It rarely fails through missing documents

It fails through design decisions nobody made, or made once and never revisited. Each pattern breaks a specific principle, which is what makes it diagnosable rather than merely regrettable.

Arrow keys to move · Esc to exit