Chapter 4 of 4

Digital Supply Chain Stack and Data Quality

3 sections · ~9 min read · 3 practice questions · part of SC Analytics & Technology

Learning objectives

  • Identify the four layers of a typical supply chain technology stack: data, planning, execution, and visibility.
  • Quantify the inventory cost of poor data quality on a planning decision, and state the assumptions the estimate rests on.
  • Explain the tradeoffs between monolithic ERP, best-of-breed, and hybrid architectures.

The Stack: Data, Planning, Execution, Visibility

A typical supply chain technology stack has four layers. The data layer is the system of record: master data (items, suppliers, customers, locations), transactional data (orders, shipments, inventory movements), and event data (signals from equipment, vehicles, partners). The planning layer is where forecasts, inventory policies, and network designs are computed and refreshed; typical tools include demand planning, sales and operations planning, inventory optimization, and network modelling software. The execution layer is where decisions become orders and shipments: warehouse management, transportation management, supplier collaboration, and order management. The visibility layer is the analytics and exception-management surface: dashboards, alerts, root-cause analysis. Many implementations fail because one layer is weak while the others are strong. Excellent planning fed by bad data produces confident, precise, wrong answers. Excellent execution without visibility creates a black box that nobody can diagnose when it misbehaves. Rich visibility without actionable planning produces dashboards that everyone watches and no one can act on. The layers also fail in a characteristic order: data problems surface as planning problems, which surface as execution problems, which are where they finally become visible and expensive. That is why the first instinct when service degrades, to buy a better planning tool, so often fails to help. The stack is not a substitute for a strategy. It is the apparatus that lets a strategy be executed consistently, at scale, with feedback.

Data Quality and Its Cost

Data quality is the most underrated variable in supply chain analytics, and its costs are structural rather than occasional. Errors propagate: a wrong unit of measure on receipt becomes a wrong reorder quantity downstream; a wrong lead time on a vendor master becomes a wrong safety stock on every item that vendor supplies; a duplicate item master splits demand history in two and destroys the forecast for both halves. The cost is quantifiable if the chain of reasoning is stated carefully, and stating it carefully matters, because this is an area where impressive-looking numbers are easy to manufacture. Two errors are common. The first is applying a percentage increase in safety stock to the entire inventory base, when safety stock is only one component of inventory alongside cycle stock and pipeline stock, so the resulting figure can overstate the effect several times over. The second is scaling a result measured on a sample of well-behaved items across a whole catalogue that includes seasonal, promotional, and intermittent demand, where the relationship does not hold. The discipline is to treat master data as a product with an owner, governance, and service levels, and to reconcile to a single source of truth for each domain. The cheapest way to improve analytics is almost always to fix the data rather than to buy a better model, since a better model fitted to worse data is a faster route to the wrong answer.

Monolithic, Best-of-Breed, and Hybrid Architectures

Three architecture patterns dominate. Monolithic, meaning a single ERP vendor for everything, maximises integration and minimises reconciliation, but ties the company to one vendor's release pace and typically underperforms specialists in any individual function. Best-of-breed, meaning specialised tools per layer joined by integration middleware, maximises fit to purpose and allows each component to be replaced independently, but pushes cost and risk into the seams between systems, which is where data quality problems are born. Hybrid, meaning a single platform for the transactional core with specialised tools for genuinely differentiating capabilities, is the common landing point in mature organisations. The right choice follows from where the company actually competes. Where supply chain capability is the differentiator, the case for specialised tools in the differentiating functions is strong. Where supply chain is a well-run cost centre, integration simplicity usually wins. Two things are worth being honest about in the decision. Integration effort in a best-of-breed estate is routinely underestimated, because it is a recurring cost that reappears at every upgrade rather than a one-time project cost. And every architecture carries a hidden tax: integration burden for best-of-breed, vendor dependency for monolithic, and boundary disputes for hybrid. Choose the tax you would rather pay, and say out loud which one you have chosen.

Worked example

Problem

A consumer goods company holds $48M of average inventory across 6,400 active SKUs. Of that, roughly $12M is safety stock and the remainder is cycle and pipeline stock. After a master-data cleanup, forecast MAPE on a representative 200-SKU sample falls from 18% to 13%. Representative items have mean weekly demand of 200 units, a one-week lead time, and a unit cost of $18. Policy is a 95% cycle service level (z = 1.65) and the holding rate is 22% per year. Estimate the inventory reduction and annual holding-cost saving, and state clearly which assumptions carry the result.

Step by step

  1. Convert MAPE to MAD at the representative demand level: 18% of 200 units = 36 units; 13% of 200 units = 26 units. Improvement = 10 units of MAD per SKU per week.
  2. Convert MAD to sigma, which the safety-stock formula requires: sigma improvement = 1.25 x 10 = 12.5 units.
  3. Scale to the lead time: with L = 1 week, sqrt(L) = 1, so sigma over the lead time also improves by 12.5 units. Note this term is what makes the estimate sensitive to lead time; at a four-week lead time the same MAPE gain would be worth twice as much.
  4. Safety-stock reduction per SKU = z x sigma improvement = 1.65 x 12.5 = 20.6 units.
  5. Value per SKU = 20.6 x $18 = $371.25.
  6. Scale to the catalogue: $371.25 x 6,400 = $2,376,000 of inventory reduction.
  7. Sense-check against the safety-stock base rather than total inventory: $2.38M against roughly $12M of safety stock is a 20 percent reduction in safety stock, which is consistent with a 28 percent reduction in forecast error, since safety stock scales linearly with sigma. Against the full $48M inventory base it is 5.0 percent, and quoting it that way would invite the false inference that all inventory responds to forecast quality. Cycle stock is driven by lot sizing and pipeline stock by lead time; neither moves when the forecast improves.
  8. Annual holding-cost saving = 22% x $2,376,000 = $522,720, alongside a one-time working-capital release of $2,376,000.

Answer. Estimated inventory reduction ≈ $2.38M, a one-time working-capital release, with an ongoing holding-cost saving of ≈ $0.52M per year. The result rests on three assumptions that should be stated whenever the number is quoted. First, that the 200-SKU sample is representative of all 6,400 SKUs, which is the weakest link: seasonal, promotional, and intermittent items will not scale linearly and may not improve at all. Second, that forecast errors are approximately normal, which is what licenses both the 1.25 MAD-to-sigma conversion and the z-factor. Third, that only safety stock responds, which is why the reduction is quoted against the $12M safety-stock base rather than the $48M total, where it would look like a 5 percent improvement in something it cannot touch. Treat this as a directional business case and validate it by holding policy fixed on a control group of SKUs while applying the cleaned data to a test group, then measuring realised inventory after two or three replenishment cycles.

Practice

Work each question before opening the solution.

  1. A business case claims that a 10 percent increase in safety stock from poor data adds 10 percent to a $50M inventory base, or $5M. What is wrong with the arithmetic, and what would the right figure look like?

    Show solution for question 1

    It applies a percentage change in one component to the whole. Safety stock is typically a minority of total inventory, sitting alongside cycle stock driven by lot sizing and pipeline stock driven by lead time, and neither of those responds to forecast error. If safety stock were $12M of the $50M, a 10 percent increase is $1.2M, not $5M, so the claim overstates the effect roughly fourfold. The right figure requires decomposing inventory into its three components first, then applying the change only to the component the mechanism actually touches. Any business case that skips that decomposition should be assumed to be inflated.

  2. Master data has an owner, a governance process, and a published quality dashboard, yet vendor lead times remain wrong. What is the likely mechanism, and what would fix it?

    Show solution for question 2

    The likely mechanism is that lead time has no natural feedback loop. Fields such as item description or price are wrong in ways someone notices immediately, whereas a wrong lead time simply produces a slightly wrong safety stock, which nobody traces back to its cause. The governance process is checking that the field is populated, not that it is true. The fix is to measure rather than to declare: compute realised lead time from receipt dates against order dates, compare it with the master value on a regular cycle, and flag the gaps. That converts an unverifiable attribute into a measured one, and the variance of realised lead time is itself an input the safety-stock calculation needs and probably does not currently have.

  3. A company running a monolithic ERP wants a specialised inventory optimization tool for its highest-value category. What has to be true for that to be a good decision rather than the start of an unmanaged best-of-breed estate?

    Show solution for question 3

    Three things. The category has to be large enough that better policy on it alone repays the tool, the integration, and the recurring cost of maintaining that integration through both vendors' upgrade cycles. The interface has to be narrow and well defined, ideally the tool consuming demand history and returning policy parameters the ERP executes, so that the ERP remains the single system of record and the new tool never becomes a second source of truth for inventory. And the decision has to be recorded as a deliberate exception with a stated rationale, so that the next team cannot cite it as precedent for adding a fourth and fifth tool. Unmanaged best-of-breed estates are rarely chosen; they accumulate one defensible exception at a time.