Chapter 4: The Museum of Variants
Open your ERP and count the part numbers that differ by almost nothing. The bracket that exists in four finishes because four different customers once asked. The motor variant nobody has ordered since 2019 that nobody dares delete. Thousands of near-identical articles, each one a fossil of some deal, lovingly preserved forever.
The ERP is a museum of variants. And everyone who works in it has quietly become a curator.
Ask how this happened and you'll hear that the market demands it. Customers are demanding. Every machine is unique. We're an engineer-to-order business. Then run one diagnostic and watch the story collapse: pull your last fifty orders and count. How many engineering touches did each order actually need? How many of those approvals changed anything? In my experience, seven out of ten engineering sign-offs are rubber stamps. The engineer looked, nodded, and billed the calendar three days. And roughly 20 percent of your choices drive 80 percent of your revenue, while the rest of the catalog generates quotes, questions, and inventory.
One manufacturer told me, with a straight face: "We call everything ETO because engineering touches it." That sentence is worth an audit. Engineer-to-order is a legitimate business model. It is also, in many companies, not a strategy at all, just a process nobody decided to pay for. When everything routes through engineering "just to be safe," oversight has replaced ownership and delay has been normalized into the culture.
Here's the reframe this chapter exists for: your complexity is not a market condition. It's an accumulation of decisions nobody made. Every exception a salesperson won and nobody productized. Every acquisition whose catalog was never merged. Every engineer's special solution that was never promoted to standard or retired. Variety kept arriving because saying no was nobody's job.
What deciding looks like
A compressor manufacturer I know lived the classic version: quotes took three to ten days because everything was ETO, everything went through the experts, and the experts were drowning.
The fix wasn't heroic software. It was a decision. They analyzed what they had actually sold, and structured the offering into nine modules with clear interfaces, described in a single 150 percent bill of materials: one master structure containing every allowed option, from which each real machine is a selection. The rule of thumb they applied is one you can steal today: if the same "special" request shows up three times in twelve months, it isn't special. It's unstructured standard, waiting to be productized.
The results, within months: 80 percent of deals quoted the same day. Engineering stopped reviewing standard quotes entirely, because standard was now defined and enforced. Margin variance shrank, because pricing stopped being renegotiated against a unique machine every time. And the field stopped calling that one expert, because the answer was in the structure instead of in his head.
A medical-device maker took it one step further and encoded regulatory requirements at the module level. Entering a new market went from a product-development project to configuration work: switch the market, and the compliant variants select themselves.
Notice what didn't happen in either story. The product didn't get simpler. The decisions got explicit. That's the entire trick. Complexity isn't the enemy; unstructured complexity is. Customers can have their variety, but every variant either lives inside the structure, priced and validated, or it's a conscious exception with a name on it and a path to a bill.
Anti-pattern: The Foggy Middle. Half configure-to-order, half engineer-to-order, with no line between them, so engineering signs off on everything "just to be safe." The result is CTO lead times with ETO costs: the worst of both, permanently.
The scorecard from your last fifty orders will tell you where you stand. The harder question is what to do at the boundary: what exactly is a module, who owns the interfaces, and who gets to say no?
That's not an engineering question. That's the subject of the next chapter, and it belongs to you.
You don't have millions of variants because customers need them. You have them because saying no was nobody's job.