Stop Managing BOM Changes by Email

Revisions, Change Requests, and Change Orders in OpenBOM

This article is concluding our five days blog series with OpenBOM Product Tour. On Monday, I told you that nobody has a BOM problem. On Tuesday, we replaced the spreadsheet with a digital BOM. On Wednesday, we let your CAD files out of the local vault. Yesterday, we released data into procurement, inventory, and ERP. Today, in the final post of this series, we get to the process that holds it all together: what happens when the product changes.

Change management is the process of capturing what changed in product data, deciding whether it requires a revision, routing it through review and approval, and releasing a new trusted baseline. Notice what is not in that definition: email. And yet in most companies, email is exactly where change management lives.

Email Can Discuss Change. It Cannot Manage Change.

The scenarios are familiar. A supplier becomes unavailable. An engineer changes a material. A quantity changes in the BOM. A CAD file gets updated. Purchasing asks whether the change is approved. Manufacturing asks which revision to build.

In email, every one of these becomes a separate conversation, and every conversation is disconnected from the thing it is about. You may have the discussion, but you lose the connection to the actual BOM, the affected item, the previous revision, the approval, and the release state. Purchasing gets an answer, but the answer is a sentence in a thread, not a released revision they can trust. Manufacturing gets a file, but nothing proves it is the approved one.

Email captures conversations. OpenBOM captures change context: the change itself, connected to the items, BOMs, files, revisions, and approvals it affects.

Change Starts in the Collaborative Workspace

Here is the first thing that makes the OpenBOM change model different: change does not start with a form. It starts with work.

In OpenBOM, engineering, manufacturing, sourcing, and suppliers work together on the latest state of product data in a shared workspace. People edit items, restructure BOMs, update files, and adjust quantities, and OpenBOM tracks the change history automatically as they do. Nobody has to stop working to document what they changed. The system already knows.

This inverts the traditional PLM model, where the process is a gate that blocks work until paperwork clears. In OpenBOM, the revision is not the place where people do the work. The revision is the captured result of work that already happened in the workspace: an immutable snapshot of an item and its BOM at a specific point in time.

The workspace is where change happens. The revision is where change is captured.

A workspace only works if everyone can actually work in it, including people who touch product data occasionally. The  TTM Advanced Manufacturing Group, which builds in-house manufacturing machinery and software for TTM plants in North America and Asia Pacific, OpenBOM story evaluated exactly that:

“We really like the ease of use of the OpenBOM UX and UI. Our Operations team picked it up quickly, and casual users can return to OpenBOM as needed and be effective.”

Owen Long, Lead, Advanced Manufacturing Group, TTM Technologies

Versions, Revisions, Change Requests, and Change Orders Are Not the Same Thing

These four words get used interchangeably in email threads, and that ambiguity is where mistakes are born. In OpenBOM, each one has a precise meaning:

• Version. A work-in-progress state of a file, document, or design during development. Versions are how progress looks: iteration after iteration while the design is still moving.
• Revision. A controlled baseline: an immutable snapshot of an item and its BOM at a meaningful point in time. A revision is a statement to the organization: this is what the product was, right here.
• Change Request. A proposed change to a specific item or BOM that needs review before it becomes part revision in a released baseline.
• Change Order. A collection of one or more change requests that routes related changes together through review and approval. This is the formal control path that turns workspace changes into approved revisions.

Versions track progress. Revisions preserve baselines. Change requests and change orders provide governance.

Two Levels of Control: Simple Revision Control and Formal Change Management

Not every change deserves a full ECO ceremony. A checkpoint on a prototype, an internal design milestone, an early iteration shared with a colleague: these need a saved baseline, not a committee. Other changes affect cost, suppliers, production, compliance, or already-released data, and those absolutely need formal review and approval before anything moves.

OpenBOM supports both levels explicitly. The simple path is revision control: capture a revision of an item and its BOM whenever a baseline matters. The formal path is change management: revisions are created only through change requests and change orders that pass approval. Teams choose the path per change, not per company.

OpenBOM lets teams apply the right level of control to the right type of change.

Xponent Power, which builds retractable solar awning systems for RVs, is a good picture of why the revision layer matters. Their early process ran on email and spreadsheets, and revision confusion was starting to threaten their ability to scale with manufacturing partners. With structured revision control in OpenBOM, every change delta is captured and merged into the product structure, and the team reports zero errors in file issuance since making the switch: the right revision reaches procurement and manufacturing partners every time.

How the Change Request and Change Order Workflow Works

When a change does need formal control, the OpenBOM flow looks like this:

1. Make or collect changes in the latest state. Work happens in the shared workspace: material swaps, vendor replacements, quantity updates, file changes.
2. Review what changed. Automatic change tracking shows the delta, so review starts from facts, not memory.
3. Create a Change Request for the affected item or BOM. The proposal is attached to the exact data it affects.
4. Group related Change Requests into a Change Order. A material change and the vendor change it triggers travel together, not in separate threads.
5. Route the Change Order for review and approval. Approval can come from one person or a group, and the decision is recorded with the change.
6. Release the approved change. The organization now has an unambiguous answer to “is this approved?”
7. Create or increment the revision. The new baseline is captured, and if the item is an assembly, the revision includes its BOM as well.

Compare that to the email version of the same change: seven steps collapse into one thread with the subject line “Rev C FINAL,” and the answer to “who approved this and what exactly did it affect?” retires with whoever hit send.

One Change Is Never Isolated

Here is why this matters more as products get more complex. A single component change ripples: it affects the assemblies above it, the cost rollup, the inventory position, the supplier commitments, and the manufacturing BOM downstream. An EBOM edit has MBOM consequences. A vendor replacement has procurement consequences. A released revision has ERP consequences.

Because OpenBOM manages EBOM, MBOM, and other BOM views as connected structures on a shared set of items (the xBOM model we toured on Tuesday), the impact of a change is visible across the whole product structure instead of being rediscovered downstream one surprise at a time. And as we saw yesterday, it is the released, approved data that flows into procurement, inventory, and ERP, so the quality of your change process directly sets the quality of everything downstream.

A change is rarely isolated. It needs impact visibility across the product structure, and that requires everyone working from the same live BOM data, not disconnected copies.

From Change History to Product Memory

Look back at the week. Monday named the real problem: not a missing BOM, but disconnected product knowledge. Tuesday and Wednesday were about capture: getting data out of CAD files and spreadsheets into a living, structured digital BOM. Thursday was about flow: moving released data into procurement, inventory, and ERP without re-entry. And today was about the discipline in the middle: capturing change, governing it, and releasing trusted baselines.

Now notice what accumulates when you run that loop. Every change request, every approval, every revision, every change order becomes part of one connected record. Not only what changed, but why it changed, who approved it, which BOMs were affected, and which revision became the released baseline. At OpenBOM, we call it Product Memory.

Product Memory is the connected, living record of everything a team knows about a product: items, BOMs, CAD files, revisions, changes, vendors, orders, and the decisions behind them, captured as work happens and available to every person and system that needs it.

This is what email can never give you, and honestly, what traditional PLM never delivered either. It is why a new engineer can be productive in week one instead of month three. It is why an audit takes an afternoon instead of a quarter. And it is the foundation that makes AI genuinely useful in engineering: an assistant is only as good as the memory it can draw on. A company that keeps its change history in inboxes has nothing to give it.

This series was a tour in five posts. The real thing is coming next: a new OpenBOM Product Tour that walks this same journey, from CAD capture through review and change management to procurement and ERP, and shows how it all builds Product Memory for your team, with the customer stories to back it up. I will share the link here as soon as it opens.

In the meantime, the best tour is the one you take yourself. 

REGISTER FOR FREE and see what your team remembers a year from now.

Best, Oleg 

FAQ 

What is the difference between a version and a revision in OpenBOM?

A version is a work-in-progress state of a file, document, or design during development. A revision is a controlled, immutable snapshot of an item and its BOM at a meaningful point in time. Versions track progress, revisions preserve baselines.

How does OpenBOM handle engineering change orders (ECOs)?

OpenBOM manages ECOs through change requests and change orders connected directly to the live product structure. A change request proposes a change to a specific item or BOM, a change order groups related change requests and routes them for review and approval, and the approved release creates or increments the revision.

Can OpenBOM replace email for managing product and engineering changes?

Yes. In OpenBOM, teams make changes in a shared workspace where change history is tracked automatically and discussion, approvals, and revisions stay connected to the affected items and BOMs. Email can discuss a change, but it cannot connect the change to the data.

What is Product Memory?

Product Memory is the connected, living record of everything a team knows about a product: items, BOMs, CAD files, revisions, changes, vendors, orders, and the decisions behind them. OpenBOM captures this context as work happens and makes it available to every person and system that needs it.