CPQ Guide

Tag: CPQ architecture

  • Composable CPQ for Manufacturing

    Composable CPQ for manufacturing is an architecture in which configure, price, quote (CPQ) capabilities are delivered as modular services and connected to the wider manufacturing technology stack. Instead of treating CPQ as one isolated application, a composable approach separates product configuration, rules, engineering calculations, pricing, quoting, bill of materials (BOM) generation, computer-aided design (CAD) automation and integration services where appropriate.

    This matters for manufacturers because the information required to produce an accurate quote is rarely owned by one system. Product definitions may be maintained in product lifecycle management (PLM) or product data management (PDM) software, customer and opportunity information may be held in customer relationship management (CRM), costs and item masters may belong to enterprise resource planning (ERP), and drawings or models may be generated by CAD systems. A composable CPQ architecture coordinates these capabilities while preserving data ownership in the systems responsible for it.

    In practical terms, composable CPQ can help a manufacturer configure a valid pump package, calculate a suitable motor and impeller combination, price the resulting assembly, generate a configurable BOM, request a CAD drawing, and send an approved order to ERP. However, not every CPQ platform provides every one of these functions. Buyers must establish which capabilities are native, which are delivered by extensions, and which remain in ERP, PLM, CAD or engineering applications.

    For background, see the broader guide to CPQ software for manufacturing and the guide to CPQ integrations.

    What is composable CPQ?

    Composable CPQ is a modular approach to CPQ in which business capabilities are exposed through reusable applications, services, APIs and data contracts. A manufacturer can combine these components to support a specific workflow rather than adopting one monolithic application for every configuration and engineering task.

    A composable architecture may include the following components:

    • Configuration experience: the user interface used by a salesperson, dealer, engineer, customer or ecommerce buyer.
    • Product model: the representation of products, options, variants, attributes, dependencies and selectable values.
    • Rules engine: logic that validates combinations, derives selections, enforces constraints or determines required actions.
    • Engineering calculation service: formulas or external engineering applications that calculate dimensions, capacity, performance or component selection.
    • Pricing and costing service: logic for list prices, discounts, surcharges, costs, margins, currencies and commercial approvals.
    • BOM service: logic that produces a configurable, engineering or manufacturing bill of materials for the selected product.
    • CAD and visualization service: tools that generate models, drawings, images or product-specific representations when supported.
    • Quote and document service: generation of quotations, specifications, approval records and customer-facing documents.
    • Integration and orchestration layer: APIs, events, middleware and workflow services that exchange data with ERP, CRM, PLM, PDM, CAD, product information management (PIM) and manufacturing execution system (MES) applications.

    These components can be deployed in one product, several products or a mixture of packaged software and custom services. “Composable” describes the architecture and assembly model; it does not guarantee that an implementation will be simple or that every component will be interchangeable.

    Why composable CPQ is relevant to manufacturers

    Generic sales CPQ often focuses on selecting commercial options, applying discounts and producing a quote. Manufacturing CPQ must frequently go further. The configuration may determine engineering feasibility, component dimensions, material requirements, production operations, compliance documentation and the data needed to manufacture the order.

    For example, configuring an industrial air-handling unit may involve airflow, static pressure, cabinet dimensions, insulation, coil selection, fan type, motor power, electrical supply, controls and environmental conditions. A valid configuration may require engineering calculations and may produce different components, drawings and production instructions. The pricing result is only one output of the configuration.

    Composable architecture is useful where a business has already invested in specialized systems or where different product families require different levels of engineering automation. One product line may need a deep CAD automation workflow, while another may only need rules-based option validation and ERP pricing. A modular design can support both without forcing every product family into the same technical model.

    Composable CPQ architecture in the manufacturing stack

    A typical architecture has several layers. The exact boundaries vary by business and software selection, but the following model helps clarify responsibilities.

    Layer Typical responsibility Manufacturing example
    Experience Guides a user through configuration, pricing and quoting Dealer selects a pump duty, materials, motor and accessories
    Configuration Maintains product options, attributes, dependencies and validation Prevents an incompatible motor and voltage combination
    Engineering Calculates or selects technical values and design outputs Calculates pump head, flow, shaft power or heat exchanger size
    Commercial Calculates prices, costs, discounts, margins and approvals Applies material surcharges and customer-specific discount rules
    Output generation Creates BOMs, specifications, drawings and quote documents Produces an order-specific BOM and a dimensioned arrangement drawing
    Enterprise systems Owns customer, item, cost, order, revision and production data ERP receives the approved order and manufacturing item references
    Integration Moves data between services and systems API or event sends configuration, price and revision information to ERP and PLM

    Configuration and product models

    The product model describes what can be sold and how it can be combined. It may include product families, models, features, options, dimensions, materials, accessories, software selections and service levels.

    The model should not be confused with a price list. A product configuration defines a technically and commercially meaningful product instance. Pricing is a separate concern, even though the selected configuration supplies inputs to pricing.

    Manufacturers should also distinguish several types of rules:

    • Rules-based configuration: explicit logic such as “if 480 V is selected, require a compatible motor option.”
    • Constraint-based configuration: a solver or constraint model determines whether a set of values satisfies technical relationships, ranges or dependencies.
    • Guided selling: questions and recommendations help a user reach a suitable product, but guided selling alone does not prove engineering validity.

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

    Engineering and CAD services

    Some manufacturing CPQ implementations include engineering calculations, parametric design automation, 2D drawings, 3D visualization or CAD file generation. Others validate configuration and hand the selected parameters to a separate engineering system.

    For example, a configurable conveyor may use CPQ to capture length, width, belt type, elevation, motor choice and guarding. A calculation service can determine drive requirements, while a CAD system generates a layout and an engineering application creates a product-specific drawing. The CPQ layer should record the inputs, calculation version and output references so that the quote can be traced to a particular engineering result.

    CAD automation is not an automatic consequence of composable CPQ. It requires suitable parametric models, stable interfaces, engineering rules, template governance and a process for handling exceptions. See CAD and engineering automation for CPQ.

    Pricing, costing and quoting

    A pricing service may calculate a selling price from the configured product, customer segment, currency, region, delivery terms, quantity, discount authority and commercial policies. A costing service may calculate material, labor, subcontracting, freight or estimated manufacturing costs.

    These are not necessarily the same as the configuration rules. A material may be technically valid but subject to a surcharge. A custom dimension may be valid but require engineering review. A customer may receive a discount that does not change the product definition but does change the commercial offer.

    Quote documents should identify the configuration, revision, assumptions, exclusions, lead-time basis and approval status. For BOM, pricing and quote architecture, see BOM generation, pricing and quote automation.

    Data ownership in a composable CPQ architecture

    The most important architecture decision is not whether to use APIs. It is deciding which system owns each type of data and how other systems consume it.

    Data domain Possible system of record CPQ relationship
    Customer, account and opportunity CRM CPQ reads customer context and returns configuration, quote and status information
    Product lifecycle, revisions and approved product structures PLM or PDM CPQ consumes released definitions, options, revisions or engineering references
    Item master, inventory, costs, orders and financial data ERP CPQ retrieves item and cost data and sends approved order information
    Product attributes and commercial content PIM or product master CPQ uses descriptions, images, documents and channel-specific content
    Geometry, templates and drawings CAD or engineering system CPQ sends parameters and stores generated-file references
    Production execution and work-center status MES CPQ usually provides order or configuration context rather than replacing execution control
    Configuration session and quote state CPQ CPQ records selected options, rule results, calculated values and commercial outcomes

    There is no universal answer for every domain. Some organizations manage configurable BOM logic in CPQ, while others maintain it in PLM or ERP. The decision should consider revision control, engineering approval, reuse, performance, auditability and the needs of downstream production.

    How a composable CPQ workflow works

    1. Start with commercial or customer context. A salesperson opens a CRM opportunity, or a dealer starts a new configuration. Customer, location, currency and channel data are passed to CPQ.
    2. Load the relevant product model. CPQ retrieves the applicable product family, market rules, effective date and product revision.
    3. Capture requirements. The user enters technical requirements such as flow, pressure, capacity, dimensions, temperature, material, voltage or environmental conditions.
    4. Validate and derive selections. Rules prevent invalid combinations, while calculations or selection services determine compatible components.
    5. Request engineering outputs when needed. CPQ may call a calculation engine, CAD automation service or engineering workflow. If the configuration exceeds supported rules, it can create an engineering review task.
    6. Generate commercial results. Pricing and costing services calculate price, margin, lead-time assumptions and approval requirements.
    7. Generate manufacturing-related outputs. Depending on the architecture, the system creates a configurable BOM, an engineering BOM (EBOM), a manufacturing BOM (MBOM), drawings, specifications or references to these outputs.
    8. Produce and approve the quote. The customer-facing quote includes the selected configuration and relevant assumptions. Internal approvals are recorded before release.
    9. Transfer the approved result. CPQ sends an order, configured item, BOM reference, document reference or configuration payload to ERP, PLM, PDM or another downstream system.
    10. Retain traceability. The business should be able to identify which product model, rule version, price version and engineering output produced the quote.

    This workflow can support configure-to-order (CTO), assemble-to-order (ATO), make-to-order (MTO) and engineer-to-order (ETO), but the level of automation differs. CTO uses predefined configurations. ATO assembles stocked or semi-finished components. MTO produces a product after the order, often using established designs. ETO creates or modifies engineering outputs for the specific order and normally requires stronger engineering workflow integration.

    The differences between these operating models are discussed in manufacturing CPQ workflows.

    Configurable BOMs, EBOMs and MBOMs

    A BOM is a structured list of components and quantities required for a product or assembly. A configurable BOM represents possible components and selection conditions. An EBOM is an engineering bill of materials organized around design intent. An MBOM is a manufacturing bill of materials organized around how the product is assembled or produced.

    Composable CPQ may generate a configured BOM directly, select an approved BOM variant, or send configuration parameters to PLM or ERP for BOM resolution. These approaches have different governance implications.

    Approach Potential use Important question
    CPQ resolves configured components Fast CTO or ATO quoting with established options How are revisions and production changes synchronized?
    PLM resolves the EBOM Engineering-controlled products with formal lifecycle management Can CPQ consume only released and valid structures?
    ERP resolves the production BOM Organizations where ERP owns item and manufacturing structures Can the order retain the original configuration and rule version?
    CPQ sends parameters to an engineering workflow ETO or calculation-driven products How are exceptions, approvals and design changes tracked?

    A common implementation error is treating any list of selected options as a production-ready MBOM. A commercial configuration may omit phantom assemblies, operation sequences, alternate materials, scrap factors, work instructions or plant-specific manufacturing data. The receiving system must confirm whether the output is suitable for production or only for quotation and engineering review.

    Integration patterns for composable CPQ

    Synchronous APIs

    A synchronous API request returns a result during the configuration session. It is suitable for retrieving item attributes, validating a selection, calculating a price or checking a technical value when the response is expected quickly.

    For example, CPQ may send pump flow, head, fluid and temperature to a selection service and receive compatible pump models. Timeouts, error handling and fallback behavior are important because a slow or unavailable service can interrupt quoting.

    Asynchronous events and workflows

    Asynchronous integration is useful when an operation takes longer or requires human review. CAD generation, ETO engineering, supplier checks and formal approval can produce events such as “drawing generated,” “engineering review completed” or “quote approved.”

    Event-based designs require reliable message handling, correlation identifiers, retries, duplicate protection and clear ownership of status. A quote should not appear technically approved simply because an integration request was sent.

    Batch and scheduled synchronization

    Some data does not need real-time exchange. Product descriptions, price books, released items, costs and document metadata may be synchronized on a schedule. Batch synchronization can reduce integration complexity but introduces timing and effective-date risks.

    Headless configuration services

    A headless configuration service separates configuration logic from the user interface. The same product model can support a salesperson application, dealer portal, ecommerce front end or internal engineering tool. This approach is useful when several channels need consistent rules, but it requires a stable API and careful control of channel-specific behavior.

    Benefits and limitations

    Potential benefits

    • Reuse of existing systems: the business can retain specialized ERP, PLM, CAD or engineering applications rather than replacing every system.
    • Channel consistency: shared configuration services can apply the same product rules across sales, dealers and digital channels.
    • Incremental delivery: a manufacturer can begin with configuration and pricing, then add BOM, engineering or CAD services where the business case is clear.
    • Clearer ownership: explicit boundaries can reduce duplicate product, cost and revision data.
    • Product-family flexibility: different product lines can use different engineering depth while sharing commercial and integration services.
    • Better traceability: versioned services and data references can make it easier to understand how a quote was produced.

    Limitations and risks

    • Integration becomes a product of its own: multiple services require monitoring, version management, security, testing and operational support.
    • Data semantics may conflict: an “option,” “variant,” “item,” “assembly” or “revision” may mean different things in CPQ, ERP and PLM.
    • Distributed failures are harder to diagnose: a quote may depend on several services with different availability and response times.
    • Rule duplication can grow: copying the same compatibility logic into CPQ, ERP, PLM and CAD creates inconsistent behavior.
    • Transaction boundaries are complex: a quote, drawing and order may not be committed at the same time.
    • Composable does not mean low-code: sophisticated configuration and engineering models still require domain expertise, testing and governance.
    • Vendor boundaries may be unclear: a platform may advertise extensibility or APIs without providing the manufacturing capabilities needed for BOM, CAD or engineering automation.

    Implementation considerations

    Define the target workflow before selecting components

    Start with a specific product family and workflow. Document the inputs, rules, calculations, outputs, approvals and systems involved. A pump manufacturer might map the flow from duty-point entry through pump selection, motor validation, material selection, costing, drawing generation and ERP order creation.

    Assign ownership for every important data object

    Create a data ownership matrix for product options, rules, revisions, item numbers, costs, prices, BOM structures, CAD templates, documents and customer data. Identify who can change each object, how changes are approved and how effective dates are applied.

    Separate rules by purpose

    Keep commercial rules, technical constraints, engineering formulas and manufacturing transformations distinguishable. A rule that blocks a combination is not the same as a formula that calculates a dimension, and neither is the same as a discount condition.

    Version models and outputs

    Configuration results should identify the product model version, rule version, price book, calculation version and relevant engineering revision. Without this information, reproducing an old quote or explaining a changed result becomes difficult.

    Design for exceptions

    Not every product can be fully automated. The architecture should support engineering review, manual adjustments, substitutions, customer-specific requirements and incomplete data without silently creating an invalid result. An ETO request should have a visible status and a defined handoff rather than appearing as a normal CTO configuration.

    Test the complete chain

    Testing must cover more than the CPQ user interface. Use representative combinations and test configuration validation, calculations, prices, BOM resolution, CAD outputs, document generation, API failures, revisions, permissions and downstream order creation. Regression tests are particularly important when a shared product model supports several channels.

    Implementation planning, governance and testing are covered in the CPQ implementation guide.

    How to evaluate composable CPQ software

    Manufacturers should evaluate the architecture against actual product and workflow requirements rather than counting generic features. Important questions include:

    • Can the platform represent product families, variants, dimensions, ranges, dependencies and conditional options?
    • Does it support rules-based configuration, constraint solving, guided selling, or only simple option selection?
    • Can rules and product models be versioned, tested and maintained by appropriate business or engineering users?
    • Can it expose configuration, validation, pricing and quote functions through documented APIs?
    • Does it generate a BOM, select a BOM, or pass parameters to another BOM-owning system?
    • Can it distinguish commercial configuration from EBOM and MBOM requirements?
    • Does it support engineering calculations, CAD automation or 3D visualization natively, through extensions, or not at all?
    • How are ERP, CRM, PLM, PDM, CAD, PIM and MES integrations implemented and monitored?
    • Can it support dealer, distributor, ecommerce and internal engineering channels with consistent logic?
    • How are ETO exceptions, approvals, manual engineering work and document revisions handled?
    • What happens when an external system is unavailable during configuration or order submission?
    • Can the organization export its product model, rules, configuration history and outputs if the architecture changes?

    Vendor claims should be verified through documentation, demonstrations using the manufacturer’s own product examples, API specifications, implementation references where available and a proof of concept. Do not assume that an API or modular architecture includes manufacturing-grade configuration, BOM, CAD or engineering behavior.

    Semantic map

    The following relationships summarize the main entities and how they interact in a composable manufacturing CPQ architecture.

    • CPQ connects product configuration with pricing, quoting and downstream manufacturing data.
    • Product models define selectable features, options, attributes and variants.
    • Configuration rules prevent invalid product combinations.
    • Constraint-based configuration evaluates technical relationships and limits.
    • Engineering calculations transform customer requirements into technical selections or values.
    • Configured products provide inputs to pricing and costing services.
    • Configured products can generate or select configurable BOM structures.
    • EBOM represents engineering design intent.
    • MBOM represents manufacturing assembly and production structure.
    • CAD automation generates product-specific models or drawings when supported.
    • CRM provides customer and opportunity context to CPQ.
    • ERP owns or consumes item, cost, order and financial data.
    • PLM or PDM governs product revisions and released engineering data.
    • MES executes or monitors production activities after order release.
    • APIs and events exchange configuration and engineering data between systems.
    • ETO workflows route unsupported configurations to engineering review.

    Frequently asked questions

    What is composable CPQ for manufacturing?

    It is a modular CPQ architecture that combines configuration, rules, engineering, pricing, quoting and manufacturing data services with systems such as ERP, PLM, CRM, CAD and MES.

    How is composable CPQ different from generic sales CPQ?

    Generic sales CPQ may focus on options, discounts and quote documents. Manufacturing composable CPQ also considers technical constraints, engineering calculations, BOMs, CAD outputs, revisions and production handoffs where those capabilities are required.

    Does composable CPQ replace ERP?

    Usually not. ERP commonly remains responsible for items, inventory, costs, orders, financial processing and manufacturing-related master data. CPQ supplies a validated commercial and technical configuration to ERP.

    Does composable CPQ replace PLM?

    Usually not. PLM often manages product lifecycle, engineering revisions and released product structures. CPQ may consume PLM data or manage a commercial configuration model linked to PLM references.

    Can composable CPQ generate a manufacturing BOM?

    It can in some implementations, but this is not universal. The BOM may instead be resolved in ERP or PLM. Buyers should verify whether the output is a configurable BOM, EBOM, MBOM or only a list of quoted options.

    What is the role of CAD in composable CPQ?

    CAD can receive configuration parameters and generate product-specific models, drawings or layouts. This requires compatible parametric models, automation interfaces and engineering governance; it is not guaranteed by a CPQ platform.

    Can composable CPQ support engineer-to-order products?

    Yes, when it includes or integrates with engineering workflow, calculation, CAD, approval and document processes. ETO should be treated as a controlled exception or design workflow rather than as simple option selection.

    Is a headless CPQ the same as composable CPQ?

    No. Headless CPQ separates the configuration service from its user interface. Composable CPQ is a broader architectural approach that may include headless services, modular applications, APIs and external engineering or enterprise systems.

    What systems commonly integrate with composable CPQ?

    Common systems include CRM, ERP, PLM, PDM, CAD, PIM, MES, ecommerce platforms, calculation services, document systems and integration middleware. The exact integration depends on the manufacturer’s workflow.

    Where should product rules be maintained?

    Rules should be maintained by the system best suited to their purpose and governance. Configuration rules may reside in CPQ, lifecycle-controlled engineering rules may reside in PLM or an engineering service, and manufacturing transformations may belong in ERP or manufacturing applications.

    How does composable CPQ handle pricing?

    It uses the configured product and commercial context as inputs to price books, cost data, discounts, surcharges, currencies, margins and approval policies. Pricing logic should remain distinguishable from technical configuration rules.

    Can one composable CPQ model serve dealers and internal engineers?

    It can when the platform provides reusable configuration services and role-specific interfaces. The dealer may see guided questions and prices, while an engineer may see calculated values, rule diagnostics and design outputs.

    What happens when an external integration fails?

    The system should provide explicit error states, retries where appropriate, monitoring and a controlled fallback or review process. It should not silently issue a technically incomplete quote or order.

    How does composable CPQ support configure-to-order?

    It validates a predefined product model, selects compatible options, calculates price and produces the required order or BOM data. The amount of downstream automation depends on ERP, PLM and production integration.

    How does composable CPQ support make-to-order?

    It captures the customer-specific requirements and creates a valid order configuration, while ERP or engineering systems determine procurement, production and delivery details.

    What is the main implementation risk?

    A major risk is unclear ownership or duplicated logic across CPQ, ERP, PLM, CAD and engineering services. This can produce conflicting rules, incorrect revisions, unreliable BOMs and difficult troubleshooting.

    How should a manufacturer start a composable CPQ project?

    Start with one representative product family and map the complete workflow from requirements through quote, engineering output and order release. Define data ownership, interfaces, exception handling and measurable acceptance criteria before expanding.

    How should composable CPQ vendors be evaluated?

    Evaluate product-model depth, rules, APIs, versioning, BOM behavior, pricing, engineering and CAD integration, ERP and PLM connectivity, exception workflows, governance, security, testing and implementation effort using real manufacturing examples.

  • Solution Configuration vs Single-Product Configuration in Manufacturing CPQ

    Solution configuration configures a complete system made from multiple products, assemblies or services, while single-product configuration configures one product model or product family at a time. In manufacturing CPQ, the difference is not simply the number of items in a quote. It determines where rules are stored, how compatibility is validated, how prices and costs are calculated, and whether the output is one product record or a coordinated solution with multiple bills of material (BOMs).

    For example, configuring one centrifugal pump with a selected motor, seal and material options is single-product configuration. Configuring a complete pumping skid with several pumps, a base frame, valves, sensors, control panels, piping and installation requirements is solution configuration. The skid may contain several independently configurable products, but the system must also validate relationships between them.

    A manufacturing CPQ system may support one or both approaches. Buyers should verify the actual capabilities of each platform rather than assume that a product configurator automatically supports multi-product system design, engineering calculations, configurable BOMs or computer-aided design (CAD) automation.

    What is single-product configuration?

    Single-product configuration is the process of selecting valid options and parameters for one configurable product, product family or engineered assembly. The configuration model normally contains the product structure, available options, dependencies, constraints, calculations and outputs for that product.

    In manufacturing, a single product can still be technically complex. A configurable industrial pump may require decisions about flow rate, head, impeller diameter, casing material, motor power, voltage, seal type, connection size and environmental conditions. The configurator must determine whether those selections are compatible and may calculate a product-specific price, cost, BOM or drawing.

    Typical single-product model

    • Features and options: such as motor voltage, frame material or connection type.
    • Dependencies: for example, a high-temperature seal is available only with certain casing materials.
    • Constraints: such as a motor size that cannot be used with a particular pump frame.
    • Calculations: such as power requirements, capacity, weight or dimensional values.
    • Outputs: such as a configured item number, price, product-specific BOM or CAD parameters.

    This model is often appropriate for standard or configurable-to-order products where the main engineering problem is selecting options within one product family. It can support configure-to-order (CTO), make-to-order (MTO) or, in some cases, engineer-to-order (ETO) workflows depending on how much design work remains after configuration.

    What is solution configuration?

    Solution configuration is the process of selecting and coordinating multiple products, subsystems, assemblies and services so that the complete combination satisfies technical, commercial and operational requirements.

    A solution may include products from different product families. A material-handling system, for example, may contain conveyors, transfer stations, motors, drives, guarding, sensors, control cabinets and software. Each item may have its own configuration rules, but the solution also requires cross-product rules.

    Examples of cross-product rules include:

    • a selected conveyor width must match the transfer station opening;
    • the motor and variable-frequency drive must support the required load and voltage;
    • the control panel must have enough inputs and outputs for the selected sensors;
    • the pump, valve and pipe materials must be compatible with the process fluid;
    • the selected vehicle body must fit the chassis wheelbase and payload rating;
    • the total electrical load must remain within the selected power-supply capacity;
    • the system must meet site, safety, environmental or regulatory requirements.

    Solution configuration therefore combines product configuration with system architecture, compatibility management and sometimes engineering design. It is especially relevant to industrial machinery, HVAC systems, electrical equipment, automation cells, specialty vehicles, energy systems and engineered skids.

    Key differences between the two approaches

    Criterion Single-product configuration Solution configuration
    Scope One product model or family Multiple products, assemblies, systems or services
    Rules Rules mainly govern options within one product Rules govern both local options and relationships between products
    Example Configuring a pump Configuring a complete pumping station
    Primary output Configured product, item number, price and possibly BOM Coordinated solution structure, multiple outputs and system-level price
    Engineering Product-specific calculations or parameter selection System sizing, interface validation, layout and integration engineering
    BOM Usually one configurable BOM or product assembly Several product BOMs plus a solution-level structure
    Quoting One product line or related option lines Multi-line commercial offer with packages, services and exclusions
    Risk Invalid option combinations Invalid interfaces, incomplete scope or incompatible subsystems

    How product models differ

    A single-product model usually starts with a product family and its option structure. The model may represent a base pump, valve, enclosure, vehicle or machine. Rules are attached to features, options, attributes and variant parts.

    A solution model adds a higher-level structure. It may contain:

    1. a solution template, such as a water-treatment skid or packaging line;
    2. required and optional subsystems;
    3. one or more product models for each subsystem;
    4. interface definitions between subsystems;
    5. system-level calculations and capacity limits;
    6. commercial rules for packages, services, freight and installation;
    7. outputs that connect the solution to engineering, production and service systems.

    The distinction between a product model and a solution model is important for governance. A pump product manager may own pump options and pump rules. A systems engineering team may own rules about pump-to-pipe, pump-to-motor or pump-to-control-panel compatibility. If these responsibilities are not defined, changes can create contradictory rules or duplicate logic.

    Rules and constraints in single-product configuration

    Single-product configuration generally relies on rules within a bounded product domain. Common rules include:

    • Option compatibility: option A requires or excludes option B.
    • Value ranges: a dimension or capacity must remain within defined limits.
    • Conditional availability: an option appears only when a prior choice makes it relevant.
    • Technical calculations: a motor or frame is selected based on load, speed or capacity.
    • Variant mapping: a configuration maps to a stock keeping unit, material number or manufacturing variant.

    These rules can be implemented as rules-based configuration, constraint-based configuration or a combination. Rules-based configuration commonly expresses explicit conditions such as if-then relationships. Constraint-based configuration evaluates permitted combinations against limits, relationships and requirements. Guided selling helps a user reach a suitable configuration through questions, but it is not necessarily the same as a complete engineering constraint solver.

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

    Rules and constraints in solution configuration

    Solution configuration requires all of the rules used by single-product configuration plus rules that cross product boundaries. These cross-product constraints often represent engineering interfaces rather than simple option dependencies.

    Common cross-product rule types

    • Dimensional interfaces: a selected pipe diameter must match a valve connection or machine inlet.
    • Capacity relationships: the cooling unit must handle the heat load produced by the selected equipment.
    • Electrical relationships: motors, drives, transformers and panels must use compatible voltage, current and protection ratings.
    • Performance relationships: a pump curve, fan capacity or conveyor speed must satisfy the system requirement.
    • Spatial relationships: equipment must fit within a defined footprint or vehicle body.
    • Regulatory relationships: selected components may need to meet a common certification or safety category.
    • Commercial relationships: installation, commissioning or service packages may be required for a particular system.

    In a mature architecture, these rules should be explicit and testable. Storing them informally in sales notes, spreadsheets or individual employee knowledge makes the solution model difficult to maintain and increases the risk of invalid quotes.

    Manufacturing examples

    Example 1: Industrial pump

    Single-product configuration begins with the required flow and pressure. The model selects pump size, impeller, casing, seal, motor and connection standard. It may generate a configured BOM and a price.

    Solution configuration begins when the customer is buying a complete pumping package. The model must coordinate several pumps, a skid frame, valves, strainers, instrumentation, a control panel and piping. It must check duty and standby arrangements, pipe interfaces, motor voltage, control-panel capacity and the physical arrangement of the skid. The quote may also include testing, documentation and installation.

    Example 2: HVAC system

    A single air-handling unit can be configured by selecting airflow, casing, filters, coils, fans and controls. A complete HVAC solution adds chillers, pumps, duct interfaces, controls, electrical equipment and site-specific requirements. The solution model must verify capacity and compatibility across the system, not merely validate each unit independently.

    Example 3: Specialty vehicle

    A single-product model may configure a truck body using body length, material, compartments, doors, lifting equipment and lighting. A solution model may combine a chassis, body, hydraulic system, power take-off, control system and customer-specific accessories. Payload, axle loads, center of gravity, electrical load and mounting interfaces become system-level constraints.

    Pricing, costing and quoting implications

    Configuration determines what can be sold, but it does not automatically determine how the solution should be priced. Pricing and quoting are related capabilities that may use configuration results as inputs.

    For single-product configuration, pricing may be based on a base model plus option prices, dimensions, materials, labor assumptions or calculated costs. For solution configuration, pricing may require:

    • prices for each configured product and assembly;
    • system-level discounts or package rules;
    • engineering, installation, commissioning and documentation services;
    • freight, site work and project-specific commercial terms;
    • currency, tax, dealer and regional pricing;
    • risk allowances or approval thresholds for non-standard work.

    A solution quote should make scope visible. It should distinguish included equipment from optional items, customer responsibilities, exclusions and engineering assumptions. A generic sales CPQ tool may produce a commercial quote but may not maintain the engineering structure or manufacturing data needed for a complex solution.

    See the guide to BOM generation, pricing and quoting for the relationship between configuration outputs and commercial documents.

    BOM and engineering outputs

    A bill of material (BOM) is a structured list of components required to make or deliver a product. In manufacturing, an engineering BOM (EBOM) represents the design view, while a manufacturing BOM (MBOM) represents how the product is assembled or produced. A configurable BOM contains rules or variant logic that determines which components are included for a particular configuration.

    Single-product configuration may produce one configurable product structure. Solution configuration may produce:

    • a solution-level structure containing several configured products;
    • an EBOM for system design;
    • separate product or subsystem BOMs;
    • an MBOM or production structure after manufacturing transformation;
    • installation, spare-parts or service lists.

    These outputs are not interchangeable. A CPQ platform may generate a quote line structure without generating an EBOM or MBOM. It may also pass selected parameters to an enterprise resource planning (ERP) system without owning the authoritative engineering structure. Integration design must define which system owns each output.

    CAD, visualization and engineering calculations

    Single-product configuration can pass parameters to a parametric CAD model, such as length, hole pattern, mounting position or material thickness. The CAD system may then generate a product-specific model or drawing.

    Solution configuration adds layout and interface questions. A system may need to position multiple products, route pipes or cables, check clearances and produce an arrangement drawing. Some platforms support these functions through CAD or design-automation integrations; others stop at selections, pricing and document generation.

    Three-dimensional visualization can help users understand a configured product or solution, but visual appearance is not proof of engineering validity. A 3D view may not validate pressure ratings, electrical load, structural strength, thermal performance or manufacturing feasibility. Engineering calculations and authoritative CAD or product lifecycle management (PLM) data may still be required.

    Review the guide to CAD and engineering automation in CPQ when evaluating these requirements.

    Where each approach fits in manufacturing workflows

    Workflow Single-product fit Solution-configuration fit
    Configure-to-order (CTO) Strong fit when one product has defined variants Useful for standard systems assembled from validated modules
    Make-to-order (MTO) Useful when options drive production without a new design Useful when several MTO products must be coordinated
    Engineer-to-order (ETO) May capture requirements before engineering Useful as a system-level specification and engineering handoff
    Assemble-to-order (ATO) Useful for selecting stocked modules Useful when modules must be combined under interface rules

    In an ETO process, solution configuration should not be presented as a substitute for engineering review. It can capture requirements, select known modules, identify non-standard conditions and create a structured handoff. The engineering team may still need to design new components, approve calculations and release final production data.

    The manufacturing workflows guide explains how configuration connects sales, engineering and production.

    System architecture and integrations

    A typical architecture separates responsibilities across several systems:

    • CPQ: manages configuration interaction, rules, pricing inputs and quote generation.
    • Customer relationship management (CRM): manages accounts, opportunities and sales activities.
    • ERP: manages items, orders, inventory, purchasing, production and financial transactions.
    • PLM: manages product structures, revisions, requirements and lifecycle control.
    • Product data management (PDM): manages engineering files and CAD-related product data.
    • CAD: creates geometry, drawings and design outputs.
    • Product information management (PIM): manages commercial product information and content for channels.
    • Manufacturing execution system (MES): manages production execution and shop-floor information.

    For single-product configuration, the main integration may be between CPQ, ERP and CAD or PLM. For solution configuration, integration must also preserve relationships between subsystems, revisions, quantities, interfaces and project-specific outputs. APIs and event-based integration may be needed when configuration changes must update pricing, engineering structures and order data without manual re-entry.

    More integration considerations are covered in the CPQ integration guide.

    Benefits and limitations

    Benefits of single-product configuration

    • More focused product models and ownership.
    • Faster validation for bounded option sets.
    • Simpler testing and release management.
    • Clearer mapping to product numbers, prices and BOM variants.
    • Good support for repeatable CTO and MTO products.

    Benefits of solution configuration

    • Validates the complete system instead of isolated products.
    • Reduces manual coordination between sales and application engineering.
    • Improves completeness of multi-product quotes and proposals.
    • Creates a structured starting point for engineering and project execution.
    • Supports modular systems, packages and repeatable solution architectures.

    Limitations and risks

    • Solution models are more difficult to design, test and govern.
    • Cross-product rules can become duplicated or contradictory.
    • Engineering calculations may exceed the capabilities of a commercial configurator.
    • Incomplete master data can make technically valid configurations impossible to manufacture.
    • Large product models can create slow user experiences and difficult change management.
    • Automatic BOM or CAD output may require specialized integrations rather than standard CPQ features.
    • Complex ETO work still requires engineering judgment and formal approval.

    How to choose the right configuration approach

    Use single-product configuration when the customer is selecting a defined product family and the important rules remain inside that family. Use solution configuration when the value proposition, technical validity or commercial scope depends on relationships between multiple products or subsystems.

    Many manufacturers need a layered approach rather than an either-or decision:

    1. model each product family independently;
    2. reuse those models within solution templates;
    3. add cross-product interface rules at the solution level;
    4. apply system-level calculations and commercial rules;
    5. generate the appropriate quote, BOM, CAD and engineering handoff outputs.

    This architecture avoids rebuilding every product rule inside every solution. It also makes ownership clearer: product teams maintain local rules, while systems or application engineering teams maintain interface rules.

    Implementation and governance considerations

    Start with a product and solution inventory. Identify which offerings are true single products, which are packages of existing products and which require new system engineering for every order. Document the input parameters, constraints, calculations, outputs and responsible owners for each category.

    Important implementation activities include:

    • defining a common vocabulary for features, options, interfaces, constraints and requirements;
    • separating product rules from pricing rules and document rules;
    • identifying the system of record for product structures and revisions;
    • establishing ownership for local product rules and cross-product rules;
    • testing valid, invalid, boundary and changed configurations;
    • versioning rules alongside product and engineering revisions;
    • testing ERP, PLM, PDM, CAD and CRM data exchanges;
    • measuring quote completeness, configuration errors, engineering rework and maintenance effort;
    • defining an approval path for non-standard or ETO configurations.

    Do not begin with an attempt to model every possible solution. A controlled pilot around one product family or repeatable solution type usually exposes data, ownership and integration problems earlier. The CPQ implementation guide provides a broader framework for requirements, testing, governance and maintenance.

    Semantic map

    The following relationships summarize the main entities and concepts in this article:

    • Single-product configuration → configures → one product family or engineered assembly
    • Solution configuration → coordinates → multiple configurable products
    • Configuration rules → prevent → invalid option combinations
    • Cross-product constraints → validate → subsystem interfaces
    • Product model → defines → features, options, parameters and outputs
    • Solution model → contains → product models and system-level rules
    • Configured product → can generate → product-specific BOM data
    • Solution configuration → can generate → a coordinated solution structure
    • CPQ → calculates or applies → configuration-dependent prices
    • CPQ → exchanges data with → ERP
    • CPQ → can pass parameters to → CAD automation
    • CAD automation → generates → product-specific drawings or models
    • EBOM → represents → the engineering product structure
    • MBOM → represents → the manufacturing assembly structure
    • ETO workflow → requires → engineering review for non-standard design
    • Solution configuration → supports → system-level quoting and engineering handoff

    Frequently asked questions

    What is the main difference between solution configuration and single-product configuration?

    Single-product configuration validates one product model. Solution configuration validates multiple products and the relationships between them, such as dimensional, electrical, performance and commercial interfaces.

    Is a product configurator the same as a solution configurator?

    No. A product configurator may handle one product family, while a solution configurator coordinates several product models and system-level constraints. Some CPQ platforms support both, but this must be verified.

    Can single-product configuration support complex industrial equipment?

    Yes. A single industrial machine may require extensive option rules, calculations, pricing logic and BOM generation even when it is modeled as one product.

    When does a product become a solution?

    It becomes a solution when the commercial or technical result depends on multiple products, subsystems, services or interfaces rather than on options within one product family.

    Does solution configuration always require CAD automation?

    No. CAD automation is useful when configuration must create geometry or drawings, but solution configuration can also stop at validated selections, pricing and structured engineering requirements.

    Can a CPQ system generate a solution BOM?

    Some manufacturing CPQ systems can generate configurable BOMs or solution structures, while others only create quote lines or pass selections to ERP and PLM. Buyers should verify the exact output and ownership model.

    What is a cross-product constraint?

    A cross-product constraint is a rule relating separate products or subsystems, such as requiring a selected motor, drive and control panel to use compatible voltage and load ratings.

    How does solution configuration affect pricing?

    It adds system-level pricing considerations such as package discounts, installation, commissioning, freight, engineering services and project-specific commercial assumptions.

    Is guided selling sufficient for solution configuration?

    Guided selling can help users answer requirements questions, but it does not necessarily validate engineering constraints or generate manufacturing-ready outputs.

    What is the role of ERP in solution configuration?

    ERP usually manages items, orders, inventory, purchasing, production and financial transactions. It may receive configured products, quantities, prices or BOM data from CPQ.

    What is the role of PLM in solution configuration?

    Product lifecycle management, or PLM, may manage product structures, revisions, requirements and engineering lifecycle data. It can be the authoritative source for product and engineering information.

    How do EBOM and MBOM differ in a configured solution?

    An engineering BOM describes the design structure, while a manufacturing BOM describes how the product is built. A solution may require both, along with a mapping between them.

    Can solution configuration support engineer-to-order projects?

    Yes, it can capture requirements, select reusable modules and identify non-standard conditions. However, new design work, calculations and approvals may still require engineering.

    Should product and solution rules be stored together?

    Usually, local product rules should remain with their product models, while cross-product interface rules should be maintained at the solution level. This reduces duplication and clarifies ownership.

    How should solution configuration be tested?

    Test valid combinations, invalid combinations, boundary values, interface mismatches, revision changes, pricing results, BOM outputs and integrations with ERP, PLM, CAD and related systems.

    What is the best starting point for implementing solution configuration?

    Start with one repeatable solution type, document its product models and interfaces, establish rule ownership, and test the complete flow from requirements through quote and engineering handoff.

  • Manufacturing CPQ Architecture: A High-Level Overview

    Manufacturing CPQ architecture is the structure of product data, configuration rules, engineering logic, pricing services, documents, integrations and workflows that turns a customer’s requirements into a valid, priced and manufacturable product definition. CPQ means Configure, Price, Quote. In manufacturing, however, CPQ usually goes beyond selecting options and calculating a sales price. It may also validate engineering constraints, calculate dimensions or performance, generate a configurable bill of materials, create product-specific drawings and pass approved order data to enterprise systems.

    A useful manufacturing CPQ architecture connects commercial and technical decisions without treating them as the same thing. Product configuration determines what can be built. Engineering logic determines whether the selected design satisfies technical requirements. Pricing and costing determine the commercial result. Quoting presents that result to the customer. Enterprise integrations move approved data into systems such as ERP, CRM, PLM, PDM, CAD and MES.

    The exact architecture depends on the product and platform. Not every CPQ application supports CAD automation, engineering calculations, BOM generation, 3D visualization or direct production integration. These capabilities must be evaluated separately during software selection and solution design. The core concepts are described in the guide to manufacturing CPQ.

    What is manufacturing CPQ architecture?

    Manufacturing CPQ architecture is a layered arrangement of product models, rules, calculations, user interfaces, commercial logic, document services and system integrations used to configure and sell complex products.

    For example, a pump manufacturer may need to capture flow rate, pressure, fluid type, temperature, materials, motor rating, seal type, connection standard and certification requirements. The CPQ system can use those inputs to recommend a product family, reject incompatible combinations, calculate a suitable pump configuration, determine a price and create a quotation. Depending on the implementation, it may also create an engineering bill of materials, request a CAD model or drawing, and send an order-ready structure to the ERP system.

    This is different from generic sales CPQ, where the primary objective may be to select products, apply discounts and produce a proposal. Manufacturing CPQ must often preserve technical intent and downstream product data. The architecture therefore has to support product engineering, manufacturing operations and commercial processes together.

    Core layers of a manufacturing CPQ architecture

    A CPQ implementation is easier to understand when separated into logical layers. These layers may be delivered by one platform or distributed across several applications.

    Layer Primary responsibility Typical manufacturing output
    Experience and channel Collect requirements and present configuration choices Sales application, dealer portal, ecommerce or customer self-service experience
    Product model Represent families, options, attributes, variants and dependencies Structured definition of a configurable machine or assembly
    Rules and constraints Control valid combinations and mandatory selections Configuration validation and guided decisions
    Engineering services Perform calculations, sizing and technical validation Motor selection, heat-load calculation, pressure rating or dimensional result
    Commercial services Calculate cost, price, discount, margin and approvals Customer price and commercial approval status
    Output generation Create quotes, BOMs, drawings and order data Proposal, EBOM, configurable BOM or CAD request
    Integration and orchestration Exchange data with enterprise applications ERP order, CRM opportunity update or PLM item reference
    Governance and operations Control versions, permissions, testing and releases Auditable product rules and maintainable product models

    1. User experience and configuration channels

    The front end is the channel through which requirements are collected and configuration decisions are made. It may be an internal application for sales engineers, a dealer portal, an ecommerce configurator or an embedded interface using application programming interfaces, commonly called APIs.

    A manufacturing interface should expose only decisions that are meaningful for the user. A technical sales engineer may need detailed dimensions and performance inputs, while a dealer may need a guided sequence of application questions. A customer configuring an industrial enclosure online may see voltage, size, material and accessory choices rather than internal part numbers.

    Visual or three-dimensional configuration can improve understanding for products such as vehicles, material-handling equipment, modular machinery and electrical cabinets. Visualization is useful, but it is not the same as rule validation or engineering automation. A realistic image does not prove that the selected product is technically valid.

    2. Product model and configuration data

    The product model is the structured representation of what a company sells and how it can vary. It commonly contains product families, features, options, attributes, components, relationships, revisions and output mappings.

    For an air-handling unit, the model might include airflow range, casing size, fan type, filter class, coil arrangement, insulation, controls and access orientation. Each option can have attributes such as cost, weight, lead time, material, supplier reference or manufacturing status.

    The model should distinguish between a commercial option and a physical component. A customer may select a high-efficiency motor, while the downstream result must identify a motor family, mounting arrangement, electrical interface and possibly several related fasteners. That mapping is one reason product configuration is closely connected to BOM management.

    Product models also need ownership and version control. Engineering may own technical attributes, product management may own marketable options, finance may own pricing inputs and manufacturing may own assembly or routing consequences. Without clear ownership, the model becomes a collection of duplicated spreadsheets and undocumented exceptions. Guidance on models, options and dependencies is available in the product configuration guide.

    3. Rules, constraints and guided selling

    Rules determine how the system responds to configuration inputs. Three related approaches should be distinguished.

    • Rules-based configuration: explicit logic such as if a stainless-steel wetted part is selected, require compatible seals.
    • Constraint-based configuration: a set of restrictions and relationships that the engine evaluates to find or reject valid combinations, such as a frame size that must support a calculated torque.
    • Guided selling: a question-driven experience that recommends products or options based on application needs. Guided selling may simplify the user experience but does not automatically provide complete engineering validation.

    Rules can be exclusion rules, required-option rules, default rules, compatibility rules, range checks or calculation rules. For example, a valve configurator may prevent a pressure class from being selected when the chosen body material and temperature exceed the material’s documented limit. An electrical equipment configurator may require an enclosure rating and cable-entry solution when a particular installation environment is selected.

    Rules should be traceable and testable. A single large script is difficult to maintain because it hides product policy, engineering constraints and commercial exceptions in the same place. More maintainable architectures separate reusable rules, calculation services, product data and approval policies.

    4. Engineering calculations and technical validation

    Engineering services convert customer or application inputs into technical results. They may calculate dimensions, capacity, power, thermal performance, pressure drop, structural requirements, speed, flow or material suitability.

    Consider a conveyor configuration. The user enters load, length, incline, speed and operating environment. An engineering calculation may determine motor torque, gearbox ratio, belt specification and frame requirements. The result can then influence the valid product options, the price and the manufacturing structure.

    Calculations may be embedded in the CPQ platform, implemented as an external service or executed through an engineering application. The architecture should define which system is authoritative, how inputs and units are handled, how calculation versions are controlled and how results are stored for audit purposes.

    Engineering automation can include parametric CAD, drawing generation, simulation requests or design templates. These capabilities are often separate from the core CPQ application. The CAD and engineering automation guide explains how configuration data can be used to produce product-specific engineering outputs.

    5. Costing and pricing services

    Pricing is related to configuration but is not the same as configuration. Configuration answers what the product is. Pricing answers what the company will charge for it. Costing estimates the resources consumed to manufacture or procure it.

    A pricing service may combine base prices, option prices, quantity breaks, customer agreements, currencies, freight, taxes, discounts and approval thresholds. A costing service may use material cost, labor, subcontracting, overhead assumptions, purchased-component prices and estimated production effort.

    For a configured industrial pump, the final price may depend on the selected metallurgy, impeller diameter, motor, seal, certification, testing requirement and delivery location. The architecture should make clear whether price is calculated from a CPQ price book, an ERP material price, a cost model, or a combination of sources.

    Commercial rules should not silently override engineering rules. A discount can change the price, but it should not make an invalid motor or pressure rating acceptable. More detail on costing, pricing, quote documents and BOM outputs is available in the BOM, pricing and quoting guide.

    6. Quote, proposal and approval generation

    Once the configuration and commercial result are complete, the CPQ system can generate a quote or proposal. A manufacturing quote may include product description, configuration summary, inclusions and exclusions, technical specifications, price, lead time assumptions, warranty terms, validity period and approval information.

    The document should represent the configured product accurately without exposing unnecessary internal implementation details. In some businesses, the quote includes a customer-friendly description while the system stores a more detailed technical configuration identifier.

    Approval workflows may be triggered by discount levels, margin thresholds, non-standard terms, unusual engineering requirements, long lead-time components or deviations from standard products. Approval status should be connected to the configuration and commercial version so that a later change cannot accidentally reuse an earlier approval.

    7. BOM and manufacturing outputs

    A bill of materials, or BOM, is a structured list of components and quantities required for a product or assembly. Manufacturing CPQ may produce several types of BOM output, but these should not be treated as interchangeable.

    • Engineering bill of materials, or EBOM: the product structure organized from an engineering design perspective.
    • Manufacturing bill of materials, or MBOM: the structure organized for manufacturing, assembly and production execution.
    • Configurable BOM: a product structure containing selectable components, conditions or rules that resolve into a particular configuration.

    A CPQ system may generate a preliminary configurable BOM, an EBOM, an MBOM, a sales BOM or simply a list of selected options. The implementation must define which output is authoritative and which system owns revisions, quantities, substitutes, routings and work instructions.

    For a configured control panel, CPQ may identify enclosure size, breakers, terminals, wiring accessories and labels. ERP may then create the order structure, while PLM or PDM manages engineering revisions and CAD documents. The CPQ output is valuable only if downstream systems can interpret it consistently.

    8. CAD, PLM and PDM relationships

    CAD means computer-aided design. PLM means product lifecycle management, and PDM means product data management. CAD creates or represents designs; PDM commonly manages design files and revisions; PLM manages broader product information, lifecycle processes and engineering governance.

    Manufacturing CPQ can exchange configuration parameters with CAD to generate a model or drawing, retrieve a validated design reference, or request engineering work for an ETO product. ETO means engineer-to-order, where significant engineering work is performed for a particular order.

    Not every CPQ platform has native CAD or PLM connectivity. Some architectures use middleware, integration services or custom APIs. Important design questions include whether CPQ stores a copy of the design, stores only a reference, or creates an immutable snapshot of the engineering result associated with the quote.

    9. Enterprise integrations

    Integrations connect CPQ to the systems that own customer, product, operational and production data.

    System Typical relationship with CPQ
    CRM, or customer relationship management Provides accounts, opportunities, contacts and sales context; receives quote status and commercial outcomes.
    ERP, or enterprise resource planning Provides items, inventory, costs, orders, customers and financial data; receives approved configuration and order information.
    PLM Manages product lifecycle, engineering structures, revisions, specifications and change processes.
    PDM Manages CAD files, documents, metadata and design revisions.
    CAD Uses configuration parameters to create or modify product designs, drawings or models where supported.
    PIM, or product information management Maintains market-facing descriptions, attributes, images and channel content.
    MES, or manufacturing execution system May receive production-relevant product or order information for execution and traceability.

    Integration should be designed around ownership rather than convenience. For example, CPQ may calculate a quote price but ERP may remain the source for customer-specific financial terms. PLM may own engineering revisions while CPQ publishes only released configuration data. The CPQ integration guide covers these system boundaries and API considerations.

    10. Manufacturing workflows supported by the architecture

    The same architecture can support different fulfillment models.

    • Configure-to-order, or CTO: a product is assembled or completed from predefined options and components.
    • Make-to-order, or MTO: production begins in response to an order, often using a defined product specification.
    • Assemble-to-order, or ATO: stocked subassemblies are combined into a selected final product.
    • Engineer-to-order, or ETO: the order requires customer-specific engineering or design work.

    In a CTO process, CPQ may validate options, resolve a configurable BOM and create an ERP order with limited engineering intervention. In an ETO process, CPQ may capture requirements, estimate price and lead time, create an engineering work package and wait for an approved design before final production data is released.

    The manufacturing workflow guide explains how configuration data moves from sales engineering through order review and production.

    A representative data flow

    1. A customer, dealer or sales engineer enters application requirements.
    2. The product model presents relevant families, options and attributes.
    3. Rules validate dependencies, exclusions, ranges and required selections.
    4. Engineering calculations determine technical values or identify a suitable variant.
    5. The system resolves components, quantities and technical outputs.
    6. Costing and pricing services calculate price, margin, lead-time assumptions and approvals.
    7. The user reviews the configuration and generates a quote or proposal.
    8. Approved data is sent to CRM, ERP, PLM, PDM, CAD or MES as appropriate.
    9. Downstream systems create or update the order, engineering record, BOM, drawing or production structure.

    This flow is not always linear. An engineering calculation may change the available options, an ERP availability check may alter lead time, or an engineering review may return a revised configuration. The architecture should support controlled revisions rather than assuming that the first configuration is final.

    Benefits of a well-designed architecture

    • Fewer configuration errors: invalid combinations are prevented before quotation or order entry.
    • Faster technical quoting: sales engineers spend less time recreating calculations and searching for compatible components.
    • More consistent pricing: commercial logic is applied systematically to the selected product definition.
    • Better engineering handoff: requirements, assumptions and selected options are preserved in structured data.
    • Reusable manufacturing data: approved configurations can contribute to BOM, CAD and ERP outputs.
    • Improved product governance: versioned rules and models reduce uncontrolled spreadsheet logic.
    • Support for channels: dealers and distributors can configure approved products without receiving unrestricted engineering authority.

    Limitations and architecture risks

    CPQ does not eliminate the need for product governance or engineering judgment. Common limitations include incomplete product data, ambiguous rules, conflicting ownership between departments, weak revision control and integrations that transfer only partial information.

    Large product models can also become difficult to maintain. Every new option may interact with materials, dimensions, suppliers, compliance requirements, price lists, drawings and production methods. Poorly structured rules can create performance problems and make testing impractical.

    Another risk is using CPQ as a replacement for every enterprise system. A CPQ platform should not automatically become the master for CAD files, engineering revisions, inventory, financial accounting or shop-floor execution. Clear boundaries reduce duplicate data and conflicting updates.

    Implementation considerations

    Start with a bounded product family

    Select a product family with meaningful configuration complexity but manageable scope. Document the current quoting process, recurring errors, engineering calculations, outputs and system handoffs before building the model.

    Define data and rule ownership

    For each attribute, option, formula, price and output, identify the owning department and system. Establish who approves changes and how released versions are retired.

    Separate standard and engineered paths

    Not every configuration should be forced into a fully automated flow. A standard CTO configuration may be released directly, while an ETO configuration may create an engineering review task with explicit assumptions and deliverables.

    Test combinations, not just screens

    Testing should include valid configurations, invalid combinations, boundary values, revisions, currencies, discounts, substitutions, missing data and downstream document or BOM outputs. The most important test may be whether the same configuration produces consistent results in CPQ, ERP and engineering systems.

    Plan for ongoing maintenance

    Product models are operational assets. They require release management, regression testing, monitoring, documentation and a process for handling supplier changes, obsolete components, new regulations and manufacturing changes. More implementation guidance is available in the CPQ implementation guide.

    How to evaluate CPQ architecture during software selection

    Buyers should evaluate architecture against the company’s actual product and production requirements rather than counting generic features. Important questions include:

    • Can the platform represent product families, options, dependencies and revisions at the required scale?
    • Can rules express technical constraints, calculated values and conditional component selection?
    • Does the platform support the required costing, pricing, approval and document processes?
    • Can it create the required BOM type, or does it only pass selected options to another system?
    • Are CAD, PLM, PDM, ERP and CRM integrations documented and maintainable?
    • Can the system support CTO, MTO, ATO and ETO paths without hiding manual engineering work?
    • How are rules tested, versioned, released and audited?
    • What data is stored in CPQ, and what data remains authoritative elsewhere?
    • Can dealers, distributors, internal sales teams and customers receive different levels of access?
    • How are APIs, integration failures, retries and configuration snapshots handled?

    Vendor documentation and demonstrations should be separated from assumptions. A vendor may describe a platform as supporting manufacturing, but the buyer should verify whether that means simple product selection, configurable BOMs, engineering calculations, CAD automation or a documented integration pattern. Manufacturing-focused selection criteria are discussed in the manufacturing CPQ comparison and selection resources.

    Semantic map

    The following relationships summarize the main entities in manufacturing CPQ architecture:

    • CPQ configures configurable products.
    • Configuration rules prevent invalid combinations.
    • Constraint-based configuration evaluates technical relationships.
    • Guided selling collects application requirements.
    • Engineering calculations validate product performance.
    • Configured products generate BOM outputs.
    • EBOM represents an engineering product structure.
    • MBOM represents a manufacturing product structure.
    • Pricing logic calculates commercial values.
    • Quote generation presents configuration and price.
    • CAD automation generates product-specific drawings.
    • CPQ exchanges customer data with CRM.
    • CPQ exchanges order data with ERP.
    • PLM governs product lifecycle and engineering revisions.
    • PDM manages CAD files and design metadata.
    • MES executes or tracks manufacturing operations.
    • CTO assembles approved product options.
    • ETO triggers customer-specific engineering work.

    Frequently asked questions

    What is CPQ architecture?

    CPQ architecture is the arrangement of product models, rules, calculations, pricing, quote generation and integrations that support Configure, Price, Quote processes. In manufacturing, it may also include BOM, CAD and engineering outputs.

    How is manufacturing CPQ different from sales CPQ?

    Sales CPQ often focuses on selecting products, applying pricing and generating proposals. Manufacturing CPQ additionally addresses technical validity, engineered options, components, BOMs, drawings, production data and engineering handoff.

    Does every CPQ system generate a BOM?

    No. Some platforms generate configurable or sales BOMs, while others send configuration results to ERP, PLM or a separate product-structure system. BOM capability and ownership must be verified for each platform.

    What is the role of a product model?

    The product model defines product families, options, attributes, components and relationships. It provides the structured foundation on which configuration rules, calculations and outputs operate.

    What are configuration rules?

    Configuration rules control valid selections and relationships. They can require, exclude, default or calculate values based on other choices, such as requiring a compatible seal for a selected pump fluid.

    What is the difference between rules-based and constraint-based configuration?

    Rules-based configuration commonly uses explicit conditions, while constraint-based configuration evaluates a network of restrictions and relationships. Both can validate products, but their modeling approaches and scalability may differ.

    What is guided selling?

    Guided selling asks application or customer questions and recommends suitable products or options. It improves the user experience but does not necessarily replace detailed engineering validation.

    Can CPQ perform engineering calculations?

    Some manufacturing CPQ platforms include calculation capabilities, while others call external engineering services or applications. The implementation should identify the authoritative calculation method and its versioning process.

    How does CPQ integrate with ERP?

    CPQ may receive item, customer, cost or availability data from ERP and send approved configuration, pricing or order information back. The exact data flow depends on system ownership and integration design.

    How does CPQ integrate with PLM?

    CPQ may consume released product structures, attributes or revisions from PLM, or send configuration references for engineering review. PLM commonly remains authoritative for lifecycle and engineering change control.

    What is the difference between EBOM and MBOM?

    EBOM is organized around the engineering design, while MBOM is organized around manufacturing and assembly. A CPQ system may produce one, both or neither, depending on its capabilities and integration architecture.

    Can manufacturing CPQ support engineer-to-order products?

    Yes, if the workflow supports engineering review, requirement capture, design outputs and controlled revisions. CPQ may initiate the ETO process without fully automating the engineering work.

    Where does CAD automation fit in CPQ architecture?

    CAD automation is an engineering service connected to configuration data. It can use selected dimensions and options to generate models or drawings, but it may be provided by a separate CAD or automation system.

    Should CPQ replace ERP or PLM?

    Usually not. CPQ should coordinate configuration and commercial processes while ERP, PLM, PDM and MES retain their appropriate operational or engineering responsibilities.

    What data does a manufacturing CPQ system require?

    It may require product families, options, attributes, rules, engineering formulas, component mappings, prices, costs, lead-time assumptions, document templates and integration identifiers.

    How should CPQ rules be governed?

    Rules should have named owners, version control, approval workflows, documentation and automated regression tests. Changes should be traceable to a product, engineering or commercial decision.

    What is a configurable BOM?

    A configurable BOM contains conditional components or structures that resolve according to selected options. It is different from a fixed BOM because the final component list depends on the configuration.

    What is the most important architecture decision?

    A central decision is determining which system owns each type of data and result. Clear ownership for product rules, engineering revisions, prices, BOMs, customers and orders prevents conflicting records and fragile integrations.