What is Product Lifecycle Management (PLM)?

We often come across Product Lifecycle Management (PLM) in systems engineering. However, we - or others - often assume that there is a common understanding of what this means. A common understanding should never be assumed for any term. And especially when the stakes are high or lengthy debates are developing, it is time to lay a solid foundation with a clear definition of the term. Many discussions can be traced back to the fact that different definitions have been implicitly adopted.

So, what is PLM?

Simply everything

The abstract definition is simple:

PLM is a concept for the seamless integration of all information generated during the life cycle of a product (Sudarsan et. al, 2010)

There are two dimensions to consider here: The temporal dimension and the informal dimension. In the temporal dimension, we usually think from the idea to the end of product support, often including scrapping. Informally, we usually think of all artifacts of product development. These include, among others:

• Requirements and other artifacts of the Systems Engineering
• Schedules and other project management artifacts
• CAD plans and other design artifacts
• Resources, production facilities and other production artifacts
• Maintenance, customer service and other services

It is perhaps already apparent here that the distinction between PLM and marketing is not so simple: Is marketing part of PLM? And if so, is it only product marketing, or is it also the website? What about the HR department?

There is no "right" and "wrong" here. Instead, the scope of PLM initiatives should be clearly defined. Remember; PLM is a "seamless integration concept." Typically, these integrations are introduced or expanded in a PLM initiative. Therefore, the scope of a PLM initiative is always a subset of the scope of PLM.

Why PLM?

A "seamless integration of all information generated during the life cycle of a product" costs money and must not be an end in itself. So what is the business case for PLM? Here we meet the usual suspects, for example:

• Enable or accelerate innovation
• Increase turnover
• Increase productivity
• Reduce costs
• Increase quality
• Ensure compliance
• Accelerate the market entry of new products.

Implementing PLM - but how?

Tools are required for the seamless integration of information. This alone is not enough, because product lifecycle management also requires a rethink and adaptation of processes in order to be able to use the information efficiently.

With PLM initiatives, we never start on a greenfield site (exceptions prove the rule). Therefore, there is already information available, but it is not yet seamlessly integrated. Two things should definitely be clarified in advance:

I have seen far too often that data has been collected and/or integrated to be really clear about its purpose. Who is using the integrated data, and for what purpose? For example, resource planning data could be integrated with the backlog to find and utilize unused resources.

There are Manufacturer of PLM systems. The promise is to cover all aspects of product lifecycle management with one system. However, as I have already said, PLM never starts on a greenfield site.

The tool question

The introduction of an all-encompassing PLM system harbors many risks:

• There may be redundancies with existing systems
• Important functions are not particularly well supported, or are missing altogether
• The required use cases may not even be possible!
• You become dependent on one manufacturer

It may well make sense to purchase a complete PLM system. However, the questions just listed (and more) should be carefully examined beforehand.

There are alternatives to a monolithic PLM system, of which I would like to present the following three:

Integration of integrable tools. Nowadays, I would attach great importance to integrability anyway. Typical interfaces are REST API or OSLC. The danger with this approach is that uncontrolled growth can quickly occur. The IT architecture must be carefully maintained like a real project.

Integration hub. There are tools that act as a data hub. These usually have a number of adapters for popular tools. This allows powerful integration scenarios to be realized. The advantage here is that these solutions are very robust and work reliably. However, rarely are all the tools to be integrated supported by the hub. In such a case, the hub can also be combined with direct integration.

Business Intelligence. There are also tools that only have read-only access to various data sources. Obviously, only certain use cases can be implemented with these tools. Nevertheless, such tools are a good way to get started with PLM: This is because you can get useful information about product development very quickly. There is no risk of data being corrupted - after all, data is only read.

As I said, there are many other options. The important thing here is to give it some thought.

Conclusion

Product lifecycle management is about information, and that means all information that has something to do with product development. It is also about using this information effectively. In practice, it makes sense to narrow down the scope by defining specific PLM initiatives (which fit into a PLM strategy). PLM cannot be realized without appropriate tools. It is important that use cases and IT architecture are clarified first.

PLM is not easy, but if implemented correctly, it has the potential to reform product development in the long term.

Photo by Sean Patrick Murphy on Unsplash