03—Services
Product Configuration / CPQ
A product configurator is only useful when the system actually understands the product.
The logic behind a configurable product
A product configurator is only useful when the system actually understands the product.
That does not mean packing in as many rules as possible. The model mainly has to know which choices exist, which combinations are valid, and what a choice means for geometry, material, price, engineering and possibly production.
I like working on that underlying product model.
More than ticking options
For simple products a list of options and a few price rules is enough.
For complex technical products that changes quickly. Dimensions affect components, material choices limit other possibilities, and some executions ask for a different product structure. Some relations are direct calculations, others work better as rules or constraints.
I try to keep those different kinds of logic apart on purpose. Not because every model has to be theoretically perfect, but because a configurator stays much easier to maintain when it is clear why something happens.
Rule-based and constraint-based
For a long time I mainly worked from parametric CAD and directional rules. That remains an excellent approach for many situations.
Since I have worked with Tacton and constraint-based configuration, I look differently at products where choices influence each other in more than one direction. In those systems it is often better to lock down relations that have to stay valid, instead of building a long chain of if/then rules.
I do not choose one technique in advance. The product determines which logic is needed.
CAD, pricing and manufacturing
For me product configuration does not necessarily stop at the edge of the CPQ tool.
A technical product eventually also has to be designed and made. That is why I like looking at the connection with CAD, engineering automation and manufacturing. The same product knowledge can then be used further for geometry, bills of materials, drawings, price calculations or production output.
That does not all have to live in one system. More important is that the meaning does not have to be translated again every time.
Where I can help
I can help structure a product family, set up parameters and domains, rules and constraints, product structures, and the connection to CAD or other technical output.
That can be inside an existing CPQ platform, or as part of a custom configurator when a standard package does not fit well.
My role often sits between product knowledge and implementation: first understand what is actually being configured, then decide how the system should model it. Have you got a product that is hard to capture in rules, or a configurator that collects more and more exceptions? Send me some context.
02—Selected