What is Product Data Quality in PLM?

What is Product Data Quality?

Product data quality is the degree to which product information is fit for the purposes it serves. That definition is deliberately functional rather than abstract. A BOM with accurate part numbers but missing quantities is not high-quality data for a procurement team, even if every number that is present is correct. A drawing with the correct geometry but an obsolete material callout is not high-quality data for a manufacturing engineer selecting raw stock. Quality is not an intrinsic property of data — it is a relational property between the data and the downstream use case.

The established framework for assessing data quality identifies four primary dimensions: accuracy, completeness, consistency, and timeliness. Accuracy is whether the data correctly represents the real-world attribute it is supposed to describe — the tolerance on a drawing matches the tolerance that was validated in testing, not the tolerance from the prior iteration that was not updated after the design change. Completeness is whether all required data elements are present — the BOM includes every component, including fasteners and consumables that might seem trivial but that a shop floor kit requires. Consistency is whether the same attribute is represented identically across all systems that hold it — the part weight in PLM matches the weight in ERP, which matches the weight on the shipping label. Timeliness is whether the data reflects the current approved state of the product — the drawing on the shop floor is the current revision, not a prior revision that was superseded last quarter.

These dimensions can fail independently, and they often do. An organization can have highly accurate data that is catastrophically incomplete — every number is right, but there are enormous gaps in coverage. It can have highly complete data that is wildly inconsistent — every field is filled in, but the same attribute has different values in different systems. Understanding which dimension is failing, in which data category, is the prerequisite for targeted improvement.

Why Product Data Quality Matters in PLM

The consequences of poor product data quality are not theoretical and they are not minor. They are production stoppages, field failures, regulatory non-conformances, and recalled products — each of which traces back to a moment when someone in the value chain acted on product information that was wrong, incomplete, or out of date.

The mechanism of failure is propagation. Product data quality failures are rarely isolated. A wrong dimension on a drawing becomes a wrong machined feature on a part, which becomes a wrong sub-assembly, which becomes a product that fails a functional test, which triggers an investigation that traces back through three revision cycles trying to find when the error was introduced. At each propagation step, the cost of identifying and correcting the error grows. A drawing error caught in a design review takes an hour to correct. The same error caught when a physical assembly fails qualification costs weeks of investigation, rework, and potential schedule impact to downstream programs.

The latency problem makes product data quality particularly insidious. Data quality failures often exist in the system for extended periods — sometimes years — before they manifest as a visible problem. A BOM that has always been missing a secondary fastener family may have been compensated for by an experienced manufacturing engineer who knew from memory that the fastener was needed. That engineer retires. The new hire follows the BOM literally. The parts arrive without the fastener. The assembly cannot be completed. The failure appears to be new; it is actually a latent data quality problem that has existed for years, invisible because institutional knowledge was compensating for it.

Common Use Cases

• BOM audit programs: A precision equipment manufacturer runs quarterly automated BOM audits that check for missing mandatory fields (unit of measure, procurement type, preferred supplier, revision level) and generate a quality scorecard by product family. Engineering managers are accountable for resolving findings within 30 days. Over two years, the program reduced BOM-related production stoppages by 60%.
• Cross-system consistency checks: A tier-1 automotive supplier runs nightly automated reconciliation between PLM and ERP, flagging any part where the PLM revision level does not match the ERP revision level. Discrepancies trigger a review workflow before the next production order can be released, preventing builds from an unvalidated revision.
• New supplier onboarding data validation: A defense contractor requires all supplier-submitted engineering data to pass automated completeness and format validation before it is ingested into PLM, refusing submissions that do not meet the standard and requiring the supplier to correct and resubmit.

Related Concepts

• What is PLM? — the broader system within which product data quality is governed and measured
• What is BOM Management? — the BOM is the highest-stakes category of product data for quality purposes
• EBOM vs MBOM — the EBOM-to-MBOM translation is one of the most common points where product data quality failures are introduced

Frequently Asked Questions

What are the four dimensions of product data quality?

The four primary dimensions are accuracy (does the data reflect reality — is the tolerance on the drawing the tolerance that was designed and tested?), completeness (does the data include everything required — is the BOM missing a fastener family that is assumed but not specified?), consistency (does the data agree with itself across systems — does the part weight in PLM match the weight in ERP?), and timeliness (is the data current — is the drawing in the PLM system the revision that was last approved, or is there a newer approved revision that was not uploaded?). All four dimensions must be met for data to be reliably usable downstream.

How does bad product data quality reach manufacturing?

Bad product data typically reaches manufacturing through the BOM. A drawing with an incorrect dimension creates a part that does not fit. A BOM missing a component means the kit arriving at the work station is incomplete. A material specification that was not updated when a supplier changed their alloy means the substituted material passes receiving inspection but fails performance requirements in the field. In each case, the defect was present in the data long before it became visible as a manufacturing problem — often through multiple revision cycles, each of which assumed the upstream data was correct.

How do you measure product data quality?

Product data quality measurement starts by defining what "correct" looks like for each data category, then sampling or systematically checking actual data against that standard. Practical metrics include BOM completeness rate (percentage of released BOMs with no missing required fields), drawing revision currency (percentage of active drawings where the PLM revision matches the revision physically in use on the shop floor), and ECO cycle time (which often correlates with data quality — long cycle times suggest data is so complex and interconnected that changes are difficult to execute correctly). Organizations that have not previously measured data quality typically find their first audit revealing; it is not unusual to find 20-30% of active BOMs with material deficiencies.