CPQ Guide

Tag: Manufacturing software architecture

  • CPQ vs CRM: Roles, Data, and Boundaries in Manufacturing

    In manufacturing, CRM and CPQ solve different problems. A customer relationship management system records accounts, contacts, leads, opportunities, activities and sales pipeline information. A configure, price, quote system defines which product combinations are valid, applies engineering and commercial rules, calculates prices and costs, and produces a quote for the selected configuration.

    The boundary is important because a CRM is not normally a product rules engine, and a manufacturing CPQ system is not normally the system of record for customer relationships. CRM manages who the customer is, what opportunity exists and where the deal stands. CPQ manages what can be sold, how it must be configured, what it costs and what should be quoted.

    For example, a CRM may contain an opportunity for a food-processing company that needs a pump skid. CPQ can use the required flow rate, pressure, fluid characteristics, materials, motor specification, controls and compliance requirements to validate a pump package, calculate the price and generate a configured bill of materials (BOM). The CRM can then store the opportunity, quote status, customer communications and expected close date while CPQ remains responsible for the product-specific quote.

    These systems are complementary rather than interchangeable. The most effective architecture connects them while preserving clear ownership of product, customer, pricing, engineering and production data. This manufacturing CPQ guide provides the broader context for how CPQ supports complex configurable products.

    What is CRM in manufacturing?

    CRM, or customer relationship management, is software used to manage commercial relationships and sales processes. In manufacturing, CRM commonly stores customer accounts, sites, contacts, sales activities, opportunities, sales stages, territories, forecasts and communications.

    A manufacturing CRM may also contain information about installed equipment, dealer relationships, service opportunities, application requirements and historical transactions. However, it does not automatically understand the engineering validity of every product option or calculate the manufacturing consequences of a configuration.

    Typical CRM responsibilities

    • Managing accounts, contacts, prospects, dealers and customer locations.
    • Recording leads, opportunities, activities, meetings, calls and emails.
    • Tracking sales stages, probability, expected revenue and forecast dates.
    • Assigning opportunities to sales representatives, sales engineers or channels.
    • Managing customer communications and commercial approvals.
    • Providing context for renewals, service agreements, installed equipment and account history.
    • Launching or displaying quotes that were created in CPQ.

    CRM is therefore primarily relationship- and opportunity-oriented. It may display product and quote information, but those records are often sourced from product, pricing or CPQ systems rather than being mastered entirely in the CRM.

    What is CPQ in manufacturing?

    CPQ means configure, price, quote. Manufacturing CPQ is software that models configurable products and applies rules to produce technically valid and commercially accurate quotes. Depending on the platform and implementation, it may also calculate engineering values, generate a configurable BOM, automate CAD outputs, create drawings or pass manufacturing data to enterprise systems.

    Manufacturing CPQ is broader than generic sales quoting because the selected options can affect engineering, purchasing, production, installation and compliance. A configuration is not simply a collection of selectable features. It may contain dimensions, capacities, materials, ratings, interfaces, tolerances, components, labor assumptions and constraints.

    For example, a valve configuration may depend on pressure class, body material, trim material, connection type, temperature range, actuator size and certification. A rule may prevent a particular elastomer from being selected when the process temperature exceeds its rating. Another rule may require a specific actuator or mounting arrangement for a defined torque range.

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

    Typical manufacturing CPQ responsibilities

    • Presenting guided selling questions or engineering inputs.
    • Applying rules that prevent invalid or unsafe combinations.
    • Performing calculations for sizing, capacity, load, flow, power or dimensions where supported.
    • Selecting components and applying configurable BOM logic.
    • Calculating material, labor, overhead, cost, margin, discounts and selling price.
    • Supporting standard configure-to-order (CTO) products and, in some systems, engineer-to-order (ETO) workflows.
    • Generating quote documents, configuration summaries and approval packages.
    • Passing product, pricing and order data to CRM, enterprise resource planning (ERP), product lifecycle management (PLM), computer-aided design (CAD) or manufacturing systems.

    Not every CPQ product supports CAD automation, engineering calculations, BOM generation or PLM integration. Buyers must verify these capabilities against the vendor’s documented functionality and the requirements of the product model.

    CPQ vs CRM: the core difference

    Area CRM Manufacturing CPQ
    Primary purpose Manage customers, relationships and opportunities Configure products, calculate prices and create accurate quotes
    Main business question Who is buying, what is the opportunity and what is the sales status? What can be sold, how should it be configured and what should it cost?
    Core data Accounts, contacts, activities, opportunities and forecasts Product models, options, rules, calculations, prices, costs and quote lines
    Primary users Sales, account managers, business development and sales leadership Sales engineers, application engineers, product managers, estimators and technical sales
    Manufacturing relevance Customer and opportunity context Technical validity, engineering definition and commercial accuracy
    Output Opportunity record, forecast, activity history and relationship record Validated configuration, price, quote, and potentially BOM or engineering outputs
    Typical downstream systems ERP, marketing, service, CPQ and analytics CRM, ERP, PLM, PDM, CAD, MES and order-management systems

    There can be overlap. CRM platforms may offer basic product catalogs, price books and quote objects. CPQ platforms may store customer references and opportunity identifiers. Overlap does not remove the need for data ownership decisions.

    How CRM and CPQ work together

    A common manufacturing workflow begins in CRM and moves into CPQ when the opportunity requires product definition or pricing complexity beyond a simple catalog sale.

    1. Opportunity creation: A salesperson records the customer, application, expected quantity, target date and commercial context in CRM.
    2. Configuration launch: The salesperson or sales engineer opens CPQ from the opportunity, often passing the account, site, currency, channel and opportunity identifier.
    3. Technical discovery: CPQ collects configuration inputs such as dimensions, capacity, material, environmental conditions, motor selection or control requirements.
    4. Validation: Configuration rules identify incompatible options, missing requirements or values outside supported ranges.
    5. Engineering and costing: Where supported, CPQ performs calculations, selects components, generates a configurable BOM and applies cost logic.
    6. Pricing: CPQ applies price lists, customer-specific terms, quantity breaks, discounts, freight assumptions, currency and approval rules.
    7. Quote generation: CPQ creates a quote containing the product description, selected options, commercial terms, exclusions, lead-time assumptions and price.
    8. CRM update: Quote status, total value, version and approval state are returned to CRM for pipeline management.
    9. Order handoff: An accepted quote may be transferred to ERP, PLM, PDM, manufacturing or order-management systems, depending on the architecture.

    This workflow keeps CRM focused on the relationship and opportunity while CPQ manages the detailed product and pricing transaction. The exact sequence varies by organization and integration design.

    Data boundaries between CPQ and CRM

    The most important implementation question is not whether CRM or CPQ can technically store a field. It is which system should own, validate and publish that field.

    Data usually owned by CRM

    • Account name, customer classification and relationship hierarchy.
    • Contacts, communication preferences and sales team assignments.
    • Opportunity stage, forecast category, close date and probability.
    • Sales activities, meetings, tasks and account history.
    • Territory, channel and relationship ownership.
    • Commercial context that does not define the product configuration.

    Data usually owned by CPQ

    • Product options, features, attributes and valid values.
    • Configuration dependencies, exclusions and constraint rules.
    • Engineering calculations and configuration-specific requirements.
    • Configured product descriptions and quote-line details.
    • Pricing logic, discount rules and approval thresholds where CPQ is the pricing authority.
    • Configurable BOM logic and configuration identifiers where supported.
    • Quote versions, configuration state and technical assumptions.

    Data that may be mastered elsewhere

    • ERP: Item masters, inventory, standard costs, customer credit, orders and financial transactions.
    • PLM: Product structures, revisions, engineering change processes and released product definitions.
    • PDM: CAD files, document metadata and design data management.
    • CAD: Parametric geometry, assemblies, drawings and model-specific design outputs.
    • PIM: Product descriptions, marketing attributes and channel content.
    • MES: Manufacturing execution, work instructions, production status and shop-floor reporting.

    These systems are distinct. An ERP item number is not necessarily a CPQ configuration rule. A PLM engineering BOM (EBOM) is not the same as a manufacturing BOM (MBOM), which is structured for production operations. A CAD model is not a CRM product record. The CPQ integration guide covers these system relationships in more detail.

    Product configuration is not the same as quoting

    Configuration, pricing and quoting are related but separate functions.

    • Configuration determines whether a product selection is technically valid and defines its attributes, components or requirements.
    • Pricing calculates what the configured product should cost or sell for.
    • Quoting presents the commercial offer, terms, assumptions and validity period to the customer.

    A CRM product catalog may show a list of products and prices without validating dependencies between options. A basic quoting tool may apply discounts without knowing whether a selected motor can drive a specified pump. Manufacturing CPQ connects these functions when the product model and data are sufficiently mature.

    Manufacturing organizations should also distinguish three approaches to configuration. Guided selling asks business-oriented questions and recommends suitable products. Rules-based configuration uses explicit if-then logic, exclusions and required selections. Constraint-based configuration evaluates relationships and limits across multiple variables, such as dimensions, capacity, loads and available components. A platform may support one, two or all three approaches.

    Manufacturing example: configurable industrial pump

    Consider a company selling centrifugal pump packages. CRM stores the customer, project site, opportunity value, expected delivery date and communication history. A CPQ session collects flow, head, fluid, temperature, material, seal type, motor voltage, enclosure rating, baseplate requirements and control-panel options.

    CPQ may then:

    • reject a pump size that cannot meet the required duty point;
    • require corrosion-resistant materials for a specified fluid;
    • select a seal family based on temperature and chemical compatibility;
    • choose a motor frame and power rating;
    • calculate a price from components, labor and commercial rules;
    • produce a configured BOM or manufacturing selection, if supported;
    • send the technical summary and quote value back to CRM.

    If the pump is a standard CTO product, the validated configuration may proceed to order entry with limited engineering review. If the application requires a new skid layout, unusual materials or a modified baseplate, the transaction may become ETO. CPQ can support the intake and handoff, but it does not automatically replace engineering or PLM unless the implementation explicitly provides those capabilities.

    CRM, CPQ and BOM ownership

    A bill of materials lists the components or assemblies required for a product. CPQ may generate a configurable BOM, but this capability is not universal and should not be assumed.

    An EBOM, or engineering bill of materials, represents the product from an engineering design perspective. An MBOM, or manufacturing bill of materials, represents how the product is assembled or produced. A CPQ system may generate a sales or configured BOM that must be transformed or reconciled before production.

    CRM is generally not the right place to maintain detailed BOM structures. It can display a product summary or quote lines, but complex component relationships, revisions and production effectivity usually belong in CPQ, PLM or ERP according to the company’s architecture.

    The BOM, pricing and quoting guide explains how configured products can connect commercial quoting with downstream product data.

    CRM, CPQ and engineering automation

    Engineering automation can include calculations, component selection, CAD generation, drawing creation and technical document production. These functions are usually closer to CPQ, CAD, PLM or engineering applications than to CRM.

    For example, CPQ might calculate a conveyor length from facility dimensions, select a drive package and pass parameters to a CAD automation service. The service could generate a product-specific layout or drawing. CRM would normally retain the opportunity and may provide a link or summary, but it would not be the authoritative CAD model.

    The CAD and engineering automation guide covers the relationship between CPQ inputs, engineering calculations, CAD models and drawings. Organizations should verify whether a selected CPQ platform performs these functions natively, invokes external tools or only stores the resulting references.

    Where the boundary becomes difficult

    Shared product and price data

    Both systems may display product names, item numbers and prices. Without ownership rules, sales teams may see different values in CRM and CPQ. A common approach is to keep customer-specific opportunity context in CRM, while CPQ retrieves product and pricing data from an approved source and returns the calculated result to CRM.

    Quote records

    CRM may need a quote record for pipeline reporting, while CPQ needs detailed versions, configuration state and rule outputs. The systems should not create competing quote versions. One system should own the detailed quote, with the other storing a synchronized summary and identifier.

    Customer-specific pricing

    Customer agreements may originate in ERP or CRM, while CPQ applies them to a configuration. The implementation should define whether the price list, contract discount, rebate or credit status comes from ERP, CRM or a dedicated pricing service.

    ETO work

    In ETO processes, CPQ may capture requirements and create a preliminary commercial estimate, but engineering may need to approve the design before a final quote. CRM should show the opportunity status, while engineering and product systems retain technical approvals, revisions and released data.

    Benefits of integrating CPQ and CRM

    • Faster technical response: Sales teams can launch a configuration from the opportunity instead of manually recreating customer information.
    • Fewer configuration errors: Rules can prevent invalid combinations before a quote reaches engineering or production.
    • Better opportunity visibility: CRM can show quote value, status, version and approval state.
    • Less duplicate entry: Account, contact, currency and opportunity data can be reused in CPQ.
    • More accurate forecasting: CRM pipeline values can reflect validated quote totals rather than rough estimates.
    • Improved engineering handoff: Technical inputs, assumptions and configuration identifiers can travel with the opportunity.
    • Clearer accountability: CRM owns the relationship while CPQ owns configuration and quote logic.

    Limitations and implementation risks

    Integration does not correct weak product data or unclear business ownership. If product options, rules, costs and revisions are inconsistent, connecting CPQ to CRM may simply move errors faster.

    • Unclear system ownership: The same price, product description or quote status is maintained in multiple systems.
    • Incomplete product models: Rules cover common combinations but not unusual engineering cases.
    • Overloaded CRM: Detailed engineering structures are forced into generic product or quote objects.
    • Weak version control: A quote is revised in CPQ but CRM continues to display an obsolete version.
    • Integration latency: Customer, inventory, cost or price updates are not available when the configuration is performed.
    • ETO ambiguity: The organization treats a preliminary estimate as a production-ready definition.
    • Governance gaps: No product owner is responsible for maintaining rules, option compatibility or release dates.
    • Excessive customization: The integration becomes dependent on one CRM implementation and difficult to maintain.

    CPQ implementation should therefore include data mapping, rule ownership, integration error handling, version management, testing and release governance. The CPQ implementation guide provides a framework for these activities.

    How to decide whether you need CPQ or CRM capabilities

    Business situation Likely requirement
    Standard products with simple prices and no technical dependencies CRM product and quote features may be sufficient
    Many options but limited technical interaction Basic CPQ or guided selling may be appropriate
    Options have dependencies, exclusions or capacity constraints A rules-based or constraint-based CPQ model is likely required
    Configuration affects BOM, engineering calculations or drawings Manufacturing CPQ with engineering and downstream integration should be evaluated
    Every order is substantially designed for a project CPQ may support requirements capture and estimating, but engineering and PLM remain central
    Customer and opportunity management is the main problem CRM should be the primary investment

    Recommended architecture and governance

    A practical architecture normally assigns responsibilities explicitly:

    1. CRM owns accounts, contacts, opportunities, activities and sales-process status.
    2. CPQ owns configuration sessions, technical selections, configuration rules and quote calculations where implemented as the pricing authority.
    3. ERP owns released item masters, orders, financial transactions and often standard costs or inventory.
    4. PLM owns released product structures, engineering revisions and change control where PLM is used.
    5. PDM owns CAD documents and design file management where PDM is used.
    6. CAD and engineering services generate geometry, drawings or calculations where those functions are integrated.
    7. MES manages production execution rather than commercial opportunity data.

    Governance should define who can change a rule, who approves pricing changes, how product revisions are released, how obsolete configurations are handled and what happens when an external system is unavailable. Testing should include valid configurations, invalid combinations, boundary values, price changes, revisions, discounts, approvals and integration failures.

    CPQ vs CRM in CTO, MTO and ETO workflows

    Configure-to-order (CTO) uses a predefined product model and approved options. CPQ can often validate the configuration, calculate the price and create a repeatable order definition.

    Make-to-order (MTO) produces a product after an order is received, usually from a defined specification. CPQ may capture the specification and pass it to ERP or production systems.

    Assemble-to-order (ATO) combines stocked or predefined modules after an order is placed. CPQ can select compatible modules, while ERP manages availability and fulfillment.

    Engineer-to-order (ETO) requires engineering work for the specific customer requirement. CPQ may collect requirements, estimate cost and initiate engineering review, but it should not be described as replacing engineering unless the system and process demonstrably support that outcome.

    The manufacturing workflows guide explains these operating models and their sales-to-production handoffs.

    Semantic map

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

    • CRM manages customer relationships and opportunities.
    • CPQ configures technically valid products.
    • Configuration rules prevent invalid combinations.
    • CPQ calculates configured product prices.
    • Configured products may generate configurable BOMs.
    • ERP manages orders and financial transactions.
    • PLM manages engineering product definitions and revisions.
    • PDM manages CAD documents and design files.
    • CAD automation generates product-specific drawings where integrated.
    • CRM displays quote status and opportunity value.
    • ETO requirements initiate engineering review.
    • CTO configurations use predefined product rules.

    Frequently asked questions

    1. Is CPQ part of CRM?

    CPQ may be embedded in, integrated with or separate from CRM. Conceptually, CPQ is a distinct capability focused on product configuration, pricing and quoting, while CRM manages customer and opportunity relationships.

    2. Can CRM replace manufacturing CPQ?

    CRM may handle simple products, catalogs and basic quotes. It usually cannot replace a manufacturing CPQ system when rules, engineering calculations, configurable BOMs or complex pricing are required.

    3. Does CPQ store customer information?

    CPQ can store customer references needed for a quote, but CRM is commonly the system of record for accounts, contacts, activities and opportunities.

    4. Does CPQ generate a BOM?

    Some manufacturing CPQ platforms generate configurable or sales BOMs, while others only produce quote lines. This capability must be verified for the specific platform and product model.

    5. Should product data be mastered in CRM or CPQ?

    CRM may store commercial catalog information, but detailed options, dependencies and configuration rules are usually better managed in CPQ or a connected product lifecycle system.

    6. Can CPQ calculate manufacturing cost?

    Some CPQ systems calculate material, labor, overhead or estimated cost. Others use external ERP or costing services. The source, refresh frequency and approval process for cost data should be defined.

    7. What does CRM send to CPQ?

    Common inputs include account, contact, opportunity, currency, channel, customer segment, location and commercial terms. The exact fields depend on the integration design.

    8. What does CPQ send back to CRM?

    CPQ commonly returns quote identifiers, configured product summaries, totals, versions, approval status, validity dates and quote status.

    9. Is a CRM quote the same as a CPQ quote?

    Not necessarily. CRM may contain a summary quote record for pipeline management, while CPQ contains the detailed configuration, calculations, versions and technical assumptions.

    10. Can CPQ automate CAD?

    Some platforms integrate with CAD or engineering automation tools, but this is not a universal CPQ capability. Verify supported CAD systems, parameter coverage, drawing outputs and revision handling.

    11. Does CPQ replace PLM?

    CPQ generally does not replace product lifecycle management. PLM typically manages engineering definitions, revisions and change control, while CPQ uses approved product knowledge to configure and quote.

    12. How does CPQ support engineer-to-order sales?

    CPQ can capture requirements, estimate cost, identify standard content and initiate engineering review. The final design, approval and release may remain in engineering and PLM systems.

    13. Should CRM own pricing?

    CRM can display prices and support sales processes, but complex configuration-dependent pricing is often better calculated in CPQ or a dedicated pricing service. Ownership should be explicit.

    14. How are discounts handled between CRM and CPQ?

    Many architectures let CRM provide customer or opportunity context while CPQ validates discount limits against configured product value, margin and approval rules. The authoritative calculation must be defined.

    15. Can CPQ work without CRM?

    Yes. CPQ can operate with other front ends or as a standalone application, although CRM is useful for account context, opportunity tracking and sales activity management.

    16. Can CRM work without CPQ?

    Yes. CRM is sufficient for relationship management and simple quoting. A separate CPQ capability becomes more valuable as product, pricing and engineering complexity increases.

    17. What is the difference between a CRM product catalog and a CPQ product model?

    A CRM catalog usually supports product display and basic selection. A CPQ product model can include options, dependencies, constraints, calculations, component logic and configuration-specific outputs.

    18. What should manufacturers test in a CRM-CPQ integration?

    Test account synchronization, currencies, price lists, configuration validity, quote versions, discount approvals, revisions, error handling, duplicate records and accepted-quote handoff to ERP or engineering systems.

    Related manufacturing CPQ guides

  • Cloud vs On-Premise CPQ for Manufacturers

    For manufacturers, the choice between cloud and on-premise CPQ depends less on where the software is hosted than on how deeply it must connect product configuration with engineering, pricing, quoting and production systems. Cloud CPQ is usually easier to deploy, access and update, while on-premise CPQ can provide greater control over infrastructure, data location and tightly coupled internal integrations. Neither option is automatically better for complex products.

    A manufacturing CPQ system should be evaluated as more than a sales quoting tool. CPQ means Configure, Price, Quote. In an industrial environment, configuration may select dimensions, materials, motors, pumps, valves, electrical components and safety options; validate engineering constraints; calculate price and cost; generate a configurable bill of materials (BOM); create engineering outputs; and transfer order data to enterprise systems. A deployment decision must therefore account for the complete data flow, not only the quote screen.

    In general, cloud CPQ is often the better starting point when a manufacturer needs rapid deployment, access for distributed sales channels, managed infrastructure and easier software updates. On-premise CPQ may be more appropriate when strict data-residency rules, isolated networks, legacy system dependencies, highly customized integrations or internal infrastructure control are decisive. A hybrid architecture can be appropriate when configuration and quoting are cloud-based but engineering, CAD, PLM or production systems remain inside the company network.

    For background, see the guide to manufacturing CPQ and the detailed explanation of product configuration and rules engines.

    What is cloud CPQ?

    Cloud CPQ is CPQ software operated in a cloud environment rather than installed entirely on the manufacturer’s own servers. The vendor or a hosting provider normally manages some or all of the infrastructure, application runtime, storage, monitoring and software deployment. Users typically access the system through a web interface or application programming interface (API).

    Cloud deployment does not mean that every system has the same architecture. A vendor may offer a multi-tenant application shared by many customers, a logically isolated hosted environment, or a dedicated private cloud instance. Buyers should verify the actual tenancy model, release process, data location, backup policy, integration methods and customization limits.

    In manufacturing, cloud CPQ may contain the product model, configuration rules, pricing logic, quote documents and user permissions. It may also connect through APIs or integration middleware to customer relationship management (CRM), enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), computer-aided design (CAD), product information management (PIM) and manufacturing execution systems (MES). The presence of an integration option should not be confused with a complete, tested integration for a particular manufacturer.

    What is on-premise CPQ?

    On-premise CPQ is installed and operated on infrastructure controlled by the manufacturer or by a hosting partner under a more traditional dedicated operating model. The company usually controls the servers, network access, operating system, database, backup arrangements, security controls and timing of application upgrades.

    On-premise does not necessarily mean that every component is physically located in the company’s main factory. It can include software hosted in a private data center or a dedicated managed environment. The important distinction is that the manufacturer retains a higher degree of responsibility and control for the application environment and its operation.

    This model can be useful where CPQ must communicate with internal systems over private networks, where production data cannot leave a controlled environment, or where the organization has established processes for infrastructure, identity management, disaster recovery and application support. It also creates more operational work. The manufacturer may be responsible for patching, capacity planning, monitoring, backup testing, high availability and compatibility with connected systems.

    Cloud vs on-premise CPQ: the main differences

    Criterion Cloud CPQ On-premise CPQ Manufacturing question
    Infrastructure Usually operated by the vendor or hosting provider Operated by the manufacturer or its designated infrastructure partner Who is accountable when the configuration service is unavailable during quoting or order entry?
    Deployment speed Often faster because servers and base environments already exist May require infrastructure, network, security and installation preparation Does the implementation schedule include firewall, identity and production-system work?
    Updates Usually delivered by the vendor according to a defined release process Scheduled and tested by the manufacturer or implementation team Can product rules, custom integrations and CAD automation survive an upgrade?
    Data control Depends on the provider’s regions, controls, contracts and architecture Greater direct control over storage location and network boundaries What customer, design, pricing and production data must remain in a controlled environment?
    External access Generally suited to dealers, distributors, remote sales teams and supplier users May require VPN, secure gateways or additional access architecture How will dealers configure products without exposing internal systems?
    Integration Often uses APIs, webhooks, middleware or secure connectors Can use internal network access and existing enterprise integration patterns Can CPQ exchange current items, prices, inventory and orders with ERP and engineering data with PLM?
    Customization May be constrained by the vendor’s extension model and shared release cycle May permit deeper environment-level customization, but increases maintenance Are custom calculations and rules genuinely differentiating, or are they creating technical debt?
    Operational responsibility Shared with the provider, subject to the contract and service boundaries Primarily the manufacturer’s responsibility Does the IT team have the skills and capacity to operate a mission-critical configuration service?
    Cost structure Often includes recurring software, hosting or service charges Includes licenses or subscriptions plus infrastructure, support and upgrade costs What is the total cost over the expected life of the product model?

    Why manufacturing CPQ makes the decision more complex

    Generic sales CPQ may focus on selecting products, applying discounts and producing a proposal. Manufacturing CPQ can include all of those activities, but it may also act as a controlled product-model and engineering decision system.

    Consider a configurable industrial pump. The user may select flow rate, pressure, fluid, temperature, casing material, impeller diameter, motor power, seal type, connection standard, enclosure rating and control panel. Rules must prevent incompatible combinations. Engineering calculations may determine a suitable motor or impeller. Pricing may depend on material, performance and supplier costs. The resulting BOM may need separate engineering and manufacturing representations. A CAD system may generate a drawing, while ERP needs item numbers, routings or order data.

    Some CPQ products support only a portion of this flow. A platform may provide guided selling and pricing but require a separate configurator, rules engine, CAD automation service or BOM application. Buyers should therefore compare the deployment architecture of the complete solution, not assume that cloud or on-premise describes every capability.

    How cloud and on-premise CPQ fit into the manufacturing architecture

    A typical manufacturing CPQ architecture contains several logical layers:

    1. User and channel layer: sales engineers, application engineers, dealers, distributors, ecommerce users or customers interact with a configuration experience.
    2. Configuration layer: a product model represents families, options, attributes, dependencies and constraints. Rules validate choices and may calculate derived values.
    3. Commercial layer: costing, price lists, discounts, margins, currencies, approvals and quote documents are applied.
    4. Engineering layer: calculations, CAD automation, drawings, specifications and engineering review may be triggered.
    5. Manufacturing data layer: the system may generate or select a configurable BOM, engineering BOM (EBOM) or manufacturing BOM (MBOM), depending on the process.
    6. Enterprise integration layer: ERP, CRM, PLM, PDM, MES and other systems exchange master data, transactions and status information.

    Cloud and on-premise deployment affect the communication paths between these layers. In a cloud design, an internal ERP or PLM system may need an outbound connector, an API gateway, a message broker or a secure integration service. In an on-premise design, CPQ may access internal databases and services more directly, although direct database access can create governance and upgrade problems.

    PLM manages product lifecycle information and revisions, while PDM commonly manages engineering files and design data. ERP manages business transactions such as items, customers, orders, purchasing and financial information. MES supports execution and visibility on the shop floor. CRM manages customer and opportunity information. These systems are related but not interchangeable. A CPQ deployment should specify which system owns each data object and how revisions are synchronized.

    Read more about CPQ integrations with ERP, CRM, PLM, PDM, CAD and MES.

    Cloud CPQ for manufacturers

    Potential advantages

    • Faster initial access: infrastructure provisioning and standard environments may be available without a new internal server project.
    • Distributed channel support: sales offices, dealers and distributors can use a browser-based application without extending the factory network to every user.
    • Centralized product-model access: approved configuration rules, pricing logic and quote templates can be maintained in one managed service.
    • Managed technical operations: the provider may handle infrastructure monitoring, backups, availability and platform maintenance within agreed service boundaries.
    • Scalable integration options: APIs and asynchronous messaging can connect cloud CPQ to multiple ERP, CRM or ecommerce environments.
    • Reduced local deployment dependency: new sales teams may not require a locally installed application.

    Limitations and risks

    • Connectivity dependence: a remote plant or dealer with unreliable connectivity may need offline processes or local fallback procedures.
    • Integration across network boundaries: sending configuration results to an internal CAD, PLM or ERP system requires carefully designed security, identity and error handling.
    • Release constraints: the vendor’s upgrade schedule may affect custom rules, integrations and extensions.
    • Data residency and confidentiality: product designs, customer information, prices and engineering calculations may be subject to contractual or regulatory restrictions.
    • Shared service dependencies: availability, performance and support depend partly on the provider’s architecture and service agreement.
    • Subscription and exit considerations: a manufacturer should understand data export, model portability, API access and assistance if the relationship ends.

    Cloud is not automatically simpler for a manufacturer with complex engineering. A large product model still requires ownership, testing, version control and a disciplined release process. Moving hosting to a provider does not remove the need to maintain rules for materials, dimensions, options, revisions and manufacturing outputs.

    On-premise CPQ for manufacturers

    Potential advantages

    • Control over the environment: the manufacturer can define network zones, storage locations, access policies and infrastructure standards.
    • Proximity to internal systems: CPQ can be placed near ERP, PLM, PDM, CAD services and file repositories where low-latency or private communication is important.
    • Release control: upgrades can be scheduled around engineering releases, factory shutdowns and peak quoting periods.
    • Support for isolated operations: plants or business units with restricted networks may prefer a system that does not require continuous external access.
    • Deeper environment customization: an organization with strong development and operations capabilities may have more control over custom services and integration components.

    Limitations and risks

    • Infrastructure responsibility: servers, databases, backups, monitoring, patching, disaster recovery and capacity planning must be assigned and funded.
    • Slower channel expansion: secure access for dealers and external sales teams can require additional identity and network architecture.
    • Upgrade burden: heavily customized deployments may be difficult to update, leaving old product rules or security components in place.
    • Higher dependence on internal specialists: the company may need people who understand the CPQ application, integration layer, databases and infrastructure.
    • Business continuity exposure: a local outage, failed integration server or unavailable data center can interrupt quoting and order preparation.

    On-premise deployment is not a substitute for governance. An internally hosted product model can still contain duplicate rules, obsolete prices, undocumented calculations and uncontrolled changes. The manufacturer remains responsible for deciding who owns the model and how changes are tested.

    Product configuration, engineering and BOM considerations

    The most important deployment question is often whether the product model is merely a sales catalog or a source of manufacturing-relevant decisions.

    Rules-based configuration uses explicit logic such as “if option A is selected, option B is required” or “this valve material is unavailable with that fluid.” Constraint-based configuration evaluates allowed combinations against technical constraints, ranges and relationships, such as pressure, temperature, load, capacity or dimensional limits. Guided selling asks users business-oriented questions and recommends products or options; it may use rules, but it does not necessarily perform full engineering validation.

    Cloud and on-premise systems can support any of these approaches only if the specific product provides the required functionality. Buyers should test realistic models, not a small demonstration product. A useful proof of concept might include a pump with material compatibility, motor sizing, regional electrical standards, price breaks, replacement components and a manufacturing output.

    A BOM is a structured list of components and quantities. An EBOM describes the engineering view of a product, while an MBOM describes how it is manufactured and may include production-specific assemblies, consumables, work instructions or shop-floor requirements. A configurable BOM represents alternatives, conditions or rules rather than one fixed structure.

    Some CPQ systems generate a BOM directly; others select existing ERP or PLM structures, call a separate configuration service, or pass option selections to downstream applications. The deployment model must support the chosen ownership pattern. For example, a cloud CPQ application may create a configuration result that an on-premise PLM system converts into an EBOM. Alternatively, CPQ may send a sales configuration to ERP while engineering creates the final MBOM later.

    CAD automation is similarly variable. A CPQ platform may integrate with parametric CAD, invoke a design automation service, generate drawings or only display a 2D or 3D representation. Verify whether CAD files are created synchronously, asynchronously or by a separate engineering system, and how revisions, failures and approvals are handled. See the guide to CAD and engineering automation and the guide to BOM generation, costing, pricing and quote automation.

    Security, availability and data governance

    Security should be evaluated as an architecture and operating responsibility, not as a simple cloud-versus-on-premise label. Cloud providers may offer strong physical security, encryption, identity controls, logging and backup capabilities, while an individual manufacturer may have weaker controls in its own data center. Conversely, some manufacturers require physical or network isolation that a standard cloud service cannot provide.

    Ask both deployment models the same questions:

    • Where are customer, pricing, product and engineering data stored?
    • How are users, dealers, service accounts and APIs authenticated?
    • Is data encrypted in transit and at rest?
    • How are configuration changes and price changes logged?
    • What are the recovery objectives for an outage?
    • How are backups isolated, retained and tested?
    • How are vulnerabilities and patches handled?
    • Can access be limited by role, business unit, product family or region?
    • How are data exports and deletion handled at contract termination?

    Availability must also be considered in operational terms. A sales team may tolerate a temporary delay in a proposal system, while an order-entry process that creates production data may require a defined recovery process. If the CPQ service cannot reach ERP, PLM or CAD, the organization needs clear behavior: queue the transaction, block submission, allow a controlled draft, or route the configuration for manual review.

    Integration patterns to evaluate

    Manufacturers should document the direction, ownership and timing of every important data exchange. Typical examples include:

    Data or event Possible source Possible CPQ use Important design issue
    Customer and opportunity CRM Start a configuration and associate it with an account Identity matching and authorization
    Item, cost and price data ERP or PIM Calculate a current quote Effective dates, currencies and synchronization failures
    Product revision and engineering attributes PLM or PDM Apply approved options and design rules Revision control and lifecycle status
    Configuration result CPQ Create an order, request engineering review or generate a BOM Idempotency, validation and audit history
    CAD request CPQ or engineering workflow Generate a model, drawing or specification Long-running jobs, errors and file ownership
    Production status ERP or MES Show order progress or confirm release Do not confuse quote status with manufacturing status

    Cloud systems commonly use REST or other APIs, webhooks, message queues and managed integration platforms. On-premise systems may use internal APIs, service buses, file exchange or direct network connections. Direct database integration can appear fast but often bypasses business rules and creates upgrade risk. In either architecture, transactions should be traceable, retriable and protected against duplicate orders.

    CTO, ETO, MTO and ATO implications

    Deployment choice should reflect the manufacturer’s operating model.

    • Configure-to-order (CTO): customers select from a controlled set of options, and the configured product can usually be assembled or produced using established structures. Fast, reliable configuration and BOM transfer are priorities.
    • Engineer-to-order (ETO): the customer’s requirements trigger new engineering work. CPQ may capture requirements, perform preliminary calculations, create a project or send a controlled request to engineering rather than produce a final manufacturing BOM immediately.
    • Make-to-order (MTO): production begins after a specific order, even if the product is based on an established design. Accurate options, cost, lead time and order data are important.
    • Assemble-to-order (ATO): standard modules are assembled after the order. The configuration and inventory model must agree on compatible modules and availability.

    A cloud architecture may work well for dealer-led CTO and ATO processes, while an on-premise or hybrid architecture may be preferred when ETO depends on restricted CAD, simulation or PLM environments. This is not a rule. The correct choice depends on the actual interfaces, data classifications and workflow controls.

    See manufacturing CPQ workflows for more detail on CTO, ETO, MTO, ATO and the sales-to-engineering handoff.

    How to choose between cloud and on-premise CPQ

    Use a weighted evaluation rather than a general preference for cloud or on-premise software. The following sequence is practical for a manufacturing selection project:

    1. Map the end-to-end workflow. Document how a requirement becomes a configuration, price, quote, engineering review, BOM, order and production release.
    2. Classify the data. Identify customer data, product designs, prices, costs, formulas, CAD files, supplier information and production data. Record residency and access requirements.
    3. Define system ownership. Decide which system owns products, options, rules, revisions, costs, prices, customers, BOMs and order status.
    4. Measure integration complexity. List ERP, CRM, PLM, PDM, CAD, PIM and MES interfaces, including legacy systems and plants with different architectures.
    5. Test representative products. Use a real product family with dependencies, incompatible options, calculations, revisions and downstream outputs.
    6. Evaluate operating capability. Compare the manufacturer’s ability to run infrastructure, manage releases, monitor integrations and support users.
    7. Model lifecycle cost. Include implementation, data cleanup, integration, licenses, hosting, internal support, upgrades, testing, training and eventual replacement.
    8. Plan governance. Assign owners for product models, rules, prices, engineering calculations, templates and integrations.
    9. Confirm exit and continuity plans. Verify backups, exports, disaster recovery, manual fallback processes and the ability to continue quoting if a connected system is unavailable.

    A proof of concept should include failure cases. Try an invalid material combination, an expired price, a missing ERP item, a CAD job that fails, a product revision that is not released and a configuration that requires engineering approval. These tests reveal more than a demonstration of a successful quote.

    The CPQ implementation guide covers requirements, migration, testing, deployment, governance and maintenance. Vendor selection criteria are also discussed in the manufacturing CPQ comparisons and selection guides.

    When a hybrid CPQ architecture makes sense

    Hybrid deployment places different functions in cloud and internal environments. For example, a manufacturer may expose cloud CPQ to dealers and sales teams, while keeping PLM, PDM, CAD automation, detailed cost data or production release services inside the corporate network.

    A hybrid design can balance external accessibility with internal control, but it introduces a boundary that must be designed carefully. The project should specify:

    • which data is copied to the cloud and which remains internal;
    • how identities and permissions cross the boundary;
    • how configuration revisions are synchronized;
    • how long-running CAD or engineering jobs report status;
    • what happens when the internal service is unavailable;
    • how errors, retries and duplicate requests are handled;
    • which system is the audit authority for the final configuration and order.

    Hybrid is not automatically a compromise-free option. It can increase integration and monitoring requirements. It is most useful when the business has a clear reason to separate user access from sensitive engineering or production services.

    Common mistakes in the deployment decision

    • Choosing based only on hosting cost: integration, model maintenance, data migration and testing often dominate the real implementation effort.
    • Assuming cloud means no IT involvement: cloud CPQ still requires identity, integration, data governance, release management and support.
    • Assuming on-premise means full control without cost: internal control requires people, processes, infrastructure and investment.
    • Evaluating a simple catalog: a few products and prices do not test engineering constraints or manufacturing outputs.
    • Confusing a quote with an order-ready configuration: a priced proposal may not contain an approved BOM, CAD output or ERP-valid item structure.
    • Ignoring model ownership: unclear responsibility for rules and revisions creates inconsistent quotes regardless of deployment model.
    • Underestimating connected-system failures: CPQ must define behavior when prices, inventory, item masters or engineering services cannot be reached.
    • Over-customizing early: custom code can make either deployment model harder to test, upgrade and govern.

    Conclusion

    Cloud and on-premise CPQ are deployment choices, not substitutes for a sound manufacturing product model. Cloud CPQ can simplify access, support distributed channels and reduce infrastructure administration. On-premise CPQ can provide tighter control over networks, data and release timing. Hybrid architecture can separate dealer-facing configuration from internal engineering and production services.

    The decisive questions are whether the system can represent the product accurately, enforce technical and commercial rules, produce the required engineering or manufacturing data, integrate with the existing enterprise landscape and remain maintainable as products change. Evaluate the complete workflow from customer requirement to production-ready information, then select the deployment model that the manufacturer can operate securely and govern over the product’s full lifecycle.

    Semantic map

    The article connects deployment architecture with the manufacturing CPQ entities and workflows below:

    • Manufacturing CPQ connects product configuration, engineering validation, pricing, quoting, BOM generation and enterprise integration.
    • Cloud CPQ connects distributed users and channels to centrally managed configuration services.
    • On-premise CPQ connects internally controlled infrastructure to ERP, PLM, PDM, CAD and production systems.
    • Hybrid CPQ connects cloud user access with internal engineering and manufacturing services.
    • Configuration rules connect customer choices to valid product structures and technical constraints.
    • Product revisions connect PLM or PDM data to approved configuration models.
    • Configured products connect pricing decisions to EBOM, MBOM or order data.
    • CAD automation connects configuration results to product-specific models and drawings.
    • ERP connects CPQ with items, costs, customers, orders and commercial transactions.
    • Manufacturing workflows connect CTO, ETO, MTO and ATO processes to downstream production.

    Frequently asked questions

    1. Is cloud CPQ better than on-premise CPQ for manufacturers?

    Not universally. Cloud CPQ may suit distributed sales and dealer access, while on-premise CPQ may suit strict network control or deeply integrated internal environments. The product model and integration requirements should determine the choice.

    2. What is the main advantage of cloud CPQ?

    The main potential advantage is managed access to a CPQ application without the manufacturer operating all underlying infrastructure. It can also simplify access for remote sales teams and distributors.

    3. What is the main advantage of on-premise CPQ?

    On-premise CPQ gives the manufacturer greater direct control over infrastructure, network boundaries, data location and upgrade timing. That control comes with additional operating responsibility.

    4. Can cloud CPQ connect to an on-premise ERP system?

    Yes, if the CPQ and ERP provide suitable APIs, connectors or integration services. The design must address authentication, firewall access, synchronization, errors, retries and duplicate transactions.

    5. Can on-premise CPQ support dealers and distributors?

    Yes, but external access may require secure gateways, identity federation, a virtual private network or a separate channel architecture. The security and support implications should be tested.

    6. Does cloud CPQ automatically generate a manufacturing BOM?

    No. BOM generation is a capability of the specific CPQ product or connected solution. Some systems generate BOMs, some select existing structures, and others pass configuration results to ERP, PLM or a separate configurator.

    7. Does on-premise CPQ provide better engineering automation?

    Not automatically. CAD automation and engineering calculations depend on the software, integration design and product model. On-premise deployment may simplify access to internal CAD or PLM services, but capability still must be verified.

    8. Is cloud CPQ suitable for engineer-to-order products?

    It can be suitable for capturing requirements, performing preliminary calculations, pricing work and initiating engineering review. Whether it can produce final engineering outputs depends on the specific system and workflow.

    9. What data does a manufacturing CPQ system need?

    It may need product families, options, attributes, rules, constraints, dimensions, materials, costs, prices, currencies, customer data, revisions and output mappings. The exact data depends on the intended workflow.

    10. Which system should own product configuration rules?

    There is no universal answer. Rules may be maintained in CPQ, a dedicated configurator, PLM or another product-model service. Ownership should be explicit, versioned, tested and aligned with the approved engineering process.

    11. How does cloud deployment affect CAD automation?

    Cloud CPQ may call a cloud CAD service, a secure internal CAD service or an asynchronous engineering workflow. The architecture must handle file transfer, permissions, processing time, revisions and failed jobs.

    12. Is on-premise CPQ more secure than cloud CPQ?

    Security depends on controls, architecture and operations rather than location alone. Compare encryption, identity management, logging, patching, backup, monitoring, network isolation and incident response for both options.

    13. What is hybrid CPQ?

    Hybrid CPQ places some services in the cloud and others inside the manufacturer’s network. A common pattern is cloud access for sales and dealers with internal ERP, PLM, PDM or CAD services retained behind corporate controls.

    14. How should manufacturers compare CPQ implementation costs?

    Include product modeling, data cleanup, integration, migration, testing, training, infrastructure, support, upgrades, security, governance and ongoing rule maintenance. Comparing only license or hosting charges is incomplete.

    15. Can a manufacturer migrate from on-premise CPQ to cloud CPQ?

    Migration may be possible, but it requires assessment of product models, custom code, integrations, historical quotes, files, user identities and data-export formats. A pilot product family can reveal portability issues.

    16. Can a manufacturer migrate from cloud CPQ to on-premise CPQ?

    That depends on the vendor’s licensing, export facilities and whether the target system represents the same rules, calculations, documents and integrations. Contractual and technical exit requirements should be reviewed before selection.

    17. Does deployment choice affect quote accuracy?

    Deployment location does not directly determine accuracy. Accuracy depends on product data, rules, calculations, price governance, integration quality, testing and user processes. Poorly maintained models produce errors in any hosting model.

    18. What should a CPQ proof of concept include?

    Use a representative configurable product with dependencies, technical constraints, pricing logic, revisions, engineering approval and a downstream output such as an order structure or BOM. Include invalid combinations and integration failure tests.

    19. Should ERP or PLM replace manufacturing CPQ?

    ERP and PLM serve different primary purposes. ERP manages business and production transactions, while PLM manages product lifecycle and engineering information. CPQ can coordinate customer-facing configuration, commercial logic and selected downstream outputs.

    20. How often must manufacturing CPQ rules be maintained?

    Rules should change whenever products, engineering constraints, prices, suppliers, regulations or manufacturing processes change. A governed release process should include ownership, testing, approval and version history.

  • CPQ vs ERP Product Configurator for Complex Manufacturing

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

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

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

    What is manufacturing CPQ?

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

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

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

    What is an ERP product configurator?

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

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

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

    CPQ vs ERP configurator: the central difference

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

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

    How the systems work together

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

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

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

    Product configuration is not the same as pricing

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

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

    Rules-based configuration

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

    Constraint-based configuration

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

    Guided selling

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

    BOM ownership: EBOM, configurable BOM and MBOM

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

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

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

    Engineering and CAD considerations

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

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

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

    CTO, ETO, MTO and ATO workflows

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

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

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

    When an ERP configurator may be sufficient

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

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

    When manufacturing CPQ is usually justified

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

    Limitations and risks

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

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

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

    Implementation approach

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

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

    How to evaluate CPQ and ERP configurator options

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

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

    Conclusion

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

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

    Semantic map

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

    Frequently asked questions

    Is CPQ the same as an ERP configurator?

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

    Can an ERP replace manufacturing CPQ?

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

    Does CPQ generate a production BOM?

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

    Should CPQ or ERP own product rules?

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

    Can CPQ calculate manufacturing cost?

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

    Does an ERP configurator support CAD automation?

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

    Which system should create the sales quote?

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

    Which system should create the work order?

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

    How does CPQ support engineer-to-order manufacturing?

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

    Is a configurable BOM the same as an MBOM?

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

    Should CPQ connect to PLM?

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

    What is the role of CRM in this architecture?

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

    Can dealers use a manufacturing CPQ system?

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

    What data should CPQ send to ERP?

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

    How should manufacturers handle price differences between CPQ and ERP?

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

    Is guided selling a product configurator?

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

    What is the biggest implementation risk?

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

    How should buyers compare CPQ and ERP configurators?

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

  • CPQ vs CAD Automation: Where Each Tool Starts and Stops

    Manufacturing Configure, Price, Quote (CPQ) and CAD automation are related but different technologies. CPQ determines what can be sold, how a product should be configured, what it should cost and what information belongs in the quote. CAD automation uses approved product parameters to create or update engineering models, drawings and related design outputs.

    The boundary is not always absolute. Some manufacturing CPQ platforms include engineering calculations, 2D or 3D visualization, configurable bills of material and integrations with computer-aided design (CAD) systems. Some CAD automation solutions can select components, apply design rules and generate bills of material. However, neither tool should automatically be treated as a complete replacement for the other.

    A practical way to separate them is this: CPQ controls the commercial and product-configuration decision; CAD automation creates or modifies the technical design that implements that decision. In a configurable pump, for example, CPQ may validate flow, pressure, material, motor and seal selections, calculate price and produce a quote. CAD automation may then select the correct pump geometry, generate a mounting arrangement, update dimensions and produce a drawing for engineering or production.

    This distinction matters when manufacturers select software, design their architecture or decide whether a product belongs in configure-to-order (CTO), make-to-order (MTO) or engineer-to-order (ETO) workflows.

    What manufacturing CPQ does

    Manufacturing CPQ is a system for modeling products, options, dependencies, constraints, calculations, pricing and quoting for complex products. It extends beyond generic sales quoting because the output may need to support engineering, procurement and production.

    A CPQ product model typically represents:

    • Product families, models and variants
    • Features, options, accessories and service selections
    • Dimensions, capacities, ratings and operating conditions
    • Dependencies between components
    • Rules that prevent incompatible combinations
    • Engineering calculations and sizing logic
    • Cost, price, discount, margin and approval rules
    • Configurable bills of material (BOMs)
    • Documents, specifications and quote content

    For example, an industrial fan CPQ model may require an airflow range, static pressure, housing material, motor voltage, drive type, temperature rating and mounting arrangement. Rules may prevent a motor from being selected outside its voltage range, require a reinforced housing above a certain pressure, or add a protective coating for a corrosive environment.

    Depending on the platform, the resulting configuration may create a quote only, or it may also create a manufacturing-ready BOM, an order structure, an engineering request or a CAD input package. These capabilities must be verified for each product rather than assumed from the term CPQ.

    See the guide to product configuration for more detail on product models, constraints and configuration validation.

    What CAD automation does

    CAD automation applies rules, parameters, templates, scripts or application programming interfaces (APIs) to create and modify CAD models and drawings. Its purpose is to reduce repetitive engineering work and produce consistent technical outputs for a specific design.

    CAD automation may generate or update:

    • Parametric 3D part and assembly models
    • 2D manufacturing drawings
    • Dimensions, annotations and title blocks
    • Cut lists and detail views
    • Weldment, sheet-metal or structural layouts
    • Design-specific component placement
    • Performance calculations tied to geometry
    • CAD-derived BOMs or engineering BOMs (EBOMs)
    • Neutral files for downstream systems

    In a configurable conveyor, for instance, CAD automation may set conveyor length, belt width, frame height, drive location and support spacing. It may suppress or add components, recalculate patterns, update assembly relationships and generate drawings. The automation normally operates inside, beside or through a CAD system and must respect the modeling conventions, feature dependencies and revision controls of that system.

    CAD automation is therefore focused on the technical representation of a product. It does not necessarily know whether a configuration is commercially sellable, whether a discount requires approval or whether a dealer is authorized to sell a particular option.

    Read more about CAD and engineering automation, including parametric CAD, visualization, drawings and engineering calculations.

    CPQ and CAD automation compared

    Capability Manufacturing CPQ CAD automation
    Primary purpose Validate, price and quote a configurable product Create or modify the technical design
    Main users Sales engineers, product managers, application engineers and commercial teams Design engineers, detailers, engineering automation specialists and drafters
    Core data Options, rules, prices, costs, product structures and commercial policies Parameters, features, geometry, assemblies, drawings and design templates
    Typical output Validated configuration, price, quote, specification and possibly BOM 3D model, drawing, design calculation, CAD BOM or manufacturing document
    Primary question Can this product be sold, and at what price? How should this product be designed and documented?
    Commercial governance Usually central Usually limited or external
    Manufacturing readiness May generate order and BOM data if supported May generate engineering data but not necessarily routings, pricing or order approvals

    Where CPQ starts

    CPQ starts when a manufacturer needs to represent a sellable product and guide a user toward a valid commercial configuration. The user might be an internal salesperson, a sales engineer, a distributor or a customer using a controlled self-service interface.

    The starting point is usually a product model. The model defines the choices exposed to the user and the rules that govern them. It may also include formulas for sizing or selection. In a valve application, the model could use media, temperature, pressure, pipe size, body material, trim material and actuation requirements to narrow the valid selections.

    CPQ then handles commercial decisions such as:

    • Which options are available for the selected product family
    • Which combinations are valid or invalid
    • Which components and services are included
    • How costs and prices are calculated
    • Which discounts or margins require approval
    • Which lead-time or availability information should be shown
    • What technical description belongs in the proposal

    This is the boundary between product configuration and CAD design. Configuration selects and validates the product definition. It does not automatically mean that the system has created a complete geometric design.

    Where CAD automation starts

    CAD automation starts when the approved product definition contains enough information to drive a design process. That information may come from CPQ, a product lifecycle management (PLM) system, a product data management (PDM) system, an engineering application or a combination of sources.

    A CAD automation process may receive:

    • Product family and model number
    • Key dimensions and performance values
    • Material and component selections
    • Motor, gearbox or actuator specifications
    • Mounting and connection requirements
    • Selected accessories and exclusions
    • Engineering calculation results
    • Revision and document metadata

    It then applies a design template or automation routine. For example, an enclosure design may use width, height, depth, ingress-protection requirements, gland-plate selections and internal component locations. The CAD process may create the geometry, place components, update hole patterns and generate a drawing package.

    CAD automation begins only when the inputs are sufficiently defined. If the application still requires an engineer to invent a new mechanism, resolve an unmodeled interaction or interpret an ambiguous requirement, the work has moved toward ETO rather than straightforward automation.

    Where the two tools overlap

    The overlap usually occurs in engineering calculations, visualization, product structures and design-driving parameters.

    Engineering calculations

    Manufacturing CPQ may calculate a required motor size, heat-exchanger area, pump duty point or structural capacity. CAD automation may use the result to select geometry or update a model. The calculation may live in CPQ, a dedicated engineering application or CAD software. Ownership should be explicit because duplicating the same formula in multiple systems creates inconsistent results.

    Configurable BOMs

    A CPQ system may generate a configurable BOM based on selected options. A CAD system may generate an EBOM from the actual design structure. These structures are related but not always identical. The engineering BOM describes the product from a design perspective, while a manufacturing BOM (MBOM) describes how the product is assembled or produced. A production system may also require routings, work instructions and manufacturing-specific substitutions.

    Manufacturers should define whether CPQ creates a preliminary BOM, an order BOM, an EBOM, an MBOM input or only a list of selected options. More information is available in the guide to BOMs, pricing and quoting.

    3D visualization

    A CPQ interface may display a product image or interactive 3D model to help users understand their selections. That visualization can be driven by configuration parameters without creating a fully detailed CAD assembly. CAD automation, by contrast, generally produces an engineering model with design intent, features and documentation.

    Rules and constraints

    CPQ rules often express commercial and product-selection logic: a high-temperature seal is required above a specified temperature, or a particular drive is unavailable with a selected voltage. CAD rules express geometric and design behavior: a hole pattern moves when a frame length changes, or a support is added when a span exceeds a limit.

    Some rules apply to both systems. They should have a clear system of record and be tested at the handoff.

    What CPQ should not be expected to do automatically

    CPQ is not automatically a CAD system, a PLM system or a manufacturing execution system. A platform may offer connectors or embedded capabilities, but buyers should verify the depth of each function.

    CPQ alone may not:

    • Create valid parametric geometry for every possible configuration
    • Resolve complex mechanical design intent
    • Generate production-ready drawings without engineering review
    • Manage CAD revisions and released design documents
    • Create manufacturing routings or work instructions
    • Replace a PLM or PDM repository
    • Guarantee that a configured BOM is suitable for shop-floor execution

    A quote can be commercially valid while still requiring engineering work. For example, a large custom pressure vessel may pass material, capacity and pricing rules but require an engineer to develop nozzle placement, welding details and code-compliance documentation.

    What CAD automation should not be expected to do automatically

    CAD automation is not automatically a CPQ system. A CAD model may be technically valid but commercially incomplete. It may not contain approved prices, discount limits, customer-specific terms, sales-channel restrictions or quote language.

    CAD automation alone may not:

    • Guide a non-engineer through commercial product choices
    • Prevent options that are technically possible but not sold
    • Calculate approved selling prices and margins
    • Apply customer, territory or channel rules
    • Generate a complete proposal and approval workflow
    • Determine whether a product should be CTO or ETO
    • Manage CRM opportunity context or ERP order creation

    Using CAD as the only configuration interface can also expose engineering parameters that should be controlled or hidden from sales users. It may make the process technically powerful but difficult to govern.

    How CPQ and CAD automation work together

    A common architecture separates responsibilities while allowing controlled data exchange.

    1. Configure: A salesperson or sales engineer selects the product family, options, dimensions and application requirements in CPQ.
    2. Validate: CPQ applies rules, constraints and calculations to reject invalid combinations or identify a need for engineering review.
    3. Price: The system calculates cost, price, margin, freight or other commercial values according to approved policies.
    4. Quote: CPQ generates a technical proposal, scope statement and commercial offer.
    5. Handoff: Approved configuration data is sent to CAD automation, PLM, ERP or an engineering work queue.
    6. Generate: CAD automation creates or updates models, drawings and design-specific documents.
    7. Review and release: Engineering checks the output where required and releases controlled documents.
    8. Order and manufacture: ERP receives order data and production systems receive the appropriate BOM and documentation.

    The integration may be synchronous, where CAD output is created during configuration, or asynchronous, where CPQ submits an engineering job and receives results later. The right approach depends on model complexity, required engineering review, system APIs and acceptable response time.

    Manufacturers should document the data contract between systems. It should identify fields, units, revision identifiers, option codes, error responses, ownership and whether values are authoritative or calculated.

    The broader system landscape is described in the manufacturing CPQ integrations guide.

    Example: configurable industrial pump

    Consider a pump manufacturer offering centrifugal pumps for water, chemicals and process applications.

    CPQ responsibilities

    • Capture flow, head, fluid, temperature and installation requirements
    • Recommend an appropriate pump family and operating range
    • Restrict materials and seals based on the fluid and temperature
    • Select motor voltage, frequency and efficiency class
    • Calculate price, cost and expected lead time
    • Generate a quote and technical specification
    • Create an order configuration or preliminary BOM

    CAD automation responsibilities

    • Select the correct impeller and casing geometry
    • Set connection sizes and mounting dimensions
    • Place motor and coupling components
    • Update baseplate dimensions
    • Generate an assembly model and general arrangement drawing
    • Produce design-specific documents for engineering review

    If the requested duty falls outside validated pump curves, CPQ may route the opportunity to engineering. CAD automation should not be asked to compensate for an incomplete product model by inventing a new hydraulic design.

    Choosing the system boundary

    The correct boundary depends on product complexity and the target workflow.

    Situation Likely emphasis Important caution
    Standard product with selectable options CPQ configuration, pricing and quote generation CAD may not be needed for every order
    Configurable product with repeated geometry patterns CPQ plus template-driven CAD automation Parameter mappings and drawing rules require testing
    Complex engineered product CPQ for front-end definition plus engineering workflow Not every quote can produce an automatic final design
    High-volume CTO product Validated CPQ-to-ERP and BOM flow Production structure may differ from EBOM
    Novel or heavily customized ETO product CPQ for scope and commercial control plus engineer-led design Automation should support, not conceal, engineering uncertainty

    Implementation considerations

    Assign ownership of product data

    Product management may own sellable options, engineering may own design parameters, finance may own pricing policies and manufacturing may own production structures. A governance model must define who approves changes and how revisions move between systems.

    Use stable identifiers

    Option names shown to users are not sufficient integration keys. Use controlled codes for products, options, materials, components, revisions and units of measure. This reduces errors when CPQ exchanges data with CAD, ERP, PLM or PDM.

    Separate validation layers

    CPQ should validate sellable configurations. CAD automation should validate design behavior. ERP should validate order and master-data requirements. These checks may overlap, but each system should have a clear purpose and error message.

    Test combinations, not just screens

    Testing should include valid and invalid combinations, boundary dimensions, unit conversions, revision changes, unavailable components, price changes, CAD failures and manual engineering overrides. A visually correct quote does not prove that the resulting BOM or drawing is correct.

    Plan for exceptions

    Some configurations will need engineering review, alternative components or customer-specific documentation. The workflow should record the exception, preserve the original configuration and identify who approved the change. Manual workarounds outside the systems create weak traceability.

    Measure the complete process

    Useful measures include configuration error rates, quote turnaround time, engineering touches per quote, percentage of orders requiring re-entry, CAD generation failures, BOM corrections, margin variance and time from order approval to released production data. These measures are more meaningful than counting software features.

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

    Practical decision checklist

    When evaluating CPQ and CAD automation together, ask:

    • Which system owns each product rule?
    • Does CPQ create only a quote, or also a validated order configuration?
    • Is the BOM an EBOM, an MBOM, a configurable BOM or a preliminary selection list?
    • Which dimensions and calculations must reach CAD?
    • Can CAD automation report errors back to CPQ?
    • When is engineering approval mandatory?
    • How are revisions synchronized?
    • What happens when a component is obsolete or unavailable?
    • Can the process support CTO, MTO and ETO orders without confusing their different requirements?
    • Which outputs are released for production, and who releases them?

    The goal is not to make one tool perform every task. The goal is to create a controlled flow from customer requirements to a valid commercial offer, an accurate technical definition and manufacturing-ready information.

    Related concepts

    Readers comparing these technologies should also understand configure-to-order, engineer-to-order and other manufacturing workflows, as well as the difference between CPQ outputs and production structures. The manufacturing CPQ guide provides the broader context.

    Semantic map

    This article connects the following manufacturing technology entities:

    • CPQ relates to product configuration, pricing, quoting and commercial validation.
    • Product configuration relates to options, dependencies, constraints and rules.
    • CAD automation relates to parametric models, drawings, geometry and engineering outputs.
    • Configured products relate to BOM generation, ERP orders and production data.
    • Engineering calculations connect application requirements with product selection and design parameters.
    • PLM and PDM provide controlled product and design data around the CPQ-to-CAD workflow.
    • ERP receives approved order, item and BOM information for business and manufacturing execution.
    • CTO uses validated product options, while ETO requires additional engineering design work.

    Frequently asked questions

    1. Is CPQ the same as CAD automation?

    No. CPQ manages product configuration, commercial rules, pricing and quoting. CAD automation creates or updates technical models, drawings and related engineering outputs.

    2. Can CPQ replace CAD?

    Usually not. Some CPQ platforms provide visualization, calculations or CAD integrations, but a complete parametric design environment normally remains a CAD or engineering responsibility.

    3. Can CAD automation replace CPQ?

    Not generally. CAD automation may generate a technically valid design but usually does not manage selling rules, discounts, approvals, customer terms or quote documents.

    4. Does every manufacturing CPQ system generate CAD drawings?

    No. CAD generation is an optional capability or integration that must be verified for the specific platform and product use case.

    5. Does every CAD system generate a manufacturing BOM?

    No. A CAD system may generate an engineering BOM, but a manufacturing BOM can require manufacturing-specific assemblies, operations, substitutes and plant rules.

    6. What is the main output of CPQ?

    The main output is a validated product configuration and commercial quote. Depending on the system, it may also produce specifications, an order structure or a configurable BOM.

    7. What is the main output of CAD automation?

    The main output is a product-specific design representation, such as a 3D model, 2D drawing, assembly layout or design calculation.

    8. Where do engineering calculations belong?

    They may belong in CPQ, CAD or a dedicated engineering application. The important requirement is to establish one authoritative calculation or a controlled synchronization between systems.

    9. Can CPQ drive CAD parameters?

    Yes, when the CPQ platform and CAD process have a defined integration. Dimensions, materials, options and calculated values can be passed to CAD automation to drive templates or models.

    10. Can CAD results be sent back to CPQ?

    Yes. A CAD process may return a model identifier, drawing status, calculated dimension, weight or error message. The integration should define which values are authoritative.

    11. How do CPQ rules differ from CAD rules?

    CPQ rules usually govern sellable options, dependencies, pricing and application constraints. CAD rules govern geometry, feature behavior, assembly relationships and drawing generation.

    12. Is a 3D configurator the same as CAD automation?

    No. A 3D configurator may change visual components or representations without generating a fully detailed engineering model or production drawing.

    13. Which tool is more important for engineer-to-order products?

    Both may be important, but neither removes the need for engineering judgment. CPQ defines scope and commercial assumptions, while CAD automation can accelerate repeatable design work after requirements are sufficiently defined.

    14. How should a manufacturer handle configurations that CAD cannot generate?

    Route them to an engineering review process, preserve the selected configuration and record the reason for manual design work. Do not silently substitute an unvalidated design.

    15. What is the difference between an EBOM and an MBOM in this workflow?

    An engineering BOM describes the product as designed. A manufacturing BOM describes how it is assembled or produced. CPQ or CAD may create an EBOM or preliminary structure, while ERP or manufacturing systems may create or refine the MBOM.

    16. Should CPQ connect directly to CAD or through PLM?

    Either architecture can be appropriate. Direct integration may suit a focused workflow, while PLM or PDM can provide revision, document and design-release control. The choice depends on system ownership and process requirements.

    17. What should buyers verify in a CPQ and CAD automation evaluation?

    Verify product-model depth, rule handling, calculation support, BOM type, CAD integration method, parameter mapping, revision control, error handling, engineering review and production-system handoff using a representative product.

  • CPQ vs Quote-to-Cash: Where Manufacturing CPQ Fits

    Manufacturing CPQ is the configuration, engineering, pricing and quoting part of the broader quote-to-cash process. Quote-to-cash describes the complete commercial lifecycle from identifying a customer requirement and preparing a quote through contract acceptance, order processing, delivery, invoicing and payment. Configure, Price, Quote (CPQ) focuses primarily on turning a customer requirement into a valid product configuration and an accurate commercial offer.

    For a manufacturer selling configurable pumps, industrial machinery, electrical assemblies or specialty vehicles, CPQ may do much more than select options and calculate a price. It can apply product rules, perform engineering calculations, validate dimensions and materials, create a configurable bill of materials (BOM), trigger computer-aided design (CAD) automation and pass order-ready data to enterprise systems. However, not every CPQ platform provides all of these capabilities.

    The practical distinction is this: CPQ helps determine what can be sold and under what commercial and technical conditions; quote-to-cash manages what happens across the wider business after and around that quote. Manufacturing CPQ normally sits between customer and product requirements on one side and customer relationship management (CRM), enterprise resource planning (ERP), product lifecycle management (PLM) and production processes on the other.

    What is quote-to-cash?

    Quote-to-cash is an end-to-end business process that begins with a sales opportunity or customer request and ends when the manufacturer receives payment. It is a process scope rather than one specific software category. Different companies implement it using several connected systems.

    A typical quote-to-cash flow includes:

    1. Identifying an opportunity, customer requirement or request for quotation.
    2. Determining whether the product and commercial terms are suitable.
    3. Configuring the product and calculating cost and selling price.
    4. Generating and approving a quotation.
    5. Negotiating terms and accepting a contract or purchase order.
    6. Creating a sales order and releasing the order for fulfillment.
    7. Planning procurement and production, followed by shipment or installation.
    8. Creating an invoice, collecting payment and managing financial records.

    The exact boundaries vary. Some organizations include lead management and opportunity management. Others begin with quotation and end with payment. The important point is that quote-to-cash crosses departmental and system boundaries. Sales, application engineering, finance, operations, manufacturing, logistics and customer service may all participate.

    What is manufacturing CPQ?

    Manufacturing CPQ is software and product-modeling capability used to configure complex products, calculate prices and costs, and generate accurate quotations. In manufacturing environments, it may also connect the selected configuration to engineering and production data.

    A manufacturing CPQ product model can contain:

    • Product families, modules, options and variants.
    • Dependencies between features, such as a motor that requires a specific controller.
    • Exclusions, such as materials or voltage ranges that cannot be combined.
    • Dimensional limits, load ratings, pressure ranges and performance constraints.
    • Calculations for capacity, flow, torque, power, heat transfer or structural requirements.
    • Pricing, discount, surcharge, currency and margin rules.
    • Component and operation relationships used to create a configurable BOM.
    • Rules for when an application engineer must review or complete an engineer-to-order request.

    These capabilities are not universal. A lightweight sales CPQ application may manage guided selling, product selections, discounts and proposal documents without generating a manufacturing BOM or CAD model. Buyers should verify each capability rather than assuming that the label CPQ describes a complete engineering system.

    Read the broader guide to manufacturing CPQ for an overview of product models, engineering automation, pricing and downstream manufacturing integration.

    CPQ versus quote-to-cash: the central difference

    Area Manufacturing CPQ Quote-to-cash
    Primary purpose Determine a valid product configuration, price and quote. Manage the complete commercial process through order, delivery, invoicing and payment.
    Typical starting point Customer requirements, product selection or an opportunity. Lead, opportunity, request for quotation or customer order.
    Product focus Options, constraints, dimensions, engineering rules and product structure. Product, contract, order, fulfillment, billing and financial records.
    Key users Sales engineers, application engineers, product managers and technical sales teams. Sales, finance, order management, operations, manufacturing, logistics and customer service.
    Typical outputs Validated configuration, price, quote, BOM, calculation results or CAD outputs where supported. Accepted order, fulfillment transactions, invoice, payment and revenue records.
    Common systems CPQ, rules engine, CAD and engineering tools. CRM, CPQ, contract management, ERP, order management, billing and payment systems.
    Manufacturing dependency Must represent product and engineering logic accurately. Must coordinate commercial, operational and financial execution.

    CPQ is therefore not automatically an alternative to quote-to-cash. It is usually a specialized capability within the quote-to-cash architecture. A company can have quote-to-cash processes without a dedicated CPQ platform, but complex manufacturers often need more than manual spreadsheets, generic CRM product lists or basic quoting tools.

    Where manufacturing CPQ fits in the quote-to-cash architecture

    Manufacturing CPQ commonly occupies the decision point where a customer requirement becomes a defined, priced and quotable product. Its upstream and downstream relationships are important.

    Upstream systems and inputs

    A CRM system stores accounts, contacts, opportunities and sales activities. It may initiate the CPQ session or receive the resulting quote. Product information management (PIM) systems may provide descriptions, images and commercial attributes. Product lifecycle management (PLM) or product data management (PDM) systems may provide approved product structures, revisions and engineering metadata.

    These systems are not interchangeable. CRM manages customer and sales relationships. PLM manages product lifecycle information and engineering change processes. PDM usually focuses on engineering files and product data control. PIM commonly manages product content for channels. CPQ consumes or references selected data to support configuration and quoting.

    The CPQ decision layer

    Within CPQ, the user or customer selects options, enters requirements and receives feedback. The system may use several types of logic:

    • Rules-based configuration: explicit if-then logic, such as requiring a stainless-steel wetted part for a specified chemical service.
    • Constraint-based configuration: a solver evaluates permitted combinations, ranges and relationships, such as pressure, temperature, flow and material limits.
    • Guided selling: questions lead a user toward suitable products or options, often without exposing the full engineering model.

    A mature model may use all three approaches. Guided selling helps a distributor or salesperson gather requirements. Rules and constraints validate the technical result. The model may then calculate price, create a BOM or route an exception to engineering.

    Downstream systems and outputs

    After a quote is accepted, the configured result may be sent to ERP for customer, order, inventory, procurement, costing or financial processing. A PLM or PDM system may remain the authority for released engineering structures and revisions. CAD integration may create or update a product-specific model and drawings. A manufacturing execution system (MES) may receive production instructions or order data, usually through ERP or another controlled integration.

    Integration design determines whether the CPQ result is merely a sales record or a reliable manufacturing input. See the guide to CPQ integrations with ERP, CRM, PLM, PDM, CAD and MES.

    How CPQ supports a manufacturing quote-to-cash process

    1. Capture requirements

    The process begins with requirements such as flow rate, lifting capacity, voltage, ambient temperature, dimensions, material, duty cycle or regulatory classification. A CPQ interface can expose these as structured inputs instead of relying on free-text notes.

    For example, a pump configuration may require flow, head, fluid type, temperature, motor voltage, seal material and area classification. The product model can identify whether the selected pump, impeller, motor and seal combination is technically valid.

    2. Validate the product

    Validation prevents invalid combinations before they reach engineering or order entry. A rule might prohibit an aluminum housing at a specified pressure, require a larger frame size above a torque threshold or restrict a motor to compatible electrical controls.

    Validation does not eliminate engineering responsibility. It is only as reliable as the product data, rules and assumptions behind it. New products, supplier substitutions, regulatory changes and undocumented exceptions can make a model incomplete.

    3. Perform calculations

    Some manufacturing CPQ systems perform calculations directly; others call external engineering services or use precomputed selection tables. Examples include heat exchanger sizing, motor selection, conveyor capacity, valve sizing, cable selection and vehicle payload calculations.

    Calculation results should be traceable. A quote may need to show the selected duty point, design margin, assumptions and any engineering approval requirement. A simple option list is not equivalent to an engineering calculation engine.

    4. Generate cost and price

    CPQ pricing can combine list prices, component costs, labor, freight assumptions, currency conversion, customer-specific agreements, volume breaks, discounts, surcharges and margin controls. Costing and pricing are related but distinct. Cost estimates describe expected internal or supplier cost; selling price describes the commercial amount offered to the customer.

    Some manufacturers calculate costs in ERP or a specialized costing system and use CPQ to retrieve them. Others maintain selected cost and pricing logic in CPQ. The authoritative source, update process and timing should be defined during implementation.

    5. Create a quote

    CPQ can generate a quote containing line items, descriptions, quantities, prices, terms, lead-time assumptions, exclusions and approval information. For engineered products, the document may also need performance data, outline drawings, compliance information or a preliminary specification.

    A polished proposal is not proof that the product is manufacturable. The technical validity of the configuration and the completeness of downstream data matter more than document formatting.

    6. Create manufacturing information

    Where supported, CPQ can generate a configurable BOM or pass configuration data to a system that creates one. A BOM is a structured list of components and quantities. An engineering BOM (EBOM) represents the product from an engineering perspective, while a manufacturing BOM (MBOM) represents how it is assembled or produced. They may contain different structures, items and operations.

    A configurable BOM may contain selectable components, quantities driven by dimensions and rules for alternative materials. It should not automatically be treated as a released EBOM or MBOM. Engineering and manufacturing governance may require review, revision control, effectivity and approval before production.

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

    7. Handoff to order and production

    After acceptance, the system must preserve the exact configuration that was quoted. A change in motor, material, dimensions or commercial terms can affect cost, BOM, lead time and drawings. A robust handoff carries a configuration identifier, revision, selected options, calculated values, documents and approval status into order processing.

    The resulting workflow may be configure-to-order (CTO), engineer-to-order (ETO), make-to-order (MTO) or assemble-to-order (ATO):

    • CTO: the customer selects from predefined valid options and the product is configured from an established model.
    • ETO: the order requires significant engineering design or modification after the commercial decision.
    • MTO: production begins after an order, often using a known design or product specification.
    • ATO: standard modules or components are stocked or prepared and assembled after the order.

    These categories can overlap. A configurable machine may be CTO at the product-model level while still requiring limited ETO work for a site-specific foundation or interface.

    See manufacturing workflows for CTO, ETO, MTO and ATO for a more detailed comparison.

    Manufacturing CPQ versus generic sales CPQ

    Generic sales CPQ typically emphasizes product selection, discount controls, approvals, quote documents and CRM workflow. Those capabilities can be useful in manufacturing, especially for standard products and dealer sales.

    Manufacturing CPQ must be evaluated more deeply when products contain engineering dependencies. Relevant questions include:

    • Can the system model dimensions, ranges, formulas and conditional dependencies?
    • Can product rules be maintained by product managers and engineers without creating uncontrolled custom code?
    • Can it produce a configurable BOM, and is that BOM an input to ERP, PLM or manufacturing engineering?
    • Can it integrate with CAD or generate drawings, and under what conditions?
    • Can it distinguish standard CTO options from ETO exceptions?
    • Can it support dealer, distributor, internal sales and direct customer workflows?
    • Can it preserve product revisions and quote configuration snapshots?
    • Can administrators test rule changes against representative product scenarios?

    A platform may be strong at sales quoting but unsuitable for engineering-driven configuration. Conversely, an engineering configurator may model products well but require additional systems for commercial approvals, customer records or financial processing.

    What quote-to-cash does not mean

    Quote-to-cash is not necessarily a single application, and it is not synonymous with CPQ. It does not automatically provide a product rules engine, CAD automation, BOM generation or manufacturing planning. These functions may be distributed across CPQ, ERP, PLM, PDM, CAD, MES and specialized applications.

    Likewise, CPQ does not automatically cover contract execution, delivery scheduling, invoicing or payment collection. Some vendors position CPQ inside a broader revenue or quote-to-cash suite, but the actual manufacturing capabilities must be verified separately.

    Benefits of placing CPQ correctly

    • Fewer configuration errors: rules identify incompatible options before quotation or order entry.
    • Faster engineering response: repeatable selections and calculations reduce manual application work for standard cases.
    • More accurate commercial decisions: cost, price, margin and lead-time assumptions can reflect the actual configuration.
    • Better sales-to-engineering handoff: structured requirements replace ambiguous notes and email attachments.
    • More reliable downstream data: selected options can feed BOM, CAD, ERP or PLM processes where integrations support it.
    • Improved governance: product rules, prices and approval logic can be versioned, tested and assigned to owners.

    Limitations and risks

    CPQ cannot compensate for poor product data. If engineering structures are incomplete, prices are outdated or exceptions exist only in an experienced salesperson’s knowledge, the system may produce consistent but incorrect results.

    Common risks include:

    • Trying to model every engineering possibility before deciding which products should be standardized.
    • Duplicating uncontrolled product and price data across CPQ, ERP and PLM.
    • Using free-text exceptions that bypass configuration validation.
    • Confusing a quote BOM with a released manufacturing BOM.
    • Sending a configuration to ERP without a clear revision or change process.
    • Assuming CAD automation is included because a platform supports product configuration.
    • Failing to test rules after product, supplier, regulatory or pricing changes.
    • Designing for sales users without involving engineering, manufacturing and finance.

    For implementation guidance, see CPQ implementation planning, testing, governance and maintenance.

    How to decide whether CPQ belongs in your quote-to-cash program

    A dedicated or expanded manufacturing CPQ capability is most valuable when product complexity creates recurring commercial and engineering risk. Indicators include long quote cycles, frequent clarification emails, repeated engineering effort for standard configurations, pricing errors, inconsistent dealer quotes, manual BOM preparation and orders that require re-entry into multiple systems.

    Start with a bounded product family rather than attempting to model the entire catalog. Select a product with measurable configuration problems, stable enough rules and a clear downstream owner. Document:

    1. Customer inputs and required technical constraints.
    2. Product options, dependencies and exclusions.
    3. Engineering formulas and selection tables.
    4. Cost and price sources, including approval thresholds.
    5. Quote content and revision requirements.
    6. BOM, CAD and document outputs.
    7. ERP, CRM, PLM, PDM and MES responsibilities.
    8. Exceptions that require human engineering review.
    9. Test cases covering valid, invalid, boundary and changed configurations.

    Then define whether CPQ is the system of record, a decision layer, or an orchestration layer. In many architectures, PLM remains authoritative for released engineering data, ERP remains authoritative for orders and financial transactions, CRM remains authoritative for customer and opportunity data, and CPQ coordinates configuration and commercial decision-making.

    How to evaluate CPQ and quote-to-cash architecture

    Evaluation question Why it matters
    Where are product rules owned? Prevents contradictory logic and clarifies who approves changes.
    Where are costs and prices maintained? Determines whether margins and commercial terms are trustworthy.
    What is the exact output of configuration? Separates a quote line from a BOM, CAD model, specification or order-ready structure.
    How are revisions represented? Protects the relationship between the quoted, ordered and manufactured product.
    Which exceptions require engineering? Prevents CPQ from falsely promising full automation.
    How are integrations monitored? Makes failures, stale data and duplicate transactions visible.
    How are rule and price changes tested? Reduces the risk that a release creates invalid configurations or incorrect quotes.

    Semantic map

    The following relationships summarize where manufacturing CPQ fits within quote-to-cash and production-oriented architecture:

    • CPQ configures configurable products.
    • Configuration rules prevent invalid combinations.
    • Constraint-based configuration evaluates technical limits.
    • Guided selling collects customer requirements.
    • Engineering calculations determine product suitability.
    • A configured product can generate a configurable BOM.
    • An EBOM represents an engineering product structure.
    • An MBOM represents a manufacturing product structure.
    • CAD automation can generate product-specific drawings.
    • CPQ calculates cost and selling price.
    • CPQ generates a quotation.
    • CRM provides opportunity and customer context.
    • ERP processes orders, inventory and financial transactions.
    • PLM governs product lifecycle and engineering revisions.
    • MES supports production execution.
    • Quote-to-cash includes CPQ, order processing, fulfillment, invoicing and payment.

    Frequently asked questions

    1. Is CPQ the same as quote-to-cash?

    No. CPQ is a capability focused on configuring products, calculating prices and producing quotes. Quote-to-cash is the broader process from opportunity or quotation through order, fulfillment, invoicing and payment.

    2. Where does CPQ fit in quote-to-cash?

    CPQ usually fits between customer requirements or a sales opportunity and the accepted order. It creates a validated commercial and, where supported, technical definition of the product before order processing.

    3. Does quote-to-cash include manufacturing?

    It can include manufacturing-related order fulfillment, but the term itself does not guarantee product configuration, BOM generation or production planning. Those capabilities usually depend on CPQ, ERP, PLM, MES and other systems.

    4. Can a CRM system replace manufacturing CPQ?

    A CRM system may support simple product selection and quoting, but it may not model engineering constraints, dimensional calculations, configurable BOMs or CAD outputs. The required product complexity should determine whether CRM-only quoting is sufficient.

    5. Does every CPQ system generate a BOM?

    No. Some CPQ systems generate only quote lines or product selections. Others can create configurable BOMs or pass structured configuration data to ERP, PLM or another engineering system. This capability must be verified for the specific platform and product model.

    6. Is a CPQ-generated BOM the same as an MBOM?

    Not necessarily. A CPQ output may be a sales or configurable BOM. An MBOM is structured for manufacturing and may include assembly sequence, operations, work centers and manufacturing-specific items.

    7. Can manufacturing CPQ support engineer-to-order products?

    It can support ETO by collecting requirements, identifying standard content, calculating preliminary prices and routing exceptions to engineering. It does not eliminate the engineering design work required for genuinely new products.

    8. What is the difference between CTO and ETO in CPQ?

    Configure-to-order uses predefined valid options and product rules. Engineer-to-order requires additional design or engineering work after the requirement is understood. A CPQ implementation may support both, but the workflows and outputs differ.

    9. Does CPQ replace ERP?

    No. CPQ generally handles configuration and quoting, while ERP manages areas such as orders, inventory, procurement, production planning, costing, invoicing and financial records. Integration responsibilities must be clearly defined.

    10. Does CPQ replace PLM?

    No. PLM manages product lifecycle information, engineering changes, approvals and released product data. CPQ may use PLM data and return configuration or order information, but the systems serve different purposes.

    11. Does manufacturing CPQ require CAD integration?

    No. CAD integration is valuable when quotes require product-specific models, drawings or design automation, but many CPQ deployments do not include it. CAD capability should be evaluated separately from configuration and pricing.

    12. Can CPQ calculate engineering requirements?

    Some systems provide formulas, selection logic or integrations with calculation services. Others rely on external engineering tools or lookup tables. Buyers should verify supported calculation types, traceability and approval requirements.

    13. What data does manufacturing CPQ need?

    Typical data includes product families, options, dependencies, constraints, dimensions, formulas, components, costs, prices, lead-time assumptions, documents, revisions and integration identifiers. The exact data model depends on the product and workflow.

    14. Who should own CPQ product rules?

    Ownership is usually shared. Product management may own commercial options, engineering may own technical constraints, manufacturing may own production implications, and finance may govern pricing controls. A formal governance model prevents conflicting changes.

    15. How does CPQ improve the sales-to-engineering handoff?

    It captures requirements and selected options in structured data, applies repeatable validation and preserves the configuration used for the quote. This reduces dependence on free-text notes and manual re-entry, although exceptions may still require engineering review.

    16. Can CPQ support dealer and distributor sales?

    Yes, some platforms provide role-specific interfaces, guided selling, price lists, approvals and self-service workflows for dealers. The manufacturer must verify channel pricing, authorization, product visibility and technical configuration capabilities.

    17. Is quote-to-cash only relevant to software companies?

    No. The concept is also relevant to manufacturers. In manufacturing, the quote-to-cash flow may include technical configuration, application engineering, BOM preparation, production, shipment, invoicing and payment rather than subscription billing.

    18. What is the biggest implementation risk?

    A major risk is treating CPQ as a quoting interface while ignoring product data, rule ownership, engineering exceptions and downstream system responsibilities. A successful implementation defines the product model and process architecture together.

    19. Should CPQ or ERP be implemented first?

    There is no universal sequence. The decision depends on product complexity, existing systems, data quality and the business objective. A focused CPQ implementation can expose product-model issues, while ERP readiness may be necessary for reliable costing and order handoff.

    20. How should manufacturers measure CPQ success?

    Useful measures include quote turnaround time, configuration error rates, engineering hours per quote, quote-to-order conversion, margin variance, manual re-entry, exception rates and the completeness of order-ready product data. Metrics should reflect the targeted product family and process.