Call: (888) 800-4PLM | Email: [email protected]

To understand the terms better, it is useful to go back in history a few years. Until about 1999 the term PLM did not exist. Before, everything that had to do with managing product data was referred to as product data management (PDM) or sometimes also engineering data management (EDM). Most PDM software vendors had their origin in CAD, CAM and/or CAE, and the main purpose of PDM systems was the management and control of the large and complex data structures of their CAD/CAM/CAE (CAx) systems. In 1999, the leading PDM systems included functionality for CAD data management, some document management, configuration/BOM management, revision control and basic workflow management.

Then the term PLM was introduced and quickly adopted by the majority of vendors, who saw the opportunity to position PLM as an enterprise application and differentiate it from the prevalent engineering and CAx data centric stance of PDM.

With the expanding scope of PLM over the past years this distinction has become more pronounced. Today the consensus is that PDM is focused on the management of CAx data, whereas PLM encompasses the enterprise-wide management of all product related data and processes from ideation to end-of-life.

But, depending on the origins of the different PLM vendors, their views differ in terms of whether PDM is part of PLM or not.

PLM vendors with origin in CAx, such as Dassault, PTC and Siemens (formerly UGS), whose PLM systems largely evolved from the PDM systems they initially offered, generally position PDM as part of PLM and consequently offer functionality to manage CAx data with their PLM systems via integrations to the various CAx systems.

PLM vendors whose origin is in configuration/BOM management, enterprise change management or ERP, such as Arena, Oracle|Agile and SAP, often promote managing CAx data with a PDM system that is part of the CAx system and then to integrate the PDM system to their PLM system.

Both approaches or solution architectures have their respective advantages and drawbacks, and it is important to analyze related processes and define detailed requirements and practical use cases to be able to decide which architecture is the better fit for a company’s long-term needs.

Back to Top