Which Version of the Bill of Material Made This One?

A customer asks for a change, or engineering improves something, or a material is substituted because the usual one is six weeks out. Somebody opens the bill of material and edits it. The change is correct and the reason is good.

What has just happened is that the bill of material now has no history. Every historical cost, every past variance and every traceability answer now refers to a recipe that was not the one used. Batches made last year are costed at today's material list. The variance report compares old production to a new standard. And the question a customer or an auditor asks — what exactly went into this one — is answered with today's specification, confidently and wrongly. Nothing warned anybody, and the previous state is not recoverable. The remedy is that a bill of material is versioned with an effective date, and production records the version it consumed, so that the past keeps describing itself.

What a change has to carry, the four questions it must answer before release, and the cheap version of all of it for a factory that will never run a formal change board.

Versioned, effective-dated, and stamped on the order

Three mechanisms, and they are not interchangeable.

Versioned means the previous definition still exists as a record rather than as an entry in an audit log. You can open it, cost it and read it. An audit trail that says a quantity changed from 1.2 to 1.35 is not a version — reconstructing a full recipe from a change log is a forensic exercise nobody performs.

Effective-dated means a version states the period during which it is the one to use, so planning uses the right one for future orders and costing uses the right one for past ones. Without dates, versions are just copies and somebody has to remember which was current in March.

Stamped on the order is the one most often missing, and it is the one that makes the other two worth anything. A production order records the version it actually consumed, because reality and the plan diverge: an order started before a change and finished after it used the old recipe, and a system that resolves the version at report time rather than storing it at execution time will say otherwise. This is the same modelling principle that decides whether historical records survive configuration changes anywhere in a business, and it is worth recognising as a general requirement rather than a manufacturing one — the clearest published statement of it is why validity has to be resolved against the date of the event.

The routing deserves identical treatment, and usually does not get it. A product whose bill of material is versioned and whose routing is edited in place has half a history — and it is the half carrying the labour and machine cost, which is where the variance figures come from. It is also the half most exposed to silent physical drift, for the reasons set out in why a routing stops describing the machine it was written for.

What a change has to answer before it is released

Engineering change control has a reputation for bureaucracy, most of it earned by implementations that ask twelve questions. Four are load-bearing, and a factory that answers only these is in good shape.

What happens to material already bought? A substitution that obsoletes stock has a cost, and somebody has to decide whether to run it out, rework it or write it off. Releasing a change without this decision is how a store fills with material for a product that no longer exists.

What happens to work in progress? Orders already started, on the floor, half-built. Finish to the old version or convert? Both are legitimate; leaving it to whoever is on shift is not.

When does it take effect — by date, by order, or by lot? These give different answers and the difference matters when a customer is involved. "From the next order" and "from the first of the month" are not the same instruction.

Who is told outside engineering? Purchasing has a new item to source, quality has a new specification to inspect against, sales may have a customer to notify, and costing has a standard to update. A change released without that list is a change that surfaces as four separate surprises over the following month.

Getting those four answered reliably is an operating-model decision rather than a configuration one, which is why it tends to be the piece that survives or fails in a programme long after its software is working long after the software is working. A change board that meets for twenty minutes weekly to answer those four for each change is not bureaucracy. It is the cheapest form this ever takes, and the alternative is the same four questions answered by accident and in the wrong order.

The cheap version, for a factory that will not do any of that

Most mid-sized factories will not stand up a formal change process, and saying otherwise in a report does not make it happen. Three things are worth doing even if nothing else is.

Never edit a released bill of material. Copy it. Even without effective dates, having last year's definition as a separate readable record preserves the ability to answer questions. This one change costs nothing and prevents the permanent loss.

Write the reason on the new version. One line. In two years, the difference between a version somebody can explain and one nobody can is the difference between a bill of material that is trusted and one that gets quietly re-derived from the floor.

Stamp the version on the production order. If the system supports only one of the three mechanisms, choose this one, because it is the one that makes historical questions answerable at all.

A factory doing those three has no change control and has preserved its history, which is most of the benefit for none of the process.

Where this shows up as a different problem

The reason engineering change control is under-bought is that its absence never presents as itself. It presents as: costing that nobody believes; a traceability exercise that takes days; purchasing ordering an obsolete component; a certification finding about specification control; a variance that moved for no reason anyone can find; and an argument between production and engineering about what the current specification actually is.

Each of those gets investigated on its own terms and none of the investigations reaches the cause, because the cause is that the definition has no history. That is why it is worth naming directly rather than leaving it to be rediscovered six times.

Where the specification also carries a compliance meaning — a food-contact ratio, a certified material, a regulated composition — the version history stops being a costing convenience and becomes the evidence, which is the argument in what a quality system has to control rather than merely document. At that point an untracked edit is not an administrative lapse; it is the loss of the only proof you had.

The wider order of work, and which of these decisions foreclose others, is in what a manufacturing implementation has to establish first. And if the symptom you recognise is two departments disagreeing about the current specification, treat that as a question of who owns the definition before treating it as a question of software.