In my day-to-day work I deal a lot with complex, variant-rich products. In the context of PLM and variant management, the question then arises: how do I describe a product with possibly billions upon billions of variants as simply and efficiently as possible?
Trying to list and spell out the individual variants one by one would be completely inefficient. If a product can have billions upon billions of possible variants, that would take a very long time.
So we need ways to describe variant spaces. And this is where the problem already starts:
- What exactly is a variant space?
- How can you make a variant space tangible and easy to grasp?
When I talk about a variant space, I (normally) mean a particular set of product variants (or variants of my “system of interest”).
Cars, for example: you can buy them in different variants: white, green, blue, with or without a sunroof, station wagon, sedan or convertible.
…and now let’s imagine a parking lot full of such cars 🅿🚗🚘
In bureaucratic German, people sometimes like to talk about a parking “space” (Parkraum), so the analogy to a variant “space” is obvious 😉 In this parking lot, similar variants stand close together, and dissimilar ones further apart. So the red ones next to each other, the green ones next to each other, and the blue ones too.
The next row of parking continues in the same way, again with the red, green and blue cars next to each other. But the first row holds only the station wagons, the second row the sedans, and the third row the convertibles.
In our parking space we have now already mapped two “dimensions”: color and body type. Every property (e.g. color) that can differ from vehicle to vehicle (red, green, blue) is its own dimension in the variant space.
The next property could be the sunroof. A car either has a sunroof or it doesn’t (= two values: present or not present). Luckily we can still extend our parking space upwards, so we quickly build a two-level parking deck: one level for each value of the property. The cars without a sunroof go on the upper level, the cars with a sunroof on the lower level.
If I now talk about red station wagons with a sunroof, I can narrow down, in this three-dimensional (variant) space, exactly the region where all vehicles matching these properties are parked.
And can every parking spot in this garage actually hold a car? No, not quite.
After all, convertibles with a sunroof don’t really make sense, do they? The row where the convertibles stand on the upper level simply stays empty on the lower level. In practice, people then talk about buildability conditions, relationship knowledge (in SAP) or simply constraints. These “rules” describe which product variants are possible or not possible. These rules don’t have to be based on technical reasons; they can also be set for sales reasons or other considerations. Maybe, to optimize production, white station wagons should only be offered with a sunroof.
By the way, instead of “properties”, people sometimes talk about “variation points”. And of course, the vast majority of products have more than three properties or variation points (besides color, body style and sunroof also engine power, comfort seats, premium or standard navigation, auxiliary heating, and so on).
Real parking lots (and garages) can of course not be built in more than three dimensions (not in our world, at least — I have yet to see a four-dimensional parking garage) – but variant spaces are fortunately only logical constructs and can, in principle, be described in any number of dimensions.
Back to everyday project work. How do I deal with handling multi-dimensional parking garages, pardon, variant spaces? It depends on the task, of course. Ultimately, a variant space is a set*, and everything that the mathematics of set theory has to offer can be applied to variant spaces as well. Boolean algebra, calculating with sets, and so on.
*Is a mathematician reading this? I’m not one, and I’m grateful for corrections or additions 😊
Now, formally correct mathematical expressions aren’t everyone’s cup of tea (mine only depending on my mood). Fortunately, in my projects it is usually enough to present the problem and the solution visually. By reducing the variant spaces to two-dimensional circles (…potatoes, cucumbers, misshapen tomatoes…).
I’ve done it this way for a long time – at some point I learned that this form of representation also has names in mathematics: Euler diagrams, Venn diagrams.
The set representation for vehicles with a glass sunroof that also have an auxiliary heater could then look like this, for example:
Venn apparently managed to show that, in a similar way, any number of sets (= any number of dimensions of the variant space) can in principle be represented in two dimensions. In practice, showing a handful of sets has been enough for me in every project so far, but it’s good to know there is still room to grow 😉
Based on such representations, I can show working principles in my project work, for example describe algorithms for how variants are consolidated, how configurators are fed, which components or which software are needed for which variant, and much more.
And that much more efficiently and understandably than with verbal descriptions or complicated, mathematically correct expressions.