The formulation team finalized a revised recipe for the shampoo base on Tuesday afternoon. The fragrance load dropped by 0.3%, a surfactant was swapped for a cheaper alternative, and the preservative system was tweaked to extend shelf life. Engineering pushed the change into the shared spreadsheet by end of day. On Wednesday morning, three production orders were already running against the old recipe. Two of them were nearly complete. One had just started. Procurement had ordered materials against the old recipe the previous week. Costing had quoted a customer based on the old recipe. Nobody told the shop floor that anything had changed, but the BOM document they would pull up if they checked now says something different than what they are actually making. By Thursday, the variance reports are going to look strange, and by Friday, somebody will be asking why actual consumption does not match expected. This is how BOM chaos happens in real factories. Not through malice or incompetence, but through the simple fact that products change faster than paper documents can keep up, and in-flight work does not pause to let updates land.
Why In-Flight Orders Should Not Inherit Mid-Production Changes
A production order is a commitment. When it moves from draft to confirmed, materials are reserved, schedules are set, and downstream teams start executing against it. If the underlying BOM shifts while that order is in flight, the reservation logic, the cost calculation, and the variance tracking all start referencing different versions of the same product. The order was planned against one set of quantities. The shop floor might be consuming against another. The finance team might be accruing cost at a third.
The operational consequences show up quickly. Expected consumption pre-fills that were calculated at confirmation no longer match the BOM the operator sees when they start a run. Reserved quantities no longer align with what the current BOM says should be reserved. When the run completes and variance is calculated, the variance is against a phantom baseline that does not match either the planning record or the execution record. Engineers end up trying to reconcile numbers that were never intended to describe the same thing.
This is why serious production systems separate the act of changing a BOM from the act of applying that change to work that is already in motion. The engineering change process is one workflow. Production execution is another. They meet at a specific, controllable point, and that point is before the order is confirmed, not during execution.
Draft, Active, and Archived: The Three States That Matter
A usable BOM version control model needs exactly three states, and the semantics of each state have to be unambiguous. Draft means the BOM is being worked on. It has no effect on production, costing, or material planning. Multiple drafts can exist simultaneously for the same product. Engineers can experiment, model alternative formulations, and simulate cost impacts without touching live operations.
Active means this is the BOM that will be used for any new production orders and for the ATP calculation. There can only be one active BOM per product. When a new version is activated, the previous active version is automatically archived. This transition is the moment the engineering change becomes operationally real.
Archived means the BOM is no longer used for new work, but it is preserved for historical reference. Production orders that were confirmed against an archived BOM still execute against that BOM, because the order carries a reference to the specific version it locked against. Variance analysis on historical runs still pulls from the correct archived version. Cost rollups from prior periods remain reproducible.
This three-state model is the foundation of a sane engineering change management process. It lets engineering iterate in draft without risk, commit to a specific version through activation, and preserve history through archival. FalOrb implements exactly this pattern: new versions can be drafted without affecting the active BOM, and activating a new version automatically archives the previous one. Draft BOMs are invisible to production planning. Archived BOMs are visible only through the historical lens of the orders that locked against them.
Version Locking at Production Order Confirmation
The critical mechanic that makes this work is the lock at confirmation. When a production order moves from draft to confirmed, the system captures a reference to the currently active BOM version. From that moment forward, the order is bound to that version regardless of what happens upstream in engineering. If a new BOM version is activated an hour later, the confirmed order does not change. Its materials stay reserved against the version it locked to. Its expected consumption stays calculated against that version. Its variance analysis stays anchored to that version.
This is what makes concurrent engineering changes and in-flight production possible. An engineer can draft and activate a new BOM version on Wednesday afternoon while three production orders that were confirmed against the prior version continue to run against it. Those three orders complete cleanly, with consistent planning, execution, and variance data. The next production order created from Wednesday afternoon onward will pick up the new version, and it too will lock at confirmation.
Without this lock, the engineering team has to coordinate every change around the production schedule. Changes get delayed because there is always something in flight. Quality improvements sit in drafts for weeks. When changes finally do land, they land in a rush, often at the cost of pausing production. The lock removes this friction. Engineering moves on its own cadence. Production moves on its own cadence. The two synchronize at the single, controllable point where an order transitions from draft to confirmed.
Multi-Level BOMs Make the Lock Even More Important
Single-level BOMs are rare in real manufacturing. Most finished goods contain sub-assemblies, and those sub-assemblies often have their own BOMs that can change independently. A bottled beverage might use a flavoring concentrate that itself has a BOM. A personal care product might use a pre-blended base. A piece of equipment might use a molded housing that is itself a manufactured sub-assembly. These are multi-level BOMs, and they compound the versioning problem.
If only the top-level BOM is versioned but sub-assembly BOMs are not, then a change to a sub-assembly silently propagates into every finished good that uses it, even for orders that are in flight. This is the worst of both worlds: you have version control that looks comprehensive but is not. The fix is to apply the same lock logic at every level. When a production order for a finished good is confirmed, the system walks the BOM tree and captures a snapshot of every sub-assembly BOM it depends on. The entire explosion is frozen for the life of the order.
FalOrb handles this explicitly. Its multi-level BOM engine supports unlimited nesting depth, detects circular references before they become runtime failures, and locks the full explosion at confirmation. If a sub-assembly BOM is revised after a parent order is confirmed, the parent order keeps using the old sub-assembly BOM. This is the only way multi-level BOM versioning produces consistent, auditable results. For a deeper look at how BOM mistakes compound across systems, the earlier piece at /blog/real-cost-of-bom-chaos-fmcg walks through the downstream damage in FMCG specifically.
The Approval Workflow That Keeps Changes Traceable
Version locking is necessary but not sufficient. The other half of the discipline is a BOM approval workflow that captures who made the change, why, and when it became active. Draft BOMs are where engineers experiment. Activation is where the organization commits. A proper approval workflow treats activation as a controlled event: someone with the authority to approve the change does so, the activation is logged with actor and timestamp, and the superseded version is automatically archived with a record of what replaced it.
This creates a complete engineering change management trail. Any batch produced three months ago can be traced back to the exact BOM version it ran against. Any cost quoted six months ago can be reproduced against the BOM version that was active at the time. Any customer complaint about a quality variance can be cross-referenced against the BOM version the affected batch used. This is the kind of traceability that audits, quality investigations, and cost reconciliations all depend on. The pattern of treating every operational event as an immutable record is one FalOrb extends across its stock movements, production runs, and BOM activations, and it is covered more broadly in the article at /blog/immutable-audit-ledger-why-every-movement-matters.
Making the Transition From Spreadsheet Chaos to Controlled Change
Most manufacturers who outgrow spreadsheets do so because a version control failure cost them real money. A bad batch. A customer complaint traced to a formulation error. A cost quote that did not match what the factory actually made. The transition to a controlled BOM lifecycle is less about adopting new technology and more about accepting a new operational discipline: engineering changes are explicit events, not ambient edits, and in-flight work does not inherit changes that happen after confirmation.
The win is that the discipline pays for itself immediately. Production variance becomes interpretable again because the planning baseline and the execution baseline match. Costing becomes reproducible because every order carries a reference to the exact BOM version it ran against. Engineering can move faster because it no longer has to coordinate every change around the production schedule. The shop floor stops being a place where changes arrive as surprises. The bom version control manufacturing model is not complicated, but it has to be consistently applied at every level of the BOM tree and at every stage of the production order lifecycle.
Once that consistency is in place, the entire relationship between engineering and production changes. Changes become additive improvements rather than disruptions. History becomes queryable rather than mythological. The question "what was this order actually built to?" has a precise, auditable answer. That is the real payoff of version control done properly: not fewer changes, but cleaner ones.
FalOrb helps manufacturers manage BOM changes without breaking in-flight production through draft/active/archived versioning, multi-level BOM locking at production order confirmation, and automatic cost rollups. Book a 30-minute walkthrough or email us at [email protected] to see how it applies to your operation. Learn more at falorb.com.