Hi all,

Curious how others handle this. When someone wants to automate part of the design process (a configurator, auto-generating CAD models, building BOMs automatically), how do you decide if it's actually worth doing?

One rule of thumb I use: if you gave the same order to two of your engineers, would they come up with the same design? If yes, you can probably turn it into rules. If not, the process usually needs sorting out first.

A few other things I check:
- Does the product change all the time, or is it fairly stable?
- Do you get enough orders for variants to make the setup worth it?
- Is there one person in engineering who owns the design rules?
- Is the BOM and part data clean, or is it a mess?

In my experience, these projects rarely fail because of the software. They fail because the process wasn't settled before anyone started automating it.
What do you look at before automating? And if you've had one turn into a maintenance headache, what should have tipped you off earlier?

Thanks!

 

Your two-engineers test is a good one. Another check is whether the exceptions can be written down: if most orders fit the rules but a steady share still needs manual changes, it helps to decide up front whether those go through the configurator or get handled outside it, otherwise the rule set keeps growing to cover one-off cases. It is also worth asking who will update the rules when the product changes, because a configurator that only one person can maintain tends to fall behind the actual design quickly.

 

Disclosure first: I architected product configurators at Cisco, Dell and IBM, and I now build them for mid-market manufacturers. So I've seen both ends.

Your two-engineers test is the best single check I know. A few I'd add:

1. Run it against your last 50 orders, not the catalog. Count how many your rules would have handled start to finish, how many needed one exception, and how many were real specials. That ratio tells you more than any feature list.

2. Split the rules by how often they change, and give each kind an owner:
- "Can it be built" rules: ratings, code limits, what physically fits. These hardly ever change.
- House standards: preferred brands, spare capacity, wire colors. These change when engineering decides.
- Pricing: changes every month.
Configurators turn into maintenance headaches when all three are tangled in one rule set that one person understands.

3. Every rule needs a source, whether that's a code section, a catalog rating or a named engineer's decision. A rule nobody can trace is one nobody dares change, and that's when the configurator falls behind the product.

4. Decide what happens to specials before you start. The configurator should send them to an engineer, labeled as specials, and not grow a new rule for every one-off. IndustryInsightsDesk's point about exceptions is the same warning.

5. Look at how orders actually arrive. Most configurators assume a clean order form. Real requests come in as emails, specs and one-line RFQs. If somebody still has to turn those into configurator inputs by hand, a lot of the payoff disappears.

To answer your last question: the early warning sign is when the first conversation is about the software and not about who owns the rules.