Mois : septembre 2023

The evolving world of Product Lifecycle Management (PLM) is witnessing constant innovations. With products becoming increasingly complex, PLM systems are striving to streamline the product development process. As we delve into the architecture of PLM systems, we encounter both contradictions and multilayered complexities.

1) Contradictory Constraints:

• A Holistic Approach: Modern PLM systems are shifting towards a holistic model, aiming to capture the entire essence of a product’s lifecycle from ideation to disposal.
• Flexibility & Modularity: In parallel, there’s an emphasis on creating PLM systems that are both agile and modular. This modularity ensures they can swiftly adapt to changing requirements and incorporate new tools.
• Deep Environmental Integration: PLM systems are increasingly becoming integrated into their surrounding environment. This entails a harmonious integration with authoring tools, diverse data sources, and interfaces with systems like ERP (Enterprise Resource Planning), MES (Manufacturing Execution Systems), and MRO (Maintenance, Repair, and Operations).

2) A 3-4 Tiered Logical Architecture:

• Individual Work: This foundational layer is dedicated to integrating authoring tools. The prime objective here is to ensure that each user can access a tailored work environment suitable for their tasks. Furthermore, users should be able to elevate the outcomes of their individual tasks to the team level, ensuring data compatibility and coherence with the overall management system.
• TDM (Team Data Management): This layer focuses on the operational processes at the team or department level. It supervises the management of working environments, consolidates individual contributions, and structures data in a format fit for the enterprise repository.
• EDM (Enterprise Data Management): Serving as the enterprise’s central data repository, the EDM layer encompasses a broad spectrum of views, from initial requirements, system engineering, to physical design, manufacturing and even recycling stages. It’s the heart of the PLM, centralizing data and ensuring its integrity.
  While feeding the TDM layer with all essential data, creating ad hoc working environments, it also consolidates feedback information, defines its applicability and ensures a digital thread of continuity between different views. The goal here is to remain as “neutral” as possible, making it adaptable to different contexts.
• Interface & Formatting Layer: This layer’s primary role is to fine-tune data and channel it efficiently to downstream applications like MES, ERP, and MRO.

The PLM system architecture must describe an environment of profound complexity. Each layer, while fulfilling a distinct function, can be subdivided into several interactive modules. These modules, in unison, manage various data streams, emphasizing the complex yet harmonious nature of PLM systems. Essentially, architecture should be balanced – finely adapting to contradictions and complex design elements.

In the field of Product Lifecycle Management (PLM), the term « Solution Architect » has been increasingly and recklessly tossed around, leading to an inevitable dilution of the role’s specialized nature. What once signified a seasoned professional skilled in PLM’s intricate terrains has now often been misattributed to application engineers, senior configurators, and functional consultants. The intent of this article is to clarify what truly makes a Solution Architect in PLM and why it’s more than just another title.

Misuse of the Title: A Loss in Specialization

It’s become alarmingly frequent for roles like application engineers and senior configurators to receive the title of ‘Solution Architect in PLM.’ While these roles are significant in their areas, they lack the comprehensive skills needed to warrant the title. This lack of specificity is not only confusing but also detrimental to the quality of PLM projects.

Rich Functional Depth and Module Interaction

A genuine Solution Architect is expected to have a profound understanding of the rich functional layers and how different modules interact in the leading PLM solutions. The professional should be well-versed in everything from Computer-Aided Design (CAD) to Material Requirements Planning (MRP), and understand how these modules communicate to provide a cohesive system.

The 10-Year Experience Benchmark

A decade of experience is often touted as the benchmark for Solution Architects in PLM, with a minimum of 4 years focused on the specific solution to be implemented. This is not mere credential inflation. Here’s why:

1. Deep Expertise: Five years on a specific PLM solution allows for a profound understanding of its capabilities and limitations.
2. Risk Mitigation: A seasoned architect is less likely to underestimate challenges and can better predict potential roadblocks.
3. Strategic Insight: Ten years in the field enables a long-term strategic viewpoint, indispensable for the success of PLM projects.
4. Change Management: Experienced architects are better at helping organizations navigate the change a new PLM system will bring.
5. Tech Stack Knowledge: A decade in PLM ensures a comprehensive understanding of the evolving tech stack that surrounds these systems.

The Importance of Multiple Experiences

Having diverse experiences across different PLM projects, industries, or functions can enrich a Solution Architect’s ability to see the bigger picture and to adapt strategies to unique circumstances.

Mastery of PLM Integration in the IT Ecosystem

True Solution Architects are experts in:

• Authoring Tool Integration: This includes CAD for mechanical, electrical, and electronic components, as well as analysis and simulation tools.
• Enterprise System Interface: They should be skilled in interfacing with Manufacturing Execution Systems (MES), Enterprise Resource Planning (ERP), Maintenance, Repair, and Overhaul (MRO), and Industrial Internet of Things (IIoT).

Holistic Vision and Client Constraints

An effective Solution Architect in PLM should possess a holistic view of the entire product lifecycle and be well-equipped to consider client-specific constraints, such as migration challenges and change management necessities.

Conclusion

The role of a Solution Architect in PLM is highly nuanced and demands a unique blend of expertise, experience, and vision. As the complexity of PLM solutions continues to escalate, it’s crucial that the integrity of this essential role be preserved. Organizations should be cautious in title attribution and ensure that those who bear it fully meet the specialized criteria that truly define a Solution Architect in the realm of PLM.

Today, I propose to discuss one significant but often misunderstood term in the realms of PLM, engineering, software development, and project management: Configuration Items (CIs) within  Bills of Materials (BOMs). With a focus on their importance for effectivity management, let’s re-examine these critical elements that lay the foundation for optimized performance and control over organizational assets.

What is a Configuration Item (CI)? A Closer Look

A Configuration Item (CI) is an individual component within a larger system that can be managed independently. However, it’s essential to note that, in most cases, a CI is a supplied subassembly whose configuration is managed by a provider.

Example: Imagine an automobile manufacturing process. The navigation system in the car could be considered a CI. It is supplied by a third-party vendor, and its internal working—say the software, the GPS module, etc.—are configured and controlled by that vendor.

CI: A ‘Grey Box’ in Effectivity Management

Effectivity management focuses on ensuring that the right configurations are used at the right time to meet certain conditions or requirements. A CI serves as a « grey box » in this context, representing a break in effectivity management. The product sees the CI as a single unit and doesn’t vare about its composition.

Why is this significant?

1. Streamlined Complexity: When a CI is treated as a grey box, it allows the primary manufacturer to focus on the integration of the CI without getting entangled in its intricate details.
2. Provider Expertise: The provider who manages the CI is often an expert in that specific subassembly, ensuring that it meets all performance and quality criteria.
3. Simplified Compliance and Documentation: Since the configuration of the CI components is managed at the CI level and not the product level, it makes compliance with standards and regulations more straightforward.

Why a ‘Grey Box’ for Configuration Items?

The term « grey box » is often used in the context of Configuration Items (CIs) to describe a component whose internal workings are not entirely transparent to the end-user or primary manufacturer but are still somewhat understood or defined. Unlike a « black box, » where the internal components and activities are completely unknown, a « grey box » suggests that while the primary manufacturer may not manage or control the CI’s internals, some level of information is available.

1. Provider’s Expertise: The vendor or provider who supplies the CI manages its internals. This management typically involves specialized knowledge that the primary manufacturer may not have, making it more effective for the CI to be a « grey box » from the manufacturer’s perspective.
2. Simplified Integration: Treating the CI as a grey box allows the primary manufacturer to focus on how it fits and functions within the larger system, without getting bogged down by its internal complexity.
3. Effectivity Management: Each CI has its own effectivity and Option/Variant rules managed by the provider. Therefore, the product sees the CI as a self-contained unit, making it easier to manage effectivity at the product level.
4. Flexibility for Special Cases: The « grey box » approach allows for exceptions, such as spare parts management. Even though a CI is generally treated as a self-contained unit, there can be scenarios where one might need to manage its components separately. For example, if a sub-component of a CI needs to be replaced as a spare part, it can still be managed at that level without altering the rest of the CI. This would not be possible if the CI were a completely closed « black box. »

By treating CIs as « grey boxes, » manufacturers maintain a level of flexibility and control without delving too deep into complexities that can be more efficiently managed by the CI’s provider. It offers a balanced approach that can be advantageous in various manufacturing and project management scenarios.

The Role of CIs in Large Assembly BOMs

Bills of Materials (BOMs) list all the components, materials, and sub-assemblies necessary to manufacture a product. For large assembly BOMs, CIs become particularly crucial for a few key reasons:

1. Modularity: Treating CIs as grey boxes allows for more manageable modules within the BOM.
2. Cost and Time Efficiency: Understanding CIs in this manner helps in better budget control and allows for parallel development activities.
3. Risk Containment: Should a problem arise in a CI, it can be addressed without derailing the larger project, as the CI is a self-contained unit managed by the provider.

Understanding the nuances of Configuration Items and their role in effectivity management and large assembly BOMs can be a game-changer. It can significantly impact how efficiently a project progresses and how effectively a product performs.

Your insights and experiences on this subject are welcome!

#PLM #ConfigurationItems #BOMs #EffectivityManagement #ProjectManagement #Engineering

Product Lifecycle Management (PLM) is a term that has become ubiquitous in the world of manufacturing, engineering, and product development. But is this term truly reflective of what it encapsulates? Let’s dig into it.

What is the So-Called PLM?

By its traditional definition, PLM encompasses the holistic approach of managing a product’s life, from conception and design to manufacturing and post-sale service. It involves the systemization of:

• Product design and engineering.
• Means and processes of manufacturing.
• Means and processes for maintenance and repair.
• Means and processes for recycling.

Who Actually Manages the Product Lifecycle?

If we dissect the entire lifecycle of a product, it’s clear that PLM alone doesn’t manage it in its entirety.

ERP:

Enterprise Resource Planning systems handle production planning, procurement, and launching production. From raw materials to finished products, the ERP system provides the overarching framework.

MES:

Manufacturing Execution Systems (MES) track and document the transformation of raw materials through to finished goods. MES ensures that the actual production is as efficient and defect-free as possible.

MRO:

Maintenance, Repair, and Operations (MRO) is focused on maintaining, repairing, and operating the production assets. It involves planning and tracking maintenance tasks, as well as repair operations to ensure the product’s efficient life after manufacturing.

IoT:

Internet of Things (IoT) technology offers real-time tracking and tracing of all information related to the manufacturing, usage, and operation of the product. This includes data acquisition from various sensors embedded in the product, which can be pivotal for lifecycle considerations such as preventive maintenance or upgrades.

Why PLM Should Really be Called PLD: Product Lifecycle Design

Considering these facts, the term « PLM » may be misleading. PLM primarily focuses on the design and development aspects of a product. It’s about enabling a collaborative environment where designs, requirements, and documentation can be centrally managed and accessed. It doesn’t really manage the « whole » lifecycle of a product, but rather sets the stage for other systems like ERP, MES, MRO, and IoT to play their parts. A more appropriate term could be PLD, or Product Lifecycle Design, as it highlights the aspect of design which is the core focus of what we traditionally call PLM.

Conclusion

Language is powerful, and the terms we use should accurately reflect what they represent. Is it time for the industry to reconsider the term PLM? Perhaps, adopting a term like PLD might align more closely with what these systems actually do. What do you think?