This section didn't finish loading
Something took too long to respond. Reloading usually fixes it.
Something took too long to respond. Reloading usually fixes it.
By SBFS Team
Every configure-to-order manufacturer has one: the engineer who knows that the 1,200mm door needs the heavier hinge, that the dark oak finish is not available on the fire-rated core, that anything over 2.4 meters ships in two pieces. Quotes queue behind that person, new hires take years to catch up, and a resignation letter is an operational risk. That knowledge — not the 3D model, not the storefront — is the real product a configurator has to carry. Capturing it is called product modeling, and it is the part of a configurator project that decides whether the project works. This article looks at what peer-reviewed research says that work is worth, why it is where projects stumble, how to pull the rules out of people's heads, and what happens when nobody maintains them afterwards.
A product model is your catalog expressed as executable rules. It is not a list of SKUs; it is the logic that decides which combinations exist, what they cost, and what they are made of. In practice it has four kinds of rule:
"Tribal knowledge" is simply that same logic living only as experience. The research literature describes the payoff of capturing it in almost those words: an early study of an industrial configurator credited it with the "formalisation of the company knowledge" and "the transformation of individual competencies into organisational competencies" (Forza & Salvador, as cited in Hvam, Haug, Mortensen & Thuesen, 2013).
The most useful measurements come from a Danish research group that has studied configurator projects in industrial companies for two decades. Their 2013 study followed four companies — cement plants, spray-drying plants, data-centre infrastructure and electronic switchboards — through the move from manual specification to a configurator, with before-and-after figures for each (Hvam, Haug, Mortensen & Thuesen, 2013):
The authors' own summary: across the four cases, lead time fell by 94–99%, on-time delivery of specifications rose to 95–100%, and the staff time spent producing them fell by 50–95%. Two details from the individual cases matter more than the averages. Before its configurator, Company A answered only about half of its quotation requests at all; afterwards every request got a quote. And at Company C, the total lead time from sale to installation fell from 400 days to 16 — because the configurator produced the bill of materials and routings along with the quote.
A companion study by the same group went looking for every published measurement it could find and identified only six cases with usable estimates, reporting up to a 99.9% reduction in quotation lead time, and an average estimated reduction of 85.5% (Haug, Hvam & Mortensen, 2011). The idea is not new, either: Digital Equipment Corporation's XCON configurator was estimated in 1989 to return "in excess of $40 million per year" (Barker & O'Connor, as cited in Hvam et al., 2013). What those companies bought was not software. It was their own product knowledge in a form a machine could apply.
If the payoff is that large, why do so many configurator projects stall? The same research group surveyed 22 manufacturing companies that use configurators — most with 450 or more employees — and asked what went wrong (Kristjansdottir, Shafiee, Hvam, Forza & Mortensen, 2018):
The two most common challenges are organizational and knowledge-related; IT problems come fourth. Within knowledge acquisition the authors name three recurring failures: difficulty acquiring the correct knowledge, a lack of the knowledge needed to meet users' and customers' needs, and failure to communicate knowledge once the configurator is in maintenance. They also describe the tribal-knowledge risk directly: "Confining access to all the valuable knowledge to a small number of employees puts the company at risk if these key personnel leave." A separate study of failed projects by overlapping authors reaches the same conclusion from the other side (Haug, Shafiee & Hvam, Computers in Industry, 2019): the causes cluster around scoping, product knowledge and organizational alignment, not rendering or code.
This is why a vendor demo tells you so little. The demo shows the 3D and the options panel; the project risk lives in your product model, which the demo has never seen. Our buyer's guide suggests bringing your two nastiest product rules to every demo for exactly that reason.
Product modeling is interviewing, structuring and testing, in that order. The approach that works in our projects:
Start with one product line and model it completely — through validity, pricing and the BOM — before expanding. It is the same sequencing that profitable mass customization depends on, and it is the substrate that makes AI in quoting safe to use at all.
A product model is not a one-off deliverable. Products change, suppliers change prices, labor rates move — and a configurator that stops tracking them keeps producing confident, wrong quotes. One case study measured exactly how wrong. Researchers recalculated a year of quotations from a manufacturer's unmaintained configurator in an updated version of the same system — 81 projects covering 2,655 sold products — and found real costs had run, on average, 20% above what the old configurator estimated: a gap of €4.2 million in a single year (Rasmussen, Myrodia, Hvam & Mortensen, 2018).
The largest drift was in sub-supplier costs — exactly the numbers that change without anyone inside the company deciding to change them. The practical defenses are unglamorous: version the rules, tie rule changes to your engineering-change process, feed actual purchase prices back into cost drivers, and periodically recalculate recent quotes against real costs. A configurator whose rules and BOM derivations share one model has a structural advantage here: the price and the parts list cannot drift apart, because they come from the same rules — and the same model can emit the BIM object an architect places in a building model.
It is the part of a configurator that holds your product model — compatibility, dimensional, derivation and pricing rules — and applies it to every configuration. It decides whether a combination is buildable, what it costs, and what it is made of. The 3D view and the options panel are interfaces on top of it.
3D modeling produces the geometry a buyer sees. Product modeling produces the logic that decides which geometry is valid, how it is priced and how it resolves into parts. A configurator can look finished with only 3D modeling done; it only works when the product modeling is done too.
Mostly for organizational and knowledge reasons rather than technical ones. In a survey of 22 manufacturers, 68% reported organizational challenges and 59% knowledge-acquisition challenges, while IT problems ranked fourth at 36% (Kristjansdottir et al., 2018). Unclear scope and product knowledge that never gets fully captured are the recurring causes.
In the one published case that measured it, a configurator left without maintenance saw real costs run 20% above its estimates on average over a year — €4.2 million across 81 projects (Rasmussen et al., 2018). The exact figure will differ for every company; the direction will not, because costs change whether or not the rules do.
SBFS models products as executable rules — validity, pricing and BOM derivation in one model — and builds the configurator, quoting and production tools on top of it. See what we do.
SBFS is led by Juan Acosta, who has spent ten years building parametric 3D configurators, CNC and SVG middleware, and manufacturing workflow software for made-to-order manufacturers.
Field notes for made-to-order manufacturers — 3D configurators, quoting, and production. No spam, unsubscribe anytime.