ENGLISH OVERVIEW
A structured view of industrial product configuration
Market structure, system classes and selection questions before software comparison
CPQ-SELECT provides a concise, vendor-neutral orientation for decision-makers working with CPQ, product configuration and adjacent engineering and lifecycle systems.
The market is not one software category
CPQ stands for Configure, Price and Quote. In industrial companies, however, the relevant chain rarely ends with a quotation. Customer and application requirements must be translated into valid products or solutions, technical rules and calculations, prices and costs, documents, engineering outputs and executable objects for order processing, manufacturing and service.
Solutions have evolved from different origins. Some start in CRM, sales automation, revenue management and quoting. Others originate in technical product logic, ERP variant configuration, PLM, configuration lifecycle management, engineering automation, visual planning or spatial design. Similar labels therefore do not imply comparable modelling depth, lifecycle coverage, maintainability or output objects.
CPQ-SELECT structures this landscape by tasks, objects and system roles. The central question is not which product offers the longest feature list, but which combination of systems can govern the required product logic and produce reliable results over time.
CORE PRINCIPLE
Product logic, process classes, result objects and target architecture determine the required system roles. Software selection is the consequence, not the starting point.
Six perspectives create a common picture
The CPQ landscape becomes clearer when viewed through six connected perspectives. They are neither a fixed sequence nor a ranking. They show where a solution has its main responsibility and which objects must become authoritative at that point.
1 · Market and sales
Requirements, opportunities, solution guidance, price, discount, quotation and approval.
2 · Product logic
Characteristics, values, constraints, calculations, valid variants and configuration status.
3 · Product and lifecycle
Structures, options, validity, releases, versions, baselines and engineering bills of material.
4 · Engineering and visualisation
Sizing, CAD/ECAD, drawings, geometry, layouts, renderings, 2D/3D and BIM outputs.
5 · Order and value creation
Materials, orders, 100-percent BOMs, manufacturing structures, routings, cost and execution.
6 · Publication and use
Product information, media, catalogues, documents, portals, data packages and analytics.
A system may support several perspectives. Nevertheless, each central object needs a defined owner. Without that clarity, companies create duplicate characteristics, rules, prices, documents and structures with conflicting validity and responsibility.
Seven reference system classes
CPQ-SELECT distinguishes seven reference classes. They are not rigid vendor labels. Modern platforms overlap, and many industrial architectures deliberately combine more than one class.
Sales-centric CPQ suites
Focus on opportunity, commercial configuration, pricing, approvals, quotation and revenue processes.
Industrial CPQ and product configuration
Focus on technical product logic, rules, calculations, valid configurations and reusable result objects.
ERP-centric variant configuration
Focus on material, order, bill of material, costing, availability and operational execution.
Configuration lifecycle management
Focus on shared configuration knowledge, lifecycle consistency, variants, options and change.
PLM-centric variant management
Focus on product definition, engineering structures, effectivity, releases, baselines and traceability.
Design and engineering automation
Focus on calculations, geometry, CAD/ECAD, drawings, technical documents and automated engineering deliverables.
Visual and spatial configuration
Focus on 2D/3D interaction, room and layout planning, rendering, assets, BIM and customer-facing visual decisions.
The class is only the first filter. A meaningful comparison must then examine the modelling approach, product and process scope, result objects, data ownership, integration, governance, deployment model and long-term maintainability.
Cross-cutting capabilities must be assessed in context
Pricing, visualisation, document generation, data formats, analytics, AI and lifecycle management are not additional system classes. They cut across several classes, but each class implements them from a different architectural starting point.
- Pricing may combine cost-plus, mark-up, characteristic- and option-based logic, value-based methods, market and segment rules, discount governance, floor and target prices, and dynamic guidance.
- Visualisation may range from supporting images to real-time 2D/3D, rendering, AR/VR, spatial planning, CAD results and BIM objects. A convincing visual is not proof of technical validity or manufacturability.
- Interfaces must define semantics, identity, version, validity, units, cardinality, error handling and ownership. An API alone does not solve the meaning problem.
- Dashboards become valuable only when metrics have clear definitions, sources and owners and support a concrete decision in sales, pricing, product modelling or governance.
- AI can assist search, guided selling, explanation, model maintenance and document work. Authoritative rules, approvals, tests and releases must remain controlled and auditable.
A shared vocabulary reduces false agreement
Terms such as CPQ, product configuration, variant configuration, Guided Selling, CTO, ETO, MaxBOM, 150-percent structure, product model, pricing engine, BIM object or Configuration Lifecycle Management are often used differently across departments and vendors.
The CPQ-SELECT glossary contains 110 definitions grouped by subject. It provides English equivalents, distinctions and related terms where appropriate. The purpose is not terminology for its own sake. Precise language prevents teams from agreeing on a word while expecting different processes, objects or system responsibilities.
Selection moves from orientation to evidence
Generic requirements catalogues are easy to create. Reliable suitability assessments are not. Public product information can support orientation, but it cannot prove that a solution fits a company’s product logic, process classes, data landscape and operating model.
- Clarify the task: business objective, scope, user groups, channels, product and process classes, complexity, result objects, pricing responsibility and target architecture.
- Build a class-consistent longlist: compare only solutions that can plausibly assume the required system role and exclude architectural mismatches early.
- Use a transparent shortlist: assess modelling, integration, security, deployment, governance, economics, lifecycle and exit readiness with weighted criteria and explicit evidence levels.
- Design the proof of concept around critical end-to-end scenarios using real product data, rules, prices, documents, handovers and boundary cases. A scripted demo is not a proof.
- Separate proof of concept from pilot: the PoC demonstrates critical feasibility; the pilot tests whether people, governance, data supply, operation and change can work under real conditions.
CPQ-SELECT provides twelve public clarification fields for this preparation. Project-specific priorities, weightings and vendor assessments remain part of a confidential selection process and are not published as a universal ranking.
Provider register: a research starting point, not a ranking
The provider register lists companies and brands alphabetically and links to official sources. It is deliberately broad enough to reflect the adjacent worlds of CPQ, technical configuration, lifecycle, engineering automation and visual configuration.
Inclusion confirms only that a relevant and verifiable market presence was identified at the stated review date. It does not confirm functional completeness, implementation quality, financial stability or suitability for a particular company. Providers are not assigned stars, scores, quadrants or paid positions.
A useful shortlist always starts from the required system class and architecture. Only then does the provider register become a sensible research instrument.
Ten structural lines of market development
CPQ-SELECT follows structural change rather than short-lived product news. For 2026, it examines ten lines of development: product models as an architectural core; lifecycle management; headless, API-first and event-driven architectures; AI as controlled assistance; more differentiated pricing; analytics and learning loops; visualisation as part of the decision; semantic interoperability; permeable system boundaries with explicit roles; and exit readiness as a quality of architecture.
These developments are not vendor forecasts. Their relevance depends on whether they improve manageability, traceability, economic impact and the ability to change the architecture deliberately.
Platform roles remain deliberately separate
CPQ-SELECT
Structures market roles, system classes, terminology, provider sources, selection questions and long-term developments.
wuepping.com
Provides deeper executive insights on strategy, modularisation, product architecture, readiness, data models and implementation approaches.
03Dr. Wüpping Consulting
Supports company-specific strategy, architecture, selection and transformation projects. The consulting role is separate from the editorial platform.
NEUTRALITY
CPQ-SELECT does not rank vendors, publish scores, accept paid placements or replace a company-specific assessment. Differences are described through tasks, objects, architecture questions and verifiable evidence.
How to use CPQ-SELECT
- Start with the market overview to define the relevant tasks, perspectives and result objects.
- Use the system classes to identify the plausible solution categories and combinations.
- Clarify terminology with the glossary before drafting requirements or conducting workshops.
- Use the selection criteria to prepare longlist, shortlist and proof-of-concept evidence.
- Consult the provider register for official sources only after the required system role is clear.
- Use the ten structural lines of market development summarised above to test whether the target architecture remains maintainable and open to change.
Editorial status: August 2026