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
4 June, 2026

Modern product development no longer happens inside a single company, a single department, or a single system. Products are designed,...

3 June, 2026

Martin Eigner recently shared a reflection that stayed with me. In a LinkedIn post about engineering in the 1970s and...

2 June, 2026

The five hard problems engineering and manufacturing teams face in 2026, and what it actually takes to solve them. Engineering...

1 June, 2026

Why the PLM data problem is really a workflow problem and why review, validation, and context must become the new...

29 May, 2026

Sheet metal design has a manufacturing reality that solid parts do not. The 3D model is only the beginning. Before...

27 May, 2026

A practical guide to working folders, Smart Sync, design structure, locking, revisions, and conversational commands inside SOLIDWORKS Introduction: Why PDM...

26 May, 2026

Last week I was at the Share PLM Summit. AI was everywhere: in the keynotes, in the vendor demos, in...

25 May, 2026

Companies struggle to get real business value from AI in engineering and manufacturing not because the technology is weak, but...

22 May, 2026

Here is the problem most PLM and other product data tools ignore Most engineering and manufacturing companies already know they...

To the top