CPQ Guide

Category: Guide

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

  • Option Dependencies in Complex Product Configuration

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

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

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

    What are option dependencies?

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

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

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

    The product model can express dependencies such as:

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

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

    Why option dependencies matter in manufacturing CPQ

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

    An invalid combination can create several problems:

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

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

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

    Core types of option dependencies

    Requires dependencies

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

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

    Excludes dependencies

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

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

    One-of and mutually exclusive dependencies

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

    At-least-one and conditional-required dependencies

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

    Value and range dependencies

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

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

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

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

    Default, recommended and suggested dependencies

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

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

    Conditional visibility dependencies

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

    Automatic inclusion and substitution dependencies

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

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

    How dependencies fit into a product model

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

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

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

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

    Rules-based, constraint-based and guided configuration

    Rules-based configuration

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

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

    Constraint-based configuration

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

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

    Guided selling

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

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

    Dependencies across engineering, BOM and pricing

    Option dependencies often have consequences beyond the configuration screen.

    Engineering calculations and CAD

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

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

    Configurable BOM, EBOM and MBOM

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

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

    Costing and pricing

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

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

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

    Manufacturing example: configurable air-handling unit

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

    Several dependencies interact:

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

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

    Dependencies in CTO, ETO, MTO and ATO workflows

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

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

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

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

    Designing maintainable option dependencies

    Use a controlled vocabulary

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

    Separate product families and validity periods

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

    Prefer reusable constraints over duplicated exceptions

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

    Make rule ownership explicit

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

    Explain why a configuration is invalid

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

    Manage exceptions deliberately

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

    Testing option dependencies

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

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

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

    Common limitations and failure modes

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

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

    Implementation approach

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

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

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

    Semantic map

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

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

    Frequently asked questions

    1. What is an option dependency in CPQ?

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

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

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

    3. Are option dependencies the same as configuration rules?

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

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

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

    5. Can dependencies apply to dimensions and numeric values?

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

    6. Do option dependencies generate a BOM?

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

    7. How do dependencies affect pricing?

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

    8. Can dependencies drive CAD automation?

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

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

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

    10. How are option dependencies tested?

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

    11. Who should own option dependencies?

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

    12. How can manufacturers prevent rule sprawl?

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

    13. Are recommendations the same as hard constraints?

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

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

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

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

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

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

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

    17. Why are clear validation messages important?

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

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

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

    19. Should all product knowledge be stored in CPQ?

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

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

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

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

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

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

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

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

    What is multi-product configuration?

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

    A multi-product configuration normally contains:

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

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

    Why manufacturers need multi-product configuration

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

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

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

    How the product-model architecture works

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

    1. Product models

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

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

    2. Solution or system model

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

    A system model for a pumping package might contain:

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

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

    3. Shared parameters

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

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

    4. Relationship rules

    Relationship rules control how products interact. Common forms include:

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

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

    Rules in a multi-product configurator

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

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

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

    Hard constraints and soft guidance

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

    Manufacturers should distinguish between:

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

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

    Example: configuring a pump package

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

    The user enters:

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

    The CPQ system can then perform several levels of evaluation:

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

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

    Multi-product BOM generation

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

    Configurable BOM

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

    EBOM and MBOM

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

    A multi-product system may have:

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

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

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

    Pricing and quoting for a configured system

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

    Pricing may include:

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

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

    CAD, engineering and technical outputs

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

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

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

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

    Read more about CAD and engineering automation in CPQ.

    Enterprise-system relationships

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

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

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

    Where multi-product configuration fits in manufacturing workflows

    Multi-product configuration can support several fulfillment models.

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

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

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

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

    Benefits of multi-product configuration

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

    Limitations and risks

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

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

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

    Implementation approach

    1. Select a bounded use case

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

    2. Map products and interfaces

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

    3. Define data ownership

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

    4. Classify rules

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

    5. Design outputs before finalizing the interface

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

    6. Build test scenarios

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

    7. Govern releases

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

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

    Maintainability principles

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

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

    How to evaluate a CPQ configurator for multi-product use

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

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

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

    Semantic map

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

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

    FAQ

    What is multi-product configuration in CPQ?

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

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

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

    What manufacturing products commonly require multi-product configuration?

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

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

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

    Can it support engineer-to-order products?

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

    What is a system-level rule?

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

    What are shared parameters in a CPQ configurator?

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

    Does every CPQ system support cross-product constraints?

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

    How does multi-product configuration affect BOM generation?

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

    Can CPQ generate an MBOM directly?

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

    How does pricing work for a configured system?

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

    Does multi-product configuration require CAD automation?

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

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

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

    What is the role of ERP?

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

    Should product rules be stored in CPQ or PLM?

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

    How can manufacturers prevent rule explosion?

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

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

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

    How should multi-product configurations be tested?

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

    What should a manufacturer ask a CPQ vendor?

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

  • How to Prevent Dead Ends in Product Configuration

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

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

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

    What is a configuration dead end?

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

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

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

    Why dead ends occur in manufacturing product models

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

    Options are modelled independently

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

    Rules are written as exceptions

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

    Engineering calculations are separated from configuration

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

    Downstream systems impose hidden constraints

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

    Product variants are not governed as a system

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

    Model the product as a constraint network

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

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

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

    Use the right type of rule

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

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

    Prevent dead ends with forward checking

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

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

    Use domain filtering

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

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

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

    Expose the reason for restrictions

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

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

    Build a complete configuration workflow

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

    1. Capture requirements before options

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

    2. Select a product architecture

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

    3. Resolve technical dependencies

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

    4. Generate and validate engineering data

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

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

    5. Validate commercial and operational feasibility

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

    6. Produce a controlled handoff

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

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

    Use a dependency matrix before writing rules

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

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

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

    Design rules for maintainability

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

    Separate product facts from user-interface behaviour

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

    Use reusable constraints

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

    Assign ownership

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

    Version the model with the product

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

    Avoid unrestricted custom logic

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

    Test for dead ends systematically

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

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

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

    Handle unavoidable engineering review explicitly

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

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

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

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

    Connect dead-end prevention to BOM, CAD and quoting

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

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

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

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

    Common approaches that do not work well

    Allow everything and validate at the end

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

    Use only exclusion lists

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

    Put all rules in one person’s knowledge

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

    Copy rules between product families

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

    Measure only quote speed

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

    Implementation checklist

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

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

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

    How to measure improvement

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

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

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

    Conclusion

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

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

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

    Semantic map

    The article connects the following entities and relationships:

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

    Frequently asked questions

    What is a dead end in product configuration?

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

    How is a dead end different from a configuration error?

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

    Can a CPQ configurator prevent every dead end?

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

    What types of rules prevent configuration dead ends?

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

    What is forward checking in product configuration?

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

    Why are calculations important in manufacturing configuration?

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

    Should invalid options be hidden or displayed?

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

    How should a system explain a blocked option?

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

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

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

    Is guided selling enough to prevent dead ends?

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

    How do BOMs relate to dead-end prevention?

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

    What is the difference between an EBOM and an MBOM?

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

    Can CAD automation help prevent dead ends?

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

    How should ETO products be handled?

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

    Who should own configuration rules?

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

    How often should configuration rules be reviewed?

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

    What should happen when no valid configuration exists?

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

    Which metrics show that dead ends are decreasing?

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

  • Feature Models for Manufacturing CPQ

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

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

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

    What is a feature model?

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

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

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

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

    Feature model terminology

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

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

    How a feature model is structured

    Product hierarchy

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

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

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

    Mandatory and optional features

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

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

    Alternative and multiple-selection features

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

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

    Numeric parameters and ranges

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

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

    Rules and constraints in a manufacturing feature model

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

    Common constraint types

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

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

    These terms overlap but should not be treated as identical.

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

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

    Manufacturing example: a configurable pump

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

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

    Several relationships may apply:

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

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

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

    Feature models and product data

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

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

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

    From feature selection to BOM, price and quote

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

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

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

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

    Feature models across CTO, ETO, MTO and ATO

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

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

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

    Maintainability is a core feature-model requirement

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

    Use modular product logic

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

    Separate concerns

    Keep different types of logic distinguishable:

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

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

    Use effective dates and revision control

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

    Assign rule ownership

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

    Testing a feature model

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

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

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

    Implementation approach

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

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

    Limitations and common failure modes

    Feature models can become too complex

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

    Rules cannot replace incomplete engineering knowledge

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

    Overly restrictive models frustrate users

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

    Data synchronization can create conflicting truths

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

    Not every CPQ system supports deep feature modeling

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

    How to evaluate feature-model capability in CPQ software

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

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

    Benefits of a well-designed feature model

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

    Related concepts

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

    Semantic map

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

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

    Frequently asked questions

    1. What is a feature model in CPQ?

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

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

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

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

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

    4. Can a feature model include dimensions?

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

    5. How do feature models prevent configuration errors?

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

    6. What is a configurable BOM?

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

    7. Does every manufacturing CPQ system generate a BOM?

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

    8. Can a feature model drive CAD automation?

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

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

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

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

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

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

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

    12. Who should own a manufacturing feature model?

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

    13. How should obsolete components be handled?

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

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

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

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

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

    16. How are feature models tested?

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

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

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

    18. Is guided selling a feature model?

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

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

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

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

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

  • Dimensional Product Configuration for Made-to-Measure Products

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

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

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

    What is dimensional product configuration?

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

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

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

    How dimensional configuration differs from ordinary option selection

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

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

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

    The product model behind dimensional configuration

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

    Customer-facing parameters

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

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

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

    Calculated parameters

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

    Rules and constraints

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

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

    Dimensional rules and engineering constraints

    Dimensional rules commonly fall into several categories:

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

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

    Worked example: a made-to-measure industrial enclosure

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

    The product model may perform the following sequence:

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

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

    Relationship between dimensions, BOMs and CAD

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

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

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

    Pricing and costing for dimensional products

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

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

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

    Where dimensional configuration fits in the manufacturing workflow

    Dimensional configuration can support several operating models:

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

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

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

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

    Benefits of dimensional product configuration

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

    Limitations and risks

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

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

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

    Implementation approach

    1. Define the standard configuration boundary

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

    2. Inventory product knowledge

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

    3. Separate inputs, rules and outputs

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

    4. Establish units and precision

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

    5. Assign ownership

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

    6. Test the model

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

    7. Plan releases and change control

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

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

    How to evaluate a dimensional CPQ configurator

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

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

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

    Semantic map

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

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

    Conclusion

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

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

    Frequently asked questions

    What is dimensional product configuration?

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

    Is dimensional configuration the same as product configuration?

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

    What products benefit from dimensional configuration?

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

    Can a CPQ system accept arbitrary dimensions?

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

    How do dimensional rules prevent manufacturing errors?

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

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

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

    Does dimensional CPQ require CAD automation?

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

    Can dimensional configuration generate a BOM?

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

    How do dimensions affect product pricing?

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

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

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

    When should a dimensional request become ETO?

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

    How should units and rounding be handled?

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

    Who owns dimensional configuration rules?

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

    Can dealers use a dimensional configurator?

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

    How are dimensional product models tested?

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

    How does dimensional CPQ integrate with ERP?

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

    Can AI replace dimensional configuration rules?

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