Before any organisation rushes into AI-driven transformation, one principle deserves absolute clarity: technology does not fix the fundamentals you haven’t fixed yourself. No matter how advanced the platform, no matter how powerful the algorithms, a transformation built on weak, inconsistent or poorly structured data will collapse under its own weight.
This is the step many skip — and the one that determines whether a transformation delivers strategic value or becomes an expensive cycle of rework and firefighting. When organisations overlook this foundation, the consequences surface almost immediately.
Rolling Out a Platform on Shifting Sand
Every transformation begins with the same promise: new technology will finally bring order to the chaos of outdated spreadsheets and old-fashioned systems. Yet many companies quickly find themselves overwhelmed, chasing hundreds of disconnected data issues at once and losing sight of the real goal — better business decisions.
Rolling out an advanced platform without fixing the underlying data is like building on shifting sand. The very first plan output often exposes the cracks that spreadsheets and legacy systems have been hiding for years.
Imagine a company in the FMCG segment that has invested millions in a cutting-edge planning platform. Expectations are high: smarter decisions, leaner inventories, faster scenario runs — but the very first plan output swings wildly out of range. The same customer appears under a dozen different names; shipment histories don’t match invoices; some SKUs are tracked in pounds in one market and kilograms in another. The replenishment engine proposes transfers that warehouses cannot even execute.
Such situations are common. Transformations fail not because the technology is flawed but because the data beneath it is fragmented, inconsistent and incomplete. Many companies still depend on spreadsheets or custom ERP fixes created years ago to fill local gaps in their planning software. These legacy workarounds often trap data in formats that newer systems cannot interpret. The result is predictable: when you feed a system garbage data, you inevitably get garbage output.
The Real Cost of Poor Data Readiness
The work of consolidating, cleansing and standardising data is almost always underestimated. In real transformation programmes, this phase can take from several months to a full year and consume thousands of person-hours before teams even sit down to discuss solution design. If a company truly wants to fast-track implementation, a complete and accurate dataset must be uploaded into the new system at the end of the mobilisation phase — well before design begins.
If your design discussions are grounded in complete information, you will avoid untested assumptions and ensure the solution reflects real business needs and processes. Full data readiness is equally crucial for meaningful testing and validation, allowing new configurations to be checked against real scenarios rather than synthetic samples. Skip or compress this stage, and delays are guaranteed, along with budget overruns and disappointing returns on investment.
Full data readiness brings several critical advantages. It allows teams to design to reality rather than assumptions, exposes quality and availability gaps early enough to resolve them, and reduces the likelihood of rework or functional defects later in the programme. It also aligns stakeholders around a single, accurate view of the business, strengthening cross-functional buy-in. Ultimately, a stable dataset means fewer surprises, more efficient use of resources, and more reliable delivery.
Real-World Data Pitfalls
In real implementations, data issues rarely appear as a single, isolated problem — they emerge as a web of inconsistencies that quietly accumulate over years. Product records may fail to load because obsolete SKUs were never retired, or because classification tags no longer match the current assortment structure. Customer and account data often contain duplicates or incomplete hierarchies, making it difficult for planning engines to align demand, shipments and revenue across teams.
Historical mismatches add another layer of distortion. As an example, when products or customers move into new categories, past sales history no longer aligns with current reporting groups, creating misleading baselines. Transactional irregularities compound the noise — deliveries without postings, postings without deliveries, and shipments that do not reconcile with invoices because different departments interpret data differently. Even cancellations and returns can introduce hidden failures: a billing document cancelled in the ERP may remain “active” in a planning tool simply because the cancellation flag was not recognised.
Gaps in market and master data further complicate the picture. New products or customer records may never reach the planning system if even one mandatory field is missing. And when duplicate or conflicting entries enter the pipeline — for example, the exact product–customer pair arriving with different price points or units of measure — optimisation engines cannot determine which version reflects reality.
Calendar mismatches can create a final layer of structural misalignment. Finance may plan on a fiscal calendar, operations on a production calendar, and reporting teams on an annual calendar, leaving the system to reconcile fundamentally incompatible time structures.
Taken together, these inconsistencies can halt a new platform long before any advanced optimisation or AI-driven capability is even activated.
Why Migration Takes So Long
All of these inconsistencies eventually surface during migration — and this is where another pitfall becomes clear: organisations consistently underestimate the effort required to align master data before go-live. In multi-country rollouts, what initially appears to be a simple task — harmonising product and customer hierarchies for demand planning — can stall the programme for months. The reasons are often straightforward: each region has defined its categories differently, and bills of material for manufacturing may be structured in ways that are incompatible across markets.
In such cases, the challenge extends far beyond software limitations. It requires painstaking reconciliation of inconsistent hierarchies, elimination of duplicates, and alignment of all markets on a single global structure. Until that harmonisation is complete, the planning system cannot run correctly, leaving the implementation team waiting.
Experience shows that large organisations benefit from starting data assessments and harmonisation 6 to 12 months before expanding into new countries or categories. This lead time ensures that markets can prepare clean, complete and consistent inputs — and prevents late-stage surprises that disrupt the transformation timeline
Five Practical Lessons for Leaders
Framing your data audit around the business outcomes you want to enable is the most effective place to start. Defining which decisions depend on reliable data helps narrow priorities and prevent scattered clean-up efforts. Once those priorities are established, map every data source, assign ownership and document any gaps or contradictions. Creating this verified baseline early prevents late-stage surprises that derail implementations.
Establishing a master data governance team is equally critical. This team must have the authority to enforce consistent codes, units-of-measure rules and hierarchies across the organisation. Around 70 per cent of success in data work comes from strong master data management, which means this capability cannot be treated as optional.
Sequencing the transformation wisely also matters. Stabilise the foundational transactional layer — orders, shipments and inventory positions — before activating optimisation or AI-driven features. Attempting to optimise on top of unstable data wastes time and undermines trust in the system.
Investing in capability-building and clear ownership makes a significant difference. Planners and local teams need to understand why new rules and definitions matter. Training sessions, reference playbooks and ongoing change-management support reduce the urge to override automated decisions. Each part of the solution should have an accountable owner — including the data itself. Users often fix what they see on the screen but are not equipped to diagnose the underlying issues.
Finally, track data readiness as a performance metric. Define measurable KPIs for data completeness and quality, and report on them with the same discipline as service level or cost. Making the invisible groundwork of data preparation visible keeps leadership focused on maintaining it.
