Why configurator projects don't get finished
When we talk to a manufacturer about a configurator, it is rarely the first attempt. Usually there was one before. And usually the story runs the same way.
The software was selected, the licence bought, a pilot set up. The pilot worked. Then the real modelling was supposed to begin: the product logic, the rules, the pricing. That task landed with someone who was already fully occupied. After nine months the configurator covered part of the range. After two years it was no longer in use in sales.
That is not a statistic. It is a course of events that has been described to us, in that shape, more than once.
In some cases the licence is still running.
The configurator didn't fail. It was never finished.
That is a different diagnosis from "the software didn't work." And it leads somewhere different: not to another product, but to another way of running the project.
This pattern is neither rare nor a sales invention. The research literature on configurator projects describes exactly this course: projects regularly fail because the configurator is never fully developed, or ends up not supporting its users as intended. What is identified as particularly demanding is not the technology but the acquisition of product knowledge, the scoping of the project and the modelling itself.
Anyone who has seen it once recognises the intermediate states. The configurator handles the standard variants. But half the enquiries are not standard variants. Sales starts keeping a spreadsheet for those. Once there are two routes, the faster one wins — and the faster one is the spreadsheet.
From then on the configurator is a secondary system. Secondary systems don't get maintained, and what isn't maintained is wrong after two pricing rounds.
The problem is the definition work, not the tool
The common explanation is that the knowledge sits in experienced people's heads and cannot be got out. Part of the research considers that explanation too simple. The soberer finding: product knowledge is spread across departments, drawings and existing systems. Assembling it, reconciling the contradictions and getting it signed off is possible — but considerably more work than was assumed at procurement. Knowledge acquisition is treated in the literature as a challenge category in its own right, and not without reason.
What has to be assembled is rarely tidy. There are design rules that live in drawings. There are manufacturing limits nobody wrote down because the shop floor knows them anyway. There are pricing rules that are part calculation and part experience. And there are exceptions handled differently depending on the customer.
All of this can be resolved. But resolving it is a project, not a by-product. It takes interviews, reconciling contradictions, decisions about which exception applies from now on, and sign-off by somebody who can stand behind those decisions.
In most projects that work is assigned to nobody. It falls to the most capable person in the building, on top of their actual job. That person is also the one the daily business can least spare.
A configurator project rarely fails on a decision. It fails because the modelling stays permanently the second most important task of someone whose most important task is urgent every day.
A common answer to engineer-to-order is: become configure-to-order first
Many configuration platforms are at their strongest in configure-to-order. The product architecture is fixed, the customer selects from predefined building blocks, and the system generates the bill of materials and the price.
For manufacturers who work that way, it works well. Configurators explicitly built for engineer-to-order also exist; the question is not whether they exist, but how well they fit your range and the effort they demand..
Look at what platform vendors publicly recommend to engineer-to-order manufacturers. Frequently the recommendation is to standardise the product into modules and reduce the share of genuinely bespoke engineering. That direction is not purely vendor interest: research on ETO companies also describes greater standardisation of the offering as a route. It does not, however, change what it is.
For some manufacturers that is a sensible strategic move. It is simply not a software project. It is a restructuring of the product programme, of engineering and partly of the sales promise, and it gets bought as a software procurement. That is why the modelling takes so much longer than planned: before anything can be modelled, somebody has to decide what the range should consist of in future.
If your business consists of every machine being different, that restructuring is not always the right road. Sometimes the variety is precisely what your customers pay you for.
Between "everything configurable" and "everything bespoke" sits the case that is usually the realistic one for ETO manufacturers: part of the product is configured, the rest remains engineering work. The configurator then produces not the finished product but the configurable share, together with a clean requirements list for the remainder. This is not a compromise of convenience — it is the shape that fits a range made of fixed and free parts. So the question to put to any vendor is not whether they can configure your product completely, but how they handle the part that cannot be configured.
Ask early whether you are introducing software or rebuilding your product programme. Either can be right. They are two different projects with two different timescales.
A rule base is not a project, it is an asset to be kept
Product knowledge changes continuously. Suppliers change, standards are updated, prices move, a new series arrives. Every one of those changes has to be carried into the rule base, or the configurator drifts away from reality. And a configurator sales no longer trusts is not debated, it is bypassed.
So the maintenance question is not an operational detail for later. It is part of the business case before the decision. Who maintains the rule base in two years? With what share of their time? And what happens when that person leaves?
If the answer to the first question is the same overloaded person who was supposed to do the initial modelling, you already know how the rest goes.
We don't supply the tool. We supply the finished system.
We do not sell you a platform in which you then model your own product. The modelling is the engagement, not your homework afterwards.
Material rules, manufacturing limits, surcharges, the exceptions your sales team grants by feel. It gets documented, put in front of you and approved by you. The side effect is often worth more than the software: for the first time, how your company actually prices is written in one place.
We don't model a catalogue of pre-built variants. The product is generated at runtime from its components — profiles cut to length, accessories attached, the model assembled on demand. The rules underneath check buildability: combinations recorded as not manufacturable cannot be selected. How far that carries depends on how completely your manufacturing limits have been captured and kept current — which is part of the definition work too.
The test is not whether the system was signed off, but whether it is still in daily use half a year later. That is why we settle the maintenance question before the quotation rather than after.
We do not assume you will standardise your range first. Where standardisation genuinely makes sense we will say so — as its own subject, not as a hidden precondition.
Five questions for any vendor, ourselves included
If the answer is someone in your building, settle how many hours a week they are released for it and who covers their existing work.
Not the catalogue, the actual enquiries. The remainder decides whether the spreadsheet stays in sales.
If so, that effort belongs in the same calculation as the licence.
And what does that maintenance cost if we don't want to do it ourselves?
Share of quotes produced by the system, lead time from enquiry to quote, amount of rework. Agreed before the project, not after.
If an earlier attempt already failed at your company, the modelling documented in that project is not wasted effort. It is often the most usable starting point for a second attempt — whoever you make that attempt with.