Product variability is one of the key strategies used by Original Equipment Manufacturers (OEMs) and companies that offer configure-to-order products. This helps to decrease costs, minimize Cost of Quality (CoQ), accelerate time-to-market, and quickly respond to new opportunities with custom solutions. So, it’s important.
Product variants are unique combinations of selected product characteristics that span functional and physical features. Traditionally variability was configured on the level of physical parts using a Bill of Materials (BOM). Today however, most products, like the Apple iPhone for example, are no longer purely mechanical and include electronics and software with variants that are increasingly configured without changes to the mechanical BOM. Here are few examples of products with variants impossible to manage via a strictly BOM-centric approach:
- BMW recently announced the pay-as-you-go availability of heated seats (link) indicating configuration via software only while maintaining the same hardware for all.
- Apple just released iPhone 14 with the ability to route messages via satellite (link) – free for now but pay-as-you-go later indicating configuration via software only while maintaining the same hardware for all.
- Automotive industry is forced to reduce functionality in cars due to a chip shortage (link) indicating configuration via software and hardware.
On one hand the above BMW and Apple examples represent product variants entirely implemented via software configuration – that have nothing to do with the physical BOM which remains the same for all variants. On the other hand, the automotive industry example represents product variants which are a combination of software and physical BOM configurations. In both cases, the software configuration is accomplished in one of two ways: via unique builds specific to the product variant, or via a single build regardless of the product variant that is controlled at run-time via a separately configured feature on/off table (a parameter table).
Today’s typical variant management process involves applying a configuration logic to an already designed 150% physical BOM (one that satisfies all standard features) to generate a variant specific 100% physical BOM (one that is a specific subset of the standard features). This is a well-established methodology based on the standardized product platforms and on libraries of pre-defended modules with standardized interfaces. It is addressed by a Configure-Price-Quote (CPQ) class of tools and is the basic methodology of variant management today:
Fig 1: Deriving a 100% BOM-centric physical variant
So, what’s not to like? The Achilles heel of the CPQ approach is that the configuration logic is very much BOM-centric and therefore focuses primarily on physical parts.
There you have it – BOM-centric variant management is insufficient to manage variability in complex products whenever software is involved, and this is where systems thinking, a holistic approach to analyzing and managing product behaviors, comes in. In these cases, variant management must become part of the system modeling methodology that embraces the Requirements, Functional, Logical, and Physical (RFLP) representations of a design as shown in Fig 2:
- Requirements at various levels of their breakdown
- Functional at various levels of their structure
- Architecture that is specific to implementation domains
- Engineering BOM that is specific to implementation domains
- Manufacturing BOM that is specific to manufacturing sites
Fig 2: A system-centric RFLP representations with traceability to BOM-centric equivalents
But wait, there’s more!
The fact that variability must often simultaneously resolve product structures in multiple implementation domains highlights a unique role of a functional breakdown. This is because a system-level function is not domain-specific, and this neutrality allows it to be allocated for implementation to any domain. In other words, to have a variant resolved across all product representations, it should be resolved using a functional breakdown first. Only then should further variant configuration be resolved in other domains, all the way to the manufacturing BOM.
This is true systems thinking and that’s why systems engineers pay increasing attention to the issue of product variability when using the various Model-Based Systems Engineering (MBSE) tools. This is not easy since the concept of product variability has never been a particular strength of these tools and it is only recently beginning to be seriously addressed with modeling languages like SysML 2.0.
The point is that managing variability solely with physical BOM-centric structures is insufficient for today’s system-centric variants that span multiple product representations. System-centric variants require solutions that are driven by tool-agnostic RFLP product definitions traceable via a tool-agnostic digital thread and managed by modern PLM (Product Lifecycle Management) platforms. PLM is important because in addition to these various product representations, that digital thread must also accommodate countless revisions of the product representations and of the variant management logic as highlighted in Fig 1.
Solution vendors are recognizing the need to expand variant management solutions beyond the traditional BOM-centric CPQ approach. The new Aras Variant Management application helps designers of next-generation products manage complex product configurations across all product representations, engineering domains, and organizational boundaries through formally defined product features, options, configuration rules, and variability of breakdown structures across all product lifecycle stages. This helps you establish a consistent approach to managing variability as an essential element of your product family strategy, giving you an unprecedented flexibility to define product platforms and maximize module reuse, while increasing quality, lowering cost, and shortening time-to-market.
In conclusion, systems thinking is very much part of variant management of complex products. It allows to start defining variability in the earliest phases of design space exploration of the “RFL” of the RFLP and connecting it later to the “P” of the RFLP (a final BOM) via a tool-agnostic digital thread. This methodology does not replace the traditional role of CPQ tools. But it does alleviate CPQ’s Achilles’ heel by expanding beyond the BOM-centric representation to address the needs of all engineering teams.
Agree? Disagree? We’d love to hear your thoughts on this subject.
Learn more about the Aras Variant Management and the benefits of systems thinking.