Insights/Implementation
It worked in the demo. That was never the question.
What goes wrong after a planning system goes live, why the failure is organisational rather than technical, and what has to exist before software can hold.
Published 25 August 2026·WhiteBox SCM
01 of 06 · The pattern
What going live actually proves
A planning system goes live. The data is migrated, the screens work, the users are trained, the project closes and the team is thanked. Some months later the planners are back in a spreadsheet, the system holds a version of the plan that nobody quite trusts, and the honest answer to what changed is not much.
This is not a story about bad software, and it is usually not a story about a bad implementation partner either. Going live proves that the system can hold the data and produce the outputs. It proves nothing at all about whether the organisation around it will use those outputs to decide anything differently, and that second thing was always the point.
02 of 06 · The demo
Why a demonstration cannot tell you
Every planning tool demonstrates well, and the reason is structural rather than dishonest. A demonstration runs on clean master data, an uncontested demand number, a defined process and a single person driving. Those four conditions are exactly the ones a struggling planning function does not have, and they are supplied by the demo environment rather than tested by it.
So the demo answers a question nobody needed answered. It shows what the software does when the organisational problems are already solved. What it cannot show, because it has assumed them away, is what happens when the demand number is contested, when the process exists on paper only, and when three people each believe a different one of them owns the call.
A demo shows what the software does once the organisational problems are already solved.
03 of 06 · The failures
Four ways it comes apart, none of them technical
The mechanisms are consistent, and each one is an organisational condition that the implementation did not change because implementations are not scoped to change it.
Figure 01 · Four mechanisms
The workaround migrates
A process that was worked around before go-live is worked around after it, in a better interface.
Every workaround exists because the official process did not fit something real: an exception, a customer, a constraint nobody wrote down. Replacing the system does not remove the thing that did not fit. It relocates the workaround, and the new one is usually less visible than the old one because it now lives beside a system everyone believes is authoritative.
The system needs a rule where there was a negotiation
Software has to encode a decision. If the business settled that decision differently depending on who was in the room, there is nothing to encode.
This is where implementations quietly stall. Somebody has to say what the rule is, discovers that the rule has never existed, and the project cannot wait for an organisation to decide something it has avoided deciding for years. So a rule is chosen by whoever is available, it does not match how the business actually works, and it is overridden from the first week.
Master data was a deliverable, not a responsibility
It was cleaned for go-live, by a project team, against a deadline. Nobody owns it on the Tuesday after the project closes.
Data quality is not a state, it is a rate: things change constantly, and what matters is whether anything catches the change. A cleanse with no owner behind it decays from the day it is finished, and it decays fastest in exactly the fields planning depends on, because those are the ones that change most.
Nothing changed about how people are judged
The system changed how the plan is produced. The measures over everyone stayed exactly as they were.
If sales is still measured on a number the new process is supposed to challenge, the process will lose, every month, regardless of how good the tool is. Behaviour follows measurement, and an implementation that does not touch the measures has left the strongest force in the organisation pointed at the old way of working.
Notice what all four have in common. Not one of them would have been caught by a better selection process, a longer testing phase or a different vendor, because not one of them is about the software.
04 of 06 · The plan
What the implementation plan does not contain
Set out the phases of a typical planning system implementation and the gap is visible without anyone needing to argue for it.
Figure 02 · A competent implementation plan
Select
Requirements gathered, vendors compared, a decision taken and signed off.
Configure
The process is mapped into the system, and where it does not fit, one of the two is bent.
Migrate
Master data is extracted, cleaned and loaded against the go-live date.
Test
The configuration is verified against the requirements as they were written.
Train
Users are shown how to operate the screens they will be given.
Go live
The switch is thrown, hypercare runs for a period, and the project closes.
Every one of those steps is necessary and every one of them is about the system. None of them assigns ownership of a number. None establishes a forum with the authority to settle a trade-off. None decides how an exception is routed, or changes what anybody is measured on.
That is not an oversight by the people running it. It is the scope they were given, and it is the scope the market sells. The work that would have made the system hold sits outside the project boundary, before it and around it, and it belongs to the business rather than to the implementation.
05 of 06 · The market
Why neither side of the market closes this
There is a structural reason this gap persists, and it is worth naming plainly because it is not anybody behaving badly.
Consultancies are engaged to produce a recommendation, and a recommendation is a deliverable that can be defined, priced and completed. The work that follows it is open-ended, and it is not what the engagement was bought for. Software companies begin at the tool, because the tool is what they have and what they are paid for, and the organisational conditions that make the tool work are outside what they can sell or control.
So the capability sits in the space between the two: after the recommendation, before the technology, owned by neither. That space is where the planning organisation actually gets built, and it is unglamorous, slow, and difficult to put in a business case, which is precisely why it stays empty.
06 of 06 · The sequence
What to do instead
Not never buy software. The tools are good, they are better than they were, and a planning function beyond a certain size cannot run without them. The argument is entirely about order.
Before selecting anything, establish who owns which number and which decisions are theirs. Get one cycle running where a trade-off is genuinely settled rather than escalated. Write down the rules the system will need to encode, and notice which ones the business cannot yet state, because those are the real requirements and they will not appear in any requirements document. Then buy, and the implementation has something to implement.
Done in that order the software lands on a working process and makes it faster. Done in the usual order it lands on a gap, and what gets automated is the gap.
Software lands on whatever is there. Put something there first.