CPQ Guide

Tag: engineering automation

  • Geometric Constraints in Configurable Product Design

    Geometric constraints in configurable product design define the spatial and dimensional relationships that a product must satisfy when customers or sales engineers select options. They determine whether components fit, whether clearances are maintained, whether mounting patterns align and whether a configured product can be manufactured safely and correctly.

    In a manufacturing CPQ system, geometric constraints are more than CAD relationships. They form part of the engineering logic connecting a configurable product model to configuration validation, engineering calculations, computer-aided design (CAD) automation, bills of material (BOMs), pricing and the sales-to-engineering handoff. For example, a pump configurator may need to verify that the selected motor fits the baseplate, that the coupling guard clears the shaft and that the outlet orientation is compatible with the installation dimensions.

    A useful implementation treats geometry as structured product knowledge rather than as an isolated drawing problem. The CPQ configurator collects dimensions and options, evaluates rules and constraints, passes approved parameters to CAD or engineering services, and returns product-specific outputs such as a 3D model, drawing, configured BOM or manufacturing data. Not every CPQ platform provides this complete chain, so capability boundaries must be verified during software selection.

    What are geometric constraints?

    Geometric constraints are rules that control the shape, position, orientation, size or spatial relationship of features and components in a product design. They can be applied inside a CAD model, within a product configuration engine, in an engineering calculation service or across several of these systems.

    Typical geometric constraints include:

    • Dimensional constraints: a frame must be between 1,000 and 2,400 millimetres long, or a pipe diameter must match a selected connection standard.
    • Distance constraints: a motor must remain a minimum distance from a guard, wall or adjacent assembly.
    • Alignment constraints: bolt holes, shafts, rails or connectors must share a defined axis or pattern.
    • Orientation constraints: a valve, access panel or discharge nozzle must face a permitted direction.
    • Clearance constraints: moving or serviceable parts require sufficient space to operate or be removed.
    • Containment constraints: an electrical enclosure or component must fit within a cabinet, vehicle bay or machine frame.
    • Topology constraints: components must connect through permitted interfaces, such as a flange, mounting face or cable entry.
    • Motion constraints: doors, booms, actuators or linkages must move through a defined range without collision.

    These constraints are different from simple option compatibility rules. A rule stating that “stainless steel construction requires a particular material grade” is primarily a product or material rule. A rule stating that “the selected pump and motor require a baseplate longer than 1,200 millimetres” is a geometric and dimensional constraint. Manufacturing CPQ often needs both.

    Why geometric constraints matter in manufacturing CPQ

    Generic sales CPQ usually focuses on selecting products, applying pricing logic and generating a commercial quote. Manufacturing CPQ may perform those functions while also validating whether the selected product can be engineered and produced. Geometry becomes important when a configuration changes physical form, component placement, structural requirements or installation conditions.

    Without geometric validation, a quote may describe a product that cannot be assembled or used. Common consequences include:

    • components that interfere during assembly or operation;
    • mounting holes that do not align;
    • insufficient access for maintenance or tool clearance;
    • incorrect enclosure, cabinet or vehicle dimensions;
    • ducts, pipes or cables that cannot reach their connection points;
    • incorrect shaft, belt or coupling geometry;
    • drawings that do not reflect the selected options;
    • late engineering changes and manual redesign;
    • incorrect BOM quantities or component variants;
    • quotes that require unplanned engineering effort or cannot be fulfilled.

    A well-designed configuration process can reject invalid combinations, guide the user toward feasible dimensions or route a valid but unusual configuration to engineering review. The objective is not always to automate every design decision. It is to identify what can be validated reliably at the point of configuration and to make exceptions explicit.

    Types of geometric constraints in configurable products

    Dimensional and parametric constraints

    Parametric constraints express relationships between dimensions rather than storing every possible product size as a separate model. For example, the overall length of a conveyor may be calculated as the sum of standard sections, transfer zones and end allowances. A machine frame may have a width that depends on the number of lanes, the selected guarding arrangement and the required service aisle.

    A parametric model might contain relationships such as:

    frame_length = infeed_length + process_length + discharge_length
minimum_guard_clearance = shaft_diameter + safety_allowance
baseplate_length >= motor_length + coupling_length + service_allowance

    The exact syntax depends on the CAD or rules platform. The important point is that the model captures engineering relationships and limits rather than relying on manual redrawing for every configuration.

    Clearance and interference constraints

    Clearance constraints protect physical separation between parts. They are particularly important for rotating machinery, moving assemblies, high-voltage equipment, access doors and products installed in restricted spaces.

    For example, a configurable agricultural machine may require a minimum gap between a wheel, guard and hydraulic line throughout the steering range. A material-handling system may need to confirm that a selected mast height does not interfere with an overhead structure. A control cabinet may need free space in front of components for wiring and service access.

    Clearance validation may be implemented as a simple numerical comparison, a bounding-box test, a spatial calculation or a full CAD interference check. Simple checks are easier to run during a fast web configuration. Detailed collision detection may require a CAD engine or engineering service and may be more appropriate after the initial configuration.

    Interface and mating constraints

    Interface constraints describe how components connect. They can cover flange standards, bolt-hole patterns, shaft diameters, connector locations, rail profiles, mounting faces and pipe connection points.

    In a pump package, the selected pump, motor, coupling and baseplate may each have defined interfaces. A valid configuration must ensure that the shaft arrangement, mounting holes and coupling dimensions are compatible. In an electrical enclosure, the enclosure, gland plate, cable entries and internal mounting rails must use compatible reference locations.

    Interface data is often more reusable than a complete product model. A component can expose connection types and reference geometry, allowing the configuration system to select compatible parts from a controlled library.

    Orientation and location constraints

    Orientation constraints control how a component is positioned relative to the product or installation. Examples include a valve installed with a permitted flow direction, a motor mounted horizontally or vertically, a service door placed on the accessible side and a hydraulic outlet rotated to one of several approved positions.

    Orientation may affect more than geometry. It can change the BOM, cable and pipe lengths, safety requirements, price and installation instructions. The configuration model should therefore treat orientation as a meaningful product parameter, not merely as a visual display setting.

    Motion and kinematic constraints

    Kinematic constraints govern movement. They are used for articulated arms, lift tables, vehicle bodies, access panels, conveyors, linkages and actuated mechanisms.

    A configurator may need to check the operating envelope of a boom, the travel range of an actuator or the rotation of a service door. A static model that fits at rest may still fail when the product moves. Where motion is safety-critical, a CPQ rule should not replace the required engineering analysis. It can perform preliminary screening and identify configurations that require a higher level of review.

    How geometric constraints fit into the product configuration architecture

    Geometric logic usually sits between the product model and the engineering or CAD automation layer. The product model defines available options, parameters and relationships. The constraint engine evaluates whether those selections are valid. A CAD or engineering service then uses approved parameters to generate product-specific outputs.

    A simplified data flow is:

    1. A user or sales engineer selects product options, dimensions and operating requirements in the CPQ configurator.
    2. The configuration engine applies option dependencies, exclusions and required selections.
    3. Geometric constraints check dimensions, interfaces, clearances, orientations and operating limits.
    4. Engineering calculations determine values such as capacity, motor size, wall thickness or structural requirements where applicable.
    5. The system identifies the appropriate components and creates a configurable BOM or passes structured data to an engineering system.
    6. CAD automation updates a parametric model, assembly, drawing or 3D visualization if the connected tools support it.
    7. Pricing and costing logic use the approved configuration and selected components to calculate the commercial result.
    8. The quote records the configuration, assumptions, warnings, approvals and generated documents.
    9. After order acceptance, the approved configuration is transferred to enterprise systems such as enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM) or manufacturing execution systems (MES), depending on the architecture.

    These stages do not have to run in a single application. A CPQ platform may validate rules and create a quote while a separate CAD automation service generates drawings. Another implementation may use a product configurator embedded in a CAD environment. The integration contract should define which system owns each parameter, rule, document and revision.

    Geometric constraints and CAD automation

    CAD automation uses configuration data to create or modify engineering models and documents. It may update dimensions in a parametric part, suppress or activate components, select standard parts, position assemblies, generate drawings or produce a neutral 3D file.

    Geometric constraints support CAD automation in several ways:

    • they provide limits for input parameters;
    • they determine which component variants can be inserted;
    • they define mating references and assembly positions;
    • they control feature suppression or inclusion;
    • they trigger warnings when a model exceeds validated conditions;
    • they provide calculated dimensions for drawings and documentation.

    For example, a configurable pump skid may use a base frame template with variable length, motor position and pipe connection orientation. The CPQ configuration supplies the selected pump, motor, coupling and connection parameters. The CAD automation process positions the components using defined references, checks known clearances and generates a layout drawing. The resulting geometry should still be reviewed according to the manufacturer’s engineering controls, especially when the configuration is outside the range of tested templates.

    More detail on this relationship is covered in the guide to CAD automation and engineering automation.

    Relationship to product rules and configuration constraints

    Geometric constraints are one category within a broader constraint model. A manufacturing product configurator commonly combines several rule types.

    Rule or constraint type Purpose Industrial example
    Option compatibility Prevents incompatible selections A particular controller is unavailable with an obsolete drive package
    Attribute dependency Sets or limits one value based on another Higher flow requires a larger pipe diameter
    Geometric constraint Controls physical dimensions and relationships The motor and coupling must fit within the base frame
    Engineering calculation Derives a technical result Calculate required motor power from load and speed
    Manufacturing rule Controls production feasibility A sheet-metal bend requires a minimum flange width
    Commercial rule Controls price, cost or approval Non-standard dimensions require an engineering surcharge
    Workflow rule Routes exceptions or approvals Configurations outside a validated envelope require engineering review

    Rules-based configuration often evaluates explicit conditions such as “if option A is selected, require option B.” Constraint-based configuration can represent a larger set of variables and relationships, allowing the system to find or validate solutions subject to limits. Guided selling presents questions in a user-friendly sequence and may conceal technical complexity from the salesperson. These approaches can be combined, but they are not interchangeable.

    See the guide to product configuration, product models and configuration rules for the wider configuration model.

    Practical manufacturing examples

    Configurable industrial pump package

    A pump package may vary by flow rate, pressure, fluid, temperature, motor rating, baseplate, coupling, seal, pipe size and discharge orientation. Geometric constraints can verify that:

    • the selected motor fits the baseplate and aligns with the pump shaft;
    • the coupling guard covers the rotating assembly without interference;
    • the chosen pipe connections are located within the skid envelope;
    • maintenance access remains available around the seal and motor;
    • the frame length supports the selected components;
    • the selected orientation does not conflict with installation access.

    The result may be a validated configuration, a configurable BOM, a price and a CAD layout. A non-standard skid length may be allowed but routed to an engineer rather than rejected automatically.

    HVAC air-handling unit

    An air-handling unit may be configured with fan sections, filters, coils, dampers, access doors and controls. Geometric constraints can govern section order, casing width, service-side access, coil face velocity limits and connection locations. If a customer selects a deep filter bank and a narrow casing, the configuration should identify the conflict before a quote is issued.

    The same parameters can influence pricing, material quantities, shipping dimensions, installation documentation and the generated drawing. The system should distinguish a physical impossibility from a commercial or logistics warning.

    Specialty vehicle body

    A specialty vehicle may combine chassis options, wheelbase, body length, storage modules, lifting equipment and access doors. Constraints may include axle load distribution, body envelope, wheel clearance, door swing and equipment mounting points. A visual configurator can help users understand the result, but visual placement alone does not prove compliance with structural, regulatory or safety requirements.

    Geometric constraints and BOM generation

    A bill of material (BOM) lists the components, assemblies, quantities and sometimes manufacturing information required to build a product. A geometric constraint does not automatically create a BOM, but it can determine which BOM items and variants are valid.

    It is important to distinguish:

    • Configurable BOM: a rules-driven structure containing alternatives, quantities or conditions that are resolved for a particular configuration.
    • Engineering BOM (EBOM): the engineering view of product structure, typically representing design assemblies and components.
    • Manufacturing BOM (MBOM): the manufacturing view, organized for production, work instructions, processes and assembly operations.

    For example, selecting a longer conveyor may require additional frame sections, supports, guards, cable and fasteners. The geometric model may calculate the number and placement of sections, while the product model resolves the correct part numbers. The resulting EBOM may then be transformed or synchronized with an MBOM in a PLM or ERP process.

    More information is available in the guide to BOM generation, costing, pricing and quote automation.

    Geometric constraints in the sales-to-engineering handoff

    The handoff from sales to engineering is a major reason manufacturers implement CPQ. A useful handoff should transfer more than a product name and total price. It should include the selected values, calculated dimensions, constraint results, assumptions, warnings, approvals, revision and generated files.

    A configuration record might contain:

    • product model and version;
    • customer and project identifiers;
    • selected options and parameter values;
    • units and dimensional tolerances;
    • calculated engineering values;
    • validated geometric relationships;
    • unresolved exceptions and engineering notes;
    • component identifiers and quantities;
    • CAD model, drawing or visualization references;
    • price, cost and approval status.

    This information reduces re-entry and makes it easier for engineering to understand what was promised. It does not eliminate the need for engineering review in engineer-to-order (ETO) work. Instead, it separates repeatable, validated configuration from genuinely new design work.

    In configure-to-order (CTO), the product is assembled from a controlled set of pre-engineered options. Geometric constraints can often be evaluated automatically within a defined envelope. In ETO, the constraints may identify a starting point and screen obvious conflicts, while engineers complete detailed design. Make-to-order (MTO) and assemble-to-order (ATO) processes may use similar logic, depending on how much design variation is permitted.

    See manufacturing workflows for CTO, ETO, MTO and ATO for the broader process context.

    Data requirements for implementing geometric constraints

    Successful implementation depends on reliable engineering data. A constraint engine cannot compensate for undefined interfaces, inconsistent units or undocumented design exceptions.

    Product and component data

    Each configurable component should have a stable identifier, revision, dimensions, interface definitions, allowable orientations and applicable operating limits. Standard parts should be separated from engineered variants where possible.

    Reference geometry

    CAD models need consistent reference planes, axes, mounting faces, connection points and coordinate systems. If every model uses different origins or naming conventions, automated assembly placement becomes fragile.

    Units, tolerances and assumptions

    Dimensions should use explicit units and, where necessary, tolerances. A clearance of 5 millimetres may have a different meaning from a nominal dimension of 5 millimetres with an allowable tolerance range. The system should also record assumptions such as standard installation orientation or service-access direction.

    Constraint ownership

    Each rule should have an owner and a review process. Product engineering may own interface constraints, manufacturing engineering may own process limits, commercial teams may own pricing rules and IT may own integration behavior. Shared ownership without clear responsibility leads to conflicting changes.

    Validation strategy and implementation considerations

    Manufacturers should not attempt to encode every engineering decision at once. A staged approach is usually more maintainable.

    1. Document the configuration envelope. Identify the products and variants that can be sold without bespoke design.
    2. List high-value failure modes. Start with errors that cause rework, safety concerns, late engineering intervention or unusable quotes.
    3. Classify constraints. Separate hard prohibitions, soft warnings, calculated values and approval triggers.
    4. Normalize engineering data. Standardize units, identifiers, interfaces, revisions and parameter names.
    5. Build test cases. Include valid boundaries, invalid combinations, unusual but valid configurations and intentionally ambiguous cases.
    6. Connect outputs gradually. Validate the configuration and BOM before automating complex CAD or manufacturing documents.
    7. Establish release governance. A change to a dimension, interface or component revision can affect rules, CAD templates, prices and downstream systems.

    Testing should include boundary values. For example, test a frame at the minimum and maximum validated length, a motor exactly at the allowable clearance and a door at the limit of its motion envelope. Test changes over time as well as individual configurations. A rule that worked for one product revision may become invalid after a component or CAD template changes.

    Integration architecture also matters. ERP, CRM, PLM, PDM, product information management (PIM), MES and CAD systems have different responsibilities. Customer and opportunity information may originate in a CRM system. Product revisions and engineering structures may be controlled in PLM or PDM. Orders, inventory and production planning may be managed in ERP. A CPQ application should not become an uncontrolled duplicate of all these data sources.

    Review the guide to CPQ integrations with ERP, CRM, PLM, PDM and CAD and the guide to CPQ implementation, testing and governance when defining the architecture.

    Limitations and risks

    Geometric constraints improve consistency, but they have important limits.

    • They depend on model quality. Incorrect dimensions, missing interfaces or obsolete CAD references produce incorrect results.
    • They may simplify real-world conditions. Bounding-box checks may not capture flexible hoses, tolerance stack-ups, thermal expansion or installation variability.
    • They can become difficult to maintain. A large network of exceptions and cross-product dependencies may be harder to manage than the original manual process.
    • They do not replace engineering judgment. Structural analysis, regulatory review, safety assessment and detailed tolerance analysis may require specialist tools and human approval.
    • They can create false confidence. A green validation status only means that the encoded checks passed; it does not prove every aspect of product suitability.
    • They may affect response time. Detailed CAD regeneration or collision analysis can be unsuitable for an interactive sales session unless it is optimized or performed asynchronously.
    • They require version control. Rules, product data, CAD templates and component revisions must be coordinated.

    A practical system should communicate the scope of validation. Messages such as “within the standard configurator envelope” or “requires engineering review” are more accurate than an unconditional claim that a product is fully engineered.

    How to evaluate CPQ support for geometric constraints

    When evaluating a CPQ configurator for manufacturing, ask specific questions rather than accepting a general claim about “3D configuration” or “engineering automation.”

    Evaluation area Questions to verify
    Constraint engine Can the system express dimensional, interface, clearance and conditional rules? Can it distinguish errors, warnings and approvals?
    Product model Can engineering teams maintain parameters, dependencies, revisions and reusable component definitions?
    CAD integration Does the platform connect to the required CAD tools or automation services? What outputs are generated and under what conditions?
    Performance Can common checks run interactively, and can complex calculations run asynchronously?
    BOM behavior Can geometric selections resolve component variants, quantities and configurable structures?
    Traceability Are the rule version, input values, validation results and generated files retained with the quote?
    Engineering workflow Can non-standard configurations be routed to engineering with complete context?
    Governance Are there testing, approval, simulation and release controls for changes to rules and models?

    Some platforms provide only guided selling, option compatibility and pricing. Others add product configuration, BOM generation, visualization, engineering calculations or CAD automation. These are separate capability areas and should be verified through demonstrations using representative manufacturing products and edge cases.

    Semantic map

    The following relationships summarize how geometric constraints connect configuration, engineering and manufacturing outputs:

    • CPQ configurator → evaluates → geometric constraints
    • Geometric constraints → validate → dimensions and spatial relationships
    • Configuration rules → prevent → invalid product combinations
    • Product parameters → drive → parametric CAD models
    • CAD automation → generates → product-specific drawings
    • Configured product → resolves → configurable BOM
    • Geometric validation → identifies → clearance and interference risks
    • Interface definitions → control → component compatibility
    • Engineering calculations → determine → derived design values
    • CPQ → exchanges data with → ERP
    • CPQ configuration → supports → sales-to-engineering handoff
    • Engineering exceptions → trigger → approval workflow
    • PLM and PDM → manage → product revisions and engineering data
    • Manufacturing BOM → supports → production planning and assembly
    • Validated configuration → informs → pricing and quote generation

    Frequently asked questions

    What are geometric constraints in product design?

    They are rules that control dimensions, positions, orientations, interfaces, clearances and movement in a product design. In manufacturing CPQ, they help determine whether a selected product configuration is physically feasible.

    Are geometric constraints the same as configuration rules?

    No. Geometric constraints are a specialized type of configuration constraint focused on physical relationships. Configuration rules also include option compatibility, material rules, pricing conditions, manufacturing limits and workflow requirements.

    Why do geometric constraints matter in a CPQ configurator?

    They help prevent quotes for products whose components do not fit, align, move or remain serviceable. This reduces avoidable engineering rework and improves the quality of the sales-to-engineering handoff.

    Can geometric constraints calculate product dimensions?

    Yes. Parametric relationships can calculate dimensions such as frame length, enclosure width or pipe routing allowances. The calculations must be based on validated engineering models and defined limits.

    Can a CPQ system perform CAD interference checking?

    Some manufacturing CPQ architectures support interference checking through native functionality or a connected CAD and engineering service. Others only perform simpler rules-based checks, so this capability must be verified for each platform.

    Do geometric constraints automatically generate CAD drawings?

    No. Constraints can provide inputs to CAD automation, but drawing generation requires a connected CAD system, automation service or platform capability designed for that purpose.

    How do geometric constraints affect a BOM?

    They can determine which component variants, quantities or assemblies are valid for a selected configuration. A separate BOM-generation function is still required to create the resolved engineering or manufacturing structure.

    What is an example of a geometric constraint in a pump configuration?

    A selected motor must fit the baseplate, align with the pump shaft and leave enough space for the coupling guard and maintenance access. If those conditions are not met, the configuration should be rejected or routed for review.

    What is the difference between clearance and interference?

    Clearance is the required separation between objects. Interference occurs when objects occupy the same physical space or violate a required minimum separation.

    How are geometric constraints used in configure-to-order?

    In configure-to-order, they validate combinations within a predefined engineering envelope. This allows standard products to be configured without creating a new design for every order.

    How are they used in engineer-to-order?

    They can screen obvious conflicts, calculate starting dimensions and define an engineering baseline. Configurations outside the validated envelope generally require engineering design and approval.

    What data is required to implement geometric constraints?

    Typical requirements include component dimensions, interface definitions, coordinate systems, allowable orientations, clearance limits, units, tolerances, product revisions and ownership of each rule.

    Should geometric constraints be stored in CAD or CPQ?

    It depends on the rule. Detailed model relationships may belong in CAD, while sales-facing configuration limits and option dependencies may belong in CPQ. Shared rules require controlled synchronization and clear system ownership.

    Can geometric constraints include manufacturing limitations?

    Yes. Examples include minimum bend radii, machining limits, weld access, tool clearance and standard material sizes. These may be implemented as manufacturing rules in addition to geometric checks.

    Do geometric constraints account for tolerances?

    They can, if the model includes tolerance ranges and the validation logic is designed for them. Simple nominal checks may not reveal tolerance stack-up or installation variation.

    Can 3D visualization prove that a configuration is valid?

    No. Visualization helps users understand the selected product and may reveal obvious spatial issues, but it is not a substitute for validated rules, engineering calculations or formal review.

    How should non-standard geometry be handled?

    The system should identify it clearly and route it to an engineering approval process with the selected parameters, constraint results, assumptions and related documents.

    What should manufacturers test before deploying geometric constraints?

    Test valid configurations, invalid combinations, minimum and maximum dimensions, boundary clearances, component revisions, unusual but permitted options and configurations that require engineering approval.

    How do geometric constraints affect pricing?

    They can change the selected components, material quantities, product dimensions, engineering effort, shipping dimensions and approval requirements. Pricing logic should use the validated configuration rather than independently recreating geometry assumptions.

    What is the most common implementation mistake?

    A common mistake is encoding rules before standardizing product data and deciding which system owns dimensions, interfaces, revisions and engineering calculations. Poor source data makes the constraint model difficult to trust and maintain.

    Geometric constraints are therefore a bridge between product configuration and engineering automation. When they are based on controlled product data, tested against real manufacturing cases and connected to the appropriate CAD, BOM and enterprise systems, they can make a CPQ process substantially more reliable. Their value comes not from creating an appearance of automation, but from enforcing the specific engineering relationships that determine whether a configured product can be quoted, designed, built and supported.

  • Engineering Calculations Inside a Product Configurator

    Engineering calculations inside a manufacturing product configurator turn customer requirements into technically valid product definitions. Instead of allowing a salesperson to select isolated options, the configurator can calculate dimensions, capacities, loads, material quantities, motor sizes, electrical ratings or other engineering values and use the results to select compatible components.

    In manufacturing CPQ, CPQ means configure, price, quote. A calculation-enabled CPQ system can connect product configuration rules with engineering formulas, pricing, bills of material (BOMs), computer-aided design (CAD) outputs and downstream enterprise systems. For example, a pump configurator might use flow rate, pressure, fluid properties and operating temperature to recommend a pump size, impeller diameter, motor rating and material combination. The result can then drive a quote, a configurable BOM, a CAD model or an engineering review.

    Not every CPQ platform supports engineering calculations. Some systems provide only guided selling, option rules and pricing. Others include a rules engine, calculation service, CAD automation or integration with external engineering applications. Buyers should therefore verify exactly where calculations run, which variables they support, how results are tested and whether the outputs are suitable for production.

    What are engineering calculations in a product configurator?

    Engineering calculations in a product configurator are formulas, algorithms and decision rules that derive technical product values from customer inputs, selected options, operating conditions and manufacturing constraints.

    These calculations may produce:

    • required dimensions such as length, width, height, diameter or wall thickness;
    • performance values such as flow, pressure, capacity, speed, torque or heat transfer;
    • component selections such as motors, pumps, valves, drives, bearings or structural members;
    • material quantities, weights, surface areas and cutting lengths;
    • electrical values such as voltage, current, breaker size or cable requirements;
    • manufacturing parameters used in a BOM, routing, drawing or CAD model;
    • cost, price, margin or surcharge inputs derived from the technical result.

    The calculation is part of a wider product model. The model defines features, options, parameters, dependencies, constraints, formulas, component relationships and outputs. A calculation should not be treated as an isolated spreadsheet copied into a sales tool. It should be governed as engineering logic with known inputs, units, assumptions, valid ranges, revision control and test cases.

    See the guide to product configuration and configuration rules for the relationship between product models, options, dependencies and validation.

    Why engineering calculations matter in manufacturing CPQ

    Generic sales CPQ often focuses on selecting commercial options, applying discounts and generating a proposal. Manufacturing CPQ may need to establish whether a product can be built and what its technical definition should be before a quote is released.

    Without embedded or connected calculations, the sales process commonly depends on manual engineering work. An application engineer may review a spreadsheet, resize a component, update a drawing, create a BOM and return a price. This can be appropriate for genuinely novel designs, but it creates delays and increases the risk of inconsistent assumptions for repeatable product families.

    A calculation-enabled configurator can automate the repeatable portion of that work. It can reject impossible combinations, recommend a valid design envelope, identify when a standard component is insufficient and route exceptional cases to engineering. The objective is not to remove engineering judgment. It is to apply approved engineering knowledge consistently and reserve expert time for cases that actually require review.

    Manufacturing problem Role of a calculation-enabled configurator
    Sales selects a motor that cannot meet the load Calculates required torque or power and restricts motor choices to valid ranges
    A frame is too small for the specified span Calculates dimensions or structural requirements and identifies a compatible frame family
    Material quantity changes with product dimensions Calculates quantity, weight and cost drivers for the configured design
    Each quote requires a new drawing Passes calculated parameters to CAD automation where supported
    Engineering receives incomplete order information Transfers validated parameters, selections, BOM data and assumptions with the handoff

    How calculations fit into the configurator architecture

    A typical architecture separates the user interface, product model, rules engine, calculation logic, output generation and connected business systems. The exact design varies by platform, but the following flow is common:

    1. Requirement capture: The user enters customer requirements such as capacity, dimensions, environment, voltage, material or duty cycle.
    2. Configuration validation: Rules check required fields, incompatible options, ranges and dependencies.
    3. Calculation: Formulas or engineering services derive technical values from the validated inputs.
    4. Component selection: The system selects or filters compatible components, variants and product families.
    5. Output generation: The configurator produces price, cost, BOM, specifications, drawings, CAD parameters or review data, depending on its capabilities.
    6. System integration: Relevant data is sent to enterprise systems such as customer relationship management (CRM), enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM) or manufacturing execution systems (MES).

    The calculation layer may be embedded in the CPQ platform, implemented as a rules service, connected to an external engineering application or distributed across several systems. The important requirement is a clear source of truth. If a motor-selection formula exists separately in a spreadsheet, CAD macro and ERP customization, the organization must define which result controls the quote and order.

    Inputs, formulas and outputs

    Every calculation should document three basic elements:

    • Inputs: values entered by the user, inherited from the product model, retrieved from a component database or supplied by another system;
    • logic: formulas, lookup tables, constraints, standards, coefficients and exception conditions;
    • outputs: calculated values, selected components, warnings, errors, cost drivers, BOM attributes or engineering deliverables.

    Units and conversions require particular care. A calculation involving pressure, flow, torque or temperature can produce a dangerous result if the system silently mixes units. The data model should store units explicitly, define accepted input units and convert values in a controlled calculation layer.

    Examples of engineering calculations

    Pump and fluid equipment configuration

    A pump configurator may capture required flow rate, differential pressure, fluid temperature, viscosity, corrosion requirements and available electrical supply. It can use these values to calculate a duty point, estimate hydraulic power and filter pump families. Additional rules may select impeller size, motor rating, seal material, casing material and connection type.

    The result is not necessarily a final engineering certification. A configurator may use approved selection curves or lookup tables, while a specialist engineer may still need to verify cavitation margin, transient conditions, applicable standards or unusual fluid behavior. The system should make this boundary visible.

    Industrial machinery and conveyor sizing

    For a conveyor or material-handling machine, inputs may include product weight, throughput, belt speed, incline, conveyor length and operating environment. Calculations can estimate drive power, belt tension, roller spacing, frame dimensions and motor requirements. The outputs can drive a component selection, a configurable BOM and parameters for a 3D model.

    Rules may also identify conditions that require review. For example, a standard frame may be available up to a specified span, while a longer span triggers a reinforced frame, additional supports or an engineer-to-order workflow.

    HVAC and thermal equipment

    An HVAC configurator may calculate heating or cooling capacity from airflow, entering and leaving temperatures, ambient conditions and application requirements. It can use the result to select a coil, fan, heat exchanger, enclosure, motor and control package. Material and environmental inputs may affect corrosion protection, insulation and enclosure ratings.

    These calculations must be based on approved engineering methods and clearly defined assumptions. A simple capacity estimate may support preliminary selection, while final equipment performance may require detailed simulation, certification or a specialist review.

    Electrical equipment

    For an electrical panel or power distribution assembly, the configurator may calculate current demand from selected loads, apply diversity factors, select protective devices and determine enclosure size. It may also validate voltage, phase, short-circuit rating, wiring space and thermal constraints.

    Electrical calculations often involve standards, regional requirements and installation conditions. The configurator should identify the governing standard and revision where relevant, rather than presenting a calculated result without context.

    Specialty vehicles and mobile equipment

    A vehicle configurator may calculate payload, axle loading, center-of-gravity limits, battery capacity, range estimates or hydraulic requirements. A selected body, lift or attachment can change the permissible payload and structural requirements. The system may therefore need sequencing rules: calculate the base vehicle first, apply the attachment, recalculate the combined configuration and then validate the result.

    Rules, constraints and calculations are different

    These concepts work together but should not be treated as interchangeable.

    Concept Purpose Example
    Guided selling Asks questions to recommend a product or option Recommend a pump family based on application type
    Rules-based configuration Defines if-then relationships and allowed choices If the enclosure is outdoor-rated, require a suitable coating
    Constraint-based configuration Finds or validates combinations that satisfy multiple constraints Select a motor and gearbox that meet torque, speed and space limits
    Engineering calculation Derives a value from inputs and formulas Calculate required shaft torque from load and radius
    Pricing logic Converts selections and calculated drivers into cost or price Apply a material surcharge based on calculated weight

    A mature product model may use all five. A guided question captures the application, configuration rules validate selections, calculations derive technical values, constraint logic identifies feasible components and pricing logic converts the result into a commercial offer.

    From calculation to BOM, CAD and quote

    Configurable BOM, EBOM and MBOM

    A bill of material (BOM) lists the components required for a product. A configurable BOM contains conditional or variable items that depend on the selected configuration.

    An engineering BOM (EBOM) represents the product from an engineering and design perspective. A manufacturing BOM (MBOM) represents how the product is assembled and produced, including manufacturing-specific structure, operations or consumables where applicable. A CPQ-generated BOM may be an intermediate or sales-order structure rather than a complete production MBOM.

    For example, a calculated enclosure size may determine the enclosure part number, mounting plate, cable length and hardware quantity. The system should distinguish between a calculated attribute, a sellable item, a manufactured part and a reference value. Sending all of these as undifferentiated lines to an ERP can create planning and costing problems.

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

    CAD and 3D outputs

    Where CAD automation is supported, calculated dimensions and selected components can become parameters for a 2D drawing, 3D model or visualization. A configurator may pass values to parametric CAD, select pre-engineered models or invoke a design automation service.

    The CAD output should have defined status and purpose. A lightweight 3D model for sales visualization is not the same as a manufacturing drawing with tolerances, material specifications and revision control. A generated model may also require engineering approval before release.

    CAD automation is covered in the CAD and engineering automation guide.

    Pricing and quoting

    Technical results often affect commercial results. Calculated weight may affect material cost and freight. Motor size may determine a purchased component cost. A larger frame may trigger labor, tooling or manufacturing surcharges. However, engineering calculations and pricing calculations should remain conceptually separate.

    The calculation layer should produce approved technical drivers, while the pricing engine applies commercial rules such as currency, quantity breaks, discounts, markups and approval thresholds. Separating these concerns makes it easier to change a price policy without changing a safety-critical engineering formula.

    Sales-to-engineering data flow

    The main value of calculation-enabled CPQ is often the quality of the handoff. A completed configuration should communicate more than a product name and total price.

    A useful handoff can include:

    • the customer requirements and original input values;
    • the selected options and calculated parameters;
    • assumptions, units and applicable standards;
    • validation messages, warnings and unresolved exceptions;
    • the selected components and configurable BOM;
    • CAD references or generated files where approved;
    • cost and price inputs without exposing inappropriate commercial data;
    • revision, author, timestamp and product-model version.

    This information may move through an opportunity in a CRM system, an order or item structure in an ERP system, a product record in a PLM or PDM system, or an API between applications. CRM manages customer and sales context; ERP manages transactions, inventory, planning and financial data; PLM manages product lifecycle information; PDM commonly manages engineering files and revisions; CAD creates design representations; MES manages execution on the shop floor. These systems are related but not interchangeable.

    See CPQ integration patterns for guidance on connecting these systems.

    When calculations should trigger review or ETO

    Configure-to-order (CTO) uses predefined options and rules to produce a valid product. Engineer-to-order (ETO) requires engineering work to create or adapt the design. Make-to-order (MTO) means production starts in response to an order, while assemble-to-order (ATO) assembles stocked or predefined modules after the order.

    A calculation-enabled configurator can support CTO and identify the boundary between standard and engineered work. Examples of review triggers include:

    • a calculated value outside the validated range;
    • a component combination not represented in the approved product model;
    • an unusual material, temperature or environmental condition;
    • a load, pressure, voltage or safety value requiring certification;
    • a dimension that cannot be manufactured using standard tooling;
    • a conflict between customer requirements and available capacity;
    • a need for a new CAD design or design revision.

    In these cases, the system should create an explicit engineering task rather than silently accepting an unverified result. The workflow may continue as ETO, or the product team may add the new case to the standard model in a later release. See manufacturing workflows for CTO, ETO, MTO and ATO.

    Implementation approach

    1. Select repeatable calculation candidates

    Start with calculations that are common, well understood and based on stable engineering methods. Do not begin with the most complex bespoke design problem. A good first candidate may be motor sizing, enclosure selection, material quantity or a standard frame calculation.

    2. Define ownership and source data

    Identify who owns formulas, lookup tables, component ratings, material properties and standards. Determine whether product data comes from PLM, PDM, ERP, a component database or the CPQ product model. Avoid copying uncontrolled spreadsheets into production logic.

    3. Model inputs and units explicitly

    Define required, optional and derived values. Record units, valid ranges, precision, default assumptions and allowable conversions. Decide how missing, uncertain or approximate customer inputs are represented.

    4. Separate validation from recommendation

    A recommendation may suggest a motor or product family. Validation must establish whether the resulting configuration is allowed. The user interface should distinguish a recommendation, a warning, a blocking error and an engineering-review condition.

    5. Define output contracts

    Document what the calculation returns and how each result is used. For example, a calculated shaft diameter may be a design attribute, a CAD parameter, a BOM selection criterion and a quote explanation. Each downstream consumer should receive a stable data structure and version.

    6. Test with engineering reference cases

    Test normal, boundary, invalid and exceptional cases. Compare results against approved calculations, engineering software or controlled reference examples. Test unit conversions, rounding, missing values, rule sequencing and changes to component data.

    7. Govern revisions

    A formula change can alter a quote, BOM, drawing or production result. Record effective dates, approvers, model versions and affected products. Decide whether existing quotes and orders retain their original calculation version.

    The CPQ implementation guide provides broader guidance on requirements, testing, deployment, governance and maintenance.

    Limitations and risks

    Engineering calculations do not automatically make a configurator an engineering authority. Important limitations include:

    • Incomplete inputs: Customer requirements may be approximate or misunderstood.
    • Model boundaries: A formula may be valid only within a defined operating range.
    • Data quality: Incorrect component ratings, material properties or revisions produce incorrect results.
    • Standards and certification: A calculated selection may still require formal compliance verification.
    • Complex physical behavior: Simulation, finite element analysis or specialist analysis may be necessary for novel designs.
    • Integration failures: A stale or partial transfer to ERP, PLM, CAD or MES can break the handoff.
    • Maintenance burden: Product changes, supplier substitutions and manufacturing changes require model updates.
    • False confidence: A precise-looking number is not reliable if assumptions and uncertainty are hidden.

    The configurator should expose assumptions and route cases outside its validated domain to qualified engineers. It should not present an automated estimate as a certified design unless the organization has established that approval process.

    How to evaluate a CPQ configurator for engineering calculations

    During vendor evaluation, ask practical questions rather than relying on a general claim that the platform supports engineering. Verify whether it can:

    • represent variables, formulas, lookup tables and conditional logic;
    • handle units, ranges, precision and rounding;
    • sequence calculations when one result becomes another input;
    • separate warnings, blocking errors and review conditions;
    • version formulas and product models;
    • expose calculations through an application programming interface (API);
    • generate or exchange configurable BOM data;
    • pass parameters to CAD or design automation tools;
    • retain calculation inputs and outputs with the quote or order;
    • support testing, audit trails, approvals and rollback;
    • integrate with ERP, PLM, PDM, CRM and other relevant systems;
    • support both standard CTO products and exceptions requiring ETO.

    Require a demonstration using a representative product family, such as a pump, machine frame, electrical enclosure or configured vehicle. Ask the vendor to show the underlying model, not only the final screen. Confirm which capabilities are native, which require customization and which depend on third-party engineering or CAD software.

    Semantic map

    The article connects engineering calculations with product configuration, rules, CAD automation, BOM generation, pricing, enterprise integration and manufacturing workflows. The main relationships are:

    • Customer requirements feed configuration inputs.
    • Configuration rules prevent invalid combinations.
    • Engineering calculations derive technical values.
    • Calculated values influence component selection and BOM structure.
    • CAD automation can use calculated parameters to generate models and drawings.
    • Technical results provide controlled inputs to costing and pricing.
    • Validated configurations improve the sales-to-engineering handoff.
    • Out-of-range results trigger engineering review or ETO.
    • ERP, PLM, PDM, CRM, CAD and MES consume different parts of the configured product data.

    Frequently asked questions

    What are engineering calculations in CPQ?

    They are formulas, lookup tables and algorithms that derive technical values or component selections from customer requirements and configuration inputs. In manufacturing CPQ, they can support sizing, validation, BOM generation, CAD parameters and pricing inputs.

    Does every CPQ system support engineering calculations?

    No. Some CPQ systems focus on guided selling, option rules, pricing and quoting. Calculation, CAD automation and engineering integration may require a specialized manufacturing platform, customization or an external engineering service.

    What is an example of a product configurator calculation?

    A pump configurator can calculate required hydraulic power from flow and pressure, then use that result to select a pump family, impeller, motor and material combination.

    How are calculations different from configuration rules?

    A rule validates or controls a relationship, such as requiring an outdoor-rated enclosure with a suitable coating. A calculation derives a value, such as enclosure size or motor power, from one or more inputs.

    Can a configurator calculate motor size?

    It can when the product model contains an approved motor-sizing method and the required inputs, such as load, speed, torque, duty cycle and operating conditions. The result may still require engineering review outside the validated range.

    Can engineering calculations generate a BOM?

    They can contribute to BOM generation by determining dimensions, quantities, variants and component selections. Whether the platform creates a production-ready BOM depends on its native capabilities and integration with ERP, PLM or manufacturing systems.

    What is the difference between a configurable BOM and an EBOM?

    A configurable BOM contains conditional items that vary with the selected product. An EBOM represents the engineering product structure. A CPQ output may support an EBOM but should not automatically be treated as a complete manufacturing BOM.

    Can calculated values drive CAD automation?

    Yes, where the CPQ and CAD architecture supports it. Calculated dimensions, selected components and parameters can be passed to parametric CAD or design automation tools to create product-specific models and drawings.

    Are CPQ calculations suitable for safety-critical products?

    They may support preliminary selection or controlled standard designs, but safety-critical use requires defined engineering ownership, validation, standards compliance, testing and approval. Automation should not bypass required professional review.

    What happens when a calculation produces an invalid result?

    The system should show a blocking error, warning or engineering-review condition according to the severity. It should not silently create a quote or order from an unverified design.

    How should units be handled in a configurator?

    Units should be explicit in the data model, with controlled input units and documented conversion rules. This is essential for pressure, flow, temperature, torque, dimensions, mass and electrical values.

    Can calculations affect product pricing?

    Yes. Calculated weight, material quantity, motor size, labor content or manufacturing complexity can provide inputs to costing and pricing. The technical calculation and commercial pricing logic should remain separately governed.

    How do calculations support configure-to-order?

    They help validate predefined product families and derive the correct standard components for a customer-specific configuration. Cases outside the approved design envelope should be routed to engineering-to-order.

    What systems exchange data with a calculation-enabled CPQ platform?

    Depending on the architecture, it may exchange data with CRM for sales context, ERP for orders and materials, PLM or PDM for product data, CAD for design outputs and MES for manufacturing execution. These systems have different responsibilities.

    Should calculations be stored in spreadsheets?

    Spreadsheets can support analysis and prototyping, but uncontrolled spreadsheet logic is risky as a production source of truth. Approved formulas should be governed, versioned, tested and exposed through the product model or a controlled calculation service.

    How should engineering calculations be tested?

    Use approved reference cases covering normal, boundary, invalid and exceptional conditions. Test units, rounding, rule sequencing, component revisions, missing inputs and integration outputs.

    What should a vendor demonstration include?

    Ask the vendor to configure a representative machine or equipment family, enter real engineering inputs, show calculations and validation, generate the relevant BOM or CAD output and demonstrate the engineering-review path.

  • Design Automation in Manufacturing CPQ

    Design automation in manufacturing CPQ is the use of product rules, engineering calculations and computer-aided design (CAD) automation to turn a valid customer configuration into product-specific engineering outputs. Depending on the platform and implementation, those outputs may include a three-dimensional model, two-dimensional drawings, design parameters, an engineering bill of materials (EBOM), a manufacturing bill of materials (MBOM), manufacturing instructions or data for enterprise systems.

    This is a major distinction between manufacturing CPQ and generic sales CPQ. A sales-oriented CPQ system may select options, calculate a price and generate a proposal. A manufacturing CPQ system can also determine whether the product can be built, calculate technical dimensions, select components, create a product structure and pass controlled data to engineering and production.

    For example, a pump manufacturer might use CPQ to capture flow rate, pressure, fluid type, temperature, motor voltage, materials and connection standards. Design automation can then apply selection rules, size the pump assembly, choose compatible components, generate a product-specific CAD configuration and produce a BOM for review or production. The result is a shorter and more reliable sales-to-engineering handoff, provided that the product model, engineering logic and CAD templates are maintained correctly.

    For broader context, see the guide to CPQ software for manufacturing and the detailed overview of CAD and engineering automation.

    What design automation means in manufacturing CPQ

    Design automation is the controlled generation or modification of engineering outputs from structured inputs. In a manufacturing CPQ process, the inputs usually include customer requirements, selected options, dimensions, operating conditions, material choices and commercial decisions. The automation layer evaluates those inputs and produces outputs that would otherwise require manual engineering work.

    Design automation does not necessarily mean that every product is designed from scratch. Most successful implementations use a reusable engineering model containing standard components, parameterized CAD templates, rules, calculations and approved variants. The system assembles or modifies those assets according to the selected configuration.

    Input Typical example Possible automated output
    Customer requirement Required airflow, lifting capacity or fluid pressure Validated technical range and selected product family
    Configuration option Motor type, enclosure, material or mounting arrangement Compatible components and product variant
    Calculated parameter Shaft diameter, vessel volume or heat-transfer area Engineering dimension or component selection
    Geometric parameter Length, width, hole spacing or frame height Updated CAD model and drawing dimensions
    Approved configuration Complete machine or assembly definition EBOM, quote, drawing package or ERP order data

    How design automation fits into the manufacturing CPQ architecture

    Design automation is usually one part of a larger CPQ architecture. It depends on a product model and configuration engine, but it also interacts with CAD, product lifecycle management (PLM), product data management (PDM), enterprise resource planning (ERP) and sometimes manufacturing execution systems (MES).

    1. Product model and configuration interface

    The product model defines the configurable structure of the product. It may contain families, features, options, dimensions, materials, accessories and component relationships. The configuration interface presents the relevant choices to a sales engineer, dealer, distributor or customer.

    A product model is not the same as a price list. It must represent technical relationships. For instance, a stainless-steel pump casing may be available only for certain fluid types and pressure classes. A high-voltage motor may require a particular control panel, cable specification and enclosure. These dependencies belong in the configuration model or in connected engineering logic.

    See product configuration, rules and constraint management for a deeper explanation of product models and validation.

    2. Rules and constraints engine

    The rules engine evaluates whether a proposed configuration is valid. Rules can include compatibility rules, exclusion rules, dependency rules, range limits, required selections and conditional defaults.

    • A 50 Hz motor may be required for a particular regional electrical standard.
    • A selected impeller diameter may require a larger casing or a different shaft.
    • A vehicle body length may restrict the available axle or suspension package.
    • A pressure rating may require a different valve body material and test procedure.
    • A lifting capacity above a defined threshold may require a larger frame and reinforced weldment.

    Rules-based configuration evaluates explicit product logic. Constraint-based configuration solves or validates relationships among variables and limits, such as dimensions, load, temperature, pressure or capacity. Guided selling is different: it recommends products or options based on customer needs, but it does not by itself prove that the resulting design is manufacturable.

    3. Engineering calculation service

    Engineering calculations convert requirements into technical values. Examples include pump selection, motor sizing, heat exchanger sizing, pressure-vessel calculations, structural checks, cable sizing and throughput calculations.

    Calculations may be implemented inside the CPQ platform, exposed through an engineering service, or connected to specialist calculation software. The important requirement is traceability. The organization should know which inputs were used, which calculation version was applied and whether the result was within the approved design envelope.

    4. CAD and visualization layer

    CAD automation uses configuration values to create or modify a parametric model. A parametric model is controlled by dimensions, features and relationships rather than being a collection of unrelated manually edited geometry.

    The output may be a three-dimensional model for review, a simplified model for a web configurator, a detailed model for engineering, or two-dimensional drawings with product-specific dimensions and annotations. Some implementations generate only visual representations, while others create native CAD files. These are materially different capabilities and should be verified during software evaluation.

    5. BOM and manufacturing data generation

    A configured product can generate a structured bill of materials (BOM), but the structure and purpose of the BOM must be defined. An EBOM is an engineering bill of materials that describes the designed product. An MBOM is a manufacturing bill of materials that reflects how the product is assembled and produced. A configurable BOM may contain rules, placeholders or selectable component relationships rather than one fixed list.

    Design automation may generate or update an EBOM directly. In other architectures, the CPQ system sends configuration data to PLM or ERP, where the approved EBOM or MBOM is created. The system of record should be explicit; otherwise, different departments may maintain conflicting product structures.

    The related guide to BOM generation, pricing and quoting explains how engineering structures connect to commercial and manufacturing outputs.

    Typical design automation workflow

    1. Capture requirements. A sales engineer or customer enters application, performance, dimensional and commercial requirements.
    2. Validate the product family. The CPQ model determines which product family and configuration path can satisfy the requirements.
    3. Apply configuration rules. The rules engine rejects incompatible choices, adds required components and identifies unresolved decisions.
    4. Run engineering calculations. The system calculates dimensions, capacities, ratings or other technical values within approved limits.
    5. Select or derive components. Standard parts, configurable components and engineered elements are assigned to the product structure.
    6. Generate engineering outputs. CAD models, drawings, specifications or visualization files are created or updated.
    7. Generate commercial outputs. Cost, price, lead time and proposal content are calculated from the validated configuration.
    8. Route exceptions. Configurations outside the standard design envelope are sent to an engineer for review rather than being silently accepted.
    9. Transfer controlled data. The approved configuration and relevant outputs are sent to CRM, ERP, PLM, PDM or MES according to the process design.
    10. Release and maintain. The configuration, rules, CAD references and related revisions are recorded for later order processing and support.

    Example: automated design of an industrial pump package

    Consider a manufacturer selling centrifugal pump packages for industrial water systems. The customer specifies flow, head, fluid temperature, material preference, motor voltage, connection standard, mounting arrangement and environmental conditions.

    The CPQ product model first checks whether the application falls within the supported product family. The rules engine may restrict materials based on temperature and fluid chemistry. An engineering calculation selects a suitable impeller diameter and motor rating. Additional rules determine whether a baseplate, coupling guard, seal package or control panel is required.

    Once the configuration is valid, a CAD template can update the pump skid length, nozzle position, motor footprint and baseplate hole pattern. A product-specific drawing may show the revised dimensions. The EBOM can include the pump, motor, coupling, guard, valves, instrumentation and fabricated base. A manufacturing process may transform that structure into an MBOM with fabrication, assembly and testing steps.

    Pricing is calculated separately but uses the same configuration facts. Material choices affect cost, while motor rating and accessories affect both cost and lead time. The proposal can include technical specifications and an image derived from the configured model. If the customer requests a flow and head combination outside the approved envelope, the system should create an engineering review rather than generate a falsely precise design.

    Design automation and the sales-to-engineering handoff

    Without automation, sales may send an email, spreadsheet or partially completed form to engineering. Engineers then interpret requirements, check compatibility, rebuild the product definition and prepare drawings or BOM data. This creates delays and introduces ambiguity about which revision, option or calculation was used.

    A manufacturing CPQ process can make the handoff structured. The sales record contains the validated configuration, calculated values, selected options, customer requirements, assumptions, exceptions and revision information. Engineering receives a defined starting point rather than a narrative request.

    This does not eliminate engineering involvement. Engineers still govern the design envelope, approve new rules, handle non-standard requests, review safety-critical applications and release controlled revisions. The goal is to move repeatable decisions into a governed model and reserve expert time for genuine engineering work.

    Design automation should therefore be evaluated together with configure-to-order, engineer-to-order and sales-to-engineering workflows.

    Relationship between CPQ, CAD, PLM, PDM and ERP

    System Primary responsibility Typical relationship with manufacturing CPQ
    CPQ Configuration, commercial logic and quote process Captures requirements, validates choices and coordinates outputs
    CAD Geometric product design Receives parameters or configuration selections and produces models or drawings
    PDM Control of CAD files, documents and revisions Stores or manages generated design files and their relationships
    PLM Product lifecycle, revisions, approvals and product structures Governs engineering data, EBOMs and release processes
    ERP Enterprise transactions, inventory, purchasing and production planning Receives order, item, BOM, price or production data
    MES Execution and tracking of manufacturing operations May receive production structures, routings or work instructions
    CRM Customer, opportunity and account management Provides the commercial context for the configuration and quote

    These systems are not interchangeable. A CPQ platform may calculate a configuration without owning the CAD file, and a CAD system may generate geometry without managing pricing or customer approvals. The integration architecture should define which system owns each object and how revisions are synchronized.

    See CPQ integrations with ERP, CRM, PLM, PDM and CAD for integration patterns and design considerations.

    Benefits of design automation in manufacturing CPQ

    • Faster engineering response: repeatable calculations and standard design variants can be produced without rebuilding them manually.
    • Fewer configuration errors: rules prevent or flag combinations that are technically incompatible.
    • More consistent quotes: technical assumptions, options, costs and lead times are based on the same configuration.
    • Better customer visualization: a configured three-dimensional image or drawing can make dimensions and options easier to review.
    • Improved data quality: structured configuration data is more useful than free-text descriptions in emails and quote notes.
    • Reduced duplicate entry: the same validated values can support the proposal, CAD output, BOM and order record.
    • Scalable expert knowledge: approved engineering logic can be used by trained sales engineers and dealers within defined limits.
    • Clearer exception management: non-standard designs can be identified and routed to engineering instead of being hidden in the order process.

    Limitations and risks

    Design automation is not a shortcut around product engineering. It exposes the quality of the underlying product knowledge. If rules are incomplete, the system can produce fast but invalid results. If CAD templates are poorly structured, automated outputs may require extensive manual repair.

    Common limitations

    • Incomplete design envelope: calculations may cover standard applications but not unusual loads, environments or regulatory requirements.
    • Complex legacy CAD: older models often contain fragile references, inconsistent naming and undocumented dependencies.
    • ETO variability: engineer-to-order products may include genuinely new design work that cannot be reduced to option selection.
    • Data ownership conflicts: CPQ, ERP, PLM and CAD teams may disagree about the authoritative item, revision or BOM.
    • Change management: a change to a component, rule or calculation can affect quotes, drawings, inventory and active orders.
    • Performance constraints: native CAD generation can be slower and more resource-intensive than generating a lightweight visual model.
    • Regulatory requirements: automated design outputs may still require documented checks, signatures or approval by qualified personnel.
    • False automation expectations: a platform may support configurable BOMs or visual models without supporting native CAD generation or engineering calculations.

    Vendor claims should therefore be tested with representative product data. Buyers should ask whether the capability is native, delivered through an integration, dependent on custom development or limited to a demonstration scenario.

    Implementation considerations

    Start with a bounded product family

    Choose a product family with meaningful configuration volume, repeated engineering decisions and a reasonably stable design. A standard pump, modular conveyor, electrical enclosure or vehicle body may be a better starting point than a product with extensive one-off engineering.

    Document the design envelope

    Record supported ranges, exclusions, calculation assumptions, material limits, regulatory conditions and escalation triggers. Engineers should define when the CPQ workflow can approve a design automatically and when human review is mandatory.

    Separate rules from presentation

    The configuration interface should not be the only location where product logic exists. Rules, calculations and option definitions should be structured, versioned and testable. This makes it easier to reuse the same logic across internal sales, dealer portals and customer-facing configuration.

    Prepare CAD templates deliberately

    Parameterize stable dimensions and use controlled references. Define naming conventions for parameters, components, configurations and output files. Decide whether the process needs native CAD, neutral formats such as STEP, PDF drawings, lightweight web visualization or a combination of these outputs.

    Define BOM ownership

    Decide whether CPQ creates a quote-level configurable BOM, whether PLM creates the released EBOM, and how ERP receives an MBOM or order-specific structure. Do not assume that one BOM representation can satisfy sales, engineering and production equally.

    Build testing around real scenarios

    Test valid configurations, invalid combinations, boundary values, revision changes, missing inputs, calculation failures, CAD regeneration and integration errors. Include regression tests so a rule change does not silently invalidate previously approved products.

    Govern releases and maintenance

    Assign ownership for product options, rules, calculations, CAD templates, prices and integration mappings. Establish an approval process for changes and retain the revision used for each quote or order. These governance practices are covered in the manufacturing CPQ implementation guide.

    How to evaluate design automation capabilities

    Evaluation area Questions to ask
    Configuration depth Can the system model nested assemblies, dimensions, dependencies, exclusions and conditional components?
    Engineering calculations Can calculations use formulas, external services, lookup tables and versioned assumptions?
    CAD automation Does it generate native CAD, neutral geometry, drawings, lightweight visualization or only images?
    BOM handling Can it create configurable BOMs, EBOMs or MBOM-related data, and where is the system of record?
    Exception workflow Can non-standard configurations be routed to engineers with complete context and audit history?
    Integration Are ERP, PLM, PDM, CRM and CAD connections standard, API-based or custom?
    Governance Can product rules, templates, calculations and revisions be tested and approved?
    Operational scale Can the architecture handle large product models, dealer users, concurrent calculations and document generation?

    When design automation is appropriate

    Design automation is most suitable where products contain repeatable engineering patterns, defined parameter ranges and a meaningful volume of similar configurations. It is especially useful for modular machinery, pump and valve packages, HVAC units, electrical equipment, material-handling systems, specialty vehicles and configurable assemblies.

    It is less suitable as a fully automated process when every order requires novel research, unbounded geometry, extensive simulation or a new regulatory interpretation. In those cases, CPQ can still capture requirements, calculate commercial values, guide standard selections and create an engineering request, while the final design remains an ETO activity.

    The practical objective is not to automate every engineering task. It is to automate the stable and repeatable decisions while preserving controlled engineering judgment where risk or novelty requires it.

    Semantic map

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

    • Manufacturing CPQ connects customer requirements to validated product configurations.
    • Configuration rules prevent invalid combinations of options, dimensions and components.
    • Engineering calculations convert application requirements into technical parameters.
    • CAD automation uses technical parameters to generate product-specific models and drawings.
    • A configured product can generate or inform an EBOM.
    • PLM governs engineering revisions and released product structures.
    • ERP uses approved order, item, BOM and commercial data for enterprise execution.
    • Exception workflows connect non-standard configurations to engineering review.
    • Design automation reduces manual sales-to-engineering data re-entry.
    • Product model governance controls changes to rules, calculations, templates and revisions.

    Frequently asked questions

    What is design automation in manufacturing CPQ?

    It is the automated generation or modification of engineering outputs from a validated product configuration. Outputs may include calculations, CAD models, drawings, specifications and BOM-related data.

    How is design automation different from generic CPQ?

    Generic CPQ commonly focuses on selecting products, calculating prices and producing quotes. Manufacturing design automation adds engineering logic and may create CAD, BOM or production-related outputs.

    Does every manufacturing CPQ platform generate CAD files?

    No. Some platforms generate visualizations or pass parameters to a CAD system, while others support native CAD automation. This capability must be verified for the specific CAD tools and file types required.

    Can CPQ automatically create an engineering bill of materials?

    Some systems can create a configurable or order-specific BOM, but the exact behavior varies. The implementation must define whether CPQ, PLM or ERP owns the released EBOM.

    What is the difference between an EBOM and an MBOM?

    An EBOM represents the product as designed by engineering. An MBOM represents how the product is assembled or manufactured. They may contain different structures, quantities, operations or production groupings.

    Can design automation support engineer-to-order products?

    It can support parts of an engineer-to-order process, such as requirement capture, standard component selection and preliminary calculations. Novel designs normally still require engineering review and manual development.

    What information is needed for CAD automation?

    Typical inputs include configuration selections, dimensions, component identifiers, material choices, parameter mappings, CAD templates and rules governing valid geometry.

    What role does the rules engine play?

    It validates selections, enforces dependencies, applies defaults, restricts ranges and identifies conditions that require engineering review.

    Is guided selling the same as engineering configuration?

    No. Guided selling recommends products or options based on customer needs. Engineering configuration validates technical compatibility and may calculate or generate a product design.

    How does design automation affect pricing?

    The configuration and calculated technical values can provide inputs to costing and pricing. Design automation does not replace the pricing engine; it supplies more accurate product facts for commercial calculations.

    Can a configured 3D model be used for manufacturing?

    Sometimes, but not automatically in every implementation. A visual model may be suitable for customer review, while manufacturing may require controlled native CAD, drawings, tolerances and released product data.

    How does design automation improve the sales-to-engineering handoff?

    It transfers structured requirements, validated selections, calculations and exceptions instead of relying on free-text emails or manually re-entered spreadsheets.

    What happens when a customer requests a non-standard design?

    The CPQ process should identify the request as outside the approved design envelope and route it to engineering with the captured requirements and proposed configuration.

    Which systems commonly integrate with design automation?

    Depending on the architecture, integrations may include CAD, PDM, PLM, ERP, CRM, MES and document-generation services. A CPQ product does not necessarily support all of these natively.

    How should manufacturers test automated designs?

    They should test valid and invalid configurations, boundary values, calculation results, CAD regeneration, BOM accuracy, revision changes, integration failures and exception routing using representative products.

    What is the biggest implementation risk?

    The biggest risk is automating incomplete or poorly governed product knowledge. Fast output is not useful if the rules, calculations, CAD templates or BOM mappings are inaccurate.

    Should CPQ replace engineering approval?

    No. CPQ can automate repeatable decisions within an approved design envelope, but qualified engineers should retain responsibility for exceptions, safety-critical decisions and controlled product releases.

  • Augmented Reality in Manufacturing CPQ: Engineering, CAD and Configuration Workflows

    Augmented reality in manufacturing CPQ combines augmented reality (AR) with configure, price, quote (CPQ) processes so users can review a configured product in a real or simulated environment before it is quoted, engineered or manufactured. A CPQ system may use the selected options, dimensions, materials, accessories and engineering outputs to display a product-specific 3D model, identify components, show clearances or guide an assembly review.

    In manufacturing, AR is not simply a visual sales feature. Its value depends on whether the AR experience is connected to a governed product model and reliable engineering data. When connected correctly, a configuration can produce a validated visual representation, a bill of materials (BOM), pricing, drawings and downstream manufacturing information. When it is not connected, AR may show an attractive but generic model that does not represent the product being quoted.

    This guide explains where AR fits in a manufacturing CPQ architecture, how data moves between configuration and engineering systems, which use cases are practical, and what manufacturers should verify before implementation.

    What is augmented reality in manufacturing CPQ?

    Augmented reality in manufacturing CPQ is the use of digital overlays, 3D models and contextual product information to present a configured industrial product in the user’s physical environment or field of view.

    For example, a sales engineer configuring a pump skid could use AR to place the selected skid in a plant area. The visualization might show the chosen pump, motor, frame, pipe connections and control enclosure. It could also display approximate footprint, service access zones and connection locations. The underlying CPQ configuration should determine which model variants and dimensions appear.

    AR is therefore an interaction and visualization layer around CPQ data. It does not replace:

    • Product configuration, which selects valid options and applies dependencies and constraints;
    • Engineering calculation, which determines whether the selected product meets duty, load, capacity or dimensional requirements;
    • CAD, or computer-aided design, which represents product geometry and can produce drawings or design outputs;
    • BOM generation, which identifies components required for a configured product;
    • Pricing and costing, which calculate commercial values; or
    • Enterprise integration, which transfers approved information to systems such as enterprise resource planning (ERP), product lifecycle management (PLM) or customer relationship management (CRM).

    A manufacturing CPQ platform may support some of these functions directly, integrate with specialist systems, or provide only the configuration and quotation layer. Buyers should verify the documented scope of each product rather than assuming that a CPQ system includes native AR, CAD automation or engineering automation.

    How AR fits into a manufacturing CPQ architecture

    A typical architecture contains several connected layers. The product model defines what can be configured. The rules engine validates selections. Engineering services calculate dimensions or performance. CAD and visualization services produce geometry. The AR application displays the resulting model on a device. Commercial and enterprise systems manage pricing, quotes, orders and production data.

    Layer Typical responsibility AR relationship
    Product model Defines options, features, attributes, variants and component relationships. Determines which product components and visual assets may be displayed.
    Rules and constraints Prevents incompatible combinations and validates technical conditions. Prevents the AR view from representing an invalid configuration.
    Engineering logic Calculates capacity, dimensions, performance, loads, clearances or selections. Supplies configuration-specific values and geometry parameters.
    CAD and 3D services Generate or retrieve parametric models, assemblies, drawings and lightweight visualization files. Provide the three-dimensional assets rendered by the AR experience.
    CPQ commercial layer Calculates cost, price, discounts, lead time and quote content. Associates the displayed configuration with a quote or opportunity.
    ERP, PLM, PDM and MES Manage enterprise, lifecycle, design, production and execution data. Supply approved revisions, item identifiers and manufacturing context where required.

    A product data management (PDM) system manages design files and revisions, while PLM manages product lifecycle information, structures, changes and governance. A manufacturing execution system (MES) manages production execution. These systems are related but not interchangeable. An AR application should use approved and traceable data, especially when the visual output is used for engineering review or production support.

    Data flow from configuration to AR

    The exact implementation varies, but a common flow is:

    1. Start with requirements. A user enters application data such as flow rate, pressure, voltage, payload, dimensions, environment or vehicle use case.
    2. Apply configuration rules. The CPQ product model enables valid options and rejects incompatible selections. For example, a motor voltage may be restricted by the selected electrical standard, and a frame size may depend on pump capacity.
    3. Run engineering calculations. A calculation service may determine shaft size, heat exchanger area, structural dimensions, cable length or required safety factors.
    4. Resolve product identity. The system identifies selected components, part numbers, variants and revision-controlled assemblies.
    5. Generate or retrieve 3D data. The solution obtains a lightweight model, a parametric CAD output or a prebuilt 3D asset that matches the configuration.
    6. Apply metadata. Components can be associated with labels, service zones, technical attributes, item numbers, cost information or installation instructions.
    7. Render the AR experience. The user places, rotates, measures or inspects the configured product using a supported device.
    8. Return decisions to CPQ. The user may confirm the configuration, request a change, attach an image to the opportunity or send the result for engineering review.

    The most important control point is the relationship between the product configuration and the 3D output. A model generated from different rules, an old CAD revision or a generic product family may create false confidence. The system should record the configuration version, CAD revision and relevant calculation results where the AR output influences a quote or design decision.

    Manufacturing use cases for AR-enabled CPQ

    Industrial machinery and equipment

    Manufacturers of machinery can use AR to show how a configured machine fits into a customer’s facility. A configured conveyor, packaging machine or material-handling system may include different lengths, guards, drives, access doors and discharge directions. An AR view can help the customer review footprint, operator access and interfaces before quotation approval.

    Pumps, valves and process skids

    For pumps and valves, AR can display selected connection sizes, orientation, actuator position, motor arrangement and service access. In a skid configuration, the visual output can help reveal clashes with adjacent equipment. It should not be treated as a substitute for a certified layout or piping design unless the underlying geometry and engineering process support that use.

    HVAC and electrical equipment

    An HVAC CPQ workflow may use AR to show an air-handling unit, duct connections, service panels and clearance zones in a building area. An electrical equipment configuration may display enclosure dimensions, cable entry locations, busbar sections and selected accessories. Rules still need to validate ratings, environmental requirements and applicable product constraints.

    Specialty vehicles and mobile equipment

    Vehicle and mobile-equipment manufacturers can display a configured body, cab, tank, boom, tool carrier or accessory package. The visualization may support customer review of reach, access and interference. Engineering validation remains necessary for axle loads, structural limits, legal requirements, stability and production feasibility.

    Sales-to-engineering handoff

    AR can make handoff discussions more concrete. A sales engineer can mark a customer concern on the configured model and transfer the same configuration identifier, selected options, dimensions and attachments to engineering. This is more useful than sending an unstructured screenshot, provided the receiving team can trace the visual output back to the controlled product model.

    Installation, service and production support

    After the sale, the same product-specific data may support installation or service guidance. A technician could identify components, access panels or connection points using an approved model. However, this requires revision control and a clear distinction between a sales visualization and an authoritative service or work instruction.

    AR compared with 3D product configuration and CAD automation

    These capabilities overlap but solve different problems.

    Capability Primary purpose Typical output
    3D product configuration Lets users inspect and manipulate a digital representation of a product. Browser-based model, option visualization or interactive assembly.
    CAD automation Creates or modifies engineering geometry from parameters and rules. Parametric CAD file, drawing, assembly or manufacturing geometry.
    Augmented reality Places digital content in a physical context or user field of view. Device-based overlay, spatial review or guided visualization.
    Virtual reality Places the user in a fully digital environment. Immersive simulated facility or product review.

    A CPQ system may offer browser-based 3D without AR, or it may integrate with a separate visualization and AR platform. CAD automation may produce a precise engineering model while AR uses a simplified model for performance. The simplified model must still preserve the dimensions, interfaces and components relevant to the intended decision.

    Benefits for engineering-driven manufacturers

    • Earlier spatial validation: Customers and sales engineers can identify footprint, access and interface problems before order release.
    • Clearer technical communication: A configured assembly can be easier to review than a text description or generic catalogue image.
    • More useful sales-to-engineering handoff: The same configuration identifier and visual context can accompany the request for engineering review.
    • Reduced ambiguity in options: Users can see the practical difference between accessories, orientations, enclosures and connection arrangements.
    • Support for complex products: AR is particularly useful when the product contains many physical options whose effects are difficult to communicate in a quote.
    • Potential reuse of engineering assets: Approved 3D models and metadata may support sales, installation, service and training, subject to governance.

    These benefits depend on data quality. AR cannot correct an incomplete product model, missing constraints, inaccurate CAD geometry or an uncontrolled engineering process.

    Limitations and implementation risks

    Visual accuracy is not engineering validation

    A model can look correct while failing a load, pressure, thermal, electrical or regulatory requirement. CPQ rules and engineering calculations must remain authoritative for those decisions.

    Model preparation can be expensive

    Detailed CAD assemblies may be too large for real-time AR. Manufacturers may need simplified meshes, material definitions, texture optimization, coordinate systems and separate visual variants. This creates another data-maintenance task.

    Configuration and CAD may not align

    A CPQ option may not map cleanly to a CAD feature. Some options change geometry, while others change only metadata, hardware, purchasing items or manufacturing operations. The implementation must define what appears visually and what is represented only in the BOM.

    Revision and lifecycle control are essential

    AR content associated with an obsolete CAD revision can mislead users. The system should define approval states, effective dates, ownership and traceability between product rules, CAD files, visual assets and production structures.

    Devices and operating conditions affect usability

    Lighting, network availability, tracking quality, screen size, protective equipment and factory conditions can affect the experience. A browser or tablet workflow may be more practical than specialized headsets for some sales and engineering teams.

    AR may not be appropriate for every product

    For a small configurable component, a 2D drawing or standard 3D viewer may provide sufficient value. AR is most justified when physical context, spatial relationships or customer understanding materially affect configuration and approval.

    Implementation approach

    1. Select a specific decision to improve. Start with a use case such as equipment footprint review, accessory selection or plant interface validation rather than an open-ended AR project.
    2. Map the authoritative data. Identify which system owns product options, rules, CAD revisions, item numbers, BOM structures, calculations and customer requirements.
    3. Define configuration-to-geometry mappings. Document how each relevant option changes the model, metadata, assembly structure or no visual output at all.
    4. Choose the required fidelity. Decide whether users need a conceptual model, dimensionally reliable layout, engineering CAD output or a service-grade representation.
    5. Design identifiers and traceability. Link the AR session to a configuration ID, quote revision, product revision and, where appropriate, CAD or PLM revision.
    6. Test rule and visual consistency. Test valid and invalid combinations, boundary dimensions, substitutions, obsolete parts and engineering overrides.
    7. Integrate with the sales and engineering workflow. Define how users request review, capture customer approval, transfer comments and update the quote.
    8. Govern changes after launch. Assign ownership for product rules, CAD assets, visual content, device support and release testing.

    Manufacturers should document requirements, integration boundaries and acceptance tests as part of the wider CPQ implementation process. The product model and rule governance should be designed alongside the AR experience, not after it.

    Questions to ask when evaluating AR and CPQ software

    • Does the platform provide native AR, browser-based 3D, or an integration framework?
    • Can the AR model be generated from the exact configured options and dimensions?
    • How are CAD files simplified, versioned and approved?
    • Can visual components be linked to part numbers, BOM items and engineering attributes?
    • Does the solution support parametric geometry, prebuilt variants or both?
    • How are configuration rules shared between CPQ and CAD automation?
    • Can the system distinguish a sales visualization from an engineering-approved model?
    • How are revisions synchronized with PLM or PDM?
    • Can a user return comments, measurements or approval status to the quote?
    • What happens when an option has no visible geometry but changes cost, BOM or manufacturing work?
    • Are offline use, device management and access permissions supported?
    • Can the implementation handle configure-to-order (CTO) and engineer-to-order (ETO) products?

    These questions should be evaluated with representative products, not only a demonstration model. Review a product with dimensional dependencies, optional components, substituted parts and at least one engineering exception.

    Related manufacturing CPQ concepts

    AR is one part of a broader engineering and commercial architecture. Read the guide to CAD and engineering automation for parametric models, drawings and calculations. The guide to product configuration and rules engines explains how options and constraints are modeled. For downstream structures and commercial outputs, see BOM generation, pricing and quoting. The manufacturing workflows guide covers configure-to-order, engineer-to-order and sales-to-engineering handoff. Integration patterns are described in the guide to CPQ integrations.

    Semantic map

    The following relationships summarize how augmented reality connects to manufacturing CPQ and engineering data:

    Entity Relationship Related entity
    CPQ configures configurable industrial products
    Configuration rules prevent invalid option combinations
    Configured product generates configuration-specific BOM
    CPQ exchanges data with ERP
    CAD automation generates product-specific geometry and drawings
    AR application displays configured 3D model
    Engineering calculations determine technical product parameters
    PLM governs product revisions and lifecycle data
    PDM manages CAD files and design revisions
    AR review supports sales-to-engineering handoff
    Configured options control visual components and metadata
    Approved product model supports quote, engineering and production workflows

    Frequently asked questions

    What is augmented reality in manufacturing CPQ?

    It is the use of digital overlays and configured 3D product content to show an industrial product in a physical or spatial context during configuration, quotation, engineering review or service.

    Does every manufacturing CPQ system support augmented reality?

    No. Some systems provide only rules, pricing and quoting. Others include 3D visualization or connect to external CAD, visualization or AR platforms. Native AR capability must be verified with the vendor.

    How is AR different from 3D product configuration?

    3D configuration displays and manipulates a digital product, often in a browser. AR places digital content into the user’s physical environment or field of view. A CPQ solution may provide one without the other.

    Can AR generate a BOM?

    AR normally does not generate the BOM itself. The CPQ or engineering system generates a configurable BOM, while AR displays selected components or metadata associated with that BOM.

    Can AR replace CAD automation?

    No. CAD automation creates or modifies engineering geometry and drawings. AR presents visual content. They can be connected, but they perform different functions.

    What product data does AR-enabled CPQ require?

    It commonly requires product options, configuration rules, dimensions, part identifiers, approved 3D assets, revision information and mappings between configuration selections and visual components.

    Can AR show a completely engineered-to-order machine?

    It can, if the engineering process produces suitable geometry and the AR workflow can consume it. ETO products usually require stronger review, revision and approval controls than standard CTO products.

    How does AR support sales-to-engineering handoff?

    It can provide a shared visual reference and transfer the configuration ID, selected options, dimensions, comments and attachments to engineering. The handoff is reliable only when the visual output remains traceable to controlled data.

    Is an AR model the same as an engineering-approved model?

    Not necessarily. AR often uses a simplified model optimized for performance. It should be labeled according to its purpose and should not be treated as an approved design without the required engineering validation.

    Can AR validate physical clearances?

    It can support an early clearance review when the model, scale, coordinate system and placement method are reliable. Formal layout, safety and compliance decisions may require certified drawings or engineering analysis.

    What is the role of configuration rules in AR?

    Rules ensure that the visualized product reflects valid combinations. For example, they can prevent an AR view from showing an incompatible motor, frame, enclosure or connection arrangement.

    Does AR affect pricing and quoting?

    AR does not inherently calculate price. It can improve option understanding and customer approval, while the CPQ pricing engine calculates cost, price, discounts, lead time and quote values.

    Can AR use data from PLM or PDM?

    Yes, an integration may retrieve approved CAD assets, revisions and metadata from PLM or PDM. The integration must define ownership, release status, access rights and revision synchronization.

    Is AR useful for configure-to-order products?

    Yes. CTO products often have repeatable option structures and reusable visual assets, making them practical candidates for AR-based configuration and customer review.

    Is AR useful for make-to-order and engineer-to-order products?

    It can be useful, but the value depends on how much geometry and engineering data exists before the order. ETO workflows need careful handling of design changes, approvals and model revisions.

    What are the main risks of implementing AR in CPQ?

    Common risks include inaccurate or obsolete models, weak configuration-to-CAD mappings, poor device usability, excessive model detail, unclear data ownership and treating visualization as engineering validation.

    How should a manufacturer start an AR CPQ project?

    Choose one high-value use case, such as reviewing equipment footprint or accessory placement. Map authoritative data, define model fidelity, connect the configuration to visual assets and test the workflow with real product variants.

    What should buyers ask AR and CPQ vendors?

    Ask whether AR is native or integrated, how models are generated and versioned, how options map to geometry, how BOM and CAD data are linked, how revisions are governed and how the result returns to the quote or engineering workflow.

  • How a CPQ Rules Engine Works in Manufacturing

    A CPQ rules engine is the decision-making component of a Configure, Price, Quote system. It evaluates a product model, applies configuration rules and constraints, and determines whether a proposed product is valid, manufacturable and commercially quotable. In manufacturing CPQ, the result may include a valid configuration, calculated dimensions, a price, a configurable bill of materials (BOM), engineering parameters, a CAD variant or a handoff to an engineer for further design work.

    The rules engine does not simply display product options. It encodes relationships such as which motor is suitable for a pump, which materials are compatible with a chemical application, how frame dimensions affect component selection, and when a configuration must be routed to engineering. It is therefore central to the product model and should be treated as operational manufacturing logic rather than as a collection of sales prompts.

    A rules engine is only one part of CPQ. Product configuration determines what can be selected, engineering logic determines how the product must be designed, pricing logic determines what it costs or should sell for, and quoting tools present the result to the customer. Some CPQ platforms also generate BOMs, CAD outputs or manufacturing data; others integrate with specialist engineering, product lifecycle management or enterprise resource planning systems instead.

    What is a CPQ rules engine?

    A CPQ rules engine is software that evaluates conditions and actions within a configurable product model. It uses inputs such as product options, dimensions, performance requirements, customer selections, production constraints and commercial policies to produce decisions or calculated outputs.

    For example, a rules engine for an industrial pump may evaluate:

    • fluid type, temperature and viscosity;
    • required flow rate and pressure;
    • pump family and impeller diameter;
    • motor power, voltage and frequency;
    • casing, seal and material compatibility;
    • installation orientation and connection standard;
    • lead time, plant capability and regional compliance requirements.

    It may then prevent invalid selections, recommend a suitable pump size, calculate a required motor rating, add components to a configurable BOM, apply a price adjustment and identify whether the order is configure-to-order (CTO) or engineer-to-order (ETO).

    A generic sales CPQ application may use rules to control discounts, bundles and quote approvals. Manufacturing CPQ uses those capabilities but extends them into product and engineering domains. The critical question is not only whether a salesperson can sell an option, but whether the selected product can be designed, costed, built and supported.

    Where the rules engine fits in a manufacturing CPQ architecture

    The rules engine normally sits between the user interface and the systems that hold product, engineering and commercial data. A typical flow is:

    1. A salesperson, dealer, customer or engineer starts a configuration.
    2. The CPQ application loads the relevant product model, version and context.
    3. The user selects options or enters requirements such as capacity, dimensions or material.
    4. The rules engine evaluates constraints, dependencies, calculations and recommendations.
    5. The configuration interface enables, disables, recommends or rejects selections.
    6. Pricing, costing, BOM and engineering services use the validated configuration.
    7. Outputs are sent to quoting, customer relationship management (CRM), enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), computer-aided design (CAD) or manufacturing execution systems (MES), depending on the architecture.

    These systems have different responsibilities. A CRM system manages customer and opportunity information. An ERP system manages transactions such as orders, inventory, purchasing and production planning. PLM manages product structures, revisions and lifecycle information. PDM focuses primarily on engineering files and related product data. CAD creates or modifies engineering designs. MES supports execution and tracking on the factory floor. CPQ coordinates the commercial configuration process and may use data from all of these systems without replacing them.

    More detail on these boundaries is available in the guide to CPQ integrations.

    The main components of a CPQ rules engine

    1. Product model

    The product model describes the configurable product, its structure and its allowable choices. It may contain product families, models, features, options, attributes, components, dimensions, units of measure and default values.

    For an industrial air-handling unit, the model might contain:

    Model element Example Purpose
    Product family Air-handling unit Defines the overall configurable product
    Feature Cooling section Groups related choices
    Option Chilled-water coil Represents a selectable alternative
    Attribute Airflow, width or voltage Stores a value used by rules and calculations
    Component Fan, filter or control panel May contribute to the BOM
    Revision Model version 2025.1 Controls which rules and components are valid

    The product model is more than a catalogue. It is a structured representation of how the product is sold and engineered. A weak model may contain options without the relationships needed to validate a real product. A strong model connects commercial choices to technical consequences and downstream outputs.

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

    2. Rule definitions

    Rules describe how the model behaves. Most rules can be expressed as a condition and an action:

    IF application_fluid = "corrosive"
THEN require casing_material IN ["316 stainless steel", "duplex stainless steel"]

    Rules can require an option, prohibit an option, recommend a choice, set a default, calculate a value, add a component, remove a component, assign a price, trigger an approval or route a configuration to engineering.

    A rule may be simple, but manufacturing products often require rules that combine several inputs:

    IF flow_rate > 120 m3/h
AND discharge_pressure > 8 bar
THEN require pump_frame = "heavy duty"
AND require motor_power >= 45 kW

    Rules should be written so that their purpose, owner, scope and effective date are clear. A rule that exists only as an undocumented expression inside an application is difficult to test and maintain.

    3. Constraints

    Constraints define combinations that are allowed or forbidden. They are central to configuration validation.

    Common constraint types include:

    • Compatibility constraints: a 60 Hz motor cannot be selected for a market requiring a 50 Hz electrical system.
    • Mutual exclusion: two options cannot be selected together because they use the same physical space.
    • Dependency: a high-temperature seal requires a compatible casing material and cooling arrangement.
    • Requirement constraints: a particular control module is required when a remote-monitoring option is selected.
    • Range constraints: a tank diameter must remain within the manufacturing capability of a selected plant.
    • Cardinality constraints: a vehicle may allow one powertrain but several accessory packages.
    • Resource constraints: a configuration may be valid technically but unavailable because a component is obsolete or not approved for the target region.

    A constraint can be hard or soft. A hard constraint blocks an invalid combination. A soft constraint allows the configuration but displays a warning, recommendation or approval requirement. For example, a pump may technically operate with a selected impeller and motor, but the combination may be outside the preferred efficiency range. The system could warn the user rather than reject it.

    4. Dependency and propagation logic

    Configuration choices often propagate through the model. Selecting a product family can limit available options. Selecting an option can set dimensions, alter a calculated value or add a component. Changing a dimension can invalidate an earlier choice.

    Consider a conveyor configuration:

    1. The user selects a belt width of 1,200 millimetres.
    2. The rules engine restricts the available drive units to those rated for that width and load.
    3. The required motor power is calculated from length, incline, material and throughput.
    4. The frame and guarding options are updated.
    5. The BOM receives the correct belt, rollers, drive assembly and support members.
    6. The price is recalculated from the selected components and length.

    This propagation may occur immediately in the user interface or through a server-side validation service. The important design issue is consistency: the same logic must be applied when a configuration is created, edited, recalculated, imported through an API or converted into an order.

    5. Calculation and engineering logic

    Some manufacturing products cannot be configured using yes-or-no rules alone. They require calculations. Examples include heat exchanger sizing, motor selection, structural capacity, cable sizing, pressure drop, thermal performance, battery capacity and vehicle payload.

    A calculation rule may derive an output from several inputs:

    required_motor_power = (flow_rate * pressure_rise) / efficiency_factor

    In practice, engineering calculations may include unit conversions, safety factors, lookup tables, interpolation, standards and product-specific formulas. The CPQ system may perform the calculation itself, call an external engineering service or pass the inputs to CAD or simulation software.

    Calculation results should be distinguished from selections. A motor power of 30 kW may be a calculated requirement, while a specific motor catalogue number is a subsequent selection based on that requirement. Keeping these concepts separate improves traceability and makes rules easier to review.

    For CAD, drawings, parametric models and engineering automation, see the CAD and engineering automation guide.

    How a CPQ rules engine evaluates a configuration

    The exact implementation varies by platform, but a typical evaluation cycle contains the following stages.

    1. Load context

    The engine loads the product model version and the context of the transaction. Context can include customer, country, currency, sales channel, plant, effective date, language, opportunity type and user permissions.

    Context matters in manufacturing. A valve may require different certifications by market. A component may be available from one plant but not another. A dealer may see a different price list from an internal sales engineer. A product revision may be valid for new orders after a release date but not for an existing contract.

    2. Accept inputs

    Inputs can come from user selections, imported customer requirements, a CRM opportunity, an ecommerce session or an engineering template. The system should identify the source and value of each important input.

    For example, “capacity” could be entered directly by a salesperson, derived from flow and pressure, or imported from a previous design. These cases may need different validation and audit treatment.

    3. Apply defaults and recommendations

    The engine may set safe defaults or recommend common combinations. Defaults accelerate configuration but should not conceal important engineering decisions. A default should have a clear rationale and remain visible when it affects cost, performance or manufacturability.

    Guided selling is related but not identical to rules-based configuration. Guided selling asks questions and recommends a product or package based on customer needs. Rules-based configuration validates the detailed product structure. A manufacturing CPQ implementation may use guided selling at the beginning and a deeper constraint model after the product family has been selected.

    4. Validate constraints

    The engine checks compatibility, dependencies, ranges, quantities and required selections. It may report errors immediately or validate the complete configuration at a checkpoint.

    Good validation messages explain what is wrong and how to resolve it. “Invalid configuration” is less useful than “A stainless-steel pump casing is required for the selected corrosive fluid. Select 316 stainless steel or change the fluid classification.”

    5. Calculate derived values

    The engine calculates values such as capacity, weight, dimensions, motor rating, cable size, material quantity, discount eligibility, cost and selling price. Calculation order matters. A price may depend on a calculated component, while the component may depend on a dimension entered by the user.

    6. Generate downstream outputs

    After validation, the configuration can be used to produce one or more outputs:

    • a configured product summary for the quote;
    • a price and cost breakdown;
    • a configurable BOM or order BOM;
    • engineering parameters for CAD or design automation;
    • technical data sheets and customer documentation;
    • an approval request;
    • an ERP order line or manufacturing request;
    • an ETO work item for engineering.

    Not every CPQ platform generates every output. Buyers should verify whether an output is native, produced through configuration, or dependent on a separate integration.

    Rules, pricing, BOMs and engineering outputs

    Configuration rules versus pricing rules

    Configuration rules answer questions such as “Can this option be selected?” or “Which component is required?” Pricing rules answer questions such as “What should this valid configuration cost?” or “Which discount requires approval?”

    The two rule sets interact but should not be confused. A high-temperature seal may be technically required by a fluid temperature rule. Its price may then be retrieved from a price list or calculated from material and size. If technical validity and commercial pricing are mixed into one opaque rule, it becomes difficult to determine whether an error is caused by product logic or a price policy.

    Configurable BOMs, EBOMs and MBOMs

    A bill of materials (BOM) is a structured list of components and quantities. A configurable BOM contains alternatives, conditions or rules that allow the final structure to be derived from a configuration.

    An engineering BOM (EBOM) represents the product from an engineering design perspective. A manufacturing BOM (MBOM) represents how the product is assembled and produced, including manufacturing-specific groupings, operations or consumables. A CPQ result may resemble an EBOM, an MBOM, an order BOM or a sales BOM, depending on the process.

    For example, a CPQ system may identify the selected gearbox, motor and frame. ERP may then use those selections to create an order-specific manufacturing structure. Alternatively, CPQ may generate a complete BOM and send it to ERP. The boundary must be designed explicitly rather than assumed.

    Read more in the guide to BOM generation, pricing and quote automation.

    CAD and drawing automation

    When a configuration includes dimensions or geometry, the rules engine may pass validated parameters to CAD automation. A CAD system can then generate a model, drawing, layout or file for review. The CPQ rules engine should not be treated as a replacement for CAD. It determines which parameters and options are valid; CAD applies geometric and drafting logic.

    A useful separation is:

    • CPQ determines the commercial and configurable product definition.
    • The rules engine validates selections and calculates design inputs.
    • CAD generates geometry and drawings from those inputs.
    • PLM or PDM controls revisions, files and engineering release status.

    Rules-based, constraint-based and guided configuration

    Approach How it works Manufacturing use Limitation
    Rules-based configuration Explicit conditions trigger actions or validations Option dependencies, component selection and approval logic Can become difficult to maintain if rules are duplicated or poorly structured
    Constraint-based configuration The engine evaluates a network of allowed and forbidden relationships Complex compatibility, sizing and engineering constraints Requires disciplined modelling and clear explanations of failures
    Guided selling Questions and recommendations lead the user toward a product or package Dealer, sales and self-service product selection May not validate detailed engineering or manufacturing requirements on its own

    These approaches are complementary. A dealer portal may begin with guided questions, use rules to narrow the product family, apply constraints to validate the detailed configuration and use calculation logic to produce an order-ready result.

    Manufacturing workflow example: configuring a hydraulic power unit

    Assume a manufacturer sells hydraulic power units with configurable reservoir size, pump type, motor, valves, filtration, controls and mounting arrangements.

    Inputs

    • required flow rate and operating pressure;
    • fluid type and operating temperature;
    • available electrical supply;
    • mounting orientation and available footprint;
    • control method and communication requirements;
    • environmental and enclosure requirements.

    Rules and calculations

    • Calculate minimum pump displacement from flow and speed.
    • Require a suitable motor rating for pressure, flow and efficiency.
    • Prevent a reservoir size below the required fluid volume.
    • Require a high-temperature seal package above a defined operating temperature.
    • Restrict enclosure and coating choices for the selected environment.
    • Add a return-line filter when the selected circuit requires it.
    • Require an engineering review when the footprint is below the standard mounting envelope.

    Outputs

    • validated configuration summary;
    • calculated pump and motor requirements;
    • component-level BOM;
    • cost and selling price;
    • lead-time estimate based on selected components;
    • technical data sheet;
    • engineering task if a non-standard mounting or control arrangement was selected.

    This example shows why the rules engine is more than a user-interface feature. It connects customer requirements to engineering decisions, commercial results and downstream work.

    Maintainability and governance

    Rules are product knowledge. They need ownership, version control, testing and release processes comparable to other important product data.

    Assign rule ownership

    Different rules may belong to different functions. Product management may own option availability. Engineering may own performance and compatibility rules. Manufacturing may own plant and process constraints. Finance or commercial operations may own discount and approval rules. A governance model should define who can propose, approve, test and release each category.

    Separate rule categories

    Keep technical constraints, calculations, BOM logic, pricing, approvals and user-interface recommendations logically separate where possible. This makes changes safer and allows a technical rule to be tested independently from a sales policy.

    Use effective dates and revisions

    Products evolve. Components become obsolete, suppliers change materials and new standards apply. Rules need effective dates, revision identifiers and a clear relationship to product model versions. A quote created under one revision should not silently change because a rule was edited later.

    Test combinations, not only individual rules

    Testing one rule at a time is insufficient. Rules interact, and a change in one product area can create invalid combinations elsewhere. Test cases should include valid configurations, prohibited combinations, boundary values, missing inputs, regional variations, obsolete components, high-volume configurations and transitions between product revisions.

    Automated regression tests are useful for large product models. A test can submit a known configuration and verify that validation status, calculated values, BOM lines, price and routing outcome remain correct after a model change.

    Measure maintainability

    Useful operational measures include the number of manual overrides, engineering escalations, rule defects, configuration rework events, duplicate rules, unresolved warnings and time required to release a product-model change. These measures are more informative than simply counting how many rules exist.

    The CPQ implementation guide covers product data, migration, testing, governance and ongoing maintenance in more detail.

    Common limitations and failure modes

    Rules become an undocumented codebase

    When every exception is added directly to the model, the rules engine can become difficult to understand. Similar rules may conflict, and no one may know which rule has priority. Use naming standards, descriptions, ownership, reusable functions and review procedures.

    The product model is incomplete

    A rules engine cannot validate information that has not been modelled. If engineering constraints exist only in spreadsheets, emails or individual experience, the CPQ result may look complete while still requiring manual review.

    Too many hard stops

    Blocking every unusual configuration can frustrate experienced sales engineers and encourage workarounds. Distinguish between impossible, unsafe, unprofitable and merely non-standard cases. Use warnings, approvals or ETO routing where appropriate.

    Rules are duplicated across systems

    Product logic may be copied into CPQ, ERP, ecommerce, CAD automation and custom middleware. Duplicated logic can produce different answers. Define a system of record for each type of data and decide which system owns each calculation or validation.

    Performance declines with model complexity

    Large product models, extensive constraint networks, external calculations and real-time integrations can make configuration slow. Performance should be tested with realistic product structures and concurrent users, not just a small demonstration model.

    Human engineering judgment is overlooked

    Not every ETO decision can be reduced to a deterministic rule. A good architecture supports controlled handoffs, engineering review, assumptions, attachments and revision of the configuration after review. Automation should remove repetitive work without pretending that every design decision is already known.

    How to evaluate a CPQ rules engine

    Manufacturers evaluating a CPQ engine should ask questions about product complexity rather than rely on feature counts.

    Evaluation area Questions to verify
    Product modelling Can the system represent nested products, options, attributes, revisions, units and configurable components?
    Constraints Can it express dependencies, mutual exclusions, ranges, cardinality and context-specific restrictions?
    Calculations Can it handle formulas, lookup tables, units, rounding, external services and engineering approvals?
    Explainability Can users understand why a selection is blocked, required or recommended?
    BOM output Does it generate a configurable BOM, order BOM, EBOM or MBOM, and how is ownership divided with ERP or PLM?
    Engineering automation Can it provide parameters to CAD or engineering tools, and what file or revision controls are available?
    Versioning Can the organisation test, approve, release and retire product-model revisions?
    Integration How are CRM, ERP, PLM, PDM, CAD, PIM and MES data exchanged, and which system owns each value?
    Performance How does evaluation perform for large models, complex constraints and concurrent users?
    Governance Can product, engineering, manufacturing and commercial teams manage rules without uncontrolled duplication?

    Documented capability should be separated from roadmap claims or assumptions. A vendor may support pricing rules but require a separate product configurator for engineering constraints. Another may support BOM generation but rely on ERP for the final manufacturing structure. The implementation architecture matters as much as the feature list.

    Relationship to CTO, ETO, MTO and ATO

    Manufacturing process types influence how the rules engine is used:

    • Configure-to-order (CTO): the rules engine selects from predefined, validated options and produces repeatable order data.
    • Engineer-to-order (ETO): the rules engine captures requirements and identifies where engineering must create or approve a unique design.
    • Make-to-order (MTO): the product is made after the order, often using a defined product model with order-specific values.
    • Assemble-to-order (ATO): standard modules are assembled after the order; the rules engine validates module compatibility and assembly choices.

    A single manufacturer may use all four approaches across different product families. The CPQ model should therefore identify which decisions are automated, which outputs are standard and which cases require engineering intervention. See the guide to manufacturing CPQ workflows.

    Implementation principles

    1. Start with a representative product family. Choose a product that exposes meaningful configuration, engineering and manufacturing complexity without attempting to model the entire catalogue immediately.
    2. Document the current decision process. Capture spreadsheets, selection charts, engineering checks, price logic, BOM rules and approval paths.
    3. Define the target output. Decide whether the first release must produce a quote only, a validated configuration, an order BOM, CAD parameters or an engineering request.
    4. Establish data ownership. Identify whether CPQ, ERP, PLM, PDM or another system owns each product, component, price, revision and status value.
    5. Model standard paths first. Automate repeatable CTO and ATO cases before encoding every rare ETO exception.
    6. Design for explanation. Users need actionable reasons for warnings, blocked options and engineering escalations.
    7. Build a release process. Treat rule changes like product changes, with review, testing, effective dates and rollback procedures.
    8. Monitor the live model. Track overrides, defects, escalations, abandoned configurations and downstream corrections.

    Semantic map

    The following relationships summarize how a CPQ rules engine connects product configuration with engineering and manufacturing systems:

    • CPQ uses a product model to represent configurable products.
    • Configuration rules prevent invalid combinations.
    • Constraints validate technical and commercial relationships.
    • Configuration inputs drive engineering calculations.
    • Engineering calculations determine required product parameters.
    • A validated configuration generates a quote.
    • A configured product can generate a configurable BOM.
    • An EBOM represents an engineering product structure.
    • An MBOM represents a manufacturing product structure.
    • CAD automation generates product-specific models and drawings.
    • CPQ exchanges customer and opportunity data with CRM.
    • CPQ exchanges order and item data with ERP.
    • PLM manages product lifecycle and revision information.
    • PDM manages engineering files and related product data.
    • ETO routing sends non-standard configurations to engineering.
    • Rules governance controls product-model changes.

    Frequently asked questions

    1. What does a CPQ rules engine do?

    It evaluates product selections and requirements against configuration, engineering, pricing and process rules. It can validate a product, calculate values, select components, produce outputs and route exceptions to engineering.

    2. Is a CPQ rules engine the same as a product configurator?

    Not exactly. A product configurator is the broader application or capability used to define a product. The rules engine is the logic layer that evaluates selections, constraints and calculations within that configurator.

    3. How is a manufacturing CPQ rules engine different from a sales CPQ engine?

    Sales CPQ commonly focuses on bundles, pricing, discounts and approvals. Manufacturing CPQ also addresses product constraints, dimensions, materials, engineering calculations, BOMs, CAD inputs and production or engineering handoffs where supported.

    4. What is a configuration rule?

    A configuration rule defines a condition and an action, such as requiring a high-temperature seal when a pump operates above a specified temperature.

    5. What is a configuration constraint?

    A constraint defines an allowed, forbidden or conditional relationship between product choices, values or resources. It may prevent incompatible options or restrict a value to a valid range.

    6. Can a rules engine calculate engineering values?

    Some can perform formulas, lookup logic and unit conversions. Others call external engineering or calculation services. The specific capability must be verified for the CPQ platform and product domain.

    7. Can CPQ rules generate a BOM?

    Some manufacturing CPQ systems generate configurable or order-specific BOMs. Others send validated selections to ERP, PLM or a separate BOM service. The resulting structure and system of record should be defined during design.

    8. Does a configurable BOM equal an EBOM?

    No. A configurable BOM describes how a selected configuration resolves into components. An EBOM represents the engineering structure, while an MBOM represents the manufacturing structure. They may share data but serve different purposes.

    9. Can a CPQ rules engine generate CAD drawings?

    It may provide validated parameters to CAD automation, which then creates models or drawings. Not every CPQ platform includes CAD generation, and CAD, PLM or PDM may remain responsible for files and revisions.

    10. How does the engine handle engineer-to-order products?

    It can capture requirements, validate known constraints, calculate preliminary values and route non-standard cases to engineering. It should not claim a complete design when engineering work is still required.

    11. What happens when rules conflict?

    The platform may use priorities, rule dependencies, evaluation order or explicit conflict handling. The implementation should define how conflicts are detected, explained and resolved rather than relying on undocumented precedence.

    12. Should every warning block configuration?

    No. Safety or impossible combinations may require a hard stop. A non-preferred but technically feasible choice may be better handled through a warning, approval or engineering review.

    13. Who should own CPQ rules?

    Ownership depends on the rule type. Engineering may own technical constraints, manufacturing may own plant rules, product management may own options, and commercial teams may own pricing and approvals. Shared governance is usually required.

    14. How are CPQ rules versioned?

    Rules should be associated with product-model revisions, effective dates and release status. This allows the organisation to reproduce an earlier quote and prevent later edits from changing historical transactions.

    15. What data does a CPQ rules engine need?

    It may need product structures, options, attributes, component data, engineering formulas, constraints, prices, costs, plant capabilities, customer context, revisions and integration mappings.

    16. Can a CPQ rules engine replace ERP?

    No. CPQ and ERP have different responsibilities. CPQ creates and validates the commercial configuration, while ERP commonly manages orders, inventory, purchasing, production planning and financial transactions.

    17. Can rules be reused across products?

    Reusable rules or functions can reduce duplication, especially for common materials, voltage standards or approval policies. Reuse must be controlled so that a change does not unintentionally alter unrelated product families.

    18. How should a company test a CPQ rules engine?

    Test valid and invalid configurations, boundary values, regional contexts, product revisions, pricing outcomes, BOM results, integrations and engineering escalations. Regression testing is important after every major model change.

    19. What is the biggest maintainability risk?

    The main risk is uncontrolled growth of undocumented exceptions and duplicated logic. Clear ownership, modular rules, versioning, explanations and automated tests reduce that risk.

    20. How does guided selling relate to a CPQ rules engine?

    Guided selling helps users identify a suitable product or package through questions and recommendations. The rules engine may then perform the deeper technical validation required to configure the final manufactured product.

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

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

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

  • Manufacturing CPQ Requirements: Functional and Technical Checklist

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

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

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

    What are manufacturing CPQ requirements?

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

    Manufacturing CPQ normally combines several related disciplines:

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

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

    Start with a manufacturing CPQ scope statement

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

    Document the following scope dimensions:

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

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

    Functional requirements checklist

    1. Product model and configuration requirements

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

    Confirm whether the system can:

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

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

    2. Rules, constraints and validation

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

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

    Requirements should cover:

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

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

    3. Engineering calculations and technical validation

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

    Potential requirements include:

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

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

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

    4. BOM generation and manufacturing outputs

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

    Specify whether the system must generate:

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

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

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

    5. CAD, drawings and visualization

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

    Evaluate whether the requirement is for:

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

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

    6. Costing, pricing and margin control

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

    Requirements may include:

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

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

    7. Quote, proposal and approval management

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

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

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

    Workflow requirements by manufacturing model

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

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

    Map these flows in the guide to manufacturing CPQ workflows.

    Technical and architecture requirements

    Data ownership and master data

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

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

    Integration and APIs

    Manufacturing CPQ integration requirements commonly include:

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

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

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

    Security, deployment and performance

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

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

    Maintainability, versioning and governance

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

    Define:

    • Who owns product data, rules, prices, calculations and templates.
    • How changes are requested, reviewed, tested and released.
    • How obsolete options and components are handled.
    • How rules are documented for future administrators.
    • How configuration defects are reported and traced.
    • How production, engineering and commercial teams resolve conflicting definitions.

    Implementation and evaluation checklist

    1. Document representative products, not only simple examples.
    2. Collect real configuration rules, exception cases, calculations and historical quotes.
    3. Map the current sales-to-engineering-to-production workflow.
    4. Classify requirements as mandatory, important, optional or future scope.
    5. Identify data owners and authoritative sources for each object.
    6. Define the required outputs: quote, specification, EBOM, MBOM, CAD file, drawing, order or engineering task.
    7. Build test scenarios covering valid combinations, invalid combinations, boundary values and exceptions.
    8. Test product revisions, price changes and effective dates.
    9. Verify integrations with representative ERP, CRM, PLM, PDM and CAD data.
    10. Measure rule maintenance effort, quote accuracy, engineering handoff quality and document generation reliability.
    11. Confirm how dealers, distributors and external users are authenticated and supported.
    12. Define governance, release management, support ownership and training before go-live.

    During vendor evaluation, ask for a controlled proof of concept using one representative product family. Require the vendor to show how a rule is created, tested, revised and traced; how a configuration becomes a BOM; how a technical exception is handled; and how data moves into downstream systems. A feature checklist alone will not reveal implementation complexity.

    The CPQ implementation guide provides a broader framework for requirements, migration, testing, deployment and governance.

    Common limitations and risks

    • Overly broad scope: attempting to replace ERP, PLM, CAD, MES and CRM in one project can obscure the CPQ objective.
    • Unmaintainable rules: duplicated logic and undocumented exceptions make product models difficult to change.
    • Weak product data: inconsistent item numbers, units, revisions and descriptions undermine every downstream output.
    • False automation assumptions: a platform may support a configurable BOM but not a production-ready MBOM or CAD design.
    • Uncontrolled exceptions: manual overrides may allow technically invalid or commercially unprofitable configurations.
    • Integration ambiguity: unclear ownership can create conflicting prices, revisions or component definitions.
    • Insufficient testing: a model can work for common products while failing at dimensional limits or rare combinations.
    • Low adoption: sales and engineering users may bypass the system if it is slower or less flexible than existing spreadsheets.

    These risks are reasons to define boundaries, ownership and test cases early. They are not reasons to assume that one platform will support every engineering and manufacturing process automatically.

    Semantic map

    The following relationships summarize the entities discussed in this guide:

    • Manufacturing CPQ connects product configuration, engineering validation, pricing, quoting and production data.
    • Product models contain options, attributes, components and configuration rules.
    • Configuration rules prevent invalid combinations and trigger calculated results.
    • Engineering calculations validate requirements and support component selection.
    • A configured product can generate a configurable BOM when the platform supports BOM logic.
    • EBOM represents an engineering product structure, while MBOM represents a manufacturing structure.
    • CAD automation can generate product-specific models or drawings when supported and properly integrated.
    • Costing estimates internal manufacturing expense, while pricing determines the customer charge.
    • CRM supplies customer and opportunity context, while ERP supplies commercial and operational records.
    • PLM and PDM manage product lifecycle and design data that may be referenced by CPQ.
    • CTO uses validated standard configurations, while ETO introduces project-specific engineering work.
    • Governance controls changes to product rules, prices, revisions and integration mappings.

    Frequently asked questions

    What is the most important manufacturing CPQ requirement?

    The most important requirement is a maintainable product model that can represent real options, dependencies, constraints and outputs. Without it, pricing and quote documents may appear correct while the configured product remains technically invalid.

    How is manufacturing CPQ different from sales CPQ?

    Sales CPQ generally emphasizes product selection, pricing, discounts and proposals. Manufacturing CPQ may additionally validate engineering constraints, calculate technical values, generate BOMs or CAD outputs and exchange data with ERP, PLM or production systems.

    Does every manufacturing CPQ system generate a BOM?

    No. Some systems generate configurable BOMs, some pass selections to an ERP or PLM system, and some only produce commercial quote data. BOM generation and its required EBOM or MBOM structure must be verified separately.

    What is a configurable BOM?

    A configurable BOM is a product structure whose components, quantities or assemblies change according to configuration choices. For example, a machine BOM may change when the user selects a different motor, frame size or material.

    Should CPQ own the product master?

    Not necessarily. Ownership depends on the architecture. ERP, PLM, PDM or another system may remain the authority for items, revisions or engineering structures, while CPQ uses synchronized data to configure and quote products.

    What rules should be included in a CPQ requirements document?

    Include compatibility, dependency, dimensional, performance, safety, pricing, BOM-selection and approval rules. Also specify how rules are versioned, tested, explained to users and linked to source data.

    What is the difference between a hard error and a warning?

    A hard error blocks a configuration because it is invalid or prohibited. A warning allows the user to continue but records a condition that may require review, such as a non-standard dimension or an unusual commercial margin.

    When are engineering calculations required in CPQ?

    They are required when product selection depends on technical inputs such as flow, pressure, load, temperature, speed, voltage, capacity or dimensions. The calculation may run inside CPQ or through an integrated engineering service.

    Does 3D visualization prove that a product is manufacturable?

    No. Visualization helps users understand a configuration, but manufacturability also depends on rules, tolerances, materials, component availability, production methods and engineering review.

    What is the difference between EBOM and MBOM?

    An EBOM describes the product from an engineering design perspective. An MBOM organizes components and operations according to how the product is manufactured or assembled. A CPQ implementation may produce one, both or neither.

    Which systems commonly integrate with manufacturing CPQ?

    Common integration targets include CRM, ERP, PLM, PDM, CAD, PIM and MES. The exact scope depends on which system owns customers, products, revisions, prices, designs, inventory and production data.

    What should a CPQ proof of concept include?

    Use a representative product family with real rules, calculations, pricing, exceptions and downstream outputs. Test valid and invalid configurations, revision changes, quote generation, BOM results and at least the most important integrations.

    How should manufacturers evaluate CPQ rule maintenance?

    Ask business and engineering users to create, change, test and release representative rules. Measure whether they can understand dependencies, identify affected products and deploy changes without unsafe manual workarounds.

    What are the CPQ requirements for configure-to-order?

    CTO generally requires repeatable configuration validation, controlled option combinations, accurate pricing and an order-ready product definition. Configurable BOM and ERP integration are often important, but the required output depends on the manufacturing process.

    What are the CPQ requirements for engineer-to-order?

    ETO requires structured capture of customer requirements, technical exception handling, engineering task initiation, document management and a controlled transition from preliminary configuration to approved design and production data.

    Can CPQ replace CAD or PLM?

    Usually it should not be assumed to do so. CPQ may integrate with CAD or PLM and automate selected tasks, but CAD design authority, lifecycle control and engineering revision management may remain in specialist systems.

    How should pricing and costing requirements be separated?

    Document internal cost inputs separately from customer-facing prices. Costs may include material, labor and purchased components, while pricing may include list prices, discounts, surcharges, margins, taxes and commercial terms.

    What governance is needed after CPQ implementation?

    Manufacturers need named owners for product models, rules, prices, calculations, templates and integrations. They also need change control, testing, release procedures, auditability and a process for handling product and supplier changes.