The issue isn’t your ERP. It’s the collision between a variable product and a system that wants fixed truth
When a company tells me “our ERP is useless,” I usually answer with something uncomfortable:
your ERP isn’t ‘bad’—it’s trying to describe a product that changes faster than your data model can represent.
In project-driven operations, the real product lives in configurations. The administrative product lives in item masters and static bills of materials.
That gap is expensive, and it charges you every day.
## What a “variable BOM” really is
A classic BOM says: “to build X, I always need A, B, and C.”
A variable BOM says: “to build X, I need A, B, and C… depending on dimensions, finish, hardware, appliance choice, installation constraints, and availability.”
In other words: your BOM isn’t a list. It’s a set of rules.
If you try to store rules as fixed lists, you end up with either:
thousands of variants (data becomes unmanageable), or
a “manual layer” (operations become unpredictable).
## The giveaway symptom: product truth is decided outside the system
I know you’re trapped in variable BOM pain when I hear:
-
- “the technician adjusts that,”
-
- “production checks it before release,”
-
- “purchasing confirms it with the supplier,”
-
- “installation decides on site.”
Translation: the system doesn’t hold the truth.
And if the system doesn’t hold the truth, everything built on it (cost, purchasing, stock, kits, promises) becomes fragile.
## Five hidden damages you won’t see on one screen
### 1) Theoretical costs that predict nothing
Quotes look profitable. Projects close at a loss. Nobody can explain the gap.
### 2) Reactive purchasing
Urgent hardware, last-minute finish swaps, incompatible parts, “just-in-case” buying. You pay in lead time, freight, and cash drain.
### 3) Unstable production
Flow breaks, micro-stoppages rise, rework becomes routine, and the plan gets rewritten every morning.
### 4) Incomplete kits
Project operations hate “almost complete.” Partial shipments trigger extra visits, rescheduling, and a customer that feels improvisation.
### 5) Uncontrolled change
When product truth lives outside the system, change is negotiated, not governed. The cost exists—but it doesn’t get recorded as a decision.
## The most common mistake: “fix it” by creating more items
Many teams respond by:
exploding the catalog into endless items, or
duplicating BOMs for every variation.
It works until it collapses, because you’re not capturing rules—you’re inflating the catalog.
You end up with either:
a huge catalog nobody trusts, or
an incomplete catalog that forces manual work.
Same problem, different costume.
## How I diagnose variable BOM risk (without jumping into implementation)
I don’t start with software. I start with symptoms.
A) Sales and quoting signals
How often is a quote recalculated?
How many “manual” lines exist (“misc materials”, “adjustments”)?
How many deals require technical validation to be quotable?
If quoting needs translation, the system is already broken.
B) Technical office / engineering signals
How much work is adaptation vs design?
How many issues come from incompatibilities?
How many product decisions depend on “what the supplier has”?
If compatibility lives in tribal memory, variability is in control.
C) Purchasing and inventory signals
How many urgent buys per week?
How much stock exists “to cover uncertainty”?
How often do parts arrive that don’t fit the actual configuration?
If purchasing compensates, the ERP isn’t describing reality.
D) Production and logistics signals
How often does an order stop for one small missing part?
How many partial shipments leave the dock?
How many installations require a second visit?
If incompleteness is normal, the BOM is fiction.
## My favorite metric: “how much of the project can the system explain without a phone call?”
If the answer is “not much,” you’re running on people, not on system. Scaling needs representation, not heroics.
## Configuration, BOM, and change: the triangle that decides whether margin is defendable
In a variable-product business, these three are inseparable:
-
- configuration (what exists for this project)
-
- derived BOM (what it needs)
-
- change (what happens after a promise is made).
If one lives outside the system, the other two degrade—and the language becomes:
“I don’t know why it’s missing,” “I don’t know when it changed,” “I don’t know who approved it,” “I don’t know what it cost.”
That “I don’t know” is margin leaking.
## Financial risk: what you don’t attribute, you repeat
A recurring pattern:
- delays happen
- urgent buys happen
- rework happens
- extra visits happen
and the cost gets booked as “overhead.”
When cost isn’t attached to cause and project, you can’t decide, correct, or defend pricing. Variable BOM pain turns the business into a roulette: good months and bad months with no usable explanation.
## Questions I ask in an ERP demo to detect smoke
I don’t care about “yes, it’s possible.” I care about proof.
-
- How do you represent compatibility rules without creating thousands of SKUs?
-
- How does an approved change update materials, purchasing, cost, and promise—consistently?
-
- How do you ensure production and purchasing are using the same truth?
-
- How do you prevent variability from escaping into spreadsheets?
-
- How do you measure actual cost per project when rework and substitutions exist?
Vague answers predict manual work returning.
## Readiness signals
Ready if leadership wants evidence-based promises, definitions can be aligned, and pain is measurable.
Not ready if every area protects its own “truth,” changes aren’t recorded, and data is untouchable.
In that case, the first move isn’t tech. It’s governance of definitions and responsibilities.
## The decisive test: completeness as a condition, not a hope
In a variable-product operation, everything depends on one word:
completeness.
I know the product is correctly represented when:
- kits can be validated by the system
- shipped complete
installed without surprises.
If that condition can’t be sustained, the business pays in interruptions and reputation erosion.
## Closing
Your product isn’t a SKU. It’s a promise built from rules.
If your ERP can’t represent that reality, growth happens on top of friction.
If you want, we can look at it in 15 minutes: where product representation breaks, what variability is legitimate vs pure disorder, and which decision criteria protect margin without turning operations into a lab.
