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
6 August, 2026

I had a conversation with Rob Ferrone earlier this week and we decided to publish it. Rob spent 25 years...

5 August, 2026

Every company that validates a bill of materials produces two things. The first is the corrected BOM. Missing quantities filled...

4 August, 2026

The most dangerous request in a PLM implementation is not “can we import our Excel files?” Of course you can....

1 August, 2026

Over the last three days I have looked at BOM Review from three angles. I explained that a BOM review...

30 July, 2026

What makes a BOM “good”? Is there such a thing at all?  The traditional perspective of any PLM or even...

29 July, 2026

A few months ago I spent time experimenting with an open source agent environment OpenClaw – a free and open-source...

28 July, 2026

Since we first introduced OpenBOM BOM Review in July, I have been asking engineering managers a simple question: how many...

25 July, 2026

We keep improving OpenBOM, and not every improvement is a new feature inside the product. Here is one that lives...

23 July, 2026

Everyone Is Asking for the API. Almost Nobody Is Asking the Right Question. Over the last few months we noticed...

To the top