Two recent blog posts by Oleg Shilovitsky (PDM vs. PLM: A Data Perspective and PDM vs. PLM: A Process Perspective) got me wondering about what a true product lifecycle management (PLM) system actually is.
In his posts, Shilovitsky discussed the differences between product data management (PDM) and PLM from the perspective of
- data (scope and control of the data) and
- process (coverage of product lifecycle activities)
I have a bit of a different perspective.
Let me back up first and look at systems being implemented for product development and collaboration (PD&C) (I’m using this term to avoid “PDM”/”PLM”). My question is this: what are the scopes of interaction between PD&C and users, on one hand, and between PD&C and other systems, on the other hand?
1. Degree of organizational involvement
Today, many manufacturers have capabilities in place to store product data, manage development processes, and facilitate collaboration. What varies among these PD&C systems is the degree of organizational involvement (i.e., how many parties are using the system). The range is from one (the design department) to the extended enterprise (including the manufacturer and its major product stakeholders such as customers, suppliers, and other partners).
Generally speaking, the degree of organizational involvement is positively related (not perfectly though) to the scope of functionality—the more functionality, the more parties involved. You can take a look at the request for proposal (RFP) template of PLM and PDM (free samples available following the links: PLM RFP Template, PDM for Discrete Industries RFP Template, and PDM for Process Industries RFP Template) to have an idea of the difference in functionality between PLM and PDM.
2. Degree of integration with other systems
Mainly concentrating on information in the product domain, a PD&C system alone doesn’t fulfill everything that a company needs to optimize its decision making and collaboration around products. The value of a PD&C system is related to the degree of how it can work with other systems. The low end option is the one-way linkage (or data export), through which product data can be retrieved from other systems, and the high end is the bi-directional integration, where a PD&C system not only provides data to other systems but also consumes information from its peer systems (such as enterprise resource planning [ERP]).
Figure 1. The organizational involvement—integration with other systems matrix
Based on the two degrees, I was able to draw a matrix (figure 1) and found four situations that a PD&C system might fall into:
Quadrant 1 - PDM: The PD&C system is mainly used on a departmental level and serves as an information source of product data for other systems.
Quadrant 2 - “Advanced PDM”: Product designers/developers are the system’s users but some information (such as sourcing, production, and quality) in other systems can be routed to the PD&C system to help product designers/developers make better decisions.
Quadrant 3 - “Manual PLM”: Many different parties can access the PD&C system but due to the integration limitation, many inputs require manual entry. For example, a key supplier can view product information stored in manufacturers’ PD&C systems but can only provide feedbacks (e.g., delivery dates) manually through the interface.
Quadrant 4 - PLM: Product stakeholders are able to access data in the PD&C system as needed (through the PD&C system or their most often used systems) and data exchange between the PD&C system and others is automated and synchronized.
If you are currently located in the PDM quadrant (as I know, many companies are), the matrix can serve as a tool providing three paths toward PLM:
Path 1: PDM -> “Advanced PDM” -> PLM
Path 2: PDM -> “Manual PLM” -> PLM
Path 3: PDM -> PLM
You may choose to go with any path as you see the best fit to your business requirements and available resources. If going directly from PDM to PLM is not an option at the moment, a big question you need to answer is which goes first—people integration or system integration?