That is logical from a sales point of view: a customer chooses an execution, the system calculates a price, and a quotation comes out. But for technical products the work of course does not stop there. Someone still has to engineer, prepare and make that product afterwards.
That is why I sometimes use the term CPQM: Configure, Price, Quote, Manufacture.
Not because I want to turn it into an official new standard, but because that extra letter makes clear for me that the configuration also has consequences for production.
A configuration is only really valuable if it can continue
A configurator can know perfectly which product the customer wants.
It knows the dimensions, options, materials and price. But if an engineer then has to take everything over again to make drawings, cutting lists or CNC data, there is still a break in the process. For some products that is not a problem, and sometimes human engineering is exactly what is needed. But on strongly repeatable products you preferably want the knowledge from the configuration to flow further.
Then an entered dimension is not only used for a price, but also for geometry. Then a material choice is not only commercially locked, but also taken into bills of materials, production output and checks.
That is the point where CPQ, for me, shifts toward manufacturing.
Pool covers make that difference very tangible
At Technics & Applications that came together well.
They make motorised pool covers with slats. At first sight that still looks fairly straightforward, especially if you think of a rectangular pool. But as soon as a pool has curves or fillets, the length of the slats changes across the width of the pool. You then do not get one standard size, but a series of parts that each have to be produced at the right length and in the right sequence.
Then you immediately see that configuration is much more than a sales tool.
The shape of the pool affects the geometry, that geometry determines the length of the slats, and that information finally has to flow through to production in a usable way. At the same time the motorised system also has to be chosen and calculated correctly. That is typical CPQM for me: the product knowledge continues into manufacturing.
The M is not only about CNC
Connecting manufacturing to configuration does not mean for me that every system has to generate G-code directly.
That would be too narrow. The real question is rather which production information can reliably come from the product model. That can be a cutting list, a sheet unfolding, a drilling pattern, bill-of-materials information, production drawings, or a set of parameters for existing CAM software. Sometimes that information goes directly to a machine, sometimes first to another system.
For me that all sits under the same thought, as long as the configuration can pass on the right manufacturing intent.
Manufacturing has to play along early enough
A classic problem is that a configurator sells something that looks commercially valid, but in practice turns out to be awkward or even unmanufacturable.
Maybe a plate is too long for the press brake. Maybe a chosen profile only exists in fixed stock lengths. Maybe a certain material-thickness combination cannot be processed on the machine that is there. If you only pull that knowledge up after the configuration, you are actually too late.
I find it much more interesting to take those production limits along at the moment they actually influence the product. Not to put the whole factory into a CPQ model, but to avoid engineering and the workshop having to correct the same limits over and over.
From choice to production intent
That is also the difference for me between a simple option configurator and a technical product model.
An option configurator may know that the colour is black, the width is 1800 and motor B is chosen. But a product model has to be able to explain further what those choices mean. Which components change with them, which operations become needed, which quantities follow, and which output production expects.
The more explicit that model is, the less knowledge is lost between sales, engineering and the workshop.
CPQM should not become a monster platform
There is a risk in this.
As soon as you add manufacturing, the temptation is large to also want to capture CAD, ERP, MES, CAM and machine control in one total platform. That usually seems a bad idea to me. I do not see CPQM as an argument to push everything into one system, but rather as a way to look more sharply at the boundary between configuration and production.
The core question for me is:
how far does the product model have to go so that configuration can flow through to engineering and production without losing knowledge?
Sometimes the answer is a DXF. Sometimes a cutting list. Sometimes a fully generated production set. That depends on the product and on the workshop.
Why I still use the term
I use CPQM mainly because it forces me to think one step further than quotation and price.
For technical products a configuration is not finished when someone presses “order”. The real value only appears when that same product knowledge stays usable further — from choice to geometry, from geometry to engineering, and from engineering to production.
Without having to interpret the same product again every time.
That is what CPQM tries to capture for me.