CPQ Guide

Tag: MBOM

  • How to Build a CPQ Product Model for Manufacturing

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

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

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

    What is a CPQ product model?

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

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

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

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

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

    Why product-model design matters

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

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

    The main layers of a manufacturing CPQ product model

    1. Product structure

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

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

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

    2. Options and attributes

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

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

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

    3. Dependencies

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

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

    4. Constraints

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

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

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

    5. Calculations

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

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

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

    6. Output mappings

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

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

    Start with a product-model scope

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

    Document:

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

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

    Separate configuration, pricing and quoting logic

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

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

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

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

    Design rules for maintainability

    Use modular rule groups

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

    Prefer declarative rules where practical

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

    Use controlled vocabularies

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

    Make defaults explainable

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

    Do not encode every exception as a normal option

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

    Build the model from authoritative product data

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

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

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

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

    Connect the model to BOM, CAD and manufacturing outputs

    Configurable BOMs

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

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

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

    CAD and engineering automation

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

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

    ERP and order handoff

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

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

    Rules-based, constraint-based and guided configuration

    These approaches overlap but are not identical.

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

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

    Modeling a pump example

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

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

    The model could apply rules such as:

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

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

    Validation, testing and governance

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

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

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

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

    Common product-modeling mistakes

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

    Implementation sequence

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

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

    How to measure product-model quality

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

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

    When a CPQ product model should stop

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

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

    Semantic map

    The article connects the following manufacturing CPQ entities and relationships:

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

    Frequently asked questions

    What is a CPQ product model?

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

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

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

    What should be modeled first?

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

    Should every component appear as a customer-facing option?

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

    What is the difference between an option and an attribute?

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

    How should engineering rules be represented?

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

    Can a CPQ product model calculate equipment size?

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

    Does every CPQ system generate a BOM?

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

    Can a CPQ model generate CAD drawings?

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

    What is the difference between EBOM and MBOM?

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

    How does pricing relate to configuration rules?

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

    How should ETO requirements be handled?

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

    Which systems provide data to a product model?

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

    Who should own the product model?

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

    How do you test a CPQ product model?

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

    How often should a product model be updated?

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

    What is the biggest product-modeling mistake?

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

    Can one CPQ model support CTO and ETO?

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

    How can manufacturers keep a product model maintainable?

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

  • Modular Product Architecture for CPQ in Manufacturing

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

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

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

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

    What is modular product architecture?

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

    A module may contain:

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

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

    Why modular architecture matters in manufacturing CPQ

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

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

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

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

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

    Core elements of a modular CPQ product model

    Modules and submodules

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

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

    Options and features

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

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

    Interfaces and compatibility contracts

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

    Examples include:

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

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

    Rules and constraints

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

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

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

    Example: modular architecture for a pump skid

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

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

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

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

    How modular product architecture supports the CPQ workflow

    1. Requirement capture

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

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

    2. Configuration and validation

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

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

    3. Engineering calculations and selection

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

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

    4. Pricing and costing

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

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

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

    5. BOM and engineering outputs

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

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

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

    6. CAD and documentation

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

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

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

    Product model layers in a maintainable CPQ architecture

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

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

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

    Rules for modular products

    Useful rules normally fall into several categories:

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

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

    Modularity and CTO, ETO, MTO and ATO

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

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

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

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

    Integration with enterprise systems

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

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

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

    Benefits of modular product architecture

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

    Limitations and risks

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

    Common risks include:

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

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

    Implementation approach

    1. Select a representative product family

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

    2. Map the current product structure

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

    3. Define ownership and authority

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

    4. Establish a rule taxonomy

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

    5. Model interfaces before every option

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

    6. Test combinations and boundaries

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

    7. Connect outputs incrementally

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

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

    How to evaluate software for modular CPQ architecture

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

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

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

    Governance and long-term maintenance

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

    Useful governance practices include:

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

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

    Semantic map

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

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

    Frequently asked questions

    What is modular product architecture in CPQ?

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

    How is modular CPQ different from a simple option list?

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

    What is an example of a CPQ module?

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

    Can modular product architecture prevent configuration errors?

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

    Does modular architecture eliminate engineering involvement?

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

    What is the difference between configuration rules and constraints?

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

    How does modular CPQ support configure-to-order?

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

    Can the same modular model support ETO?

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

    Does modular CPQ generate a BOM?

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

    What is the difference between an EBOM and an MBOM?

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

    How does CAD relate to modular product architecture?

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

    Who should own CPQ product rules?

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

    What causes modular CPQ models to become difficult to maintain?

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

    How should a manufacturer start a modular CPQ project?

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

    Can modules be reused across different product families?

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

    How does modular architecture affect pricing?

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

    What integrations are important for modular manufacturing CPQ?

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

    How should modular CPQ models be tested?

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

    What is the main benefit of modular product architecture?

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

  • CPQ vs PLM: How Sales Configuration Differs from Engineering Configuration

    CPQ and PLM solve different configuration problems in manufacturing. Configure, Price, Quote (CPQ) software helps sales teams, dealers and application engineers select a valid product configuration, calculate its price and produce a quote. Product lifecycle management (PLM) software manages the engineering definition of a product across its lifecycle, including design files, revisions, engineering bills of material, approvals and change control.

    In practical terms, CPQ answers: What can we sell to this customer, under these commercial and technical conditions, and at what price? PLM answers: What is the approved product definition, how is it designed, which components and documents belong to it, and how should engineering changes be controlled?

    For a manufacturer of industrial pumps, CPQ might guide a salesperson through flow rate, head pressure, fluid type, motor size, seal material, voltage, controls and accessories. It can reject incompatible choices, calculate a price and produce a quotation. PLM may contain the approved pump designs, CAD files, engineering bill of material (EBOM), specifications, revisions, engineering changes and released documentation used to maintain the product.

    The systems often exchange data, but one should not automatically replace the other. The right architecture depends on product complexity, the maturity of engineering data, the level of configure-to-order (CTO) or engineer-to-order (ETO) work, and whether the CPQ platform can generate manufacturing outputs or only commercial quotes.

    What is the difference between CPQ and PLM?

    Area Manufacturing CPQ PLM
    Primary purpose Configure a sellable product, calculate commercial values and create a quote or order package. Manage product definitions, engineering data, revisions, workflows and lifecycle changes.
    Main users Sales, dealers, sales engineers, application engineers, product managers and commercial operations. Design engineers, product engineers, manufacturing engineers, document controllers and engineering managers.
    Configuration view Customer-facing or sales-facing options, constraints, pricing and availability. Engineering structure, design intent, approved parts, documents, revisions and change relationships.
    Typical outputs Quote, proposal, price, cost estimate, selected options, configuration summary and sometimes a configurable BOM or CAD output. EBOM, CAD files, specifications, drawings, change records, approvals and released product data.
    Time horizon Opportunity, quotation and order entry. Product development, release, revision and end-of-life management.
    Commercial logic Discounts, margins, freight, regional pricing, customer terms and approval thresholds. Usually not the primary system for quote pricing or sales discount governance.
    Change control Controls the validity of current selling rules and commercial policies. Controls formal engineering changes, revisions, approvals and release status.

    There is overlap. Both systems can contain product options, component relationships, rules and versions. The difference is the business context and authority of each data set. A CPQ product model is optimized for selecting and selling a valid configuration. A PLM product structure is optimized for defining, approving and changing the product.

    See the broader guide to manufacturing CPQ for how configuration, engineering automation, pricing and production data fit together.

    What manufacturing CPQ does

    Manufacturing CPQ is more than a generic proposal or subscription-quoting tool. It can combine product configuration, technical validation, pricing, costing, quote generation and downstream order information. The exact scope varies by platform, so buyers should verify whether a product supports only commercial quoting or also BOM generation, engineering calculations, CAD automation and production handoff.

    Sales and application configuration

    CPQ presents the choices that a customer or seller is allowed to make. A configuration model may include product families, options, dimensions, materials, performance ranges, accessories, service packages and regional variants. It can use guided selling, rules-based configuration or constraint-based configuration.

    • Guided selling asks questions and recommends a suitable product or option set. It is useful when a buyer does not know the technical product terminology.
    • Rules-based configuration applies explicit conditions such as requiring a stainless-steel wetted part for a corrosive fluid.
    • Constraint-based configuration evaluates relationships among values, ranges and dependencies, such as motor power, impeller diameter, speed and operating point.

    For a conveyor system, a CPQ model might allow belt length and width to vary within engineering limits, require a specific frame for a long span, prevent a motor from being selected below the calculated load requirement and add guarding when a particular safety classification is chosen.

    Pricing and costing

    CPQ can calculate a price from a configured product rather than applying a single price to a generic product family. The calculation may include option prices, material surcharges, labor, freight, currency, customer-specific agreements, discounts, margin rules and approval thresholds. Some systems also calculate estimated cost using material, labor or routing data.

    Pricing is not the same as engineering configuration. A stainless-steel enclosure may be technically valid in several sizes, but each size and material combination can have different costs, lead times and margins. A CPQ implementation should keep technical rules separate from commercial rules where possible, even when both affect the final quote.

    Quote and proposal generation

    After validation and pricing, CPQ can generate a quote containing the selected configuration, commercial terms, delivery assumptions, line items, options, exclusions and approvals. Some systems produce a sales-facing configuration summary only. Others can pass structured data to order management, ERP, CAD or manufacturing systems.

    A quote is not automatically a production-ready order. The manufacturer must define which validations, approvals and data transformations are required before a quoted configuration can be released for production.

    What PLM does in manufacturing

    Product lifecycle management (PLM) is the discipline and software environment used to manage a product from concept and design through release, change, production support and retirement. PLM commonly manages engineering documents, computer-aided design (CAD) files, product structures, specifications, revisions, approvals, requirements and engineering change processes.

    Engineering product definition

    PLM provides a controlled source for the engineering definition of a product. This may include assemblies, components, materials, drawings, models, specifications, test results and approved alternatives. The structure may be represented as an engineering bill of material, or EBOM, which describes the product from an engineering perspective.

    For a pump, the EBOM may include the casing, impeller, shaft, seals, bearings, motor interface, fasteners and associated drawings. It may also contain design revisions and approved substitute components. The EBOM may not be the same structure that production needs on the shop floor.

    Revision and change management

    PLM manages engineering change requests, engineering change orders, approval workflows and effectivity. When a component changes material or a drawing revision is released, PLM can record who approved the change, which product versions are affected and when the new definition becomes effective.

    This is a central distinction from CPQ. A CPQ rule may say that a particular option is available for a product family. A PLM change process determines whether the underlying design, component or document is approved for release and which revision is current.

    CAD and engineering collaboration

    PLM often connects engineering data with CAD and product data management (PDM) processes. PDM is generally focused on managing technical files and product data, while PLM usually covers a broader lifecycle, including requirements, changes, workflows and cross-functional product information. The boundaries vary by organization and software architecture.

    More information about the relationship between configuration, CAD automation, drawings and engineering calculations is available in the CAD and engineering automation guide.

    Sales configuration versus engineering configuration

    The same physical product can have several representations. Sales needs a manageable set of choices that corresponds to customer needs. Engineering needs a precise and controlled definition of components, dimensions, interfaces and design intent. Manufacturing needs an executable structure, operations and materials. These representations must be related, but they do not need to be identical.

    Question Sales configuration in CPQ Engineering configuration in PLM
    Who is selecting or reviewing it? Seller, dealer, customer or application engineer. Design engineer, product engineer or manufacturing engineer.
    What is being optimized? Customer fit, valid options, price, margin and quote speed. Design integrity, requirements, manufacturability, compliance and revision control.
    How are choices expressed? Features, options, dimensions, performance inputs and commercial packages. Parts, assemblies, CAD parameters, specifications, documents and approved revisions.
    What happens when a choice is invalid? The user receives an error, restriction or alternative recommendation before quoting. The design or release process prevents unauthorized or incomplete engineering data from becoming official.
    What is the result? A quote, order configuration or handoff package. An approved product definition and controlled change history.

    Consider an air-handling unit. A salesperson may choose airflow, external static pressure, casing material, filter class, coil arrangement, fan type and controls. CPQ can validate that the selected fan meets the duty point and calculate a price. PLM may manage the fan assembly design, coil drawings, approved materials, component revisions and design documentation. If the configuration is outside an approved product family, the CPQ workflow may initiate an engineering review or route the opportunity into an ETO process.

    How CPQ and PLM work together

    Integration between CPQ and PLM can connect commercial configuration with controlled engineering data. The integration should define which system owns each data object, how revisions are synchronized and what event triggers data exchange.

    A typical data flow

    1. Product data is prepared. Engineering and product teams identify sellable options, compatible components, technical limits and approved variants. PLM may be the source for released engineering data, while CPQ stores a sales-oriented model.
    2. The user configures the product. A salesperson, dealer or application engineer selects options and enters requirements such as capacity, dimensions, voltage, temperature or material.
    3. CPQ validates the configuration. Rules and constraints check compatibility, ranges, dependencies, mandatory options and any commercial restrictions.
    4. Engineering calculations may run. Depending on the platform and implementation, CPQ may calculate performance or call an external engineering service. For example, a pump selection may use flow, head, fluid properties and speed to identify a suitable configuration.
    5. Price and cost are calculated. CPQ applies price lists, option values, costs, discounts, freight and approval rules.
    6. Engineering data is referenced or generated. The system may retrieve an approved part, create a variant, call CAD automation or send the configuration to engineering for review. Not every CPQ system supports these functions.
    7. The quote or order is handed off. Structured data may be sent to customer relationship management (CRM), enterprise resource planning (ERP), PLM, CAD, manufacturing execution system (MES) or another order system.
    8. Production data is released. After required reviews, the appropriate BOM, drawings, work instructions and order data are released for manufacturing.

    The CPQ integration guide explains the role of ERP, CRM, PLM, PDM, CAD, product information management (PIM), MES and APIs in this architecture.

    EBOM, configurable BOM and MBOM

    Bill of material structures are a frequent source of confusion in CPQ and PLM projects.

    • EBOM, or engineering bill of material, represents the product as designed. It groups parts and assemblies according to engineering relationships.
    • Configurable BOM represents the selectable structure and rules for multiple possible variants. It may contain optional, conditional or interchangeable components.
    • MBOM, or manufacturing bill of material, represents how the product is assembled or produced. It may group components by operation, workstation, kit or manufacturing sequence.

    A CPQ system might select components from a configurable BOM and pass the result to ERP or PLM. PLM may own the EBOM and revision process. ERP or a manufacturing planning system may own the MBOM. In some businesses, one system contains more than one structure, but ownership and synchronization still need to be explicit.

    For a customized electrical cabinet, CPQ could select enclosure dimensions, breaker ratings, control voltage and accessories. PLM could manage the approved schematic, panel layout, components and design revision. ERP could use the resulting order BOM for purchasing and production. The data flow must prevent a sales option from creating a component combination that has no approved engineering or manufacturing definition.

    See the BOM, pricing and quoting guide for a deeper explanation of configurable BOMs, EBOMs, MBOMs, costing and quote outputs.

    Where the boundary becomes difficult: CTO and ETO

    Configure-to-order (CTO) products are assembled from predefined and approved options. CPQ is often well suited to CTO when the product model, rules, pricing and component relationships are stable. An order for a standard conveyor with selected length, belt type, motor and guarding may generate a known configuration and predictable production data.

    Engineer-to-order (ETO) products require substantial engineering work for a specific customer. The design may be new, modified or outside the approved product model. CPQ can still capture requirements, estimate price, select a starting platform and initiate engineering work, but it may not be able to complete the design or generate a final production package by itself.

    Make-to-order (MTO) means production starts after an order but may use a standard or lightly configured product. Assemble-to-order (ATO) means standard components are assembled after the order. These models can overlap with CTO, but they describe different aspects of fulfillment and should not be treated as interchangeable labels.

    For an industrial heat exchanger, CPQ may support standard tube materials, connection sizes and pressure classes. If the required duty, footprint or code compliance falls outside approved limits, the opportunity may require ETO engineering. The system should make this boundary visible rather than allowing a salesperson to quote an apparently valid but technically unsupported design.

    Read more about these operating models in the manufacturing workflows guide.

    Can CPQ replace PLM?

    Usually, no. CPQ can contain product models, rules, options and even engineering information, but that does not make it a full PLM system. A CPQ platform may lack formal revision control, CAD file management, engineering change workflows, requirements management, document control or lifecycle governance.

    Likewise, PLM is not automatically a CPQ system. PLM may know which components are approved, but it may not provide customer-friendly guided selling, sales pricing, discount controls, quote templates, dealer workflows or commercial approval logic.

    Some platforms cover a broad part of both domains, and some manufacturers use a tightly integrated product configuration platform alongside PLM. Evaluation should focus on documented capabilities, system ownership and process fit rather than product category labels.

    Benefits of connecting CPQ and PLM

    • Fewer invalid quotes: sales users work from approved technical options and constraints.
    • Less duplicate product data: shared identifiers, attributes and revision references reduce manual re-entry.
    • Better engineering handoff: engineering receives structured requirements instead of interpreting free-text quote notes.
    • Faster CTO processing: approved configurations can flow toward BOM and order creation with fewer checks.
    • Controlled product changes: discontinued or superseded components can be removed from future selling models.
    • More accurate pricing: selected technical attributes can drive material, component and engineering cost logic.
    • Improved traceability: the business can relate a quoted configuration to an engineering revision and production record.

    Limitations and implementation risks

    Integration does not eliminate the need for product-model governance. Common risks include:

    • Unclear ownership: engineering, product management and sales each maintain different versions of options or components.
    • Over-simplified models: a sales option hides technical variables that are necessary for sizing, costing or production.
    • Excessive rule duplication: the same constraint is implemented differently in CPQ, PLM, ERP and CAD.
    • Revision mismatch: CPQ sells an option against one engineering revision while production uses another.
    • Incomplete BOM mapping: a quote contains commercial line items but no reliable component or assembly structure.
    • Unsupported ETO assumptions: the organization expects CPQ to design products that require engineering judgment.
    • Weak testing: combinations, boundary values, discontinued parts and revision transitions are not tested before release.
    • Uncontrolled custom logic: rules become difficult to understand and maintain when business exceptions are added without governance.

    Manufacturers should document the source of truth for each object: option, component, specification, CAD file, EBOM, configurable BOM, MBOM, price, cost, revision, customer requirement and approval status.

    Implementation approach for CPQ and PLM alignment

    1. Map the product and data lifecycle

    Document how a product moves from engineering definition to sellable model, quote, order, engineering review and production. Identify where each system creates, approves, changes and retires data.

    2. Separate customer language from engineering language

    Customers may ask for a high-temperature pump or a weatherproof enclosure. Engineering may need fluid temperature, pressure, material grade, ingress protection rating and certification requirements. CPQ should translate understandable questions into the technical parameters required for validation.

    3. Define configuration boundaries

    Mark which variants are CTO, which require application-engineering review and which are ETO. A clear boundary prevents a guided selling interface from presenting unsupported flexibility.

    4. Establish revision and effectivity rules

    Decide when a PLM revision becomes available for quoting, whether existing quotes retain the old revision, and how open opportunities are handled when an option is discontinued.

    5. Design the handoff payload

    Specify the information sent between systems. It may include product family, selected options, parameter values, component identifiers, quantities, revision references, calculated results, price, cost, customer requirements, documents and approval status.

    6. Test real combinations

    Testing should include normal configurations, incompatible options, minimum and maximum dimensions, obsolete components, regional restrictions, material substitutions, engineering overrides, price changes and revision transitions. Test both the rules and the resulting data structures.

    7. Assign ongoing ownership

    Product management may own sellable options, engineering may own technical constraints and released components, finance may own pricing policy, and manufacturing may own routing or MBOM requirements. These responsibilities should be explicit.

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

    How to evaluate CPQ and PLM architecture

    When comparing platforms or planning an integration, ask the following questions:

    • Can the CPQ system represent dimensions, ranges, dependencies, formulas and conditional components?
    • Does it support guided selling, rules-based configuration, constraint solving or a combination?
    • Which system owns the approved product definition and engineering revision?
    • Can the CPQ model reference PLM parts and revisions without copying uncontrolled data?
    • Can the system generate a configurable BOM, a selected BOM or only quote line items?
    • Can it calculate technical performance, or does it call an external engineering service?
    • Does it support CAD automation, drawings or 3D visualization, and are those capabilities documented?
    • How are CTO configurations separated from ETO requests?
    • How are ERP, CRM, PLM, PDM, CAD and MES integrations implemented and monitored?
    • Can administrators test, version and audit rules without depending on unrestricted custom code?
    • How are product changes communicated to sales users and existing opportunities?
    • What happens when a quote contains a component that is no longer released?

    Vendor claims should be checked against a representative product model, not a simple feature checklist. A manufacturer should use sample products with real constraints, calculations, options, revisions, pricing logic and downstream outputs during evaluation.

    Conclusion

    CPQ and PLM are complementary systems with different centers of gravity. Manufacturing CPQ manages the commercial and application-facing act of configuring a product for a customer, validating choices, calculating price and preparing a quote or order handoff. PLM manages the controlled engineering definition, documents, revisions, design relationships and product changes.

    The strongest architecture connects the two without pretending that one system performs every function. CPQ should expose only sellable and supportable choices. PLM should remain authoritative for engineering definitions and controlled changes. ERP, CAD, PDM, MES and other systems may contribute additional data or execute later stages of the process.

    For simple CTO products, the connection may be a relatively direct flow from approved options to a selected BOM and order. For complex ETO products, CPQ may capture requirements and commercial assumptions while PLM and engineering complete the design. In both cases, clear ownership, revision control, rules governance and realistic testing are more important than the system labels alone.

    Semantic map

    The article connects these entities and relationships:

    • CPQ connects customer requirements, product options, technical rules, pricing and quoting.
    • PLM connects engineering definitions, CAD data, revisions, approvals and lifecycle changes.
    • CPQ and PLM exchange product, component, revision and configuration information.
    • Configuration rules connect customer selections to valid technical combinations.
    • Technical parameters connect sales questions to engineering calculations.
    • Configured products connect selected options to BOM and order data.
    • EBOM connects engineering design structure to released product definitions.
    • MBOM connects production structure to manufacturing operations and assembly.
    • CTO connects approved configurations to repeatable order fulfillment.
    • ETO connects non-standard requirements to engineering review and design work.
    • ERP connects approved order and BOM data to planning, purchasing and fulfillment.
    • CAD connects product parameters to models, drawings and design outputs.

    Frequently asked questions

    What is CPQ in manufacturing?

    Manufacturing CPQ is software that helps users configure complex products, validate technical and commercial choices, calculate price or cost, and create quotes or order-ready data. Some platforms also support BOM generation, CAD automation or engineering calculations, but these capabilities are not universal.

    What is PLM in manufacturing?

    PLM is product lifecycle management software and process used to control engineering product definitions, CAD files, specifications, revisions, approvals, changes and lifecycle information.

    Is PLM the same as CPQ?

    No. CPQ is primarily focused on configuring and selling a valid product, while PLM is focused on defining, controlling and changing the engineered product. They may share product data and integrate in a manufacturing architecture.

    Can CPQ generate an engineering BOM?

    Some manufacturing CPQ systems can generate or select BOM structures, but not all can create an authoritative EBOM. The implementation must define whether CPQ generates a selected configuration, references a PLM EBOM or sends data to another system for engineering release.

    Can PLM calculate a sales price?

    PLM may contain cost or product attributes that support calculations, but it is not normally the primary system for customer pricing, discounts, commercial approvals and quote documents. CPQ or ERP commonly performs those functions.

    Does CPQ replace CAD?

    No. CPQ may call CAD automation, pass parameters to a CAD system or generate product-specific drawings when that capability is supported. CAD remains the system or tool used to create and manage detailed design geometry and drawings.

    How does CPQ use PLM data?

    CPQ may use approved part identifiers, product options, attributes, revisions, component relationships and technical limits from PLM. The data may be synchronized, referenced through an integration or transformed into a sales-oriented product model.

    Should PLM or CPQ own product options?

    Ownership depends on the option. PLM should generally own engineering parts, revisions and released design data. CPQ may own the commercial presentation of options, sales labels, pricing and guided-selling questions. Technical rules should have a clear authoritative owner.

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

    A configurable BOM represents possible variants and conditional components for multiple configurations. An EBOM represents an engineering product structure, usually with approved components and revisions. A CPQ selection may resolve a configurable BOM into a specific structure that references released engineering data.

    What is the difference between an EBOM and an MBOM?

    An EBOM describes how engineering defines the product. An MBOM describes how manufacturing plans to build it. The MBOM may regroup parts into kits, operations or workstations and may include manufacturing-specific items.

    Can CPQ support engineer-to-order products?

    CPQ can capture requirements, select a base product, estimate price and initiate engineering review for ETO work. It does not necessarily perform the detailed design or replace PLM and CAD processes required to create a new engineered product.

    How does CPQ support configure-to-order products?

    For CTO products, CPQ can present approved options, enforce constraints, calculate price and produce a selected configuration or BOM. The configuration can then flow to ERP or manufacturing systems, subject to the quality of the product model and integration.

    What happens when an engineering revision changes?

    The organization should define effectivity rules. A new revision may become available for future quotes while existing quotes retain the previous revision, or open opportunities may be migrated. CPQ and PLM must agree on status, timing and traceability.

    Why should CPQ rules not simply be copied from PLM?

    PLM and CPQ solve different user and process problems. PLM data may be too detailed for sales, while CPQ needs commercial rules and customer-friendly questions. Relevant engineering constraints should be reused or transformed carefully rather than copied without ownership.

    Can ERP replace CPQ and PLM?

    ERP manages resources, orders, inventory, purchasing, production and financial transactions. It may contain products and BOMs, but it does not necessarily provide deep configuration, engineering lifecycle management, CAD control or sales guidance. ERP, CPQ and PLM often perform complementary roles.

    How should a manufacturer choose between CPQ and PLM investments?

    Start with the main operational problem. If invalid quotes, slow configuration, inconsistent pricing and weak sales-to-engineering handoff are the priority, CPQ may be the nearer-term need. If uncontrolled revisions, CAD files, engineering changes and product definitions are the priority, PLM may be more urgent. Many complex manufacturers eventually require both.

    What should be tested in a CPQ-PLM integration?

    Test product options, constraints, component identifiers, revisions, effectivity dates, discontinued parts, BOM results, engineering review triggers, pricing, documents, failed messages and changes to released data. Use real product examples, including edge cases and ETO exceptions.

    What is the biggest CPQ-PLM implementation mistake?

    A common mistake is treating the project as a simple data synchronization exercise. The manufacturer must first define product-model ownership, configuration boundaries, revision behavior, engineering approval points and the exact data required by ERP, CAD and production.

  • CPQ vs ERP Product Configurator for Complex Manufacturing

    Manufacturing CPQ and an ERP product configurator are related technologies, but they are not interchangeable. A configure, price, quote system is usually designed to help sales, dealers or customers select a valid product, calculate a price and produce a quote. An ERP product configurator is usually designed to translate an order into operational data such as item selections, manufacturing bills of material, routings, work orders and purchasing requirements.

    For complex manufacturing, CPQ is generally the better front-end when configuration begins before an order exists and requires engineering rules, technical calculations, visual selection, proposal generation or guided selling. An ERP configurator is often the better execution layer when the order has been accepted and the business needs production, inventory, procurement, scheduling and financial transactions. Many manufacturers use both: CPQ manages commercial and engineering configuration, while ERP manages order fulfillment and production.

    The important question is not simply whether CPQ or ERP is better. It is which system should own each type of product data, rule, calculation, bill of material and workflow.

    What is manufacturing CPQ?

    Manufacturing CPQ is software for configuring complex products, calculating prices and costs, and generating accurate quotes. In manufacturing, CPQ can go beyond generic sales quoting. It may model product options, dimensional constraints, engineering formulas, compatible components, configurable bills of material, CAD outputs and the handoff from sales to engineering and production.

    For example, a pump manufacturer may use CPQ to select pump type, flow rate, head, motor size, materials, seals, connections and control equipment. The system can reject an unsuitable motor, calculate a duty point, select compatible components, create a preliminary bill of material and produce a quotation. Depending on the platform, it may also generate a product-specific drawing or send parameters to a computer-aided design system.

    Manufacturing CPQ capabilities vary considerably. Some products focus on guided selling and pricing. Others support constraint-based configuration, engineering calculations, configurable BOM generation, CAD automation and engineer-to-order workflows. Buyers should verify each capability rather than assume that it is included in every CPQ platform. See the manufacturing CPQ guide and the guide to product configuration and rules engines for more detail.

    What is an ERP product configurator?

    An enterprise resource planning system, or ERP system, manages operational transactions such as sales orders, inventory, purchasing, production, costing, shipping and financial accounting. An ERP product configurator is a module or extension that helps convert selected options and dimensions into an order-specific product structure.

    An ERP configurator may generate or select an item, bill of material, routing, operations, variants, quantities and planning data. It typically works close to the ERP item master, inventory records, work centers, suppliers and manufacturing processes. Its primary concern is often whether the business can manufacture, purchase, schedule and cost the ordered product using ERP-controlled data.

    An ERP configurator can be highly capable, especially when the product is configured after order entry and the ERP is the system of record for manufacturing. However, it may not provide the same sales experience, proposal workflow, product visualization, engineering calculations or dealer-facing configuration tools that a manufacturing CPQ platform provides. Capabilities differ by ERP product and implementation.

    CPQ vs ERP configurator: the central difference

    Criterion Manufacturing CPQ ERP product configurator
    Primary purpose Configure, price and quote a potential product or project Convert an accepted order into operational manufacturing data
    Typical users Sales engineers, dealers, application engineers and customers Order entry, production control, planning, purchasing and finance teams
    Process position Before or during opportunity and quotation After order capture and during fulfillment
    Configuration focus Customer requirements, technical feasibility and commercial options Manufacturing variant, item, BOM, routing and supply requirements
    Pricing Quote pricing, discounts, margins, freight and commercial approvals Product cost, standard cost, inventory valuation and order costing
    Engineering May include calculations, CAD automation, drawings and technical validation Usually consumes approved engineering and manufacturing data, although some ERP systems include engineering functions
    Output Quote, proposal, configuration, preliminary BOM and possibly CAD data Sales order, production BOM, routing, work order, purchase demand and fulfillment transactions

    The boundary is not absolute. Some CPQ systems create production-ready data, and some ERP configurators support customer-facing order entry. The comparison describes the common architectural pattern, not a universal product limitation.

    How the systems work together

    A common architecture uses CPQ for the commercial and technical front end and ERP for execution. A customer or sales engineer enters requirements in CPQ. The CPQ product model applies rules and constraints, calculates technical values, selects options, determines a price and produces a quote. When the quote becomes an order, CPQ sends the approved configuration to ERP through an integration or application programming interface, commonly called an API.

    1. Customer requirements are captured in CPQ.
    2. Configuration rules validate compatible options and required selections.
    3. Engineering calculations determine dimensions, ratings, capacities or component choices.
    4. CPQ calculates cost, price, discount limits and margin.
    5. A quote and technical proposal are produced.
    6. The accepted configuration is sent to ERP, often with an order, item references, attributes or a configurable BOM.
    7. ERP creates or confirms the sales order and generates manufacturing, purchasing and financial transactions.
    8. Production and fulfillment use ERP-controlled operational data.

    The integration must preserve configuration identity. A quote should not transfer only a descriptive text such as custom pump. It should transfer the selected options, dimensions, revisions, component references, quantities, engineering results, documents and any identifiers needed to reproduce the configuration. Otherwise, sales, engineering and production may interpret the same order differently.

    Product configuration is not the same as pricing

    Product configuration determines what can be sold or built. Pricing determines what the selected product should cost the customer. These functions are related but separate.

    A rule may state that a stainless-steel wetted part is required for a corrosive application. A pricing rule may add the cost of that material. A manufacturing rule may select a different process or routing. A commercial rule may apply a customer-specific discount. Keeping these rule types distinguishable makes the model easier to test and govern.

    Rules-based configuration

    Rules-based configuration uses explicit conditions such as if motor power exceeds a threshold, select a larger frame, or if voltage is 480 V, allow only compatible control equipment. It is effective when product knowledge can be expressed as clear dependencies and exclusions.

    Constraint-based configuration

    Constraint-based configuration evaluates relationships among requirements, options and technical limits. For example, a heat exchanger may need to satisfy flow, pressure, temperature, material and connection constraints simultaneously. The system may find valid combinations rather than merely follow a sequence of questions.

    Guided selling

    Guided selling simplifies the interaction for a user who may not know the technical product structure. It asks about application requirements and recommends or exposes suitable configurations. Guided selling is a user experience approach; it does not replace the underlying product rules or engineering validation.

    BOM ownership: EBOM, configurable BOM and MBOM

    A bill of material, or BOM, lists the components and quantities required for a product. An engineering BOM, or EBOM, represents the product from an engineering and design perspective. A manufacturing BOM, or MBOM, represents how production builds it, including manufacturing-specific groupings, consumables, operations or packaging. A configurable BOM is a structure containing selectable components, conditions and quantities that is resolved for a particular configuration.

    CPQ may create a sales or engineering-oriented configurable BOM. ERP may transform that result into an MBOM or use its own configurable structure to create production demand. Product lifecycle management, or PLM, and product data management, or PDM, systems may own approved engineering structures and revisions. These systems should not be treated as interchangeable.

    Manufacturers should define whether CPQ selects an existing ERP or PLM structure, creates a preliminary EBOM, sends a complete order BOM, or sends only configuration attributes that ERP resolves. Each approach has different integration, revision-control and testing requirements. More guidance is available in BOM generation, costing and quote automation.

    Engineering and CAD considerations

    Complex products often require more than option compatibility. A configured conveyor, pressure vessel, electrical enclosure or mobile vehicle may need dimensional calculations, load checks, drive selection, clearance validation or product-specific drawings.

    CPQ may perform simple calculations directly, call an engineering calculation service, or pass parameters to computer-aided design, or CAD, automation. A CAD system can generate geometry, drawings or models based on approved parameters. An ERP configurator may receive the resulting item and manufacturing data, but it is not automatically a CAD or engineering automation platform.

    Manufacturers should ask whether calculations are deterministic and reviewable, whether engineering assumptions are version-controlled, whether generated drawings require approval, and whether a failed calculation blocks quoting or creates an engineering task. The CAD and engineering automation guide covers these issues.

    CTO, ETO, MTO and ATO workflows

    Configure-to-order, or CTO, produces a product from predefined options and rules. CPQ is often valuable because it validates the customer selection and creates a repeatable configuration before the order reaches ERP.

    Engineer-to-order, or ETO, requires engineering work for a specific customer requirement. CPQ can capture requirements, calculate a preliminary design, identify exceptions and initiate an engineering review. It should not be presented as a substitute for engineering approval when the design is genuinely new.

    Make-to-order, or MTO, means production begins in response to an order rather than forecast stock. Assemble-to-order, or ATO, assembles stocked or standard modules after an order. An ERP configurator may be sufficient for straightforward ATO or CTO products already modeled in ERP. A CPQ layer becomes more valuable when configuration starts in sales, involves many commercial choices or requires engineering and quotation work.

    When an ERP configurator may be sufficient

    • The product has a limited number of options and simple dependencies.
    • Customers do not require a detailed technical proposal before ordering.
    • Configuration begins after order entry.
    • ERP already contains accurate item, BOM, routing and cost data.
    • There is little need for CAD automation or engineering calculation.
    • The sales channel is internal and does not require a sophisticated dealer or self-service experience.
    • The main objective is reliable production execution rather than faster pre-order engineering.

    Even in this situation, verify usability, rule maintainability, revision control, order-change handling, performance and integration with CRM, PLM or CAD where relevant.

    When manufacturing CPQ is usually justified

    • Sales engineers must configure products before a formal order exists.
    • Invalid combinations create expensive rework or customer delays.
    • Pricing depends on dimensions, materials, performance, options, logistics or project-specific costs.
    • Quotes require technical descriptions, drawings, approvals or multiple alternatives.
    • Dealers and distributors need controlled access to complex product knowledge.
    • Engineering must review exceptions rather than manually rebuild every quote.
    • Products support CTO and ETO paths with different handoffs.
    • Customers need web, portal or visual configuration experiences.

    Limitations and risks

    Adding CPQ does not automatically solve poor product data. If option definitions, component identifiers, prices and revisions are inconsistent, the manufacturer may create two conflicting models: one in CPQ and one in ERP. This increases governance effort.

    Duplicating rules is another risk. A voltage compatibility rule maintained differently in CPQ and ERP can produce an order that passes one system and fails in another. Where possible, establish a clear source of truth and use automated validation between systems.

    Integration timing also matters. Real-time availability, lead time, cost and engineering status may require different interfaces from relatively stable product rules. A quote may use estimated cost while ERP later confirms supply constraints. The business process should define how changes are communicated and approved.

    Implementation approach

    1. Map the current workflow. Document how a requirement becomes a quote, order, engineering package, BOM, routing and shipment.
    2. Classify products. Separate standard, CTO, ATO, MTO and ETO products rather than forcing every product into one model.
    3. Assign ownership. Decide whether CPQ, ERP, PLM, PDM or CAD owns each product attribute, rule, revision, BOM and document.
    4. Build a canonical product model. Define stable option identifiers, units, engineering values, effective dates and revision behavior.
    5. Separate rule types. Distinguish feasibility, recommendation, pricing, manufacturing and approval rules.
    6. Define handoff data. Specify what moves from CPQ to ERP: configuration ID, attributes, BOM, documents, prices, revisions, dates and approval status.
    7. Test representative complexity. Include standard products, boundary dimensions, incompatible materials, substitutions, obsolete options, engineering exceptions and order changes.
    8. Govern releases. Assign owners for product modeling, pricing, engineering rules, integrations and regression testing.

    Implementation planning should include adoption, data migration, integration monitoring and ongoing model maintenance. See the CPQ implementation guide and manufacturing CPQ integration guide.

    How to evaluate CPQ and ERP configurator options

    Question What to verify
    Can the system model the product? Options, attributes, dependencies, dimensions, revisions, substitutions and product families
    Can it validate engineering requirements? Rules, constraints, calculations, units, tolerances and exception workflows
    What BOM does it produce? Preliminary BOM, EBOM, configurable BOM, MBOM or only component attributes
    How is pricing calculated? Cost, price lists, discounts, currency, freight, margin and approval logic
    How does it integrate? ERP, CRM, PLM, PDM, CAD, product information management, MES and APIs
    Can the model be maintained? Ownership, testing, versioning, deployment, audit history and non-developer administration
    Which workflows are supported? CTO, ETO, MTO, ATO, dealer, distributor, ecommerce and internal sales engineering

    Do not compare products by feature count alone. A technically impressive configurator may still be unsuitable if its product model is difficult to maintain, its ERP handoff is weak, or it cannot represent the manufacturer’s actual engineering process. Vendor claims should be checked against demonstrations using the buyer’s own products and rules.

    Conclusion

    For complex manufacturing, CPQ and an ERP product configurator usually solve different parts of the same process. CPQ helps determine what can be configured, what it should cost and what should be presented to the customer. ERP helps turn the accepted result into an executable order, supply plan and production process. A strong architecture gives each system clear ownership and transfers an unambiguous configuration between them.

    An ERP configurator may be sufficient for stable products with simple options and transaction-focused order entry. Manufacturing CPQ is more appropriate when configuration affects engineering, pricing, proposals, CAD, customer interaction or sales-to-engineering handoff. In either case, success depends on product data quality, rule governance, revision control and disciplined integration.

    Semantic map

    • CPQ connects customer requirements with product configuration, pricing, quoting and engineering review.
    • ERP connects accepted orders with inventory, purchasing, production, costing and fulfillment.
    • Product configuration connects options, attributes, rules, constraints and valid product variants.
    • Engineering connects requirements and calculations with CAD models, drawings and approved product structures.
    • EBOM connects engineering design with components and design relationships.
    • MBOM connects manufacturing planning with operations, work centers and production components.
    • Integration connects CPQ configuration identity with ERP order and manufacturing data.

    Frequently asked questions

    Is CPQ the same as an ERP configurator?

    No. CPQ usually supports pre-order configuration, pricing and quoting, while an ERP configurator usually supports order execution and manufacturing data. Some products overlap.

    Can an ERP replace manufacturing CPQ?

    Sometimes. An ERP may be sufficient for simple, internally managed configuration. Complex sales engineering, pricing, CAD or proposal requirements often justify a separate CPQ layer.

    Does CPQ generate a production BOM?

    Some CPQ systems can generate or transmit a production-ready BOM, but this is not universal. Verify whether the output is an EBOM, configurable BOM, sales BOM or MBOM.

    Should CPQ or ERP own product rules?

    Ownership should follow the rule’s purpose and the architecture. CPQ may own sales and configuration rules, while ERP owns execution rules. Shared rules require clear governance to avoid conflicts.

    Can CPQ calculate manufacturing cost?

    Many manufacturing CPQ systems support costing, but depth varies. Confirm support for material, labor, overhead, purchased components, routing, freight and revision-specific costs.

    Does an ERP configurator support CAD automation?

    Not necessarily. CAD automation may be a separate CPQ, engineering or CAD capability. Verify the exact CAD systems, parameter handling, drawing generation and approval process.

    Which system should create the sales quote?

    CPQ commonly creates the customer-facing quote because it combines configuration, price, discounts, technical descriptions and approvals. ERP may create the sales order after acceptance.

    Which system should create the work order?

    ERP normally creates work orders because it manages production planning, inventory, purchasing and manufacturing execution data.

    How does CPQ support engineer-to-order manufacturing?

    It captures requirements, applies known rules, performs preliminary calculations, identifies exceptions and starts an engineering review. It does not eliminate engineering approval for new designs.

    Is a configurable BOM the same as an MBOM?

    No. A configurable BOM expresses selectable product structures. An MBOM represents how manufacturing builds the resolved product, including production-specific organization and operations.

    Should CPQ connect to PLM?

    It may need to. Product lifecycle management, or PLM, can provide approved product structures, revisions and engineering status. The required integration depends on data ownership and workflow.

    What is the role of CRM in this architecture?

    Customer relationship management, or CRM, manages accounts, opportunities and sales activities. CPQ may run inside or beside CRM, while ERP manages accepted orders and fulfillment.

    Can dealers use a manufacturing CPQ system?

    Yes, where the platform supports dealer roles, controlled product access, channel pricing, approvals and technical configuration. These capabilities must be verified for the selected system.

    What data should CPQ send to ERP?

    Typical data includes configuration ID, selected options, dimensions, quantities, prices, revisions, BOM information, documents, approvals and customer or project references.

    How should manufacturers handle price differences between CPQ and ERP?

    Define whether CPQ uses estimated or authoritative pricing, establish effective dates and synchronize price sources. Differences should create a controlled exception rather than an unexplained order change.

    Is guided selling a product configurator?

    Guided selling is an interaction method that recommends suitable choices. It may use a product configurator underneath, but it does not replace the product model, constraints or engineering validation.

    What is the biggest implementation risk?

    A major risk is creating duplicate, inconsistent product models and rules in CPQ and ERP. Clear ownership, shared identifiers, integration testing and release governance reduce this risk.

    How should buyers compare CPQ and ERP configurators?

    Use representative products and test configuration depth, calculations, BOM output, pricing, CAD, ETO handling, integrations, maintainability, performance and production handoff rather than relying on generic feature lists.

  • Manufacturing CPQ Process Flow from Customer Need to Quote

    A manufacturing CPQ process flow takes a customer need and turns it into a technically valid, manufacturable and commercially accurate quote. CPQ means configure, price, quote. In manufacturing, the process can include product configuration rules, engineering calculations, CAD automation, bill of materials generation, costing, pricing, approvals and integration with enterprise systems.

    The flow is usually: capture requirements, select or build a product configuration, validate technical constraints, perform engineering calculations, generate product and manufacturing data, calculate cost and price, prepare the quote, obtain approvals and hand the approved configuration into order execution. The exact sequence varies by product and business model. A standard configure-to-order product may follow an automated path, while an engineer-to-order product may require engineering review before a quote is released.

    This is different from generic sales CPQ, which may focus mainly on selecting commercial options, applying discounts and producing a proposal. Manufacturing CPQ must also answer whether the product can be built, which components are required, how it should be engineered and what data production needs. The manufacturing CPQ guide provides broader context on this category.

    What is the manufacturing CPQ process flow?

    The manufacturing CPQ process flow is the controlled sequence used to convert customer requirements into a validated product definition and quote. It connects commercial activity with product engineering and operations.

    Stage Primary question Typical output
    1. Customer need What must the product do? Requirements, application data and target specifications
    2. Product configuration Which valid product choices meet the need? Configured product and selected options
    3. Technical validation Can the selected combination work safely and correctly? Validated configuration, warnings or engineering tasks
    4. Engineering definition What product-specific design is required? Calculations, dimensions, CAD data, drawings or engineering instructions
    5. BOM and manufacturing data Which parts and assemblies are needed? Configurable BOM, EBOM, MBOM or manufacturing package
    6. Cost and price What will the product cost and what should the customer pay? Cost breakdown, price, discounts and margins
    7. Quote and approval How should the offer be presented and controlled? Customer quote, assumptions, lead time and approvals
    8. Handoff How does the approved result enter execution? Order, ERP transaction, engineering job or production release

    Stage 1: Capture the customer need

    The process begins before a product option is selected. A salesperson, dealer, application engineer or customer may describe the required duty, environment and operating conditions rather than naming a specific model.

    For a pump manufacturer, the requirements might include flow rate, pressure, fluid type, temperature, material compatibility, motor voltage, installation arrangement and regulatory requirements. For industrial machinery, they may include throughput, workpiece dimensions, available floor space, cycle time, safety requirements and automation interfaces.

    A manufacturing CPQ application can capture these requirements through guided questions, technical input fields, imported data or a dealer portal. Guided selling presents questions in an order that helps the user reach an appropriate product family. It is not the same as a rules engine: guided selling helps select a suitable solution, while configuration rules determine whether selected features are technically compatible.

    Requirements should be represented as structured data wherever possible. Free-text notes can preserve context, but they are difficult to validate and cannot reliably drive calculations, BOM selection or CAD automation.

    Important requirement data

    • Application and operating conditions
    • Required capacity, performance or duty point
    • Dimensions, weights and connection standards
    • Materials, coatings and environmental conditions
    • Power, voltage, controls and communication requirements
    • Compliance, certification and documentation needs
    • Delivery location, quantity and requested date
    • Customer-specific standards or approved components

    Stage 2: Select the product family and configure the product

    Once the need is structured, the user selects a product family and configures its features. A product model defines available options, attributes, components, rules and relationships. The model may represent a pump, valve assembly, air-handling unit, conveyor, electrical cabinet, trailer or complete production machine.

    Configuration can use several approaches:

    • Rules-based configuration: explicit rules allow, require or prohibit options. For example, a high-temperature seal may require a specific material and exclude a standard elastomer.
    • Constraint-based configuration: the system evaluates relationships and limits across many variables. For example, motor power, impeller diameter, frame size and flow may need to remain within engineering limits.
    • Guided selling: questions narrow the product choice based on customer requirements. The result may then be checked by configuration rules.

    A configuration model should distinguish commercial options from technical attributes. A customer may choose a stainless-steel housing as an option, while the resulting wall thickness, fastener material and manufacturing operation are derived values that the customer never selects directly.

    The product configuration guide explains product models, dependencies, constraints and configuration validation in more detail.

    Stage 3: Validate technical constraints

    Validation prevents a quote from being created for a product that cannot be built, will not perform as required or violates a company policy. Validation may happen continuously as the user configures the product or as a formal review before quoting.

    Typical rules include:

    • an option requires another option;
    • two materials or components are incompatible;
    • a dimension must remain within a defined range;
    • a motor must match the voltage and load;
    • a pressure rating must exceed the application requirement;
    • a selected component is unavailable for a particular product family;
    • a certification requires specific construction or documentation;
    • a customer-specific standard limits approved suppliers or parts.

    Validation can produce errors, warnings or review tasks. An error blocks the configuration. A warning may allow the user to proceed while recording an assumption. A review task routes the case to engineering, compliance, purchasing or another specialist.

    Rules should be tested against valid and invalid combinations. A large rule set can become difficult to maintain if rules are duplicated, embedded in code without documentation or owned by no clear business team. Product configuration governance is therefore as important as the rule technology.

    Stage 4: Perform engineering calculations and design automation

    Some products can be selected from a fixed catalog. Others require calculations that determine product dimensions or components. Manufacturing CPQ may perform these calculations directly, call an engineering service or create a task for an engineer.

    For a pump, calculations may determine required head, power, impeller selection and operating range. For a heat exchanger, they may calculate surface area and connection sizes. For a conveyor, they may determine frame length, belt width, drive requirements and support spacing. For a vehicle body, they may calculate clearances, payload effects and mounting requirements.

    Design automation can use these results to create a product-specific design. Parametric computer-aided design, or CAD, systems can update dimensions and component selections. The output may include a three-dimensional model, a two-dimensional drawing, a specification sheet or manufacturing instructions. Not every CPQ platform includes CAD automation, so this capability must be verified separately.

    Engineering automation is particularly valuable when the same design logic is repeated across many orders. However, it requires governed engineering formulas, compatible CAD templates, reliable input data and a process for handling cases outside the automation envelope. The CAD and engineering automation guide covers these relationships.

    Stage 5: Generate the bill of materials and manufacturing data

    A validated configuration can drive a bill of materials, or BOM. A BOM is a structured list of the components, materials and quantities required for a product or assembly. In a manufacturing CPQ process, BOM generation may be immediate, conditional or delegated to an ERP, product lifecycle management system or engineering system.

    Several BOM concepts should be distinguished:

    • Configurable BOM: a product structure containing optional, conditional or variable components that are resolved for a particular configuration.
    • EBOM: an engineering bill of materials, organized around the designed product and engineering relationships.
    • MBOM: a manufacturing bill of materials, organized around how the product is assembled or produced.

    An industrial machine might have one configured product definition, an EBOM describing the designed assembly and an MBOM that adds work instructions, packaging, consumables or production-specific grouping. These structures may be related but are not interchangeable.

    CPQ may also derive routings, labor assumptions, purchased components, alternates, tooling requirements and documentation. In other implementations, CPQ creates a configuration identifier and passes the commercial result to an enterprise resource planning system, or ERP, which owns the official item and BOM transaction.

    The BOM, pricing and quoting guide explains how configurable BOMs connect to costing and quote generation.

    Stage 6: Calculate cost, price and lead time

    Costing and pricing are related but different activities. Costing estimates the internal resources required to produce the configured product. Pricing determines what the customer is charged.

    Cost inputs may include materials, purchased parts, labor, machine time, subcontracting, freight, tooling, engineering effort, warranty exposure and overhead allocations. Pricing may apply list prices, customer agreements, regional adjustments, quantity breaks, project discounts, channel margins, surcharges and target margin rules.

    A manufacturing CPQ process should make clear which values are calculated, which are retrieved from a source system and which can be overridden. For example, material cost may come from ERP, a standard component price may come from a product information management system, and a project discount may require sales management approval.

    Lead time can also be configuration-dependent. A standard motor may be available from stock, while a custom coating, nonstandard material or engineered frame may add procurement and production time. A quote that shows price without realistic delivery assumptions is incomplete for many industrial buyers.

    Stage 7: Generate the quote and manage approvals

    The quoting stage turns the validated commercial result into a customer-facing document. A manufacturing quote commonly contains:

    • configured product description and option summary;
    • technical specifications and performance data;
    • quantities, unit prices and total price;
    • discounts, surcharges, taxes or freight assumptions;
    • estimated lead time and delivery terms;
    • scope boundaries, exclusions and customer responsibilities;
    • warranty, validity period and payment terms;
    • drawings, images, datasheets or compliance documents when appropriate.

    Approval workflows should be based on business risk, not only price. A quote may need engineering approval for a nonstandard operating point, finance approval for a low margin, legal approval for unusual terms or operations approval for a capacity constraint.

    Document generation should use the same configuration and pricing data used to create the quote. Re-keying selected options into a word processor or spreadsheet creates a risk that the document will not match the product being offered.

    Stage 8: Handoff from quote to order and production

    When the customer accepts the quote, the approved configuration becomes an order candidate or an engineering release. The handoff depends on the manufacturing workflow.

    Workflow Typical CPQ handoff Example
    Configure-to-order (CTO) Validated configuration, item identifiers and resolved BOM enter order processing Standard pump package with selectable materials and motor sizes
    Engineer-to-order (ETO) Requirements, calculations and engineering tasks create a project-specific design Large custom material-handling machine
    Make-to-order (MTO) Demand triggers procurement or production after order acceptance Configured electrical enclosure built after approval
    Assemble-to-order (ATO) Standard modules are combined after order receipt Modular conveyor assembled from stocked sections

    The handoff may involve customer relationship management, or CRM, for the opportunity and account; ERP for order, inventory, purchasing and financial transactions; product lifecycle management, or PLM, for product definitions and revisions; product data management, or PDM, for CAD files and documents; manufacturing execution systems, or MES, for production execution; and CAD for design outputs. These systems have different responsibilities and should not be treated as interchangeable.

    The manufacturing workflow guide explains CTO, ETO, MTO and ATO processes, while the CPQ integration guide covers system boundaries and data exchange.

    How the process differs by manufacturing environment

    Configure-to-order

    CTO works best when the product architecture, options and manufacturing structures are known in advance. Automation can validate selections, resolve a BOM, calculate price and create an order with limited manual engineering.

    Engineer-to-order

    ETO begins with a customer need but requires project-specific design. CPQ can capture requirements, identify a product platform, calculate preliminary dimensions, estimate engineering effort and create a controlled handoff. It should not be presented as fully automated if engineers must still design and approve the product.

    Dealer and distributor sales

    Dealer users may need a simplified interface, controlled access to prices and product guidance without seeing internal costs or engineering rules. The manufacturer must still ensure that the resulting configuration can be produced and supported.

    Self-service and ecommerce

    Self-service configuration can work for bounded products with clear rules, stable pricing and predictable fulfillment. Products requiring application engineering, site surveys or safety review may need a hybrid workflow that routes complex cases to specialists.

    Systems and data architecture

    A manufacturing CPQ solution commonly sits between customer-facing channels and engineering or enterprise systems. The CPQ application may own the configuration session and quote, while other systems remain authoritative for specific data.

    System Typical responsibility
    CRM Accounts, contacts, opportunities and sales activity
    CPQ Configuration session, rules, calculations, pricing logic and quote
    ERP Items, inventory, purchasing, orders, finance and operational costing
    PLM Product structures, revisions, change processes and lifecycle governance
    PDM CAD files, engineering documents and controlled design data
    CAD Parametric models, drawings and design outputs
    PIM Product attributes, descriptions, media and channel content
    MES Production dispatch, execution, quality and shop-floor records

    In practice, ownership must be agreed for each data object. For example, CPQ may calculate a configuration-specific option set, PLM may own released engineering structures, ERP may own sellable item numbers and costs, and CAD may generate the geometric model. Integration should transfer identifiers, revisions, quantities, units and status as well as descriptive text.

    Benefits of a controlled manufacturing CPQ flow

    • Fewer configuration errors: rules prevent incompatible options from reaching the quote.
    • Faster response: repeatable calculations and document generation reduce manual work.
    • More consistent pricing: cost and price logic is applied systematically.
    • Better engineering leverage: engineers spend less time answering repetitive selection questions.
    • Improved production handoff: approved configurations can carry structured BOM and specification data.
    • Traceability: the company can record who configured, reviewed and approved the quote.
    • Improved channel control: dealers can sell complex products within defined technical and commercial boundaries.

    Limitations and common failure points

    CPQ does not eliminate product complexity. It exposes and formalizes it. Implementation can be difficult when product options are poorly defined, engineering knowledge exists only in documents, prices are maintained in disconnected spreadsheets or BOM ownership is unclear.

    Common failure points include:

    • trying to automate products whose engineering rules have not been documented;
    • treating every custom request as a simple option;
    • using one product structure for sales, engineering and manufacturing without mapping their differences;
    • allowing uncontrolled manual overrides;
    • ignoring units, revisions, effective dates and regional variations;
    • building integrations before agreeing on data ownership;
    • failing to test negative cases and unusual but valid applications;
    • assuming that a vendor’s generic CPQ capability includes CAD, BOM, ETO or PLM functions.

    Some configurations should remain subject to engineering review. A good process makes the boundary visible and routes exceptions deliberately rather than hiding them in manual workarounds.

    Implementation considerations

    Manufacturers should begin with a defined product family and a measurable workflow problem. Map the current process from customer inquiry through quote and order release. Identify where users re-enter data, where errors occur, which decisions require engineering and which systems own the relevant information.

    Before building the model, document:

    • features, options, attributes and valid ranges;
    • dependencies, exclusions and required combinations;
    • engineering formulas and their owners;
    • component selection and BOM logic;
    • cost sources, price rules and approval thresholds;
    • quote templates, assumptions and revision controls;
    • interfaces to CRM, ERP, PLM, PDM, CAD, PIM and MES;
    • exception paths for ETO and nonstandard requests.

    Use representative examples for testing: a normal configuration, an invalid combination, a boundary value, a discontinued component, a revision change, a low-margin quote and an ETO case. Test not only the user interface but also the outputs: configuration identifier, BOM, CAD file, price, lead time, quote document and downstream transaction.

    Ownership should continue after deployment. Product management may own commercial options, engineering may own technical rules, manufacturing may own assembly logic, finance may own pricing policy and IT may own integrations. A release and change-control process is necessary when products, components, suppliers or regulations change.

    The CPQ implementation guide covers requirements, migration, testing, governance, adoption and maintenance. Buyers evaluating platforms can also use the manufacturing-focused CPQ comparison and selection resources.

    How to measure the process

    Useful measures should cover speed, quality and downstream usefulness rather than quote volume alone. Possible measures include quote cycle time, percentage of quotes requiring engineering intervention, configuration error rate, quote-to-order conversion, margin variance, time from order to engineering release, percentage of orders requiring rework and the proportion of BOM data accepted without manual correction.

    Metrics need clear definitions. For example, quote cycle time may begin when all required technical inputs are available rather than when an incomplete inquiry first arrives. Otherwise, the measure may encourage premature quotes instead of accurate ones.

    Conclusion

    A manufacturing CPQ process flow connects customer requirements to a valid product, an engineering definition, manufacturing data, cost, price and a controlled quote. The strongest implementations do not treat CPQ as a document generator. They establish a reliable product model, make configuration rules explicit, separate EBOM and MBOM responsibilities, automate appropriate engineering work and exchange governed data with CRM, ERP, PLM, PDM, CAD and MES systems.

    The right level of automation depends on the product. Standard CTO products may support near-real-time configuration and order handoff. ETO products may use CPQ to structure requirements and accelerate preliminary engineering while retaining expert review. In both cases, the objective is the same: provide a commercially accurate offer that the manufacturer can build, deliver and support.

    Semantic map

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

    • Customer requirements lead to product configuration.
    • Product configuration is evaluated by configuration rules.
    • Configuration rules prevent invalid combinations.
    • Engineering calculations determine product-specific parameters.
    • Validated configurations generate configurable BOMs.
    • EBOMs describe engineered product structures.
    • MBOMs describe manufacturing assembly structures.
    • CAD automation generates product-specific design outputs.
    • Costing estimates resources required to build the product.
    • Pricing converts cost and commercial policy into a customer price.
    • CPQ generates quotes from configuration and pricing data.
    • CRM stores opportunity and customer context.
    • ERP manages orders, inventory, purchasing and financial transactions.
    • PLM governs product definitions, revisions and lifecycle changes.
    • MES supports production execution after order release.
    • ETO requires engineering review for project-specific designs.

    Frequently asked questions

    1. What is a CPQ process flow in manufacturing?

    It is the sequence that converts customer requirements into a validated configuration, engineering and manufacturing data, cost, price and a formal quote.

    2. What does CPQ stand for?

    CPQ stands for configure, price, quote. In manufacturing, configure may include technical validation and engineering outputs in addition to selecting commercial options.

    3. How does manufacturing CPQ differ from sales CPQ?

    Sales CPQ often concentrates on product selection, discounts and proposals. Manufacturing CPQ may also manage constraints, calculations, BOMs, CAD outputs, costing and production handoff.

    4. What happens first in the CPQ process?

    The process starts by capturing structured customer requirements such as duty, dimensions, materials, environment, performance and compliance needs.

    5. What is the role of configuration rules?

    Configuration rules define valid and invalid combinations, required options, exclusions, ranges and technical dependencies.

    6. Is guided selling the same as product configuration?

    No. Guided selling asks questions to recommend a product or configuration path. Product configuration validates the selected features and their technical relationships.

    7. Can CPQ generate a bill of materials?

    Some manufacturing CPQ systems generate or resolve BOMs, while others pass configuration data to ERP, PLM or another system that owns the BOM. This capability must be verified for each platform.

    8. What is the difference between an EBOM and an MBOM?

    An EBOM represents the engineered product structure. An MBOM represents how the product is assembled or produced. They may contain different groupings, parts and manufacturing information.

    9. Does every CPQ system include CAD automation?

    No. CAD automation may be a native capability, an integration or an external engineering service. Buyers should verify supported CAD systems, templates, outputs and revision handling.

    10. How does CPQ support engineer-to-order products?

    CPQ can capture requirements, select a product platform, perform preliminary calculations, estimate engineering effort and create a controlled engineering handoff. It does not necessarily replace project engineering.

    11. How does CPQ calculate manufacturing prices?

    It can combine material, labor, purchased-component, freight, engineering and overhead inputs with price lists, margins, discounts, surcharges and approval rules.

    12. Which systems commonly integrate with manufacturing CPQ?

    Common integrations include CRM, ERP, PLM, PDM, CAD, PIM and MES. The exact scope depends on the product model and the responsibilities assigned to each system.

    13. What information should appear in a manufacturing quote?

    A quote should normally include the configured product, technical specifications, quantities, price, lead time, assumptions, exclusions, terms and relevant drawings or documentation.

    14. Why are manufacturing CPQ implementations difficult?

    They require product rules, engineering knowledge, pricing data, BOM logic, system ownership and exception handling to be made explicit and maintained over time.

    15. Should every configuration be fully automated?

    No. Standard, repeatable configurations are good automation candidates. Novel, safety-critical or highly customized designs may require engineering review.

    16. What is the difference between CTO and ETO?

    Configure-to-order uses predefined product structures and options. Engineer-to-order requires project-specific engineering before or during order fulfillment.

    17. How does CPQ support configure-to-order production?

    It validates options, resolves the configuration, calculates price and can pass item, BOM and specification data into order and production systems.

    18. What should be tested before launching a CPQ process?

    Test valid, invalid, boundary, discontinued, revised, low-margin and ETO scenarios, including the resulting configuration, BOM, price, quote, CAD output and downstream transactions.

    19. Who should own manufacturing CPQ rules?

    Ownership is usually shared: product management for commercial options, engineering for technical rules, manufacturing for assembly logic, finance for pricing and IT for integrations.

    20. What is the main objective of manufacturing CPQ?

    The objective is to create an accurate, technically valid and commercially acceptable offer that the manufacturer can reliably build, deliver and support.

  • Manufacturing CPQ Implementation Guide

    Implementing manufacturing CPQ is a product-modeling and operational transformation project, not simply a software installation. A successful implementation connects configurable products, engineering rules, pricing, quotations and downstream manufacturing data while preserving clear ownership of product information.

    CPQ means configure, price, quote. In a manufacturing environment, the system may also validate technical requirements, calculate dimensions or performance, generate a configurable bill of materials (BOM), create engineering outputs and exchange order data with enterprise systems. The exact scope depends on the selected platform and the manufacturer’s processes; not every CPQ product supports CAD automation, engineering calculations, BOM generation or engineer-to-order workflows.

    The recommended approach is to begin with a defined product and process scope, establish a governed product model, separate configuration from pricing logic, integrate systems through explicit data contracts, test realistic product combinations and roll out in controlled stages. The implementation should be owned jointly by sales, engineering, manufacturing, finance and information technology rather than by sales operations alone.

    What manufacturing CPQ implementation involves

    Manufacturing CPQ implementation is the process of designing, configuring, integrating, testing and deploying a CPQ system so that it can produce valid commercial and technical outputs for configurable products.

    A manufacturing implementation typically covers several connected capabilities:

    • Product configuration: selecting valid models, options, dimensions, materials, accessories and performance characteristics.
    • Rules and constraints: preventing incompatible combinations and deriving required components or settings.
    • Engineering calculations: sizing or validating products when supported by the platform or connected engineering services.
    • Pricing and costing: calculating list prices, discounts, surcharges, estimated costs, margins and currencies.
    • Quoting: generating commercial quotations, proposals, approvals and validity dates.
    • Manufacturing data: producing a configurable BOM, engineering bill of materials (EBOM), manufacturing bill of materials (MBOM), routing information or order attributes where supported.
    • CAD and documents: creating drawings, models or technical documents through CAD automation or connected applications where available.
    • Integration: exchanging data with customer relationship management (CRM), enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), manufacturing execution systems (MES), product information management (PIM) systems and CAD tools.

    This is broader than generic sales CPQ, which may focus mainly on selecting commercial products, applying discounts and producing a proposal. A manufacturing CPQ project must also address technical validity, engineering ownership, production requirements and the lifecycle of product rules. The manufacturing CPQ guide provides a broader overview of this distinction.

    Define the implementation scope before selecting features

    Manufacturers often start with an ambitious list that includes configuration, visual selection, calculations, CAD, BOMs, costing, pricing, dealer portals and ERP integration. Treating every capability as a first release increases modeling and testing risk. Define the business problem and release boundaries first.

    Document the current process

    Map how a quote is created today. Identify where a salesperson selects options, where an application engineer checks feasibility, where prices are calculated, where a BOM is created and how the order reaches production. Record manual spreadsheets, email approvals, engineering overrides and duplicate data entry.

    For an industrial pump manufacturer, the process may include selecting flow, head, fluid, temperature, materials, motor type, seal arrangement and connection standard. A valid selection may require a hydraulic calculation, a motor check, a material compatibility rule, a pump assembly BOM and a customer-specific price. Each activity should be assigned to a system or person rather than assumed to belong in CPQ.

    Choose a focused first product family

    A good pilot product has meaningful configuration complexity, visible commercial value and reasonably reliable source data. Avoid beginning with an entire portfolio containing unrelated product families, inconsistent part numbering and undocumented exceptions.

    Define whether the initial release supports configure-to-order (CTO), make-to-order (MTO), assemble-to-order (ATO) or engineer-to-order (ETO). CTO uses predefined options and rules. ATO assembles stocked subassemblies or modules. MTO produces a configured product after the order. ETO requires new or substantially modified engineering work for a particular order. A CPQ system may support more than one model, but the data and workflow requirements differ.

    Establish the implementation team and decision rights

    CPQ product models contain commercial, technical and operational decisions. A cross-functional team should therefore include:

    • a business owner responsible for measurable outcomes;
    • a product manager or configuration owner responsible for product structure;
    • sales or application engineering representatives who understand customer requirements;
    • design and manufacturing engineering representatives;
    • pricing, costing and finance representatives;
    • ERP, CRM, PLM, PDM, CAD and integration specialists as applicable;
    • quality assurance and data migration personnel;
    • change management and training owners.

    Define who can approve a new option, change a compatibility rule, modify a price, release a CAD template or change an ERP mapping. Without decision rights, the system becomes a collection of undocumented exceptions. The CPQ implementation and governance guide can be used to structure roles, milestones, testing and operational ownership.

    Build a manufacturing product model

    The product model is the structured representation of what can be sold and how it behaves. It should not be a direct copy of a marketing brochure or a flat list of part numbers.

    Separate product concepts

    Product-model element Purpose Industrial example
    Product family Groups related products with common logic Horizontal centrifugal pumps
    Feature or parameter Captures a customer or engineering decision Flow rate, voltage or enclosure rating
    Option Represents a selectable value or component Stainless-steel casing
    Dependency Connects one selection to another A high-temperature seal requires a compatible material
    Constraint Prevents an invalid combination A motor cannot be selected below the calculated power requirement
    Derived value Calculates or assigns a result from inputs Recommended impeller diameter
    Output mapping Translates selections into downstream data ERP item, BOM component or CAD parameter

    Keep customer-facing language separate from internal codes. A user may select “outdoor stainless enclosure,” while the system must map that choice to an approved item, engineering attribute and ERP value. This separation supports clearer interfaces and reduces disruption when internal part numbering changes.

    Model rules in layers

    Use different rule types for different decisions:

    • Selection rules determine which options are visible or available.
    • Validation rules identify invalid combinations, such as incompatible voltage and motor selections.
    • Dependency rules add required accessories, components or features.
    • Calculation rules derive dimensions, capacities, quantities or performance values.
    • Commercial rules apply prices, discounts, surcharges and approval thresholds.
    • Output rules map a configuration to a BOM, drawing parameter, ERP material or manufacturing instruction.

    Rules-based configuration evaluates explicit conditions. Constraint-based configuration evaluates relationships and permissible values, which can be more appropriate for products with many interacting technical variables. Guided selling helps a user arrive at a product by asking questions in a controlled sequence, but it does not by itself replace engineering constraints. These approaches can coexist and should not be treated as interchangeable.

    Prepare and govern product data

    Most implementation difficulty comes from incomplete or contradictory product data rather than from the configuration screen. Before modeling, create a source-of-truth inventory for options, components, prices, units, revisions, documents and engineering constraints.

    Important preparation activities include:

    1. identify duplicate and obsolete part numbers;
    2. standardize units, naming, currencies and attribute values;
    3. identify effectivity dates and product revisions;
    4. classify options as configurable, mandatory, derived, obsolete or engineering-only;
    5. document approved substitutes and regional variations;
    6. separate standard products from ETO exceptions;
    7. define ownership for product, price, engineering and manufacturing data;
    8. record the source system for each attribute and identifier.

    Do not migrate every historical exception into the new model. A quote history may contain one-off engineering decisions that should remain controlled exceptions rather than become permanent selectable options. Data migration should preserve required history while creating a cleaner structure for future transactions.

    Design pricing, costing and quoting separately from configuration

    Configuration answers whether and how a product can be built. Pricing determines what the customer is charged. Costing estimates the economic impact of the configuration. Quoting presents the result commercially. These concerns are related but should be designed separately.

    A configured machine might require a base model price, option prices, material surcharges, freight, installation, commissioning and a project-specific discount. Its estimated cost may include purchased components, labor, manufacturing overhead and external services. The quote may also require approval if the margin falls below a threshold.

    Define:

    • price books and effective dates;
    • customer, region, currency and channel rules;
    • discount authority and approval levels;
    • cost sources and whether costs are estimates or actual values;
    • tax, freight, installation and service treatment;
    • quotation revisions, expiration dates and audit history;
    • how prices are synchronized with ERP or finance systems.

    Pricing data should not be embedded invisibly in configuration rules. A rule stating that a 400-volt motor is required for a certain configuration is technical. A rule applying a regional surcharge to that motor is commercial. Keeping these concerns distinct makes testing and future price changes safer. See the guide to BOM generation, pricing and quote automation for related design considerations.

    Design BOM, CAD and engineering outputs

    A bill of materials is a structured list of components. An engineering bill of materials (EBOM) describes the product from an engineering perspective, while a manufacturing bill of materials (MBOM) organizes components for production. A configurable BOM may contain rules that include, exclude or quantity-adjust components based on the selected configuration.

    Decide whether CPQ will:

    • create a sales or reference BOM only;
    • generate an EBOM for engineering review;
    • produce or contribute to an MBOM;
    • send component selections to ERP or PLM;
    • trigger an engineering workflow for non-standard requirements.

    Do not assume that a CPQ-generated BOM is automatically production-ready. Manufacturing may need routings, work centers, effectivity, packaging, quality instructions and plant-specific substitutions that belong in ERP, PLM or MES. Define which system owns each downstream structure.

    CAD automation can generate product-specific models, drawings or documents by passing configuration parameters to a CAD system or template. This requires stable parameter names, validated design templates, controlled revisions and error handling. If CAD automation is not supported, CPQ may instead produce engineering inputs for a separate design process. The CAD and engineering automation guide explains these distinctions.

    Plan the integration architecture

    CPQ rarely replaces the systems that manage all enterprise data. It should exchange the right data with each system and avoid becoming an uncontrolled master for information owned elsewhere.

    System Typical relationship with CPQ Questions to resolve
    CRM Opportunity, account, contact and quote context Which system owns the opportunity and quote status?
    ERP Items, prices, customers, orders, inventory and financial data How are configured items and orders represented?
    PLM Product revisions, engineering structures and release status Which released attributes and structures can CPQ use?
    PDM CAD files, documents and design metadata How are approved files and revisions referenced?
    CAD Parameters, models, drawings and technical outputs What inputs are required and how are failures handled?
    PIM Product descriptions, media and channel content Which system owns customer-facing content?
    MES Production execution data and manufacturing status Does CPQ send production instructions or only order data?

    Specify identifiers, data ownership, interface direction, timing, error handling, security and version behavior for every integration. A synchronous API may be appropriate for validation or pricing, while batch synchronization may be sufficient for catalog data. The CPQ integration guide covers these system boundaries in more detail.

    Build and test the product model

    Testing must cover more than whether a user can complete a quote. It should confirm that the configuration is technically valid, commercially accurate and usable by downstream teams.

    Use structured test cases

    Create test cases from real products, historical quotes, engineering calculations and known failure modes. Include:

    • minimum and maximum dimensions;
    • each required option and major option family;
    • incompatible materials, voltages, pressures or ratings;
    • regional, currency and customer-specific pricing;
    • substitutions and obsolete components;
    • calculation boundary conditions;
    • standard CTO configurations;
    • ETO triggers and manual engineering review;
    • ERP, CRM, PLM, CAD or document-generation failures;
    • revisions made after a quote has been issued.

    Test in layers

    1. Unit testing: test individual rules, calculations and mappings.
    2. Model testing: test interactions among features, options and constraints.
    3. Integration testing: verify messages, identifiers, revisions and error responses between systems.
    4. End-to-end testing: configure, price, approve, quote, order and produce representative products.
    5. User acceptance testing: have sales, engineering, manufacturing and finance perform real tasks.
    6. Regression testing: repeat a controlled test suite after every significant model or integration change.

    Test both valid and invalid configurations. A system that produces a quote quickly but allows an impossible pump, unsafe electrical combination or incomplete machine BOM has not passed manufacturing acceptance.

    Plan rollout, adoption and operational support

    Rollout should reflect the organization’s ability to maintain the model. A phased deployment may begin with internal application engineers, then expand to sales, dealers, distributors or customers. Each phase should have explicit entry and exit criteria.

    Training should explain not only which buttons to use, but why the system asks particular questions, what an error means and when to request engineering review. Provide different guidance for sales users, application engineers, product administrators, pricing specialists and integration support.

    During hypercare, monitor configuration failures, manual overrides, quote rework, approval queues, integration errors and questions from users. A temporary support process should identify whether an issue is a data defect, a rule defect, a user-interface problem, a training gap or a legitimate product exception.

    Governance and lifecycle maintenance

    Manufacturing products change continuously. New motors, materials, suppliers, standards, plants, currencies and customer requirements can make a CPQ model inaccurate unless changes are controlled.

    Establish a release process that includes:

    • change request and business justification;
    • impact analysis across rules, prices, BOMs, CAD and integrations;
    • review by technical and commercial owners;
    • versioning and effectivity dates;
    • automated and manual regression testing;
    • deployment approval and rollback planning;
    • communication to affected users;
    • post-release monitoring.

    Measure the quality of the model as well as the speed of the application. Useful indicators include quote cycle time, engineering touches per quote, invalid configuration attempts, manual overrides, pricing corrections, BOM errors, approval duration, order re-entry and the percentage of quotes completed without engineering intervention. Metrics should be interpreted in context; a rise in engineering reviews may indicate better detection of complex ETO work rather than a failed implementation.

    Common implementation limitations and failure modes

    Failure mode Why it occurs Prevention
    Modeling every exception as an option Historical quotes contain undocumented one-off decisions Separate standard configuration from controlled ETO review
    Starting with the user interface Teams design screens before defining product logic Model data, rules, ownership and outputs first
    Ignoring downstream structures Sales BOM is assumed to be a manufacturing BOM Define EBOM, MBOM and ERP ownership explicitly
    Embedding prices in technical rules Commercial and engineering changes become coupled Separate pricing tables and configuration logic
    Relying on undocumented overrides Users work around incomplete rules Capture exceptions, approvals and reasons
    Underestimating data cleanup Duplicate, obsolete or inconsistent source records are migrated Profile, cleanse and classify data before migration
    Assuming integrations are interchangeable CRM, ERP, PLM, PDM, MES and CAD have different purposes Define system-of-record responsibilities and interface contracts
    Skipping regression testing A price or rule change breaks an unrelated product family Maintain reusable test cases and release gates

    Recommended implementation sequence

    1. Set objectives: define the business problems, product scope, workflow and measurable outcomes.
    2. Map the current state: document quoting, engineering, pricing, order entry and production handoffs.
    3. Assess data: inventory product, option, component, price, CAD, BOM and customer data.
    4. Design the target model: define features, options, constraints, calculations, outputs and ownership.
    5. Choose the first release: select a product family and workflow that can be tested end to end.
    6. Configure and integrate: build the model, interfaces, documents and required engineering services.
    7. Test with real scenarios: include valid, invalid, boundary, revised and exception cases.
    8. Train and pilot: use controlled users and capture operational feedback.
    9. Deploy in phases: expand product families and channels only when governance is ready.
    10. Operate and improve: monitor rules, data, integrations, user adoption and business outcomes.

    A detailed project plan should also address security, environments, release management, backup and recovery, audit trails, supplier data, localization and regulatory requirements where applicable. These concerns vary by platform and industry and should be verified during vendor evaluation rather than assumed.

    Semantic map

    The following relationships summarize the main entities and dependencies in a manufacturing CPQ implementation:

    • Manufacturing CPQ connects product configuration with pricing, quoting and downstream engineering or production processes.
    • Product models contain features, options, parameters, dependencies, constraints and output mappings.
    • Configuration rules prevent invalid combinations and derive required components or values.
    • Configured products can generate BOM data when the selected CPQ platform supports BOM generation.
    • EBOM structures describe engineering intent, while MBOM structures organize production requirements.
    • Pricing rules calculate commercial values separately from technical configuration rules.
    • CAD automation can generate product-specific drawings or models when templates and integrations are available.
    • ERP manages enterprise transactions and may receive configured items, prices or orders from CPQ.
    • PLM and PDM manage product revisions, engineering structures, documents and CAD data.
    • ETO workflows route non-standard requirements to engineering review rather than forcing every exception into a standard model.
    • Governance controls changes to product rules, prices, BOMs, integrations and engineering outputs.
    • Regression testing verifies that model changes do not invalidate existing product families.

    Frequently asked questions

    1. What is manufacturing CPQ implementation?

    It is the process of modeling configurable products, rules, calculations, prices, quotes and downstream outputs in a CPQ system, then integrating, testing and operating that system within manufacturing workflows.

    2. How is manufacturing CPQ different from sales CPQ?

    Sales CPQ generally emphasizes product selection, pricing, discounts and proposals. Manufacturing CPQ may additionally validate technical combinations, calculate requirements, generate BOM data, automate CAD work and connect configuration with engineering and production.

    3. How long does a manufacturing CPQ implementation take?

    Duration depends on product complexity, data quality, number of product families, integrations, engineering automation and governance requirements. A focused pilot is usually more predictable than a portfolio-wide deployment.

    4. Which product family should be implemented first?

    Choose a product with meaningful configuration complexity, reliable source data, clear business ownership and measurable quoting or engineering problems. Avoid a product family dominated by undocumented exceptions.

    5. Who should own the CPQ product model?

    Ownership is usually shared, but one accountable product or configuration owner should coordinate decisions. Engineering, product management, pricing, manufacturing and IT should approve changes within their areas of responsibility.

    6. Should configuration rules be stored in ERP?

    ERP may own items, inventory, orders and financial data, but it is not automatically the best place for customer-facing configuration logic. Define system ownership based on the required workflow and the capabilities of the selected platforms.

    7. Can CPQ generate a manufacturing BOM?

    Some CPQ systems can generate or map configurable BOMs, while others produce only sales or engineering outputs. Verify whether the platform supports the required EBOM, MBOM, effectivity, plant and routing requirements.

    8. What is the difference between an EBOM and an MBOM?

    An EBOM represents an engineering view of the product, often organized by design structure. An MBOM represents how the product is assembled or manufactured. They may contain different groupings, quantities, consumables and production information.

    9. Can CPQ support engineer-to-order products?

    It can support ETO by capturing requirements, identifying standard versus non-standard work and routing exceptions to engineering. It does not eliminate engineering design work unless the product has been sufficiently standardized and automated.

    10. Does every CPQ system provide CAD automation?

    No. CAD automation may be native, delivered through an integration or unavailable. Confirm supported CAD systems, parameter handling, template control, revision management, output formats and failure handling.

    11. How should pricing and configuration logic be separated?

    Technical rules should determine what can be configured and what components or values are required. Pricing logic should calculate commercial amounts using prices, costs, discounts, currencies, surcharges and approval policies.

    12. What data should be migrated into CPQ?

    Migrate approved and useful product attributes, options, rules, identifiers, prices, documents and mappings. Do not automatically migrate every historical exception or obsolete record.

    13. How should CPQ integrations be tested?

    Test valid and invalid messages, identifiers, revisions, timing, authentication, error responses and retries. Include end-to-end scenarios from configuration and quote creation through order transfer and downstream processing.

    14. What is a good CPQ implementation pilot?

    A good pilot covers one product family and one complete workflow, such as configuration through approved quote or configuration through ERP order. It should include real rules, pricing, representative outputs and defined acceptance criteria.

    15. How can manufacturers reduce CPQ rule complexity?

    Standardize product options, remove obsolete choices, separate technical and commercial rules, identify reusable submodels and route genuine ETO requirements to engineering instead of encoding every exception as a selectable option.

    16. What testing is required before go-live?

    Use unit, model, integration, end-to-end, user acceptance and regression testing. Include boundary values, incompatible selections, price changes, product revisions, BOM outputs, document generation and integration failures.

    17. How should CPQ changes be governed after launch?

    Use controlled change requests, impact analysis, approvals, versioning, effectivity dates, regression testing, deployment records and post-release monitoring. Assign clear owners for rules, prices, product data and interfaces.

    18. What KPIs are useful after implementation?

    Useful measures include quote cycle time, engineering effort per quote, configuration errors, manual overrides, pricing corrections, BOM errors, approval time, order re-entry and the proportion of standard quotes completed without engineering intervention.

    19. Can CPQ replace PLM, ERP or CAD?

    Usually not. CPQ may exchange data with these systems, but ERP, PLM, PDM and CAD have distinct responsibilities. The implementation should define boundaries rather than treating CPQ as a replacement for every enterprise application.

    20. When should a manufacturer consider a custom-built CPQ solution?

    Consider build versus buy after documenting product complexity, integrations, governance, lifecycle cost and internal capability. A custom solution may fit unique requirements, but the manufacturer must also maintain rules, security, testing, infrastructure and upgrades.

  • Product Master Data for Configurable Products

    Product master data for configurable products is the structured information required to define, sell, engineer, price, manufacture and support product variants. It includes product families, features, options, attributes, dimensions, materials, components, part numbers, revisions, costs, prices, configuration rules, bills of material and related engineering information.

    In manufacturing, product master data is more than a list of items and prices. A configure, price, quote (CPQ) system may need to understand whether a pump can use a particular impeller, whether a motor is suitable for a selected voltage, how a frame size changes the bill of material (BOM), and whether a configured assembly requires a new drawing or engineering review.

    The practical objective is to give each system the product information it needs without creating conflicting versions of the product model. Product lifecycle management (PLM) may own engineering definitions, enterprise resource planning (ERP) may own manufacturing and commercial item records, computer-aided design (CAD) systems may own geometry, and CPQ may use a governed subset of this information to configure and quote valid products.

    This article explains the data domains, ownership model, system relationships, implementation issues and operational controls required for reliable product master data in a manufacturing CPQ architecture.

    What is product master data?

    Product master data is the controlled, reusable information that identifies a product and describes its commercial, technical, engineering and manufacturing characteristics. It is generally more stable and structured than transactional data such as a particular quote, sales order or production order.

    For a configurable industrial product, master data commonly includes:

    • Product families, models and configuration hierarchies
    • Features, options, variants and selectable values
    • Technical attributes such as capacity, pressure, voltage, dimensions and material
    • Part numbers, descriptions, units of measure and lifecycle status
    • Option compatibility, dependency and exclusion rules
    • Engineering relationships, revisions and effectivity dates
    • Configurable BOM structures and component quantities
    • Manufacturing operations, work centers or routing references where applicable
    • Standard costs, list prices, discounts and pricing conditions
    • CAD templates, drawings, documents and design parameters
    • Supplier, sourcing, service and regulatory information

    Master data should be distinguished from product content. Product content may include sales descriptions, images, brochures and web copy. Product master data is typically more structured and operational: it determines which configurations are valid and what downstream systems must receive when a customer selects them.

    Why master data matters in manufacturing CPQ

    Generic sales CPQ can often work with a relatively simple catalog, discount table and proposal template. Manufacturing CPQ usually needs a deeper product model. The system may have to validate technical constraints, calculate performance, select components, generate a BOM and pass an order-ready definition to ERP or engineering.

    For example, consider a configurable centrifugal pump. A salesperson may select flow rate, head, fluid type, temperature, seal material, motor power, voltage, connection standard and mounting arrangement. These choices can affect one another:

    • The required impeller diameter may depend on flow and head.
    • The fluid and temperature may restrict seal and material choices.
    • Motor power may depend on calculated shaft power and efficiency.
    • Voltage and frequency may determine an eligible motor variant.
    • The selected frame and coupling may determine the baseplate and guard.
    • The final configuration may select different components in the configurable BOM.

    If the CPQ configurator contains outdated or incomplete master data, it can produce a technically invalid quote even when the interface appears to work correctly. The result may be engineering rework, an incorrect price, a delayed order or a production exception.

    Reliable master data therefore supports the full path from customer requirements to product definition, quote, order, engineering output and manufacturing execution. It is one of the foundations of manufacturing CPQ.

    Core data domains for configurable products

    Product and variant hierarchy

    The hierarchy describes how a company organizes product families, models, platforms, modules, assemblies and sellable variants. A material handling manufacturer might define a product family for conveyors, a platform for belt conveyors, models by width and length range, and optional modules for drives, guards, sensors and controls.

    The hierarchy should not be confused with every possible finished-product part number. Some organizations create a unique item number for every combination. Others use a configurable material, a sales configuration identifier or a generated engineering number. The appropriate approach depends on ERP, manufacturing, inventory, costing and traceability requirements.

    Features, options and attributes

    Features represent meaningful decisions in the configuration process, such as drive type, enclosure rating or pressure class. Options are selectable values within those features. Attributes describe characteristics of the configured product or selected component, such as length, weight, capacity or operating temperature.

    Dimensions require particular care. A dimension may be a discrete option, a numeric input within a range, a calculated value or a parameter passed to CAD. The data model should define units, precision, valid ranges, rounding rules and dependencies. A vessel diameter, for example, may be entered by an engineer but constrained by material thickness, transport limits and available forming equipment.

    Part and item master records

    An item master record identifies a component, assembly, finished product or service. It commonly includes an item number, description, unit of measure, lifecycle status, revision, planning attributes and accounting classifications.

    CPQ should not automatically become the authoritative source for every item attribute. In many architectures, ERP owns inventory, purchasing and manufacturing item data, while PLM owns engineering part definitions and revisions. CPQ may store references, synchronized attributes and configuration-specific logic rather than replace those systems.

    Rules and constraints

    Rules determine how product choices relate to one another. Rules-based configuration uses explicit conditions such as “if option A is selected, option B is required.” Constraint-based configuration represents permitted combinations and restrictions, potentially across numeric values, capacities and engineering relationships. Guided selling asks questions and recommends choices, but a recommendation is not necessarily a technical validation.

    Typical rules include:

    • Requires: a selected option requires another option or component.
    • Excludes: two options cannot be selected together.
    • Compatibility: a component is valid only for certain models, materials or operating conditions.
    • Range: a value must remain within an allowed minimum and maximum.
    • Calculation: a value such as motor size or material thickness is derived from inputs.
    • Effectivity: a rule applies only from a specific date, revision or market.
    • Approval: a valid but unusual configuration requires engineering review.

    Rules should be treated as governed product knowledge, not merely interface behavior. They require named owners, test cases, version control and a process for handling exceptions. More detail is available in the guide to product configuration and configuration rules.

    Engineering and CAD data

    Some configurations can be assembled from standard components, while others require engineering calculations, parameterized geometry or a new drawing. CAD data may include templates, models, drawing rules, material parameters and references to standard hardware.

    CPQ may send selected parameters to a CAD automation service, which generates product-specific geometry or drawings. Alternatively, CPQ may only identify the configuration and create an engineering request. These are different capabilities and should not be assumed to exist in every CPQ platform.

    CAD and engineering data should have clear ownership and revision relationships. A CPQ option should not silently point to an obsolete drawing or an unapproved model. See CAD and engineering automation in CPQ for the relationship between configuration data and design outputs.

    BOM and manufacturing data

    A bill of material (BOM) describes the components and quantities required for a product or assembly. An engineering BOM (EBOM) represents the product from an engineering perspective. A manufacturing BOM (MBOM) organizes material and assemblies for production. A configurable BOM is a structure containing rules, alternatives or selections that resolve into a product-specific BOM after configuration.

    For a configured electrical enclosure, the selected enclosure size, circuit protection, terminals, wiring accessories and mounting plate may determine the resolved BOM. The EBOM may describe functional engineering relationships, while the MBOM may add packaging, work instructions, consumables or production-specific subassemblies.

    CPQ may generate a quote-level BOM, an order BOM, an EBOM request or an MBOM-ready structure. The exact output must be defined rather than assumed. More information is available in BOM generation, costing, pricing and quoting.

    Pricing, costing and commercial data

    Pricing data includes list prices, regional prices, customer-specific agreements, discounts, surcharges, currencies and validity periods. Costing data may include material cost, purchased component cost, labor, setup, subcontracting and overhead assumptions.

    Configuration data and pricing data are related but not identical. A selected stainless-steel material may change both the technical validity of a product and its cost. However, the price calculation may also depend on customer segment, quantity, freight, margin policy or commercial approval rules.

    Separating these concerns makes the model easier to govern. A product engineer may own material compatibility, while commercial operations owns price conditions. Both may be required before a quote can be released.

    System ownership in the manufacturing technology stack

    Product master data is usually distributed across several enterprise systems. The goal is not to force every attribute into one database, but to define authoritative ownership and reliable synchronization.

    System Typical responsibility Relationship with CPQ
    PLM Engineering product definitions, revisions, lifecycle and change control Provides approved product structures, options, revisions or engineering references
    PDM Product data management for CAD files, drawings and documents Provides controlled design files or document references where supported
    ERP Items, inventory, purchasing, manufacturing, orders, accounting and often pricing Receives order and item data; may provide commercial and operational master data
    CRM Accounts, opportunities, activities and customer-facing sales processes Uses CPQ configuration and quote results within the opportunity workflow
    CAD Parametric geometry, models, drawings and design calculations Receives configuration parameters or returns engineering outputs
    PIM Product information for channels, catalogs and digital commerce May receive approved descriptions, attributes and media for publication
    MES Manufacturing execution, work instructions, production tracking and shop-floor data May receive resolved BOMs, routings, instructions or configuration identifiers
    CPQ Configuration interaction, validation, commercial calculation and quote assembly Uses governed data and rules to create a valid commercial configuration

    The boundaries vary by organization and software architecture. For example, a CPQ platform may own the executable configuration model while PLM owns the source engineering structure. In another implementation, a product model may be authored in PLM and transformed into a CPQ-specific representation. Both approaches require explicit synchronization and change management.

    How product master data flows through a CPQ process

    1. Product definition: Engineering and product management define families, options, parameters, components and constraints.
    2. Approval and release: PLM, ERP or another governance process releases the relevant revisions and item records.
    3. Model preparation: The CPQ product model is created or synchronized, including rules, descriptions, prices and outputs.
    4. Configuration: A salesperson, dealer, engineer or customer selects requirements and options.
    5. Validation: The configurator checks dependencies, ranges, compatibility and required approvals.
    6. Calculation: The system calculates technical values, costs, prices, discounts and lead-time factors as configured.
    7. Output generation: CPQ creates a quote, proposal, configuration identifier and, where supported, a resolved BOM or CAD request.
    8. Enterprise handoff: CRM, ERP, PLM, CAD or MES receives the appropriate data through APIs, files or middleware.
    9. Order and production: The accepted configuration becomes an order, engineering package or manufacturing definition according to the selected workflow.

    This flow differs by operating model. Configure-to-order (CTO) uses predefined configurations and components. Engineer-to-order (ETO) requires engineering work for a significant portion of the product. Make-to-order (MTO) manufactures against an order, while assemble-to-order (ATO) combines stocked modules after the order. Product master data must indicate which path applies and what outputs are required.

    Data ownership and governance

    A product data governance model should answer four questions for every important field: who creates it, who approves it, which system is authoritative and which systems consume it.

    A practical ownership matrix may assign:

    • Engineering ownership of technical limits, component compatibility and design revisions
    • Product management ownership of product families, market options and lifecycle decisions
    • Manufacturing engineering ownership of production structures, routings and assembly constraints
    • Commercial ownership of price lists, discount policies and approval thresholds
    • IT or enterprise architecture ownership of interfaces, identifiers and integration monitoring
    • CPQ administration ownership of executable rules, user experience and model deployment

    Governance also requires common identifiers. Part numbers, option codes, revision codes, units of measure and effectivity dates must be mapped consistently. A description such as “high temperature seal” is not sufficient if ERP, PLM and CPQ use different codes or meanings for the same component.

    Change management is equally important. A new motor may require an ERP item, a PLM revision, a CAD update, a BOM rule change, a price update and new CPQ test cases. A release process should identify all affected systems and prevent partially updated models from being used for live quotes.

    Implementation considerations

    Start with a product data inventory

    Document the current sources of product information, including spreadsheets, ERP item masters, CAD libraries, PLM structures, price lists, dealer catalogs and engineering calculators. Identify duplicate fields, conflicting identifiers, obsolete options and undocumented rules.

    Model the configuration scope

    Do not migrate every product record into CPQ automatically. Define which product families require interactive configuration, which are sold as standard items and which require ETO review. Prioritize products where configuration errors, engineering effort or quote delays have a material operational impact.

    Separate source data from executable logic

    A source BOM or product structure may not be directly usable as a CPQ model. The CPQ implementation may need transformed options, conditional components, calculated attributes and user-facing descriptions. Document this transformation so that model maintainers can trace a rule back to its engineering or commercial source.

    Test combinations and lifecycle changes

    Testing should cover valid configurations, invalid combinations, boundary values, price changes, revisions, discontinued components, effectivity dates, currencies and integration failures. It should also verify that the resolved BOM, CAD request, quote and ERP order contain consistent identifiers.

    Plan for maintenance

    Product models are operational software assets. They need release calendars, rule ownership, regression tests, deployment controls and monitoring. A configuration model that is correct at launch can become unsafe when suppliers change components, standards change, prices expire or engineering releases a new revision.

    Implementation guidance covering migration, testing, deployment and governance is available in the manufacturing CPQ implementation guide.

    Common limitations and failure modes

    • Unclear ownership: Multiple systems edit the same field, producing conflicting values.
    • Catalog-only modeling: The CPQ model contains descriptions and prices but not technical constraints or downstream structure.
    • Overloaded CPQ: CPQ is made responsible for engineering, inventory, document control or manufacturing functions better handled elsewhere.
    • Hidden spreadsheet logic: Critical calculations remain outside the governed product model.
    • Part-number explosion: Every theoretical combination receives a separate item number without considering maintainability.
    • Weak revision control: Existing quotes or orders cannot be traced to the product rules and revisions used at the time.
    • Incomplete integration: A quote is generated successfully but the resulting configuration cannot be consumed by ERP, PLM, CAD or production.
    • Unmanaged exceptions: Sales teams bypass validation because the standard model cannot represent legitimate ETO or approval cases.

    These problems are not solved by adding more fields to a product catalog. They require a defined architecture, reliable identifiers, data stewardship and agreement about the desired manufacturing workflow.

    Product master data checklist

    Before implementing or expanding a CPQ configurator, verify that the organization can answer the following questions:

    • Which system owns each product, part, option, revision and price?
    • Are configuration rules documented and testable?
    • Which inputs are discrete options, numeric parameters, calculated values or engineering requests?
    • Can the model identify invalid combinations before a quote is released?
    • Does the configured product need a quote BOM, EBOM, MBOM, CAD output or only a configuration identifier?
    • How are CTO, ATO, MTO and ETO products distinguished?
    • How are revisions, effectivity dates and discontinued components handled?
    • Which data must flow to CRM, ERP, PLM, PDM, CAD, PIM or MES?
    • Who approves technical exceptions and commercial overrides?
    • How will product model changes be tested and deployed?
    • Can a historical quote be reproduced using the rules and master data that were active at the time?

    Semantic map

    The following relationships summarize how product master data connects a manufacturing CPQ configurator with engineering and enterprise systems:

    • Product master data defines configurable products.
    • Configuration rules prevent invalid combinations.
    • Product options select components and attributes.
    • Configured products generate resolved BOMs.
    • EBOMs represent engineering product structures.
    • MBOMs organize products for manufacturing.
    • PLM controls engineering revisions.
    • ERP manages operational item and order data.
    • CAD automation generates product-specific drawings.
    • CPQ calculates prices from configuration and commercial data.
    • CRM stores opportunities and uses quote results.
    • APIs exchange product and configuration data between systems.
    • MES consumes manufacturing definitions and production instructions.
    • Product data governance controls ownership and change.
    • ETO workflows route non-standard configurations to engineering.

    FAQ

    What is product master data for configurable products?

    It is the governed technical, commercial, engineering and manufacturing information used to define, validate, price and produce product variants.

    Is product master data the same as a product catalog?

    No. A catalog may contain descriptions and prices, while master data also includes identifiers, revisions, constraints, components, calculations and downstream manufacturing relationships.

    Which system should own product master data?

    There is usually no single owner for every field. PLM commonly owns engineering definitions, ERP operational item data, and CPQ the executable configuration and quoting model, subject to the company’s architecture.

    Should CPQ be the master data system?

    Usually not for all domains. CPQ should consume or reference authoritative data and may own the rules and model required for configuration, unless the selected architecture explicitly assigns it broader ownership.

    How does master data support a CPQ configurator?

    It supplies the products, options, attributes, constraints, prices and component relationships that allow the configurator to produce valid and commercially accurate results.

    What is the difference between product configuration and product master data?

    Product master data describes the product and its possible variants. Product configuration is the act of selecting values and resolving one valid instance of that product.

    What data does a configurable pump require?

    It may require flow, head, fluid, temperature, materials, seal type, impeller, motor, voltage, connection standard, price and component relationships.

    How do configuration rules relate to master data?

    Rules are governed logic built from product knowledge. They use master data such as options, attributes, components, ranges, revisions and compatibility relationships.

    What is a configurable BOM?

    A configurable BOM contains alternatives, conditions or selection rules that resolve into a product-specific BOM after configuration.

    Does CPQ generate an EBOM or MBOM?

    Some platforms can generate or integrate with BOM structures, but capabilities vary. The implementation must specify whether CPQ produces a quote BOM, EBOM, MBOM, order structure or reference only.

    How is an EBOM different from an MBOM?

    An EBOM represents the product from an engineering viewpoint. An MBOM organizes materials and assemblies for manufacturing and may include production-specific structures and consumables.

    What role does PLM play in configurable product data?

    Product lifecycle management (PLM) commonly controls engineering parts, structures, revisions, approvals and effectivity, which CPQ may consume for configuration and quoting.

    What role does ERP play?

    Enterprise resource planning (ERP) commonly manages item records, inventory, purchasing, manufacturing orders, accounting and operational transactions connected to the configured product.

    How does CAD use CPQ product data?

    Where supported, CPQ can pass dimensions, options and parameters to CAD automation. CAD may then generate geometry, drawings or design outputs, although not every CPQ system provides this capability.

    How should numeric dimensions be modeled?

    Define units, precision, valid ranges, rounding, dependencies and whether the value is entered, selected or calculated. These details are essential for engineering validation.

    How does master data support engineer-to-order products?

    It identifies standard limits, reusable modules, engineering inputs and approval triggers, allowing CPQ to distinguish valid standard configurations from cases requiring engineering work.

    What causes product master data conflicts?

    Common causes include duplicate ownership, inconsistent part numbers, manual spreadsheets, missing revision control, unsynchronized prices and undocumented configuration logic.

    How should product data changes be tested?

    Test valid and invalid combinations, boundary values, pricing, BOM resolution, revisions, effectivity dates and every affected integration before deployment.

    Can product master data improve quote accuracy?

    Yes, when the data includes current rules, costs, prices, components and engineering constraints. Master data alone cannot improve accuracy if it is incomplete or poorly governed.

    What is the difference between CPQ master data and PIM data?

    Product information management (PIM) focuses on publishing product content across channels. CPQ master data must additionally support configuration logic, technical validation, pricing and downstream transaction outputs.

    Should every product combination have its own part number?

    Not necessarily. Some products use configurable items or generated identifiers, while others require distinct part numbers for inventory, traceability, costing or production. The decision should reflect operational requirements.

    How often should CPQ product master data be updated?

    It should be updated whenever approved products, components, prices, rules, revisions or manufacturing processes change, using a controlled release process rather than an arbitrary calendar alone.

  • BOM in CPQ: How Bills of Materials Fit into Configure-Price-Quote

    A bill of materials (BOM) in Configure, Price, Quote (CPQ) is the structured list of components, quantities and relationships generated or selected for a specific product configuration. In manufacturing CPQ, the BOM connects what a customer selects with what engineering, purchasing, production and finance need to cost, price, quote and eventually build the product.

    The basic flow is:

    1. A salesperson, dealer, engineer or customer configures a product.
    2. Configuration rules validate options, dimensions, materials and dependencies.
    3. The CPQ system resolves the selections into a configurable BOM or product-specific BOM.
    4. Component quantities and attributes support costing and pricing.
    5. The approved configuration and commercial data are assembled into a quote.
    6. Relevant BOM data may be sent to enterprise systems such as an Enterprise Resource Planning (ERP), Product Lifecycle Management (PLM) or Manufacturing Execution System (MES) platform.

    Not every CPQ platform generates manufacturing-ready BOMs. Some systems only use product options to calculate prices and produce a proposal. Buyers should therefore verify whether a platform supports BOM generation, which BOM type it produces, how rules are maintained and whether the output is suitable for engineering or production.

    This guide explains how BOMs fit into manufacturing CPQ, how they relate to configuration and pricing, how EBOMs and MBOMs differ, and what manufacturers should evaluate during implementation.

    What is a BOM in CPQ?

    A BOM in CPQ is a structured representation of the parts, assemblies, materials and quantities required for a configured product. The BOM may be generated dynamically from configuration choices or retrieved from predefined product structures. It can support commercial calculations, engineering review, manufacturing planning or several of these purposes at once.

    A typical BOM line may contain:

    • item number or material number;
    • component description;
    • quantity and unit of measure;
    • parent assembly;
    • effective date or revision;
    • make-or-buy status;
    • cost and price references;
    • optional attributes such as material, finish, size or voltage;
    • manufacturing or procurement notes;
    • links to drawings, specifications or CAD files.

    In a simple sales CPQ application, the BOM may be only a commercial bundle used to calculate a price. In manufacturing CPQ, the BOM can be the result of a deeper product model containing constraints, engineering calculations, variant logic and relationships between configured features.

    For example, configuring an industrial pump may involve selecting flow rate, pressure, fluid type, motor power, seal material, impeller material, connection standard and enclosure rating. Those choices can determine the pump assembly, motor, coupling, baseplate, seal kit, control panel, fasteners and documentation included in the BOM.

    The BOM is therefore not merely a list printed on a quote. It is an output of the product configuration model and a potential input to costing, engineering, ERP, PLM, purchasing and production.

    How BOM generation fits into the CPQ architecture

    Manufacturing CPQ usually contains several related data and logic layers. The exact architecture varies by product and vendor, but the following pattern is common.

    Layer Purpose Manufacturing example
    Product model Defines products, features, options, components and relationships. A pump family with available impellers, motors and seal types.
    Configuration rules Controls valid, invalid, required and conditional choices. A high-temperature seal is required for a specified fluid and temperature range.
    Engineering calculations Derives technical values from customer or application inputs. Calculating motor size from flow, head and efficiency requirements.
    BOM logic Selects components and calculates quantities or structures. Adding a reinforced baseplate when motor weight exceeds a threshold.
    Cost model Applies material, labor, overhead, supplier and manufacturing costs. Calculating cost from selected steel grade, machining time and purchased motor.
    Pricing model Converts cost and commercial rules into customer prices. Applying customer terms, currency, margin, freight and volume discounts.
    Quote document Communicates scope, price, assumptions, validity and commercial terms. A proposal showing the configured equipment, options, exclusions and price.
    Enterprise integration Transfers approved data to surrounding systems. Sending an order-ready structure and item references to ERP and PLM.

    These layers should be related but not confused. A configuration rule determines whether a combination is valid. A BOM rule determines which components result from that combination. A cost rule determines what the selected components cost. A pricing rule determines what the customer is charged. A quote document presents the result.

    For more background, see the guide to product configuration and configuration rules and the overview of BOM generation, pricing and quote automation.

    From customer selections to a configured BOM

    1. Capture requirements and configuration inputs

    The process begins with inputs such as product family, capacity, dimensions, operating environment, materials, accessories, certifications and delivery requirements. These inputs may be entered by an internal salesperson, sales engineer, dealer, customer or engineering user.

    In an industrial enclosure example, the inputs could include width, height, depth, ingress protection rating, mounting method, door arrangement, paint system and electrical components. Some values are discrete options, while others are numerical variables or free-form engineering requirements.

    2. Validate the configuration

    The CPQ rules engine checks the proposed configuration. Rules may require an option, exclude a combination, recommend an alternative or request engineering review.

    There are several related approaches:

    • Rules-based configuration uses explicit if-then logic, dependencies and compatibility rules.
    • Constraint-based configuration evaluates relationships and limits across variables, such as dimensions, load, capacity, temperature or power.
    • Guided selling asks questions and recommends suitable products or options, but may not provide the engineering depth required to validate a complex product.

    A guided selling interface can be useful for selecting a suitable product family. It is not automatically a substitute for a constraint solver or engineering rules engine.

    3. Resolve components and quantities

    After validation, BOM logic determines which components belong in the configured structure. A selected option can add an item, replace another item, change a quantity, alter a component attribute or create a new subassembly.

    For example, selecting a dual-pump skid might:

    • change the top-level equipment quantity from one pump to two;
    • add a common skid frame;
    • add two motors and two couplings;
    • add a shared control cabinet;
    • add isolation valves and check valves for each pump;
    • change cable and pipe lengths based on layout dimensions;
    • require additional instrumentation.

    The result may be a multi-level BOM rather than a flat list. A top-level skid contains pump assemblies, each pump assembly contains a motor and hydraulic components, and the control panel contains electrical subassemblies.

    4. Apply calculations and attributes

    Some BOM values cannot be selected directly. They must be calculated. A configured conveyor may require belt length based on conveyor dimensions. A heat exchanger may require surface area and tube count. A vehicle body may require material quantities based on length, width and payload.

    The CPQ system may also assign attributes to BOM lines. A generic motor item might become a specific motor variant with a defined power, voltage, frequency, enclosure and efficiency class. In other cases, CPQ may pass calculated requirements to an ERP or PLM system that selects the final material number.

    5. Calculate cost and price

    Once the BOM is resolved, the system can use its lines as inputs to costing. Costing may include component purchase prices, manufacturing operations, labor, setup, subcontracting, freight, tooling, scrap, overhead and engineering effort. Pricing then applies commercial policies such as margin, discount, currency, customer segment and approval thresholds.

    However, BOM generation and costing are separate capabilities. A CPQ platform may generate a commercial BOM without calculating detailed manufacturing cost. Conversely, a system may calculate price from a product model without producing a production-ready BOM.

    6. Produce the quote and route approvals

    The quote normally includes a customer-readable description rather than every internal BOM line. It may show major assemblies, options, quantities, technical specifications, exclusions, lead time, price and terms. Internal users may see a more detailed breakdown for margin analysis, review and approval.

    Approval workflows can be triggered by low margin, unusual discounts, non-standard materials, extended lead time, engineering risk or an ETO requirement. Engineer-to-order (ETO) products require new or modified engineering work, so the BOM may remain provisional until engineering completes its review.

    EBOM, MBOM and configurable BOM

    Manufacturers should distinguish among several BOM concepts.

    BOM type Meaning Typical purpose
    EBOM Engineering Bill of Materials: the product structure from a design or engineering perspective. Defines designed assemblies, parts, revisions and technical relationships.
    MBOM Manufacturing Bill of Materials: the structure used to plan and build the product. Includes manufacturing assemblies, operations, work-center relationships, consumables or packaging where applicable.
    Configurable BOM A rules-driven structure containing alternatives, optional items, quantities or conditions. Represents a product family before one customer configuration is finalized.
    Configured or order BOM The resolved structure for one specific order or quote. Supports a particular customer requirement, order, build or engineering review.

    A CPQ system may own the configurable product model and produce a configured BOM, while PLM owns the authoritative EBOM and ERP or manufacturing systems manage the MBOM. In other architectures, CPQ may read item and structure data from PLM or ERP and return only configuration selections and commercial information.

    These responsibilities must be defined explicitly. Treating an EBOM and an MBOM as interchangeable can create problems with assembly sequence, phantom assemblies, work instructions, bulk materials, packaging and shop-floor reporting.

    Read more about manufacturing and CPQ terminology, including EBOM, MBOM, CTO and ETO.

    Manufacturing examples

    Industrial pump configuration

    A pump manufacturer may sell several product families with options for capacity, pressure, fluid, temperature, impeller diameter, seal type, motor, coupling, baseplate and controls.

    The configuration model can validate that:

    • the selected impeller supports the required flow and head;
    • the motor has sufficient power and the correct electrical specification;
    • the seal material is compatible with the fluid and temperature;
    • the casing material satisfies corrosion requirements;
    • the selected flange standard matches the connection requirement;
    • the baseplate supports the selected motor and pump arrangement.

    The resulting BOM could contain a pump casing, impeller, shaft, mechanical seal, bearings, motor, coupling, guard, baseplate, fasteners, documentation and optional instrumentation. A CAD or engineering system may use the same configuration to generate a drawing or dimensional layout, but that capability is not present in every CPQ implementation.

    HVAC equipment

    An air-handling unit configuration may include airflow, static pressure, casing dimensions, filters, coils, fans, heaters, dampers, controls and access panels. Dimensions can influence the number of modules, panel quantities, coil size, fan selection and shipping sections.

    A quote-only CPQ tool may calculate a price from these choices. A deeper manufacturing CPQ system may generate a variant BOM, calculate performance, create a product-specific drawing and pass an order structure to ERP or PLM. The buyer must verify which of these outputs are actually supported.

    Specialty vehicle

    A specialty vehicle may be configured with chassis, wheelbase, axle rating, body length, storage modules, electrical systems, hydraulic equipment and safety options. A body length change may affect frame members, floor panels, wiring harnesses, lighting, fasteners and weight calculations.

    The BOM may need to reflect both optional content and calculated quantities. It may also need revision control because vehicle programs often evolve while orders remain open.

    How BOM data supports costing and pricing

    The BOM provides a product-specific basis for cost and price, but it does not automatically make the calculation accurate. The quality of the result depends on item master data, supplier costs, operation rates, labor assumptions, waste factors, currency handling and the date on which values are effective.

    Costing inputs

    • purchased component cost;
    • raw material weight, length, area or volume;
    • machine and labor rates;
    • setup and changeover time;
    • subcontracted operations;
    • scrap and yield factors;
    • freight, packaging and customs costs;
    • engineering or project effort for ETO work;
    • tooling and one-time charges.

    Pricing inputs

    • target margin or markup;
    • customer-specific price agreements;
    • volume breaks;
    • discount authority;
    • channel or dealer margins;
    • currency and exchange-rate policy;
    • tax, freight and surcharge treatment;
    • commercial risk and contingency;
    • approval thresholds.

    Some businesses calculate cost and price in CPQ. Others use CPQ to assemble the commercial structure and rely on ERP for authoritative cost or price data. Integration design should define which system owns each value and how revisions, effective dates and failed transactions are handled.

    BOMs and CAD, PLM and ERP integration

    BOM-related CPQ architecture commonly involves several enterprise systems with different responsibilities.

    System Typical responsibility Possible CPQ relationship
    Customer Relationship Management (CRM) Accounts, opportunities, contacts and sales activity. Starts a configuration or stores the quote and opportunity reference.
    ERP Items, inventory, purchasing, costing, orders, production and finance. Provides item and price data or receives an approved order structure.
    PLM Product definitions, revisions, engineering changes and lifecycle control. Provides approved product structures or receives configured engineering data.
    Product Data Management (PDM) CAD files, documents and design data management. Links configured products to models, drawings or controlled documents.
    CAD Computer-Aided Design models and drawings. Uses configuration inputs to generate geometry or documentation where supported.
    Product Information Management (PIM) Commercial and technical product content. Supplies descriptions, images, specifications and channel content.
    MES Execution and tracking of manufacturing operations. Receives production-relevant structures or order data through ERP or direct integration.

    These systems are not interchangeable. A CRM opportunity is not a BOM. A PLM EBOM is not necessarily a manufacturing MBOM. A CAD assembly is not automatically an ERP item structure. CPQ must translate or map data between these contexts when the workflow requires it.

    Important integration questions include:

    • Which system is authoritative for item numbers and revisions?
    • Does CPQ create new items or only select existing items?
    • Is the BOM transferred as a flat list, hierarchical structure or both?
    • How are configured dimensions and calculated attributes passed downstream?
    • How are engineering changes reflected in open quotes?
    • What happens when an item, price or revision cannot be found?
    • Can the receiving system distinguish a quote BOM from an order or production BOM?
    • Are integrations synchronous, asynchronous or manually approved?

    See the guide to CPQ integration with ERP, CRM, PLM, PDM, CAD and MES for broader architecture considerations.

    CTO, ETO, MTO and ATO BOM workflows

    BOM behavior depends on the manufacturing strategy.

    Model Meaning BOM implication
    Configure-to-order (CTO) A predefined product is assembled after the customer selects allowed options. CPQ can often resolve a known configurable BOM from approved variants.
    Engineer-to-order (ETO) Engineering designs or significantly modifies the product for the order. CPQ may create a preliminary BOM and trigger engineering work before final release.
    Make-to-order (MTO) Production starts after an order, using a defined product or specification. The BOM may be created or released when the order is accepted.
    Assemble-to-order (ATO) Standard subassemblies are stocked and combined for the order. CPQ selects a combination of existing modules and may generate an assembly structure.

    In CTO, the CPQ BOM can be relatively deterministic. In ETO, it may represent requirements rather than a final production structure. A system should make this status visible so that a customer-facing quote is not mistaken for an approved manufacturing release.

    These workflows are discussed in more detail in the guide to configure-to-order, engineer-to-order and related manufacturing workflows.

    Benefits of BOM-driven CPQ

    More accurate configuration and pricing

    When price and cost are derived from the actual configured content, the quote is less dependent on manual spreadsheet interpretation. This is especially valuable when options change material, capacity, labor, purchased components or manufacturing effort.

    Faster sales-to-engineering handoff

    A structured configuration and BOM give engineering a defined starting point. Engineers can focus on exceptions, calculations and new design work instead of re-entering every option from a sales document.

    Better visibility of scope

    A resolved BOM exposes included components, optional content, exclusions and quantities. This reduces ambiguity during commercial review and helps identify missing accessories or services.

    Improved approval control

    Approvals can use calculated margin, component cost, non-standard selections, lead time and engineering status rather than relying only on the total quote value.

    Reusable product knowledge

    Rules and product structures become a governed model that can be reused across direct sales, dealers, ecommerce, internal applications and customer service, subject to the capabilities of the chosen platform.

    Limitations and risks

    A commercial BOM may not be production-ready

    A CPQ-generated BOM may omit routing, operations, work instructions, consumables, packaging, phantom assemblies or shop-floor details. It should not be sent directly to production without confirming its intended use.

    Product models become difficult to maintain

    Large product families can contain thousands of options and dependencies. Poorly governed rules create contradictions, duplicate logic and unexpected combinations. Ownership, naming standards, version control and automated regression testing are essential.

    Data synchronization is complex

    Item numbers, costs, prices, revisions and availability change in ERP, PLM and supplier systems. A stale CPQ model can produce an invalid or unprofitable quote even when the configuration logic is correct.

    Engineering calculations require validation

    Calculations for load, pressure, thermal performance, electrical sizing or structural requirements may require specialist review. A CPQ calculation should not be treated as an engineering approval unless the manufacturer has validated and governed it for that purpose.

    Variant explosion can affect performance

    When many dimensions, options and conditional components interact, the theoretical number of variants can become very large. The implementation may need modular architectures, constraint solvers, parameterized items or integration with engineering systems rather than storing every possible finished BOM.

    Quote and order revisions can diverge

    If a customer changes the configuration after approval, the system must show which BOM, cost, price, revision and document version correspond to the change. Otherwise, sales, engineering and production may work from different definitions.

    Implementation guidance

    Define the purpose of the BOM first

    Document whether CPQ needs to produce a commercial BOM, costing BOM, EBOM, MBOM, order BOM or a preliminary ETO structure. One output may not satisfy every downstream process.

    Establish data ownership

    Assign ownership for products, options, item numbers, revisions, costs, prices, engineering formulas and manufacturing structures. A governance matrix should identify the system of record and the synchronization method for each data object.

    Model the product before copying spreadsheets

    Existing spreadsheets often mix options, prices, formulas, exceptions and manual judgment. Before migrating them, separate product attributes, configuration rules, BOM logic, cost data and approval policies.

    Use stable identifiers

    Every component, option, assembly and revision should have a consistent identifier. Descriptions alone are not sufficient for reliable integration because similar descriptions may refer to different materials, revisions or units of measure.

    Test combinations, not just individual rules

    Testing should include valid configurations, invalid combinations, boundary values, revision changes, quantity calculations, missing data, currency changes, discounts, approvals and downstream integration failures.

    Define release states

    Useful states may include draft, technically valid, commercially approved, engineering review, order-ready and production-released. The names vary, but the distinction between a quote configuration and a released manufacturing structure should be explicit.

    Measure operational outcomes

    Relevant measures can include quote cycle time, configuration error rate, engineering rework, margin variance, approval duration, percentage of quotes requiring manual correction, order-entry effort and integration failure rate. The right measures depend on the business process and baseline data.

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

    What to ask CPQ vendors about BOM capability

    • Does the platform generate a hierarchical BOM, a flat commercial list or both?
    • Can it represent configurable BOMs with optional, alternative, conditional and calculated components?
    • Can BOM logic calculate quantities from dimensions, capacity or other variables?
    • Does it distinguish commercial, engineering and manufacturing structures?
    • Can it import or synchronize items and revisions from ERP or PLM?
    • Can it return configured data to CAD or engineering automation tools?
    • Does it support BOM versioning and effective dates?
    • Can users compare BOM changes between quote revisions?
    • How are costs, prices and currencies sourced and refreshed?
    • Can the system mark a configuration as requiring engineering review?
    • What APIs and integration events are available?
    • How are errors handled when an item or downstream transaction is unavailable?
    • Can dealers or customers see a simplified view while engineering users see detailed data?
    • What testing and rule-governance tools are included?
    • Which capabilities are standard, which require configuration and which require custom development?

    Vendor evaluation should focus on the manufacturer’s actual product complexity and downstream process rather than on a generic feature checklist. The manufacturing CPQ comparison and selection resources can help structure an evaluation.

    Semantic map

    The following relationships summarize how BOMs connect configuration, costing, quoting and manufacturing systems:

    • CPQ configures configurable products.
    • Configuration rules prevent invalid combinations.
    • A configured product generates a configured BOM.
    • A configurable BOM represents product variants.
    • A configured BOM identifies components and quantities.
    • BOM components contribute to product cost.
    • Costing supports price calculation.
    • Pricing determines the commercial quote value.
    • A quote communicates configured scope and commercial terms.
    • Engineering review validates non-standard or ETO requirements.
    • EBOM represents an engineering product structure.
    • MBOM represents a manufacturing product structure.
    • CPQ exchanges item and order data with ERP.
    • CPQ may exchange product structure data with PLM.
    • CAD automation generates product-specific drawings when supported.
    • Approved configuration data can support production planning.

    Frequently asked questions

    What does BOM mean in CPQ?

    BOM means Bill of Materials. In CPQ, it is the component and quantity structure associated with a configured product and may support costing, pricing, quoting, engineering or production.

    Does every CPQ system generate a BOM?

    No. Some CPQ systems calculate prices and create quotes without generating a BOM. Manufacturers should verify whether BOM generation is supported and whether the output is commercial, engineering or manufacturing-oriented.

    How does CPQ create a BOM?

    CPQ applies product rules, constraints, option dependencies and calculations to customer inputs, then selects components, assemblies and quantities for the resulting configuration.

    What is the difference between a configurable BOM and a configured BOM?

    A configurable BOM contains alternatives, options and conditional logic for a product family. A configured BOM is the resolved structure for one particular customer configuration or order.

    Is a CPQ BOM the same as an EBOM?

    Not necessarily. An EBOM is an engineering product structure. A CPQ BOM may be a commercial or order structure and may require engineering or PLM validation before it becomes an authoritative EBOM.

    Is a CPQ BOM the same as an MBOM?

    No. An MBOM is organized for manufacturing execution and may include operations, manufacturing assemblies, consumables or packaging that are absent from a commercial CPQ BOM.

    Can BOM data be used to calculate price?

    Yes, when component costs, quantities and pricing rules are available. The accuracy depends on current item data, supplier costs, labor and overhead assumptions, margins and commercial policies.

    Can CPQ calculate manufacturing cost?

    Some manufacturing CPQ systems can calculate detailed or estimated cost, while others use costs supplied by ERP or another system. This capability must be verified for the specific platform and implementation.

    How does configuration affect the BOM?

    Configuration choices can add, remove or replace components, change quantities, alter attributes or trigger calculated dimensions and subassemblies.

    What is an example of a BOM rule?

    A BOM rule could add a larger motor, reinforced frame and upgraded coupling when a machine is configured for a higher load or capacity range.

    Can CPQ generate a CAD model from a BOM?

    Some platforms integrate with CAD or engineering automation tools, but BOM generation alone does not create CAD geometry. CAD automation requires suitable parametric models, mappings and validated engineering logic.

    How does CPQ support engineer-to-order products?

    CPQ can capture requirements, calculate preliminary values, create a preliminary BOM and route the configuration to engineering. The final BOM may not exist until design work and technical approval are complete.

    What happens when an item changes in ERP?

    The implementation should define synchronization and error handling. CPQ may refresh the item, block the configuration, use an approved replacement or route the quote for review, depending on governance.

    Can a BOM appear on the customer quote?

    Sometimes. Customer quotes usually show selected equipment, major assemblies and options rather than every internal component. The visible level should match commercial clarity and confidentiality requirements.

    How does a BOM affect quote approvals?

    The BOM can provide the component cost, non-standard content, engineering effort and lead-time information used to trigger margin, technical or management approvals.

    What BOM data should CPQ send to ERP?

    The required data may include item numbers, quantities, units, configuration attributes, revisions, customer references and order status. The exact payload depends on whether ERP creates the order, production structure or only a sales document.

    Why are BOM revisions important in CPQ?

    Revisions show which product definition, component set, cost basis and rules were used for a quote or order. They help prevent discrepancies when products change during a sales cycle.

    What is the main risk of using a CPQ BOM for production?

    The main risk is assuming that a commercial or configured BOM contains all manufacturing data. Production may also require routings, operations, work instructions, revisions, quality data and manufacturing-specific structures.

    How should manufacturers test BOM generation?

    Testing should cover normal configurations, invalid combinations, boundary dimensions, option replacements, quantity calculations, revision changes, price changes, approval paths and failed ERP or PLM transactions.

    In practice, BOM capability is one of the clearest differences between generic sales CPQ and manufacturing-oriented CPQ. A quoting tool may tell a salesperson what to charge. A manufacturing CPQ architecture can additionally explain what the customer is buying, which components are required, what it costs, whether it can be engineered and how the data should move toward production.

  • Quote Automation for Complex Manufactured Products

    Quote automation for complex manufactured products is the use of configurable product models, engineering rules, costing logic, pricing rules and document generation to produce accurate quotations with less manual work. In a manufacturing context, automation must do more than calculate a selling price. It may need to validate dimensions, select compatible components, calculate performance, create a configurable bill of material (BOM), request engineering review and produce a quote that reflects what can actually be designed, purchased and built.

    This capability is commonly delivered through configure, price, quote (CPQ) software. Manufacturing CPQ connects the commercial quotation process with product configuration and downstream systems such as enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), computer-aided design (CAD) and manufacturing execution systems (MES). The exact scope varies by platform: some CPQ tools focus mainly on guided selling and price calculation, while others support rules-based engineering, BOM generation, CAD automation and engineer-to-order workflows.

    For example, a salesperson quoting an industrial pump may select flow rate, pressure, fluid type, temperature, motor, seal material, connection standard and enclosure. The system can reject incompatible combinations, calculate the required pump size, select valid components, apply material and labor costs, add appropriate margins, route exceptions for approval and generate a quotation. Where supported, it can also create a product-specific BOM, CAD model or drawing.

    For background, see the guide to manufacturing CPQ, the detailed explanation of product configuration and configuration rules, and the overview of BOM, pricing and quoting.

    What quote automation means in manufacturing

    Quote automation is the controlled transformation of a customer requirement into a commercial and technical offer. The input may be a salesperson’s selections, an application engineer’s requirements, a dealer’s guided configuration or data submitted through an ecommerce channel. The output usually includes a validated configuration, price, lead-time assumptions, scope and exclusions, and a formal quote document.

    Generic sales CPQ often automates product selection, discounts and proposal documents. Manufacturing CPQ adds industrial product logic. Its model may include dimensions, tolerances, materials, ratings, capacity calculations, electrical requirements, component compatibility, manufacturing constraints, supplier availability and engineering review conditions.

    Capability Generic sales CPQ Manufacturing-oriented CPQ
    Product selection Options and packages Options, dimensions, variants, components and technical requirements
    Validation Basic dependencies and exclusions Rules, constraints, calculations, standards and engineering limits
    Pricing List prices, discounts and currencies Material, labor, purchased parts, overhead, freight, margin and configuration-specific pricing
    Output Quote and proposal Quote, configuration record, BOM, technical specification and possibly CAD outputs
    Downstream connection Customer relationship management (CRM) and order systems CRM, ERP, PLM, PDM, CAD, MES, supplier and manufacturing systems

    How automated quoting works

    A robust quote automation process is a chain of dependent decisions rather than a single price calculation. The typical sequence is configuration, validation, engineering calculation, structure generation, costing, pricing, approval and document production.

    1. Capture customer requirements

    The process starts with structured requirements. Depending on the product, this could include required output, dimensions, operating environment, material, regulatory standard, power supply, delivery date, quantity and site conditions. A guided interface can ask questions in a logical order and hide options that are not relevant to the selected product family.

    Structured requirements are preferable to free-text notes because they can be validated and used by later calculations. Free text may still be necessary for special instructions, but it should not be the only record of an important technical requirement.

    2. Select and validate the product configuration

    The CPQ product model represents product families, features, options, variants, components and relationships. Rules determine what can be selected together. A rule might state that a stainless-steel wetted path is required for a corrosive fluid, that a particular motor is unavailable above a specified load, or that a high-temperature seal must be selected when fluid temperature exceeds a threshold.

    Rules-based configuration typically uses explicit conditions such as “if option A is selected, require option B” or “exclude option C.” Constraint-based configuration goes further by evaluating limits and relationships across variables, such as a maximum shaft load, available installation space or required heat-transfer capacity. Guided selling is different again: it helps a user reach a suitable product by asking business or application questions, but it may not fully validate the underlying engineering design.

    More detail on these distinctions is available in the guide to product configuration.

    3. Perform engineering calculations

    Some products can be quoted from a fixed option matrix. Others require calculations. A pump may need a performance selection based on flow and head. An air-handling unit may require airflow, static pressure, coil capacity and casing dimensions. A vehicle body may require axle loading, payload and frame constraints.

    Engineering calculations can be implemented inside CPQ, exposed through a calculation service, or performed by an external engineering application. The important design question is how the calculation result becomes a controlled configuration decision. If a calculation is performed manually in a spreadsheet but the result is not recorded in the product model, the quote may remain difficult to reproduce and audit.

    4. Generate a product structure or BOM

    A validated configuration can be mapped to a configurable BOM. A BOM is a bill of material: the components, quantities and relationships required for a product or assembly. Manufacturing environments commonly distinguish between an engineering BOM (EBOM), which describes the design structure, and a manufacturing BOM (MBOM), which describes how the product is assembled or produced.

    Quote automation may generate a preliminary configurable BOM, an EBOM, an MBOM or a sales-oriented material list. These are not interchangeable outputs. A sales BOM may be sufficient for pricing, while production requires manufacturing operations, routings, substitutes, phantom assemblies, work centres and revision-controlled part numbers.

    Some systems generate only a commercial list of selected items. Others can create detailed structures or pass configuration parameters to ERP or PLM for authoritative BOM creation. Buyers should verify the actual output and ownership of each structure rather than assuming that a CPQ-generated BOM is production-ready.

    5. Calculate cost

    Costing estimates what the manufacturer expects to spend to fulfil the configuration. Cost elements may include raw materials, purchased components, labor, subcontracting, setup, engineering effort, freight, installation and overhead. Cost data may come from ERP, a costing database, supplier records or manually maintained values.

    Costing and pricing are related but distinct. Cost answers “what will this configuration cost us?” Pricing answers “what should we charge the customer?” Keeping the two concepts separate supports margin analysis, approval thresholds and controlled discounting.

    6. Apply pricing and commercial rules

    The pricing engine can combine base prices, option prices, quantity breaks, customer agreements, regional conditions, currencies, surcharges, escalation clauses, freight and discounts. A configured enclosure may add material cost, machining cost and a commercial surcharge. A rush delivery request may trigger a capacity or expedition fee rather than simply changing the product price.

    Pricing rules should be versioned and traceable. If a quote is revised after a price-list change, the business should be able to identify which price list, cost basis, exchange rate and approval policy were used.

    7. Route exceptions and approvals

    Not every quote should be automatically approved. The workflow may route a quote to sales management when the margin falls below a threshold, to engineering when a non-standard dimension is requested, to legal when contractual terms change, or to operations when the delivery date conflicts with capacity.

    Approval workflows should show the reason for the exception and the data supporting the decision. A vague “special approval required” status creates delay. A useful workflow identifies whether the issue is technical risk, commercial margin, credit exposure, delivery feasibility or a non-standard customer requirement.

    8. Generate the quote document

    The final document may include the configured product description, itemized or grouped pricing, quantities, delivery assumptions, validity period, payment terms, exclusions, warranty language and technical attachments. For complex equipment, the document may also include performance data, a preliminary drawing, a specification sheet or a configuration summary.

    Document automation should be based on the validated configuration rather than copied text. Otherwise, the price may reflect one option set while the description or drawing reflects another.

    Reference architecture for manufacturing quote automation

    Quote automation normally sits between customer-facing channels and enterprise engineering and operations systems. A typical architecture contains the following layers:

    • Experience layer: salesperson, application engineer, dealer, distributor, customer portal or ecommerce interface.
    • Configuration layer: product models, options, dependencies, constraints, calculations and validation services.
    • Commercial layer: cost models, price lists, discount rules, currencies, taxes, freight and approval policies.
    • Engineering output layer: specifications, configurable BOMs, EBOM or MBOM requests, CAD parameters, drawings and technical documents where supported.
    • Enterprise integration layer: APIs, middleware or file-based exchanges with CRM, ERP, PLM, PDM, CAD, PIM and MES.
    • Governance layer: version control, permissions, audit history, testing, release management and ownership of product data.

    CRM, or customer relationship management, generally stores accounts, opportunities and customer interactions. ERP, or enterprise resource planning, typically manages items, inventory, purchasing, costs, orders and financial information. PLM, or product lifecycle management, controls product definitions, revisions and lifecycle processes. PDM, or product data management, commonly manages CAD files and engineering data. PIM, or product information management, manages product content for commercial channels. MES, or manufacturing execution system, supports production execution. CAD, or computer-aided design, creates engineering models and drawings.

    These systems may exchange data, but they are not substitutes for one another. The CPQ integration guide explains how these system boundaries affect architecture and data ownership.

    Manufacturing example: quoting a configured industrial pump

    Consider a manufacturer selling centrifugal pumps for industrial water, chemical and process applications. A quote may require the following inputs:

    • flow rate and differential head;
    • fluid composition, density and temperature;
    • pump material and wetted-part material;
    • seal type and elastomer;
    • connection standard and size;
    • motor power, voltage, frequency and enclosure;
    • baseplate, coupling guard and instrumentation;
    • certification, documentation and delivery requirements.

    The configuration model can use the application inputs to identify a suitable pump family and impeller range. Rules can prevent a material from being used with an incompatible fluid, prevent a motor from being selected for an unsuitable voltage, and require a high-temperature seal when the operating temperature exceeds a defined limit.

    The system can then select a pump assembly, motor, coupling, baseplate, seal kit and instruments. It can calculate a preliminary cost from material and purchased-part prices, apply labor and overhead assumptions, and produce a selling price using customer and channel rules. If the requested duty point falls outside standard performance limits, the quote can be routed to an application engineer instead of being rejected or silently accepted.

    Depending on the implementation, the output may be a quote-level BOM, a technical selection sheet, a CAD assembly, a drawing request or an ERP sales-order configuration. These outputs should be clearly labelled by maturity. A preliminary quote BOM is not automatically an approved manufacturing BOM.

    Where quote automation fits different manufacturing workflows

    Workflow Role of quote automation Typical output
    Configure-to-order (CTO) Selects proven modules and options within a defined product model Validated configuration, price, standard BOM and order data
    Make-to-order (MTO) Triggers production of a product after the customer order, often with limited configuration Quote, demand information and item or variant selection
    Assemble-to-order (ATO) Combines stocked or standard subassemblies after selection Configuration, component demand and assembly structure
    Engineer-to-order (ETO) Captures requirements and identifies engineering work for a non-standard design Budgetary quote, engineering scope, assumptions and approval tasks

    CTO is generally the easiest environment for high automation because the product rules and outputs are repeatable. ETO requires more human review because the design may not exist when the quote starts. Automation can still improve ETO by capturing requirements, estimating engineering effort, creating a preliminary structure and identifying assumptions, but it should not imply that an unverified design is production-ready.

    See the guide to configure-to-order, engineer-to-order and related manufacturing workflows for a fuller comparison.

    Benefits of quote automation for manufacturers

    Shorter response cycles

    Automating repeatable configuration, calculations and document production reduces the number of manual handoffs between sales, application engineering and pricing teams. The benefit is greatest where quotes repeatedly use the same product families and rules.

    Fewer configuration and pricing errors

    Validation can prevent combinations that a salesperson may not know are technically incompatible. Central pricing logic can also reduce inconsistent discounts and forgotten surcharges. Automation does not eliminate errors if the underlying model or price data is wrong; it moves the control point earlier in the process.

    Better engineering capacity

    Engineers can spend less time reviewing standard configurations and more time on genuine exceptions, new designs and complex applications. This requires a clear boundary between standard, reviewable and non-standard work.

    More consistent manufacturing data

    A configuration record linked to a BOM or ERP item can reduce re-entry from quote to order. This is valuable when the quoted product contains many options, quantities or technical attributes.

    Improved margin visibility

    When cost elements are linked to the configuration, commercial teams can see the effect of material substitutions, custom dimensions, expedited delivery and discounting before committing to a price.

    Traceable decisions

    Versioned rules, prices, approvals and configuration snapshots make it easier to explain why a quote had a particular scope and price. This supports revision management and post-order analysis.

    Limitations and risks

    Incorrect product models produce repeatable errors

    Automation amplifies the logic it is given. An incomplete dependency, outdated part number or incorrect calculation can create many incorrect quotes quickly. Model validation and test cases are essential.

    Engineering knowledge is difficult to encode

    Experienced engineers often use tacit knowledge, judgement and exceptions. Converting that knowledge into maintainable rules requires workshops, examples, ownership and agreement on what is standard.

    Cost data may not be current

    A sophisticated pricing engine cannot compensate for stale supplier prices, missing labor standards or inconsistent overhead assumptions. Data freshness and ownership should be part of the design.

    BOM maturity may be misunderstood

    A CPQ-generated list may support pricing but lack the revisions, operations and manufacturing context needed for production. The handoff to PLM or ERP must define which system creates and controls the released structure.

    ETO remains partially manual

    Quote automation can organize ETO work, but it cannot reliably remove engineering review where the product, performance or compliance basis is genuinely new.

    Integration creates operational dependencies

    Real-time calls to ERP, PLM or CAD may fail because of unavailable services, permissions, latency or inconsistent master data. The implementation needs error handling, reconciliation and a defined fallback process.

    Rules can become difficult to maintain

    Duplicated logic across CPQ, ERP, CAD and spreadsheets creates conflicting outcomes. A governance model should identify where each rule is authoritative and how changes are released.

    Data required for automated quoting

    A manufacturing quote automation project normally requires more than a product catalogue. The data foundation may include:

    • product families, variants and option definitions;
    • part numbers, revisions, units of measure and lifecycle status;
    • compatibility, exclusion and requirement rules;
    • engineering formulas, limits, standards and calculation inputs;
    • configurable BOM relationships and quantities;
    • material, purchased-part, labor and overhead costs;
    • price lists, discounts, customer agreements and currencies;
    • lead-time, availability and sourcing assumptions;
    • document templates, technical descriptions and revision references;
    • approval thresholds and exception categories.

    Data should be classified by owner. Product engineering may own technical rules, manufacturing engineering may own production structures, finance or commercial operations may own pricing policies, and ERP administration may own item and cost master data. A CPQ project should not hide these ownership decisions inside application configuration.

    Implementation approach

    Define the first product scope

    Start with a product family that has meaningful quote volume, repeatable rules and measurable business pain. Avoid selecting the most complex product as the first model unless the organization has the resources to manage its engineering exceptions.

    Document the current quote process

    Map every input, spreadsheet, calculation, approval, system lookup and manual handoff. Identify where errors occur and distinguish standard configurations from exceptions. This process map is more useful than a feature checklist when evaluating software.

    Build a governed product model

    Define features, options, attributes, constraints, calculations and outputs in a structured model. Use real historical quotes and known invalid combinations as test cases. Decide whether rules belong in CPQ, an engineering service, ERP, PLM or another system.

    Separate configuration, cost and price

    Do not use a single field to represent an option’s cost, price and commercial description. A selected motor may have a cost, a list price, a customer-specific price, a freight effect and a technical description. These values may come from different sources and change under different controls.

    Design the system handoff

    Specify what happens when a quote is accepted. Does CPQ create an ERP sales order, send a configuration identifier, request a BOM, create a PLM object, upload CAD parameters or simply pass a PDF to a salesperson? Each exchange needs field mapping, error handling and a clear system of record.

    Test combinations and revisions

    Testing should include valid configurations, invalid combinations, boundary values, missing data, price changes, currency changes, revisions, approval exceptions and integration failures. Test the generated document as well as the internal configuration and price.

    Release and govern the model

    Product models need version control, change requests, named owners and release dates. A rule change may affect open opportunities, existing quotes and active orders. The organization should decide whether old quotes retain the old model version or are recalculated under the new one.

    The manufacturing CPQ implementation guide covers requirements, migration, testing, governance, adoption and maintenance in more detail.

    How to evaluate quote automation software

    Buyers should evaluate the complete quote-to-order use case rather than counting generic CPQ features. Useful questions include:

    • Can the system model the product’s dimensions, options, dependencies and engineering constraints?
    • Can non-developers maintain rules, or does every change require custom code?
    • What types of calculations are supported, and how are calculation versions controlled?
    • Does the platform generate a sales BOM, configurable BOM, EBOM or MBOM?
    • How are part numbers, revisions, substitutes and quantities handled?
    • Can the system connect to authoritative ERP, PLM, PDM, CAD and CRM data?
    • Can it create CAD models or drawings, or does it only pass parameters to another system?
    • How are standard configurations separated from ETO exceptions?
    • Can it show cost, margin, price and approval reasons independently?
    • How are quote revisions, expired prices and historical configurations stored?
    • What APIs, webhooks, integration tools and error-monitoring capabilities are available?
    • How are dealers, distributors, application engineers and internal sales users supported?
    • What happens when an integration or external calculation service is unavailable?

    Vendor documentation and a proof of concept should be used to verify these answers. A demonstration of a simple option-selection flow does not prove that a platform can handle engineering calculations, production structures or CAD automation.

    Key measures after deployment

    Useful measures should connect automation to manufacturing outcomes. Examples include quote cycle time, percentage of quotes completed without engineering intervention, configuration error rate, quote-to-order conversion, gross-margin variance, approval turnaround time, percentage of quotes using current price data, re-entry between systems and time required to maintain a product model.

    Speed alone is not sufficient. A fast quote that contains an invalid motor, incomplete BOM or unsupported delivery promise can increase downstream cost. Quality, traceability and handoff accuracy should be measured alongside response time.

    Related concepts

    Quote automation is closely related to CAD and engineering automation when a configuration drives models, drawings or calculations. It also depends on BOM generation, costing and pricing and on integration architecture for reliable movement of data. Manufacturers comparing commercial approaches can use the manufacturing CPQ comparison and selection resources.

    Semantic map

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

    • CPQ configures configurable manufactured products.
    • Configuration rules prevent invalid product combinations.
    • Constraint-based configuration evaluates engineering limits.
    • Guided selling collects customer requirements.
    • Engineering calculations determine technical selections.
    • A configured product generates a quote-level BOM.
    • An EBOM represents an engineering product structure.
    • An MBOM represents a manufacturing product structure.
    • Costing calculates the expected cost of a configuration.
    • Pricing converts cost and commercial rules into a selling price.
    • Approval workflows review commercial and technical exceptions.
    • Quote documents describe the validated configuration.
    • CAD automation generates product-specific drawings when supported.
    • CPQ exchanges customer and configuration data with CRM.
    • CPQ exchanges item, cost and order data with ERP.
    • PLM controls product revisions and lifecycle information.
    • PDM manages engineering files and CAD data.
    • ETO quoting identifies work that requires engineering review.
    • CTO quoting uses pre-engineered product rules and modules.
    • Product model governance controls changes to quoting logic.

    Frequently asked questions

    What is quote automation for complex manufactured products?

    It is the automated conversion of customer requirements into a validated configuration, cost, selling price, approval workflow and quote document. Depending on the platform, it may also produce BOMs, technical specifications or CAD outputs.

    How is manufacturing quote automation different from sales CPQ?

    Sales CPQ commonly focuses on product selection, pricing, discounts and proposals. Manufacturing CPQ may additionally handle engineering constraints, calculations, configurable BOMs, CAD parameters, production data and ERP or PLM handoffs.

    Does quote automation generate a BOM?

    Some platforms generate a quote-level or configurable BOM, while others send configuration data to ERP or PLM for BOM creation. Buyers must verify whether the output is a sales BOM, EBOM, MBOM or production-ready structure.

    Can CPQ calculate the cost of a configured product?

    Many manufacturing CPQ systems support cost models, but the depth varies. Costing may include materials, purchased parts, labor, overhead, freight and engineering effort. The source and freshness of the cost data are critical.

    What is the difference between costing and pricing in CPQ?

    Costing estimates the manufacturer’s expense to produce or deliver the configuration. Pricing determines the amount charged to the customer using list prices, margins, discounts, agreements, surcharges and other commercial rules.

    Can quote automation handle engineer-to-order products?

    It can support ETO by capturing requirements, estimating engineering work, recording assumptions and routing exceptions. It should not represent an unverified custom design as a standard, production-ready configuration.

    Can a CPQ system create CAD drawings?

    Some platforms support CAD automation or connect to CAD automation services. Others only store selections or pass parameters to another system. This capability must be verified for the required CAD tool, model types, drawings and revision process.

    What product data is needed to automate quotes?

    Typical data includes product families, options, part numbers, rules, calculations, BOM relationships, costs, prices, lead times, technical descriptions, revisions and approval policies.

    Where should configuration rules be maintained?

    The answer depends on the architecture. Rules may be maintained in CPQ, PLM, ERP, CAD or an external service. The important requirement is to define one authoritative owner for each rule and prevent conflicting copies.

    How does quote automation connect with ERP?

    CPQ may retrieve item, cost, inventory or customer data from ERP and send back a quote, configuration identifier, BOM request or sales order. The integration can use APIs, middleware or controlled file exchanges.

    Does quote automation replace application engineers?

    No. It can automate repeatable selections and identify exceptions, allowing engineers to focus on non-standard applications, new designs, performance review and technical risk.

    How are invalid configurations prevented?

    Rules and constraints can require compatible options, exclude combinations, enforce numeric limits and trigger calculations. The quality of prevention depends on the completeness and maintenance of the product model.

    Can quote automation manage different currencies and customer prices?

    Many commercial CPQ systems support currencies, price lists, customer agreements and discount rules. Manufacturers should verify exchange-rate control, effective dates, tax handling and how historical quotes retain their original pricing basis.

    What is a configurable BOM?

    A configurable BOM is a product structure containing rules or selection conditions that determine which components and quantities apply to a particular configuration. It may require transformation into an approved EBOM or MBOM before production.

    How should manufacturers test an automated quoting model?

    Use historical quotes, valid and invalid combinations, boundary values, price changes, revisions, approval exceptions, missing data and integration failures. Test the configuration, price, BOM, document and downstream transaction together.

    What are the main risks of automated quoting?

    Common risks include incorrect rules, stale costs, unclear BOM ownership, duplicated logic, integration failures, unsupported ETO assumptions and documents that do not match the configured product.

    How should a manufacturer choose a quote automation platform?

    Evaluate product-model depth, rules, calculations, BOM outputs, pricing, CAD and engineering integration, ERP and PLM connectivity, workflow, governance, APIs, implementation effort and support for CTO, MTO, ATO and ETO processes.

    What is the first product family to automate?

    A suitable first candidate usually has substantial quote volume, repeatable configuration rules, available product data and a clear business problem. It should be complex enough to demonstrate value but bounded enough to govern effectively.

    How can a manufacturer measure quote automation success?

    Measure quote cycle time, engineering effort, configuration errors, margin variance, approval time, re-entry, use of current data and downstream order accuracy. Speed should be assessed alongside technical and commercial quality.

  • Product Bundles and Solution Pricing in Manufacturing CPQ

    Product bundles and solution pricing in manufacturing CPQ allow a company to quote a complete engineered solution rather than pricing isolated parts. A bundle may combine a base machine, drive system, control panel, safety equipment, installation accessories and service coverage. The CPQ system validates whether the selected components work together, calculates costs and prices, produces the relevant bill of materials (BOM), routes exceptions for approval and generates a customer-ready quote.

    In this context, CPQ means configure, price, quote. Manufacturing CPQ extends beyond generic sales quoting: it can connect product rules and engineering calculations to configurable BOMs, computer-aided design (CAD) outputs, enterprise resource planning (ERP), product lifecycle management (PLM) and production processes. Not every CPQ platform supports all of these capabilities, so manufacturers must verify the depth of product modeling, bundle logic, costing, downstream integration and engineering automation before selecting a system.

    A useful starting point is the guide to CPQ software for manufacturing. For the specific product-modeling foundation, see product configuration, and for the downstream commercial and manufacturing data flow see BOM, pricing and quoting.

    What are product bundles and solution pricing?

    A product bundle is a commercially and technically related group of products, assemblies, options, services or consumables sold as one solution. A bundle can be fixed, configurable or partially configurable. A fixed bundle always contains the same items. A configurable bundle allows choices such as capacity, material, voltage, motor, enclosure, accessories or service level. A solution bundle can also include multiple related products that must be engineered or delivered together.

    Solution pricing is the calculation of a price for the complete configured solution rather than simply adding unrelated item prices. It may include component prices, configuration-dependent costs, engineering effort, labor, freight, installation, warranty, risk margins, discounts and commercial adjustments.

    For example, a pump manufacturer might sell a chemical-transfer package containing:

    • a centrifugal pump selected by flow rate, head and fluid compatibility;
    • a motor selected by power, voltage and hazardous-area requirements;
    • a baseplate and coupling guard;
    • valves, strainers and instrumentation;
    • a control panel and variable-frequency drive;
    • documentation, testing and commissioning services.

    The bundle is not valid merely because every item exists in the catalog. The motor must match the pump duty, the materials must be compatible with the fluid, the control panel must support the selected voltage and the enclosure may need to meet a specified environmental or hazardous-location rating. The final price must reflect the resulting engineering and manufacturing requirements.

    How bundles differ from simple product kits

    Manufacturers should distinguish a commercial bundle from a manufacturing kit, sales package or configured solution. The terms are sometimes used interchangeably, but they can represent different data and operational behavior.

    Concept Meaning in manufacturing Typical CPQ requirement
    Fixed bundle A predefined group of items sold together. Bundle definition, price and component availability.
    Configurable bundle A package with selectable options and dependencies. Rules, constraints, option pricing and validation.
    Solution A combination of products, assemblies, services and engineering work that addresses a customer requirement. Cross-product compatibility, calculations, approvals and often project-level pricing.
    Kit A set of parts grouped for picking, assembly or delivery. Kit structure, inventory behavior and possibly a configurable BOM.
    Package or system A technically integrated equipment group delivered as a functional unit. System rules, interfaces, engineering outputs and production handoff.

    A simple sales bundle may only add several stock items to a quote. A manufacturing solution model may need to create a new assembly structure, select engineered components, calculate dimensions and send data to ERP or PLM. The implementation should therefore define whether the bundle is only a commercial construct, a manufacturing structure, or both.

    How manufacturing CPQ models a bundle

    A bundle model normally contains a hierarchy of products and assemblies. At the top is the solution or package. Under it are mandatory components, optional modules, substitution groups, accessories, services and engineering outputs.

    Bundle structure

    A typical industrial equipment bundle might be modeled as follows:

    • Solution: packaged water-treatment skid.
    • Primary equipment: pump, tank, filter and heat exchanger.
    • Drive and controls: motor, variable-frequency drive, panel and sensors.
    • Mechanical integration: frame, piping, fittings, guards and supports.
    • Commercial options: extended warranty, spare-parts kit, commissioning and training.
    • Engineering outputs: configured BOM, specification sheet, layout drawing and installation requirements.

    Each node can have attributes, valid values, quantities, dependencies, costs, prices and fulfillment behavior. A component may be included automatically when another option is selected. For example, selecting a high-temperature application may require a different seal material, insulation package and temperature-rated sensor.

    Rules and constraints

    Rules-based configuration uses explicit conditions such as “if voltage is 480 V, use a 480 V control package.” Constraint-based configuration evaluates permitted relationships and limits, such as motor power, shaft speed, flow, pressure and enclosure requirements. Guided selling asks questions in a sequence that helps a user reach a valid configuration, but it may not provide the same depth of technical constraint solving.

    A bundle model may contain several types of rules:

    • Inclusion rules: selecting a fire-rated enclosure adds a fire-rated door assembly and approved cable glands.
    • Exclusion rules: two incompatible communication modules cannot be selected together.
    • Dependency rules: a remote monitoring option requires a gateway and a suitable network connection.
    • Quantity rules: a long conveyor requires additional supports at defined intervals.
    • Calculation rules: pump size, motor rating, material thickness or cable size is calculated from technical inputs.
    • Approval rules: a nonstandard material, discount or delivery commitment requires review.

    Detailed guidance on product options, dependencies and validation is available in the product configuration guide.

    Solution pricing architecture

    Solution pricing should separate the different reasons why a price changes. This makes the model easier to test, explain and maintain.

    Pricing layer Examples Manufacturing considerations
    Component price Pump, motor, valve or panel list price. Item revisions, currencies, units and effective dates.
    Option price Stainless-steel construction, upgraded controls or additional sensors. May replace a standard component rather than add to it.
    Quantity price Additional conveyors, filters or spare parts. Quantity may be calculated from dimensions or capacity.
    Configuration surcharge Special coating, hazardous-area compliance or nonstandard testing. Should be tied to a clear technical trigger.
    Engineering price Application engineering, design work or custom documentation. Often depends on ETO complexity and approval.
    Service price Installation, commissioning, training or maintenance. May depend on site, duration, travel and scope.
    Commercial adjustment Customer discount, dealer margin or project-level adjustment. Requires authority limits, approval thresholds and auditability.

    The price engine may calculate a list price, net price, cost, gross margin and price explanation. A manufacturer should preserve the distinction between cost and price. Cost may include purchased components, labor, overhead, freight and engineering effort. Price is the amount offered to the customer after margins, discounts and commercial policies are applied.

    Bundle pricing strategies

    Several pricing approaches can be combined:

    • Component aggregation: add the prices of all selected items and services.
    • Bundle price: assign a defined price to a valid combination.
    • Replacement pricing: subtract the standard component and add the upgraded component.
    • Tiered pricing: apply different prices based on quantity, capacity or order volume.
    • Formula pricing: calculate price from dimensions, power, material weight or processing time.
    • Cost-plus pricing: apply a margin or markup to calculated cost.
    • Project pricing: combine equipment, services, risk allowances and commercial terms at solution level.

    Pricing rules should also handle effective dates, currencies, units of measure, regional price lists, customer-specific agreements and channel margins. If the CPQ price differs from ERP or finance data, the integration must define which system is authoritative for each value.

    From configured bundle to BOM

    A configured solution can generate one or more BOM structures. A configurable BOM represents possible components and selection logic before a customer configuration is finalized. 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. These structures may be related but are not interchangeable.

    For a packaged machine, CPQ might generate:

    • a quote-level commercial BOM showing customer-visible assemblies;
    • an EBOM for engineering review and design release;
    • an MBOM or ERP order structure for purchasing, routing and production;
    • a spare-parts list and service BOM for after-sales use.

    Whether CPQ directly creates an EBOM or MBOM depends on the platform architecture and integration design. Some systems produce a structured order configuration that ERP, PLM or a product data management (PDM) system transforms into the appropriate downstream structure. Others can generate production-relevant BOM lines directly. This capability must be verified rather than assumed.

    For a deeper treatment of BOM structures and quote generation, see BOM, pricing and quoting in manufacturing CPQ.

    Relationship with CAD and engineering automation

    Bundles become more valuable when technical selections drive engineering outputs. A CPQ platform may pass configuration parameters to CAD automation, a rules-based design service or a separate engineering application. Possible outputs include a parametric 3D model, 2D drawing, dimensional specification, load calculation or equipment layout.

    For example, a conveyor solution may use belt width, length, incline angle, product weight and throughput to determine frame sections, drive power, support spacing and guarding. The resulting dimensions can affect both the BOM and the price. If the system only changes the quote description without updating engineering data, the bundle is commercially configured but not fully engineered.

    CAD automation is not a universal CPQ feature. Manufacturers should verify whether a prospective system can:

    • store or calculate the parameters required by the CAD model;
    • call an external CAD or engineering service;
    • generate drawings or neutral files;
    • maintain revision and approval status;
    • return calculated dimensions and components to the CPQ model;
    • handle failures, incomplete inputs and manual engineering review.

    The CAD and engineering automation guide explains how these capabilities fit beside configuration and quoting.

    Approvals and commercial governance

    Solution pricing often creates approval requirements that do not exist for standard products. Approval triggers may include a margin below threshold, an unusual payment term, a nonstandard material, a custom delivery date, a safety-critical application or a large engineering commitment.

    A practical approval workflow should show:

    1. which rule or threshold triggered the approval;
    2. what cost, price, margin or technical value is affected;
    3. which person or role must review the exception;
    4. whether the approval changes the configuration, price or terms;
    5. which version of the configuration and pricing model was approved.

    Approvals should not be used to compensate for missing product rules. If sales repeatedly requests approval for a combination that is always valid, the product model may need a new rule or standard option. Conversely, an approval should not override a genuine safety or technical constraint without a controlled engineering process.

    Quote documents for bundled solutions

    The quote should communicate enough detail for the customer to understand the proposed solution without exposing internal manufacturing structures unnecessarily. A bundle quote may contain:

    • solution summary and application assumptions;
    • selected equipment and major options;
    • technical specifications and exclusions;
    • commercial price by system, assembly or service category;
    • delivery, installation and commissioning scope;
    • warranty, payment and validity terms;
    • drawings, rendered views or preliminary layouts where available;
    • approval notes and revision information.

    Customer-facing descriptions and internal BOM descriptions should be governed separately. A sales quote might describe “stainless-steel product-contact construction,” while the internal structure contains specific grades, fasteners and purchased parts. Both representations must remain linked to the same approved configuration.

    Enterprise-system relationships

    Bundle pricing normally involves several systems with different responsibilities.

    System Typical responsibility Example exchange with CPQ
    CRM, or customer relationship management Accounts, opportunities, contacts and sales activity. Opportunity context, customer and quote status.
    ERP, or enterprise resource planning Items, inventory, purchasing, orders, finance and production transactions. Item masters, costs, orders, availability and order structures.
    PLM, or product lifecycle management Product revisions, engineering releases, change control and lifecycle data. Released options, revisions, EBOMs and engineering status.
    PDM, or product data management CAD files, drawings and design metadata. CAD references, revisions and generated design files.
    CAD Geometry, drawings and design calculations. Parameters, models, layouts and drawings.
    PIM, or product information management Descriptions, attributes, media and channel content. Customer-facing product information and option content.
    MES, or manufacturing execution system Shop-floor execution, work instructions and production status. Released orders, routings or configuration-specific instructions.

    These systems are not interchangeable. A CPQ platform may own the selling configuration and calculated quote, while ERP owns the order and financial transaction. PLM may own engineering revisions, and CAD or PDM may own design files. The integration architecture should document ownership, synchronization frequency, identifiers, revision behavior and error handling. More guidance is available in CPQ integrations for manufacturing.

    Bundle workflows by manufacturing strategy

    Bundles can support several operating models, but the required depth differs.

    • Assemble-to-order (ATO): standard modules are assembled after the order. CPQ must select compatible modules and produce an order structure.
    • Make-to-order (MTO): the product is made after the order using a relatively standard design. Pricing, availability and production data are central.
    • Configure-to-order (CTO): customers select from predefined options and constraints. A valid configuration can usually map to known BOM and routing patterns.
    • Engineer-to-order (ETO): the order requires new or materially changed engineering. CPQ must capture requirements, estimate engineering work and hand off controlled inputs for design.

    A bundle can begin as CTO and become ETO when a customer requests a nonstandard capacity, interface or material. The system should make that transition explicit rather than pretending every solution is a standard configuration. See manufacturing CPQ workflows for related order-to-production patterns.

    Benefits and limitations

    Potential benefits

    • Fewer incompatible combinations reach the customer or engineering team.
    • Prices reflect selected options, calculated quantities and engineering scope.
    • Sales engineers can quote complete solutions with less manual spreadsheet work.
    • Configured BOM data can reduce re-entry between sales, engineering and ERP.
    • Approval decisions become traceable and tied to configuration and margin data.
    • Quote documents can present consistent technical and commercial information.

    Important limitations

    • A CPQ model is only as accurate as its product, cost and rule data.
    • Complex engineering calculations may require specialist applications or manual review.
    • Dynamic pricing can become difficult to maintain if formulas are undocumented.
    • Different BOM structures may require transformation between CPQ, PLM and ERP.
    • Frequent product changes create governance and regression-testing demands.
    • Large bundles can produce performance, usability and version-control challenges.
    • Commercial bundling does not automatically solve inventory, capacity or scheduling constraints.

    Implementation approach

    A successful implementation starts with a defined scope rather than attempting to model every product and exception at once.

    1. Select a representative bundle: choose a product family with meaningful configuration, pricing and downstream impact.
    2. Map the current workflow: document how requirements, options, costs, approvals, BOMs, drawings and orders move between teams.
    3. Define system ownership: identify where items, costs, prices, rules, revisions, CAD files and customer data are maintained.
    4. Separate standard and engineered content: mark which choices are CTO-valid and which trigger ETO review.
    5. Build the product model: create attributes, options, dependencies, constraints, calculations and bundle structures.
    6. Design the price model: define cost sources, price lists, formulas, discounts, margins, currencies and approval thresholds.
    7. Define output structures: specify quote lines, configurable BOMs, EBOM or MBOM mappings, drawings and ERP order data.
    8. Test realistic scenarios: include valid, invalid, boundary, obsolete, partially specified and exception configurations.
    9. Establish governance: assign rule ownership, release procedures, version control, audit records and change-impact testing.
    10. Measure operational results: track quote cycle time, configuration corrections, approval delays, engineering rework and order-data errors.

    Implementation planning should include data migration, integration testing, user adoption and ongoing maintenance. The manufacturing CPQ implementation guide covers these concerns in more detail.

    Evaluation checklist for manufacturing buyers

    When evaluating CPQ software for bundled industrial solutions, ask vendors to demonstrate a complete scenario rather than isolated features:

    • Can the system model nested bundles, substitutions and cross-product dependencies?
    • Can technical constraints prevent invalid combinations before quote submission?
    • Can calculated dimensions, capacities or quantities affect both BOM and price?
    • Can the system distinguish customer-visible bundle lines from internal component structures?
    • Can it calculate cost, margin, price and discount independently?
    • Can approval rules identify technical, commercial and engineering exceptions?
    • Can it produce the required quote, specification, BOM or order outputs?
    • Which capabilities are native, and which require custom development or external services?
    • How are product revisions, effective dates and obsolete options governed?
    • How are ERP, CRM, PLM, PDM, CAD, PIM and MES integrations implemented and monitored?
    • Can the model support dealer, distributor, internal sales engineering and customer self-service channels?
    • How are failed calculations, integration errors and incomplete ETO requirements handled?

    Vendor profiles and comparisons can help structure research, but manufacturers should validate documented capabilities through a scenario-based demonstration and technical proof of concept. See manufacturing CPQ software profiles and CPQ comparison and selection guidance.

    Semantic map

    The following relationships summarize how product bundles connect configuration, pricing, engineering and manufacturing execution:

    • CPQ configures configurable products.
    • Configuration rules prevent invalid combinations.
    • Product bundles combine products, assemblies and services.
    • Solution pricing calculates a commercial price for a configured solution.
    • Configured products generate configurable BOMs.
    • Engineering rules determine component compatibility.
    • Cost calculations inform solution pricing.
    • Approval rules govern commercial and technical exceptions.
    • CAD automation generates product-specific drawings.
    • EBOMs represent engineering product structures.
    • MBOMs represent manufacturing assembly structures.
    • CPQ exchanges item and order data with ERP.
    • CPQ exchanges revisions and released structures with PLM.
    • CRM provides opportunity and customer context to CPQ.
    • ETO requirements trigger engineering review.
    • Quote documents communicate approved solution scope.

    Frequently asked questions

    1. What is a product bundle in manufacturing CPQ?

    A product bundle is a group of related equipment, components, options and services sold as one configurable solution. It may also produce a structured BOM for engineering or production.

    2. How is solution pricing different from adding item prices?

    Solution pricing can include compatibility-driven substitutions, calculated quantities, engineering effort, services, risk allowances, discounts and project-level approvals in addition to component prices.

    3. Can a bundle contain products from different product families?

    Yes. A pump package, for example, may contain a pump, motor, valves, controls, piping and services. Cross-family rules must validate interfaces, capacities, materials and electrical requirements.

    4. Does every CPQ system generate a BOM?

    No. Some CPQ platforms generate quote lines or order configurations only. Others generate configurable BOMs or integrate with ERP and PLM to create downstream structures. This must be verified for each product.

    5. What is a configurable BOM?

    A configurable BOM describes possible components and selection logic before a specific customer configuration is finalized. It differs from an EBOM or MBOM, which represent engineering or manufacturing structures.

    6. Can CPQ generate an EBOM?

    Some systems can generate or export engineering-oriented structures, while others pass configuration data to PLM or engineering tools. The supported revision, release and transformation process should be documented.

    7. Can CPQ generate an MBOM?

    Some platforms or integrations can create manufacturing-relevant structures, but this is not universal. ERP or manufacturing systems may own the MBOM and transform data received from CPQ or PLM.

    8. How do bundle rules prevent configuration errors?

    Rules enforce inclusions, exclusions, dependencies, quantities, technical limits and required approvals. They can prevent incompatible motors, materials, controls or accessories from reaching the quote.

    9. What happens when a bundle requires custom engineering?

    The configuration can be routed to an ETO workflow. CPQ may capture requirements, estimate engineering effort, flag assumptions and hold the quote for engineering review.

    10. Can solution pricing include installation and commissioning?

    Yes. Services can be modeled as bundle components or calculated charges. The model may use site conditions, duration, travel, labor rates and scope assumptions.

    11. How should costs and prices be separated?

    Costs represent internal or supply-side economic inputs such as materials, labor and engineering. Prices are customer charges after margins, discounts, terms and commercial policies are applied.

    12. Can bundle pricing vary by customer or region?

    It can, provided the pricing model supports customer agreements, regions, currencies, channels, effective dates and approval controls. The authoritative source for each price should be defined.

    13. Is CAD automation required for manufacturing bundles?

    No. Many bundles can be quoted without automated CAD. CAD automation becomes important when selections change geometry, dimensions, drawings, layouts or engineering calculations.

    14. How does CPQ connect bundles to ERP?

    Depending on the architecture, CPQ may exchange item identifiers, prices, configuration data, BOM lines, customer information and order details with ERP. Ownership and error handling must be designed explicitly.

    15. How does PLM differ from ERP in a bundle workflow?

    PLM generally manages product revisions, engineering releases and lifecycle data. ERP manages transactions such as purchasing, inventory, costing, orders and production. Both may receive different outputs from CPQ.

    16. Can distributors use manufacturing CPQ bundles?

    Yes. A dealer or distributor channel can use a controlled bundle model with permitted options, channel pricing, customer-specific discounts and quote outputs while protecting technical rules.

    17. What approval triggers are common for solution pricing?

    Common triggers include low margin, unusual discounts, nonstandard materials, safety-sensitive applications, custom delivery commitments, large engineering effort and exceptional commercial terms.

    18. How should bundle models be tested?

    Test valid and invalid combinations, boundary values, substitutions, obsolete options, price changes, revision changes, incomplete requirements, integration failures and ETO escalation paths.

    19. What is the main limitation of a bundle model?

    It can become difficult to maintain when rules, prices, BOM mappings and engineering exceptions are undocumented or owned by different teams without coordinated governance.

    20. What should manufacturers ask during a CPQ demonstration?

    Ask the vendor to configure a realistic multi-product solution, apply technical rules, calculate cost and price, trigger an approval, generate the required BOM and quote, and show the ERP, PLM or CAD handoff.