Officially, your best-selling machine comes in three versions. The server holds eleven. A longer one, a heavier one, two with a different drive, one for that customer with the low building, and a few that nobody can explain anymore. No one ever decided there should be eleven flavors. It just happened, copy by copy, deadline by deadline.
That silent sprawl is rarely a matter of sloppy engineers. It is a matter of missing ground rules. If you want to manage product variants in CAD seriously, you need an answer to three questions: when does a deviation deserve its own article number, who owns which version, and what exactly is the base that all those flavors descend from? This article lays out those ground rules, with examples from machine building and sheet metal work. Tooling helps you stick to them afterwards, from a clear naming convention to a toolbox like Thundercad, but the rules come first.
How eleven flavors appear without anyone deciding
Sprawl almost always starts with a reasonable decision under time pressure. A customer wants the conveyor one meter longer; the engineer copies the existing conveyor, stretches the frame and makes the deadline. The copy stays on the server, because deleting it feels like destroying value. A few months later another customer asks for that same length, but with a heavier drive. The new engineer does not start from the base but from the copy, because that one was the most recent. And so version eleven descends from version nine, which descends from a customer special from years back, complete with the deviating base plates nobody has asked for since.
Every step was logical; the result is not. What silently travels along with such a copy, and how to set up a clean one, is something we covered earlier in Reusing models without carrying over the old mistakes. This article is about the question that comes before it: should that eleventh version have existed at all, and if so, under which number?
Variant, configuration or customer special: choose deliberately
The core of keeping variants manageable is choosing consciously what each deviation is. Three categories cover practice:
| Variant | Configuration | Customer special | |
|---|---|---|---|
| What it is | Fixed version with its own article number and document set | Same model, different parameter values within defined limits | One-off deviation within a single order |
| When | The deviation will recur and production must see the difference | The difference can be set with dimensions or options | The deviation is one-off and likely stays that way |
| Lives in | The managed product range | The base model itself | The order folder, not the base |
| Example | Heavy-duty version with double drive | Belt length adjustable within a fixed range | Deviating foot for one specific building |
The decision rule in words: if production, purchasing or service has to treat the deviation as a different product, it is a variant and it deserves its own article number with its own document set. If the difference can be set within the existing model, it is a configuration and no new article should appear. And if the deviation is genuinely one-off, treat it as a customer special: it lives in the order folder and never pollutes the base.
The most expensive form is the in-between: a copy that was meant to be temporary and quietly starts leading a half-life. No number, no owner, but real customers.
Give every version an owner and a status
Eight near-identical copies are hard enough; eight copies without an owner are unmanageable. Nobody dares to throw one away, because somewhere a machine might be running on it. Nobody feels responsible for updating, so improvements in the base never reach the variants. The remedy is simple on paper: every version has exactly one owner and a status.
- The base has an owner: one engineer or product manager who reviews and applies changes.
- Every variant records in its metadata which base it descends from and who maintains it.
- Every version has a status: active, customer special or phased out. Phased out means: kept for service, but never a starting point again.
- Whoever changes the base notifies the owners of the variants. A short message is enough.
Filling in those fields has to cost next to nothing, or the agreement dies within a month. With the iProperty Panel from Thundercad you record status, base and owner on a configurable data card per document type, so the fields are visible and editable right where the file is.
Status fields and owners only work when filling them in is effortless. With a data card per document type the right metadata is in place within seconds, and you see at a glance which version you are holding.
Try 30 days freeStandardize the base, not the exception
In the end you do not fight sprawl with clean-up actions, but with a strong base. At most machine builders the majority of a machine is identical from order to order; the differences concentrate in a handful of modules. Capture that: one base model per product family, with a fixed list of options and clear interfaces. The customer with the deviating drive then gets a different drive module, not a copy of the complete machine.
Two things keep such a base alive. First, frozen interfaces: connection dimensions, mounting patterns and reserved spaces are fixed, so a module can change without touching the rest. Second, a strict gate: new options enter the base only after a deliberate decision by the owner, never because an order copy quietly trickles back in. How to combine this with an order process where every job is different is covered in Engineer-to-order: every order is different, your process does not have to be.
This works just as well in sheet metal as in machine building. Take a family of electrical enclosures: one base cabinet per size range, fixed positions for glands and hinges, and the customer's wishes live in the door and the internal layout. Treat every cabinet as a new design and you draw the same cabinet slightly differently every week, and within a year you have organized your own sprawl.
Pruning existing sprawl: from eleven back to three
If the server is already full, start small: one product family, one afternoon, two people who know the family well. The approach:
- List every version you can find, including the half-finished ones. Note per version what deviates from the base and when it was last used.
- Decide per version: merge into the base, promote to an official variant with its own article number, or phase out.
- Put the status straight into the metadata and assign owners, otherwise the growth starts again immediately.
- Throw nothing away. Phased-out versions move, clearly marked, to an archive folder: reachable for service questions, invisible as a starting point for new orders.
Do not expect three spotless versions after one afternoon. Do expect the counter to stop climbing, and that is the real win.
Frequently asked questions
When does a customer special get its own article number?
The moment it becomes repeatable: a second customer asks for it, service has to keep supplying parts for it, or production must be able to tell it apart from the standard. Until then the special lives in the order folder under the order number, and the base stays clean.
How many variants of one machine is normal?
There is no magic number, but there is a healthy test. If you can say for every variant who owns it, what sets it apart and when it was last sold, the count is manageable. The moment a version has no answer to any of those questions, it is not a variant anymore but sprawl.
Where do I start when the sprawl has been growing for years?
With one product family, not with everything at once. List the versions, decide per version, mark the status and assign owners, as described above. If you want to record status and ownership on a data card per document type right away, try Thundercad 30 days for free.