Catégorie : Uncategorized (Page 2 of 2)

BOM or Product Structure ? How the concepts have converged.


The Bill of Materials (BOM) is a critical component in the realm of manufacturing, design, and product management. Over time, the term « BOM » has evolved in significance and is now often seen as synonymous with « Product Structure. » Let’s delve deeper into this idea.

Historical Context:

Traditionally, a Bill of Materials (BOM) was a list or document that specified the raw materials, parts, and components, along with their quantities, needed to manufacture a finished product. The BOM was essentially an ingredients list for manufacturing.

On the other hand, Product Structure described how a product was broken down into its constituent components, sub-assemblies, and assemblies. It was more of a hierarchical depiction, detailing how different parts fit into the overall product.

Convergence of Concepts:

  1. Complexity of Modern Products: As products have become more complex, so too has their documentation. It’s no longer enough to just list parts; manufacturers need to understand the relationships between parts, how they fit together, and the various dependencies. This necessitates a deep structural view of the product, blurring the lines between a mere list (BOM) and a detailed breakdown (Product Structure).
  2. Digital Evolution: With the rise of digital tools and Product Lifecycle Management (PLM) software, the BOM has evolved from a static list into a dynamic, multi-dimensional entity. Modern BOMs can now represent the hierarchical structure, variants, and configurations of a product, encompassing the essence of what was traditionally termed ‘Product Structure’.
  3. Holistic Product View: In today’s competitive market, a holistic view of the product is paramount. From design and engineering to manufacturing and after-sales support, understanding the product’s structure is critical. Thus, the BOM has expanded in scope to provide a 360-degree view of the product.
  4. Unified Terminology for Cross-Functional Collaboration: With multiple departments and teams (design, engineering, procurement, manufacturing, etc.) collaborating on a single product, a unified language is essential. Referring to the product’s structure as the BOM simplifies communication and ensures that everyone is on the same page.
  5. Lifecycle Management: Modern BOMs are not static. They change and evolve as the product moves through its lifecycle, reflecting design changes, substitutions, or adaptations based on feedback or supply chain dynamics. This dynamic nature aligns more with the concept of ‘Product Structure’, which inherently acknowledges the product’s evolving nature.

Conclusion:

The evolution of the BOM from a static list to a dynamic representation of a product’s entirety is a reflection of the complexities of modern manufacturing and product design. The convergence of the terms « BOM » and « Product Structure » is not just semantic; it mirrors the industry’s need for a more holistic, integrated, and detailed view of products. As products continue to evolve, it’s likely that our understanding and representation of their structure will evolve alongside them.

PLM and MBOM – a first look

First, some terminology:

(Always useful, even if some terms are not used in the post)

Part : any component, sub-assembly, assembly, product that is referenced during the product or manufacturing design

Manufactured Part: This is the actual physical piece that has been fabricated according to the specifications provided in the design, in a Manufacturing Process. It involves the utilization of materials, machinery, and labor to transform a design into a tangible item that can be assembled or integrated into a larger system or product. Once produced, the manufactured part is stored in a stock, and extracted on demand to be consumed in a new Manufacturing Process . These parts are usually designed to meet specific requirements, dimensions, materials, or tolerances that are unique to the company’s products.

Design Part: Conversely, a design part is a conceptual or virtual representation of a component. It exists in the form of drawings, CAD models, or other design documents, containing all the specifications, dimensions, materials, and other information required to manufacture the part. The design part serves as the blueprint for creating the manufactured part.

Configured part: fully defined part, with no ambiguity in term of definition, unlike generic parts, which can for example carry options/variants.

Material (or Raw Material) : Raw materials are the unprocessed natural substances or basic elements used as the starting point in manufacturing and production.

Work-In-Progress (WIP): refers to the goods that are in various stages of the production process but have not yet been completed. These items have already incurred some labor, material, and overhead costs but are not yet finished products.
WIP is not managed in stock, thus, in most of the case, it does not have any part number. It is referenced as the result of a manufacturing operation.

Semi-Finished Parts : A semi-finished part is a component that has undergone some, but not all, of its manufacturing processes and is intermediate between raw materials and the final product. It may require further machining, shaping, or assembly to become a finished part suitable for use in a final product. A semi finished part passes through a stock, so, he has to have a part number.

Part Number : a part number, for a configured part, is an Id that defines a class of equivalence. Two objects that have the same part number are fully interchangeable. A part number is absolutely mandatory for each purchased or manufactured part that passes through a stock.

You cannot discuss about MBOM without knowing what Manufacturing Process Plan (MPP) is :

A Manufacturing Process Plan (MPP) is a detailed document or roadmap that outlines the steps, sequences, methods, tools, equipment, and standards required to transform raw materials and compoents into new manufatured parts.

Here’s what the Manufacturing Process Plan typically includes:

  1. Sequence of Operations: The MPP lays out the precise sequence of steps that must be followed in the production process, from the preparation and treatment of raw materials to assembly, finishing, and inspection.
  2. Workstations : workstations and machines on which manufacturing operations are performed
  3. Tools and Equipment: The plan specifies the tools, machinery, and equipment necessary for each stage of production, including their setup and calibration.
  4. Materials and Components: The MPP lists the raw materials, semi-finished parts, and other components required.
  5. Quality Standards and Inspection: Quality control measures, acceptance criteria, and inspection techniques are outlined to ensure that the finished product meets the required standards and specifications.
  6. Labor and Skills Requirements: The plan may describe the labor requirements, including the necessary skills, qualifications, and training needed for different stages of the process.
  7. Time and Cost Estimates: Many MPPs also include estimates of the time and cost associated with each step, aiding in scheduling, budgeting, and overall project management.
  8. Safety and Environmental Compliance: The MPP may also contain information regarding safety protocols, waste management, and compliance with environmental regulations.

Product Design versus Manufacturing Process Design

In the world of modern manufacturing, the development of a product is no longer an isolated endeavor. The conception of a product and its manufacturing process is a parallel undertaking, intricately woven together to ensure efficiency, cost-effectiveness, and innovation. Here’s a closer look at how this parallel design process unfolds:

1. Reuse of Existing Parts or Subassemblies

The initial stages of product design often involve an assessment of existing parts or subassemblies that might be reused or adapted. This not only saves time and resources but also leverages proven components to enhance reliability. Reutilizing existing parts requires a clear understanding of inventory, previous designs, and how these components can integrate with new products.

2. Selection of Component and Subassembly Sourcing Methods

Choosing the right sourcing methods for components and subassemblies is a simultaneous consideration with product design. This involves critical decisions like:

  • Purchasing: Sourcing ready-made components that meet the required specifications.
  • Subcontracting: Collaborating with specialized manufacturers to produce certain parts or assemblies.
  • Internal Manufacturing: Producing the components in-house, leveraging existing capabilities, and controlling quality.

This choice is closely tied to factors like cost, quality, lead time, and strategic alignment with the overall product objectives.

3. Defining the Manufacturing Process with Impact on Part Design

The manufacturing process’s conception is not an afterthought but an integral part of the overall product design. The process selected can significantly impact the design of the parts, influencing factors such as:

  • Material Selection: Choice of materials that align with manufacturing capabilities and product requirements.
  • Tolerance Levels: Defining the acceptable variations in dimensions that can be achieved within the chosen manufacturing methods.
  • Cost Constraints: Aligning the part design with cost-effective manufacturing techniques without compromising quality.
  • Sustainability Considerations: Incorporating sustainable practices in both design and manufacturing.

By considering the manufacturing process early in the design phase, it is possible to create products that are not only innovative but also manufacturable, cost-effective, and aligned with market needs.

Conclusion about MPP: A Symbiotic Relationship

The parallelism between product design and the conception of its manufacturing process reflects a symbiotic relationship where each aspect informs and shapes the other. This synergy fosters innovation, reduces time-to-market, and ensures that the final product is not only a realization of creative vision but also a practical and marketable commodity.

In essence, modern manufacturing demands a holistic approach, where design is not confined to the drawing board but extends into the very heart of production, encompassing aspects such as part reuse, sourcing strategies, and process considerations that resonate with the product’s purpose, market positioning, and value proposition.

In such a case, MBOM is not « strictly-speaking » created from an EBOM. MPP is designed in parallel of the EBOM, with strong accountability check to verify that the two structures are aligned (i.e. all the design components have an equivalence in the MPP structure). Then, MBOM is a filtering of the MPP

Understanding MBOM in PLM: A Connection Between Design and Production

The Manufacturing Bill of Materials (MBOM) is an indispensable element within Product Lifecycle Management (PLM), serving as a bridge between product design and actual manufacturing processes. Its role in defining the flow of materials and components used in production is crucial. Here’s an in-depth look at the role of MBOM within PLM:

1. MBOM as a Filtered View of Manufacturing Process Plan (MPP)

The definition of MBOM is quite simple: for a product, sub-assembly or single part, it involves filtering the process plan, detailing the components and raw materials taken from stocks and consumed in the manufacturing process.
Thus, intrinsically, the MBOM is second-level information relating to the process plan. It translates procedural guidelines into concrete requirements for materials and components.

Thus, the answer to the question « What does my MBOM look like for a given product? », comes down to the following questions

  • How do I manufacture my product?
  • Which raw materials and components do I have to source?
  • Which intermediate components pass through inventory/stock during the overall manufacturing process?

Of course, often, the MBOM structure is quite close to the EBOM structure.
But do not forget that they can be quite different. Think about the products delivered in kits.

2. Integration between PLM and ERP Systems

As soon as the manufacturing process is complex enough, it is worth creating the the process plan and MBOM within the PLM system, using all the Product Data Management and Manufacturing Process Simulation capabilities
Once created in the PLM, the MBOM is leveraged in the Enterprise Resource Planning (ERP) system, where it guides procurement, production scheduling, and inventory management.

In Summary: MBOM Describes Inventory Flows

The MBOM serves as a dynamic roadmap that describes the incoming and outgoing flows of stocks, components, and materials within the production process. Of course, it must be aligned with the EBOM (ie all the components of the eBOM must be ‘consumed’ in the MBOM) , taking into account several main differences. Just a few examples :

  • Components of purchased or subcontracted subassemblies do not appear in the MBOM.
  • Raw materials appear in the MBOM of manufactured parts
  • Components that are produced during the Manufacturing Process as WIP (i.e. that do not pass through a stock during the manufacturing process) do not appear in the MBOM, but their raw marerials do !
  • Some semi-finished parts can appear in the MBOM (for example, if some manufacturing operations are subcontracted)
  • You can have some specific manufacturing objets, like kits

To conclude

Often, a product is designed, and defined, in the way it will be manufactured. That’s why EBOM and MBOM are often close. But that shouldn’t make us forget that EBOMs and MBOMs serve two different purposes. EBOM defines the products, MBOM the supplys needed to build the product, and the flows between stocks and production lines.

And, for complex products this not solve one of the main questions of PLM :

  • How do we guarantee the alignment between Design and Manufacturing during the whole lifecycle of the product ?

This alignment, which is the foundation of digital thread relies, on a strong change management process, but also on technical functionnalities. To be developped in further posts !

A PLM Project : Be Conceptual during the Analysis – Be Pragmatic during Solution Design

Frequently, the absence of a comprehensive view, the disregard for a project’s full scope, the neglect of relevant theoretical principles, and the denial of a project’s inherent complexity are primary factors leading to project failure, or at the very least, causing delays and cost overruns.

Beyond a certain level of complexity in a Product Lifecycle Management (PLM) project, the software solution alone does not guarantee the overall coherence of the implementation.

This means that, while a software solution is a crucial part of a PLM project, it isn’t the sole factor ensuring a successful, consistent implementation. Especially in complex projects, other factors like strategic planning, process design, change management, data integrity, and user acceptance play a critical role.

My vision:
Be conceptual during the analysis – Be pragmatic during the solution design.

  1. Be conceptual during the analysis:
    During the initial stages of the project, the goal is to grasp the big picture and understand the problem space in a comprehensive manner. This involves understanding the organization’s needs, requirements, pain points, and objectives, along with how the proposed PLM solution might fit into the current system and process landscape. At this stage, it’s important to think conceptually – which means considering abstract ideas and theories. You should not only focus on what is currently happening but also envision potential future scenarios, dependencies, and impacts. This could involve mapping out complex process flows, performing gap analyses, or constructing conceptual data models. The idea is to formulate a strategic understanding of the project scope with the ad-hoc level of detail ensuring the accuracy, consistency and scalability of the future solution.
  2. Be pragmatic during the solution design:
    Once the conceptual understanding and analysis phase is complete, the project moves into solution design. At this point, it’s crucial to shift the mindset from theoretical to pragmatic – focusing on practical applications and concrete solutions. Pragmatic design means coming up with solutions that work effectively in the real world, taking into account constraints such as resources, timeline, technology limitations, and user acceptance. Rather than seeking the ‘perfect’ solution, the focus is on finding a ‘good enough’ solution that meets the business needs, can be implemented within constraints, and delivers tangible value. This includes designing workflows, data models, interfaces, and other details of the PLM system in a way that they are not only theoretically sound, but also usable, efficient, and feasible to implement. This might involve making compromises and balancing trade-offs to ensure the project’s success. In such a case, compromises are made consciously, but without sacrificing scalability and the holistic view of the solution.

In conclusion, it’s all about having the right mindset at the right stage – being conceptual during the analysis to capture the broad vision and being pragmatic during the design to ensure the delivery of a feasible, effective, and efficient PLM solution.

The BOM dilemma : modular versus global approach

The dilemma for Bill of Materials (BOM) management arises due to conflicting perspectives on how to structure and manage BOMs effectively. There are two primary viewpoints that contribute to this dilemma:

  1. Modular BOM Perspective: From a modular perspective, BOM management involves organizing assemblies and subassemblies in a hierarchical structure. This approach recognizes that products are often built using modular components and subassemblies. Each module or subassembly is treated as a separate entity, allowing for easier management, reuse, and maintenance. This perspective emphasizes the modularity and reconfigurability of products, enabling efficient design changes and customization.
  2. Whole BOM Perspective: on the other hand, the whole BOM perspective considers the BOM as a cohesive whole, where each component is treated as an individual entity, regardless of its position within the assembly hierarchy. This viewpoint emphasizes the need to manage and track each component independently, ensuring accurate documentation, procurement, and inventory management. It focuses on the individual components’ specifications, lifecycle, and dependencies, without considering the assembly structure explicitly.

The dilemma arises because these two perspectives have different priorities and implications for BOM management:

  • Complexity vs. Simplification: The modular BOM perspective aims to simplify the management of complex products by breaking them down into modular components. This approach enables better control over changes, promotes reuse, and supports concurrent engineering. However, it may introduce additional complexity in managing relationships between different modules and subassemblies.
  • Granularity vs. aggregation: The entire BOM perspective emphasizes granularity, treating each component independently to capture its specific characteristics, life cycle, absolute position in the product… This approach ensures tracking and precise management of components, allows to track a component in different product views (engineering BOM, manufacturing BOM, service BOM), to manage BOM filtering (extract all components that are within 20 cm of a given component). However, it can ignore relationships and dependencies between components, potentially missing the big picture of how they fit together to form assemblies.
  • Product Structure Engine implemented in PLM software: some PLM software only supports the simple « assembly – component » relationship, and do not allow a component to be explicitly referenced independently of its position in the product structure tree

The key to resolving this dilemma lies in finding the right balance between the two perspectives. Effective BOM management requires considering both the modular structure of assemblies and subassemblies and the individual characteristics and lifecycle of each component. This can be achieved through advanced PLM systems that allow for hierarchical representation of assemblies while maintaining comprehensive component-level data. These systems enable organizations to navigate the complexities of BOM management, facilitate efficient collaboration, and ensure accurate and up-to-date information across all levels of the BOM hierarchy.

My beliefs in term of PLM Implementation Methodology

Implementing a Product Lifecycle Management (PLM) solution involves a multi-disciplinary approach that requires various key roles, a strategic methodology, and meticulous execution to ensure that the solution effectively supports the organization’s objectives.

Here is an outline of what I recommand:

1. Key Roles: Solution Architect, Business Consultants, Functional Consultants, and Technical Engineers

The overall success of a PLM implementation largely relies on the synergy of various key roles, which include:

  • Solution Architects: They are responsible for guaranteeing the global coherency of the implemented solution. They provide a holistic view, making sure that all parts of the implementation align with the organization’s overall strategy and objectives. The Solution Architect translates business requirements into technology requirements (data model, configuration rules, and processes) and defines the overall PLM architecture.
  • Business Consultants: They bridge the gap between the organization’s operational needs and the technical solution. They understand the business operations in depth and help translate these requirements into actionable implementation strategies.
  • Functional Consultants: They are responsible for configuring the PLM software to meet the organization’s needs as outlined by the business consultants. They understand the software’s capabilities and limitations, and work towards creating an optimal setup.
  • Technical Engineers: They execute the implementation plan, handling software installation, integration, and support.

2. Hybrid Methodology: V Cycle and Agile

My belief is a hybrid of two proven approaches – the V Cycle and Agile.

The initial phase of the project utilizes the V Cycle method to establish the core model and the common foundations of the solution. This model includes defining and understanding the business requirements, designing the system architecture, and developing test strategies. This methodology helps ensure that we develop a system that is not only technically sound but also addresses all the operational needs of the business.
The main objective of this core model is to ensure the overall consistency of the solution, to guarantee overall digital continuity (i.e. digital thread).
During this phase, the use of a System Engineering approach can be particularly effective.

Once the core model is established, we switch to an Agile approach for implementing user features. This iterative method allows for continuous delivery of small, incremental changes based on user feedback and testing. Agile promotes flexibility, encourages collaboration, and helps manage changing priorities effectively, leading to an overall better fit solution for the organization.
During this phase, the Solution Architect continues to oversee the process, and update the core model, ensuring the overall coherence of the solution.

3. Minimizing Developments, Maximizing Parameterization

A fundamental principle of today’s PLM implementation methodologies is to limit, and better avoid, custom developments and instead maximize the use of the parameterization capabilities of the implemented software. This approach not only reduces the time and cost of implementation but also makes the system easier to maintain and upgrade.

Custom developments can introduce complexities into the system, making it difficult to upgrade or adapt to changing business needs. On the other hand, parameterization allows for flexibility and scalability, enabling the system to evolve with the organization. Hence, we strive to utilize the software’s existing capabilities to the fullest extent and only accept custom developments when absolutely necessary.

By following this structured approach, we can ensure a smooth, effective PLM implementation that is tailored to customer organization’s needs and easy to maintain in the long run.

4. Working in a Closed Loop

Each business or functional requirement should be benchmarked with the capabilities of the software. This process allows us to quickly identify and close any gaps, preferably without the need for custom development.
Whenever possible, gaps should be closed through parameterization or reformulation of the requirements. It’s important to note that requirements are often expressed as solutions and can often be reformulated in a more effective manner. This nevertheless requires a perfect understanding of the customer’s processes in order to be a credible force of proposal.

By adhering to this approach, such a PLM implementation methodology is designed to deliver an effective, sustainable solution that can evolve with customer’s organization and deliver maximum value from his investment.

PLM, LinkedIn and complexity

I am stunned by the average level of posts on the PLM on Linkedin.
I’m sorry but, in 2023 :

  • Part Number management (significant, non-significant) should no longer be a problem.
  • Revision management should no longer be a question.
  • Configuration management theory should no longer be a question.
  • Notions of EBOMs, MBOMs … should no longer be a question.

So why are there still problems on these topics?

I see 3 reasons:

  • The weight of habits, the conservatism of end users
  • PLM software capabilities
  • The complexity induced by these topics due to the complexity of the managed products

Conservatism of end users

I have been often stunned by the conservatism of the key users during PLM solution designs, especially when it is a second or third generation PLM project. People are aware that things must change, that alignment with standards means the disappearance of secondary functions, but they cannot get used to these ideas. To sum up : everything is allowed, nothing is possible
Integrator is pushed to implement expensive abd useseless function, or in worst cases, models that harm the general coherency of the solution.

Thus, customers find themselves requiring meaningful identifiers (with heavy developments to generate and control these identifiers), more or less wobbly revision management, capability to modify afterwords the class of an object. And, of course, the non respect of these requirements is a show-stopper, even if 95% of the companies do not need them…

PLM software capabalities

Whatever one may think, there are, in 2023, real differences, and real differatiators between the main PLM solutions, especially on two topics, essentialy related to product structure management:

  1. Occurrences, revision and effectivity management
  2. Continuity between the different structures : EBOM, MBOM, Manufacturing Process (routings).

The extended notion of occurrence (relative versus absolute occurrences), strong revision management rules, single structure management engine are key topics.

If these functions are not correctly implemented, the risks of more or less generic workarounds, or heavy specific developments, impacting the core of the solution are likely to prevail, with all the impacts on the maintenance and scalability of the solution.

Complexity

There is a refusal, which turns into a denial, of complexity among users and customer PLM managers

If you mix (and you have to mix !) digital thread between the differents product views (EBOM, MBOM, SBOM …), change management – implying revision management and traceability -, you quickly get something that seems very complex, even looking unmanageable by end users.

Sorry, guys, but even if the functions are well implemented in a PLM solution, configuration management (taken in its broadest sense) is, and will remain a complex topic. Insuring traceability between engineering and manufacturing views of a product is a complex task. To manage it, the PLM solution must be efficient, the PLM implementation must be rigorous, and users must be trained.

What is PLM ?

Let’s try this definition:

  • Management of the Design of a product and of all the processes and artefacts relating to, or which are involved in the lifecycle of the product (specifications, design, manufacturing, operations, maintenance, repair, recycling …).
    In this context, Design includes all the simulation, verification, validation, and quality processes that guarantee the quality of the designs listed above
  • Management of the results of these designs : notion of dynamic product repository. Why dynamic: because it is one of the aims of PLM to manage information about the product « AS IT IS », but also « AS IT WAS » and ‘AS IT WILL BE ». And even in some cases , « AS IT COULD BE ».
  • Management of the projects relating to the designs and repositories mentioned above.

PLM has an holistic view of the Product Information, that goes far beyond the definition of the product and its associated means and processes. It also manages all the intents, all the assumptions, all the studies, all the verifications, relating to the product.

Newer posts »