CPQ Guide

Tag: engineering configuration

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