Video Demo: Introduction to Change Management in OpenBOM

A change is not an ECO button, it is a connected process. Change management in engineering rarely starts with a form.

It usually starts with a comment. A doubt. A supplier issue. A design improvement. A “can we adjust this?” moment.

Over the years, I’ve seen many systems present change management as a command — create ECO, attach files, route for approval, close. Technically correct. Practically incomplete.

What we wanted to demonstrate in this 9-minute walkthrough is something different. Not a command. Not a screen. But a complete story — a day in the life of a change moving through engineering, collaboration, product data, and procurement.

Below is the full demo. After that, I’ll walk through what is really happening behind the scenes.

Video: End-to-End Demo 

It Starts With a Conversation

In real life, changes don’t begin in a formal workflow. They begin in context.

In the demo, the story starts inside OpenBOM with comments and tasks. Someone raises an issue. A colleague is mentioned. A task is assigned. The discussion unfolds directly on the item or BOM.

This may look simple, but it is fundamental.

Too often, collaboration happens outside the system that holds the product data. Email threads grow. Slack conversations disappear. The change is decided somewhere, and later someone tries to “register” it in the system.

Here, the conversation is already attached to the data. The discussion lives where the product lives. That connection matters because change is never abstract. It always affects something specific.

Design Evolves — Data Follows

The next step in the story happens in SolidWorks.

A designer updates the model. A component changes. A parameter shifts. The design authority remains inside CAD, exactly where it should be.

With OpenBOM integration, the updated structure and metadata are captured automatically. There is no retyping. No exporting to Excel. No rebuilding of the BOM from scratch.

This is where change management becomes less administrative and more structural.

The system is not asking the engineer to “document” the change in a separate world. It is simply capturing what actually happened in design and reflecting it in the product data.

Engineering remains in control. Data remains connected.

Formalizing the Change — Without Breaking the Flow

At some point, a discussion becomes a formal decision.

In the demo, we create a Change Order. It is intentionally straightforward. It holds the description, the reason, the status, and — most importantly — the connection to real items and BOMs.

I have seen change processes become heavy because the workflow system is separated from the data model. You create a document about change, then separately modify the structure. Two parallel universes.

In OpenBOM, the change object is part of the same data environment. It is not a detached document. It is a structured placeholder that links directly to the affected items and BOM lines.

The system is not trying to simulate the change. It is tracking it where it actually lives.

Navigating the Impact

This is the part I personally like most in the demo.

We move from the Change Order to specific items. We navigate into multi-level BOM structures. We modify properties. We adjust quantities. Each modification is connected back to the change record.

There is no need to switch tools or re-contextualize what is happening.

Change management here is not about filling out a form after the fact. It is about working directly in the product structure and maintaining traceability as you go.

This is a subtle but important distinction.

When systems are built around documents, change becomes paperwork.
When systems are built around connected data, change becomes structured evolution.

Alignment Through Visibility

A change is not complete until people align.

OpenBOM’s notifications and task system make sure that the right people are informed. Approvers see what changed. Status transitions are visible. Conversations remain attached to the product data.

We intentionally avoid overcomplicating the process.

I’ve observed that many engineering teams do not fail because they lack workflow engines. They struggle because workflows become so complex that users start bypassing them.

Clarity is more powerful than complexity.

• Who needs to review?
• What is the current state?
• What exactly changed?

When those three questions are easy to answer, collaboration becomes smoother.

Closing the Loop With Procurement and ERP

The most important moment in the story is the last one.

Engineering change does not end with approval. It ends when procurement and operations are aligned.

In the demo, we show how updated items and BOMs flow into purchasing — either through OpenBOM’s built-in purchasing capabilities or through integration with ERP, in this example Odoo.

This is where many systems introduce friction. Engineering completes the ECO, but the ERP remains outdated. Someone exports data. Someone imports it. Someone reconciles differences.

Here, the connection is direct. The same structured data model that connects CAD to BOM also connects BOM to ERP.

The loop closes:

Discussion → Design update → Structured change → Approval → Purchasing → ERP.

Not as disconnected events, but as one continuous data story.

What is my takeaway? 

Here is an important message from the demo- it is not that OpenBOM has ECR or ECO objects and workflows. It is that the system organizes data and processes in a way that feels natural and connected. There is no heavy vaulting layer – it is about data. There are no siloes of structures. There is no artificial separation between collaboration and data (Excels and files attached to emails) .

Instead, there is a consistent product data model that connects the following objects and activities:

• SolidWorks as the design authority,
• OpenBOM as the structured product workspace,
• and ERP as the operational backbone.

The experience remains simple, but the connectivity is deep.

Conclusion: A Complete Story Instead of a Feature

When we prepared this demo, we made a conscious decision not to show “how to click ECO.”

We wanted to show how change unfolds over time.

• It begins with a conversation.
• It moves through design.
• It becomes formal.
• It propagates through structure.
• It requires alignment.
• It ends in operations.

If change management feels complicated in your organization, it is often not because the rules are unclear. It is because the systems involved are disconnected.

Our goal with OpenBOM is not to build a heavier workflow engine. It is to provide a clean, connected data foundation that allows change to move naturally from engineering to procurement without losing context.

If you have nine minutes, watch the full walkthrough above. It is short, but it tells the whole story. And in change management, the story is what matters most.

REGISTER FOR FREE to check OpenBOM Change Management and how it can help your organization. 

Best, Oleg