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

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

Mass Customization - a brief history

Posted On Thursday, May 2, 2019

During the 1980-90’s manufacturers in the developed world were faced with saturated home markets and sophisticated customers. The markets were so large though, that they remained attractive to emerging competitors from developing countries, typically entering the market with low price and relatively unsophisticated products.
Many of the traditional manufacturers responded to this competition with the continuous-improvement school. In continuous improvement, the manufacturer drives the employees to find faster and more efficient methods to develop and make low-cost, defect free products to be able to deliver new products to the market quicker. This enabled mass producers to quickly respond to changing market preferences, and to continuously invent and use new technology.
These manufacturers were able to continually introduce new products with more features, increasing the variety offered to the customer. A new paradigm emerged from this – mass customization. According to the mass customization guru Pine, a mass customizer is a company that “develop, produce, market and distribute goods and services with such variety that nearly everyone finds exactly what they want at a price they can afford”.
However this move move to mass customization created conflicts in the different system that had been optimized for low cost and lean production with relatively low variety. Continuous improvement and mass customization require very different organisational structures, values, management roles and systems, learning methods, and ways of relating to customers. It also requires a completely different approach to product description as described above.
Despite the fact that so many companies are struggling with mass customization, most manufacturers are joining the quest. Mass customization offers a solution to the basic dilemma of whether to produce large volumes of standardized goods at a low cost or to decide to differentiated products in smaller volumes at a higher cost. The choice does not have to be made; a true mass customizer can be both a mass producer and an innovative specialty business.
CPQ in the era of Mass Customization
Mass customization requires a very different approach of selling products compared to traditional selling of standard products. The customers are offered a wide range of options of each product, and must be supported in the selection process. This site’s purpose is to look into the methods when implementing CPQ systems which are required when selling mass customized products.

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.

Configurator challenge

Posted On Friday, March 8, 2019

The configurator is one of the more difficult parts to evaluate in a CPQ-solution. The most straight forward way is probably to set up part of your real product rules in the CPQ system. However, this exercise is time consuming if you are evaluating multiple vendors. You are also likely to get questions from the vendors which in turn consume even more time.
It is not uncommon to try to solve this by instead giving the vendors a general problem and ask them to solve it. The travelling salesman problem is one typical example, however these problems tend to be completely unrealistic and have almost no relation to real configuration problems.
Below is an example of a configuration task that can show you how the configurator works. The main complexity with this challenge are all the ‘or’ statements which are very common product rules problems, but that are difficult to solve with a simple configurator.
Please contact us to get the expected results for the scenario.
Configuration task 1: 
  • A: integer between 1 and 5
  • B: integer between 1 and 5
  • C: integer between 1 and 5
  • D: integer between 1 and 5
  • E: integer between 1 and 3
  • F: integer between 1 and 9999
  • G: integer between 1 and 9999
  • H: integer between 1 and 20
  • Rule 1: A=2 requires D=4
  • Rule 2: B=1 requires (A=1 and E=1) or (A=2 and E=1)
  • Rule 3: C=1 requires (A=3 and B=2) or (A=4 and B=2)
  • Rule 4: C=2 requires (A=3 and B=2) or (A=4 and B=2)
  • Rule 5: C=3 requires (A=2 and B=1) or (A=3 and B=2)
  • Rule 6: C=4 requires B!=4
  • Rule 7: C=5 requires D=3 or D=4 or D=5
  • Rule 8: A=2 requires G=1 or G=2
  • Rule 9: D=3 requires F=3 or G=4
  • Rule 10: A >= F
  • Rule 11: E >= F + G
  • Rule 12: H = A * B

Why is product configuration complex?

Posted On Thursday, January 17, 2019

In essence, a product configurator is only a bunch of selection menus that you need to keep track of to validate that it is technically correct solution. So why is it complex, and why do you need a tool for it?

The easiest way to explain this is to think of a typical configurator for a product. Imagine that our sales configurator has 25 questions, with an average of 10 answers to each question. This is a reasonably sized configurator, your product may very well have many more questions. So how many theoretical variants of the product do we have? To calculate this, you have to take the number of variants in question 1 which is 10, multiple by the number of variants in question 2 which is also 10, and keep on going...

So basically 10x10x10… until we get to 25 questions. So this gives us 10^25 number of solutions (that’s a 1 with 25 zeros).

This is a large number, but how large is it? Well, imagine we spend 1 millisecond (a thousand of a second) to analyze each potential solution just to make sure it is valid or not. Well, then we would spend the time equal to the age of our universe 10000 times (the age of the universe is about 10^21) to validate that our solution is correct.

So it becomes obvious we cannot analyze each solution in a configurator. We can cheat - and just try the configuration the sales rep put together and check that all rules are ok. But then we won't know if there are any better solutions out there.

Tacton uses a constraint-solving configuration engine, to try to do something smarter.

Contact us to find out what!

Top 4 reasons why manufacturers choose a CPQ solution

Posted On Wednesday, July 23, 2014

What criteria can you use to determine if your company needs a CPQ solution? How can you tell when it’s time to invest in CPQ software?

I wouldn’t set out specific criteria as much as offer four reasons that I think will help you sort out an answer.

This is what we hear over and over again from clients and potential customers.

Spend more time selling
Is there a feeling that not enough selling is being done by your team? If so, this deserves your immediate attention.

Sales people are expensive and their primary role is to engage with customers and prospects. This is how your organization generates revenue.

Preparing quotations and proposal documentation is still a major tasks in many sales organizations. If this can be reduced there will be more time for actual selling.

Better proposals
A good quote delivers a vibrant, crisp and compelling proposals that distinguish you from the competition. A superior quote will persuade your customer and win more business.

Developing best practice for quotes, RFP documents and other sales documentation enables your team to increase the overall quality of the delivered proposals.

A better proposal will tell the customer that you will fulfill their needs and deliver what the customer wants. A better proposal that will provide important benefits and clearly describe the delivered value. A better proposal that validate that you have the right qualifications to fulfill the customer needs.

The proposal should send the message why your company better than anyone else can deliver the optimal solution with the highest value.

Get the price right
Working with complex products is somewhat problematic. To get the price right is a challenge and it makes a big difference when it comes to bottom line earnings.

The first problem: One option often requires another option. Forgetting that other option in a quote can be will severely reduce the profit. But to keep track of all options and exception is a difficult task that requires up-to-date knowledge.

The second problem: When multiple products are combined there is normally a reduction in price that only applies under certain conditions. To work with packages is an efficient way to expand the offering, but it also requires that up-to-date knowledge.

The third problem: In a changing world pricelists need to adopt fast. What was previously done on a yearly basis is nowadays more likely to be day-to-day updates. To be able to adopt to changing circumstances also requires that up-to-date knowledge.

First to respond
When a customer asks for a quotation or proposal it’s unlikely the request is sent only to your company. The most likely scenario is that the same questions and requirements will be sent to up to a dozen competitors.

Companies with an implemented CPQ solutions reports that speed makes a difference when it comes to closing more deals. A rapid respond really makes a difference.

Being the first to respond will in itself not guarantee better business. But in combination with more time selling, better proposals and correct pricing it definitely makes a difference. 

CPQ - Configure, price, quote software

Posted On Sunday, July 13, 2014

This webpage is about quote and proposal software, quote proposal software, price quote software, quote software, quoting software, quote generator software, product configurator, configurator product, product configurator ecommerce, product configuration, what is product configuration, b2b e commerce web, b2b e commerce solutions, b2b e commerce company, b2b e commerce sales, b2b in e commerce, e commerce b2b, what is b2b e commerce, b2b e commerce, web sales software, sales software, b2b sales software, software product sales, sales quoting software, product quoting software, sales quote software, quote generation software, sales quotes software, web quoting software, product configurator software, what is crm on demand, big machines reviews, big machine software, big machines support, big machine cpq, cpq configure price quote, oracle cpq
Powered by Blogger.

Get In Touch

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

Contact Form




© cpq.se. All Rights Reserved