Ask a manufacturer where its analytics work should start and the answer arrives shaped like the organisation. Marketing has spend it cannot attribute. Sales has a forecast nobody trusts. Operations has stock in the wrong place at the wrong time. Each is a real problem, each has one owner, and each can be scoped without asking anybody else's permission. That last property is why first programmes get scoped that way. Not because the value sits there. Because the boundary does.
A proposal I co-authored for a European food and consumer goods manufacturer opened with a sentence that ran the other way, and I have thought about it more than about anything else in the document. It said the opportunity ran across the full supply chain: from improving the returns in marketing, to improving the predictability of the supply chain, to the quality of the products delivered from the farmers and the services provided back to them.
Four value areas, one sentence, written off the back of the first discussions with the business. And they are not four projects.
The sentence does not fit the org chart
Read the four areas as physical positions rather than as departments and the shape becomes obvious.
Services to the farms are delivered before the raw material exists. Quality of what arrives from them is measured at intake, on material somebody else produced under conditions we influence but do not control. Supply-chain predictability is measured in the middle, across plants and channels, and is the only one of the four that is about a whole rather than a point. Marketing return is measured at the shelf end, long after the material that carried it left the farm.
One object, four measurement points, four owners. Nothing in that is anybody's mistake. It is what happens when a company grows along its functions, which is the only way companies grow. The trouble starts when you put an analytics number on it, because a number needs a boundary and this thing has none where the reporting lines are drawn.
The catalogue in the proposal is the honest evidence of that. Fourteen named candidate cases, sorted into four functional buckets, three of them written up in detail. Sorting them that way was right for a reader taking the document into a management meeting. But look at what the sorting does. A case about predicting demand sits in the Sales bucket, its benefit is inventory, an Operations number, and it comes from better visibility of information along the supply chain, which is nobody's number in particular. The bucket is a fact about who attends the kick-off, not about where the value lands.
Why an improvement books as a cost next door
The clearest thing in the reference case is a pair of numbers most people skim past: 30 percent lead-time reduction and 25 percent inventory optimisation, from one engagement, across the global supply chain, alongside $150M of cash freed.
Take them apart and they are not obviously friends. Inventory is what an organisation holds so that variability upstream does not become a stock-out downstream. Reduce it alone and you have moved a cost into somebody else's service level. Reduce lead time alone and you have usually paid for it with expedited freight, smaller runs and more changeovers, all landing as unit cost in a plant that was not in the room. Either is easy to deliver as a departmental win, and either, delivered alone, is a transfer rather than an improvement.
They arrive together only when the programme spans the chain, which is how the reference describes itself: one flow of information running the length of the global supply chain, where demand, supply-chain performance and operating processes could be read from several perspectives at once. That reading of the pair is mine rather than the document's, and I think it is the useful one. Two numbers that trade against each other locally, both moving the right way at once, is not a stronger result than one number. It is a different kind of result, the signature of a measurement surface wider than any of the departments being measured.
Fourteen opportunities, four buckets, one line
- 4
- Value areas named in a single opening sentence, farm through shelf
- 14
- Candidate cases in the portfolio, sorted into four functional buckets
- 3
- Cases written up in detail for the choosing conversation
- 1-3
- Areas the proposal recommended starting with
There is a second reason the boundaries will not hold, and it is technical rather than political.
The channel-effectiveness case in the same document proposed something I still like: read the system log files across every channel, and use what they record to compare how much work each channel and each sales team was absorbing and what came back. Log files are exhaust. Nobody has to be persuaded to produce them, nobody negotiates their definition in a meeting, and they cover periods before anyone thought to look. The same document also describes stitching data from different operating areas and channels into a single customer view.
Both are boundary-crossing by construction. A log file records an event, not a department, and stitching the operating areas together is the whole exercise. So even the cases framed inside one bucket needed data from at least two, which is the ordinary condition of this work and the ordinary place it stalls. Not at the model. At the join: two systems, two owners, two definitions of the same object, and no shared key that either owner is accountable for.
That is why the readiness call in the proposal was worth making out loud. It quoted six to eight weeks for a first case against its own footnote, which reserves four to six for established data analytics environments and makes the rest depend on what data is actually available. That judgement was made before a single model was scoped, and what it hedged against was the state of the joins and the definitions rather than the difficulty of any algorithm.
What "start small" has to mean here
I still believe in starting small. Everything I have watched fail at this scale failed by starting large: a platform first, a warehouse first, a long programme whose first visible output is a governance document. Pick one to three areas, deliver one case with a concrete result, and let the roadmap follow the evidence. That was the advice then and it is the advice now.
What I would add is a rule about where the numbers live.
Choose the case by the department that will run it and you get a result that department can defend and the next one can dispute. Choose it by the measurement and you have to answer a harder question at the start: which readings along the line does this case move, and where does the counter-cost fall. If lead time is the target, inventory is the counter-reading. If marketing return is the target, the service level that promotion demands of the plant is the counter-reading. If intake quality is the target, the cost of the services delivered back out to the farms is the counter-reading. Neither number in a pair may be reported without the other. That one constraint does more for a first analytics case than any amount of model selection.
This is why the RealAI Platform work begins with the measurement layer rather than the pipeline, and why our Consult team asks for the counter-reading before it asks for the use case. Pipelines are assembly work now, deployment is close to solved in most stacks, and lineage tooling is cheap enough that knowing which system a value came from is a decision rather than a project. What has not become cheap is agreeing what a number means across two functions that have never had to agree before.
The value ran along the material. The measurement ran along the org chart. Every argument that followed about which case to start with was really an argument about which of those two the numbers would be kept on.
What we would fix, and in what order
None of this needs a data scientist, which is the uncomfortable part, because all of it has to land before one is worth hiring.
Draw the physical path of the product and mark every point where somebody takes a reading today, including the ones taken in a spreadsheet by one person. Name one owner for the line rather than for the four segments, and give that person the pair rule: no target reading published without its counter-reading beside it. Set one definition per counted thing, with the query that produces it stored next to the definition, so a figure and its meaning travel together across a function boundary. Find the shared key that joins a batch at intake to a case leaving a plant and to a line on an invoice, and if no such key exists, that is the first case rather than a prerequisite for one. Then pick your small thing.
Answer those and you have built nothing. You have a line you can measure, which is what an improvement has to be booked against if it is to be an improvement rather than a transfer.
Drawn from a data analytics proposal I co-authored for a European food and consumer goods manufacturer: its opening value statement, its opportunity catalogue, its example cases and its effort judgement. That document carried findings and recommendations ahead of a decision to start, not delivered outcomes at this manufacturer. Its percentage and cash figures are references to earlier engagements by the authoring practice, reported here as claims the document made rather than as results of ours. Reading the four value areas as one measurement surface is our own.
“The value ran along the material. The measurement ran along the org chart. Every argument that followed about which case to start with was really an argument about which of those two the numbers would be kept on.”
Get in touch
Put RealAI’s applied-AI team on your hardest data problem.
We help enterprises move from pilots to production: sovereign models, governed data, and agents you can audit. Start with a value-first assessment.