Redesigning the Digital Thread When Process and Data Disagree
A manufacturer is adopting a digital supply chain standard to integrate planning, procurement, and logistics. During design, three conflicts surface: (1) procurement's ERP records supplier lead time as a single fixed number, while planning needs a distribution of lead times; (2) logistics tracks shipments by pallet, while planning forecasts by case; (3) each function maintains its own item master, and the three disagree on 18% of items. A vendor proposes a middleware layer that 'reconciles everything at the reporting layer' so no source system changes. The program sponsor likes this because it avoids touching ERP. A pilot showed the middleware produced correct dashboards but planners still could not trust the numbers for decisions.
1. Explain why the reporting-layer reconciliation failed and what the digital standard requires instead.
Read the worked answer
The pilot failed because the middleware reconciled outputs, not semantics. Dashboards looked right, but the underlying definitions, granularity, and data models still conflicted, so any decision that depended on the reconciled number could not be traced or trusted.
The three conflicts are model-level, not presentation-level:
- Lead time as a point value vs. a distribution is a data model difference; a reporting layer cannot invent variability that the source never captured.
- Pallet vs. case is a unit-of-measure and granularity mismatch; conversion at the reporting layer hides rounding and allocation errors.
- Three item masters with 18% disagreement is a master-data governance failure; reconciling at the top leaves the operational systems acting on different truths.
A digital standard addresses this by defining shared data entities, semantics, and granularity at the source/integration layer, with governance over master data - not by papering over divergence in a dashboard.
2. The sponsor wants to avoid touching ERP. Recommend a pragmatic path that still delivers trustworthy decisions.
Read the worked answer
Avoiding ERP change entirely is not viable, but a staged, scoped approach is:
- Fix master data first - establish one governed item master (or a clear system of record with cross-references) and resolve the 18% disagreement. This is the highest-leverage, lowest-risk step and unblocks the rest.
- Align semantics for the two decision-critical attributes - capture supplier lead time as a distribution (min/most-likely/max or history) and adopt a common unit-of-measure with documented conversions between pallet and case. These require source-level changes, but can be scoped narrowly to the fields planning actually uses.
- Use the middleware only for integration and translation, not as the place where truth is manufactured - it should carry governed definitions, not reconcile conflicts.
- Prove trust with a pilot on a bounded category, validating that planners will act on the numbers before scaling.
Message to the sponsor: the middleware is fine as plumbing; the standard lives in data definitions and governance, which cannot be delegated to a reporting layer.