When Software Meets the BOM

Oleg Shilovitsky
Oleg Shilovitsky
25 February, 2026 | 2 min for reading
When Software Meets the BOM

For a long time, managing products meant managing mechanical structures.

Assemblies, subassemblies, parts, revisions — the Bill of Materials was designed around physical things. Electronics eventually found their place in that structure as well. Boards, components, firmware — they could be anchored to hardware.

But software changed the equation.

Software doesn’t behave like a physical part. It versions independently. It evolves continuously. It may update long after the product ships. It connects to hardware, but it is not constrained by hardware hierarchies. And that creates tension.

Many organizations still manage software outside the product structure, or reduce it to a simple line item in a BOM. Neither approach truly reflects how modern products are built — especially in robotics, smart devices, industrial equipment, and embedded systems where code defines behavior.

At OpenBOM, we’ve been working on a practical way to bring mechanical, electronics, and software elements together in one connected product structure. Not by forcing software into a rigid hierarchy, but by supporting relationships that reflect real engineering workflows.

If this challenge sounds familiar, I invite you to join our upcoming live session:

When Software Meets the BOM: Managing Mechanical, Electronics & Code Together (Live Demo)

We’ll walk through a practical demonstration of how these three domains can coexist inside a digital BOM and how changes across hardware and software can stay aligned.

Modern products are multidisciplinary by nature. The systems we use to manage them should reflect that reality.

Join us and let’s discuss how to make it work.

👉 March 4, 2026 at 11am EST (Eastern US time)  

Register here: https://my.demio.com/ref/qAJtEu8A7ok8qAow 

Why join?

Software in BOMs is no longer a theoretical problem.


If your product includes firmware, embedded code, or software-driven functionality, the way you structure your BOM will either support alignment — or create friction between teams.

This session is an opportunity to step back and look at how modern product structures can reflect the reality of multidisciplinary engineering. You’ll see practical examples, not slides. And you’ll have a chance to ask questions and discuss how others are approaching the same challenge.

Modern products are multidisciplinary by nature. The systems we use to manage them should reflect that reality.

Best, Oleg

Related Posts

Also on OpenBOM

4 6
20 May, 2026

Why disconnected BOM and product data holds AI agents back — and how to fix it AI agents in engineering...

19 May, 2026

For years, BOM review was often treated as a procedural step between engineering and release. Teams created bills of materials,...

18 May, 2026

I’m heading to SharePLM Summit 2026 in Jerez de la Frontera, Spain. This is a new conference in my calendar,...

15 May, 2026

Many manufacturing companies using SOLIDWORKS as a mechanical design CAD system start with a relatively simple engineering process. A few...

14 May, 2026

For almost three decades, most PDM and PLM systems followed the same architectural assumptions. A product was represented as a...

13 May, 2026

How modern products require connected data models that combine mechanical, electronic, software, and manufacturing information across the lifecycle. Why Mechanical...

11 May, 2026

Twenty years ago, designing a product mostly meant mechanical design. A mechanical assembly captured most of what needed to be...

8 May, 2026

Earlier this week, I previewed CAD File Agent for SOLIDWORKS. If you missed that, check these two articles: Why did...

7 May, 2026

A new kind of experience for engineers who never wanted a PDM system in the first place We Started with...

To the top