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.
--
Magnus: 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
Patrik:
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?
--
Magnus:
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.
--
Magnus:
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.
Patrik:
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.
Magnus:
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.
Magnus:
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.
Examples:
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.
--
Patrik:
Vad ska man börja med?
Quality vs Time-savings
--
Magnus:
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.
--
Magnus:
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.
--
Patrik:
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.
Patrik:
If you only remember 3 things from this webinar, what should that be Magnus?
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?
Patrik:
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