Why Planning Teams Quietly Revert To Excel After Go-Live

A transformation can reach go-live and still fail the way it always has. At first, the planner overrides one recommendation because the numbers looked wrong last Tuesday and keeps a personal spreadsheet to double-check the platform; then, six months later, the whole team trusts that spreadsheet.

Gartner predicts that 60% of supply-chain digital adoption efforts will fail to deliver their promised value by 2028 because of insufficient investment in learning and development. In practice, the problem often begins earlier than that. It starts with whether planners trust the platform enough to stop working around it.

We discussed this challenge with Julia Sanzharova, whose career spans supply chain, enterprise planning and technology. Her work focuses on translating complex planning requirements into reusable digital product capabilities and understanding what allows those capabilities to work across large organisations.

Post-go-live adoption begins long before the platform launches. Sanzharova approaches the problem through her Expert-to-Digital Framework, a three-stage method built around understanding the domain and the decisions a product must support, prioritising reusable capabilities and stress-testing the design against real operational pressure.

The six adoption disciplines below operate across those stages and continue after launch, determining whether the platform becomes and remains the place where planning decisions are made.

Set Honest Expectations About Product Maturity

Adoption starts with a clear understanding of what the organisation is implementing. An established product capability and an emerging one require different conditions. When the capability is still developing, planners need time and authority to challenge design decisions and work with the vendor on improvements. Leadership must fund this co-development and allow for greater instability during implementation and early use.

With a mature capability, the problem flips. By this point, local teams already believe the system works. What’s harder is getting them to give up the version they built around it. Before a market gets a custom workflow, someone should be able to say exactly why: a regulatory requirement or a real difference in how that market sells, not just “that’s how we’ve always done it.”

Vendor evaluation should establish what’s genuinely standard, and what’s still being configured or built specifically for this account. That distinction usually shows up in the product documentation itself and in reference customers you find on your own, not the ones the vendor hands you.

Planners need to know whether they’re adopting a proven capability or helping develop a new one, because that changes how training and post-launch support get planned. Get the expectation wrong and when gaps appear later, trust declines fast and planners start rebuilding the missing logic in spreadsheets.

Agree How Planning Decisions Should Be Made

Separately from product maturity, someone has to decide who actually owns a planning decision and how. In a mature demand-planning process, the forecast and the financial target serve different purposes.

A statistical baseline is created at the level where demand can be predicted reliably, then enriched with documented commercial intelligence. Any gap to the target remains visible and is addressed through agreed actions.

Skip that agreement and planners settle it themselves. A planner may adjust the forecast in a personal file, review it with colleagues and copy only the final number back into the platform. The system records the outcome, while the reasoning and challenge process remain outside it.

Build A Global Model That Can Evolve

Once the decision logic is understood, it has to be translated into a product roadmap. The roadmap should prioritise capabilities that can be reused across markets, while deliberately allowing for justified local requirements.

Customisation rarely starts with one bad call, it’s usually a market insisting its process is unique, or a stakeholder pushing for one more workflow that nobody had the energy to argue against at the time. Some of that turns out to be genuinely justified by regulation or how the market actually works. Most of it is just a habit nobody ever went back and questioned.

At one FMCG company, the transformation spanned dozens of markets shaped by years of acquisitions, each with its own systems and level of planning maturity, across seven connected planning domains. Early pilots were gradually pulled into a reusable global model, built on the principle of staying as common as possible and as local as necessary.

According to programme documentation, the template repository eventually covered up to 96% of market requirements without rebuilding the core solution. The more capability a market could obtain from the shared template, the less pressure there was to recreate missing workflows locally. Recurring requirements from later deployments could then be assessed for inclusion in the common roadmap.

A reusable model also creates a route for improvement that a fragmented one doesn’t. When several markets hit the same limitation, that becomes a shared product capability the roadmap can absorb.

Make Data Readiness A Formal Decision Gate

Advanced planning logic depends on reliable operational data. In one global programme, master data varied significantly across markets.

Procurement and production lead times were derived from actual performance, while transportation lanes were generated using defined rules covering permitted products and routes, priorities and active relationships. This work had to reflect current operations rather than inherited system values.

A working data-readiness gate needs a named owner per data domain and an agreed quality threshold. More importantly, somebody has to actually decide what happens when data isn’t ready, instead of letting the deadline decide for them.

Data quality becomes an adoption issue as soon as planners see recommendations they can’t trust. Once they start checking outputs by hand or keeping a parallel spreadsheet, the platform can stay technically live while operational adoption falls apart around it.

Readiness also needs to be reassessed as the solution expands. Data approved for an earlier implementation may change before the next rollout, while new markets introduce additional sources, owners and definitions. Repeating the gate prevents an earlier sign-off from becoming a permanent assumption.

Measure Where Decisions Are Actually Made

Adoption is visible in where planners investigate exceptions and actually approve decisions. High login rates and completed training modules can sit on top of a platform while the real operational judgement happens somewhere else entirely.

Touchless rates matter, but only alongside forecast quality and bias, service and inventory levels, plan stability and how cleanly exceptions get resolved. A falling override rate is only good news if the recommendations underneath it are still reliable.

AB InBev leaders have publicly reported inventory holdings down 20%, forecast accuracy above 87% by country and SKU and 85% touchless demand-planning output in the US, where out-of-stocks were reported below 0.5%.

None of that proves the platform caused the improvement on its own, but it’s a far better signal of adoption than a training completion rate.

Continue Stress-Testing After Go-Live

A design that performed well during testing faces different pressures after go-live: urgent exceptions, incomplete data, competing commercial priorities and decisions that cannot wait for the next governance meeting.

Executive sponsorship remains important during this period. Leaders need to resolve conflicts between the shared design and local requests, while local teams need a clear route for raising genuine gaps. Recurring overrides and workarounds should be reviewed throughout stabilisation because they provide early evidence of where the operating model is under pressure.

Before approving the next phase of a transformation, leadership should be able to answer three questions. Are decisions being made in the platform? Are exceptions traceable and improving the model? Can the operating process continue without the programme team?

Post-go-live evidence should feed back into the transformation. Repeated overrides can point to missing domain logic. A local spreadsheet that won’t go away can mean a roadmap gap or a decision right nobody settled.

A data correction can mean a readiness gate was passed too early. Investigate these before the workaround becomes routine, not after.

Together, these six disciplines keep the three-stage framework running as a continuous loop.

Domain and industry knowledge shape the product, the roadmap directs investment towards reusable capabilities, and enterprise stress-testing shows how the solution performs under operational pressure. After go-live, recurring overrides, data corrections and local workarounds provide new evidence for the next cycle.

A transformation holds when the organisation continues learning from that evidence after the programme team has left.