The Bill of Materials (BOM) stands as a pivotal yet contentious subject within the space of Product Lifecycle Management (PLM), product development process, product data management, engineering, data management and raw materials. This term, ubiquitous in its usage, paradoxically elicits widespread debate in the world of 3D CAD, PLM technology, PLM solutions concerning its definition, representation, management, and, crucially, its evolving role in the spheres of engineering, manufacturing, and PLM software. It is tightly connected to other disciplines such as supply chain management, computer aided design (CAD), project management, overall product lifecycle and business processes in any manufacturing company.

For those who may have missed my earlier articles, I invite you to explore the ongoing debates around BOMs on LinkedIn and my recent articles, which dig into resolving BOM type discourse.

How to resolve BOM Type discourse?

Adopting digital product data model in place of multiple BOMs

Traceability, Digital Thread and Future PLM Software Architecture

Today, I’d like to explore more into the complex world of BOM management, aiming to spark a dialogue on its future. While the subject is vast, we zero in on a pressing query: does the future hold a place for BOMs, and if so, how do we navigate the management of multiple BOMs, especially in relation to CAD and design systems? Opinions vary widely among leading PLM vendors, industry experts, and practitioners, each bringing unique insights to what I like to refer to as “Da BOM” topic.

How to manage complexity of product lifecycle?

The name of the problem is complexity. Products are complex, processes are complex. Multiple disciplines, configurations, lifecycle stages – this is only a slice of complexity in modern engineering and product. How leading PLM vendors solve these problems? What approach are they offering? To BOM or not to BOM?

The “Let’s BOM It” Approach

Companies like Siemens Industrial Software and Accenture believe in Enterprise BOMs. Today’s products transcend traditional mechanical and electrical parts, embracing electronics, software, sensors, actuators, and product-as-a-service models. This complexity necessitates a sophisticated BOM, viewed as a strategic asset for holistic digital product definition management across the product lifecycle. The pursuit of an advanced Enterprise BOM framework calls for a nuanced understanding of the separation between Design and Engineering BOM.

Here are a few examples I found on their websites – Why CAD BOM Separation? Here is a key passage:

In today’s complex digital landscape, the evolution of a product involves orchestrated maturity of many individual disciplines: design, engineering, manufacturing, planning, service. Each domain has a way to view and organize a product and specific properties and behaviors to assign to a product’s parts and assemblies.

Efficiently managing, controlling, and eliciting change on such an orchestrated set of product data begins with accurately aligning the evolving product design, aka CAD BOM, and the product engineering BOM.

Our customers have been talking with us for a long time about their needs for having a different product design and product EBOM. While the product’s design and EBOM views are complimentary, they have other data structures and support various functions. Also, the way the design and EBOM evolve is quite different, with different business processes and different roles in the company taking part in them. 

For example, designers, research & development, and the different engineering disciplines use various design tools to author, innovate, and create a rich set of designs to be inserted into a design definition.  On the other hand, product engineers, purchasing, regulatory, and service must define and manage cost, logistics, opportunities, operations, regional availability, and rules in what constitutes the product EBOM.

For another example, in some companies, design tends to take the lead. Design systems and components evolve first, and much of the EBOM tends to resemble the design structure, with some additions in the EBOM from product engineers. However, in other companies, the EBOM takes the lead. The product engineer defines the assemblies and parts to be designed, and the design structure tends to resemble the EBOM.

CAD BOM/design to EBOM alignment is a crucial underpinning for achieving high concurrency between design, engineering, and manufacturing domains where alignment provides the needed dependency among the different disciplines while allowing each part with its own set of data and processes to mature at its own pace.

There are only incremental improvements to reduced process time, increased quality, and decreased costs with loose and manual alignment. However, with automated alignment, a company can realize significant time collapse in the product engineering process, improve the quality of deliverables, and reduce development costs.

Another interesting article for the same topic is this one – Accenture: why companies with complex products should separate their Design from their EBOM, which speaks about the BOM approach taken beyond the design and EBOM. Here is another passage:

In the ever-evolving business landscape, as customer preferences are changing and companies across industries are venturing into new markets and innovating products – part counts, variants, product complexities, and production volumes are all increasing. Products nowadays are no longer simple designs with only mechanical and electrical parts. They include more electronic parts, software parts, are fitted with sensors & and actuators, and can come with product-as-a-service models. As a result, the bill of material (BOM) is getting more complex as different structures, types and configurations are created across the value chain. The BOM is a strategic asset, leveraged for holistic digital product definition management throughout the product lifecycle. For organizations who are in pursuit of achieving the next level of maturity in BOM management via the Enterprise BOM framework; It is imperative to understand the decoupling of Design and Engineering bill of material (EBOM).

The following passage is highlighting the focus on product data as a central place of product lifecycle, variants, change management, supply chain and other disciplines.

An organization should not only consider product data as the merit for decoupling Design and EBOM but also consider factors like lifecycle, product variants, product volume, product complexity in terms of different part domains, cardinality criteria (there could be an N: N relationship possible between design component and part), change management, and organization of product data by different roles. For instance, consider the operations of an automotive manufacturer, where thousands of cars are produced each day. A car comprises a diverse array of mechanical, electrical, electromechanical, and electronic components, each serving distinct functions and contributing to safety features or driver assistance systems. Connectivity, infotainment, and mobility-as-a-service are augmented via complex software applications. The development process involves multiple domain-specific teams, suppliers, and a variety of tools for the design, validation, and release of these complex designs. Hardware components follow a lifecycle that includes stages such as drafting, design, verification, and production release, while software components go through phases like design, development, testing, and deployment. If the car is intended for the global market, various versions are created to accommodate different steering system positions, automatic or manual gear shift options, the presence of sunroofs, and a multitude of color choices, among other customizations. Consequently, the same steering component may be associated with various designs due to differing positional requirements. Similarly, the exterior body design may be linked to different components due to variations in color or material grades. The demand for product variants can fluctuate based on consumer preferences, directly influencing production volume. All these intricate factors are interconnected and significantly influence the decision-making process regarding the decoupling of DBOM and EBOM.

The “Beyond BOM” and “Virtual Twin” Perspective

Dassault Systèmes champions the “Beyond BOM” philosophy through their 3DEXPERIENCE platform strategy, emphasizing the need for a virtual twin model to navigate the complexities of modern product development.

Check the following page to learn more about what DS calls a virtual twin.

Virtual twin technologies provided by Dassault Systèmes’ platform solutions enable businesses, consumers, patients and citizens, to solve the biggest sustainability challenges and drive innovation by: Designing innovative, visionary models and objects; Accelerating cross-team collaboration and managing product creation from early planning to final release, including all developmental milestones; Using digital twin simulation in the design process to assess performance, reliability and safety.

As the physical product advances through its lifecycle, so too does the virtual twin. New sources of data are added, such as operational data from sensors, performance measurements and maintenance records. When combined with the original requirements, design decisions and simulation results, the virtual twin has its own lifecycle: the twin of the ‘as-made’ and ‘as-used’ product.

The virtual twin is both the digital replica of the product itself and of its history and evolution.

According to DS, the “Beyond BOM” approach is the one that will solve the problem of complexity in product design, engineering, simulation and manufacturing. Here is the passage from Beyond BOM e-book.

BOMS ARE NO LONGER SUFFICIENT TO SUPPORT ENGINEERING. BOMs have been around for centuries, playing a critical role to define and communicate product structures. The BOM has served as the master, single source of truth for Purchasing, Manufacturing, and the rest of the enterprise. An engineering BOM (EBOM) is typically created by Engineering, often linked to the MCAD and ECAD files that contain detailed product data including geometry specifications, and then extended with additional information to support downstream functions such as sourcing and purchasing. They are also usually recreated entirely into separate manufacturing BOMs (MBOMs) to support manufacturing processes and planning. While any type of BOM is a useful documentation tool to connect enterprise stakeholders and contributors, a BOM is no longer dynamic and comprehensive enough to serve as the master definition of the product or the manufacturing processes.

A proposal of DS is to move into a virtual single environment of 3DEXPERIENCE.

This unified environment and unified product structure are the key for different experience provided by DS 3DEXPERIENCE. You can judge it in the following 2 videos:

Create new configurations and revisions for 3D Design and Engineering environment.

As far as I can understand a unified product structure is the main difference that DS presents as way to manage a unified mechanism to define the product and take it though the different design and manufacturing stages. As products integrate mechanics, electronics, and software, a dynamic approach is essential for validation and optimization, signaling a shift towards a unified product structure capable of supporting design and engineering representation.

Bridging the Approaches – Open Product Model?

Despite their differing presentations, both Siemens Industrial Software and Dassault Systèmes acknowledge the reality of product complexity and the necessity for an evolved model to manage product data throughout its lifecycle. This consensus underscores a shared recognition of the complexities inherent in product data, advocating for future PLM technologies to adopt models capable of managing this intricate information.

Recent articles I’ve published discuss the imperative for a comprehensive “product model,” exploring the use of graph models for future PLM technologies. These discussions extend to how graph-based digital threads and product knowledge graphs can address complex product data modeling, CAD/BOM management, EBOM-MBOM processes, and PLM-ERP integrations.

In my future articles I will talk more about how future open product models can provide a solution to bridge heterogeneous systems in product design, manufacturing and maintenance. I will also address the problem of vertical integration in product design, BOM management, engineering and manufacturing, and specifically, the usage of fully integrated vertical product suites from a single vendor vs multiple systems and data integrations.

What is my conclusion?

So, what is the path forward? Product data’s complexity is a reality of every manufacturing company and demanded by all customers Despite formal disagreements among vendors, there’s a clear alignment with customer requirements for a comprehensive product model to effectively manage data for product development and manufacturing. The journey towards refining product models to support this process (regardless if you call it BOM or product structure) requires understanding of technical characteristics of this model and not how to call it. Design digital transformation. BOM management and integration strategies is ongoing, with a collaborative effort required to navigate the evolving landscape of product lifecycle management.

In closing, the discourse surrounding BOMs is not merely about choosing to adopt or reject them but understanding how they can be evolved and integrated to meet the demands of modern engineering and manufacturing practices. The future of product models including design disciplines, BOM and digital processes lies in innovation, collaboration, and the continuous pursuit of models that enhance our ability to manage the complexity of product data effectively.

Best, Oleg

Disclaimer: I’m co-founder and CEO of OpenBOM developing a digital-thread platform with cloud-native PDM & PLM capabilities to manage product data lifecycle and connect manufacturers, construction companies, and their supply chain networks. My opinion can be unintentionally biased.

The post To BOM or Not to BOM? Navigating the Future of Product Models and Bill of Materials appeared first on Beyond PLM (Product Lifecycle Management) Blog.