New PLM: From Definition to Realization?

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

Share

Share This Post

  • Quinterow

    Hello Oleg. What do you think regarding the implementation of PLM? When and how should it be done? Should this be a step by step process?

  • beyondplm

    Quinterow, the first step is to decide what problems in your company you want to solve. Then you can back and see how PLM can solve it. This is not a single shot, but more iterative process, in my view. Best, Oleg

  • beyondplm

    Jens, CIMData definition is a good one. However, it is too complicated… We need it 30 sec to 1 min pitch about PLM definition. What is your take? Thanks for your comments! Oleg

  • beyondplm

    Awadhesh, thanks for your comments and insight. I agree, there is a place for a broader term. However, I’m afraid about new TLA (three letter acronyms). Some of my thoughts about that is here — http://beyondplm.com/2010/09/22/the-future-of-tla-in-engineering-software/. Best, Oleg

  • beyondplm

    Hemboy, Thanks for your insight. I think you pointed out 3 very important points: 1/PLM is touching a very sensitive space – product development; 2/ PLM vendors are trying to apply “department store approach” to solve these problems; 3/changes are so expensive that kills all successful implementations next day. The first step towards better solutions is to drop OOTB approach and think about configurable systems again. Best, Oleg

  • beyondplm

    Steve, Thanks! Please, send me the link your blog post. I’d be glad to discuss. Best, Oleg

  • beyondplm

    I agree. that’s why it is defined as a “business activity” and not as a software. Best, Oleg

  • beyondplm

    Satish, thanks for helping me to memorize – TDM, EDM, PDM, cPDM, PLM… The fact PLM activities and support are not proliferating downstream is a big problem for both vendors and customers. Today, PLM is still too complex. However, industry people are thinking about that… Best, Oleg