PLM: The Debate Over The Troubled TLA

References Cited

Product Lifecycle Management (PLM)

It’s funny. It seems that unresolved debates come back in vogue like retro clothes.

In recent weeks, I’ve found myself in a spat of conversations about the definition of PLM again. Most of these conversations have been initiated because new software products have launched that challenge what seems to be an accepted definition. As a result, people are asking themselves again “what exactly is PLM?” Despite all the talk, there doesn’t seem to be much consensus. So am I writing to tell you the one true definition of PLM? No. I’ll tell you what I think PLM is. However, I’ll offer a framework for the conversation. Hopefully, you can point to this and say “THAT is what I mean by PLM,” even if you don’t agree with my definition. Let’s dive in.

PLM as a Business Strategy

I’ve come across a number of folks who take this position. They define PLM as a business strategy that a company or organization pursues. I have difficulty with this logic because of a single question: if PLM did not exist, could the company or organization NOT pursue that strategy? Let’s look at some specific examples of what organizations are trying to do and see how the logic holds up.

  • Execute Process X: In this case, X really could be any process. If PLM did not exist, could process X still be executed? Now of course, most processes in a manufacturer have been run for years of not decades. The old school way of doing so is to use email or even physically walk pieces of paper around the office. Even if you’re talking about automating a process, alternatives to PLM could be used. Just about every enterprise system has some type of workflow engine. I’m not saying any of these scenarios are better than using PLM. What I’m saying is that they do not require PLM.
  • Centrally Manage Data: We’ve heard about centrally managing data for quite some time. But can you not centrally manage data without PLM? Of course you can. Even if it might be ugly, you can centrally manage data on shared drives, share point or some other manner. Again, it might not be the best alternative, but it is possible.

Now, with all this being said, can you pursue an initiative to deploy PLM? Of course. In fact, that in and of itself can be quite an undertaking. But pursuing an initiative to deploy PLM is far different than pursuing a business strategy or initiative that is PLM. All this is leads up to my first position: PLM is a technology. Why? Because it is not required to run a manufacturing business. Don’t get me wrong. There are dramatic tangible benefits. But it is not required. In fact, there are many organizations running their businesses today without PLM.

If you disagree with me, that’s OK. I’m open to a discussion. Leave a comment explaining your position. I’d love to talk about it. And regardless, feel free to point to this post or even post your own position in counterpoint to this one.

PLM as a Technology

The other position that many take is that PLM is a technology. But even within this designation, there can be diverging opinions. Let’s take a look.

PLM Manages the Lifecycle of the Product

I’m open to the discussion, however I published my position and logic a few months ago in a post titled The PLM Misnomer: What We Know It Isn’t. But essentially, my position rests on a few simple points. The processes and deliverables that are mainly supported by PLM are creating during the development cycle, even if they are used later in the product’s lifecycle. Furthermore, there are many other enterprise systems (see in the post) that are used in those later lifecycle stages that are far more prominent, even in regards to processes and deliverables related to the product. As I said before, I’m willing to listen to other points of view. Comment or post and I’ll happily reply back.

PLM Technology Confusion

Now, the next stage of this discussion gets a bit tricky. To make things a little more clear, I’m publishing this diagram for the discussion.

What’s going on here? More importantly, what’s the point? Let me explain. In this Venn diagram, I’ve created circles for CAD, CAM, CAE and PDM. One could certainly argue about overlaps between those four, but for simplicity’s sake and focus, let’s keep them separate for now. Beyond those four circles, there are three other ‘definitions’ relevant to a discussion about PLM.

  • Circle #4: Process Enablement – This set of technology capabilities include things like project management, workflow, task management and reporting. Essentially, it encapsulates most things you need to automate processes or make key decisions in the development cycle.
  • Circle #5: Process and Data Management – This phrase acts as an umbrella to cover both process enablement capabilities (circle #4) as well as PDM. Many extol the virtues of doing both together, and as such, need to reference those capabilities in one set.
  • Circle #6: IT Ecosystem for Product Development – This is also an umbrella term, but one with a far larger reach. This is the entire ecosystem of CAD, CAM, CAE, PDM and process enablement (circle #4). Obviously a lot of discussions need to occur about interoperability between all of these different types of technology. Therefore, some definition is needed.

Before we move on to which one of these is PLM, let me say this: we need to have some definition for circles #4, #5 and #6. There are legitimate conversations in the scope of each definition. So I don’t think we throw away the rest if one is designated as PLM. But more importantly, we have arrived at a dangerous place today. Somehow along the way, we’ve used the acronym PLM to refer to each of these definitions. That’s dangerous in that if two people are using two different definitions, then the conversations are at completely different levels. And when a proponent of PLM talks about ROI and value proposition to an executive, that is scary.

My Definition of PLM

So what definition do I use for PLM? I use circle #4. We need terms like these to serve the purpose we have in store for them. I, for one, believe that process management technologies need to be assessed in terms of value, deployment, impact and the like separately from CAD, CAM, CAE and PDM. Only if we do that do we know if it is worth the effort.

Summary and Questions

Here’s the quick summary. There are many potential definitions of PLM including:

  • PLM is a business strategy
  • PLM is a set of technologies that manages the lifecycle of the product
  • PLM is a technology for process enablement (I use this definition)
  • PLM is a set of technologies for process and data management (umbrella term)
  • PLM is a set of technologies that encompasses CAD, CAM, CAE, PDM and process enablement (another umbrella term)

Are you ready for a debate? Aherm… I mean a professional disagreement of course.

What definition of PLM do you use? Why?  I’m looking forward to the discussion.

Take care. Talk soon. And thanks for reading.


Chad Jackson is an Industry Analyst at Lifecycle Insights and publisher of the engineering-matters blog. With more than 15 years of industry experience, Chad covers career, managerial and technology topics in engineering. For more details, visit his profile.

Like this post?

Sign up now to get more like it

  • Craig Rode

    OK, I’ll bite.

    Let’s start with the obvious.  “Product Lifecycle Management” is a verb phrase.  So, that’s the beginning of the confusion.  Applying a verb phrase to a noun (the software) is what causes all the debate.  The same problem, of course, exists with CRM and ERP.  Just about anything can be said to be product lifecycle management, from keeping track of design benchmarks in Excel to analysis document management.  One of the activities that PLM could be applied to is Product Data Management.  But that doesn’t mean you need PDM to be doing PLM, or vice versa.  So, I would say that PLM is the collection of processes, some automated, some not, that create and manage all information about the design, engineering, manufacturing, use, and disposal of products.  That’s still pretty vague, but the point is that “PLM” is a thing only in the same sense that “mammal” is a thing. 

    The stuff the industry calls PLM is the collection of applications build on 20 year old technology based on PDM that have been put together to try and solve the activity of PLM.

    In essense, then, I disagree with you.  I contend that PLM is a collection of processes, not technology.

    • Hey Craig. Thanks for weighing in.

      Just so I understand, you’re saying that PLM is a set of processes that create and manage all information about a product across its lifecycle phases?

      If that’s the case, what do you call the type(s) of technologies that support that effort?

      • Craig Rode

        Hi Chad,

        Thanks for your reply.  I’d go with precedent.  If word processing is a verb, then “word processing software” is the noun.  If calculating is a verb, then “calulators” is the noun.  Hence if “product lifecycle management” is the verb, then “product lifecycle managment tools” or “product lifecycle management applications” are the nouns.  Just rolls off the tongue, doesn’t it?

        My meta point here is product lifecycle management (the verb) is so broad that we need to drop down a level to have any meaning.  There is BOM management software, there is PDM software, there is project management, customer requirements software.  Each of these are different aspects and can be done by different applications.  Else, if all software that is used for different aspects of PLM can be called “PLM”, then Microsoft’s Excel is PLM.

        • Understood. I had questions along the lines of your last thought there. Thanks for your perspective.

  • Ganesan

    I fully agree that PLM is not a business strategy as you have rightfully pointed out that you can have a strategy without a PLM. Also, i fully agree that PLM plays a much larger role in Development phase rather than in the lifecycle phase.

    I will go with ” PLM is a set of technologies for process and data management”. In my view,  data management is an integral part of PLM with the process support for decision making. If it is a pure process enablement for developemnt cycle without context of product data, it can be done with any system with a good workflow engine.

    In this context, I want to clarify data management. There are 2 buckets of data management. One is WIP design data management with integration to ECAD, MCAD… systems. I would call this WIP system as PDM, which is primarily used within Engineering.

    In the PLM context, data managment is is more of structured data (BOM, AML, AVL…)required for downstream planning, manufacturing and service and also the design data as it reaches some milestone (prototyping or pilot manufacturing or final production).

    • Hey Ganesan. I think you bring up some legitimate and interesting points. 

      If PLM is purely about supporting processes, which I believe it is, then anything with a workflow engine and project management capabilities qualifies. Although things like CRM and ERP also have other integrated capabilities beyond workflow. But I admit, that turns into a slippery slope. However there are new solutions, like Autodesk’s PLM360 and Kenesto, that act in this way.I think I see your point about PDM. However, there is WIP data management across many functional organizations. Engineering certainly has that with CAD models (ECAD, MCAD, UML Software models, etc.)  as well as documents for specifications and the like. However, service organizations have WIP representations of their operations and the documentation that represents it. Manufacturing has a similar parallel in terms of tooling design, CNC tool paths and the like. Procurement iterates on AML and AVL constantly in a WIP-like state and releases it for compliance. Deliverables from any organization goes through a WIP phase before it is ‘released’.

      So on that last point, are you saying the PLM is only supposed to contain deliverables or representations that are in a ‘released’ state?

      • Ganesan

        Hi Chad,

        I am not familiar with Autodesk PLM 360 or Kenesto. But, in all my PLM implementation projects, the central thing is product information management. The processes in PLM are in one way or other falls under creation, review, observe, approve or release some kind of product information which could be an item or a BOM or a document or Engineering change. That is i am uncomfortable when you limit that PLM is purely about supporting processes wihout including the Product Information Management.

        Let me answer your question on “is PLM supposed to contain deliverables that are in a released state?” . PLM is the paltform for collaboration between R&D and all downstream for product information. So, whenever the product information is ready to be shared with downstream like “sharing an early BOM to get feedback from procurement or to prepare the planning or when the PCB or PCBA is ready for prototyping or trial manufacturing,  it should be shared through the PLM. On the other hand, the design WIP system manages the everyday progress in the development. 


        • I think that’s an interesting distinction using upstream and downstream participants as the difference between PDM and PLM. I think that is a concept that should be represented somehow.

          My only point was that PDM actually applies to a lot of other organizations as well as engineering, whether that be before or after the product is released to manufacturing, because those organizations also have deliverables that mature, progress and eventually can be viewed and consumed by others.

  • Great discussion Chad…I tend to align with the CIMData definition as stated by Stan…But sometimes I wonder if we spend too much time trying to define the TLA rather than focusing on delivering business value?  My hope is vendors make PLM so transparent and useful that the users of PLM enjoy the benefits – without having to know the acronym…Call me a dreamer…

    • I think this sort of conversation gains a lot of traction because of two reasons. First, people want to make sure that when they have a conversation about PLM, they’re talking about the same thing. Second, they want to be able to compare like types of solutions.

      But you have a great point. Sometimes we go so far down the path of splitting hairs that we get lost in the definition of things instead of understanding the value of things. That would make an interesting post… the varied ROIs of PLM. 

      I’ll put that on in the queue! Thanks!

  • Interesting discussion and perspectives. My thoughts on this are simple…the key word in PLM is Product-every business of every stripe is producing a product. From services to manufacturing and back, companies build and sell Product. So, one can argue that all companies can benefit from PLM-right? But hold on…let’s take it another step. The core conversation re PLM is not about needing-but about doing-PLM. Think about it…no two companies have identical processes, and therefore, they likely have dissimilar approaches (processes) in place to execute (do) PLM. But they have PLM.
    There are existing business rules/norms that companies all execute against that I refer to as Persistence-those key process elements that are not bound to any specific industry or product. Companies are ‘doing’ PLM-just not in an organized, efficient, and repeatable way.  In my opinion, the opportunity is not to introduce PLM, but to reintroduce PLM. 
    Improvement and innovation are not dependent upon technology, however, without tools, there are limits to the degree of improvement, and speed of innovation, that can be achieved. Regarding PLM technology, the play is simply to deliver the consistency and where possibile, the automation that drive waste from the existing product lifecycle, and enable an environment for improved collaboration and work between peers and partners. In business, it is all about how efficiently we communicate-after all, communicating is what we do when we collaborate and work. For me, PLM is a discussion about improving what you already do, and how you do it. My definition of PLM is “improved communications”-by whatever means and methods that suit the business.

    • Hey Chris. Thanks for jumping into the conversation! It’s always good to hear a new perspective.

      In your first paragraph, I would agree with your following statement…

      Think about it…no two companies have identical processes, and therefore, they likely have dissimilar approaches (processes) in place to execute (do) PLM. But they have PLM.

      … with a minor exception: replace the acronym PLM with product development. Every product company executes process in a larger product development process. Furthermore, every product company today has a technology or technologies they use to support that product development process. In many cases, its an entire ecosystem of the stuff. But I guess my point in all this is that it doesn’t HAVE to be PLM. In fact, many organizations don’t have PLM or anything that resembles it. They’re using email, word processors, spreadsheets and the like with no centralized system… maybe other than ERP.

      What do you think of those thoughts? I’m seriously interested to understand if I interpreted your points correctly.

      Terminology is such a bear in this industry. It makes conversations like these challenging. But I 

      • Chris Atkins

        I think we are tracking with each other…I would emphasize that business is less interested in technology than in the results, i.e., the product that comes from the business process. In some cases (and businesses), there is minimal need to utilize technology to achieve the objective. 

        Think back to the days prior to personal computers and productivity software-the work got done in spite of the obstacles. Arguably, PLM exists today much as it did then. The key difference today is that with the adoption of technology, there is an expectation that somehow we are more (most) productive. However, this target expectation is often misaligned with reality when you consider the massive effort and support that is needed to achieve and maintain what is often marginal, or worse, vague benefits and ROI. In my opinion, the unmet challenge for technology is to deliver the improvements in a manner and environment that essentially simplifies how one achieves the benefits, without the hassle and complexity that has become the typical user experience.My point is that PLM is in fact a process used by business to deliver product. Computers and productivity applications are merely enabling resources. In my opinion, the cornerstone in product lifecycle is process improvement, without which, the technology only gets you to a bad result…faster. Characterizing PLM as a set of tools is okay-provided that the discussion regarding tools includes an evaluation of the business problem, properly aligned with the business need for improvement. That is the best practice for determining the “if” and “how” for technology going ahead.

  • No worries. I think professional disagreement is a perfectly healthy thing. I don’t feel an overwhelming need to utter convince everyone I am right. My objective here is to provide a context for me and others as a backdrop for when we talk about other topics related to PLM.

    Can I ask you a question for clarification? If there is such a thing as a PLM strategy or initiative that is business in nature, and not IT deployment / maintenance in nature, what did the PLM strategy look like 20 years ago before PLM systems existed? Furthermore, what is the objective and metrics related to a PLM strategy? If it existed prior to PLM systems existing, then I would think the objective and metrics would not be related to PLM. I’m just trying to understand.

    As to your question as to why we need new names, and maybe we don’t for some of these more granular areas, I’m afraid there has been a lot of confusion because people are calling all of these things PLM. And that can be a problem. Here’s an example.

    Someone asks how long it takes to deploy PLM when they really mean CAD, CAM, CAE, PDM and process enablement. Someone else, thinking PLM is really global PDM, provides an answer. Those two people are on two completely different pages. The second person essentially provided an answer that is misleading and potentially damaging. I find that scary. Especially if the first person takes that answer to their CEO to get budget approval. It could eventually cost them their job. Yikes.

    Like I said before, I don’t mind what the names are, but I do think we need some type of common framework we can all reference to quickly and clearly identify which part of this whole IT ecosystem we are discussing.

    • Stan Przybylinski

      Hi Chad,

      Let’s see, I was not in the industry 20 years ago, but in the early 90s we had early PDM systems like Sherpa and a toolkit called Metaphase. Cars were made in clay models, which were measured by hand to create stamping dies. Bills of material were on paper, or in that timeframe possibly in spreadsheets (maybe even Lotus 1-2-3). SneakerNet was rampant. My point was not so much what the system was, but that people were developing products that had lifecycles before they had PDM, cPDm, PLM or whatever. If you remember, auto product cycles were in the 5-6 year length. People had a product development strategy, not TLAs (or at least different ones).

      As to your second point, that is why when we work with end user companies we take a strategic planning approach, looking at vision, mission, and then getting into requirements (a lot about pain points) to determine objectives and tactics. There are very few companies that are starting from a clean sheet of paper with no TLAs, so those requirements need to consider the existing toolset and processes. As this thread as shown, part of the failure of PLM (a system or a strategy) is that expectations are not appropriately set, monitored, and evaluated throughout whatever it is you are implementing, IT or not. And creating this framework for communications is an important part of that, so I hope that I have helped in some small way.


      • I think I understand now. The way I’m reading you, PLM is basically the tech infrastructure used to support product development, which has changed over time. Then it was a combination of spreadsheets, notebooks, email and whatnot. Now it is a formalized enterprise system. I think I understand your definition better now. That makes me think of circle #6 in the figure above.

        • Stan Przybylinski

          Yes, we see it more as a number 6, with other IT stuff not on your list being possible.

  • Anonymous

    Chad, great article and comments! 

    In my view, the reason why we have returned debates about PLM is Autodesk PLM 360. During my panel discussion earlier this week in Munich (PLM Innovation 2012), the debates between vendors came to the point that “Autodesk definition of PLM” is probably different from “PTC definition of PLM”. This is clearly shown that PLM vendors will be trying to dismiss competitiveness of Autodesk PLM by “redefining the TLA”. So, very predictable to see why it is going all over again. Just my thoughts…

    I posted about definition of PLM in examples few time during past two years. Here are links to these posts: 

    Siemens PLM and Al Dean (Hilarious one- don’t miss it)

    Autodesk PLM definition by Steve Bodnar at AU 2011

    Dassault PLM definition by Al Bunshaft

    PLM definition by PTC

    BEst, Oleg

    • Thanks for commenting Oleg. I agree that different software providers are defining PLM differently. I am sure that will make for more confusion in the market.

      Thanks for sharing those images. Good to get documented proof!

  • Steve Ammann

    I think if we can put PLM in context with the other Enterprise platforms it helps frame the definition of PLM for people that are running companies and/or trying to get a product to market. In 2012, it seems to me that we have the big three. CRM – roots in the customer record, and yes great business processes on top of that,  ERP – with roots in inventory and great business processes on top of that, and PLM with roots in the product definition or product structure and yes you guessed it, excellent business processes on top of that.
    CRM – based on the customerPLM- based on your virtual productERP- based on your inventory and/or physical productYou really should understand your platforms to understand PLM and please don’t let the transactionally based ERP folks that have the CFO’s and CTO’s ear, tell you PLM is just another process under the ERP umbrella, unless you want your product design group to quit.Here is a product lifecycle view of Platform importance/use – hope it helps clarify things- SCM ( supply chain management) has been included in the PLM footprint now and that makes sense, because the roots of PLM- virtual product- support the supply chain business processes.