we help nordic small- and midsized manufacturers get started with tools for configuration, pricing and quoting
Get Started
Showing posts with label blog. Show all posts
Showing posts with label blog. Show all posts

Price is a decision

Posted On Monday, November 22, 2021

This is an old truth but it's something we're repeating in every workshop:

"Cost can be calculated, price is a decision"

One could argue that price can not be decided, since "it's given by market conditions". Even if this might be right, it's somewhat narrow-minded. As long as you're doing things just like everybody else it's most likely true, but as soon as you have a unique offering you set the price.

The price is the possibility to drive business in a strategic direction. So, say that you want to sell LESS of something price is a very effective way to achieve this.

The reason for writing this post is a discussion last week with a company concerned about their environmental impact. They had realized two things. Their valued employees did not enjoy business travel and running digital workshops during the pandemic proved to be a very effective way to run their project.

So what was the conclusion?

To adjust the price to encourage customers to choose digital ways to do business. It's aligned with the company's own value proposition and it's a concrete way to reduce carbon emissions by several tones of CO2.

Currently their consultancy rate for travel time is 50 %. Starting 2022 the consultancy fee for business travel will be increased to 100 %.

You've probably figured out by now that we're talking about cpq.se. This is a first step to make our business model more sustainable.

The second step is to encourage others to do the same. Put a higher price on your travel and just wait for pricing to do it's magic.

Tacton CPQ for Hubspot

Posted On Tuesday, October 26, 2021

We are currently working on a dedicated webpage about Tacton CPQ for Hubspot. Right now you can sign up for a newsletter, but there's more to come.

Read more at Tacton CPQ for Hubspot

Webinar May 27, 2021 - Master data in CPQ

Posted On Thursday, May 27, 2021

Patrik: But what’s the missing link that kills order quality?

Magnus: I don't think there is one missing link. I think there are many. And an additional challenge being that management's typically expect this to all be really be working.

Everybody involved in the processes knows that there might be glitches in the information transferring within the company. So, if the people that makes the decision don't think it's a problem, it's very likely that it's not going to be fixed.

We want to run this webinar to inspire because we know this is a solvable problem.


: And while presenting this, we also want to point out some pitfalls that we have experienced over the last 20 odd years – when trying to get your master data to control CPQ and sales. 

We also want to note: You’re not alone, we are currently working with 4 projects importing master data (everything from medical devices to heavy equipment). As they say in the movies, it’s all based on a true story – while we cannot share details from the specific projects.

We’ll also run a mini-demo in the end.


Patrik: And so Magnus, what problem are we talking about? And whose problem is this really?

Magnus:  It's very likely that it's exactly the people listening in on this webinar that has this problem. And my guess would be that they will be engineers that they work in manufacturing that they work in logistics. Typically, I would not think that they work in sales and don't want to put on any blame game here. But many of the problems that we're going to see here has to do with sales. And make sense because it's really the problem that we're trying to solve with the CPQ system. Right?


Patrik: Let's go into it. In this webinar, we're going to use one piece of a product in every example, and it's going to be a beacon mounted on a roof of a light truck.

We think everybody understands what a light truck is – so it’s a good example.

We're going to use the example of a beacon that causes issues when we transfer information between different systems, between sales and so on. So we're going to start off with a small example of a problem flow, a typical example of problem flow.


Magnus: A typical example of how these error may occur in an organization:

Flow from the person that has the problem, to the person causing the problem


Sam works in supply chain, a beacon manufacturer has quality issues – he wants to remove the beacon temporarily from the product offering. He can easily make the change in his supply chain systems. But he wants to ensure the beacon is not sold, so he sends and e-mail to Jennifer that works in engineering.

Jennifer reads the e-mail the next day. She doesn’t really know what to the with the info, but she makes a note in the PLM system.

Tom works with the CPQ rules, and he’s developed a magic Excel macro that exports data from PLM and formats it nicely. Notes in PLM are ignored.

Nora works in sales. She has a huge deal in progress, 200 light trucks – here biggest order ever. She creates a quote from CPQ, and gets it signed.

Supply chain gets an e-mail with the quote – and sees, 200 beacons ordered!

I mean, can you point out the person that's at fault here?



Not really. I would say it's everybody's fault. We have this problem, this problem goes two ways.

So there is a problem for everybody who knows something about the product to make sure that everybody in sales is informed. And then it goes the other way around as well that, the information that sales knows about the customer and the preferences and everything needs to flow back also into manufacturing and into production planning.

 Whatever be, all these other functions, everything that Sam and Jennifer and Tom does. So today, in this, we're going to focus on one of the directions. The information flowing from Sam, Jennifer and Tom into Nora's CPQ tool.

The problem is that we saw here with Patrik’s example is that, this is sort of like a “Broken telephone”. One tells another tells another and all of a sudden the story has changed. This is very funny if you're five years old, and you go to birthday party, but it's not so fun when it's in your daily routine. And this is really the problem that we're trying to solve; the “Broken telephone” problem.


Patrik: We touched on this already. But in this webinar, we’re very one directional. We're going from supply chain and engineering all the way out to sales. But as just as you mentioned, Magnus, we need this bi-directional flow, where what sales knows that is really essential flows back to Product Development and Engineering, because that's essential for them to know what new products to engineer, what new products to deliver. And this is a topic thatac ompletely new webinar.

So if you're listening in and you're in sales, your day will come!


Patrik: So Magnus, with that said, with your 20 years of experience, what should you start with? What kind of information should you include in a CPQ system?

Magnus: Okay, you can think of this from different aspects. Of course, one important thing when it comes to profitability is that you keep your prices in sync. It's quite straightforward. And it's not very complicated from a configuration point of view. Because, it's just a number, and it has to get the calculation in the pricing module correct.

But if we look at another common wish, I wouldn't say it's a requirement, but a common wish, often in early stages of a project, is that okay, but we should get warehouse availability into our CPQ system? There are a few problems with this, isn't it, Patrik


Patrik: the first problem with warehouse availability is that most likely medium or low quality. If you work as a responsible for ERP system, you're going to know that the quality of that data is not actually very high. So you start off with trying to include information into the CPQ system with low to medium type of quality. And on top of that, you have the question of, is it really important? Are you going to deliver this piece of equipment in the very near future? It’s like to drive a car by looking in the rear view mirrors.



Yeah, and the reason there is because it's very difficult to foresee the consequences. So for example, if we take Sam’s beacon here, if we remove that from the CPQ system and say that it can't be sold, there will be Domino effects. So you remove the beacon, and if you don't take into consideration that it's actually a legal requirement in France, that you cannot sell a construction truck, unless it has a beacon, then you will, by removing this beacon, block sales in that country. And this is just an example where it can be very difficult to foresee the consequences, this with the changes in the master data will have an effect on your CPQ system. It's not necessarily always a good thing because it's very difficult to foresee the consequences. When something is removed, many other things will fall by consequence.

Okay. So we should really talk a little bit about low and high risk here when it comes to integrating data. So what's your take on this, Patrik?


Patrik: Important analysis early in the project. It's easy to say that we should do the low risk things. For example, we just spoke about prices, and we said price is just number. And so it's kind of low risk + high reward to keep that in sync with external systems.

But then there are things that are more high risk to include in your configurator. And one example could be then quite common that you have some sort of country of availability, or you allow it or should you be selling this piece of equipment to a country. So it could be legal requirements, or it could be marketing demand or something like that. And while there is probably a high value of making sure that you don't sell the incorrect item to the wrong country, there's also an extremely high risk here, because you could get those kind of Domino effects that we just spoke about a moment ago, where you remove a beacon and that beacon is a legal requirement for some option, for example, construction trucks, and thereby you cannot sell construction trucks, which is high risk, you might stop your sales in a critical faith.


Magnus:  You could also turn the question around and say that it's a big risk that we sell these as well. If we cannot source the beacons in a few weeks, we're gonna have a big problem in France.


Patrik:  Exactly. So with this said, just because it's high risk doesn't mean we should not do it. We should just be more careful when we do it.


Patrik: Let's try to draw this map of what kind of information and system are we talking about.

Magnus: There can be many systems when in an organization- you know quite a bit about this, Patrik, because you have a lot of experience. Let's bring up some three letter abbreviations here. And I'll let you have a go Patrik.

Patrik: Let’s bring in our people again, so we don’t get stuck with the abbreviation. Jennifer works in Engineering, and manages the product with her team. Sam works in supply chain and ERP, and is responsible for making sure the product is supplied with parts and actually manufactured. Tom sits in between all these systems, and tries to collect all required information into the CPQ-system. Nora works in sales, and uses CPQ daily.

These are the typical systems to fetch information into CPQ automatically.

What’s important:

* All these systems are great expert systems for their specific purpose. But only CPQ can overview the complex relations for the complete product, for example what will happen when removing the beacon.

* PLM typically (if used) contains all modules and variants you want to sell – also called EBOM. ERP typically contains parts delivered to the customer, also called MBOM.

Magnus:  But does that mean that we need to make all the ERP and PLM info available in CPQ?

Patrik: If you're a PLM centric company and you actually have control of all the modules, module variants, and so on, maybe even some of the technical rules in the PLM system, it might be a good idea to extract the information and drive to CPQ system based on this. The same may be true for ERP. But it's not a good idea to believe that you can mirror all the PLM or ERP structures and rules straight into CPQ. Then I think you're doomed to fail. What do you think, Magnus?

Magnus:  Yeah, and I think we keep coming back to this whenever we discuss product data in any sort of form that, what's important for sales, and what's good enough for sales? So we don't need the nitty details that you need to keep track of in the PLM system. Can you provide some examples of how a typical product structure can provide us with completely different sets  of data that Tom and Nora might need.


Let me show you a very simple product structure of our beacon. We have the module beacon which may exist or not. And the beacon consists of a number of parts, in this case shown as glass and bolts.

Let me give you some examples of inromation that may be needed in CPQ for an organization:

Example 1: Spare parts for service contracts from PLM. Probably doesn’t make a lot of sense for a beacon, but very important for biopharmacetical company where the spares is an essential part of the business model.

Example 2: Country of availability for modules from ERP based on legal requirements or marketing decisions. Are we allowed to sell the beacon to Norway or not? Essential to sell the correct product.

Example 3: Technical rules describing the relation when you can have the beacon or not, it may compete for the same space on the truck as an aero package. Typically coming from PLM.


First example, Data in synch

Second example. block things not allowed to sell in markets

Third example: re-use of existing rules.

I’m answering my own question here. It depends on what ifnroamtion that’s relevant for our organization. We don’t need all data.


Patrik: We mentioned risk before we started talking about the type of data.


Automation is also risky.

We always ask this question:

The upside of using the correct data, it's quite obvious, but what is the risk of using this data? And what can we do proactively to mitigate this risk.


E.g. Don’t block sales, only prioritze lower or warn

Only choose the beacon if there is absolutely no other solution

Maybe we should move the beacons so that it's not something that the sales rep can sell themselves, or quote themselves, but they will need to do an ETO request.

Another thing could be if we want to decrease sale of something where we know that we have a sourcing problem, work with pricing, for example, or maybe a combination of these two. If you know that for some customers, the beacon is very important, they really need it, they are willing to pay whatever it costs.



 Vad ska man börja med?

Quality vs Time-savings



And then, for me, time savings can always be done later, but my strong belief is that we should always start with things that increases our quality. And in addition to that, where we can handle the risks without risking the usability for sales of the tool.

So are there any other things, any other ways that we can mitigate these risks that we were talking about?


Patrik:  I mean, I think an obvious answer to this is to make sure to test as much as possible. I mean, obviously, testing is essential in all projects. But especially when you start integrating things.



Okay, so in practice, what does that mean when it comes to data integration? When we have integration, we want to split this up in several steps.

Because if something goes wrong, so all of a sudden, something doesn't work, due to our integration of sort of live data, we want to see and easily understand why and how it breaks.

Keep in mind that we should, at any given point be possible to do effective debugging of this. We should definitely not create a black box.


Patrik: What we've seen in the project we run together is that, the human mind is really amazing when it comes to finding patterns and spotting changes.

We recommend having an intermediate format, for example in Excel.

You can use the combination of the human mind on finding patterns and spot changes, but also use the classical tools we’re used to.

Magnus: Like using Excel or Tacton Studio for debugging.

Patrik:  It may sound kind of rudimentary to use Excel. You need to keep in mind it’s impossible to tests all combinations in product configuration. You easily end up in billions and billions of combinations which would take the eternity of time to test. It's better to go back to as close as possible to the source and try to understand the source before you push it into Tacton.


Magnus: Okay, so a webinar without some kind of demo, is that a good webinar, Patrik?

Patrik: Every webinar should have a demo! But you’re going to demo using a click-dummy, right?


Let’s run a demo of ‘Beacon trucks’.

Magnus: So first off, this would be the normal behavior in our CPQ system, we get the beacon light, t’s an option they include by default (hence the name).


Magnus: But then, with some automated data flow directly from Sam's system, we can say that we should lower the priority here on this specific SKU. So now with this information flowing into the system, the CPQ system automatically still offers the beacon light as an option but the default will data driven be set to none.


Magnus: And the second thing, and just to bring this closer to a real life example, is that we also do at the same time, do a slight adjustment of the price.

So this beacon light becomes a little bit hefty when it comes to price compared to what we sell this truck for. So that we not only do one thing, maybe we do two things.



Expect high-fives when you’ve delivered this project – but also expect that this is a steep hill to climb.

Managers will just expect that it should have worked from the beginning! And you are indirecltly limiting sales from selling anything they want.

But as a company, expect higher margins and less order errors.


If you only remember 3 things from this webinar, what should that be Magnus?


Don’t over-automate, because of the hidden domino-effects.

Focus on quality! You can always save time later.

Focus on playing the ”broken telephone game” at children parties – do less of that at work.

Patrik, did I catch the most important things?


I’d say, don’t forget a human readable format that you can read and understand for your integrations. Don’t let code get in the way of understanding what’s happening from a business perspective!


Any more questions, just give us a call


Patrik +46736614953

Magnus +46762098557

Top 5 things you should read or listen to before starting your CPQ project

Posted On Monday, November 2, 2020

Ok, so you're planning to implement CPQ at your business. You figured you should maybe do some reading to learn some tips and tricks. Where should you start?

We've collected the 5 most important things you should read or listen to about CPQ before starting your project.

1. Gartner's Magic Quadrant

Gartner publishes a research paper once a year in the form of a Magic Quadrant. The latest version was released in Fall 2020. The document can usually be downloaded for free from some of the vendor's web sites (Tacton).

2. Knowledge-Based Configuration: From Research to Business Cases by Alexander Felfernig, Lothar Hotz, Claire Bagley, Juha Tiihonen

This is an academic-styled book about configuration. We don't recommend you to read the whole thing, as it will gain you limited value for actually implementing CPQ. We do recommend chapter 2 for a brief history of configuration, chapter 6 for understanding of different technologies for CPQ and chapter 16-19 for valuable insights into implementations at different companies.

3. Product Customization by Lars Hvam
This is a really good book for preparing your company for a CPQ implementation, how to document your CPQ data before the implementation.

4. The CPQ Podcast

Novus CPQ is an independent CPQ analyst firm. Their podcast is focused on interviewing experts and CPQ vendors. Some of their interviews are really insightful:

5. Top 10 reasons why CPQ projects fail

Don't miss this blog post describing the top 10 pitfalls when implementing CPQ. Learn from mistakes made in other CPQ project, and avoid doing them in your project.

Constraints, rules or relations - what's the difference?

In CPQ, there's a lot of talk about the way you describe how the products can be configured. Some vendors talk about constraints, some about rules, some try to get around it by calling it constraint rules (I'm looking at you Apttus/Conga!).

All in all though, who cares about what they are called? The more important question is how easy they are to set up and maintain.

Tacton calls it constraints. If you look up the word constraint, it's a limitation or restriction - which is actually a good way to think about it. Without constraints all combinations of all items in the product can be combined in any way the customer wants. With a constraint, you limit the way you can combine the product.

So if you have 100 rims and 100 tyres, and you want to describe the valid combinations of these - how do you do?

In Tacton, you try to figure out the natural law, of why they work together. So, why does a tyre work with a rim? Well, they obviously have to fit. So the width of the rim needs to match the width of the tyre. In Tacton language:


And that's it. It's a natural law. It's true today, and it's true tomorrow. Most likely it's true in 10 years (if we haven't come to flying cars by then...). I want to point out, that usually, there's a number of constraints working together, so there's going to be constraints about diameters, materials, tyre patterns etc. But let's stick to one constraint for now.

So now you may be thinking, is there any other way? This seems to be the smartest way?

Yes, this is the smartest way - but there are many more ways you can do this. You can write relations, e.g.

tyre A works with rim A, B and D
tyre B works with rim C
tyre C works with rim D and E

This works. And sometimes this is the only way to describe the product (typically where things have to be tested to ensure it works). But this way stinks in general, because is the first relation true tomorrow? Maybe, maybe not. Who knows? So it becomes a very cumbersome way to describe things. Also, this is an easy way to get to 10,000 rules or more.

So, in summary. Ignore what the product description method is called. But do make sure it's easy to set up and maintain over time!

A brief history of product description models

Posted On Wednesday, April 3, 2019

In the early days of manufacturing, products were not very complex and it was sufficient to provide a simple parts list, in order to define the product content. With time, the product complexity grew and the number of variants that some companies were offering the market increased; therefore product description models and tools had to be developed.

The next step in product description models was to introduce a hierarchical structure to the parts list to keep control over the evolving number of parts. But during the 70’s and 80’s products in some industries started having so many variants that it became too tedious to update each variant of each model as a separate hierarchical product structure. Companies started using labels to describe the usage of sub-assemblies that were alternatively used in different variants of the product.

In modern product description the whole structure is parametric hence configurable. The elements are abstract representations of design solutions and will only represent physical parts or assemblies when they are configured through assignment of values to the necessary parameters. The driver for the change from a parts hierarchy with variants to configurable structures is usually attributed to mass customization.

Publicly available B2B CPQ examples

Posted On Saturday, February 2, 2019

(updated 2020-06-24)

Configurators built using CPQ software :

ABB (Configit)
Aritco (Animech Technologies)
Bennington Marine (Verenia)
Bürkert (Tacton)
Demag (Camos)
Ebara (Intelliquip)
Festo (Camos)
Grundfos (Configit)
John Deere (Configit)
Lisec (Encoway)
Maxon motor (Camos)
Mercedes-Benz Trucks (CAS Software / SAP)
Oldcastle (KBMax)
Scania (Tacton)
Tuff Shed (KBMax)

Demos by vendors:

Bike/Lawn Mower/Etc (e-Con Solutions)
Elevator (Tacton)
Hearing Device (Configit)
Med-tech cart (Tacton)
Scissor lift/Cupboard/Etc (DriveWorks)
Truck (Tacton)

Notable configurators built in-house:

DAF Trucks
International Trucks
MAN Trucks
Montech AG
Renault Trucks
Siemens AG

Other configurators may be found in the configurator database, however most of them are very simple B2C (Business to Consumer) products.

How CPQ analytics can improve product development

Posted On Friday, August 18, 2017

One interesting aspect of an implemented CPQ solution is the possibility to analyze sales in a new way.

Traditional sales statistics answers the question what has been sold. This is somewhat interesting but normally it doesn’t bring very much new insight to the table.

With clever BI-tools (like Tableau or QlikView) it’s possible to slice the data in a way that will give you a better understanding on what’s tending and who is really doing profitable sales. But this still doesn’t answer the big question… With ordinary sales statistics one can tell WHAT is selling, but it doesn’t answer the question WHY?

A CPQ solution makes it possible to keep track of all quotations. This opens up for analysis where one can compare successful quotes with the less successful. This type of analysis will give concrete measures on what products that has been offered and make it possible to compare it what has actually been sold.

The analysis gives the possibility to reduce the product portfolio based on what has been part of actual quotations and if it has been sold. This gives a rating per sub-component whether a certain product is providing adequate value on the market.

The analysis also answers the question where there is possibility for new business. By understanding the type of deals that are refused by customers gives great input for product development.

This video introduces the concept of CPQ analysis.

Powered by Blogger.

Get In Touch

Lyckan 7, 753 24 Uppsala, Sweden
+46 736 614 953

Contact Form




© cpq.se. All Rights Reserved