S&OP sets the plan. S&OE executes against it when reality disagrees. Written down, the split is obvious. In practice the handoff between them is where a lot of planning transformations quietly fail.
Here is what that failure looks like from inside a programme.
The symptom: exceptions that nobody owns
The clearest tell is a class of exception that neither process claims. It is too short-horizon for the monthly S&OP cycle to address and too structural for the weekly S&OE team to resolve — so it gets escalated, discussed, and reappears next week unchanged.
When a control tower is mostly re-litigating the same handful of issues, this is usually why.
Cause 1: different data, same question
S&OP runs on aggregated, cleansed, consensus-agreed numbers. S&OE runs on live, messy, current state. Both are correct for their purpose. The problem starts when they disagree and no one has defined which wins for a given decision type.
Getting regional leadership to agree the definitions behind a global planning KPI cockpit — forecast accuracy, inventory aging, service levels — is tedious work, and it is what stops this argument from recurring monthly. If the definitions are not agreed, every review meeting re-opens them.
Cause 2: the plan is not actually constrained
Consensus forecasts built from statistical models and sales input, without being tested against constrained supply, produce a plan that S&OE cannot execute. Execution then spends its time absorbing the gap rather than managing genuine variability.
Blending statistical models, sales input and industry signals against constrained supply raised consensus forecast accuracy by 6.5% on one programme. The accuracy gain matters less than what it implies: the plan became executable, so S&OE could do its actual job.
Cause 3: process design stops at L3
Many transformations design S&OP and S&OE to level 3 — boxes, arrows, ownership — and stop. L4 and L5 are where the handoff lives: who does what, with which data, in which system, on which day, and what happens when the answer is ambiguous.
Designing the L4/L5 demand-planning processes explicitly is what converts a process diagram into something a planner can follow at 9am on a Tuesday.
Cause 4: no shared exception taxonomy
If S&OP and S&OE classify exceptions differently, the handoff cannot be automated and cannot be measured. A shared taxonomy — with thresholds agreed by both — is a precondition for exception-based planning working at all.
Get this wrong and the exception queue becomes noise, which means planners start ignoring it, which means the system has failed regardless of how well it is configured.
What good looks like
- One agreed set of KPI definitions, signed off by regional leadership, not by the project team
- A consensus forecast tested against constrained supply before it is published
- L4/L5 process detail for the handoff, not just L3 boxes
- A shared exception taxonomy with thresholds both processes accept
- A named owner for the ambiguous middle — the exceptions that are neither clearly strategic nor clearly executional
None of this is software. All of it determines whether the software you are implementing produces a plan anyone can execute.