Product master data for configurable products is the structured information required to define, sell, engineer, price, manufacture and support product variants. It includes product families, features, options, attributes, dimensions, materials, components, part numbers, revisions, costs, prices, configuration rules, bills of material and related engineering information.
In manufacturing, product master data is more than a list of items and prices. A configure, price, quote (CPQ) system may need to understand whether a pump can use a particular impeller, whether a motor is suitable for a selected voltage, how a frame size changes the bill of material (BOM), and whether a configured assembly requires a new drawing or engineering review.
The practical objective is to give each system the product information it needs without creating conflicting versions of the product model. Product lifecycle management (PLM) may own engineering definitions, enterprise resource planning (ERP) may own manufacturing and commercial item records, computer-aided design (CAD) systems may own geometry, and CPQ may use a governed subset of this information to configure and quote valid products.
This article explains the data domains, ownership model, system relationships, implementation issues and operational controls required for reliable product master data in a manufacturing CPQ architecture.
What is product master data?
Product master data is the controlled, reusable information that identifies a product and describes its commercial, technical, engineering and manufacturing characteristics. It is generally more stable and structured than transactional data such as a particular quote, sales order or production order.
For a configurable industrial product, master data commonly includes:
- Product families, models and configuration hierarchies
- Features, options, variants and selectable values
- Technical attributes such as capacity, pressure, voltage, dimensions and material
- Part numbers, descriptions, units of measure and lifecycle status
- Option compatibility, dependency and exclusion rules
- Engineering relationships, revisions and effectivity dates
- Configurable BOM structures and component quantities
- Manufacturing operations, work centers or routing references where applicable
- Standard costs, list prices, discounts and pricing conditions
- CAD templates, drawings, documents and design parameters
- Supplier, sourcing, service and regulatory information
Master data should be distinguished from product content. Product content may include sales descriptions, images, brochures and web copy. Product master data is typically more structured and operational: it determines which configurations are valid and what downstream systems must receive when a customer selects them.
Why master data matters in manufacturing CPQ
Generic sales CPQ can often work with a relatively simple catalog, discount table and proposal template. Manufacturing CPQ usually needs a deeper product model. The system may have to validate technical constraints, calculate performance, select components, generate a BOM and pass an order-ready definition to ERP or engineering.
For example, consider a configurable centrifugal pump. A salesperson may select flow rate, head, fluid type, temperature, seal material, motor power, voltage, connection standard and mounting arrangement. These choices can affect one another:
- The required impeller diameter may depend on flow and head.
- The fluid and temperature may restrict seal and material choices.
- Motor power may depend on calculated shaft power and efficiency.
- Voltage and frequency may determine an eligible motor variant.
- The selected frame and coupling may determine the baseplate and guard.
- The final configuration may select different components in the configurable BOM.
If the CPQ configurator contains outdated or incomplete master data, it can produce a technically invalid quote even when the interface appears to work correctly. The result may be engineering rework, an incorrect price, a delayed order or a production exception.
Reliable master data therefore supports the full path from customer requirements to product definition, quote, order, engineering output and manufacturing execution. It is one of the foundations of manufacturing CPQ.
Core data domains for configurable products
Product and variant hierarchy
The hierarchy describes how a company organizes product families, models, platforms, modules, assemblies and sellable variants. A material handling manufacturer might define a product family for conveyors, a platform for belt conveyors, models by width and length range, and optional modules for drives, guards, sensors and controls.
The hierarchy should not be confused with every possible finished-product part number. Some organizations create a unique item number for every combination. Others use a configurable material, a sales configuration identifier or a generated engineering number. The appropriate approach depends on ERP, manufacturing, inventory, costing and traceability requirements.
Features, options and attributes
Features represent meaningful decisions in the configuration process, such as drive type, enclosure rating or pressure class. Options are selectable values within those features. Attributes describe characteristics of the configured product or selected component, such as length, weight, capacity or operating temperature.
Dimensions require particular care. A dimension may be a discrete option, a numeric input within a range, a calculated value or a parameter passed to CAD. The data model should define units, precision, valid ranges, rounding rules and dependencies. A vessel diameter, for example, may be entered by an engineer but constrained by material thickness, transport limits and available forming equipment.
Part and item master records
An item master record identifies a component, assembly, finished product or service. It commonly includes an item number, description, unit of measure, lifecycle status, revision, planning attributes and accounting classifications.
CPQ should not automatically become the authoritative source for every item attribute. In many architectures, ERP owns inventory, purchasing and manufacturing item data, while PLM owns engineering part definitions and revisions. CPQ may store references, synchronized attributes and configuration-specific logic rather than replace those systems.
Rules and constraints
Rules determine how product choices relate to one another. Rules-based configuration uses explicit conditions such as “if option A is selected, option B is required.” Constraint-based configuration represents permitted combinations and restrictions, potentially across numeric values, capacities and engineering relationships. Guided selling asks questions and recommends choices, but a recommendation is not necessarily a technical validation.
Typical rules include:
- Requires: a selected option requires another option or component.
- Excludes: two options cannot be selected together.
- Compatibility: a component is valid only for certain models, materials or operating conditions.
- Range: a value must remain within an allowed minimum and maximum.
- Calculation: a value such as motor size or material thickness is derived from inputs.
- Effectivity: a rule applies only from a specific date, revision or market.
- Approval: a valid but unusual configuration requires engineering review.
Rules should be treated as governed product knowledge, not merely interface behavior. They require named owners, test cases, version control and a process for handling exceptions. More detail is available in the guide to product configuration and configuration rules.
Engineering and CAD data
Some configurations can be assembled from standard components, while others require engineering calculations, parameterized geometry or a new drawing. CAD data may include templates, models, drawing rules, material parameters and references to standard hardware.
CPQ may send selected parameters to a CAD automation service, which generates product-specific geometry or drawings. Alternatively, CPQ may only identify the configuration and create an engineering request. These are different capabilities and should not be assumed to exist in every CPQ platform.
CAD and engineering data should have clear ownership and revision relationships. A CPQ option should not silently point to an obsolete drawing or an unapproved model. See CAD and engineering automation in CPQ for the relationship between configuration data and design outputs.
BOM and manufacturing data
A bill of material (BOM) describes the components and quantities required for a product or assembly. An engineering BOM (EBOM) represents the product from an engineering perspective. A manufacturing BOM (MBOM) organizes material and assemblies for production. A configurable BOM is a structure containing rules, alternatives or selections that resolve into a product-specific BOM after configuration.
For a configured electrical enclosure, the selected enclosure size, circuit protection, terminals, wiring accessories and mounting plate may determine the resolved BOM. The EBOM may describe functional engineering relationships, while the MBOM may add packaging, work instructions, consumables or production-specific subassemblies.
CPQ may generate a quote-level BOM, an order BOM, an EBOM request or an MBOM-ready structure. The exact output must be defined rather than assumed. More information is available in BOM generation, costing, pricing and quoting.
Pricing, costing and commercial data
Pricing data includes list prices, regional prices, customer-specific agreements, discounts, surcharges, currencies and validity periods. Costing data may include material cost, purchased component cost, labor, setup, subcontracting and overhead assumptions.
Configuration data and pricing data are related but not identical. A selected stainless-steel material may change both the technical validity of a product and its cost. However, the price calculation may also depend on customer segment, quantity, freight, margin policy or commercial approval rules.
Separating these concerns makes the model easier to govern. A product engineer may own material compatibility, while commercial operations owns price conditions. Both may be required before a quote can be released.
System ownership in the manufacturing technology stack
Product master data is usually distributed across several enterprise systems. The goal is not to force every attribute into one database, but to define authoritative ownership and reliable synchronization.
| System | Typical responsibility | Relationship with CPQ |
|---|---|---|
| PLM | Engineering product definitions, revisions, lifecycle and change control | Provides approved product structures, options, revisions or engineering references |
| PDM | Product data management for CAD files, drawings and documents | Provides controlled design files or document references where supported |
| ERP | Items, inventory, purchasing, manufacturing, orders, accounting and often pricing | Receives order and item data; may provide commercial and operational master data |
| CRM | Accounts, opportunities, activities and customer-facing sales processes | Uses CPQ configuration and quote results within the opportunity workflow |
| CAD | Parametric geometry, models, drawings and design calculations | Receives configuration parameters or returns engineering outputs |
| PIM | Product information for channels, catalogs and digital commerce | May receive approved descriptions, attributes and media for publication |
| MES | Manufacturing execution, work instructions, production tracking and shop-floor data | May receive resolved BOMs, routings, instructions or configuration identifiers |
| CPQ | Configuration interaction, validation, commercial calculation and quote assembly | Uses governed data and rules to create a valid commercial configuration |
The boundaries vary by organization and software architecture. For example, a CPQ platform may own the executable configuration model while PLM owns the source engineering structure. In another implementation, a product model may be authored in PLM and transformed into a CPQ-specific representation. Both approaches require explicit synchronization and change management.
How product master data flows through a CPQ process
- Product definition: Engineering and product management define families, options, parameters, components and constraints.
- Approval and release: PLM, ERP or another governance process releases the relevant revisions and item records.
- Model preparation: The CPQ product model is created or synchronized, including rules, descriptions, prices and outputs.
- Configuration: A salesperson, dealer, engineer or customer selects requirements and options.
- Validation: The configurator checks dependencies, ranges, compatibility and required approvals.
- Calculation: The system calculates technical values, costs, prices, discounts and lead-time factors as configured.
- Output generation: CPQ creates a quote, proposal, configuration identifier and, where supported, a resolved BOM or CAD request.
- Enterprise handoff: CRM, ERP, PLM, CAD or MES receives the appropriate data through APIs, files or middleware.
- Order and production: The accepted configuration becomes an order, engineering package or manufacturing definition according to the selected workflow.
This flow differs by operating model. Configure-to-order (CTO) uses predefined configurations and components. Engineer-to-order (ETO) requires engineering work for a significant portion of the product. Make-to-order (MTO) manufactures against an order, while assemble-to-order (ATO) combines stocked modules after the order. Product master data must indicate which path applies and what outputs are required.
Data ownership and governance
A product data governance model should answer four questions for every important field: who creates it, who approves it, which system is authoritative and which systems consume it.
A practical ownership matrix may assign:
- Engineering ownership of technical limits, component compatibility and design revisions
- Product management ownership of product families, market options and lifecycle decisions
- Manufacturing engineering ownership of production structures, routings and assembly constraints
- Commercial ownership of price lists, discount policies and approval thresholds
- IT or enterprise architecture ownership of interfaces, identifiers and integration monitoring
- CPQ administration ownership of executable rules, user experience and model deployment
Governance also requires common identifiers. Part numbers, option codes, revision codes, units of measure and effectivity dates must be mapped consistently. A description such as “high temperature seal” is not sufficient if ERP, PLM and CPQ use different codes or meanings for the same component.
Change management is equally important. A new motor may require an ERP item, a PLM revision, a CAD update, a BOM rule change, a price update and new CPQ test cases. A release process should identify all affected systems and prevent partially updated models from being used for live quotes.
Implementation considerations
Start with a product data inventory
Document the current sources of product information, including spreadsheets, ERP item masters, CAD libraries, PLM structures, price lists, dealer catalogs and engineering calculators. Identify duplicate fields, conflicting identifiers, obsolete options and undocumented rules.
Model the configuration scope
Do not migrate every product record into CPQ automatically. Define which product families require interactive configuration, which are sold as standard items and which require ETO review. Prioritize products where configuration errors, engineering effort or quote delays have a material operational impact.
Separate source data from executable logic
A source BOM or product structure may not be directly usable as a CPQ model. The CPQ implementation may need transformed options, conditional components, calculated attributes and user-facing descriptions. Document this transformation so that model maintainers can trace a rule back to its engineering or commercial source.
Test combinations and lifecycle changes
Testing should cover valid configurations, invalid combinations, boundary values, price changes, revisions, discontinued components, effectivity dates, currencies and integration failures. It should also verify that the resolved BOM, CAD request, quote and ERP order contain consistent identifiers.
Plan for maintenance
Product models are operational software assets. They need release calendars, rule ownership, regression tests, deployment controls and monitoring. A configuration model that is correct at launch can become unsafe when suppliers change components, standards change, prices expire or engineering releases a new revision.
Implementation guidance covering migration, testing, deployment and governance is available in the manufacturing CPQ implementation guide.
Common limitations and failure modes
- Unclear ownership: Multiple systems edit the same field, producing conflicting values.
- Catalog-only modeling: The CPQ model contains descriptions and prices but not technical constraints or downstream structure.
- Overloaded CPQ: CPQ is made responsible for engineering, inventory, document control or manufacturing functions better handled elsewhere.
- Hidden spreadsheet logic: Critical calculations remain outside the governed product model.
- Part-number explosion: Every theoretical combination receives a separate item number without considering maintainability.
- Weak revision control: Existing quotes or orders cannot be traced to the product rules and revisions used at the time.
- Incomplete integration: A quote is generated successfully but the resulting configuration cannot be consumed by ERP, PLM, CAD or production.
- Unmanaged exceptions: Sales teams bypass validation because the standard model cannot represent legitimate ETO or approval cases.
These problems are not solved by adding more fields to a product catalog. They require a defined architecture, reliable identifiers, data stewardship and agreement about the desired manufacturing workflow.
Product master data checklist
Before implementing or expanding a CPQ configurator, verify that the organization can answer the following questions:
- Which system owns each product, part, option, revision and price?
- Are configuration rules documented and testable?
- Which inputs are discrete options, numeric parameters, calculated values or engineering requests?
- Can the model identify invalid combinations before a quote is released?
- Does the configured product need a quote BOM, EBOM, MBOM, CAD output or only a configuration identifier?
- How are CTO, ATO, MTO and ETO products distinguished?
- How are revisions, effectivity dates and discontinued components handled?
- Which data must flow to CRM, ERP, PLM, PDM, CAD, PIM or MES?
- Who approves technical exceptions and commercial overrides?
- How will product model changes be tested and deployed?
- Can a historical quote be reproduced using the rules and master data that were active at the time?
Semantic map
The following relationships summarize how product master data connects a manufacturing CPQ configurator with engineering and enterprise systems:
- Product master data defines configurable products.
- Configuration rules prevent invalid combinations.
- Product options select components and attributes.
- Configured products generate resolved BOMs.
- EBOMs represent engineering product structures.
- MBOMs organize products for manufacturing.
- PLM controls engineering revisions.
- ERP manages operational item and order data.
- CAD automation generates product-specific drawings.
- CPQ calculates prices from configuration and commercial data.
- CRM stores opportunities and uses quote results.
- APIs exchange product and configuration data between systems.
- MES consumes manufacturing definitions and production instructions.
- Product data governance controls ownership and change.
- ETO workflows route non-standard configurations to engineering.
FAQ
What is product master data for configurable products?
It is the governed technical, commercial, engineering and manufacturing information used to define, validate, price and produce product variants.
Is product master data the same as a product catalog?
No. A catalog may contain descriptions and prices, while master data also includes identifiers, revisions, constraints, components, calculations and downstream manufacturing relationships.
Which system should own product master data?
There is usually no single owner for every field. PLM commonly owns engineering definitions, ERP operational item data, and CPQ the executable configuration and quoting model, subject to the company’s architecture.
Should CPQ be the master data system?
Usually not for all domains. CPQ should consume or reference authoritative data and may own the rules and model required for configuration, unless the selected architecture explicitly assigns it broader ownership.
How does master data support a CPQ configurator?
It supplies the products, options, attributes, constraints, prices and component relationships that allow the configurator to produce valid and commercially accurate results.
What is the difference between product configuration and product master data?
Product master data describes the product and its possible variants. Product configuration is the act of selecting values and resolving one valid instance of that product.
What data does a configurable pump require?
It may require flow, head, fluid, temperature, materials, seal type, impeller, motor, voltage, connection standard, price and component relationships.
How do configuration rules relate to master data?
Rules are governed logic built from product knowledge. They use master data such as options, attributes, components, ranges, revisions and compatibility relationships.
What is a configurable BOM?
A configurable BOM contains alternatives, conditions or selection rules that resolve into a product-specific BOM after configuration.
Does CPQ generate an EBOM or MBOM?
Some platforms can generate or integrate with BOM structures, but capabilities vary. The implementation must specify whether CPQ produces a quote BOM, EBOM, MBOM, order structure or reference only.
How is an EBOM different from an MBOM?
An EBOM represents the product from an engineering viewpoint. An MBOM organizes materials and assemblies for manufacturing and may include production-specific structures and consumables.
What role does PLM play in configurable product data?
Product lifecycle management (PLM) commonly controls engineering parts, structures, revisions, approvals and effectivity, which CPQ may consume for configuration and quoting.
What role does ERP play?
Enterprise resource planning (ERP) commonly manages item records, inventory, purchasing, manufacturing orders, accounting and operational transactions connected to the configured product.
How does CAD use CPQ product data?
Where supported, CPQ can pass dimensions, options and parameters to CAD automation. CAD may then generate geometry, drawings or design outputs, although not every CPQ system provides this capability.
How should numeric dimensions be modeled?
Define units, precision, valid ranges, rounding, dependencies and whether the value is entered, selected or calculated. These details are essential for engineering validation.
How does master data support engineer-to-order products?
It identifies standard limits, reusable modules, engineering inputs and approval triggers, allowing CPQ to distinguish valid standard configurations from cases requiring engineering work.
What causes product master data conflicts?
Common causes include duplicate ownership, inconsistent part numbers, manual spreadsheets, missing revision control, unsynchronized prices and undocumented configuration logic.
How should product data changes be tested?
Test valid and invalid combinations, boundary values, pricing, BOM resolution, revisions, effectivity dates and every affected integration before deployment.
Can product master data improve quote accuracy?
Yes, when the data includes current rules, costs, prices, components and engineering constraints. Master data alone cannot improve accuracy if it is incomplete or poorly governed.
What is the difference between CPQ master data and PIM data?
Product information management (PIM) focuses on publishing product content across channels. CPQ master data must additionally support configuration logic, technical validation, pricing and downstream transaction outputs.
Should every product combination have its own part number?
Not necessarily. Some products use configurable items or generated identifiers, while others require distinct part numbers for inventory, traceability, costing or production. The decision should reflect operational requirements.
How often should CPQ product master data be updated?
It should be updated whenever approved products, components, prices, rules, revisions or manufacturing processes change, using a controlled release process rather than an arbitrary calendar alone.