Complexity Management for Variant-Rich Products
Modularization & Variant Management
Variety in the Market. Simplicity Within the Organization.
We connect customer needs, business objectives, the product portfolio and product architecture so that external variety does not translate into uncontrolled internal complexity.
IMPACT
Reuse
Leverage platforms, modules and standards across products and generations.
Complexity Costs
Reduce internal variety without losing market-relevant differentiation.
Configurability
Create clearly defined variant spaces as the foundation for CPQ and end-to-end processes.
Modularization Is Not an End in Itself.
A modular product system only creates value if it makes a measurable contribution to business objectives: through greater reuse, lower complexity costs, shorter development and delivery times, improved innovation capability and product variety that customers are willing to pay for.
We do not view modularization and variant management solely from the engineering perspective of product structure. Our starting point is customer needs, market segments, strategic objectives and the question of which external variety creates value – and which internal variety places an unnecessary burden on engineering, procurement, production, logistics and service. Typical triggers include organically grown product portfolios, declining reuse, increasing part and process diversity, and unclear boundaries between standard products, configuration and engineering.
Combining the market and company perspectives provides clear guiding principles for the portfolio, platforms, modular product systems, interfaces and permitted variant spaces. The objective is a product architecture that enables market-relevant variety while supporting reuse, standardization and configurability.
Translating this architecture into characteristics, rules and sales logic is addressed under CPQ & Product Configuration. Consistent representation in product data models, bills of materials, master data and core systems is addressed under Product Structures · Data Models · System Architectures.
From Customer Needs to a Common Product Language
Many companies know their customers well, but this knowledge is dispersed across sales, product management and engineering. Effective modularization requires a common language: Which tasks does the customer want to accomplish? Which performance levels drive the purchasing decision? Where do genuine preferences and trade-offs exist? Which differences are technically relevant but provide no additional value to the customer?
This market perspective is translated into performance characteristics, functions and technical solutions. The result is a traceable chain from customer needs through the portfolio and product logic to a modular, configurable product architecture.
Structure the Portfolio and Define Clear Boundaries
Before modules are defined, it must be clear what will be offered and how orders will be fulfilled. We structure product portfolios and establish clear boundaries for each product family: What is standard? What can be selected? What is assembled, manufactured or configured to order? Where does engineering begin? Depending on the business and product model, we distinguish between MTS, PTO, ATO, MTO, CTO, CTO+ and ETO. These Process Classes do not form a linear maturity sequence; they represent different combinations of make-to-stock production, selection, assembly, manufacturing, configuration and engineering.
- MTS: Pre-manufactured standard products and inventory.
- PTO: Selection or combination of existing products and materials.
- ATO: Order-specific assembly from approved components and modules.
- MTO: Order-specific manufacturing based on defined product and process structures.
- CTO: Fully rule-based configuration within an approved solution space.
- CTO+: Configured solutions with clearly limited engineering content.
- ETO: Genuine customer-specific engineering outside the controlled variant space.
Platforms, Modules and Interfaces
A platform enables reuse across products and generations. Modules structure functions and variants. Clearly defined interfaces limit the impact of changes and allow technical solutions to be standardized or differentiated selectively.
We do not view modern industrial products solely in mechanical terms. Product architectures combine mechanics, electrical systems, electronics, controls, software, parameterization, documentation and services. These domains follow different lifecycles, cost structures and rates of change, yet must still interact within a common product logic.
Optimize Variants and Make Standards Effective
Variant reduction does not mean removing as much as possible from the portfolio. The key is to distinguish between external market variety and internal technical variety. The objective is to preserve customer-relevant differentiation while reducing the number of different technical solutions, parts, processes and data objects behind it.
- Identify low-runners and duplicates.
- Define high-runners, standard modules and preferred solutions.
- Leverage transfer and reuse potential across product families.
- Deliberately balance overspecification against economies of scale.
- Manage phase-in and phase-out through a product and module roadmap.
Variant Management Across Product Generations and Lifecycles
Variant management does not begin with a one-time cleanup and does not end with the release of a product generation. It creates transparency across the creation, approval, use, cost impact, modification and phase-out of variants and connects decisions across product management, engineering, sales, operations and service.
- Create transparency around variant creation, reasons for deviations and new requirements.
- Evaluate external market variety and internal technical variety separately.
- Actively manage the approval, market introduction and use of new variants.
- Actively manage high-runners, preferred solutions and justified exceptions.
- Manage changes, replacements, migrations, phase-in and phase-out along product and module roadmaps.
- Establish KPIs and responsibilities for variant diversity, reuse and lifecycle management.
Design for Configurability from the Outset
A modular product system is not automatically configurable. For CPQ and Product Configuration, the market and product perspectives must be connected consistently: customer requirements are translated into performance characteristics, which in turn define permitted product options, modules and rules. The resulting solution space must be technically valid, economically manageable and understandable for both sales teams and customers.
This connection forms the bridge to CPQ: modularization structures the solution space; Product Configuration and CPQ make it usable throughout the sales and order process.
Manage Profitability and Complexity Costs
Economic viability is not a final check performed after developing the modular product system. It must be managed before launch, during concept development and throughout the entire lifecycle.
- Potential analysis: What impact do we expect on costs, revenue, time to market and capacity?
- Complexity costs: Where do additional variants, parts, rules, documents and processes create effort and cost?
- Module and variant profitability: Which variants contribute to market and earnings objectives?
- Roadmap: Which modules and variants will be introduced, harmonized or discontinued?
- Governance: Which KPIs and approvals prevent the modular product system from growing out of control again?
It is important to distinguish this from CPQ pricing. Here, the focus is on portfolio, product and complexity profitability. CPQ pricing addresses concrete price determination within the quoting process, including price components, terms, discounts, margins and approvals.
Complexity Management Across the Lifecycle
Prevent
Product strategy, portfolio structure and clear boundaries prevent unnecessary variants from arising in the first place.
Reduce
Existing variety is streamlined, harmonized and economically consolidated through standards, preferred solutions and reuse.
Control
Roles, maintenance processes, KPIs, approvals, tests and releases keep product and variant logic stable over time.
Results
- A portfolio with clear boundaries between standard products, configuration and engineering.
- A modular product architecture with defined interfaces and measurable reuse.
- Less internal technical variety while retaining market-relevant external differentiation.
- A robust foundation for Product Configuration, CPQ and end-to-end data flows.
- Governance and KPIs for the long-term maintenance of the modular product system.
Typical Project Pattern
Initial Situation
Organically grown product portfolios, unclear boundaries between standard products and engineering, high part and process diversity, and limited transparency regarding high-runners, low-runners and reuse.
Approach
Structure the portfolio and Process Classes, assess the variant space, organize platforms and modules, define interfaces, and validate a configurable target model using real product families.
Impact
Fewer technical variants, clearer standards, greater reuse, a controlled CTO/CTO+ solution space and a robust foundation for CPQ, bills of materials and lifecycle governance.
Frequently Asked Questions
How Do We Distinguish Pragmatically Between CTO and ETO?
By defining clear boundaries for each product family: a controlled, tested variant space on one side; clearly defined engineering content and genuine new development on the other.
When Should We Reduce Variants – and When Should We Develop a New Platform?
Variant reduction makes sense when variety provides little customer value or solutions are redundant. A new platform is appropriate when reuse, interfaces and technology paths need to be reorganized across multiple product generations.
How Do We Prevent Complexity from Growing Again?
Through clear accountability for the portfolio, modules, characteristics and rules, supported by approvals, KPI-based management, release processes and testing.
Discuss Your Modularization, Variant Management or Complexity Challenge
In an initial 30- to 45-minute conversation, we clarify the current situation, objectives, scope and key risks. We then assess whether a focused initial analysis, a series of target architecture and concept workshops, an independent review or an early pilot is the right way to proceed.