You are currently browsing the category archive for the ‘Change’ category.

I believe we are almost at the end of learning from the past. We have seen how, from an initial serial CAD-driven approach with PDM, we evolved to PLM-managed structures, the EBOM and the MBOM. Or to illustrate this statement, look at the image below, where I use a Tech-Clarity image from Jim Brown.

The image on the right describes perfectly the complementary roles of PLM and ERP. The image on the left shows the typical PDM-approach. PDM feeding ERP in a linear process. The image on the right, I believe it is from 2004, shows the best practice before digital transformation. PLM is supporting product innovation in an iterative approach, pushing released information to ERP for execution.

As I think in images, I like the concept of a circle for PLM and an arrow for ERP. I am always using those two images in discussions with my customers when we want to understand if a particular activity should be in the PLM or ERP-domain.

Ten years ago, the PLM-domain was conceptually further extended by introducing support for products in operations and service. Similar to the EBOM (engineering) and the MBOM (manufacturing), the SBOM (service) was introduced to support product information for products in operation. In theory a full connected cicle.

Asset Lifecycle Management

At the same time, I was promoting PLM-practices for owners/operators to enhance Asset Lifecycle Management. My first post from June 2010 was called: PLM for Asset Lifecycle Management and Asset Development introduces this approach.

Conceptually the SBOM and Asset Lifecycle Management have a lot in common. There is a design product, in this case, an asset (plant, machine) running in the field, and we need to make sure operators have the latest information about the asset. And in case of asset changes, which can be a maintenance operation, a repair or complete overall, we need to be sure the changes are based on the correct information from the as-built environment. This requires full configuration management.

Asset changes can be based on extensive projects that need to be treated like new product development projects, with a staged approach that can take weeks, months, sometimes years. These activities are typical activities performed in PLM-systems, not in MRO-systems that are designed to manage the actual operation. Again here we see the complementary roles of PLM (iterative) and MRO (execution).

Since 2008, I have worked a lot in this environment, mainly in the nuclear and process industry. If you want to learn more about this aspect of PLM, I recommend looking at the PLMpartner website, where Bjørn Fidjeland, in cooperation with SharePLM, published a course on Plant Information Management. We worked together in several projects and Bjørn has done a great effort to describe the logical model to be used instead of a function-feature story.

Ten years ago, we were not calling this concept the “Digital Twin,” as the aim was to provide end-to-end support of asset information from engineering, procurement, and construction towards operation in a coordinated manner. The breaking point in the relation between the EPCs and Owner/Operators is the data-handover – how much of your IP can/do you expose and what is needed. Nowadays, we would call striving for end-to-end data continuity the Digital Thread.

Hot from the press in this context, CIMdata just published a commentary Managing the Digital Thread in Global Value Chains describing Eurostep’s ShareAspace capabilities and experiences in managing an end-to-end information flow (Digital Thread) in a heterogeneous environment based on exchange standards like ISO 10303-239 PLCS.  Their solution is based on what I consider a more modern approach for managing digital continuity compared to the traditional approach I described before. Compare the two images in this paragraph. The first image represents the old/current way with a disconnected handover, the second represents ShareAspace connected approach based on a real digital thread.

The Service BOM

As discussed with Asset Lifecycle Management, there is a disconnect between the engineering disciplines and operations in the field, looking from the point of view of an Asset owner/operator.

Now when we look from the perspective of a manufacturing company that produces assets to be serviced, we can identify a different dataflow and a new structure, the Service BOM (SBOM).

The SBOM provides information on how a product needs to be serviced. What are the parts that require service, and what are the service kits that are possible for that product? For that reason, service engineering should be done in parallel to product engineering. When designing a product, the engineer needs to identify which the wearing parts (always require service in time) and which parts might be serviceable.

There are different ways to look at the SBOM. Conceptually, the SBOM could be created in close relation with the EBOM. At the moment you define your product, you also should specify how the product will be services. See the image below

From this example, it is clear that part standardization and modularization have a considerable benefit for services downstream. What if you have only one serviceable part that applies to many products? The number of parts to have in stock will be strongly reduced instead of having many similar parts that only fit in a single product?

Depending on the type of product, the SBOM can be generic, serving many products in the field. In that case, the company has to deal with catalogs, to be defined in PLM. Or the SBOM can be aligned with the As-Built of a capital product in the field. In that case, the concepts of Asset Lifecycle Management apply. Click on the image to see a clear picture.

The SBOM on its own,  in such an environment, will have links to specific documents, service instructions, operating manuals.

If your PLM-system allows it, extending the EBOM and MBOM with an SBOM is not a complex effort. What is crucial to understand is that the SBOM has its own lifecycle, which can even last longer than the active product sold. So sometimes, manufacturing specifications, related to service parts need to be maintained too, creating a link between the SBOM and potential MBOM(s).

ECM = Enterprise Change Management

When I discussed ECM in my previous post in the context of Engineering Change Management, I got the feedback that nowadays, everyone talks about Enterprise Change Management. Engineering Change Management is old school.

In the past, and even in a 2014 benchmark, a customer had two change management systems. One in PLM and one in ERP, and companies were looking into connecting these two processes. Like the BOM-interaction between PLM and ERP, this is technology-wise, never a real problem.

The real problem in such situations was to come to a logical flow of events. Many times the company insisted that every change should start from the ERP-system as we like to standardize. This means that even an engineering change had to be registered first in the ERP-system

Luckily the reach of PLM has grown. PLM is no longer the engineering tool (IT-system thinking). PLM has become the information backbone for product information all along the product lifecycle. Having the MBOM and SBOM available through a PLM-infrastructure allows organizations to streamline their processes.

Aras – digital thread through connected structures

And in this modern environment, enterprise change management might take place mostly in a PLM-infrastructure. The PLM-infrastructure providing a digital thread, as the Aras picture above illustrates, provides the full traceability to support configuration management.

However, we still have to remember that configuration management and engineering change management, first of all, are based on methodology and processes. Next, the combination of tools to be used will vary.

I like to conclude this topic with a quote from Lee Perrin’s comment on my previous blog post

I would add that aerospace companies implemented CM, to avoid fatal consequences to their companies, but also to their flying customers.

PLM provides the framework within which to carry out Configuration Management. CM can indeed be carried out without PLM, as was done in the old paper-based days. As you have stated, PLM makes the whole CM process much more efficient. I think more transparent too.

Conclusion

After nine posts around the theme Learning from the past to understand the future, I walked through the history of CAD, PDM and PLM in a fast mode, pointing to practices and friction points. In the blogging space, it is hard to find this information as most blog posts are coming from software vendors explaining why their tool is needed. Hopefully, these series have helped many of you to understand a broader context. Now I want to focus on the future again in my upcoming blog posts.

Still, feel free to contact me and discuss methodology topics.

Picture by Christi Wijnen – a good friend and photographer in the Netherlands

In the previous seven posts, learning from the past to understand the future, we have seen the evolution from manual 2D drawing handling. Next, the emerge of ERP and CAD followed by data management systems (PDM/PLM) and methodology (EBOM/MBOM) to create an infrastructure for product data from concept towards manufacturing.

Before discussing the extension to the SBOM-concept, I first want to discuss Engineering Change Management and Configuration Management.

ECM and CM – are they the same?

Often when you talk with people in my PLM bubble, the terms Change Management and Configuration Management are mixed or not well understood.

When talking about Change Management, we should clearly distinguish between OCM (Organizational Change Management) and ECM (Engineering Change Management). In this post, I will focus on Engineering Change Management (ECM).

When talking about Configuration Management also here we find two interpretations of it.

The first one is a methodology describing technically how, in your PLM/CAD-environment, you can build the most efficient way connected data structures, representing all product variations. This technology varies per PLM/CAD-vendor, and therefore I will not discuss it here. The other interpretation of Configuration Management is described on Wiki as follows:

Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.

This is also the area where I will focus on this time.

And as-if great minds think alike and are synchronized, I was happy to see Martijn Dullaart’s recent blog post, referring to a poll and follow-up article on CM.

Here Martijn precisely touches the topic I address in this post. I recommend you to read his post: Configuration Management done right = Product-Centric first and then follow with the rest of this article.

Engineering Change Management

Initially, engineering change management was a departmental activity performed by engineering to manage the changes in a product’s definition. Other stakeholders are often consulted when preparing a change, which can be minor (affecting, for example, only engineering) or major (affecting engineering and manufacturing).

The way engineering change management has been implemented varies a lot. Over time companies all around the world have defined their change methodology, and there is a lot of commonality between these approaches. However, terminology as revision, version, major change, minor change all might vary.

I described the generic approach for engineering change processes in my blog post: ECR / ECO for Dummies from 2010.

The fact that companies have defined their own engineering change processes is not an issue when it works and is done manually. The real challenge came with PDM/PLM-systems that need to provide support for engineering change management.

Do you leave the methodology 100 % open, or do you provide business logic?

I have seen implementations where an engineer with a right-click could release an assembly without any constraints. Related drawings might not exist, parts in the assembly are not released, and more. To obtain a reliable engineering change management process, the company had to customize the PLM-system to its desired behavior.

An exercise excellent for a system integrator as there was always a discussion with end-users that do not want to be restricted in case of an emergency  (“we will complete the definition later” / “too many clicks” / “do I have to approve 100 parts ?”). In many cases, the system integrator kept on customizing the system to adapt to all wishes. Often the engineering change methodology on paper was not complete or contained contradictions when trying to digitize the processes.

For that reason, the PLM-vendors that aim to provide Out-Of-The-Box solutions have been trying to predefine certain behaviors in their system. For example, you cannot release a part, when its specifications (drawings/documents) are not released. Or, you cannot update a released assembly without creating a new revision.

These rules speed-up the implementation; however, they require more OCM (Organizational Change Management) as probably naming and methodology has to change within the company. This is the continuous battle in PLM-implementations. In particular where the company has a strong legacy or lack of business understanding, when implementing PLM.

There is an excellent webcast in this context on Minerva PLM TV – How to Increase IT Project Success with Organizational Change Management.

Click on the image or link to watch this recording.

Configuration Management

When we talk about configuration management, we have to think about managing the consistency of product data along the whole product lifecycle, as we have seen from the Wiki-definition before.

Wiki – the configuration Activity Model

Configuration management existed long before we had IT-systems. Therefore, configuration management is more a collection of activities (see diagram above) to ensure the consistency of information is correct for any given product. Consistent during design, where requirements match product capabilities. Consistent with manufacturing, where the manufacturing process is based on the correct engineering specifications. And consistent with operations, meaning that we have the full definition of product in the field, the As-Built, in correct relation to its engineering and manufacturing definition.

Source: Configuration management in aerospace industry

This consistency is crucial for products where the cost of an error can have a massive impact on the manufacturer. The first industries that invested heavily in configuration management were the Aerospace and Defense industries. Configuration management is needed in these industries as the products are usually complex, and failure can have a fatal impact on the company. Combined with many regulatory constraints, managing the configuration of a product and the impact of changes is a discipline on its own.

Other industries have also introduced configuration management nowadays. The nuclear power industry and the pharmaceutical industry use configuration management as part of their regulatory compliance. The automotive industry requires configuration management partly for compliance, mainly driven by quality targets. An accident or a recall can be costly for a car manufacturer. Other manufacturing companies all have their own configuration management strategies, mainly depending on their own risk assessment. Configuration management is a pro-active discipline – it costs money – time, people and potential tools to implement it. In my experience, many of these companies try to do “some” configuration management, always hoping that a real disaster will not happen (or can happen). Proper configuration management allows you to perform reliable impact analysis for any change (image above)

What happens in the field?

When introducing PLM in mid-market companies, often, the dream was that with the new PLM-system configuration, management would be there too.

Management believes the tools will fix the issue.

Partly because configuration management deals with a structured approach on how to manage changes, there was always confusion with engineering change management. Modern PLM-systems all have an impact analysis capability. However, most of the time, this impact analysis only reaches the content that is in the PLM-system. Configuration Management goes further.

If you think that configuration management is crucial for your company, start educating yourselves first before implementing anything in a tool. There are several places where you can learn all about configuration management.

  • Probably the best-known organization is IpX (Institute for Process Excellence), teaching the CM2 methodology. Have a look here: CM2 certification and courses
  • Closely related to IpX, Martijn Dullaart shares his thoughts coming from the field as Lead Architect for Enterprise Configuration Management at ASML (one of the Dutch crown jewels) in his blog: MDUX
  • CMstat, a configuration and data management solution provider, provides educational posts from their perspective. Have a look at their posts, for example, PLM or PDM or CM
  • If you want to have a quick overview of Configuration Management in general, targeted for the mid-market, have a look at this (outdated) course: Training for Small and Medium Enterprises on CONFIGURATION MANAGEMENT. Good for self-study to get an understanding of the domain.

 

To summarize

In regulated industries, Configuration Management and PLM are a must to ensure compliance and quality. Configuration management and (engineering) change management are, first of all, required methodologies that guarantee the quality of your products. The more complex your products are, the higher the need for change and configuration management.

PLM-systems require embedded engineering change management – part of the PDM domain. Performing Engineering Change Management in a system is something many users do not like, as it feels like overhead. Too much administration or too many mouse clicks.

So far, there is no golden egg that performs engineering change management automatically. Perhaps in a data-driven environment, algorithms can speed-up change management processes. Still, there is a need for human decisions.

Similar to configuration management. If you have a PLM-system that connects all the data from concept, design, and manufacturing in a single environment, it does not mean you are performing configuration management. You need to have processes in place, and depending on your product and industry, the importance will vary.

Conclusion

In the first seven posts, we discussed the design and engineering practices, from CAD to EBOM, ending with the MBOM. Engineering Change Management and, in particular, Configuration Management are methodologies to ensure the consistency of data along the product lifecycle. These methodologies are connected and need to be fit for the future – more on this when we move to modern model-based approaches.

Closing note:

While finishing this blog post today I read Jan Bosch’s post: Why you should not align. Jan touches the same topic that I try to describe in my series Learning from the Past ….., as my intention is to make us aware that by holding on to practices from the past we are blocking our future. Highly recommended to read his post – a quote:

The problem is, of course, that every time you resist change, you get a bit behind. You accumulate some business, process and technical debt. You become a little less “fitting” to the environment in which you’re operating

In the series learning from the past to understand the future, we have almost reached the current state of PLM before digitization became visible. In the last post, I introduced the value of having the MBOM preparation inside a PLM-system, so manufacturing engineering can benefit from early visibility and richer product context when preparing the manufacturing process.

Does everyone need an MBOM?

It is essential to realize that you do not need an EBOM and a separate MBOM in case of an Engineering To Order primary process. The target of ETO is to deliver a unique customer product with no time to lose. Therefore, engineering can design with a manufacturing process in mind.

The need for an MBOM comes when:

  • You are selling a specific product over a more extended period of time. The engineering definition, in that case, needs to be as little as possible dependent on supplier-specific parts.
  • You are delivering your portfolio based on modules. Modules need to be as long as possible stable, therefore independent of where they are manufactured and supplier-specific parts. The better you can define your modules, the more customers you can reach over time.
  • You are having multiple manufacturing locations around the world, allowing you to source locally and manufacture based on local plant-specific resources. I described these options in the previous post

The challenge for all companies that want to move from ETO to BTO/CTO is the fact that they need to change their methodology – building for the future while supporting the past. This is typically something to be analyzed per company on how to deal with the existing legacy and installed base.

Configurable EBOM and MBOM

In some previous posts, I mentioned that it is efficient to have a configurable EBOM. This means that various options and variants are managed in the same EBOM-structure that can be filtered based on configuration parameters (date effectivity/version identifier/time baseline). A configurable EBOM is often called a 150 % EBOM

The MBOM can also be configurable as a manufacturing plant might have almost common manufacturing steps for different product variants. By using the same process and filtered MBOM, you will manufacture the specific product version. In that case, we can talk about a 120 % MBOM

Note: the freedom of configuration in the EBOM is generally higher than the options in the configurable MBOM.

The real business change for EBOM/MBOM

So far, we have discussed the EBOM/MBOM methodology. It is essential to realize this methodology only brings value when the organization will be adapted to benefit from the new possibilities.

One of the recurring errors in PLM implementations is that users of the system get an extended job scope, without giving them the extra time to perform these activities. Meanwhile, other persons downstream might benefit from these activities. However, they will not complain. I realized that already in 2009, I mentioned such a case: Where is my PLM ROI, Mr. Voskuil?

Now let us look at the recommended business changes when implementing an EBOM/MBOM-strategy

  1. Working in a single, shared environment for engineering and manufacturing preparation is the first step to take.

Working in a PLM-system is not a problem for engineers who are used to the complexity of a PDM-system. For manufacturing engineers, a PLM-environment will be completely new. Manufacturing engineers might prepare their bill of process first in Excel and ultimately enter the complete details in their ERP-system. ERP-systems are not known for their user-friendliness. However, their interfaces are often so rigid that it is not difficult to master the process. Excel, on the other side, is extremely flexible but not connected to anything else.

And now, this new PLM-system requires people to work in a more user-friendly environment with limited freedom. This is a significant shift in working methodology. This means manufacturing engineers need to be trained and supported  over several months. Changing habits and keep people motivated takes energy and time. In reality, where is the budget for these activities?  See my 2016 post: PLM and Cultural Change Management – too expensive?

  1. From sequential to concurrent

Once your manufacturing engineers are able to work in a PLM-environment, they are able to start the manufacturing definition before the engineering definition is released. Manufacturing engineers can participate in design reviews having the information in their environment available. They can validate critical manufacturing steps and discuss with engineers potential changes that will reduce the complexity or cost for manufacturing. As these changes will be done before the product is released, the cost of change is much lower. After all, having engineering and manufacturing working partially in parallel will reduce time to market.

Reducing time to market by concurrent engineering

One of the leading business drivers for many companies is introducing products or enhancements to the market. Bringing engineering and manufacturing preparation together also means that the PLM-system can no longer be an engineering tool under the responsibility of the engineering department.

The responsibility for PLM needs to be at a level higher in the organization to ensure well-balanced choices. A higher level in the organization automatically means more attention for business benefits and less attention for functions and features.

From technology to methodology – interface issues?

The whole EBOM/MBOM-discussion often has become a discussion related to a PLM-system and an ERP-system. Next, the discussion diverted to how these two systems could work together, changing the mindset to the complexity of interfaces instead of focusing on the logical flow of information.

In an earlier PI Event in München 2016, I lead a focus group related to the PLM and ERP interaction. The discussion was not about technology, all about focusing on what is the logical flow of information. From initial creation towards formal usage in a product definition (EBOM/MBOM).

What became clear from this workshop and other customer engagements is that people are often locked in their siloed way of thinking. Proposed information flows are based on system capabilities, not on the ideal flow of information. This is often the reason why a PLM/ERP-interface becomes complicated and expensive. System integrators do not want to push for organizational change, they prefer to develop an interface that adheres to the current customer expectations.

SAP has always been promoting that they do not need an interface between engineering and manufacturing as their data management starts from the EBOM. They forgot to mention that they have a difficult time (and almost no intention) to manage the early ideation and design phase. As a Dutch SAP country manager once told me: “Engineers are resources that do not want to be managed.” This remark says all about the mindset of ERP.

After overlooking successful PLM-implementations, I can tell the PLM-ERP interface has never been a technical issue once the methodology is transparent. A company needs to agree on logical data flow from ideation through engineering towards design is the foundation.

It is not about owning data and where to store it in a single system. It is about federated data sets that exist in different systems and that are complementary but connected, requiring data governance and master data management.

The SAP-Siemens partnership

In the context of the previous paragraph, the messaging around the recently announced partnership between SAP and Siemens made me curious. Almost everyone has shared an opinion about the partnership. There is a lot of speculation, and many questions were imaginarily answered by as many blog posts in the field. Last week Stan Przybylinski shared CIMdata’s interpretations in a webinar Putting the SAP-Siemens Partnership In Context, which was, in my opinion, the most in-depth analysis I have seen.

For what it is worth, my analysis:

  • First of all, the partnership is a merger of slide decks at this moment, aiming to show to a potential customer that in the SAP/Siemens-combination, you find everything you need. A merger of slides does not mean everything works together.

  • It is a merger of two different worlds. You can call SAP a real data platform with connected data, where Siemens offering is based on the Teamcenter backbone providing a foundation for a coordinated approach. In the coordinated approach, the data flexibility is lower. For that reason, Mendix is crucial to make Siemens portfolio behave like a connected platform too.
    You can read my doubts about having a coordinated and connected system working together (see image above). It was my #1 identified challenge for this decade: PLM 2020 – PLM the next decade (before COVID-19 became a pandemic and illustrated we need to work connected)
  • The fact that SAP will sell TC PLM and Siemens will sell SAP PPM seems like loser’s statement, meaning our SAP PLM is probably not good enough, or our TC PPM capabilities are not good enough. In reality, I believe they both should remain, and the partnership should work on logical data flows with data residing in two locations – the federated approach. This is how platforms reside next to each other instead of the single black hole.

  • The fact that standard interfaces will be developed between the two systems is a subtle sales argument with relatively low value. As I wrote in the “from technology to methodology”-paragraph, the challenges are in the organizational change within companies. Technology is not the issue, although system integrators also need to make a living.
  • What I believe makes sense is that both SAP and Siemens, have to realize their Industry 4.0 end-to-end capabilities. It is a German vision now for several years and it is an excellent vision to strive for. Now it is time to build the two platforms working together. This will be a significant technical challenge mainly for Siemens as its foundation is based on a coordinated backbone.
  • The biggest challenge, not only for this partnership, is the organizational change within companies that want to build an end-to-end connected solution. In particular, in companies with a vast legacy, the targeted industries by the partnership, the chasm between coordinated legacy data and intended connected data is enormous. Technology will not fix it, perhaps smoothen the pain a little.

 

Conclusion

With this post, we have reached the foundation of the item-centric approach for PLM, where the EBOM and MBOM are managed in a real-time context. Organizational change is the biggest inhibitor to move forward. The SAP-Siemens partnership is a sales/marketing approach to create a simplified view for the future at C-level discussions.
Let us watch carefully what happens in reality.

Next time potentially the dimension of change management and configuration management in an item-centric approach.
Or perhaps Martijn Dullaart will show us the way before, following up on his tricky poll question

 

In this post in the series Learning from the past to understand the future, I want to leave the 3D CAD structures behind. But before doing so, I want to mention some of the lessons learned:

In Part 1:  “Intelligent” drawing numbers were the source for “intelligent” part numbers as often there was a one-to-one relationship between the drawing and the part(s) on a drawing.

In Part 2: 3D CAD has been introduced in the automotive and aerospace industry due to process optimization, where a 3D CAD environment created better collaboration possibilities (DMU). The introduction of 3D CAD in the mid-market was different. Here 3D CAD is used as an engineering tool, not changing any processes.

The complexity grew because also file names needed to be managed, introducing the need for PDM-systems.

In Part 3: we discussed the challenges of working with file-based 3D CAD structures. The versioning problem with check-in/check-out of structure in particular in the case of data reuse. Here the best practice was introduced to have physical parts with a different lifecycle than 3D CAD parts and assemblies.

Now engineers need to create valid configurations based on links between the physical part and the 3D/2D object. This requires a PDM-system with BOM and CAD-files as standard information objects.

In Part 4: we discussed the relations between the BOM and 3D CAD structures without neglecting the fact the 2D Drawing is still the primary legal information carrier for manufacturing/suppliers. The point discussed in this post was the fact that most companies used a kind of ETO-approach. Starting from the 3D CAD-system, adding sometimes manufacturing parts in this structure, to generate a BOM that can be served as input for the ERP-system.

I want to follow up from the last conclusion:

Changing from ETO to CTO requires modularity and a BOM-driven approach. Starting from a 3D CAD-structure can still be done for the lowest levels – the modules, the options. In a configure to order process, it might not be relevant anymore to create a full 3D-representation of the product.

Starting from a conceptual structure

Most companies that deliver products to the market do not start from scratch, as we discussed. They will start from either copying an existing product definition (not recommend) or trying to manage the differences between them, meanwhile keeping shared components under revision control.

This cannot be done based on 3D CAD-structures anymore. At that time (we are in the early 2000s) in the mid-market, the PDM-system was used to manage these structures, in particular, they used the BOM-capabilities.

The BOM-structure was often called the EBOM, as engineers were defining the EBOM. But is it really an EBOM? Let us have a look wat defines an EBOM.

What characterizes an EBOM?

There are many personal definitions of what is considered as an EBOM.  Also, the Wiki-definition here does not help us a lot. So here is my personal 2004 definition:

  • The EBOM reflects the engineering view of a product and, therefore, can have a logical structure of assemblies and subassemblies based on functionality, modularity, and standardization.
  • The EBOM is a part structure specifying a product from its design intent, specifying parts, materials, tolerances, finishing.
  • The EBOM-structure is allowing multidisciplinary teams to work together on a joint definition of the product

The picture below illustrates the above definition.

In this EBOM-structure, we see that the first two levels actually are more a logical division of functional groups, either as units, product/discipline-specific definitions (cabling/software). These components should not be in the EBOM if you have support for logical structures in your PLM-environment. However, in 2004 – PLM was not that mature in the mid-market, and this approach was often chosen.

If we look at the Line Feed module, which could also be used in other products, there is the typical mechanical definition and in parallel the electrical definition. Having them inside a single EBOM gives the advantage of being able to do a “where-used” and status/impact-analysis.

1 – Purchased parts

Motor P280 is an interesting EBOM-part to consider. This motor is required; however, in an EBOM, you should not specify the supplier part number directly. As supplier part availability and preference will change over time, you do not want to revise the EBOM every time a supplier part gets changed.

Therefore, the Motor P280 should have an internal part number in the EBOM. Next, it will be engineering that specifies which motors fulfill the need for Motor P280.   Preferably they will create an Approved Manufacturing List for this motor to give manufacturing/purchasing the flexibility to decide per order where to purchase the motor and from which supplier.

The relation between the Approved Manufacturing List and the Approved Vendor List is shown in the diagram above.

Or follow the link to this image to read more in Arena’s glossary. In particular, for electronic components, this concept is needed as high-level specifications for electronic parts might be the same.

However, the details (tolerances/environment) can be decisive, which component is allowed. Besides, due to the relatively short lifecycle of electronic components, the EBOM needs to be designed in such a manner to anticipate changes in suppliers.

You can only benefit from this approach if, from the beginning of your designs, there are no supplier-specific parts in your EBOM. For Engineering, to Order companies that want to become more Build to Order, this is a challenging but critical point to consider.

Note: The functional characteristics for the motor will come from the electrical definition, and through a reference designator, we create the link between the functional definition and the physical implementation in the product.

2 – Make Parts

Secondly, if we look to the conveyor block D1020 rev A, this block is a make part, with probable a whole assembly of parts below it. As it is a make part, there is at least an assembly drawing and, more likely, a related technical data package linked to D1020 rev A. Make parts still carry a revision as here the Form-Fit-Function discussion can be used when implementing a change of the part.

Note: I used for the final assembly drawing the same number scheme as this is how most companies work. However, in my previous post, I described that if you have a PDM-system in place, the numbering can be different. Maintaining the relations between a part and the related drawing is, in this case, crucial.

The Configured EBOM

The image on the left, we used to illustrate the typical mid-market EBOM in a PDM-system, will become more complicated if we also add options and variants to the EBOM. I assume you know the difference between a variant and an option.

In this case, the EBOM the definition for the full product range. Actually, the top part of the EBOM does not exist as an instance. It is the placeholder to select a resolved EBOM for a specific product configuration.  For the ease of use, I have simplified the initial diagram, now zooming in on variants and options, apologizing for my artistic capabilities as the purpose of a blog is different from a book.

If we look at the diagram, this configured structure contains variants and options.

First, on the logical definition, we see a new grouping. There are two types of Line Feed available, one specific for the X-123 and a later, more generic designed LF100, suitable for all X-1nn variants.

As the LF100 is more generic designed, the customer can select between two motors, the standard P280 and the more advanced version P360, with better service capabilities.

For the Line Feed LF200, there is an option to order a Noise Reduction Cover. It was sold once to an existing customer, and as the cover fits all X-123, it has been linked here as an option to the X-123 definition. So, the customer solution with the Noise Reduction Cover does not have an isolated, copied structure in the EBOM.

Also, in the Logical Structure, we see there is a cabling definition for the X-123 or the default cabling set for all other products.

The diagram illustrates what many mid-market companies have been doing more or less in their PDM-system to avoid copying of EBOM structures per customer order.
It is an example of where a tool (the PDM-system) is slowly abused for administrative reasons. Let me explain why.

The link between Products and (E)BOMs

If we look at the upper part of the configured EBOM structure, this is a logical product definition. Or to say it in different words, it is a portfolio definition, which products and modules a company can sell to the market. Some of the grouping of the portfolio is purely based on business reasons, which products and options do we want to sell.

In most companies, the product portfolio is managed in (marketing) documents without a direct connection to the engineering world. However, we will see in an upcoming post, this relation is crucial for a digital enterprise. Meanwhile, look at on old blog post: Products, BOMs and Parts if you want to be faster

The Engineering definition below the red dashed line is a real EBOM, representing the engineering definition of a system, a module, or a component. When these systems and modules are defined in a single structure that can be filtered based on selection criteria, we talk about a Configured EBOM or sometimes a 150 % EBOM.

Each of the components in the configured EBOM can have a related 3D CAD structure or specification that can be developed traditionally.

The result of a resolved EBOM is a variant that can be delivered to the customer. In this EBOM-driven approach, there is not always a full 3D-representation of the customer product.

Again, size (1500+) words make me stop this story, where next time we will go from product to EBOM and introduce the need for an MBOM in specific industries.

Conclusion

A pure EBOM only specifies a product and contains all relevant information in context – designs & specifications. The EBOM should not be mixed or confused with a logical grouping, belonging to a portfolio definition (even if the system allows you to do it)

On my previous post shared on LinkedIn Ilan Madjar, a long-time PLM colleague reacted with the following point (full thread here)

Ilan is pointing to the right challenge in many companies. Changing the way you work is though exercise and requires a good understanding, vision, and execution to move forward. Do not trust the tool to work for you – it is about human understanding and process re-engineering to be more efficient. And if you do not practice this on the basic PDM-level as discussed so far, imagine the impossibility of going through a digital transformation.

 

This time a short post (for me) as I am in the middle the series “Learning from the past to understand the future” and currently collecting information for next week’s post. However, recently Rob Ferrone, the original Digital Plumber, pointed me to an interesting post from Scott Taylor, the Data Whisperer.

In code: The Virtual Dutchman discovered the Data Whisperer thanks to the original Digital Plumber.

Scott’s article with the title: “Data Management Hasn’t Failed, but Data Management Storytelling Has” matches precisely the discussion we have in the PLM community.

Please read his article, and just replace the words Data Management by PLM, and it could have been written for our community. In a way, PLM is a specific application of data management, so not a real surprise.

Scott’s conclusions give food for thought in the PLM community:

To win over business stakeholders, Data Management leadership must craft a compelling narrative that builds urgency, reinvigorates enthusiasm, and evangelizes WHY their programs enable the strategic intentions of their enterprise. If the business leaders whose support and engagement you seek do not understand and accept the WHY, they will not care about the HOW. When communicating to executive leadership, skip the technical details, the feature functionality, and the reference architecture and focus on:

  • Establishing an accessible vocabulary
  • Harmonizing to a common voice
  • Illuminating the business vision

When you tell your Data Management story with that perspective, it can end happily ever after.

It all resonates well with what I described in the PLM ROI Myth – it is clear that when people hear the word Myth, they have a bad connotation, same btw for PLM.

The fact that we still need to learn storytelling is because most of us are so much focused on technology and sometimes on discovering the new name for PLM in the future.

Last week I pointed to a survey from the PLMIG (PLM Interest Group) and XLifcycle, inviting you to help to define the future definition of PLM.

You are still welcome here: Towards a digital future: the evolving role of PLM in the future digital world.

Also, I saw a great interview with Martin Eigner on Minerva PLM TV interview by Jennifer Moore. Martin is well known in the PLM world and has done foundational work for our community

. According to Jennifer, he is considered as The Godfather of PLM.  This tittle fits nicely in today’s post. Those who have seen his presentations in recent years will remember Martin is talking about SysLM (System Lifecycle Management) as the future for PLM.

It is an interesting recording to watch – click on the image above to see it. Martin explains nicely why we often do not get the positive feedback from PLM implementations – starting at minute 13 for those who cannot wait.

In the interview, you will discover we often talk too much about our discipline capabilities where the real discussion should be talking business. Strategy and objectives are discussed and decided at the management level of a company. By using storytelling, we can connect to these business objectives.

The end result will be more likely that a company understands why to invest significantly in PLM as now PLM is part of its competitiveness and future continuity.

Conclusion

I shared links to two interesting posts from the last weeks. Studying them will help you to create a broader view. We have to learn to tell the right story. People do not want PLM – they have personal objectives. Companies have business objectives, and they might lead to the need for a new and changing PLM. Connecting to the management in an organization, therefore, is crucial.

Next week again more about learning from the past to understand the future

Two weeks ago, I wrote about the PLM Innovation Forum, a virtual conference organized by TECHNIA, where I described some of my experiences with the event and the different ways of interaction in a virtual conference.

The content remains available till May 31st, so I had time to stroll through the rich content offered. In particular, if you are already familiar with the Dassault Systèmes & TECHNIA offerings, the content is extremely rich.

From the “auditorium“, I selected four presentations that have a logical relation to each other. I believe they will help you understand some of the aspects of PLM independent of the PLM vendor. Let’s start.

Value-Driven Implementation

In this session, Johannes Storvik, you can identify three parts. In the first part, Johannes talks about how to select the best PLM-approach, discussing the various options from custom, standardized, or even fully Out-Of-The-Box, comparing these options with building types. An interesting comparison, however, there is a risk with this approach.

Many companies are now stating they only need a collection of Commercial of the Shelf (COTS) systems and prefer only OOTB. The challenge with this approach is that you start from the tools, constraining the business from the start.

I would state start from your business goals, and ultimately they will lead to requirements for the tools. And then, if available, you find solutions that require no or minor adaptation. Starting from the business is crucial, and Johannes elaborates more on that.

The second part discussing PLM benefits, and if you are looking for confirmation PLM brings value, have a look at the topics, areas, and numbers mentioned. Most benefits and areas are quite traditional, related to a coordinated organization (if you follow my coordinated to connected typology).

The last part, connecting the dots from business to enablers, a Benefits Dependency Network, is a methodology that I recommend. Originally developed by Cranfield School of Management, it allows you to connect your PLM-needs to the company’s business needs and strategies. You can read more about this methodology in this HBR article: A tool to map your next digital initiative.

Benefits Dependency Network: note the potential storyline you can build

My experience from this methodology is that it allows you to extract one, two perhaps three storylines. These storylines then help you to explain why the PLM enablers are needed connecting to a business case into one understandable storyline, suitable for all levels in the company

With Johannes, we went from PLM-characteristics towards connecting PLM to the business and exec management, making PLM implicit visible at the management level. Now the next step.

Industrialization of the Construction Industry

The theme of this session might be misleading. Arto Tolonen, from the LETHO group, has a long history in PLM as a practitioner and at the University of Oulu, where he specialized in Product Data Management and Product Portfolio Management.

The last part of his presentation is dealing with transformational thinking for the construction industry from a one-off construction towards thinking in repeatable processes, using PLM practices. With his dry humor, he asks:
“Why are all buildings prototypes ?” and more.

For many years, I have been preaching PLM practices to be valuable for other industries too. See this 2013 post: PLM for all industries?  The most common challenge was to respond to the question:  “What does your tool do?”   PLM practices only become valuable if you think in repeatable processes.

The exciting part is when Arto talks about the disconnect between the exec level in an organization and reality in the field. Understanding how products are performing, and how each product contributes to the profit of the company, is usually blurred with subjective information. Your company’s love baby might be the worst performer but never dropped from the product portfolio for sentimental reasons.

Arto explains the importance of (digital) portfolio management, connecting the economic data with the technical data. And by doing so, use portfolio management to drive the development of new offerings based on market needs and numbers. Or to decommission products.

I am fully aligned with Arto and believe that a digital transformation should include a connected product portfolio management environment, driving new development projects. Product Portfolio management is not the same as BOM-management.

The portfolio items are facing the outside world, your customers. How the products are built, is defined in the inside world of BOMs and design data.

Now combining product portfolio management with product management makes a lot of more sense if you are going to use it to support the modularization of your products. Based on solution platforms, you can design your products to become modular, leading to a lot of business benefits.

With Arto, we discovered the need to have digital portfolio management connecting business performance and product development. Another implicit reason for PLM to your business explained with humor. Now the next step.

Modularization

Closely related to product portfolio management is the topic of modularization.  If you want to optimize your offering with a great variety of choices for your customers, without spending more time to develop an individual solution, you need to implement modularization for your products.

Daniel Strandhammar van Brick Strategy explains this topic in his session. So many companies I am working with a claim that they want to move from and ETO (Engineering To Order) model to a CTO (Configure To Order) model. Unfortunately, many of them keep on talking about that without making steps towards more configurable products.

Although in many PLM-infrastructures, the capabilities exist to support the modularity of a product portfolio, it requires thinking and analysis outside the tools. The tools are there to support the modularization. Still, it depends on your engineering teams to transform the company’s portfolio step by step into a more modular product.  Brick Strategy is typical such a company that can help you and coach you in a modularization process.

If you look at the benefits Daniel is mentioning related to modularization, these benefits are significant. However, as Daniel also explains per type of business, the effects of modularization might be different, still in every situation worth to invest.

It is interesting to know that many of the modularization methodologies come from Scandinavian countries. Perhaps a region, with companies like Scania (master of modularization), IKEA and others leading the ways towards modularization. Is it a surprise that LEGO is also a Scandinavian company?

Daniel continues by explaining how a roadmap for modularization could look like. If you are struggling with that point, have a look at the video. It is a crucial part of the story.

Note: There is also a presentation from Anders Malmberg fro Scania talking about their Starling project. Not particularly related to modularization, more related to how to organize significant PLM transformations.

With Daniel’s presentation, we see the relation between a product portfolio and modularization. Another implicit reason for PLM to improve your business explained. Now let’s do it.

 

Making Multi-view BOM a reality

My ultimate dream was that James Roche from CIMdata would complete the storyline. We went from business initiatives through product portfolio management and modularization through a flow of organizational topics to enhance your business outcome using PLM.

With James, I was hoping we now would get the final necessary part, the need for a multi-view BOM, and how to establish this. As I mentioned before with modularization, many companies started with a kind of ETO-approach to deliver solutions for their customers. The downside of this approach is that, when designing a product, the manufacturing process was already leading the way the BOM will be structured. Many of the companies that I work with are in this situation. There is no clear EBOM and MBOM, the situation is a kind of hybrid BOM, blocking modularity and multi-plant manufacturing.

James’s presentation unfortunate started with a 10 min technical delay, and then the next part is crucial to understand. He explains nicely what it means to have a “hybrid” single BOM and more to a multi-view EBOM/MBOM. James addressed this topic, both using an example looking at it from a technological and organizational view.

As James is the CIMdata Practice Director for Aerospace & Defense, this was the industry in focus and even example provided above is not necessarily the best solution for every A&D company. Organizational change and managing risks are crucial in such a transition, and that is where James spent even more time. It would be great, and I consider it one of my next blog options, to discuss and share best practices for other types of industries. Is there always a need for a multi-view BOM and are they all the same?

With James we concluded the PLM value story, making it my fourth pick of the PLMIF conference, giving you an end-to-end storyline why PLM is important and how it is connected to your business results.

 

Conclusion

The four presentations that I highlighted here show a storyline that is crucial to understand and pitch when you talk about the business value of PLM. It is not about technical features and functions. It is part of a business strategy, building the right portfolio, manage it in a modular manner, and use multiple BOM views to optimize the delivery of your products.

 

Note: two more weeks to see the full presentations of PLMIF – go and have a look in case you haven’t done so: http://www.plmif.org

 

 

 

Life goes on, and I hope you are all staying safe while thinking about the future. Interesting in the context of the future, there was a recent post from Lionel Grealou with the title: Towards PLM 4.0: Hyperconnected Asset Performance Management Framework.

Lionel gave a kind of evolutionary path for PLM. The path from PLM 1.0 (PDM) ending in a PLM 4.0 definition.  Read the article or click on the image to see an enlarged version to understand the logical order. Interesting to mention that PLM 4.0 is the end target, for sure there is a wishful mind-mapping with Industry 4.0.

When seeing this diagram, it reminded me of Marc Halpern’s diagram that he presented during the PDT 2015 conference. Without much fantasy, you can map your company to one of the given stages and understand what the logical next step would be. To map Lionel’s model with Marc’s model, I would state PLM 4.0 aligns with Marc’s column Collaborating.

In the discussion related to Lionel’s post, I stated two points. First, an observation that most of the companies that I know remain in PLM 1.0 or 2.0, or in Marc’s diagram, they are still trying to reach the level of Integrating.

Why is it so difficult to move to the next stage?

Oleg Shilovitsky, in a reaction to Lionel’s post, confirmed this. In Why did manufacturing stuck in PLM 1.0 and PLM 2.0? Oleg points to several integration challenges, functional and technical. His take is that new technologies might be the answer to move to PLM 3.0, as you can read from his conclusion.

What is my conclusion?

There are many promising technologies, but integration is remaining the biggest problem for manufacturing companies in adopting PLM 3.0. The companies are struggling to expand upstream and downstream. Existing vendors are careful about the changes. At the same time, very few alternatives can be seen around. Cloud structure, new data management, and cloud infrastructure can simplify many integration challenges and unlock PLM 3.0 for future business upstream and especially downstream. Just my thoughts…

Completely disconnected from Lionel’s post,  Angad Sorte from Plural Nordic AS wrote a LinkedIn post: Why PLM does not get attention from your CEO. Click on the image to see an enlarged version, that also neatly aligns with Industry 4.0. Coincidence, or do great minds think alike? Phil Collins would sing: It is in the air tonight

Angad’s post is about the historical framing of PLM as a system, an engineering tool versus a business strategy. Angrad believes once you have a clear definition, it will be easier to explain the next steps for the business. The challenge here is: Do we need, or do we have a clear definition of PLM? It is a topic that I do not want to discuss anymore due to a variety of opinions and interpretations.  An exact definition will never lead to a CEO stating, “Now I know why we need PLM.”

I believe there are enough business proof points WHY companies require a PLM-infrastructure as part of a profitable business. Depending on the organization, it might be just a collection of tools, and people do the work. Perhaps this is the practice in small enterprises?

In larger enterprises, the go-to-market strategy, the information needs, and related processes will drive the justification for PLM. But always in the context of a business transformation. Strategic consultancy firms are excellent in providing strategic roadmaps for their customers, indicating the need for a PLM-infrastructure as part of that.

Most of the time, they do not dive more in-depth as when it comes to implementation, other resources are needed.

What needs to be done in PLM 1.0 to 4.0 per level/stage is well described in all the diagrams on a high-level. The WHAT-domain is the domain of the PLM-vendors and implementers. They know what their tools and skillsets can do, and they will help the customer to implement such an environment.

The big illusion of all the evolutionary diagrams is that it gives a false impression of evolution.  Moving to the next level is not just switching on new or more technology and involve more people.

So the big question is HOW and WHEN to make progress.

HOW to make progress

In the past four years, I have learned that digital transformation in the domain of PLM is NOT an evolution. It is disruptive as the whole foundation for PLM changes. If you zoom in on the picture on the left, you will see the data model on the left, and the data model on the right is entirely different.

On the left side of the chasm, we have a coordinated environment based on data-structures (items, folders, tasks) to link documents.

On the right side of the chasm, we have a connected environment based on federated data elements and models (3D, Logical, and Simulation models).

I have been discussing this topic in the past two years at various PLM conferences and a year ago in my blog: The Challenges of a connected ecosystem for PLM

If you are interested in learning more about this topic, register for the upcoming virtual PLM Innovation Forum organized by TECHNIA. Registration is for free, and you will be able to watch the presentation, either live or recorded for 30 days.

At this moment, the detailed agenda has not been published, and I will update the link once the session is visible.  My presentation will not only focus on the HOW to execute a digital transformation, including PLM can be done, but also explain why NOW is the moment.

NOW to make progress

When the COVID19-related lockdown started, must of us thought that after the lockdown, we will be back in business as soon as possible. Now understanding the impact of the virus on our society, it is clear that we need to re-invent ourselves for a sustainable future, be more resilient.

It is now time to act and think differently as due to the lockdown, most of us have time to think.  Are you and your company looking forward to creating a better future? Or will you and your company try to do the same non-sustainable rat race of the past and being caught by the next crises.

McKinsey has been publishing several articles related to the impact of COVID19 and the article: Beyond coronavirus: The path to the next normal very insightful

As McKinsey never talks about PLM, therefore I want to guide you to think about more sustainable business.

Use a modern PLM-infrastructure, practices, and tools to remain competitive, meanwhile creating new or additional business models. Realizing concepts as digital twins, AR/VR-based business models require an internal transition in your company, the jump from coordinated to connected. Therefore, start investigating, experimenting in these new ways of working, and learn fast. This is why we created the PLM Green Alliance as a platform to share and discuss.

If you believe there is no need to be fast, I recommend you watch Rebecka Carlsson’s presentation at the PLMIF event. The title of her presentation: Exponential Tech in Sustainability. Rebecca will share insights for business development about how companies can upgrade to new business models based on the new opportunities that come with sustainability and exponential tech.

The reason I recommend her presentation because she addresses the aspect of exponential thinking nicely. Rebecka states we are “programmed” to think local-linear as mankind. Exponential thinking goes beyond our experience. Something we are not used doing until with the COVID19-virus we discovered exponential growth of the number of infections.

Finally, and this I read this morning, Jan Bosch wrote an interesting post: Why Agile Matters, talking about the fact that during the design and delivery of the product to the market, the environment and therefore the requirements might change. Read his post, unless as Jan states:

Concluding, if you’re able to perfectly predict the optimal set of requirements for a system or product years ahead of the start of production or deployment and if you’re able to accurately predict the effect of each requirement on the user, the customer and the quality attributes of the system, then you don’t need Agile.

What I like about Jan’s post is the fact that we should anticipate changing requirements. This statement combined with Rebecka’s call for being ready for exponential change, with an emerging need for sustainability, might help you discuss in your company how a modern New Product Introduction process might look like, including requirements for a sustainable future that might come in later (per current situation) or can become a practice for the future

Conclusion

Now is the disruptive moment to break with the old ways of working.  Develop plans for the new Beyond-COVID19-society.  Force yourselves to work in more sustainable modes (digital/virtual), develop sustainable products or services (a circular economy), and keep on learning. Perhaps we will meet virtually during the upcoming PLM Innovation Forum?

Note: You have reached the end of this post, which means you took the time to read it all. Now if you LIKE or DISLIKE the content, share it in a comment. Digital communication is the future. Just chasing for Likes is a skin-deep society. We need arguments.
Looking forward to your feedback.

Meanwhile, two weeks of a partial lockdown have passed here in the Netherlands, and we have at least another 3 weeks to go according to the Dutch government. The good thing in our country, decisions, and measures are made based on the advice of experts as we cannot rely on politicians as experts.

I realize that despite the discomfort for me, for many other people in other countries, it is a tragedy. My mental support to all of you, wherever you are.

So what has happened since Time to Think (and act differently)?

All Hands On Deck

In the past two weeks, it has become clear that a global pandemic as this one requires an “All Hands On Deck” mentality to support the need for medical supplies and in particular respiration devices, so-called ventilators. Devices needed to save the lives of profoundly affected people. I have great respect for the “hands” that are doing the work in infectious environments.

Due to time pressure, innovative thinking is required to reach quick results in many countries. Companies and governmental organizations have created consortia to address the urgent need for ventilators. You will not see so much PR from these consortia as they are too busy doing the real work.

Still, you see from many of the commercial participants their marketing messages, why, and how they contribute to these activities.

One of the most promoted capabilities is PLM collaboration on the cloud as there is a need for real-time collaboration between people that are under lockdown. They have no time setting-up environments and learning new tools to use for collaboration.

For me, these are grand experiments, can a group of almost untrained people corporate fast in a new environment.

For sure, offering free cloud software, PLM, online CAD or 3D Printing, seems like a positive and compassionate gesture from these vendors. However, this is precisely the wrong perception in our PLM-world – the difficulty with PLM does not lie necessary in the tools.

 

It is about learning to collaborate outside your silo.

Instead of “wait till I am done” it should become “this is what I have so far – use it for your progress”. This is a behavior change.

Do we have time for behavioral changes at this moment? Time will tell if the myth will become a reality so fast.

A lot of thinking

The past two weeks were weeks of thinking and talking a lot with PLM-interested persons along the globe using virtual meetings.

As long as the lockdowns will be there I keep on offering free of charge PLM coaching for individuals who want to understand the future of PLM.

Through all these calls, I really became THE VirtualDutchman in many of these meetings (thanks Jagan for the awareness).

I realized that there is a lot of value in virtual meetings, in particular with the video option on. Although I believe video works well when you had met before as most of my current meetings were with people, I have met before face-to-face. Hence, you know each other facial expressions already.

I am a big fan of face-to-face meetings as I learned in the past 20 years that despite all the technology and methodology issues, the human factor is essential. We are not rational people; we live and decide by emotions.

Still, I conclude that in the future, I could do with less travel, as I see the benefits from current virtual meetings.

Less face-to-face meetings will help me to work on a more sustainable future as I am aware of the impact flying has on the environment. Also, talking with other people, there is the notion that after the lockdowns, virtual conferencing might become more and more a best practice. Good for the climate, the environment, and time savings – bad for traditional industries like aircraft carriers, taxis, and hotels. I will not say 100 % goodbye but reduce.

A Virtual PLM conference!

I was extremely excited to participate in the upcoming PLM Innovation Forum (PLMIF) starting on April 28th, organized by TECHNIA. I have been visiting the event in the past a few times in Stockholm. It was a great place to meet many of the people from my network.

This time I am even more excited as the upcoming PLMIF will be a VIRTUAL conference with all the aspects of a real conference – read more about the conference here.

There will be an auditorium where lectures will be given, there are virtual booths, and it will be a place to network virtually. In my next post, I hope to zoom in on the conference.

Sustainability, a circular economy, and modern PLM should go together. Since 2014, these topics have been on the agenda of the joint CIMdata Roadmap/PDT conferences. Speakers like Amir Rashid KTH Sweden, Ken Webster Ellen MacArthur Foundation, and many others have been talking about the circular economy.

The Scandinavian mindset for an inclusive society for people and the environment for sure, has influenced the agenda. The links above lead to some better understanding of what is meant by a circular economy and a sustainable future, as also the short YouTube movie below:

The circular economy is crucial for a sustainable future. Therefore, I am looking forward to participating in the upcoming PLM Innovation Forum on April 28th, where it will be all about digitalization for sustainable product development and manufacturing. Hopefully, with the right balance towards the WHY-side of our brain, not so much about WHAT.

You are welcomed to register for free here: the virtual PLM Innovation Forum – we might meet there (virtually).

The PLM Green Alliance

The PLM Green Alliance had been announced some months ago, started by Rich McFall and supported by  Bjorn Fidjeland,  Oleg Shilovitsky, and me.

It was the first step to proactively bringing people together to discuss topics like reducing our carbon footprint, sharing and brainstorming about innovations that will lead to a sustainable future for ourselves and our children, grand-grand-children. The idea behind the PLM Green Alliance is that a proactive approach is much cheaper in the long term as we can still evaluate and discuss options.

This brings me back to the All hands On Deck approach we currently use for fighting the COVID-19 virus.

In a crisis mode, the damage to the people and the economy is severe. Besides, in a crisis mode, a lot of errors will be made, but don’t blame or joke about these people that are trying. Without failure, there is no learning.

We are in a potential time of disruption as the image shows below, but we do not have the complete answers for the future

Think about how you could pro-actively work on a sustainable future for all of us. This will be my personal target, combined with explaining and coaching companies related to topics of modern PLM, during the current lockdown and hopefully long after. The PLM Green Alliance is eager to learn from you and your companies where they are contributing to a more sustainable and greener future.

Do not feel your contribution is not needed, as according to research done by the Carr Center’s Erica Chenoweth: The ‘3.5% rule’: How a small minority can change the world. It could be an encouragement to act instead of watching who will determine your future.

Conclusion

While learning to live in a virtual world, we might be realizing that the current crisis is an opportunity to switch faster to a more sustainable and inclusive society. For PLM moving to data-driven, cloud-based environments, using a Model-Based approach along the whole lifecycle, is a path to reduce friction when delivering innovations. From years to weeks? Something we wished to have today already. Stay safe!

People, wherever you are, we are in a kind of lockdown. Some countries more restricted than others. Still, the challenge will be for most of us how to survive in two perhaps three months of being locked in your home and make the best of it. As I am not a virus expert, I will not give you any recommendations on this topic. As a PLM geek, I want to share with you the opportunities I see for the upcoming months.

A crisis is an opportunity

Most of us should be lucky that we do not live in the same situation as twenty years ago. At that time, internet connectivity was expensive and slow. Meaning working from home would mean isolation from the rest of the world. The positive point now is that we can be connected virtually without travel, without face-to-face meetings, and we are pushed to do so. This external push is an interesting point for me.

The traditional attitude for my PLM engagements was that face-to-face meetings are crucial for creating a human connection and trust. Now I ask myself is this a behavior of the past that should become obsolete in the future. Probably we cannot afford this approach anymore in the future if we take sustainability and the environment into consideration. We live now in a globally connected world, but should we act still in the old way?

Perhaps not. Let’s look at some of the examples that it is time to shift behaviors.

We might think in the Western world we know it all due to our dominance in the past hundred years. However, when you study history, you will see civilizations come to power and after hundreds of years, they lose power because they kill themselves internally. Apparently, a typical human property that will not disappear – still interesting to analyze when considering a globally connected world. Where is the point of gravity today?

Interestingly, the ancient Chinese population already knew that a crisis was an opportunity, as I am being told. The Chinese characters for crisis mean danger and opportunity, respectively, according to Wiki – see the image above. Joe Barkai was one of the first in my network that took action to explain that instead of focusing on the loss of what is happening now, we should take the opportunity to be better prepared for the future. You can read his post here: The Corona virus and your company’s brand. And these kinds of messages are popping up more frequently now. Let’s stay safe while thinking and preparing for the future.

Now a PLM related example.

Remember what the FFF is happening?

Two-three weeks ago, we had a vivid discussion in our PLM and CM community based on the famous FFF mnemonic.  What the FFF is happening was a post sharing my point of view, and there were a lot of reactions from different people.

The purpose of my post was to explain that the whole discussion was based on paradigms that drawings are defining the part. Because of that, we have a methodology to decide if YES or NO we need a new part number or revision. To me, this practice should no longer be a discussion.

A part has a unique identifier, and a document has a unique identifier. In PLM-systems, the information is managed by relations, no longer by identifiers – who knows the exact unique identifier? In a PLM-system information is connected, and the attributes of the part and document will tell you the details of the type of information. “Intelligent or meaningful” identifiers are in such an environment no longer relevant. Think about that…..

In the comments of my post, Jesse Leal was confirming this statement:

This in contrary to Joe Brouwer, who you might have noticed, always is spitting his opinion that the good old days of the draftsman are gone, Boeing made a tremendous mistake and that PLM is fake. This all combined with hyperlinks to his products and opinions. The comment below says it all:

Two points to observe in this response:

Hey, Bob, send me the new digital identifier”.

This statement assumes that if a person needs to retrieve information from someone else, they need to contact this person (Bob).

Bob then needs to drop his current work and answer to the response and send the latest version of a drawing?  This is old school. In a PLM-system,  information should be connected, and if Bob has released his latest drawing (no matter if it is FFF), any user could find the latest approved version, not even having to look at the identifier (which could be meaningless) but by following the relations between products, parts, and documents.

This is PLM!

One of the benefits, Bob does not get disturbed during the day by these kinds of questions and can focus on his critical work as an expert.

Second, if you need to sit with a designer to understand PLM, then you are probably talking with the wrong person. Designers work in the context of PDM. When we speak about PLM, we are talking about a broader scope beyond engineering and design.

This is a common mistake in a lot of marketing stories. Companies that focus on the design space only, some EBOM-integrations with CAD-systems, are most of the time focusing on PDM.  When Agile PLM came out (later Oracle E9) and later Aras without CAD-integrations, these companies were focusing on the flow of information inside the company, not necessarily driven by CAD. Of course, the traditional PLM companies combine CAD integration with other capabilities. Dassault Systèmes, Siemens, and PTC all have a strong relationship with their native CAD-systems. However, their offerings go way beyond CAD-integrations e.g. end-to-end governance, change processes and an item-centric backbone.

The diagram above explains the basics for the future. In a push-mode, the person in the middle has the responsibility to distribute information and ensure it remains accurate for all stakeholders. This makes this person crucial (good job security) but extremely inefficient compared to people working in the pull-mode, being responsible for getting the accurate data themselves. It may be clear the pull-mode is the model of a digital enterprise.

So if you have the time now, take this time to rethink how well your company is ready for a digital future. Companies that currently rely on Bob are in trouble as Bob is currently sitting at home. Companies that have learned to shift from the push-mode to the pull-mode could continue working as planned, as they do not need Bob. And don’t worry about your job. If you are in Bob’s position you will lose your job over time. However, when you keep on evolving, learning and adding value to your company, you will be always needed – don’t lock yourself in.

If you want to be inspired more in this area, read Jan Bosch’s post: This is not the end . Here Jan mentions the opportunity to move to digital practices (and more) – get out of our traditional patterns

 

What can you do?

Even though COVID-19 has, and will have, a dramatic impact on our society, this is also the moment to rewire some of our processes.  Because there was never time to think and act due to the running business. It reminded me of the financial crisis in 2008, when the market for PLM vendors was terrible, no significant sales for them as companies could not invest.

However, for me, 2008 was an extremely busy year,  thanks to all kinds of regulations from governments. There was time and budget to support employees to raise their skills and PLM was one of these domains. That year I conducted many workshops. It was also the year that I started my blog virtualdutchman.com.

Now we are in a similar situation and probably worse as now we are locked to our homes. However, we are also better connected. Imagine this situation without the internet. Now we can learn even better.

So let’s benefit from this connectivity and use the lockdown time to learn, think, and discuss with peers. Challenge and involve the management of your company how they see and lead to the future.


In that context, I am happy to spend on average one day per week on free conference calls if you need clarification or support for your PLM-related ideas.

Contact me through a personal message on LinkedIn, and we will find a way to connect.

 

Conclusion

This decade will be decisive for many of us. At the beginning of this year, I wrote PLM 2020- The next decade (4 challenges). With my narrow PLM-mind, I overlooked viruses. Bill Gates did not do that, as you can see from his 2015 TED talk: The next outbreak? We’re not ready.  Bill also explains that our traditional thinking patterns should change in a globally connected world.

I wish you all the time to think and educate yourself and prepare for a changed future. Stay safe inside, stay healthy, knowing for some of you it will be a big challenge.

One week ago, Yoann Maingon wrote an innocent post with the question: Has FFF killed?  The question was raised related to a 2014 problem at GM, where a changed part was causing fatal accidents.

The discussion started by Yoann and here my short extract. Assuming this problem was a configuration management issue and Yoann somehow indicated that the problem might be related to the fact that ERP-systems do not carry a revision on the part number – leading to an unnoticed change.  Therefore, he assumes there is a disconnect between the PLM-side (where we have parts with multiple lifecycle states and revisions) and ERP (where we have an industrial lifecycle – prototype/production).

He posted his thoughts, and then LinkedIn exploded (currently 116 comments), which means it is a topic that is of significant concern in our community. Next, if you read the comments, there are different viewpoints:

  • What does FFF really imply?
  • What about revisions of parts?
  • What are the best practices?

Let’s investigate these viewpoints with some comments

What does FFF really imply?

When we talk about FFF in engineering, we mean Form, Fit and Function – the three primary characteristics to describe a part  (source Wikipedia)

  • Form refers to such characteristics as external dimensions, weight, size, and visual appearance of a part or assembly. This is the element of FFF that is most affected by an engineer’s aesthetic choices, including enclosure, chassis, and control panel, that become the outward “face” of the product.
  • Fit refers to the ability of the part or feature to connect to, mate with, or join to another feature or part within an assembly. The “fit” allows the part to meet the required assembly tolerances to be useful.
  • Function is a criterion that is met when the part performs its stated purpose effectively and reliably. In an electronics product, for example, a function can depend on the solid-state components used, the software or firmware, and quite often on the features of the electronics enclosure selected.

One of the comments in Yoann’s post referred to Safe/Unsafe as a potential functional characteristic. I think this addition is not needed. Safety should be a requirement for the part, not a characteristic.

FFF was and still is an approach for engineers to decide if a new, improved version of the part would get a revision or needs a new part number.

I think before we dive deeper into the other viewpoints, it is crucial to define the part number a little more.

In a correct PLM data model, there are two types of part numbers. First, the internal part number that your company uses inside its engineering Bill of Materials to identify a part. This part number can be a meaningless part only to provide uniqueness inside the company.

In 2015 I wrote several posts related to best practices and data modeling for PLM. The most relevant posts to this discussion are here:

The part number can specify a part that needs to be manufactured according to specification, or it can be a part that needs to be purchased from an available supplier/manufacturer. The manufacturer part number is, most of the time, a meaningful number (6 – 7 characters) as these parts need to be ordered by your company. The manufacturer part number is the SKU for the manufacturer. As you can imagine in the manufacturer’s catalog, there isn’t a revision mentioned. In graphics, see the image below:

Your company might sell Product MP-323121 (note: the ID is meaningful to help the customer to order the product).

Internally there is a related EBOM that specifies the product. The EBOM top part is O122 (note: here, we can use a meaningless identifier as all is digitally connected).

For the manufacturing of O122, we need to resolve the EBOM according to its specifications. Therefore, for Part O124, the company needs to decide to purchase from their approved manufacturers either part ABC-21231 or XYZ-88818 (note: again, a meaningful ID as these companies are not digitally connected).

Now coming back to the FFF-discussion. For the orange parts, with a meaningful ID, no revision exists. However, if Assembly O122 is 100% FFF compatible, the Product ID MP-323121 will not change. It allows your company to optimize the EBOM and/or MBOM, meanwhile keeping 100% compatibility to the outside world. (note: the same principle applies to the two manufacturers for Part O124.)

In case Top Assembly O122 has new or changed parts – what should happen there?

At that moment, the definition has changed. The definitions, most of the time described in documents/drawings/models, are related information to the BOM. Therefore the Top Assembly O122 should get a new identifier. There is no need to name it a revision, it is a new data set in the PLM-system, again with a meaningless identifier as we are connected digitally,

What about revisions of parts?

Of course, the management of changes existed long before PLM-systems were introduced.

The specifications of a part were defined in drawings. The drawing contained all the information, not only the geometry definitions, but also specifications on how to manufacture the part.

For complex products, a considerable set of consistently related drawings would be released to manufacturing.  A release process with physical signatures on it.

At the same time, there was no discussion: the drawing represents the part. And as there was no digital connection, part numbers/drawing numbers were meaningful, often with the format of the drawing as part of the identifier.

In case changes were needed, for example, fixing a dimension or tolerance as discovered during manufacturing, the drawing had to be revised to remain consistent. First, in the original drawing, the issue or change was marked in red (redlining). Then engineering had to create a new version of the drawing.

Depending on the impact of change (here comes also the FFF-principle), people decided if a new part number was needed (FFF-change) or that the change only required an update of the drawing(s), meaning a revision.  If the difference was small (for example, adding a missing annotation), it could be called a minor change, all to be reflected in the drawing number, which equals the part number in this approach. So, when we talk about revisions of parts, we are talking about a document change.

A lousy practice from that approach is also that often manufacturing just redlines a drawing and keeps the redlined drawing as their source. It is too time-consuming or difficult to update the source drawing(s) through a change process. Engineering is not aware of this change, and when a later change comes through from engineering, these “fixes” might be missed as there is no traceability.

Generic example of a PLM data model and its relationsWhen PLM-systems were introduced, of course, companies did not want to disrupt their existing ways of working. Therefore, they were asking the PLM-editors to enable revisions on parts and so the PLM-editors did (or do).

Decoupling of parts and documents in a PLM data model

However, if you want to use the PLM-system in the best manner, you need to “decouple” the concept:  part number equals drawing number, combined with the possibility to start using meaningless identifiers, as relations between parts and drawings are managed in the PLM-system through relational links.

Relevant post related to the PLM data model are:

What are the best practices?

As some people mentioned in their comments to Yoann’s post, why do we have to answer this question as all is already well understood and described in best practices? I agree with that statement: Best Practices exist – so how to obtain them?

First, there is the whole framework of Configuration Management, which existed long before PLM-systems were introduced. If you follow their methodology, you can be (almost) guaranteed your information is consistent and correct. Configuration Management is crucial in areas where the impact of an error is enormous, like the GM-example Yoann referred to. Also, companies in the Aerospace and Defense industry are the ones that have strict configuration management in place.

Configuration management does not come for free. It requires an investment in skills, potentially a change in ways of working, and requires an overhead. Manufacturing companies that are creating less “risky” products often focus more on optimizing (= reducing) the cost of their internal processes instead of investing in proper methodologies to manage consistency.

If you want to learn more about CM, investigate the Institute of Process Excellence (IPX), the founders of the CM2 framework for Enterprise Configuration Management, and much more. Note: Their knowledge does not come for free, which I can understand. However, it also creates a barrier for the company’s further investment in CM as this kind of strategic investments are hard to sell at the management level by individuals in a company.

In the context of CM, I advise you to follow Martijn Dullaart, who is quite active in our social community. His latest blog post related to this thread is: It’s about Interchangeability and Traceability

With the introduction of PLM-system, these companies and the PLM-editors created the opportunity to implement configuration management in their system.

The data inside the system would be the “single version of the truth.” Unfortunately, this was most of the time, just a sales strategy, falsely giving the impression that information is under control now. Last year I wrote several posts related to the relation between PLM and CM, starting from PLM and Configuration Management – a happy marriage?

If you are interested in another resource for information related to these topics, have a look at the website from Jörg Eisenträger who also collected his best practices for PLM and CM for sharing (thanks Paul van der Ree for the link)

Don’t expect best practices from your PLM-vendors as their role is to sell software. It is the continuous discussion between:

  • A PLM-system that forces companies to work according to embedded methodology (hard to sell/implement but idealistically correct)

And

  • A flexible PLM-system that allows you to build and configure anything (easy to sell/challenging to implement correctly, depending on “wise” decisions)

The Future

Even though most companies are working drawing-centric, with or without a linked PLM-backbone for BOM-management, the next upcoming challenge is to evolve to model-based practices. The current CM-practices still talk about documents, although documents are already electronic datasets in that context. The future, however, in a model-based enterprise evolves related to connected models, 3D Models, but also simulation and software models, with different lifecycles and pace of change. For the model-based enterprise, we need to develop digital best practices that guarantee the same level of quality, however, executed and/or supported by (AI) Artificial Intelligence. AI is needed as human beings cannot physically analyze and understand all the impact of a change in such an environment.

Conclusion

The FFF-discussion illustrates that building a consistent framework within PLM is not an easy goal to achieve. My blog buddy Oleg Shilovitsky would claim that we consultants create the complexity. PLM-editors will never solve this complexity, it is up to your company’s mission to invest in knowledge to understand why and how to reduce the complexity. With this post and the related links and discussions, I hope more clarity will help you to make “wise” decisions.

%d bloggers like this: