Why do my employees hate PLM?

Very often PLM implementations begin with big promises on collaboration (both internal & external) and higher ROI. As a result, these projects immediately get funding from the upper management but only to realize later that the promises were not fulfilled. In my experience, this failure could be attributed to the following reasons:

• Existing processes were not fully understood before selecting the right PLM solution.
• Low user adoption as PLM applications are often difficult to use because of complicated UI.
• PLM applications are not adaptive (not easily configurable).
• PLM processes are executed in silos rather than in a cohesive well-integrated manner.
• No support from peripheral stakeholders.
• Absence of a single powerful entity that controls the end-to-end process i.e. from product design to release. The very concept of collaboration is at risk here. Every group is interested in only their processes and do want to take time to understand the end-to-end process. The management in these groups do not appreciate the end-to-end process either.

In my opinion, the last point is very important. All other points are important as well but once the upper management realizes the important of PLM and provides a foundation where different groups take up accountability (even outside the tool) then the benefits of PLM will be fully realized.

CM Vs. CDM

The world of product design and manufacturing is changing based on the globalization policies. Captilization is pushing more and more design and manufacturing jobs to cheaper countries. As a result, the tools that are supporting the product and design activities are changing to support these models. However, they are are not changing fast enough to keep up pace with the changes happening in the industry. Contract Manufacturing (CM) was a model where the product will be designed in one geographic location and the manufacturing will be done in an offshore location. This model is changing to Contract Design Manufacturing (CDM) where part of the design is now moved to offshore along with the manufacturing activities. This poses challenges such as how much design can I share with my partner? If I collaborate with more than one partner on a project, can they both see each other's data via my PLM system? How do I control partner's IP protected data? Are users trained to understand such complexity? While the answers may be simple to the above questions, it quickly becomes complex before we realize.

It will be interesting to see how the PLM tools out there would support such complex business models.

Id, Name, Number, Description, Title, Short Desc, Long Desc,...

As if there is no shortage of debates in the PLM field, one basic (and unfortunate) lingering debate is about how do you call the identifier of an item (Part, Doc, Change, etc.)? It is very agonozing that the PLM tools out there were not able to come up with an unambiguous name to reference this identifier. I have seen one particular tool calling the identifier as Name but it confused the users as they thought "Name" stands for description. It is understandable that, just like in real word, names are not numbers. For example, people are called by their names (First Name or Last Name). Some developed countries have unique numbers to identify each person. It is called SSN in the U.S. SSN is the id and their name is just a name. Why dont we follow the same nomenclature in the PLM world? Number and Id could be synonymous while Name is a short description. The term Title is applicable for documents but it would be much simpler if we use the term Name just like any other item. The Name field usually has some length restrictions and hence we can have a field for long description with unlimited number of characters. So, let us put this debate to rest and use the following terms:

Id = Unique identifier (Could be mix of numbers and characters)
Name = Short Description
Description = Long Description

Problem solved. Now let us think about some real problems...

What's in a number?

Part numbering in PLM has always been an interesting point of discussion, even after so many years since PLM evolved, with different people having their own fixed views. It is getting even complicated with the CTM (contract to manufacture) and CDM (contract to develop and manufacture) models. Each of the parties involved in the above models have their own PDM/PLM system with their own part numbers. So a single item could have multiple numbers across different parties involved, which naturally complicates things. Imagine you being called by different names and everyone trying to map your name to their own internal name. What a mess? Hopefully this topic will die soon and the industry can focus on more important issues. I will share the lessons I have learned from part numbering:

1. Part numbers are tied to legacy data and processes. Before selecting a PLM system, take time to understand how the legacy data is organized and processed. Smart numbering, such as dash numbers, and the logic around such numbers are not supported by all PLM applications.
2. Create visibility with the end users, rather than the managers, who know how most processes work.
3. Change Management - Try to convince the users to adopt the industry standard practice (though it is questionable if such a standard exists) rather than trying to force a solution on them. The earlier they know the better it is.
4. Changing existing part numbers to new numbers could be disastrous. These part numbers could have propagated to downstream systems such as ERP and MES. Make an impact analysis on if it is worth making the change on all these systems? Make an end to end analysis rather than just focusing on engineering processes.

If ERP and Finance processes could be standardized and talk the same language irrespective of tools used then PLM should be able to do the same. Will it happen?

More to come. Stay tuned!