Beyond the Mechanical BOM: Unified Product Data Management Across Hardware and Software

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

Why Mechanical PDM/PLM Is No Longer Enough

For many years, Product Data Management meant managing CAD files. The product was a mechanical assembly. Engineering teams organized folders, managed revisions, and released drawings. The assumption was simple: if you controlled the files, you controlled the product.

That assumption no longer holds.

Almost every product being designed today combines mechanical systems, electronics, embedded firmware, software services, and cloud connectivity. A drone, a medical device, an EV charging station, an industrial robot: none of these are mechanical assemblies with some electronics attached. They are systems where multiple engineering disciplines evolve concurrently, each with different tools, different release cadences, and different ownership models.

What makes this harder is that most PLM platforms did not fundamentally change this picture. They expanded on it. More complex workflows, added requirements, manufacturing and other modules, expanded the number of integrations, but the underlying architecture remained document-centric and rooted in the same mechanical assembly logic that PDM was built on back in the 1990s when I first started to work on SmarTeam. PLM inherited the file-centric foundation and built upward from there. For many organizations, moving from PDM to PLM meant gaining process capabilities and integrations without gaining a genuinely different approach to product data.

The challenge this creates is not primarily a tooling problem. It is a data architecture problem. When organizations try to stretch document-centric systems to manage the relationships between disciplines, distributed teams and communication between distributed teams, the cracks become visible quickly: disconnected BOMs, manual reconciliation, siloed changes, duplicated records across systems.

This article is about what managing product data actually requires when the product is multidisciplinary.

How Modern Products Combine Mechanical, Electrical, and Software Engineering

A modern product behaves more like a system than a mechanical assembly.

Mechanical engineers develop enclosures, mechanisms, and structural components. Electrical engineers manage PCB layouts, electronic components, and sourcing constraints. Software teams release firmware and cloud-connected applications independently from hardware changes. Manufacturing organizations transform engineering structures into manufacturing and procurement representations. Service organizations maintain yet another perspective focused on maintenance and operational support.

Each discipline uses different tools and works with different assumptions. MCAD systems manage geometry and assemblies. ECAD systems manage electronic design and PCB structures. Software teams manage repositories, packages, dependencies, and deployment pipelines. Manufacturing teams maintain MBOMs and routing structures. Procurement teams focus on sourcing and supplier relationships.

The result is not a single product structure, but multiple interconnected representations of the same product. This is where traditional document-centric PDM approaches begin to hit their limits.

Why PDM and PLM Struggle With Hardware and Software BOM Management

Traditional PDM was built around a set of assumptions that made sense for their time. The product has one primary engineering structure. That structure is driven by the MCAD assembly. Changes move sequentially through a defined release process. Each discipline owns its own domain and hands off to the next.

These assumptions worked reasonably well when products were mostly mechanical and release cycles were measured in months or years.

Modern products break every one of them.

Electronics evolve on a different schedule than mechanical structures. Firmware may change multiple times between hardware revisions. Software continues to evolve after the product ships. Manufacturing structures diverge from engineering structures from the moment production begins. Supply chain changes introduce alternates and substitutions throughout the lifecycle, not just at release.

The result is that the same product ends up represented in multiple places simultaneously: once in the MCAD system, again in an ECAD tool, again in ERP, and often again in spreadsheets maintained by procurement or manufacturing teams who cannot rely on what engineering produces. Each of these representations drifts from the others. Synchronization becomes a manual activity. Nobody has a complete picture of what the product actually is at any given moment.

The instinct is to solve this with integrations: connect the systems together and let data flow between them. That helps at the margins, but it does not address the deeper issue. The underlying data model is still document-centric and discipline-siloed. You are connecting systems that were not designed to share a common product definition. The integration moves data; it does not create a connected product model.

That distinction matters because it determines what you can build on top.

A Connected Product Data Model for Hardware and Software

The limitations of traditional PDM and PLM are not primarily about missing features. They are about the foundational assumption that a product can be adequately represented as a collection of files organized in a folder structure. Once you accept that assumption, everything built on top of it inherits the same constraints.

OpenBOM starts from a different assumption. A product is not a file collection. It is a network of connected data objects: items, relationships, properties, and structures that together represent what the product is, how it is built, and how it evolves over time. The platform is built around a flexible, graph-based data model designed to accommodate multiple engineering disciplines within a unified product structure without forcing them into a single rigid schema.

This matters because multidisciplinary products do not have one owner, one tool, one release cycle, or one representation. Mechanical, electronic, firmware, and software data each carry different schemas, different lifecycle states, and different team ownership. A data model that can only handle one of these naturally, and treats the others as attachments or integrations, is not a foundation for managing modern products. It is a workaround.

OpenBOM’s approach makes four specific capabilities possible that document-centric systems struggle to deliver. Discipline-specific catalogs and multi-disciplinary items allow different engineering domains to maintain their own data schemas while remaining connected inside a shared product structure. Multi-disciplinary BOM composition allows multiple synchronized product perspectives to coexist and evolve together. Collaborative change across disciplines allows concurrent work across mechanical, electronic, software, and manufacturing teams without locking each domain into isolated revision cycles. Dynamic views allow different teams to interact with the same underlying product data through representations tailored to their specific needs.

Each of these builds directly on the flexible data model. Together they define what an engineering platform for modern multidisciplinary products actually needs to do.

Managing Mechanical, Electrical, and Software Parts in One Product Structure

One of the first practical problems multidisciplinary product development creates is that different engineering domains need to track fundamentally different information about their components. A mechanical part is described by material, finish, weight, and manufacturing method. An electronic component carries footprint, manufacturer lifecycle status, approved alternates, and sourcing references. A software package is defined by version, dependencies, license type, and security vulnerability status. These are not variations of the same data. They are genuinely different schemas driven by different engineering realities.

Traditional PDM systems typically respond to this by either forcing everything into a single generic schema, which loses discipline-specific information, or by maintaining separate systems per discipline (MCAD PDM, PCB PDM, and so on), which breaks connectivity across the product.

OpenBOM addresses this through discipline-specific catalogs. Each engineering domain can define and maintain its own data schema, its own properties, its own classification logic, its own metadata, while remaining connected inside the broader product structure. Mechanical catalogs carry mechanical properties. Electronic catalogs carry component and sourcing intelligence. Software catalogs carry dependency and compliance attributes. The schemas are specialized; the product model connecting them is unified.

This becomes particularly important at the item level. A modern product item is rarely owned by a single discipline. A robotic controller assembly, for example, may simultaneously carry a mechanical enclosure definition, a PCB reference, a firmware package, purchasing constraints, and compliance documentation. In a document-centric system, these live in separate places and require manual reconciliation. In OpenBOM, a single item can hold connected definitions from multiple disciplines, becoming a shared product context rather than a file pointer owned by one team.

This is even more visible at the component level. A single electronic switch, for example, has two representations: one in MCAD and one in the PCB design. OpenBOM allows multi-disciplinary items to carry information from both disciplines simultaneously, and allows both sets of data to be updated concurrently through the collaborative change model described below.

That shift, from item as file reference to item as connected product context, is what makes genuine multidisciplinary collaboration possible at the data level.

How to Manage EBOM, ECAD BOM, and Software BOM Together

The idea that a product has one BOM is one of the most persistent and damaging assumptions in product data management.

It made sense when products were mechanical assemblies. The MCAD system produced a structure, that structure became the engineering BOM, and everything downstream, manufacturing, procurement, service, was derived from it through manual transformation. One primary structure, one source, one starting point.

Modern products do not work that way. A product that combines mechanical systems, electronics, firmware, and software does not have a single natural structure. It has multiple legitimate representations that coexist, each serving a different purpose and owned by a different team. The engineering BOM reflects design intent. The electronic BOM reflects the PCB assembly structure. The software BOM tracks packages, dependencies, and licenses. The manufacturing BOM reflects how the product is actually built, which frequently diverges from how it was designed. The procurement BOM reflects sourcing strategy and supplier relationships.

These are not the same structure viewed from different angles. They are genuinely different representations of the same product, each with its own logic, its own lifecycle, and its own ownership.

The traditional response to this is to pick one structure as the master and force everything else to reconcile against it. In practice this means manual exports, spreadsheet transformations, and constant drift between representations as each domain evolves independently.

OpenBOM’s approach is fundamentally different. Because the product model is built around connected data objects rather than a single file hierarchy, multiple BOM structures can be composed from the same underlying items and relationships. Mechanical, electronic, software, and system-level structures can coexist and evolve concurrently while maintaining traceability between them. Changes in one representation can be reflected across others without manual reconciliation.

This is what a flexible BOM means in practice: not a single mechanical BOM, but multiple synchronized product perspectives stitched together to create a multi-disciplinary digital BOM. One product, multiple representations, maintained together rather than reconciled after the fact.

Concurrent BOM Changes Across Mechanical, Electrical, and Software Teams

In traditional PDM and PLM, change is a document workflow. An engineer initiates a change order, attaches the affected files, performs a check-out, routes the change through an approval chain, then performs a check-in and releases a new revision. The process is sequential by design. Each discipline is handled independently, hands off to the next, and the change moves through the organization in a defined order.

That model reflects how mechanical products were developed. One primary discipline drove the design. Others responded to it. Sequential handoffs worked because the dependencies were mostly one-directional.

Multidisciplinary products break that assumption at the root.

When mechanical, electronic, firmware, and manufacturing changes happen concurrently, which in modern product development they almost always do, sequential revision workflows become bottlenecks. A mechanical change triggers an electronics layout update. The electronics update affects firmware interfaces. The firmware change has manufacturing implications. None of these wait for the previous one to complete a formal release cycle before the next begins. They happen in parallel, across teams that may be in different locations, working in different tools, on different schedules. If the system requires separate revisions for each change, the process becomes too slow. But attempting to combine everything into a single revision creates locking conflicts that make concurrent work impossible.

The result in document-centric systems is familiar: informal coordination through email and meetings, changes tracked in spreadsheets outside the system, revisions released prematurely to unblock downstream teams, and a change history that reflects the approval process rather than what actually happened to the product.

OpenBOM approaches change differently. OpenBOM provides collaborative workspaces where mechanical, electronic, software, procurement, and manufacturing data can evolve concurrently. A patented collaborative BOM editing mechanism allows multiple users to make changes simultaneously, similar to how Google Sheets enables concurrent editing but applied to structured BOM data. Each team works on its respective discipline within a shared product context. Changes are tracked at the data level as they happen and the full history is captured. Once the combined product state across all disciplines is validated, a coordinated revision captures the full multidisciplinary change as a coherent product event.

This means change becomes a collaborative data activity rather than a routed document workflow. The distinction is not cosmetic. It determines whether your change process reflects the reality of how modern products evolve, or forces that reality into a process model designed for a simpler time.

BOM Views for Engineering, Procurement, Manufacturing, and Service Teams

A connected multidisciplinary product model creates a new challenge. The same product now contains mechanical properties, electronic component data, firmware references, software packages, sourcing information, manufacturing constraints, and compliance attributes: all connected, all part of the same structure. That is exactly what you want from an architectural standpoint. But no single team needs to see all of it at once, and forcing every team to navigate the full product complexity to find what is relevant to them is its own form of friction.

Different teams need different representations of the same product data.

A mechanical engineer needs to see geometry, materials, and assembly relationships. A procurement team needs supplier references, approved alternates, and sourcing risk. A manufacturing team needs production-oriented structures with routing and work instruction context. A compliance team needs traceability, certification status, and regulatory attributes. A service organization needs a maintenance-oriented view that may look nothing like the engineering structure that produced it.

The traditional solution is to create separate structures for each audience: export a procurement BOM, maintain a separate manufacturing BOM, produce a service parts list. Each of these starts as a snapshot of engineering data and then diverges as it is manually maintained by a different team. Synchronization becomes a recurring problem. Changes in engineering do not automatically propagate. Each team ends up managing its own version of the product.

OpenBOM addresses this through dynamic views generated directly from the connected product model. Rather than duplicating structures for different audiences, the same underlying data is presented through views configured for specific roles, disciplines, or business processes. Engineering, procurement, manufacturing, service, and compliance teams each interact with product information through a representation tailored to their needs, without losing connectivity to the broader product structure and without creating independent copies that drift over time.

This is a direct consequence of building on a connected data model rather than a document hierarchy. When the product is represented as connected objects and relationships, views become a query over that structure rather than a manual export from it. The product stays coherent. The teams stay connected.

From EBOM to MBOM to SBOM: Connecting Engineering and Manufacturing with xBOM

The four capabilities described above, catalogs and multi-disciplinary items, BOM composition, collaborative change, and dynamic views, are built around engineering workflows. But the flexible data model that makes them possible does not stop at the engineering boundary. It extends naturally into manufacturing, procurement, supply chain, service, and compliance.

This is where BOM types become strategically important.

In traditional PDM and PLM, the engineering BOM is the primary structure and everything downstream is derived from it through manual transformation. Manufacturing teams take the EBOM and reconstruct it as an MBOM. Procurement teams extract component lists and manage them separately. Service organizations maintain their own parts structures. Each transformation is a manual activity, each derived structure drifts from the source, and the connections between them exist only in spreadsheets and institutional memory.

OpenBOM’s approach to BOM types changes this relationship. Because the product model is built around connected data objects rather than a file hierarchy, different BOM types, engineering, manufacturing, procurement, software, service, compliance, are not separate structures derived from a single master. They are connected representations of the same product, each composable from the shared data foundation with its own structure, its own lifecycle, and its own ownership.

A manufacturing BOM can be composed directly from engineering items with manufacturing-specific attributes added at the MBOM level. A software BOM can be generated from software catalog entries already connected to the product structure. A procurement BOM can reflect sourcing decisions and approved alternates without duplicating the underlying component definitions. A service BOM can present a maintenance-oriented view of the same product without requiring a separate manual structure.

This is what xBOM means at the lifecycle level. Not a single BOM that tries to serve every purpose, and not a collection of disconnected structures maintained by different teams in different systems. A family of connected product representations, each purpose-built for its audience, all traceable back to the same connected product model.

The practical consequence is significant. When engineering changes, the effect propagates through connected BOM types rather than requiring manual updates across separate systems. When a component is discontinued, the impact is visible across engineering, manufacturing, procurement, and service simultaneously. When a software dependency carries a security vulnerability, it surfaces in the SBOM and connects back to the affected product structures.

This is the foundation of a genuine digital thread: not a marketing concept, but a practical data architecture where product information flows continuously across disciplines and lifecycle stages without losing coherence or requiring constant manual reconciliation.

Conclusion: Rethinking Product Data Management for Hardware and Software Products

The shift toward multidisciplinary products is not a temporary trend. It is the direction every product category is moving. Mechanical-only design is increasingly the exception rather than the rule.

What this means for product data management is that the foundational question is no longer “how do we manage our CAD files better?” It is “how do we create a connected product model that reflects the actual complexity of what we build?”

That requires moving away from document-centric architectures toward data models built around flexible object relationships, discipline-specific but connected structures, concurrent collaborative change, and multiple synchronized product representations. Not one BOM. Not one release process. Not one system of record that everything else is forced to reconcile against. A product model that reflects how modern products actually work.

OpenBOM’s approach to multidisciplinary data management is built on that foundation. The goal is not to replace every tool an engineering organization uses. It is to create the connected product layer that makes all of those tools part of a coherent product system, across mechanical, electronic, software, manufacturing, and supply chain domains, and across the full product lifecycle.

REGISTER FOR FREE to check how OpenBOM can help. 

Best, Oleg