Variant Management: Where Variants Come From, What They Cost and How to Control Them

Variant management rarely fails for lack of intent. It fails because variants are created in one place, the costs land in a second, and the decision to keep or drop them is taken in a third. An initiative that only cuts the number of articles often falls back to the old state when rules and accountability for new variants are missing. This article shows where variants actually come from, how to make their cost visible, and why the data side decides the outcome even though it appears in almost no project plan. That data side is where a PIM earns its keep.

What is variant management?

Variant management is the systematic handling of product variety across the entire product lifecycle, from the moment a variant is created in engineering through to its discontinuation and the spare parts supply that follows. It covers three tasks: reducing unnecessary variety, making necessary variety manageable, and controlling the creation of new variety. A useful distinction is the four levels on which a variant can be described: product, assembly, structure and material level. The classification goes back to Herlyn (PPS im Automobilbau, Hanser 2012, p. 76 ff.); a German-language summary is available in the Wikipedia entry on Variantenmanagement). The same variant looks different on every level, and that is exactly where the friction between sales, engineering and production originates.

What is the difference between variant management and product variety?

Product variety is the state, meaning the number and spread of variants in the portfolio. Variant management is how you handle it. Confusing the two leads to a widespread false assumption, namely that fewer variants are automatically better. Variety only becomes a problem when it generates cost that no customer pays for.

Where variants come from

Before reducing anything, look at how variants arise. Five drivers can be distinguished in practice, and they demand entirely different responses.

Driver	Typical trigger	Correct response
Market-driven	Customers genuinely require different variants, such as power classes or connection types	Manage it. Modularisation and a configurable structure, not deletion.
Regulatory	Country approvals, labelling obligations, certificates, language versions	Manage it, mostly as a data variant. Rarely creates technical complexity.
Sales-driven	A single customer asks for a deviation, it gets promised, and it becomes a permanent variant	Control it. An approval process for new variants including a commercial assessment.
Legacy	Predecessor generations, acquisitions, leftovers nobody discontinues	Reduce it. The only driver where deletion really is the right answer.
Engineering-driven	Similar parts are designed again because existing ones cannot be found	Control it preventively. Classification and reuse search, not portfolio cuts.

The practical consequence is uncomfortable: legacy and sales-driven variants are the most obvious candidates for deletion. Consolidation is possible for the other drivers too, but it has to account for market requirements, technical dependencies and regulatory obligations. Cutting indiscriminately there costs revenue without touching the cause.

What variants really cost

The core problem with variant cost is allocation. The extra cost of a rarely sold variant arises spread across engineering, procurement, logistics, production, documentation and costing, yet in standard costing it hits all products equally. Fraunhofer IPA describes the effect precisely: so-called exotics are cross-subsidised by fast movers, and without transparency on actual variant costs the benefit of an individual variant cannot be assessed at all (Fraunhofer IPA, German only). That is exactly why unprofitable variants survive so long. They never appear as unprofitable in any report, because the cost they cause disappears into an overhead block. Taking variant management seriously therefore starts with process-based cost allocation, not with a deletion list. How large the lever can be is shown by one fully calculated case from the machinery sector. At a mid-sized manufacturer with up to 20,000 parts per machine, fewer than 100 machines per year and a product life sometimes exceeding 40 years, standardising 55 percent of components reduced the total component count by 51 percent. The consultancy estimates the follow-on effects at roughly 25 percent less initial engineering effort and 10 percent less change effort across the lifecycle (Modular Management, German only). These figures come from a single consulting project and are not an industry average, but they show the order of magnitude in question.

Reduce, manage or control? A decision aid

This three-way split matches the classification established by Wildemann: reduce existing complexity, manage unavoidable complexity, and control the creation of future complexity (TCW), currently available in German only. In practice that split lacks an assignment aid. The following matrix provides one:

Situation	Wrong response	Correct response
The variant sells but causes disproportionate cost	Delete it	Adjust the price or rebuild it on a modular basis. Discontinue only if both fail.
The variant barely sells and has no strategic role	Keep it because one customer once wanted it	Discontinue with a successor rule and a spare parts commitment.
The variant differs only in labelling, language or packaging	Set it up as a separate technical variant	Manage it as a data variant. One product, several output expressions.
Variety arises from customer requests during ongoing sales	Agree to every request	An approval process with cost assessment, plus a configurable kit for the standard case.
Similar parts get designed repeatedly	Reprimand engineering	Introduce classification and feature search so that reuse is faster than new design.
Variety arises late in the process (colour, label, packing)	Vary early	Move the variant determination point later and shift variety into the data.

When is a variant not a variant but merely a data record?

This question is almost never asked in variant projects, and it carries the largest lever. A variant can be treated as a pure data variant when the physical product, the manufacturing structure and the packaging bill of materials stay unchanged and only sales, language or target-market information differs. In that case it creates no technical complexity but data complexity. The distinction matters because the two require entirely different answers. The distinction needs that precision because it does not hold automatically: a label or a packaging unit can itself be part of the bill of materials and then changes production or logistics processes. Assess case by case rather than by attribute type. Technical variety is fought with modularisation and common parts. Data variety is not fought at all. It is organised. A product with a dozen country expressions is not a case for engineering but for a data model that manages language and country expressions as views on the same record rather than creating a dozen articles. Confusing the two means cutting at the wrong end, reducing technical variants the market needs while still carrying redundant article masters.

The data side: features, bills of materials, classification

This is where the real gap sits in most variant projects. Modularisation is decided, kits are defined, and a year later the structure has not reached sales. The reason is almost always the same: the new order exists in presentations, not in the data model.

A variant feature is not a master data feature

The feature set used in engineering and the sales-side feature in the product data model rarely match. Engineering needs tolerances, material values and production parameters. Sales needs power classes, connection types and approvals, meaning the attributes a customer actually searches by. Both views have to be mapped onto each other. Without that mapping you get attribute sprawl, duplicates and shop filters nobody can work with. How to measure and improve feature quality is covered in our article on data quality.

Four bill-of-materials forms and what they say about your configurability

The BOM form is a good indicator of variant management maturity, because it shows how variety is represented technically. Classic literature distinguishes common-parts, plus-minus, base-type and derivative bills of materials, among others. For assessing configurability, the following four-way split has proven useful in practice, ordered by the amount of variety each can carry. It is an orientation aid rather than a closed taxonomy: further configurable and constraint-based approaches exist alongside it.

• Common-parts BOM: shared parts are managed once, variant-specific parts separately. Simple, but unwieldy with many variants.
• Plus-minus BOM: a base BOM is extended with additions and reduced by omissions. Works with manageable variety.
• Matrix BOM: parts are assigned via a feature matrix. Compact, but hard to maintain once dependencies between features appear.
• Rule-based or configurable BOM: parts and assemblies are derived from attributes and dependencies through a rule set. A typical approach for very large variant spaces, because not every combination has to be maintained individually.

A reliable warning sign is the frequent manual reworking of bills of materials during order processing. If a maximum structure regularly has to be reduced by hand, the problem is not the BOM but a missing rule set. And once nobody can explain which rule drives that reduction, every product change has become a risk.

ECLASS and ETIM as an ordering framework

Classification standards appear surprisingly rarely in variant management literature, even though they are precisely the instrument for ordering a variant space. A standardised attribute set makes variants comparable, makes reuse searchable and makes product data channel-ready. ECLASS covers roughly 48,000 product classes and more than 23,000 unique properties across four classification levels. The current release 16.0 of 28 November 2025 added, among other things, 995 new classes and 1,253 new properties, and extends material declaration to nearly all classification classes. In the electrical, plumbing and tools sectors ETIM is the more relevant standard: open, free to use, ID-based and built in two levels from group and class, with a data model identical across all member countries. Practically important and rarely mentioned: mapping tables exist between ETIM and ECLASS, partly at class level and partly at property and value level. The current table, ETIM 10.0 to ECLASS 15.0, is no longer restricted to the electrical sector but covers several ETIM sectors. Two caveats belong with that: the tables are available to ETIM member companies in the members area rather than publicly, and each refers to a specific version pair. A mapping therefore substantially reduces the mapping effort, but replaces neither governance nor version reconciliation. For variant management this implies one concrete step that is often skipped: before consolidating variants, check whether your features are based on a standard at all. Without that foundation you are comparing variants by their names rather than by their properties, and then every variant looks unique.

The variant determination point and its data consequences

The variant determination point is the place in the process where a neutral intermediate product becomes a specific variant. The later that point sits, the longer production stays flexible and the lower the inventory risk. That is the commercial side, and it is well documented. Less attention goes to the flip side. Moving the variant later does not move it into nothing. It moves it into the data. A variant configured late needs complete, correct and approved information on labelling, packaging, documentation and target market at the moment of configuration. Late configuration without a robust data model therefore only shifts the problem from the warehouse to dispatch, where it turns out more expensive.

Machinery and automotive set different priorities

Most articles on the topic lump both industries together, even though the effective measures carry different weight in each. The values in the table below are typical orders of magnitude for orientation, not industry statistics.

Dimension	Machinery and plant engineering (CTO/ETO)	Automotive and high volume
Volume per variant	Often single digit, sometimes one-off	High, variety arises through combinatorics
Product life	20 to over 40 years, spare parts supply and contractual service commitments far beyond the series	Model lifetime limited, successor planned
Main cost driver	Engineering effort per order, documentation	Logistics, tooling, ramp-up cost, part count
Most effective lever	Modularisation and reuse in engineering	Kit and platform strategy across models
Data focus	Order-specific structure, certificates, spare parts reference across decades	Feature combinatorics, configurator rules, channel readiness
Typical mistake	Standardisation is seen as a constraint on engineering	Variety is represented in the configurator without reducing part count

For automotive, with its combinatorics of trim lines, engine options and markets, the data side is particularly unforgiving, because every additional feature value multiplies. How Viamedici addresses this sector is shown on the automotive industry page.

The variant outlives the product: spare parts and after-sales

One point that regularly surfaces too late in variant projects: discontinuing a variant does not end the obligation to maintain its data. Spare parts supply, successor part relationships, technical documentation and approval records have to remain available for as long as contracts or regulation require, which in plant engineering often means decades, by which time nobody who originally designed the variant still works at the company. In practice this means a variant reduction does not lower the number of records to maintain in the short term at all. It only lowers the growth. A business case built on immediately falling maintenance effort does not add up. Slower growth and better findability are the realistic outcomes.

Metrics for variant management

Without measures, variant management stays a matter of opinion between sales and engineering. Six metrics that have proven useful:

Metric	Calculation / definition	What it tells you
Variants per million in revenue	Number of active variants divided by annual revenue in millions	A rough indicator of portfolio complexity, best used for internal comparison over time
Slow-mover share	Share of variants with fewer than x sales per year across the portfolio	Identifies the candidate pool for discontinuation
Reuse rate	Share of components used in more than one product	The best early indicator of engineering-driven variety
Share of special orders	Orders deviating from standard divided by all orders	Shows whether the approval process actually bites
Feature completeness per channel	Share of variants with a complete attribute set for the respective output channel	The data metric that decides sellability
Maintenance effort per new variant	Person-hours to create and approve a new variant completely	Translates complexity into money and is the easiest figure to argue with management

Which system holds what?

Variant management is not a systems topic, yet it cannot be implemented without clear system roles. The allocation that works in practice:

• PLM or engineering owns the product definition, technical features, assembly structure and the engineering BOM.
• ERP owns material numbers, the manufacturing BOM, procurement, cost and order-related execution.
• PIM owns the market-facing features, value lists, classification, translations, media and approved states per channel. This is the level on which data variants are managed instead of being created as technical variants. Details in our article comparing PIM and MDM.
• MDM owns the golden record across system boundaries, meaning the single truth on material, supplier and classification.
• CPQ owns configuration rules, pricing and quoting in the sales process. That boundary is covered in our article on CPQ.

What matters is not which system can do the most, but which system is leading for which data object in which lifecycle phase. That decision belongs in writing, with an accountable role per data object. Who fills that role and what they need to be able to do is described in our article on the data steward. On the product side, our PIM system VIA/PIM360° consolidates feature, variant and classification management, while our Master Data Management Software VIA/MDM handles the cross-domain master data.

Six steps to get started

1. Take inventory. List all active variants with volume, revenue and last sales date. Usually that list alone is the first surprise.
2. Assign drivers. Map each variant to one of the five drivers. That separates deletion candidates from cases to be managed.
3. Identify data variants. Flag every case that differs only in labelling, language, packaging or certificate. This group belongs in the data model, not in the reduction exercise.
4. Allocate cost. For a representative sample, capture variant-driven effort on a process basis instead of leaving it in overhead.
5. Standardise features. Align feature sets with ECLASS or ETIM and map the engineering view onto them.
6. Control growth. An approval process for new variants with cost assessment and a named decision authority. Skip this step and in three years the portfolio is back where it started.

Conclusion

Variant management is not a clean-up exercise but an ongoing discipline with two sides. One is commercial: variety arises from five different drivers, and only one of them can be solved by deletion. The other is data-related, and it decides whether an agreed structure ever reaches day-to-day work. Standardised features, a workable rule set instead of manually reworked bills of materials, and a clear split between technical variant and data variant achieve more together than any reduction initiative. And if you only want to measure one thing to begin with, measure the maintenance effort for a new variant. It says more about your complexity cost than the number of your articles.