It used to be that product variant management was done using CPQ tools (Configure, Price, Quote) which allowed users to resolve a product configuration according to a set of rules applied to the product platform’s existing features, options, and usage conditions. The idea was to eliminate any custom engineering work while providing manufacturing with the right BOM (Bill of Materials) for a customized product. A good example of this is the use of a car manufacturer’s website to let customers configure their cars. The series of choices are dynamically arranged based on what the customer already selected. If you chose a basic model of a car, you may no longer have the option of choosing features like heated seats. In a different scenario, a CPQ tool may identify what parts of the desired configuration do require custom engineering. For example, a central air conditioning system where the air handler, the condenser, the vents, and the thermostat are off-the-shelf, but the air ducts must be designed to fit the house’s specific layout and architecture. The goal of CPQ tools is to minimize the time between ordering a custom product and manufacturing shipping it.
Today product complexities driven by pervasive connectivity, increasing software content, and a high degree of customization force OEMs to consider the basic tenants of variability management much earlier in the product lifecycle. These are cases where managing the variability built into a product platform requires a degree of technology sophistication on the part of the user beyond what typical CPQ tools require. For example, the concept of variability is often used during numerous design phases and within various design representations to explore what is possible from a technology perspective. Since CPQ tools were not designed for this purpose, engineering teams default to using complex spreadsheets. That is a source of much pain due to the lack of data model enforcement, traceability, revision control, change process, and not knowing which spreadsheet is the one that matters in a specific case. Even if the spreadsheet process works, it is open to human error and does not provide a path for connecting the results with the CPQ tool users.
Aras has invested considerable time and resources researching these issues with customers over an extended period. This led to several conclusions that were incorporated into our latest application, Aras Variant Management, and they are all worth pointing out.
Variability resolution logic should never be implemented as part of the product breakdown structure that needs to be resolved. The breakdown structure is any product representation that includes definition of all variant points and related components. A breakdown structure could be a representation of a product at the level of requirements, functional breakdown, architectural breakdown, or a physical implementation including mechanical, electronics, and software. Variability resolution logic and the product breakdown structure are two different data models, and by managing them separately one can develop a configuration logic methodology—rules, features, and options—that can be applied to multiple sets of design representations with variant components. This means that the rules themselves become a reusable OEM asset. It also means that rules and breakdown structure development processes can have their own lifecycles, revision controls, change management, and approval workflows.
An independent variability logic applies the same set of rules to each of the RFLP (Requirements, Functional, Logical, and Physical) design representations, individually or together. For example, by building a breakdown structure that reflects a system functional breakdown one can define the structure and the related variant components in a way that allows targeting of these functions to a multiplicity of implementation domains. This means that the same set of variability configuration rules can be applied to a system-level functional breakdown to distribute its allocation between the mechanical, electronic, and software implementations. That is a powerful concept for MBSE (Model-based Systems Engineering) initiatives because it extends product variability methodology all the way back to the design exploration stage of the product lifecycle.
Information that results from the resolved breakdown structure—a variant— is also key to making variant management methodology relevant to every stage of the product design lifecycle. In a typical CPQ scenario the output of the configurator is meant to feed CRM or MRP systems. But when variability management is applied earlier in a design cycle the desired output is often to inform, evaluate, and resolve technology issues that drive definition of the individual variant components, groups of these components that define sub-systems, and the variability configuration rules. That may involve no data generated at all other than a temporary view of the target configuration, a set of system model elements, a set of the related requirements, a filtered content of documents, and others. The flexibility of determining the type of the resulting data is key to extending variability methodology throughout the organization.
Finally, flexibility to set the context of the variability resolution without changing the rules or the breakdown structure is important as well. For example, over time, details of the rules or of the breakdown structure will evolve and therefore variability resolution executed a month ago may yield different results than one executed today. While the default of this type of context is typically set to the latest version of rules and structures, it may be critical to select an earlier date to be able to compare how changes of the rules and structures affect the variant resolution. That type of context setting is critical, and it is only possible if the underlying data is subject to the lifecycle and traceability services.
There are some of the aspects of variant management that make the methodology applicable beyond the traditional focus of the CPQ tools. What is important is that all of them require services of the underlying PLM platform including traceability, revision control, change management, access control to the data, and others. Therefore, the latest Aras Variant Management capability built on the Aras low-code PLM platform is an important step towards helping OEMs manage ever increasing product complexity.
Visit www.aras.com to learn how Aras Variant Management application helps you efficiently manage product variants.