The argument in brief
- This question is answered too late in almost every programme. If the old role survives alongside the new system, the assembly work continues in the shadows and the system slowly becomes optional.
- Three functions appear that almost nobody staffs today: stewardship of the cost ledger, the simulation Lab, and model stewardship. Treating them as overhead is the most reliable way to waste the rest of the investment.
- The honest headcount answer is that this changes what people do far more than how many there are, at least in the first two years. Selling it as a cost programme cuts the judgment the organisation still needs.
- Resistance is concentrated in the middle, not at the front line. Planners generally welcome the removal of clerical work. The difficulty sits with those whose authority derives from controlling the number.
- The transition is a sequencing problem. Announce the destination, move one unit, staff the new functions before they are obviously needed, and retire the shadow process explicitly rather than by hope.
The question that gets answered too late
Programmes of this kind rarely fail on the mathematics. They fail on the organisation, and they fail in a specific and repeatable way.
A decision factory does not slot into the existing structure. It changes what a substantial part of the planning organisation is for. When that change is left implicit, which it usually is until well after the first deployment, the old work quietly reconstitutes itself alongside the new system. Both then run in parallel, at greater total cost than before, until somebody senior concludes that the investment underdelivered.
If a planner is still judged on producing a defensible number by hand, they will keep the spreadsheet, and the spreadsheet will win.
It will win because it is the artifact their performance is measured against, because it is the artifact they can defend in a meeting, and because they are behaving entirely rationally given the incentives in front of them. The old job has to be genuinely abolished and the new one genuinely defined, staffed and measured. This paper sets out what those roles are.
The eight roles, before and after
Titles differ between organisations. The eight functions below do not, and every deployment we have seen has needed all of them regardless of what they were called.
| Function | What it was | What it becomes | Measured on |
|---|---|---|---|
| Demand planner | Assembles and defends a number; judgment gets whatever time is left | Owns the outcome of a portfolio; reviews by exception; works the minority of decisions where context is genuinely new | Realised cost against the ledger, and the quality of override reasoning |
| Finance business partner | Constrains the plan after it is produced; arbitrates cost against service case by case | Owns and signs the ledger; recalibrates it each cycle against realised outcomes | Ledger calibration: predicted cost of error against actual |
| Forecasting analyst | Produces estimates, then defends them; improvement competes with the cycle and loses | Owns the demand and lever-response models: their fit, their confidence ranges, their drift | Decision quality downstream, not error metrics in isolation |
| Simulation analyst | Does not exist; scenario work is ad hoc and rarely retained | Runs proposed commitments against thousands of futures before they are made, priced by the ledger | Decisions tested before commitment; value of tests proposed |
| Data engineer | Serves extract requests while the authoritative numbers live in files nobody owns | Owns one pipeline with a hard mandate: every number is entered once | Count of surviving local master files. The target is zero |
| Regional lead | Runs a local variant end to end and defends the local number at consolidation | Owns local inputs, constraints and fitted parameters within uniform global logic | Local calibration, and reason codes rather than a rival file |
| Commercial manager | Commits spend, then commissions attribution that arrives too late to matter | Brings proposed moves to the Lab before commitment; sponsors the tests the models ask for | Priced decisions taken ex ante; experiments completed |
| Function leadership | Arbitrates between functions each cycle; sets targets renegotiated monthly | Sets the objective in writing and the risk appetite: which tail the business will carry | Consistency of the objective across budget and cycle |
Where the same effort gets redeployed
The table above describes changes in kind. Exhibit 1 describes the change in distribution, which is what a leadership team actually has to plan for.
Exhibit 1
The same planning capacity, pointed at a materially different set of activities
Read the bottom four rows carefully, because they are the ones that get cut. Owning the cost model, running the Lab, system unlock and governing the system together account for a meaningful share of effort in the target state, and close to none today. They look like overhead in a business case, because they are not attached to a transaction and produce no visible output in any given month.
System unlock is worth pausing on, because it is the row most easily mistaken for something that already happens. It does not. It is a standing habit of asking, every cycle, what actually capped throughput this time: a cost inefficiency nobody had priced, a policy nobody remembers agreeing to, an approval step that adds delay and no information, a constraint the ledger now makes visible for the first time. Before the ledger exists there is no reliable way to find this, so the habit has nowhere to attach. Once it exists, finding and removing that one binding constraint is a higher-return use of a planner's afternoon than reviewing a hundred routine recommendations the model already has right.
Organisations that treat this as a cost programme fund the automation and skip these four. The consequence is not a loud failure. An unstewarded ledger goes stale within a year, an unstaffed Lab means nothing is tested before commitment, drifting response models quietly degrade every recommendation the engine produces, and with nobody hunting the constraint the organisation keeps optimising everything except the one thing actually holding it back. The system does not break. It becomes ignorable, and the spreadsheets return.
The honest answer to the headcount question
It will be asked in the first meeting, and the credibility of everything else depends on answering it straight.
This changes what the headcount does far more than how many there are, at least over the first two years. The assembly work genuinely disappears and it is a large fraction of current effort. Against that, three functions appear that are not staffed today, and the people capable of filling them are largely the same people currently doing the assembly, which is convenient but not automatic: the transition requires deliberate reskilling rather than reassignment.
Over a longer horizon, planning organisations that complete this transition do tend to run leaner, for the straightforward reason that decision volume can grow without proportional headcount. But an organisation that sells the programme on near-term headcount reduction will make two mistakes at once. It will cut before the new functions are staffed, which guarantees the decay described above, and it will lose the experienced judgment that the architecture specifically depends on for the minority of decisions that were never automatable.
A framing that survives contact with the works council
The clerical component of the planning role is being abolished. The judgment component is being expanded, given better instruments, and measured for the first time on something the people doing it actually control. That is defensible, it is true, and it is considerably easier to sustain than a productivity narrative that the first year will not support.
Where the resistance actually sits
Sponsors routinely brace for resistance from the wrong place. Front-line planners are usually the easiest constituency in the programme. They are the people currently spending three weeks of every month on reconciliation, they know precisely how little of it adds value, and the offer of getting that time back is genuinely attractive.
The difficulty is concentrated one level up, among people whose authority derives from controlling the number. In an unpriced process, influence flows to whoever can most credibly assert what demand will be, and that influence is real, hard-won and about to be transferred to an explicit calculation. Nobody experiences that as a process improvement.
Three things help, and none of them is communication.
- Give the constituency a better role rather than a smaller one. The regional lead who owns local parameters and challenges the model with recorded reason codes has more durable influence than one who wins arguments, because their knowledge now compounds into the system instead of evaporating.
- Make the first evidence come from a peer, not from the centre. A backtest run in a receptive unit and presented by its own leadership is worth several times the same analysis delivered by a corporate team.
- Retire the shadow process explicitly, on a date, in writing. Ambiguity here is read, correctly, as an invitation to wait the programme out.
Sequencing the people change
The organisational transition has its own critical path, and it runs ahead of the technical one rather than behind it.
Name the ledger owner before the first ledger is built, because an artifact without an owner becomes a study. Staff the model steward before the first model is deployed, because a model without a steward drifts silently. Stand up the Lab, even as a single analyst with a laptop, before the first large commitment is put to it, because the first time a commercial director asks the Lab a question is the moment the capability either earns its place or does not.
And change the measurement before you change the process. A planner told to trust the system while still being appraised on manual forecast accuracy has received two instructions, and will follow the one attached to their appraisal. This single misalignment accounts for more failed deployments in our experience than every technical cause combined.