Managing File Chaos and BOM Complexity: OpenBOM Lessons from SolidWorks Users

Data is everything in today’s digital world. While every manufacturing company thinks differently about their products and strategy, the common ground for staying competitive in the 2020s is finding a way to turn data into successful products and services.

After working with thousands of engineers, we’ve gathered a valuable set of good and bad practices around how engineers use their tools before they come to OpenBOM. Earlier today, I sat down with OpenBOM’s VP of Product, Steve Hess, to discuss the top lessons we’ve learned from customers about data usage.

If you ask a typical engineering team whether they can generate an accurate Bill of Materials (BOM) from their SolidWorks design data, the answer is usually “yes.” But after a few minutes of digging—looking at folders, talking to designers, and reviewing the models—we usually discover a different story.

At OpenBOM, we work closely with engineering and manufacturing teams every day to bring clarity and automation to their product data. SolidWorks users are a large portion of our customer base, and their challenges often look remarkably similar. The common thread? Dirty data.

The truth is, BOM creation doesn’t start with clicking “Export.” It starts with consistent, structured, and collaborative design practices—and that’s where many teams fall short. 

In this article, we share three key lessons we’ve learned from working with SolidWorks customers, and five persistent challenges that make accurate BOM creation harder than it should be.

Three Lessons Learned from SolidWorks Users

1. Multiple File Copies Are the Silent Killer

One of the most damaging—but common—practices we encounter is the use of Pack-and-Go or ad-hoc duplication to manage design files. While this feels safe and practical at the moment (“I’ll just copy this project folder to make a new version”), it quickly creates a minefield of problems.

We’ve seen customers maintain 5, 10, or even 20 copies of a single assembly across various folders, USB drives, or cloud sync tools. As each one diverges with minor tweaks, no one knows which version is correct. Is the file in Project-Final the same as Project-Final-Final2? Who made the last change? Which part is ready for procurement?

This duplication fragments the data, causes errors in BOM roll-ups, and introduces significant risk in production. It also kills any chance of reusing parts efficiently.

2. File Names Are Not Part Numbers

Another pattern we consistently encounter is the misuse of file names as de facto part numbers. In the absence of a company-wide part numbering system, engineers improvise—sometimes naming parts based on functionality (gearbox_v2.SLDPRT), sometimes based on project (projectX_bracket_final.SLDPRT), and sometimes based on mood.

This informal system breaks down the moment teams try to automate anything—be it BOM generation, procurement planning, or inventory tracking. Worse, engineers often revise files by renaming them, rather than using revision control, creating more confusion.

A proper part number is a reference to a unique design intent—not a filename that changes on a whim.

3. Design is Not Collaborative

Despite all the hype around cloud tools and modern collaboration, most SolidWorks teams still operate in silos. One designer works on a file, saves it locally or to a shared drive, and emails (or pack-n-go) a colleague when they’re done. Collaboration, if it exists, is sequential and fragile.

In more advanced teams, a basic PDM system (eg. SolidWorks PDM) helps to manage check-in/check-out, but often without integration to BOM processes or downstream systems like ERP or procurement. Designers are hesitant to overwrite each other’s work, so they make copies. Communication gaps lead to duplicate parts, missed updates, and BOMs that are out of sync with actual design intent.

We believe design should be real-time and collaborative—more like Google Docs, less like passing a USB stick back and forth.

Five Things That Prevent Accurate BOM Creation

Even when teams want to generate accurate BOMs from their designs, a handful of structural problems get in the way. Here are the five most common blockers we’ve seen.

1. Complex Configurations That Confuse Everything

SolidWorks configurations are a powerful feature—but they’re also one of the biggest sources of BOM confusion. A single file can contain multiple configurations for size, material, mounting options, and more. However, unless strict naming and documentation standards are enforced, no one knows which configuration is intended for manufacturing.

We’ve seen BOMs generated from the wrong configuration, leading to incorrect materials, missing parts, and failed assemblies on the shop floor. A multi-configuration model might save modeling time, but it requires discipline and clarity in how it’s used.

2. Lack of Company-Wide Part Numbering Standards

Without a standard part numbering system, engineering teams make up their own rules—and those rules rarely align. Some numbers come from CAD file names. Others are copied from old projects. Others are “temporary” and never replaced.

When we onboard customers to OpenBOM, part number inconsistencies are often the first and most painful cleanup step. You can’t roll up costs, analyze inventory, or order parts efficiently if the same component appears with three different identifiers in your BOM.

A standard part numbering system doesn’t just make life easier—it’s a prerequisite for scaling.

3. Copies of Commercial Parts Everywhere

Another headache? Commercial off-the-shelf (COTS) components like bearings, fasteners, and motors are downloaded from vendor sites (eg. Granger, McMaster, etc) or copied from old projects—again and again and again.

We often find the same part in multiple folders with slight variations: different names, different metadata, sometimes even different geometry. This makes it impossible to standardize purchases, manage inventory, or get a clean roll-up in the BOM.

A single source of truth for COTS components—stored in a shared catalog—is essential to any BOM automation effort.

4. External References Create a Spiderweb of Dependencies

External references (or “in-context” design) are another feature that’s often overused. While referencing geometry across parts can be useful during design, it creates a tangled web of file dependencies that’s fragile and nearly impossible to manage at scale.

We’ve seen changes to one file silently break another. We’ve seen entire assemblies collapse because a referenced file was renamed or moved. Extracting a clean BOM structure from these assemblies is challenging and prone to error.

For BOM purposes, each part and assembly should ideally be self-contained and structured with clear, well-defined relationships.

5. Misuse of Purchased Assemblies

Lastly, many SolidWorks users include full purchased assemblies in their design—sometimes imported from STEP files or vendor models. But instead of treating them as black-box items, they inadvertently pull all internal components into the BOM.

The result? An over-detailed BOM full of irrelevant internal parts (screws, washers, PCBs) that the team will never manufacture or buy individually. This leads to confusion in procurement, cluttered documentation, and inflated part counts.

A good rule of thumb: If you’re not manufacturing it, it shouldn’t explode in the BOM.

The Real Problem: Dirty Data, Underestimated Effort

The pattern is clear: files and BOM errors aren’t caused by bad tools—they’re caused by bad data practices.

And here’s the hard truth: most companies vastly underestimate how long it takes to clean up their data. They bring OpenBOM in and use “One-click-BOM” functionality, which is amazing by their simplicity, but the old rule (garbage-in, garbage-out rule) kicks up. 

Cleaning up files, fixing part numbers, consolidating COTS components, and standardizing configuration usage is not a one-hour job. It’s a project. Sometimes it takes weeks. Sometimes it takes longer. But it’s always worth it.

The longer a company waits to clean their data, the harder it becomes to fix. And the more risk they introduce into their BOMs, procurement processes, and production plans.

Conclusion: A Path Forward

At OpenBOM, we’re not just building software—we’re helping companies fix the foundation. We help SolidWorks users:

• Establish clean catalogs for items and COTS parts
• Standardize part numbers across their organization
• Automatically generate structured, revision-controlled BOMs
• Connect design, procurement, and planning through a unified platform

If you’re struggling with messy SolidWorks data and unreliable BOMs, you’re not alone. But with the right tools—and the willingness to tackle the data cleanup—you can build a system that works for design, manufacturing, and everyone in between.

Let us know if you want to talk.

REGISTER FOR FREE and check OpenBOM today. 

Best, Oleg