Choosing and evaluating products for managing data is a daunting task. With the ease of access to broad, general information – which is often conflicting – getting your decision-makers and Very Important People using the same vocabulary is the first step to developing a conclusion. One of the mistakes I often encounter while providing release management life cycle consulting for Bay Area engineering firms is the misuse of the terms “PDM,” product data management, and “PLM,” product lifecycle management.
PDM software – Product Data Management – was traditionally designed by the application developers. SolidWorks produced PDMWorks to manage .sldprt files, MentorGraphics developed DxDesigner into a PDM for their PADS and HyperLynx suites, and PTC released Pro/INTRALINK to manage Pro/ENGINEER data. The simplest goal of a PDM system is to act as a file vault for securely storing and sharing data; however, PDM products are often purchased to optimize reuse and enhance design functionality. For example, OrCAD uses CIS Libraries religiously to allow reuse of common Electrical CAD designs, reducing development time for Research & Development. PDM implementation is almost always done at the request of the R&D team, and PDM management is often undertaken by individuals in R&D or outsourced consulting services hired by R&D.
Smaller companies typically function with a single PDM tied closely to their most common CAD environment. The selling point of using the PDM is the improved productivity of the CAD users. Later, these smaller companies adopt methods of integrating PDM to PLM, producing robust infrastructure systems.
PLM software, on the other hand, is designed for Product Lifecycle Management. All PLM systems include process automation and/or workflows of some kind, which are designed to improve Operations productivity and metrics. Most PLM systems communicate with multiple MCAD and ECAD programs, resulting in less detail and integration with each individual application. Whereas the PDM systems are designed for R&D consumption, the PLM systems include features for Operational Executives – such as web-browser interfaces and “CAD preview” windows. A PLM implementation will usually be shared by the entire company, whereas a PDM system will be used only by the people who need it. The broad, overarching nature of PLM also causes it to cost significantly more than PDM solutions.
Every time I see a company with a PLM system used as their PDM system, it’s been a “push down” implementation from Operational groups (i.e. Information Systems) into R&D. It’s an easy mistake to fall into since the PLM management “experts” are not the PDM users, but the infrastructure management services are being provided by the Operational groups, who would prefer to support a single system than integrate multiple applications.
Recently, I was brought into a medical device firm to resolve a short-coming they had revealed during an FDA audit. To summarize: their Information Technology department was unable to upgrade their PLM system in a timely manner due to the lengthy Computer Systems Validation process required by the FDA; the R&D department was being forced to use a 4-year-old CAD system to maintain compatibility with the outdated PLM system. Some Engineering teams upgraded their CAD tools to the newest version, abandoning any use of PLM (or PDM) systems, instead relying on a manual process in their product development. Ultimately, someone made a mistake in their pen-and-paper based audit trail, leading to significant remediation.
The most successful PLM implementations I’ve seen in medium-to-large sized companies always include one or more separate PDM systems tied to a single PLM system:
- A separate application-specific PDM system allows the Designers and Engineers to utilize all the advanced features they want, add additional system functionality if desired, and update any software they need (SolidWorks is notorious for forcing users to use the newest version). This “small-scale” mentality allows the R&D teams to remain nimble and use cutting-edge technology.
- The PDM-PLM connectors – such as the products developed by Zero Wait-State – need to be configured to communicate with the PLM server. It needs to be automated and bi-directional so that the PLM Workflows are triggered appropriately, establishing the efficiency and consistency produced by the PLM services.
- And, finally, the PLM system can be updated (or not) independently of the PDM tools. This stability reduces the necessity and overhead of repeated CSV remediation, infrastructure support services, and complex user training.
Next time, I’ll go more in-depth comparing features of specific Mechanical Engineering PDM examples: Agile Engineering Collaboration 3.0, PTC Pro/INTRALINK 9.1, and SolidWorks Enterprise PDM 2011.
Edwin Chung
Application Integration Engineer, SPK
