My 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
Managing 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
One 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 Decisions
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.