An ever increasing number and wide variety of manufacturers manage variants today. Products can have different capabilities, characteristics, colors etc., and choosing one object over another can influence the choice of subsequent parts and materials. The choices you make at the start determines the final product but also the possible variants of the product.
Over the years, we have met with a lot of companies, and many were not always managing variants very efficiently.
These companies typically use:
Tribal knowledge (yes this still exists!)
Spreadsheets (surprise!) with genius macros that took somebody months to build
“Niche” configurator applications that don’t have product data embedded but need to be incorporated to it
We often also see companies using configurators way downstream in ERP or Sales order configurators/CPQ configurators
We also see people managing variants and options in the Mechanical CAD domain and not electronics or software, separately in silos
The result of that practice is:
Many hours of hard labor where people are manipulating data in spreadsheets; copying and pasting stuff from one place to the other or running around looking for the person that knows. And at the end of the day, these types of processes do not scale, do not allow a company to be nimble, and really hurts their top line.
So, is there a better way to do Variant Management?
If you think about the product lifecycle, the product definition itself, what you are building and planning to offer constantly evolves from the moment it is conceived to the moment it is supported in the field.
Multiple changes can and do happen to the product between these points in time. Change also influences the variability of the products. Therefore product definition and variability definition change throughout the lifecycle of the product and one impacts the other.
Let me give you an example:
Say you want to add a specific type, color, or maybe size for a bicycle, that choice impacts the next choice of variants to the product. For instance, if you choose a mountain bike model, your choice of material may include aluminum and carbon fiber while your color choice may be limited depending on which frame you choose. There might be color types that are not easily applicable on aluminum frames or the design team sets specific colors for the mountain bike lines this season. Both relatively simple examples.
Variants are a natural part of a product’s lifecycle where one variant is intricately tied to another. Product families, compatibility of parts, and more affect the viability of the product at the end. Mistakes in variant management can be costly to remedy.
This means you must figure out how to manage variants efficiently.
Let’s look at a simplified example of the aspects of variability:
You have variability definitions, like:
Features, such as frame material, color, and size
Options like lights or brakes and the individual choices you can make
Rules that tell you when these choices are compatible or not; like the frame and color examples above. You can have different reasons to have rules that restrict the possible combinations in your product offering – from functional compatibility to company choice and beyond.
Then you also have the generic structure of the product. Again, if we look at a bicycle, you can break that down into its variable components:
You have the variable components – like the frame and the rear shocks – that act as a placeholder. Then the actual technical solutions and physical assemblies at product level that make up your bicycle. The levels above aggregate the levels below.
Then you can tie a note to that variability definition. In this example, a frame can vary by material size and color. But then you also say what physical part or what type of technical solution are you going to apply to that combination?
If I have aluminum, medium-sized frame in black and red, I use this specific part or frame to build my combination.
These are pieces of defining variability in your product. But what if things change?
Say, I add a color to the mix. Now, just by adding one color, I am adding many combinations. And just because I add a color, it doesn’t mean I can produce the product in that particular color. I still need to figure out how I am going fulfill the combinations that resulted from adding that color.
Ideally, my variant management solution should tell me that I have missing solutions for new combinations. Then appropriate team members can say; “ok, for the new color combination, I now have worked on and completed a specific technical solution”. Which in this case could be a test result showing the paint from a particular supplier is compatible with the frame. The variables, rules, documentation, and new materials are added to the configuration options that in the end fulfills the required combination.
Logically handling components of Variant Management
The philosophy inside Minerva PLM is variability should be defined in one place, so people are managing not only the variants, but the rules and drivers behind component selection in an organized fashion. Additionally, maximizing visibility into the rules and allowing the system to take over compliant selection creates a reliable process with reduced risk.
What if you could stop defining variability at a very specific structure level, and define variability of any part or object independently of where a part is going to be used?
This would empower you to centralize variability definition and then the product/requirement structures you need throughout the lifecycle can use that same variability definition.
The resulting definition would be a frame with the total variability view that can be logically applied with rules when there are requirements and there is functional breakdown, logical breakdown, and an EBOM and an MBOM for the frame and the bicycle itself – the variability can be applied to all these places.
If you would like to see this in action or learn more about how we do Variant Management in Minerva PLM, please reach out.