Same Item, Six Names: The Master Data Problem Behind Every Bad Report

There is a moment in most F&B digitalisation projects that nobody puts on the plan. Somebody exports the item list to check it, and finds that chicken breast exists four times — once as CHK BREAST, once as Chicken Breast (Fresh), once as CB-FRZ-2KG, and once as a line somebody created during a stock count in 2023 and never used again. Three of them have stock on hand. Two of them are still being ordered.

The reaction is usually embarrassment, which is the wrong reaction. Every operation that has grown quickly has this, because every operation that has grown quickly let the item list grow the same way it let everything else grow — by whoever needed something, adding it, at the moment they needed it.

The problem is not untidiness. It is that the item master, the supplier master, and the recipe library are the vocabulary the entire business uses to describe itself. When the vocabulary is inconsistent, every sentence built from it is unreliable — including the ones on which capital decisions are made.

How the damage actually shows up

Bad master data rarely announces itself. It presents as a series of unrelated-looking operational complaints.

Two departments produce different numbers and both are right. Procurement reports spend against one set of item codes; the kitchen reports usage against another. Neither is lying. They are counting different objects that happen to share a name, and the reconciliation meeting that follows is an argument nobody can win because the disagreement is structural.

Stock is simultaneously short and overstocked. Split an item across duplicate codes and its true position is split too. One code shows zero and triggers an order; another holds three weeks of cover in the same chiller. This is the mechanism behind a specific and common pattern: rising purchase volume alongside rising waste.

Purchasing leverage evaporates. A supplier appears three times under three spellings, so the group’s total spend with that vendor is never seen in one place. Negotiations then happen against a fraction of the real number, which is a weak position entered voluntarily.

Recipe costs drift out of reality. A recipe points at an item code that is no longer the one being purchased. The recipe still costs out cleanly. It is simply costing a version of the ingredient the business stopped buying eight months ago, and every margin figure downstream inherits that error silently.

Traceability breaks at the worst possible time. If the same physical ingredient is represented by several codes, a recall query answers for one of them. The scope comes back narrower than the truth — and a narrow answer to a recall question is more dangerous than no answer, because it will be acted on.

Analytics amplify rather than reveal. Dashboards, forecasts, and anomaly detection are all functions of the underlying records. Point them at a fragmented item master and they will produce confident, well-presented, wrong output. This is the failure mode people mean when they say their reporting project “didn’t tell them anything they didn’t already know.”

Why it degrades continuously

Master data is not a state you reach. It is a rate — how fast records are created against how fast they are governed.

New outlets create new local habits. A new supplier arrives mid-week and someone adds them to get the delivery received. A promotion needs a bundle SKU by Friday. A staff member leaves and their successor cannot find the existing code, so they make one. Each of these decisions is individually correct — the alternative was to stop work — and collectively they are the entire problem.

This is why one-off cleanups do not hold. A group that spends six weeks deduplicating its item list and changes nothing about who can create records will be back where it started within a year, having paid for the cleanup twice.

It is also why master data is the most common cause of implementation overrun. Teams budget for configuration and training; the schedule is then consumed by discovering that the data being migrated does not describe the operation accurately enough to migrate.

What governed master data looks like in practice

The goal is not a perfect list. It is a list that stays good without heroics.

One definition, held centrally. In RMS, items, suppliers, recipes, sub-recipes, yields, and BOMs are governed from one place and pushed to every outlet and central kitchen. Outlets consume the definition rather than each maintaining their own version of it, which removes the mechanism by which local variants appear.

Creation is a request, not a keystroke. New items and suppliers route through an approval step rather than being typed into a live master by whoever is under pressure. The cost is a short delay on genuinely new records. The saving is the entire class of duplicates created by people who could not find what already existed.

Structure the codes so that searching works. Most duplicates are created by people who looked and did not find. Consistent naming, categories, and units of measure are not bureaucracy — they are what makes the existing record discoverable at the moment somebody is deciding whether to create a new one.

Retire deliberately. Items go out of use constantly and almost never get deactivated, which is why lists only grow. An item with no movement in twelve months should require a reason to stay active, not a reason to be removed.

Let the data police itself. Once the operation runs on live records, the AI-Kitchen Command Center watches for the signatures of decay — two codes with near-identical usage patterns, a supplier receiving orders under multiple identities, an item whose recipe cost has diverged from its purchase price, a code that has not moved in a year but still holds stock. These are anomalies like any other, and catching them continuously is the difference between governance and an annual cleanup.

Teach the rule, not just the screen. People create duplicates because nobody explained the convention, not because they enjoy it. MindFlow Online Academy carries the naming standards and creation rules as part of role training, so the person hired in month nine works to the same convention as the launch team — which is the only reason the standard survives turnover.

A cheap diagnostic

Before committing to anything, three exports will tell you where you stand.

• Sort the item master by description and read it. Duplicates are usually visible to a human in twenty minutes. Count them, and count how many have stock or recent purchase activity.
• Sort the supplier master the same way, then total spend by name. Any vendor appearing more than once is understating your leverage by exactly the amount you cannot see.
• Count active items with no movement in twelve months. In most groups this is a substantial share of the list, and every one of them is a candidate for accidental reuse.

If those three checks come back clean, the reporting problems are somewhere else and worth chasing there. If they do not, no analytics layer, forecast, or dashboard will outperform the records beneath it.

The unglamorous prerequisite

Master data is the least interesting thing in any digitalisation programme, and it determines whether the interesting things work. Forecasting, food cost control, traceability, anomaly detection, and channel profitability are all functions that take the item master as an input. None of them can be more accurate than it is.

The operators who get clean numbers are not running better analytics than everyone else. They fixed the vocabulary first, then put rules in place so it stayed fixed — and every report they have produced since has been arguing about decisions rather than about whose spreadsheet is right.

---

Start with the data you already have. Book a demo and we’ll review your item and supplier masters against how RMS would model them — before anything is migrated, and before anything is signed.