History of CPQ According to One Man

n 1996, I was working in one of the first ISPs (Internet Service Providers) in my area of Italy, that I founded with some friends.  Meanwhile, I was also graduating with a degree in Mechanical Engineering from the University of Parma. My skills were therefore deeply rooted in a passion for IT and Mechanics. During this time I was lucky enough to meet a wonderful person and mentor, Professor Franco Folini. He understood my abilities and suggested that I argue the following as part of my thesis: ‘Definizione e sperimentazione di strumenti di supporto alla progettazione meccanica basati su tecniche feature-based e fortemente integrati nel sistema informativo aziendale’ (Translated to: ‘Definition and testing of mechanical design support tools based on feature-based techniques and strongly integrated in the company information system’).

I was quite surprised. Was he kidding me? Testing? Systems like this should already exist in every company. My vision of an engineer was not of a worker busy all the day long re-doing the same project over and over again, changing only a few variables. My vision of an engineer was much more lauded than that, but unfortunately far from the reality.

Re-Imagining CAD

In 1993, Solidworks was founded with a great idea: move a Unix based parametric/feature based CAD application to Windows. Why was this idea so great for our story? One reason is pretty obvious now: the affordability and flexibility of Windows.  The other key reason is not so obvious, though – OLE (Object Linking and Embedding, also known as COM). In short, OLE allows processes to communicate. One side of the process is called ‘Client’, that can be embedded into another process called ‘Server’. A basic example of this would be when you embed an Excel object in Word, or vice versa.

So back to my thesis idea: we can store all the engineering rules in a system and use this system to drive a Parametric Feature-based CAD application. The basic idea already existed and went by the name of Knowledge Based Engineering (KBE). KBE was developed at the beginning of the 1980s at IntelliCorp, as part of the project ‘Artificial Intelligence for the Business’.

It is probable that only a few knew about this project at the time. Too many pieces of software and hardware landscape were missing at that time.

Thanks to the ‘excuse’ of needing input for my thesis, I knocked on the doors of Solidworks Italia, SolidEdge Italia, and Cad.Lab (who created Eureka CAD and later was changed their name to Think3). I connected with a manufacturing company,Casappa S.p.A., interested to test a KBE strategy with a pump. This was just one small part of their product lines.

My thesis went very well, and I was able to store the rules for the pump family in a database, and with a MFC/C++ software I authored, was able to drive Solidworks to generate the CAD models automatically.

After my graduation I was ready to go and conquer the world with the renewed idea of the KBE.  Well, not really… Most of the companies at that time were using 2D CADs and the paper and my clash with reality was hard. I had to put my knowledge on a shelf with my thesis.
The Millennium Shift (2000-2010)

Starting in 2000, the decade was defined as the era of 3D CAD adoption in manufacturing companies. Looking to the CAD applications available on the market, automation became a pretty obvious enhancement for many. SolidWorks introduced the concept of ‘configurations’ – a way to drive a 3D model using a table of data, like an Excel spreadsheet. Creo (also known as Pro Engineer) introduced ‘part families’ – which was a similar concept to SolidWorks Configurations. All the other CADs started to follow suit with the same functionality, just with different names.

Storing rules with the geometry is not an efficient approach, though, and this opened the door to Rule-Driven Product Management (RPM) to fill the gap, such as: Rule Stream, Driveworks, Rule designer, and many others. For me, personally, it started my love affair with my first commercial configurator: RPMWorks. It was 2004.

At the time I was working with PDMs (Product Data Management) and 3D CAD applications. I noticed that not only the definition of a product was made of Engineering Rules, but also the manufacturing specifications were typically stored in a PDM. So, if you generate a model automatically, the engineering rules are only a part of a bigger problem. RPMWorks was born with this idea: automatically generate products using CAD and PDM.

RPMWorks and the other products on the market were just niche software. Some key ideas were still missing in the full puzzle making up Configure, Price and Quote (CPQ). At the end of the decade, I met the like-minded people (who eventually became fellow KBMax founders) that shared in the same vision of filling this important functional gap. (Fun fact: The name KB of KBMax stands for ‘Knowledge Based’.)
The Fourth Industrial Revolution In Full Force (2010-2020)

This decade is when the acronym “CPQ” was forged. In my opinion there are three factors that led CPQ products’ move from a niche engineering tool to a well known solution used by many companies:

    A Focus on Sales
    The Cloud
    3D Visualization

1. A Focus on Sales

Even with the advent of CPQ, the most common tool used to this day by a typical sales team to calculate product pricing is Microsoft Excel. Excel is not connected with anything else, but itself. (Read More: See the other blog post I wrote about Excel and CPQ).  So we have the paradox that we have all the product rules in the tech department and a disconnected tool to calculate the price of these products in another area of the company. Can we calculate a price and create a quote with the engineering rules? The answer of this question is the main reason why modern CPQ products can be so effective. Don’t get me wrong, also in the previous decades this was obvious, but not easy to do: moving an engineering tool from a workstation to a low powered notebook was not feasible, like it was not to train a salesman to use a complex engineering tool.

So here we add the second factor: the cloud.

2. The Cloud

In cloud computing you have unlimited resources and you don’t have to ask your IT department to own and maintain a hyper-complex environment.

The idea was clear: move the complexity of an engineering tool where you can have unlimited resources and delegate the hassle of hosting and maintaining an enterprise grade architecture.

The objection is: why do I have to use a complex tool instead of a very easy Excel spreadsheet?

The answer is the third factor: 3D visualization.
3. 3D Visualization

In a few words: 3D visualization allows you to provide a 3D visualization in seconds, with the right price, and the right quote to your customer, along with all the documents needed to finalize the sale – all generated on-demand.

So in this decade we saw many new players in the CPQ products market, with a different mix of these technologies: cloud, 3D Viewer, CRM integration, CAD integration, and PDM/PLM integration. Despite all the players, we are proud to stand out and be recognized as the top leader in Visual Configuration Software by G2.
The Future of CPQ (2020-2030)

So, what’s next?

I see better implementation of existing technologies such as: CAD in the cloud, with file lifecycle integration, and 3D viewing with photo realistic quality.

But, I think that now is the right time to return to the building blocks of CPQ products and start with a base of Artificial Intelligence (AI) like it was the founding idea of the KBE. Rather than explicitly writing them, business rules can be deduced by ingesting existing documents, like CAD models, excel spreadsheets, or other data sources. Instead of writing a rule, I see that this rule can be written by AI and be automatically updated by the current state of the market – much like Amazon now dynamically updates prices.

Currently, CPQ is primarily B2B, and rarely B2B2C. In coming years, I think we will see more used for B2B2C, leading to integration with portals such as Amazon, eBay, and others. In this scenario, I anticipate heavier use of augmented reality (AR) with products configured in real-time, while the constraints are deduced from the real environment. For example, if configuring a table inside a room, the size of the room can be derived automatically and then inserted by the configurator.

At KBMax, we have exciting prototypes of all these technologies and more, just waiting for the right future condition. Stay tuned!