One Product, Many BOMs: Modeling Multi-View Structures with OpenBOM xBOM

Recently, my attention was caught by an article from Rob Ferrone explaining the complexity of a BOM. In a nutshell, he tells a simple story: one car seat, represented by many different BOMs, each exposing a different dimension of complexity. What I particularly like about his visuals is how clearly they illustrate the relationships between different elements of product data and how those elements interact across views.

Rob’s post inspired us to demonstrate some of the capabilities of OpenBOM data management — but from a slightly different perspective. Enterprise PLM systems in the wild can potentially address some of the data management aspects presented in his visuals. In many companies, multiple systems such as ERP, PLM, and MES collectively attempt to cover these use cases. However, as I learned from Rob’s comments, despite the existence of all these systems, he often found himself playing the role of “CEO” (Chief Excel Officer) managing the complexity manually in Excel.

This is exactly the gap that caught my attention. The problem is not necessarily the absence of systems. It is the absence of a coherent data layer that can organize and connect information across those systems. OpenBOM is not designed to replace ERP, PLM, or MES. Instead, it provides a product data service capable of managing and connecting structured information in a way that makes it usable across disciplines. It helps organize catalogs, relate multiple BOM views, connect silos, collect history, and gradually build what I call product memory — a persistent, structured knowledge base about the product.

When product data is organized this way, it stops being just a static record. It becomes a foundation for reasoning, automation, and ultimately agentic workflows that can operate on top of that memory. That is the perspective I would like to explore in this article.

How to capture product data?

Imagine a six-axis robotic arm standing on a factory floor. It welds automotive frames, assembles electronics, packages consumer goods, or handles pallets in a warehouse. From the outside, it feels like one product. One machine. One thing you can point to and say, “This is the robot.”

But if you step inside the company that designs, builds, sources, assembles, and services that robot, the idea of “one product” quickly begins to dissolve.

I’ve had many conversations with manufacturing companies building complex industrial equipment — robots, CNC machines, packaging lines, medical devices, aerospace assemblies. What always emerges in those conversations is the same pattern: there are many islands of data that represent a product across the organization and it is inherently multi-dimensional.

Let me speak in this article about industrial robots. We have many customers developing robots and to manage their planning, engineering, procurement, maintenance, integrating with ERP and other systems is the reality. 

Similar to how you see it in Rob’s pictures, the “robot” that engineering sees is not exactly the “robot” that manufacturing sees. It is not the same “robot” that purchasing negotiates. It is not the same “robot” that service supports in the field. And it might not be the same “robot” that prototype teams build for validation.

When you begin mapping these perspectives, you realize that what we casually call “the BOM” is actually a family of related but structurally different views.

There is the product definition view, where the robot is offered in multiple variants: standard reach, extended reach, high payload, collaborative version, region-specific configurations. In that view, the BOM expresses options, constraints, and configuration logic.

There is the engineering view, where the robot is decomposed into structural frames, axis assemblies, servo motors, harmonic drives, gearboxes, electrical cabinets, controllers, safety modules, and embedded software. Here, the structure reflects design intent and subsystem organization.

There is the supplier view, where the robot expands into hundreds of sourced components — castings from one supplier, precision gears from another, electronics sourced globally, standard hardware shared across multiple product families.

There is the purchasing view, where the robot is reorganized by commercial logic: strategic components, standard parts, tooling, prototype builds, amortized development investments, regional sourcing categories.

There is the prototype view, where serial-number-specific builds contain deviations from production intent, experimental components, validation instrumentation, or temporary substitutions.

There is the production view, where the robot is structured differently across assembly plants, each with its own flow, sequencing logic, and sometimes localized components.

There is the service view, where the robot becomes a set of field-replaceable units, maintenance kits, upgrade modules, and spare parts packages.

Now, if you pause and ask a simple question: “Which one is the BOM?” The answer to this question can be uncomfortable. The robot does not have one BOM. It has many.

The real problem in most organizations is not that there are many views. The problem is to organize a single informational model and not as disconnected artifacts (which in many ways is how it is managed either by many Excel spreadsheets and/or different systems. It create friction. Either we oversimplify the product model and lose clarity, or we fragment it and lose coherence.

In OpenBOM, the xBOM service is designed around a different architectural assumption. Instead of asking which view is “the real one,” we assume that all legitimate views are real — and we focus on modeling them in a way that keeps them connected.

To do that, we rely on three foundational elements: shared catalogs of items, multiple BOM types as structured perspectives, and flexible object relationships that go beyond hierarchy.

Let’s unpack what that means in the context of our robot.

Identity Before Structure: The Role of Catalogs

Whenever I discuss multi-view BOM modeling, I begin with identity rather than structure.

In many traditional systems and/or spreadsheets, structure comes first. You create an assembly, then you populate it with parts. But if you want to manage multiple views consistently, you need to define objects independently of how they are arranged.

In OpenBOM, this is done through catalogs.

A catalog is not simply a repository of parts. It is the authoritative definition of items — each with a part number and a flexible set of properties. And part numbers, in this context, are not limited to traditional engineering drawing numbers. They can represent anything that your organization considers a managed object.

For an industrial robot, the catalog may contain structural components such as the base casting or arm segments. It will contain servo motors, gearboxes, bearings, and harmonic drives. It will include control boards, wiring harnesses, safety interlocks, and firmware modules. It may also contain tooling assets, service kits, serial-number-specific configurations, and plant-specific variants.Each of these items exists once in the catalog. We might have many catalogs. 

That single sentence carries enormous architectural weight. When the Axis 3 servo motor is defined in the catalog, it becomes a shared object. Engineering, manufacturing, purchasing, and service do not redefine it independently. They reference it.

Without this shared identity foundation, every department inevitably creates its own representation. Over time, those representations drift. The purchasing spreadsheet refers to a slightly different naming convention than engineering. Service documentation references a different revision assumption. Manufacturing tracks a variant that never quite aligns with the design intent.

When items are centrally managed in catalogs, identity is stabilized. Every BOM view becomes a structured perspective of the same underlying objects rather than an independent interpretation of reality.

This is the first pillar of multi-view modeling: one object foundation.

Structured Perspectives: Multiple BOM Types

Once identity is stable, structure becomes meaningful.

Traditional thinking often assumes there is one primary structure — usually the Engineering BOM — and that all other views must be derived from it. But in practice, different disciplines organize the same robot differently because they are solving different problems.

In the Engineering BOM, the robot may be structured by sub-system. You might see groupings such as base structure, axis assemblies, drive systems, electrical cabinet, control system, and safety architecture. This structure reflects functional decomposition and design logic.

In the Manufacturing BOM, the same robot may be organized by assembly sequence. The hierarchy may reflect how the base is assembled, how arm segments are integrated, when motors are installed, when cabling is routed, and how final calibration is performed. The logic here is operational rather than functional.

In the Purchasing BOM, the structure may group items by sourcing strategy. Strategic components may be separated from standard hardware. Region-specific parts may be grouped for negotiation and logistics planning. Tooling investments may be tracked distinctly from recurring production components.

In the Service BOM, the robot may be reorganized around field-replaceable units. Instead of subsystems, the structure may highlight replaceable motor kits, gearbox modules, safety board replacements, and preventive maintenance bundles.

Each of these structures is valid. Each answers a legitimate question.

OpenBOM xBOM allows you to define these as separate BOM types, each with its own hierarchy and structural logic. Crucially, they all reference the same items from the shared catalog.

This is where the architectural elegance emerges. You do not duplicate parts to create a manufacturing view. You reorganize them. You do not manually map engineering parts to purchasing categories in an external spreadsheet. The connection is inherent because they are the same objects.

Multi-view modeling is not about creating parallel data silos. It is about projecting the same object foundation into different structured perspectives.

Beyond Hierarchy: Modeling Relationships

Even with multiple structured views, a robot is still more complex than a set of trees.

Hierarchy tells you what is contained within what. It does not capture every meaningful relationship.

A servo motor may be approved from two suppliers. A gearbox assembly may depend on a specific tooling process. A firmware version may be compatible only with certain controller hardware revisions. A high-payload configuration may require reinforced structural components. A production variant may be allocated to specific plants.

These connections are not always hierarchical. They are associative, contextual, and cross-cutting.

In OpenBOM, object link properties allow you to model these relationships explicitly. An item can link to another item, to a supplier, to a document, to a tooling asset, or to a plant. These links add semantic meaning that hierarchy alone cannot express.

When you combine structured BOM types with flexible object relationships, the robot begins to resemble what it truly is: a connected system of data rather than a static list of parts.

Structure defines containment. Links define context.

And it is context that makes multi-view modeling powerful.

Conclusion: The Three Foundations of xBOM

If you step back and visualize all these perspectives — engineering, manufacturing, purchasing, prototype, production, and service — what you see is not a single hierarchical tree. You see a connected network of structured views, each reflecting a different operational reality of the same product.

The temptation in many organizations is to collapse that network into a single “master” BOM and declare it the source of truth. But that approach inevitably removes perspective and creates friction. When one structure is forced to serve all disciplines, it stops serving any of them well.

A more honest and more sustainable approach is to accept that modern industrial products are inherently multi-view and to model them intentionally.

This is exactly where the xBOM model comes into focus. At its core, xBOM rests on three fundamental elements.

1. Shared catalogs of items establish consistent identity across the organization. Every object — whether it is a servo motor, a casting, a controller board, or a service kit — exists once and carries its properties in a single authoritative place. Identity is stable, reusable, and independent of structure.
2. Multiple BOM types allow each discipline to express its own structural logic. Engineering can be organized by subsystem, manufacturing by assembly flow, purchasing by sourcing strategy, service by replaceable units. Each structure answers its own question without duplicating data or fragmenting the product definition.
3. Object links and flexible relationships extend modeling beyond simple containment. They connect items to suppliers, plants, tooling, configurations, and documents, capturing the contextual meaning that hierarchy alone cannot express.

When these three elements work together, complexity does not disappear, but it becomes organized and intelligible. Different teams can operate within their own perspective while remaining anchored to the same product foundation. The robot on the factory floor may look like a single machine, but inside the enterprise it is a multi-dimensional dataset. The xBOM architecture simply reflects that reality instead of fighting it.

Modeling the dataset correctly is not about adding more views for the sake of it. It is about building a coherent architecture that connects those views through shared identity and explicit relationships. Once that architecture is in place, the product stops being fragmented across departments and begins to function as a connected system that can be understood, analyzed, and evolved with clarity.

The robot was never just one BOM.It was always many structured perspectives of the same reality.

In the next articles, I will move from architecture to practice. We will look at concrete examples of how catalogs are defined, how multiple BOM types are structured, and how object links create meaningful connections across views. Step by step, we will demonstrate how the xBOM model can be implemented in real industrial scenarios — not as theory, but as an operational data service that brings order to multi-view product complexity.

Interested to discuss how to build a multi-view BOM structure of your product data? 

REGISTER FOR FREE and contact us to discuss. 

Best, Oleg