cpq.se
we help nordic small- and midsized manufacturers get started with tools for configuration, pricing and quoting
Get Started
Showing posts with label Tacton CPQ. Show all posts
Showing posts with label Tacton CPQ. 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.

--


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

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

Posted On Monday, November 2, 2020



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:

rim.width=tyre.width

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!

CPQ Partner meetup

Posted On Friday, November 8, 2019


The partner network for CPQ and especially Tacton CPQ is expanding in the Nordics. Yesterday we had a first meetup in Uppsala, organized by cpq.se and hosted by Sisyfos Digital.

We started out with a short introduction of all attendants. There were six companies joining during the day.

CPQ Finland - CPQ implementation in Finland with extensive knowledge in PLM.

Cloud Exponent - 20+ Tacton experience with focus on business transformation and expert on SalesForce integrations

Metro Communications - Microsoft partner in the UK with long Tacton experience now focusing on cloud solutions including Microsoft Dynamics

OMT - Business engineering with 50 years combined experience within their CPQ consulting team

Sisyfos Digital - working with digitalization and PIM (and my favorite Uppsala consulting firm)

cpq.se - that's us. Tacton CPQ re-seller in the extended Nordics and CPQ expert consulting.





The purpose of the day was to bring together some of the people that have reached out to myself and Patrik over the last months. We started out with speed-dating, but quickly realized it was more of ex-on-the-beach.

Many of us knew each other from previous endeavors, but there were sure new faces to be introduced as well as new collaborations to be investigated.
Today’s topic - How to present CPQ

The topic for the day was sales and the second session focused on a meta-presentation how we at cpq.se present the concept of CPQ, challenges for our customer, value delivered, quick demo and subscription fees. The presentation ends with a proposed next step.

Next thing, after some traditional Swedish fika, was for every company to present their take on the CPQ sales pitch. After a few minutes of preparation each company presented their view of how to present CPQ to their customers.

With all the expertise in the room there was a very good discussion on how each and everyone of us could improve and optimize the pitch.

The afternoon went by really fast and we finished of the day with a visit to my favorite local brewery in Uppsala. During the evening we were joined by some old friends from Tacton. The picture above was taken by our guide Colin when we had a first ever taste of the upcoming collaboration between Uppsala Brygghus and Edge Brewing.

A very inspiring day. We will definitely meet-up again to discuss opportunities and challenges in the CPQ business.

Tacton CPQ Enterprise vs. Tacton CPQ Professional

Posted On Thursday, September 26, 2019

Tacton CPQ is available in two editions – Tacton CPQ Enterprise and Tacton CPQ Professional.

The Professional Edition is an out-of-the-box solution with predefined industry-specific workflows, templates and processes. This typically meets the needs of small and medium businesses looking for the advantages of a standard CPQ solution.

The Enterprise Edition can be more tailored to meet specific business requirements and extends the functionality of Tacton CPQ with even more configurability.

So, what’s the big difference?

In Tacton CPQ there are different objects very much in the same fashion as you find in CRM-systems like Salesforce and Microsoft Dynamics. Standard objects are Account, Opportunities, Solutions, Approvals, just to name a few.

In Tacton CPQ Professional all necessary objects are already predefined but new objects can not be created, but the existing objects can be tailored. In Tacton CPQ Enterprise it is possible to create new objects.

So, what does this mean? 

Let me give an example…

Say that you have something called “Purchasing agreements” that gives certain customer an extra discount for selected pricelists. Both Tacton CPQ Professional and Tacton CPQ Enterprise supports pricelists, but if you want to add additional business logic to your pricing combining pricelist with account one way to do this would be to define a new object, a purchasing agreement object.

In practice this means that if the initial CPQ-analysis shows that there might be a need for one extra object there is usually no need to worry. If we wanted to solve a few “Purchasing agreements” we could extend the pricelist objects, add a few extra pricelists and the problem would have been solved. 

The real difference is when there is a need for multiple new objects to sort out complex business logic. So, rule of thumb is to move to Enterprise once such complexities gets too tricky.

There are a few limitations to Tacton CPQ Professional that one needs to take into consideration. In the table below we point out the major differences in the table below.


Tacton CPQ Professional
Tacton CPQ Enterprise
Advanced Configuration
X
X
Advanced Pricing
X
X
Simple document generation
X
X
Advanced document generation
-
X
CPQ Branding    
-
X
Workflows
X
X
Lead generation
-
O
Industry-standard User roles
X
X
Custom User roles
-
X
Business approvals
X
X
Technical approvals
X
X
Visualization
O
O
iPad App
O
X

Tacton CPQ Professional is set up based on years of CPQ-experience to give an out-of-the-box setup ready to tackle the common CPQ challenges. In the illustration below the standard workflow and supporting objects are displayed. To put it simple; if you need to define more blue or gray boxes Tacton CPQ Professional is not for you. If you think that your business operates like most businesses, you should probably get started with Tacton CPQ Professional. 



So, what about the price? Is there a difference? What do I need to pay?

We’ll let you do the math and give you a clue; if you pay the same amount of dough Tacton CPQ Professional will increase your number of users by 50 % compared with Tacton CPQ Enterprise.

It’s our firm belief that 90 % of small and medium business will be more than satisfied with Tacton CPQ Professional. After a CPQ Analysis workshop we can tell you for sure.
Powered by Blogger.

Get In Touch

Lyckan 7, 753 24 Uppsala, Sweden
+46 736 614 953
info@cpq.se

Contact Form

Name

Email

Message

© cpq.se. All Rights Reserved