Why Traditional Engineering Change Management Falls Short: OpenBOM Workspace-Based Approach

Most engineers understand change management the way it’s been taught for decades: you identify something that needs to change, you create a revision, you send it for review, it gets approved, and it gets released. That cycle is well understood, widely implemented, and — for many organizations — genuinely functional. It’s not broken. But it was designed around a set of assumptions about how engineering work actually happens, and those assumptions are starting to show their age.

Let me explain what I mean, and then walk through how we think about this problem in OpenBOM.

Traditional Engineering Change Management in PDM/PLM and Its Limitations

The traditional revision-driven workflow has a certain elegance to it. Everything is gated. A change request kicks off a process. That process leads to a reviewed, approved, and released revision. Incrementally, you can also manage changes at the sub-assembly level — allowing parts of the product to evolve independently — which gives you some flexibility without abandoning the structure.

But the model has three problems that become harder to ignore as engineering teams get more distributed, products more complex and cross-functional, and more dependent on real-time data from other systems.

1. The first problem is collaboration. In traditional systems, working simultaneously on the same BOM or part structure is either impossible or requires elaborate workarounds. One person locks the record, makes changes, releases it — and only then can someone else pick it up. That serializes work that should be parallel, and it creates bottlenecks that compound over time.
2. The second problem is convergence. Modern products aren’t the work of one discipline. Mechanical, electrical, software, and supply chain teams all touch the same product structure. Each domain evolves on its own timeline, responds to its own constraints, and uses its own tools. Getting all of those changes to converge into a coherent revision — especially under a process that assumes a single, linear flow — is genuinely hard. The system isn’t designed for it.
3. The third problem is context. When a revision is released, it captures a state. What it doesn’t capture is the story of how you got there. Who changed what, when, and why? What was tried and discarded? What supplier substitution happened in week three that nobody wrote down? Traditional revision management stores outcomes. It compresses history. And once that context is gone, it’s gone.

These three problems share a common root. The system assumes that change begins with a revision. In reality, change begins much earlier — and the system has no way to see it.

Where Engineering Changes Actually Happen Before Revisions

Here’s a question worth sitting with: where does a change live before it becomes a revision?

In most systems, the honest answer is in the previous revision. Also, changes happen in email threads, in spreadsheets, in CAD files on individual machines, in conversations that never get written down. The formal system only gets involved once someone decides something is ready to be reviewed. Everything before that point is invisible to the system.

But change is continuous. Engineers edit design, assign new Part Number. Procurement updates supplier references. supplierpush updated geometry and attributes. APIs write data from external systems. None of these actors starts their day by “creating a revision.” They start by doing work. And in a system that only recognizes revision-level events, all of that work is either lost or has to be reconstructed after the fact. Some of these changes might be rolled back. Some of them are options. 

This is the gap that the concept of a workspace is designed to fill.

The OpenBOM Workspace: A Real-Time Environment for Engineering Changes

A workspace in OpenBOM is not a staging area. It’s not a sandbox or a pre-release holding zone. It is the primary live environment where work happens  for everyone, all the time.

Multiple users can work in the workspace simultaneously. A mechanical engineer can update a component while a procurement specialist adjusts a supplier reference and a system integration pushes updated specifications from an ERP. None of them needs to wait for the others. None of them needs to initiate a formal process to begin. The workspace accepts changes continuously, from every source, without a gate.

What makes this different from just having an editable database is what happens to those changes as they come in. Instead of simply overwriting the current state, the system captures each change as a discrete event. A part number is edited – that’s an event, with a timestamp and a user. A quantity is updated – same thing. A component is added, removed, linked, or modified – each action is recorded individually, as it happens.

This means that the workspace is not just a place where the current state of the product lives. It is a place where the history of how the product evolved is continuously being written.

Capturing Engineering Change History and Context in Real Time

This is where the third limitation of traditional systems gets addressed directly.

When every change is captured as an event, who made it, what was changed, when it happened, you no longer have to reconstruct history from revision notes. You have the actual history. You can see that a component was swapped on a Tuesday because a supplier went out of stock. You can see that a quantity was corrected three times before landing on the right number. You can see which changes came from a CAD integration and which were entered manually.

This isn’t about creating an audit trail for compliance purposes, though that’s a real benefit. It’s about understanding how a product evolved. Engineering is an iterative process. Decisions get made, reconsidered, and revised. A system that only stores outcomes treats iteration as noise. A system that stores events treats iteration as information.

The change history in the workspace is the record of that information. And it’s always available, without having to do anything special to preserve it.

Revisions in PLM: Immutable Snapshots Instead of Workflow Processes

Given all of that, what is a revision?

In OpenBOM, a revision is an immutable snapshot — a capture of the state of an item and its BOM at a specific point in time, labeled and stored. That’s it. It is not a process. It is not a gate. It is a named point in the evolution of a product that you’ve decided is worth preserving.

This distinction matters because it changes what a revision is for. In the traditional model, a revision is the mechanism through which change is controlled. You can’t make a change without eventually creating a revision, and you can’t create a revision without going through a process. The revision is the process.

In OpenBOM, the revision is a result. It’s what you get after changes have accumulated in the workspace and you’ve decided to capture the current state. The work happens in the workspace. The revision records what that work produced.

This means revisions can be created at any time, for any reason — as lightweight checkpoints during development, as formal milestones before a design review, or as the output of an approved change process. The revision itself doesn’t determine how it was created. That’s governed separately.

How Revisions Are Created: Simple Snapshots and Formal Change Control

There are two paths to creating a revision, and they’re designed for different needs.

The first is a simple snapshot. You’re working in the workspace, you’ve reached a state you want to preserve, and you create a revision directly. No workflow, no approval required. This supports the kind of iterative work that engineering actually involves — capturing checkpoints, preserving options, marking progress without bureaucracy. For many changes, this is exactly the right approach.

The second path is formal change control, using Change Requests and Change Orders.

A Change Request (CR) is a proposal for a specific change to a specific item or BOM. It documents what is being changed and why. A Change Order (CO) is a grouping mechanism — it collects one or more CRs, routes them for review and approval, and, once approved, results in a revision being created.

The key thing to understand about CR/CO is what it does and doesn’t do. It does not generate changes. The changes already exist in the workspace. What CR/CO does is organize, govern, and formalize the decision to turn those changes into a revision. It is a process layer applied to changes that already happened, not a process layer that must be completed before changes can happen.

Change Control in PLM: Applying Governance Without Blocking Work

This is the central principle, and it’s worth being direct about it.

In traditional change management, the process is upstream of the work. You request, you get approved, and then you change. Control is a barrier, not in the pejorative sense, but in the literal sense: it stands between the current state and the next state, and you must pass through it to proceed.

In OpenBOM, control is downstream of the work. You work, you capture, and then you decide what level of formality the outcome requires. Some changes get a simple snapshot. Some go through full CR/CO. Some routine updates, minor corrections, exploratory edits, may never need to be formalized at all.

This means that the process doesn’t block the work. Teams can move at their natural pace, collaborate in real time, and respond to changes as they happen. When a change is significant enough to warrant formal governance, that governance is applied. When it isn’t, the overhead isn’t imposed.

This is not a loosening of control. It’s a more accurate application of it.

Managing Multi-Disciplinary Changes and Convergence in Product Development

Return to the second limitation — the problem of multi-disciplinary convergence.

In the workspace model, mechanical, electrical, software, and supply chain changes can all happen in parallel, in the same product structure, without waiting on each other. Each domain evolves on its own timeline. The workspace absorbs all of it.

When the time comes to create a revision, whether through a simple snapshot or a formal CO, that revision becomes the point of convergence. It captures the accumulated state of all those parallel changes, across all those domains, at that moment in time. The revision doesn’t force teams to synchronize before they can work. It provides the moment of record after they have.

This is a meaningful change from a system where convergence has to happen before the revision is initiated. It shifts the convergence point from the beginning of the process to the end, which is where it naturally belongs.

Conclusion: A New Model for Engineering Change Management in Modern PLM Systems

Let me summarize the model simply.

Change is continuous. It happens in the workspace, from people, from systems, from integrations. It doesn’t wait for a process to begin. The workspace captures that change as it happens, preserving every event in a continuous history.

A revision is a snapshot of accumulated change. It is a record of state, not a mechanism of process. It can be created simply or through formal change control, depending on what the situation requires.

Control is a layer applied to change, not a precondition for it. It governs which changes get formalized, reviewed, and permanently recorded — without blocking the work that precedes that decision.

If I had to reduce this to a single idea: start by capturing change. Then decide when to release what matters.

That shift, from controlling change to capturing it, and governing selectively, is what makes engineering change management something that works with how engineers actually work, rather than against it.

REGISTER FOR FREE to check how OpenBOM helps you.