SOLIDWORKS PDM Meets Digital BOM: Exploring an OpenBOM Prototype

For more than two decades, SolidWorks has built one of the most remarkable ecosystems in engineering software.

Starting in the late 1990s, SolidWorks rode the Windows revolution and created a massive community of mechanical engineers, manufacturing companies, solution partners, and software developers. Thousands of companies adopted SolidWorks as their primary design tool, and over time an entire industry grew around it—resellers, consultants, simulation tools, CAM software, and data management systems.

Last month I attended 3DEXPERIENCE World 2026 in Houston, TX, and you could feel this ecosystem in action. The community is amazing and the energy is powerful. It has been shaping mechanical engineering for an entire generation.

What I found particularly interesting this year was how processes inside this ecosystem are evolving. I wrote about it in my Beyond PLM article: 3DEXPERIENCE World 2026: Where Is the New Center of Gravity for the SolidWorks Ecosystem?

The foundation of this success is what I often call the Windows and desktop DNA of engineering. For decades, engineering work has been organized around local applications, folders, and files. Engineers understand this model intuitively, companies built processes around it, and suppliers and partners exchange data through it. Entire organizations operate on the assumption that files represent the product.

But something interesting is happening inside many of the companies that built their engineering processes around SolidWorks. The products they design are becoming significantly more complex. Mechanical engineering is still the core discipline, but it is no longer the whole story. Modern products combine mechanical components with electronics, embedded software, sensors, firmware, and connected services.

At the same time, engineering decisions increasingly intersect with procurement, supply chains, and manufacturing planning. The moment a design is completed, the conversation quickly moves beyond CAD files.

This creates an interesting challenge for many organizations in the SolidWorks ecosystem.

SolidWorks—and SolidWorks PDM—do an excellent job managing design files, revisions, and engineering workflows. But once companies begin thinking about product structures, multi-disciplinary BOMs, procurement planning, or ERP integration, the workflow often moves outside the design environment.

During the conference, I spoke with several customers, SolidWorks resellers, and technology partners, and we kept coming back to the same question:

How can engineering data managed in SolidWorks PDM naturally connect to the broader product lifecycle?

That conversation eventually led to a small experiment.

From Conversation to Prototype

After returning from Houston, we decided to explore an idea that emerged during those discussions.

What if SolidWorks PDM continued to manage engineering files and revisions exactly as it does today, while another system automatically captured the product structure and BOM information around those designs?

In other words:

• SolidWorks PDM remains responsible for design file management.
• Another system organizes product data, BOM structures, and operational workflows.

This is precisely the type of problem OpenBOM was designed to solve.

OpenBOM provides a cloud platform that captures product information around engineering designs and organizes it into structured BOMs that can support procurement planning, manufacturing preparation, and ERP integrations.

So we asked a simple question.

What if SolidWorks PDM and OpenBOM could work together automatically?

Working together with several partners in the SolidWorks ecosystem, we built a prototype integration between SolidWorks PDM and OpenBOM.

This is not a finished product announcement. Think of it as a visual exploration of how such a solution could work.

The goal was to allow engineering teams to continue working exactly as they do today, while automatically building a digital product structure around their designs.

Why PDM Is Not the Same as BOM Management

During many of the discussions in Houston, another topic surfaced repeatedly.

Many companies assume that if they have PDM, they automatically have BOM management solved.

At first glance this assumption seems reasonable. PDM systems can extract assembly structures from CAD models, present them as tables, and generate BOM reports. From an engineering perspective that certainly looks like a BOM.

But in reality PDM and BOM management solve two very different problems.

PDM systems focus primarily on file and revision management. Their main responsibility is to control engineering documents such as CAD models, assemblies, drawings, and related files. They ensure that engineers work with the correct versions and that design changes are tracked through workflows.

A product BOM, however, is not just a list extracted from a CAD assembly.

In modern manufacturing environments it becomes something much broader — a product data structure used across multiple functions in the organization.

A real BOM needs to support processes such as:

• procurement planning
• supplier selection
• cost analysis
• manufacturing preparation
• service and maintenance
• ERP integration

These processes extend well beyond engineering document control.

Another complication is that modern products rarely consist of mechanical parts alone. Products often include electronics, electrical systems, purchased components, firmware, and software elements that never appear in CAD assemblies at all.

This is why many organizations eventually discover that the engineering BOM extracted from CAD is only the starting point, not the final product definition.

Instead of forcing a single system to handle everything, a more natural approach is to allow each environment to focus on what it does best:

• PDM manages design files and engineering workflows
• BOM systems manage product data structures used across the organization

The prototype integration between SolidWorks PDM and OpenBOM explores exactly this idea.

The Spreadsheet Gap Between Engineering and ERP

Another pattern we frequently see in manufacturing organizations is what I often call the spreadsheet gap.

Engineering systems such as CAD and PDM manage design data. ERP systems manage procurement, inventory, and manufacturing processes. But the information connecting these two worlds often lives in spreadsheets.

The workflow typically looks something like this:

Engineering completes a design in CAD and stores the files in PDM. Then someone exports a BOM into Excel. That spreadsheet is cleaned up, adjusted, and eventually entered into the ERP system.

This process may work, but it introduces several challenges.

First, it is manual and time consuming.

Second, it creates multiple versions of the same information.

And third, it makes it difficult to keep engineering and operations synchronized when designs change.

The goal of connecting SolidWorks PDM with OpenBOM is to remove this gap and replace it with a structured digital product model.

The Architecture Concept

The prototype integration follows a simple architectural idea.

Engineering tools continue to manage design files, while OpenBOM captures the product data structure that surrounds those designs.

The architecture looks like this:

SolidWorks CAD → SolidWorks PDM → OpenBOM → ERP Systems

Each system plays a specific role.

• SolidWorks CAD creates the engineering design.
• SolidWorks PDM manages files, revisions, and workflows.
• OpenBOM organizes product structures and BOM data.
• ERP systems manage procurement and manufacturing operations.

This layered architecture allows each system to focus on its strengths while still enabling a continuous flow of product information.

Three Elements of the Prototype

To visualize this idea we built a prototype consisting of three key elements.

1. Embedded OpenBOM User Interface

The first component is an embedded OpenBOM user interface that allows users to access product structures and BOM information connected to the SolidWorks environment.

This interface provides visibility into:

• product structures
• BOM relationships
• component metadata
• product information stored in OpenBOM

Instead of forcing users to jump between multiple systems, the embedded interface allows them to interact with product information directly within the engineering workflow.

2. SolidWorks PDM Data Card for BOM Information

The second element of the prototype leverages the SolidWorks PDM data card.

Data cards are a familiar part of the PDM environment and are commonly used to present metadata about files and assemblies. In the prototype we extended this concept to present BOM information captured from the design.

This allows engineers and PDM users to see structured product information directly within the environment they already use.

Instead of exporting BOMs into spreadsheets, the information can be displayed and managed through the integrated system.

3. Workflow-Driven Data Synchronization

The third component focuses on automation.

SolidWorks PDM includes powerful workflows that control how designs move through different lifecycle stages such as development, review, approval, and release.

In the prototype these workflows trigger automatic synchronization events.

For example, when a design reaches a specific state such as Released, the system can capture relevant information and synchronize it with OpenBOM cloud services.

The captured information may include:

• assembly structures
• part metadata
• drawings and derivative files
• PDFs and documentation

Once synchronized, this information becomes part of a structured digital BOM.

From Engineering BOM to Digital Product Model

Once the data reaches OpenBOM, it becomes part of a digital product model.

Unlike a static BOM document, this model represents the product as a structured dataset that can support multiple activities across the organization.

These activities may include:

• product analysis
• procurement planning
• cost estimation
• supply chain collaboration
• manufacturing preparation

In other words, the BOM becomes a living dataset rather than a document stored in a spreadsheet.

Multi-Disciplinary Product Structures

Another important capability enabled by this approach is the management of multi-disciplinary product structures.

Modern products frequently combine multiple engineering domains.

A typical product may include:

• mechanical components
• electrical systems
• electronic boards
• embedded software
• firmware and configuration elements

OpenBOM allows these components to coexist within a single flexible product structure.

Different teams can then view the same product from different perspectives, such as:

• engineering BOM
• manufacturing BOM
• procurement BOM
• service BOM

Each of these views represents a different stage of the product lifecycle while still referencing the same underlying product data.

Connecting Engineering to ERP

One of the most common questions engineering teams ask is how to connect design data with ERP systems.

Many organizations still rely on manual processes to transfer BOM information from engineering to ERP environments.

Typical workflows involve exporting spreadsheets, manually entering part numbers, and recreating BOM structures inside ERP systems.

The OpenBOM platform provides ERP integrations and APIs that allow product information to flow directly into operational systems.

Once the digital product structure is captured, it can support activities such as:

• procurement planning
• supplier collaboration
• inventory preparation
• manufacturing execution

This creates a much more continuous flow of information between engineering and operations.

A Small Prototype, But an Interesting Direction

It is important to emphasize that what we built so far is only a prototype.

The goal is not to announce a finished product, but to explore how such a solution might work and gather feedback from the community.

Sometimes the most interesting innovations start exactly this way — with a conversation at an industry event, followed by a quick experiment that visualizes the idea.

The feedback we received so far from customers and partners suggests that this concept resonates with many engineering teams.

Companies are looking for ways to extend their engineering systems into broader product lifecycle workflows, without disrupting the tools engineers rely on every day.

Prototype Demonstration

To make the concept easier to understand, we recorded a short prototype demonstration video showing how the integration could work in practice.

Seeing the workflow in action makes it much easier to imagine how engineering data captured in SolidWorks PDM could automatically become part of a digital BOM environment managed by OpenBOM.

Conclusion and What Do You Think?

I’m always curious to hear feedback from engineers, PDM administrators, and manufacturing teams.

If you are using SolidWorks PDM, does this approach resonate with the way your organization manages product data?

Would connecting engineering data with a digital BOM environment help simplify your workflows?

Conversations like the ones we had in Houston often become the starting point for the next generation of tools.

And sometimes a simple idea, connecting two systems that already exist, can open the door to a much more connected product data environment.

If you are interested in learning more or discussing the prototype further, feel free to reach out.

Please contact OpenBOM support – we would be happy to discuss this solution with you. 

Best, Oleg