Do we need to fix PLM basics?

The weekend normally puts me into a much deeper thinking mode about what to discuss on PLMtwine. Since the post about Top Five Disappointing PLM Technologies, I’ve been thinking more about fundamental PLM elements, rather than about specific pieces of PLM. In additional, it was very interesting to see how many thoughts and opinions came in the space of PLM after the Google Wave announcement ten days ago. When new technology comes, it always sounds like new techie stuff can fix old problems magically. But this is not always true, and sometime dressing new technology “clothes” on an “old body” do not create a magical change. So far, I’d like to share my thoughts about the ‘basics’ of Product Lifecycle Management – the things that, in my view, provide fundamental definitions and tool-sets for the rest of our PLM activity.

PLM Model

This is the most important piece of a PLM system. Since PLM is about product lifecycles, it’s essential to be able to create a product model and its surrounding world in the PLM system. In the current PLM landscape, I see three PLM model lines:

(1) CAD / Product Structure – these models evolve from design and product data management systems. The core advantages of these systems emerged from a very mature background and from the history of the CAD industry and its ability to create design and engineering models. In my view, these systems are perfect to represent product design in a static view. However, they lack capabilities to manage product model relationships with the business world. The core reason is in the roots of these models that are able to present only snapshots of various product views.

(2) ERP based– these models came out of business systems. In the beginning of MRP/MRP II, these model fundamentals are in manufacturing and business planning. These systems are much more sustainable to represent time-oriented business and much more appropriated for lifecycle (from a time management standpoint) – but since their core is business-oriented, most of them are missing the ability to keep comprehensive definitions of product design, engineering and other elements of product models.

(3) EDM/PDM – you can find many various product models created as part of different applications in the document and product data management domains. All of these models are normally suited very well for their original applications. The core problem with these models is that most of them are fragmented and not expandable on the level that is needed to keep a system running or expanded.

So, my intermediate conclusion is that Product Models for PLM are still in a very immature phase. Most probably, new technologies need to be applied to this space in order to be more efficient, and in order to scale the tasks we have today in Product Lifecycle Management.

Change Management

Since PLM is about lifecycles, “change” is another fundamental piece of PLM space. Unfortunately, in my view, most PLM systems are not created with ‘change’ in mind. Applying changes in these systems is a very expensive and time-consuming process. A lot of business logic and specific techniques create complex dependencies as to how PLM is implemented and as to what is needed in order to add specific new characteristics. At the same time, today’s business is very dynamic. These unmatched behaviors create a basic conflict between PLM implementation and the surrounding business environment.

Staged Assumption

This approach is directed to resolve the complexity of PLM implementation in the organization. Since all PLM expectations cannot be created in a single implementation shot, most of the implementation is done in stages. This is a very practical and efficient mechanism for separating PLM implementation on domains. In this way, each domain is treated separately as well additional ones being added year after year. The problem with this approach is the issue of “Change Management” that I discussed earlier in this post. From stage to stage, complexity of the system increases and is multiplied by inefficient change management, thus creating more and more expensive implementations. (I have to say that this characteristic is not unique for PLM and probable the same for all Enterprise systems).

Final conclusion for today: I don’t want to discover possible solutions and point to “magic” or “instant” technologies. However, I did want to about three fundamental behaviors of Product Lifecycle Management. Understanding these behaviors and their alignment with new technological achievements can change what we’ve been doing in PLM until now.

As usual, I’m looking forward to an open discussion, and will continue blogging about this topic.