Welcome to this The PLM blog post
originally published in 2011.
The discussion about PDM vs. PLM is still relevant today.
What do you think?

My wife loves HGTV and we spend a significant amount of time watching various shows about home renovation. Often times, these renovations can be quite extensive and I wonder at what point do you decide you are better off just finding a new house? I see a similar phenomenon in the product lifecycle management (PLM) space with companies building out or enhancing existing applications. Sometimes, this is a viable strategy to extend a useful tool to meet additional needs. However, at some point it can go too far and you must be able to assess when your current product data management (PDM) or PLM system has reached its limits and additional modifications would be ill advised. Adding a gourmet kitchen to 1000 square foot duplex just doesn't make sense and trying to turn a PDM system into a PLM system with add-ons doesn't work either. The other side of this coin is that if it works for your company there is no need to toss it out and replace it with something more complicated. Like many other things, it is a balancing act that requires wisdom and discernment on the part of management. This article will analyze what types of modifications for PDM and PLM are reasonable and which ones will tip the scales towards trying to find a new neighborhood.

Smaller companies and some larger ones typically start out with point solutions that manage data for specific applications or groups inside the company. Eventually they start to recognize the value of product lifecycle management and look to expand the footprint of the system. This is done by engaging more users throughout the company. But with these new users come new requirements that can tax an application-specific PDM tool beyond its limits. Enterprise PDM from SolidWorks (EPDM) is a good example of an entry-level system for data management and workflow. Many smaller companies will leverage this product as their first data management tool and as they grow seek to expand its capabilities. This approach is sound to a point. Once you start to get into the more complicated aspects of PLM, this strategy starts to fall apart. You reach a point of diminishing returns.

Before we expand on this idea we should review what types of expansion of PDM are reasonable and viable for a small company that is just embarking on trying to automate their product development environment. Most of the enhancements to products like EPDM can be done via scripts that can be delivered via consultants. We are looking at this methodology and will be creating standard applications based on the most useful products. One area where entry-level PDM tools can use some enhancements is in the change process. Custom enhancements can enable things like setting up a change control board with voting. EPDM and other tools allow some form of basic routing out-of-the-box but any formal change control would require some work. This is an area where things have the potential to get out of hand, so change requirements need to be fairly straightforward if you are planning on addressing them with a PDM tool. Another related area would be enabling PDM to manage more file types and to be accessed from areas outside of CAD. Office2PDM is a tool developed by Extensible CAD Technologies that brings EPDM capability to Microsoft Office applications. This would allow a broader audience to take advantage of EPDM's vaulting technology and allow easy check-in of non-CAD information into the vault. This seems like a useful function and a reasonable addition to a PDM application. Project Management is also a natural extension of PDM. 360 Enterprise Software has developed a suite of products that extend EPDM information into the enterprise and link the information to project management tools. Depending upon a company's requirements, this could be a reasonable intermediate step to adopting a full-blown PLM solution.

The last enhancement for PDM would be the ability to export information from PDM directly into an ERP application. This is the point where the differences between PLM and PDM can start to create issues. The problem with ERP is that the type of information it is expecting is fairly far removed from the type of information a PDM application captures. PDM tools are more concerned about files than they are about product structure. While the information the ERP needs may exist in some form or fashion in the PDM, getting it out in the right format could be a tall order. Generally, if you are looking to create bill of material (BOM)-type information for an ERP system, you are better served to go ahead and invest in PLM, but there are always exceptions. One of the key differentiators is that PDM systems tend to track information in more of a file structure. This is the reason a tool like EPDM is so popular among SolidWorks users. When looking at the interface, it very closely resembles the file structure of Windows Explorer. The now defunct Product Point from PTC offered a similar interface that was also considered very user friendly. PLM tools focus on product structure as opposed to file structure. Attachments are a secondary consideration to the actual structure of the product itself. Sometimes the structure in CAD assemblies mirrors this and sometimes is does not. It really depends on how companies utilize CAD tools and the types of products they make. There is a trend in the industry to source more items for product design that are not necessarily modeled and you also have information coming in from electrical design systems as well. Most PDM tools are CAD specific so they don't do particularly well handling relational data from other CAD tools. One of the reasons PTC discontinued Product Point was its lack of multi CAD support. If a company's manufacturing BOM is a blend of sourced and made parts coming from multiple systems, then PDM may fall short as a solution and certainly will not be an ideal source for an ERP system.

There are several other areas where PLM provides capabilities far beyond PDM and where expanding PDM could be ill advised. Supply chain management is one of these areas unless the requirement is just access to CAD information. There are numerous features for supply chain management including costing, availability, and reporting that can hinder a company's ability to effectively control supplier data. PLM offers a robust set of capabilities for this area that blend functionality from design, quality, and manufacturing to allow companies to optimize their supply chain and meet requirements for cost and time. Other areas where PDM falls short and where customization or enhancements could be challenging are in workflow capabilities. The workflow engines and the logic for configuring them are quite robust in most PLM tools. Recreating anything close to this in PDM tools would be very costly and would ultimately be limited by the architecture of the system. If a company wants to fully automate the change process and implement closed loop architecture, PLM is really the best platform for this due to the built-in process templates for these use cases and the ability to configure workflows via a user interface. Specialized functionality like governance and compliance with both environmental and medical regulations is also something that is more easily achieved with PLM due to architecture and prebuilt capabilities in PLM.

Obviously, there is a place for both PDM and PLM and it is not always a good decision to replace PDM with PLM when just adding a little capability to your existing application will address your immediate needs. There is also a point where enhancements and add-ons will create an unstable environment with limited tools, so executives really need to understand their business objectives thoroughly before making decisions one way or the other. PDM is a good start for a company looking to optimize their product development process and may serve a smaller company's needs for quite some time. We tend to need to view things in extreme contexts where it is always one way or another and in complex situations like most companies have, these generalizations don't always apply. Sometimes it is better to fix up what you have rather than bring in an entirely new system. This is the lesson you learn in watching home improvement shows and in the efforts to improve process and product development capabilities.