For industrial equipment manufacturers
Nobody builds a stock machine. Every unit is configured for an order, and every unit is supported for two decades by people who were not there when it was built.
Configure to order, without a BOM per order
The failure mode this industry knows best is the copied BOM. An order comes in with a particular motor, a particular control package and a longer conveyor; somebody copies last month's structure, edits it, and the company now maintains one more independent bill of materials forever.
After four years that is eleven hundred structures that were once the same machine and have drifted apart in ways nobody has catalogued. A change to a shared subassembly now means finding every copy, and there is no reliable way to do that because the copies are not related to anything.
A configured order should be a resolution, not a copy. One structure carries the options; an order names the option selections; the resolved result is what gets built, and it is reproducible from the selections at any point afterwards.
The rules are where the domain knowledge lives, and in this industry they are mostly constraints rather than choices: this control package requires that power supply, this conveyor length excludes that drive, this regional variant mandates a different guard. Expressed as rules they are checkable at quote time; expressed as tribal knowledge they are checkable when something arrives that does not fit.
Twenty years of service
A machine sold this year will be serviced in 2046 by a technician who will ask one question: what is on this unit. Not what was designed, not what the current model contains — what is actually in front of them.
That answer requires the as-built configuration for that serial: the resolved structure at build, plus every service action since. Replacement parts fitted, field modifications applied, upgrade kits installed, each recorded against the unit rather than folded into a number.
Component obsolescence is the quiet cost of a long service life. A part in a machine built in 2030 may have been unavailable since 2036, and the useful record is not only what was fitted but what has been approved as a replacement — which is AML work done years after the design closed.
Documentation follows the same logic. The manual a technician needs is the one for that unit's configuration, not the current model's, and generating it from the as-built structure is the only way that stays true for twenty years without somebody maintaining a document per serial.
The failure it prevents
A customer reports a failure on a machine built nine years ago. Service dispatches a technician with the replacement part named in the current parts list.
The part does not fit. The unit was built with a different drive assembly, part of an option that was discontinued in the intervening years, and the current parts list has no record of it because the option was removed rather than superseded. The technician leaves, a second visit is scheduled, and the customer's line is down for four more days.
The parts list was current and the machine was not. A parts list generated from the unit's as-built configuration would have named the right component, and the fact that the option no longer exists in the current model is precisely why the as-built record has to be kept rather than derived.
How it meets the rest of the product
Variant rules carry the configuration logic and validate a selection before it becomes an order, which is where they earn their cost. An impossible combination caught at quote is a conversation; the same combination caught at assembly is a machine sitting half-built while somebody decides who pays.
Effectivity handles the continuous improvement that characterises this industry — machines change gradually rather than in model years, and a change effective from a serial number rather than a date is the common case here.
Baselines matter more than usual, because a baseline taken at shipment is the definitive record of what a customer received. It stores the resolved line set and the conditions that produced it, so a dispute nine years later is settled by a record rather than by reconstruction.
How it meets your ERP
This is the industry where the configured-order seam is hardest. Your ERP needs a bill of materials to plan and purchase against, and it needs it per order, which is exactly the thing Manufacturing PLM is trying not to create as a permanent object.
The workable arrangement is that Manufacturing PLM resolves the configuration and publishes the resolved structure against the order, as an order-specific bill in the ERP where it belongs, while the engineering side keeps one structure with rules. The ERP gets what it needs and the copy lives in the system that is supposed to hold per-order data.
Serial-number effectivity has to survive the seam. Where your ERP supports it the publication carries it; where it does not, the effectivity stays here and the ERP receives the resolved structure for that order without the general rule that produced it.
Where the boundary is
Manufacturing PLM does not quote or configure at the point of sale. CPQ tools own the commercial configuration, the pricing and the proposal. What lives here is the engineering rule set that says which combinations are buildable, which a CPQ can read rather than duplicate.
It also does not schedule field service or manage service contracts. It holds the as-built record and generates the documentation for a configuration; dispatch, scheduling and contract management belong to a field service system.
Facts
| The failure mode | One copied BOM per order, drifting apart forever |
| Instead | One structure with rules; an order names selections |
| Rules here | Mostly constraints, not choices |
| Caught at quote | A conversation. Caught at assembly, a half-built machine |
| Service life | Twenty years, answered from as-built plus every action since |
| Effectivity | By serial number as often as by date |
| At shipment | A baseline — the definitive record of what the customer received |
| Not offered | CPQ · field service dispatch · service contracts |
Frequently asked
What is wrong with copying a BOM per order?
After four years you have eleven hundred structures that were once the same machine and have drifted apart uncatalogued. A change to a shared subassembly means finding every copy, and there is no reliable way to do that because the copies relate to nothing.
What replaces the copy?
A resolution. One structure carries the options, an order names the option selections, and the resolved result is what gets built — reproducible from those selections at any point afterwards, including nine years later when somebody needs to know what shipped.
What kind of rules does this industry need?
Mostly constraints rather than choices: this control package requires that power supply, this conveyor length excludes that drive, this regional variant mandates a different guard. Expressed as rules they are checkable at quote time instead of when something arrives that does not fit.
How do we answer service questions twenty years out?
From the as-built configuration for that serial — the resolved structure at build, plus every service action since. Replacement parts fitted, field modifications, upgrade kits, each recorded against the unit rather than folded into a single number that stops being true.
Why not derive the parts list from the current model?
Because the unit may contain an option that was discontinued rather than superseded, so the current list has no record of it at all. That is exactly why the as-built record has to be kept rather than reconstructed from what exists today.
Our ERP needs a BOM per order. How does that work?
Manufacturing PLM resolves the configuration and publishes the resolved structure against that order, so the ERP holds the order-specific bill where per-order data belongs anyway. The engineering side keeps one structure with rules, and no permanent copy is ever created here.
Does this replace our CPQ?
No. CPQ owns commercial configuration, pricing and the proposal. What lives here is the engineering rule set describing which combinations are actually buildable, which a CPQ can read rather than duplicate — duplication being how the two quietly stop agreeing.