Business Benefits of a Virtual Tabulation®-Based Configuration Solution

When configuration rules are maintained in separate systems, it is difficult to get a consistent and aligned view on products across the enterprise.

This blog post will explain the benefits of collecting all the rules across the main functional areas of the organization, such as Engineering and Sales, and turning them into a single, complete rule set managed by a single configuration engine.

The Configuration Problem

A product model is a logical representation of a product or service. The product model has variables (also called features or options), and rules linking the variables together.

A fundamental challenge is to support an interaction where a configurator application uses the product model to guide a user towards a valid configuration. Such an interaction is a key part of a CPQ process, in which a product is configured and priced before providing a quotation, or may be exposed on a public web-site, an application on an iPad or a dealer ordering solution.

However, even the most simple question one might ask about a product model, namely, does a valid configuration even exist, is mathematically difficult for a computer to solve. This is unlike other tasks such as sorting a set of data, which is a rather simple problem for a computer to solve. The diagram below illustrates the runtime behavior size of the problem. Unfortunately, determining whether there exists any valid configuration (the so-called SAT-problem) is a known NP-complete problem, meaning that the time to solve it in the worst-case grows exponentially with the size of the product model.

Three Generations of Configuration Technology

Configuration engines all need to solve the configuration problem, i.e., guide a user to select values for the variables that satisfy all rules. They all try to work around the fundamental complexity of the problem by either compromising on the quality of the guidance or finding heuristics that work well for practical cases.

Overall, configuration engines can be classified in the following three main groups:

  • In the 1970’s: Rule-based or production-based systems, e.g. Drools
  • In the 1980’s and 1990’s: Constraint propagation and constraint solvers, e.g., ASP VC + IPC, and constraint solvers, e.g., ILOG, Oracle, Tacton
  • Since 2000: Compilation-based technology, which is what Configit has been developing and evolving ever since

The Configit approach is a two-phased compilation-based approach. In the first phase, we compile all rules into a representation of the set of all possible valid configurations called the Virtual Tabulation® file. In the second phase, the VT™ file is used to support a configurator that can efficiently guide the user to a valid configuration. In this second phase, it is easy for the runtime to provide the answer to the user based on the set of valid configurations because the hard part of the problem has already been solved when calculating the set of valid configurations. This is what we mean when we say we only solve the difficult problem once.

To illustrate the power of VT™ technology, one of our customers has a model with 8,000 features and 1,800 rules, resulting in 1050 possible valid combinations. This VT™ representation of the valid configurations is only 3 MB.

The set of valid configurations is often very, very large. For example, we have customer models with more than 10150 valid combinations which is more than the number of elementary particles in the universe. To perform analysis and validations of such large sets of configurations, it is possible to project the set of valid configurations to a subset of the variables which can then be inspected in, for example, Excel (illustrated below).

Five Areas Benefiting From A Compilation-Based Approach

The Virtual Tabulation® approach offers a number of unique business benefits, five of which are:

  • Full guidance
  • Performance
  • Correctness
  • BOM Validation
  • Optimization

We will cover each of these in more detail in the following.

Full Guidance
The compiled-based approach enables the user, without technical knowledge of the model, to optimize and locate a valid configuration. Expert users don’t need much guidance other than a validation of their choices. But, if you’re a non-expert, you need the full guidance of a configurator to prevent you from being led down a dead end path. Such trial and error will make the experience error-prone and frustrating.

The full guidance configurator will guide and inform you of other consistent choices when you choose a parameter, such as the number of gears on a bicycle. Non-valid combinations are greyed out, but still selectable, and if selected, the configurator explains the consequence and highlights the conflicts needed to solve towards a valid configuration.

If your configuration engine doesn’t answer efficiently and quickly, it will never get user acceptance. The typical guidelines for acceptable performance is less than a second from selecting a choice to receiving the response. Performance around 0.1 second (or 100 milliseconds) feels instantaneous. But it’s around one second where people’s patience stops.

With a compiled approach, the difficult problem is solved once, and guiding the user to the consequence of his choice will be like a look-up in a table, resulting in fast interaction.

Having invalid rules on a website or in sales tools can cause all kinds of challenges and costly errors, so ensuring only correct configuration models are being released to downstream systems is critically important.

A typical approach would be to simulate or test a model, but this doesn’t work with complex products. A car model with 1021 valid configurations sold globally is extremely difficult to test as the configuration process only covers a small fraction of the valid configurations. Changes that work in Sweden, for example, might not suit Germany, which is why a higher level validation is needed.

Having a representation of the full set of valid configurations allows you to do cool, interesting things, such as creating reports that compare a previous set of valid configurations to that of an updated rule set, highlighting all the changes so you can see how it effects individual markets. Or you can use the solution space to prove properties, so whenever there’s a change in the system, the application will re-validate if the chosen properties still hold true. This gives you the comfort of knowing that a change hasn’t broken something fundamental in the model.

BOM Validation
It is essential to ensure that the product models are aligned with the corresponding bill-of-materials (BOMs) so that a valid and complete BOM can be created for each configured order. If not, all kinds of problems in the manufacturing process can occur, such as a car with two engines and no wheels.

The left illustration is of a configurable BOM (also called a Super-BOM or a 150% BOM), with selection conditions to filter the right parts based on the choices made in the configuration process.

The right picture illustrates the issues that can occur with a mismatch between the buildable and the orderable configurations; buildable configurations that cannot be ordered, orderable and sold configurations that cannot be manufactured.

These situations can be avoided by combining the VT™ representation of all valid configurations with the bill of materials information to identify, in one process, whether these situations will occur and create a report with counterexamples. This means that the configuration model will never allow combinations that cannot be manufactured and thereby removing errors in the ordering and manufacturing processes.

When optimizing the bill of materials based on statistical data, you can check whether certain variants available are necessary, or remove parts that only affect a small fraction of the actual choices in the configuration model. As an example, low-runners are configuration choices that only appear in a low percentage of (expected) orders.

The below image shows an automotive part used behind a steering wheel, which has a number of different controls. Depending on the configuration of the car, different parts are needed based on the selection of, for example, lane assist, adaptive cruise control or steering wheel heating.

These variant drivers all have an influence and in this example, add up to 96 physical parts shown to the right of the feature tree. When combined with statistical information about customer choices, it provides a probability for each of the parts, identifying those that are very unlikely. These parts can then be eliminated by adding rules in the configuration model. For example, if the lane assist is always bundled with the adaptive cruise control, the need for some of these parts can be eliminated.

For more information, you can watch our webinar on this topic by clicking here.