Control Tower on Shaky Data
Meridian Distribution is deploying a supply chain control tower. Its data estate is fragmented: 14 ERP systems across five instances, 22% of supplier lead times maintained by hand in spreadsheets, and a 6% EDI error rate with its largest 3PL. Of 40,000 SKUs, roughly 3,100 are suspected duplicates. The vendor's predictive-ETA demo performed well on the vendor's own clean reference data. The CIO wants an enterprise cloud data lake stood up before any use case goes live. Three regional general managers resist standardizing order-to-cash because of local tax and e-invoicing rules. The two-year budget is US$9M. Last quarter 4,100 expedites were booked with no root cause recorded.
1. Should Meridian fund the enterprise data lake first, or launch the control tower use case on current data? Argue the sequencing.
Read the worked answer
Neither as framed. Scope a narrow data product to the highest-value use case, and run it in parallel with a bounded, not enterprise-wide, data program.
Reasoning:
- The control tower's predictive ETA cannot outperform inputs where 22% of lead times are hand-maintained and 6% of 3PL messages are wrong. The vendor demo proves the algorithm works on clean data; it says nothing about Meridian's. Value is bounded by input quality, so buying the tower first buys a faster wrong answer.
- Equally, a full enterprise data lake first is a multi-year foundation with no benefit in year one and a high probability of being overtaken by the use cases it was meant to serve. It also consumes the budget that would prove value.
- Quantify the leak first. 4,100 unexplained expedites per quarter is the business case. Trace a sample to root cause; if a material share traces to the EDI error rate and manual lead times, the fix has a defensible payback and the tower becomes the delivery mechanism rather than the goal.
- Scope: inbound visibility for the top 200 suppliers and the top 20% of SKUs, with lead-time ownership assigned and EDI errors instrumented. Expand only on measured accuracy.
Governance point: make data quality a line in the benefits register with an owner, not a workstream in an IT plan.
2. How should the team decide which order-to-cash practices must be standardized and which may remain local?
Read the worked answer
Separate three different things that the GMs are currently blending:
- Statutory requirement (tax, e-invoicing, local reporting). Non-negotiable in content, but not necessarily in process. Legally required variation is not a design choice and must be costed as a compliant extension, not a fork of the process.
- Historical practice dressed as requirement. Test it: ask for the regulation, not the policy.
- Genuine operating variance (customer mix, route structure, service commitments). This may earn a variation.
Apply a cost-of-non-standard test: for each requested variation, estimate the ongoing cost of the fork, including every future release, report, integration and audit that must handle it. Compare that against the quantified benefit of the local practice. Where the variance cost exceeds the benefit, the variance is denied and the number is shown to the GM.
The strategic argument: 14 ERP instances across five platforms already means every future change is paid for 14 times. Each new fork compounds that tax. Allow variation only for statutory need or where the cost test is genuinely passed, and record every exception in a register with an owner and an expiry date so exceptions cannot become permanent by default.
3. What commercial and architectural safeguards should be negotiated with the control tower vendor before signature?
Read the worked answer
The tower is a decision-support layer, so the risk is that Meridian outsources judgement along with software.
Buy: the visibility platform, standard connectors, alerting, scenario simulation capability and the maintenance behind it. Keep in-house: exception rules, prioritization logic, escalation thresholds and root-cause analytics. These encode Meridian's operating choices and are the part competitors cannot buy.
Safeguards to negotiate:
- No black-box ETA. Contractual right to the feature logic and accuracy reporting, with measured accuracy against Meridian's own data during a proof-of-value period before full commitment.
- Data portability and exit. Defined export formats for all derived data and models at any time, plus a transition-assistance clause. Otherwise the tower becomes a new lock-in layered on the old ERPs.
- Accuracy service levels with remedies, measured on Meridian data, not reference data.
- Pricing decoupled from volume growth, since the connector count grows as the estate consolidates.
- Proof-of-value gate: pay for a scoped pilot on the top supplier and SKU subset; the full license releases only if stated accuracy and adoption thresholds are met.
Architecturally, insist the tower reads from a governed data layer rather than writing back into 14 ERPs.