Two Origins, One Destination? A Look at the Two Main Genres of PLM Solution from the Integration Standpoint

A Brief History of PLM

Product lifecycle management (PLM) originated decades ago in the discrete manufacturing area, for the purposes of storing and managing product definition information (mainly computer-aided design [CAD] data). At that time, this kind of management system was usually called engineering data management (EDM) or product data management (PDM), and management of product definition activities mainly resided within the design department.

As time went on, people realized that having a consistent information source across departmental boundaries—and later on, throughout the extended enterprise environment—would be extremely beneficial in speeding up product development processes, serving customer needs better, and aiding faster and less expensive production. With the idea of facilitating collaboration between the producers and users of product definition information, as well as the entire life cycle of a product, PLM has taken shape and become an exemplary management methodology, not only for discrete manufacturing, but also for other industries such as process manufacturing, high-tech, consumer packaged goods (CPG), and even services.

Two Genres of PLM Vendors

Before going further, it is worthwhile examining what PLM represents in terms of solution offerings. Although multiple PLM definitions exist and the industry has not reached a consensus about what a PLM system is, people tend to consider PLM as consisting of two major categories.

1.  The first category is sometimes called "PLM tools," which includes various computer-aided technologies for manufacturing such as CAD, computer-aided manufacturing (CAM), and computer-aided engineering (CAE).

2. The second category is known as collaborative Product Definition management (cPDm), which manages the documents and data generated by PLM tools and provides a collaborative platform for different parties within the product life cycle.

Due to PLM's origin in engineering and the heavy requirements of CAD integration in core cPDm functionality for discrete manufacturing, major PLM vendors (such as Dassault Systèmes, Siemens PLM, and PTC) have significant presence in CAD and related areas. These three vendors now provide both PLM tools and cPDm solutions, and hold almost a half of the total PLM market revenue (data source: AMR)[1]. The reason for the strength of these CAD-PLM vendors is obvious—they all started from CAD and developed cPDm solutions along the way by responding to their CAD users' demands for managing product definition information.

Meanwhile, another group of vendors provides cPDm solutions without CAD/CAM/CAE functionalities. There might be various reasons for non-CAD vendors to go to cPDm even though they don't provide PLM tools; and after a series of acquisitions (e.g. Infor's acquisition of Formation Systems, Oracle's acquisition of Agile, and more recently, Lawson's acquisition of FreeBorders PLM), it is becoming clear that enterprise resource planning (ERP) vendors are establishing themselves in the PLM market. These ERP-PLM vendors don't have a CAD advantage, but their extensive install bases in enterprise management systems may increase sales opportunities for their PLM offerings. After all, to many users, PLM is just another management system.

There are also other cPDm vendors who provide neither CAD nor ERP systems, but the CAD-PLM and ERP-PLM vendors are the two mainstreams in the PLM marketplace. Is there any difference between these two genres? Yes; and an easy way to understand one of the major differences is to examine the two gaps PLM needs to bridge in the enterprise environment.

Two Gaps between Product Definition Information and the Enterprise Environment

Ideally, there shouldn't be any gaps. Although major product definition information is generated by the design department of an organization, this information should be accessible instantly—not only by the design process, but also by consequent processes such as production, marketing, sales, and other services. Meanwhile, data from production, marketing, sales, and other services are valuable inputs for decision making during the design and development phases. However, due to the fact that during the early days of development, CAD and enterprise systems were developed in significant ignorance of each other, the gap became an obstacle when people started to realize the benefit of having an integrated environment that would cover almost every activity associated with a product's life cycle.

PLM was the choice for filling in the gap. In fact, the PLM approach actually fills in two gaps. The first is between PLM tools and cPDm. This gap is mainly handled by CAD integration. The second is the one between cPDm and ERP, which is usually handled by enterprise/ERP integration.

Would it be better to connect product definition data directly with an ERP system? No—not very likely. First of all, ERP is good at handling transactional data, but not necessarily good at handling the richness of product definition information. Second, ERP only needs certain parts of all the available data from a product definition. Third, due to the fact that "PLM tool" and ERP industries were formed separately, cPDm is the best solution bridging these two systems. Nowadays, both PLM-tool vendors and ERP vendors recognize that offering cPDm is a strategic direction to take.

Who Is Good at What?

So far, we have discussed the two main genres of PLM (or more precisely, of cPDm) players. Because of the different development histories, knowledge, and technologies of these two types of PLM, there seem to be differences in the capabilities that fill in the two gaps. To visually illustrate the differences, I randomly selected from the Technology Evaluation Centers (TEC) PLM Evaluation Center two PLM solutions from vendors who do not offer CAD products and another two from vendors that are significantly involved in CAD. Comparing the four solutions' scores for CAD integration and enterprise/ERP integration, we can deduce that a solution that scores higher on CAD integration gets a lower rating on enterprise/ERP integration, and vice versa (see figure 1).

Figure 1. Four solutions' scores for CAD integration and enterprise/ERP integration (data source: TEC).

Although four solutions do not represent the whole PLM industry, it is reasonable to think that CAD integration and enterprise/ERP integration require different technologies and knowledge, and that these differences are a reflection of the vendors' areas of expertise.

Which One Is Good for You?

Recognizing the origin of a PLM solution is meaningful when you need to identify the best-fit PLM solution for your organization. The following three factors may help you clarify your integration needs and affect your selection result.

• Use of CAD/CAM/CAE in your organization: In general, the more complicated the CAD/CAM/CAE landscape, the more likely the need for CAD-PLM. A CAD-PLM vendor has the unbeatable ability to integrate its own CAD products. Due to long-time practice in PLM tools, CAD-PLM vendors are also making advances in regard to integration with other CAD products. However, this doesn't mean that ERP-PLM solutions won't get contracts from CAD users. Some mainstream CAD products are now supported by third-party integration tools that may be able to meet satisfactory integration requirements. In the meantime, major ERP-PLM vendors are working hard with CAD vendors to increase connectivity.

• Industry and product features: If you are a discrete manufacturer and you have a complicated product structure, CAD-PLM is probably the one that you need. If your products do not have a complicated structure or have no structure at all, the vendor's industry focus might be a more important criterion in the software selection process than the vendor's origin (i.e. CAD or ERP).

•  Level of integration: You should also evaluate your expectation of the integration level. Seamless, real-time, and bidirectional integration is the ideal of every IT manager, but achieving this could be very costly or even impossible. A better approach might be to set reasonable and prioritized integration requirements for both CAD and enterprise/ERP integration, and to use the prioritization to help determine the genre of your PLM solution.

The Outlook

Although there continues to be a difference between CAD-PLM and ERP-PLM in terms of integration capability, the gap is closing in.

From a technological point of view, the PLM industry is using two major approaches to address integration issues.

First, the integration amongst individual products is continuing nonstop. With this philosophy, CAD, cPDm, and ERP vendors are working together to build connectors between one specific product and another (e.g., the integration between "PTC Pro/ENGINEER Wildfire" and SAP PLM).

Second, there are technologies that support non-product-specific integrations. These technologies include, but are not limited to, the following:

•  Industrial standards—such as the International Organization for Standardization 10303 (ISO 10303, also known as the "Standard for the Exchange of Product model data," or STEP, is an ISO standard for the computer-interpretable representation and exchange of industrial product data)

•  Data integration middleware—software that connects applications to enable data integration and interoperability

•  CAD integration tools—special middleware that enables the PLM and other management systems to acquire CAD data and to maintain the integrity of product definition information

•  Service-oriented architecture (SOA)—a method that allows different applications to exchange data with one another as they participate in business processes

As technologies keep advancing, CAD-PLM vendors will accumulate more experience in the whole enterprise landscape. And, as ERP-PLM vendors step deeper into the product design and engineering domain, CAD-PLM and ERP-PLM solutions will become more alike, with fewer differences. One day, the origin of a PLM solution might not be so important in terms of integration capability. PLM will be just PLM.