Provenance Pilot Scope at a Grocery Retailer
A grocery retailer with 1,800 stores and 2.4 million active SKUs wants to prove provenance for fresh produce, seafood, and packaged goods. Its 9 suppliers use three different ERP systems; only 3 can emit GS1 EPCIS events today. A consultant proposes putting every SKU's receive, move, and sale event on a permissioned blockchain: about 50 million events per month at an estimated $0.03 per event, plus 18 months of supplier onboarding. The retailer's actual pain is recall scope: 4 recalls in 18 months each took 6–11 days to identify affected lots, costing $250k–$900k. The CFO wants a go/no-go decision in 30 days and a pilot that shows value within two quarters. Store-level point-of-sale data is already centralized and reliable; lot data is not.
1. Should the retailer approve the consultant's all-SKU blockchain plan? Justify the scope decision.
Read the worked answer
Conditional no to the all-SKU plan; yes to a narrow lot-level pilot. Blockchain is justified only where multiple parties need a shared, tamper-evident record and no single party can be trusted to hold it. The retailer already has reliable POS data; putting every sale event on-chain adds 50 million events/month × $0.03 = $1.5 million/month ($18 million/year), likely exceeding the recall cost it addresses ($250k–$900k per recall, 4 in 18 months). Item-level events also create privacy and data-volume issues.
The real problem is lot traceability across suppliers. Use a permissioned ledger for critical tracking events: commission/pack, ship, receive, transform, and recall. Keep POS and store inventory in existing systems. If the retailer can contractually mandate a central database and suppliers comply, a centralized system may be cheaper; blockchain's advantage is multi-party trust and evidence.
2. Define a two-quarter pilot and the business-process changes needed to make it credible.
Read the worked answer
Pilot 3 willing suppliers and 2 high-risk categories (for example, leafy greens and seafood), not 9 suppliers and 2.4 million SKUs. Re-engineer the process:
- Define a GS1 EPCIS profile with minimum lot fields and critical events; allow CSV/portal upload for suppliers without EPCIS.
- Capture at packing/commissioning and DC receipt; do not capture every store move.
- Assign lot IDs at source, not at the retailer DC; otherwise recall scope is still broad.
- Build exception handling for missing/late events and a recall query that returns lot-to-store in minutes.
- Integrate with the retailer's recall workflow, not a parallel dashboard.
Run a 90-day pilot with a go/no-go review. The pilot should prove the process, not just the ledger.
3. What KPIs and kill criteria should the CFO use to decide whether to expand?
Read the worked answer
KPIs: median time to identify affected lots (baseline 6–11 days; target under 24 hours), percentage of lots with complete critical events at DC receipt (target >95%), supplier onboarding time (<30 days per supplier), cost per lot traced, and false-positive recall scope (stores/lots withdrawn). Business KPIs: avoided revenue loss and recall labor.
Kill criteria: after 90 days, if fewer than 80% of pilot lots have complete events, or median trace time is not reduced by at least 50%, stop and fix process/data ownership before expanding. Also stop if per-lot cost exceeds expected recall savings by 2x. This prevents scaling a pilot that only demonstrates technology.