In early 2023, a SAP S/4HANA rollout at SPAR Group’s KwaZulu-Natal distribution centre triggered what court papers describe as an immediate breakdown in order picking, dispatch scheduling, inventory visibility, and pricing accuracy. Industry estimates put the resulting cost at roughly R1.6 billion in lost turnover and R720 million in lost profit by September 2023 alone, and one of the retailer’s largest franchisees filed a R168.7 million lawsuit over the fallout. The specifics vary by case, but the pattern does not: implementations rarely fail on software selection. They fail on records nobody owned.
Master data management in supply chain means keeping item, supplier, location, and bill of materials records accurate, complete, and consistent enough that forecasting, MRP, and replenishment produce plans a planner can actually act on. This guide maps the defects to the failures they cause, in the order they should be cleaned.
Master Data Management in Supply Chain Systems
Master data management in supply chain systems means governing the reference records that every transaction depends on, rather than the transactions themselves. It covers four domains that matter to planning: the item or material master, the supplier master, the location or plant master, and the bill of materials (BOM) with its routings.
Transactional data is what happens: an order placed, a receipt posted, a shipment dispatched. Master data is what those transactions reference to mean anything: which item, which supplier, which plant, and what that item is actually built from. A perfectly logged transaction against a wrong item code is still a wrong number.
The Defect-to-Failure Map
| Defect | Planning Output It Breaks | Symptom the Business Reports |
| Duplicate item codes | Splits demand history across two records | Unexplained forecast error on a fast mover |
| Duplicate supplier records | Splits performance and spend history | A supplier scorecard nobody trusts |
| Wrong or stale lead time | Breaks reorder point timing | Chronic expediting or excess cover |
| Wrong unit of measure | Breaks order quantity | An order a hundred times too large |
| Missing or wrong BOM component | Breaks MRP explosion | A shortage discovered on the line |
| Missing routing or capacity parameter | Breaks the production schedule | A plan the shop floor ignores |
| No phase-in or phase-out link | Breaks demand history continuity | A cold start on a mature product |
| Inactive records never retired | Inflates the planning run | An exception list nobody works |
Every one of these produces a confident, specific, wrong number. The forecast still generates a value, the MRP run still produces a planned order, the reorder point still fires on schedule, all of it looking as legitimate as correct output. Nobody questions a plausible number until the shortage or the oversized order actually arrives, which is why these defects survive so many review cycles unnoticed. A duplicated supplier record, for instance, is exactly what makes a supplier scorecard impossible to trust.
The Assumption Most Planning Software Gets Wrong
Systems built for tidy, single-instance data environments assume a hygiene level that most real supply chains do not have. Item codes accumulate across plants, mergers and acquisitions until the same part carries three or four different codes. Suppliers get onboarded on paper or over email long before anyone enters them into a system properly, so the supplier master reflects whoever typed fastest, not who actually ships the part. The same material ends up described three different ways in three different units, because three different people entered it at three different times.
The failure mode is not that the software is bad. It is that the software has no tolerance for the input it is actually given.
Planning tools do not fail on the shop floor because the underlying logic is wrong. They fail because they assume a clean item master walks in the door, and nobody in the organization promised one.
Data Quality Dimensions That Are Actually Testable
The data quality field defined these dimensions well before supply chain software existed; DAMA International’s Data Management Body of Knowledge is the standard reference they come from. Data quality, in a supply chain setting, only matters once it is testable, so each dimension below turns into a check a planner can run this week rather than a score IT reports quarterly.
| Dimension | What It Means for the Record | A Test to Run This Week | What Failing It Costs |
| Completeness | Every required field on the item or supplier record is populated, not blank or defaulted | Pull 50 active SKUs and check for blank lead time, UoM, or supplier fields | Planning parameters default to zero or a guess, silently |
| Accuracy | The value matches reality, not what was true at setup | Compare 20 planned lead times against the last 6 months of actual receipts | Reorder points fire too early or too late |
| Consistency | The same item, supplier, or location is described the same way everywhere | Search the item master for one material spelled two different ways | Demand and spend split across records that are really one |
| Timeliness | The record reflects the current state, not the state at creation | Check how long ago the supplier master’s lead time field was last updated | Plans run on a supplier relationship that no longer exists |
| Uniqueness | Each entity exists exactly once in the system | Run a duplicate check on supplier tax ID or item description | Forecast error gets blamed on demand volatility that is really a duplicate record |
Why Cleanup Projects Stall
Five reasons account for most stalled cleanup efforts.
- No owner for the record, only for the system. IT owns the database; nobody owns whether the supplier master is actually correct.
- Cleanup treated as a migration task that ends at cutover. Once go-live passes, nobody is assigned to keep the records right.
- The easy domain gets cleaned first. Meanwhile, the domain it depends on is left untouched, so the fix does not hold.
- No exception reporting. Decay restarts the moment the project team moves on to the next priority.
- No link between the cleanup and a planning outcome anyone is measured on. It competes for priority against everything else and loses.
A Cleanup Sequence That Survives Go-Live
Six steps, in order, because some records are inputs to others.
This sequence is Oritiq’s own methodology, built from how these record types reference each other rather than from a single published framework: a plant code has to be correct before anything tied to that plant can be trusted, an item master has to be correct before a BOM built from it means anything, and so on down the chain.
- Location and plant master first. Everything else references it, and an organization running several plants on one common ERP will find a wrong plant code corrupts every transaction and item record tied to that plant, across every site sharing the system.
- Item master and unit of measure next. Planning parameters, BOM, and routing all reference the item, and a UoM error compounds into every order quantity calculated from it downstream.
- Supplier master, once item records are stable. Supplier performance and lead time data need a clean item reference to mean anything at all.
- Bill of materials and routing. Both depend on a clean item master and a clean plant master to explode and schedule correctly.
- Planning parameters: lead time, lot size, safety stock. These sit on top of item, supplier, and BOM records and stay meaningless until those are correct, which is also where an inventory optimization effort actually starts paying off.
- Demand history repair, including phase-in and phase-out links, last. It depends on every domain above being stable enough to attribute history to the right item.
Cleaning the item master before the location master is how a cleanup gets done twice.
How to Keep It Clean After Cutover
Ownership assigned by record type, not by system: someone specific owns whether the supplier master is correct, separate from whoever administers the ERP. Creation rules enforced at entry, so a new item or supplier record cannot be saved with a blank lead time or unit of measure. A standing exception report with a named owner, reviewed on a fixed cadence. And a quarterly review tied to an actual planning metric, forecast error or fill rate, not a data quality score nobody outside IT looks at.
Decay is the norm. A cleanup with no maintenance loop has a shelf life of about a year, which is also why most stalled projects trace back to the reasons above; see why supply chain software implementations fail for the wider pattern.
Where Oritiq Fits
Oritiq handles unclean master data natively rather than requiring it to be fixed before onboarding, with a structured cleanup and organization process built into the platform and run as part of deployment, so the planning layer and the data work start together instead of in sequence. It also handles the linkage between phased-in and phased-out items, since that link sits at the boundary of master data and demand history and is exactly where the defect map above breaks down. Bring a sample of an organization’s item and supplier master and see what it flags before committing to a bigger cleanup project.
FAQs
What is master data management in supply chain?
Master data management in supply chain means keeping the reference records that transactions depend on, item, supplier, location, and bill of materials, accurate, complete, and consistent. It matters because forecasting, MRP, and replenishment all calculate from these records; if the records are wrong, the plan is wrong even when the software runs perfectly.
What counts as supply chain master data?
Supply chain master data covers four domains: the item or material master, the supplier master, the location or plant master, and the bill of materials with its routings. It excludes transactional data such as individual orders, receipts, and shipments, which reference these records but do not define them.
How does bad master data cause forecast error?
Duplicate item codes are the most common cause: the same part gets ordered under two different codes, splitting its demand history in half. Each record then shows roughly half the actual demand, and the forecast built on either one alone reads as unexplained volatility that has nothing to do with the market.
In what order should master data be cleaned?
Location and plant master first, since every other record references it. Then item master and unit of measure, then supplier master, then bill of materials and routing, then planning parameters like lead time and safety stock, then demand history repair. Cleaning a dependent domain before the one it relies on means redoing the work.
How long does a supply chain master data cleanup take?
It depends more on record volume and how tangled the duplicates are than on the software involved. A single domain with a few thousand clean-enough records can take weeks; a multi-plant network with years of accumulated duplicate item and supplier codes can take several months to work through properly.
Do you need a separate MDM tool, or can the ERP handle it?
An ERP can store clean master data, but most were not built to find and resolve the duplicates, gaps and inconsistencies in existing records. That detection and cleanup work is usually a separate effort, whether handled by a dedicated MDM tool or built natively into a planning layer that sits on top of the ERP.
How do you stop master data from degrading again after cleanup?
Assign ownership by record type, enforce creation rules at entry so incomplete records cannot be saved, keep a standing exception report with a named owner, and tie a quarterly review to an actual planning metric. Without a maintenance loop, a clean master data set typically degrades back within about a year.