After “The Doctor is IN,” I have another written post in the category of PLM and complementary practices/domains. In January, I discussed the complementary value of PLM and CLM (Configuration Lifecycle Management) with Henrik Hulgaard from Configit. For me, CLM is a synonym for Product Configuration Management.

PLM and Complementary Practices (feedback)

As expected, readers were asking the question:

“What is the difference between CLM (Configuration Lifecycle Management) and CM(Configuration Management)?”

Good question.

As the complementary role of CM is also a part of the topics to discuss, I am happy to share this blog today with Martijn Dullaart. You probably know Martijn if you are actively following topics on PLM and CM.

Martijn has his own blog mdux.net, and you might have seen him recently in Jenifer Moore’s PLM TV episode: Why CM2 for Faster Change and Better Documentation. Martijn is the Lead Architect for Enterprise Configuration Management at ASML (Our Dutch national pride) and chairperson of the Industry 4.0 committee of the Integrated Process Excellence (IPX) Congress. Let us start.

Configuration Management and CM2

Martijn, first of all, can you bring some clarity in terminology. When discussing Configuration Management, what is the pure definition, what is CM2 as a practice, and what is IpX‘s role and please explain where you fit in this picture?

Classical CM focuses mainly on the product, the product definition, and actual configurations like as-built and as-maintained of the product. CM2 extends the focus to the entire enterprise, e.g., the processes and procedures (ways of working) of a company, including the IT and facilities, to support the company’s value stream.

CM2 expands the scope to all information that could impact safety, security, quality, schedule, cost, profit, the environment, corporate reputation, or brand recognition.

Basically, CM2 shifts the focus to Integrated Process Excellence and promotes continual improvement.

Additionally, CM2 provides the WHAT and the HOW, which is something most standards lack. My main focus remains on the product and promoting the use of CM beyond its domain.

For all CM-related documentation, we are already doing this.

Configuration Management and PLM

People claim that if you implement PLM as an enterprise backbone, not as an engineering tool, you can do Configuration Management with your PLM environment.

What is your opinion?

Yes, I think that this is possible, provided that the PLM tool has the right capabilities. Though the question should be: Is this the best way to go about it. For instance, some parts of Configuration Management are more transactional-oriented, e.g., registering the parts you build in or out of a product.

Other parts of CM are more iterative in nature, e.g., doing impact analysis and making an implementation plan. I am not saying this cannot be done in a PLM tool as an enterprise backbone. Still, the nature of most PLM tools is to support iterative types of work rather than transactional types of work.

I think you need some kind of enterprise backbone that manages the configuration as an As-Planned/As-Released baseline. A baseline that shows not only the released information but also all planned changes to the configuration.

Because the source of information in such a baseline comes from different tools, you need an overarching tool to connect all of them. For most companies, this means that they require an overarching system to support their current state of enterprise applications.

Preferably, I would like to use the data directly from the sources. Still, connectivity and performance are not yet to a level that we can do this. Cloud and modern application and database architectures are highly promising in this regard.

 

Configuration Management for Everybody?

I can imagine companies in the Aerospace industry need to have proper configuration management for safety reasons. Also, I can imagine that proper configuration management can be relevant for other industries. Do they need to be regulated, or are there other reasons for a company to start implementing CM processes?

I will focus the first part of my answer within the context of CM for products only.

Essentially, all products are subject to some degree of regulation. Aerospace & Defense, as well as Medical Device and Pharma, are highly regulated for obvious reasons. Other industries are also regulated, for example, through environmental regulations like REACH, RoHS, WEEE or safety-related regulations like the CE marking or FCC marking.

Customers can also be an essential driver for the need for CM. If, as a customer, you purchase expensive equipment, you expect the supplier of that equipment to deliver on its commitment. The supplier can also maintain and upgrade the equipment efficiently with as few disruptions to your operations as possible.

Not just customers but also consumers are critical towards the traceability of the product and all its components.

Even if you are sitting on a rollercoaster, you presume the product is well-designed and maintained. In other words, there is often a case to be made to apply proper configuration management in any company. Still, the extent to which you need to implement it may vary based on your needs.

 

The need for Enterprise Configuration Management is even more significant because one of the most challenging aspects is changing the way an organization works and operates.

Often, there are multiple ways to accomplish the same task. There is a lot of tribal knowledge, and ways of working are not documented in a way that allows people to easily find them, let alone in a structured and linked format that facilitates impact analysis when introducing changes to your organization.

 

CM and Digital Transformation

One of the topics that we both try to understand better is how CM will evolve in the future when moving to a more model-based approach. In the CM-terminology, we still talk about documents as information objects to be managed. What is your idea of CM and a model-based future?

It is indeed a topic where probably new or changed methodology is required, and I started already describing CM topics in several posts on my enterprise MDUX blog. Some of the relevant posts in this context are:

First, let me say that model-based has the future, although, at the same time, the CM aspects are often overlooked.

When managing changes, excessive detail makes estimating cost and effort for a business case more challenging, and planning information that is too granular is undesirable. Therefore, CM2 looks at datasets. Datasets should be as small as possible, but not too small. Datasets are sets of information that need to be released as a whole. Still, they can be released independently from other datasets. For example, a bill of materials, a BOM line item is not a dataset, but the complete set of BOM line items that make up the BoM of an assembly is considered a dataset. I can release a BoM independent from a test plan.

Data models need to facilitate this. However, in many PLM systems today, a BOM and the metadata of a part often use the same revision. This means that to change the metadata, I need a revision of the BoM, while the BoM might not change. Some changes to metadata might not be relevant for a supplier. Communicating the changes to your supplier could create confusion.

I know some people think this is about document vs. model-centric, but it is not. A part is identified in the ‘physical world’ by its part ID. Even if you allow revisions in the supply chain, including part IDs, you create a new identifier. Now every new revision will end up in a different stock location. Is that what we want?

In any case, we are still in the early days, and the thinking about this topic has just begun and needs to take shape in the coming year(s).

 

CM and/or CLM?

As in my shared blog post with Henrik Hulgaard related to CLM, can you clearly differentiate between the two domains for the readers?

 

Configuration Lifecycle Management (CLM)  is mainly positioned towards Configurable Products and the configurable level of the product.

 

Why I think this, even though Configit’s  CLM declaration states that “Configuration Lifecycle Management (CLM) is the management of all product configuration definitions and configurations across all involved business processes applied throughout the lifecycle of a product.”,
it also states:

  • “CLM differs from other Enterprise Business Disciplines because it focuses on cross-functional use of configurable products.”
  • “Provides a Single Source of Truth for Configurable Data“
  • “handles the ever-increasing complexity of Configurable Products“.

I find Configuration Lifecycle Management is a core Configuration Management practice you need to have in place for configurable products. The dependencies you need to manage are enormously complex. Software parameters that depend on specific hardware, hardware-to-hardware dependencies, commercial variants, and options.

Want to learn more?

In this post, we have only scratched the surface of PLM and Configuration Management. Where can an interested reader find more information related to CM for their company?

 

To become trained in CM2, people can reach out to the Institute for Process Excellence, a company that focuses on consultancy and methodology for many aspects of a modern, digital enterprise, including Configuration Management.

And there is more out there, e.g.:

Conclusion

Thanks, Martijn, for your clear explanations. People working seriously in the PLM domain, managing the full product lifecycle, should also learn and consider best practices in Configuration Management. I look forward to a future discussion on how to perform Configuration Management in a model-based environment.

PLM, CLM, and CM – mind the overlap