Which Product Configurator fits my products?

Even with logically similar designed products, it is advisable to take different approaches when setting up a Product Configurator – whether for sales, didactic or technical reasons. Depending on the required handling, the product structure but also the existing basic data for the product, different configuration systems are recommended. In this article, we would like to describe the different types of Product Configurators in more detail. Basically, we distinguish between the following:

Product Filter
Decision Tree
Variant Configurator
Variant Chain Configurator
Variant Matrix
Compatibility Finder

In this post we will explain the specifics of each of these systems.

This can only be called product configuration in a broader sense. However, as Product Filters are often mentioned in practice in connection with product configuration, we also want to include this type of “configurator” here.

It works as follows:

Products are filtered by indexed values stored with the product.
The filter dynamically restricts itself to the values in the hit list (faceted search).

The Product Filter is the type of product configuration geared towards mass data filtering. Users achieve the optimal result by setting filters on product properties. This form of product configuration naturally only works for a limited number of product variations.

The prerequisites for such a Product Filter include, among other things, master data that are as stadardized as possible, which means: a) unique, clean attributes and values on the product; b) ambiguous attributes or values require cleansing or mapping information; c) very fast access to the information to be filtered. The “Lucene” software library, which is specially designed for super-fast filter results, is often used for this purpose. Lucene features special functions for indexing object properties and for searching by faceted filtering. Lucene is built into, among others, the software solutions Elasticsearch and Solr.

This type of configurator is suitable for: Webshop systems with a product master in which the products come with standardized properties. Good example: clothing. Here, you can get by with a small set of attributes and, in turn, a few values to find the right product. Example: Type: T-shirt, Brand: adidas/nike/noname, Gender: m/f, Size: S/M/L/XL/XXL, Color: white/black/red.

2 Decision Tree: Navigating to the optimal configuration

Traversing a graph to collect configuration items
Subsequent modification possible by changing the segments
Example: https://pim.test.alterra.sepia.de/decision_graph/
Video: https://www.sepia.de/public/videos/wsf-sales-configurator/wsf-sales-configurator.mp4

The Decision Tree is a very flexible way to also map more complex configuration scenarios. Together with a Segment Collection function, it can be a very powerful tool for implementing a Product Configurator. Tree structures of any depth and width can be mapped.

The graph can be used to define decisions that build on each other: “…you have chosen option A, you still have to choose sub-option A or B…” and so on.

Decision segments can be exited at any time by defining an exit option at each segment.

Any number of decision segments arranged in parallel can be processed one after the other.

The Alterra:GraphPicker special software library is often used here. This library enables the collection and logging of segments selected from a Decision Tree.

The segments collected as part of the configuration can be subsequently deleted or changed. Practical example: A product configuration consisting of various components has been completed, but a component should be replaced later. Then the GraphPicker can be used to jump to the node in question and the graph can be retraversed from there.

Alterra:GraphPicker can also be used to map more complex logical dependencies between subgraphs. To do so, when populating the Decision Tree, rules for the validity of further subgraphs must be stored at certain end nodes. Example: Additional software => MS Office => Excel is only selectable if operating system => Windows or Mac is selected and RAM package => 8GB or 16GB.

In this way, the conditional activation and deactivation of decision paths can be implemented without having to implement additional program logic.

Conclusion: Decision Trees can also be used to implement very complex configurations where a large number of components have to be combined to form a product package.

This type of configurator is suitable for: If the goal is to guide the user to his desired configuration by asking specific questions, the Decision Tree is the right choice. A Decision Tree can also be used to represent products that consist of a large but finite number of elements. Theoretically, these elements can then again be optimized using variant configuration (see Variant Configurator below). Use cases from mechanical engineering would be, for example, modern lathes, milling machines, CNC machines, grinding machines, cutting machines that consist of various, mostly optional elements.

3 Variant Configurator

Definition of classes, characteristics and values as maximum bill of materials / maximum attribute value list
Assign class to variant master
Select an initial configuration
Define dependencies between attributes/values (configuration rules)
Define constraints (higher-level rules for the validity of the configuration)
Test rules by calculating possible variants
Interactive evaluation of rules during user input
Generate quote based on configured variant
Order BOM (for procurement and production) results from the configuration

The product configuration of the “variant configuration” type is the classic among the configuration scenarios. It involves defining a master product that is equipped with the maximum number of possible characteristics/values. Which characteristics/values can be combined with which other characteristics/values is determined by the configuration rules that were also defined on the variant master. Of course, there are also products that are completely freely configurable, i.e. all features/values can be combined with all others. The variant configuration results in an exponential set of possible variants. Example: 7 characteristics with 5 values each result in 5^7=78,125 variants. By means of variant configuration, a potentially gigantic number of products can be easily handled without the need to maintain an extra product data record for each article.

Due to the high flexibility and the relatively small amount of data, a Variant Configurator offers benefits in several areas:

Sales: Customers can be guided to exactly the configuration they need in a short amount of time.
Marketing: The maintenance effort for product data is considerably reduced. In addition, product images can be automatically output via 3D rendering.
Production: The variant configuration can output parts lists for production. Ideally, a complete production order is generated directly from the configurator.
Purchasing and logistics: The parts required in production and order processing can be determined via the configuration process and fed into other systems.

Conclusion: These benefits apply to the same extent or in part also to the other types of product configuration. Overall, it can be assumed that an intelligently set up Variant Configurator project can have various synergy effects up to and including a continuous supply chain around a company. Thus, the “digital factory” or the “digital company” does not have to remain a thing of the future.

This type of configurator is suitable for: Variant configuration is most likely the most common form of product configuration. It is suitable for: Products that have a finite set of attribute/value pairs. By linking variant configurations (see Variant Chain Configurator below), it is even possible to map almost any product complexity.

4 Variant Chain Configurator: Variant Configurator with linking of compatible variants

Setting up many variant masters (see Variant Configuration)
Super complex configurations possible
Based on components that can themselves also be variant masters
The component is configured as a variant and during this process it is checked whether there are other variant masters that match it.
Interlinking of components can basically be continued endlessly
Configuring a variant, finding suitable partial or completely configured variants

For the first time, this software component standardizes configuration tasks that were previously only solvable by individual programming. Up to now, Variant Configurators have been used in practice that are based on a maximum bill of materials and that consider the configuration a decomposition process using a top-down approach.

The functional principle of a Variant Chain Configurator is that individual components of an overall system are defined. These components each consist of a maximum BOM and selectable attributes. The overall system is created from individual components that are combined one after the other. Each individual component can be configured via variant configuration. At the end of each component configuration (or even during it), the system checks whether theoretically suitable further components can be docked onto the current element. If so, the component is called up with the options set that are relevant for docking and can then be further “variant-configured”. Once this is also done, the process continues in the same way until no suitable elements are available or a rule takes effect that recognizes the entire system as being finalized (constraint).

This type of configurator is suitable for: Wherever variant-configured elements combine to make a product, Variant Chain Configurators can be used. For example, if a workstation consisting of a variable table (type of wood, depth, width, height adjustable: yes/no) and a chair (castors: yes/no, castors: carpet/parquet, fabric color, armrests: yes/no) should be configured.

5 Variant Matrix

Creating a variant matrix by multiplying out the possible items via attributes and values, under consideration of rules (constraints)
Filtering the possible variants based on the values given in the matrix in real time
Look & Feel as with the Variant Configurator (see above)
Example: https://www.team7-home.com/de/de/schlafen/betten/light-bett/#config_anchor

A Variant Matrix is an item table created by multiplying out attributes and values from a Variant Configurator based on rules. Configurators such as Alterra:Variantmatrix can use these tables to create a real-time configurator. The particular challenge here is the ability to filter extremely large amounts of data very quickly. In the case of a table from the manufacturer TEAM7, a variant matrix with 5–8 features with 7–10 characteristics each can mean a quantity of 8^6 = 262,144 items. Here, a very efficient handling of these relatively large amounts of data is required so that the user can see results quickly and thus enjoy a pleasant configuration experience.

Disadvantages: Variant Matrices are only suitable for products where the number of possible variants is limited. Although special tools such as Alterra:VariantMatrix can handle matrices of several million variants and deliver results within an acceptable amount of time, the number of variants increases so rapidly above a certain degree of product complexity that a Variant Matrix no longer makes sense. Example: 15 attributes with 8 properties each = 8^15, i. e. 35 trillion variants in one matrix. This amount of data can no longer be handled using reasonable effort.

Advantages: Some companies have legacy ERP systems in use, whether for production or sales, that already work with a Variant Configurator. If, for technical, organizational or monetary reasons, it is not possible to bring this configurator onto the Internet, then one might fall back on the solution of generating the possible sales products via the configurator and creating the Variant Matrix for an external (Internet) configurator from this. As long as the amount of data remains manageable, this is an absolutely viable option for many IT decision-makers, especially since the generated data is then guaranteed to be consistent at all points across the company. In addition, there is no need to maintain multiple configuration and price logics in parallel.

This type of configurator is suitable for: Cases where companies have mapped the set of rules to central systems, but these do not provide sufficient services to use them directly for e-commerce, be it for software-architectural reasons, performance reasons or because a direct connection to these systems is undesirable for security reasons. In these cases, product lists can be extracted from the system, which are then used by the configurator.

6 Compatibility Finder – Compatibility Management

Finding compatible products or components by rule set
Finding suitable other products for a selected product
Evaluating the rules on a product class and finding suitable objects
Data: Definition of dependencies between product classes

Example:

Compatibility Rule Editor: Definition of dependencies between product classes

What also works: Definition of dependencies of properties and values across the complete product master. In this case, instead of the attributes of the product classes, the attributes and values are used directly, i. e. without reference to a product class. Example: Blue goes with red and white, but not with green.

Compatibility Management is suitable for finding compatible products, where rules can be defined on the basis of properties that facilitate finding matching parts. To define the rules, you can start at several points. One possible starting point: You create rules that will then apply to a complete product master. Here, all used property/value pairs of the product pool are offered for rule definition via Compatibility Rule Editor. Example: All products that have the property ‘inner diameter’ with a value of ‘10 mm’ are compatible with all other products that have the property ‘outer diameter’ with a value of ‘9.9 mm’. The Compatibility Finder must then go through the entire product master to find possible (compatible) object pairs. It requires a little less computing power to limit the number of objects to be considered directly by class selection. Thus, when defining the compatibility rule for both sides to be compared, you first select a product class and then the properties and values of this class. When determining the result set, the set of elements to be searched can then be limited to the selected classes.

Optimization potential for rules for the entire product pool: If you do not use product classes to limit the amount of data, you can also define priorities for rules via Alterra:Compatiblity Manager. An example for this: Reduce the master data to all products with diameter > 8mm and < 11 mm. Then apply the rule “compatible are all products that have the property ‘inner diameter’ with a value of ‘10 mm’ with all other products that have the property ‘outer diameter’ with a value of ‘9.9 mm’”. This then naturally leads to considerably faster search results.

This type of configurator is suitable for: In practice, this type of configurator can be found, for example, in the area of sanitary installation, in particular for the configuration of hot and cold water circuits. Such a system is also well suited wherever a confusing number of standard parts can be combined with each other as, for example, in the bicycle parts sector.

Price calculation via a separate set of rules

The configurators listed here can also be used relatively easily for price calculation – without the need to implement a complex pricing function. The Variant Configurator, for example, can obtain its prices from the selected product properties. The product price is then calculated by simply adding them up. However, there are usually other factors that are independent of this for pricing in everyday business. For example, a general surcharge might be applied if a particularly large number of configuration options are changed compared to the standard offer. Or, the other way round, a discount is granted if you stay as close as possible to the standard offer. In addition, there are time-related, regional or customer group-dependent factors. To be able to implement such a differentiated price calculation in combination with the product configuration, a configurator should have a pricing module that makes these additional non-production-dependent factors maintainable and usable. Configuration software such as Alterra::CPQ comes with a special pricing module that works logically above the actual product configurator. So pricing operates as a function that uses parts of the configuration or even the complete configuration and also external variables as arguments.

Configurators need a reliable master data basis: PIM-System

Despite all the differences in presentation and function, there is one thing that all configurator types have in common: Without a very accurate product database, none of the systems can deliver reasonable results. Therefore, in most cases it is advisable to use a special PIM system (e.g.: Alterra:PIM) geared towards product configuration in addition to an ERP system. Configurator-specific information can then be efficiently entered in the PIM system. When integrating a configurator, you should never lose focus on the PIM data master and, if possible, assign specialists with expertise in PIM and product configuration to the project team.

Conclusion and outlook

Depending on the configuration method used, there are usually also different data modelling and management approaches with respect to the basic data of the configurator. So special attention should be paid to this when introducing a configurator. Depending on whether you need a simple product filter or want to configure a complex variant chain, you have to maintain your data differently – and later, of course, put different amounts of effort into defining configuration rules. With a simple product filter, the effort is more in the product maintenance of the individual articles. With most other configuration types, the main effort is to create an optimal set of rules for calculating the configuration.

Read more about Alterra::Variant-Configuration