Cancel
Showing results for 
Search instead for 
Did you mean: 

Product Variant Management: Delivering the Variability Your Customers Demand

Enthusiast
Enthusiast


product variant managementMy colleagues have previously discussed BOM management at a high level and introduced BOM configuration management, including product variant management. I’d like to dive deeper into the topic– discussing the demands and considerations of supporting increasing variability across your product offerings.

 

Increasing Expectation of Product Variability

Customers expect and demand not just a product that meets their functional needs, but also one that is tailored to specifically what they want. This includes style, color, special features and conveniences of their choosing.

 

Regardless of whether you make it your business to predict and offer the variety that your customers demand with specific carefully targeted product variants, or if you allow your end customers much more flexibility in the exact features and options they elect to have, managing this range of offerings efficiently as part of your product definition is a must.

 

The Challenge of Choice


product variant management challengeManaging a distinct Bill of Materials (BOM) for each variant of a product you wish to offer to the marketplace may be feasible if you have a few, or a few dozen, or even a few hundred product variants. However, as you progress along that range you will quickly find that you are spending a disproportionate amount of time managing and keeping these many configurations updated as the product evolves instead of using that energy to innovate better products.

 

Leveraging the Power of Commonality

For a given type of product, there is usually an overwhelming percentage of the Bill of Materials (BOM) that’s common across many, most, or all product variants. Harnessing this knowledge to formally manage variability directly within the Bill of Materials (BOM) allows great efficiency in defining and managing your product over its lifetime.

 

Product Architecture Drives Products across Platforms and Generations


product variant management architectureOne way to recognize and reuse product knowledge as products evolve and new generations of products are introduced is to manage a template of product breakdowns that describe the functions, systems, logical elements or other breakdowns that are common across products or generations of products.

 

This establishes a framework for reuse, product planning, and accountability for completeness of product definition relative to the expected content and variability. Often architectures formalize a corporate standard for how products are organized, planned, and delivered which enables a repeatable measure of completeness and maturity as a product definition evolves.

 

Formally Manage Your Product Portfolio

Introducing your product decisions to the marketplace happens via defining and marketing your product suite to your customer base. These decisions flow from Product Planning through to Engineering and Production—it’s important to have a formal representation of this product breakdown available to guide and account for work throughout the process. Reuse and applicability are the key concepts here:

 

Reuse from the standpoint of being able manage a corporate set of features that can be selectively leveraged as new products and new product generations are introduced;

 

Applicability from the standpoint of ensuring that within a broad library of features that are offered across the entire product line, there is a limited subset that is relevant and allowed for a given product.

 

Supporting both of these concepts to guide what the user is exposed to and is expected and allowed to leverage offers great power in managing variability across a product portfolio.

 

Engineering on Demand

Even after carefully defining and presenting the variability that you wish to offer to your customer base, you may deliberately allow customers to configure orders for which not all of the engineering definition is complete. In this case, typically for specialized products that have a range of dimensional variability and geometric or engineering dependencies, the variability intelligence you manage includes these engineering heuristics. You Engineer-to-Order some percentage of the parts for an ordered configuration on demand after receiving the order.

 

Voice of the Customer drives Product Decisionsproduct variant management customer voice

Ultimately, product decisions are made based on what customers demand and will pay for to make the product successful and profitable. Often there is a disconnect between capturing customer demands and how these get evaluated and approved in the product planning cycle from how this gets communicated and incorporated within the engineering product definition. It’s desirable to allow autonomy among the Product Managers / Product Planners and the Engineers and Designers, but to enable a seamless handoff and ability to perform impact analysis and accountability throughout this process.

 

Separating Product Variability from Product Engineering

Commonly, variability is recorded against the product content and is inextricably tied to the engineering definition of the product. That is, options and configurator constraints are defined using nodes in the Bill of Materials as the context for performing this work. This leaves little autonomy for the Product Managers--who are doing early product planning to reflect the voice of the customer and determining what features will be offered, and how the product suite will be broken down for the marketplace. Product Managers need the ability to formally consider different features to be offered, review, evaluate, whittle down, and finally decide what options should be offered to the market--all before engineering needs to get involved, and without the need to expose Product Management to the engineering definition of the product at all.

 

Why Configurator in PLM?

PLM is typically the gold source for the engineering definition of a product. Often the upstream market-driven decisions that drive engineering activities are very disconnected from the engineering work that satisfies these decisions. Connecting these parts of the process and enabling the same level of configuration management rigor and control for product variant management that is typically exercised over the engineering product definition enables the entire Integrated Product Definition to be managed consistently in coordination.

  

 

About the blogger: I am a 10-year member of the Teamcenter Product Management team responsible for Integrated Product Definition. I enjoy working with customers across all industries to understand how SPLM tools are helping to define their products and run their business.

Comments
Theorist

Hi, I am not able to put my thought altogether.. but let me try.

Confirurable Products! How one should one have the structure of Master EBOM for them? How deeper one should go on deciding the modules which will finally form the varaint? Does having configurable EBOM is something which needs to be decided at the begining only? or someone can derive it from current practice (of design intent EBOM) ? How much complexity is the real complexity? Such questions are on my mind on today where I will be working on having Configurable EBOM of an automobile (which has systems, sub-systems, features, color combinations & more complexities as I dig deep into). Whether the success of configurable EBOM lies in its modular structure or the strong configurator?

After going through the literature available across internet on Configurable EBOM, one fine day I started working on deciding the MODULES of a products which will configure another varaint/s from master EBOM. And at the end of day I was done with nothing. What more questions I got are - Whether Platform strategy needs evolvement (read - product platform - then - Modular platform - then - assembly kit structure) to reach at the level wherein we can have configurable master EBOM structure or someone can directly think of having modular structure EBOM from current junk data which is totally design intent ?

Lastly I want to know from your personal experience that whether a product having near about 6500 parts, 20 defined systems, 158 derived sub-systems, 205 features (max. possible) & say 25 combinations of colors - is a complex one ? Can PLM itself can be able to get the configurator for this senario? Will it be advisible to have configurable EBOM for this case when we need to manage about 20 varaints & keep kitting for more varaints in future as concepts?

I might sound like asking questions only, but that is what bothering me here when I read your blog on varaint management. I am having more questions but will keep them with me until I decide on something.