Decision preparation

Why End-to-End Planning Transformations Succeed or Fail Before Technology Is Chosen

Most large planning transformations fail long before technology is implemented. Drawing on practitioner experience, this Perspective explores why problem definition, operating model design, and ROI discipline determine success before vendor selection begins.
Published:
 
February 3, 2026
Author & Contributors:
 

Most supply chain planning transformations begin with a deceptively simple question: which system should we choose?

It feels like progress. Shortlists are drawn up, demos are booked, and business cases start to take shape. Yet this is also the point at which many transformations quietly lock in failure. Not because the technology is wrong, but because too many assumptions have already gone untested.

From his experience leading global planning transformation at Coty, Dan Smith describes a different — and more demanding — starting point. When faced with the need to replace or upgrade legacy planning systems, the organisation deliberately resisted jumping straight to vendor selection. Instead, it focused on a more fundamental question: what exactly are we trying to fix — and what happens if we only fix part of it?

That framing proved critical.

At Coty, the team identified fifteen concrete problems to solve across demand, supply, valuation, and decision-making. These were not aspirational future-state ideas. They were specific operational gaps that created manual work, delayed decisions, and undermined confidence in the plan.

An important insight emerged early: partial solutions do not deliver partial value. Manual work does not disappear when only some problems are addressed. It reappears elsewhere in the process, quietly eroding the return on investment the transformation was meant to deliver.

This forced a more honest internal conversation. The question was no longer which tool had the broadest feature set, but whether the organisation was prepared to commit to eliminating entire categories of work — and to accept the organisational implications that followed.

Consultants and system providers routinely advise organisations to define their operating model before implementation. Many companies agree with the principle. Far fewer execute it properly.

In practice, this step is often skipped, under-resourced, or treated as a theoretical exercise. Teams are not freed up to engage deeply. Process discussions remain high-level. The operating model looks sound on paper, but it is not robust enough to survive real execution pressure.

At Coty, significant time and effort were invested in defining how planning would work end to end: decision rights, data flows, organisational responsibilities, and interfaces between functions. This was not about producing a perfect diagram. It was about stress-testing assumptions early, while there was still room to change course.

By doing this work up-front, the organisation confronted trade-offs upfront. Centralisation versus local autonomy. Automation versus judgement. Headcount implications if the system actually worked as intended. These are the issues that often surface late, once contracts are signed and options are limited. Addressing them early reduced the risk of discovering structural weaknesses after capital had already been committed.

Financial discipline reinforced this approach. The transformation had to withstand hard ROI scrutiny. There was little tolerance for initiatives justified solely by long-term promise or strategic narrative. Every dollar needed to earn its place.

That constraint sharpened decision-making. Capabilities that sounded attractive but could not demonstrate value were removed. Scope was deliberately narrowed. The transformation was shaped around outcomes that mattered financially, not around what made for the most impressive roadmap.

Crucially, ROI was not treated as a spreadsheet exercise. It directly informed operating model choices, automation targets, and sequencing decisions. Headcount reduction, licence consolidation, and process simplification were explicit design goals, not unintended consequences.

Only once this foundation was in place did vendor evaluation begin in earnest. Even then, familiar traps were avoided. Sales demonstrations were insufficient. Technical teams were asked to distinguish clearly between what was live, what required heavy configuration, and what existed only as future ambition. Reference calls were used to understand not just whether solutions worked, but where they struggled under real-world complexity.

Capabilities were assessed explicitly across People, Process, and Technology. Coty’s relatively strong internal capabilities and mature processes made it easier to identify where technology could genuinely unlock value, rather than simply compensate for deeper weaknesses.

Looking back, the success of the transformation had little to do with choosing the “best” technology. It rested on something more fundamental: confidence that the organisation understood what it was committing to.

By the time contracts were signed, few illusions remained. Trade-offs had been surfaced. Irreversible choices had been acknowledged. The remaining risk was execution, not misunderstanding.

For leaders approaching similar decisions, the lesson is not to copy any specific architecture or vendor stack. It is to recognise that building confidence happens long before committing capital. If that confidence is missing, no tool can compensate for it.