Why SolidWorks Teams Lose Control of BOMs and Files – And What PDM Can’t Fix

How file-based workflows, disconnected BOMs, and the limits of PDM combine to create a product data problem most engineering teams recognize but rarely name correctly.

SolidWorks Was Built for a Different World

SolidWorks is a super solid foundation for any engineering and manufacturing team.

It was built to be exactly that. Thirty years ago, SolidWorks set a new standard for what professional mechanical CAD could be — powerful enough for serious engineering work, accessible enough to run on a Windows PC, practical enough for teams that sat together in one office and passed files down the hall. It delivered on that promise remarkably well, and the ecosystem that formed around it became one of the most resilient in the history of engineering software.

But the world those workflows were designed for no longer exists for most teams.

The trouble starts when a design has to become a BOM, a spreadsheet, a PDF, a STEP file sent to a supplier, a sourcing table in procurement, and a revision someone needs to track across all of them at once — across people in different offices, different time zones, different tools, and different habits around where files get saved and shared.

I’ve watched this pattern repeat in engineering teams for years. It has nothing to do with CAD quality. It has everything to do with what happens to product information once it leaves the CAD environment. After 3DEXPERIENCE World 2026 I wrote a longer reflection on where the SolidWorks ecosystem is heading and argued that the next center of gravity in engineering is forming around product data, not around another CAD transition. This post is the ground-level version of that same argument. I want to be practical to help engineering and manufacturing teams. The kind of problem that shows up on a Tuesday afternoon when someone asks: which BOM did we actually send to purchasing?

SolidWorks Is Not Where the Chaos Begins

This is an important distinction worth stating clearly. When teams complain about BOM problems, file chaos, spreadsheet overload, or revision confusion, the instinct is often to assume the CAD system itself is the problem. It won’t be solved by moving to another CAD or hosting files in the cloud. 

The CAD model can be accurate and up to date while everything around it slowly becomes fragmented. And once that fragmentation begins, people lose confidence not in the design itself, but in the downstream data needed to actually build, buy, and deliver the product. Engineers trust what they see on screen in SolidWorks. What they do not always trust is the BOM that was exported last Tuesday, the spreadsheet procurement is currently using, or the PDF someone emailed to a supplier two revisions ago.

That gap — between the design and the operational data surrounding it — is where most of the real productivity loss happens. And it is also where the real conversation about SolidWorks data management needs to start.

Why SolidWorks PDM Doesn’t Solve the Problem in 2026

The obvious response at this point is: use SolidWorks PDM. Vault your files, control your revisions, manage your releases. The tool exists. Many teams already have it.

And PDM does solve part of the problem. Inside a controlled vault, file versions are tracked, access is managed, and engineers can check files in and out with reasonable confidence about what is current. For a team of mechanical engineers sitting in the same office, working on the same Windows network, building purely mechanical products, PDM works reasonably well.

But that description fits fewer and fewer teams in 2026.

The first limitation is infrastructure. SolidWorks PDM was designed in the same era and with the same assumptions as SolidWorks itself — a Windows-centric environment, a local or networked infrastructure, and a team that is largely co-located. Remote work has fundamentally changed that model. Distributed teams, contractors working from different locations, and suppliers who need controlled access to design data do not fit cleanly into a vault architecture built around Windows infrastructure and local network performance. The friction of working with PDM across geographies and outside the firewall is real, and many teams feel it every day.

The second limitation is scope. SolidWorks PDM manages SolidWorks files. That is what it was built to do, and it does that job within its boundaries. But modern products are rarely purely mechanical. Electronics, firmware, software, and interconnected subsystems are now part of the product definition for a growing number of engineering teams. PDM has no meaningful answer for an ECAD schematic, a firmware revision, or a software bill of materials. The moment a product includes a PCB, an embedded controller, or a software component, PDM’s coverage ends and the fragmentation problem begins again — in a different part of the organization, with different tools, different file formats, and no connection back to the mechanical BOM.

The third limitation is collaboration flow. PDM was designed around engineering control — checking files in, checking files out, managing revisions inside a disciplined vault. That model assumes product data moves in one direction: engineering produces, everyone else consumes. But that is not how product development actually works. Supply chain and procurement need early visibility into design intent, often before a design is fully released, so they can start sourcing, flag long lead time components, identify preferred vendors, and surface supply constraints that may influence design decisions. That feedback needs to come back into engineering before changes become expensive. PDM has no natural mechanism for this kind of iterative, cross-functional exchange. It was built for engineering scope, not for the upstream and downstream conversations that happen around it. So procurement works from exports and spreadsheets, suppliers work from emailed files, and the feedback loop that should connect engineering to supply chain remains informal, slow, and disconnected.

So teams end up in a familiar place. The mechanical side may be relatively controlled inside PDM. Everything else — electronics files, software versions, supplier communication, cross-disciplinary BOMs, procurement data, supply chain feedback — lives outside it. And the boundary between those worlds is exactly where the disconnection happens.

PDM was the right answer for the problem it was designed to solve. The problem has grown larger than the tool. If you are curious how a modern cloud-based approach to PDM and BOM management addresses these gaps, our Getting Started with OpenBOM 2026: Managing CAD Files and Versions article walks through the practical steps.

How SolidWorks BOM Data Falls Apart After the Export

In many SolidWorks teams, the design work itself is not the most chaotic part. The real breakdown starts when information begins to move outside the CAD environment and across people, folders, and functions.

An engineer finishes or updates an assembly in SolidWorks. At that moment, the design reflects the latest thinking. But the related files are not always organized in one controlled place. They may be spread across local machines, shared drives, PDM vaults, network folders, cloud storage, and email attachments. Teams working from different offices or remote locations make this worse, because every group develops its own habits around storing, naming, and sharing files. There is no single moment when someone decided to create this fragmentation. It just accumulates, project by project, handoff by handoff.

Then a BOM is exported manually. At the same time, derivative files begin to multiply. PDF drawings are created for release or review. STEP files are generated for manufacturing or vendor communication. DXFs are prepared for sheet metal or fabrication workflows. These files are often created manually, named inconsistently, and stored in different places — attached to emails, dropped into project folders, copied into supplier portals, saved on a desktop with the intention of organizing them later.

And here is where things quietly go wrong. A supplier receives a STEP file by email and uses it to prepare a quote. Two weeks later, engineering updates the assembly to address a tolerance issue. Nobody thinks to re-send the file. The supplier quotes from the old geometry. Procurement approves the order. The discrepancy surfaces weeks later, during production preparation, when someone finally compares the ordered parts against the current CAD.

That situation is not dramatic. It does not feel like a system failure. It feels like a normal Tuesday.

Then the BOM export becomes a spreadsheet. That spreadsheet starts its own life. Someone in procurement adds vendor names, lead times, prices, or substitutions. Someone else uses the same spreadsheet to review sourcing options. A supplier receives a copy by email. Another person saves a version in a shared drive. Another team member makes a small edit and renames the file with a date or initials. Meanwhile, engineering continues changing the CAD model. By the time anyone notices the inconsistency, the gap between what engineering has and what everyone else is working from has quietly grown.

The Version Control Questions Every SolidWorks Team Keeps Asking

This is the moment when a perfectly competent team starts asking the same questions over and over.

Is this the latest assembly? Which BOM did we send to purchasing? Did anything change after the export? Is the supplier quoting the current revision? Are we ordering from the right version? Which file in the shared drive is the real one?

These are not rare or dramatic questions. They are the daily operational friction of teams working in a system that was never designed to preserve context once information leaves the CAD environment. And the cost is not always visible as a single dramatic failure. More often it appears as hesitation, duplicated work, delayed purchasing, and a low-grade but constant uncertainty about what is actually current.

The team searches shared drives to find the correct file. They compare spreadsheet copies to understand what changed. They email suppliers to confirm whether a quote is still valid. They ask engineering if the assembly was updated after the export. They cross-check PDFs against CAD. The work continues, but a growing portion of it is reconciliation rather than progress. Time that should go into building a better product goes into confirming which version of the data is the right one.

Why SolidWorks Teams Still Rely on Spreadsheets for BOM Management

People like to say that teams should stop using spreadsheets, but that advice misses the point. It assumes the spreadsheet is a bad habit. It is not. It is a rational response to a real gap.

Once product information leaves CAD, it has to go somewhere. It has to be shared, reviewed, annotated, compared, and discussed across people who do not all have access to the same tools or the same systems. Procurement needs to add vendor names, lead times, and prices. Operations needs to flag substitutions. A supplier needs something they can open without installing anything. A project manager needs something they can sort and filter. The spreadsheet does all of that. It is flexible, familiar, and requires no onboarding. In a distributed team where not everyone is inside the same PDM vault or the same software license, it is often the only practical common ground.

That is why spreadsheets have survived every wave of PLM, PDM, and ERP adoption for the past thirty years. They are not surviving because teams are unsophisticated. They are surviving because no other tool has fully replaced what they do at the boundary between engineering and everyone else.

The problem is not that spreadsheets exist. The problem is that they are disconnected from the source. They carry data, but they do not carry context. They can tell you what parts are in a BOM, but they cannot tell you whether that BOM reflects the assembly as it exists today, what changed since the last export, or what decisions were made along the way. That context lives somewhere else — or more often, nowhere in particular. And without it, the spreadsheet becomes both necessary and unreliable at the same time. This is the gap that a connected digital BOM is designed to fill — not by replacing the spreadsheet by force, but by making the connected version more useful than the disconnected one.

The Real Issue: Disconnected Product Knowledge, Not Too Many Files

This is where I think the conversation about SolidWorks data management needs to become more precise.

The problem is not simply that teams use files. Files were never the enemy. In my February Beyond PLM article I argued that files were actually what made the SolidWorks ecosystem so broad and resilient — they created practical openness, allowed partners and suppliers to participate, and enabled an enormous ecosystem to form around a single CAD environment. That was a genuine structural advantage, and it still explains much of why the ecosystem remains strong today.

But files alone were never designed to carry the full weight of product knowledge across a distributed organization. A STEP file carries geometry. A PDF carries a drawing. A BOM spreadsheet carries a parts list at a point in time. What none of them carry reliably is the surrounding context — the decisions, the changes, the sourcing assumptions, the revision logic, the supplier conversations, and the downstream implications that together form the real knowledge around a product.

When that context is missing, teams compensate. They send emails to confirm versions. They maintain parallel spreadsheets. They add notes to shared drives. They ask the same questions repeatedly. The product knowledge exists, but it is scattered — living in inboxes, file names, meeting notes, and individual memory rather than in any connected place.

That is the real source of lost control. Not too many files. Disconnected product knowledge around those files.

What Needs to Change in Engineering and Manufacturing Workflows

The SolidWorks ecosystem is not going away. The foundation it built over thirty years is real, and the trust engineers place in it is earned. But the workflows that made sense when everyone sat in one office, worked on one Windows PC, and handed files down the hall are showing their age in a world of distributed teams, global supply chains, and products that combine mechanical, electrical, and software components across multiple disciplines.

The teams that feel this most acutely are not the ones with bad CAD skills or poor project management. They are often the most competent teams — the ones moving fast enough that the fragmentation of downstream data becomes the actual bottleneck. They are not losing control because they are doing something wrong. They are losing control because the tools and workflows around them were not designed for the environment they are operating in today.

The real problem is not that teams have too many files. The real problem is that the product knowledge around those files is disconnected.

That is what the next conversation needs to be about.

What OpenBOM Does About This

OpenBOM was built specifically for this problem. It connects directly to SolidWorks, captures BOM data and derivative files at the source, and keeps that information connected across engineering, procurement, suppliers, and operations — without replacing the tools and workflows your team already depends on. If you already have SolidWorks PDM, OpenBOM integrates with it directly, extending its reach into the downstream workflows where PDM coverage ends.

We are also bringing the latest thinking in AI and connected data directly into OpenBOM for SolidWorks teams — so that product knowledge becomes something a team can query, reuse, and build on rather than reconstruct from scratch every time. More on that in the coming weeks.

If the pattern described in this article sounds familiar, register for free and see how it works with your actual data. And stay tuned — the next article in this series goes deeper into what connected product knowledge looks like in practice.

Best, Oleg