Most PLM systems earn their keep as an expensive filing cabinet for a while. You put parts in, you get parts out, the drawings are current. Then the first real configuration question arrives — what exactly was in unit 147 when it shipped? or if I change this bracket, which of the last two years' builds are affected? — and the filing cabinet has no answer, because those questions are not about storing a BOM. They are about which BOM applied, to what and when.

That is effectivity, and it is the idea that separates a document store from a configuration management system. It is also the concept teams most often try to handle with a spreadsheet, and the one where the spreadsheet does the most damage.

A BOM is not static, and pretending it is causes the mess

The unspoken assumption behind most BOM trouble is that a product has a bill of materials. It does not. It has a bill of materials that changes over time as parts are revised and superseded, and it varies across the configurations you sell. A single stored structure cannot be true for all of that at once.

There are two axes of variation, and confusing them is the root of most of the pain:

Change over time. The product is nominally the same, but a component was substituted at some point — a new supplier, a revised part, a fix. Units built before the change have the old part; units after have the new one. Same product, different content depending on when.

Variation across configurations. At the same moment in time you sell more than one version — a base model and a premium one, a 110V and a 240V, a left-hand and a right-hand drive. Same product family, different content depending on which variant.

Effectivity is the mechanism for both. It attaches to a line in the structure a rule that says this component applies under these conditions — so one structure can carry all the truth instead of one structure per case.

Three kinds of effectivity, and when each is right

Date effectivity. The line applies from a date, or between two dates. Easy to set up and easy to understand, and it is usually the wrong first choice for anything that matters, because dates lie. A change is planned for the first of the month, the shipment slips, and now your date-effective BOM says units built that week have a part they do not physically contain. Date effectivity is fine for things that genuinely switch on a date — a regulatory label, a price — and dangerous for anything where the physical cutover is not actually tied to the calendar.

Unit or serial effectivity. The line applies from unit 100, or to units 100–250. Precise, and it survives schedule slips because it is tied to the thing itself rather than to a date the thing was supposed to exist. The cost is that you must track units — you need serial numbers and a record of which serial got what. For anything you will have to account for later, per unit, this is the honest choice, and the extra tracking is the price of being able to answer the as-built question at all.

Option or configuration effectivity. The line applies when a configuration option is chosen — this component is present when the product is the 240V variant. This is how you model variants without cloning, and it is the subject of the next section because it is where the biggest structural decision lives.

Most real products need more than one of these at once: option effectivity for the variants you sell, unit effectivity for the changes you make over a production run. A platform that can only do date effectivity will push you toward the workaround, so this is worth checking before you rely on it.

The clone-and-edit trap

Here is the decision that quietly determines whether your configuration management works, made early and usually without anyone noticing it was a decision.

You have a base product. You need a variant. There are two ways to get one.

Clone the BOM and edit it. Copy the whole structure, change the parts that differ, save it as the variant. Fast, obvious and the beginning of the end. Because now you have two structures that were the same yesterday and will drift apart forever. A change to a common component must be made in both, by hand, and the day someone updates one and forgets the other, your two variants silently disagree about a part that was supposed to be identical. Multiply by every variant and every year and the where-used answer — which products use this part — becomes untrustworthy, which means change impact analysis becomes guesswork.

Model one structure with configuration rules. Keep a single superset structure — every component that could appear in any variant — and attach option effectivity so each line is present only for the configurations that use it. A change to a common component is made once and is correct for every variant by construction. This is often called a 150% BOM: it contains more than any single product needs, and configuration rules resolve it down to the exact 100% for a given variant.

The superset model is more work to set up and far less work to live with, and the difference compounds. Clone-and-edit is cheaper on the first variant and more expensive on every change thereafter, forever. The same asymmetry governs part numbering and most other configuration decisions: the cheap first move is the expensive long-term one.

The question all of this exists to answer

Strip away the mechanism and effectivity earns its keep by answering two questions that a static BOM cannot:

As-built: given this unit, what is its exact configuration? For a warranty claim, a recall, a field failure, an audit — you must be able to reconstruct what physically shipped in a specific unit, months or years later. If your answer lives in someone's spreadsheet mapping serials to changes, you do not have configuration management. You have a person, and their spreadsheet, and the risk that both leave.

Impact: given this change, which units and variants are affected? This is where effectivity connects to the change process. The exposure window — everything built between a problem's introduction and its fix — is a question of effectivity, and if you cannot answer it from the system you will answer it by hand, slowly, under pressure, at exactly the moment accuracy matters most.

A system that can answer both from the same dataset is doing configuration management. One that needs a side spreadsheet for either is a filing cabinet with good intentions.

The spreadsheet is telling you something specific

By the argument in why people bypass PLM, the effectivity spreadsheet is a requirements document. Read it precisely, because it names the exact question your system cannot answer:

  • A sheet mapping serial numbers to which changes they got means the system has no unit effectivity, and someone is maintaining as-built by hand.
  • A sheet listing which variant uses which parts means you cloned BOMs instead of modelling configuration, and this is the reconciliation ledger for the drift.
  • A sheet of "parts affected by ECO-xxxx" means change impact is manual, which means it is sometimes wrong, which means changes escape.

Each points at a specific missing capability, not a training gap. Automating the spreadsheet's shape is the trap; supplying the capability it substitutes for is the fix.

How to start without boiling the ocean

You do not need to model every variant and every change from day one, and trying to is its own failure mode.

Pick the effectivity axis you actually need. Most organisations need one of the three far more than the others. A make-to-order shop lives on option effectivity; a serialised-equipment manufacturer lives on unit effectivity; a process or regulatory-driven line may genuinely live on dates. Identify yours and model that one properly before adding the others.

Enforce it in the system, not in a convention. Effectivity that depends on people remembering to set it is effectivity that is sometimes not set, which is worse than none because it looks complete. Make it a required, validated part of releasing a change.

Refuse the clone. The single highest-leverage rule. The first time someone proposes to copy a BOM to make a variant, that is the moment to stop and model the superset instead — because it never gets easier to unwind, only harder.

Effectivity is unglamorous and it is where PLM stops being storage and starts being control. Settle which axis you need, model it once and keep one structure, and the configuration questions that ambush most manufacturers become queries instead of investigations.

Working paper. If your variants have drifted or you cannot answer the as-built question without a spreadsheet, get in touch.