Making a field required guarantees there is a value, not that it is the right one. That is the difference between a form with validations and a material master that is actually governed: rules extracted from your own data, creation with no re-keying, and continuous validation of what already exists.
What is material master data governance in SAP?
It is the set of rules, approval workflows and controls that determine who can create or change a material, with what information and under which validations, before that record exists in SAP. It also covers the traceability of every change and the continuous validation of the existing master, not just the definition of required fields.
According to Harvard Business Review, only 3% of companies have data that meets basic quality standards. The rest live with a master that passes every validation in the form and fails later, in the process.
The material that was created correctly and broke MRP three weeks later
It passed validation. Every required field was filled in. Someone on the plant floor asked for it by email, someone in master data created it, and the flow moved on.
Three weeks later, MRP proposed 4,000 units of something that is consumed six at a time. The base unit of measure was EA instead of KG. A perfectly valid value. A perfectly incorrect value.
Nobody did anything wrong, as far as the system was concerned. And that is the problem: the system was not checking what we thought it was checking.
Required does not mean correct
Flagging a field as required guarantees one thing only: that there is a value. Not that it is the right one.
What happens next is familiar to anyone who has looked at a material master older than five years:
XXX,N/A,.,PENDING- The value copied from the previous material, because “it looked similar”
- A description that starts with the supplier code because that made it easier to find back in 2017
- The material group that happened to be first in the dropdown
All of it passes validation. All of it fails later: in the warehouse, in planning, in inventory, in the invoice that does not match. The validation arrived in time for the form and too late for the process.
A required field is a tax on whoever fills in the form, not a control over the data. It adds friction for the requester and no quality to the master. And when the cost of getting it right falls entirely on the person with the least context, the outcome is predictable.
There is a second-order consequence, and it is the expensive one: where the master is dirty, there are duplicates. The same bearing created three times with three different descriptions means three safety stocks, three purchases, three storage locations. Sparetech estimates that between 10% and 25% of stock value can be redundant because of duplicate materials. That is not a data problem: it is tied-up capital.
Excel and the external system: the same problem, with extra steps
When the standard gets uncomfortable, two escape routes appear. Both feel like a solution and neither is.
A spreadsheet validates nothing. An Excel file travelling by email does not check whether the material group exists, whether the purchasing view is consistent with the plant, whether the material is already created under another name. It cannot: it is not connected to SAP. When someone re-keys that sheet into the system, validation arrives late and is performed by a tired person at six in the afternoon. Excel is not where data is governed; it is where data governance is temporarily suspended.
An external system does validate, but it has to be synchronised. And synchronisation is a second system to maintain: its own latency, its own conflicts, its own project when SAP changes release. You trade a data quality problem for an integration problem, which is more expensive and less visible. The master stops having a single source of truth exactly when it matters most.
There is a third way, and it is the boring one: keep the workflow inside SAP. It is requested, approved, and created from what was approved. No re-keying, no parallel copy, no synchronisation. It is not spectacular. It simply means there is no second place where the data can be wrong.
Useful rules are not written: they are extracted from the master you already have
This is the part almost every data quality project gets backwards.
A committee is convened, a naming convention is drafted, a 40-page document is published, and the organisation is asked to follow it. Six months later, the only person following the convention is the one who wrote it.
The reason is simple: nobody knows in advance which combinations of characteristics are valid for a bearing, a reagent or a milling spare part. Theory does not know. The consultant does not know. But the current master does: those 40,000 materials contain the real pattern of how that specific company names, classifies and describes what it buys.
Extracting those rules from the master itself — AI-assisted work, because at that scale manual review is not viable — changes the nature of the document. It stops being an imposed standard and becomes a description of how the house actually works. It is, literally, letting your data propose the rules. And a rule that describes how people already work is a rule people follow, because it does not ask them to change: it asks them to be consistent.
That is the difference between a naming convention that is followed and one that is worked around.
Decentralise, automate, validate
Cleaning the master once and leaving the same entry routes open guarantees it will look exactly the same in 18 months. Data cleaning is not a project: it is a state. And what sustains that state is a specific order of three moves.
Decentralise with adoption. Whoever knows the material is whoever requests it: the maintenance engineer, the plant manager, the technical buyer. The bottleneck appears when that person has to work through a transaction designed for a specialist. You solve it by showing them only what concerns them — their request type, their views, their fields — and nothing else.
Automate creation. Once the request is approved, the material is created in SAP across all its views from what was approved. With nobody typing anything again. Every re-key between approval and creation is a chance to introduce exactly the error the workflow was meant to prevent.
Validate continuously. Not only at creation: also over what already exists. Missing views, badly maintained fields, duplicates that got in before there were any rules. The master degrades on its own; without validation running over the existing stock, every clean-up is a snapshot with an expiry date.
And above all three: traceability. Who requested what, who approved it, on what grounds and when. Not for bureaucracy, but because it is the only thing that lets you answer the auditor’s question without reconstructing an email thread.
The cost of not doing it is hard to see on a line of the P&L, but it has been measured: Gartner puts the average cost of poor data quality to a company at $12.9 million a year.
How SiDM Materials solves it
SiDM Materials is Innova’s application to create and govern material master data in SAP from a single application. It applies business rules, AI-assisted, to validate and correct existing materials (data cleaning) and speed up the creation of new materials, with approval and participation workflows. It runs on SAP ECC and S/4HANA.
Translated into the three moves above:
| What hurts | What SiDM Materials does |
|---|---|
| Creating a material takes days | A single request for creation, extension or change; on approval, SiDM creates the material in SAP across all its views |
| Too many views, fields and transactions | Each request type shows only the views and fields that apply; data is copied from a model material |
| Duplicate materials inflating stock and purchases | Duplicate search by text or characteristics, unique-value fields and descriptions built with masks |
| Approvals by email and Excel | Multi-level approval with its own strategies and notifications in each user’s language |
| Nobody knows who approved what, or why | History of every status change with its reason, plus an audit report of requests |
| Missing views or badly maintained data | Validation of views and fields against rules, with correction of the views that are missing |
It is deployed on SAP ECC and S/4HANA, on the architecture you already have — Fiori, BTP or web server — with implementation in 4–8 weeks and no per-user or per-company fees. It is part of the Master Data Suite, together with SiDM Suppliers.
If you want the strategic context first — how to frame the project before touching a single transaction — it is in master data strategy in SAP.
See it working before you talk to anyone
There is a point where descriptions stop being useful. This one you understand by looking at it.
There is a 30-screen interactive demo covering the full journey of a material creation request: from the requester starting out from a variant and adopting a model material, to the request not being released because the bill of materials, the routing and the production version are missing.
No form, no sales rep, no calendar invite. Screen by screen, at your own pace. Open the SiDM Materials interactive demo.
Frequently asked questions
So is a required field useless?
It ensures presence, not correctness. It is a valid component within a broader validation scheme, but on its own it shifts the cost to the requester without improving the master. A useful control checks the value against a rule, not against emptiness.
How do you detect duplicate materials that already exist?
By matching texts and characteristics, not only codes. On top of that come unique-value fields and descriptions generated with masks, which stop the same item from being created again under a different name. Detection over the existing master and prevention at creation are two different jobs: you need both.
Do you need to migrate to S/4HANA to govern master data properly?
No. Data governance is independent of the release. What does change is the cost of not doing it: migrating with a dirty master moves the problem along and makes the project more expensive, because data conversion becomes the critical path.
How long does it take to go live?
Innova applications are implemented in 4–8 weeks. The factor that stretches a master data project is not the tool: it is the internal agreement on the rules. Extracting them from the existing master instead of drafting them from scratch shortens exactly that part.
What role does AI play here?
Assisted, not autonomous. It is used to find patterns across a master of tens of thousands of records — how things are named, how they are classified, which combinations of characteristics actually appear — and turn them into proposed rules. The decision on which rule is adopted still belongs to the master data team.
Want to see these rules applied to your own material master? We look at it with your data, not with an example.
