System-level configuration is the process of selecting and validating multiple related products, subsystems and engineering parameters as one complete industrial solution. In manufacturing CPQ, or Configure, Price, Quote software, the objective is not merely to choose options on a single product. It is to ensure that pumps, motors, valves, controls, frames, electrical equipment, software and services work together, meet technical constraints, produce accurate commercial results and generate usable downstream data.
A system-level configurator therefore sits between product configuration, engineering, pricing and manufacturing. It may use rules to prevent incompatible selections, calculations to size components, configuration data to create a configurable bill of materials (BOM), and integrations to transfer the result to enterprise systems. The exact scope depends on the platform. Some CPQ products focus primarily on guided selling and quotations, while manufacturing-oriented systems may also support engineering calculations, CAD automation, BOM generation or configure-to-order and engineer-to-order workflows.
For example, configuring an industrial pumping system may require more than selecting a pump model. The system may need to evaluate flow, pressure, fluid properties, temperature, materials, motor voltage, starter type, instrumentation, piping connections, skid dimensions and site requirements. A valid configuration must satisfy hydraulic, mechanical, electrical, commercial and production constraints simultaneously.
This guide explains how system-level configuration works, how to structure the product model, how to manage rules and dependencies, where the data flows after configuration, and what manufacturers should consider before implementing it. For a broader introduction, see the guide to manufacturing CPQ and the detailed guide to product configuration and rules engines.
What is system-level configuration?
System-level configuration is the coordinated configuration of a complete solution made up of several products, assemblies or functional subsystems. The configurator evaluates relationships between those parts rather than treating each item as an independent selection.
A system may include:
- a primary machine or piece of equipment;
- mechanical assemblies such as frames, conveyors, guards and enclosures;
- electrical components such as motors, drives, starters, panels and sensors;
- fluid, hydraulic or pneumatic components;
- control hardware and software;
- installation materials, commissioning services and documentation;
- customer-specific engineering or site adaptations.
In a simple product configurator, an option may be valid or invalid within one product family. In a system-level configurator, validity may depend on selections made elsewhere in the system. A selected motor can affect the drive, electrical panel, cooling requirements, mounting arrangement, cable size, price and BOM. A selected process fluid can affect pump materials, seals, temperature limits and certification requirements.
Why system-level configuration matters in manufacturing
Complex industrial sales often begin with a customer requirement rather than a finished part number. The sales engineer must translate a process need into a complete technical solution. This creates several risks when configuration is performed manually in spreadsheets, product catalogs, email and disconnected engineering tools.
- Incomplete scope: important accessories, controls, protection devices or services may be omitted.
- Invalid combinations: selected components may not be mechanically, electrically or operationally compatible.
- Inconsistent calculations: two engineers may apply different sizing assumptions or formulas.
- Slow engineering review: specialists must repeatedly check routine configurations.
- Incorrect pricing: system dependencies, options and engineering effort may not be reflected in the quote.
- Poor order handoff: sales information may not be structured for ERP, product lifecycle management or production systems.
System-level configuration addresses these problems by making the relationships explicit in a governed product model. It does not eliminate engineering judgment. Instead, it automates repeatable decisions and identifies cases that require review or a separate engineer-to-order process.
System-level configuration compared with other configuration approaches
| Approach | Primary purpose | Typical manufacturing example | Main limitation |
|---|---|---|---|
| Guided selling | Help a user select suitable products through questions and recommendations | Recommend a standard air-handling unit based on airflow and building type | May not validate deep engineering relationships or create manufacturing data |
| Rules-based configuration | Apply explicit if-then logic to options and dependencies | If a high-temperature seal is selected, restrict the material and certification options | Large numbers of exceptions can make rules difficult to maintain |
| Constraint-based configuration | Represent permitted and prohibited relationships across variables and components | Ensure pump duty, motor capacity, voltage, impeller size and frame dimensions remain compatible | Requires a well-defined constraint model and clear ownership |
| Product configuration | Define one product or product family | Configure a conveyor length, belt type, drive and guarding package | May not coordinate several product families or subsystems |
| System-level configuration | Validate and generate a complete interconnected solution | Configure a packaging line with conveyors, robots, controls, safety equipment and services | Has greater data, integration and governance complexity |
These approaches can coexist. A system-level configurator may use guided questions at the user interface, rules-based logic for explicit policies, constraint solving for technical compatibility and engineering calculations for sizing.
The product model behind a system configurator
The product model is the structured representation of what can be sold, how it can be configured and what the configuration produces. A maintainable model separates commercial choices from engineering logic while defining the relationships between them.
System hierarchy
The hierarchy describes the solution from the system level down to modules, assemblies, components and selectable options. For example, a material-handling system could be represented as:
- material-handling solution;
- conveyor line;
- infeed conveyor, transfer section and discharge conveyor;
- frame, belt, roller, motor, gearbox and guarding assemblies;
- drive, control panel, sensors and safety devices;
- installation, commissioning and documentation services.
The hierarchy should reflect how the company sells, engineers, procures and manufactures the solution. A sales bundle is not always the same as an engineering assembly or a manufacturing assembly.
Features, options and parameters
Features describe meaningful aspects of the system, such as capacity, operating environment, control architecture or compliance requirement. Options are selectable values or components. Parameters are measurable inputs such as flow rate, length, voltage, pressure, temperature, load or speed.
For a pump skid, parameters may include:
- design flow and differential pressure;
- fluid density, viscosity and temperature;
- pump material and seal arrangement;
- motor power, voltage, frequency and enclosure rating;
- connection standard and nozzle orientation;
- skid footprint, lifting points and access requirements;
- instrumentation and control protocol.
Parameters can drive calculations and rules. They should not be treated as free-text notes if downstream systems need to use them. A structured temperature value can trigger material restrictions; a free-text statement such as hot service cannot reliably do so.
Relationships between subsystems
The model must represent relationships such as requires, excludes, compatible with, derives from, sized by and supplied with. These relationships may cross product boundaries.
For example, selecting a 460-volt motor may require a matching control-panel voltage, affect the starter or variable-frequency drive, and restrict the available documentation package. Selecting stainless steel wetted parts may require compatible fasteners, seals and welding procedures. Selecting outdoor installation may require a specific enclosure rating, heater, coating system and cable-entry arrangement.
Rules and constraints in system-level configuration
Rules determine how the configurator responds to selections and calculated values. A constraint is a condition that must be satisfied for the complete configuration to be valid. In practice, manufacturers often use several types of logic together.
Compatibility rules
Compatibility rules prevent combinations that cannot work together. A gearbox may be incompatible with a particular conveyor width. A control panel may not support the selected number of axes. A valve material may be unsuitable for the specified chemical or temperature range.
Dependency rules
Dependency rules add or require related elements. Selecting a hazardous-area motor may require certified cable glands, an appropriate enclosure, special documentation and an inspection activity. Selecting a robotic cell may require safety fencing, interlocks and a safety controller.
Exclusion rules
Exclusion rules remove options that are not available in a particular configuration. A compact frame may exclude a large motor. A selected certification route may exclude certain materials or control components. Exclusions should be explained clearly to the user so that a technical restriction does not appear to be an arbitrary sales limitation.
Calculation rules
Calculation rules derive values from customer inputs. A configurator may calculate required motor power, heat-exchanger area, tank volume, cable size, pressure drop, structural load or estimated cycle time. Calculations need version control, documented assumptions, units and an approval process. A formula embedded in an interface without ownership or testing becomes difficult to trust.
Availability and commercial rules
Some rules relate to sourcing and commercial policy rather than technical validity. A component may be technically suitable but unavailable in a region, obsolete, restricted to a particular plant or subject to a minimum order quantity. These rules should be distinguished from engineering constraints because they have different owners and change cycles.
Example: configuring a complete pump and control skid
Consider a manufacturer selling packaged pump skids for industrial water treatment. The customer specifies flow, pressure, fluid temperature, installation location, electrical supply and control requirements.
Configuration inputs
- flow rate and required head;
- fluid composition and temperature;
- continuous or intermittent duty;
- indoor or outdoor installation;
- available voltage and frequency;
- single-pump or duty-standby arrangement;
- local control, remote monitoring or plant-network integration;
- footprint, lifting and access restrictions.
Configuration logic
The model uses the duty point to select an appropriate pump family and impeller range. Fluid temperature and composition restrict materials and seal options. Duty-standby operation adds a second pump, isolation valves, check valves, instrumentation and control logic. Outdoor installation affects the panel enclosure, coating, heater and weather protection. The available electrical supply constrains the motor and drive options.
If the calculated motor load exceeds the selected drive range, the configurator should reject the combination or propose a larger drive. If the skid footprint is too small for the selected pump and maintenance clearance, the system should identify the issue before quotation. If the requested duty falls outside the standard product model, the configuration may be routed to engineering review rather than silently producing a standard quote.
Outputs
The configuration may produce a technical specification, price, lead-time assumptions, system BOM, equipment tag list, control narrative and quotation. Depending on the company’s architecture, it may also trigger CAD automation for the skid layout, create an engineering bill of materials (EBOM), or send order data to an enterprise resource planning (ERP) system.
How system-level configuration connects to engineering and manufacturing
A system configurator is most useful when its output is structured for the next process. The exact flow depends on whether the product is configure-to-order, make-to-order or engineer-to-order.
Configuration to engineering
For standard or lightly variable solutions, the configuration may provide enough information for order release. For more complex solutions, it can create an engineering work package containing selected options, calculated values, unresolved decisions, customer documents and review requirements.
CAD, or computer-aided design, automation may use configuration parameters to select templates, suppress or activate features, set dimensions and generate drawings. This capability is not present in every CPQ platform and may require a separate CAD automation service or integration. More detail is available in the guide to CAD and engineering automation.
Configuration to BOM generation
A BOM is a bill of materials listing the components and quantities required for a product or system. An EBOM, or engineering bill of materials, describes the design structure. An MBOM, or manufacturing bill of materials, describes how the product is assembled or produced. A configurable BOM is a rule-driven structure that resolves into a specific BOM after selections and calculations are complete.
System-level configuration may generate a sales or technical BOM first, then pass data to PLM, ERP or manufacturing systems for further transformation. The configurator should define whether it owns the final BOM, proposes a BOM for engineering approval, or only identifies commercial components. These are different operating models and should not be conflated.
Configuration to pricing and quoting
Pricing is related to configuration but is not the same function. The system model determines what the solution contains and whether it is valid. The pricing engine determines material prices, labor, engineering effort, services, discounts, margins, freight assumptions and commercial adjustments.
A pump skid may have a component price, a package assembly charge, engineering hours, testing fees and commissioning services. Some values may come from ERP or a costing system. A quote should make clear which values are calculated automatically and which require commercial approval. See BOM, pricing and quoting automation for the relationship between these functions.
Configuration to enterprise systems
Common systems have different responsibilities:
| System | Typical responsibility in a system-level workflow |
|---|---|
| CRM, or customer relationship management | Customer, opportunity, account and sales-process information |
| CPQ | Configuration interaction, rules, calculations, pricing and quote preparation |
| ERP, or enterprise resource planning | Items, inventory, purchasing, production orders, sales orders, finance and fulfillment |
| PLM, or product lifecycle management | Product structures, revisions, approvals, engineering change and lifecycle governance |
| PDM, or product data management | Controlled CAD files, drawings and related design data |
| CAD | Geometric design, assemblies, drawings and design automation |
| MES, or manufacturing execution system | Production execution, work instructions, tracking and shop-floor reporting |
| PIM, or product information management | Commercial product content, descriptions, attributes and channel information |
These systems can exchange data through APIs, integration middleware, files or platform-specific connectors. A reliable architecture defines the system of record for each object and avoids creating conflicting versions of the same product, component or rule. See the guide to CPQ integrations for integration patterns and ownership questions.
System-level configuration across manufacturing workflows
Configure-to-order
In configure-to-order (CTO), the manufacturer offers a defined product architecture with controlled options. System-level configuration can validate the customer solution and generate a production-relevant structure without designing a new product for every order.
Make-to-order
In make-to-order (MTO), production begins after the order is received, but the product may still use a relatively stable design. The configurator can determine the required components, dimensions and routing information while preserving standard manufacturing rules.
Engineer-to-order
In engineer-to-order (ETO), each order requires substantial engineering work. System-level configuration can capture the customer requirement, perform preliminary sizing, define standard subsystems and identify the boundary between reusable logic and bespoke design. It should not pretend that every ETO decision can be automated.
Assemble-to-order
In assemble-to-order (ATO), standard modules are assembled after the order is placed. A system configurator can coordinate module compatibility, availability and assembly requirements across the complete solution.
These workflow distinctions matter because they determine how much authority the configurator has. A CTO model may generate a releasable BOM. An ETO model may generate a controlled engineering request and preliminary estimate instead.
Benefits of system-level configuration
- More complete solutions: dependencies help include required accessories, controls and services.
- Earlier error detection: invalid technical combinations can be identified before quote submission or order entry.
- Faster routine engineering: repeatable sizing and selection logic can be applied consistently.
- Better quote quality: price, scope, lead-time assumptions and technical content are based on the same configuration.
- Improved handoff: structured data is easier to transfer to ERP, PLM, CAD and production processes.
- Reusable engineering knowledge: validated rules preserve expertise when products, staff or markets change.
- Greater traceability: the company can identify which rules, revisions and inputs produced a quoted solution.
Limitations and risks
System-level configuration is not a shortcut around product data quality or engineering governance. Its limitations usually arise from model scope, unclear ownership and excessive complexity.
Rules can become unmaintainable
A model with thousands of overlapping exceptions may be harder to manage than the manual process it replaced. Rules should be modular, named, documented and tested. Repeated logic should be centralized rather than copied across many product families.
Engineering knowledge may be incomplete
Experienced engineers often rely on assumptions that are not written down. Before automation, the organization must identify units, tolerances, safety factors, valid operating ranges, standards and approval conditions.
System boundaries can create ambiguity
Manufacturers need to decide whether product rules live in CPQ, PLM, ERP, CAD or another service. Duplicating the same logic in several systems creates synchronization risk. A CPQ model may need a simplified commercial representation while PLM remains the authority for released engineering structures.
Not every configuration is automatable
Novel applications, unusual site conditions, regulatory interpretations and major customizations may require engineering review. A mature system should support controlled exceptions, not force every opportunity into a standard model.
Integration does not guarantee usable data
An API can transfer fields successfully while still producing an unusable manufacturing result. Integration design must address units, revisions, item identities, effectivity, configuration status, error handling and ownership of changes.
Implementation approach
1. Select a bounded system
Start with a product family or solution type where demand is significant, configuration patterns are repeatable and the business can identify a measurable problem. A complete factory-wide model is rarely the best first release.
2. Map the current workflow
Document how requirements move from customer inquiry to quote, engineering review, order entry, design release, procurement and production. Identify where data is re-entered, where decisions are delayed and where errors occur.
3. Establish product and rule ownership
Assign owners for product options, engineering formulas, pricing, availability, compliance, BOM structures and integration mappings. Define who approves a rule, who tests it and who can release a revision.
4. Build the minimum viable product model
Model the system hierarchy, key parameters, standard modules, critical constraints and required outputs first. Avoid automating low-value exceptions before the core logic is proven.
5. Separate decisions from presentation
The user interface should guide sales engineers or customers, but the underlying model should hold the authoritative rules and calculations. This makes the logic easier to test and reuse in dealer portals, internal tools or APIs.
6. Test real configuration scenarios
Testing should include valid standard cases, boundary values, incompatible selections, changed product revisions, unavailable components, incomplete inputs and deliberate engineering exceptions. Test the resulting quote, BOM, CAD output and ERP transaction where applicable.
7. Pilot the downstream handoff
Do not stop at a technically valid quote. Confirm that engineering, purchasing, production and service can use the generated output. A system-level model is successful only when it reduces work across the workflow rather than moving effort to a later department.
8. Govern changes after launch
Manufacturers need a release process for new components, obsolete parts, price updates, revised formulas, regulatory changes and plant-specific availability. Configuration models require ongoing maintenance, regression testing and monitoring.
Further guidance is available in the guide to CPQ implementation and governance and the overview of manufacturing configuration workflows.
How to evaluate a system-level CPQ configurator
Buyers should evaluate the complete configuration lifecycle rather than counting interface features. Important questions include:
- Can the model represent multiple interacting subsystems and reusable modules?
- Can rules express dependencies, exclusions, ranges, calculations and approval conditions?
- Can non-developers maintain appropriate product content and rules?
- Can the system distinguish technical validity from commercial availability?
- Can it generate or integrate with a configurable BOM, EBOM or MBOM process?
- Can it pass structured parameters to CAD, PLM, ERP or MES systems?
- Can it support both standard configurations and controlled ETO exceptions?
- Can it show users why a selection is invalid or what additional information is needed?
- Does it provide versioning, testing, audit trails and effective dates?
- Can it support dealer, distributor, internal sales-engineering and API-based channels?
- How are units, currencies, revisions, item numbers and configuration identifiers handled?
- What happens when an integration fails or a component becomes unavailable?
Vendor claims should be verified through a realistic scenario using the manufacturer’s own product structure and rules. A platform may advertise configuration support while requiring separate software for CAD automation, engineering calculations or manufacturing BOM transformation. Product research can be organized using the manufacturing CPQ software profiles and comparison and selection guidance.
Semantic map
System-level configuration connects customer requirements, product models, rules, engineering calculations, commercial outputs and manufacturing systems. The following relationships summarize the article:
- Customer requirements feed system parameters.
- System parameters drive engineering calculations.
- Engineering calculations constrain component selection.
- Configuration rules prevent invalid subsystem combinations.
- Subsystem dependencies determine required accessories and controls.
- A valid configuration produces a structured solution definition.
- A structured solution definition can generate a configurable BOM.
- An engineering BOM may be transformed into a manufacturing BOM.
- Configuration data informs pricing and costing.
- CPQ exchanges customer and configuration data with CRM and ERP.
- CAD automation can use configuration parameters to generate drawings.
- PLM governs released product structures and revisions.
- ETO exceptions create engineering review work.
- Configuration governance maintains rules, formulas and product revisions.
Frequently asked questions
What is system-level configuration in manufacturing?
It is the configuration of a complete industrial solution made up of several related products, assemblies or subsystems. The system validates technical relationships across those parts rather than configuring each product independently.
How is system-level configuration different from product configuration?
Product configuration usually focuses on one product family. System-level configuration coordinates multiple product families and evaluates dependencies between mechanical, electrical, software, service and process elements.
What is a system-level CPQ configurator?
It is CPQ software that captures requirements, applies configuration rules and produces a valid industrial solution across multiple subsystems. Depending on the platform, it may also calculate prices, generate BOM data or connect to engineering and enterprise systems.
Does every CPQ system support system-level configuration?
No. Some CPQ platforms primarily support guided selling, option selection and quote generation. Buyers must verify whether a platform supports deep rules, calculations, multi-level BOMs, engineering workflows and required integrations.
What types of rules are needed?
Common rule types include compatibility, dependency, exclusion, calculation, availability, compliance and approval rules. The mix depends on the product and the level of engineering automation required.
Can system-level configuration replace engineering?
No. It can automate repeatable decisions and identify standard solutions, but novel applications, unusual conditions and major customizations still require engineering judgment and review.
Can a system configurator calculate equipment size?
Some systems can perform engineering calculations or call an external calculation service. This is not universal. The manufacturer must verify formula support, unit handling, validation, versioning and approval controls.
Can system-level configuration generate a BOM?
Some manufacturing CPQ systems can generate a configurable or resolved BOM, while others pass selections to ERP or PLM for BOM creation. The implementation must define whether the CPQ output is authoritative, preliminary or subject to engineering transformation.
What is the difference between an EBOM and an MBOM?
An EBOM represents the engineering design structure. An MBOM represents the structure and sequence used to manufacture or assemble the product. A system-level configurator may create one, both, or data that another system transforms between them.
How does system-level configuration support engineer-to-order?
It captures structured requirements, selects reusable modules, performs preliminary calculations and identifies the work that requires engineering. It supports ETO without assuming that all custom design decisions can be automated.
How does system-level configuration support configure-to-order?
It validates selections within a predefined product architecture and can produce a quote, configuration identifier, BOM and order data for a standard but customizable solution.
What manufacturing example suits system-level configuration?
Examples include pump skids, HVAC systems, packaging lines, electrical distribution systems, industrial vehicles, conveyors and machine cells where several subsystems must operate together.
Where should configuration rules be stored?
The answer depends on the architecture. CPQ may own commercial configuration logic, PLM may govern released engineering structures, ERP may own item and availability data, and CAD may own geometric logic. Ownership and synchronization must be defined explicitly.
How can manufacturers keep rules maintainable?
Use modular rules, clear naming, documented assumptions, ownership, version control, effective dates, automated regression tests and a formal change process. Avoid duplicating the same logic across multiple systems.
What happens when a customer request is outside the product model?
The configurator should identify the exception and route it to engineering or commercial review. It should not silently accept a configuration that has not been technically or commercially approved.
What is the role of CAD automation?
CAD automation can use configuration parameters to select templates, set dimensions, activate features and generate product-specific drawings. It is often implemented through a separate CAD automation capability or integration rather than being native to every CPQ platform.
How does system-level configuration affect pricing?
The selected system structure determines which components, services and engineering activities need pricing. A pricing engine then applies costs, prices, discounts, margins and approval policies. Configuration and pricing should be connected but governed as separate concerns.
What integrations are usually required?
Common integrations include CRM for opportunities, ERP for items and orders, PLM or PDM for product data, CAD for design automation, MES for production execution and PIM for commercial product information. The required set depends on the workflow.
How should a manufacturer start a system-level configuration project?
Start with one bounded product or solution family, map the current workflow, establish rule ownership, model the critical constraints, test real cases and validate the downstream handoff before expanding the scope.