CPQ Guide

Tag: constraint-based configuration

  • How to Build a CPQ Product Model for Manufacturing

    A CPQ product model is the structured definition of a configurable product used by a Configure, Price, Quote system. In manufacturing, it describes the product hierarchy, selectable options, engineering parameters, configuration rules, calculations, prices and downstream outputs needed to produce a valid quote and, where supported, a bill of materials (BOM), CAD configuration or production order.

    Building a reliable model starts with the product and its engineering logic, not with a list of sales questions. The model should represent how the product is actually designed, priced, manufactured and supported. A pump model, for example, may need to validate flow, head, fluid properties, motor size, impeller diameter, materials, seal type, voltage and certification requirements before it can produce a price or manufacturing-ready result.

    This guide explains how to design a maintainable manufacturing CPQ product model, how to separate configuration rules from pricing, how to connect the model to BOM and CAD processes, and how to test and govern it over time.

    What is a CPQ product model?

    A CPQ product model is a machine-readable representation of a configurable product and the logic that determines which configurations are valid, what they cost and what data should be generated. It normally combines product structure, attributes, options, dependencies, constraints, calculations and outputs.

    In generic sales CPQ, a product model may mainly determine which commercial products can be selected together and how discounts are calculated. A manufacturing CPQ model usually goes further. It may also need to capture dimensions, materials, performance requirements, engineering formulas, component substitutions, manufacturing choices, assembly relationships and references to product data managed in other systems.

    Model element Purpose in manufacturing CPQ Example
    Product hierarchy Organizes the configurable assembly and its modules Conveyor system, drive unit, belt, guards and controls
    Options and attributes Captures choices or values selected by a user Belt width, frame material, motor voltage
    Rules and constraints Prevents invalid or unsafe combinations A high-temperature seal is required for a specified fluid temperature
    Engineering calculations Derives sizes, ratings or performance values Motor power calculated from load, speed and incline
    Commercial logic Calculates cost, price, discounts and surcharges Price adjusted for stainless steel and a hazardous-area motor
    Downstream outputs Provides data to quoting, engineering and production Configurable BOM, CAD parameters and ERP item references

    The model is therefore more than a product catalog. It is a controlled product knowledge base that connects commercial configuration with engineering and manufacturing processes.

    See the related guide to product configuration and configuration rules for a broader explanation of options, dependencies and validation.

    Why product-model design matters

    A poorly designed model can produce valid-looking quotes for products that cannot be built, priced profitably or supported by engineering. It may also become difficult to change when product managers add options, when suppliers change components or when engineering revises a design.

    A well-designed model provides a controlled path from customer requirements to an approved configuration. It can reduce manual interpretation by sales engineers, expose missing information early and create consistent data for later systems. However, CPQ does not automatically create accurate engineering logic. The quality of the result depends on the source product data, rule ownership, integration design and testing discipline.

    The main layers of a manufacturing CPQ product model

    1. Product structure

    Begin by representing the product as a hierarchy of assemblies, modules and components. The hierarchy should reflect how the product is configured and, where useful, how it is engineered or assembled.

    For an industrial air-handling unit, the structure might include the base unit, casing, fan section, filters, heating or cooling coil, controls, electrical package and accessories. Each module can have its own options, rules, calculations and output mappings.

    Do not assume that the sales structure, engineering structure and manufacturing structure are identical. A sales user may select one option called a heating package, while the engineering or manufacturing output may contain a coil, valves, sensors, control panels, wiring and mounting hardware. The model should make these relationships explicit rather than forcing users to select every internal component manually.

    2. Options and attributes

    Options are discrete choices, such as cast iron or stainless steel. Attributes are values that may be entered or calculated, such as length, flow rate, operating temperature or enclosure rating.

    Each attribute should have a defined data type, unit, allowed range, default behavior and ownership. A dimension should not be stored as unstructured text if it is used in calculations or CAD automation. Similarly, a material should use a controlled value connected to a material record or code rather than several free-text spellings.

    Data type Manufacturing example Design consideration
    Enumeration Motor type: standard, brake, inverter-duty Use controlled values with stable identifiers
    Numeric value Tank volume: 500 litres Store units, precision and valid range
    Boolean Include access platform: yes or no Define default and downstream effect
    Text Customer marking or project reference Keep free text out of engineering logic where possible
    Calculated value Required shaft diameter Document formula, inputs and rounding rules

    3. Dependencies

    Dependencies describe relationships between selections. If a customer selects a diesel engine, the model may show compatible exhaust, cooling and fuel-system options. If a product includes a hygienic stainless-steel frame, certain surface finishes and fasteners may become available while painted-steel options become unavailable.

    Dependencies should be expressed in terms of stable product data rather than interface labels. The rule should refer to an option identifier or attribute value that remains consistent if the wording shown to users changes.

    4. Constraints

    Constraints define what is permitted, required, excluded or conditionally available. Common types include:

    • Compatibility constraints: two components cannot be used together.
    • Requirement constraints: selecting one option requires another option.
    • Range constraints: a value must remain within a technically valid range.
    • Capacity constraints: a selected motor, frame or power supply must support the calculated load.
    • Process constraints: a configuration must follow manufacturing or installation limitations.
    • Regulatory constraints: materials, safety devices or certifications are required for a market or application.

    For example, a valve model may permit a 250-millimetre diameter only when the pressure class and body material support it. A pump model may reject an impeller diameter if the requested duty point falls outside the operating envelope. A mobile machine may require a specific braking package when gross vehicle weight exceeds a threshold.

    5. Calculations

    Engineering calculations transform requirements into derived values. They can size a component, determine a performance rating, select a standard part or calculate a surcharge. Examples include pressure drop, heat-transfer area, belt length, battery capacity, structural load, motor power and cable size.

    Calculation inputs should be clearly identified and validated before the calculation runs. The model should also record units, assumptions, rounding and the source of the formula. A formula copied from a spreadsheet without documenting its variables and limits is difficult to verify and maintain.

    Not every CPQ platform includes a full engineering calculation engine. Some systems rely on external services, CAD rules, engineering applications or custom code. The architecture should make this boundary explicit.

    6. Output mappings

    Output mappings connect configuration decisions to commercial and technical results. A selected option may map to a component number, a BOM quantity, an operation, a price condition, a CAD parameter, an ERP material code or a document section.

    One customer-facing option can produce multiple outputs. Selecting a stainless-steel pump package may change the casing material, fastener set, seal, baseplate finish, BOM components, cost, lead-time message and technical description.

    Start with a product-model scope

    Before building rules, define the product family and the business process the model must support. A first release should have a clear boundary. Trying to model every product variant, legacy exception and engineering possibility at once usually produces unclear ownership and excessive testing effort.

    Document:

    • the product family and included modules;
    • the intended users, such as sales, dealers, application engineers or customers;
    • the workflow, such as configure-to-order (CTO), engineer-to-order (ETO), make-to-order (MTO) or assemble-to-order (ATO);
    • the required outputs, such as price, quote text, configurable BOM or CAD parameters;
    • the systems that own item, revision, customer and commercial data;
    • the approval points and conditions that require engineering review.

    CTO means configure-to-order: the product is assembled from predefined options and components. ETO means engineer-to-order: a customer requirement leads to additional engineering work or a new design. MTO means make-to-order: production begins after a customer order rather than from stock. ATO means assemble-to-order: standard modules are assembled into a customer-selected combination. One product family can support more than one of these patterns, but the model should identify when a configuration remains within standard rules and when it becomes an engineering case.

    Separate configuration, pricing and quoting logic

    Configuration determines whether and how a product can be built. Pricing determines its commercial value. Quoting determines how the result is presented, approved and communicated. These concerns interact but should not be confused.

    For example, a pump configuration rule may require a mechanical seal for a particular fluid. The pricing logic then adds the seal cost and applicable margin. The quote may display the seal as part of the selected package or as a technical inclusion. Combining all three concerns in one large rule makes changes risky.

    Concern Question answered Example
    Configuration Is this product definition valid? Can this impeller be used with this casing?
    Engineering What size or technical result is required? What motor rating meets the duty point?
    Costing What does the configuration cost to produce? What is the material and labor cost?
    Pricing What should the customer be charged? What price, discount and surcharge apply?
    Quoting How should the offer be presented and approved? Which descriptions, terms and documents appear?

    This separation makes it easier to change a price list without rewriting engineering rules, or to revise a component relationship without altering quote templates.

    Design rules for maintainability

    Use modular rule groups

    Organize rules by product module, function or decision type. Examples include motor compatibility, pressure rating, material selection, electrical requirements and documentation. Modular rules are easier to test than a single collection of nested conditions covering the whole product.

    Prefer declarative rules where practical

    A declarative rule states what must be true, such as a 480-volt motor requires a compatible control panel. This is generally easier for product experts to review than deeply embedded procedural code. Custom code may still be appropriate for complex calculations, external lookups or specialized engineering algorithms, but it should have an owner, test cases and version control.

    Use controlled vocabularies

    Materials, voltage classes, pressure ratings, regions, certifications and component types should use governed values. Controlled vocabularies reduce duplicate values and make integrations more reliable. They also help distinguish a commercial label from an engineering identifier.

    Make defaults explainable

    Defaults can reduce configuration time, but an incorrect default can create a hidden engineering or commercial error. Document why a default exists and whether the user may override it. For example, a standard motor may be preselected based on a typical duty, but the model should require confirmation when the calculated load exceeds the standard assumption.

    Do not encode every exception as a normal option

    Some requests are genuine ETO cases. If the model turns every historical exception into a selectable option, the product model becomes difficult to understand and test. Define an escalation path for nonstandard requirements instead of allowing invalid combinations through informal overrides.

    Build the model from authoritative product data

    A product model needs reliable source data. Typical sources include engineering specifications, product catalogs, drawings, bills of material, CAD parameters, price lists, costing sheets, ERP item masters and product lifecycle management (PLM) records.

    PLM manages product definitions, revisions and engineering lifecycle information. Product data management (PDM) commonly focuses on controlled engineering files and relationships. Enterprise resource planning (ERP) manages business transactions such as items, inventory, purchasing, production and orders. Product information management (PIM) manages product content for channels and catalogs. These systems are related but are not interchangeable sources for every model element.

    Before importing data, identify the system of record for each field. An ERP may own sellable item numbers and costs, while PLM owns engineering revisions and CAD relationships. A CPQ model may need synchronized copies of both, with explicit effective dates and revision behavior.

    Data Possible system of record CPQ use
    Engineering revision PLM or PDM Validate revision-specific options and outputs
    Sellable item and inventory status ERP Map selected components and check availability rules
    CAD family and parameters CAD or PLM Drive geometry or generate drawings where supported
    Channel description and images PIM Present product information to users
    Cost and price conditions ERP, pricing service or CPQ Calculate cost, price and margin

    Connect the model to BOM, CAD and manufacturing outputs

    Configurable BOMs

    A configurable BOM is a bill of materials whose components or quantities depend on the selected configuration. The output may be a structured BOM for review, an ERP order structure, a manufacturing BOM (MBOM) or an engineering BOM (EBOM).

    An EBOM represents the product from an engineering design perspective. An MBOM represents how the product is built, including manufacturing assemblies, consumables or process-specific items. They may not have the same structure. A CPQ system should not automatically treat a sales configuration output as a complete production BOM unless the mapping and approval process support that use.

    For example, an air-handling unit may have one commercial heating option, an engineering assembly containing a coil and control valve, and an MBOM containing installation hardware and production operations. The product model should identify which output is being generated and which system is responsible for final validation.

    CAD and engineering automation

    Some manufacturing CPQ platforms connect configuration values to parametric CAD, drawing templates or engineering calculation tools. A selected tank diameter might drive a CAD parameter, while a calculated nozzle position might be passed to a design automation service.

    CAD automation should be treated as a separate capability from basic CPQ. A system may support product rules and quoting without generating geometry. If CAD output is required, verify parameter mapping, revision control, regeneration behavior, drawing approvals and failure handling. More information is available in the guide to CAD and engineering automation in CPQ.

    ERP and order handoff

    ERP integration may transfer customer information, configured items, prices, BOMs, delivery information or order lines. The CPQ model must define which identifiers and revisions are sent, how errors are handled and whether ERP validates the result again.

    CPQ should not be treated as a replacement for ERP, PLM, CAD or manufacturing execution system (MES) functionality. It is an orchestration and decision layer that may exchange data with these systems. The exact boundary depends on the platform and implementation.

    Rules-based, constraint-based and guided configuration

    These approaches overlap but are not identical.

    • Rules-based configuration uses explicit conditions such as if-then relationships, requirements, exclusions and calculations.
    • Constraint-based configuration describes valid combinations through constraints that a solver or rules engine evaluates, often across many variables.
    • Guided selling asks business or application questions and recommends suitable products or options. It may guide a user without representing the full engineering constraint system.

    A guided selling flow might ask for required flow and pressure, then recommend a pump family. A constraint-based model may validate the resulting pump, motor, seal and materials across many interacting values. Guided selling can be a useful front end, but it does not by itself guarantee manufacturing validity.

    Modeling a pump example

    Consider a centrifugal pump sold for industrial water service. The model might contain the following inputs:

    • required flow and head;
    • fluid type, temperature and density;
    • casing and impeller material;
    • seal arrangement;
    • motor power, voltage and frequency;
    • connection size and pressure class;
    • baseplate and coupling requirements;
    • area classification or certification requirement.

    The model could apply rules such as:

    • the selected impeller must meet the duty point within the approved operating range;
    • fluid temperature above a defined limit requires a suitable seal and gasket package;
    • the motor must meet the calculated power requirement with the required service factor;
    • the connection size must be compatible with the casing;
    • an area classification requires an approved motor and electrical package;
    • material and certification selections may trigger additional documentation and lead-time conditions.

    The outputs might include a configuration summary, a price, a quote description, a component list, an engineering review flag and parameters for a pump datasheet. If the product falls outside the standard hydraulic range, the model should route it to application engineering rather than silently producing a standard quote.

    Validation, testing and governance

    Testing should cover more than individual rules. A model can pass isolated tests and still fail when several options interact. Create test cases from real product knowledge, historical quote errors, boundary conditions and known exceptions.

    Test type Purpose Example
    Positive test Confirms a valid configuration is accepted Standard pump with approved motor and seal
    Negative test Confirms an invalid configuration is rejected Pressure class below the required operating pressure
    Boundary test Checks limits and unit handling Maximum allowable temperature or flow
    Interaction test Checks combined rules High temperature plus hazardous-area motor plus special material
    Regression test Ensures a change does not break existing behavior New motor option does not alter existing BOM mappings
    Output test Confirms downstream data is correct Configured components map to the correct ERP identifiers

    Assign ownership for rules, calculations, prices, product descriptions, integrations and approvals. A product manager may own commercial options, engineering may own technical constraints, manufacturing may own MBOM mappings and finance may govern pricing policy. Shared governance is necessary because no single department owns the entire product model.

    Use versioning and effective dates. A quote created under one product revision should remain traceable even after a new motor, material or price is introduced. Releases should include impact analysis, test evidence and a rollback or correction procedure.

    Common product-modeling mistakes

    • Starting with the user interface: screens are designed before the product logic and data ownership are understood.
    • Using free text for structured engineering data: values cannot be validated or integrated reliably.
    • Mixing price and validity rules: discounts or surcharges accidentally make invalid products appear acceptable.
    • Copying spreadsheets without verification: hidden assumptions, obsolete formulas and manual overrides become embedded in the model.
    • Modeling only the happy path: edge cases, regional requirements and engineering review conditions are ignored.
    • Ignoring revisions: old quotes and new product definitions cannot be distinguished.
    • Assuming the CPQ BOM is production-ready: EBOM, MBOM and sales structures may require different mappings.
    • Allowing uncontrolled overrides: users bypass rules without recording who approved the exception.
    • Building one giant model: unrelated product families become difficult to test and govern.

    Implementation sequence

    1. Select a representative product family. Choose a product with meaningful configuration complexity and measurable business value.
    2. Map the current process. Document how sales, application engineering, costing, design and production handle a quote today.
    3. Inventory product data. Identify options, attributes, rules, formulas, components, revisions, prices and documents.
    4. Define ownership. Assign responsibility for technical, commercial and downstream data.
    5. Design the product hierarchy. Separate modules, standard options, calculated values and exceptions.
    6. Implement core validity rules first. Prevent unsafe or impossible configurations before adding advanced presentation features.
    7. Add calculations and outputs. Introduce sizing, pricing, quote content, BOM mappings and CAD or engineering interfaces as required.
    8. Test with real scenarios. Include valid, invalid, boundary and historical cases.
    9. Pilot with users and engineering. Confirm that questions are understandable and that outputs are useful downstream.
    10. Release under governance. Version the model, document changes and monitor exceptions after deployment.

    The detailed planning, migration, testing and governance topics are covered in the CPQ implementation guide.

    How to measure product-model quality

    Useful measures should reflect manufacturing outcomes rather than only interface activity. Possible measures include quote cycle time, percentage of configurations requiring rework, engineering review rate, invalid configuration rate, BOM correction rate, margin variance, quote-to-order conversion and the time required to implement a product change.

    Interpret these measures carefully. A lower engineering review rate may mean the model handles standard products better, or it may mean users are bypassing review. A faster quote may still be poor if the price or BOM is inaccurate. Pair speed measures with quality, margin and downstream correction measures.

    When a CPQ product model should stop

    A product model should represent repeatable, governable product logic. It should not attempt to automate every engineering decision or replace professional approval for novel designs. Establish clear boundaries for standard configuration, configurable engineering and full ETO work.

    For standard CTO products, the model may generate a validated BOM and pass parameters to ERP or CAD. For ETO products, it may capture requirements, calculate preliminary values, estimate price and create an engineering work request without claiming that the final design is complete. This distinction protects both the customer and the manufacturer.

    Semantic map

    The article connects the following manufacturing CPQ entities and relationships:

    • CPQ product model → represents → configurable product structure
    • Product options → define → customer-selectable choices
    • Configuration rules → prevent → invalid combinations
    • Engineering calculations → derive → technical product values
    • Configured product → produces → quote data
    • Configured product → can generate → configurable BOM
    • EBOM → represents → engineering product structure
    • MBOM → represents → manufacturing assembly structure
    • CAD automation → uses → configuration parameters
    • CPQ → exchanges data with → ERP
    • CPQ → may exchange revisions with → PLM or PDM
    • Pricing logic → calculates → customer price and margin
    • Manufacturing constraints → limit → valid product configurations
    • CTO workflow → uses → predefined product options
    • ETO workflow → escalates → nonstandard engineering requirements

    Frequently asked questions

    What is a CPQ product model?

    A CPQ product model is the structured definition of a configurable product, including its hierarchy, options, attributes, rules, calculations, prices and downstream outputs.

    How is a manufacturing CPQ model different from a sales CPQ catalog?

    A manufacturing model may validate engineering constraints, calculate technical values and produce BOM, CAD or ERP data. A sales catalog usually focuses on selectable products, pricing and quote presentation.

    What should be modeled first?

    Start with the product structure, critical technical inputs and rules that distinguish valid from invalid configurations. Add pricing, documents and advanced outputs after the core product logic is understood.

    Should every component appear as a customer-facing option?

    No. Internal components should normally be derived from higher-level selections. Exposing every component increases user effort and creates more opportunities for invalid combinations.

    What is the difference between an option and an attribute?

    An option is usually a discrete choice, such as stainless steel or painted steel. An attribute is a value, such as length, flow, temperature or voltage.

    How should engineering rules be represented?

    Use explicit, modular rules with defined inputs, outputs, units, ownership and test cases. Declarative rules are often easier to maintain, while custom code may be needed for specialized calculations.

    Can a CPQ product model calculate equipment size?

    Some CPQ platforms support engineering calculations or connect to external calculation services. The capability must be verified for the required formulas, units, ranges, approvals and auditability.

    Does every CPQ system generate a BOM?

    No. BOM generation varies by platform and implementation. Confirm whether the system supports configurable BOMs and whether the output is a sales structure, EBOM, MBOM or ERP order structure.

    Can a CPQ model generate CAD drawings?

    Only when the platform or its integrations support CAD or design automation. Verify parameter mapping, geometry generation, revision control, drawing approval and failure handling.

    What is the difference between EBOM and MBOM?

    An EBOM describes the product from an engineering perspective. An MBOM describes how it is manufactured and may include production-specific assemblies, consumables or operations.

    How does pricing relate to configuration rules?

    Configuration rules determine whether a product is valid. Pricing logic calculates cost, price, discounts and surcharges for a valid configuration. Keeping these concerns separate improves maintainability.

    How should ETO requirements be handled?

    The model should capture requirements, identify what is outside the standard envelope and route the case to engineering. It should not present an unapproved design as a standard configuration.

    Which systems provide data to a product model?

    Possible sources include PLM or PDM for engineering definitions, ERP for items and costs, CAD for design parameters, PIM for channel content and pricing services for commercial conditions.

    Who should own the product model?

    Ownership is usually shared. Product management may own commercial structure, engineering technical rules, manufacturing BOM mappings and finance pricing policies. A governance process coordinates these owners.

    How do you test a CPQ product model?

    Test valid and invalid configurations, boundary values, interacting rules, calculations, revisions, pricing and downstream outputs. Use regression tests whenever a rule or product definition changes.

    How often should a product model be updated?

    Update it whenever product options, engineering rules, component revisions, prices, regulations or downstream mappings change. Releases should be versioned and tested rather than changed informally.

    What is the biggest product-modeling mistake?

    A common mistake is treating the model as a sales questionnaire instead of a controlled representation of product and manufacturing logic. This creates quotes that look complete but require engineering correction.

    Can one CPQ model support CTO and ETO?

    Yes, but the model must distinguish standard configurable paths from nonstandard engineering work. CTO may produce validated outputs directly, while ETO may generate an engineering request and preliminary commercial result.

    How can manufacturers keep a product model maintainable?

    Use modular rules, controlled data, clear ownership, documented calculations, versioning, automated regression tests and a defined process for exceptions and product changes.

  • Cardinality Rules in CPQ Product Models

    Cardinality rules in CPQ product models define how many instances of an option, component, feature or subassembly a user may select. A rule can specify a minimum, maximum or exact quantity, such as requiring one motor, allowing up to four lifting points or permitting exactly two battery modules.

    In manufacturing Configure, Price, Quote (CPQ), cardinality is more than a user-interface setting. It is part of the product model that controls configuration validity, component quantities, pricing, Bill of Materials (BOM) generation and sometimes engineering or Computer-Aided Design (CAD) outputs. A well-designed rule prevents a sales user from quoting a machine that cannot be built, while a poorly designed rule can create false restrictions, incomplete BOMs or excessive manual review.

    This guide explains how cardinality works, how it differs from other configuration rules, where it fits in the CPQ architecture and how manufacturers can implement and maintain it.

    What is a cardinality rule?

    A cardinality rule limits the number of selections or instances associated with a configurable product relationship. It is usually expressed as a minimum and maximum value:

    • Minimum cardinality: the smallest permitted number of selections.
    • Maximum cardinality: the largest permitted number of selections.
    • Exact cardinality: the minimum and maximum are the same.
    • Unbounded or open cardinality: the model permits a variable number of instances, subject to other constraints.

    For example, a pump package may require one drive motor, allow one or two standby pumps and allow up to six monitoring sensors. The cardinality rules describe the permitted count for each relationship without necessarily deciding which specific option is selected.

    Rule Example Manufacturing effect
    Exactly one 1 motor for each pump skid Prevents an incomplete or over-motorized assembly
    Zero or one Optional heater Allows the feature to be omitted or selected once
    One or more At least one safety valve Ensures a required functional capability
    Zero to four Additional lifting lugs Supports variable quantities in a configurable BOM
    Exactly two Two battery modules in a vehicle pack Ensures a balanced or required system design

    How cardinality fits into a CPQ product model

    A CPQ product model represents the structure and logic of a configurable product. It may contain products, assemblies, features, options, attributes, constraints, calculations, prices and output mappings. Cardinality typically applies to the relationship between a parent item and a child option or component.

    For example, a material-handling machine model might contain:

    • one base vehicle;
    • one powertrain selected from diesel, electric or hybrid options;
    • zero or one enclosed operator cabin;
    • zero to three auxiliary hydraulic circuits;
    • one to four stabilizer legs;
    • zero or one remote-control package.

    The cardinality rule tells the CPQ system how many child selections are allowed. Other rules determine whether those selections are compatible. For example, an electric powertrain may require a minimum battery capacity, while a remote-control package may require a specific control system. Cardinality alone does not express every engineering relationship.

    Manufacturers should document the product model separately from the user interface. A visual configurator may show four empty attachment positions, but the underlying model still needs explicit rules defining whether zero, one, two, three or four attachments are valid and how each selection affects the BOM, price and engineering outputs.

    See the guide to product configuration for the wider relationship between product options, dependencies, constraints and validation.

    Common cardinality patterns in manufacturing

    Required single selection

    A required single selection has a cardinality of one to one. It is appropriate when every finished product must contain exactly one component or option. Examples include one motor on a pump, one control cabinet on a machine or one chassis on a specialty vehicle.

    This rule does not necessarily mean that there is only one available product. A user may choose one motor from several valid motor options. The cardinality controls quantity; a separate selection rule controls the available alternatives.

    Optional single selection

    A zero-to-one relationship allows a feature to be omitted or selected once. Examples include an insulation package on an industrial tank, a cab air-conditioning unit on construction equipment or a protective coating on a fabricated assembly.

    Optional does not mean unrestricted. The option may still be required when another feature is selected. For example, a cold-weather package may require the insulation package even though insulation is generally optional.

    Multiple selections with a fixed maximum

    A zero-to-four or one-to-six relationship supports repeated components. This is common for sensors, lifting points, auxiliary outlets, shelves, nozzles, lighting units and attachment positions.

    The maximum should reflect a physical, safety or process limit. If a machine can accept four sensors but the electrical cabinet supports only three input channels, the cardinality should not be four unless the model also includes a rule that adds the required expansion hardware.

    Exact repeated quantity

    An exact quantity is useful when the design requires a fixed number of identical or related components. Examples include two drive motors on a tandem conveyor, four wheels on a vehicle or two redundant pressure sensors in a safety system.

    Exact cardinality can also support manufacturing standards. A product family may require two lifting eyes for a defined load class even though the commercial configurator presents the requirement as a single package selection.

    Variable quantity based on an input

    Some models derive quantity from an engineering input rather than allowing direct selection. A cable tray may require a number of supports based on length. A heat exchanger may require a number of tube bundles based on capacity. A modular conveyor may require additional frame sections based on overall length.

    This is often implemented with a calculation, formula or quantity rule. The resulting quantity behaves like cardinality in the BOM, but it should be distinguished from a user selecting repeated options manually. The model must define rounding, minimums, maximums and exceptions.

    Cardinality rules versus other configuration rules

    Cardinality answers the question, “How many may be selected?” It does not by itself answer whether a selection is compatible, what value an attribute may have or what component should be generated.

    Rule type Main question Example
    Cardinality How many? Up to four hydraulic outlets
    Compatibility constraint Can these selections coexist? High-temperature seals require a compatible fluid package
    Attribute validation Is the entered value within range? Tank diameter must be between 800 and 2,400 millimetres
    Dependency rule What must or must not accompany this option? A second pump requires a larger control panel
    Selection rule Which alternatives are available? Only approved motors are shown for a voltage class
    Quantity calculation What quantity should be generated? One support bracket per 1.5 metres of rail

    Rules-based configuration uses explicit conditions such as “if option A is selected, require option B.” Constraint-based configuration evaluates permitted combinations and values, often across many variables. Guided selling simplifies the user experience by asking business questions and recommending a configuration. A manufacturing CPQ implementation may use all three approaches, but guided selling does not replace the underlying cardinality and engineering rules.

    Manufacturing examples

    Pump skid

    A pump skid may include one duty pump, zero or one standby pump, one motor per pump and zero to eight instrumentation points. If a standby pump is selected, the model may require a second motor, additional isolation valves and a larger base frame. The cardinality rules control the number of pumps and instruments; dependency and compatibility rules control the associated equipment.

    The configured result may produce a configurable BOM with quantities for pumps, motors, valves, transmitters, cable glands and structural members. A pricing engine can use the same quantities to calculate material and labour costs, while an engineering system may use the selections to generate a layout or datasheet.

    Industrial enclosure

    An electrical enclosure may allow zero to twelve cable entries, one or two cooling fans and zero or one heater. The number and location of cable entries affect gland plates, internal clearance and machining operations. Selecting two fans may require a larger power supply and a different control circuit.

    A simple cardinality rule cannot validate physical placement or heat dissipation. Those requirements need spatial, electrical or thermal constraints, calculations or engineering review.

    Specialty vehicle

    A configurable utility vehicle may allow two to six seats, zero or one winch, zero to four auxiliary work lights and one or two battery modules. A second battery may be permitted only with a high-capacity charger and a revised battery enclosure. The configuration can therefore contain both quantity limits and conditional dependencies.

    Cardinality and BOM generation

    A Bill of Materials (BOM) lists the components, subassemblies and quantities needed for a product. Cardinality affects the BOM when each selected instance maps to one or more BOM items.

    Manufacturers should distinguish:

    • Configurable BOM: a model containing alternatives, optional items, rules or quantity logic before a specific order is configured.
    • Engineering BOM (EBOM): the product structure used by engineering to describe the designed product.
    • Manufacturing BOM (MBOM): the production-oriented structure used for manufacturing, assembly, operations and sometimes plant-specific requirements.

    One selected auxiliary circuit may generate a valve, hose kit, control output and mounting hardware. If the user selects three circuits, the CPQ system must either repeat those items three times or apply a quantity formula. That mapping needs to be explicit. A cardinality rule that changes the user interface but does not change downstream quantities is incomplete.

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

    Cardinality, pricing and quoting

    Cardinality and pricing are related but separate concerns. The cardinality rule determines whether a quantity is valid. Pricing logic determines the commercial effect of that quantity.

    For example, the first two sensors on a machine may have standard pricing, while sensors three and four may receive a volume discount or require a higher-capacity signal module. The quote may also include one-time engineering charges if the quantity exceeds a standard package.

    Costing may include material, purchased components, assembly labour, testing and engineering effort. A CPQ system should not assume that multiplying a unit price by quantity produces an accurate manufacturing price. Some costs are fixed, tiered or triggered only when a threshold is crossed.

    Cardinality in CTO, MTO and ETO workflows

    Configure-to-order (CTO) uses predefined options and combinations. Cardinality rules are usually highly structured because the product is designed for repeatable configuration.

    Make-to-order (MTO) produces a product after an order is received, often from a controlled set of specifications. Cardinality may govern selected components while manufacturing planning determines the final production structure.

    Engineer-to-order (ETO) requires new or adapted engineering for a customer order. Cardinality rules can screen standard options and identify when a request exceeds the standard model, but they do not eliminate engineering work. For example, a CPQ model might permit up to four nozzles in a standard vessel but route a request for five nozzles to engineering review.

    Assemble-to-order (ATO) combines stocked modules or subassemblies. Cardinality often controls the number of modules, but inventory and plant constraints may also need to be checked.

    These distinctions are important because a rule that is sufficient for CTO may be only a front-end guardrail for ETO. See the manufacturing workflow guide for the relationship between configuration, engineering and production.

    System architecture and data flow

    In a manufacturing CPQ architecture, cardinality data may be authored in the CPQ product model or synchronized from another product-lifecycle system. The appropriate ownership depends on the implementation.

    1. A product manager or engineer defines the product structure and valid quantities.
    2. The CPQ model exposes selectable options and quantity controls to the sales or dealer user.
    3. The rules engine validates the configuration in real time and again at submission.
    4. Pricing and costing logic evaluates the selected quantities.
    5. The CPQ system generates a quote, configuration record and, where supported, a BOM or order structure.
    6. ERP, Product Lifecycle Management (PLM), Product Data Management (PDM), Manufacturing Execution System (MES) or CAD systems receive the relevant output.

    Enterprise systems are not interchangeable. Customer Relationship Management (CRM) may hold the opportunity and account. Enterprise Resource Planning (ERP) may manage items, inventory, orders and manufacturing transactions. PLM or PDM may govern engineering structures and revisions. CAD may generate geometry and drawings. Product Information Management (PIM) may manage commercial product content. MES may coordinate shop-floor execution.

    Integration decisions should define which system owns option identifiers, revision status, valid dates, quantities, BOM mappings and approval status. More detail is available in the CPQ integration guide.

    Implementation guidance

    Model the relationship, not just the screen

    Do not implement cardinality only as a maximum number of clicks or rows in the interface. Define the parent, child, quantity meaning, physical limit, applicable product revisions and downstream output.

    Use explicit units and identifiers

    Quantities should have clear units and stable identifiers. “Three outlets” may mean three commercial options, three physical ports or three complete outlet assemblies. Those meanings should not be left to interpretation.

    Separate standard limits from engineering limits

    A standard product may allow zero to four attachments, while an engineer could approve five for a special project. Decide whether five is forbidden, allowed through an ETO route or represented as a separate product variant. Do not silently override a standard rule.

    Test boundaries

    Test zero, minimum, maximum and maximum-plus-one values. Also test combinations around dependencies: one pump, two pumps, maximum sensors with one pump, maximum sensors with two pumps and invalid combinations involving incompatible materials or power ratings.

    Version rules with the product

    Cardinality may change when a component is redesigned, a safety standard changes or a manufacturing plant introduces a new limitation. Rules need effective dates, ownership, approval and revision control. A quote created under one product revision should remain reproducible even after the model changes.

    Make rules explainable

    When a user cannot select a third battery module, the message should explain why: for example, “This chassis supports a maximum of two modules” or “A third module requires the reinforced frame package.” Explainable validation reduces sales-engineering queries and helps administrators maintain the model.

    Limitations and common failure modes

    • Confusing option count with physical quantity: one selected package may contain several physical components.
    • Ignoring downstream mappings: the interface allows multiple selections but the BOM or ERP order contains only one item.
    • Using cardinality for every rule: quantity limits cannot replace electrical, structural, thermal or regulatory calculations.
    • Hard-coding limits: values embedded in custom code are harder to audit and revise than governed model data.
    • Overly broad maximums: permissive models create configurations that require manual engineering review.
    • Missing revision context: a quantity valid for one product generation may be invalid for another.
    • Weak error handling: users receive a generic validation failure instead of a useful engineering explanation.

    Not every CPQ platform supports the same depth of cardinality, constraint, BOM, CAD or engineering logic. During software evaluation, verify whether the system supports minimum and maximum quantities, repeated components, conditional quantities, revision control, calculated quantities, validation messages and downstream mappings. Confirm these capabilities with a representative product model rather than relying on a generic feature list.

    How to evaluate cardinality support in CPQ software

    Evaluation area Questions to verify
    Model structure Can a parent contain repeated child components and nested assemblies?
    Rule logic Can minimum, maximum and exact quantities be combined with dependencies?
    Quantity calculation Can quantities be derived from dimensions, capacity or length?
    Validation Are boundary conditions and cross-component constraints supported?
    BOM output Do repeated selections create correct quantities in configurable, engineering or manufacturing structures?
    Pricing Can quantity tiers, fixed charges and threshold costs be represented separately?
    Integration Can rule and product revisions be exchanged with ERP, PLM, PDM, CAD or CRM?
    Governance Can product owners test, approve, version and audit changes?
    Workflow Can invalid or nonstandard quantities be routed to engineering approval?

    A practical proof of concept should use a real configurable assembly, such as a pump skid, electrical enclosure or vehicle body. Include optional items, repeated components, calculated quantities, a pricing threshold and a BOM output. This reveals limitations that a simple option-selection demonstration may hide.

    Semantic map

    The following relationships summarize how cardinality connects product configuration with engineering and manufacturing systems:

    • CPQ product model → contains → configurable products, assemblies and options
    • Cardinality rule → limits → the quantity of selectable components
    • Minimum cardinality → enforces → required product elements
    • Maximum cardinality → prevents → excessive or unsupported component quantities
    • Compatibility constraint → validates → relationships between selected options
    • Configured product → generates → a configuration record and possible BOM
    • Repeated component selection → changes → BOM quantity and manufacturing requirements
    • Quantity calculation → derives → component count from dimensions or capacity
    • Pricing engine → evaluates → quantity-based cost and price rules
    • CPQ → exchanges data with → ERP, CRM, PLM, PDM, CAD or MES
    • CAD automation → generates → product-specific geometry or drawings when supported
    • ETO workflow → routes → nonstandard configurations to engineering review

    Frequently asked questions

    1. What is cardinality in CPQ?

    Cardinality is the permitted number of selections or instances in a CPQ product model, expressed through minimum, maximum or exact quantities.

    2. What is an example of a cardinality rule?

    A machine may allow zero to four auxiliary hydraulic circuits. Zero means the feature is optional, while four is the maximum supported quantity.

    3. Is cardinality the same as an option dependency?

    No. Cardinality controls how many items may be selected. A dependency controls what must, may or may not accompany a selection.

    4. What does a cardinality of one-to-one mean?

    It means exactly one instance is required. A pump skid might require exactly one base frame or one control cabinet.

    5. What does zero-to-one cardinality mean?

    It means an option can be omitted or selected once. It is commonly used for optional heaters, coatings, cabins and accessories.

    6. Can cardinality rules control repeated components?

    Yes. They can allow repeated sensors, valves, lights, seats, outlets or modular sections, provided the CPQ model maps those selections correctly to downstream data.

    7. Can cardinality be calculated from a dimension?

    Yes, in systems that support calculated quantities. For example, a model may derive the number of conveyor supports from conveyor length and a defined spacing rule.

    8. How do cardinality rules affect a BOM?

    They can change the quantity of BOM items or the presence of repeated subassemblies. The model must explicitly map selected instances to configurable, engineering or manufacturing BOM output.

    9. Do cardinality rules determine price?

    No. They determine whether a quantity is valid. Pricing logic separately calculates unit prices, quantity breaks, fixed charges, discounts and additional engineering or manufacturing costs.

    10. Can cardinality rules replace engineering calculations?

    No. They can enforce basic quantity limits, but structural, thermal, electrical, hydraulic and regulatory requirements may need calculations or specialized validation.

    11. How are cardinality rules used in configure-to-order?

    In Configure-to-order, cardinality helps keep selections within a predefined, repeatable product design and supports reliable BOM and order output.

    12. How are cardinality rules used in engineer-to-order?

    They define the standard product boundary. A request outside that boundary can be blocked or routed to engineering for review rather than treated as a normal configuration.

    13. Should cardinality rules live in CPQ or PLM?

    Ownership depends on the architecture. CPQ may own commercial configuration logic, while PLM or PDM may govern engineering structures. Ownership, synchronization and revision rules must be explicit.

    14. What is the difference between a configurable BOM and a cardinality rule?

    A configurable BOM describes alternatives, options and quantities for a product family. Cardinality is one type of rule that controls how many related items may be selected within that structure.

    15. How should manufacturers test cardinality?

    Test zero, minimum, maximum and maximum-plus-one values, then test combinations with dependencies, dimensions, pricing thresholds and BOM output.

    16. What happens if a user exceeds the maximum?

    A well-designed CPQ system blocks the invalid configuration or provides a clear route to an engineering approval process. It should explain the physical or product-model reason.

    17. Can cardinality vary by product revision?

    Yes. A new chassis, control panel or safety design may change permitted quantities. Rules should be versioned with effective dates and product revisions.

    18. What should a CPQ software evaluation demonstrate?

    The demonstration should include nested assemblies, repeated components, calculated quantities, conditional dependencies, pricing effects, revision control and accurate BOM or order output for a real manufactured product.

    For implementation planning, rule governance, testing and maintenance, consult the CPQ implementation guide. For CAD and engineering dependencies, see the CAD and engineering automation guide.

  • Handling Engineer-to-Order Exceptions Inside CPQ

    Engineer-to-order (ETO) exceptions are customer requirements that fall outside a manufacturer’s standard product model. In a manufacturing CPQ process, the objective is not to force every unusual request into a predefined option list. The objective is to identify what can be configured safely, isolate what requires engineering judgment, collect the information needed for review, and transfer an approved design into quoting and production systems without losing traceability.

    This is different from generic sales CPQ, where an exception may simply require a manager’s pricing approval. In manufacturing, an exception can affect structural integrity, motor selection, materials, safety compliance, manufacturing methods, the bill of materials (BOM), computer-aided design (CAD) files, lead time and warranty obligations. CPQ must therefore manage the boundary between rules-based configuration and engineering work.

    A practical ETO exception workflow uses the product model to validate standard requirements, an exception object or engineering request to capture the deviation, workflow rules to route it to the right reviewer, and controlled outputs to update the quote, BOM, CAD data and enterprise systems after approval. The exception should remain visible throughout the manufacturing workflow, rather than disappearing into email or free-text quote notes.

    What is an engineer-to-order exception?

    An engineer-to-order exception is a customer or project requirement that cannot be fulfilled entirely by the current standard configuration model and therefore requires additional engineering analysis, design work, approval or production planning.

    Examples include a pump requiring a non-standard wetted material, a conveyor needing an unusual length and support arrangement, an air-handling unit requiring a casing dimension outside the standard range, or a mobile machine requiring a mounting interface that has not been modeled previously.

    An exception does not always mean that the entire product becomes a one-off design. Many ETO products contain a standard core with a limited custom portion. CPQ should preserve the standard elements and identify only the affected assemblies, calculations, drawings, parts and commercial assumptions.

    Common categories of ETO exception

    Exception type Manufacturing example Likely review
    Parameter outside range A pressure vessel diameter exceeds the modeled standard range Mechanical engineering and compliance
    New combination A motor, gearbox and impeller combination has not been validated Application engineering and testing
    New component A customer requests an unlisted alloy or sensor Engineering, purchasing and quality
    Interface change A skid requires a customer-specific pipe or mounting connection Mechanical and manufacturing engineering
    Performance requirement A fan must meet an unusual airflow, noise or temperature condition Engineering calculation and validation
    Compliance exception A machine must satisfy a regional electrical or hazardous-area requirement Compliance and technical authority
    Process exception A welded assembly requires a non-standard fabrication sequence Manufacturing engineering and quality

    Why ETO exceptions need controlled handling

    Uncontrolled exceptions create a gap between the sales promise and the engineered product. A salesperson may record “special stainless construction” in a quote, while engineering later discovers that the requested material changes shaft tolerances, seals, welding procedures, cost and delivery time.

    The risks are interconnected:

    • Configuration risk: the proposed combination may violate a technical dependency that is not visible to sales.
    • Cost risk: engineering hours, prototypes, special tooling, testing and low-volume components may be omitted from the price.
    • Schedule risk: review, design, procurement and approval activities may extend the promised delivery date.
    • Data risk: an approved custom design may not be reflected in the BOM, CAD files, ERP item structure or manufacturing instructions.
    • Governance risk: a one-time workaround may later be reused without the original engineering assumptions.

    CPQ does not eliminate these risks by itself. It provides a controlled place to capture the requirement, apply known rules and manage the handoff. The product model, engineering systems and approval processes still need clear ownership.

    The boundary between configuration and engineering

    A maintainable CPQ implementation distinguishes three outcomes instead of treating every request as either valid or invalid.

    Outcome Meaning Typical CPQ action
    Valid standard configuration The request is inside approved product rules and parameter ranges Allow configuration and generate normal commercial and manufacturing outputs
    Conditional configuration The request is known but requires a calculation, document, approval or additional input Allow provisional configuration and create a review task
    Unmodeled ETO exception The requirement is outside the current product model or creates a new design problem Capture an exception request, restrict commitments and route to engineering

    This distinction is more useful than a simple “configuration failed” message. A failed configuration may be technically correct but operationally incomplete. For example, a 7.5 kW motor may be valid for a standard pump range, while a 15 kW motor may be possible only after checking the shaft, coupling, baseplate and power supply. The latter should become a conditional or ETO case, not an unstructured override.

    Manufacturers should document this boundary in the product configuration model. Rules that are stable and reusable belong in the model. Decisions that require case-specific engineering evidence belong in a controlled exception workflow.

    Product-model logic for ETO exceptions

    Rules-based configuration

    Rules-based configuration uses explicit conditions such as “if option A is selected, option B is required” or “if frame size is X, only motors from list Y are permitted.” These rules are suitable for known relationships, exclusions, defaults and permitted ranges.

    For an industrial pump, rules might require a particular seal family for a corrosive fluid, prevent a small motor from being paired with a large impeller, or restrict a casing material to specified temperature ranges.

    Constraint-based configuration

    Constraint-based configuration represents technical limits and relationships that may involve dimensions, capacities, loads, temperatures, materials or calculations. A constraint could compare required flow and head with an operating envelope, verify that a frame can support a selected motor, or check that a platform length remains within transport limits.

    Constraints are useful for detecting whether a request is inside the modeled design space. They do not automatically solve every design problem. If the requested value is outside the design space, CPQ should explain the constraint and offer an ETO path where appropriate.

    Guided selling

    Guided selling asks users questions in a business-friendly sequence and recommends suitable products or options. It is useful for helping a distributor or sales engineer collect application information, but it should not be confused with engineering validation. A guided question such as “What fluid will the pump handle?” may select a material family; it does not replace a materials review for an unusual chemical or temperature.

    Exception-aware model behavior

    A mature product model can define an explicit response for an out-of-model request. That response may include:

    • the reason the standard configuration cannot be confirmed;
    • the technical data that must be supplied;
    • the type of engineering review required;
    • the options that remain provisional;
    • the estimated engineering effort or commercial allowance;
    • the approval level needed before a quote can become firm;
    • the downstream outputs that will be blocked until approval.

    For example, a CPQ system may permit a non-standard conveyor width to be entered, but mark the conveyor frame, guards, drive selection and drawing as pending engineering review. It should not silently generate a production-ready BOM as though the design were already approved.

    Data captured in an ETO exception

    An exception record should contain more than a description such as “customer needs custom design.” It should provide enough structured information for engineering to assess feasibility and for commercial teams to understand the consequences.

    Data group Examples
    Commercial context Opportunity, customer, quote revision, requested delivery date and sales owner
    Application requirements Capacity, duty cycle, fluid, temperature, pressure, environment, load and operating conditions
    Requested deviation Dimension, material, interface, performance target, component or compliance requirement
    Configuration context Selected model, options, quantities, affected assemblies and standard alternatives considered
    Engineering evidence Calculations, customer drawings, specifications, photographs, test requirements and assumptions
    Commercial impact Engineering hours, special components, tooling, testing, risk allowance, lead-time impact and provisional price
    Governance Owner, reviewer, status, decision date, revision, reason code and links to approved design records

    Structured fields should be used for information that affects rules, routing, pricing or reporting. Documents and free text remain useful for context, but they should not be the only place where a critical requirement is stored.

    Workflow: from exception request to approved order

    1. Capture the requirement

    The salesperson, distributor or application engineer records the customer requirement through the CPQ interface. The system should identify the affected product, configuration revision and quote line. If the request originated in a customer drawing or specification, that document should be attached or referenced.

    2. Run standard validation

    CPQ evaluates all known product rules and constraints before creating the exception. This prevents engineering from spending time on a request that is already invalid because of a basic incompatibility. The system should distinguish a hard failure from a review condition.

    3. Classify the exception

    Classification can be based on the affected discipline, technical risk, novelty, compliance implications or expected commercial impact. A low-risk non-standard finish may need product engineering approval, while a pressure boundary change may require a formal design review and compliance sign-off.

    4. Estimate commercial and schedule impact

    CPQ can apply provisional engineering charges, special material costs, risk allowances or lead-time rules. These are estimates until engineering completes the review. The quote should clearly label assumptions and conditions rather than presenting an uncertain value as a final commitment.

    5. Route the review

    Workflow rules send the request to the appropriate engineering owner. Routing may depend on product family, material, country, compliance category, plant or exception type. Approval should be role-based and traceable. An email notification alone is not a sufficient system of record.

    6. Record the engineering decision

    The reviewer should be able to approve, reject, request more information, propose a standard alternative or convert the request into a reusable product feature. The decision should state assumptions, limits and required downstream actions.

    7. Update outputs and quote status

    After approval, the system may update the configurable BOM, item selections, price, cost, lead time and quote documents. Where supported, it may also trigger CAD or calculation automation. Until the relevant review is complete, production-facing outputs should remain provisional or blocked.

    8. Handoff the approved order

    The final order package may include the approved configuration, exception decision, engineering documents, BOM references, drawings, calculations, customer approvals and commercial assumptions. Integration with enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), manufacturing execution systems (MES) or CAD tools depends on the organization’s architecture and the capabilities of the selected CPQ platform.

    How exceptions affect BOM, CAD, pricing and quoting

    Configurable BOM, EBOM and MBOM

    A configurable BOM represents the selectable structure before all choices are resolved. An engineering BOM (EBOM) describes the product from a design perspective, while a manufacturing BOM (MBOM) represents the structure and operations needed to build it. An ETO exception may change both structures, but not necessarily in the same way.

    For example, a custom enclosure may require a new EBOM component and drawing, while the MBOM also needs a special bending operation, inspection step and purchased fasteners. CPQ should not claim to generate a complete MBOM unless that capability and integration are actually implemented. In some architectures, CPQ produces a provisional configuration and ERP or PLM creates the controlled engineering and manufacturing structures.

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

    CAD and engineering automation

    Some manufacturing CPQ platforms can pass approved parameters to CAD automation tools to create models, drawings or calculation inputs. Others only record the requirements and link to external CAD or PLM processes. The distinction matters for ETO exceptions.

    A custom dimension may be safe to pass to a parametric CAD template if the template covers that range. A new structural arrangement may require a designer to create and review a new model. The CPQ workflow should identify which outputs are automated, which are manual and which require formal release.

    See CAD and engineering automation in manufacturing CPQ for the relationship between configuration parameters, calculations, models and drawings.

    Cost and price

    Exception pricing should account for more than material cost. Potential elements include design hours, analysis, prototyping, testing, special tooling, supplier minimums, expedited procurement, additional inspection and manufacturing inefficiency. Some of these may be calculated in CPQ; others may require an engineering or project estimate.

    Pricing and engineering approval should be coordinated. Approving technical feasibility without updating cost can create an unprofitable order. Conversely, adding a large contingency without documenting its basis can make a technically suitable proposal commercially uncompetitive.

    Exception statuses and controls

    A simple status model helps users understand whether a quote can be issued, accepted or released. A possible model is:

    1. Draft: the requirement is being collected.
    2. Validation required: standard CPQ rules have not yet completed.
    3. Engineering review: the request is assigned to an engineering owner.
    4. More information required: required data or documents are missing.
    5. Conditionally approved: the design is acceptable subject to stated assumptions or tests.
    6. Approved for quote: commercial values and scope can be presented under defined conditions.
    7. Approved for order: the required technical and commercial approvals are complete.
    8. Rejected: the request cannot be supported or is not commercially viable.
    9. Converted to standard feature: the approved solution is being modeled for future reuse.

    Permissions should reflect these states. A sales user may create an exception, but only an authorized engineering role may approve a pressure boundary change. A quote may be sent with a clearly stated engineering contingency, while order release remains blocked until required documents are approved.

    Designing maintainable exception logic

    Do not turn every exception into a permanent option

    If each customer-specific variation is added directly to the product model, the model can become difficult to test and understand. The result is often a large number of conditional rules, duplicate options and exceptions that conflict with one another.

    Use a decision framework:

    • Model a variation as a standard option when it is repeatedly sold, technically understood and operationally supported.
    • Use a conditional rule when the variation is known but requires a defined calculation or approval.
    • Keep it as an ETO exception when the design is genuinely novel, infrequent or dependent on case-specific engineering.
    • Retire or redesign the process when repeated exceptions reveal a missing product family or poorly defined standard range.

    Separate reusable rules from case decisions

    A reusable rule might state that a certain seal material is required above a temperature threshold. A case decision might approve a particular seal arrangement for one unusual chemical after reviewing supplier data. The first belongs in governed product logic; the second belongs in the exception record unless it is later validated for general use.

    Version the model and the exception

    Quotes can remain open while product rules change. Store the product-model version, rule version, configuration revision and exception revision with the quote. Otherwise, an engineer reviewing a later revision may not know which constraints applied when the original commercial commitment was made.

    Test negative and boundary cases

    Testing should cover valid configurations, invalid combinations, borderline values, missing data, rejected exceptions, approval reversals and changes after approval. A model that works for a standard pump may still fail when a material change affects price, BOM selection and CAD parameters simultaneously.

    Integration architecture

    Exception handling commonly crosses several systems, but each system should have a defined responsibility.

    System Typical responsibility
    CRM (customer relationship management) Opportunity, account, contacts and commercial pipeline context
    CPQ Configuration, rules, quote context, exception capture, pricing and approval workflow
    CAD Models, drawings and design geometry where automation or manual design is required
    PLM Product revisions, engineering change control, release status and lifecycle governance
    PDM (product data management) Controlled storage and relationships for design files and technical documents
    ERP (enterprise resource planning) Items, purchasing, inventory, production orders, costing and order execution
    MES (manufacturing execution system) Shop-floor instructions, execution records and production feedback

    These systems are not interchangeable. A CPQ exception record may initiate a PLM review, reference a CAD drawing and send approved item data to ERP. The exact flow depends on the manufacturer’s data ownership and the documented capabilities of the platforms involved. See the CPQ integration guide for integration patterns and boundary decisions.

    Implementation approach

    1. Map current exceptions: review recent quotes, engineering requests and order corrections. Classify the reasons, affected data and outcomes.
    2. Identify high-value boundaries: start with exception types that cause recurring delays, margin leakage, rework or order errors.
    3. Define the standard model: document options, ranges, dependencies, calculations and approved alternatives before designing the exception workflow.
    4. Define ownership: assign responsibility for product rules, engineering decisions, pricing assumptions, CAD outputs, BOM release and system integration.
    5. Build structured exception forms: require the application data and documents needed for a real review.
    6. Set approval gates: define when a quote can be issued, when an order can be accepted and when production data can be released.
    7. Integrate selectively: automate stable data exchanges first. Do not create a complex CAD or PLM integration before the exception process and data definitions are stable.
    8. Measure and improve: review exception volume, turnaround time, rework, approval outcomes, margin variance and conversion into standard features.

    Implementation planning should include data migration, testing, deployment, adoption and long-term governance. The manufacturing CPQ implementation guide covers these activities in more detail.

    Benefits and limitations

    Potential benefits

    • Earlier visibility of technical risk during quoting.
    • Less reliance on email, spreadsheets and unstructured quote notes.
    • Better separation between standard configuration and genuine engineering work.
    • More accurate estimates for engineering effort, special materials and lead time.
    • Traceable approval decisions and assumptions.
    • Improved continuity between the quote, approved design, BOM and order.
    • Reusable knowledge when recurring exceptions are converted into governed product features.

    Important limitations

    • CPQ cannot replace engineering judgment for novel designs, testing or regulatory decisions.
    • A workflow cannot compensate for inaccurate product data or unclear ownership.
    • Exception pricing is difficult when engineering effort and manufacturing risk are not estimated consistently.
    • Automated CAD, BOM or ERP outputs require compatible data models and integrations; they are not universal CPQ features.
    • Allowing unrestricted overrides can undermine configuration governance and create unsafe or unmanufacturable orders.
    • Over-modeling every possible custom request can make the product model expensive to maintain.

    Practical example: custom pump skid

    Consider a pump skid configured for a chemical-processing application. The standard CPQ model validates flow, head, pump size, motor, base frame, valves and instrumentation. A customer then requests a non-standard alloy, a different nozzle orientation and a compact footprint.

    CPQ can first check whether the alloy is an approved material for the fluid and temperature. It can identify that the nozzle orientation is outside the standard CAD template and that the compact footprint may reduce maintenance clearance. The request is classified as an ETO exception and routed to mechanical, materials and application engineering.

    The provisional quote includes the standard pump package, an engineering allowance, special material cost and a conditional lead time. Engineering confirms the material, redesigns the base, verifies access clearances and approves the nozzle arrangement. The final record references the approved drawing revision, updated EBOM, manufacturing requirements and commercial changes. ERP receives the released item and order data only after the required technical gate is complete.

    This is a controlled CPQ order process: the customer receives a usable commercial response before every design detail is complete, but the manufacturer does not confuse a provisional configuration with a production-ready design.

    FAQ

    What is an ETO exception in CPQ?

    It is a customer requirement outside the approved standard product model that requires engineering analysis, design, approval or special manufacturing planning.

    Should CPQ reject every configuration outside the standard range?

    No. CPQ should distinguish between an impossible request, a known conditional request and a genuinely new ETO requirement. Conditional requests can be routed for review instead of being silently rejected.

    Can CPQ replace an engineer for ETO products?

    No. CPQ can apply known rules, collect requirements, calculate supported values and route work, but engineers remain responsible for novel designs, technical judgments, testing and formal approval.

    How should a non-standard dimension be handled?

    Validate it against modeled limits first. If it is outside those limits but potentially feasible, capture it as an exception with affected assemblies, engineering inputs, cost impact and approval requirements.

    What is the difference between a configuration error and an ETO exception?

    A configuration error violates a known rule or technical constraint. An ETO exception is outside the current model and may be feasible after engineering review.

    Should ETO exceptions be stored as free-text notes?

    No. Use structured fields for requirements, affected components, status, owner, cost, lead time and approvals. Attachments and notes can provide supporting context.

    How does exception handling affect CPQ pricing?

    It can add engineering labor, special materials, testing, tooling, procurement risk, manufacturing effort and schedule allowances. These values should be labeled as estimates until the technical review is complete.

    Can an exception generate a BOM before approval?

    It may generate a provisional or configurable BOM, depending on the platform. A released production BOM should normally wait for the required engineering and manufacturing approvals.

    What is the role of CAD in ETO exception handling?

    CAD may validate or generate product-specific models and drawings. Some CPQ platforms automate this through templates, while others only pass requirements to CAD, PDM or PLM systems.

    When should an exception become a standard product option?

    Consider conversion when the variation is repeatedly requested, technically validated, commercially supported and maintainable within the product model.

    How can manufacturers prevent too many product-model exceptions?

    Review exception history, improve option definitions and ranges, standardize recurring designs and use governance to decide which deviations belong in the core model.

    What approval levels are useful for ETO requests?

    Approval levels can reflect technical risk, compliance impact, commercial exposure, engineering effort and production consequences. A minor finish change should not follow the same path as a pressure-boundary redesign.

    How should CPQ handle missing engineering information?

    Set the exception to a “more information required” status, identify the missing fields or documents and prevent final approval until the required information is supplied.

    Can CPQ manage customer-specific designs?

    It can manage the commercial and configuration context and link to controlled design records. The actual customer-specific CAD and lifecycle control may belong in CAD, PDM or PLM.

    How do ETO exceptions affect configure-to-order?

    They create a boundary between configure-to-order (CTO), where predefined choices determine the product, and ETO, where engineering must create or approve new design work. The order should follow the appropriate path rather than being mislabeled as CTO.

    What is the difference between ETO and make-to-order?

    Make-to-order (MTO) generally means production begins after an order but uses an established design. ETO requires new or customer-specific engineering work in addition to order-triggered production.

    Which metrics help evaluate exception handling?

    Useful measures include exception volume by type, engineering review time, percentage requiring more information, quote revision count, approval cycle time, rework, margin variance, order corrections and conversion of recurring exceptions into standard features.

    Semantic map

    The article connects the following manufacturing CPQ entities and relationships:

    • CPQ manages the boundary between standard configuration and ETO engineering.
    • Product models define options, parameters, dependencies and approved ranges.
    • Configuration rules prevent known invalid combinations.
    • Constraints identify values that require review when they exceed modeled limits.
    • ETO exceptions capture requirements outside the standard product model.
    • Engineering reviews determine technical feasibility and design responsibility.
    • Approved exceptions can update configurable BOMs, EBOMs and MBOMs.
    • CAD automation can generate product-specific models and drawings when templates support the design.
    • Pricing logic estimates engineering effort, special materials, testing and manufacturing risk.
    • Workflow approvals control quote release, order acceptance and production release.
    • PLM and PDM manage controlled product and design records.
    • ERP manages items, purchasing, production, costing and order execution.
    • Recurring exceptions can become governed standard product features.

    For broader context, see the guide to manufacturing CPQ and the related material on CTO, ETO, MTO and order-to-production workflows.

  • Needs-Based Configuration and Guided Selling in Manufacturing CPQ

    Needs-based configuration and guided selling help manufacturers convert customer requirements into a valid product configuration. Instead of asking a buyer to understand every model code, component dependency and engineering limitation, the system asks questions about the application, operating conditions and required performance. It then recommends suitable products or options, prevents invalid combinations and can pass the result to pricing, quoting, bill of materials (BOM) generation, engineering and production systems.

    In manufacturing, guided selling is not simply a sales questionnaire. It is a user-facing method for accessing a governed product model. The underlying model may contain configurable products, options, constraints, calculations, approval rules, prices, technical attributes and manufacturing data. The quality of the outcome depends more on that product model than on the wording of the questions.

    This makes guided selling particularly useful for industrial machinery, pumps, valves, HVAC equipment, electrical systems, material-handling equipment, specialty vehicles and other products where customers describe a requirement rather than specify an exact part number.

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

    What are needs-based configuration and guided selling?

    Needs-based configuration is the process of selecting or designing a product configuration from customer requirements, application conditions and performance objectives rather than from a known product code.

    Guided selling is the interaction layer that leads a salesperson, dealer, engineer or customer through relevant questions and recommendations to reach an appropriate product configuration.

    A manufacturing CPQ system may use guided selling to collect information such as:

    • Required flow rate, pressure, temperature or lifting capacity;
    • Product dimensions, installation space and environmental conditions;
    • Material compatibility, corrosion exposure or hygiene requirements;
    • Voltage, frequency, motor size or control-panel requirements;
    • Duty cycle, speed, payload, range or operating terrain;
    • Required standards, certifications or safety features;
    • Delivery constraints, target cost or preferred commercial options.

    The system maps those answers to product families, technical parameters and configuration rules. It may then recommend one or more valid configurations, identify missing information, calculate a product size and produce a quote. Whether it also generates a BOM, CAD output or manufacturing order depends on the capabilities and integrations of the specific CPQ implementation.

    Why guided selling matters in manufacturing

    Industrial products are often sold through application requirements. A customer may know that a pump must move a liquid at a particular flow and pressure, but may not know the impeller diameter, motor rating, seal material or casing configuration required. Similarly, a customer ordering an air-handling unit may specify airflow, static pressure, ambient conditions and filtration requirements without knowing the internal component selection.

    A traditional catalogue or generic sales CPQ tool may support product selection and pricing but leave the technical interpretation to an application engineer. Manufacturing-oriented guided selling attempts to encode enough product and engineering knowledge to make that interpretation repeatable.

    Sales situation Traditional approach Needs-based CPQ approach
    Customer describes an application Salesperson sends requirements to an engineer Guided questions capture structured technical inputs
    Product selection Search through catalogues or spreadsheets Rules and calculations recommend valid product families and options
    Technical validation Manual review after the quote Constraints identify invalid or incomplete configurations during selection
    Engineering handoff Free-text notes and attachments Structured configuration data, attributes, documents and outputs
    Production preparation Manual interpretation of the quoted product Configurable BOM or order data where supported

    The objective is not to remove engineering judgment from every sale. It is to reserve engineering time for genuinely novel, high-risk or engineered-to-order work while allowing repeatable configurations to follow a controlled path.

    How the product model supports guided selling

    The product model is the structured representation of the products, options, relationships and technical logic used by the CPQ system. It is the foundation of guided selling. A question-and-answer interface without a reliable product model can make the sales process look simpler while producing unreliable results.

    Product families and configuration attributes

    A product family defines the scope of a configuration, such as centrifugal pumps, industrial control panels or electric forklifts. Within the family, the model may contain attributes and selectable features. Attributes describe requirements or product characteristics, while options represent choices that can be selected or derived.

    For a pump, attributes might include flow, differential pressure, fluid temperature, fluid chemistry and operating speed. Options might include casing material, seal type, impeller trim, motor enclosure, coupling arrangement and mounting configuration.

    Questions and answer mappings

    Guided selling questions should collect information that has a technical or commercial purpose. Each answer should map to one or more model values, constraints or calculations. For example:

    • The question about fluid type may restrict casing, seal and elastomer materials.
    • The question about flow and pressure may select a pump family and determine a required operating point.
    • The question about outdoor installation may require a weatherproof enclosure or environmental protection rating.
    • The question about available electrical supply may restrict motor voltage and starter options.

    Questions should not be added merely because the information is interesting. Every question creates user effort, training requirements and a maintenance obligation. A useful question either changes the recommendation, validates the configuration, calculates a value, determines price or supplies information needed downstream.

    Rules, constraints and calculations

    Rules describe how selections affect other selections. A rule may say that choosing a high-temperature application requires a particular seal material. Constraints define combinations that are prohibited or conditions that must be satisfied. A constraint may prevent a stainless-steel option from being paired with an incompatible coating.

    Rules can be implemented in different ways, including decision tables, dependency logic, formulas, scripts or constraint-solving engines. The implementation should be understandable to the people who own the product model. A technically powerful rule that cannot be tested or maintained can become a long-term operational risk.

    Calculations are also important. A guided selling process may calculate motor power, structural capacity, heat load, cable size, tank volume or required safety margin. These calculations should have clear units, input ranges, assumptions, rounding rules and approval requirements. CPQ calculations are not automatically a substitute for certified engineering analysis.

    Example: guided selling for an industrial pump

    Consider a manufacturer selling configurable process pumps. A customer begins with an application rather than a part number.

    1. The system asks for required flow, pressure, fluid, temperature and operating hours.
    2. It determines which pump families can meet the duty point.
    3. It excludes materials and seals that are incompatible with the fluid or temperature.
    4. It checks whether the operating point falls within an approved performance range.
    5. It recommends a pump size, impeller range, motor rating and seal arrangement.
    6. It asks about installation orientation, coupling, baseplate and control requirements.
    7. It calculates a price and identifies lead-time or engineering-review conditions.
    8. It creates a quote and, where configured, a product-specific BOM or engineering request.

    The result is more than a recommended product name. It is a structured configuration with technical inputs, selected options, derived values and traceable assumptions. If the selected pump is a configure-to-order product, the configuration may generate a manufacturing-ready BOM. If the application falls outside the standard model, the system may route it into an engineer-to-order workflow instead.

    For related manufacturing data flows, see the guide to BOM generation, pricing and quoting and the guide to configure-to-order and engineer-to-order workflows.

    Guided selling versus related configuration approaches

    Approach Primary purpose Typical input Manufacturing use
    Rules-based configuration Apply explicit dependencies and conditions Selected options and attribute values Prevent incompatible options and derive required components
    Constraint-based configuration Find combinations that satisfy multiple technical constraints Requirements, limits and relationships Select equipment that meets performance and compatibility conditions
    Guided selling Lead a user through questions and recommendations Application and business requirements Help non-specialists reach a technically valid configuration
    Product search Find an existing item Keywords, attributes or part numbers Locate standard products when the required item is already known
    Visual configuration Show appearance, layout or spatial arrangement Selected visual options Represent vehicle bodies, machine layouts or finish combinations

    These approaches can coexist. A guided selling interface may collect application requirements, a constraint engine may determine feasible products, rules may control option dependencies, and a visual configurator may show the result. They should not be treated as interchangeable capabilities.

    From guided questions to manufacturing outputs

    Guided selling normally sits at the front of a broader CPQ and enterprise workflow.

    1. Requirement capture: The user enters application, performance, commercial and delivery requirements.
    2. Product recommendation: The system identifies suitable product families or configurations.
    3. Configuration validation: Rules, constraints and calculations check technical feasibility.
    4. Pricing and costing: The system applies prices, discounts, surcharges, estimated costs or approval thresholds.
    5. Quote generation: A proposal presents the selected product, scope, assumptions, price and delivery information.
    6. Engineering handoff: Structured data, customer requirements and exceptions are passed to engineering when required.
    7. Downstream execution: Depending on the architecture, the configuration may create an order, configurable BOM, engineering record, CAD request or ERP transaction.

    An enterprise resource planning (ERP) system normally manages business transactions, inventory, purchasing and production planning. A product lifecycle management (PLM) system manages product definitions, revisions and lifecycle processes. A product data management (PDM) system typically manages engineering files and CAD relationships. A computer-aided design (CAD) system creates product geometry and drawings. These systems are related but not interchangeable.

    CPQ may exchange data with each system, but the ownership of product data must be explicit. A CPQ model should not silently become an uncontrolled duplicate of engineering or ERP data.

    EBOM, configurable BOM and MBOM considerations

    A bill of materials (BOM) is a structured list of components and quantities. An engineering BOM (EBOM) represents the product from an engineering design perspective. A manufacturing BOM (MBOM) represents how the product is assembled or produced. A configurable BOM contains rules or alternatives that resolve according to the selected configuration.

    Guided selling can supply the inputs used to resolve a configurable BOM, but it does not automatically create a correct production structure. The implementation must define:

    • Which components are selected by customer options;
    • Which components are derived from calculations;
    • Which items are sales-only, engineering-only or manufacturing-relevant;
    • How revisions and effective dates are controlled;
    • How substitutes, phantom assemblies and purchased components are represented;
    • How the resolved structure is transferred to ERP, PLM or manufacturing systems.

    For example, choosing a longer conveyor may require additional frame sections, guards, belts, fasteners and a different drive arrangement. The customer-facing answer is simple, but the downstream structure may involve many dependencies. BOM ownership and revision governance should be defined before automating order release.

    Designing effective guided selling questions

    Start with customer language, then map to engineering data

    Customers may say that a machine must operate outdoors, handle abrasive material or fit through a particular doorway. Engineering models may require ingress protection, material grade, wear allowance or maximum envelope dimensions. The guided selling layer should translate between those vocabularies without hiding important assumptions.

    Ask high-value questions first

    Early questions should identify the product family and eliminate large parts of the product space. Later questions can address options that apply only to the selected family. This reduces cognitive load and prevents users from answering questions that are irrelevant to their application.

    Use progressive disclosure

    Show advanced questions when a prior answer makes them relevant. For example, ask about hazardous-area certification only when the application environment requires it. However, do not hide mandatory technical inputs so deeply that users cannot understand why the system cannot complete the configuration.

    Explain recommendations and exclusions

    A recommendation is more credible when the system explains its basis, such as meeting the required flow and pressure or satisfying an environmental rating. When an option is unavailable, a useful message identifies the reason and, where appropriate, an alternative. Messages should be understandable to sales users while retaining enough detail for technical review.

    Maintainability and governance

    Guided selling models become difficult to maintain when rules are scattered across code, spreadsheets, product descriptions and individual employee knowledge. A maintainable model has clear ownership and traceability.

    • Define rule ownership: Product management may own commercial options, engineering may own technical constraints, and manufacturing may own production mappings.
    • Separate concerns: Keep configuration logic distinct from pricing, document templates and integration transformations where practical.
    • Use controlled terminology: Define units, attribute names, option codes, material names and status values consistently.
    • Version the model: Product revisions, supplier changes, standards and effective dates can alter valid configurations.
    • Record assumptions: Calculations should identify source data, tolerances, safety factors and approval requirements.
    • Test combinations: Use positive, negative, boundary, regression and end-to-end tests.
    • Monitor exceptions: Frequent manual overrides may indicate missing rules, inaccurate data or a product family that should be treated as engineered-to-order.

    Implementation planning should cover model governance, migration, testing, deployment and ongoing maintenance. The CPQ implementation guide provides a broader framework for these activities.

    Limitations and risks

    Needs-based configuration does not eliminate ambiguity in customer requirements. A customer may provide incomplete, inaccurate or contradictory information. The system should identify missing inputs and uncertainty instead of producing a false sense of precision.

    Other risks include:

    • Overly complex questionnaires: Users may bypass the process or provide arbitrary answers.
    • Outdated rules: Product changes can make recommendations or BOM mappings invalid.
    • Hidden engineering assumptions: A simplified question may omit a condition that affects safety or performance.
    • Conflicting system ownership: Different values in CPQ, ERP, PLM and CAD can create downstream errors.
    • Excessive customization: One-off exceptions can turn a reusable model into unmaintainable application code.
    • Misuse of recommendations: A suggested configuration may require engineering approval, certification or site-specific validation.
    • Weak exception handling: The system needs a controlled path for ETO, non-standard materials, special compliance requirements and incomplete data.

    For safety-critical equipment, pressure systems, lifting equipment, medical products or regulated electrical assemblies, guided selling should support—not replace—the applicable engineering review and compliance process.

    Implementation approach

    1. Select a focused product family: Begin with a product that has meaningful configuration volume, stable rules and measurable engineering or quoting friction.
    2. Document the decision process: Capture how experienced application engineers select products today, including exceptions and information sources.
    3. Build the canonical product model: Define families, attributes, options, constraints, calculations, prices and downstream mappings.
    4. Classify outcomes: Separate standard configurable products, configure-to-order (CTO) products, make-to-order (MTO) products, assemble-to-order (ATO) products and engineer-to-order (ETO) cases.
    5. Design the conversation: Organize questions by decision value, user role and product stage.
    6. Connect downstream systems carefully: Establish whether CPQ receives or publishes data to CRM, ERP, PLM, PDM, CAD, product information management (PIM) or manufacturing execution system (MES) platforms.
    7. Test with real scenarios: Include common applications, boundary conditions, invalid combinations, discontinued options and engineering overrides.
    8. Release with governance: Define who approves model changes, how revisions are deployed and how affected quotes or orders are handled.
    9. Measure operational results: Track configuration errors, quote completion, engineering escalations, manual overrides, rework and time to produce a technically complete quote.

    Platform selection should verify these capabilities directly. Not every CPQ product supports constraint solving, engineering calculations, BOM generation, CAD automation, 3D visualization or PLM integration. The manufacturing CPQ comparison and selection resources can help structure an evaluation.

    When to use guided selling

    Guided selling is most valuable when customers know their requirements but cannot reliably translate them into a product code. It is a strong fit for product families with repeatable rules, meaningful option dependencies and a large dealer, sales or application-engineering population.

    It may be less suitable as the primary interface when every project is unique, requirements are unstable or the product requires extensive conceptual engineering before a valid design can be defined. In those cases, CPQ can still capture requirements and manage commercial information while routing the opportunity to an ETO process.

    The appropriate goal is not to force every product into a questionnaire. It is to create a controlled path for repeatable decisions and a clear escalation path for decisions that still require engineering expertise.

    FAQ: needs-based configuration and guided selling

    1. What is guided selling in CPQ?

    Guided selling in CPQ is a question-and-recommendation process that helps a user select a suitable product and valid options. In manufacturing, it can use application requirements, technical rules and calculations rather than only commercial preferences.

    2. How is guided selling different from product configuration?

    Product configuration defines the product model, options and validity logic. Guided selling is the user experience that helps someone reach a configuration through relevant questions and recommendations.

    3. Is guided selling the same as a product selector?

    Not always. A basic product selector may filter catalogue items by attributes. Guided selling can also interpret application requirements, apply engineering constraints, calculate values and route exceptions.

    4. Can guided selling generate a BOM?

    It can provide the inputs for a configurable BOM or resolved BOM when the CPQ system and its integrations support that capability. A guided-selling interface alone does not guarantee a manufacturing-ready BOM.

    5. What manufacturing products benefit most from guided selling?

    Products with repeatable but complex decisions are strong candidates, including pumps, valves, HVAC units, conveyors, control panels, industrial vehicles and configurable machinery.

    6. What data is needed to implement guided selling?

    Typical data includes product families, options, attributes, technical limits, dependencies, calculations, prices, lead times, documentation and downstream part or BOM mappings.

    7. Can guided selling support engineer-to-order products?

    Yes, but often as a requirements-capture and triage process. If the product cannot be validated through standard rules, the system should create an engineering review or ETO handoff rather than claim that the configuration is complete.

    8. How do rules differ from constraints?

    A rule describes a dependency or action, such as selecting a seal when a fluid is corrosive. A constraint defines a condition that must or must not be satisfied, such as preventing an incompatible material combination.

    9. Should salespeople see every engineering parameter?

    No. The interface should expose the information needed for the user’s role while retaining technical data in the governed model. Advanced details should be available when needed for review or troubleshooting.

    10. How can guided selling handle incomplete requirements?

    It should identify missing mandatory inputs, explain why they matter and provide a controlled path to request clarification or engineering review. It should not silently assume critical values.

    11. Can guided selling calculate equipment size?

    It can perform approved calculations when the formulas, input ranges, units and assumptions are defined. Complex or safety-critical calculations may still require specialist engineering tools and review.

    12. How does guided selling connect with ERP?

    CPQ may send a configured item, options, prices, customer data or order information to an ERP system. The exact integration depends on system ownership, interfaces and whether the ERP can represent configurable products.

    13. How does guided selling connect with PLM and CAD?

    It may exchange product definitions, revisions, attributes or configuration results with product lifecycle management and computer-aided design systems. CAD automation or PLM integration must be verified for the specific platform.

    14. What is the role of pricing in guided selling?

    Pricing is downstream from technical selection but may also influence recommendations. The implementation should distinguish product validity from price calculation so that a technically valid configuration is not confused with a commercially approved quote.

    15. How should guided-selling rules be maintained?

    Assign rule owners, version the product model, document assumptions, test changes and establish an approval process. Engineering, product management, manufacturing and commercial teams may need different ownership responsibilities.

    16. What is a configurable BOM?

    A configurable BOM is a product structure containing alternatives or rules that resolve according to selected options and derived values. It differs from a fixed BOM because the final components depend on the configuration.

    17. Can customers use guided selling without a salesperson?

    Yes, for suitable products and risk levels. Self-service should use clear validation, controlled product scope and an escalation path for applications that require technical review.

    18. How should a manufacturer measure guided-selling performance?

    Useful measures include completion rate, invalid configurations, manual overrides, engineering escalations, quote cycle time, rework, configuration-related order errors and the proportion of opportunities resolved through standard models.

    Semantic map

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

    • CPQ configures configurable products.
    • Guided selling captures customer requirements.
    • Product models define configurable options.
    • Configuration rules prevent invalid combinations.
    • Constraints validate technical feasibility.
    • Engineering calculations derive product parameters.
    • Configured products generate configurable BOMs.
    • Configured products determine prices and costs.
    • CPQ exchanges configuration data with ERP.
    • CPQ exchanges product data with PLM and PDM.
    • CAD automation generates product-specific drawings.
    • Guided selling routes exceptions to engineering.
    • CTO products use repeatable configuration rules.
    • ETO products require engineering review.
    • MBOMs represent manufacturing assembly structures.

  • Modular Product Architecture for CPQ in Manufacturing

    Modular product architecture for CPQ is the practice of designing a complex manufactured product as a structured set of reusable modules, interfaces, options, rules and variants that a Configure, Price, Quote (CPQ) system can understand. Instead of modelling every finished product as a separate item, the manufacturer models the product as a system of related modules and controlled choices.

    In manufacturing, this architecture connects commercial configuration with engineering and production data. A customer may choose a pump capacity, motor type, seal material, control panel, mounting arrangement and documentation package. The CPQ product model must determine which combinations are valid, calculate dimensions or performance values where necessary, select components, calculate cost and price, and potentially generate a configurable bill of materials (BOM), drawings or CAD outputs.

    The central principle is simple: separate reusable product modules from the rules that govern how those modules can be combined. This makes the model easier to maintain than a large list of independent product variants, while still allowing the CPQ system to support configure-to-order (CTO), make-to-order (MTO) and engineer-to-order (ETO) processes.

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

    What is modular product architecture?

    Modular product architecture is a product design and information-modeling approach in which a product is divided into modules with defined responsibilities, interfaces and compatibility rules. Each module performs a function or represents a physical section of the product, such as a drive system, frame, enclosure, hydraulic circuit, electrical control system or safety package.

    A module may contain:

    • Selectable options and variants;
    • Technical attributes such as dimensions, flow, voltage, pressure or load capacity;
    • Compatibility requirements and exclusions;
    • Component and subassembly references;
    • Cost and price information;
    • Manufacturing or sourcing attributes;
    • CAD parameters, drawings or visualization data;
    • Rules for generating engineering or production outputs.

    In CPQ, the module is not merely a user-interface section. It is part of a product model that can drive validation, calculations, pricing, BOM generation and downstream system integration.

    Why modular architecture matters in manufacturing CPQ

    Generic sales CPQ can often quote relatively simple products using product options, discounts and approval thresholds. Manufacturing CPQ usually has a deeper responsibility. The selected configuration may need to become an engineering definition, a configurable BOM, a CAD model, a routing input or an order-ready package.

    Without modular architecture, manufacturers commonly create one of two difficult models:

    • A flat option list: users can select many attributes, but the system does not reliably understand technical relationships between them.
    • A variant explosion: every combination is maintained as a separate SKU, assembly or rule path, producing duplicated data and difficult change management.

    A modular product model reduces duplication by allowing the manufacturer to maintain a reusable definition for each functional area. A change to a motor family, enclosure standard or control option can be managed in one module rather than repeated across hundreds of product variants.

    Modularity also creates a clearer boundary between responsibilities. Product engineering can own technical compatibility rules, manufacturing can own production structures and sales operations can maintain commercial pricing or quote presentation without editing engineering logic directly.

    Core elements of a modular CPQ product model

    Modules and submodules

    A module represents a coherent product function or physical assembly. For an industrial pump package, modules might include the pump, motor, baseplate, coupling, seal system, instrumentation, control panel and documentation package. Each module can contain submodules. The control panel may contain an enclosure, variable frequency drive, disconnect, PLC, operator interface and wiring accessories.

    Good modules have a clear purpose and relatively stable interfaces. A motor module might expose output power, frame size, voltage and mounting requirements. The pump module might require a minimum motor rating and define shaft, coupling and baseplate constraints.

    Options and features

    An option is a selectable alternative within a module, while a feature is a characteristic or requirement that may be selected, calculated or inherited. For example, a valve module may offer stainless steel, carbon steel or alloy construction. A feature such as pressure class may be selected by the customer, calculated from operating conditions or inherited from a connected module.

    Manufacturers should distinguish commercial choices from engineering attributes. “Premium control package” may be a commercial option, while voltage, enclosure rating and short-circuit current rating are technical attributes that affect component selection and validation.

    Interfaces and compatibility contracts

    A module interface defines how one module connects to another. Interfaces can be physical, electrical, hydraulic, mechanical, software-related or commercial.

    Examples include:

    • A motor shaft diameter must match the coupling bore.
    • A pump flange standard must match the connected piping arrangement.
    • A control panel voltage must match the motor and site supply.
    • A battery module must fit the available vehicle compartment.
    • A lifting attachment must support the configured machine mass.
    • A heat exchanger capacity must meet the calculated thermal duty.

    Making interfaces explicit is important because many configuration errors occur at the boundaries between modules rather than inside an individual module.

    Rules and constraints

    Rules determine how the product model behaves. A rule may assign a component, restrict an option, calculate a value, require an additional module or produce a warning.

    A rules-based configuration model applies explicit conditions such as “if voltage is 480 V, use control panel variant B.” A constraint-based configuration model represents relationships such as capacity, dimensions, ratings and limits, then evaluates whether a proposed combination satisfies those constraints. Guided selling uses questions and recommendations to help a user reach a suitable configuration, but it does not automatically replace the underlying engineering rules.

    Most manufacturing CPQ implementations use a combination of these approaches. Guided questions can collect customer requirements, while rules and constraints validate the technical result.

    Example: modular architecture for a pump skid

    Consider a manufacturer selling packaged centrifugal pump skids. The product has a common structural concept but varies significantly by application.

    Module Typical choices or attributes Important relationships
    Pump Flow, head, impeller diameter, casing material Must meet duty point and material requirements
    Motor Power, voltage, efficiency class, hazardous-area rating Must exceed calculated shaft power and match supply
    Seal system Single seal, double seal, cartridge seal, flush plan Depends on fluid, temperature and pressure
    Baseplate Standard or heavy-duty, coating, drainage features Must accommodate pump and motor footprint
    Controls Starter, variable frequency drive, PLC, instrumentation Depends on motor, voltage and control requirements
    Documentation Standard, certified, inspection and compliance packages May require additional engineering and testing tasks

    The configuration process could begin with customer requirements such as flow rate, pressure, fluid, temperature, voltage and hazardous-area classification. The CPQ system may then select a suitable pump family, calculate a required motor range, restrict materials, require a seal plan and determine the control architecture.

    The resulting product is not just a collection of selected options. It is a structured configuration with technical values, selected components, derived values, commercial terms and downstream outputs.

    How modular product architecture supports the CPQ workflow

    1. Requirement capture

    The system collects customer and application requirements. These may include dimensions, operating conditions, load, throughput, pressure, temperature, voltage, environmental conditions and regulatory requirements.

    Requirements should be stored separately from the final product selection where possible. For example, “required flow is 180 cubic metres per hour” is different from “pump model X is selected.” This separation helps the system explain why a selection was made and allows engineering logic to change without losing the original customer requirement.

    2. Configuration and validation

    The CPQ engine evaluates selected modules, options and calculated values. It may prevent invalid combinations, recommend a suitable module or allow a provisional configuration that requires engineering review.

    Rules should identify the reason for a restriction. “Option unavailable” is less useful than “The selected enclosure rating is incompatible with the chosen control panel because the panel requires a different mounting arrangement.” Explainable validation is particularly important for sales engineers and dealers.

    3. Engineering calculations and selection

    Some products require calculations rather than simple option selection. A fan may require airflow and static-pressure calculations. A conveyor may require load, speed and motor-torque calculations. A heat exchanger may require thermal-duty calculations. A vehicle may require axle-load, payload and dimensional checks.

    Calculation outputs can drive module selection. For example, a calculated shaft power can determine the minimum motor size, while a calculated total weight can determine the frame, lifting points and transport configuration. Calculation logic may reside in the CPQ platform, an engineering service, a rules engine or a connected application. The architecture should make this boundary explicit.

    4. Pricing and costing

    Pricing is related to configuration but is not the same as configuration. The product model determines what can be built; the pricing model determines what it costs commercially.

    A module may carry a standard price, cost, surcharge, discount eligibility or pricing formula. Configuration choices can also create indirect costs. A special material may require additional fabrication, a certified inspection package may add testing effort, and an ETO requirement may create engineering hours.

    Manufacturers should define whether prices are based on list price, standard cost, estimated cost, supplier cost, labour assumptions or a combination. The CPQ system should also distinguish a customer-facing quote from an internal cost estimate.

    5. BOM and engineering outputs

    A valid configured product can generate one or more BOM structures. An engineering bill of materials (EBOM) represents the product from an engineering design perspective. A manufacturing bill of materials (MBOM) represents how the product is assembled and produced. A configurable BOM may contain rules, alternates, quantities, effectivity dates or placeholders that are resolved when the configuration is finalized.

    A pump skid might generate an EBOM containing the pump, motor, coupling and instrumentation, while the MBOM adds fabrication operations, weldments, purchased hardware, assembly kits and packaging items. The CPQ system may generate the complete BOM, generate a structured input for an ERP system, or pass the configuration to a product lifecycle management (PLM) or product data management (PDM) system for further processing. These capabilities vary by platform and must be verified during software evaluation.

    For related topics, see the guide to BOM generation, pricing and quote automation.

    6. CAD and documentation

    Where supported, modular architecture can drive computer-aided design (CAD) automation. A configured frame size, motor, enclosure and mounting arrangement may determine the CAD assembly, dimensions, hole patterns and drawing notes.

    CAD automation may generate a 3D model, 2D drawing, arrangement drawing or manufacturing documentation. However, not every CPQ system includes CAD automation. Some systems only pass configuration parameters to a CAD or engineering application through an integration or API. The manufacturer must define which system owns geometry, revision control and drawing approval.

    The CAD and engineering automation guide explains these relationships in more detail.

    Product model layers in a maintainable CPQ architecture

    A maintainable model usually separates several layers rather than storing all logic in one large rules table.

    Layer Purpose Example
    Requirement layer Captures what the customer or application requires Flow, pressure, voltage and ambient temperature
    Product architecture layer Defines modules, interfaces and product families Pump, motor, baseplate and controls
    Configuration layer Applies options, rules and constraints Hazardous-area rating requires a suitable motor and panel
    Calculation layer Derives engineering values Required motor power or frame load
    Component layer Maps selections to parts, assemblies and substitutes Specific motor item and coupling assembly
    Commercial layer Calculates cost, price, discount and margin Material surcharge and engineering fee
    Output layer Creates documents and downstream data Quote, EBOM, MBOM, CAD request and ERP order

    This separation does not require every layer to be hosted in the same application. It does require clear ownership, data contracts and version control between applications.

    Rules for modular products

    Useful rules normally fall into several categories:

    • Eligibility rules: determine whether a module or option is available for a product family.
    • Compatibility rules: prevent incompatible combinations, such as a motor and drive with mismatched voltage.
    • Requirement rules: make an option mandatory when a condition applies.
    • Exclusion rules: prevent a selection because of safety, regulatory, dimensional or manufacturing constraints.
    • Calculation rules: derive dimensions, ratings, quantities or performance values.
    • Selection rules: select a default or recommended component from an approved range.
    • Output rules: control BOM lines, drawing parameters, quote text or manufacturing attributes.
    • Approval rules: route unusual configurations, low margins or technical exceptions for review.

    Rules should be documented in business and engineering language. They should also be testable independently of the sales interface. A rule that only works because of a hidden user-interface dependency is difficult to audit and maintain.

    Modularity and CTO, ETO, MTO and ATO

    Modular product architecture supports several manufacturing strategies, but the degree of automation differs.

    • Configure-to-order (CTO): the product is assembled from predefined modules and validated combinations. This is usually the strongest fit for reusable modular models.
    • Make-to-order (MTO): production begins after an order, often using a standard or configurable product definition.
    • Assemble-to-order (ATO): stocked modules or subassemblies are combined after the order is received.
    • Engineer-to-order (ETO): the order requires new or significantly modified engineering work. The modular model can provide a starting architecture, but it cannot eliminate all design activity.

    A CPQ system should not claim to make an ETO product fully automatic simply because it has configurable options. In ETO, the model may identify the design envelope, produce a preliminary BOM and create an engineering work package, while final geometry, calculations and approvals remain with engineering.

    See the guide to CTO, ETO, MTO and related manufacturing workflows.

    Integration with enterprise systems

    Modular CPQ architecture typically exchanges data with several enterprise systems, each with a different purpose.

    System Typical relationship with CPQ
    Customer relationship management (CRM) Provides account, opportunity and sales context; may receive quote and configuration status
    Enterprise resource planning (ERP) Receives order, item, pricing, BOM, inventory or manufacturing data
    Product lifecycle management (PLM) Manages product structures, revisions, effectivity and engineering change processes
    Product data management (PDM) Controls CAD files, documents and design metadata
    Product information management (PIM) Manages commercial product content, descriptions and channel information
    Manufacturing execution system (MES) May receive production instructions, configuration data or manufacturing attributes
    CAD system May receive parameters and return models, drawings or engineering results

    These systems are not interchangeable. A CPQ product model should define which system is authoritative for each data type. The CPQ integration guide covers integration patterns, APIs and system boundaries.

    Benefits of modular product architecture

    • Lower model duplication: reusable modules reduce the need to maintain every finished-product combination independently.
    • Improved configuration quality: explicit interfaces and constraints prevent technically invalid selections.
    • Faster product changes: a revised component or rule can be updated in a controlled module.
    • Better engineering handoff: requirements, selected options, calculations and exceptions can travel with the quote.
    • More consistent pricing: commercial logic can respond to technical selections and estimated effort.
    • Scalable product families: common modules can be reused across machines, regions or market segments.
    • More useful downstream data: the configuration can produce structured BOM, CAD and ERP inputs rather than only a PDF quote.

    Limitations and risks

    Modularity is not automatically simple. A poorly designed modular model can become a collection of tightly coupled exceptions. If every module depends on many hidden conditions in other modules, the model may be difficult to understand and test.

    Common risks include:

    • Defining modules around organizational departments instead of product functions;
    • Using commercial option names that hide technical differences;
    • Duplicating engineering rules in CPQ, CAD, ERP and spreadsheets;
    • Failing to model dimensions, loads, ratings or interfaces explicitly;
    • Ignoring revisions and effectivity dates;
    • Allowing sales users to bypass constraints without an approval process;
    • Assuming an EBOM can be used directly as an MBOM;
    • Treating a configurable product as CTO when it actually requires ETO work;
    • Creating rules that are not covered by automated test cases;
    • Sending incomplete or ambiguous configuration data to ERP or engineering systems.

    The architecture must also address product variants that do not fit the standard modules. An exception process is necessary, but excessive exceptions indicate that the product model or modular boundaries need review.

    Implementation approach

    1. Select a representative product family

    Start with a product family that has meaningful configuration complexity, measurable business value and sufficiently stable engineering knowledge. Avoid choosing the largest and most irregular product family as the first model.

    2. Map the current product structure

    Document modules, options, interfaces, calculations, component substitutions, pricing inputs, BOM structures, CAD dependencies and approval steps. Include spreadsheets and manual engineering activities because they often contain undocumented rules.

    3. Define ownership and authority

    Assign ownership for product architecture, technical rules, component data, pricing, CAD parameters, BOM structures and commercial content. Establish which system owns each master record and how changes are approved.

    4. Establish a rule taxonomy

    Classify rules as eligibility, compatibility, requirement, exclusion, calculation, selection, output or approval rules. This makes the model easier to review and prevents every condition from becoming an unstructured custom script.

    5. Model interfaces before every option

    Identify the physical, electrical, hydraulic and commercial interfaces between modules. This often reveals the constraints that matter most to engineering and production.

    6. Test combinations and boundaries

    Test normal configurations, minimum and maximum values, incompatible options, missing data, regional variants, obsolete components, revision changes and exception paths. Testing should include both valid and invalid configurations.

    7. Connect outputs incrementally

    Begin with a reliable quote and configuration record, then add pricing, BOM, ERP, PLM, CAD or MES outputs according to business priority. A technically impressive model that produces unreliable downstream data is not a successful implementation.

    The CPQ implementation guide provides additional guidance on migration, testing, governance, deployment and maintenance.

    How to evaluate software for modular CPQ architecture

    When evaluating a CPQ platform, manufacturers should ask more than whether it supports “product options.” Useful evaluation questions include:

    • Can the platform represent hierarchical modules and reusable subassemblies?
    • Can it model numeric constraints, ranges, dependencies and calculated values?
    • Can technical rules be separated from pricing and presentation logic?
    • Can it explain validation failures to sales and engineering users?
    • Can it maintain effective dates, revisions and approved component alternatives?
    • Can it generate or exchange configurable BOM data?
    • Can it integrate with ERP, PLM, PDM, CAD and CRM through supported interfaces?
    • Can engineering calculations run within the platform or through an external service?
    • Can the model support dealer, distributor and internal engineering workflows?
    • Can administrators test and deploy model changes without uncontrolled production edits?
    • How are ETO exceptions represented and handed to engineering?
    • How does the platform perform with large product models and many dependent rules?

    Capabilities vary considerably. A vendor may provide strong commercial quoting but limited engineering automation, or may support product configuration without generating production-ready BOMs. Buyers should validate the complete workflow using their own product data rather than relying on feature labels.

    Governance and long-term maintenance

    Product models change as components become obsolete, suppliers change, standards are revised, prices move and product families evolve. Governance should define who can change rules, how changes are tested, when models are released and how historical quotes remain reproducible.

    Useful governance practices include:

    • Version-controlled product models and rule sets;
    • Named owners for each module;
    • Change impact analysis for shared modules;
    • Automated regression tests for important configurations;
    • Approval workflows for technical and commercial changes;
    • Effective dates for components, prices and rules;
    • Monitoring of invalid configurations, manual overrides and engineering rework;
    • Documentation of interfaces, assumptions and calculation sources.

    The strongest architecture is not the one with the most rules. It is the one that represents product knowledge clearly, produces reliable outputs and can be changed without creating hidden consequences across the product family.

    Semantic map

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

    • CPQ represents modular product architecture.
    • Modular product architecture organizes configurable products into reusable modules.
    • Modules expose interfaces and technical attributes.
    • Configuration rules govern module compatibility.
    • Constraints prevent invalid product combinations.
    • Engineering calculations derive technical values.
    • Technical values influence component selection.
    • Configured products generate configurable BOM structures.
    • EBOM represents an engineering product structure.
    • MBOM represents a manufacturing assembly structure.
    • CAD automation uses configuration parameters to generate design outputs.
    • Pricing logic converts configuration selections and cost inputs into commercial prices.
    • CPQ exchanges configuration and quote data with ERP, CRM, PLM, PDM, CAD and other systems.
    • CTO uses predefined modular combinations.
    • ETO uses modular architecture as a starting point for additional engineering work.

    Frequently asked questions

    What is modular product architecture in CPQ?

    It is a way to model a configurable manufactured product as reusable modules, options, interfaces and rules that a CPQ system can validate and use to produce pricing, quotes and downstream product data.

    How is modular CPQ different from a simple option list?

    A simple option list presents choices. Modular CPQ also represents technical relationships, constraints, calculations, component mappings, BOM structures and output requirements.

    What is an example of a CPQ module?

    A motor, pump, enclosure, hydraulic circuit, control panel or vehicle axle assembly can each be represented as a module when it has a defined function and interface.

    Can modular product architecture prevent configuration errors?

    It can prevent errors that have been explicitly represented as rules or constraints, such as incompatible voltage, dimensions, materials, pressure ratings or mounting arrangements.

    Does modular architecture eliminate engineering involvement?

    No. It can automate repeatable decisions and identify standard configurations, but unusual designs, new products and many ETO requirements still need engineering review.

    What is the difference between configuration rules and constraints?

    Rules express explicit actions or conditions, while constraints define relationships and limits that a proposed configuration must satisfy. Manufacturing CPQ often uses both.

    How does modular CPQ support configure-to-order?

    It assembles approved modules and validates their interfaces so the configured product can proceed with limited additional design work.

    Can the same modular model support ETO?

    Often it can provide a controlled starting point, preliminary product structure and engineering requirements, but it should not be assumed to complete all ETO design activities automatically.

    Does modular CPQ generate a BOM?

    Some platforms generate configurable or resolved BOMs, while others send configuration data to ERP, PLM or another system that owns BOM generation. This capability must be verified for each product.

    What is the difference between an EBOM and an MBOM?

    An EBOM describes the product from an engineering perspective. An MBOM describes how the product is assembled or manufactured. They may contain different structures, quantities and process-related items.

    How does CAD relate to modular product architecture?

    Module selections and calculated dimensions can provide parameters for CAD automation, but the CPQ system may only exchange data with CAD rather than generate models itself.

    Who should own CPQ product rules?

    Ownership should be assigned by rule type. Engineering typically owns technical constraints, product management may own product architecture, and commercial teams may own pricing and quote presentation.

    What causes modular CPQ models to become difficult to maintain?

    Common causes include duplicated rules, hidden dependencies, unclear module boundaries, uncontrolled exceptions, missing version control and treating every commercial option as a technical rule.

    How should a manufacturer start a modular CPQ project?

    Choose a representative product family, document its modules and interfaces, classify its rules, identify authoritative systems and test a controlled configuration-to-output workflow.

    Can modules be reused across different product families?

    Yes, if the module has stable interfaces, well-defined attributes and reusable rules. A common motor, control panel or safety package may serve several related machine families.

    How does modular architecture affect pricing?

    It allows prices, surcharges, costs and engineering fees to be associated with selected modules and derived requirements, while keeping commercial calculations distinct from technical validation.

    What integrations are important for modular manufacturing CPQ?

    Important integrations may include ERP for orders and manufacturing data, CRM for opportunity context, PLM or PDM for product and CAD data, and CAD for design automation. The required set depends on the workflow.

    How should modular CPQ models be tested?

    Test valid configurations, invalid combinations, boundary values, revisions, obsolete components, regional variants, manual overrides, calculation failures and downstream BOM or ERP outputs.

    What is the main benefit of modular product architecture?

    The main benefit is a more maintainable connection between product knowledge and business processes. Reusable modules and explicit rules can support accurate configuration without maintaining every possible finished-product variant separately.

  • What Is a Manufacturing Product Configurator?

    A manufacturing product configurator is software that converts customer requirements and selected options into a valid definition of a configurable industrial product. It uses a structured product model, configuration rules, engineering constraints and calculations to determine which combinations are allowed and what components are required.

    Depending on its scope, the configurator may also calculate price and cost, create a quote, generate a bill of material (BOM), select engineering components, produce CAD outputs or exchange data with enterprise systems. These capabilities are not present in every product configurator, so buyers should distinguish core configuration from related configure, price, quote (CPQ), engineering automation and manufacturing functions.

    For example, a pump configurator might accept flow rate, head pressure, fluid type, temperature, motor voltage, materials and connection standards. It can prevent an unsuitable impeller from being paired with a motor, select compatible seals and materials, calculate a duty point and produce a valid configuration for pricing, engineering review or production.

    This makes a manufacturing configurator different from a simple online product selector. It represents how an engineered product is built, what constraints apply, which components are needed and what downstream information must be created.

    What a manufacturing product configurator does

    The central purpose of a configurator is to resolve product variability in a controlled way. Instead of allowing salespeople or customers to choose every possible option independently, the system models relationships between features, dimensions, components, calculations and processes.

    A typical configuration process contains these steps:

    1. Collect requirements: The user enters product parameters such as capacity, dimensions, environment, voltage, material or performance requirements.
    2. Present valid choices: The system displays relevant options and hides or disables choices that do not apply.
    3. Apply rules and constraints: Dependencies, exclusions, ranges and engineering conditions are evaluated as selections change.
    4. Calculate the result: The system may calculate dimensions, performance, quantities, costs, prices or lead-time factors.
    5. Resolve product data: Components, assemblies, operations, documents and attributes are selected for the configured product.
    6. Pass the result downstream: The configuration may be sent to a quote, customer relationship management (CRM) system, enterprise resource planning (ERP) system, product lifecycle management (PLM) system, computer-aided design (CAD) tool or manufacturing process.

    The output can be as simple as a validated option set or as detailed as a manufacturing-ready product definition. The appropriate output depends on the product, the company’s operating model and the capabilities of the selected software.

    Manufacturing product configurator versus generic CPQ

    CPQ means configure, price, quote. Generic sales CPQ software often focuses on selecting products, applying discounts and producing commercial proposals. A manufacturing product configurator can include those functions, but it must also represent physical products and engineering relationships.

    Area Generic sales CPQ Manufacturing product configurator
    Primary output A commercial quote or orderable product selection A valid product definition that may support quoting, engineering and production
    Product structure Products, bundles, options and commercial attributes Features, components, assemblies, dimensions, materials, variants and manufacturing relationships
    Rules Option dependencies, eligibility, discounts and approvals Engineering constraints, compatibility rules, dimensional limits, performance calculations and manufacturing conditions
    Downstream data Quote, order and customer information Potentially BOMs, CAD parameters, drawings, routings, specifications, costs and ERP or PLM records
    Typical users Sales, account management and commercial operations Sales engineering, application engineering, product management, design engineering, manufacturing and operations

    These categories overlap. A manufacturing CPQ platform may include a product configurator, pricing engine, quote generator and workflow tools. Conversely, a product configurator may validate selections without calculating prices or generating quotes. Buyers should evaluate the actual product model and outputs rather than treating all CPQ products as equivalent.

    See the guide to CPQ software for manufacturing for a broader explanation of how configuration, pricing, quoting and engineering fit together.

    The product model behind a configurator

    The product model is the structured representation of how a configurable product is organized. It defines the product’s features, options, components, attributes, values, relationships and outputs. A weak product model may produce a system that is difficult to maintain even if its user interface looks simple.

    Product features and options

    A feature is a decision area or characteristic, such as drive type, mounting arrangement, enclosure rating or frame size. An option is a selectable value within that feature, such as electric motor, wall mount, IP65 enclosure or 7.5 kW motor.

    Some features are discrete. Others are numeric or conditional. A tank configurator may allow a diameter between defined minimum and maximum values, while a conveyor configurator may use length, belt width and incline angle as input parameters.

    Components and assemblies

    The model can associate selections with physical components and subassemblies. Selecting stainless steel wetted parts in a pump configuration may replace several components, change fasteners and require a different seal arrangement. Selecting a larger motor may also change the baseplate, coupling, guard and electrical documentation.

    Attributes and technical data

    Attributes describe products and components. Examples include voltage, pressure rating, temperature range, material grade, weight, dimensions, efficiency class and certification. These values can be used for filtering, rules, calculations, documentation and integration.

    Versions and applicability

    Manufacturing products change over time. A configurator may need effective dates, revision control, regional applicability, market-specific options and product lifecycle states. A rule that is correct for a new motor family may be wrong for an older product revision. The model therefore needs governance, ownership and release processes.

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

    Rules, constraints and configuration logic

    Rules determine how the configurator responds to selections. They can prevent invalid combinations, automatically select related values, calculate results or route unusual configurations to engineering.

    Rules-based configuration

    Rules-based configuration uses explicit logic such as:

    • If the pump handles abrasive slurry, require a specified wear-resistant material.
    • If the motor voltage is 480 V, use the compatible starter and electrical enclosure.
    • If the platform length exceeds a threshold, require an additional support assembly.
    • If a vehicle has a refrigerated body, require the corresponding power and insulation package.

    Rules can be expressed as required options, exclusions, defaults, substitutions, conditional visibility, value ranges or formulas.

    Constraint-based configuration

    Constraint-based configuration focuses on relationships and permitted states. Instead of only listing predefined bundles, it evaluates conditions such as capacity, geometry, load, material compatibility or operating environment.

    For example, a pressure vessel configurator may need to consider design pressure, temperature, diameter, wall thickness, material and code requirements together. A selection is valid only when the combined result satisfies the applicable constraints.

    Guided selling

    Guided selling asks users questions and recommends suitable products or options. It is useful when customers know their application but not the technical product terminology. Guided selling can sit on top of a rules engine, but it is not the same as engineering validation. A recommendation may identify a suitable product family, while a deeper configurator validates the exact dimensions, components and manufacturing result.

    Hard stops and warnings

    Not every issue must block configuration. A hard stop prevents completion, such as an impossible voltage and motor combination. A warning may allow the user to continue but require engineering review, such as a non-standard operating point or a request outside the normal product envelope.

    Industrial examples

    Pump configuration

    A pump configurator can capture flow, head, liquid properties, temperature, solids content, materials, seal type, motor, voltage and connection standard. Rules may constrain impeller diameter, casing material, seal selection and motor size. Engineering calculations may determine whether the selected pump meets the duty point.

    The result might include a product code, selected components, performance data, price, lead-time classification and a configurable BOM. If the company uses CAD automation, the configuration may also drive a pump baseplate or piping arrangement drawing.

    Industrial HVAC equipment

    An air-handling-unit configurator may use airflow, external static pressure, casing dimensions, insulation, filters, coils, fans, controls and environmental conditions. Changing airflow can affect fan selection, coil size, casing dimensions and electrical requirements.

    A valid configuration may produce a technical schedule for the quote, a BOM for engineering, a manufacturing configuration for ERP and a drawing package. The same product model must be carefully governed because changes to one option can affect many downstream outputs.

    Material handling equipment

    A conveyor configurator may accept conveyor length, width, elevation, belt type, load, speed, drive arrangement and guarding requirements. Rules can determine support spacing, drive size, pulley selection and safety components. A non-standard length may require a warning or an engineer-to-order workflow rather than automatic release.

    Electrical equipment

    A switchgear or control-panel configurator may manage enclosure size, busbar ratings, incoming supply, breaker types, protection devices, control voltage and communication modules. It must account for compatibility, space, thermal limits and applicable documentation. Configuration alone does not replace electrical design verification, but it can standardize repeatable product families and reduce manual selection errors.

    How the configurator fits into the manufacturing technology stack

    A product configurator is usually part of a broader information flow. It may operate inside CPQ, as a dedicated configuration service, within an engineering application or as a module connected to enterprise systems.

    System Typical responsibility Possible relationship with the configurator
    CRM Customer, opportunity and sales activity management Provides account and opportunity context and receives quote status or configured deal information
    CPQ Configuration, pricing and quoting Hosts or invokes the product model and creates commercial outputs
    ERP Items, inventory, purchasing, orders, production and finance Receives orderable products, BOMs, prices, configurations or manufacturing instructions
    PLM Product lifecycle, revisions, approvals and engineering product data Provides released product structures, revisions and engineering metadata
    PDM Product data and document management Stores CAD files, drawings and related technical documents
    CAD Computer-aided design and geometry Receives parameters and may return models, drawings or engineering outputs
    PIM Product information for distribution and digital channels Supplies descriptions, attributes, images and channel content
    MES Manufacturing execution and shop-floor operations May receive production-relevant configuration, instructions or genealogy data

    These systems are not interchangeable. PLM is not simply a larger product configurator, ERP is not a rules engine, and CAD geometry is not the same as a manufacturing BOM. The integration architecture should define which system owns each type of data and how revisions are synchronized.

    The CPQ integration guide covers these system relationships in more detail.

    From configuration to BOM, CAD and quote

    Configuration and the BOM

    A bill of material (BOM) lists the components, subassemblies and quantities required for a product. A configurator may resolve a configurable BOM by adding, removing or substituting components based on the selected options.

    An engineering BOM (EBOM) represents the product from an engineering perspective. A manufacturing BOM (MBOM) represents how the product is assembled or produced. These structures may differ. A configurable product model may need to produce or help reconcile both, rather than assuming that one list serves every department.

    BOM generation requires reliable item identifiers, revision data, quantities, effectivity, units of measure and clear ownership. A configuration engine that only returns text descriptions is not necessarily generating a manufacturing-ready BOM.

    Configuration and CAD automation

    CAD automation can use configuration values to select models, set dimensions, suppress features, create assemblies or generate drawings. For a pump skid, the configured pump, motor, base, piping and connection arrangement may drive a layout drawing.

    CAD automation has additional dependencies: parametric models must be stable, naming conventions must be controlled, geometric conditions must be tested and the resulting files must be managed with appropriate revisions. A configurator can provide parameters without being a CAD automation system.

    Configuration and pricing

    Price is related to configuration but is not the same thing. A price engine may use component prices, quantity breaks, labor, material costs, freight, currency, customer agreements, margins and approval thresholds. Engineering calculations may affect price when dimensions, ratings or materials change.

    Costing and pricing logic should be traceable. Users should be able to understand whether a price came from a component, formula, surcharge, discount, project cost or manual adjustment.

    Configuration and quoting

    A quote can include commercial terms, delivery assumptions, technical descriptions, exclusions, approvals and attachments. A configuration supplies technical content, but quote generation requires separate document and workflow logic. The two functions often work together in CPQ, but they should not be treated as identical.

    See BOM, pricing and quoting in manufacturing CPQ for the relationship between these outputs.

    Manufacturing workflows supported by configurators

    Configure-to-order

    In configure-to-order (CTO), the company sells a product assembled from predefined and validated options. The configurator can select the correct components and pass the result to order processing or production. CTO works best when product boundaries, options and manufacturing data are well defined.

    Make-to-order and assemble-to-order

    Make-to-order (MTO) products are produced after an order is received, often using a defined product structure. Assemble-to-order (ATO) products are assembled from stocked or prepared modules. A configurator can resolve the required modules and options, but inventory and production planning remain ERP or manufacturing responsibilities.

    Engineer-to-order

    In engineer-to-order (ETO), the final product requires new or substantially changed engineering work. A configurator may capture requirements, validate the standard envelope, calculate preliminary values and identify a standard starting point. It should then route non-standard requirements to engineering rather than pretending that every result can be generated automatically.

    A practical design often uses a threshold: standard configurations proceed automatically, while out-of-range dimensions, unapproved materials or unusual duty conditions create an engineering task.

    Read more about these patterns in the manufacturing CPQ workflow guide.

    Benefits of a manufacturing product configurator

    • Fewer invalid combinations: Rules prevent incompatible motors, materials, ratings, dimensions or accessories from being selected together.
    • Faster technical sales: Sales teams can resolve repeatable applications without waiting for an engineer to rebuild the same logic manually.
    • More consistent quotes: Standardized configuration and pricing inputs reduce variation between sales channels.
    • Lower engineering workload: Routine selections, calculations, component resolution and document generation can be automated where the product model supports it.
    • Better handoff to operations: A validated configuration can carry technical information into ERP, PLM, CAD or production workflows.
    • Preserved product knowledge: Rules and calculations make some engineering knowledge explicit and reusable rather than keeping it only in spreadsheets or individual expertise.
    • Improved change control: Versioned models can help organizations manage product revisions and effective dates.

    Limitations and risks

    A configurator does not automatically make a product configurable. The product must have sufficiently understood options, constraints and outputs. Common limitations include the following:

    • Incomplete product knowledge: If rules exist only in informal practices or spreadsheets, modeling them requires discovery and validation.
    • Rule conflicts: Overlapping or contradictory rules can create unexpected outcomes and difficult troubleshooting.
    • High maintenance effort: New components, suppliers, regulations, prices and engineering revisions can require frequent model updates.
    • Unclear ownership: Product management, engineering, sales and IT may disagree about who can change rules and approve releases.
    • ETO complexity: Highly novel products may not fit a fixed option model and still require engineering judgment.
    • Integration mismatch: Different item numbers, revisions, units, structures and lifecycle states can make ERP, PLM and configurator synchronization difficult.
    • False confidence: A valid software configuration is not necessarily a complete safety, regulatory or engineering approval.
    • Technical debt: Hard-coded exceptions and duplicated logic can make the model fragile over time.

    These risks are reasons to establish model governance and testing, not reasons to assume that configuration software is unsuitable.

    How to design a maintainable product model

    Start with product families and boundaries

    Define which products are genuinely configurable and where a new model, product family or engineering process is required. Avoid placing unrelated products into one large rule set simply because they share a sales screen.

    Separate concerns

    Keep product selection, engineering constraints, pricing, document text and integration mappings distinct where the platform allows it. A motor compatibility rule should not be hidden inside a quote paragraph, and a discount rule should not determine whether an impeller is technically valid.

    Use reusable rules

    Common constraints should be represented once and reused where possible. For example, an enclosure-rating rule may apply across several electrical product families. Reusable logic reduces duplication but must still account for product-specific exceptions.

    Make rules explainable

    Users need useful messages such as the selected motor is below the calculated power requirement, not only a generic invalid configuration error. Explainability helps sales users, engineers and administrators correct problems.

    Control ownership and releases

    Assign owners for product data, rules, calculations, pricing and integrations. Use approval and release states so that changes are reviewed before they affect live quotes or orders.

    Test realistic combinations

    Testing should include normal configurations, boundary values, invalid combinations, obsolete components, regional variations, revisions, missing data and integration failures. Automated regression tests are particularly valuable when a product family contains many interacting options.

    The CPQ implementation guide discusses requirements, migration, testing, governance and maintenance.

    How to evaluate configurator software

    Manufacturers should evaluate a product configurator against the complexity of their products and the outputs they require. Useful questions include:

    • Can the system model numeric parameters, ranges, dependencies, exclusions and calculations?
    • Can rules distinguish warnings from hard stops and route exceptions to engineering?
    • Can product models be versioned, tested, approved and maintained by appropriate users?
    • Can the system represent configurable components, subassemblies and quantities?
    • Does it generate a true BOM, or only a product code and description?
    • Can it support EBOM, MBOM or configurable BOM requirements?
    • Does it integrate with the company’s ERP, PLM, PDM, CAD, CRM or MES systems?
    • Can it support standard CTO products as well as controlled ETO exceptions?
    • Are calculations, assumptions, units and engineering formulas traceable?
    • Can dealers, distributors, internal sales teams and customers use different views or permissions?
    • Are APIs available for ecommerce, portals or headless configuration experiences?
    • How are revisions, effective dates, regional rules and discontinued items handled?
    • What tools exist for debugging rules, comparing model versions and analyzing configuration errors?

    Feature checklists are not enough. Ask vendors to demonstrate a representative product family using real constraints, real component structures and realistic downstream outputs. Vendor claims should be separated from capabilities that have been verified in the proposed deployment.

    Implementation approach

    1. Document the current process: Map how requirements are gathered, how engineers validate them, how prices are calculated and how data reaches production.
    2. Select a representative product: Choose a product family with meaningful configuration complexity but defined boundaries. Avoid starting with the easiest brochure product or the most chaotic ETO project.
    3. Build the product model: Define features, options, parameters, components, calculations, constraints and outputs.
    4. Clean source data: Reconcile item numbers, descriptions, units, revisions, costs, prices, drawings and lifecycle states.
    5. Define system ownership: Decide whether ERP, PLM, CAD, CPQ or another system owns each data object and how updates are exchanged.
    6. Test with users: Use sales engineers, product managers, design engineers, manufacturing and operations staff to test realistic scenarios.
    7. Release incrementally: Start with a controlled product scope, measure results and expand after the model and governance process are stable.
    8. Maintain continuously: Treat the product model as operational software. Review rule changes, regression tests, release notes and user feedback.

    Semantic map

    The following relationships summarize the entities discussed in this guide:

    • Manufacturing product configurator → applies → product rules and engineering constraints
    • Product model → represents → configurable product structure
    • Configuration rules → prevent → invalid component combinations
    • Constraint-based configuration → validates → combined product requirements
    • Guided selling → collects → application requirements
    • Configured product → resolves → components and subassemblies
    • Configured product → can generate → configurable BOM
    • Engineering BOM → represents → product design structure
    • Manufacturing BOM → represents → production assembly structure
    • CAD automation → generates → product-specific models and drawings
    • Pricing engine → calculates → configured product price
    • CPQ → produces → technical and commercial quote
    • Configurator → exchanges data with → ERP
    • Configurator → can use → PLM product revisions
    • ETO workflow → routes → non-standard requirements to engineering
    • Product model governance → controls → rule releases and revisions

    Frequently asked questions

    What is a manufacturing product configurator?

    It is software that converts product requirements and selected options into a valid definition of an engineered product. It may also produce prices, quotes, BOMs, drawings or system data, depending on its capabilities.

    Is a product configurator the same as CPQ?

    No. CPQ means configure, price, quote. A configurator handles product selection and validation, while CPQ usually adds pricing, quoting and commercial workflows. Some CPQ platforms include manufacturing-grade configuration, but not all do.

    What is the difference between a product configurator and a product selector?

    A selector usually filters products or recommends a suitable model. A configurator resolves a specific combination of options, parameters, constraints and components and may create downstream engineering or manufacturing data.

    Can a configurator generate a BOM?

    Some can, but this is not universal. Buyers should verify whether the system creates a structured configurable BOM with item identifiers, quantities, revisions and effectivity, or only returns a configuration code and description.

    Does a configurator replace engineering?

    Usually not. It can automate repeatable engineering decisions and identify invalid selections, but safety reviews, regulatory approval, novel designs and non-standard requirements may still require qualified engineers.

    What types of manufacturing products benefit most from configuration?

    Products with repeatable option combinations and meaningful technical constraints are strong candidates. Examples include pumps, valves, industrial machinery, HVAC units, electrical equipment, conveyors, vehicles and material handling systems.

    What are configuration rules?

    Configuration rules define allowed, required, excluded or calculated relationships between product options and parameters. They can specify compatibility, ranges, defaults, substitutions, warnings and engineering review conditions.

    What is constraint-based configuration?

    Constraint-based configuration evaluates whether a combination of values satisfies technical relationships and limits. It is useful for products where dimensions, capacities, materials, loads or performance requirements interact.

    What is guided selling in a configurator?

    Guided selling asks application questions and recommends products or options in terms users understand. It can improve product selection, but it does not by itself prove that a detailed engineering configuration is valid.

    Can configurators support engineer-to-order products?

    They can support the front end of an ETO process by capturing requirements, validating standard limits and identifying exceptions. Fully novel designs generally still require engineering work outside the standard configuration model.

    How does a configurator connect to ERP?

    It may send product codes, configuration attributes, BOMs, prices, order details or production-relevant data to an ERP system. The exact integration depends on system ownership, data structures, APIs and the configurator’s documented capabilities.

    What is the difference between an EBOM and an MBOM?

    An EBOM, or engineering bill of material, represents the product from a design perspective. An MBOM, or manufacturing bill of material, represents how the product is assembled or produced. They can contain different structures and information.

    Can a configurator automate CAD?

    Some platforms integrate with CAD automation tools or can drive parametric models. This is a separate capability from basic configuration and requires stable CAD templates, parameter mappings, revision control and testing.

    How are product configurator rules maintained?

    Rules should have owners, documentation, version control, approval steps, release states and regression tests. Maintenance includes updating components, prices, calculations, product revisions, regulations and integration mappings.

    What happens when a user selects an invalid option?

    The system may prevent the selection, remove an incompatible option, display a warning, suggest an alternative or route the configuration to engineering. The correct response depends on the severity and business process.

    Can customers use a manufacturing configurator directly?

    Yes, some organizations expose a simplified configurator through ecommerce, dealer portals or customer self-service. Complex or safety-critical products often restrict advanced choices to trained sales or engineering users.

    What data is needed to implement a configurator?

    Typical inputs include product structures, options, parameters, component identifiers, compatibility rules, calculations, prices, revisions, documents, workflows and integration mappings. Data quality and ownership are as important as software functionality.

    How should a manufacturer choose a configurator?

    Evaluate the system using a representative product and real rules. Test configuration depth, calculations, BOM behavior, CAD or PLM integration, pricing, ETO handling, governance, APIs, implementation effort and downstream outputs rather than relying on generic feature counts.

    What is a configurable BOM?

    A configurable BOM is a product structure that resolves into different component lists or quantities according to selected options and parameters. It may serve engineering, manufacturing or order processing, but its intended use must be defined.

    Is a configurator useful if a company does not generate automatic CAD?

    Yes. A configurator can still validate options, capture requirements, calculate prices, create quotes, resolve components and support ERP or engineering workflows without generating CAD. CAD automation is an optional capability.

  • Technical Validation During Product Configuration

    Technical validation during product configuration is the process of checking whether a proposed product is technically valid, manufacturable and complete before the manufacturer issues a quote or releases an order. In a manufacturing CPQ configurator, validation can check option compatibility, dimensions, materials, load requirements, electrical ratings, capacity calculations, required components and downstream production data.

    This is more than confirming that a customer selected a permitted option. A manufacturing-focused Configure, Price, Quote (CPQ) system may need to determine whether a pump can deliver the requested flow at the specified head, whether a machine frame supports the selected load, whether a motor matches the power requirement, or whether the resulting bill of materials (BOM) contains every component required for production. Some platforms support these functions natively; others require integration with engineering, product lifecycle management or custom calculation services.

    The purpose of technical validation is to identify invalid or incomplete configurations while the product is being configured, rather than after the quote reaches engineering or production. It reduces avoidable rework, but it does not replace engineering review for products that require detailed design, certification or project-specific analysis.

    What technical validation means in manufacturing CPQ

    Technical validation evaluates a configured product against the product model and the engineering knowledge encoded in that model. The model describes available options, parameters, components, dependencies, constraints, calculations and output rules. Validation uses this information to determine whether the selected configuration is acceptable.

    A simple rule might prevent a stainless-steel pump casing from being paired with an incompatible seal material. A more advanced rule might calculate required motor power from flow, pressure, fluid density and efficiency, then restrict the available motor family to units that meet the result. The first is an option compatibility rule; the second is an engineering calculation combined with a selection constraint.

    Technical validation normally covers several dimensions:

    • Configuration validity: selected features and options are compatible.
    • Dimensional validity: lengths, widths, heights, clearances and connection sizes fall within allowable ranges.
    • Functional validity: the product can meet the requested performance, capacity or operating conditions.
    • Material validity: materials, coatings and components are suitable for the application or environment.
    • Manufacturing validity: the configuration can be produced using available processes, equipment and approved components.
    • Documentation validity: the data required for drawings, specifications, BOMs and work instructions is complete.
    • Commercial validity: cost, lead time, pricing and approval conditions can be calculated from a technically valid configuration.

    These checks belong primarily to product configuration and rules management, but their outputs affect pricing, quoting, CAD automation, BOM generation, ERP transactions and engineering workflows.

    Why technical validation matters for a CPQ configurator

    Generic sales CPQ often focuses on selecting a package, applying discounts and generating a proposal. Manufacturing CPQ must usually establish whether the proposed product can actually be built and delivered. The difference is important when products contain engineered dimensions, optional assemblies, performance calculations or customer-specific designs.

    Without technical validation, a sales engineer may create a quote for a machine with an impossible combination of frame size, motor, guarding and conveyor length. The problem may not be discovered until an application engineer reviews the order. At that point, the company may need to revise the price, request new drawings, change the delivery date or return to the customer for clarification.

    Validation moves appropriate checks earlier in the workflow. It can provide an immediate error, warning or recommendation while the configuration is still being edited. For example:

    • An error can prevent a 460-volt motor from being selected for a control system designed only for 230 volts.
    • A warning can indicate that a selected stainless-steel finish may increase lead time.
    • A recommendation can suggest a larger heat exchanger when the calculated thermal load exceeds the standard range.
    • An engineering review status can be assigned when the configuration passes standard rules but requires project-specific analysis.

    Validation therefore improves the quality of the handoff from sales to engineering. It does not mean that every decision should be automated or that every product should be treated as fully configurable.

    The product model behind technical validation

    Technical validation depends on a structured product model. The model should represent the product in terms that can be understood by sales, engineering, manufacturing and the connected enterprise systems.

    Features, options and parameters

    Features describe configurable areas of a product, such as drive system, enclosure, mounting arrangement or control package. Options are the available choices within those features. Parameters are values entered or calculated during configuration, such as tank diameter, flow rate, lifting capacity or cable length.

    For an industrial pump, the model might contain:

    • pump type and impeller family;
    • flow rate and discharge head;
    • fluid temperature and viscosity;
    • casing and impeller material;
    • shaft seal type;
    • motor voltage, frequency and power;
    • base, coupling and guard options;
    • connection size and orientation.

    Validation rules use these values to determine which options remain available and what calculations must be performed.

    Dependencies and constraints

    A dependency describes a relationship between product elements. A constraint limits the combinations or values that are allowed. For example, a high-temperature fluid condition may require a particular seal family. A large impeller may require a larger casing. A 12-metre conveyor may require an intermediate support structure.

    Constraints can be expressed as allowed combinations, prohibited combinations, ranges, required selections or conditional requirements. They may also depend on plant, market, regulatory region, product revision or manufacturing method.

    It is useful to distinguish three related approaches:

    Approach Purpose Manufacturing example
    Rules-based configuration Applies explicit if-then logic and option dependencies. If a hazardous-area motor is selected, require the matching certified enclosure and documentation.
    Constraint-based configuration Finds or restricts solutions within technical limits and relationships. Select a heat exchanger and fan combination that satisfies airflow and thermal capacity limits.
    Guided selling Uses questions and recommendations to help a user reach a suitable product. Ask about room size, operating temperature and airflow before presenting HVAC unit options.

    These approaches can coexist, but guided selling alone is not technical validation. A guided selling questionnaire may lead a user toward a product family, while rules and engineering calculations determine whether the final configuration is valid.

    Types of technical validation checks

    Compatibility validation

    Compatibility validation checks whether selected components can operate together. Examples include a motor and gearbox combination, a valve body and actuator, a truck chassis and body module, or an electrical enclosure and control hardware.

    Compatibility can be simple, such as a direct option dependency, or complex, such as checking voltage, current, environmental rating, connector type and available mounting space across several assemblies.

    Range and dimensional validation

    Range validation checks whether values fall within approved limits. A configurable pressure vessel may accept a diameter from one range and a wall thickness from another. A machine enclosure may require minimum clearance around moving parts. A conveyor length may be limited by the selected frame profile and support spacing.

    Dimensional checks should account for units, tolerances, reference datums and rounding. A model that accepts metric and imperial inputs must define how conversions are handled and how values are stored for downstream systems.

    Performance and engineering calculations

    Some products require calculated values rather than simple option checks. A pump configuration may calculate hydraulic power. An HVAC unit may calculate capacity from airflow, entering temperature and leaving temperature. A lifting device may compare rated load, reach and duty cycle. An electrical system may calculate current, heat dissipation or enclosure requirements.

    Calculation logic should identify its inputs, formulas, units, assumptions, valid ranges and output actions. If a calculation is outside its validated operating range, the system should not silently produce a result. It should raise an exception, request engineering review or prevent completion.

    Material and application validation

    Material rules connect the customer application to approved product materials. Fluid chemistry, temperature, corrosion exposure, hygiene requirements and outdoor installation can influence casing, seals, coatings, fasteners and insulation.

    For example, selecting a corrosive chemical may exclude a standard elastomer and require a different seal material. The rule should also identify whether the replacement affects price, lead time, procurement codes, drawings or certification documents.

    Manufacturing and supply validation

    A technically feasible product may still be unsuitable for a specific plant or supply chain. Manufacturing validation can check whether a component is approved for a plant, whether a fabrication process supports the requested dimension, or whether a selected component is obsolete or temporarily unavailable.

    These checks often require data from enterprise systems. Enterprise Resource Planning (ERP) systems may provide item status, plant data and purchasing information. Product Lifecycle Management (PLM) or Product Data Management (PDM) systems may provide released revisions and approved structures. A CPQ platform should not be treated as the authoritative source for all of this information unless the architecture explicitly makes it so.

    Validation outputs: errors, warnings, recommendations and reviews

    Not every issue should block configuration. A useful validation design distinguishes the severity and action associated with each result.

    Output Meaning Example
    Error The configuration cannot be completed or released. The selected motor does not meet the calculated load requirement.
    Warning The configuration is possible but requires attention or acceptance. The requested paint system is available only at a longer lead time.
    Recommendation An alternative may improve technical or commercial suitability. Recommend a larger frame to provide additional service margin.
    Engineering review The standard model cannot fully determine suitability. A custom support structure is needed for an unusual installation.
    Information Provides context without changing validity. Shows the calculated operating point and selected design margin.

    Each result should have an owner and a defined resolution. A vague message such as configuration invalid is difficult for sales and engineering teams to use. A better message identifies the condition, the affected selection and the next action, such as select a motor rated at least 15 kilowatts or submit the configuration for application engineering review.

    Relationship between validation, BOM, CAD and pricing

    Technical validation is a central point in the flow from customer requirements to production data, but it is not the same as BOM generation, CAD automation or pricing.

    • Validation determines whether the configuration satisfies defined technical and business conditions.
    • BOM generation determines which components and quantities are associated with the valid configuration.
    • CAD automation creates or updates geometry, models, drawings or layouts when supported by the architecture.
    • Costing and pricing calculate internal cost, customer price, margin, discounts and commercial approvals.
    • Quoting presents the commercial result, scope, assumptions, lead time and terms to the customer.

    A valid configuration may generate a configurable BOM without generating a finished CAD model. Conversely, a CAD system may create geometry while the CPQ model still lacks complete costing or manufacturing logic. These capabilities should be evaluated separately. See the guide to BOM generation, pricing and quote automation and the guide to CAD and engineering automation for their distinct roles.

    EBOM, MBOM and configurable BOM

    An Engineering Bill of Materials (EBOM) describes a product from an engineering design perspective. A Manufacturing Bill of Materials (MBOM) represents how the product is assembled or produced, including manufacturing-specific structures, operations or consumables. A configurable BOM is a structure that changes according to selected options, parameters and rules.

    Technical validation may operate before BOM generation, during component selection or after a preliminary BOM is produced. For example, the configuration may validate the chosen motor family first, then select the exact item number and quantity for the configurable BOM. An ERP or manufacturing system may later transform that structure into an MBOM or production order.

    Where validation fits in the manufacturing workflow

    A typical workflow begins when a salesperson, dealer, sales engineer or customer enters requirements into the CPQ configurator. The system applies product rules, performs calculations and identifies invalid selections. When the configuration passes the required checks, it can calculate cost and price, generate a quote and prepare downstream data.

    1. Capture customer requirements and operating conditions.
    2. Select the product family and required features.
    3. Apply dependencies, exclusions and value ranges.
    4. Run engineering calculations and technical constraints.
    5. Generate validation messages and resolve exceptions.
    6. Determine the configured BOM, options, documentation and possible CAD outputs.
    7. Calculate cost, price, margin and lead-time implications.
    8. Route non-standard or incomplete cases to engineering approval.
    9. Create the quote and, after acceptance, transfer approved data to ERP, PLM, CAD or manufacturing systems.

    In Configure-to-Order (CTO), validation usually selects from an established product model and released components. In Engineer-to-Order (ETO), validation may identify the boundary between standard configuration and work that requires engineering design. Make-to-Order (MTO) and Assemble-to-Order (ATO) processes may use similar checks, but their item, routing and production-data requirements differ. The related manufacturing workflow guide explains these distinctions.

    Maintainability of validation rules

    A technically correct rule can still become a long-term problem if nobody can maintain it. Product models often outlive the original implementation team, and rules change when products, suppliers, plants, standards and engineering policies change.

    Manufacturers should maintain a clear ownership model. Product management may own feature definitions, engineering may own technical constraints, manufacturing may own plant-specific rules, supply chain may own sourcing restrictions and commercial teams may own approval thresholds. A governance process must resolve conflicts between these owners.

    Useful maintenance practices include:

    • store rules in readable, named units rather than one large block of opaque logic;
    • separate product structure, technical constraints, pricing and workflow approvals;
    • record the source, owner, revision and effective date of important rules;
    • use version control for product models and released configurations;
    • define units, tolerances, rounding and calculation precision explicitly;
    • test normal, boundary, invalid and exception cases;
    • retain known-good configurations as regression tests;
    • review rules when components become obsolete or engineering standards change;
    • monitor validation failures to identify unclear requirements or missing model logic.

    Rule maintainability is a major selection criterion when evaluating manufacturing CPQ and product configuration software. A platform may demonstrate powerful configuration functions but still be difficult to govern at the scale of a large industrial product portfolio.

    Implementation considerations

    Start with decision-critical rules

    Do not attempt to encode every engineering fact at once. Begin with rules that prevent expensive or frequent errors, such as incompatible voltage selections, impossible dimensions, missing required assemblies and invalid operating ranges. Expand the model after the initial rule set is tested in real quoting workflows.

    Define the authoritative source for each data type

    The CPQ application may own the sellable option model, while PLM owns released engineering revisions, ERP owns item and plant data, Customer Relationship Management (CRM) stores the opportunity and customer context, and CAD owns detailed geometry. Product Information Management (PIM) may manage descriptive and channel content, while a Manufacturing Execution System (MES) manages shop-floor execution. These systems are related but not interchangeable.

    Integration decisions should define which system creates, approves, updates and consumes each data object. The CPQ integration guide provides a framework for separating these responsibilities.

    Test rules with engineering scenarios

    Testing should use representative products and real configuration paths. Include minimum and maximum dimensions, incompatible materials, unusual but valid combinations, obsolete items, unit conversions, missing data and transitions between product revisions. Test both the user experience and the downstream output. A configuration that displays no error but creates an incomplete BOM is not technically validated.

    Plan for human review

    Some cases cannot be safely automated. Define when the system should stop, what evidence the engineer receives, which fields can be changed and how the approved result returns to the quote. A controlled engineering review is preferable to allowing users to bypass a rule without traceability.

    Implementation planning should cover data migration, ownership, release management, testing, adoption and ongoing support. The CPQ implementation guide covers these activities in more detail.

    Limitations and common failure modes

    Technical validation is only as reliable as the product data, rules and assumptions behind it. Common failure modes include:

    • Incomplete product knowledge: undocumented engineering exceptions remain outside the model.
    • Stale data: obsolete components or unreleased revisions remain selectable.
    • Overly broad rules: a rule blocks valid configurations because it does not account for a legitimate exception.
    • Overly narrow rules: the model accepts a combination that fails under actual operating conditions.
    • Hidden calculations: users cannot understand why a value or option was selected.
    • System duplication: the same rule is implemented differently in CPQ, ERP and CAD.
    • False certainty: a green validation result is treated as a guarantee of full engineering suitability.
    • Weak exception handling: users bypass warnings or create uncontrolled manual changes.

    Validation should therefore communicate its scope. It can confirm that a configuration satisfies modeled rules, but it may not confirm site conditions, regulatory approval, installation quality, supplier performance or every aspect of detailed design.

    How to evaluate technical validation in a CPQ platform

    When comparing platforms, ask vendors to demonstrate a real manufacturing scenario rather than a generic option-selection screen. Useful evaluation questions include:

    • Can the model handle numeric parameters, ranges, units and tolerances?
    • Can rules express dependencies across multiple assemblies?
    • Can the system perform engineering calculations, and how are formulas tested?
    • Can validation produce errors, warnings, recommendations and engineering-review states?
    • Can the platform distinguish configured items, EBOM structures and MBOM requirements?
    • How are product revisions, effective dates and plant-specific rules managed?
    • Can rules be maintained by authorized business and engineering users?
    • How are validation results exposed through APIs or integrations?
    • What happens when ERP, PLM, PDM or CAD data is unavailable?
    • Can the system preserve an auditable record of the rules and revisions used for a quote?

    These questions help distinguish a manufacturing product configurator from a quoting application that only handles bundles, discounts and proposal documents.

    Conclusion

    Technical validation is the control layer that connects product configuration with engineering reality. It checks options, parameters, dimensions, materials, calculations, manufacturing constraints and required outputs before a configured product proceeds to pricing, quoting or production.

    Reliable validation requires more than a collection of if-then statements. It depends on a maintainable product model, authoritative data, clear rule ownership, tested calculations, controlled exceptions and appropriate integration with ERP, PLM, PDM, CAD and manufacturing systems. When implemented carefully, a CPQ configurator can prevent predictable configuration errors while still routing genuinely novel or high-risk products to engineering review.

    Semantic map

    The main entities and relationships covered in this guide are:

    • CPQ configurator → applies → product configuration rules
    • Product model → contains → features, options, parameters and constraints
    • Technical validation → checks → compatibility, dimensions, materials and performance
    • Engineering calculation → produces → technical requirement or selection result
    • Configuration rule → prevents → invalid product combination
    • Valid configuration → generates → configurable BOM
    • Configurable BOM → can be transformed into → manufacturing BOM
    • Valid configuration → supports → pricing and quote generation
    • CAD automation → uses → configured dimensions and selections
    • CPQ → exchanges product and order data with → ERP
    • CPQ → exchanges released product data with → PLM or PDM
    • Exception handling → routes non-standard cases to → engineering review
    • CTO workflow → uses → released product rules
    • ETO workflow → identifies → work requiring engineering design
    • Rule governance → maintains → product model accuracy

    Frequently asked questions

    1. What is technical validation during product configuration?

    It is the process of checking whether a proposed product satisfies defined technical, dimensional, material, performance and manufacturing rules before it is quoted or released.

    2. Is technical validation the same as product configuration?

    No. Product configuration selects and defines the product. Technical validation checks whether the selected values and options form a valid and usable product.

    3. How does a CPQ configurator validate a product?

    It evaluates rules, dependencies, constraints, parameter ranges and, where supported, engineering calculations against the selections entered by the user.

    4. What is an example of a technical validation rule?

    A rule might require a larger motor when calculated pump power exceeds the rating of the selected motor family, or prevent a material from being used with an incompatible fluid.

    5. Can technical validation check dimensions?

    Yes, if the product model includes dimensional parameters, units, allowable ranges, tolerances and the relationships between dimensions and components.

    6. Does every CPQ platform support engineering calculations?

    No. Some platforms support formulas or constraint logic, while others require a separate engineering calculation service or integration with specialist software.

    7. Does a valid configuration automatically produce a BOM?

    No. BOM generation is a separate capability. A platform may validate a configuration without generating an Engineering BOM, Manufacturing BOM or configurable BOM.

    8. What is the difference between a configurable BOM and an MBOM?

    A configurable BOM changes according to product selections. A Manufacturing BOM represents how the selected product is structured and produced in a manufacturing environment.

    9. Can validation replace engineering review?

    No. It can automate known and repeatable checks, but unusual applications, certification requirements and new designs may still require engineering review.

    10. What should happen when a configuration fails validation?

    The system should identify the failed condition, affected selection and corrective action. It may block the configuration, suggest an alternative or route the case for engineering approval.

    11. What is the difference between an error and a warning?

    An error normally prevents completion or release. A warning indicates a condition that may be acceptable but requires attention, acknowledgement or further review.

    12. How are technical validation rules maintained?

    Rules should have named owners, documented sources, version control, effective dates, regression tests and a formal process for product and engineering changes.

    13. Which systems provide data for validation?

    Depending on the architecture, CPQ may use product data from PLM or PDM, item and plant data from ERP, geometry from CAD and customer context from CRM.

    14. Can validation include supply-chain restrictions?

    Yes, a model can check approved suppliers, plant availability, obsolete items or sourcing restrictions when that information is available and current.

    15. How does validation support configure-to-order manufacturing?

    It ensures that the selected configuration stays within the approved product model and can be built from released components and defined manufacturing structures.

    16. How does validation support engineer-to-order manufacturing?

    It can identify which requirements fall outside the standard model and create a controlled engineering-review path instead of allowing an unsupported configuration to proceed as standard.

    17. Why are units and tolerances important?

    Inconsistent units, rounding or tolerances can produce incorrect calculations and false validation results, especially for dimensions, pressure, temperature, flow and electrical values.

    18. What should manufacturers demonstrate when evaluating a CPQ platform?

    They should demonstrate a real product scenario involving numeric parameters, dependencies, engineering calculations, validation messages, BOM outputs, revisions and downstream system handoffs.

  • System-Level Configuration for Complex Industrial Solutions

    System-level configuration is the process of selecting and validating multiple related products, subsystems and engineering parameters as one complete industrial solution. In manufacturing CPQ, or Configure, Price, Quote software, the objective is not merely to choose options on a single product. It is to ensure that pumps, motors, valves, controls, frames, electrical equipment, software and services work together, meet technical constraints, produce accurate commercial results and generate usable downstream data.

    A system-level configurator therefore sits between product configuration, engineering, pricing and manufacturing. It may use rules to prevent incompatible selections, calculations to size components, configuration data to create a configurable bill of materials (BOM), and integrations to transfer the result to enterprise systems. The exact scope depends on the platform. Some CPQ products focus primarily on guided selling and quotations, while manufacturing-oriented systems may also support engineering calculations, CAD automation, BOM generation or configure-to-order and engineer-to-order workflows.

    For example, configuring an industrial pumping system may require more than selecting a pump model. The system may need to evaluate flow, pressure, fluid properties, temperature, materials, motor voltage, starter type, instrumentation, piping connections, skid dimensions and site requirements. A valid configuration must satisfy hydraulic, mechanical, electrical, commercial and production constraints simultaneously.

    This guide explains how system-level configuration works, how to structure the product model, how to manage rules and dependencies, where the data flows after configuration, and what manufacturers should consider before implementing it. For a broader introduction, see the guide to manufacturing CPQ and the detailed guide to product configuration and rules engines.

    What is system-level configuration?

    System-level configuration is the coordinated configuration of a complete solution made up of several products, assemblies or functional subsystems. The configurator evaluates relationships between those parts rather than treating each item as an independent selection.

    A system may include:

    • a primary machine or piece of equipment;
    • mechanical assemblies such as frames, conveyors, guards and enclosures;
    • electrical components such as motors, drives, starters, panels and sensors;
    • fluid, hydraulic or pneumatic components;
    • control hardware and software;
    • installation materials, commissioning services and documentation;
    • customer-specific engineering or site adaptations.

    In a simple product configurator, an option may be valid or invalid within one product family. In a system-level configurator, validity may depend on selections made elsewhere in the system. A selected motor can affect the drive, electrical panel, cooling requirements, mounting arrangement, cable size, price and BOM. A selected process fluid can affect pump materials, seals, temperature limits and certification requirements.

    Why system-level configuration matters in manufacturing

    Complex industrial sales often begin with a customer requirement rather than a finished part number. The sales engineer must translate a process need into a complete technical solution. This creates several risks when configuration is performed manually in spreadsheets, product catalogs, email and disconnected engineering tools.

    • Incomplete scope: important accessories, controls, protection devices or services may be omitted.
    • Invalid combinations: selected components may not be mechanically, electrically or operationally compatible.
    • Inconsistent calculations: two engineers may apply different sizing assumptions or formulas.
    • Slow engineering review: specialists must repeatedly check routine configurations.
    • Incorrect pricing: system dependencies, options and engineering effort may not be reflected in the quote.
    • Poor order handoff: sales information may not be structured for ERP, product lifecycle management or production systems.

    System-level configuration addresses these problems by making the relationships explicit in a governed product model. It does not eliminate engineering judgment. Instead, it automates repeatable decisions and identifies cases that require review or a separate engineer-to-order process.

    System-level configuration compared with other configuration approaches

    Approach Primary purpose Typical manufacturing example Main limitation
    Guided selling Help a user select suitable products through questions and recommendations Recommend a standard air-handling unit based on airflow and building type May not validate deep engineering relationships or create manufacturing data
    Rules-based configuration Apply explicit if-then logic to options and dependencies If a high-temperature seal is selected, restrict the material and certification options Large numbers of exceptions can make rules difficult to maintain
    Constraint-based configuration Represent permitted and prohibited relationships across variables and components Ensure pump duty, motor capacity, voltage, impeller size and frame dimensions remain compatible Requires a well-defined constraint model and clear ownership
    Product configuration Define one product or product family Configure a conveyor length, belt type, drive and guarding package May not coordinate several product families or subsystems
    System-level configuration Validate and generate a complete interconnected solution Configure a packaging line with conveyors, robots, controls, safety equipment and services Has greater data, integration and governance complexity

    These approaches can coexist. A system-level configurator may use guided questions at the user interface, rules-based logic for explicit policies, constraint solving for technical compatibility and engineering calculations for sizing.

    The product model behind a system configurator

    The product model is the structured representation of what can be sold, how it can be configured and what the configuration produces. A maintainable model separates commercial choices from engineering logic while defining the relationships between them.

    System hierarchy

    The hierarchy describes the solution from the system level down to modules, assemblies, components and selectable options. For example, a material-handling system could be represented as:

    • material-handling solution;
    • conveyor line;
    • infeed conveyor, transfer section and discharge conveyor;
    • frame, belt, roller, motor, gearbox and guarding assemblies;
    • drive, control panel, sensors and safety devices;
    • installation, commissioning and documentation services.

    The hierarchy should reflect how the company sells, engineers, procures and manufactures the solution. A sales bundle is not always the same as an engineering assembly or a manufacturing assembly.

    Features, options and parameters

    Features describe meaningful aspects of the system, such as capacity, operating environment, control architecture or compliance requirement. Options are selectable values or components. Parameters are measurable inputs such as flow rate, length, voltage, pressure, temperature, load or speed.

    For a pump skid, parameters may include:

    • design flow and differential pressure;
    • fluid density, viscosity and temperature;
    • pump material and seal arrangement;
    • motor power, voltage, frequency and enclosure rating;
    • connection standard and nozzle orientation;
    • skid footprint, lifting points and access requirements;
    • instrumentation and control protocol.

    Parameters can drive calculations and rules. They should not be treated as free-text notes if downstream systems need to use them. A structured temperature value can trigger material restrictions; a free-text statement such as hot service cannot reliably do so.

    Relationships between subsystems

    The model must represent relationships such as requires, excludes, compatible with, derives from, sized by and supplied with. These relationships may cross product boundaries.

    For example, selecting a 460-volt motor may require a matching control-panel voltage, affect the starter or variable-frequency drive, and restrict the available documentation package. Selecting stainless steel wetted parts may require compatible fasteners, seals and welding procedures. Selecting outdoor installation may require a specific enclosure rating, heater, coating system and cable-entry arrangement.

    Rules and constraints in system-level configuration

    Rules determine how the configurator responds to selections and calculated values. A constraint is a condition that must be satisfied for the complete configuration to be valid. In practice, manufacturers often use several types of logic together.

    Compatibility rules

    Compatibility rules prevent combinations that cannot work together. A gearbox may be incompatible with a particular conveyor width. A control panel may not support the selected number of axes. A valve material may be unsuitable for the specified chemical or temperature range.

    Dependency rules

    Dependency rules add or require related elements. Selecting a hazardous-area motor may require certified cable glands, an appropriate enclosure, special documentation and an inspection activity. Selecting a robotic cell may require safety fencing, interlocks and a safety controller.

    Exclusion rules

    Exclusion rules remove options that are not available in a particular configuration. A compact frame may exclude a large motor. A selected certification route may exclude certain materials or control components. Exclusions should be explained clearly to the user so that a technical restriction does not appear to be an arbitrary sales limitation.

    Calculation rules

    Calculation rules derive values from customer inputs. A configurator may calculate required motor power, heat-exchanger area, tank volume, cable size, pressure drop, structural load or estimated cycle time. Calculations need version control, documented assumptions, units and an approval process. A formula embedded in an interface without ownership or testing becomes difficult to trust.

    Availability and commercial rules

    Some rules relate to sourcing and commercial policy rather than technical validity. A component may be technically suitable but unavailable in a region, obsolete, restricted to a particular plant or subject to a minimum order quantity. These rules should be distinguished from engineering constraints because they have different owners and change cycles.

    Example: configuring a complete pump and control skid

    Consider a manufacturer selling packaged pump skids for industrial water treatment. The customer specifies flow, pressure, fluid temperature, installation location, electrical supply and control requirements.

    Configuration inputs

    • flow rate and required head;
    • fluid composition and temperature;
    • continuous or intermittent duty;
    • indoor or outdoor installation;
    • available voltage and frequency;
    • single-pump or duty-standby arrangement;
    • local control, remote monitoring or plant-network integration;
    • footprint, lifting and access restrictions.

    Configuration logic

    The model uses the duty point to select an appropriate pump family and impeller range. Fluid temperature and composition restrict materials and seal options. Duty-standby operation adds a second pump, isolation valves, check valves, instrumentation and control logic. Outdoor installation affects the panel enclosure, coating, heater and weather protection. The available electrical supply constrains the motor and drive options.

    If the calculated motor load exceeds the selected drive range, the configurator should reject the combination or propose a larger drive. If the skid footprint is too small for the selected pump and maintenance clearance, the system should identify the issue before quotation. If the requested duty falls outside the standard product model, the configuration may be routed to engineering review rather than silently producing a standard quote.

    Outputs

    The configuration may produce a technical specification, price, lead-time assumptions, system BOM, equipment tag list, control narrative and quotation. Depending on the company’s architecture, it may also trigger CAD automation for the skid layout, create an engineering bill of materials (EBOM), or send order data to an enterprise resource planning (ERP) system.

    How system-level configuration connects to engineering and manufacturing

    A system configurator is most useful when its output is structured for the next process. The exact flow depends on whether the product is configure-to-order, make-to-order or engineer-to-order.

    Configuration to engineering

    For standard or lightly variable solutions, the configuration may provide enough information for order release. For more complex solutions, it can create an engineering work package containing selected options, calculated values, unresolved decisions, customer documents and review requirements.

    CAD, or computer-aided design, automation may use configuration parameters to select templates, suppress or activate features, set dimensions and generate drawings. This capability is not present in every CPQ platform and may require a separate CAD automation service or integration. More detail is available in the guide to CAD and engineering automation.

    Configuration to BOM generation

    A BOM is a bill of materials listing the components and quantities required for a product or system. An EBOM, or engineering bill of materials, describes the design structure. An MBOM, or manufacturing bill of materials, describes how the product is assembled or produced. A configurable BOM is a rule-driven structure that resolves into a specific BOM after selections and calculations are complete.

    System-level configuration may generate a sales or technical BOM first, then pass data to PLM, ERP or manufacturing systems for further transformation. The configurator should define whether it owns the final BOM, proposes a BOM for engineering approval, or only identifies commercial components. These are different operating models and should not be conflated.

    Configuration to pricing and quoting

    Pricing is related to configuration but is not the same function. The system model determines what the solution contains and whether it is valid. The pricing engine determines material prices, labor, engineering effort, services, discounts, margins, freight assumptions and commercial adjustments.

    A pump skid may have a component price, a package assembly charge, engineering hours, testing fees and commissioning services. Some values may come from ERP or a costing system. A quote should make clear which values are calculated automatically and which require commercial approval. See BOM, pricing and quoting automation for the relationship between these functions.

    Configuration to enterprise systems

    Common systems have different responsibilities:

    System Typical responsibility in a system-level workflow
    CRM, or customer relationship management Customer, opportunity, account and sales-process information
    CPQ Configuration interaction, rules, calculations, pricing and quote preparation
    ERP, or enterprise resource planning Items, inventory, purchasing, production orders, sales orders, finance and fulfillment
    PLM, or product lifecycle management Product structures, revisions, approvals, engineering change and lifecycle governance
    PDM, or product data management Controlled CAD files, drawings and related design data
    CAD Geometric design, assemblies, drawings and design automation
    MES, or manufacturing execution system Production execution, work instructions, tracking and shop-floor reporting
    PIM, or product information management Commercial product content, descriptions, attributes and channel information

    These systems can exchange data through APIs, integration middleware, files or platform-specific connectors. A reliable architecture defines the system of record for each object and avoids creating conflicting versions of the same product, component or rule. See the guide to CPQ integrations for integration patterns and ownership questions.

    System-level configuration across manufacturing workflows

    Configure-to-order

    In configure-to-order (CTO), the manufacturer offers a defined product architecture with controlled options. System-level configuration can validate the customer solution and generate a production-relevant structure without designing a new product for every order.

    Make-to-order

    In make-to-order (MTO), production begins after the order is received, but the product may still use a relatively stable design. The configurator can determine the required components, dimensions and routing information while preserving standard manufacturing rules.

    Engineer-to-order

    In engineer-to-order (ETO), each order requires substantial engineering work. System-level configuration can capture the customer requirement, perform preliminary sizing, define standard subsystems and identify the boundary between reusable logic and bespoke design. It should not pretend that every ETO decision can be automated.

    Assemble-to-order

    In assemble-to-order (ATO), standard modules are assembled after the order is placed. A system configurator can coordinate module compatibility, availability and assembly requirements across the complete solution.

    These workflow distinctions matter because they determine how much authority the configurator has. A CTO model may generate a releasable BOM. An ETO model may generate a controlled engineering request and preliminary estimate instead.

    Benefits of system-level configuration

    • More complete solutions: dependencies help include required accessories, controls and services.
    • Earlier error detection: invalid technical combinations can be identified before quote submission or order entry.
    • Faster routine engineering: repeatable sizing and selection logic can be applied consistently.
    • Better quote quality: price, scope, lead-time assumptions and technical content are based on the same configuration.
    • Improved handoff: structured data is easier to transfer to ERP, PLM, CAD and production processes.
    • Reusable engineering knowledge: validated rules preserve expertise when products, staff or markets change.
    • Greater traceability: the company can identify which rules, revisions and inputs produced a quoted solution.

    Limitations and risks

    System-level configuration is not a shortcut around product data quality or engineering governance. Its limitations usually arise from model scope, unclear ownership and excessive complexity.

    Rules can become unmaintainable

    A model with thousands of overlapping exceptions may be harder to manage than the manual process it replaced. Rules should be modular, named, documented and tested. Repeated logic should be centralized rather than copied across many product families.

    Engineering knowledge may be incomplete

    Experienced engineers often rely on assumptions that are not written down. Before automation, the organization must identify units, tolerances, safety factors, valid operating ranges, standards and approval conditions.

    System boundaries can create ambiguity

    Manufacturers need to decide whether product rules live in CPQ, PLM, ERP, CAD or another service. Duplicating the same logic in several systems creates synchronization risk. A CPQ model may need a simplified commercial representation while PLM remains the authority for released engineering structures.

    Not every configuration is automatable

    Novel applications, unusual site conditions, regulatory interpretations and major customizations may require engineering review. A mature system should support controlled exceptions, not force every opportunity into a standard model.

    Integration does not guarantee usable data

    An API can transfer fields successfully while still producing an unusable manufacturing result. Integration design must address units, revisions, item identities, effectivity, configuration status, error handling and ownership of changes.

    Implementation approach

    1. Select a bounded system

    Start with a product family or solution type where demand is significant, configuration patterns are repeatable and the business can identify a measurable problem. A complete factory-wide model is rarely the best first release.

    2. Map the current workflow

    Document how requirements move from customer inquiry to quote, engineering review, order entry, design release, procurement and production. Identify where data is re-entered, where decisions are delayed and where errors occur.

    3. Establish product and rule ownership

    Assign owners for product options, engineering formulas, pricing, availability, compliance, BOM structures and integration mappings. Define who approves a rule, who tests it and who can release a revision.

    4. Build the minimum viable product model

    Model the system hierarchy, key parameters, standard modules, critical constraints and required outputs first. Avoid automating low-value exceptions before the core logic is proven.

    5. Separate decisions from presentation

    The user interface should guide sales engineers or customers, but the underlying model should hold the authoritative rules and calculations. This makes the logic easier to test and reuse in dealer portals, internal tools or APIs.

    6. Test real configuration scenarios

    Testing should include valid standard cases, boundary values, incompatible selections, changed product revisions, unavailable components, incomplete inputs and deliberate engineering exceptions. Test the resulting quote, BOM, CAD output and ERP transaction where applicable.

    7. Pilot the downstream handoff

    Do not stop at a technically valid quote. Confirm that engineering, purchasing, production and service can use the generated output. A system-level model is successful only when it reduces work across the workflow rather than moving effort to a later department.

    8. Govern changes after launch

    Manufacturers need a release process for new components, obsolete parts, price updates, revised formulas, regulatory changes and plant-specific availability. Configuration models require ongoing maintenance, regression testing and monitoring.

    Further guidance is available in the guide to CPQ implementation and governance and the overview of manufacturing configuration workflows.

    How to evaluate a system-level CPQ configurator

    Buyers should evaluate the complete configuration lifecycle rather than counting interface features. Important questions include:

    • Can the model represent multiple interacting subsystems and reusable modules?
    • Can rules express dependencies, exclusions, ranges, calculations and approval conditions?
    • Can non-developers maintain appropriate product content and rules?
    • Can the system distinguish technical validity from commercial availability?
    • Can it generate or integrate with a configurable BOM, EBOM or MBOM process?
    • Can it pass structured parameters to CAD, PLM, ERP or MES systems?
    • Can it support both standard configurations and controlled ETO exceptions?
    • Can it show users why a selection is invalid or what additional information is needed?
    • Does it provide versioning, testing, audit trails and effective dates?
    • Can it support dealer, distributor, internal sales-engineering and API-based channels?
    • How are units, currencies, revisions, item numbers and configuration identifiers handled?
    • What happens when an integration fails or a component becomes unavailable?

    Vendor claims should be verified through a realistic scenario using the manufacturer’s own product structure and rules. A platform may advertise configuration support while requiring separate software for CAD automation, engineering calculations or manufacturing BOM transformation. Product research can be organized using the manufacturing CPQ software profiles and comparison and selection guidance.

    Semantic map

    System-level configuration connects customer requirements, product models, rules, engineering calculations, commercial outputs and manufacturing systems. The following relationships summarize the article:

    • Customer requirements feed system parameters.
    • System parameters drive engineering calculations.
    • Engineering calculations constrain component selection.
    • Configuration rules prevent invalid subsystem combinations.
    • Subsystem dependencies determine required accessories and controls.
    • A valid configuration produces a structured solution definition.
    • A structured solution definition can generate a configurable BOM.
    • An engineering BOM may be transformed into a manufacturing BOM.
    • Configuration data informs pricing and costing.
    • CPQ exchanges customer and configuration data with CRM and ERP.
    • CAD automation can use configuration parameters to generate drawings.
    • PLM governs released product structures and revisions.
    • ETO exceptions create engineering review work.
    • Configuration governance maintains rules, formulas and product revisions.

    Frequently asked questions

    What is system-level configuration in manufacturing?

    It is the configuration of a complete industrial solution made up of several related products, assemblies or subsystems. The system validates technical relationships across those parts rather than configuring each product independently.

    How is system-level configuration different from product configuration?

    Product configuration usually focuses on one product family. System-level configuration coordinates multiple product families and evaluates dependencies between mechanical, electrical, software, service and process elements.

    What is a system-level CPQ configurator?

    It is CPQ software that captures requirements, applies configuration rules and produces a valid industrial solution across multiple subsystems. Depending on the platform, it may also calculate prices, generate BOM data or connect to engineering and enterprise systems.

    Does every CPQ system support system-level configuration?

    No. Some CPQ platforms primarily support guided selling, option selection and quote generation. Buyers must verify whether a platform supports deep rules, calculations, multi-level BOMs, engineering workflows and required integrations.

    What types of rules are needed?

    Common rule types include compatibility, dependency, exclusion, calculation, availability, compliance and approval rules. The mix depends on the product and the level of engineering automation required.

    Can system-level configuration replace engineering?

    No. It can automate repeatable decisions and identify standard solutions, but novel applications, unusual conditions and major customizations still require engineering judgment and review.

    Can a system configurator calculate equipment size?

    Some systems can perform engineering calculations or call an external calculation service. This is not universal. The manufacturer must verify formula support, unit handling, validation, versioning and approval controls.

    Can system-level configuration generate a BOM?

    Some manufacturing CPQ systems can generate a configurable or resolved BOM, while others pass selections to ERP or PLM for BOM creation. The implementation must define whether the CPQ output is authoritative, preliminary or subject to engineering transformation.

    What is the difference between an EBOM and an MBOM?

    An EBOM represents the engineering design structure. An MBOM represents the structure and sequence used to manufacture or assemble the product. A system-level configurator may create one, both, or data that another system transforms between them.

    How does system-level configuration support engineer-to-order?

    It captures structured requirements, selects reusable modules, performs preliminary calculations and identifies the work that requires engineering. It supports ETO without assuming that all custom design decisions can be automated.

    How does system-level configuration support configure-to-order?

    It validates selections within a predefined product architecture and can produce a quote, configuration identifier, BOM and order data for a standard but customizable solution.

    What manufacturing example suits system-level configuration?

    Examples include pump skids, HVAC systems, packaging lines, electrical distribution systems, industrial vehicles, conveyors and machine cells where several subsystems must operate together.

    Where should configuration rules be stored?

    The answer depends on the architecture. CPQ may own commercial configuration logic, PLM may govern released engineering structures, ERP may own item and availability data, and CAD may own geometric logic. Ownership and synchronization must be defined explicitly.

    How can manufacturers keep rules maintainable?

    Use modular rules, clear naming, documented assumptions, ownership, version control, effective dates, automated regression tests and a formal change process. Avoid duplicating the same logic across multiple systems.

    What happens when a customer request is outside the product model?

    The configurator should identify the exception and route it to engineering or commercial review. It should not silently accept a configuration that has not been technically or commercially approved.

    What is the role of CAD automation?

    CAD automation can use configuration parameters to select templates, set dimensions, activate features and generate product-specific drawings. It is often implemented through a separate CAD automation capability or integration rather than being native to every CPQ platform.

    How does system-level configuration affect pricing?

    The selected system structure determines which components, services and engineering activities need pricing. A pricing engine then applies costs, prices, discounts, margins and approval policies. Configuration and pricing should be connected but governed as separate concerns.

    What integrations are usually required?

    Common integrations include CRM for opportunities, ERP for items and orders, PLM or PDM for product data, CAD for design automation, MES for production execution and PIM for commercial product information. The required set depends on the workflow.

    How should a manufacturer start a system-level configuration project?

    Start with one bounded product or solution family, map the current workflow, establish rule ownership, model the critical constraints, test real cases and validate the downstream handoff before expanding the scope.

  • 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.