A few months ago, I ordered an electric kettle, and to my surprise, it came with a Wi-Fi card and an iPhone app. Why? Probably because someone thought it would be a good idea to know the temperature of the water before it finished boiling. I found it unnecessary and returned the kettle. But you get the point – complexity is everywhere.
Product development is changing rapidly. Products that used to be purely mechanical are now combinations of mechanical assemblies, electronics, embedded software, and connected systems. Even relatively simple devices today include electronics, firmware, and cloud connectivity. As a result, the way product data is organized must evolve.
The traditional approach — where mechanical BOMs, electrical BOMs, and software artifacts live in separate systems — no longer works well. Engineering teams spend increasing amounts of time reconciling spreadsheets, aligning revisions, and manually translating information between disciplines. The complexity is not only technical; it is organizational. Different tools, different teams, and different workflows all need to converge into a single product definition.
This is where the concept of a Digital BOM becomes essential.
A Digital BOM is not just a list of parts. It is a connected product structure that consolidates information coming from multiple engineering disciplines and keeps it synchronized as the product evolves.
In this article, I want to explain how OpenBOM approaches this problem and demonstrate how mechanical, electronic, and software data can be brought together into a single, connected product structure.
Product Complexity Requires a New Foundation
The increase in product complexity is not slowing down. Mechanical engineers work in MCAD systems, electrical engineers define components and assemblies in ECAD tools, and software teams manage firmware and releases in completely different environments. Each discipline generates its own structure, naming conventions, and lifecycle.
Historically, companies tried to solve this problem by forcing everything into a single system. In practice, this approach created friction. Engineering teams prefer to work in specialized tools optimized for their domain.
Instead of replacing those tools, OpenBOM focuses on connecting them.
The foundation of this approach is a flexible BOM structure capable of representing product information independently from where it was created. The BOM becomes the neutral layer where product definition is consolidated. Mechanical assemblies, electronic components, and software artifacts can coexist within the same structure while preserving their original context.
This flexibility is critical because no two companies organize product data in exactly the same way. Some structures originate from MCAD, others from ECAD, and increasingly software becomes a first-class component of the product definition.
Flexible BOM Structure as the Foundation
At the core of OpenBOM is a flexible data model that allows product structures to evolve naturally as information arrives from different sources.
Instead of forcing a rigid hierarchy, OpenBOM allows assemblies, subassemblies, electronic components, and software items to be organized in ways that reflect how products are actually built and delivered. Mechanical parts, PCB assemblies, firmware versions, and documentation can all be connected within the same Digital BOM.
This structure becomes the foundation for collaboration between disciplines. Mechanical changes can be reflected alongside electronic revisions. Software releases can be linked to specific hardware configurations. The result is a single product definition that remains consistent across engineering and downstream processes.
The important idea here is that the BOM is not owned by a single discipline anymore. It becomes a shared product model.
Multiple Integrations That Bring Data Together
A Digital BOM only works if data flows into it naturally. Manual data transfer is exactly what engineering teams are trying to avoid.
OpenBOM integrates with a wide range of CAD systems and engineering tools through connectors that automatically extract product structure information. These integrations allow engineering teams to continue working in their preferred environments while OpenBOM collects and organizes the resulting data.
Mechanical assemblies from SolidWorks, cloud-native designs from Onshape, and electronic structures from Altium can all contribute to the same product structure. As data is synchronized, components and assemblies automatically align based on part numbers, references, and relationships.
From the user’s perspective, the data simply “clicks” together.
This approach removes the need for manual consolidation and significantly reduces errors caused by re-entering or translating information between systems.
Desktop and Cloud Connections Working Together
One of the common misconceptions in product data management is that everything must be either desktop or cloud-based. In reality, modern engineering environments are mixed.
Some teams use desktop CAD tools. Others use cloud-native systems. Electronics design and software development often follow entirely different infrastructure models.
OpenBOM operates across both worlds seamlessly. It does not matter where the data originates. Desktop applications can synchronize product structures just as easily as cloud systems. The BOM structure is collected, normalized, and stored in the cloud where it becomes accessible to the entire team.
As part of this process, OpenBOM can automatically generate derivative files and upload them to the workspace, ensuring that drawings, PDFs, and supporting documentation remain connected to the product definition.
The result is a unified product structure without forcing teams to change how they work.
Demo: SolidWorks, Onshape, and Altium Integration
The following video demonstrates how OpenBOM connects multiple disciplines into a single Digital BOM.
In this example, mechanical data is coming from SolidWorks, cloud-based design from Onshape, and electronic components from Altium. Each system contributes its portion of the product structure, and OpenBOM consolidates them into a single connected model.
The key takeaway from this demonstration is not the individual integrations themselves, but how naturally the structures combine. The BOM becomes the central reference point for the product, regardless of where the data originates.
Conclusion: Integration Becomes Critical as Products Evolve
As products become more complex, managing data across disciplines becomes one of the most important challenges engineering organizations face. Mechanical, electrical, and software teams cannot operate in isolation if the goal is to deliver reliable and scalable products.
The ability to integrate information from multiple sources into a single Digital BOM is no longer optional. It is becoming a requirement for companies building modern products.
OpenBOM approaches this challenge by providing a flexible BOM foundation combined with seamless integrations across CAD systems and data sources. Instead of forcing change onto engineering teams, it allows existing tools to remain in place while connecting their outputs into a unified product definition.
When product complexity grows, integration across disciplines becomes the key to maintaining control. The Digital BOM is where that integration finally comes together.
REGISTER FOR FREE to check how OpenBOM can help you.
Best, Oleg
Join our newsletter to receive a weekly portion of news, articles, and tips about OpenBOM and our community.
