Solving Configuration Problems with SAP VC Technology
Variant Configuration Multi-Level Design
One of the greatest performance benefits seen during my time a VC consultant was with switching from a single-level configuration to multi-level configuration for a multi-sectioned product. In some cases, initial loading time for the model dropped from over 30 seconds to less than 3 seconds! Whether you’re configuring different groups of panels, pipe segments, or any other repetitive component, it can make a world of difference in both maintenance and performance when designing an efficient model.
Often what you’ll see, as a first attempt at tackling this kind of solution, is one KMAT at the top level of configuration containing all the possible characteristics in a single class. Say that you had a product with anywhere from 1 to 100 configurable components that share similar a dozen qualities; in a single-level design you would have to store these values in enumerated characteristics (e.g. LENGTH_001, 002, etc.) to support the maximum allowed components for a given configuration. Even if you have just a dozen features for a configured sub-component, you’re already looking at 1200 unique characteristics without counting any additional global data you may want to capture.
Now, consider taking that bloated top-level configuration and breaking it out into multi-level. You would have a few characteristics at the top configurable material (let’s call it VC_ASSEMBLY) that are global and apply to all items. The Bill of Materials for that KMAT would contain 100 line items of a single component KMAT (we’ll call it VC_COMPONENT). This component KMAT has its own class of characteristics that describe it: Length, Width, Height, Color, etc. The BOM may look like this:
Since each component KMAT is its own instance in configuration, enumeration is no longer necessary. You’ve gone from over a thousand characteristics to roughly a dozen with just one design change. Imagine all the dependencies and relationship logic you would have had to write for those 1000+ characteristics if they were all within the same level. The performance benefit at this point would be improved by many multitudes. In addition, by creative use of constraints, maintenance for this model will be far easier. Rules that would need to be written in hundreds of lines can now be written as just one or two lines in a constraint, for example. Passing data between levels is a simple matter of using a constraint between classes or, to pass down a value, using $PARENT and $SELF syntax in a procedure.
With the use of selection conditions on the BOM, you can also control how many instances appear for a given configuration. Let’s say we tie the BOM position number of the line item to a “Number of Instances” characteristic. Now, rather than loading all 100 instances at once, you can quickly enter configuration with just the bare minimum characteristics loaded to support your model; dynamically changing the number of component instances as needed. As a result, the final CUOBJ (configuration values) information saved to the SAP database will end up being much smaller than all 100 instances being stored each time.
There are of course many more levels of detail I could go into on this topic and many tricks of the trade that will make multi-level models an even more elegant design. For now, I hope I’ve given you a glimpse into how multi-level design improves both performance and maintenance within a model. For numerous configuration items with like-features, it’s a powerful option to consider.