There has been a spirited discourse recently on the role of product data management (PDM) and product lifecycle management (PLM) in the product development process. Several weeks ago Oleg Shilovitsky wrote a blog article titled, "Integrate PLM and PDM: Wrong Question?". In the article he debates the advantages of leveraging PLM solutions in a comprehensive manner versus integrating existing systems into a PLM system. As a company that works with enterprise level tools like Oracle's Agile PLM and PTC's Windchill PDMLink while also offering integration solutions for SolidWorks EPDM and PTC's Intralink we have seen both sides of this discussion. To select the correct approach one must understand the differences between PLM and PDM and the unique requirements of product development. It is impossible to prescribe a "one size fits all" solution to this issue. It is dependent on the tools and process a company uses and the types of products they design. This blog will define PLM and PDM in this context and outline the criteria that drive the decision on whether to integrate or replace PDM tools when adopting PLM solutions.

Oleg sites an article from SolidWorks written in 2008 that does a fairly decent job of defining PDM, but a fairly poor job of defining PLM. The article titled, "PDM vs. PLM: It All Starts with PDM", makes several claims starting with the title that I take issue with. While in some cases PDM is a starting point, there are many companies that begin product development elsewhere. Products like Agile, Arena and Aras have thrived without PDM and have worked off of a bill of material (BOM) structure that might not even involve physical files. The article claims that PLM is a superset of PDM yet many PLM tools existed for quite some time without PDM capability. I think the more accurate statement is that PLM and PDM share some similar capabilities. It is true that PLM and PDM share common functionality and that some systems embed PDM capabilities inside their PLM tools but this doesn't mean that all PLM tools evolved from PDM. Even PDMLink and TeamCenter are "ground up" PLM tools, not beefed up PDM applications. The bottom line is that both solutions vault data but that is where the similarities end. The other point in the article I take issue with, which Oleg refers to a little in his article, is that PLM is only for big companies. More accurately if you want to be a big company you will most likely need PLM. Oleg's point is that it might be more cost effective to integrate existing applications rather than replace them with PLM. This is something that has to be looked at on a case by case basis. The article from SolidWorks actually states "Usually, only large, global corporations have the resources to afford PLM and the breadth of enterprise to justify it." I am not sure this was even an accurate statement when this article was written three years ago.

I am sure there are many different definitions of PDM but I think the one that most accurately describes the capability in the context of today's applications is a data vault that is typically associated with a specific authoring tool. It could be specific to a computer aided design (CAD) or electrical computer aided design (ECAD) application or even a software version control system. The system will usually offer specific functionality related to the authoring tool data it vaults which makes it optimal for storing the data and offering necessary functionality for managing "work in process". These applications are designed to work with a smaller entity inside a company and are specific to managing certain types of information. They may offer some limited routing capability and some form of version and revision control but that is usually about it. Examples of PDM tools would include; SolidWorks Enterprise PDM (EPDM), PTC's ProductPoint and Intralink, Siemens' TeamCenter Engineering, Autodesk Vault, Allegro Design Workbench, Subversion, SourceSafe, etc. Some of these products blur the lines a little with PLM but for the most part they are clearly applications built to manage specific data types for specific types of functionality. The advantage these tools offer is deep integration with the authoring tools they work with. The downside is that they are not architected for broader adoption by users outside of engineering and lack some enterprise functions.

The SolidWorks article defines PLM as including customer relationship management (CRM) and enterprise resource planning (ERP). I think this is too broad a definition. Most PLM systems manage processes centered on developing a bill of material (BOM) and possibly the physical file attachments that the items represent. They also typically offer a robust workflow engine that can capture and automate processes that are oriented around reviewing and approving information. They can assign and track activities associated with the product development process. PLM provides a comprehensive view for the information and activities associated with the product development process. PLM typically works in unison with CRM and ERP and sometimes even PDM. Some PLM tools offer quality data management, product portfolio management, compliance management and supply chain management capabilities. All of these functions can also be handled by separate applications that specialize in these capabilities and some companies elect to handle these functions with their CRM or ERP products. There are numerous marketing slides from vendors that show PLM as the hub for various tools. The main advantage PLM offers is a common platform where all parties involved in product development can pull information. Even if companies elect to use specialized tools for different functions some derivative of the information resides in the PLM and feeds downstream applications like ERP. The big question is whether or not it is better to use the PLM as much as you can to create and manage these processes or is it worthwhile to leverage specialized applications that offer more robust capabilities in these areas and integrate between them all?

It would be dangerous to try and answer this question blindly. It really depends on a number of variables. Some companies standardize on a single CAD tool and have a very engineering centric process. These types of companies thrive with CAD based PLM tools like PDMLink, TeamCenter and Enovia. Other companies have more varied environments and use multiple CAD systems and use external manufacturing and design partners more extensively. They find that the BOM is a more important element for design than the cad files themselves. These companies benefit from broader based PLM tools like AgilePLM. Many companies are trying to balance elements of both a broad manufacturing and design environment with complex engineering and could benefit from integration approaches. As software becomes a more critical component for product design, integration becomes even more critical since most PLM tools offer very little for managing software development. There is no formula to point to that will determine whether PLM or PDM is the right answer for a company. I do think it is critical for product development companies that want to stay competitive to look beyond just vaulting data in a PDM tool. It is also important for companies to consider the impact of mandating a universal PLM platform without understanding how specific applications are being used and how much capability the PLM platform offers for managing specific types of information. There are tradeoffs between PLM and PDM tools. Integration is a viable strategy in many cases but it is not always the right choice. As I stated in my title it is a balancing act and it must be approached thoughtfully in order to ensure success.

[Edit: Repost from 2011]

[clear-line]