When Bills of Material Hinder Product Development

Though BOMs are essential to drive product modularity and complexity, they can hinder operations.

BOMs serve as the basis for managing product deliverables in manufacturing organizations—from concept definition to design, engineering, production planning, inventory management and cost control. They aim to provide a complete and accurate description of the components and materials needed to produce a product, including quantities, specifications, work instructions and more. The aim is to ensure that production processes run smoothly and efficiently, supply chain operation is optimized and that all necessary steps are taken to produce high-quality products.

Concept, engineering, manufacturing, cost and service BOMs can be referred as the five ‘structural pillars’ of manufacturing organizations because they provide detailed lists of all the raw materials, components and sub-assemblies needed to design, manufacture and maintain a product. These can nevertheless be fragile pillars when based on rigid or obsolete legacy design choices. (Image courtesy of Bigstock.)

Information is critical for product modularity, change management, supply chain management, finance and procurement approvals. It helps to ensure that the necessary materials and components are available when they are needed, at the right cost. While BOMs require effort to maintain and update, they help to streamline operations and ensure that manufacturing organizations can produce high-quality products efficiently and cost-effectively.

Following a survey commissioned by Siemens, CIMdata reported on the “Importance of an Enterprise BOM.” Interestingly, according to the results, “Almost half [of the industrial respondents] said their BOM management approach hurts their business, even though 22 percent say they already have an enterprise BOM capability.” This suggests that core challenges relate to how BOM management practices are implemented.

In this post, I discuss the reasons why BOM management practices can enable or hinder business operations, and expand on whether it can get easier or more complex when adopting a single “super BOM” approach.

A Closer Look into BOMs

Some business leaders misinterpret the purpose of BOMs. It is not about building a static representation of products; instead, it is about a flexible and dynamic approach to managing product modularity and variability. BOM management practices cover aspects of both product and business-related capabilities. This includes considerations such as how companies:

• Operate and drive product and process changes.
• Generate and test innovative ideas, concerting concepts to development initiatives.
• Collaborate across internal functions and with external parties.
• Configure their product options and variability across alternates, substitutes, features, colors and more.
• Source components, materials and associated services.
• Industrialize products and scale production.
• Simulate and track revenue and productivity.
• Track product changes and drive associated decisions and mitigations.
• Reuse components and optimize supply chains.

Most BOM studies in discrete manufacturing industries tend to be rooted in mechanical CAD, DMU and CAE—debating the role of BOMs across the PLM and ERP landscape. The CIMdata 2022 survey asked relevant questions, albeit traditionally focusing on high-level topics such as part count and BOM size, product variant management challenges, mainstream tools and systems used, methods for managing product BOMs across the lifecycle, or digital mockup verification often specific to mechanical design.

Perhaps not surprisingly, it is therefore difficult to derive clear trends or tangible conclusions from such a survey. Nevertheless, some interesting points were reported by CIMdata:

• BOMs are managed in both PLM and ERP platforms, including COTS and bespoke homebrew solutions.
• Too many BOM systems can hinder operations—highlighting that there is no real consensus on whether a single BOM is either sufficient or potentially effective (a statement that should certainly be nuanced based on the industry sector and the relative organizational maturity).
• The CAD BOM remains an important topic when it comes to virtual prototyping and verification; however, this is only a narrow lens related to mechanical engineering with specific interdependencies with BOM management.

Multiple BOM views are relevant when they serve a clear purpose, following clear design principles to avoid duplication and overheads. For instance, production intent BOMs should not include references to concept BOM components. This is to ensure that the relevant quality, compliance, financial and procurement checks are performed, through the relevant governance and change traceability. In addition, change management translates into different scrutiny levels across product lifecycle phases—implying, for instance, that more rigorous cross-functional approval and compliance verification is required as products mature.

In another sponsored eBook entitled “Siemens Solution for an Enterprise BOM,” CIMdata reported on Siemens moving towards a single BOM approach in Teamcenter. The argument refers to the separation of concern between engineering and manufacturing, debating whether a single, dual or multi-BOM approach would add more value to the enterprise. Siemens refers to this multi-BOM approach as an “enterprise BOM” with multiple user interfaces and release process authority. In other words, some might refer to this as a “super BOM” with multiple functional authoring perspectives.

“A comprehensive enterprise BOM provides automated reconciliation and synchronization across domains throughout the lifecycle that can be created and managed with optimal autonomy via integrated release and change processes […] Commercial PLM solutions are advancing to enable a single Enterprise BOM approach to BOM management and manufacturing enterprises are increasing the adoption of such solutions.”—CIMdata (2022)

CIMdata described an enterprise BOM as “a consolidated resource that maintains all the relationships among data elements that are needed to support the user role requirements in all the domains of an extended enterprise, such as engineering, manufacturing, service and the supply chain. This capability is built on a PLM-enabled Digital Thread spanning the extended enterprise.”

In other words, enterprise BOMs might be made possible through end-to-end integration and PLM technology to manage data interdependencies and release process complexity.

How BOMs Enable Operations

Effective operations imply horizontal and vertical integration across functions, technical domains, new product development and introduction delivery gates. Simply put, it implies decision and change traceability throughout, end-to-end process integration, coupled with data duplication minimization. Multiple BOMs typically need to be aligned or synchronized to maintain the relevant traceability and alignment.

Theoretically speaking, providing multiple views of a common “super BOM” can help drive complexity down, reducing the need for continuous data synchronization and the risk of misalignment. Practical implementation, however, can be challenging as both modularization and agility heavily rely on the principle of separation of concerns. It implies balancing between the need to segregate data to keep things simple, and opportunities to reduce complex data synchronization, driving towards a single version of the truth, simplifying part numbering, change management and other operational processes.

Effectively managing product complexity implies driving BOM modularity towards a structured approach to integrated change. Albeit not an exhaustive list, the following data governance guardrails are critical to defining effective BOM strategies:

1. Aligning BOMs to how innovation team operate with organizational design and driving cross-functional data traceability.
2. Driving common release processes across teams, data sets and enabling platforms.
3. Adopting a platform approach to maximize data reuse and enable product modularity.
4. Robustly adopting embedded PLM and ERP data model and processes, avoiding costly pitfalls when deviating from core design principles.
5. Building sustainable data stewardship capabilities to drive BOM changes, centralizing essential non-value-added activities with specialized product data management teams.
6. Integrating enterprise platforms across a core data backbone, maximizing integration robustness, building trust on primary data sets and driving effective collaboration.
7. Electively mandating core process adherence and data standards without hindering value-added activities.
8. Aligning master data governance and ways of working to the above principles with uncompromising architecture principles.

How BOMs Hinder Operations

Rising product modularity, variability and change velocity, coupled with associated productivity and efficiency pressure, imply that manually managing complexity is not a sustainable option when scaling operations. As organizations prepare to scale and grow, segregation of concern and BOM integration become inevitable; therefore, it makes sense to plan and embed future product and business variability as part of BOM change management decisions.

Per the industry survey mentioned above, CIMdata reported that “46 percent [of the respondents] claimed that using multiple BOM systems hinders their business and makes adding or updating variants difficult. 22 percent claim to use an enterprise BOM approach, and others are exploring (41 percent), want to move as soon as possible (14 percent) or in the next five years (8 percent). Industrial companies are ready to embrace the Enterprise BOM approach and the systems that enable it.”

BOMs can indeed hinder organizations with:

• Highly manual file-based/spreadsheet-based processes, with limited or sub-optimal integration or continuous improvements.
• Limited data continuity across functional domains.
• Duplicated, overlapping or poorly integrated enterprise systems.
• Disparate maturity levels across business functions, from marketing, to R&D, manufacturing, quality, procurement and more.
• High technical debt, implying reactive rather than proactive PLM roadmaps.
• Limited continuity between concept, production intent and production data.

A multi-view BOM approach can also bring its share of challenges. This includes the premise that product data matures at the same velocity and timing across all enterprise functions. Furthermore, a key question remains: is the definition of an “enterprise BOM” commonly understood and agreed upon?

Involving master BOM views across functions makes sense; however, what about aligning these views across multiple product development phases? Should concept or prototype BOMs be managed in the same way that production intent and production BOMs should? Can any type of organization adopt such an approach? Does it assume a robustly integrated digital thread across PLM and ERP platforms? Are PLM and ERP vendors clear about the associated business scenarios and user stories to enable such integration?