From PDM Limits to the Spreadsheet Bottleneck: Why Engineering Teams Need Connected BOM Workflows

The article I published earlier this week – Why PDM Alone Is Not Enough to Manage Engineering Data – explored why traditional PDM systems can no longer support the full scope of modern engineering work. PDM was created to manage CAD files and keep revisions under control. It still does this well, but the engineering landscape has changed. Products now span mechanical, electrical, electronics, firmware and software. Teams are distributed, supply chains are fragmented and every project carries a wider range of data than ever before. Once you move past the CAD environment, the role of PDM becomes limited.

This limitation is where today’s story begins. The gap between what PDM was designed to do and what engineering teams actually need has created a secondary problem that is now common across the industry. As soon as the information leaves CAD, most teams default to a familiar tool. They open Excel (or any type of spreadsheets available for them).

It feels natural because Excel is always available and easy to use, but it brings complexity and inefficiency that often goes unnoticed until it becomes a serious bottleneck. This article explains how engineering teams reached this point, why spreadsheets became the fallback tool and why they now stand in the way of efficient and connected product development.

The Growing Gap Between PDM and Real Engineering Work

To understand how engineering teams ended up relying on spreadsheets, it helps to look at the evolution of PDM systems. Early PDM tools were simple vaults created to manage CAD files. They controlled versions, organized projects and kept multiple designers from overwriting each other’s work. For a long time that was enough.

As long as the engineering definition lived inside CAD files, PDM systems could act as the central source of truth. Once products expanded beyond single engineering disciplines, PDM remained focused on files while the surrounding engineering context grew in complexity. Parts lists became more detailed. Supplier information became more critical. Manufacturing requirements changed frequently. Electrical and mechanical designs needed to stay aligned.

The more complexity grew, the less PDM could represent the full product. Engineers needed a place to combine information that was not stored in CAD. This included purchased parts, non modeled items, packaging materials, electronics components, compliance attributes, variants and manufacturing details. PDM systems did not evolve for this type of work. They continued to be file organizers while the real product definition expanded beyond the CAD boundary.

This is the moment when spreadsheets quietly entered the process. Teams filled the gaps left by PDM with Excel files that spread across local drives, shared folders, emails and cloud storage. Excel became the glue that held together the parts of the product that did not live inside CAD.

The Rise of Spreadsheets Inside Engineering Organizations

Every engineering organization I meet has a similar story. It begins with one spreadsheet created to track something simple that did not belong in CAD. Someone builds a small parts list for a prototype. Someone else adds a worksheet to track a few supplier items. The spreadsheet grows. A new tab appears. Then a column. Then another sheet.

Over time the spreadsheet becomes essential. It contains information that no other system manages. As soon as the BOM needs to include anything not modeled in CAD, the spreadsheet becomes the master list. The product starts living in multiple places. CAD contains the structure, while the Excel file contains everything CAD does not manage.

At this point the spreadsheet is no longer a temporary workaround. It becomes the single place where the complete product definition exists. Engineers, buyers, managers and contractors rely on it because nothing else contains all the information.

This model can continue for a while. As long as the spreadsheet is updated by one person and shared with a small team, things function well enough. The problems only begin when product complexity grows or when more people begin to rely on the same spreadsheet for daily work.

Why Spreadsheets Become a Bottleneck for BOM Work

When PDM cannot represent the full product structure, spreadsheets fill the gap. This sounds harmless, but it introduces several weaknesses that compound over time.

Spreadsheets are disconnected from the systems that generate most of the product data. Engineers need to extract information from CAD tools and paste it into sheets. Multiple people contribute updates by sending versions over email or saving copies in cloud folders. Changes from suppliers arrive as new files. Cloud storage synchronizes some of these files but does not unify the data.

Spreadsheets require manual updates. An engineer needs to type new parts, revise quantities, fix descriptions, add suppliers and adjust references. One missed update leads to incorrect information. One copied row creates a duplicate item. One overwritten file results in a lost revision.

Data arrives from many unstructured sources. Files from cloud storage, attachments from emails, copy and paste from CAD export, manually typed updates from BOM reviews. The spreadsheet absorbs everything but verifies nothing. It becomes a container for data rather than a reliable product structure.

Eventually teams reach the point where no one fully trusts the spreadsheet. They still use it because it is the only place where all the information exists, but they approach it with caution. Engineers spend time confirming quantities. Buyers send clarifying messages. Manufacturing requests screenshots to verify the final structure.

The spreadsheet that was supposed to fill a gap becomes a daily source of uncertainty.

The Human Impact Behind Spreadsheet Driven Processes

This uncertainty affects engineers more than anyone else. Spreadsheets create subtle pressure that builds day after day.

A typical engineer begins their morning by opening the latest version of the BOM to confirm it contains their recent updates. If the file is in a shared folder, they look for the newest timestamp. If it arrived by email, they search their inbox. If someone else edited the file, an unexpected conflict appears.

Engineers spend time fixing issues that should not exist. They review quantities, verify item numbers, compare versions and repair broken formulas. Some of this is invisible overhead. It looks like small tasks, but multiplied across the team it becomes a significant cost.

Engineers feel frustrated because they cannot rely on the data. They hesitate to make changes because they fear breaking something. They spend more time checking for mistakes than creating new designs.

This pressure creates a culture of caution. Teams work slower. Meetings become longer as people verify information verbally. The spreadsheet becomes a fragile system everyone depends on but no one fully trusts.

The Strategic Consequence for Organizations

Spreadsheet driven processes slow teams down in a way that becomes visible to leadership only after significant delays. Engineering decisions rely on data accuracy. Manufacturing planning depends on correct part information. Procurement needs reliable supplier records. When spreadsheets become the central place for BOM data, every function inherits the same uncertainty.

Organizations lose the ability to maintain a continuous thread of information from design to production. Traceability becomes difficult. Revision clarity becomes inconsistent. Variants and options become impossible to manage in a single file.

The result is an engineering process that cannot scale with the complexity of the product. What worked for the first few prototypes does not work for production. What worked for a single department does not support cross functional teams.

In 2025, teams should not rely on spreadsheets to manage complex product definitions. The work is simply too interconnected. Data comes from too many sources. Collaboration requires a shared and real time view of the product structure. The spreadsheet cannot provide this view.

How Connected BOM Workflows Emerge From This Reality

The move away from spreadsheet driven processes does not happen because someone decides to replace Excel. It happens because engineering complexity eventually reaches a point where spreadsheets cannot keep up.

A connected BOM workflow is a natural evolution of this complexity. Instead of storing the product definition inside a static file, the BOM becomes a living structure that reflects data from CAD, engineering attributes, purchased components, supplier information, manufacturing planning and service requirements.

This type of workflow does not require manual updates because the data arrives from the systems where it originates. CAD updates create structural changes. Engineers enrich parts with additional attributes. Manufacturing adds process information. Procurement links suppliers.

The BOM becomes a shared space for the entire team rather than a single file controlled by one person. Everyone sees the same information. Everyone works from a consistent source. Teams stop sending spreadsheets back and forth and start working on the same structure in real time.

This connected approach restores trust. Engineers no longer fear breaking a spreadsheet. Buyers rely on accurate metadata. Manufacturing receives the correct structure every time.

The spreadsheet bottleneck disappears and the product definition becomes part of a larger and more reliable engineering workflow.

The Path Forward: From Spreadsheets to the Digital BOM

The shift from PDM to spreadsheets happened because engineering teams needed a way to represent the full product definition. The shift from spreadsheets to a connected approach is starting to happen for the same reason. As products grow in complexity and teams depend on fast, reliable data, a static file no longer represents what a product actually is. The information moves. It changes. It grows with every decision made by engineering, manufacturing, procurement and suppliers.

This is the point where a new concept begins to emerge. Spreadsheets flatten product information into rows and columns. A Digital BOM treats the product definition as a living model. It carries the structure of the product, the data behind each part and the relationships that allow the entire organization to work with confidence. It behaves more like a product data backbone than a document.

A Digital BOM is not a spreadsheet and it is not a CAD export. It is a representation of how the product actually exists inside the company. It includes what CAD provides but also everything CAD does not manage such as supplier items, compliance details, alternates, consumables, configurations and manufacturing attributes. It is always synchronized with the systems that generate the information. It is accessible to every team that depends on it. Most importantly, it becomes the shared truth that removes uncertainty and replaces the constant need to verify data manually.

Once a Digital BOM exists, the workflow around it changes as well. The work no longer depends on sending files or reconciling spreadsheets. Teams begin to operate through what I call a Connected BOM Workflow. This workflow links design changes, engineering attributes, purchasing details and manufacturing requirements into a continuous flow of information. Everyone sees updates in context. Everyone works on the same product representation.

A Connected BOM Workflow is a natural evolution of modern engineering work. It aligns data from multiple sources, reduces friction between departments and gives organizations a way to scale their processes without increasing manual effort. It also removes the hidden cost created by spreadsheets.

The long-time OpenBOM customer – Pyka – described the process of how they moved from Google Spreadsheets to OpenBOM. Here is the story of Pyka digital BOM adoption: 

Pyka Lead Mechanical Engineer Garrett Rini described the product’s evolution “moving from prototyping to production manufacturing is really hard.  We needed to button down parts, assemblies, and procedures and pass that information along to the manufacturing teams.”

“Our airplanes have lots of parts and assemblies to keep track of across two distinct teams, Engineering and Manufacturing, and we need to be on the same BOM all of the time. Getting all of that info straight was a big problem and Google sheets weren’t going to get us there.”  Says Garrett.

“We were basically trying to build OpenBOM in Google sheets,” he says. After a bit of research, OpenBOM for Teams was a perfect fit for this rapidly growing company.

Conclusion: 

Digital BOM and Connected BOM Workflow are new ways to think about how product data should behave in an environment where engineering work is fast, collaborative and multi-disciplinary. They reflect the reality that a product is not a static document but a constantly evolving system of information.

As product complexity grows, this shift becomes essential. Teams that continue relying on spreadsheets will face increasing overhead and uncertainty. Teams that adopt a Digital BOM and operate within a Connected BOM Workflow will be able to move faster, maintain accuracy and support the demands of modern engineering with far more clarity and confidence.

I will continue exploring these ideas in future articles and share practical steps for introducing Digital BOM practices and Connected BOM Workflows in engineering organizations. These concepts represent an important transition in how we manage product information and they offer a foundation for the next stage of digital transformation in engineering and manufacturing.

Meantime REGISTER FOR FREE to check how OpenBOM can help you to organize a connected digital BOM workflow. 

Best, Oleg