CPQ Guide

Tag: Product configuration

  • Solution Configuration vs Single-Product Configuration in Manufacturing CPQ

    Solution configuration configures a complete system made from multiple products, assemblies or services, while single-product configuration configures one product model or product family at a time. In manufacturing CPQ, the difference is not simply the number of items in a quote. It determines where rules are stored, how compatibility is validated, how prices and costs are calculated, and whether the output is one product record or a coordinated solution with multiple bills of material (BOMs).

    For example, configuring one centrifugal pump with a selected motor, seal and material options is single-product configuration. Configuring a complete pumping skid with several pumps, a base frame, valves, sensors, control panels, piping and installation requirements is solution configuration. The skid may contain several independently configurable products, but the system must also validate relationships between them.

    A manufacturing CPQ system may support one or both approaches. Buyers should verify the actual capabilities of each platform rather than assume that a product configurator automatically supports multi-product system design, engineering calculations, configurable BOMs or computer-aided design (CAD) automation.

    What is single-product configuration?

    Single-product configuration is the process of selecting valid options and parameters for one configurable product, product family or engineered assembly. The configuration model normally contains the product structure, available options, dependencies, constraints, calculations and outputs for that product.

    In manufacturing, a single product can still be technically complex. A configurable industrial pump may require decisions about flow rate, head, impeller diameter, casing material, motor power, voltage, seal type, connection size and environmental conditions. The configurator must determine whether those selections are compatible and may calculate a product-specific price, cost, BOM or drawing.

    Typical single-product model

    • Features and options: such as motor voltage, frame material or connection type.
    • Dependencies: for example, a high-temperature seal is available only with certain casing materials.
    • Constraints: such as a motor size that cannot be used with a particular pump frame.
    • Calculations: such as power requirements, capacity, weight or dimensional values.
    • Outputs: such as a configured item number, price, product-specific BOM or CAD parameters.

    This model is often appropriate for standard or configurable-to-order products where the main engineering problem is selecting options within one product family. It can support configure-to-order (CTO), make-to-order (MTO) or, in some cases, engineer-to-order (ETO) workflows depending on how much design work remains after configuration.

    What is solution configuration?

    Solution configuration is the process of selecting and coordinating multiple products, subsystems, assemblies and services so that the complete combination satisfies technical, commercial and operational requirements.

    A solution may include products from different product families. A material-handling system, for example, may contain conveyors, transfer stations, motors, drives, guarding, sensors, control cabinets and software. Each item may have its own configuration rules, but the solution also requires cross-product rules.

    Examples of cross-product rules include:

    • a selected conveyor width must match the transfer station opening;
    • the motor and variable-frequency drive must support the required load and voltage;
    • the control panel must have enough inputs and outputs for the selected sensors;
    • the pump, valve and pipe materials must be compatible with the process fluid;
    • the selected vehicle body must fit the chassis wheelbase and payload rating;
    • the total electrical load must remain within the selected power-supply capacity;
    • the system must meet site, safety, environmental or regulatory requirements.

    Solution configuration therefore combines product configuration with system architecture, compatibility management and sometimes engineering design. It is especially relevant to industrial machinery, HVAC systems, electrical equipment, automation cells, specialty vehicles, energy systems and engineered skids.

    Key differences between the two approaches

    Criterion Single-product configuration Solution configuration
    Scope One product model or family Multiple products, assemblies, systems or services
    Rules Rules mainly govern options within one product Rules govern both local options and relationships between products
    Example Configuring a pump Configuring a complete pumping station
    Primary output Configured product, item number, price and possibly BOM Coordinated solution structure, multiple outputs and system-level price
    Engineering Product-specific calculations or parameter selection System sizing, interface validation, layout and integration engineering
    BOM Usually one configurable BOM or product assembly Several product BOMs plus a solution-level structure
    Quoting One product line or related option lines Multi-line commercial offer with packages, services and exclusions
    Risk Invalid option combinations Invalid interfaces, incomplete scope or incompatible subsystems

    How product models differ

    A single-product model usually starts with a product family and its option structure. The model may represent a base pump, valve, enclosure, vehicle or machine. Rules are attached to features, options, attributes and variant parts.

    A solution model adds a higher-level structure. It may contain:

    1. a solution template, such as a water-treatment skid or packaging line;
    2. required and optional subsystems;
    3. one or more product models for each subsystem;
    4. interface definitions between subsystems;
    5. system-level calculations and capacity limits;
    6. commercial rules for packages, services, freight and installation;
    7. outputs that connect the solution to engineering, production and service systems.

    The distinction between a product model and a solution model is important for governance. A pump product manager may own pump options and pump rules. A systems engineering team may own rules about pump-to-pipe, pump-to-motor or pump-to-control-panel compatibility. If these responsibilities are not defined, changes can create contradictory rules or duplicate logic.

    Rules and constraints in single-product configuration

    Single-product configuration generally relies on rules within a bounded product domain. Common rules include:

    • Option compatibility: option A requires or excludes option B.
    • Value ranges: a dimension or capacity must remain within defined limits.
    • Conditional availability: an option appears only when a prior choice makes it relevant.
    • Technical calculations: a motor or frame is selected based on load, speed or capacity.
    • Variant mapping: a configuration maps to a stock keeping unit, material number or manufacturing variant.

    These rules can be implemented as rules-based configuration, constraint-based configuration or a combination. Rules-based configuration commonly expresses explicit conditions such as if-then relationships. Constraint-based configuration evaluates permitted combinations against limits, relationships and requirements. Guided selling helps a user reach a suitable configuration through questions, but it is not necessarily the same as a complete engineering constraint solver.

    More detail on product models, dependencies and validation is available in the guide to product configuration.

    Rules and constraints in solution configuration

    Solution configuration requires all of the rules used by single-product configuration plus rules that cross product boundaries. These cross-product constraints often represent engineering interfaces rather than simple option dependencies.

    Common cross-product rule types

    • Dimensional interfaces: a selected pipe diameter must match a valve connection or machine inlet.
    • Capacity relationships: the cooling unit must handle the heat load produced by the selected equipment.
    • Electrical relationships: motors, drives, transformers and panels must use compatible voltage, current and protection ratings.
    • Performance relationships: a pump curve, fan capacity or conveyor speed must satisfy the system requirement.
    • Spatial relationships: equipment must fit within a defined footprint or vehicle body.
    • Regulatory relationships: selected components may need to meet a common certification or safety category.
    • Commercial relationships: installation, commissioning or service packages may be required for a particular system.

    In a mature architecture, these rules should be explicit and testable. Storing them informally in sales notes, spreadsheets or individual employee knowledge makes the solution model difficult to maintain and increases the risk of invalid quotes.

    Manufacturing examples

    Example 1: Industrial pump

    Single-product configuration begins with the required flow and pressure. The model selects pump size, impeller, casing, seal, motor and connection standard. It may generate a configured BOM and a price.

    Solution configuration begins when the customer is buying a complete pumping package. The model must coordinate several pumps, a skid frame, valves, strainers, instrumentation, a control panel and piping. It must check duty and standby arrangements, pipe interfaces, motor voltage, control-panel capacity and the physical arrangement of the skid. The quote may also include testing, documentation and installation.

    Example 2: HVAC system

    A single air-handling unit can be configured by selecting airflow, casing, filters, coils, fans and controls. A complete HVAC solution adds chillers, pumps, duct interfaces, controls, electrical equipment and site-specific requirements. The solution model must verify capacity and compatibility across the system, not merely validate each unit independently.

    Example 3: Specialty vehicle

    A single-product model may configure a truck body using body length, material, compartments, doors, lifting equipment and lighting. A solution model may combine a chassis, body, hydraulic system, power take-off, control system and customer-specific accessories. Payload, axle loads, center of gravity, electrical load and mounting interfaces become system-level constraints.

    Pricing, costing and quoting implications

    Configuration determines what can be sold, but it does not automatically determine how the solution should be priced. Pricing and quoting are related capabilities that may use configuration results as inputs.

    For single-product configuration, pricing may be based on a base model plus option prices, dimensions, materials, labor assumptions or calculated costs. For solution configuration, pricing may require:

    • prices for each configured product and assembly;
    • system-level discounts or package rules;
    • engineering, installation, commissioning and documentation services;
    • freight, site work and project-specific commercial terms;
    • currency, tax, dealer and regional pricing;
    • risk allowances or approval thresholds for non-standard work.

    A solution quote should make scope visible. It should distinguish included equipment from optional items, customer responsibilities, exclusions and engineering assumptions. A generic sales CPQ tool may produce a commercial quote but may not maintain the engineering structure or manufacturing data needed for a complex solution.

    See the guide to BOM generation, pricing and quoting for the relationship between configuration outputs and commercial documents.

    BOM and engineering outputs

    A bill of material (BOM) is a structured list of components required to make or deliver a product. In manufacturing, an engineering BOM (EBOM) represents the design view, while a manufacturing BOM (MBOM) represents how the product is assembled or produced. A configurable BOM contains rules or variant logic that determines which components are included for a particular configuration.

    Single-product configuration may produce one configurable product structure. Solution configuration may produce:

    • a solution-level structure containing several configured products;
    • an EBOM for system design;
    • separate product or subsystem BOMs;
    • an MBOM or production structure after manufacturing transformation;
    • installation, spare-parts or service lists.

    These outputs are not interchangeable. A CPQ platform may generate a quote line structure without generating an EBOM or MBOM. It may also pass selected parameters to an enterprise resource planning (ERP) system without owning the authoritative engineering structure. Integration design must define which system owns each output.

    CAD, visualization and engineering calculations

    Single-product configuration can pass parameters to a parametric CAD model, such as length, hole pattern, mounting position or material thickness. The CAD system may then generate a product-specific model or drawing.

    Solution configuration adds layout and interface questions. A system may need to position multiple products, route pipes or cables, check clearances and produce an arrangement drawing. Some platforms support these functions through CAD or design-automation integrations; others stop at selections, pricing and document generation.

    Three-dimensional visualization can help users understand a configured product or solution, but visual appearance is not proof of engineering validity. A 3D view may not validate pressure ratings, electrical load, structural strength, thermal performance or manufacturing feasibility. Engineering calculations and authoritative CAD or product lifecycle management (PLM) data may still be required.

    Review the guide to CAD and engineering automation in CPQ when evaluating these requirements.

    Where each approach fits in manufacturing workflows

    Workflow Single-product fit Solution-configuration fit
    Configure-to-order (CTO) Strong fit when one product has defined variants Useful for standard systems assembled from validated modules
    Make-to-order (MTO) Useful when options drive production without a new design Useful when several MTO products must be coordinated
    Engineer-to-order (ETO) May capture requirements before engineering Useful as a system-level specification and engineering handoff
    Assemble-to-order (ATO) Useful for selecting stocked modules Useful when modules must be combined under interface rules

    In an ETO process, solution configuration should not be presented as a substitute for engineering review. It can capture requirements, select known modules, identify non-standard conditions and create a structured handoff. The engineering team may still need to design new components, approve calculations and release final production data.

    The manufacturing workflows guide explains how configuration connects sales, engineering and production.

    System architecture and integrations

    A typical architecture separates responsibilities across several systems:

    • CPQ: manages configuration interaction, rules, pricing inputs and quote generation.
    • Customer relationship management (CRM): manages accounts, opportunities and sales activities.
    • ERP: manages items, orders, inventory, purchasing, production and financial transactions.
    • PLM: manages product structures, revisions, requirements and lifecycle control.
    • Product data management (PDM): manages engineering files and CAD-related product data.
    • CAD: creates geometry, drawings and design outputs.
    • Product information management (PIM): manages commercial product information and content for channels.
    • Manufacturing execution system (MES): manages production execution and shop-floor information.

    For single-product configuration, the main integration may be between CPQ, ERP and CAD or PLM. For solution configuration, integration must also preserve relationships between subsystems, revisions, quantities, interfaces and project-specific outputs. APIs and event-based integration may be needed when configuration changes must update pricing, engineering structures and order data without manual re-entry.

    More integration considerations are covered in the CPQ integration guide.

    Benefits and limitations

    Benefits of single-product configuration

    • More focused product models and ownership.
    • Faster validation for bounded option sets.
    • Simpler testing and release management.
    • Clearer mapping to product numbers, prices and BOM variants.
    • Good support for repeatable CTO and MTO products.

    Benefits of solution configuration

    • Validates the complete system instead of isolated products.
    • Reduces manual coordination between sales and application engineering.
    • Improves completeness of multi-product quotes and proposals.
    • Creates a structured starting point for engineering and project execution.
    • Supports modular systems, packages and repeatable solution architectures.

    Limitations and risks

    • Solution models are more difficult to design, test and govern.
    • Cross-product rules can become duplicated or contradictory.
    • Engineering calculations may exceed the capabilities of a commercial configurator.
    • Incomplete master data can make technically valid configurations impossible to manufacture.
    • Large product models can create slow user experiences and difficult change management.
    • Automatic BOM or CAD output may require specialized integrations rather than standard CPQ features.
    • Complex ETO work still requires engineering judgment and formal approval.

    How to choose the right configuration approach

    Use single-product configuration when the customer is selecting a defined product family and the important rules remain inside that family. Use solution configuration when the value proposition, technical validity or commercial scope depends on relationships between multiple products or subsystems.

    Many manufacturers need a layered approach rather than an either-or decision:

    1. model each product family independently;
    2. reuse those models within solution templates;
    3. add cross-product interface rules at the solution level;
    4. apply system-level calculations and commercial rules;
    5. generate the appropriate quote, BOM, CAD and engineering handoff outputs.

    This architecture avoids rebuilding every product rule inside every solution. It also makes ownership clearer: product teams maintain local rules, while systems or application engineering teams maintain interface rules.

    Implementation and governance considerations

    Start with a product and solution inventory. Identify which offerings are true single products, which are packages of existing products and which require new system engineering for every order. Document the input parameters, constraints, calculations, outputs and responsible owners for each category.

    Important implementation activities include:

    • defining a common vocabulary for features, options, interfaces, constraints and requirements;
    • separating product rules from pricing rules and document rules;
    • identifying the system of record for product structures and revisions;
    • establishing ownership for local product rules and cross-product rules;
    • testing valid, invalid, boundary and changed configurations;
    • versioning rules alongside product and engineering revisions;
    • testing ERP, PLM, PDM, CAD and CRM data exchanges;
    • measuring quote completeness, configuration errors, engineering rework and maintenance effort;
    • defining an approval path for non-standard or ETO configurations.

    Do not begin with an attempt to model every possible solution. A controlled pilot around one product family or repeatable solution type usually exposes data, ownership and integration problems earlier. The CPQ implementation guide provides a broader framework for requirements, testing, governance and maintenance.

    Semantic map

    The following relationships summarize the main entities and concepts in this article:

    • Single-product configuration → configures → one product family or engineered assembly
    • Solution configuration → coordinates → multiple configurable products
    • Configuration rules → prevent → invalid option combinations
    • Cross-product constraints → validate → subsystem interfaces
    • Product model → defines → features, options, parameters and outputs
    • Solution model → contains → product models and system-level rules
    • Configured product → can generate → product-specific BOM data
    • Solution configuration → can generate → a coordinated solution structure
    • CPQ → calculates or applies → configuration-dependent prices
    • CPQ → exchanges data with → ERP
    • CPQ → can pass parameters to → CAD automation
    • CAD automation → generates → product-specific drawings or models
    • EBOM → represents → the engineering product structure
    • MBOM → represents → the manufacturing assembly structure
    • ETO workflow → requires → engineering review for non-standard design
    • Solution configuration → supports → system-level quoting and engineering handoff

    Frequently asked questions

    What is the main difference between solution configuration and single-product configuration?

    Single-product configuration validates one product model. Solution configuration validates multiple products and the relationships between them, such as dimensional, electrical, performance and commercial interfaces.

    Is a product configurator the same as a solution configurator?

    No. A product configurator may handle one product family, while a solution configurator coordinates several product models and system-level constraints. Some CPQ platforms support both, but this must be verified.

    Can single-product configuration support complex industrial equipment?

    Yes. A single industrial machine may require extensive option rules, calculations, pricing logic and BOM generation even when it is modeled as one product.

    When does a product become a solution?

    It becomes a solution when the commercial or technical result depends on multiple products, subsystems, services or interfaces rather than on options within one product family.

    Does solution configuration always require CAD automation?

    No. CAD automation is useful when configuration must create geometry or drawings, but solution configuration can also stop at validated selections, pricing and structured engineering requirements.

    Can a CPQ system generate a solution BOM?

    Some manufacturing CPQ systems can generate configurable BOMs or solution structures, while others only create quote lines or pass selections to ERP and PLM. Buyers should verify the exact output and ownership model.

    What is a cross-product constraint?

    A cross-product constraint is a rule relating separate products or subsystems, such as requiring a selected motor, drive and control panel to use compatible voltage and load ratings.

    How does solution configuration affect pricing?

    It adds system-level pricing considerations such as package discounts, installation, commissioning, freight, engineering services and project-specific commercial assumptions.

    Is guided selling sufficient for solution configuration?

    Guided selling can help users answer requirements questions, but it does not necessarily validate engineering constraints or generate manufacturing-ready outputs.

    What is the role of ERP in solution configuration?

    ERP usually manages items, orders, inventory, purchasing, production and financial transactions. It may receive configured products, quantities, prices or BOM data from CPQ.

    What is the role of PLM in solution configuration?

    Product lifecycle management, or PLM, may manage product structures, revisions, requirements and engineering lifecycle data. It can be the authoritative source for product and engineering information.

    How do EBOM and MBOM differ in a configured solution?

    An engineering BOM describes the design structure, while a manufacturing BOM describes how the product is built. A solution may require both, along with a mapping between them.

    Can solution configuration support engineer-to-order projects?

    Yes, it can capture requirements, select reusable modules and identify non-standard conditions. However, new design work, calculations and approvals may still require engineering.

    Should product and solution rules be stored together?

    Usually, local product rules should remain with their product models, while cross-product interface rules should be maintained at the solution level. This reduces duplication and clarifies ownership.

    How should solution configuration be tested?

    Test valid combinations, invalid combinations, boundary values, interface mismatches, revision changes, pricing results, BOM outputs and integrations with ERP, PLM, CAD and related systems.

    What is the best starting point for implementing solution configuration?

    Start with one repeatable solution type, document its product models and interfaces, establish rule ownership, and test the complete flow from requirements through quote and engineering handoff.

  • Product Hierarchies and Configuration Trees in CPQ

    Product hierarchies and configuration trees are the structures that organize a configurable product inside a manufacturing CPQ system. They show how a finished product is divided into assemblies, subassemblies, components, options and selectable values, while configuration rules determine which combinations are valid.

    In a manufacturing context, a CPQ configurator uses this model to do more than present sales options. It can validate technical choices, calculate dimensions or performance, select compatible components, create a configurable bill of materials (BOM), apply costing and pricing logic, and pass approved product data to engineering, enterprise resource planning (ERP), product lifecycle management (PLM), computer-aided design (CAD) or manufacturing systems. The exact capabilities depend on the CPQ platform and its integrations.

    A well-designed hierarchy separates the product structure from the user interface, pricing and downstream production data. That separation makes the model easier to test and maintain as products, components, suppliers and manufacturing processes change.

    This guide explains how product hierarchies work, how configuration trees differ from BOMs and option lists, how rules operate across a model, and what manufacturers should consider when building and governing a CPQ product model. For broader context, see the guide to product configuration and the manufacturing CPQ guide.

    What is a product hierarchy in CPQ?

    A product hierarchy in CPQ is a structured representation of a product family and its components, assemblies, options and variants. It defines the levels at which a product can be configured and the relationships between those levels.

    For example, an industrial pump product hierarchy might contain:

    • Product family: centrifugal process pump.
    • Base model: horizontal end-suction pump.
    • Major assemblies: hydraulic end, motor, baseplate, coupling and protection system.
    • Subassemblies: impeller, casing, shaft, seal arrangement and bearing housing.
    • Options: material grade, motor voltage, seal type, mounting arrangement and instrumentation.
    • Calculated attributes: flow rate, pressure, shaft power, motor size and connection dimensions.
    • Outputs: configured product identifier, BOM lines, price, cost, drawings and order data.

    The hierarchy can represent physical structure, commercial structure, engineering structure or a combination of them. These structures do not always match. A sales option such as “corrosive service package” may select several engineering components, while one purchased component may support several commercial options.

    What is a configuration tree?

    A configuration tree is a navigable decision structure used to guide a user through the choices required to define a product. It commonly appears as a set of product levels, option groups and selections, but it may also be represented internally as a graph of related objects and rules.

    In a simple configuration tree, the user moves from a parent item to child choices:

    Industrial air-handling unit
├── Unit type
│   ├── Rooftop
│   └── Indoor
├── Airflow range
│   ├── 10,000 m³/h
│   └── 20,000 m³/h
├── Heat exchanger
│   ├── Standard coil
│   └── High-temperature coil
├── Fan assembly
│   ├── Direct drive
│   └── Belt drive
└── Controls
    ├── Basic controller
    └── Building management system interface

    The visible tree is usually only part of the model. A user may select “20,000 m³/h,” but the system may need to validate fan capacity, motor power, casing dimensions, coil selection, electrical supply and transport limits. Those relationships may cross several branches of the tree.

    For that reason, a manufacturing CPQ system should not be treated as a menu builder. The tree provides structure and sequence; the rules engine provides technical logic.

    Product hierarchy, configuration tree and product model compared

    These terms are related but not interchangeable.

    Concept Purpose Manufacturing example
    Product hierarchy Organizes products, assemblies, subassemblies and components into levels. Machine, drive system, frame, guarding and control panel.
    Configuration tree Guides the sequence and context of configuration choices. Select machine type, then capacity, motor, accessories and controls.
    Product model Contains structure, attributes, rules, calculations, references and output behavior. Defines valid pump combinations, motor sizing logic, BOM mappings and price rules.
    Option list Defines individual choices available for an attribute or feature. 304 stainless steel, 316 stainless steel or duplex stainless steel.
    Bill of materials Lists materials and components required to build a particular product or assembly. Configured pump, impeller, seal, motor, fasteners and baseplate.

    A hierarchy or tree is therefore not automatically a production BOM. The CPQ model may use a commercial hierarchy to collect selections and then transform those selections into an engineering or manufacturing structure.

    How product hierarchies work in a manufacturing CPQ model

    1. Product families and base products

    The top level usually identifies a product family, such as industrial conveyors, hydraulic power units, switchgear cabinets or mobile elevating work platforms. A family may contain several base products with different architectures.

    Choosing a base product should establish the applicable structure and rule set. A skid-mounted pump, for example, may expose baseplate and coupling choices that are not relevant to a close-coupled pump.

    2. Assemblies and subassemblies

    Assemblies divide a complex product into manageable engineering or manufacturing areas. A material handling machine might contain a frame assembly, lifting mechanism, hydraulic system, electrical cabinet, safety system and operator platform.

    Assemblies are useful because different teams may own different sections of the model. They also support modular BOM generation, reuse of common components and more targeted testing.

    3. Features, attributes and options

    A feature is a configurable characteristic or capability, such as lifting capacity or temperature rating. An attribute is a value associated with the product, such as width, voltage, material or operating pressure. An option is a selectable value or component associated with that feature.

    Some values are discrete, such as 400 V or 480 V. Others are numeric ranges, such as a conveyor length between 3 and 12 metres. Numeric inputs normally require validation rules, units of measure and engineering calculations.

    4. Optional, mandatory and conditional branches

    Each branch should have a defined selection behavior. It may be mandatory, optional, mutually exclusive, repeatable or conditionally visible. For example, a pump seal selection may be mandatory, while a spare-parts kit is optional. A hazardous-area motor may become available only when the installation classification requires it.

    5. Components and output mappings

    Leaf nodes in the hierarchy may represent saleable options, engineering components, purchased parts, documents or production instructions. A commercial option such as “washdown package” could map to stainless-steel guards, sealed bearings, a revised control enclosure and a different paint specification.

    These mappings are often critical to BOM generation. A CPQ implementation should make clear whether a node is only a sales choice, a physical component, a configurable placeholder or an instruction to generate or select another object.

    Configuration rules and constraints across the tree

    Configuration rules control how choices interact. A rule may hide an option, require another option, prohibit a combination, calculate a value, select a component or raise an engineering review.

    Common rule types include:

    • Availability rules: show or hide options based on product family, market, date or customer context.
    • Compatibility rules: prevent incompatible combinations, such as a motor that cannot be mounted to a selected pump frame.
    • Dependency rules: require one choice when another is selected, such as requiring a temperature sensor with a specific process package.
    • Exclusion rules: prevent two choices from being selected together.
    • Cardinality rules: control the minimum or maximum number of repeated components, such as one to four conveyor sections.
    • Range rules: validate dimensions, loads, pressures, temperatures or electrical values.
    • Calculation rules: derive values such as motor size, cable length, tank volume or structural reinforcement.
    • Substitution rules: select an approved component based on performance, availability or regional requirements.
    • Workflow rules: route a configuration to engineering approval when it exceeds standard product limits.

    Rules can be local to one branch or cross the entire model. A local rule may state that a particular seal is compatible with a casing material. A cross-tree rule may state that the total machine width cannot exceed a transport limit after the frame, guarding and accessory dimensions are combined.

    Rules-based configuration, constraint-based configuration and guided selling

    Manufacturers should distinguish three related approaches.

    Approach How it works Typical use
    Rules-based configuration Explicit if-then logic determines availability, dependencies and exclusions. If voltage is 480 V, restrict control transformer choices to approved variants.
    Constraint-based configuration The system evaluates limits and relationships across variables, often solving for valid values. Ensure pump flow, head, impeller diameter and motor power remain within technical limits.
    Guided selling The user answers business or application questions and the system recommends suitable products or paths. Recommend a valve family based on media, pressure, temperature and connection type.

    These methods can coexist. Guided selling may select a product family, rules may control available options, and constraint logic may validate dimensions or performance. A basic CPQ configurator may support only simple dependencies, while a deeper manufacturing configuration platform may also support calculations, constraint solving or engineering automation. Buyers should verify the actual capabilities of each system.

    Relationship between the configuration tree and the BOM

    A bill of materials is a structured list of components required to build or service a product. CPQ may produce several BOM-related outputs, but the configuration tree is not necessarily identical to any of them.

    Configurable BOM

    A configurable BOM contains alternatives, rules, optional items or placeholders that are resolved when a product is configured. It may represent the reusable engineering logic for a product family.

    EBOM

    An engineering bill of materials, or EBOM, represents the product from an engineering perspective. It may reflect design assemblies, CAD references, revision-controlled parts and engineering ownership.

    MBOM

    A manufacturing bill of materials, or MBOM, represents how the product is built. It may group components by operation, workstation, plant or production sequence and can differ from the EBOM.

    For example, a CPQ tree for a hydraulic power unit may select reservoir size, pump type, motor, valve block and instrumentation. The resulting EBOM may contain design assemblies, while the MBOM may add hose kits, installation kits, labels and work instructions required at particular manufacturing stages.

    Whether CPQ generates an EBOM, MBOM, configurable BOM or only a sales-level structure depends on the product model and system architecture. Some organizations use CPQ to create a preliminary structure and rely on PLM or ERP to create the authoritative production BOM.

    See the guide to BOM generation, pricing and quoting for a deeper discussion of these outputs.

    How hierarchies support pricing, costing and quoting

    Product hierarchy provides the context for pricing and costing, but configuration and pricing remain separate concerns.

    A selected motor may add a component cost and a customer price. A larger frame may change material cost, labour assumptions, freight classification and engineering effort. A custom coating may add both a purchased service and a production operation. The price model must define whether these values are inherited from a parent assembly, calculated from attributes or supplied by an external system.

    Common pricing relationships include:

    • base price plus option surcharges;
    • quantity or length-based pricing;
    • cost-plus margin calculations;
    • customer, channel or regional price lists;
    • currency, tax and commercial-term adjustments;
    • engineering or non-standard configuration charges;
    • discount and approval thresholds.

    A technically valid configuration is not automatically commercially valid. The CPQ workflow may need to check minimum margins, obsolete components, supplier restrictions or approval requirements before producing a quote.

    CAD, engineering calculations and product hierarchies

    In engineering-led manufacturing, configuration choices may drive CAD parameters, calculations and drawings. For example, selecting a tank diameter and nozzle arrangement may change the model dimensions, support structure, insulation panels and fabrication drawings.

    A CPQ system may pass configuration values to a CAD or engineering automation process, which then generates product-specific geometry, drawings or documentation. However, CAD automation is not a default feature of every CPQ product. It may require a separate design automation tool, custom integration or engineering service.

    Important data relationships can include:

    • configuration attributes mapped to CAD parameters;
    • selected components mapped to approved CAD parts;
    • calculated dimensions passed to drawing templates;
    • engineering results used to select a component or trigger review;
    • revision and effectivity data synchronized with PLM or product data management (PDM) systems.

    CAD output should not be generated from an ungoverned sales tree. The model must identify which values are design-defining, which are commercial only and which require engineering confirmation. More detail is available in the CAD and engineering automation guide.

    Example: configuration tree for an industrial pump

    Consider a configurable centrifugal pump used in chemical processing.

    1. Select the pump family and hydraulic arrangement.
    2. Enter required flow, head, fluid temperature and specific gravity.
    3. Select casing and wetted-part materials.
    4. Select seal arrangement based on fluid, temperature and pressure.
    5. Select motor voltage, frequency, enclosure and hazardous-area classification.
    6. Choose mounting, baseplate, coupling guard and instrumentation.
    7. Calculate or validate impeller diameter, shaft power and motor size.
    8. Generate a configured product identifier, price, cost estimate and BOM.
    9. Route non-standard duty points or material combinations to engineering review.

    Some dependencies cross the hierarchy. Fluid temperature affects seal selection and material compatibility. Flow and head affect hydraulic selection and motor size. Motor size affects baseplate dimensions and electrical documentation. Hazardous-area classification affects motor, instrumentation and enclosure choices.

    The resulting product hierarchy may be used for navigation, while the rules and calculations determine the technically valid configuration. The output may include a sales quote, a configurable BOM, an engineering review package and data for ERP or PLM.

    Configuration trees and CTO, ETO, MTO and ATO workflows

    Configuration trees support several manufacturing operating models, but they support them in different ways.

    • Configure-to-order (CTO): the customer selects from a predefined product model and approved combinations. The tree and rules should resolve to repeatable components and processes.
    • Engineer-to-order (ETO): the product requires new or modified engineering. The tree may capture requirements and standard modules, then trigger calculations, CAD work or engineering approval.
    • Make-to-order (MTO): production begins after an order, but the product may use a standard or configured design. CPQ can supply the order-specific structure and requirements.
    • Assemble-to-order (ATO): standard modules are assembled after an order. The hierarchy should map selections to available modules, inventory items and assembly instructions.

    A configuration tree should therefore identify where standard logic ends and human engineering begins. If every unusual request is forced into a large collection of exceptions, the model may become difficult to govern.

    See the manufacturing workflow guide for more on CTO, ETO, MTO and ATO processes.

    Architecture and enterprise-system relationships

    Product hierarchy data may be distributed across several systems:

    System Typical responsibility Possible CPQ relationship
    CRM Customer, opportunity and account information. Provides sales context and receives quote status or configured product details.
    ERP Items, inventory, purchasing, costing, orders and production transactions. Receives orderable items, prices, BOM references or order data.
    PLM Product definitions, revisions, approvals and lifecycle governance. Provides approved product structures, options or revisions.
    PDM CAD files, documents and product data management. Stores or references design files and revision-controlled documents.
    CAD Parametric geometry, assemblies and drawings. Receives configuration parameters or provides design references.
    PIM Product information, descriptions, attributes and content. Supplies commercial descriptions and channel-facing information.
    MES Manufacturing execution, operations and shop-floor information. May receive production-relevant configuration or work instructions.

    These systems are not interchangeable. A CPQ hierarchy should have clear ownership rules. For example, PLM may own engineering revisions, ERP may own orderable item codes and CPQ may own interaction logic. The integration design should specify which system is authoritative for each attribute, component, revision and status.

    Read the CPQ integration guide for architecture and data-exchange considerations.

    Benefits of a well-designed configuration hierarchy

    • More reliable configuration: incompatible combinations can be blocked before quotation or order entry.
    • Faster sales engineering: users work from approved product logic instead of repeatedly checking spreadsheets and catalogues.
    • Consistent downstream data: the configured result can provide a common basis for pricing, BOMs, drawings and orders.
    • Reusable product modules: shared assemblies and rules can be reused across product families.
    • Improved change control: owners can identify which branches, rules and outputs are affected by a product change.
    • Better customer guidance: the interface can present relevant choices in a logical sequence.
    • Clearer exception handling: configurations outside standard limits can be routed to engineering rather than silently accepted.

    Limitations and common failure modes

    Overloading the tree with every rule

    A tree is useful for structure and navigation, but not every relationship belongs in the visible hierarchy. Cross-branch dependencies should be implemented and documented as rules or constraints rather than represented through excessive nesting.

    Confusing commercial options with physical parts

    A customer-facing package may select multiple components, operations and documents. Treating the package as one physical item can produce incomplete BOMs or unclear manufacturing instructions.

    Duplicating product logic across systems

    If the same compatibility rule exists separately in CPQ, ERP, PLM and CAD without ownership or synchronization, the systems can disagree. A governance model should define where each rule is maintained and how changes are propagated.

    Creating too many exceptions

    Repeated exceptions often indicate that the standard product model is poorly defined or that ETO requirements are being forced into a CTO structure. Exception categories, approval paths and engineering handoffs should be explicit.

    Ignoring effectivity and revision

    Components and rules can change by date, plant, market, certification, supplier or product revision. A configuration that was valid last year may not be valid for a current order. Effectivity and revision behavior must be tested.

    Using descriptions as identifiers

    Names and descriptions can change for commercial reasons. Stable internal identifiers, revision references and controlled mappings are more suitable for integrations and BOM generation.

    Implementation approach for product hierarchies

    1. Define the product scope: identify the product families, markets, plants and workflows included in the first release.
    2. Document the physical and commercial structures: compare sales options, engineering assemblies, EBOM structures and MBOM requirements.
    3. Classify configuration data: separate features, attributes, options, calculations, constraints, components, documents and approval triggers.
    4. Identify rule ownership: assign responsibility to product management, engineering, manufacturing, pricing or another accountable team.
    5. Model standard paths first: implement common CTO and ATO configurations before adding rare exceptions.
    6. Define output contracts: specify what CPQ sends to quoting, ERP, PLM, CAD, PDM or MES and in what format.
    7. Build test cases: include valid combinations, invalid combinations, boundary values, revisions, substitutions, missing data and exception routes.
    8. Validate with engineering and production: confirm that selected components, quantities, documents and calculations reflect how the product is actually built.
    9. Introduce governance: establish change requests, approvals, release processes, regression testing and model ownership.

    Implementation guidance should cover product data migration, testing, deployment and ongoing maintenance. The CPQ implementation guide provides a broader framework.

    How to keep a configuration tree maintainable

    • Use consistent names and identifiers for product families, assemblies, features and options.
    • Keep commercial labels separate from technical identifiers.
    • Group options by engineering or customer decision rather than by the order in which they were historically added.
    • Document rule intent, not only rule syntax.
    • Prefer reusable rules and modules over copied logic.
    • Use units, ranges and precision explicitly for numeric attributes.
    • Record rule owners and affected outputs.
    • Test product revisions and effectivity dates.
    • Measure invalid configurations, engineering overrides, model defects and quote rework.
    • Review unused, obsolete and duplicate options regularly.

    Maintainability is especially important when product knowledge is distributed across application engineers, product managers, sales engineers and manufacturing specialists. A model that only one developer understands is a business risk, even if it produces correct results.

    How to evaluate a CPQ configurator’s hierarchy capabilities

    When evaluating software, ask vendors to demonstrate a real manufacturing scenario rather than a simple product bundle. Useful demonstration requirements include:

    • multiple assembly levels and reusable subassemblies;
    • numeric dimensions and engineering constraints;
    • cross-branch dependencies;
    • optional, mandatory, repeatable and mutually exclusive components;
    • revision and effectivity handling;
    • configuration of standard and engineered products;
    • configurable BOM output and distinction between EBOM and MBOM;
    • price and cost changes driven by configuration;
    • engineering approval for non-standard combinations;
    • integration with ERP, CRM, PLM, PDM or CAD where required;
    • API access and support for external product data;
    • testing, versioning, audit history and role-based model governance.

    Do not assume that a platform’s ability to display a nested option list means it supports deep product modeling. Verify how it stores rules, evaluates constraints, handles calculations, manages revisions and produces downstream data. A vendor comparison should distinguish documented capabilities from planned, partner-provided or custom-developed functionality. Relevant selection resources are available in the manufacturing CPQ comparisons guide and CPQ software profiles.

    Semantic map

    The following relationships summarize how product hierarchies and configuration trees connect manufacturing CPQ concepts.

    • CPQ configurator → organizes → configurable product models
    • Product hierarchy → contains → assemblies and subassemblies
    • Configuration tree → guides → product selections
    • Configuration rules → prevent → invalid combinations
    • Constraints → validate → technical limits
    • Configured product → generates → configuration-specific BOM data
    • Configurable BOM → resolves into → selected components and quantities
    • Product attributes → drive → engineering calculations
    • Configuration values → parameterize → CAD automation
    • Configured product → determines → price and cost
    • CPQ → exchanges data with → ERP
    • CPQ → integrates with → PLM and PDM
    • Engineering exception → triggers → approval workflow
    • Configuration model → supports → configure-to-order
    • Configuration model → initiates → engineer-to-order handoff

    Frequently asked questions

    What is a product hierarchy in CPQ?

    A product hierarchy is the structured organization of a configurable product into families, models, assemblies, subassemblies, components and options. In manufacturing CPQ, it provides the context for rules, pricing, BOM generation and engineering outputs.

    What is a configuration tree?

    A configuration tree is a structured path through product choices. It guides users from a product family or base model to the options, values and components required to define a valid configuration.

    Is a configuration tree the same as a BOM?

    No. A configuration tree guides selections, while a BOM lists components required to build or service a product. A CPQ model may transform tree selections into a configurable BOM, EBOM, MBOM or another downstream structure.

    How does a CPQ configurator use a product hierarchy?

    It uses the hierarchy to present relevant choices, apply rules, calculate values, validate compatibility and create outputs such as prices, quotes, BOM references or engineering requests.

    What is the difference between a product hierarchy and a product model?

    The hierarchy describes the product structure. The product model is broader and may include the hierarchy, attributes, rules, calculations, revisions, output mappings and workflow behavior.

    Can a configuration tree contain multiple assembly levels?

    Yes. Industrial machines commonly require several levels, including the finished machine, major assemblies, subassemblies and individual components. The model should balance detail with maintainability.

    What are cross-branch configuration rules?

    Cross-branch rules connect choices in different parts of the tree. For example, a hazardous-area selection may restrict the motor, instrumentation, enclosure and documentation branches.

    How are technical constraints different from configuration rules?

    Rules often express explicit relationships such as requires or excludes. Constraints describe limits or relationships that must be satisfied, such as maximum load, pressure, temperature, dimension or power.

    Can product hierarchies support engineer-to-order products?

    Yes, but the hierarchy should identify which selections are standard and which trigger engineering work. ETO workflows may use CPQ to capture requirements before CAD, calculation, design approval or manual BOM work.

    How does a hierarchy affect pricing?

    It provides the context for base prices, option surcharges, quantity-based calculations, component costs, engineering charges and approval thresholds. Pricing logic should remain distinguishable from technical configuration logic.

    How does a configuration tree support BOM generation?

    Selections in the tree can map to components, quantities, substitutes, assemblies or production instructions. The result may be a configurable BOM or a resolved configuration-specific BOM, depending on the system design.

    Can one commercial option map to several components?

    Yes. A package such as a washdown or hazardous-area package may map to several physical components, documentation requirements and manufacturing operations.

    What is the role of PLM in a product hierarchy?

    Product lifecycle management, or PLM, may own approved product structures, revisions, effectivity and engineering change information. CPQ can consume or reference that data, but ownership depends on the architecture.

    What is the role of ERP in a configuration model?

    Enterprise resource planning, or ERP, commonly manages items, inventory, purchasing, costing, orders and production transactions. CPQ may send orderable item data, prices, BOM references or configuration details to ERP.

    Does every CPQ system generate CAD drawings?

    No. CAD automation may be native, integrated through another tool or unavailable. Buyers should verify whether a platform supports CAD parameters, drawings, engineering calculations and revision-controlled design outputs.

    How should manufacturers test a configuration tree?

    Testing should cover valid and invalid combinations, boundary values, missing data, revisions, substitutions, pricing changes, BOM outputs, integration messages and engineering exception routes.

    Who should own a product hierarchy?

    Ownership is usually shared. Product management may own commercial structure, engineering may own technical rules, manufacturing may own production implications and IT or CPQ administrators may manage implementation. Responsibilities should be documented.

    What makes a configuration tree difficult to maintain?

    Common causes include duplicated rules, unclear ownership, excessive exceptions, copied logic, inconsistent identifiers, missing revision control and confusion between commercial options and physical components.

    Should every product option appear in the customer-facing tree?

    No. Some technical selections can be derived automatically, hidden behind a package, controlled by engineering or maintained in downstream systems. The visible tree should expose the decisions users need to make.

    How do product hierarchies support configure-to-order manufacturing?

    They organize approved modules and options so that standard configurations can be validated and translated into repeatable BOM, pricing and production data with limited engineering intervention.

  • Option Dependencies in Complex Product Configuration

    Option dependencies are relationships between configurable product choices. They determine whether options are compatible, required, excluded, conditionally available or automatically added when a user selects another option. In manufacturing Configure, Price, Quote (CPQ), these dependencies are used to validate products such as industrial machines, pumps, HVAC units, electrical assemblies and specialty vehicles before a quote reaches engineering or production.

    A manufacturing CPQ configurator does more than display a list of features. It applies product rules to dimensions, materials, performance requirements, components, manufacturing methods and commercial choices. For example, selecting a high-temperature pump seal may require a particular shaft material, exclude a standard elastomer and change the allowable operating range. The result may affect the configurable bill of materials (BOM), engineering calculations, cost, price, drawings and the manufacturing workflow.

    This guide explains how option dependencies work, how they are represented in a product model, how they differ from related rule types, and how manufacturers can implement them without creating an unmaintainable collection of exceptions.

    What are option dependencies?

    An option dependency is a rule that defines a relationship between two or more product options, attributes or configuration decisions. The relationship may require an option, prohibit a combination, suggest a choice, change a value or trigger an additional component.

    In a simple example, a pump product may contain these options:

    • Pump size: 50 mm, 80 mm or 100 mm
    • Impeller material: cast iron, stainless steel or duplex stainless steel
    • Motor type: standard efficiency or high efficiency
    • Seal package: standard, chemical-duty or high-temperature
    • Control panel: none, local starter or variable frequency drive

    The product model can express dependencies such as:

    • If the chemical-duty seal is selected, stainless steel or duplex wetted parts are required.
    • If the high-temperature seal is selected, the maximum operating temperature must be within the seal rating.
    • If a variable frequency drive is selected, a compatible motor and control enclosure are required.
    • If the 100 mm pump size is selected, the standard motor option is unavailable because the required power exceeds its rating.
    • If the pump is configured for a hazardous location, the control panel and motor certifications must be compatible.

    These are not merely sales recommendations. They can represent engineering constraints, safety requirements, manufacturing choices, compliance requirements or commercial policies.

    Why option dependencies matter in manufacturing CPQ

    Generic sales CPQ may use dependencies to control product bundles or pricing. Manufacturing CPQ typically needs a deeper model. A valid configuration must often be physically buildable, technically safe, serviceable, costed correctly and transferable to downstream systems.

    An invalid combination can create several problems:

    • Sales quotes a product that cannot meet the customer specification.
    • Engineering must manually correct the configuration after order entry.
    • The generated BOM contains incompatible or missing components.
    • A computer-aided design (CAD) model or drawing uses the wrong dimensions.
    • Material, motor, voltage or pressure selections violate product limits.
    • Cost and price are calculated from the wrong product variant.
    • Enterprise resource planning (ERP) receives an incomplete or incorrect manufacturing structure.

    Dependencies move validation closer to the point where the product is specified. They do not eliminate engineering review in every case, particularly for engineer-to-order work, but they reduce avoidable errors and make the handoff more structured.

    See the product configuration guide for a broader explanation of product models, features, options, constraints and validation.

    Core types of option dependencies

    Requires dependencies

    A requires rule states that selecting one option requires another option, value or component. For example, selecting a 400-volt three-phase motor may require a control panel rated for that electrical configuration.

    Requires rules can apply to visible selections or hidden product data. A customer may select a high-pressure option, while the product model automatically requires a reinforced casing, a particular gasket material and a higher-rated fastener set.

    Excludes dependencies

    An excludes rule prevents two options from being selected together. A standard aluminum housing may be excluded when a corrosive chemical application is selected. A manual control system may be excluded when a fully automated safety package is required.

    Exclusions should be used for genuine incompatibilities. Overusing them to hide uncertain or poorly documented product knowledge can make the model difficult to understand and maintain.

    One-of and mutually exclusive dependencies

    Some option groups allow exactly one choice. A machine may require one drive type: hydraulic, electric or pneumatic. Other groups may allow several choices but prevent particular pairs. For example, a vehicle may allow several accessory packages but exclude two packages that occupy the same mounting location.

    At-least-one and conditional-required dependencies

    An at-least-one rule requires a selection from a group. A machine may require at least one discharge connection, communication protocol or safety device. A conditional-required rule applies only in a specific context. For example, a remote monitoring module may be required if the customer selects a cloud-connected service, but not for a locally controlled machine.

    Value and range dependencies

    Some relationships concern numeric or dimensional values rather than discrete options. A conveyor length may be allowed only within a range supported by the selected frame size. A pressure vessel diameter may limit wall thickness, material grade or allowable pressure.

    Range rules are important because many engineered products cannot be represented accurately using only yes-or-no options. The model may need formulas such as:

    Maximum flow = function of impeller diameter, speed and pressure requirement

    The exact implementation varies by CPQ platform. Some systems support formulas, constraints or external calculation services; others require custom logic or integration with engineering applications.

    Default, recommended and suggested dependencies

    A default sets an initial value but may allow the user to change it. A recommendation guides the user without necessarily preventing a choice. These rules are different from hard constraints.

    For example, a stainless steel fastener set may be recommended for an outdoor machine, while a particular fastener may be mandatory for a marine application. A recommendation supports guided selling; a mandatory rule protects product validity.

    Conditional visibility dependencies

    Visibility rules show or hide options based on earlier decisions. Selecting a diesel engine may expose fuel-system options, while selecting an electric drive exposes voltage and battery options. Visibility improves usability, but hiding an option is not the same as validating a configuration. The underlying model still needs explicit rules for compatibility and completeness.

    Automatic inclusion and substitution dependencies

    A selection may automatically add a component or substitute one component for another. Selecting a high-temperature package could add insulation, a different seal and a temperature sensor to the configurable BOM. Selecting a premium controller could replace a standard controller and change the wiring harness.

    These rules must be connected carefully to item masters, revision control and BOM logic. Otherwise, the customer-facing selection may appear correct while the downstream manufacturing structure remains incomplete.

    How dependencies fit into a product model

    A product model represents the configurable structure of a product. It usually contains attributes, option groups, allowed values, rules, calculations, components, documents and outputs. Dependencies are one layer of this model rather than the entire model.

    Product-model element Purpose Manufacturing example
    Feature or attribute Describes a product characteristic Flow rate, voltage, frame size or material
    Option Represents a selectable value or component choice Duplex impeller or 480-volt motor
    Dependency Controls relationships between choices High pressure requires reinforced casing
    Calculation Derives a value from selections Required motor power from flow and head
    Component mapping Links configuration choices to items Selected seal maps to a specific item number
    Output rule Controls documents or downstream data Generate a drawing variant or manufacturing note

    A useful model separates product knowledge into layers. Commercial rules control what can be sold or under which conditions. Engineering rules control technical feasibility. Manufacturing rules control how the product is built. Pricing rules calculate cost, margin and customer price. Integration mappings transfer the result to systems such as ERP, product lifecycle management (PLM), product data management (PDM), CAD or manufacturing execution systems (MES).

    Keeping these concerns distinguishable makes testing and ownership easier. A rule that says a premium coating adds cost is not the same as a rule that says a premium coating requires a compatible substrate.

    Rules-based, constraint-based and guided configuration

    Rules-based configuration

    Rules-based configuration uses explicit statements such as if-then conditions, requires rules, exclusions and decision tables. It is often effective for discrete product families with well-defined combinations.

    Example: if enclosure rating is IP66, then the standard ventilation option is unavailable and a sealed cooling option is required.

    Constraint-based configuration

    Constraint-based configuration describes permitted relationships and lets a solver determine whether a combination is valid. It is useful when many variables interact, especially dimensions, capacities, performance limits and mutually dependent engineering values.

    Example: the selected pump must satisfy the requested flow and pressure while remaining within limits for speed, impeller diameter, motor power and material.

    Guided selling

    Guided selling asks questions and recommends suitable choices based on customer needs. It may use dependencies, but it is not a substitute for a technical rules engine. A guided question such as “Is the machine used outdoors?” may recommend a weatherproof enclosure. The product model still needs to validate whether that enclosure is compatible with the selected voltage, cooling method and certification.

    Manufacturers should identify which rules are advisory, which are blocking and which require engineering review.

    Dependencies across engineering, BOM and pricing

    Option dependencies often have consequences beyond the configuration screen.

    Engineering calculations and CAD

    Selections may provide inputs to engineering calculations. A selected span, load, pressure, flow rate or operating temperature can determine dimensions, component ratings or material requirements. If the CPQ system connects to CAD automation, the same selections may drive a parametric model, drawing, specification sheet or 3D representation.

    However, a CPQ platform should not be assumed to provide CAD automation or engineering calculations. Buyers need to verify whether these capabilities are native, delivered through an integration or handled by a separate engineering application. The CAD and engineering automation guide explains these architectural choices.

    Configurable BOM, EBOM and MBOM

    A configurable BOM is a rule-driven structure that resolves into a product-specific list of components. An engineering bill of materials (EBOM) describes the product from an engineering perspective. A manufacturing bill of materials (MBOM) describes how the product is assembled or produced, including manufacturing-specific groupings, operations or consumables.

    A dependency can affect all three. Selecting a different motor may change the EBOM component, the MBOM assembly sequence and the purchased-item cost. The CPQ output may be a sales or engineering structure that ERP later transforms into a manufacturing structure. It is important to define which system owns each BOM and how revisions are synchronized.

    Costing and pricing

    A dependency may add or remove cost, change labor content, alter a supplier item or trigger an approval threshold. For example, a stainless steel option may change material cost, machining time and lead time. A hazardous-location package may require certified components and additional inspection.

    Pricing logic should not be confused with technical validity. A zero-price option may still be required for engineering reasons, and a priced option may be technically interchangeable with another option. Separating configuration rules from pricing rules helps prevent commercial changes from silently changing product validity.

    Related outputs such as BOMs, costing and quote documents are covered in the BOM, pricing and quoting guide.

    Manufacturing example: configurable air-handling unit

    Consider an air-handling unit configured for a commercial building. The user selects airflow, external static pressure, installation environment, heating method, cooling method, filtration level, casing material and controls.

    Several dependencies interact:

    • A higher airflow range requires a larger fan section and may exceed the selected casing width.
    • A coastal installation may require corrosion-resistant casing and fasteners.
    • A high-efficiency filter increases pressure drop and may require a larger fan motor.
    • Electric heating requires an electrical supply and control panel with sufficient capacity.
    • A heat recovery wheel may require a minimum unit width and maintenance clearance.
    • A selected building-management-system protocol may require a compatible controller and communication module.

    The product model should validate the configuration, calculate or retrieve the required fan duty, resolve components, calculate cost and produce a quote. Depending on the system architecture, it may also generate a selection report, CAD layout or manufacturing BOM. If the requested airflow and pressure fall outside the standard product envelope, the configuration can be routed to an engineer-to-order (ETO) process rather than rejected without explanation.

    Dependencies in CTO, ETO, MTO and ATO workflows

    Configure-to-order (CTO) uses predefined options and rules to produce a product from an established family. Dependencies are usually designed to prevent invalid combinations while allowing controlled variation.

    Engineer-to-order (ETO) involves engineering work for requirements that are not fully covered by the standard model. Dependencies can identify when a configuration leaves the standard envelope, collect the engineering inputs and create a structured handoff.

    Make-to-order (MTO) means production starts after an order is received, while assemble-to-order (ATO) generally uses stocked modules assembled after the order. In ATO, dependencies may determine which modules can be combined. In MTO, they may control material, routing and production-specific requirements.

    These workflows should not be treated as interchangeable. A rule that is sufficient for CTO may be inadequate for ETO, where the system must also manage engineering tasks, assumptions, approvals and revised outputs. See the manufacturing workflows guide for more detail.

    Designing maintainable option dependencies

    Use a controlled vocabulary

    Define consistent names for features, options, values, components and rule types. Avoid creating separate rules for synonyms such as high temperature, high-temp and elevated-temperature unless they represent genuinely different technical conditions.

    Separate product families and validity periods

    A rule for one pump family may not apply to another. Product revisions, supplier changes and regulatory updates can also change dependencies. The model should support effective dates, revisions or another controlled method for identifying which rules apply.

    Prefer reusable constraints over duplicated exceptions

    If five product families share the same motor-voltage relationship, represent the common logic once where the platform permits it. Duplicated rules are likely to diverge when a component or standard changes.

    Make rule ownership explicit

    Engineering may own pressure and material constraints. Product management may own commercial packaging. Manufacturing engineering may own routing or assembly rules. IT or a CPQ administrator may implement the logic, but implementation ownership should not be confused with product knowledge ownership.

    Explain why a configuration is invalid

    A message such as “invalid selection” is less useful than “The selected 100 kW motor cannot be used with the 200 mm pump because the required shaft and coupling assembly are not supported.” Clear explanations help sales engineers resolve issues and expose gaps in the product model.

    Manage exceptions deliberately

    Some customers require deviations from standard rules. An exception process should identify who approves the deviation, what engineering evidence is required, how the quote is marked and whether the exception becomes a new standard option. Allowing users to bypass rules without traceability undermines the purpose of configuration validation.

    Testing option dependencies

    Testing should cover individual rules, interactions and downstream outputs. A rule may work alone but fail when combined with dimensions, revisions, pricing or BOM mappings.

    Test area Example test
    Positive configuration A valid pump, motor, seal and voltage combination is accepted
    Negative configuration An incompatible motor and enclosure combination is blocked
    Boundary values Maximum flow and pressure limits are handled correctly
    Rule interaction High temperature plus hazardous location produces the correct requirements
    Revision behavior A discontinued component is unavailable after its effective date
    BOM resolution Required components and substitutions appear in the correct structure
    Pricing Material, labor and surcharge effects are calculated correctly
    Integration ERP, PLM or CAD receives the correct identifiers and attributes
    User explanation Blocked choices provide an actionable reason

    Manufacturers should maintain a test set of representative products, edge cases and historical configurations. Automated regression testing is particularly valuable when a shared rule affects multiple product families.

    Common limitations and failure modes

    • Rule sprawl: Hundreds of local exceptions make the model hard to review and slow to change.
    • Conflicting ownership: Sales, engineering and manufacturing may encode different interpretations of the same product rule.
    • Hidden dependencies: A rule exists in a spreadsheet, CAD macro or employee knowledge but not in the central product model.
    • Overly broad options: A single option represents several technical variants, making downstream mapping ambiguous.
    • Weak error messages: Users cannot determine how to correct an invalid configuration.
    • Uncontrolled overrides: Users bypass rules to close orders, transferring risk to engineering and production.
    • Disconnected outputs: The configuration is valid in CPQ but produces an incomplete BOM or incorrect CAD output.
    • Unmanaged changes: Component revisions or supplier substitutions are not reflected in the dependency model.

    CPQ is not a replacement for product governance. If source data, item identifiers, revisions and engineering decisions are inconsistent, a rules engine will reproduce those inconsistencies more quickly.

    Implementation approach

    1. Map the product family: Document features, options, dimensions, components, calculations, outputs and known invalid combinations.
    2. Classify the rules: Separate technical constraints, commercial rules, manufacturing rules, pricing logic and recommendations.
    3. Identify authoritative systems: Decide whether item, revision, engineering or manufacturing data comes from ERP, PLM, PDM, CAD or another source.
    4. Model the standard envelope: Define what can be configured without engineering intervention and what triggers ETO review.
    5. Build a small representative model: Test the model with real configurations, including difficult combinations and boundary values.
    6. Map outputs: Verify configurable BOMs, EBOM or MBOM structures, pricing, documents, CAD parameters and integration payloads.
    7. Establish governance: Define change requests, approvals, release procedures, ownership and audit history.
    8. Measure maintenance: Track rule defects, engineering corrections, quote rework, invalid configurations and time required to release product changes.

    The implementation architecture may include CPQ, customer relationship management (CRM), ERP, PLM, PDM, CAD, product information management (PIM) and MES. These systems have different responsibilities. CRM manages customer and opportunity context; ERP manages transactions and enterprise resources; PLM manages product lifecycle information; PDM manages design files and metadata; CAD creates design geometry; PIM manages product information for distribution; and MES supports execution on the factory floor. A CPQ implementation should define the data flow rather than assume that one system owns everything.

    The CPQ integrations guide and CPQ implementation guide provide related guidance on architecture, migration, testing and governance.

    Semantic map

    The following relationships summarize the main entities discussed in this guide:

    • CPQ configurator → applies → product configuration rules
    • Option dependencies → control → compatible product choices
    • Configuration rules → prevent → invalid combinations
    • Constraint-based configuration → validates → engineering limits
    • Guided selling → recommends → suitable product options
    • Configured product → resolves into → product-specific BOM
    • Configured product → supplies inputs to → engineering calculations
    • CAD automation → generates → product-specific drawings
    • Configuration choices → influence → cost and price
    • EBOM → represents → engineering product structure
    • MBOM → represents → manufacturing product structure
    • CPQ → exchanges data with → ERP
    • CPQ → can integrate with → PLM and PDM
    • ETO trigger → routes → non-standard configuration to engineering
    • Product governance → maintains → rules and revisions

    Frequently asked questions

    1. What is an option dependency in CPQ?

    An option dependency is a rule that defines how one product choice affects another choice, value, component, calculation or output. It may require, exclude, recommend or automatically add an option.

    2. What is a manufacturing example of an option dependency?

    Selecting a high-temperature seal on a pump may require a compatible shaft material, exclude a standard elastomer and add a temperature-rated component to the BOM.

    3. Are option dependencies the same as configuration rules?

    Option dependencies are one type of configuration rule. Configuration rules also include calculations, defaults, range limits, document triggers, BOM mappings and workflow conditions.

    4. What is the difference between a requires rule and an excludes rule?

    A requires rule makes another option or value necessary. An excludes rule prevents two options or values from being used together.

    5. Can dependencies apply to dimensions and numeric values?

    Yes. Rules can limit ranges or define relationships between dimensions, capacities, pressure, speed, load, voltage and other engineering variables.

    6. Do option dependencies generate a BOM?

    They can contribute to BOM generation by adding, removing or substituting components, but not every CPQ platform generates BOMs. The capability and resulting BOM type must be verified for the selected system.

    7. How do dependencies affect pricing?

    A dependency may add material, labor, supplier or certification costs. Technical validity and pricing should remain distinct even when both are driven by the same selection.

    8. Can dependencies drive CAD automation?

    They can provide parameters or selections to CAD automation when the CPQ architecture supports that integration. CPQ should not be assumed to include CAD generation natively.

    9. What happens when a configuration is outside the standard rules?

    The system can block it, request additional information, allow a controlled override or route it to an engineer-to-order workflow. The appropriate behavior depends on product risk and company policy.

    10. How are option dependencies tested?

    Test valid and invalid combinations, boundary values, rule interactions, revisions, BOM resolution, pricing, integrations and user-facing explanations.

    11. Who should own option dependencies?

    Product and engineering teams should own the underlying product knowledge. CPQ administrators or developers may implement it, while manufacturing and commercial teams should own relevant downstream and pricing rules.

    12. How can manufacturers prevent rule sprawl?

    Use controlled vocabularies, reusable constraints, clear product-family boundaries, explicit ownership, version control and periodic reviews of duplicate or obsolete rules.

    13. Are recommendations the same as hard constraints?

    No. A recommendation guides the user but may be overridden. A hard constraint prevents a technically or commercially invalid combination.

    14. How do option dependencies affect an EBOM and MBOM?

    A selected option may change the engineering structure, the manufacturing structure or both. The implementation should define which system creates and owns each structure.

    15. Can dependencies support configure-to-order products?

    Yes. CTO products commonly use dependencies to validate predefined options and resolve a standard product variant.

    16. Can dependencies support engineer-to-order products?

    Yes, but they normally need to identify the boundary of standard configuration and trigger engineering review rather than pretending every design can be fully automated.

    17. Why are clear validation messages important?

    They tell sales engineers what must change and expose the reasoning behind a rule. This reduces trial and error and helps users trust the configurator.

    18. What enterprise systems are commonly related to option dependencies?

    Depending on the architecture, dependencies may exchange data with CRM, ERP, PLM, PDM, CAD, PIM or MES. These systems are complementary and should not be treated as interchangeable.

    19. Should all product knowledge be stored in CPQ?

    No. CPQ should use authoritative product and engineering data from the appropriate systems while managing the configuration logic required for a valid quote and downstream handoff.

    20. What is the first step in implementing option dependencies?

    Start by documenting a representative product family, its options, engineering limits, invalid combinations, component mappings, pricing effects and non-standard cases before selecting or building rules.

  • Multi-Product Configuration in CPQ: Rules, Architecture and Manufacturing Workflows

    Multi-product configuration in CPQ is the process of configuring two or more related products, assemblies or equipment packages as one connected solution. Instead of validating each product independently, the CPQ system evaluates relationships between products, shared options, technical interfaces, quantities, pricing and downstream manufacturing data.

    For example, a manufacturer may need to configure a pump, motor, baseplate, control panel and piping package in a single quotation. Each item has its own product model, but the complete solution must also satisfy system-level rules: the motor must match the pump load, the baseplate must fit the selected equipment, the control panel must support the voltage and starter type, and the quoted assembly must produce compatible bills of material and engineering outputs.

    Multi-product configuration is therefore more than placing several products on a quote. It is a coordinated configuration model that connects product-level rules with cross-product constraints. In manufacturing CPQ, it can support system selling, equipment packages, machine lines, vehicle bodies with chassis options, HVAC systems, electrical panels with connected devices and other engineered-to-order or configure-to-order solutions.

    See the guide to product configuration for the fundamentals of options, features, dependencies and validation. Multi-product configuration extends those concepts across product boundaries.

    What is multi-product configuration?

    Multi-product configuration is a CPQ capability that lets users select and validate multiple configurable products within one related configuration, project, quote or solution. The products may be sold together, installed together, operated together or manufactured as one system.

    A multi-product configuration normally contains:

    • two or more product models;
    • relationships between the models, such as compatibility, dependency or quantity rules;
    • shared commercial data, including customer, currency, price list and delivery context;
    • technical information, such as voltage, capacity, dimensions, materials and operating conditions;
    • one or more system-level bills of material (BOMs);
    • possibly a combined drawing, system specification, engineering package or proposal;
    • links to downstream enterprise systems such as enterprise resource planning (ERP), product lifecycle management (PLM), customer relationship management (CRM), computer-aided design (CAD) or manufacturing execution systems (MES).

    The term does not necessarily mean that all products share one product model. A pump, motor and control cabinet can retain separate models while a higher-level solution model governs their relationships.

    Why manufacturers need multi-product configuration

    Many industrial products are not sold in isolation. A customer may buy a complete operating solution even when the manufacturer manages it as several product families. Configuring each item separately can create technical and commercial problems.

    Problem with separate configuration Effect on the manufacturer Multi-product response
    Products are technically incompatible Engineering rework, delayed orders or field failures Cross-product constraints validate interfaces and compatibility
    Shared dimensions are entered repeatedly Conflicting values and manual corrections Shared parameters synchronize related product models
    Each product creates a separate quote Inconsistent discounts, taxes or delivery assumptions A solution-level commercial structure manages the package
    Component information is fragmented Incomplete or duplicated BOM data A system BOM can consolidate product and installation components
    Engineering receives disconnected requests Manual interpretation of sales requirements A structured configuration is passed to engineering and production

    Multi-product configuration is particularly useful when the value of the sale depends on the interaction between products. A conveyor, drive and safety enclosure may each be valid on their own, but the complete line must satisfy speed, load, guarding and control requirements.

    How the product-model architecture works

    A maintainable implementation usually separates product models, shared attributes, relationship rules and system outputs. Combining all logic in one large ruleset makes the model difficult to test and change.

    1. Product models

    Each product or assembly should have a defined model containing its selectable features, default values, valid options, technical parameters, prices and output mappings. A product model might represent a pump, motor, tank, valve skid, switchgear section or vehicle body.

    The model should identify which values are entered by the user and which values are calculated. For example, a user may select flow rate and fluid type for a pump, while the model calculates a recommended impeller size or motor range.

    2. Solution or system model

    A solution model groups products into a coherent configuration. It defines which product families can be added, how many instances are allowed and what information is shared between them.

    A system model for a pumping package might contain:

    • one or more pumps;
    • motors and variable-frequency drives;
    • valves and instrumentation;
    • a skid or base frame;
    • an electrical control panel;
    • optional piping, insulation and commissioning services.

    The system model can also define product roles. For example, one component may be the primary pump, another a standby pump and another a dosing unit. Role information matters because the same product family can behave differently depending on its position in the system.

    3. Shared parameters

    Shared parameters are values used by multiple product models. Examples include supply voltage, ambient temperature, required capacity, enclosure rating, operating pressure, material grade, installation region and target delivery date.

    Shared parameters should have a clear source of authority. If voltage is entered once at system level, downstream models should consume that value rather than asking the user to enter it again. If a product-specific exception is allowed, the model should state when and why the exception is valid.

    4. Relationship rules

    Relationship rules control how products interact. Common forms include:

    • Compatibility: a selected motor must be compatible with the pump shaft, power demand and supply voltage.
    • Dependency: selecting a heat exchanger requires an appropriate control valve and sensor package.
    • Exclusion: two components cannot be selected together because they use the same mounting position.
    • Quantity: one controller is required for every defined group of drives, subject to capacity limits.
    • Dimensional: the enclosure width must accommodate the selected devices and cable-entry arrangement.
    • Capacity: the selected frame, transformer or drive must support the total connected load.
    • Consistency: all system components must use an approved material or environmental rating.
    • Sequencing: a downstream product cannot be selected until a compatible upstream product has been chosen.

    These rules should be expressed using business and engineering terms that product owners can understand. A rule such as motor.power >= pump.required_power may be technically useful, but the model should also explain the reason, unit and applicable operating conditions.

    Rules in a multi-product configurator

    A manufacturing CPQ configurator can use several types of logic. They are related but not interchangeable.

    Logic type Purpose Manufacturing example
    Rules-based configuration Applies explicit if-then logic, dependencies and exclusions If the enclosure is outdoor-rated, require a suitable gasket and coating
    Constraint-based configuration Finds or validates combinations that satisfy limits and relationships Select a motor and drive whose capacity, voltage and duty rating satisfy the pump requirements
    Guided selling Uses questions and recommendations to help a user reach a suitable product Ask about flow, pressure and fluid, then recommend pump families
    Calculation logic Derives technical or commercial values from inputs Calculate heat load, cable size, frame dimensions or shipping weight

    Guided selling may recommend a product, but it does not by itself prove that a complete system is manufacturable. Constraint validation and engineering calculations are needed when product relationships affect safety, performance or production.

    Hard constraints and soft guidance

    A hard constraint prevents an invalid configuration. For example, a 460-volt motor should not be accepted when the configured electrical system is limited to 230 volts. Soft guidance presents a recommendation or warning but may allow an authorized user to continue.

    Manufacturers should distinguish between:

    • invalid: cannot be quoted or released;
    • requires review: technically possible but needs engineering approval;
    • not preferred: valid but commercially or operationally undesirable;
    • informational: provides context without changing validity.

    This distinction prevents sales users from bypassing important controls while allowing legitimate engineered-to-order (ETO) work to enter a controlled review process.

    Example: configuring a pump package

    Consider a manufacturer selling a packaged pumping system. The configuration includes two centrifugal pumps, motors, a variable-frequency drive (VFD), a skid, isolation valves and a control panel.

    The user enters:

    • required flow and pressure;
    • fluid type and temperature;
    • number of duty and standby pumps;
    • electrical supply and frequency;
    • installation environment;
    • preferred materials and connection standards.

    The CPQ system can then perform several levels of evaluation:

    1. Each pump model is checked against the flow, pressure and fluid requirements.
    2. The motor is selected based on pump power, voltage, duty and efficiency requirements.
    3. The VFD is checked against motor current, enclosure requirements and control architecture.
    4. The skid is sized for the number and arrangement of pumps.
    5. The control panel is checked against the number of motor starters, instruments and communication requirements.
    6. The system-level BOM consolidates pumps, motors, valves, panel components, frame members and purchased parts.
    7. Pricing logic applies product prices, package charges, engineering effort, freight assumptions and authorized discounts.
    8. If supported, CAD automation creates a layout or drawing using the selected dimensions and connection positions.

    The resulting quote is not just a list of line items. It is a structured representation of a system with traceable inputs, rules, calculated values and outputs.

    Multi-product BOM generation

    A bill of material (BOM) lists the components required to sell, engineer, purchase, assemble or manufacture a product. Multi-product configuration complicates BOM generation because the system may need both product-level and system-level structures.

    Configurable BOM

    A configurable BOM is a template containing alternatives, optional components, quantities and rules. The CPQ system resolves it according to the selected configuration. For example, a control panel template may contain alternative breakers, contactors and communication modules.

    EBOM and MBOM

    An engineering bill of material (EBOM) represents the product from an engineering and design perspective. A manufacturing bill of material (MBOM) represents how the product is assembled or produced, including manufacturing-specific groupings, operations or consumables.

    A multi-product system may have:

    • separate EBOMs for the pump, panel and skid;
    • a consolidated system EBOM for the customer solution;
    • one or more MBOMs for fabrication, panel assembly and final integration;
    • installation or service BOMs containing items that are not part of the factory assembly.

    CPQ does not automatically replace an ERP or PLM system. The CPQ platform may generate or assemble BOM data, but the authoritative released structure may remain in PLM or ERP. The integration design must define which system owns item masters, revisions, approved alternatives, manufacturing structures and release status.

    More detail on these relationships is available in the guide to BOM generation, pricing and quoting.

    Pricing and quoting for a configured system

    Multi-product configuration should not be confused with multi-line quoting. A quote can contain many lines without understanding how those lines relate technically. Multi-product CPQ adds system-level commercial logic to the product relationships.

    Pricing may include:

    • individual product and option prices;
    • quantity breaks across the complete system;
    • package or system discounts;
    • engineering and design charges;
    • commissioning, installation or testing services;
    • freight calculated from total weight, dimensions or shipment groups;
    • currency, tax, regional and channel rules;
    • approval thresholds for margin, discount or non-standard components.

    Costing can use material, labor, subcontracting, engineering hours and overhead assumptions. The CPQ system may calculate an estimate, while ERP or a costing system remains the source of actual production cost. These boundaries should be documented rather than assumed.

    CAD, engineering and technical outputs

    Some multi-product configurations require more than a quote and BOM. A selected combination may need dimensional validation, a system layout, a wiring diagram, a datasheet or product-specific drawings.

    Where supported, CAD automation can use configuration parameters to generate or update:

    • assembly geometry;
    • mounting-hole patterns;
    • pipe or cable connection locations;
    • enclosure dimensions;
    • brackets, guards and supports;
    • 2D drawings and annotations;
    • customer-facing 3D visualization.

    CAD automation is not a standard feature of every CPQ platform. It may require a dedicated CAD integration, an engineering automation service or a separate design-automation application. The implementation must also manage CAD templates, revision control, regeneration failures and human review.

    Read more about CAD and engineering automation in CPQ.

    Enterprise-system relationships

    Multi-product configuration commonly crosses several systems, each with a different responsibility.

    System Typical responsibility Multi-product data exchanged
    CRM Accounts, opportunities, contacts and sales activity Opportunity context, customer and quote references
    CPQ Configuration, pricing, quoting and solution logic Selected options, rules, prices, approvals and outputs
    ERP Items, inventory, orders, purchasing, production and finance Item numbers, order lines, BOMs, costs and order status
    PLM Product definitions, revisions, engineering change and release control Approved product structures, revisions and effectivity
    PDM Product data and CAD document management CAD files, drawings, metadata and revisions
    CAD Geometric design and engineering outputs Parameters, models, drawings and generated documents
    PIM Product information for distribution and commerce Descriptions, attributes, images and channel content
    MES Shop-floor execution and production tracking Released work instructions, routings or production data

    Integration can be direct, API-based, event-driven or mediated by an integration platform. The correct pattern depends on transaction volume, latency, data ownership and the ability of each system to expose stable interfaces. See the guide to CPQ integrations for architecture considerations.

    Where multi-product configuration fits in manufacturing workflows

    Multi-product configuration can support several fulfillment models.

    Workflow Role of multi-product configuration
    Configure-to-order (CTO) Validates a known combination and creates a production-ready order or structured handoff
    Make-to-order (MTO) Captures product and system choices that trigger manufacturing after order acceptance
    Assemble-to-order (ATO) Selects standard modules that are assembled into a customer-specific system
    Engineer-to-order (ETO) Defines the initial technical requirement and routes exceptions to engineering for completion

    In an ETO workflow, CPQ should not pretend that every design decision can be automated. A better approach is to identify what can be validated automatically, what requires engineering review and what information engineering must receive to complete the design.

    The configured solution can then become the starting point for an engineering request, project record, order, PLM structure or ERP sales order. The handoff should preserve the original selections and rule results so that engineering does not need to reconstruct the customer requirement manually.

    See manufacturing workflows for CPQ for CTO, ETO, MTO and order-to-production patterns.

    Benefits of multi-product configuration

    • Fewer compatibility errors: cross-product rules identify invalid combinations before order entry or engineering release.
    • Shorter quote preparation: sales and applications teams can configure a complete package without repeatedly requesting manual checks.
    • Better technical consistency: shared parameters reduce conflicting voltage, capacity, material and dimensional values.
    • More complete manufacturing data: system-level BOMs and structured outputs provide a stronger handoff to ERP, PLM and production.
    • Improved pricing control: package discounts, engineering fees and system-level costs can be applied consistently.
    • Traceability: the manufacturer can connect customer requirements, selected options, rules, revisions and quote outputs.
    • Reusable product knowledge: approved product and interface rules can be applied across sales channels and regions.

    Limitations and risks

    Multi-product configuration introduces complexity rather than eliminating it. The most common risks are architectural and governance-related.

    • Rule explosion: every additional product, option and interface can multiply possible combinations.
    • Unclear ownership: product management, engineering, pricing and IT may disagree about who maintains rules and data.
    • Duplicated master data: item numbers, attributes and revisions may diverge between CPQ, ERP and PLM.
    • Over-automation: a model may accept a result that still needs engineering judgment or regulatory review.
    • Slow configuration performance: complex constraint solving and integrations can make the user experience impractical.
    • Hidden assumptions: units, environmental conditions, installation practices and regional standards may not be explicit.
    • Uncontrolled exceptions: allowing users to override rules without reason codes and approvals weakens the model.
    • Output mismatch: a CPQ BOM may not match the structure required by ERP, PLM or manufacturing.

    A successful implementation defines the boundary between automatic configuration and controlled engineering review. It also treats product models as governed engineering assets rather than temporary sales forms.

    Implementation approach

    1. Select a bounded use case

    Start with a product family where product relationships are important and the rules are sufficiently understood. A complete pump package, modular conveyor cell or standard electrical enclosure may be a better starting point than an entire industrial plant.

    2. Map products and interfaces

    Document the product families, assemblies, selectable features, shared parameters, physical interfaces, electrical interfaces, performance limits and installation assumptions. Include optional products and service components where they affect the system.

    3. Define data ownership

    For each attribute and structure, identify the system of record. Decide whether CPQ consumes released data from PLM, item and price data from ERP, customer data from CRM and technical content from a product information management system.

    4. Classify rules

    Separate hard constraints, warnings, recommendations, calculations and approval triggers. This makes testing easier and clarifies what users are allowed to override.

    5. Design outputs before finalizing the interface

    Define the required quote, BOM, order, engineering request, drawing, datasheet and integration outputs. A configuration interface should collect information because a downstream process needs it, not merely because it is easy to display.

    6. Build test scenarios

    Test valid combinations, invalid combinations, boundary values, missing data, option changes, product substitutions, revision changes, quantity changes and exception workflows. Include regression tests so that a rule change for one product does not break another product family.

    7. Govern releases

    Use versioning, approval, effective dates and change records for product models and rules. Coordinate CPQ releases with ERP item changes, PLM revisions, CAD template changes and price updates.

    The broader CPQ implementation guide covers requirements, migration, testing, governance, adoption and maintenance.

    Maintainability principles

    Maintainability is often more important than the initial configuration experience. A model that works for ten products but cannot be safely changed will become a bottleneck.

    • Use reusable rule components for common interfaces and standards.
    • Keep product-specific rules within the relevant product model where possible.
    • Use shared parameters instead of copying the same value between screens.
    • Give rules meaningful names and record their engineering rationale.
    • Separate technical validity from commercial pricing logic.
    • Use controlled reference data for units, materials, voltage classes and standards.
    • Record overrides with an owner, reason and approval status.
    • Test product combinations using representative configuration matrices.
    • Measure rule defects, manual interventions, engineering reviews and failed integrations.

    How to evaluate a CPQ configurator for multi-product use

    Manufacturers evaluating a CPQ configurator should ask questions beyond whether it supports product options.

    Evaluation area Questions to verify
    Product model Can the platform represent multiple product families, assemblies, roles and quantities?
    Rules Can it express cross-product constraints, calculations, warnings, approvals and exceptions?
    Data governance How are revisions, effective dates, ownership and testing managed?
    BOM Can it produce the required product, system, configurable, EBOM or MBOM outputs?
    Engineering Does it support calculations, CAD, drawings or controlled handoffs, and which capabilities require additional software?
    Commercial logic Can it price individual products and system-level packages without mixing pricing with technical validity?
    Integration Are APIs and mappings available for CRM, ERP, PLM, PDM, CAD, PIM and MES?
    Performance How does the system behave with large product models, many instances and complex constraints?
    Operations Can administrators diagnose rule failures and update models without unsafe code changes?

    Do not assume that a vendor’s standard CPQ product includes CAD automation, BOM generation, constraint solving or PLM integration. Verify each capability against documented product behavior, supported interfaces and the proposed implementation scope. The manufacturing CPQ software guide and CPQ comparison resources provide additional evaluation context.

    Semantic map

    The following relationships summarize the entities and flows discussed in this guide:

    • CPQ configures configurable products.
    • Multi-product configuration connects related product models.
    • Configuration rules prevent invalid combinations.
    • Shared parameters synchronize product models.
    • Constraint logic validates technical relationships.
    • Guided selling recommends suitable product combinations.
    • Configured products generate system BOM data.
    • EBOM represents engineering product structure.
    • MBOM represents manufacturing assembly structure.
    • Pricing logic calculates package prices and costs.
    • CAD automation generates product-specific drawings.
    • CPQ exchanges configuration data with ERP.
    • PLM governs released product definitions and revisions.
    • CRM provides opportunity and customer context.
    • ETO routes unresolved design decisions to engineering.
    • CTO converts approved configurations into repeatable production orders.

    FAQ

    What is multi-product configuration in CPQ?

    It is the coordinated configuration of two or more related products or assemblies within one solution, quote or project. The system validates both each product independently and the relationships between them.

    How is multi-product configuration different from a quote with multiple line items?

    A multi-line quote can list products without understanding their technical relationships. Multi-product configuration applies shared parameters, compatibility rules, calculations and system-level outputs across the products.

    What manufacturing products commonly require multi-product configuration?

    Common examples include pump packages, HVAC systems, conveyor lines, electrical equipment, machine cells, material-handling systems, vehicle bodies and complete skids or process modules.

    Can multi-product configuration support configure-to-order manufacturing?

    Yes. It can validate approved combinations, resolve options into BOM and order data, and pass the result to ERP or production when the product family is suitable for configure-to-order.

    Can it support engineer-to-order products?

    Yes, but it should define the boundary between automation and engineering review. CPQ can capture requirements, validate known constraints and create an engineering request without claiming that every design decision is automated.

    What is a system-level rule?

    A system-level rule governs a relationship between products or assemblies. For example, it may require a motor to match the pump power, or require a controller to support the number of connected drives.

    What are shared parameters in a CPQ configurator?

    Shared parameters are values used by multiple product models, such as voltage, ambient temperature, capacity, material grade or installation region. They reduce duplicate entry and conflicting values.

    Does every CPQ system support cross-product constraints?

    No. Some platforms focus mainly on product options, pricing and quoting. Buyers should verify whether the system supports cross-product rules, calculations, constraint solving and the required exception workflows.

    How does multi-product configuration affect BOM generation?

    It may create separate product BOMs, a consolidated system BOM or both. The implementation must define whether the output is an EBOM, MBOM, configurable BOM, installation BOM or another structure required by downstream systems.

    Can CPQ generate an MBOM directly?

    Some implementations can generate manufacturing-oriented structures, but this is not universal. The manufacturer must verify whether CPQ creates the required MBOM or whether ERP, PLM or a manufacturing system transforms the configuration into an MBOM.

    How does pricing work for a configured system?

    Pricing can combine product and option prices with package discounts, engineering charges, services, freight, taxes and approval rules. Technical validity should remain separate from commercial pricing logic.

    Does multi-product configuration require CAD automation?

    No. CAD automation is optional, although it can be valuable when product relationships affect dimensions, layouts, mounting patterns or drawings. CAD capabilities and integrations must be evaluated separately.

    What is the role of PLM in multi-product configuration?

    Product lifecycle management (PLM) commonly governs released product definitions, revisions, engineering changes and approved structures. CPQ may consume this data or submit configured results, depending on the architecture.

    What is the role of ERP?

    Enterprise resource planning (ERP) typically manages item masters, inventory, orders, purchasing, production and finance. CPQ may send configured items, quantities, prices and BOM information to ERP.

    Should product rules be stored in CPQ or PLM?

    There is no universal answer. Rules used during interactive configuration may reside in CPQ, while product definitions and engineering change control may remain in PLM. Ownership and synchronization must be explicitly designed.

    How can manufacturers prevent rule explosion?

    Use modular product models, reusable interface rules, shared parameters, clear product boundaries, constraint classification and automated regression testing. Avoid encoding every exception as an unstructured special case.

    What happens when a configuration is valid but non-standard?

    The system can issue a warning, require an engineering review or route the configuration into an ETO workflow. The treatment should depend on risk, authority and the manufacturer’s approval policy.

    How should multi-product configurations be tested?

    Test valid and invalid combinations, boundary values, quantity changes, substitutions, missing data, revisions, overrides, pricing outcomes, BOM outputs and integration failures. Regression tests are important when shared rules change.

    What should a manufacturer ask a CPQ vendor?

    Ask whether the platform supports multiple product models, cross-product constraints, calculations, BOM outputs, system-level pricing, APIs, revision control, audit trails and integrations with the manufacturer’s ERP, PLM, CAD and CRM systems.

  • How to Prevent Dead Ends in Product Configuration

    A dead end in product configuration occurs when a salesperson, dealer, engineer or customer can make several apparently valid selections, but a later choice reveals that the product cannot actually be completed, manufactured, priced or delivered. For example, a customer may select a large pump casing, a high-flow impeller and a compact motor frame before the configurator discovers that the motor cannot fit the selected baseplate.

    The most reliable way to prevent these failures is to treat the product model as an engineering decision system rather than a catalogue of options. A manufacturing CPQ system must represent valid components, dependencies, constraints, calculations, availability rules, manufacturing limits and downstream outputs. It should reject or prevent incompatible choices as early as possible, explain why a choice is unavailable and preserve enough structured data to generate an accurate bill of materials, quote and engineering handoff.

    This is more demanding than generic sales CPQ, which may primarily select products, quantities, discounts and commercial terms. Manufacturing CPQ can also need to validate dimensions, materials, electrical ratings, performance calculations, assembly relationships, CAD parameters and production data. The concepts of product configuration and configuration validation are therefore central to preventing dead ends.

    What is a configuration dead end?

    A configuration dead end is a state in which a partially configured product has no valid path to completion, even though the selections made so far were accepted by the system. The user may have to undo several choices, restart the configuration or send the request to an engineer for manual review.

    Dead ends are different from simple validation errors. A validation error usually identifies an immediate conflict, such as selecting a 460-volt motor with a control panel designed only for 230 volts. A dead end can remain hidden until several dependent decisions have been made. The system accepts each individual decision but fails to recognise that their combined effect leaves no feasible product.

    Situation Example Result
    Direct conflict A stainless-steel option is selected for a frame available only in painted carbon steel. The system can block the second selection immediately.
    Capacity conflict A selected lifting mast, payload and reach exceed the available hydraulic capacity. A calculation or constraint must identify the limit.
    Downstream conflict A selected enclosure requires a cable entry arrangement not supported by the chosen control cabinet. The product model must include electrical and manufacturing dependencies.
    Availability dead end A component is technically compatible but obsolete or unavailable in the plant or supply chain. Lifecycle, plant and sourcing data must influence configuration.
    Output dead end A configuration is commercially valid but cannot produce a required BOM, drawing or manufacturing attribute. Output completeness must be tested before quoting or ordering.

    Why dead ends occur in manufacturing product models

    Dead ends usually result from incomplete product knowledge, weak rule structure or a configuration process that checks decisions too late. The most common causes are below.

    Options are modelled independently

    A flat list of options may show a motor, gearbox, enclosure and mounting arrangement as separate choices. However, the product may allow only particular combinations. If the relationships are not modelled, the configurator cannot distinguish an available option from an option that is valid only in a specific context.

    Rules are written as exceptions

    Product teams sometimes encode knowledge as a growing set of statements such as do not allow option A with option B, except when option C is present. This can work for a small product but becomes difficult to review as exceptions accumulate. Contradictory rules, duplicate rules and rules with unclear ownership create gaps in validation.

    Engineering calculations are separated from configuration

    A pump selection may depend on flow, head, fluid temperature, viscosity, speed and material. If the CPQ model checks only whether a pump family is selected, while a spreadsheet performs the actual hydraulic calculation later, the user can reach a commercially valid but technically unsuitable configuration.

    Downstream systems impose hidden constraints

    An enterprise resource planning system, or ERP system, may require a specific material code, plant assignment or routable assembly. A product lifecycle management system, or PLM system, may require an approved component revision. A computer-aided design system, or CAD system, may support only certain parameter ranges. If these constraints are not reflected in the product model, the dead end appears after the quote.

    Product variants are not governed as a system

    Engineering changes, supplier substitutions, obsolete parts and plant-specific manufacturing practices can change what is valid. Without controlled releases and ownership, the CPQ model gradually diverges from engineering and production reality.

    Model the product as a constraint network

    A robust product model represents more than features and prices. It describes the relationships between choices, measurements, components, calculations and outputs. A useful model commonly includes:

    • Products and families: the configurable machine, assembly or equipment family.
    • Features and options: customer or engineer selections such as drive type, material, voltage, capacity or finish.
    • Attributes: values such as length, pressure rating, temperature, payload, speed or operating environment.
    • Dependencies: relationships stating that one choice requires, excludes or changes another.
    • Constraints: technical limits that must hold across the entire configuration.
    • Calculations: formulas that derive dimensions, performance, capacity, power, cost or component selection.
    • Component mappings: relationships between selections and configurable bills of materials.
    • Output requirements: data needed for pricing, quoting, CAD, BOM, ERP, PLM or manufacturing.
    • Lifecycle and availability data: approved, obsolete, superseded, plant-specific or supplier-specific status.

    This structure creates a network rather than a linear questionnaire. A change to a motor may affect the coupling, shaft, baseplate, enclosure, power supply, price, weight and CAD parameters. The system must be able to propagate those effects or explain which dependent decisions must be revisited.

    Use the right type of rule

    Not all configuration logic is the same. Separating rule types improves clarity, testing and maintenance.

    Rule type Purpose Industrial example
    Availability rule Controls whether an option is shown or selectable. Show a hazardous-area motor only when the application classification supports it.
    Requires rule States that one selection needs another. A stainless-steel hopper requires stainless-steel product-contact fasteners.
    Excludes rule Prevents incompatible combinations. A high-temperature seal excludes a standard elastomer.
    Cardinality rule Controls the number of selections. A control panel must contain exactly one primary controller and may contain up to four expansion modules.
    Range constraint Limits a numerical value. A conveyor width must be between the frame’s minimum and maximum supported width.
    Calculation rule Derives a value or selection. Motor power is calculated from load, speed, efficiency and service factor.
    Compatibility rule Matches options across domains. A valve body, actuator and pressure class must come from a compatible combination.
    Manufacturing rule Reflects production capability. A plant can weld a selected frame only within its available length and material limits.
    Lifecycle rule Controls approved and obsolete items. Prevent a discontinued drive from being selected for a new quote.

    Prevent dead ends with forward checking

    Forward checking means evaluating the consequences of a choice before the user proceeds too far. After a user selects a 12-metre conveyor, the configurator should not merely accept the length. It should check the available frame sections, splice arrangements, motor capacity, shipping limits, guarding requirements, support spacing and CAD or BOM mappings.

    The interface can then remove impossible options, mark conditional options, or present a warning requiring review. This is preferable to allowing every option and showing a long list of errors at the end.

    Use domain filtering

    Each configurable attribute has a domain: the set of values that may be selected. A rule engine can reduce that domain as other decisions are made. For example:

    1. The customer selects a pump application with a specified flow and head.
    2. The calculation identifies an acceptable impeller diameter and speed range.
    3. The system removes motors that cannot provide the required power.
    4. The system removes baseplates and couplings incompatible with the remaining motor and pump combinations.
    5. The user sees only combinations with a feasible engineering and manufacturing path.

    Domain filtering is especially useful for dimensions, ratings, materials and standard component families. It is less suitable when the result depends on a complex engineering analysis that requires a specialist calculation service or manual review.

    Expose the reason for restrictions

    A blocked choice should have a useful explanation. Instead of saying option unavailable, the system might state that the selected 400-millimetre impeller requires a frame size that exceeds the chosen skid width, or that the selected pressure class requires a valve body material not available in the chosen connection type.

    Explanations help sales engineers correct the configuration, reduce support requests and reveal weaknesses in the product model. They also make rules easier to validate with engineering and product management.

    Build a complete configuration workflow

    A dead-end prevention strategy should cover the full path from requirements to manufacturing data.

    1. Capture requirements before options

    Begin with operating requirements such as flow, pressure, payload, travel distance, ambient temperature, duty cycle, voltage, regulatory classification and installation constraints. Requirements often narrow the feasible product space more effectively than asking users to choose components directly.

    2. Select a product architecture

    Use the requirements to identify a product family, frame size, architecture or platform. For a material-handling machine, this might determine whether the product uses a belt, roller or chain conveyor before detailed components are selected.

    3. Resolve technical dependencies

    Evaluate dimensions, ratings, performance and compatibility. This is where constraint-based configuration differs from simple guided selling. Guided selling helps a user navigate questions toward a likely product. Constraint-based configuration evaluates whether the combined selections satisfy technical rules.

    4. Generate and validate engineering data

    Where supported, the system can create a configurable bill of materials, CAD parameters, drawings or engineering calculations. A bill of materials, or BOM, lists the components and quantities needed for the configured product. An engineering BOM, or EBOM, describes the product from an engineering perspective, while a manufacturing BOM, or MBOM, represents how it is assembled or produced. These structures should not be treated as interchangeable.

    Some CPQ platforms generate only a commercial configuration and quote. Others support BOM generation, CAD automation or engineering calculations through native functions or integrations. The implementation must verify what the selected platform actually produces.

    5. Validate commercial and operational feasibility

    After technical validation, check costing, pricing, lead time, plant assignment, supplier status, minimum order quantities and approval requirements. A configuration that is technically possible may still be unavailable for a specific plant or outside the organisation’s commercial policy.

    6. Produce a controlled handoff

    The final configuration should pass structured data to the relevant systems. ERP manages business and production transactions, PLM manages product definitions and revisions, product data management or PDM manages engineering files and relationships, CAD manages geometry and drawings, and a manufacturing execution system or MES may manage shop-floor execution. A CRM system manages customer and opportunity information; it is not a substitute for product or manufacturing data management.

    More detail on these system relationships is available in the CPQ integrations guide.

    Use a dependency matrix before writing rules

    A dependency matrix helps teams discover hidden relationships before implementing them. Each row can represent a feature, attribute or component, while columns identify affected domains.

    Selection Configuration impact Engineering impact Manufacturing impact Commercial impact
    Motor voltage Filters controller and cable options. Changes electrical diagram and motor data. Changes wiring and test requirements. Changes price and possibly lead time.
    Frame material Filters finish and fasteners. Changes weight and structural properties. Changes welding and surface treatment. Changes cost and sourcing.
    Operating temperature Filters seals, lubricants and sensors. Changes allowable performance range. May require special assembly procedures. Changes price and approval requirements.
    Overall length Filters modules and support spacing. Changes CAD and structural calculations. Changes BOM quantities and transport constraints. May require freight or installation surcharges.

    The matrix should include negative relationships as well as positive ones. Teams often document what an option enables but fail to document what it makes impossible.

    Design rules for maintainability

    Preventing dead ends is not only a logic problem. It is also a product-model governance problem. Rules should be readable, traceable and owned.

    Separate product facts from user-interface behaviour

    A rule stating that a 316 stainless-steel wetted part requires compatible fasteners is product knowledge. A rule stating that the user must answer material before seal type is interface behaviour. Keeping these concepts separate allows the same product logic to support a sales portal, dealer interface, engineering application or API.

    Use reusable constraints

    If the same pressure-class rule applies to several valve families, implement it as a reusable constraint or service where the platform permits it. Copying the rule into multiple models increases the risk that one version will be updated while another remains stale.

    Assign ownership

    Engineering should own technical constraints, product management should own supported product scope, manufacturing should own plant and process constraints, supply chain should own sourcing status, and commercial teams should own pricing and approval policies. One system owner should coordinate changes and resolve conflicts.

    Version the model with the product

    Rules, components, prices and drawings change at different rates. A quote should use a controlled version of the product model and identify the effective dates of important data. If an approved component is replaced, the organisation must decide whether open quotes retain the old component or are revalidated.

    Avoid unrestricted custom logic

    Custom scripts can solve difficult cases, but they may be difficult to test, explain and migrate. Use the platform’s standard modelling concepts where they are sufficient, and isolate custom calculations behind documented interfaces when they are necessary.

    Test for dead ends systematically

    Testing should not stop after checking a few popular configurations. A manufacturing product model needs structured coverage of normal, boundary, exceptional and historical cases.

    • Pairwise tests: test important combinations of two features, such as material and temperature rating.
    • Boundary tests: test minimum and maximum dimensions, capacities, pressures, speeds and temperatures.
    • Three-way or higher-order tests: test combinations known to create interactions, such as motor, enclosure and voltage.
    • Negative tests: confirm that invalid combinations are blocked with understandable messages.
    • Completion tests: verify that every accepted configuration can produce the required price, quote data, BOM or engineering output.
    • Change-impact tests: change a core rule or component and verify all affected product families.
    • Integration tests: check that ERP, PLM, PDM, CAD and other systems accept the resulting data.
    • Regression tests: rerun known scenarios after each model release.

    One useful test criterion is configuration completeness: every configuration accepted by the CPQ system must either produce all required downstream outputs or be explicitly routed to engineering review. This prevents a system from claiming success when it has only completed the commercial part of the process.

    Handle unavoidable engineering review explicitly

    Not every product can be fully constrained in a CPQ model. Engineer-to-order, or ETO, products may require a new design or engineering decision for each order. Even configure-to-order, or CTO, products can include combinations that require specialist review.

    The goal is not to pretend that every configuration is fully automatic. The goal is to distinguish three states clearly:

    1. Valid and automatable: the product model can generate the required commercial and technical outputs.
    2. Valid but requires review: the request is within a supported family but needs engineering confirmation or a non-standard calculation.
    3. Invalid: no approved product or engineering path exists.

    A review queue should capture the selected requirements, rule results, calculations, assumptions, affected components and missing decisions. This is more useful than sending an unstructured email containing a screenshot of the configuration.

    Connect dead-end prevention to BOM, CAD and quoting

    Configuration validation has downstream consequences. A valid selection should map to the right component records, quantities, revisions and attributes. If the system generates a configurable BOM, the rules must determine which components are included, excluded, substituted or added conditionally.

    For example, selecting a high-temperature pump package may require a different seal, lubricant, bearing arrangement, motor insulation class and warning label. If the product model changes only the displayed price but not the BOM and engineering data, the configuration is not operationally complete.

    CAD automation may use configuration values to generate a product-specific model, drawing or layout. However, CAD automation introduces its own constraints: parameter ranges, feature dependencies, template versions and file-generation rules. These should be tested alongside the configuration model rather than assumed to work because the commercial configuration is valid. See the CAD and engineering automation guide for the relationship between configuration and engineering outputs.

    Pricing should also be separated from technical validation. A price rule can calculate a surcharge for a material or capacity, but it should not be the only place where compatibility is checked. The BOM, pricing and quoting guide explains how technical configuration data can flow into costing and quote generation.

    Common approaches that do not work well

    Allow everything and validate at the end

    This creates long correction cycles and makes it difficult for users to understand which earlier choice caused the problem. It may be acceptable for exploratory engineering tools, but it is risky for dealer, sales and self-service workflows.

    Use only exclusion lists

    Exclusion lists are useful for direct incompatibilities but do not model capacities, calculations, ranges or derived components. A pump may be compatible with a motor in isolation but unsuitable for the required duty point.

    Put all rules in one person’s knowledge

    Unwritten knowledge creates a single point of failure. When an experienced application engineer leaves, the business may lose the reasoning behind important constraints.

    Copy rules between product families

    Copied rules drift. A shared standard, reusable rule service or centrally governed component model is usually safer when the same constraint applies in multiple families.

    Measure only quote speed

    Faster quoting is not a success if it increases engineering corrections, order changes or production holds. Track configuration quality as well as speed.

    Implementation checklist

    Use the following checklist when designing or improving a manufacturing CPQ configurator:

    • Identify the product families and configuration boundaries.
    • Document requirements, options, attributes, components and derived values.
    • Map dependencies across mechanical, electrical, software and process domains.
    • Separate direct compatibility rules from calculations and manufacturing constraints.
    • Define valid, review-required and invalid outcomes.
    • Identify the required EBOM, MBOM, CAD, quote and ERP outputs.
    • Record component lifecycle, revision, plant and sourcing conditions.
    • Assign business and technical owners to each rule group.
    • Build test cases from real quotes, engineering exceptions and production failures.
    • Test boundary values and combinations with high interaction risk.
    • Provide explanations for blocked or conditional choices.
    • Version the model and establish a controlled release process.
    • Monitor rejected configurations, manual overrides, engineering escalations and order corrections.
    • Review the model after product changes, supplier changes, plant changes and ERP or CAD changes.

    For a broader implementation plan covering data migration, testing, governance, deployment and adoption, see the CPQ implementation guide. The manufacturing workflows guide is also relevant when configuration results must move from sales engineering into production.

    How to measure improvement

    Useful measures should reveal whether the product model is preventing errors rather than merely hiding them. Consider tracking:

    • percentage of configurations completed without manual correction;
    • number of invalid combinations detected before quote submission;
    • number of engineering reviews caused by missing or ambiguous rules;
    • quote revisions caused by configuration errors;
    • orders placed on hold because of incomplete technical data;
    • percentage of accepted configurations producing complete BOM and CAD outputs;
    • time required to update and test a product rule;
    • frequency of manual overrides and their approval outcomes;
    • configuration abandonment at specific questions or decision points;
    • production or procurement corrections linked to configuration data.

    These measures should be interpreted carefully. A fall in engineering reviews may mean that the model is better, or it may mean that the system is accepting more invalid configurations. Pair efficiency measures with quality and downstream outcome measures.

    Conclusion

    Preventing dead ends in product configuration requires more than adding validation messages to a sales form. A manufacturing CPQ configurator must represent product architecture, dependencies, technical limits, calculations, component status, manufacturing capability and downstream output requirements.

    The strongest approach filters impossible choices early, explains restrictions, tests interactions and maintains a controlled relationship between the CPQ model and engineering, ERP, PLM, PDM, CAD and production data. It also recognises that some ETO and non-standard products require an explicit engineering-review path rather than forced automation.

    When configuration rules are treated as governed product knowledge, the result is not simply a faster quote. It is a more reliable transition from customer requirements to a manufacturable, correctly priced and properly documented product.

    Semantic map

    The article connects the following entities and relationships:

    • Manufacturing CPQ connects customer requirements to configurable product decisions.
    • Configuration rules constrain options, attributes, dimensions and components.
    • Constraint-based configuration evaluates whether combined selections are technically feasible.
    • Guided selling helps users navigate toward suitable products but does not replace engineering validation.
    • Calculations derive performance, capacity, dimensions, power and component selections.
    • Configuration validation prevents invalid combinations and identifies review-required cases.
    • A configured product generates structured BOM and quote data when the platform supports those outputs.
    • EBOM represents an engineering product structure, while MBOM represents a manufacturing structure.
    • CAD automation uses configuration parameters to generate product-specific geometry or drawings.
    • ERP receives commercial, item, plant and order data from connected workflows.
    • PLM and PDM manage product definitions, revisions and engineering files.
    • Dead-end prevention depends on testing, ownership, versioning and product-model governance.

    Frequently asked questions

    What is a dead end in product configuration?

    A dead end is a configuration state in which the selections already made leave no valid way to complete the product. It may be technically impossible, unavailable to manufacture, unsupported by downstream systems or unable to produce required outputs.

    How is a dead end different from a configuration error?

    A configuration error often identifies an immediate conflict. A dead end may appear only after several individually valid choices combine into an infeasible product.

    Can a CPQ configurator prevent every dead end?

    No. A well-modelled CPQ system can prevent known and testable conflicts, but novel engineering requirements, incomplete data and ETO work may still require human review.

    What types of rules prevent configuration dead ends?

    Common rules include requires, excludes, compatibility, range, capacity, calculation, lifecycle, plant and manufacturing rules. Together they describe more than simple option visibility.

    What is forward checking in product configuration?

    Forward checking evaluates the consequences of a selection immediately and removes or flags downstream options that can no longer lead to a valid product.

    Why are calculations important in manufacturing configuration?

    Many products depend on calculated values such as motor power, flow, pressure, load, heat transfer, structural capacity or dimensions. Option compatibility alone cannot validate these requirements.

    Should invalid options be hidden or displayed?

    Either approach can work. Hiding clearly impossible options simplifies the experience, while displaying disabled options with explanations can help users understand product boundaries and revise requirements.

    How should a system explain a blocked option?

    It should identify the relevant selection and constraint, such as a motor being unavailable because its frame size exceeds the selected baseplate or its voltage does not match the control system.

    What is the difference between rules-based and constraint-based configuration?

    Rules-based configuration applies explicit statements such as requires or excludes. Constraint-based configuration evaluates relationships, ranges and calculations across multiple variables to determine whether a complete solution is feasible.

    Is guided selling enough to prevent dead ends?

    No. Guided selling can ask useful questions and recommend a product family, but manufacturing products often require deeper validation of dimensions, performance, components and production constraints.

    How do BOMs relate to dead-end prevention?

    A valid configuration should map to the required components and quantities. If an accepted configuration cannot produce a complete or approved BOM, the product model has not been validated operationally.

    What is the difference between an EBOM and an MBOM?

    An EBOM, or engineering bill of materials, describes the product from the design perspective. An MBOM, or manufacturing bill of materials, describes the structure, operations or components used to build it. A CPQ process may generate or contribute to one or both, depending on the platform and integration architecture.

    Can CAD automation help prevent dead ends?

    Yes, if CAD parameters, templates and feature limits are connected to configuration validation. CAD automation can also reveal unsupported geometry, but it should not be assumed that every CPQ platform includes CAD generation.

    How should ETO products be handled?

    ETO products should have an explicit engineering-review path. The system should capture requirements and known constraints, identify what is standard or non-standard, and avoid presenting an unverified configuration as production-ready.

    Who should own configuration rules?

    Ownership should be divided by subject area. Engineering typically owns technical constraints, product management owns supported scope, manufacturing owns process limits, supply chain owns sourcing status and commercial teams own pricing policies.

    How often should configuration rules be reviewed?

    Rules should be reviewed whenever products, components, suppliers, plants, ERP structures, CAD templates or regulatory requirements change. Routine regression testing should accompany each controlled model release.

    What should happen when no valid configuration exists?

    The system should explain the limiting requirements and offer alternatives where possible. If the request may be feasible through engineering work, it should create a structured review case rather than forcing the user to restart or submit an unstructured request.

    Which metrics show that dead ends are decreasing?

    Useful metrics include invalid combinations caught early, engineering corrections, quote revisions, order holds, manual overrides, complete BOM or CAD output rates and time required to update product rules.

  • Feature Models for Manufacturing CPQ

    Feature models are structured product models that describe which features, options, components and relationships are available in a configurable product. In manufacturing Configure, Price, Quote (CPQ) software, the feature model provides the logic used to determine whether a selected product configuration is valid, what engineering parameters apply, which components belong in the bill of materials (BOM), and how the configuration should be priced and quoted.

    For example, a pump manufacturer might model pump type, flow rate, pressure, impeller material, motor size, seal arrangement, voltage and connection standard as features. The model can prevent a user from selecting a motor that is too small for the required duty, a seal material that is incompatible with the fluid, or a voltage option that is unavailable for a particular motor family. Depending on the CPQ architecture, the valid configuration can then drive pricing, a configurable BOM, engineering calculations, CAD outputs or an order handoff to enterprise systems.

    A feature model is therefore more than a list of sales options. It is part of the product knowledge layer connecting commercial configuration with engineering and manufacturing. It is usually implemented within, or alongside, the product configuration and rules capabilities described in the product configuration guide.

    What is a feature model?

    A feature model is a formal representation of the structure and variability of a product family. It identifies the features that a product may contain, the values those features can take, and the rules governing combinations of features.

    In a simple sales system, an option list might show available colors, accessories and quantities. A manufacturing feature model goes further by representing product architecture and engineering relationships. It may include:

    • mandatory product characteristics, such as rated pressure or enclosure type;
    • optional features, such as an auxiliary heater or protective coating;
    • alternative choices, such as one of several motor technologies;
    • numeric parameters, such as length, capacity, temperature or lifting height;
    • dependencies between features;
    • exclusions between incompatible features;
    • calculation rules for derived dimensions, capacities or costs;
    • component-selection logic for a configurable BOM;
    • conditions that determine whether a configuration follows a configure-to-order or engineer-to-order path.

    The model normally represents a product family rather than one individual sellable item. A configured product is an instance created when a user selects values and options within that family.

    Feature model terminology

    Term Meaning in manufacturing CPQ Example
    Product family A group of related products sharing an architecture and configuration logic. Horizontal centrifugal pumps.
    Feature A characteristic or decision point in the product model. Seal type, mounting arrangement or rated voltage.
    Option A selectable value or alternative under a feature. Mechanical seal, gland packing or magnetic drive.
    Attribute A data value associated with a product, feature or component. Maximum temperature of 180 degrees Celsius.
    Constraint A rule limiting valid combinations or values. A high-temperature seal is required above a specified fluid temperature.
    Cardinality The minimum and maximum number of selections allowed in a group. Select exactly one motor, or up to three accessories.
    Derived value A value calculated from other selections or inputs. Required motor power calculated from flow and head.
    Configuration A completed set of feature selections and values for a specific product. A 15 kW, stainless-steel pump with a 400 V motor and a cartridge seal.

    The terminology varies between CPQ platforms. Some systems use features and options broadly, while others separate characteristics, attributes, parameters, variants, modules and components. During software selection, manufacturers should examine how the platform represents these concepts and whether the structure can be maintained by product and engineering teams.

    How a feature model is structured

    Product hierarchy

    Most feature models begin with a product hierarchy. The hierarchy reflects the product architecture or the decisions a user must make. A configurable industrial fan, for example, might be organized as:

    • Industrial fan
    • Fan arrangement
    • Air performance
    • Drive system
    • Motor
    • Housing and materials
    • Controls
    • Accessories
    • Compliance and documentation

    The hierarchy can be technical, commercial or user-oriented. A sales configurator may ask for application requirements first, while an engineering-oriented model may expose product modules and component relationships. These two views can use the same underlying model but present different questions to sales engineers, dealers or customers.

    Mandatory and optional features

    A mandatory feature must be resolved for a valid configuration. For a pump, rated flow and pressure may be mandatory because they determine the operating point. An optional feature might be a baseplate, a vibration sensor or a special coating.

    Mandatory does not always mean that the customer actively selects the value. The CPQ system may assign a default or derive it from other inputs. The distinction is important because an apparently optional commercial choice may be technically mandatory downstream.

    Alternative and multiple-selection features

    An alternative group requires one choice from a defined set. A motor model, connection standard or drive arrangement often works this way. A multiple-selection group permits several choices, such as accessories or instrumentation packages.

    Cardinality makes these groups precise. For example, a product model may require exactly one motor, permit zero or one standby heater, and allow between zero and four monitoring accessories. Without explicit cardinality, users and downstream systems may interpret the product structure differently.

    Numeric parameters and ranges

    Manufacturing products often cannot be modeled with fixed picklists alone. Dimensions, capacity, temperature, pressure, payload, stroke length and electrical ratings may be numeric inputs. A feature model can define permitted ranges, increments, units and relationships between values.

    For a conveyor, the model might accept a belt length between 2 and 30 metres in 0.5 metre increments. It might then calculate frame sections, belt weight, motor power and guarding requirements. Numeric validation can be simple, such as a minimum and maximum, or complex, such as a calculation based on material, speed and incline.

    Rules and constraints in a manufacturing feature model

    Rules determine how feature selections interact. They are the mechanism that turns a catalogue into an engineering-aware configuration system. A rule may hide an option, make a feature mandatory, reject a combination, calculate a value, select a component or trigger an engineering review.

    Common constraint types

    Constraint type Purpose Manufacturing example
    Requires Forces one selection when another is made. A variable-frequency drive requires a compatible motor and control panel.
    Excludes Prevents incompatible selections. A plastic housing excludes a high-temperature process option.
    Requires one of Ensures a compatible alternative is selected. A hazardous-area motor requires an approved protection method.
    Range constraint Limits a numeric value. Maximum operating pressure depends on body material and temperature.
    Conditional mandatory Makes a feature required only under a condition. A lifting certificate is required above a specified load rating.
    Calculation rule Derives a value from inputs. Required heat-exchanger area is calculated from duty and temperature difference.
    Selection rule Chooses a component or option automatically. A motor frame and coupling are selected from torque and speed.
    Workflow rule Routes a configuration to a process. Non-standard dimensions create an engineering review task.

    Rules-based configuration, constraint-based configuration and guided selling

    These terms overlap but should not be treated as identical.

    • Rules-based configuration uses explicit statements such as “if option A is selected, require option B” or “if flow exceeds a threshold, select frame size C.”
    • Constraint-based configuration focuses on the permitted solution space. The system evaluates relationships, ranges and constraints to identify valid combinations, sometimes solving for compatible values.
    • Guided selling presents questions in a user-friendly sequence to recommend or narrow products. It may use configuration rules, but it can also be a simpler questionnaire that does not fully validate engineering feasibility.

    A manufacturing CPQ implementation may use all three. Guided selling can collect application requirements, a constraint engine can validate engineering feasibility, and rules can generate components and pricing. A guided selling questionnaire alone should not be assumed to replace a product model or engineering rules engine.

    Manufacturing example: a configurable pump

    Consider a pump family sold for industrial process applications. The feature model might contain the following decisions:

    • pump arrangement: end suction, inline or multistage;
    • flow rate and differential head;
    • fluid type and temperature;
    • casing material: cast iron, stainless steel or duplex stainless steel;
    • impeller material and diameter;
    • seal arrangement;
    • motor power, speed and voltage;
    • baseplate and coupling guard;
    • instrumentation and control options;
    • certification and documentation requirements.

    Several relationships may apply:

    1. The selected pump arrangement limits the available casing and impeller families.
    2. Fluid temperature and chemical compatibility restrict seal and material options.
    3. Required flow and head determine an acceptable hydraulic operating range.
    4. Impeller diameter and speed influence motor power.
    5. The motor power and frame size determine compatible coupling and baseplate options.
    6. The voltage and frequency determine which motor variants can be selected.
    7. A hazardous-area requirement restricts motor, instrumentation and control-panel choices.
    8. Special materials may require a longer lead time and an engineering approval.

    The model should distinguish customer inputs from derived engineering values. The customer may specify flow, head, fluid and temperature. The system may calculate a duty point, recommend an impeller, select a motor range and identify whether the request can be fulfilled from standard designs.

    The final result might include a valid configuration, a price, a component structure, a manufacturing classification and an engineering status. It might also produce a CAD request or a drawing package, but only if the selected CPQ and connected engineering systems support those capabilities. Details on this part of the architecture are covered in the CAD and engineering automation guide.

    Feature models and product data

    A feature model depends on several types of product data. The model itself is not a replacement for every product-data system in the enterprise.

    Data category Typical contents Possible system of record
    Product structure Modules, features, options and component relationships. CPQ, product lifecycle management or product data management system.
    Technical attributes Ratings, dimensions, materials, tolerances and certifications. Product lifecycle management, product data management or engineering systems.
    Commercial data Prices, discounts, surcharges, currencies and effective dates. CPQ, enterprise resource planning or pricing system.
    Manufacturing data Part numbers, routings, work centres, procurement status and production rules. Enterprise resource planning or manufacturing execution system.
    Engineering definitions CAD templates, formulas, simulation inputs and drawing metadata. Computer-aided design, product data management or product lifecycle management.
    Reference content Images, descriptions, manuals and marketing specifications. Product information management or content systems.

    Manufacturers need clear ownership for each data type. A CPQ system may use a copy or synchronized representation of engineering data for fast configuration, while the product lifecycle management (PLM) or product data management (PDM) system remains authoritative for released designs. Customer relationship management (CRM) may store the opportunity and account, but it is not normally the authoritative source for engineering product structure. Enterprise resource planning (ERP) may own item numbers, inventory and order processing, but it may not be suitable for maintaining complex configuration logic.

    From feature selection to BOM, price and quote

    Feature selection is only one stage in a manufacturing CPQ workflow. A typical flow is:

    1. A salesperson, dealer, engineer or customer enters application requirements.
    2. The CPQ interface presents relevant features and hides or disables invalid choices.
    3. The rules engine validates selections and calculates derived values.
    4. The product model resolves the selected modules and components.
    5. The system generates or resolves a configurable BOM.
    6. Costing and pricing logic calculates material, labour, overhead, freight, margin and commercial adjustments as applicable.
    7. The system creates a quote, proposal or approval request.
    8. The configuration is transferred to ERP, PLM, PDM, CAD or other systems when the process requires it.

    A configurable BOM contains alternative or conditional components that are resolved according to selected features. An engineering BOM (EBOM) represents the product from an engineering design perspective. A manufacturing BOM (MBOM) represents how the product is assembled and produced. These structures may be related but are not interchangeable.

    For example, a feature model may select a stainless-steel pump casing and a particular seal. The EBOM may include the design assembly and technical components, while the MBOM may add packaging, assembly consumables, shop-floor kits or manufacturing-specific items. The CPQ output must be mapped carefully to the receiving system rather than assuming that one generic BOM fits every purpose. See the BOM, pricing and quoting guide for this relationship.

    Feature models across CTO, ETO, MTO and ATO

    Feature models support different manufacturing strategies, but the model must make the boundary between standard configuration and engineering work explicit.

    Workflow Role of the feature model
    Configure-to-order (CTO) Selects from validated product modules and generates a standard manufacturing result without new engineering.
    Engineer-to-order (ETO) Captures requirements, identifies standard starting points and triggers engineering design or review for non-standard work.
    Make-to-order (MTO) Uses the configuration to define a product manufactured after the order rather than held as finished stock.
    Assemble-to-order (ATO) Selects standard modules or subassemblies that are assembled after the order.

    A common implementation mistake is to treat every variation as CTO. If a feature changes structural design, requires a new drawing or affects a safety calculation, the feature model should identify that consequence and route the configuration appropriately. It should not merely allow the option and leave engineering to discover the issue after the order is booked. The manufacturing workflows guide explains how these paths connect sales, engineering and production.

    Maintainability is a core feature-model requirement

    A model that works for a product demonstration but becomes difficult to change is not a successful manufacturing model. Product families change frequently: components become obsolete, suppliers change, standards are revised, prices expire and engineering releases new variants.

    Use modular product logic

    Separate reusable modules where possible. Motor selection, enclosure selection, drive selection and documentation requirements may be shared across several product families. Reusable logic reduces duplication, but excessive abstraction can make the model difficult for product owners to understand. The appropriate structure depends on product architecture and platform capabilities.

    Separate concerns

    Keep different types of logic distinguishable:

    • configuration rules determine technical validity;
    • calculation rules derive dimensions, capacities or quantities;
    • BOM rules select components;
    • pricing rules calculate commercial values;
    • workflow rules determine approvals and engineering tasks;
    • content rules select descriptions, images and documents.

    Combining all of these in one large set of opaque expressions makes troubleshooting and change control difficult. A price surcharge should not be hidden inside a technical compatibility rule, and a CAD parameter should not be maintained only in a proposal template.

    Use effective dates and revision control

    Feature models need versioning. A motor may be valid for orders before a discontinuation date but replaced by another item afterward. A revised pressure standard may apply only to new product releases. The system should support, or integrate with systems that support, effective dates, revisions, approvals and traceability.

    Assign rule ownership

    Product management may own market-facing options, engineering may own technical constraints, manufacturing engineering may own assembly logic, and commercial operations may own discount policies. These responsibilities must be documented. A governance process should define who can change a rule, who reviews it, how it is tested and how it is released.

    Testing a feature model

    Testing should cover more than whether each option appears on screen. Manufacturers should test the model as a product-definition system and as an integration component.

    • Positive tests: verify known valid configurations for standard products.
    • Negative tests: attempt incompatible combinations and confirm that the model blocks or explains them.
    • Boundary tests: test minimum, maximum and just-outside-range values.
    • Interaction tests: evaluate combinations involving materials, ratings, dimensions, environment and accessories.
    • Regression tests: rerun approved configurations after every rule or product-data change.
    • BOM tests: verify quantities, alternates, phantom assemblies, revisions and manufacturing-specific components.
    • Pricing tests: confirm that cost, price, surcharge, currency and discount results match approved rules.
    • Integration tests: check identifiers, units, revisions and status values exchanged with ERP, PLM, PDM, CRM or CAD.
    • Workflow tests: confirm that non-standard configurations reach the correct engineering or approval queue.

    Representative test cases should include real product families and difficult combinations, not only simple catalogue examples. Automated testing is especially valuable when a model contains many interacting constraints.

    Implementation approach

    1. Define the product scope. Start with a product family and identify which variations are genuinely supported, not every theoretical possibility.
    2. Document the product architecture. Identify modules, options, parameters, components, alternatives and manufacturing consequences.
    3. Classify requirements. Separate commercial questions, technical inputs, calculated values, BOM effects, pricing effects and workflow triggers.
    4. Capture authoritative data. Establish sources for part numbers, engineering attributes, prices, drawings, revisions and manufacturing status.
    5. Model constraints explicitly. Convert engineering knowledge into testable rules rather than relying on informal tribal knowledge.
    6. Define exception handling. Decide what happens when a request is outside the model: reject it, recommend an alternative, create an engineering review or initiate an ETO process.
    7. Build a representative pilot. Select a product family with meaningful complexity and measurable downstream effects.
    8. Validate with multiple roles. Sales engineering, product management, design engineering, manufacturing engineering, pricing and IT should review the results.
    9. Connect downstream systems carefully. Map identifiers, units, revisions, statuses and ownership before automating orders or BOM transfers.
    10. Establish release governance. Define change requests, approvals, regression tests, deployment procedures and model ownership.

    Implementation planning should include product-model design, migration, integration, testing, adoption and ongoing maintenance. The CPQ implementation guide provides a broader framework.

    Limitations and common failure modes

    Feature models can become too complex

    As options and exceptions accumulate, the number of possible combinations can grow rapidly. A model may become technically correct but operationally unmanageable. Simplifying the product portfolio, grouping common packages and removing obsolete options can be more effective than adding more rules.

    Rules cannot replace incomplete engineering knowledge

    A CPQ system can enforce documented relationships, but it cannot automatically discover every physical, regulatory or production constraint. If experts have not defined the relevant limits, the model may validate an unsafe or impractical result.

    Overly restrictive models frustrate users

    Blocking an invalid combination is useful only when the reason and next action are clear. The interface should explain whether the user must choose another option, provide an additional input or request engineering review.

    Data synchronization can create conflicting truths

    If a component is active in CPQ but obsolete in ERP, or if a CAD parameter differs from the feature-model definition, the process can fail after quotation. Integration architecture and ownership are as important as the rules themselves. Relevant system relationships are discussed in the CPQ integrations guide.

    Not every CPQ system supports deep feature modeling

    Some platforms focus primarily on sales configuration, pricing and quote documents. Others provide deeper constraint logic, BOM generation, engineering calculations, CAD automation or PLM integration. Buyers should verify the documented capabilities of each platform using representative product models rather than assuming that “CPQ” implies manufacturing-grade configuration.

    How to evaluate feature-model capability in CPQ software

    Evaluation question Why it matters
    Can the system represent hierarchical product families and reusable modules? Complex manufacturers need structure without duplicating logic.
    Does it support requires, excludes, alternatives, cardinality and numeric constraints? These are common foundations for technical validation.
    Can rules calculate derived values? Many products depend on dimensions, capacity, performance or load calculations.
    Can users see why a choice is invalid? Explainable validation reduces sales and engineering rework.
    Can the model generate a configurable BOM? Commercial configuration must produce usable downstream data where required.
    How are EBOM and MBOM differences handled? Engineering and manufacturing structures may require different outputs.
    Are revisions, effective dates and approvals supported? Released products and obsolete components must be controlled.
    Can non-standard configurations trigger ETO or engineering review? Not every valid customer requirement is a standard CTO result.
    How are model changes tested? Complex rule changes can create regressions across product families.
    Can the platform integrate with ERP, PLM, PDM, CAD and CRM? Configuration data must reach the systems that execute the order.

    Demonstrations should use actual or representative products: a pump with material and duty constraints, a machine with dimensional calculations, or an electrical enclosure with thermal and compliance rules. Ask the vendor to show model maintenance, error explanations, test execution and revision handling, not only the customer-facing configurator.

    Benefits of a well-designed feature model

    • Faster technical quoting: sales engineers spend less time checking routine combinations manually.
    • Fewer configuration errors: incompatible options can be prevented before an order reaches engineering or production.
    • Consistent product knowledge: approved rules become reusable across direct sales, dealers and self-service channels.
    • Better engineering handoff: requirements, selected options and derived values are captured in structured form.
    • More reliable BOM and pricing outputs: product and commercial results are linked to the same configuration decisions.
    • Improved product governance: changes can be reviewed, tested and released rather than hidden in spreadsheets or individual expertise.
    • Support for scalable product variation: manufacturers can offer controlled customization without creating an unmanaged catalogue of separate products.

    Related concepts

    Feature models are closely related to several CPQ and engineering concepts:

    Semantic map

    The following relationships summarize how feature models fit into manufacturing CPQ:

    • CPQ uses feature models to represent configurable product families.
    • Feature models contain features, options, parameters and product modules.
    • Configuration rules constrain relationships between features.
    • Constraint validation prevents invalid product combinations.
    • Engineering calculations derive values from configuration inputs.
    • Configured products resolve configurable BOMs.
    • EBOM data represents engineering product structure.
    • MBOM data represents manufacturing assembly structure.
    • Pricing rules calculate commercial values from configuration data.
    • CAD automation can use configuration parameters to generate product-specific models and drawings.
    • CPQ exchanges configuration and order data with ERP.
    • PLM and PDM can govern released product definitions and revisions.
    • Non-standard configurations can trigger ETO engineering workflows.

    Frequently asked questions

    1. What is a feature model in CPQ?

    A feature model is a structured representation of product features, options, values and constraints used to create valid configurations. In manufacturing CPQ, it can also drive BOM, pricing, engineering and workflow outputs.

    2. Is a feature model the same as a product catalogue?

    No. A catalogue lists products or options, while a feature model describes how options relate and which combinations are valid. A feature model represents product variability and logic.

    3. What is the difference between a feature and an option?

    A feature is a decision point or product characteristic, such as seal type. An option is a value under that feature, such as mechanical seal or gland packing.

    4. Can a feature model include dimensions?

    Yes. Manufacturing feature models often include numeric parameters such as length, capacity, pressure, temperature, payload or motor power, together with ranges, units and calculation rules.

    5. How do feature models prevent configuration errors?

    They apply constraints such as requires, excludes, range and conditional rules. The system can block incompatible selections or route exceptions for engineering review.

    6. What is a configurable BOM?

    A configurable BOM contains conditional or alternative components that are resolved according to feature selections. It is different from a single fixed BOM for one product variant.

    7. Does every manufacturing CPQ system generate a BOM?

    No. BOM generation is a platform capability that must be verified. Some CPQ systems focus on configuration, pricing and quoting and require another system to create or resolve the BOM.

    8. Can a feature model drive CAD automation?

    It can when the CPQ platform and connected CAD or engineering systems support that integration. Configuration parameters may drive templates, dimensions, models or drawings, but this is not universal CPQ functionality.

    9. How does a feature model support engineer-to-order products?

    It can capture requirements, identify a standard base product and detect non-standard inputs. The model can then route the request to engineering instead of treating it as a routine configure-to-order result.

    10. What is the difference between rules-based and constraint-based configuration?

    Rules-based configuration uses explicit conditional statements. Constraint-based configuration evaluates permitted relationships and values across a solution space. Many manufacturing platforms combine both approaches.

    11. Should pricing rules be stored in the feature model?

    Pricing can be linked to feature selections, but technical rules and commercial rules should remain distinguishable. Clear separation makes ownership, testing and future pricing changes easier.

    12. Who should own a manufacturing feature model?

    Ownership is usually shared. Product management may own market options, engineering technical constraints, manufacturing engineering production logic, and commercial teams pricing. A named model owner should coordinate changes and governance.

    13. How should obsolete components be handled?

    Use controlled revisions, effective dates and replacement logic where supported. The CPQ model, ERP and engineering systems must agree on component status and validity dates.

    14. Can the same feature model serve sales and engineering?

    Often yes, but users may need different views. Sales may answer application questions while engineering reviews detailed parameters. Both views should use a consistent underlying definition where practical.

    15. What happens when a customer requests an unsupported combination?

    The system should explain the issue and provide an approved alternative, request additional information or initiate an engineering review. Automatically accepting every exception weakens the value of the model.

    16. How are feature models tested?

    Test valid and invalid combinations, boundaries, calculations, BOM results, pricing, revisions, integrations and workflow routing. Regression tests are important after changes to shared rules.

    17. How do feature models relate to PLM and PDM?

    Product lifecycle management (PLM) and product data management (PDM) often govern released engineering structures, revisions and CAD data. CPQ may consume selected data and apply commercial or configuration logic for quoting.

    18. Is guided selling a feature model?

    Not necessarily. Guided selling is a user experience that asks questions or recommends products. It may use a feature model, but a questionnaire without technical validation is not a complete manufacturing product model.

    19. What is the biggest feature-model implementation risk?

    A major risk is encoding undocumented or inconsistent product knowledge. Other risks include duplicated rules, unclear data ownership, poor revision control and insufficient testing with real product combinations.

    20. How should manufacturers start modeling a complex product family?

    Begin with a representative family, document its architecture and constraints, identify authoritative data sources, define standard and non-standard paths, and validate the model with sales, engineering, manufacturing and IT before expanding.

  • Dimensional Product Configuration for Made-to-Measure Products

    Dimensional product configuration allows a manufacturing Configure, Price, Quote (CPQ) system to create a valid, priced and manufacturable product from customer-specific measurements. Instead of selecting only predefined options, the user enters dimensions such as length, width, height, diameter, capacity or opening size. The CPQ product model then applies engineering rules, calculates dependent values, selects components, determines price and may produce a bill of materials (BOM), CAD output or manufacturing handoff.

    This capability is important for manufacturers selling made-to-measure equipment, enclosures, conveyors, tanks, doors, windows, ductwork, heat exchangers, platforms, cabinets, vehicle bodies and other products whose geometry changes with the order. It is more than a sales form. A manufacturing configurator must connect customer requirements with product engineering, costing, production data and downstream enterprise systems.

    Dimensional configuration is usually implemented as part of a broader product configuration model. Depending on the product and software architecture, it may also use CAD and engineering automation, configurable BOM logic, pricing calculations and integration with ERP, PLM or PDM systems.

    What is dimensional product configuration?

    Dimensional product configuration is the rules-based generation of a product variant from variable physical measurements and related engineering parameters.

    A dimensional configurator does not simply store a measurement on an order. It evaluates whether the measurement is allowed, calculates values that depend on it, identifies compatible components and creates downstream data for quoting or production. For example, a configurator for a belt conveyor may accept conveyor length, belt width, incline angle, material type and load. It can then calculate drive requirements, select frame sections, determine support spacing and generate a product-specific BOM.

    The term made-to-measure normally describes products that vary within defined dimensional ranges. It does not necessarily mean that every order is a completely new engineering project. A well-designed product model defines the boundaries within which the product can be configured repeatedly and safely.

    How dimensional configuration differs from ordinary option selection

    Traditional option-based configuration selects from fixed choices such as motor type, paint finish or control voltage. Dimensional configuration introduces continuous or semi-continuous variables. A user may enter 2,450 millimetres rather than select a standard length of 2,000 or 3,000 millimetres.

    Configuration type Typical input Manufacturing implication
    Option selection Motor family or material grade Selects a predefined item or rule branch
    Dimensional configuration Length, diameter or opening size May change geometry, quantities, calculations and fabrication
    Constraint-based configuration Several related dimensions and requirements Checks relationships and rejects invalid combinations
    Engineer-to-order configuration Dimensions outside the standard model May require engineering review or additional design work

    These approaches often operate together. A configurable pump skid may combine dimensional inputs for frame length with discrete selections for pump model, material, motor voltage and instrumentation.

    The product model behind dimensional configuration

    The product model is the structured representation of what can be sold and how it must be built. For dimensional products, it should separate customer-facing inputs from internal engineering variables and manufacturing outputs.

    Customer-facing parameters

    These are the values a salesperson, dealer, engineer or customer enters. Examples include:

    • overall length, width and height;
    • inside or outside diameter;
    • clear opening, working area or usable volume;
    • load, flow rate, pressure or capacity;
    • operating temperature and environmental conditions;
    • mounting location, connection size and orientation;
    • material, finish, insulation or regulatory requirement.

    Input definitions should include units, permitted ranges, precision, default values and whether the value is mandatory. A system should also identify whether a dimension is customer-specified, calculated, inherited from another value or controlled by a standard.

    Calculated parameters

    Calculated parameters convert requirements into engineering values. A tank configurator may calculate shell area, volume, material mass and reinforcement requirements. A duct configurator may calculate cross-sectional area, pressure loss assumptions and panel counts. A machine enclosure configurator may calculate sheet-metal blank sizes, door clearances and the number of mounting rails.

    Rules and constraints

    Rules describe what is permitted and what must happen when a value changes. A minimum and maximum rule might restrict a platform width to a defined range. A dependency rule might require additional supports when length exceeds a threshold. A compatibility rule might prevent a selected motor from being used with a particular voltage or frame size.

    Rules should be expressed in a maintainable form rather than hidden in application code wherever possible. They need owners, test cases, version control and an explanation that an application engineer can understand.

    Dimensional rules and engineering constraints

    Dimensional rules commonly fall into several categories:

    Rule category Example Purpose
    Range rule Tank diameter must be between 600 and 3,000 mm Prevents unsupported sizes
    Relationship rule Door height must be less than enclosure height minus clearance Maintains geometric feasibility
    Increment rule Cut length must be supplied in 5 mm increments Matches material or machine capability
    Conditional rule Lengths above 4,000 mm require a centre support Adds required components
    Compatibility rule A selected actuator is unavailable above a defined load Prevents unsafe or unsuitable combinations
    Calculation rule Motor power is selected from load and speed Automates engineering selection
    Approval rule Non-standard pressure or temperature requires engineering review Separates standard configuration from ETO work

    Some products require constraint solving rather than a simple sequence of if-then statements. For example, a heat exchanger may need to satisfy flow, pressure drop, temperature and material constraints simultaneously. The configurator may use a calculation service, selection algorithm or engineering application to find an appropriate design. Buyers should verify how a CPQ platform handles such logic instead of assuming that every rules engine supports advanced constraint solving.

    Worked example: a made-to-measure industrial enclosure

    Consider an enclosure manufacturer selling electrical cabinets in custom widths, heights and depths. The customer enters an external width of 1,200 mm, height of 1,800 mm and depth of 400 mm, then selects stainless steel, a sealed door, a cooling unit and a defined ingress-protection requirement.

    The product model may perform the following sequence:

    1. Validate that the dimensions are within the supported manufacturing range.
    2. Calculate usable internal volume after wall thickness, door clearance and mounting space.
    3. Check that the selected cooling unit fits the available surface and heat-load requirement.
    4. Determine sheet-metal panels, doors, hinges, locks, mounting rails, seals and fasteners.
    5. Apply material, finish, labour and purchased-component costs.
    6. Generate a configured BOM and, where supported, send geometry parameters to CAD automation.
    7. Produce a quote and flag the order for engineering approval if a rule is exceeded.

    A simple option configurator might capture the same dimensions but still require an engineer to calculate panel sizes and create the BOM. A manufacturing CPQ solution adds value when the dimensional logic is connected to repeatable engineering and production outputs.

    Relationship between dimensions, BOMs and CAD

    A bill of materials is the structured list of components required to build a product. An engineering BOM (EBOM) describes the product from an engineering perspective, while a manufacturing BOM (MBOM) organizes parts and operations for production. A configurable BOM contains rules that determine which items, quantities or variants apply to a particular configuration.

    Dimensions can affect all three representations. Increasing the length of a conveyor may add frame sections, idlers, guards, cable lengths and supports. Increasing the diameter of a vessel may change shell plates, nozzles, reinforcement rings and welding operations. The CPQ system may generate an EBOM directly, pass configuration data to a product lifecycle management (PLM) or product data management (PDM) system, or send order-specific data to an ERP system that creates production structures.

    CAD automation is a separate capability. A CPQ system may pass dimensional parameters to a parametric CAD model, invoke a design automation service or generate a drawing package. Not every CPQ product provides this functionality. Where CAD output is required, the implementation must define model ownership, revision control, drawing approval, file formats and the point at which engineering releases the design.

    Pricing and costing for dimensional products

    Dimensional inputs frequently influence price through material quantity, cutting length, surface area, weight, fabrication time, purchased components and transport requirements. Pricing should therefore be distinguished from configuration. The configuration determines what the product is; the pricing model determines what it costs or what the customer is charged.

    For a made-to-measure duct section, for example, price may depend on sheet area, gauge, insulation, number of seams, fittings and installation accessories. A tank may require separate calculations for material mass, welding hours, testing and surface treatment. A CPQ system can perform these calculations, but the source data and formulas must be governed. Cost rates, supplier prices, labour assumptions and commercial markups require different ownership from engineering constraints.

    Read more about BOM generation, costing, pricing and quote automation.

    Where dimensional configuration fits in the manufacturing workflow

    Dimensional configuration can support several operating models:

    • Configure-to-order (CTO): the customer selects within a validated product family and the system produces repeatable manufacturing data.
    • Make-to-order (MTO): the product is made after the order, often using standard or configurable components.
    • Engineer-to-order (ETO): the requirements require design work, calculations or approval beyond the standard product model.
    • Assemble-to-order (ATO): standard subassemblies are combined after the order, with dimensions possibly determining the selected combination.

    A useful workflow distinguishes standard dimensional variation from genuine engineering exceptions. A dimension outside the supported range should not be forced through the configurator simply to complete a quote. It should create an engineering review, an ETO task or a controlled request for a new product-model version.

    The resulting data may move from CPQ to customer relationship management (CRM), enterprise resource planning (ERP), PLM, PDM, manufacturing execution system (MES) or CAD systems. These systems are not interchangeable: CRM manages customer and opportunity information, ERP manages commercial and operational transactions, PLM and PDM manage product data and revisions, MES manages shop-floor execution, and CAD manages geometric design.

    See the guide to configure-to-order, engineer-to-order and sales-to-engineering workflows and the overview of CPQ integrations.

    Benefits of dimensional product configuration

    • Faster quoting: sales engineering can produce a technically bounded quote without manually rebuilding calculations for every inquiry.
    • Fewer configuration errors: invalid dimensions, incompatible components and missing dependencies can be blocked before order entry.
    • Reduced repetitive engineering: standard calculations and drawings can be reused for products within the approved model.
    • More consistent pricing: material, labour and component effects can be calculated from the same configuration data.
    • Better sales-to-production handoff: the order contains structured dimensions and selections rather than only free-text notes.
    • Improved product knowledge: rules make implicit engineering decisions visible and testable.

    Limitations and risks

    Dimensional CPQ does not remove the need for engineering judgment. It can only automate logic that has been defined, tested and maintained. Products with poorly documented design knowledge often expose the greatest implementation difficulty.

    • Rules can become difficult to maintain when one product model contains too many exceptions.
    • Engineering formulas may depend on assumptions that are not recorded in the CPQ model.
    • CAD, BOM and ERP integrations can create revision and synchronization problems.
    • Rounding, units and tolerances can produce different results between systems.
    • Commercial pricing may change faster than engineering rules, requiring separate governance.
    • Non-standard requests can be incorrectly presented as standard configurations.
    • Highly complex products may require specialist calculation or constraint software rather than only a CPQ rules engine.

    Validation must cover boundary values, unit conversions, calculated dimensions, unavailable components, revision changes and combinations that should be rejected. Test data should include realistic product families rather than only simple examples.

    Implementation approach

    1. Define the standard configuration boundary

    Document which dimensions, materials and options can be sold without engineering intervention. Identify the point at which a request becomes ETO or requires approval.

    2. Inventory product knowledge

    Collect drawings, spreadsheets, selection charts, calculation methods, BOM structures, price formulas and exception rules. Resolve conflicting sources before building the model.

    3. Separate inputs, rules and outputs

    Define customer inputs separately from calculated engineering values, commercial values and manufacturing outputs. This improves traceability and makes changes safer.

    4. Establish units and precision

    Specify the system of measurement, display precision, calculation precision, rounding policy and tolerances. A value displayed as 2,450 mm may be stored and calculated at a different precision.

    5. Assign ownership

    Product engineering should own technical constraints, manufacturing should validate production structures, commercial teams should own pricing policy and IT should govern integrations and environments.

    6. Test the model

    Test normal configurations, minimum and maximum dimensions, threshold transitions, incompatible selections, obsolete components and deliberately invalid combinations. Compare generated BOMs, drawings and prices with approved reference outputs.

    7. Plan releases and change control

    Product models need versioning. A rule change may affect open quotes, released orders, CAD files, BOMs and ERP item references. The implementation should define when an old configuration remains valid and how historical outputs are preserved.

    The broader CPQ implementation guide covers requirements, testing, governance, deployment and maintenance in more detail.

    How to evaluate a dimensional CPQ configurator

    When evaluating software, manufacturers should ask practical questions rather than count generic features:

    • Can the system model continuous dimensions, ranges, increments, tolerances and units?
    • Can calculated values be reused across rules, pricing, BOMs and documents?
    • Can the model distinguish standard configurations from engineering-review cases?
    • Can rules be maintained by authorized product experts without uncontrolled code changes?
    • Can the system generate or exchange configurable BOM data?
    • Can it integrate with the required CAD, PLM, PDM, ERP and CRM systems?
    • How are revisions, approvals, test cases and historical configurations managed?
    • Can the architecture support dealer, internal sales, ecommerce or API-based channels?
    • What happens when a dimension changes after a quote, order or engineering release?

    Some platforms focus mainly on guided selling and quote generation. Others include deeper product configuration, engineering calculations, BOM generation or CAD automation. These capabilities should be verified against documented product behavior and a representative manufacturer product model.

    Semantic map

    The following relationships summarize the main entities and data flows in dimensional product configuration:

    • CPQ configures made-to-measure products.
    • Dimensional inputs drive engineering calculations.
    • Configuration rules prevent invalid combinations.
    • Constraints define supported product boundaries.
    • Calculated parameters determine dependent dimensions.
    • Configured products generate configurable BOMs.
    • Dimensions influence material quantities and costs.
    • CAD automation generates product-specific drawings.
    • CPQ exchanges configuration data with ERP.
    • PLM manages product revisions and engineering definitions.
    • PDM controls product files and design records.
    • ETO handles requirements outside the standard model.
    • Rules governance maintains product-model integrity.
    • Manufacturing data connects sales configuration with production.

    Conclusion

    Dimensional product configuration is the foundation for quoting and producing many made-to-measure industrial products. Its purpose is not merely to capture customer measurements. A robust model validates dimensions, applies engineering relationships, selects compatible components, calculates price and cost, and transfers structured data to the systems that support design and production.

    The strongest implementations begin with a clearly defined standard product boundary and maintainable product rules. They distinguish configuration from pricing, EBOM from MBOM, standard CTO work from ETO work, and CPQ from the ERP, PLM, PDM, CAD and MES systems around it. With those boundaries established, a dimensional configurator can reduce repetitive engineering while preserving the controls needed for safe and manufacturable products.

    Frequently asked questions

    What is dimensional product configuration?

    It is the process of creating a valid product variant from customer-specific measurements and related engineering requirements. The system may calculate dependent values, select components, determine price and generate manufacturing data.

    Is dimensional configuration the same as product configuration?

    Dimensional configuration is a specialized form of product configuration. General product configuration may select options, while dimensional configuration also evaluates variable physical measurements and their engineering relationships.

    What products benefit from dimensional configuration?

    Common examples include conveyors, tanks, enclosures, ductwork, windows, doors, platforms, vehicle bodies, heat exchangers, cabinets and other products whose geometry or material usage changes by order.

    Can a CPQ system accept arbitrary dimensions?

    It can accept variable dimensions only within the limits represented by the product model. Unsupported sizes should trigger an error, approval or engineer-to-order process rather than being treated as automatically valid.

    How do dimensional rules prevent manufacturing errors?

    They enforce ranges, increments, clearances, compatibility relationships and required components before the configuration becomes an order. This prevents many errors that would otherwise appear during engineering or production.

    What is the difference between a dimension and a calculated parameter?

    A dimension may be entered by the user, such as enclosure width. A calculated parameter is derived from inputs, such as usable internal width, panel area or required support spacing.

    Does dimensional CPQ require CAD automation?

    No. CAD automation is optional and depends on the product and platform. A configurator can validate dimensions and generate pricing or BOM data without creating CAD files, although CAD automation may reduce repetitive design work.

    Can dimensional configuration generate a BOM?

    Some manufacturing CPQ systems can generate or contribute to a configurable BOM. Others pass structured configuration data to ERP, PLM or another engineering system that creates the BOM. This capability must be verified for the specific platform.

    How do dimensions affect product pricing?

    Dimensions can change material area, weight, cutting length, fabrication time, purchased components, packaging and transport. Pricing logic can use these values, but the commercial formulas must be governed separately from engineering rules.

    What is the difference between EBOM and MBOM in dimensional configuration?

    An EBOM represents the product from an engineering perspective. An MBOM organizes the materials and structures needed for manufacturing. A dimensional configuration may influence both, but they serve different downstream purposes.

    When should a dimensional request become ETO?

    A request should become engineer-to-order when it exceeds approved dimensional ranges, requires a new design, needs an unvalidated calculation or introduces a manufacturing method not covered by the standard product model.

    How should units and rounding be handled?

    The implementation should define calculation units, display units, precision, rounding and tolerance rules. These standards must be consistent across CPQ, CAD, BOM, ERP and manufacturing outputs.

    Who owns dimensional configuration rules?

    Technical constraints normally belong to product or application engineering. Manufacturing validates production implications, commercial teams own pricing policy and IT governs integrations, environments and access.

    Can dealers use a dimensional configurator?

    Yes, if the system supports the required channel and permissions. Dealers may receive a simplified interface while the manufacturer retains control of technical rules, approvals, pricing and engineering outputs.

    How are dimensional product models tested?

    Testing should include valid configurations, boundary dimensions, threshold changes, unit conversions, invalid combinations, obsolete parts, price changes and comparisons with approved BOM or CAD reference outputs.

    How does dimensional CPQ integrate with ERP?

    It may send the configured product, quantities, prices, customer information and order details to ERP. The exact integration depends on system ownership, item structures, revision rules and whether the CPQ or ERP creates the production BOM.

    Can AI replace dimensional configuration rules?

    AI may assist with recommendations, natural-language input or analysis, but validated engineering constraints still need explicit control. A manufacturer should not rely on probabilistic output to enforce safety, compatibility or production rules.

  • Configuration Model Versioning for Manufacturing CPQ

    Configuration model versioning is the controlled management of successive revisions of a configurable product model, including its options, constraints, calculations, prices, bill of materials (BOM) logic and downstream engineering outputs. In manufacturing Configure, Price, Quote (CPQ), versioning ensures that a quote or order uses the correct product rules for the relevant date, customer agreement, engineering release or production period.

    This matters because a manufacturing configuration is more than a list of sales options. A model for an industrial pump, electrical panel, heat exchanger or material-handling vehicle may determine whether a motor is permitted, calculate performance requirements, select components, generate a configurable BOM, produce a computer-aided design (CAD) drawing and send manufacturing data to an enterprise resource planning (ERP) system. If those rules change without traceable version control, the same customer selection can produce different results at different times.

    A practical versioning strategy gives every released model a clear identity, effective dates, change history, approval status and relationship to related data. It also makes it possible to reproduce an old quote accurately while allowing new quotes to use the current product definition.

    For background, see the guide to product configuration and configuration rules and the broader guide to manufacturing CPQ software.

    What is a configuration model?

    A configuration model is the structured representation of a configurable product. It describes what can be selected, what combinations are valid, how technical requirements are calculated and what outputs should be created for a valid configuration.

    A model can contain several related layers:

    • Product structure: families, modules, assemblies, components and selectable features.
    • Attributes: dimensions, capacity, voltage, pressure, material, finish, temperature range or other parameters.
    • Options: motors, accessories, control packages, enclosures, mounting arrangements or service packages.
    • Rules: dependencies, exclusions, requirements, ranges and conditional logic.
    • Calculations: sizing, performance, load, flow, thermal, electrical or cost calculations.
    • Outputs: price, cost, BOM, engineering notes, CAD parameters, drawings and quote content.
    • External references: item numbers, engineering documents, ERP materials, product lifecycle management (PLM) objects or CAD templates.

    For example, a pump configuration model may accept flow rate, head, fluid type, temperature and installation arrangement. It may then restrict materials, calculate a suitable impeller diameter, select a motor range and generate a product-specific BOM. The model is therefore a combination of commercial, technical and manufacturing knowledge.

    What does configuration model versioning mean?

    Configuration model versioning means creating identifiable, controlled revisions of that model rather than overwriting its current state. Each version can record which options, rules, calculations, component references and outputs were valid at a particular point in time.

    A version may be associated with:

    • a product release or engineering change;
    • a sales effective date;
    • a manufacturing effective date;
    • a regional or market-specific offering;
    • a customer-specific contract or approved configuration;
    • a price-list period;
    • a compatible CAD or ERP release;
    • a replacement or obsolescence decision.

    The goal is not simply to keep numbered copies of files. The goal is to control the behavior of the product model throughout the quote-to-order and order-to-production lifecycle. A quote created under version 3.2 should remain understandable even after version 4.0 introduces a new motor family or removes an obsolete material.

    Why versioning is important in manufacturing CPQ

    Generic sales CPQ may mainly version discounts, product catalogs and price books. Manufacturing CPQ often needs to version the technical definition of a product as well. A change to one rule can affect feasibility, cost, lead time, BOM structure, drawings and production instructions.

    Preserving quote and order accuracy

    Suppose a customer receives a quote for a stainless-steel pump with a specific seal, motor and control panel. Two months later, the standard seal is replaced because of a supplier change. If the old quote is recalculated using the new model without review, the price, technical description or BOM may no longer match the offer accepted by the customer.

    Versioning allows the business to distinguish between the model used to create the quote and the model approved for new opportunities. The old quote can be reproduced, while a controlled transition process determines whether an accepted order should be migrated to the new release.

    Supporting engineering change control

    Engineering changes often have a defined effective date, serial-number range or production order boundary. Configuration model versioning connects the commercial product model to that change process. It can identify which rules, components and CAD templates changed, who approved the change and which open quotes or orders might be affected.

    Maintaining downstream consistency

    Product data is usually distributed across several systems. A product lifecycle management (PLM) or product data management (PDM) system may control engineering documents and CAD files. An ERP system may control item masters, inventory and production orders. A customer relationship management (CRM) system may hold opportunities and accounts. CPQ may control the interactive configuration and quote calculation.

    Without version alignment, CPQ can generate a BOM that refers to an obsolete ERP item, a CAD output based on a different rule set or a quote using a price that does not correspond to the released design. Version identifiers provide a basis for checking compatibility across these systems. See the guide to CPQ integrations with ERP, CRM, PLM, PDM and CAD.

    What should be versioned?

    Manufacturers should define the version boundary deliberately. Versioning only the visible option list is usually insufficient.

    Model element Example Why version it
    Product structure Adding a new hydraulic module Changes available selections and downstream assemblies
    Configuration rules High-temperature fluid requires a specific seal Controls technical validity and safety
    Parameters and ranges Permitted enclosure dimensions Prevents invalid or non-manufacturable values
    Engineering calculations Motor sizing or pressure-drop formula Can change selected components and performance
    Configurable BOM logic Include a cooling fan above a power threshold Determines manufacturing and purchasing content
    Prices and costs Material surcharge or labor factor Preserves commercial reproducibility
    CAD mappings Parameter-to-drawing or template references Ensures drawings match the selected design
    Integration mappings CPQ option to ERP material number Prevents incorrect order and inventory data
    Documentation Installation notes or compliance certificates Keeps quote and production documents aligned

    Some organizations maintain separate versions for technical configuration, pricing and documentation. That can be useful when prices change frequently but the engineering model remains stable. However, the CPQ architecture must record the exact combination used for each quote and order. Otherwise, separate version numbers can create ambiguity.

    Common versioning approaches

    Snapshot versioning

    Snapshot versioning stores a complete, immutable copy of the model at release. A quote references the snapshot that was used. This is straightforward to audit and makes historical reproduction reliable.

    The limitation is data duplication. A large product model may contain many repeated rules or references. Snapshot storage also requires a clear process for carrying approved changes into the next version.

    Revision-based versioning

    Revision-based versioning assigns revisions such as A, B, C or 1.0, 1.1 and 2.0. A minor revision might correct wording or a non-technical presentation issue, while a major revision might change product structure or technical rules.

    Revision numbers are useful for communication, but the number alone does not define behavior. The system should also store the actual changed elements, approval state, effective dates and dependencies.

    Effective-dated versioning

    Effective-dated versioning determines which model applies based on a date. For example, a new valve material may apply to quotes created after 1 July, while orders already released continue under the previous model.

    Date-based logic must account for different dates in the workflow. Quote date, customer acceptance date, order date, requested delivery date and manufacturing release date may not be the same. Manufacturers should define which date controls each business decision.

    Configuration baseline versioning

    A baseline captures an approved combination of model version, rules, price list, BOM logic, CAD references and external data mappings. It is particularly useful for engineered products and long sales cycles, where a project must remain stable while related product models continue to evolve.

    Branching and variant versioning

    Some manufacturers need parallel variants for regions, brands, customers or production sites. A branch may inherit a common core model while changing local certifications, voltage standards, materials or pricing.

    Branching can reduce duplication, but it introduces merge and governance problems. A correction made in the global model may need to be evaluated separately for every regional branch. Branches should therefore have explicit ownership and a documented relationship to the base model.

    Configuration model versioning in a manufacturing workflow

    1. Model definition: Product management and engineering define structure, options, parameters, constraints and calculations.
    2. Development: A model administrator implements the changes in a controlled workspace or draft version.
    3. Validation: Sales engineering, design engineering, manufacturing and commercial teams test expected and invalid combinations.
    4. Approval: Authorized owners approve the release and identify effective dates, affected systems and migration requirements.
    5. Publication: The version becomes available to the appropriate sales channels, such as direct sales, dealers or ecommerce.
    6. Configuration: A user selects product requirements and receives validation feedback.
    7. Output generation: CPQ calculates price and cost and may create a BOM, engineering specification, drawing request or CAD output.
    8. Order handoff: The accepted configuration and version identifiers are sent to ERP, PLM, PDM, CRM or manufacturing systems as appropriate.
    9. Monitoring: The organization reviews errors, overrides, rejected configurations and change requests.

    The exact outputs depend on the CPQ platform. Some systems manage product rules and quotes but do not generate manufacturing BOMs or CAD files. Others connect to specialist engineering and product data systems. The implementation should document which system is authoritative for each output.

    Example: versioning an industrial air-handling unit

    Consider a configurable air-handling unit with airflow, casing dimensions, filter class, fan type, coil material, voltage and controls.

    In version 5.0, a particular fan is allowed for a defined airflow range. A new version introduces a higher-efficiency fan and changes the minimum service clearance. The change affects more than the option name:

    • the rule engine must prevent incompatible dimensions and fan selections;
    • the engineering calculation must use the revised efficiency data;
    • the configurable BOM must select the new fan assembly and mounting hardware;
    • the CAD template must reflect the changed connection locations;
    • the price and cost model must include the new component;
    • the quote must explain any change in lead time or technical performance;
    • the ERP mapping must reference the correct released materials.

    An open quote created with version 5.0 may remain on that version until its validity period ends. A new opportunity may use version 5.1. An accepted order may require a formal engineering review before migration because the new fan changes the approved design. Versioning makes these decisions explicit rather than accidental.

    Rules for handling old quotes and orders

    There is no universal policy for every manufacturer. Common policies include:

    Policy Use case Risk to manage
    Lock the original model Long-lived quotes or legally significant proposals Old components may become unavailable
    Recalculate using the current model Short quote validity periods Technical and commercial results may change
    Allow controlled migration Orders affected by approved engineering changes Requires impact analysis and approval
    Freeze technical data but refresh price Stable design with changing material or labor costs Technical and commercial versions must be recorded separately
    Require reconfiguration Safety, compliance or availability changes Can delay the order and require customer communication

    At minimum, a quote or order record should preserve the model version, rules version, price-list version, configuration selections, calculated values, generated outputs and any manual overrides.

    Versioning and BOM, CAD and engineering outputs

    A bill of materials is not always a single list. An engineering BOM (EBOM) represents the design structure, while a manufacturing BOM (MBOM) represents how the product is assembled and produced. A configurable BOM may contain rules that include or exclude items based on the selected configuration.

    When a model changes, the organization should determine whether the change affects the EBOM, MBOM, both or neither. For example, changing a sales description may not affect either BOM. Replacing a motor may affect the EBOM, MBOM, purchasing items, cost and assembly instructions.

    CAD automation may also be version-sensitive. A parametric drawing template, design table or three-dimensional model must be compatible with the model version and its calculated dimensions. A versioned CPQ model should not call an old CAD template for a new geometry rule without a compatibility check.

    Detailed relationships between configuration, BOM and quote outputs are covered in BOM generation, pricing and quote automation and CAD and engineering automation for CPQ.

    Data architecture and version identifiers

    A useful version record commonly includes:

    • product family and model identifier;
    • version or revision number;
    • status such as draft, in review, released, superseded or retired;
    • creation, approval and effective timestamps;
    • owner and approving roles;
    • change description and reason;
    • parent version or inherited model;
    • compatible price, BOM, CAD and documentation versions;
    • supported regions, channels, plants or customer segments;
    • migration and replacement instructions;
    • test results and known limitations.

    Identifiers should be stable and machine-readable. Display labels can change, but an integration should not depend only on a product name such as “Standard Pump.” It should receive a durable product and version identifier, together with the configuration instance or transaction identifier.

    Where systems exchange data through application programming interfaces (APIs), the payload should make version context explicit. A downstream system should be able to determine whether it received a draft, released or retired model and whether the referenced ERP materials and documents are compatible.

    Governance and ownership

    Versioning is both a technical and organizational control. A model becomes difficult to maintain when sales, engineering, product management and IT can change rules independently without a common release process.

    Typical responsibilities include:

    • Product management: defines commercial offerings, option lifecycle and market applicability.
    • Engineering: owns technical rules, calculations, performance limits and design references.
    • Manufacturing: validates assembly logic, MBOM impact, routings and production feasibility.
    • Commercial operations: maintains price logic, discount policies and quote presentation.
    • IT or CPQ administration: manages environments, security, integrations and deployment.
    • Quality or compliance: reviews regulated, safety-critical or traceability-related changes.

    A change-control board may be appropriate for major releases, but not every text correction should require the same process. Define change classes, approval thresholds and emergency procedures. Record who approved a model and why.

    Testing configuration model releases

    Testing should cover more than whether the configuration screen loads. A release should be tested against representative manufacturing scenarios and known edge cases.

    • Rule tests: Verify required, excluded and conditional options.
    • Boundary tests: Test minimum and maximum dimensions, pressures, temperatures, loads and electrical values.
    • Calculation tests: Compare outputs with approved engineering calculations or reference cases.
    • BOM tests: Confirm that configurable items, quantities, alternates and phantom assemblies are correct.
    • Pricing tests: Check material, labor, overhead, surcharges, discounts and currency behavior.
    • CAD tests: Confirm that dimensions, interfaces and drawing annotations correspond to the configuration.
    • Integration tests: Verify identifiers and payloads sent to ERP, CRM, PLM, PDM or other systems.
    • Regression tests: Ensure that unchanged product families still behave as expected.
    • Migration tests: Evaluate open quotes and orders that may be affected by the release.

    Automated tests are valuable for large rule sets, but expert review remains important for engineering intent and manufacturability. A configuration can be logically valid yet still be impractical to source, assemble or service.

    Implementation recommendations

    1. Define the unit of versioning. Decide whether the version applies to an entire product family, a module, a regional variant or a combined release package.
    2. Separate draft from released data. Sales users should not accidentally configure against an unfinished rule change.
    3. Make releases immutable. Correct a released model by creating a new controlled revision rather than editing historical behavior in place.
    4. Record effective dates explicitly. Define whether the date controls quoting, order acceptance, production release or another event.
    5. Map dependencies. Identify related BOM, CAD, price, ERP, PLM and documentation versions.
    6. Preserve transaction context. Store the model and rule versions used for every quote, order and generated output.
    7. Use regression libraries. Maintain approved configurations for each major product family and test them after every significant change.
    8. Plan for obsolete components. A historical model may need to remain readable even after an item is no longer purchasable.
    9. Define migration rules. Explain when an open quote can be upgraded automatically and when engineering approval is required.
    10. Monitor model quality. Track overrides, invalid selections, manual corrections, failed integrations and frequent support requests.

    For a broader implementation method, see the guide to manufacturing CPQ implementation, testing and governance.

    Limitations and common failure modes

    Version numbers without behavioral control

    A revision label is not enough if users can change shared rules, price tables or CAD references outside the release process. The complete dependency set must be controlled.

    Overwriting released models

    Editing a released model in place can make old quotes impossible to reproduce. This is especially dangerous when a quote stores only selections rather than a complete model baseline.

    Confusing product version with configuration instance

    A product version describes the rules and structure available at a point in time. A configuration instance describes one customer-specific selection. Both identifiers are needed. Two customers can use the same model version but have different dimensions, materials and BOMs.

    Ignoring external system timing

    Releasing a CPQ model before ERP materials, PLM documents or CAD templates are available can produce technically valid but operationally unusable configurations. Release readiness should include downstream dependencies.

    Creating too many branches

    Regional and customer-specific branches can become difficult to maintain. Use inheritance and shared components where possible, and document which rules are global and which are local.

    Failing to distinguish technical and commercial changes

    A price update may not require a new engineering model, while a component substitution may require a new BOM and CAD release. The versioning design should support these different change types without hiding their relationship.

    Configuration model versioning versus related concepts

    Concept Meaning Relationship to model versioning
    Product revision A change to a product design or released item May require a new configuration model version
    Price-list version A controlled set of prices, costs or commercial conditions May be versioned independently but must be recorded with the quote
    Configuration instance One selected customer-specific product References the model version used to create it
    Engineering change order Formal authorization for a design or process change Can trigger model, BOM, CAD and ERP updates
    Rules engine Software that evaluates constraints and logic Executes the rules contained in a particular model release
    Product lifecycle management Control of product data and lifecycle processes May govern engineering releases that CPQ consumes

    Versioning is therefore a cross-functional control, not merely a feature of the CPQ user interface.

    Semantic map

    The following relationships summarize how configuration model versioning fits into manufacturing CPQ:

    • CPQ uses configuration models to define configurable products.
    • Configuration model versions preserve the behavior of product rules over time.
    • Configuration rules prevent invalid combinations of options and parameters.
    • Engineering calculations determine technical values from customer requirements.
    • Configured products generate configurable BOMs when the platform supports BOM generation.
    • Configurable BOMs may contribute to engineering BOMs and manufacturing BOMs.
    • CAD automation generates product-specific drawings when compatible CAD automation is available.
    • Price-list versions determine commercial values for a configuration.
    • Released model versions support reproducible quotes and orders.
    • CPQ exchanges product and transaction data with ERP, CRM, PLM, PDM and other systems through integrations.
    • Engineering change orders can trigger new configuration model releases.
    • Configuration model governance controls ownership, approval, testing and retirement.

    FAQ

    What is configuration model versioning?

    It is the controlled creation and management of revisions to a configurable product model, including options, rules, calculations, prices, BOM logic and engineering references.

    Why does manufacturing CPQ need model versioning?

    Manufacturing CPQ can influence technical feasibility, BOMs, CAD outputs and production data as well as price. Versioning preserves the exact logic used for a quote or order.

    Is configuration model versioning the same as product revision control?

    No. Product revision control usually focuses on the released design or item. Configuration model versioning controls the selectable product logic and its related outputs. The two processes should be linked.

    Should every price change create a new configuration model version?

    Not necessarily. A separate price-list version can handle commercial changes, provided the quote records both the technical model version and the applicable price version.

    How long should an old configuration model remain available?

    It should remain available for as long as the business needs to reproduce quotes, support orders, meet contractual obligations or satisfy regulatory and traceability requirements.

    Can a released configuration model be edited?

    A released model should generally be immutable. Changes should create a new revision so historical quotes and orders retain their original behavior.

    What is an effective date in CPQ model versioning?

    An effective date specifies when a model version becomes applicable. The organization must define whether it applies to quote creation, order acceptance, production release or another event.

    How are open quotes handled after a model release?

    They can be locked to the original version, recalculated with the new version, or migrated through a controlled review. The appropriate policy depends on quote validity, technical risk and customer commitments.

    Does versioning apply to configurable BOMs?

    Yes. BOM inclusion rules, quantities, alternates and component references can change independently or as part of a model release and should be traceable.

    How does versioning affect CAD automation?

    The model version should reference compatible CAD templates, parameters and drawing logic. Otherwise, a new rule set may generate an incorrect or incomplete design output.

    What is the difference between a model version and a configuration instance?

    The model version defines the rules available at a point in time. The configuration instance is one customer-specific selection created using those rules.

    Should CPQ or PLM own the product model version?

    It depends on the architecture. PLM may own engineering definitions, while CPQ may own sales configuration logic. Ownership and synchronization responsibilities must be explicit rather than assumed.

    How do ERP systems use CPQ version information?

    ERP may use the version context to validate item numbers, BOMs, routings or order data. The integration should communicate stable identifiers rather than relying only on product names.

    What tests are needed before releasing a model version?

    Test valid and invalid combinations, parameter boundaries, calculations, pricing, BOMs, CAD outputs, integrations, regression cases and migration of open quotes or orders.

    Can different regions use different configuration model versions?

    Yes, if regional regulations, voltage standards, materials or commercial policies differ. Regional variants should inherit shared logic where possible and have clear ownership.

    What happens when a component becomes obsolete?

    The old model may remain available for historical traceability, while new configurations use a replacement component. Open orders may require a controlled substitution or engineering review.

    How does versioning support engineer-to-order products?

    For engineer-to-order (ETO) products, versioning preserves the requirements, rules, calculations and design baseline used to create a project-specific engineering package.

    Is versioning needed for configure-to-order products?

    Yes. Configure-to-order (CTO) products may use predefined options, but changes to constraints, component mappings or manufacturing rules can still affect the resulting order.

    What is the biggest implementation mistake?

    The most common mistake is versioning the visible product catalog while leaving shared rules, price tables, CAD references or integration mappings uncontrolled.

    Can a CPQ platform version models automatically?

    Some platforms provide built-in revision, release or effective-date capabilities, while others require configuration, external lifecycle tools or custom governance. This must be verified for each product.

    How should manufacturers measure versioning quality?

    Useful measures include quote reproducibility, invalid-configuration rates, manual overrides, release defects, integration failures, rework caused by outdated data and the time required to approve a model change.

  • Assemblies and Subassemblies in Product Configuration

    Assemblies and subassemblies are the structural building blocks of a configurable product model. In manufacturing CPQ, an assembly is a functional or physical grouping of components, while a subassembly is a lower-level grouping that is installed, tested, purchased or manufactured as part of a larger assembly. Modeling these relationships correctly allows a CPQ configurator to validate customer selections, calculate prices, generate a configurable bill of material (BOM), support engineering automation and pass reliable product data to enterprise systems.

    This is more than a matter of arranging parts in a product tree. A configurable pump skid, industrial conveyor, HVAC unit or specialty vehicle may contain optional assemblies, mutually exclusive subassemblies, quantity-dependent components, variant-specific hardware and engineering calculations. The product model must represent those relationships and apply rules consistently from the initial configuration through quoting, design release and production.

    In manufacturing CPQ, assemblies and subassemblies usually sit between the commercial product definition and the detailed engineering and manufacturing structures. They can influence configuration, costing, pricing, lead time, CAD outputs, engineering review and the final production BOM. The exact capabilities depend on the CPQ platform and its integrations; not every CPQ system creates BOMs, automates CAD or supports deep engineering structures.

    What are assemblies and subassemblies?

    An assembly is a product or functional unit made from multiple components or lower-level assemblies. A subassembly is an assembly used inside a larger assembly. The distinction is relative to the product level being examined: a motor-and-coupling module may be a subassembly of a pump package but a complete assembly for a motor supplier.

    Examples include:

    • A conveyor system containing a drive assembly, frame assembly, guarding assembly and controls assembly.
    • A centrifugal pump package containing a pump assembly, motor assembly, baseplate assembly, coupling guard and instrumentation panel.
    • An air-handling unit containing a fan section, filter section, coil section, damper assembly and control panel.
    • A specialty vehicle containing a chassis assembly, powertrain assembly, hydraulic system, cab assembly and body equipment.

    Assemblies can be defined by physical structure, manufacturing responsibility, serviceability, purchasing strategy or functional behavior. A CPQ model therefore should not assume that every visible product grouping is automatically a manufacturing subassembly. The product structure must reflect how the manufacturer designs, prices, sources, builds and services the product.

    Why assemblies matter in manufacturing CPQ

    A generic sales quoting tool may treat a product as a list of selectable options. A manufacturing CPQ system often needs to understand which components belong together, where they are installed, which options are compatible and what downstream data must be produced.

    Assembly-level modeling helps a manufacturer:

    • organize a large product model into maintainable modules;
    • reuse a common subassembly across multiple finished products;
    • apply rules at the appropriate level of the product structure;
    • calculate quantities, costs, prices, dimensions and capacities;
    • generate configurable engineering or manufacturing BOMs;
    • identify which changes require engineering review;
    • control optional, mandatory, purchased and manufactured content;
    • create product-specific CAD models, drawings or installation documents when supported;
    • send structured data to enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM) or manufacturing execution systems (MES).

    Without this structure, configuration rules become a flat collection of exceptions. That makes them difficult to test and increases the risk that a valid-looking quote produces an incomplete BOM or an unbuildable design.

    How assemblies are represented in a product model

    A product model is the structured definition of a configurable product, including features, options, components, rules, calculations and relationships. Assemblies normally appear as nodes in a hierarchical product tree.

    Industrial pump package
  Pump assembly
    Casing
    Impeller
    Mechanical seal
    Bearing housing
  Drive assembly
    Motor
    Coupling
    Coupling guard
  Baseplate assembly
    Baseplate
    Anchor hardware
  Instrumentation assembly
    Pressure transmitter
    Temperature sensor
    Junction box

    Each node may have attributes such as part number, revision, description, quantity, unit of measure, sourcing type, effective dates, plant, operation, lead time, cost and sales price. A configurable node may also have conditions that determine whether it is included, which variant is selected and how its quantity or parameters are calculated.

    Common assembly attributes

    Attribute Purpose in configuration Manufacturing example
    Assembly type Identifies a standard, configurable, purchased or engineered structure. Standard motor module versus engineered skid assembly.
    Parent relationship Shows where the assembly is installed or used. Control panel installed on the main frame.
    Option condition Controls when the assembly is included. Washdown enclosure required for a food-processing application.
    Quantity rule Calculates the number of instances. One support bracket for every defined length of conveyor.
    Variant or revision Controls the applicable design or part revision. High-temperature seal kit for a specified temperature range.
    Manufacturing status Indicates whether content is released, obsolete or under review. Prevent a superseded drive assembly from being quoted.
    Downstream mapping Connects the model to ERP, PLM, CAD or other records. Map a CPQ assembly to an ERP phantom assembly or material.

    Assembly rules and configuration constraints

    Assembly logic determines how a selected product configuration changes the product structure. Rules may add, remove, replace or modify assemblies and components. They may also block combinations that would create an unsafe, incompatible or unmanufacturable result.

    Typical rules

    • Inclusion rules: selecting a 400-volt motor adds the corresponding motor assembly and electrical protection components.
    • Exclusion rules: a compact enclosure excludes a large variable-frequency drive because there is insufficient space.
    • Dependency rules: selecting a stainless-steel wetted path requires compatible seals, fasteners and instrumentation.
    • Substitution rules: a selected performance range chooses one of several impeller or gearbox variants.
    • Quantity rules: the number of rollers, supports, brackets or cable sections is calculated from product dimensions.
    • Compatibility rules: a high-pressure valve assembly can only be selected with a body material and actuator rated for that pressure.
    • Completeness rules: an electrical control assembly cannot be released until the required disconnect, enclosure and control voltage are defined.

    Rules can be implemented as simple rules-based logic, constraint-based logic or guided selling. Rules-based logic explicitly states conditions such as if option A is selected, include assembly B. Constraint-based configuration evaluates permitted combinations across many variables, such as pressure, flow, temperature, material, dimensions and regulatory requirements. Guided selling helps a user reach a valid configuration through questions, but it does not replace the underlying product rules.

    These approaches can be combined. A guided selling interface may ask about fluid type and operating temperature; a constraint engine may then determine compatible materials and seals; and a rules engine may add the appropriate subassemblies to the BOM.

    Assemblies, subassemblies and BOM structures

    A bill of material (BOM) lists the components and quantities needed to define or build a product. Assembly modeling is closely related to BOM generation, but the two concepts are not identical. A product model describes configurable behavior, while a BOM is a resulting or released structure for a particular product, variant or manufacturing process.

    Configurable BOM

    A configurable BOM contains alternatives, optional components, rules or placeholders that can resolve into a specific structure after configuration. It may represent the range of possible products before a customer makes selections.

    Engineering BOM

    An engineering BOM (EBOM) represents the product as designed, often emphasizing functional and design relationships. It may contain CAD parts, design assemblies, technical documents and engineering revisions.

    Manufacturing BOM

    A manufacturing BOM (MBOM) represents how the product is built. It may reorganize components by production operation, work center, plant, kit or assembly sequence. A single engineering subassembly can be split, combined or restructured for manufacturing.

    Structure Main purpose Relationship to CPQ
    Configurable BOM Represent possible product variants and option logic. Resolved from customer selections and configuration rules.
    EBOM Represent the designed product and engineering relationships. May receive selected components, parameters or revisions.
    MBOM Represent the buildable production structure. May be generated or completed downstream in ERP or manufacturing systems.

    A CPQ application may generate one or more of these structures, or it may pass configuration results to PLM, PDM or ERP for authoritative BOM creation. The implementation should define which system owns each structure rather than assuming that CPQ is the system of record.

    Example: configuring a pump skid

    Consider a pump skid configured for a chemical-processing customer. The user selects flow rate, discharge pressure, fluid temperature, wetted material, motor voltage, control method and installation environment.

    The CPQ product model may apply the following logic:

    1. The required duty point selects a pump family and calculates a suitable impeller diameter.
    2. The fluid and temperature select a compatible casing material, seal arrangement and gasket material.
    3. The motor power calculation selects a motor size and starter or variable-frequency drive.
    4. An outdoor installation adds a weather-resistant enclosure and modifies the baseplate coating.
    5. A hazardous-area classification restricts the motor, instruments, enclosure and cable entries.
    6. The selected control method adds a control panel subassembly with the required components.
    7. The final configuration creates a quote, a price calculation, a lead-time estimate and, where supported, an engineering BOM or CAD package.

    Some outcomes are commercial and some are engineering outcomes. The price may use assembly-level costs, purchased component prices, labor, engineering effort, margin and freight rules. The BOM may include the selected motor, seal, valves, instruments and hardware. A CAD integration may use calculated dimensions and selected variants to produce a skid layout. These capabilities may be distributed across CPQ, CAD, PLM and ERP rather than delivered by one application.

    Assemblies in CTO, ETO, MTO and ATO workflows

    Assembly modeling supports several manufacturing approaches, but the required depth differs.

    • Configure-to-order (CTO): the manufacturer builds a product from predefined options and approved subassemblies. The model should resolve to known components and routings with limited engineering intervention.
    • Engineer-to-order (ETO): the configuration defines requirements, but engineers create or adapt designs for the order. Assembly structures may include engineered placeholders, calculated dimensions or review gates.
    • Make-to-order (MTO): production begins after the order, often using a configured product definition and order-specific planning.
    • Assemble-to-order (ATO): standard subassemblies are stocked or prepared in advance and combined after the customer order.

    For example, a standard conveyor drive module may support CTO, while a conveyor frame with unusual length, loading and environmental constraints may move into ETO. The CPQ system should make that transition explicit, such as by assigning an engineering review status or creating a structured handoff to engineering.

    Relationship to CAD and engineering automation

    Assemblies are often the bridge between commercial configuration and design automation. A CAD system may use the selected assembly variant, dimensions, mounting points, material, hole patterns and component positions to create a product-specific model or drawing.

    Possible outputs include:

    • an assembly-level 3D model;
    • configured component models;
    • 2D manufacturing or installation drawings;
    • dimension and clearance checks;
    • customer layout drawings;
    • assembly instructions or service documentation.

    CAD automation is not automatic merely because a CPQ platform contains an assembly tree. The CAD models, parameters, templates, mappings, revision controls and error handling must be implemented. Read more about CAD and engineering automation in manufacturing CPQ.

    Assembly-level pricing, costing and quoting

    Assembly structure can support more accurate costing and pricing. A configurable pump package may calculate material cost from the pump, motor, baseplate, instruments and controls, then add labor, testing, engineering, overhead and margin. An assembly may also have its own price, cost, lead time or approval threshold.

    However, price structure should not be confused with product structure. A commercial package may be sold as one line item even when it contains many manufacturing assemblies. Conversely, one physical assembly may contain components that need separate commercial treatment because of options, service contracts or compliance requirements.

    Pricing and BOM logic should be tested independently. A component can be included in the BOM without having a separate visible price, or a commercial option can change price without changing the physical BOM. Guidance on this relationship is covered in BOM generation, pricing and quote automation.

    Maintainability and governance

    Large assembly models become difficult to maintain when structure, rules and ownership are unclear. A practical governance model should define:

    • which team owns each assembly and its rules;
    • which system is authoritative for item numbers, revisions and released BOMs;
    • how common subassemblies are reused across product families;
    • how obsolete parts and superseded revisions are blocked;
    • how effective dates, plants and regional variants are handled;
    • how rules are named, documented and tested;
    • which changes require engineering, manufacturing or commercial approval;
    • how configuration results are traced back to the options and rules that created them.

    Modular product models are generally easier to maintain than one large flat model, but excessive modularization also creates problems. A subassembly should represent a meaningful reusable or governed unit. Creating a separate node for every minor component can make navigation, testing and integration unnecessarily complex.

    Testing assembly logic

    Testing should cover both valid and invalid configurations. A useful test set includes normal products, boundary values, incompatible options, missing selections, revision changes and downstream output checks.

    Test area Example
    Selection validity Confirm that a high-pressure pump cannot use an unrated seal assembly.
    Quantity calculation Verify that conveyor support quantities change correctly with length.
    Variant selection Confirm that the correct motor and coupling are selected for each power range.
    BOM completeness Check that required fasteners, brackets and control components are included.
    Revision control Ensure an obsolete subassembly cannot be selected after its effective end date.
    Integration output Verify that item numbers, quantities and revisions are accepted by ERP or PLM.
    Engineering escalation Confirm that an out-of-range dimension creates an ETO review rather than an invalid release.

    Automated test cases are particularly useful when a common subassembly is reused across many product families. A change to a motor, valve, enclosure or mounting pattern can have consequences in every parent assembly that uses it.

    Common limitations and implementation risks

    • Confusing sales options with physical structure: not every selectable option is a component, and not every component should be exposed to sales users.
    • Duplicated assembly definitions: copies of the same subassembly can diverge and produce inconsistent pricing or BOM results.
    • Unclear system ownership: CPQ, ERP, PLM and CAD may each hold part of the product definition. Without clear ownership, revisions become difficult to control.
    • Hidden engineering assumptions: rules based on undocumented calculations are difficult for sales, engineering and IT to maintain.
    • Overly flat models: a large list of individual components makes dependencies and reuse difficult to understand.
    • Overly deep models: excessive hierarchy can slow configuration and complicate integrations, reporting and user interfaces.
    • Incomplete downstream mapping: an assembly may configure correctly but fail when ERP requires a specific item, unit, plant or routing.
    • Unsupported automation claims: a CPQ product may support configurable options but not native EBOM, MBOM, CAD or engineering calculations.

    These risks should be addressed during requirements analysis and implementation planning. See the guide to manufacturing CPQ implementation, testing and governance and the overview of CPQ integrations with ERP, PLM, PDM, CAD and MES.

    Recommended implementation approach

    1. Map the current product structure: document finished products, assemblies, subassemblies, options, common parts and engineered variants.
    2. Separate structure from rules: identify what the product contains and what conditions determine inclusion, substitution or quantity.
    3. Classify each assembly: mark it as standard, configurable, purchased, manufactured, phantom, engineered or service-related according to the manufacturer’s processes.
    4. Define ownership: decide whether CPQ, ERP, PLM, PDM or CAD owns each item, revision, BOM and design record.
    5. Model a representative product family: choose a product with meaningful configuration complexity rather than a simple demonstration product.
    6. Connect downstream outputs: test quote lines, prices, BOMs, CAD parameters, engineering tasks and ERP transactions.
    7. Test reuse and change impact: modify a shared subassembly and evaluate every affected parent product.
    8. Establish release governance: document approvals, effective dates, revision rules, ownership and regression testing.

    The goal is not to reproduce every legacy engineering record inside CPQ. The goal is to hold enough product and rule information to guide valid configuration and create reliable downstream outputs, while preserving the appropriate system of record for detailed engineering and production data.

    Related manufacturing CPQ concepts

    Assemblies and subassemblies are closely connected to product configuration, product models and configuration rules, as well as configure-to-order and engineer-to-order workflows. They also relate to configurable BOMs, engineering automation, costing, quote generation and enterprise integration. For a broader introduction, see the guide to manufacturing CPQ.

    Frequently asked questions

    1. What is an assembly in product configuration?

    An assembly is a product structure made from multiple components or lower-level assemblies. In manufacturing CPQ, it may represent a functional module, manufacturing unit, purchased package or configurable section of a finished product.

    2. What is a subassembly?

    A subassembly is an assembly used inside a larger assembly. Examples include a motor-and-coupling module in a pump package or a drive module in a conveyor.

    3. Are assemblies the same as BOMs?

    No. An assembly is a structural product concept, while a BOM is a formal list of components and quantities for a product, variant or manufacturing process. A CPQ product model may resolve into one or more BOM structures.

    4. Can a CPQ configurator generate subassemblies automatically?

    Some manufacturing CPQ systems can generate or resolve configurable subassemblies. Others only pass selections and parameters to ERP, PLM, PDM or another engineering system. This capability must be verified for the specific platform.

    5. How do assembly rules prevent configuration errors?

    Rules can include required assemblies, exclude incompatible variants, select approved substitutions and calculate quantities. They can prevent combinations such as an undersized motor, incompatible seal or incorrectly rated enclosure.

    6. Should every component be modeled as a separate subassembly?

    No. Separate subassemblies should represent meaningful reusable, functional, manufacturing or governed units. Modeling every small component as a separate module can make the product model harder to maintain.

    7. How do assemblies affect pricing?

    Assembly contents can contribute material, labor, purchased-component, testing and engineering costs. An assembly may also carry a price or surcharge, although commercial pricing does not always mirror the physical BOM exactly.

    8. How do assemblies affect CAD automation?

    Selected assemblies can provide CAD variants, dimensions, mounting locations, materials and parameters. When the necessary CAD integration and templates exist, these inputs can produce product-specific models or drawings.

    9. What is the difference between an EBOM and an MBOM for assemblies?

    An engineering BOM represents the designed product, while a manufacturing BOM represents how the product is built. Manufacturing may reorganize or combine engineering assemblies for production operations.

    10. How are assemblies used in configure-to-order manufacturing?

    In configure-to-order manufacturing, approved assemblies and subassemblies are selected from a defined product model. The resolved structure should normally map to known parts, routings and production data.

    11. How are assemblies used in engineer-to-order manufacturing?

    In engineer-to-order manufacturing, assemblies may include calculated dimensions, engineered placeholders or review conditions. CPQ can define requirements and initiate engineering work rather than fully determining every component.

    12. Can one subassembly be reused in several products?

    Yes. Reuse is a major reason to model subassemblies explicitly. The shared module must have controlled revisions, compatible interfaces and rules that work in each parent product.

    13. Which system should own assembly data?

    There is no universal answer. CPQ may own commercial configuration logic, PLM or PDM may own design structures, and ERP may own released manufacturing items and plant-specific data. Ownership and synchronization must be defined during implementation.

    14. What happens when a selected assembly is not buildable?

    A well-designed model should block the configuration, request a missing selection, calculate a valid alternative or route the order to engineering review. It should not silently create an incomplete production structure.

    15. How should assembly changes be tested?

    Test valid and invalid combinations, quantity calculations, BOM completeness, revisions, pricing, CAD outputs and integrations. Also test every major parent product that reuses the changed subassembly.

    16. Are assemblies visible to sales users?

    They can be, but they do not have to be. Sales users may select business-level options such as capacity or environment, while the CPQ model resolves the underlying assemblies and components automatically.

    17. How do assemblies support dealer or distributor configuration?

    They allow dealers to work with understandable product choices while the system applies technical rules and resolves the required modules. Permissions may limit access to engineering-level details or sensitive costs.

    18. What is a phantom assembly?

    A phantom assembly is a logical grouping used for planning or structuring a BOM that may not be built or stocked as a separate physical unit. Whether and how it is supported depends on the manufacturing system and integration design.

    19. What is the main implementation mistake with assembly modeling?

    A common mistake is copying an existing BOM into CPQ without defining configuration behavior, ownership, revisions and downstream mappings. A usable product model must explain how customer choices produce a valid product structure.

    Semantic map

    • CPQ connects customer requirements to configurable product structures.
    • Assemblies organize components into functional or manufacturing units.
    • Subassemblies provide reusable modules within larger product structures.
    • Configuration rules control assembly inclusion, exclusion, substitution and quantity.
    • Constraints prevent incompatible or unbuildable combinations.
    • Configured products can generate resolved BOMs when the CPQ platform supports that capability.
    • EBOMs represent designed products and MBOMs represent manufacturing structures.
    • CAD automation can use configured assembly parameters to create product-specific design outputs.
    • Assembly content contributes to costing, pricing, lead-time estimation and quote generation.
    • CPQ exchanges configuration and order data with ERP, PLM, PDM, CAD and MES through integrations or APIs.
    • CTO uses approved assemblies, while ETO may use engineered assembly requirements and review gates.
    • Assembly governance controls ownership, revisions, reuse, testing and release status.

  • Manufacturing CPQ Requirements: Functional and Technical Checklist

    Manufacturing CPQ requirements should cover the complete path from product selection to production-ready data. A suitable system must do more than apply discounts and generate a proposal. It should represent configurable products, enforce engineering constraints, calculate prices and costs, produce accurate quotes, and provide usable data to engineering, enterprise resource planning (ERP) and production systems.

    This checklist is intended for manufacturers of machinery, equipment, vehicles, pumps, valves, electrical systems and other complex products. It separates functional requirements from technical, integration, governance and implementation requirements. Not every configure, price, quote (CPQ) platform supports every capability. Buyers should verify each requirement against documented product behavior, not assume that a feature exists because it is commonly associated with manufacturing CPQ.

    For broader context, see the guide to manufacturing CPQ and the detailed guide to product configuration.

    What are manufacturing CPQ requirements?

    Manufacturing CPQ requirements are the business, functional and technical capabilities needed for a CPQ system to configure engineered products, calculate commercial results and exchange reliable information with downstream systems.

    Manufacturing CPQ normally combines several related disciplines:

    • Product configuration: selecting valid options, dimensions, materials, accessories and features.
    • Rules and constraints: preventing incompatible or unsafe combinations and guiding users toward valid designs.
    • Engineering automation: performing calculations, selecting components and, where supported, creating CAD outputs.
    • Pricing and costing: calculating list price, discounts, labor, material cost, freight, margin and other commercial values.
    • Quoting: producing a quote, proposal or order-ready commercial package.
    • Manufacturing data: generating a configurable bill of materials (BOM), routings, item references or engineering outputs where supported.
    • Integration: exchanging data with customer relationship management (CRM), ERP, product lifecycle management (PLM), product data management (PDM), computer-aided design (CAD), product information management (PIM) and manufacturing execution system (MES) applications.

    Generic sales CPQ may focus mainly on products, prices, discounts, approvals and documents. Manufacturing CPQ adds product structure, technical validity, engineering intent and production consequences.

    Start with a manufacturing CPQ scope statement

    Before writing a feature checklist, define what the system must control. A requirement for a standard configurable pump is different from a requirement for a fully engineered process skid or a custom agricultural vehicle.

    Document the following scope dimensions:

    • Product families, models and variants in scope.
    • Configurable attributes such as capacity, dimensions, voltage, pressure, material, finish, motor type and environmental rating.
    • Sales channels, including direct sales, dealers, distributors, ecommerce and internal application engineering.
    • Manufacturing strategies, such as configure-to-order (CTO), engineer-to-order (ETO), make-to-order (MTO), assemble-to-order (ATO) and standard make-to-stock products.
    • Required outputs, including quote documents, order lines, configurable BOMs, drawings, calculations, specifications and manufacturing instructions.
    • Systems that own product, customer, price, engineering and production data.
    • Users, regions, languages, currencies, legal entities and approval responsibilities.

    A clear scope prevents a common procurement error: selecting a sales quoting tool for a problem that actually requires product modeling, engineering automation or production integration.

    Functional requirements checklist

    1. Product model and configuration requirements

    The product model is the structured representation of what can be sold and how it can be configured. It may include product families, option groups, attributes, components, variants, documents, prices and manufacturing relationships.

    Confirm whether the system can:

    • Represent multiple product families and model generations.
    • Separate mandatory, optional, conditional and mutually exclusive options.
    • Represent numeric values, ranges, units of measure, dimensions and tolerances.
    • Support materials, coatings, colors, ratings, standards and certifications.
    • Reuse common components and rules across product families.
    • Support nested assemblies and configurable subassemblies.
    • Maintain product revisions and effective dates.
    • Distinguish a commercial option from an engineering component or manufacturing item.
    • Store explanatory text, technical specifications, images, drawings and customer-facing descriptions.
    • Support multiple languages, currencies and regional product availability.
    • Record why a configuration choice was made and which rules produced it.

    For example, a pump model may expose flow rate, head, impeller material, seal type, motor voltage and connection size. The configuration model must ensure that the selected motor can provide the required duty and that the material and seal combination is suitable for the specified fluid.

    2. Rules, constraints and validation

    Rules determine what the user may select and what the system should calculate or recommend. A serious evaluation should distinguish three related approaches:

    Approach Purpose Manufacturing example
    Rules-based configuration Applies explicit if-then logic and dependencies. If a machine uses a high-temperature option, require a compatible seal and insulation package.
    Constraint-based configuration Finds or validates combinations against technical, dimensional or resource constraints. Select a motor, gearbox and frame that satisfy torque, speed, voltage and envelope limits.
    Guided selling Uses questions and recommendations to simplify selection for a user. Ask about required throughput and installation conditions, then recommend suitable machine configurations.

    Requirements should cover:

    • Option compatibility and incompatibility rules.
    • Dependencies between dimensions, performance values and components.
    • Minimum and maximum values, permitted increments and unit conversions.
    • Capacity, load, pressure, temperature, power, speed and safety calculations.
    • Rules that select or suppress BOM items.
    • Warnings, hard errors and approval-triggering exceptions.
    • Rule priorities when multiple rules affect the same result.
    • Traceability from a validation message to the rule or source data.
    • Testing of positive, negative, boundary and regression cases.

    Ask vendors how rules are authored, versioned, tested and deployed. A rule engine that is powerful but only maintainable by custom programmers may create a long-term governance problem.

    3. Engineering calculations and technical validation

    Some products require calculations before they can be quoted. Examples include pump duty calculations, heat-transfer sizing, structural load checks, motor selection, pressure-drop calculations and vehicle axle or payload calculations.

    Potential requirements include:

    • Formula and variable management with units and conversions.
    • Use of customer requirements as calculation inputs.
    • Component selection based on calculated results.
    • Lookup tables, engineering curves and manufacturer data.
    • Rounding, tolerances and significant-figure controls.
    • Calculation logs and reproducible results.
    • Integration with external calculation services or engineering applications.
    • Human review when a result falls outside standard product limits.

    Do not assume that a CPQ system includes a general-purpose engineering solver. Some platforms provide formulas and rules; others integrate with specialist applications; some provide neither. Requirements should state whether the CPQ system must calculate, invoke an external service or merely store an approved engineering result.

    Related capabilities are covered in the guide to CAD and engineering automation.

    4. BOM generation and manufacturing outputs

    A bill of materials (BOM) is a structured list of components and quantities required for a product or assembly. A configurable BOM applies selection logic so that the output changes according to the customer configuration.

    Specify whether the system must generate:

    • A sales or quotation BOM for commercial visibility.
    • An engineering BOM (EBOM), which represents the product from an engineering design perspective.
    • A manufacturing BOM (MBOM), which represents how the product is assembled or produced.
    • Service, spare-parts or installation BOMs.
    • Phantom assemblies, alternates, substitutes, consumables and reference-only items.
    • Quantities calculated from dimensions, length, area, weight or performance.
    • Item revisions, effectivity dates, units of measure and plant-specific data.
    • Routings, operations, labor assumptions or work-center information.

    EBOM and MBOM are not interchangeable. An EBOM might describe the designed machine, while an MBOM may reorganize the same product into assembly operations and manufacturing stages. The CPQ system may generate one, both or neither. Define the system of record and the handoff process explicitly.

    See the guide to BOM generation, pricing and quoting for related requirements.

    5. CAD, drawings and visualization

    CAD integration connects configuration choices with computer-aided design data. Depending on the platform and implementation, this may involve selecting existing models, changing parameters, generating a new model, producing a drawing or sending data to a CAD system.

    Evaluate whether the requirement is for:

    • Static product images and option illustrations.
    • Interactive 2D or 3D visualization.
    • Parametric model updates based on dimensions or selected options.
    • Automatic generation of 2D drawings, PDFs or neutral CAD files.
    • Creation or update of CAD assemblies and parts.
    • Design validation before release to engineering or production.
    • Links to PDM or PLM revisions and approved design data.

    Visualization improves understanding, but it does not by itself prove that a configuration is manufacturable. CAD automation may also require specialist templates, stable parameter naming, robust model structures and engineering ownership.

    6. Costing, pricing and margin control

    Pricing and costing are related but different. Costing estimates what the manufacturer spends on material, labor, purchased components, subcontracting, freight or overhead. Pricing determines what the customer is charged.

    Requirements may include:

    • Base prices, option prices, surcharges and formula-based prices.
    • Material, labor, machining, assembly, tooling, freight and installation costs.
    • Quantity breaks, customer-specific prices and regional price lists.
    • Currency conversion, taxes and legal-entity rules.
    • Discount limits and approval thresholds.
    • Target margin, contribution margin and minimum-price controls.
    • Price validity dates and revision management.
    • Scenario comparison for alternative configurations.
    • Separation of internal cost data from customer-visible pricing.

    A price calculation should be traceable. Users should be able to understand which product choices, cost inputs, commercial rules and approvals produced the final amount.

    7. Quote, proposal and approval management

    Quote generation turns a validated configuration into a commercial response. Functional requirements may include:

    • Quote versions, revisions, expiration dates and status history.
    • Multiple configurations or line items in one quote.
    • Alternatives, options, exclusions and assumptions.
    • Technical specifications and customer-specific text.
    • Drawings, calculations and compliance documents as attachments.
    • Approval workflows for discount, margin, non-standard terms or technical exceptions.
    • Electronic acceptance and conversion to an order or opportunity where supported.
    • Templates for different countries, channels, products and legal entities.

    For ETO work, the quote may need to show estimated engineering effort, assumptions, milestones and the boundary between standard product content and project-specific design.

    Workflow requirements by manufacturing model

    Model CPQ emphasis Typical downstream requirement
    Configure-to-order (CTO) Validate known options and generate a repeatable product definition. Reliable configurable BOM, item references and order data.
    Engineer-to-order (ETO) Capture requirements, identify technical exceptions and initiate engineering work. Engineering task, approved design, drawings and project-specific BOM.
    Make-to-order (MTO) Configure or specify a product that is produced after order receipt. Production-relevant specification and planning data.
    Assemble-to-order (ATO) Combine stocked modules or components according to valid choices. Accurate module demand and assembly instructions.

    Requirements should define the handoff from sales to application engineering, order management, production planning and procurement. A quote that looks correct to sales may still be incomplete for manufacturing if it lacks revision, item, dimension, routing or approval information.

    Map these flows in the guide to manufacturing CPQ workflows.

    Technical and architecture requirements

    Data ownership and master data

    Identify which system owns each data object. CRM may own account and opportunity data. ERP may own items, inventory, orders and financial data. PLM may own product revisions and lifecycle status. PDM may manage CAD files and document relationships. PIM may manage product descriptions and channel content. MES may manage execution and shop-floor transactions.

    For each object, document the source of truth, synchronization direction, update frequency, identifier and error-handling process. Do not treat these systems as interchangeable.

    Integration and APIs

    Manufacturing CPQ integration requirements commonly include:

    • CRM opportunity, account and contact synchronization.
    • ERP item, customer, price, inventory, order and financial integration.
    • PLM or PDM exchange for revisions, approved structures and documents.
    • CAD integration for models, parameters, drawings or files.
    • PIM exchange for product descriptions, images and channel content.
    • MES or manufacturing-system exchange for production data where appropriate.
    • Webhooks, application programming interfaces (APIs), batch imports and exports.
    • Identity, authentication, logging, retries and reconciliation.

    Ask whether the API supports the objects and transactions required by the use case. A generic customer or quote API may not support configurable BOMs, engineering revisions or calculation results.

    Use the manufacturing CPQ integrations guide when documenting system boundaries and data flows.

    Security, deployment and performance

    Technical requirements should cover role-based access, single sign-on, data segregation, audit trails, encryption, backup, retention and regional hosting requirements. Manufacturing users may include external dealers, internal sales engineers, application engineers, administrators and production planners, each with different permissions.

    Performance requirements should use realistic product models and workloads. Test configuration response time with large rule sets, many concurrent users, complex calculations, document generation and integration calls. A fast demonstration with a small product model does not establish production performance.

    Maintainability, versioning and governance

    Product rules change when suppliers, standards, materials, costs and manufacturing processes change. The system should support controlled updates, effective dates, approvals, testing and rollback or equivalent recovery procedures.

    Define:

    • Who owns product data, rules, prices, calculations and templates.
    • How changes are requested, reviewed, tested and released.
    • How obsolete options and components are handled.
    • How rules are documented for future administrators.
    • How configuration defects are reported and traced.
    • How production, engineering and commercial teams resolve conflicting definitions.

    Implementation and evaluation checklist

    1. Document representative products, not only simple examples.
    2. Collect real configuration rules, exception cases, calculations and historical quotes.
    3. Map the current sales-to-engineering-to-production workflow.
    4. Classify requirements as mandatory, important, optional or future scope.
    5. Identify data owners and authoritative sources for each object.
    6. Define the required outputs: quote, specification, EBOM, MBOM, CAD file, drawing, order or engineering task.
    7. Build test scenarios covering valid combinations, invalid combinations, boundary values and exceptions.
    8. Test product revisions, price changes and effective dates.
    9. Verify integrations with representative ERP, CRM, PLM, PDM and CAD data.
    10. Measure rule maintenance effort, quote accuracy, engineering handoff quality and document generation reliability.
    11. Confirm how dealers, distributors and external users are authenticated and supported.
    12. Define governance, release management, support ownership and training before go-live.

    During vendor evaluation, ask for a controlled proof of concept using one representative product family. Require the vendor to show how a rule is created, tested, revised and traced; how a configuration becomes a BOM; how a technical exception is handled; and how data moves into downstream systems. A feature checklist alone will not reveal implementation complexity.

    The CPQ implementation guide provides a broader framework for requirements, migration, testing, deployment and governance.

    Common limitations and risks

    • Overly broad scope: attempting to replace ERP, PLM, CAD, MES and CRM in one project can obscure the CPQ objective.
    • Unmaintainable rules: duplicated logic and undocumented exceptions make product models difficult to change.
    • Weak product data: inconsistent item numbers, units, revisions and descriptions undermine every downstream output.
    • False automation assumptions: a platform may support a configurable BOM but not a production-ready MBOM or CAD design.
    • Uncontrolled exceptions: manual overrides may allow technically invalid or commercially unprofitable configurations.
    • Integration ambiguity: unclear ownership can create conflicting prices, revisions or component definitions.
    • Insufficient testing: a model can work for common products while failing at dimensional limits or rare combinations.
    • Low adoption: sales and engineering users may bypass the system if it is slower or less flexible than existing spreadsheets.

    These risks are reasons to define boundaries, ownership and test cases early. They are not reasons to assume that one platform will support every engineering and manufacturing process automatically.

    Semantic map

    The following relationships summarize the entities discussed in this guide:

    • Manufacturing CPQ connects product configuration, engineering validation, pricing, quoting and production data.
    • Product models contain options, attributes, components and configuration rules.
    • Configuration rules prevent invalid combinations and trigger calculated results.
    • Engineering calculations validate requirements and support component selection.
    • A configured product can generate a configurable BOM when the platform supports BOM logic.
    • EBOM represents an engineering product structure, while MBOM represents a manufacturing structure.
    • CAD automation can generate product-specific models or drawings when supported and properly integrated.
    • Costing estimates internal manufacturing expense, while pricing determines the customer charge.
    • CRM supplies customer and opportunity context, while ERP supplies commercial and operational records.
    • PLM and PDM manage product lifecycle and design data that may be referenced by CPQ.
    • CTO uses validated standard configurations, while ETO introduces project-specific engineering work.
    • Governance controls changes to product rules, prices, revisions and integration mappings.

    Frequently asked questions

    What is the most important manufacturing CPQ requirement?

    The most important requirement is a maintainable product model that can represent real options, dependencies, constraints and outputs. Without it, pricing and quote documents may appear correct while the configured product remains technically invalid.

    How is manufacturing CPQ different from sales CPQ?

    Sales CPQ generally emphasizes product selection, pricing, discounts and proposals. Manufacturing CPQ may additionally validate engineering constraints, calculate technical values, generate BOMs or CAD outputs and exchange data with ERP, PLM or production systems.

    Does every manufacturing CPQ system generate a BOM?

    No. Some systems generate configurable BOMs, some pass selections to an ERP or PLM system, and some only produce commercial quote data. BOM generation and its required EBOM or MBOM structure must be verified separately.

    What is a configurable BOM?

    A configurable BOM is a product structure whose components, quantities or assemblies change according to configuration choices. For example, a machine BOM may change when the user selects a different motor, frame size or material.

    Should CPQ own the product master?

    Not necessarily. Ownership depends on the architecture. ERP, PLM, PDM or another system may remain the authority for items, revisions or engineering structures, while CPQ uses synchronized data to configure and quote products.

    What rules should be included in a CPQ requirements document?

    Include compatibility, dependency, dimensional, performance, safety, pricing, BOM-selection and approval rules. Also specify how rules are versioned, tested, explained to users and linked to source data.

    What is the difference between a hard error and a warning?

    A hard error blocks a configuration because it is invalid or prohibited. A warning allows the user to continue but records a condition that may require review, such as a non-standard dimension or an unusual commercial margin.

    When are engineering calculations required in CPQ?

    They are required when product selection depends on technical inputs such as flow, pressure, load, temperature, speed, voltage, capacity or dimensions. The calculation may run inside CPQ or through an integrated engineering service.

    Does 3D visualization prove that a product is manufacturable?

    No. Visualization helps users understand a configuration, but manufacturability also depends on rules, tolerances, materials, component availability, production methods and engineering review.

    What is the difference between EBOM and MBOM?

    An EBOM describes the product from an engineering design perspective. An MBOM organizes components and operations according to how the product is manufactured or assembled. A CPQ implementation may produce one, both or neither.

    Which systems commonly integrate with manufacturing CPQ?

    Common integration targets include CRM, ERP, PLM, PDM, CAD, PIM and MES. The exact scope depends on which system owns customers, products, revisions, prices, designs, inventory and production data.

    What should a CPQ proof of concept include?

    Use a representative product family with real rules, calculations, pricing, exceptions and downstream outputs. Test valid and invalid configurations, revision changes, quote generation, BOM results and at least the most important integrations.

    How should manufacturers evaluate CPQ rule maintenance?

    Ask business and engineering users to create, change, test and release representative rules. Measure whether they can understand dependencies, identify affected products and deploy changes without unsafe manual workarounds.

    What are the CPQ requirements for configure-to-order?

    CTO generally requires repeatable configuration validation, controlled option combinations, accurate pricing and an order-ready product definition. Configurable BOM and ERP integration are often important, but the required output depends on the manufacturing process.

    What are the CPQ requirements for engineer-to-order?

    ETO requires structured capture of customer requirements, technical exception handling, engineering task initiation, document management and a controlled transition from preliminary configuration to approved design and production data.

    Can CPQ replace CAD or PLM?

    Usually it should not be assumed to do so. CPQ may integrate with CAD or PLM and automate selected tasks, but CAD design authority, lifecycle control and engineering revision management may remain in specialist systems.

    How should pricing and costing requirements be separated?

    Document internal cost inputs separately from customer-facing prices. Costs may include material, labor and purchased components, while pricing may include list prices, discounts, surcharges, margins, taxes and commercial terms.

    What governance is needed after CPQ implementation?

    Manufacturers need named owners for product models, rules, prices, calculations, templates and integrations. They also need change control, testing, release procedures, auditability and a process for handling product and supplier changes.