By Lars Hoegsted | HoegEye (www.hoegeye.com)

The term Configure-Price-Quote describes the interactions that take place when selling customized products and services. Processes around configurable products are special because the product is never produced before the actual purchase. The product never exists as such; it is just a blueprint – a DNA – for billions of possible final product configuration states. In terms of biology you can think of configurable products as using “sexual reproduction” – they reproduce by matching the product genes in their DNA to a specific set of requirements and creating a unique version of the products in accordance to the rules described in the Product DNA.

In the article “Neglected Models” we highlight the three fundamental components of interaction with configurable products – modeling, solving and configuration. The video “Why you need AI” uses a riddle falsely attributed to Einstein to highlight how difficult it is for humans to handle complexity and the importance of using artificial intelligence to helps us sort out the combinatorial explosions linked to configurable products.

This article provides three basic rules that companies break when looking at CPQ solutions. Breaking these rules does not necessarily mean failure of the CPQ project, but it will block the company from developing and using their configuration potential in digital product strategy.

AI can’t get no SATisfation

Humans want choice but shy away from complexity. We are thrilled when we are presented with lots of options for our next new car but get frustrated when we have to go through endless selections and even more so when our combination of important choices creates a conflict.

We seek the “Joy of Choice” but shy away from the “Cost of Complexity”.

 

Figure 1 Screenshot from the Audi online configurator

CPQ processes rely heavily on artificial intelligence as arbitrator between product possibilities and customer requirements, but it can only guarantee that the product rules are satisfied – there is no guarantee for customer satisfaction.

We can experience this when we try to customize our next car online. If you are looking at investing in a Tesla, you will find that you can’t get an active spoiler to improve the highway mileage for your Tesla 100D without upgrading to the more expensive Tesla P100D with a shorter range.

Likewise, you can’t get the fuel-efficient 19” wheels with the S-line sports package for your new Audi Q7 but receive the message that you have to deselect the sports package if you want the 19” wheels (see Figure 1).

In both cases, there are clearly no technical reasons behind these restrictions but commercial product rules block us from the desired combinations.

In the Audi case, it is a solver – an algorithm using artificial intelligence – that determines if our requirements can be satisfied by a product configuration.

The AI helps Audi ensure that we can have the “Joy of Choice” without bothering too much with the “Cost of Complexity”.

Who Owns the Fish?

Configurable products offer multiple different options and therefore also introduce the risk of combinatorial explosions. This can be illustrated by a simple riddle, falsely attributed to Einstein.

Einstein’s riddle involves 5 different nationalities living in different houses on the same road. Each house has a different color. The owners have different pets, cars and drinking habits. The unrestrained number of combinations yields an astonishing 2.985.984.000.000 different possible combinations.

 

Figure 2 Hints to Einstein’s Riddle

Now, Einstein offers 15 hints (see Figure 2) and asks the simple question: “Who owns the fish?”.

You will find more details here: https://youtu.be/NbCQPZ39Opk.

Einstein’s riddle illustrates how humans find it difficult to handle many variables that depend on each other. Even if there is only a single correct combination of houses, owners, cars, pets and drinks we get lost in all the false combinations.

The combinatorial explosion means that we can’t keep track of all combinations and when dependencies and constraints are added to the mix it becomes extremely difficult to distinguish legal from illegal combinations.

Luckily, keeping track of combinations with dependencies is “gefundenes Fressen” for a class of AI-algorithms called “Constraint Satisfaction Solvers” or just SAT-solvers.

Model – Solve – Configure

 When we interact with sexual products (products that have to be configured to match the product genes to the requirement profile) both during early and late configuration it is always based on three fundamental activities: “Model – Solve – Configure”.

 

 

This is also the fundamental activity that takes place when CPQ solutions support companies and customers in obtaining an ideal customized solution.

The process takes knowledge from experts and exposes it as an AI-program that helps customer solve their questions:

1. Domain experts describe the knowledge in appropriate tools – this is called “Modeling”
2. The AI reads the knowledge and provide answers – This is called “Solving”
3. We interact with programs that in turn use the AI to guarantee correct results – This is called “Configuration”

Three Basic Rules

This division of labor in-between modeling, solving and configuration means that there are three basic ground rules to observe when you work with configurable products:

 

 

1. Provide modeling tools for different   domain experts
2. Separate Modeling from Configuration
3. Never, never create your own Solver!

Why This Rule Isn’t Trivial

The first point may seem trivial, but this is far from the case. Most companies are happy using whatever modeling tool that happens to be at hand and so all modeling has to be expressed in a way that pleases the tool – not the domain experts that have to put their knowledge into models.

In 99% of implementations today, this means that companies educate specialists in the tools modeling language so these specialists in turn have to liaison with all relevant domain experts asking them for input to their models. I have also seen solutions where companies try to solve this bottleneck by hiring external experts or set up modeling centers (typically in areas with low cost of IT-services) who sit at the end of a pipeline that feeds them information to be implemented into models. This approach is inherently slow and error prone as a lot of knowledge has to be transferred from Domain Experts to modeling interpreters.

Another important fact which is normally overlooked is the requirement for good modeling tools – plural! Modeling requirements are very different in engineering, manufacturing, sales, marketing, service and for different types of products. It is important that experts can interact with models using tools and syntax that makes sense for them. If you don’t do this, you turn product modeling from a strategic asset into a tedious chore that you have to do along with your time sheets and expenses.

Finally, you need a modeling platform that supports collaboration and contributions from multiple different users over time. Just like developing software, the development of digital product models requires a platform where users can check information in and out, merge, diff, commit, test and release their incremental additions to the total set of product models. You need to be able to handle versions, error corrections, patches, time sensitivity and different target platforms.

No single system or platform provides a coherent solution that addresses these three fundamental modeling requirements and the leaders in this area create their own platform combining multiple tools and technologies to: “provide modeling tools supporting multiple different domain experts”

Why Separate Modeling from Configuration?

A quick and dirty approach to product modeling is the classic step-by-step way or if-then-else way of thinking. You explain both the rule and what should happen when the user interacts with the rules.

Now, if you want to redesign the user experience you will have to move around all your modeling code as well and when you change your model data you also have to release a new version of your configurator. Furthermore, you have to consider how you model because this may directly impact the user experience.

This simply breaks down in practice. A further consideration is that modeling data will be used across multiple different applications running on different platforms (web, apps, on-device). This means that you want to be able to have application designers develop and improve applications independently of the ongoing work to develop and update data and logic for the products used by these applications.

Hence, the traditional adage from programming of separating data from logic really needs to be modified to separate modeling from the configurator application.

Never, Never Create Your Own Solver!

There is an abundance of SAT-solvers out there. Building a SAT-solver may at first glance seem temptingly simple but don’t let yourself be tricked – it is an extremely complicated programming task. SAT-solvers battle a well-known and very hard problem in computer science and they all have to rely on different heuristics and data structures to perform with acceptable efficiency. There are annual competitions between different public SAT-solvers and the leading technology vendors also compete heavily on their different proprietary SAT-solving technologies. Use or adapt one or more commercial or public SAT-solvers but never never start developing your own solver from scratch unless you are into computer science research or intend to be a vendor in this field.

Imperfect Trinity

Model-Solve-Configure, this is the trinity of activities behind interactions with configurable products. It is interesting to investigate the efforts that vendors put into these three different areas. Using the number of approved patents, we get a picture of how R&D budgets are prioritized. First of all, there is a clear picture of an increasing patenting activity in the area of configurable products. More than 10 new global patents are granted yearly in this area (The numbers for 2015 and 2016 are expected to increase significantly because a proportion of pending patents will become granted with effectivity back-dated to these years).

When we distribute granted patents on to the three different areas of Modeling, Solving and Configuration we see a skewed picture. Only 18% of R&D efforts seem to be linked to create support for modeling configurable products. This is perhaps not surprising. When customers evaluate vendor technology the focus is on the functions and features in the end user applications. This all plays into the solver and configurator features. Establishing and maintaining the data foundation behind the solver and configurator apparently doesn’t merit the same level of attention.

This is actually surprisingly naïve. The solver and the configurator applications are much less important both in terms of time, efforts and cost. Designing, customizing and implementing configurator enabled applications are simple well defined tasks and once implemented they remain quite static. Solvers are almost 100% static standard components which, once implemented, act just like an appliance.

However, the modeling platform has to support ongoing daily activities and efforts from many different users across the organization.

A Story About Investing in Configuration

Let’s consider an anonymized example:

A global company with approx. 25.000 employees manufactures industrial components in a B2B setting and operates with 17 different designs (product families) of configurable products.

They maintain product data on two different platforms: SAP for manufacturing and a commercial market facing e-business platform. They use SAP solvers in both environments and provide custom developed customer facing configurators and standard SAP configurators for downstream configuration processes (ordering, manufacturing, scheduling and delivery).

Their original investment in technology for solvers and configuration powered applications were approx. 3 mUSD. The annual maintenance of the applications requires approx. 2 FTEs; there is virtually no maintenance required for the SAP solvers and the annual recurring technology costs of operating the software are approx. 500.000 USD.

Each product line requires modeling in both SAP and the commercial platform. The company operates with a central center of excellence for product modeling and has processes in place to ensure the flow of information from engineering, product management, sales and marketing into models. Across the board, the company allocates an average of 5 FTEs to product modeling per product line.

Using a nominal cost of $100.000 per FTE, this means that the company has invested the following over a 7-year period:

• 8 mUSD invested in solvers and configurator applications
• 60 mUSD invested in product modeling

This means that the accumulated costs for product modeling (over 7 years) is more than 7 times larger than the combined investments in implementing and maintaining solvers and configuration applications!

Breaking the Rules

Let us consider an example where a company is about to invest in a new CPQ-solution (Configure-Price-Quote). This typically involves an internal team of stakeholders from relevant departments – a product manager, a pricing expert and an ERP-expert, an architecture expert from IT and key representatives from legacy CPQ functions. The selection process is typically sponsored by sales and managed by an appointed internal dedicated project manager or, especially in larger organizations with political fractions, an external consultant.

Reports from Gartner, Forrester, IDC and others are studied and the work to build up an RFP or RFI gets on its way.

Already at this early point, the quest for a CPQ solution has in effect changed from a solution finding process to a vendor selection process. RFPs are built on earlier RFPs and more or less by force of habit it becomes a beauty contest between suiting vendors from this point onward. These selection processes tend to focus on functions and features of competing vendor solutions which in turn means that most of the time and effort is spent looking at configurator applications rather than the underlying product modeling.

Once the company is ready to make a selection, they are starting to see the world through the lenses of their preferred vendor’s technology – the proverbial hammer to nail the CPQ solution!

However, the three basic principles are now completely lost:

1. Provide modeling tools for multiple different domain experts gives way to: “We all just need to get used to this new tool and the demos looked good”
2. Separate Modeling from Configuration is completely disregarded as an exotic wish: “We standardize on vendor technology and this gives us more expressive power”
3. Never, never create your own Solver is replaced by self-assuring famous last words: “Our configuration problems are too complex and specific to our business so we need to create our own work-around”