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

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

Posted On Tuesday, October 8, 2019



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 Apptus!).

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!
Powered by Blogger.
/

Get In Touch

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

Contact Form

Names

Email

Message

© cpq.se. All Rights Reserved