Multiple BOMs and the Reality of Product Data

A few weeks ago, Martin Eigner published a thoughtful post discussing a deceptively simple question: Is a CAD model the same as a Part? His post responded to earlier articles, including one of mine, and expanded the discussion in an important direction. Rather than arguing for a single correct answer, Martin raised a more fundamental point that many of the decisions we make in product data modeling are not universal truths, but choices shaped by context.

Introduction: One Question, Many Valid Answers

The traditional argument is well known. CAD models are volatile, parts must be stable. Separating CAD from Part helps control revisions, maintain compliance, and avoid unnecessary complexity. In many environments this approach works extremely well, especially where configuration management and traceability are critical.

At the same time, Martin pointed out something that practitioners often recognize immediately. In some organizations, particularly during early development or in certain industries, the CAD model naturally becomes the leading object. Separating CAD and Part too early may introduce overhead rather than clarity. In other cases, tight coupling between design and product definition enables agility and faster iteration. What works in one company may create friction in another.

This is why discussions around CAD versus Part rarely converge to a single answer. The question itself exposes a deeper reality: product data modeling is not universal. It reflects how companies organize responsibility, decision-making, and information flow across engineering, manufacturing, and business processes.

And this is where the conversation becomes more interesting.

The CAD-versus-Part debate is not really about CAD or Parts. It is about how products are represented as they move through design, engineering, supply chain planning, manufacturing, sales, and maintenance. Different perspectives require different structures. Different industries evolve different practices. Even within the same company, multiple representations of the product often coexist.

In my experience working with companies across industries, this diversity is not a problem to eliminate. It is a reality to understand and manage. The challenge is not choosing the single correct model, but maintaining connectivity between models so information remains consistent and understandable as products evolve.

This article continues that discussion from a broader perspective. Instead of focusing on a single modeling decision, it looks at the larger landscape of product data organization — why multiple BOM types emerge, where problems typically appear, and what successful companies have in common when managing complexity across teams, systems, and lifecycle stages.

Understanding Multiple BOM Types in Modern Product Development

Product development often begins in a simple way. A small team creates a design, stores CAD files in shared folders, and manages parts in spreadsheets. Decisions are made quickly because everyone involved understands the product and its context. At this early stage, it feels natural to assume that a single structure describing the product will be enough.

That assumption rarely survives contact with reality.

As products move beyond design and into sourcing, manufacturing preparation, sales configuration, and long-term support, the number of people involved increases. Each team begins to look at the same product from a different perspective. Engineering focuses on function and design intent. Supply chain focuses on availability and cost. Manufacturing focuses on assembly and sequencing. Sales focuses on what can be offered and configured for customers. Maintenance focuses on serviceability and lifecycle support.

The product itself has not changed. What has changed is the number of questions being asked about it.

This is where complexity begins to appear. And it is important to understand that this complexity is not a failure of tools or processes. It is a natural outcome of how modern products are developed and delivered.

The complexity of modern products is not only technical. It is organizational and informational.

Product Development as a Coordinated System

Product development is not a single activity. It is a coordinated system involving multiple functions that interact continuously throughout the lifecycle of a product.

Engineering defines functionality and product structure. Supply chain defines sourcing options, availability, and cost. Manufacturing defines how the product is actually built and assembled. Sales defines what is offered to customers and how it is configured. Maintenance defines what must be supported, replaced, and serviced over time.

Each function introduces new attributes, decisions, and structures around the same product. As a result, the product is no longer represented by a single definition, but by multiple connected views shaped by the needs of different teams.

What has changed in recent years is not only product complexity, but the growing demand for connected data. Decisions made in one area increasingly affect others immediately. A component change in engineering impacts sourcing. Supplier availability influences design choices. Manufacturing constraints affect configuration options. Service feedback influences future revisions. The need for information to move reliably between these activities has become essential for continuous operation.

This is why multiple BOMs naturally appear. They are not created because companies seek complexity, but because specialization requires different representations of the same product. The real challenge is not the existence of these different views, but maintaining connectivity between them so that information remains consistent and understandable as it flows across teams, companies, and systems.

The Map of Solutions Companies Actually Use

If we look across industries, a consistent pattern emerges. Companies rarely design their product data architecture from scratch. Instead, systems are introduced gradually as new problems appear.

CAD systems manage geometry, assemblies, and configurations. PDM systems manage files and versions. PLM tools or spreadsheets manage item structures and engineering definitions. CPQ tools manage selling configurations. Procurement and finance systems manage ordering. ERP systems manage production execution and supply chain operations. Service systems manage serial numbers and maintenance history.

Each system solves a local problem well. The difficulty appears when information must move between them.

Engineering releases a change, but procurement does not see it immediately. Manufacturing reorganizes product structures to fit production needs. Sales creates configurations that diverge from engineering intent. Service teams struggle to understand how delivered products differ from the original design.

Most companies did not design this fragmentation intentionally. It evolved over time as the business grew, as new requirements appeared, and as teams optimized their own local workflows.

The result is a landscape where multiple product structures coexist, often with different terminology and ownership. The table included in this article reflects patterns observed across many companies and industries. It is not a theoretical framework, but a map of how solutions and problems tend to evolve together.

Understanding the Most Common BOM Types

The term BOM, or Bill of Materials, is widely used, although it is not universally defined. Different industries use different terminology, and many companies combine or rename structures depending on their needs. What matters is not the name, but the purpose each structure serves.

The CAD structure represents design intent. It reflects how engineers think about assemblies, configurations, and geometry. The file-oriented or design BOM focuses on versions and relationships between design artifacts.

The Engineering BOM defines items and revisions from an engineering perspective. It answers the question of what the product is made of from a design standpoint.

The Sales BOM represents what customers actually buy. It may group components differently or hide internal complexity to simplify configuration and ordering.

The Procurement or Planning BOM reflects how parts are sourced and ordered. Suppliers, alternates, and purchasing quantities become important here.

The Manufacturing BOM reorganizes the product according to assembly sequence, production steps, and operational efficiency.

The Service BOM focuses on maintenance, replacement parts, and lifecycle support, often incorporating serial numbers and field history.

Different software systems evolved to solve local problems:

• CAD systems manage geometry and configurations.
• PDM systems manage files and versions.
• PLM and spreadsheets manage item structures.
• CPQ tools manage selling configurations.
• Finance and procurement systems manage ordering.
• ERP systems manage production execution.
• Service systems manage serial numbers and maintenance.

Here is quick summary table: 

These structures exist because different teams need different answers from the same product data. The existence of multiple BOMs is therefore not inefficiency. It is a specialization.

Where Problems Actually Appear

In practice, problems rarely originate from individual systems. They appear at the boundaries between them.

Engineering changes may not reach procurement in time. Manufacturing may manually restructure product data to fit production workflows. Sales configurations may drift away from engineering definitions. Service teams may lack traceability to understand what was actually delivered.

Over time, decision context disappears. Teams see the current data, but not the reasoning behind it. Information exists, but understanding does not.

This is why many organizations experience recurring issues despite investing in new tools. The underlying problem is not missing software functionality. It is loss of continuity as information moves between lifecycle stages.

The handover between teams is where complexity becomes visible.

Why There Is No Universal Solution

It is tempting to search for a single correct structure or a universal methodology that solves these problems. In reality, such a solution does not exist.

Industry differences matter. Engineer-to-order environments behave differently from high-volume manufacturing. Company size influences process maturity. Supply chain complexity reshapes data organization. Regulatory requirements introduce additional constraints.

What works for a small robotics startup may not work for a global equipment manufacturer. Even within the same industry, companies evolve differently depending on their products and markets.

Successful organizations do not eliminate complexity. They learn how to manage it while preserving flexibility.

What Successful Companies Have in Common

Despite differences, successful companies share a common characteristic. They maintain continuity of product information across the lifecycle.

Information moves between teams, companies, and systems without constant re-creation. Engineering intent remains visible in manufacturing. Procurement decisions remain connected to design. Service feedback informs future revisions.

The BOM becomes a commonly used organizing structure not because it is perfect, but because it provides shared understanding and traceability. It becomes a common language connecting different functions of the business.

BOM as a Data Organization Concept

Looking forward, the goal is not to eliminate multiple BOM types. Modern products require multiple perspectives, and those perspectives will continue to exist.

The real challenge is allowing these different views to coexist while maintaining connection between them. Product data must remain understandable as it evolves through design, production, delivery, and service.

In this sense, BOM becomes less a document and more a data organization concept. It represents how knowledge about the product is structured and preserved over time.

The future of product development depends not on simplifying reality, but on making complexity manageable without losing context or decision history.

The Role of OpenBOM in a Complex Product Environment

After understanding the landscape of multiple BOM types and interconnected processes, an important question emerges: where does OpenBOM fit?

The important point is that OpenBOM was never designed with the goal of replacing existing engineering, manufacturing, or business systems. CAD systems, ERP platforms, PDM tools, and specialized applications exist for good reasons. Each of them solves a specific problem well. The challenge most companies face is not the existence of these systems, but the difficulty of keeping information consistent and understandable as it moves between them. Although OpenBOM can be used as PDM, PLM, or even ERP software in certain situations, depending on the problems being solved, company size, industry, and specific operational needs, its primary role is not to replace systems, but to help connect information and maintain continuity across them.

Organizing Information 

One aspect of this role is organizing information in a way that preserves history and context. As products evolve, decisions accumulate. Parts change, suppliers change, and assumptions made early in development are often forgotten. OpenBOM helps structure product information so that relationships and decision history remain visible. Over time, this creates what can be described as product memory — an understanding of the product that persists beyond individual projects or team members.

Collaboration between people 

Another aspect is supporting collaboration around product data. Product development is fundamentally a human activity involving discussion, review, and coordination between teams. OpenBOM provides a shared workspace where product data becomes the common reference point for collaboration. Comments, reviews, and tasks allow decisions to be connected directly to structured information rather than scattered across emails or disconnected documents.

Data Handover 

The third aspect is enabling data handover between teams, companies, and systems. Engineering, procurement, manufacturing, and service organizations all operate in different environments. OpenBOM supports data sharing and synchronization without forcing every participant into the same system. Instead, it helps maintain continuity as information moves forward through the lifecycle.

In this context, OpenBOM does not attempt to define a single correct BOM or workflow. Its role is to allow multiple product views to coexist while preserving connection between them.

Vision

The following picture gives you a vision of how we see companies adopting OpenBOM services by first organizing data and building a foundation for product data beyond traditional systems of record. The path toward this vision requires both technology and organizational change, as people and companies gradually adapt how they collaborate around product data.

Conclusion

Products evolve through people, decisions, and time. As organizations grow and products become more complex, multiple representations of the same product become inevitable. The challenge is not to eliminate this complexity, but to organize it in a way that keeps information connected and understandable.

The role of product data organization is not to simplify reality. It is to make complexity manageable so that knowledge can move forward together with the product itself.

This understanding becomes increasingly important as companies move toward more collaborative workflows, long-running change processes, and AI-assisted decision making. Connected data, preserved context, and shared understanding form the foundation on which those next steps can be built.