Key facts
- Product master data. is the slow-changing core of a product record and holds its codes and composition. Its specifications document claims and packaging. Transactional data sits outside it and covers orders and batches, along with the associated stock movements.
- Ownership is set per attribute. The business owns the content. PLM holds the product-defining attributes until release. After release, ERP holds the attributes used for planning and costing, along with those needed for logistics.
- Measure quality before you fix it. In a Harvard Business Review study, only 3% of data scores reached even the loosest acceptable standard.
- Bad data costs more than the programme to fix it. Gartner puts the average cost of poor data quality at $12.9 million a year per organisation.
- Supplier data is where errors start. Leadership reporting is where they show up.
What counts as product data
Product data is every fact a manufacturer records about what it makes, such as the raw material code or the claim printed on the pack. In a process business the set is wider than in discrete manufacturing. A yoghurt or a shampoo is a recipe, so the record has to hold ingredient quantities and percentages. It must also record part numbers and the properties that come from blending ingredients. The data falls into 4 groups. Each group has different owners and different consequences when it's wrong.
Identity and structure data
Identity data tells every system which product this is. It includes the material number and the Global Trade Item Number (GTIN). The product hierarchy and brand sit in this group, which also holds unit of measure conversions. Structure data links the finished good to its formula and packaging components. It also records the links to variants by market. When identity data is wrong, the same product shows up twice under two codes and nobody can say which code is current. So check this group first. Every other group hangs off it.
Composition and specification data
Composition data describes what's inside the product. That means the formula and raw material specifications. It also covers nutritional or physicochemical values, with the tolerances the plant has to hit. This is the data R&D and quality teams create, and most of what a process manufacturer knows about its products lives here. The detail of what a specification should contain sits in the Specification management guide. Every value the business uses in calculations depends on these records, as do its labels.
Compliance and labelling data
Compliance data records what the product is allowed to say and has to declare. That covers allergens and ingredient declarations. Claims also belong here, alongside the safety data used for market registrations. In food, Regulation (EU) No 1169/2011 sets out what the label must tell consumers, so a gap in this group becomes a gap on the pack. Most of these values are derived. They're calculated from composition data, and they're only as accurate as the inputs.
Commercial and packaging data
Commercial data supplies sales and logistics teams with pack sizes and weights. It also records shelf life and dimensions for cases and pallets. Retailers need this data along with images and marketing copy. Product information management in manufacturing means this group, sent out to retailers and online channels. Although it comes last in the chain, retailers see it first and reject listings when the dimensions don't match the physical case.
Where product data lives today
In most process manufacturers, product data lives in 4 or 5 systems at once, plus the spreadsheets that connect them. Each system was bought for a different job, so each holds the part of the record its users needed, in its own format and under its own codes. When systems overlap, the same attribute ends up in two places without an agreed rule for which copy wins.
Data created in one place, such as a spreadsheet or a supplier email, gets retyped into PLM. It is then retyped again into ERP and PIM. Every retype is another chance for an error, and each copy starts ageing the moment it's made.
Companies are at different stages, with a mid-sized ingredients producer running everything from ERP and spreadsheets while a multinational food group has all 5 layers yet still settles disputes by email. Before choosing any software, name the system where each of 10 attributes you care about is created. If you can't, the first job is mapping.
| System | What it usually holds | Who edits it | Where it goes wrong |
|---|---|---|---|
| Enterprise resource planning (ERP) | Material master, bills of materials for production, costs, plant and logistics views | Supply chain, finance, master data team | Takes product-defining data late and retyped from other sources |
| Product lifecycle management (PLM) | Formulas, specifications, regulatory calculations, change history | R&D, quality, regulatory | Release to ERP is manual or partial, so the two drift apart |
| Product information management (PIM) | Marketing copy, images, channel attributes | Marketing, e-commerce | Copies technical values instead of reading them from the source |
| Master data management (MDM) hub | Golden record and matching rules across systems | Data governance team | Built as a technical layer with no business owner behind it |
| Spreadsheets and shared drives | Supplier questionnaires, label calculations, launch trackers | Everyone | Holds no version history, so a copy can't be traced back to its source |
Who owns the material master
The business owns product master data, and every attribute group has one named owner who answers for its accuracy. IT runs the systems that store it, while the business decides values such as shelf life or allergen status. Ownership in this sense means one person signs off a value, and everyone else reads it. That person works in quality or regulatory, or in supply chain when the value falls under that function.
Between systems, the usual split follows the product's lifecycle. Before launch, PLM is the authoring system for the product's formula and specifications. It also holds the claims and label content that define the product. At release, PLM sends those attributes to ERP, and ERP becomes the owner of everything that runs the business. That includes plant data and costing. Procurement and logistics data also belong there. A field like net weight can sit in both systems, but only one of them may change it. The other receives it through an interface and locks it.
With SAP Master Data Governance or a separate MDM hub, the material master is created there and enriched by PLM, so your workflow has a third participant. Companies with several ERP instances after acquisitions keep a local owner per instance for plant data and a single global owner for product-defining data. Neither model is wrong. What fails is a model nobody wrote down, where R&D assumes ERP is correct and supply chain assumes PLM is.
To check the current state, pick 20 active finished goods and compare 5 shared attributes between PLM and ERP. Compare net weight and shelf life first, then allergen status and pack size. Finish with the status code. Every mismatch shows a missing ownership rule. Fix the rule first, then the record. A rule designed on paper and then built differently in the system creates the same drift, which is why the people who design an ownership model should also configure it. C+P Consulting keeps the same people on process design and on the technical build for that reason.
Measuring quality before fixing
Measure data quality with a sample of real records against rules your users agree on, before anyone starts cleaning. A baseline lets you size the problem and choose where to start. Later, it lets you prove that the fix worked. Teams that skip this step clean the records that are easy to reach. Those aren't always the ones that cause recalls or rejected listings.
The fastest method is the Friday Afternoon Measurement, described in Harvard Business Review by Tadhg Nagle and his co-authors, Thomas Redman and David Sammon. Across the department records they studied, only 3% of data scores were acceptable under the loosest standard. Adapted to product data, the method runs like this:
In a GS1 master data study in Sweden, on average only 70% of trade item information matched the physical product, and only 30% of items had error-free data. If retail-facing data looks like that, the upstream specification data that feeds it deserves a look too.
What you measure depends on how the data gets used. Completeness matters most for launch data, while accuracy matters most for label inputs. For anything ERP plans with, consistency between systems matters most. Agree with the data's users what "correct" means for each attribute before scoring, or the score will start arguments instead of ending them. C+P Consulting begins its PLM programmes with an Assess phase to quantify ROI and map current processes before any design work starts. The assessment also maps the data and pain points. The Product data quality guide covers scoring rules and sampling in more depth.
- Pull the last 100 product records your team created or changed.
- Choose the 10 to 15 attributes that matter most for those records, such as allergen status and net weight. Shelf life and GTIN are other candidates.
- Have two or three people who use the data mark each attribute as correct or obviously wrong.
- Count the records with no errors at all. That count is your score out of 100.
- Sort the errors by attribute and by where they entered, so the pattern points to a root cause.
Governance people follow
Product data governance works when daily workflows contain rules with named owners and somebody is responsible for fixing errors at the source. The governance that holds up is the kind a formulator or a buyer barely notices, because the system asks for the right value at the right step and releases a record only after an owner approves it.
Thomas Redman, the data quality author who developed the Friday Afternoon Measurement, puts the responsibility on the people closest to the data. In Getting In Front on Data he writes: "People must step up to their responsibilities as data creators and data customers." In his terms, the person entering a raw material specification is a data creator whose customer is the regulatory analyst who calculates the label from it. When the two talk about errors, quality improves faster than any cleansing project can manage.
Governance needs to match your size and regulatory exposure, so a business making infant nutrition or cosmetics with safety assessments needs tighter release gates than one making industrial coatings. It should accept slower changes as the cost. Beware of approval chains that are too long, though. If a simple pack change needs 6 signatures, people start working around the system, and the shadow spreadsheet comes back.
Check adoption. Look at how many records went through the approved workflow last quarter and how many changes were made directly in ERP. A gap between the two means the governance exists on paper only. That's why C+P Consulting measures adoption and stays through go-live and the weeks after it. The Product data governance guide sets out role models and workflow design in detail.
- Decision rights per attribute group. One role approves each group, with regulatory responsible for claims and quality responsible for specifications. Supply chain approves logistics data.
- Rules enforced in the system. Mandatory fields and value lists enforce completeness, while status gates stop an incomplete record moving to the next stage.
- Stewards with time in their week. A data steward whose role exists only on an organisation chart will triage nothing.
- A route for disputes. When R&D and supply chain disagree about a value, a named person settles it within an agreed time.
- A small set of quality measures,. reviewed monthly by the people who own the attributes.
Single source of truth meaning
A single source of truth means each attribute has one authoritative place where it's created and changed, and every other system reads from there. Allergen status and net weight can be authored in PLM. Standard cost can have its home in ERP, while marketing copy lives in PIM. The company still has one source of truth, provided each value has exactly one home and moves to the others automatically.
The confusion costs money because it pushes projects toward the wrong goal. A team that reads "single source of truth" as "one system" tries to move everything into PLM or ERP, then finds that neither does the other's job well. A workable map records each attribute's home system and owner. For every attribute, it also identifies the systems that receive it. Many architects call the merged result a golden record, which an MDM hub or interfaces between systems assemble.
Accenture found that only one third of executives trusted their data enough to get value from it. A source of truth that people don't trust gets copied into private spreadsheets, and then there are two sources again.
Migration is where most programmes either create that trust or lose it. When specifications and formulas move from legacy files into a new platform, reconcile every record against its source through counts and value checks. Exception lists should make any gaps visible so the business can see the migrated data is complete. C+P Consulting's migration step, for example, uses analytics to prove the integrity of product data after the move, with checks on specifications and formulations. Check for 3 signs of a working source of truth. Users should stop asking "which number is right" as interfaces carry changes without rekeying. Audits should trace any value back to its home system. The Single source of truth guide covers attribute mapping and architecture choices.
What it costs
Product data management has 5 cost buckets. Software is one, while implementation and integration form another. Data migration and cleansing have their own budget, as do internal people. Ongoing support is the fifth bucket. Licences are the smaller part. Implementation and integration, together with the business time spent on ownership and cleansing, make up most of the total. These are the costs most frequently left out of the business case.
Published ranges give a starting point. Treat them as orders of magnitude and get quotes against your own scope.
Budget for the time deployments take, which OvalEdge reports as go live in 3 to 6 months for cloud-native MDM programmes and 9 to 18 months for on-premise and hybrid deployments. It adds that timelines depend more on governance readiness than on the tool.
The cost of doing nothing belongs in the same calculation. Gartner estimates poor data quality costs organisations $12.9 million a year on average. Under the 1x10x100 rule, cited in the same Dataversity analysis, an error costs about 1 unit to fix where it enters. The cost rises to 10 once it has spread through systems and to 100 when it reaches a customer or a decision. For a process manufacturer, the 100 can mean a relabel or a withdrawn batch. A delisted product is another example.
Your costs depend on 3 variables. The number of systems the data must flow between and the amount of legacy data that needs migration determine part of the cost. The rest depends on how far the design departs from the platform's standard functions. Customisation is the variable you control most. Each custom field and workflow has to be built and tested. It must then keep working through every upgrade. A standard-first approach starts from what the platform does out of the box and deviates only for a real business reason, which C+P Consulting applies as a design principle. Before you approve a budget, check that the business case includes internal staff time for data owners and stewards. Without it, the project will be underfunded from day one.
| Cost component | Typical range | Source |
|---|---|---|
| Cloud MDM subscription, small to mid-sized | $50,000 to $200,000 per year | Binmile MDM cost guide |
| On-premises MDM licence | $100,000 to $500,000 upfront | Binmile |
| Implementation and integration, small to mid-sized | $100,000 to $300,000 | Binmile |
| Implementation and integration, large and complex | $300,000 to $1,000,000 | Binmile |
| Annual maintenance and support | 15 to 25% of licence fees per year | Bluestonex |
| Consulting and professional services | £100,000 to £1M+ | Bluestonex |
Supplier data collection
Supplier data collection is the process of getting raw material specifications from suppliers in a structured form, early enough that formulation and labelling don't wait on them. Certificates and compliance declarations are collected on the same basis. In a process business, every finished product inherits allergen and origin data from its ingredients. Its safety data also comes from those ingredients. So a supplier's error turns into your label error.
In 2024, undeclared allergens caused 101 recalls, or 34% of US food recalls, according to the US PIRG Education Fund. An allergen missing from a supplier specification is one of the routes by which that happens. Gartner's 2019 product manager survey found that 45% of product launches slip by at least a month, with supply problems among the listed causes.
Most manufacturers still email supplier questionnaires as spreadsheets. When a questionnaire comes back partly filled in, someone retypes it. A supplier portal lets suppliers enter data straight into structured fields for validation against your rules. The specification then lands in the product record with its source and date attached. The portal only works if suppliers actually use it, and that depends on onboarding. Keep the first request short and explain why each field matters. Give suppliers a named contact who answers questions.
Supplier data requirements depend on category and risk, so a flavour house with hundreds of complex raw materials needs full specification exchange and document expiry tracking, while a coatings producer needs safety data sheets and substance declarations most of all. To check supplier data against the same standards as internal data, sample 50 raw material records. Count the records that have both a current specification and a valid certificate, along with a complete allergen or substance declaration. Note which suppliers have the highest number of gaps. The Supplier collaboration and Onboarding suppliers guides cover portal design and rollout.
Reporting from product data
Reporting from product data means dashboards that read directly from the governed product record and refresh without anyone rebuilding them by hand. These dashboards support leadership and portfolio decisions, as well as compliance work. If a report needs a person to consolidate spreadsheets before every meeting, it reports from that person's last export and starts going out of date as soon as it's sent.
A dashboard showing how many products contain a restricted substance depends on reliable composition data backed by supplier declarations. Its quality also depends on the ownership rules behind that data. That's why reporting projects run before the data is governed tend to end in arguments about whose number is right.
At one home and personal care manufacturer, leadership had steered the portfolio from manually consolidated spreadsheets that were always a step behind. C+P Consulting digitised the underlying data flows and built executive and portfolio dashboards that refresh automatically from source systems. Compliance dashboards were built to refresh in the same way. The result was real-time decision data and no manual consolidation at all.
Executives need reports on portfolio margin and the launch pipeline, while regulatory teams need to see compliance exposure before an auditor does. For regulatory work, a report can identify which products would be affected if a substance limit changed. Portfolio managers use what-if analysis to examine formulas and ingredient costs. Check that users can click from each dashboard figure back to the product records behind it; otherwise, they'll stop trusting it the first time a number looks odd. The Reporting from product data and Compliance dashboards guides go further into those reports. The What-if analysis guide covers scenario analysis in more depth.
Guides in this topic
Each sub-topic in this guide has its own page that goes deeper. Use the table to find the one that matches your question.
| Sub-topic | Question it answers | Guide that covers it |
|---|---|---|
| Material master ownership | Which system and which role owns each attribute between PLM and ERP | Who owns the material master |
| Data quality | How to score product data before cleaning it | Product data quality: measuring it before you fix it |
| Governance | How to set rules and roles people actually follow | Product data governance that people follow |
| Source of truth | What a single source of truth means in practice | Single source of truth: what it really means |
| Supplier collaboration | How to get reliable supplier data before you need it | Supplier collaboration: getting reliable data before you need it |
| Supplier onboarding | How to bring suppliers onto a data platform | Onboarding suppliers onto a data platform |
| Supplier quality | How supplier quality data fits in the product record | Supplier quality management in the product record |
| Leadership reporting | How to build dashboards leadership will open | Reporting from product data: dashboards leadership will open |
| Compliance reporting | How to see regulatory exposure before an audit | Compliance dashboards: knowing your exposure before an auditor does |
| Scenario analysis | How to model formula and cost changes on product data | What-if analysis on product data |
| Business intelligence | How BI connects to governed product data | Business intelligence for product data |
Where to start
Start with the ownership map. List the 30 attributes that drive your labels and launches, along with those needed for plant operations. For each attribute, record where it is created and who approves it. Add the systems that receive it. That single page identifies the sources of quality problems and the governance rules you're missing. It also shows how big a migration you're facing. It costs a week of workshop time and needs no new software. The gaps on that map, more than any vendor demo, should set the scope of whatever product data management programme comes next.
C+P Consulting helps process manufacturers get product data into one governed record through ownership rules and structured supplier collection. Its work also covers reporting from that record. To talk through your own map, book a 30-minute conversation.
FAQ
Product data management means keeping product facts in a governed record that people and systems can trust. For process manufacturers, this includes recipes and specifications. Each attribute has an agreed owner and an authoritative source, even when several systems hold copies.
More articles
PLM for process manufacturers: the complete guide
PLM for process manufacturing: how formula-based PLM differs from discrete, where ERP, PDM and PIM take over, and the signs you have outgrown spreadsheets.
Regulatory compliance in Food product development
Food information regulation explained: what must legally appear on an EU food label, which foods are exempt, and where UK requirements now differ
Packaging specifications: why they are the weakest record in the product file
Packaging specification management: what the record must hold at component level, why supplier data decays, and how the pack file drives labels and artwork.
The EU packaging regulation and the product data you will need
PPWR regulation explained: what applies from 12 August 2026, the PFAS and recyclability limits, and the packaging data behind every declaration of conformity.
PLM implementation for process manufacturers: a delivery model that holds
A plm implementation for process manufacturers runs in 4 phases. A first release takes 3 to 6 months and an enterprise rollout runs 12 to 24 months.
Specification management for food manufacturers: the complete guide
This guide explains food product specification management, with a 7-step approval order and the BRCGS Issue 9 review every 3 years.
New product development in consumer goods: the complete guide
This new product development guide for consumer goods compares three stage-gate options and four methods to rank projects against capacity.