Auteur/autrice : Frederic ZELLER (Page 2 of 2)

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 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.

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.