Area of expertise 02
CPQ & Product Configuration
Configure correctly. Price profitably. Quote with confidence.
We connect customer needs, product logic, pricing, approvals, documents and result objects in one end-to-end process – from Guided Selling to order and bill of materials.
02
Impact
Speed
Pricing quality
End-to-end consistency
Move faster from inquiry to a valid, priced and executable solution.
End to end instead of an isolated solution
CPQ is more than a configurator.
A robust CPQ process brings three disciplines together on an equal footing. Configure translates customer need into a technically valid solution. Price develops a transparent and commercially viable price. Quote combines the solution, price, visualization and documents into a reproducible quotation.
For highly configurable industrial products, all three disciplines must be based on the same approved product logic. Otherwise, long quotation lead times, early engineering involvement, inconsistent pricing versions and missing result objects are merely digitized.
C
Configure
Translate need into a valid, calculated solution that the respective user can understand.
P
Price
Bring together product logic, costs, market, customer value, conditions, margin and approvals.
Q
Quote
Combine solution, price, line items, documents and approval status into a robust quotation.
Decisive point: The chain becomes consistent end to end only when business objects, system roles and accountability are clarified at every handover.
Configure
From customer need to a valid, reproducible solution.
Product configuration does not begin with an interface. It begins with the question of how customer requirements can be translated into a controlled solution space. Guided selection, expert configuration and detailed technical work may provide different views – but must use the same approved product and rule base.
Need and user perspective
Guided Selling captures application, required performance, operating conditions and preferences in clear market language. Recommendations, defaults and different configuration depths support customers, sales, expert sales and engineering.
Product and rule model
Characteristics, values, options, modules, dependencies, constraints and preferred solutions are named clearly, versioned and modeled in a testable form. Reusable solutions retain the same meaning across sales, engineering and execution.
Sizing and result objects
Multi-line-item and system configuration, sizing, performance curves and technical calculations are incorporated where they safeguard selection and validation. Configuration ID, specification, parameters, documents and structural information are created reproducibly.
Process boundaries and engineering
CTO, CTO+ and ETO require clear handover points. Rule-based configuration, parameterization and limited engineering content can work together without allowing special solutions to create uncontrolled permanent complexity.
Process boundaries: MTS, PTO, ATO, MTO, CTO, CTO+ and ETO do not form a linear maturity sequence. For each product family, it must be clarified which content is created through rules, when engineering becomes involved and which result objects are required.
Application context
Market, product and process determine the right starting point.
Market- and sales-oriented quotation management has different requirements from a technically deep product configurator, ERP-centric order configuration or engineering automation. A system class is therefore first and foremost a business classification of the use case – not a ranking of technologies or an assessment of products.
System classes × application and functional focus
Which system class fits which product and application context?
System classes address different market, product and process situations. The matrix shows their business starting point, typical application fields and the functional roles in which they lead, support or integrate.
| System class |
|---|
The classification describes typical areas of focus and does not assess individual products. Specific roles depend on the product design, modules and target architecture. An English overview of the system classes is available at CPQ-SELECT.
Price
Pricing logic, margin and governance belong in the same decision process.
Pricing is not a downstream calculation step. For complex products, price is shaped by configuration, cost basis, market, customer value, contract, service scope and deal context. The pricing architecture is therefore clarified first, and only then its technical distribution across ERP, CPQ and CRM.
Pricing architecture
Price waterfall and governance for highly configurable products
Price determination from cost basis to net price. What matters is not the height of the stages, but who is accountable for them, which system is authoritative — and where margin is regularly lost along the way.
1 · Pricing mechanisms
2 · Price waterfall
Schematic representation of the stage logic. Heights are illustrative proportions and do not represent metrics.
3 · System landscape and roles
Target model: transparent, rule-based and value-oriented price determination — with a named owner for every stage and the realized net price feeding back into the pricing architecture.
Guiding principle: Configuration and pricing must not rebuild the same product logic independently. Cost information, price components, margin visibility, overrides and approvals require unambiguous data ownership.
Quote and handover
The selected solution becomes a robust and executable result.
Quote is more than document generation. The customer must understand the solution, scope of supply, alternatives and commercial implications. Internally, configuration, pricing status, visualization, documents and approvals must be versioned together and remain reproducible.
Quotation and alternatives
Main and secondary line items, options, packages, scopes of supply, exclusions and variant comparisons are combined into a consistent quotation structure.
Documents and visualization
Technical data, text, drawings, layouts and 2D/3D representations are derived from the approved state – not as a visual effect, but as an unambiguous component of the quotation.
Order and result objects
Configuration ID, line items, characteristics, price components and approval status form the controlled handover to the order, change orders and the derivation of the order-specific 100% BOM.
Architecture principle: CPQ does not need to generate the manufacturing-ready bill of materials itself. It must, however, deliver an unambiguous, reproducible result state from which CPQ, PLM, ERP or a coupled process can reliably derive the intended downstream objects.
Impact across the process chain
A robust product description earlier. Fewer loops before production starts.
The main leverage does not come from faster quotation generation alone. Product knowledge becomes available earlier, decisions become reproducible and engineering focuses more strongly on genuinely new solution content instead of recurring order clarification.
Application: highly complex machinery, plant engineering and large-scale industrial systems
Qualitative representation: the actual advantage and starting level vary by product area, product architecture and the scope of product logic defined in advance.
Our consulting principle
Five perspectives make CPQ operationally sustainable.
A robust CPQ process emerges only when solution space, process, data objects, system roles and accountability are designed together.
Contribution to the shared target model
Product
Solution space, product structure, options, services and required result objects form the business starting point.
Key question: Which solutions may be offered – and which results must they produce?
Approach and outcomes
From an evolved quotation process to a robust CPQ target model.
We begin with real product families and representative end-to-end cases. Criteria lists alone are not enough: a PoC demonstrates technical feasibility; a pilot reveals operational viability, maintenance effort and governance.
01
Current situation and scope boundaries
Create transparency regarding product families, users, process classes, quotation lead times, engineering content, pricing issues, result objects and business objectives.
02
Target model and pilot
Develop and validate the product and rule model, Guided Selling, pricing architecture, system roles and handover objects using realistic use cases and 10–20 representative edge cases per product family.
03
Operations and scaling
Establish roles, maintenance, testing, release calendar, monitoring, training and KPIs, and roll out product families, regions and channels in a controlled manner.
Typical outcomes
- Approved solution space for Guided Selling, configuration and engineering
- Traceable pricing architecture with margin visibility and approvals
- Reproducible quotations, documents and version states
- Defined result objects for order and downstream processes
Measurable management
- Quotation lead time, error rate and engineering content
- Hit rate, discount rate, margin and approval effort
- Reuse and effort for product-model changes
- Release quality, regression testing, monitoring and continuous improvement
Frequently asked questions
Key decisions before a CPQ initiative.
How do we distinguish MTS, PTO, ATO, MTO, CTO, CTO+ and ETO for CPQ?
Through clear process and scope boundaries for each product family. What matters is which content is created through rules within the approved solution space, when engineering becomes involved, which result objects are required and which systems participate.
Where should configuration logic reside across CPQ, PLM and ERP?
This depends on product structure, configuration depth and process pattern. Guided Selling and high-level sales logic may reside in CPQ, while PLM or ERP leads structure- and BOM-related logic. Shared semantics, unambiguous validity and no uncontrolled duplication of rules are essential.
How can configuration and quotation be handed over reliably to the order and bill of materials?
Through defined result objects and a reproducible configuration ID. Line items, characteristics, documents, price components and approval status are handed over so that the order and 100% BOM can be derived unambiguously in the intended target system.
How do we assess whether a CPQ solution is a good business and technical fit?
Not from criteria lists alone. What matters are realistic use cases and edge cases for Guided Selling, configuration, pricing, documents, changes, integration and BOM derivation. A PoC demonstrates feasibility; a pilot shows whether modeling, operations and governance are sustainable.
How do configurations and quotations remain reproducible across changes?
Products, options, rules, prices, documents and interfaces are versioned, tested and released together. Historical states must remain traceable for reconfiguration, change orders, retrofit, spare-parts quotations and service quotations.
Independent. Experienced. Implementation-oriented.
Assess a CPQ, configuration or end-to-end challenge on a sound basis.
In an initial conversation, we clarify the current situation, product and process context, configuration and pricing logic, result objects, system landscape and key risks. We then assess whether a focused review, target model, PoC or pilot is the right starting point.