From 2D Drawings to BOM Collaboration: How PLM Complexity Became a User Experience Problem

Martin Eigner recently shared a reflection that stayed with me. In a LinkedIn post about engineering in the 1970s and 1980s, he described how much simpler the world felt when the 2D drawing was the primary communication medium for engineering work. It is a striking observation, and I think it points to something the PLM industry still has not fully resolved.

The obvious reading is that products were simpler then. And of course they were, in some ways. But that is not actually Martin’s point, and it is not the more interesting question. The more interesting question is this: did our digital systems make PLM complexity worse than it needs to be?

I think the answer is yes. And the 2D drawing tells us exactly why.

What Is a Collaborative Context Workspace?

Before going into the history, it helps to define the concept this article is built around. A Collaborative Context Workspace is a product data environment that connects CAD, BOM, procurement, supplier, and ERP information in one place and presents it through a simple, spreadsheet-like collaborative interface. Unlike traditional PLM systems, it is designed to hide data complexity from users rather than expose it. The goal is not to replace EBOM, MBOM, or other product structures. The user experience was inspired by Google Spreadsheets, but the data model includes the level of abstraction and flexibility to put any PLM artifact as a simple “spreadsheet” view. 

The goal is to give people a single working context where those structures are connected and usable, without requiring them to navigate each one as a separate system.

This is what OpenBOM Collaborative Workspace is built to do, and the rest of this article explains why the problem it solves is real and why the industry has struggled with it for so long.

The Drawing Was Not Simple. It Was Shared.

In the 2D drawing era, the drawing did more than describe geometry. It contained product structure, position numbers, notes, references, and enough engineering intent for people across multiple functions to understand what needed to be built. It was the common artifact that connected engineering, manufacturing, procurement, and downstream suppliers. It was limited, of course. It did not support configuration management, digital change processes, software dependencies, or global supplier collaboration. But it had one advantage that modern PLM systems often fail to replicate: people knew exactly where to look.

The drawing was the leading artifact. It was the product memory of its time.

When digital tools arrived, we gained enormous capability. 3D CAD models captured geometry in ways drawings never could. PDM systems organized files, versions, and revisions. PLM systems introduced formal change processes, lifecycle states, and configuration control. ERP systems managed item masters, inventory, and planning. Procurement systems organized supplier relationships and purchasing workflows. Electronics and software brought their own structures and dependency models.

With all of this came EBOM, MBOM, SBOM, service BOM, manufacturing process structures, ERP item records, supplier packages, change objects, and a growing collection of digital representations, each created for a legitimate reason, each owned by a different team, and each increasingly disconnected from the others.

Products became more complex. But the user experience of managing product data became more complex even faster.

When PLM Complexity Becomes a User Experience Problem

The problem is not that modern products require multiple BOM views. Engineering needs to represent design intent. Manufacturing needs to represent how the product will be built. Procurement needs cost, supplier, lead time, and ordering information. ERP needs planning and transactional data. Service needs maintenance and replacement context. These are real requirements, and no single flat structure satisfies all of them.

The problem is that people are forced to navigate all of these representations directly, as separate worlds, with no shared context to orient them.

Where does the CAD assembly end and the EBOM begin? Who owns the MBOM? Which BOM is the released version? Which spreadsheet has the current supplier pricing? What did engineering send to procurement last week? Which version did the supplier actually receive? Is the procurement package aligned with the latest engineering change?

These questions are not abstract data governance concerns. They are daily friction points for engineers, manufacturing planners, buyers, and program managers. And when the friction becomes high enough, people make a rational choice. They go back to the simplest tool available.

They open Excel.

Why Spreadsheets Won, and What That Actually Means

It is tempting for PLM professionals to treat spreadsheet use as a failure of discipline. I think that misreads the situation. Spreadsheets became the default workspace in engineering and manufacturing because they are genuinely good at something: making structured data visible, editable, and immediately understandable to the person in front of them.

People understand rows and columns. They understand filters, formulas, sorting, and comparison. A spreadsheet gives users a feeling of control. You can see the data, change it, organize it in whatever way matches the problem you are solving, and send it to someone else without a workflow or a training session.

Traditional PLM often responded to spreadsheet use by adding more governance: more object types, more formal workflows, more rigid structures. Some of this was necessary. But in practice it often pushed people further away. The result was predictable: PLM became the system of record for formal releases, and spreadsheets remained the actual working environment.

The right lesson is not that spreadsheets should be eliminated. The right lesson is that the spreadsheet experience needs to be replaced with something better, not something heavier. The goal is to preserve the clarity and flexibility that spreadsheets offer while replacing the fragility, disconnection, and governance gaps with something connected, collaborative, and traceable.

This is the architectural problem that BOM management software needs to solve, and it is the problem OpenBOM Collaborative Workspace is built around.

BOM Collaboration Needs a Connected Data Model Underneath

The core idea behind a Collaborative Context Workspace is straightforward. Product data can be complex underneath. The user experience should be simple on top.

Modern engineering teams need to work with CAD data, BOM structures, item attributes, documents, supplier information, cost records, inventory, purchasing activity, change history, and ERP integrations. That complexity is real and cannot be wished away. But users should not be required to jump between disconnected systems just to understand the current state of a product.

A workspace that works does two things at once. It connects product information from multiple sources into a coherent underlying model. And it projects the relevant portion of that model into a familiar, table-based collaborative environment where people can review, edit, compare, comment, and decide.

This is how OpenBOM approaches the problem. The flexible data model connects information coming from different places: CAD systems, item catalogs, multiple BOM structures, vendor records, cost data, purchasing transactions, and ERP integrations. Rather than forcing all of this into a single predefined structure, the model holds relationships between these sources while allowing each view to show what is relevant for the task at hand.

On top of this, users work in a spreadsheet-like collaborative environment that feels familiar but behaves like a connected product system. When a buyer looks at a BOM, they see cost and supplier information without having to reconstruct it from a separate file. When an engineer makes a change, the downstream impact is visible in context rather than discovered during a review meeting two weeks later.

BOM Sandbox: Exploring Changes Before They Are Released

One of the areas where this architecture matters most is in the work that happens before a formal change is released. Engineers and manufacturing teams spend significant time asking what-if questions: what happens if we replace this component, which assemblies are affected, what does this do to cost, which suppliers are involved, does manufacturing need to adjust the build structure?

In most PLM environments, this exploration happens outside the system. People export data, work through the analysis in spreadsheets, align in email threads and meetings, and then bring the conclusion back into the formal system. This is not because engineers prefer to work that way. It is because formal PLM systems are designed for governed records, not for exploratory work.

A BOM sandbox changes this. It gives teams a place to explore a change in the actual product context before the decision becomes official. Cost impact, affected structures, procurement implications, and supplier readiness can all be reviewed together, collaboratively, while the question is still open. This is not a replacement for formal change management. It is the working environment that makes formal change management faster and better informed.

OpenBOM’s collaborative workspace includes this working layer because the space between the first question and the final release is where most of the real product decision-making actually happens.

Collaboration Is What Removes Hidden PLM Complexity

There is a pattern in engineering organizations that rarely gets named directly. When people cannot work together in the same product context, they build coordination infrastructure around it. They email spreadsheets. They send ZIP archives. They create their own copies of BOMs. They hold alignment meetings to reconcile information that diverged because different people were working from different versions.

This coordination overhead is invisible in most PLM metrics but very visible to the people doing the work. It is the reason program managers spend hours before design reviews gathering information that should already be in one place.

Simultaneous collaboration in a shared workspace removes much of this overhead structurally. When engineering, manufacturing, procurement, and suppliers can all see the same product context and work within it, the informal coordination layer shrinks. People still need to make decisions and resolve conflicts, but they do so against shared information rather than reconciling divergent copies.

This is what makes collaboration a simplification mechanism rather than a convenience feature. OpenBOM Collaborative Workspace supports this working pattern specifically for growing manufacturing companies where product work happens across CAD tools, multiple team members, external suppliers, contractors, and ERP processes, often simultaneously.

The Leading Artifact Has to Change

Martin’s observation about the drawing as a shared context points to a gap that PLM has not fully closed. Engineering needs a leading artifact: a place that anchors the shared understanding of what is being built, for everyone involved.

In the 2D drawing era, the drawing served this function. It was limited, but it was authoritative and shared. In the modern era, no single artifact plays this role. The CAD model is authoritative for geometry but not for cost or procurement. The EBOM is authoritative for design structure but not for manufacturing. The ERP item master is authoritative for planning but not for configuration. Each system holds a piece of the picture, and no single piece is the leading artifact.

A Collaborative Context Workspace is designed to become the new leading artifact, not as a document, but as a living environment. It does not replace CAD, PLM, or ERP. It connects them and projects the relevant context to the user at the right moment. The complexity is still there, organized and managed underneath. What changes is that users no longer have to navigate it directly just to understand the product.

This is also how the workspace creates Product Memory.

Product Memory and the Foundation for PLM AI

AI is part of nearly every PLM conversation today, and I think the excitement is justified. But it is easy to underestimate what AI actually needs to be useful in an engineering context.

A language model connected to a document repository can answer questions about documents. That is not the same as understanding a product. To reason meaningfully about product information, an AI agent needs to know what a part is, where it is used, which revision is current, what documents are connected to it, which supplier provides it, what it costs, what changed, which BOM structures contain it, and what decisions were made about it and why. This is not a retrieval problem. It is a context problem.

A connected Collaborative Context Workspace creates this context. When product data, structures, decisions, files, supplier relationships, costs, and changes are organized in one environment with explicit relationships, AI agents can do meaningful work: validating BOMs, identifying gaps, explaining the impact of a change, summarizing procurement readiness, flagging inconsistencies between engineering and manufacturing structures, and surfacing the information people need before they think to ask for it.

This is what Product Memory means in practice. It is the accumulated, connected context of product decisions over time. And it is the foundation that makes PLM AI useful rather than superficial. OpenBOM Collaborative Workspace is built with this in mind. The flexible data model is not only an architectural choice for today’s user experience. It is the structure that makes AI reasoning over product data tractable.

The Lesson from the Drawing Era

The 2D drawing era was not simple because products were simple. It was simpler because everyone shared the same context. The drawing was imperfect, but it was common.

Digital transformation gave us richer data, better tools, and far more capability. It also gave us fragmented systems, disconnected silos, and user experiences that exposed organizational complexity rather than hiding it. PLM systems often made this worse by requiring users to navigate data structures rather than work within product context.

The next step is not more complexity. It is a collaborative workspace that brings CAD, BOM, procurement, supplier, and ERP information into a shared context, presents it simply, and builds the product memory that makes AI reasoning possible.

BOM simplification is not about removing BOMs. PLM simplification is not about pretending products are simple. The opportunity is to hide unnecessary complexity behind a collaborative context that helps people understand, decide, and act.

This is what OpenBOM Collaborative Workspace is designed for. And I think it is the right direction for PLM to move.

REGISTER FOR FREE to check how OpenBOM Collaborative Workspace can help. 

Best, Oleg 

Frequently Asked Questions

What is a Collaborative Context Workspace in PLM?

A Collaborative Context Workspace is a product data environment that connects CAD, BOM, procurement, supplier, and ERP information in one place and presents it through a simple, spreadsheet-like collaborative interface. It is designed to hide data complexity from users rather than expose it, giving engineering and manufacturing teams a single working context instead of multiple disconnected systems. OpenBOM Collaborative Workspace is built on this concept.

What is BOM simplification and why does it matter?

BOM simplification is not about reducing the number of BOM types or removing product structures. Engineering BOMs, manufacturing BOMs, and service BOMs each exist for legitimate reasons. BOM simplification is about reducing the user experience friction that comes from navigating disconnected systems. When teams have to jump between CAD, ERP, procurement spreadsheets, and supplier files to understand one product question, the complexity is in the workflow, not the product. A connected collaborative workspace simplifies this by bringing those views into one environment.

What is Product Memory in PLM? Product Memory is the accumulated, connected context of product decisions over time: what a part is, where it is used, which revision is current, what changed, what supplier provides it, what decisions were made and why. Unlike a document archive or a BOM export, Product Memory captures relationships between product data, people, decisions, and processes. It is the foundation that makes PLM AI reasoning practical rather than superficial, because AI agents need context, not just documents.