Because these problems are connected by dependency rather than coincidence.
A margin control validates an invoiced price against an agreed price. The agreed price is attached to a customer record and a product record. If either record is wrong, the control still runs, still reports, and still passes. It is checking accurately against the wrong reference.
On paper any of the three layers could be improved first. Each has a clear business case, a visible cost, and a team who would welcome the change.
In practice the sequence decides whether the effort pays back, because work done at the top of the stack inherits every fault beneath it.
What is the dependency stack in food and beverage operations?
Three layers, in this order from the bottom.
Master data sits at the base. Customer records, product records, hierarchies, categories, units of measure, and the agreed prices attached to them.
Order handling sits above it. Validation, pricing at the point of entry, exception handling, amendments and approvals. All of it references the layer below.
Margin control sits at the top. Agreed terms against invoiced position, rebates, credit notes, and the assembled view of what an account actually costs.
Each layer is only as reliable as the one underneath. That is the whole of the argument, and it is the part most improvement plans skip, because each layer has its own owner and its own business case and the three are rarely assessed together.
What happens when you fix margin control before the data underneath it?
A business tightens order validation so no line can be priced outside the agreed customer price. Sound discipline, properly implemented.
But three lines sit under the wrong category in the product file, so they validate against the wrong agreed price. The control does exactly what it was built to do. The exceptions report comes back clean every week.
Nobody goes looking for the problem, because the control was supposed to have found it.
The business now has more confidence than it had before, and no more accuracy. That is worse than having no control, because the previous state at least prompted people to check.
What happens when you fix order accuracy before pricing?
A second business goes after order accuracy first, because that is the part customers see.
Picking improves. Short deliveries fall. Service conversations get easier.
Twelve months on, margin has not moved, because the agreed prices those orders were placed against were never checked. Every order is now reliably correct at a number nobody validated.
The improvement worked. It did not touch the thing that was costing money.
Neither of these is a failure of effort. Both businesses committed budget, ran the project properly, and finished it.
What does a sequencing mistake cost beyond the project itself?
The direct cost is the least of it.
When real improvement produces no visible commercial change, the conclusion drawn is usually that the problem was harder than it looked. The next proposal is a little harder to get through. The one after that is harder still.
A business can spend two budget cycles this way, doing good work in the wrong sequence, and arrive at the view that its problems are structural.
They are usually just stacked.
That is the quiet damage. Not a failed project, which at least gets reviewed, but a successful one that produced nothing, which erodes the appetite for the next attempt.
How do you work out which layer to start with?
A short trace, using one account rather than a new report.
Pick a customer account that matters commercially. Take a single order line from it and work backwards. Identify the price it was charged at. Find the agreed price it should have validated against. Then find the record that agreed price is attached to, and check that record.
Run the same trace on a line where a credit note was raised in the last quarter, and see how far down the stack the original cause sits.
Then look at the last operational improvement the business signed off. Ask which layer it sat on, and whether the layer beneath it was right at the time.
If the layer beneath was not right, the return on that project was capped before it started.
Three questions worth answering before committing budget to the next one.
- Which layer does the proposed improvement sit on.
- Whether the layer beneath it has been verified recently, rather than assumed.
- What the control would report if the layer beneath were wrong, and whether anyone would notice.
The third is the most useful. A control that cannot fail visibly is not yet a control.
What does the right sequence look like in practice?
Not a two year data project before anything else happens. That is the usual objection, and it is a fair one.
The workable version is narrower. Verify the records that the intended improvement depends on, rather than all records. If the plan is to tighten margin control on the top forty accounts, the records that need to be right are the customer hierarchies, product categories and agreed prices attached to those accounts. That is a bounded piece of work that can run alongside the main project rather than delaying it by a year.
The principle is simply that each layer is verified before the layer above it is relied upon. Sequence, not scale.
How Allsop helps food and beverage businesses get the sequence right
At Allsop, we work with food and beverage businesses through intelligent software for Customer Order Management, Data Workbench and Customer Margin Management. The three map onto the three layers, which is deliberate.
Data Workbench improves the process that produces clean, accurate master data, so customer hierarchies, product records and agreed price records stay correct as they change rather than only at the point they are created.
Customer Order Management handles orders and amendments through a controlled route built on those records, so validation references something reliable.
Customer Margin Management brings agreed terms, invoiced position and later adjustments together, so account margin can be read as one figure rather than reconstructed after the quarter closes.
We do not decide what a customer should pay. We work on the process around that decision, so margin control validates against agreed prices rather than against whatever the record happens to say.
The order matters more than the pace.
If the business has improved something real in the last two years and seen less commercial movement than expected, it may be worth looking at what sat underneath it. Speak to us, or read more about how we approach master data accuracy
Frequently asked questions
Should we fix data, orders or margin first?
Data first, but only the data the intended improvement depends on. Master data sits underneath order handling, and order handling sits underneath margin control, so any improvement inherits the faults in the layer below it. That does not mean a full data programme before anything else can start. It means verifying the customer records, product records and agreed prices that the planned control will reference.
Why do operational improvement projects deliver less than expected?
Often because they were built on a layer that had not been verified. A margin control validating against an inaccurate agreed price will run correctly and report cleanly while checking the wrong reference. The project succeeds on its own terms and produces no commercial movement, which is usually attributed to the problem being harder than expected rather than to the sequence.
What is the dependency stack in food and beverage operations?
Three layers. Master data at the base, covering customer and product records, hierarchies and agreed prices. Order handling above it, covering validation, pricing at entry and exception handling. Margin control at the top, covering agreed terms against invoiced position and the full cost of an account. Each layer references the one beneath it.
Can you improve order accuracy without fixing master data first?
Yes, and it will improve service. Picking accuracy, short deliveries and query volumes all respond to better order handling. What it will not do is protect margin, because an order placed accurately against an unvalidated price is still charged at the wrong number. The improvement is real but it lands on service rather than on margin.
How do you tell which layer a problem actually sits on?
Trace one order line backwards. Identify the price charged, find the agreed price it should have validated against, then find the record that agreed price is attached to. Repeat on a line where a credit note was raised. The layer where the trace breaks down is where the problem originates, which is often not the layer where it was noticed.
How long does master data work take before other projects can start?
It depends on scope, and the scope is usually narrower than assumed. Verifying the records a specific control will reference, such as the hierarchies and agreed prices for a defined set of accounts, is a bounded task that can run alongside the main project. A full data programme across every record is a different undertaking and rarely a prerequisite.
