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...