New PLM: From Definition to Realization?

The definition of PLM is one of the topics I’m discussing on blog. I think, in the modern enterprise software, PLM buzzword created a biggest amount of collision, miss interpretation and disputes. I often ask myself what caused such a high level of disagreement? MRP, ERP, CRM… Even SCM – the agreement about these TLAs seems to me smooth. However, each time a discussion comes to PLM, I can hear multiple voices about what it supposed to be and how it supposed to behave.

I read a blog by Chad Jackson on engineering-matters.com called PLM Misnomer What we know it isn’t. Chad took a broad review of what PLM is based on Wikipedia’s definition of a product lifecycle. These are my two favorite passages from Chad’s blog:

(PLM…) definitions can vary quite dramatically. And personally, I don’t have any problem with that. However, in response to a tweet questioning the definition of PLM, I saw a tweet along the following lines: the definition of PLM is simple, it’s what manages the lifecycle of the product! And I have to say, I completely disagree. From my perspective, PLM systems don’t begin to address the entire lifecycle of the product.

PLM systems don’t really manage the product’s entire lifecycle. It is a front-end oriented system more related to concepts and detailed design.

Two Engineers – Three Opinions

Engineering and Manufacturing. Different opinions. If you had a chance to attend meetings in manufacturing companies, you can see how complicated to come to a single conclusion. You can do things this way, but you can also approach some alternatives. This is not about money – this is about engineering. When software engineering (vendors) crosses paths with manufacturing (customers), the results are unpredictable. This is what happened to the most of CAD/PLM vendors when they started to develop complex systems for large OEMs in automotive and aerospace industries. Most of today PLM systems are having roots in this development.

If I had more time, I’d write a shorter story…

This is one of my best quotes by Mark Twain. If I’d apply it to development of software I’d say – it is easy to develop something complicated. It is damn hard to develop something simple. I think, an attempt to provide a complicated and exhaustive definition of PLM (as well as complex product suites) is a core of the problem. The diverse set of functionality required by manufacturing companies pushed vendor to add more and more modules (and functions) to their products. So, they became big, complicated and expensive. The idea of business apps presented by Dion Hinchliffe is interesting in my view. Take a look on the following conceptual diagram of Business Apps.

What is my conclusion? PLM is complicated because it touches one of the most sensitive elements of a manufacturing company – the way this specific company runs their development and manufacturing. Every company developed their own processes. PLM companies passed the way from development of a toolkit to gigantic systems with lots of functions and features. Industry had enough time to think. In my view, now it is a time find how to create a “short story” about how to realize PLM ideas in a scalable, but not complicated way.

Just my thoughts…

Oleg