CPQ Guide

Tag: costing and pricing

  • CPQ for Heat Exchanger Manufacturers

    CPQ for heat exchanger manufacturers is software that combines product configuration, engineering validation, costing, pricing and quote generation for configurable heat transfer equipment. A suitable system can guide a user through shell-and-tube, plate, air-cooled or other exchanger designs, reject technically invalid combinations, calculate or capture engineering requirements, and pass the resulting product definition to enterprise systems.

    Heat exchanger configuration is a manufacturing problem rather than a simple sales quoting exercise. A quote may depend on duty, flow rates, temperatures, pressure, materials, corrosion allowances, tube dimensions, pass arrangements, nozzle locations, codes, testing requirements and production constraints. The CPQ system must therefore connect commercial inputs with engineering rules and manufacturing data.

    This guide explains how manufacturing CPQ applies to heat exchangers, which rules and data it requires, what outputs it can produce, how it integrates with ERP, CRM, PLM, PDM and CAD systems, and what manufacturers should verify before implementation. The general principles also apply to related equipment such as boilers, condensers, pressure vessels, evaporators and process skids.

    What is CPQ for heat exchanger manufacturing?

    CPQ means configure, price, quote. In heat exchanger manufacturing, it is an application or connected software architecture that represents product families, validates customer requirements, selects compatible components and materials, calculates costs and prices, and produces a technically controlled quotation.

    Generic sales CPQ may combine products, apply discounts and create a proposal. Manufacturing CPQ goes further when required. It can represent engineering relationships such as heat transfer duty, allowable pressure drop, design pressure, design temperature, material compatibility, tube count, surface area and nozzle arrangement. Depending on the platform and implementation, it may also create a configurable bill of material, an engineering bill of material, CAD parameters, datasheet outputs or an engineer-review package.

    Not every CPQ product supports thermal calculations, mechanical design, CAD automation or production BOM generation. Buyers should evaluate each capability as a documented feature or integration rather than assuming it is included because a vendor uses the term manufacturing CPQ.

    Why heat exchangers are difficult to configure

    A heat exchanger is usually a family of related products rather than a single standard item. The commercial model may offer a catalog of standard sizes, but the final design can still be specific to the application, fluid pair, duty and site conditions.

    Configuration area Typical heat exchanger inputs Possible downstream effect
    Thermal duty Heat load, inlet and outlet temperatures, flow rates, fouling factors and allowable approach temperature Heat transfer area, tube count, plate count, exchanger size or selected model
    Fluid and process data Fluid identity, concentration, viscosity, density, phase, solids content and corrosiveness Materials, velocity limits, pressure drop and construction method
    Mechanical design Design pressure, operating pressure, design temperature, vacuum conditions and cyclic service Wall thickness, heads, tubesheets, gaskets, seals and code requirements
    Materials Carbon steel, stainless steel, nickel alloys, titanium, special coatings and elastomers Component eligibility, cost, lead time, welding and procurement requirements
    Geometry Shell diameter, tube length, tube diameter, pass arrangement, frame size and nozzle orientation CAD dimensions, manufacturing operations, footprint and installation fit
    Compliance and testing Applicable pressure vessel code, inspection class, hydrotest, radiography, certification and documentation Engineering review, test plan, labor, subcontracted services and price
    Commercial requirements Quantity, currency, delivery location, warranty, spare parts and service scope Cost, margin, freight, terms and final quote

    These variables are interdependent. Increasing the required duty may increase surface area and exchanger size. A more corrosive fluid may require a different alloy, which changes cost, welding procedures and availability. A lower allowable pressure drop may require more flow area or a different arrangement. A CPQ implementation must model these relationships explicitly or route them to a validated engineering calculation.

    Core CPQ capabilities for heat exchanger manufacturers

    Product models and configuration structure

    The product model defines the exchanger families, options, attributes, components and relationships that users can select. A manufacturer may create separate models for fixed-tube-sheet shell-and-tube exchangers, U-tube exchangers, floating-head exchangers, gasketed plate heat exchangers and welded plate units.

    Each model can contain mandatory inputs, optional features and derived values. For example, a user may select a shell-and-tube family, enter the service conditions, choose a tube material and specify a nozzle standard. The system can derive a candidate size, restrict incompatible tube materials and expose only the head and gasket options that suit the selected pressure and temperature range.

    Product configuration is different from pricing. Configuration determines what product is technically and commercially valid. Pricing then assigns costs, prices, margins, discounts and commercial adjustments to that valid configuration. Keeping the two concerns distinct makes rule testing and maintenance easier. The product configuration guide explains product models, options, dependencies, constraints and validation in greater depth.

    Rules and constraints

    Rules prevent invalid or incomplete designs. Common rule types include:

    • Compatibility rules: a gasket material must be compatible with the selected fluid and temperature range.
    • Range rules: a design pressure, temperature, flow rate or velocity must remain within an approved range.
    • Dependency rules: a floating-head construction requires a compatible shell, tubesheet and maintenance arrangement.
    • Exclusion rules: a particular coating, tube material or nozzle option cannot be combined with a selected code or manufacturing process.
    • Calculation rules: surface area, tube count, shell diameter, estimated pressure drop or weight is derived from input values or an engineering service.
    • Approval rules: non-standard materials, unusual dimensions or ETO requirements require engineering review.

    Rules-based configuration applies explicit if-then relationships. Constraint-based configuration evaluates multiple conditions and seeks a valid combination within a solution space. Guided selling simplifies the user experience by asking a sequence of business or application questions. A heat exchanger CPQ implementation may use all three: guided selling for sales users, constraint validation for technical compatibility, and calculation or engineering services for design outputs.

    Thermal and mechanical engineering calculations

    Some manufacturers use CPQ to collect engineering inputs and pass them to specialist calculation software. Others implement selected calculations directly in the CPQ model. The right boundary depends on calculation complexity, certification requirements, platform capabilities and the manufacturer’s engineering governance.

    Potential calculations include heat transfer area, estimated overall heat transfer coefficient, temperature approach, flow velocity, pressure drop, tube count, pass arrangement, exchanger weight and preliminary dimensions. Mechanical design may require separate analysis for pressure boundary thickness, tubesheets, supports, expansion, vibration or code compliance.

    A commercial configurator should not be treated as a certified design tool merely because it performs arithmetic. Manufacturers should identify which calculations are preliminary, which are design-authoritative, which require engineering approval and which must be performed in validated specialist software. The CAD and engineering automation guide covers the relationship between CPQ, calculations, parametric design and engineering outputs.

    Materials, standards and compliance

    Material selection is often central to heat exchanger configuration. The product model may need to distinguish material grade, product form, corrosion allowance, cladding, surface treatment, weld procedure and traceability requirements. A material that is valid for one fluid or temperature range may be unsuitable for another.

    Rules may also reference pressure vessel codes, customer specifications, inspection requirements and regional documentation. CPQ should capture these requirements as structured data rather than leaving them only in free-text notes. However, the system should distinguish a customer-requested standard from an approved engineering design. Standards, code editions and internal policies require controlled ownership and review.

    Pricing and quoting for heat exchangers

    Heat exchanger pricing usually combines material, fabrication, engineering, testing, purchased components and commercial adjustments. A quote may need to account for metal weight, tube or plate quantity, weld length, machining, surface treatment, inspection, documentation, freight, installation support and expected engineering effort.

    Cost or price driver Example CPQ data Pricing consideration
    Raw materials Shell plate, tubes, plates, frames, heads, nozzles, gaskets and fasteners Quantity, grade, market price, scrap factor and supplier lead time
    Fabrication Rolling, forming, welding, machining, assembly and finishing Labor standards, routing, machine time and setup requirements
    Engineering Thermal design, mechanical checks, drawings and review hours Standard versus non-standard design and ETO complexity
    Testing and certification Hydrostatic testing, non-destructive examination, certificates and witnessed inspection Internal labor and external inspection costs
    Commercial terms Margin, currency, freight, payment terms, warranty and risk allowance Customer, region, project and delivery requirements

    Costing and pricing should use the configured product as their source rather than relying only on a manually selected price list. The system may calculate a standard price for a catalog configuration while flagging a custom design for engineering review and quotation adjustment. The BOM, pricing and quoting guide explains configurable BOMs, costing logic, quote generation and approvals.

    BOM, CAD and manufacturing outputs

    A bill of material, or BOM, lists the components required for a product. Heat exchanger CPQ can produce different BOM representations depending on the business process:

    • Configurable BOM: a rule-driven structure containing selectable components and alternatives.
    • Engineering BOM (EBOM): the engineering view of the designed product, including components, specifications and design relationships.
    • Manufacturing BOM (MBOM): the production view, organized for assembly, operations, work centers, consumables and manufacturing execution.

    An exchanger CPQ system might generate a preliminary EBOM containing shell sections, tubes, tubesheets, baffles, heads, nozzles, gaskets and supports. ERP or manufacturing planning systems may then transform or enrich this into an MBOM with routings, operation sequences and shop-floor requirements. Some platforms can generate a production-ready BOM; others only return a configured item, option codes or a structured data payload for another system.

    CAD automation may create a model or drawing by passing parameters such as shell diameter, tube length, nozzle orientation, support location and plate count to a parametric CAD template. It may also generate a datasheet or dimensional drawing. These outputs require controlled templates, naming conventions, revision management and engineering approval. Visualization can help users understand orientation and footprint, but a 3D image is not necessarily a manufacturing drawing.

    Typical CPQ workflow for a heat exchanger

    1. Capture the application: the user enters fluids, flow rates, temperatures, duty, pressure, installation constraints and applicable standards.
    2. Select a product family: the system proposes or guides the user toward a shell-and-tube, plate, air-cooled or other suitable family.
    3. Validate requirements: rules check ranges, materials, pressure and temperature compatibility, options and mandatory technical data.
    4. Run calculations or engineering services: the system derives a preliminary size or sends the requirements to an approved calculation engine.
    5. Complete configuration: the user selects construction details, materials, nozzles, supports, instruments, insulation, testing and documentation.
    6. Generate cost and price: the system calculates material, labor, engineering, testing and commercial values, applying approved pricing rules.
    7. Route exceptions: non-standard conditions, low margin, unusual materials or code requirements trigger engineering or commercial approval.
    8. Create outputs: the system produces a quote, technical datasheet, assumptions, exclusions, preliminary BOM and, where supported, CAD or drawing data.
    9. Transfer the order: an accepted configuration is sent to CRM, ERP, PLM, PDM, CAD or manufacturing systems with a controlled identifier and revision.

    This workflow can support configure-to-order (CTO), where the manufacturer assembles a validated product from known options, or make-to-order (MTO), where production begins after an order but uses a defined product model. Engineer-to-order (ETO) applies when substantial engineering is required for a specific project. Assemble-to-order (ATO) uses stocked or pre-engineered modules assembled after the order. Heat exchanger businesses often use a mixture of these modes across product families.

    Integration architecture

    CPQ normally sits between customer-facing and engineering or operational systems. A customer relationship management system, or CRM, may provide the opportunity and account context. CPQ manages the configuration, commercial calculation and quote. An enterprise resource planning system, or ERP, may manage items, inventory, purchasing, production orders, finance and fulfillment.

    Product lifecycle management (PLM) manages product definitions, revisions, approvals and lifecycle processes. Product data management (PDM) commonly manages CAD files and engineering documents. Computer-aided design (CAD) tools create models and drawings. A product information management system (PIM) may manage descriptive product and channel content. A manufacturing execution system (MES) manages production execution and shop-floor data. These systems are related but not interchangeable.

    System Typical relationship with CPQ
    CRM Opportunity, customer, account, sales stage and quote context
    ERP Items, costs, prices, inventory, orders, purchasing, production and finance
    PLM Approved product structures, revisions, engineering change and lifecycle governance
    PDM CAD files, drawings, documents and revision-controlled engineering data
    CAD Parametric models, drawings and product-specific geometry
    PIM Descriptions, specifications and channel content for products and options
    MES Production operations, execution instructions, labor and shop-floor feedback

    Integration may use APIs, middleware, files, event messages or direct database processes. The key design question is ownership. For example, CPQ may own the commercial configuration while PLM owns released engineering structures and ERP owns manufacturing items and costs. The CPQ integration guide provides a broader framework for defining these boundaries.

    Benefits and limitations

    Potential benefits

    • Faster preparation of technically consistent quotations.
    • Fewer invalid combinations of materials, dimensions and pressure or temperature requirements.
    • More consistent pricing for material-intensive and engineering-intensive products.
    • Earlier visibility of engineering effort, testing requirements and non-standard work.
    • Improved handoff from sales engineering to design, purchasing and production.
    • Reusable product knowledge instead of dependence on individual experts and spreadsheets.
    • Structured quote data that can support BOM generation, CAD automation and ERP order creation where integrations exist.

    Important limitations

    • A CPQ system cannot compensate for incomplete or contradictory product data.
    • Complex thermal and mechanical design may remain in specialist engineering software.
    • Rules can become difficult to maintain when product families, standards and exceptions are poorly governed.
    • Automatic BOM generation does not guarantee a correct MBOM or production routing.
    • CAD automation depends on robust templates, valid parameters and revision control.
    • Legacy ERP, PLM and CAD systems may make integration more difficult than configuration itself.
    • Sales users may bypass the system if it asks for too many technical inputs without suitable guidance.

    Implementation considerations

    Start with a product family that has meaningful quote volume, repeatable rules and measurable engineering effort. Do not begin by attempting to model every exchanger, customer exception and historical quotation. Establish a controlled scope such as a standard shell-and-tube family or a defined plate exchanger range.

    Build a governed product model

    Document attributes, option values, units, valid ranges, dependencies, default values and approval states. Identify which data is customer input, which is derived, which is calculated externally and which comes from ERP or PLM. Assign ownership for thermal rules, mechanical rules, material compatibility, pricing, drawings and release decisions.

    Separate standard and engineered paths

    A standard configuration can move through automated validation and pricing. A custom configuration may require a calculation package, design review, supplier confirmation or management approval. Both paths can use the same CPQ front end, but they should not pretend to have the same level of automation.

    Test engineering and commercial logic

    Test normal configurations, boundary values, incompatible materials, missing inputs, unit conversions, currency changes, revisions and exception routes. Use real historical requirements where possible, but verify them against current engineering standards. Test both the visible quote and the hidden outputs: BOM lines, item codes, dimensions, calculation results, approvals and integration messages.

    Plan maintenance and change control

    Heat exchanger rules change when materials, suppliers, codes, costs, design policies and product families change. A governance process should define who can change rules, how changes are reviewed, how versions are released and how old quotes remain reproducible. The CPQ implementation guide covers requirements, data migration, testing, deployment, governance and maintenance.

    How to evaluate CPQ software for heat exchangers

    Manufacturers should evaluate the actual product and implementation architecture against representative exchanger cases. A useful demonstration should include a standard design, an invalid material combination, a non-standard pressure requirement, a customer-specific nozzle arrangement, a price change and an ETO approval path.

    • Can the system model multi-level exchanger families and reusable options?
    • Can it express dependencies, exclusions, ranges and conditional requirements?
    • Can it call an external thermal or mechanical calculation service?
    • Can it represent units, formulas, tolerances and engineering assumptions?
    • Can it produce a configurable BOM, EBOM or item structure, and under what conditions?
    • Can it pass parameters to CAD or generate drawings through an approved integration?
    • Can it separate material cost, labor, engineering, testing, freight and margin?
    • Can it support standard CTO or MTO designs alongside ETO exceptions?
    • How are ERP, CRM, PLM, PDM and CAD ownership and revisions handled?
    • How are rules tested, versioned, audited and maintained by internal teams?

    Vendor comparisons should focus on documented capabilities, implementation responsibilities and integration boundaries rather than feature-count claims. The manufacturing CPQ software section and CPQ comparison guides can support a broader selection process.

    Semantic map

    The following relationships summarize how CPQ connects heat exchanger requirements with engineering and manufacturing outputs:

    • Heat exchanger CPQ connects application requirements to product configurations.
    • Configuration rules prevent incompatible materials, dimensions and service conditions.
    • Thermal inputs influence heat transfer area and exchanger selection.
    • Mechanical requirements influence pressure boundary components and construction.
    • Configured products generate structured BOM data when the platform supports BOM generation.
    • CPQ pricing uses configuration data, cost data and commercial rules.
    • CAD automation uses approved parameters to generate product-specific models or drawings.
    • CRM provides opportunity context for the CPQ quote.
    • ERP receives order, item, pricing or BOM data according to the integration design.
    • PLM and PDM govern engineering revisions and released design information.
    • ETO exceptions trigger engineering review rather than uncontrolled automatic release.
    • Manufacturing workflows transform an accepted quote into engineering and production work.

    Frequently asked questions

    1. What does CPQ mean for a heat exchanger manufacturer?

    It means using configure, price, quote software to manage heat exchanger requirements, technical options, validation, pricing and quotation outputs. Depending on the platform, it may also connect to calculations, BOM, CAD and enterprise systems.

    2. Can CPQ calculate the required heat transfer area?

    Some implementations perform selected thermal calculations directly, while others send inputs to specialist engineering software. The calculation method, validation status and engineering approval process must be verified.

    3. Can CPQ replace thermal design software?

    Usually not in every situation. CPQ may handle preliminary sizing or orchestrate a calculation service, but complex or code-controlled designs may still require dedicated thermal and mechanical engineering tools.

    4. Which heat exchanger types can CPQ model?

    It can be configured for shell-and-tube, gasketed plate, welded plate, brazed plate, air-cooled and other product families if their options, rules and calculations are properly modeled.

    5. Does CPQ generate a BOM for a heat exchanger?

    Some platforms generate configurable BOMs or engineering BOMs. Others pass option selections to ERP or PLM for BOM resolution. A buyer should confirm whether the output is an EBOM, MBOM, configurable structure or only an item code.

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

    An EBOM is the engineering view of the designed exchanger. An MBOM is organized for manufacturing, including production structure, operations, consumables or work-center needs. They may not be identical.

    7. Can CPQ automate heat exchanger CAD drawings?

    Some CPQ architectures integrate with parametric CAD or document-generation tools. Automation depends on stable templates, supported parameters, revision control and engineering approval; it is not a universal CPQ feature.

    8. How does CPQ handle material compatibility?

    The product model can use compatibility rules based on fluid, concentration, temperature, pressure, corrosion requirements and approved material lists. Engineering review may still be required for unusual services.

    9. Can CPQ support pressure vessel codes?

    It can capture code selections and apply related options or approval rules. Code compliance calculations and certification should remain under the manufacturer’s controlled engineering process unless specifically validated.

    10. Can CPQ price custom heat exchangers?

    Yes, if cost drivers and commercial rules are modeled. Custom designs may require engineering hours, supplier quotations, material risk allowances or manual approval rather than a fully automatic price.

    11. Is CPQ suitable for engineer-to-order heat exchangers?

    It can support ETO by capturing structured requirements, identifying exceptions and creating an engineering handoff. It does not eliminate the engineering work required for genuinely novel designs.

    12. What is the role of ERP in a heat exchanger CPQ architecture?

    ERP commonly manages items, costs, purchasing, inventory, production orders, finance and fulfillment. CPQ may send the accepted configuration, price, item data or BOM to ERP, depending on system ownership.

    13. What is the role of PLM or PDM?

    PLM manages product lifecycle, revisions and engineering approvals. PDM commonly manages CAD files and documents. They help control released design information that CPQ should not independently duplicate or release.

    14. Can distributors use heat exchanger CPQ?

    Yes. A distributor-facing configuration can expose approved product choices, application questions, pricing and quotation workflows while hiding internal engineering complexity. Complex exceptions should route to the manufacturer.

    15. How should a manufacturer start a CPQ project?

    Start with one product family, define its rules and data ownership, map the quote-to-production process, establish integration boundaries and test representative configurations before expanding scope.

    16. What are the biggest CPQ implementation risks?

    Common risks include incomplete product data, undocumented engineering knowledge, over-complex rules, unclear system ownership, weak testing, poor revision control and attempting to automate ETO designs too early.

    17. How is manufacturing CPQ different from generic sales CPQ?

    Manufacturing CPQ must often represent engineering constraints, materials, dimensions, calculations, BOMs, CAD outputs and production handoffs in addition to price and quote documents.

    18. What should be included in a heat exchanger CPQ proof of concept?

    Use a standard exchanger, a boundary condition, an incompatible material case, a custom nozzle or dimension request, a cost change, an approval route and a downstream output such as a BOM, datasheet or ERP payload.

  • CPQ for Engineer-to-Order Manufacturing

    CPQ for engineer-to-order manufacturing helps manufacturers convert a customer requirement into a technically valid, priced and manufacturable order. It does more than generate a sales quote. A manufacturing CPQ system can capture application data, apply product rules, perform engineering calculations, identify standard and custom components, create a configurable bill of materials (BOM), initiate CAD or engineering work, and transfer approved order data to enterprise systems.

    Engineer-to-order (ETO) products are designed or substantially engineered for a specific customer after the order or quotation process begins. Examples include custom pumping systems, industrial machinery, material-handling equipment, process skids, large electrical assemblies and specialty vehicles. In these environments, the central question is not simply “What is the price?” It is “Can this product be designed, manufactured and delivered within the stated requirements, and what data is needed to do so?”

    This guide explains how CPQ fits into that process, which data and rules it requires, how it connects with engineering and production systems, and where its limitations must be managed.

    What is CPQ for engineer-to-order manufacturing?

    CPQ for engineer-to-order manufacturing is software that supports the configuration, pricing, quoting and engineering handoff of products that require customer-specific design or validation. CPQ means configure, price, quote. In an ETO context, configuration usually defines the design basis and requirements rather than producing a completely finished product definition without engineering involvement.

    A suitable CPQ process should distinguish between three outcomes:

    • Standard configuration: The selected options fit an existing product model and can often proceed through configure-to-order or make-to-order production.
    • Configured variant: The selection is valid but requires a product-specific BOM, calculation, drawing or engineering review.
    • New or exceptional design: The requirements exceed the approved product model and must be handled as an engineering project, with controlled assumptions, approvals and design work.

    CPQ does not replace computer-aided design (CAD), product lifecycle management (PLM), enterprise resource planning (ERP) or manufacturing execution system (MES). Instead, it coordinates information between these systems when the product model and integrations are designed appropriately. Not every CPQ platform supports BOM generation, CAD automation, engineering calculations or ETO workflows, so each capability must be verified during software evaluation.

    See the broader manufacturing CPQ guide for an overview of CPQ architecture and use cases.

    How ETO CPQ differs from generic sales CPQ

    Generic sales CPQ typically focuses on selecting commercial options, applying discounts and producing a proposal. That may be adequate for standardized products or subscription services. ETO manufacturing requires a deeper product and engineering model.

    Concern Generic sales CPQ ETO manufacturing CPQ
    Configuration Option selection and compatibility checks Technical requirements, dimensions, materials, ratings, capacities and constraints
    Pricing List prices, discounts and commercial rules Material, labor, purchased parts, engineering effort, risk, overhead, freight and margin
    Output Quote or proposal Validated requirements, configuration data, cost basis, BOM inputs and engineering work package
    Engineering Usually outside the CPQ workflow Calculations, CAD parameters, design review and controlled exceptions may be included
    Production handoff Order details for fulfillment Production-relevant master data, revisions, documents and approval status
    Exceptions Often handled manually Classified as standard, configurable, configurable-with-review or new design

    The distinction is important when selecting software. A platform may be strong at guided selling and proposal generation while having limited support for engineering calculations or manufacturing BOMs.

    The ETO CPQ workflow from requirement to production

    The exact workflow varies by industry and product architecture, but a practical ETO process usually contains the following stages.

    1. Capture the customer requirement

    The process begins with application and technical requirements rather than only a product name. A sales engineer may record flow rate, pressure, temperature, fluid properties, operating environment, required capacity, footprint, voltage, compliance requirements and delivery constraints for a pumping system. For a conveyor, the inputs may include load, length, elevation, throughput, belt type, motor characteristics and site conditions.

    Requirements should be represented as structured data wherever possible. Free-text notes are useful for context, but they are difficult to validate, calculate or transfer reliably to engineering and ERP systems.

    2. Apply product rules and constraints

    The CPQ product model evaluates whether the requested combination is allowed. Rules can express dependencies, exclusions, required selections, ranges and conditional behavior. For example:

    • A high-temperature seal requires a compatible elastomer and may exclude a standard coating.
    • A pump operating above a specified pressure requires a particular casing material and inspection level.
    • A vehicle body length may require a different chassis, axle rating and braking package.
    • A motor voltage must match the selected electrical enclosure and control system.
    • A structural span above a defined length may require an additional support assembly.

    Rules-based configuration uses explicit product logic such as “if option A is selected, require component B.” Constraint-based configuration evaluates permitted values and relationships, such as dimensional, capacity or compatibility limits. Guided selling leads a user through questions and recommendations but does not, by itself, guarantee complete engineering validation. These approaches may be combined.

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

    3. Perform engineering calculations

    Many ETO products cannot be priced or selected correctly without calculations. A CPQ application may contain calculation logic, call an external engineering service or pass requirements to a specialized application. Possible calculations include pump head and flow selection, heat-exchanger sizing, motor power, structural loading, pressure ratings, cable sizing, storage capacity and vehicle payload.

    Calculations should identify their inputs, formulas, units, assumptions, valid ranges and revision. A result such as “recommended motor: 30 kW” should be traceable to the requirements and calculation version that produced it. If the calculation is only advisory, the workflow should make clear that engineering approval remains necessary.

    4. Determine the engineering path

    After validation, the system can classify the order. A standard configuration may proceed automatically. A valid but unusual configuration may require an engineering review. A genuinely new design may create an engineering task with requirements, assumptions, selected reference products and customer documents.

    This classification prevents two common mistakes: sending an invalid order directly to production, or sending every order through a slow manual engineering process even when the design is already covered by approved rules.

    5. Calculate cost and price

    ETO pricing may include material, purchased components, manufacturing labor, engineering hours, testing, documentation, tooling, freight, installation and project risk. CPQ can calculate a target cost and apply pricing policies, but the calculation depends on reliable source data.

    Costing and pricing are related but different. Costing estimates what the manufacturer is expected to spend. Pricing determines what the customer is charged after considering margin, market conditions, commercial policy and risk. Engineering changes after quotation may require a revised cost and price.

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

    6. Generate quote and approval data

    The quotation should describe the technical basis of the offer. It may include selected options, operating assumptions, performance values, exclusions, delivery assumptions, documentation, testing and validity conditions. A technically detailed quote reduces ambiguity when the order moves from sales to engineering.

    Approval rules may be triggered by discount level, margin, non-standard materials, unusual delivery requirements, export restrictions, contractual terms or technical risk. Approvals should preserve the configuration revision and the price version used to create the offer.

    7. Create the engineering and manufacturing handoff

    When the customer accepts the quote, the approved configuration becomes an order baseline. The handoff may contain:

    • customer and project identifiers;
    • requirements and operating conditions;
    • selected options and parameter values;
    • calculation results and assumptions;
    • approved exceptions and deviations;
    • cost and price information where appropriate;
    • component and material requirements;
    • BOM or BOM-generation instructions;
    • CAD parameters, reference models or drawing requests;
    • required certificates, inspections and documentation;
    • revision, approval and change-control status.

    The goal is not merely to send a PDF to engineering. It is to send structured, versioned data that can be reused by PLM, CAD, ERP and production processes.

    How product data becomes production-ready

    A central ETO CPQ design question is how a commercial configuration becomes an engineering and manufacturing definition. This normally requires several related data structures.

    Product model

    The product model defines features, options, parameters, relationships, rules, calculations and outputs. It may include a machine family, allowable dimensions, compatible materials, standard assemblies and approved alternatives. The model should describe what users may select and what the organization is prepared to support.

    Configurable BOM

    A configurable BOM contains rules or selection logic that expands into a product-specific list of components. For example, a pump model may include one of several impellers, a selected seal package, a motor, coupling, baseplate, instrumentation and documentation package.

    The configurable BOM is not necessarily the final manufacturing BOM. It may be an intermediate structure used to derive an engineering BOM (EBOM) or manufacturing BOM (MBOM).

    • EBOM: An engineering bill of materials organized around the designed product and its functional or design structure.
    • MBOM: A manufacturing bill of materials organized around how the product is assembled, fabricated, inspected and produced.
    • Configurable BOM: A rule-driven structure that resolves into selected components based on configuration inputs.

    Some CPQ systems generate a complete BOM. Others send configuration parameters to ERP or PLM, where the BOM is expanded. The ownership of each structure must be defined rather than assumed.

    CAD and engineering outputs

    CAD automation can use configuration values to select models, set dimensions, create assemblies or generate drawings. In an enclosure project, for example, the configured width, height, mounting pattern and cable-entry arrangement may drive a parametric CAD model.

    However, CAD automation has technical prerequisites: stable templates, controlled parameters, naming conventions, compatible revisions and a way to handle geometry that falls outside the template. A CPQ platform that displays a 3D product image is not necessarily capable of generating production CAD.

    Read more about CAD, engineering and design automation.

    System architecture and integrations

    ETO CPQ normally sits between customer-facing processes and engineering or enterprise systems. The architecture should define which system owns each type of data.

    System Typical responsibility Possible CPQ exchange
    CRM Customer, opportunity, contacts and sales activity Opportunity context, account, quote status and acceptance
    CPQ Configuration, calculations, pricing, quote and handoff logic Validated configuration and commercial outputs
    CAD Geometric design and engineering models Parameters, references, models and drawing requests
    PDM Product data and CAD document control Files, metadata, revisions and approved references
    PLM Product structures, lifecycle, revisions and change management EBOM, requirements, specifications and engineering status
    ERP Items, inventory, purchasing, costing, orders and planning Items, sales order, BOM, routing and pricing data
    MES Shop-floor execution and production records Released work instructions, routings or production identifiers
    PIM Commercial product information and content Descriptions, attributes and customer-facing content

    CRM, ERP, PLM, PDM, PIM and MES are not interchangeable. Integration should specify data ownership, identifiers, revision behavior, error handling, security and timing. The CPQ integration guide covers these system relationships in more detail.

    CTO, ETO, MTO and ATO in one process

    Manufacturers often support several fulfillment models. Configure-to-order (CTO) uses predefined options and generally approved product structures. Engineer-to-order (ETO) requires customer-specific engineering. Make-to-order (MTO) means production starts after an order but may use an established design. Assemble-to-order (ATO) combines stocked or prebuilt modules after the order.

    Model Design status at order Typical CPQ role
    CTO Defined by approved options Validate selections, price and generate order configuration
    ETO Requires customer-specific engineering Capture requirements, calculate, price, route engineering and control revisions
    MTO Established design, produced after order Validate demand, price and trigger production supply
    ATO Modules already available Configure the finished combination and reserve or trigger assembly

    One product family may move between these models. A standard pump package may be CTO, while a custom skid with site-specific piping, controls and structural requirements is ETO. The CPQ workflow should make this distinction explicit.

    See the guide to CTO, ETO, MTO, ATO and order-to-production workflows.

    Benefits of CPQ in ETO manufacturing

    • Earlier technical validation: Invalid combinations and missing requirements can be identified before order entry.
    • Faster engineering triage: Engineers can focus on exceptions and new designs rather than rechecking routine selections.
    • More consistent costing: Material, labor, engineering and risk inputs can be calculated from the same configuration.
    • Better quote quality: Assumptions, exclusions and technical outputs are tied to a specific revision.
    • Reduced order-entry errors: Structured configuration data is less ambiguous than manually rekeyed descriptions.
    • Improved reuse: Approved product rules, calculations and templates can be reused across sales channels.
    • Traceable handoff: Sales, engineering, purchasing and production can reference the same approved order basis.

    Limitations and risks

    ETO CPQ is not a shortcut around product governance or engineering complexity. Its effectiveness is limited by the quality and scope of the product model.

    • Incomplete rules: Undocumented engineering knowledge still produces manual review and order risk.
    • Rule explosion: A large number of exceptions can make the model difficult to test and maintain.
    • Unbounded customization: A product that is effectively redesigned for every customer may not be suitable for full automation.
    • Unreliable source data: Incorrect costs, item identifiers, dimensions or revisions undermine every downstream output.
    • Integration complexity: Different systems may use different item structures, units, revisions and approval states.
    • False confidence: A configuration can be logically valid while still requiring engineering judgment, regulatory review or site verification.
    • Maintenance burden: Product changes, supplier substitutions and manufacturing changes must be reflected in rules and outputs.

    A useful design principle is to automate repeatable decisions and expose uncertain decisions for controlled human review. The system should show why an option is unavailable, which assumption produced a result and what remains unapproved.

    Implementation approach

    Start with a bounded product family

    Select a product family with meaningful configuration volume, recurring engineering work and reasonably stable rules. Avoid beginning with the entire catalog or with a product whose design process is still changing rapidly.

    Document the decision model

    Work with sales engineering, design engineering, manufacturing, costing and IT to document inputs, constraints, calculations, outputs and exceptions. Identify rules that are mandatory, advisory or subject to approval.

    Define data ownership

    Decide whether CPQ, ERP, PLM, PDM or another system owns items, descriptions, revisions, costs, BOMs, CAD files and manufacturing structures. Define how approved data moves between systems.

    Separate reusable logic from customer-specific data

    Product rules and approved templates should not be mixed indiscriminately with customer notes or project assumptions. This separation makes the model easier to govern and reuse.

    Test engineering edge cases

    Testing should include valid standard configurations, invalid combinations, boundary values, unit conversions, unavailable components, obsolete items, manual overrides, revision changes and integration failures. Test the generated quote, BOM, CAD request and ERP transaction—not only the screen flow.

    Establish release governance

    Assign owners for product rules, calculations, pricing, item data, templates and integrations. Use version control, approval status and change-impact analysis. A product change that affects a seal, motor, material or regulatory requirement may affect configuration rules, costs, CAD and production data simultaneously.

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

    How to evaluate ETO CPQ software

    Manufacturers should evaluate an ETO-capable CPQ platform against actual product and engineering scenarios rather than generic feature counts. Ask vendors to demonstrate:

    • multi-level product models and reusable rules;
    • dimensional, capacity and compatibility constraints;
    • unit handling and engineering calculations;
    • configuration statuses and human approval steps;
    • configurable BOM expansion and EBOM or MBOM handoff;
    • CAD parameters, drawing requests or documented CAD integrations;
    • cost and price separation;
    • revision and change-control behavior;
    • ERP, PLM, PDM, CRM and CAD integration patterns;
    • API availability and error handling;
    • performance with large product models;
    • rule testing, audit trails and model governance;
    • support for dealer, distributor and internal engineering users;
    • handling of configurations that exceed the approved product model.

    Ask the vendor to identify which capabilities are native, which require configuration, which depend on partner or external systems, and which are not supported. A product configurator, quoting tool and engineering automation platform may be combined in one product or implemented as separate components.

    Practical example: engineer-to-order pump package

    Consider a manufacturer quoting a pump package for a chemical-processing site. The customer provides flow, differential pressure, fluid temperature, fluid properties, hazardous-area requirements, voltage, materials, instrumentation and delivery conditions.

    1. CPQ captures the structured requirements and checks units and required fields.
    2. A selection or calculation service identifies suitable pump families and motor ranges.
    3. Rules require compatible casing, impeller, seal, motor, controls and hazardous-area components.
    4. The product model identifies standard components and flags the custom base frame and piping arrangement for engineering.
    5. Costing includes purchased items, fabrication, engineering, testing and documentation.
    6. The quote records operating assumptions, exclusions and the technical approval status.
    7. After acceptance, the approved configuration and calculation results create an engineering work package.
    8. Engineering produces or approves the design, while PLM or PDM controls drawings and revisions.
    9. ERP receives the order and the appropriate product, BOM, purchasing and production information.

    In this example, CPQ does not need to pretend that every design decision is automated. Its value is to validate what can be validated, preserve the requirements, identify the engineering boundary and prevent the approved commercial configuration from being lost during handoff.

    Semantic map

    The following relationships summarize how ETO CPQ connects commercial, engineering and manufacturing concepts:

    • CPQ configures configurable products.
    • Configuration rules prevent invalid combinations.
    • Engineering calculations validate application requirements.
    • A configured product generates or drives a configurable BOM.
    • A configurable BOM can produce an EBOM or provide inputs to one.
    • An EBOM can be transformed into an MBOM for production.
    • CAD automation generates product-specific models or drawings.
    • CPQ exchanges customer and order data with CRM.
    • CPQ exchanges items, orders and BOM data with ERP.
    • PLM manages product structures, revisions and lifecycle status.
    • PDM controls CAD files and engineering documents.
    • ETO requires customer-specific engineering.
    • CTO uses approved configuration options.
    • Pricing converts cost and commercial rules into a customer price.
    • An approved quote becomes an order baseline for engineering and production.

    Frequently asked questions

    1. What does CPQ mean in engineer-to-order manufacturing?

    CPQ means configure, price, quote. In ETO manufacturing, it captures technical requirements, validates selections, supports calculations and produces a controlled quote and engineering handoff.

    2. Can CPQ replace engineering in an ETO business?

    No. CPQ can automate repeatable decisions and route exceptions, but engineering judgment remains necessary for new designs, unusual conditions, compliance and final approval.

    3. Does every CPQ system support engineer-to-order workflows?

    No. Some products focus on sales configuration and quoting. Buyers must verify support for calculations, approvals, BOMs, CAD, revisions, engineering handoff and relevant integrations.

    4. How does ETO CPQ differ from configure-to-order CPQ?

    Configure-to-order generally selects from approved product options. ETO CPQ must also capture requirements, manage customer-specific design work and control the transition from quote to engineering.

    5. Can CPQ generate a manufacturing BOM?

    Some systems can generate or expand BOMs, while others send configuration data to ERP or PLM. The buyer must verify whether the system creates an EBOM, MBOM, configurable BOM or only BOM instructions.

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

    An EBOM represents the designed product structure. An MBOM represents how the product is assembled or manufactured. They may contain related but differently organized information.

    7. Can CPQ automate CAD for custom products?

    Some CPQ solutions support CAD parameters, model generation or drawing workflows through native or external tools. A visual configurator alone does not prove production CAD automation.

    8. What engineering calculations can ETO CPQ perform?

    Depending on the platform and implementation, calculations may cover sizing, capacity, pressure, power, loading, dimensions, materials or compatibility. Each calculation must be validated for its intended engineering use.

    9. How does CPQ handle a requirement outside the product model?

    It may reject the input, flag an exception, route the opportunity for engineering review or create a new design task. The correct behavior depends on company policy and product risk.

    10. Should CPQ own product data or should PLM own it?

    Ownership varies. CPQ commonly owns configuration and quote logic, while PLM owns product structures and lifecycle data. The architecture must explicitly define ownership and synchronization.

    11. Is ERP integration required for ETO CPQ?

    It is not technically mandatory, but integration is often important for item data, costs, sales orders, purchasing, inventory, BOMs and production planning.

    12. What role does CRM play in an ETO workflow?

    CRM typically provides account, opportunity and customer context. CPQ adds technical configuration and commercial calculation, then returns quote status and value to CRM.

    13. Can CPQ calculate the price of engineering effort?

    Yes, if engineering effort is modeled through estimated hours, task types, rates, complexity factors or project rules. The resulting estimate should be distinguished from actual labor recorded later.

    14. How should manufacturers test an ETO CPQ model?

    Test standard, boundary, invalid and exceptional configurations, along with calculations, prices, revisions, BOM outputs, CAD requests and system integration failures.

    15. What data is needed to implement ETO CPQ?

    Typical inputs include product options, rules, dimensions, materials, item masters, costs, prices, engineering formulas, BOM structures, CAD templates, approval policies and integration identifiers.

    16. Can one CPQ system support both CTO and ETO?

    Potentially. A product family can use automated CTO paths for approved variants and route more complex selections into ETO review. The platform must support different statuses and workflows.

    17. How does CPQ reduce sales-to-engineering errors?

    It replaces ambiguous manual descriptions with structured requirements, validated selections, explicit assumptions, revision information and reusable order data.

    18. What is the biggest implementation risk?

    A common risk is automating an incomplete or poorly governed product model. The software cannot reliably compensate for undocumented rules, inconsistent item data or unclear engineering ownership.

    19. Should every ETO exception be automated?

    No. Automation is appropriate for repeatable and well-understood decisions. Novel, high-risk or poorly bounded designs should remain subject to controlled human review.

    20. What should a manufacturer ask during a CPQ demonstration?

    Use a real product scenario and ask the vendor to show requirements capture, constraints, calculations, costing, quote revision, engineering review, BOM output, integration behavior and handling of an out-of-model request.

  • Manufacturing CPQ vs Mainstream Sales CPQ: What Makes It Different?

    Manufacturing CPQ is different from mainstream sales CPQ because it must define and validate an engineered product, not only select commercial options and calculate a selling price. A mainstream sales CPQ application may help a representative choose products, apply discounts, and create a proposal. Manufacturing CPQ can also determine whether a configuration is technically feasible, calculate product dimensions or performance, generate a configurable bill of materials (BOM), automate CAD outputs, calculate cost, and pass manufacturing-ready data to enterprise systems.

    CPQ means configure, price, quote. In a manufacturing environment, those three activities are connected to product engineering and production. A configured industrial pump, electrical enclosure, conveyor, trailer, or air-handling unit may require rules about materials, dimensions, motor selection, pressure, temperature, safety requirements, accessories, manufacturing methods, and delivery configuration. The quote is therefore an early representation of a product that may later become an order, engineering package, BOM, or production instruction.

    The distinction is not absolute. Some mainstream sales CPQ products support complex configuration, and some manufacturing CPQ products focus mainly on quoting. Buyers should evaluate documented capabilities rather than assume that every CPQ platform includes BOM generation, CAD automation, engineering calculations, or product lifecycle management (PLM) integration.

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

    What is mainstream sales CPQ?

    Mainstream sales CPQ is software primarily designed to help sales teams configure an offering, calculate a price, and produce a quote or proposal. It commonly operates close to a customer relationship management (CRM) system and focuses on commercial workflows.

    A sales representative might select a base product, add service packages, choose quantities, apply an approved discount, and generate a proposal. The system may enforce rules such as “option B requires option A” or “this discount requires manager approval.” These capabilities are valuable for many businesses, particularly when the products are standardized or when the principal complexity is commercial rather than engineering-related.

    Mainstream sales CPQ often manages:

    • product and service catalogs;
    • guided selling and recommendations;
    • option selection and simple dependencies;
    • pricing, discounts, promotions, and approvals;
    • quote documents and proposal templates;
    • CRM opportunity and account data;
    • contract, subscription, or renewal details in some applications.

    It may not be responsible for selecting detailed engineering parameters, creating a production BOM, generating a product-specific drawing, or validating manufacturing feasibility. Those tasks may remain in enterprise resource planning (ERP), product data management (PDM), PLM, CAD, or engineering applications.

    What is manufacturing CPQ?

    Manufacturing CPQ is a configure, price, quote system designed for products whose structure, performance, cost, or production method changes according to customer requirements. It combines commercial quoting with a product model that represents engineering and manufacturing logic.

    The product model can include features, options, dimensions, materials, components, formulas, constraints, dependencies, and revision-controlled data. The rules may determine which combinations are allowed, what values are calculated, which components are required, and whether a configuration should be sold as configure-to-order (CTO), make-to-order (MTO), assemble-to-order (ATO), or engineer-to-order (ETO).

    For example, a CPQ model for a centrifugal pump could use flow rate, head, fluid type, temperature, seal material, impeller diameter, motor rating, voltage, connection size, and certification requirements. The system might reject a material that is unsuitable for the selected fluid, recommend a motor based on calculated power, add required coupling and guard components, and send the final configuration to an ERP system for order processing.

    Manufacturing CPQ does not replace every engineering or enterprise application. Its role depends on the architecture. It may own the commercial product model, call an external calculation service, read released data from PLM, create a configurable BOM, invoke CAD automation, and publish an approved configuration to ERP.

    Core differences between manufacturing CPQ and mainstream sales CPQ

    Area Mainstream sales CPQ Manufacturing CPQ
    Primary objective Create commercially valid quotes efficiently Create commercially and technically valid quotes for engineered products
    Product model Catalog items, packages, options, and services Product structures, engineering parameters, components, variants, formulas, and revisions
    Configuration Guided selection and basic dependencies Rules, constraints, calculations, compatibility checks, and technical validation
    Pricing List prices, discounts, promotions, and approval thresholds Those functions plus material, labor, machine, overhead, freight, risk, and project-specific costing where supported
    Output Quote, proposal, order, or contract data Quote plus configuration data, BOMs, specifications, drawings, calculation results, and order or engineering inputs where supported
    Engineering connection Often indirect or optional Frequently central, through CAD, PDM, PLM, calculation tools, or engineering workflows
    Production connection Usually through CRM, order management, or ERP May include ERP, manufacturing BOM, MES, planning, purchasing, and production handoff
    Typical product Standard software package, service bundle, or relatively simple product Machine, vehicle, pump, valve system, electrical assembly, HVAC unit, or engineered equipment

    Product configuration is more than choosing options

    In mainstream sales CPQ, configuration can mean selecting a valid bundle. In manufacturing, it may mean defining a product instance through continuous values and engineering relationships.

    Rules-based configuration

    Rules-based configuration uses explicit statements such as “if a stainless-steel wetted part is selected, use the compatible seal family” or “if the conveyor length exceeds a threshold, add an intermediate support.” Rules can control visibility, required selections, exclusions, defaults, and generated components.

    Constraint-based configuration

    Constraint-based configuration models allowable relationships between values. A motor may need to satisfy calculated torque; a pressure vessel may have wall thickness determined by pressure and material; a vehicle body may restrict axle, suspension, and payload combinations. The system evaluates constraints rather than relying only on a sequence of sales questions.

    Guided selling

    Guided selling asks commercial or customer-facing questions and recommends suitable products. It is useful when a buyer does not know the technical terminology. Guided selling can be part of manufacturing CPQ, but it is not the same as engineering validation. A recommendation still needs to be checked against product rules and technical constraints.

    These approaches can coexist. A dealer may answer application questions, the system may recommend a pump family, and a calculation engine may determine the impeller and motor. The result is stronger than a catalog selection alone.

    Engineering calculations and technical validation

    Many manufactured products cannot be configured correctly from static option dependencies. Their design depends on calculations. Examples include:

    • heat exchanger area based on flow, temperature, and duty;
    • pump selection based on flow, head, fluid properties, and efficiency;
    • motor or gearbox selection based on load, speed, torque, and duty cycle;
    • structural member dimensions based on load, span, material, and safety factors;
    • HVAC capacity based on airflow, ambient conditions, heat load, and required controls;
    • cable, fuse, enclosure, and panel selections based on electrical load and standards;
    • vehicle axle, suspension, and chassis choices based on payload and operating conditions.

    A manufacturing CPQ system may perform these calculations itself, use embedded formulas, or call an external engineering application or service. Buyers should verify where calculations execute, who owns the formulas, how units and rounding are handled, how revisions are controlled, and whether results are auditable.

    Technical validation can prevent an invalid quote, but it does not automatically prove that a design is safe, compliant, or production-ready. Some products still require engineering review, certification, simulation, or formal approval.

    BOM generation and the engineering-to-production connection

    A bill of materials is a structured list of components required for a product or assembly. Manufacturing CPQ may generate a configurable BOM from the selected options and calculated values. The generated structure may then be transformed or synchronized with other enterprise records.

    An EBOM, or engineering bill of materials, represents the product from an engineering perspective. An MBOM, or manufacturing bill of materials, represents how the product is assembled or produced. They are related but not interchangeable. An EBOM may describe functional assemblies and design parts, while an MBOM may include manufacturing consumables, workstations, packaging, kits, and assembly sequence information.

    CPQ may generate a preliminary or order-specific structure, while PLM or ERP remains the system of record for released product data. In other architectures, CPQ publishes an order-specific BOM directly to ERP. The correct design depends on product maturity, governance, and the capabilities of each platform.

    For more detail, see BOM generation, costing, pricing, and quote automation.

    CAD automation and product-specific engineering outputs

    Some manufacturing CPQ implementations connect configuration choices to computer-aided design (CAD). CAD automation can create or update a model, drawing, layout, or calculation package using selected dimensions, components, and materials.

    For example, configuring a conveyor may set frame length, belt width, support spacing, drive position, and guarding. A CAD automation process could use those values to produce a product-specific assembly and drawing. A configurable electrical cabinet could generate enclosure dimensions, panel layouts, cutouts, and component placement according to approved rules.

    CAD automation is not a standard consequence of using CPQ. It may require a separate CAD engine, templates, design automation code, PDM or PLM controls, and engineering review. Manufacturing buyers should ask whether the proposed platform generates native CAD, neutral files, drawings, visual representations, or only textual specifications.

    Read more about CAD, engineering automation, visualization, and technical calculations in CPQ.

    Pricing and costing are related but different

    Mainstream sales CPQ commonly calculates a selling price from a price list, quantity, discount, and approval policy. Manufacturing CPQ may also calculate or consume product cost.

    Costing estimates what the manufacturer expects to spend on materials, purchased components, labor, machine time, subcontracting, overhead, freight, tooling, or engineering effort. Pricing determines what the customer is charged. A price may include margin, risk, commercial strategy, regional adjustments, channel discounts, or project-specific terms.

    For a configured machine, the cost model may depend on steel weight, motor selection, machining time, purchased assemblies, controls, testing, and installation. A quote can then apply a margin rule or approval threshold. Cost and price data may come from ERP, a costing application, CPQ, or a combination of systems.

    Cost estimates should not be treated as automatically accurate. They depend on current material prices, routings, labor standards, supplier data, scrap assumptions, and model maintenance.

    How manufacturing CPQ fits into the enterprise architecture

    Manufacturing CPQ usually sits between customer-facing processes and product or operational systems. The exact boundaries vary, but the systems should not be treated as interchangeable.

    System Typical responsibility
    CRM Accounts, opportunities, activities, contacts, and sales pipeline
    CPQ Configuration, commercial rules, pricing, quoting, and sometimes technical outputs
    ERP Orders, inventory, purchasing, production planning, finance, and fulfillment
    PLM Product lifecycle, released structures, revisions, change processes, and technical governance
    PDM CAD files, metadata, versions, and design document management
    CAD Geometric design, assemblies, models, and drawings
    PIM Product information and commercial content across channels
    MES Manufacturing execution, shop-floor instructions, tracking, and production records

    Integration may use application programming interfaces (APIs), batch files, middleware, events, or direct connectors. Important data includes product identifiers, revisions, option values, quantities, units, prices, costs, BOM lines, customer requirements, approvals, and document references.

    The CPQ integration guide explains how these systems can exchange data and where ownership decisions matter.

    Which products need manufacturing CPQ?

    Manufacturing CPQ is most valuable where product variation creates technical, commercial, or operational risk. Typical examples include:

    • industrial machinery with selectable capacity, drives, materials, and accessories;
    • pumps and valves with application-dependent materials, ratings, seals, and connections;
    • HVAC equipment with capacity, coil, fan, casing, controls, and environmental choices;
    • electrical equipment with voltage, enclosure, protection, wiring, and certification requirements;
    • specialty vehicles with chassis, body dimensions, payload, suspension, and equipment packages;
    • material-handling systems with length, width, load, drive, guarding, and layout variables;
    • medical or laboratory equipment with performance, compliance, and accessory dependencies.

    It may be unnecessary when products are fully standard, configurations are small and stable, or an existing ERP and quoting process already handles the required complexity.

    Manufacturing workflow: from customer requirement to production

    1. Capture requirements: Sales, a dealer, customer, or engineer records application, performance, dimensional, regulatory, and delivery requirements.
    2. Identify a product family: Guided questions or product knowledge narrows the opportunity to a suitable machine or equipment family.
    3. Configure and validate: The CPQ model applies dependencies, constraints, calculations, defaults, and exclusions.
    4. Calculate cost and price: Component selections and engineering values feed cost and commercial pricing logic.
    5. Generate the quote: The system produces a proposal with scope, specifications, assumptions, lead time, price, and terms.
    6. Review exceptions: Engineering, commercial, or management approval handles nonstandard requirements and margin or risk exceptions.
    7. Create downstream data: Where supported, CPQ generates a BOM, specification, CAD output, order configuration, or engineering request.
    8. Release to enterprise systems: Approved data is sent to CRM, ERP, PLM, PDM, MES, or other systems according to the implementation design.

    This workflow can support CTO, where approved product variants are assembled or produced after the order; MTO, where production starts for a customer order; ATO, where standard modules are assembled in a customer-specific combination; and ETO, where significant engineering work is required. A CPQ system may support only some of these models, so the workflow must be verified during selection.

    See manufacturing CPQ workflows for a deeper discussion of CTO, ETO, MTO, ATO, and sales-to-engineering handoff.

    Benefits of manufacturing CPQ

    • Faster technical quoting: Sales engineers can reuse approved rules and calculations instead of rebuilding every configuration manually.
    • Fewer configuration errors: Invalid combinations and missing components can be identified before order entry.
    • Better engineering capacity: Engineers can focus on exceptions, new products, and nonstandard designs rather than repetitive quote work.
    • More consistent costing: Product structure and process assumptions can be connected to cost logic.
    • Improved handoff: Sales, engineering, and production receive a shared configuration instead of reinterpreting free-text requirements.
    • Reusable product knowledge: Rules, formulas, and approved options become maintainable digital product logic.
    • Better customer communication: Quotes can include accurate specifications, visuals, assumptions, and limitations.

    Limitations and implementation risks

    Manufacturing CPQ is not simply a catalog project. The difficult work often involves discovering undocumented engineering knowledge and deciding who owns each rule.

    • Complex rule maintenance: Rules can become contradictory, duplicated, or difficult to test as product families evolve.
    • Data ownership conflicts: CPQ, ERP, PLM, and CAD teams may disagree about the authoritative product structure, price, revision, or component identifier.
    • ETO boundary problems: A system may handle standard variants well but require a controlled engineering workflow for genuinely new designs.
    • Calculation governance: Engineering formulas need version control, unit management, validation, and approval.
    • Integration fragility: Changes to ERP item masters, PLM revisions, APIs, or CAD templates can break downstream processes.
    • Over-modeling: Attempting to encode every historical exception can produce an unmaintainable product model.
    • Adoption issues: Sales teams may avoid a complex interface, while engineers may distrust results that cannot be explained.
    • Document limitations: A quote document is not necessarily a manufacturing drawing, released BOM, or legally approved design.

    How to evaluate a manufacturing CPQ platform

    Start with representative product families rather than generic feature checklists. Select examples that expose the real complexity: continuous dimensions, incompatible materials, calculated components, optional assemblies, revision changes, nonstandard requests, and downstream outputs.

    Ask vendors and implementation partners to demonstrate:

    • how product models represent options, dimensions, formulas, constraints, and revisions;
    • how users diagnose an invalid configuration and explain a recommendation;
    • how engineering calculations are created, tested, versioned, and approved;
    • how configurable BOMs differ from EBOMs and MBOMs;
    • how costs, prices, discounts, and approvals are separated;
    • how CAD files, drawings, or visual outputs are generated, if required;
    • how exceptions move to engineering without losing configuration context;
    • how data is exchanged with CRM, ERP, PLM, PDM, CAD, PIM, and MES;
    • how APIs, audit trails, permissions, testing environments, and release management work;
    • how product model changes are governed after deployment.

    A practical implementation plan should define product scope, data ownership, rule ownership, integration boundaries, migration requirements, test cases, approval stages, user roles, and maintenance responsibilities. The CPQ implementation guide covers these planning concerns in more detail.

    Manufacturing CPQ vs mainstream sales CPQ: the practical conclusion

    Mainstream sales CPQ is primarily a commercial productivity system. Manufacturing CPQ is a commercial and technical decision system for products whose configuration affects engineering, cost, documentation, inventory, and production.

    The difference is most important when a quote must answer more than “what does this package cost?” It may need to answer: Is the design feasible? Which components are required? What performance will it deliver? What material and motor are appropriate? What does it cost to build? Which drawing or BOM should be created? Can the order be released without another round of interpretation?

    Manufacturers should not select a platform based on the CPQ label alone. They should map their product model, rules, calculations, output requirements, workflow, and system ownership. A sales-oriented platform may be sufficient for standard products. A manufacturing-oriented architecture is more appropriate when configuration decisions must reliably connect customer requirements to engineering and production.

    Semantic map

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

    • CPQ configures configurable products.
    • Configuration rules prevent invalid combinations.
    • Constraint-based configuration validates technical relationships.
    • Guided selling recommends suitable product families.
    • Engineering calculations determine product-specific values.
    • Configured products generate configurable BOMs.
    • EBOMs represent engineering product structures.
    • MBOMs represent manufacturing product structures.
    • CAD automation generates product-specific drawings.
    • Costing estimates manufacturing resource consumption.
    • Pricing converts cost and commercial policy into a selling price.
    • CPQ exchanges customer and configuration data with CRM.
    • CPQ exchanges orders and item data with ERP.
    • PLM governs released product revisions.
    • PDM manages CAD files and design metadata.
    • MES executes and records shop-floor manufacturing.
    • CTO assembles approved product variants after order receipt.
    • ETO routes nonstandard requirements through engineering.

    Frequently asked questions

    1. What is the main difference between manufacturing CPQ and sales CPQ?

    Manufacturing CPQ validates and describes an engineered product as well as pricing it. Sales CPQ usually focuses on commercial selection, pricing, approvals, and quote generation.

    2. Is manufacturing CPQ only for engineer-to-order companies?

    No. It supports configure-to-order, make-to-order, assemble-to-order, and engineer-to-order processes. The depth of configuration and engineering involvement varies by product family.

    3. Does every manufacturing CPQ system generate a BOM?

    No. BOM generation is a platform capability that must be verified. Some systems create configurable BOMs, while others pass configuration data to ERP, PLM, or a separate engineering application.

    4. Can a mainstream sales CPQ configure manufactured products?

    Sometimes. A sales CPQ platform may handle standard options and commercial rules, but it may not support engineering calculations, detailed constraints, BOM generation, or CAD automation.

    5. What is the difference between product configuration and guided selling?

    Guided selling helps users identify a suitable product through questions and recommendations. Product configuration validates the selected product and determines its options, parameters, components, and dependencies.

    6. Does manufacturing CPQ replace ERP?

    No. ERP usually remains responsible for orders, inventory, purchasing, finance, and production planning. CPQ provides configuration and quoting data that may be exchanged with ERP.

    7. Does manufacturing CPQ replace PLM?

    No. PLM typically manages product lifecycle, released structures, revisions, and engineering change processes. CPQ may consume approved PLM data or create order-specific information under defined governance.

    8. What is an EBOM?

    An EBOM is an engineering bill of materials. It describes a product from the design perspective and may differ from the manufacturing bill of materials used to plan assembly and production.

    9. What is an MBOM?

    An MBOM is a manufacturing bill of materials. It represents the components, consumables, and structure needed to manufacture or assemble a product, which may not match the engineering structure exactly.

    10. Can CPQ perform engineering calculations?

    Some platforms support formulas or integrations with calculation services. This is not universal. Buyers should verify calculation scope, unit handling, version control, testing, and engineering approval.

    11. Does CPQ automatically create CAD drawings?

    No. CAD automation requires appropriate CAD integrations, templates, automation logic, and governance. Some platforms support it; others produce specifications or pass data to a separate tool.

    12. How does manufacturing CPQ improve sales-to-engineering handoff?

    It can preserve structured customer requirements, selected options, calculated values, approvals, and exceptions instead of relying on free-text descriptions or re-entry.

    13. What types of manufacturing products benefit most from CPQ?

    Products with many valid variants, technical dependencies, application calculations, repeatable engineering logic, or high error costs benefit most. Examples include machinery, pumps, valves, HVAC units, vehicles, and electrical systems.

    14. When is mainstream sales CPQ sufficient for a manufacturer?

    It may be sufficient when products are standardized, technical variation is limited, pricing is the main challenge, and engineering or production systems already manage configuration outputs.

    15. How should a manufacturer test a CPQ vendor?

    Use real representative product families and test dimensions, dependencies, calculations, exceptions, revisions, pricing, BOM output, approval workflows, and integrations rather than relying on a generic demonstration.

    16. Who should own manufacturing CPQ rules?

    Ownership should be assigned by rule type. Engineering may own technical constraints, product management may own product definitions, commercial teams may own pricing policy, and IT may govern integrations and deployment.

    17. Can manufacturing CPQ support dealers and distributors?

    Yes, where the platform provides suitable portal, permissions, channel pricing, product guidance, and quote workflows. The technical depth and data exposed to dealers should be controlled.

    18. What is the biggest implementation risk?

    A common risk is attempting to automate poorly understood or constantly changing product knowledge without clear data ownership, rule governance, test cases, and release processes.

  • CPQ Software for Manufacturing: The Complete Guide

    CPQ software for manufacturing is a system that helps manufacturers configure complex products, apply engineering and commercial rules, calculate costs and prices, generate quotes, and transfer accurate product data to engineering, enterprise and production systems. CPQ means configure, price, quote, but manufacturing CPQ usually extends beyond sales quoting. Depending on the platform and implementation, it may also generate bills of material, support engineering calculations, automate computer-aided design (CAD), create product-specific drawings, and support configure-to-order or engineer-to-order workflows.

    For example, a manufacturer of industrial pumps may use CPQ to select a pump family, flow rate, pressure rating, motor, seal, material, connection standard and accessories. The system can reject incompatible combinations, calculate the required pump configuration, determine a cost and selling price, produce a quotation, and send a manufacturing bill of material (MBOM) or engineering bill of material (EBOM) to connected systems. Not every CPQ product supports every step, so buyers must evaluate documented capabilities rather than assume that all CPQ platforms are engineering automation systems.

    This guide explains how manufacturing CPQ works, where it fits in the technology stack, which capabilities matter, how it differs from generic sales CPQ, and how to plan an implementation.

    What is manufacturing CPQ software?

    Manufacturing CPQ software is a product configuration, pricing and quoting application designed for companies that sell products with many options, dependencies, dimensions, materials, performance requirements or engineering variations. It converts customer and sales requirements into a valid product definition and a commercially usable quote.

    The central object is usually a product model. A product model represents a configurable product family, its features, options, parameters, rules, calculations, prices, costs and downstream outputs. A model for a conveyor system might include belt width, length, speed, frame material, motor size, controls, guarding and installation requirements. These choices may affect one another and may also affect the BOM, CAD geometry, labor, lead time and price.

    Manufacturing CPQ can sit between customer-facing sales channels and operational systems. It may be used by sales engineers, application engineers, dealers, distributors, customers through self-service channels, or internal customer service teams. The system can be connected to customer relationship management (CRM), enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), CAD, product information management (PIM), manufacturing execution systems (MES) and ecommerce platforms.

    These integrations are not automatic characteristics of the CPQ category. The available integration method, data ownership and level of automation depend on the selected product, connectors, APIs and implementation design.

    How manufacturing CPQ differs from generic sales CPQ

    Generic sales CPQ often focuses on selecting sellable items, applying discounts and producing a proposal. Manufacturing CPQ may perform those functions, but it must also represent physical products and engineering constraints.

    Area Generic sales CPQ Manufacturing CPQ
    Configuration Selects products, packages and commercial options Models technical parameters, dependencies, dimensions, materials and performance constraints
    Validation Prevents incompatible commercial selections May validate mechanical, electrical, hydraulic, thermal, safety and manufacturing constraints
    Pricing Uses price books, discounts and approvals May combine material, labor, purchased components, overhead, freight, margin and project-specific calculations
    Outputs Quote, proposal and order data Potentially quote, configurable BOM, EBOM, MBOM, drawings, CAD files, calculations and manufacturing attributes
    Downstream systems Usually CRM, ERP and payment or order systems May include CRM, ERP, PLM, PDM, CAD, MES, PIM, dealer portals and engineering applications
    Workflow Sales opportunity to quote Customer requirements to configuration, engineering validation, quote, order, production and service data

    The distinction is important when selecting software. A platform that produces attractive proposals may not be able to calculate a shaft diameter, create an engineering BOM or generate a production-ready drawing.

    The main capabilities of manufacturing CPQ

    Product configuration and product models

    Configuration is the process of selecting and defining a valid product from a product family. The product model should identify available features, options, values, ranges, units of measure, defaults, dependencies and exclusions. It may also contain revisions, effective dates, regional availability and customer-specific restrictions.

    A robust model separates reusable product knowledge from presentation logic. The same configuration logic might be used in an internal engineering application, a dealer portal and a guided sales experience, although each channel may expose different questions.

    Manufacturers should document whether a platform supports discrete options, numeric ranges, formulas, modular structures, variant management, version control and reusable rules. These details affect model maintainability as much as the number of advertised features.

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

    Rules, constraints and guided selling

    Rules determine what the system should allow, recommend, calculate or require. Common rule types include:

    • Compatibility rules: prevent combinations such as a motor that cannot deliver the required torque.
    • Dependency rules: require a variable-frequency drive when a particular motor control option is selected.
    • Exclusion rules: prevent two incompatible materials or connection standards from being selected together.
    • Calculation rules: derive motor size, vessel volume, cable length, structural dimensions or other values.
    • Validation rules: check technical limits, regulatory requirements, tolerances and required customer inputs.
    • Recommendation rules: suggest an option based on application conditions or operating requirements.
    • Commercial rules: apply customer pricing, territory restrictions, minimum margins or approval thresholds.

    Rules-based configuration evaluates explicit if-then logic. Constraint-based configuration describes permitted relationships and searches for solutions that satisfy those constraints. Guided selling asks questions in a business-friendly sequence and uses the answers to narrow the product choices. A manufacturing implementation may use all three, but they solve different problems.

    Engineering calculations

    Some products require calculations before a valid configuration can be selected. Examples include pump duty, heat exchanger capacity, pressure drop, load capacity, airflow, cable sizing, battery capacity and structural loading.

    Calculation logic may be implemented directly in the CPQ product model, called from an external engineering service, or handled by a connected application. The implementation should identify input units, formulas, assumptions, rounding, tolerances, standards and approval ownership. A price calculator is not automatically an engineering calculator, and a basic option dependency is not equivalent to a validated physical design.

    Costing and pricing

    Pricing determines what the customer is charged; costing estimates what the manufacturer expects to spend. The two should be modeled separately even when they use related data.

    Cost inputs can include raw materials, purchased components, labor operations, machine time, subcontracting, freight, tooling, installation and overhead. Price logic may include list prices, customer agreements, regional prices, volume breaks, currency, surcharges, discounts, target margins and approval thresholds.

    Manufacturers should ask whether the CPQ system calculates costs itself, retrieves them from ERP, or supports both approaches. They should also define which system is authoritative for prices, costs, currencies, exchange rates and commercial approvals. More detail is available in the guide to BOM generation, pricing and quoting.

    Quote and proposal generation

    A quote usually contains the configured product description, quantities, price, discounts, validity period, delivery assumptions, terms, exclusions and commercial notes. Manufacturing quotes may also require technical specifications, performance data, drawings, compliance statements, installation scope and customer-specific documentation.

    Document generation should use the validated configuration rather than allow sales users to manually retype technical details. Approval workflows can route exceptions such as low margin, non-standard materials, unusual lead times or configurations outside an approved product model.

    Bill of material generation

    A bill of material (BOM) is a structured list of components and quantities needed for a product or assembly. A CPQ system may generate a configurable BOM directly, map configuration choices to ERP items, or send a configuration identifier for downstream resolution.

    An EBOM, or engineering bill of material, describes the product from an engineering design perspective. An MBOM, or manufacturing bill of material, organizes components and operations for production. A configurable BOM represents possible or selected variants before a specific order is finalized. These structures are related but not interchangeable.

    For a configured control cabinet, the BOM may depend on enclosure size, incoming voltage, motor starters, terminal blocks, safety devices and cable requirements. The CPQ output must specify the intended structure, item identifiers, quantities, revisions, attributes and ownership. The system should not be described as generating a production-ready MBOM unless that capability and the required integration have been verified.

    CAD automation and visualization

    CAD automation links configuration choices to geometry, assemblies, drawings or models. A configured agricultural implement might produce a model with a selected working width, hitch type, hydraulic circuit and frame option. A configured machine enclosure might generate dimensions, panel cutouts and mounting positions.

    Possible outputs include a 2D drawing, 3D model, neutral CAD file, rendered image, installation layout or technical document. Some systems provide native parametric CAD automation; others integrate with CAD or design automation services. Three-dimensional visualization can improve understanding, but a visual configurator alone does not prove that the underlying geometry is manufacturable.

    Review CAD and engineering automation in CPQ for design automation, visualization, drawings and calculations.

    Where CPQ fits in the manufacturing technology stack

    CPQ is typically an orchestration and decision layer rather than a replacement for every enterprise application. A clear data ownership model is essential.

    System Typical responsibility Possible CPQ relationship
    CRM Accounts, opportunities, contacts and sales activities Starts a configuration from an opportunity and receives quote status or value
    ERP Items, inventory, purchasing, orders, production planning and financial data Supplies item, cost and price data or receives configured order and BOM data
    PLM Product structures, revisions, lifecycle states and engineering governance Provides approved product data or receives new engineered variants
    PDM CAD files, documents, metadata and design revisions Stores or retrieves CAD outputs and related documents
    CAD Geometry, assemblies, drawings and design attributes Receives parameters and returns generated design outputs
    PIM Product descriptions, media, attributes and channel content Provides customer-facing product information
    MES Shop-floor execution, work instructions and production tracking May receive manufacturing data or configuration identifiers
    Ecommerce or dealer portal Customer or channel ordering experience Provides a front end for guided configuration and quoting

    For integration planning, see the manufacturing CPQ integration guide. It covers APIs, data exchange and relationships with ERP, CRM, PLM, PDM, CAD, PIM and MES.

    Manufacturing workflows supported by CPQ

    Configure-to-order

    Configure-to-order (CTO) uses an approved product model to select a valid variant from predefined options. The manufacturer may stock or plan the underlying components, while the final product is configured after the order. A standard pump family with selectable seals, motors and connections is a common example.

    Make-to-order and assemble-to-order

    Make-to-order (MTO) begins production after a customer order and may use a standard or configurable design. Assemble-to-order (ATO) combines stocked modules after the order. CPQ can capture the selected modules and pass the resulting structure to ERP, but it does not by itself determine inventory policy or production scheduling.

    Engineer-to-order

    Engineer-to-order (ETO) requires new or substantially modified engineering for a customer order. CPQ can capture requirements, perform preliminary calculations, create a commercial estimate and initiate an engineering review. It may also create a preliminary BOM or CAD starting point. ETO requires controlled handoff and technical approval; CPQ should not be treated as a substitute for engineering sign-off.

    These workflows are explained in the manufacturing CPQ workflow guide.

    Example: configuring an industrial air-handling unit

    Consider an air-handling manufacturer selling units for commercial buildings. The configuration may include airflow, external static pressure, unit orientation, casing material, filter class, heating or cooling coil, fan type, motor, controls, access doors and environmental rating.

    1. The salesperson or dealer enters application requirements and site constraints.
    2. The CPQ model checks whether the selected fan can meet the airflow and pressure requirement.
    3. The system applies dependencies, such as requiring a particular control panel for a selected voltage or a corrosion-resistant casing for a specified environment.
    4. An engineering calculation determines a suitable coil or fan range, subject to the manufacturer’s approved methods.
    5. The configuration maps to components, quantities, costs, lead-time attributes and a price.
    6. The system generates a technical quote and may request approval for non-standard selections.
    7. If supported, a CAD or selection tool generates a layout, schedule or drawing.
    8. Approved order data is sent to ERP, PLM, CAD or another downstream system according to the implementation design.

    The example shows why configuration, engineering, pricing and BOM generation must be considered separately. A system may perform the first five steps well but require another application for CAD output or production BOM creation.

    Benefits of CPQ for manufacturers

    • Faster quote preparation: reusable models and automated calculations reduce manual work on repeatable configurations.
    • Fewer configuration errors: rules prevent or identify invalid combinations before an order reaches engineering or production.
    • More consistent pricing: cost and price logic can be applied consistently across sales channels.
    • Reduced engineering effort: approved configurations and automated documents can reduce routine application-engineering tasks.
    • Better sales-to-engineering handoff: the selected options, parameters and assumptions are captured as structured data rather than free-text notes.
    • Improved manufacturing data: supported implementations can produce or transmit item selections, BOM structures, drawings and configuration identifiers.
    • Channel control: dealers and distributors can receive guided access to approved products, prices and quoting permissions.
    • Traceability: configuration versions, approvals and quote revisions can be recorded for later review.

    Benefits depend on product-model quality, data accuracy, integration depth, user adoption and governance. Implementing a CPQ application without maintaining the rules and product data will not remove the underlying complexity.

    Limitations and risks

    Manufacturing CPQ projects often fail or underperform for reasons that are not caused by the user interface. Product knowledge may be distributed across spreadsheets, drawings, ERP records, engineering workbooks and individual employees. Converting that knowledge into tested, maintainable rules is a substantial modeling task.

    • Model complexity: large product families can create thousands of interactions and difficult testing requirements.
    • Data ownership: conflicting item, price, revision and description data can produce inconsistent outputs.
    • Engineering boundaries: a CPQ model may cover standard configurations but not novel ETO designs or specialist calculations.
    • Integration limitations: a connector may transfer basic order data without supporting revisions, BOM structures, documents or real-time validation.
    • Rule maintenance: product changes, supplier substitutions, regulations and pricing updates require controlled releases.
    • Performance: complex calculations, CAD generation and large product models may require asynchronous processing or specialized architecture.
    • Governance: unclear ownership can allow obsolete or unapproved options to remain available.
    • User experience: exposing engineering terminology without guidance can make configuration difficult for sales or dealers.

    Buyers should request demonstrations using representative products, including difficult configurations and negative test cases, rather than relying only on feature checklists.

    How to evaluate CPQ software for manufacturing

    Evaluation should begin with the product and workflow, not with generic sales automation features. Create representative scenarios for a standard configurable product, a calculation-driven product, a product with CAD output and an ETO or exception workflow.

    Evaluation area Questions to verify
    Product modeling Can the system model options, parameters, ranges, modules, revisions, units and effective dates?
    Rules and constraints Can technical, commercial and manufacturing rules be expressed, tested and maintained by appropriate users?
    Calculations Can the platform run required formulas, use external services and record assumptions and units?
    BOM Does it generate a configurable BOM, EBOM or MBOM, or does it map choices to ERP items?
    CAD and documents Can it generate drawings, models, layouts or technical documents, and under whose ownership?
    Pricing and costing Can it handle material costs, labor, margins, currencies, discounts, agreements and approvals?
    Workflow Does it support CTO, ATO, MTO, ETO, engineering review and exception handling?
    Integration What APIs, connectors, events, batch processes and error-handling mechanisms are available?
    Governance Are versioning, permissions, testing, audit history and release controls adequate?
    Scale How does performance change with large models, many rules, multiple regions and several channels?

    Use the manufacturing CPQ software profiles and CPQ comparison and selection resources to structure vendor research. Capability descriptions should be checked against product documentation, demonstrations and contractual scope.

    Implementation approach

    1. Define the business case and scope

    Choose an initial product family and workflow with measurable problems, such as long quote preparation, frequent configuration errors or excessive engineering review. Define the intended users, channels, outputs and systems involved.

    2. Inventory product and commercial data

    Collect option lists, dimensions, formulas, compatibility rules, item numbers, revisions, costs, prices, documents, lead times and approval policies. Identify duplicate and contradictory sources before loading data into the product model.

    3. Establish ownership and governance

    Assign owners for product rules, engineering calculations, prices, costs, CAD templates, ERP mappings and integrations. Define who can propose, approve, publish and retire a change.

    4. Model a representative product

    Start with a product that is valuable but not impossibly broad. Include normal configurations, boundary values, invalid combinations, substitutions, regional differences and exception paths. This exposes model and architecture issues early.

    5. Design integrations and data contracts

    Specify what each system sends and receives, which identifier links a quote to an order, how revisions are represented, how errors are retried, and how users are notified when an external system is unavailable.

    6. Test rules and outputs

    Use automated and manual tests for valid configurations, invalid combinations, boundary calculations, price changes, revisions, BOM quantities, documents and integration failures. Business users and engineers should review the outputs.

    7. Deploy in controlled releases

    Train users on the configuration process and the boundaries of automation. Monitor quote cycle time, error rates, approval volume, engineering rework, model defects and integration failures. Add product families only after the operating model is stable.

    See the CPQ implementation guide for requirements, migration, testing, deployment, maintenance and performance measures.

    Key questions to ask before buying

    • Which product families are genuinely configurable, and which require ETO engineering?
    • Which rules are safety-critical or legally significant?
    • Does the business need a quote only, or also BOM, CAD and manufacturing outputs?
    • Which system owns items, revisions, costs, prices and approved product structures?
    • Who will maintain the model after implementation?
    • Can the solution support internal sales, dealers, distributors and customer self-service without duplicating rules?
    • How will non-standard configurations be routed to engineering?
    • What happens when ERP, PLM, CAD or pricing services are unavailable?
    • How will old quotes and configurations remain reproducible after a product revision?

    Semantic map

    The following relationships summarize how manufacturing CPQ connects product knowledge, commercial decisions and downstream execution:

    • CPQ configures configurable products.
    • Product models contain options, parameters and rules.
    • Configuration rules prevent invalid combinations.
    • Constraint-based configuration satisfies technical requirements.
    • Guided selling translates customer requirements into selections.
    • Engineering calculations validate product performance.
    • A configured product determines component selections.
    • A configured product can generate or resolve a BOM.
    • EBOM represents an engineering product structure.
    • MBOM represents a manufacturing product structure.
    • Pricing logic calculates the selling price.
    • Costing logic estimates manufacturing and delivery cost.
    • CAD automation generates product-specific drawings or models.
    • CPQ exchanges configuration data with ERP.
    • PLM governs product revisions and lifecycle states.
    • CRM provides opportunity and customer context.
    • ETO routes non-standard requirements to engineering.
    • CTO selects approved product variants for order execution.

    Frequently asked questions

    What does CPQ stand for in manufacturing?

    CPQ stands for configure, price, quote. In manufacturing, it usually includes technical product configuration and may connect quoting with engineering, BOM, CAD and enterprise workflows.

    What is the main purpose of manufacturing CPQ?

    Its main purpose is to turn customer requirements into a valid, priced and documented product configuration that can move efficiently toward order fulfillment.

    Is manufacturing CPQ the same as sales CPQ?

    No. Sales CPQ may focus on products, discounts and proposals, while manufacturing CPQ must often manage technical parameters, constraints, calculations, BOMs and engineering handoff.

    Can CPQ generate a bill of material?

    Some platforms can generate or resolve configurable BOMs, while others pass configuration selections to ERP or PLM for BOM resolution. The specific output and production readiness must be verified.

    What is the difference between an EBOM and an MBOM?

    An EBOM organizes a product from an engineering perspective. An MBOM organizes materials and operations for manufacturing. A CPQ implementation may produce one, both, or neither directly.

    Can CPQ create CAD drawings?

    Some manufacturing CPQ solutions integrate with CAD or design automation tools to generate drawings, models or layouts. Others provide visualization without generating manufacturing CAD.

    Does CPQ replace ERP?

    No. ERP typically manages items, inventory, purchasing, orders, production planning and financial transactions. CPQ usually supplies validated configuration and commercial data to ERP.

    Does CPQ replace PLM?

    No. Product lifecycle management (PLM) governs product data, revisions, lifecycle states and engineering processes. CPQ may consume approved PLM data or initiate controlled engineering work.

    Can CPQ support engineer-to-order products?

    It can support the front end of ETO by capturing requirements, estimating price and routing exceptions. Full ETO still requires engineering design, review, revision control and production preparation.

    What products benefit most from manufacturing CPQ?

    Products with many technical options, dependencies, dimensions, materials or application-specific calculations benefit most. Examples include machinery, pumps, valves, HVAC units, electrical equipment and specialty vehicles.

    What is a product model in CPQ?

    A product model is the structured representation of a configurable product family, including features, options, parameters, rules, calculations, prices, costs and outputs.

    What is the difference between configuration rules and constraints?

    Rules commonly express explicit actions such as requiring or excluding an option. Constraints describe relationships or limits that a valid solution must satisfy. Platforms may support one or both approaches.

    Can manufacturers use CPQ for dealer and distributor sales?

    Yes, if the platform supports the required channels, permissions, customer-specific pricing, product visibility and approval workflows. The same governed product logic should ideally be reused across channels.

    How does CPQ reduce engineering workload?

    It can automate repeatable selections, calculations, documents and standard configurations. It does not eliminate engineering review for novel designs, safety-critical decisions or unsupported exceptions.

    How long does a manufacturing CPQ implementation take?

    There is no reliable universal duration. Scope, product complexity, data quality, integrations, CAD automation, governance and the number of channels all affect the timeline.

    What data is needed to implement CPQ?

    Typical data includes product structures, options, parameters, compatibility rules, formulas, item identifiers, revisions, costs, prices, documents, lead times, customer rules and integration mappings.

    How should CPQ rules be maintained?

    Rules should have named owners, version control, test cases, approval gates, release procedures and an audit trail. Engineering, product management, commercial teams and IT may share governance responsibilities.

    What should a CPQ proof of concept include?

    It should include a representative product, difficult and invalid configurations, pricing, required calculations, expected BOM or CAD outputs, user roles and at least one realistic downstream integration.

    Can CPQ be used for configure-to-order and make-to-order?

    Yes. CPQ can define approved variants and pass configuration data into order and production processes. It does not independently determine inventory, scheduling or shop-floor execution.

    Is 3D visualization required for manufacturing CPQ?

    No. Visualization is useful when spatial understanding affects buying or configuration, but a rules engine, validated data model and reliable downstream outputs may be more important for many products.