This article describes the base technology behind a configurator, and why your company should select one kind of technology over another. The type of engine you choose have a major impact on how quickly and easily your sales people can turn customer requirements into configured products.
Let’s start with two simple assumptions:
- A configurator is essentially a rules engine running a set of configuration rules collected in a configuration model
- The configuration model defines which items in a product that may be selected in combination with each other
We’ll simplify things by focusing on two kinds of rules engines used for configuration; the imperative rules engine and the declarative rules engine.
The imperative rules engine
An imperative rules engine is sequential, and each rule has a defined place in the sequence. This means that the user need to start with question 1 and move forward sequentially. If you are working with an imperative engine and come to question 6, and then realize you need a different value for question 2, you will need to go back and change that value manually. You may also need to modify answers for questions 3, 4, and 5.
It’s a simple way to ensure the configurator is consistent, but the forced sequence causes the users to loop back and forth. Here’s an example of imperative configuration:
A manufacturer of electrical equipment and enclosures has a configuration model for machine A that they produce. Let’s say a sales rep is working with a customer to configure a solution.
The first questions define the power of the electrical equipment which in turn requires a volume due to the size of the machine. Following the sizing of the machine, the enclosure needs to be configured. However at this point, the sales rep realizes there is a conflict between the size of the machinery and the enclosure, and based on external size restrictions the sales rep cannot increase the volume of the enclosure either.
In a conflict as this one, the sale rep will need to go back and change the answer to the initial questions about power, and then confirm that all other questions that lead up to the volume are still correct.
It should be noted that not only using a sequential tool is problematic; it is also difficult to create a reliable configuration model with an imperative rules engine. The administrator of such a tool needs to set up a pre-defined sequence of how he expects the customers to define the product. And since every user is unique, the sequence will never be correct. Hence, sales people become experts, not in the product they are selling – but how to work the configurator to give them a solution.
In summary, structure and order are great for ensuring accuracy – but only if everyone follows the same order.
The declarative rules engine
A declarative rules engine is not dependent on order, because each rule (sometimes called constraint) states an independent fact. If you answer any question, the rules engine looks at all associated questions and re-calculates all answers. If there’s a change all the answers are automatically adjusted.
This means that a declarative rules engine is friendlier for selling, because in most cases customers don’t describe their requirements in sequence – and describing a configured product involves a lot of ‘discovery’ questions. Whether the user begins with question 6, 1 or 10, a declarative rules engine will cooperate. Here is the same example from above:
Our electrical equipment manufacturer has the same configuration model.
Our sales rep is again working with a customer to configure a solution. The sales rep may start with any question. For simplicity, let’s assume the sales rep starts with the first questions that define the power of the electrical equipment, which requires a volume. When answering the questions in regards to the enclosure the sales rep is made aware of the conflict. A proposed change is described by the configurator, either limiting the power or increasing the enclosure.
In this case, the seller will be given the alternatives and can make an informed decision directly without the need to go back and change previous answers. None of the other questions that lead up to the final question need to be reviewed either.
A declarative rules engine gives users a solution without forcing them to use a rigid process. A declarative rules engine enables the seller to become an expert, allowing focus on only the important questions for the customers leading to an optimal configuration.
Most of the key vendors on the market state that they are using constraints which are a basis for a declarative rules engine. However, it seems like some companies do not have the technology to back this claim. We recommend analyzing this thoroughly.