Re-Thinking PLM with OpenBOM xBOM Workspace

On Friday I wrote about how OpenBOM re-thinks cloud PDM and moves engineering teams beyond the local vault. The question that follows naturally is what sits above the file. Today, I want to discuss how OpenBOM re-thinks PLM with xBOM Workspace.

For most of PLM’s history, the answer was a set of documents and a stack of separate bills of materials, and the architecture of nearly every system was organized to manage them. That organizing assumption is worth questioning. A product is not a folder of files, and it is not five disconnected BOMs that happen to describe the same thing. It is a single model that different functions need to see differently.

The interesting architectural question is not how to store more BOMs more efficiently. It is what happens when the product model, rather than the document or the BOM, becomes the center of gravity. That shift is what OpenBOM xBOM Workspace is built around, and everything that follows is a consequence of it.

OpenBOM xBOM Workspace is a collaborative environment that organizes product information around a single, shared product model rather than around documents or separate bills of materials. Within it, xBOM represents engineering, manufacturing, procurement, service, and compliance not as separate BOM copies that must be synchronized, but as configurable views of one product definition. Derived structural views, real-time collaboration, simultaneous editing, reviews, change requests and orders, and role-based access all operate on that one model, shifting the center of gravity of a PLM system from the document to the product itself.

PLM Systems Inherited a MCAD Document-Centric Core

Most existing PLM systems trace their architectural roots to the document management and MCAD file management tools developed in the 1980s and 1990s. The problem those tools solved was specific and concrete: manage CAD files, control revisions, and regulate who could open or change an engineering document. PDM grew out of that need, and it did the job well for the world it was built for.

The trouble is what came next. Over the following decades, organizations needed far more than file control, so BOM management, change processes, requirements, manufacturing planning, supplier collaboration, and program management were added around the original foundation. Each addition expanded what PLM could do, but the center of the system rarely moved. Underneath the new capabilities, the primary object was still the document, and the primary operations were still check-in, check-out, and revision of files.

This is why so many PLM implementations feel heavier than the work they support. The architecture is organizing product information around files, while the people using it are trying to reason about a product.

Separate BOMs Were a Workaround, Not a Design Goal

The second inheritance is BOM fragmentation. Engineering keeps an engineering BOM, manufacturing maintains a manufacturing BOM, and procurement, service, and compliance each work from a structure of their own. These are usually described as different views of one product, but in practice they are implemented as separate structures that have to be synchronized, reconciled, and governed across organizational boundaries.

It is worth being honest about why this happened. Different functions genuinely see a product differently, and that is not a defect to be eliminated. Engineering thinks in functional assemblies. Manufacturing thinks in process steps and consumables. Procurement thinks in purchasable parts and volume. The separate-BOM pattern was an attempt to serve those real differences. The limitation is the mechanism it used. It served multiple perspectives by making multiple copies, and copies drift.

Once you see fragmentation as a workaround rather than a design goal, the question changes. The goal is not to manage these BOMs more cheaply. It is to represent the perspectives without duplicating the product.

The Product Model Becomes the Center of Gravity

OpenBOM starts from a different foundation. Instead of treating documents as the primary system object, it is built on a flexible object data model where an organization can define and manage many kinds of business objects, the relationships between them, and the product structures they form, all inside a single collaborative workspace.

Items, assemblies, suppliers, manufacturers, documents, software components, manufacturing records, requirements, change records, and custom business objects are all represented through the same underlying modeling approach. The relationships between those objects are first-class elements of the product definition rather than secondary references attached to a file. A supplier is connected to the parts it provides. A change record is connected to the items it affects. A document is one object among many, not the thing everything else hangs from.

This is the architectural move that matters. In a document-centric system, files are the center of gravity and product information is arranged around them. In OpenBOM, the flexible product model is the center of gravity, and documents, BOMs, changes, reviews, tasks, and lifecycle views all operate as connected representations of that model. The shift is from managing documents about a product to managing the product definition itself.

xBOM Holds Multiple Perspectives, Not Multiple Copies

xBOM model is the part of this architecture that most directly answers the fragmentation problem, and it is worth stating plainly what it is and what it is not.

xBOM is not a mechanism for maintaining multiple bills of materials. It is a framework for representing multiple product perspectives within a single collaborative workspace built on one shared product model. It does this through configurable BOM types and graph-oriented relationships rather than through separate stored structures. Engineering, manufacturing, procurement, service, compliance, and custom lifecycle views become configurable representations of the same underlying definition. The relationships, lifecycle states, and business processes stay connected, while each function sees the structure through the lens that fits its work.

A concrete case makes the difference clear. Consider a team building an electric cargo bike. Engineering models the drive unit as a single functional assembly, because that is how it is designed and reasoned about. Manufacturing needs that same assembly broken out into the wiring harness, the fasteners, and the assembly sequence that the line actually follows. Procurement does not care about the assembly boundary at all. It needs the battery cells consolidated across every assembly that uses them so it can negotiate one volume price.

In a separate-BOM world, those are three documents that someone has to keep in agreement, and the moment an engineer revises the drive unit, the other two start to drift until a sync process catches up. In OpenBOM, they are three views of one model. The drive unit is defined once. Manufacturing’s breakout and procurement’s consolidation are derived perspectives on the same parts and relationships, so a change to the model is a change everyone is already looking at. The perspectives differ. The product does not. This is the shift from managing several independent BOMs toward managing one connected network of product relationships.

In a separate-BOM world, those are three documents that someone has to keep in sync, and the moment an engineer revises the drive unit, the other two start to drift until a sync process catches up. In OpenBOM, there are three views of one model sharing the same item objects. The drive unit is defined once. Manufacturing’s breakout and procurement’s consolidation are derived perspectives on the same parts and extend instance (BOM) attributes with flexible attributes, so a change to the model is a change everyone is already looking at. The perspectives differ. The product does not.

This is the core of the xBOM workspace idea. The focus moves from managing several BOM silos to managing one connected product model that can support many lifecycle perspectives at once.

The Product Is No Longer Only Mechanical

There is a second kind of fragmentation that matters even more, and the cargo bike shows it too. The bike is not only a frame and a drive unit. It has a motor controller board designed in an ECAD tool, firmware that lives in a Git repository, sensors, and a wiring harness that ties the electrical and mechanical sides together. A modern product is rarely a single-discipline object anymore. From medical devices to industrial robots to connected consumer hardware, products now combine mechanical structures, electronics, printed circuit boards, and software, and each of those disciplines is designed in its own tool.

For decades PLM treated this as a mechanical problem with everything else handled on the side. The mechanical team works in SOLIDWORKS or Creo, the electronics team designs the board in Altium or Eagle, some groups work in cloud tools like Onshape or Autodesk Fusion, and software sits in a repository none of the CAD systems can see. Some of these tools are cloud-native and some are still desktop and file-server bound. Historically these disciplines met only late, through emails, side conversations, and scattered documents, and usually at manufacturing, which is the worst possible place to discover that they disagree.

The cost of that gap is specific and familiar. A last-minute change to the control board in ECAD never reaches the mechanical enclosure that has to house it. A software component tied to a particular board revision goes untracked in the BOM. Multiply those across several teams and a few development cycles and the result is rework and delay that no one can trace back to a single decision.

A workspace organized around the product model treats discipline as just another perspective. The mechanical part, the electronic component, the PCB, and the software package are all items in the same model, each with its own metadata, references, versions, and lifecycle status, regardless of which discipline tool produced it. The mechanical team sees the electronic components it has to fit. The electrical team is alerted when a housing change affects the board layout. Procurement sees one holistic picture of what has to be ordered across every discipline. The disciplinary views are not a separate problem from the functional ones. They are the same idea, applied along a different axis, on the same product model.

The Same Product Model Produces Multi-Level and Flattened Views Without Extra Maintenance

The perspectives in xBOM are not only functional. They are also structural, and this is where the one-model architecture pays off in everyday work. 

The core data model of product structure in OpenBOM is reference-instance model and it allows to keep flexible data attributes for both objects and links and to perform edits of instances and items in the same collaborative grid user experience. 

Different processes need the product structured differently. An engineer navigating the cargo bike wants the multi-level view: the drive unit, the assemblies beneath it, the parent-child path down to a single fastener, the hierarchy you move through to understand how the product is built. Procurement wants none of that hierarchy. It wants the flattened view, with every instance of the same battery cell across every assembly consolidated into one line and one total quantity it can price. Manufacturing wants the quantity rollups that tell it how much of each material a build consumes.

In a document-centric system, these are different spreadsheets that someone exports, edits, and maintains. In OpenBOM they are derived. The multi-level view and the flattened view (quantity reports) are all generated from the same structure, and they recalculate as the structure changes. Cost rollups, material planning, and procurement analysis read from those derived views rather than from separately kept files. No one maintains a flattened BOM, because there is nothing to maintain. There is one model, and the views are computed from it.

The Workspace Holds a Latest State, and Formalizes Only at Milestones

Traditional PLM manages change through formal revision cycles and document locking, which pushes users to create a revision for nearly every modification and to move between modules to do it. That ceremony makes sense at release. It makes very little sense during active design, where it slows the work it is meant to protect.

OpenBOM separates day-to-day collaborative work from formal release. Multiple people edit the same product information at the same time, and every change is recorded automatically, so a continuous audit trail exists without anyone issuing a revision to produce it. The latest-state workspace is the continuously evolving definition of the product, the thing the whole team is actually working on. When a milestone calls for a fixed point, a revision snapshot or a design baseline preserves a specific state of the structure. 

The foundation of the workspace is a collaborative grid experience that seamlessly integrates data from the product model and presents a unified view of the simple “spreadsheet like” user experience. 

The effect is that flexibility during development and traceability at release stop being a tradeoff. They are two operations on one model rather than two systems that have to be kept in agreement.

Reviews Belong on the Product, Not in a Spreadsheet

Once the product model is the center of gravity, several things that used to live outside PLM can move back onto it, and review is the clearest example.

Product reviews are still routinely run in spreadsheets, email threads, and screenshots, disconnected from the data being reviewed. OpenBOM brings the review onto the product itself. Because the workspace is built on a flexible object model, a comment, a task, or a decision can attach not only to a part but to an assembly, a relationship, a document, a supplier, or a manufacturing record, or to any custom object an organization has defined. 

In OpenBOM, the  BOM Review is a validation, a manufacturing readiness check, a procurement review, and a compliance verification can all happen in the same environment, with full context, against live data.

Take the cargo bike again. When a procurement reviewer flags that two assemblies specify slightly different cells that could be consolidated, that comment lives on the battery cell in the model, visible to the engineer who owns it and the buyer who raised it. The review is no longer a separate artifact that goes stale the moment the BOM changes. The discussion sits on the object it concerns, and it stays there, where the next person to open that part will find it.

Change Connects to Live Product Data Instead of Living in Its Own Silo

Formal governance still matters, and collaborative editing does not replace it. What changes is where change management lives. OpenBOM’s change requests and change orders operate directly inside the workspace, connected to the product data they govern rather than running as an isolated administrative workflow off to the side.

The foundation of change management is OpenBOM workspace architecture, which allows to multiple users to perform changes simultaneously and after coming to the desired maturity state, to capture a snapshot that represents a “revision” – an immutable state preserved in the history.   

This is what lets the day-to-day work and the formal release process share one chain of traceability. The procurement reviewer’s comment on the battery cell becomes a change request. The request carries its impact across every assembly that uses the cell, because those relationships are already in the model. A task is assigned, an engineering change order follows, and the affected items, revisions, review comments, and change records all stay linked to the same structure and to each other. The result is a continuous chain from the first observation through implementation and release, rather than a set of separate records that someone later has to prove are related.

Each Role Sees the Product Through Its Own View

Traditional PLM tends to expose everyone to everything, then relies on training and discipline to keep people focused on the part of the system that concerns them. OpenBOM treats visibility as a property of the view, not of the data. Engineering, manufacturing, procurement, supplier collaboration, and executive reporting each work through a view shaped to the role or task, while the underlying model stays single and consistent. Information visibility is separated from data storage, so the same product definition serves every role without being copied for any of them. 

This extends past predefined schemas. Because the model is built from configurable objects, an organization can introduce custom attributes, custom object types, and process-specific workspaces, and define new views without extensive customization or a schema rebuild. The product model is one thing. What each role sees is a configuration on top of it, and the configuration can change without disturbing the model underneath. Learn more how multiple teams can work together via multiple views. 

Distributed and AI-Driven Work Needs a Model, Not a Pile of Documents

This architecture would matter even if nothing about how teams work had changed. But the way products are developed now makes it matter more.

Engineering work is distributed across companies, suppliers, and time zones, and increasingly it is supported by automated workflows and AI processes. None of that operates well on isolated collections of documents. A distributed team needs a single current state to work against rather than a set of files to reconcile. An automated workflow needs structured relationships it can traverse. An AI agent reviewing a BOM or proposing a change needs direct access to a product model, not a folder it has to interpret. A document-centric architecture forces all of these to first reconstruct the product from its files. A workspace organized around the product model hands them the product directly.

This is also where the workspace connects to the larger arc of where OpenBOM is going. A model that captures the product, its relationships, and the decisions made against it is the foundation that a product memory can be built on. That is a subject for its own article, but it is worth noting that the architecture described here is what makes it possible.

Conclusion: From Documents About a Product to the Product Itself

The move from a document-centric core to a workspace organized around the product model is a small change to state and a large change to consequences. Instead of arranging information around files, OpenBOM arranges it around a connected product model made of flexible objects, relationships, and lifecycle views. xBOM extends that foundation by letting engineering, manufacturing, procurement, service, and custom perspectives coexist as configurable views of one definition rather than separate structures that have to be kept in step. Derived views, latest-state collaboration, reviews, change processes, and role-based access are not separate modules bolted on around that model. They are things the model lets you do.

The result is that BOM management, reviews, tasks, changes, and lifecycle operations, along with the AI-driven workflows now arriving in engineering, can all operate on a shared product definition while traceability, collaboration, and governance hold across the whole lifecycle. The center of gravity moves from the document to the product, and once it does, a great deal of the friction that PLM teams have learned to live with turns out to have been a property of the old center, not of the work.

REGISTER FOR FREE to check how OpenBOM can help. 

Best, Oleg 

FAQ

What is OpenBOM xBOM Workspace? It is a collaborative workspace where BOMs, derived views, reviews, tasks, changes, and lifecycle operations all act on one shared product model. Instead of managing files and separate BOM structures, teams manage a connected product definition that different functions can view through the lens that fits their work.

What is OpenBOM Collaborative Editing? It is a mechanism that allows multiple users to perform simultaneous editing tasks on complex structured product data, including hierarchical data, items, and instances, using a simple spreadsheet-like user experience. The workspace automatically captures the history.  

What does xBOM mean? xBOM is a framework for representing multiple product perspectives, such as engineering, manufacturing, procurement, service, and compliance, within a single product model using configurable BOM types and graph-oriented relationships. It is not a way to maintain multiple separate BOMs. The perspectives differ while the underlying product definition stays the same.

How does xBOM Workspace handle engineering, manufacturing, and procurement views? They are derived from one model rather than maintained as copies. The same product produces a multi-level engineering view, a flattened procurement view with consolidated quantities, and manufacturing quantity rollups, and all of them recalculate when the model changes.

How does change management work in OpenBOM? Change requests and change orders operate inside the workspace, connected directly to live product data. A review comment can become a change request that carries its impact across every affected item, with tasks, revisions, comments, and change records linked along a continuous chain from observation through release.

How is xBOM Workspace different from traditional PLM? Most PLM systems inherit a document-centric architecture from the CAD file management tools of the 1980s and 1990s, where files are the primary object. OpenBOM is built on a flexible object data model where the product, its relationships, and its lifecycle views are the primary objects, and documents are one connected representation among many.

Why does this architecture matter for AI and distributed teams? Distributed teams, automated workflows, and AI processes need direct access to a structured product model, not isolated collections of documents they first have to reconstruct. A workspace organized around the product model hands them the product directly.