Data readiness is one of the most consistently underestimated constraints in supply chain transformation — and one of the hardest to assess honestly from inside the organisation.
The conversation about data readiness usually starts in the wrong place. Someone proposes a capability investment — a planning platform, an AI use case, a forecasting improvement — and data quality surfaces as a concern. The question then becomes whether the data is good enough to proceed. That framing almost always produces the wrong answer, because good enough depends entirely on what you are actually trying to do with it, and that question has usually not been answered precisely enough to test against.
The more useful question is not whether your data is good enough in the abstract. It is which specific decisions you are trying to improve, what data those decisions actually require, and what the gap is between what you have and what you need. That diagnostic is harder to do than it sounds, because the people best placed to assess data quality are often the ones most adapted to working around its limitations — which makes the gaps invisible until something external forces them into view.
The organisations that navigate data foundations decisions well tend to share a few characteristics. They resist the pressure to boil the ocean — to fix everything before attempting anything. They identify the specific use cases where data quality is the binding constraint and where it is not. And they treat data foundations investment as a sequenced set of decisions rather than a single programme to be designed, approved, and implemented all at once.
What follows draws on BPC's corpus of recorded practitioner conversations — what tends to go wrong when data foundations are approached as a prerequisite rather than a design problem, what sequencing tends to produce better outcomes, and what practitioners who have navigated comparable decisions say they would do differently.
The most consistent failure mode is attempting to boil the ocean — designing a single, global data model before there is clarity on which specific decisions it needs to support, who owns those decisions, and what level of data quality each decision actually requires. The result is a programme that delivers infrastructure long before it delivers decisions, and a gradual erosion of confidence in both the programme and the people running it.
A related pattern is the persistence of Excel. Despite extensive investment in ERP, analytics platforms, and partner portals, Excel remains the primary decision tool for many supply chain teams. This is not a cultural failure — it is a data model failure. Spreadsheets persist because they allow individuals to reconcile data from multiple systems in ways central platforms cannot yet support. When organisations attempt to eliminate Excel without first understanding what it is doing, the local logic it encoded simply reappears elsewhere.
The ownership question is also consistently underestimated. Most supply chain data involves inputs from commercial teams, finance, manufacturing, logistics, and IT — each with its own standards, incentives, and governance. When a cross-functional digital initiative is introduced, someone is made accountable for delivering the outcome without necessarily having authority over all the required inputs. That gap between accountability and control is where data programmes most often stall.
Starting with a clearly defined use case and working back to what data it actually requires tends to produce better outcomes than starting with a data quality assessment and working forward to what might eventually be possible. The use case provides the test: is the data usable at the point of decision, not simply present somewhere in the system landscape?
Limiting initial scope deliberately also tends to help. One consistent pattern from practitioners who have made progress is defining a manageable subset of flows, aligning ownership and governance within that boundary, and demonstrating value before expanding. That approach reduces the risk of over-engineering and allows governance and definitions to stabilise through use rather than through design.
The inventory reduction argument is worth noting for data governance specifically. Clean master data — removing duplicates, resolving item aliases, standardising definitions — tends to reduce inventory holding measurably. That is a working capital argument, which lands differently with finance than a time-saving or error-reduction argument. For organisations struggling to get data foundations work funded on operational efficiency grounds, the balance sheet framing is often the more viable route.
Examines the strategic context that should sit upstream of any capability investment, including operating model design, partner ecosystem constraints, and the shift toward AI-enabled best-of-breed components.