One of the topics that people often ask is what is the difference between PDM and PLM. The question is almost rhetoric, since the number of explanation is +1 from the number of people involved into the discussion. I stumble on the following article in the FISHER/UNITEC blog – PDM or PLM: Top Down or Bottom Up. There are two important point that caught my attention. First point was about the gap between the product design (CAD) and the layer of managing financials, material requirements and manufacturing planning (ERP). Here is my favorite passage, which clearly position the problem:
Most will agree that the gap between CAD and ERP is too great to ignore the value proposition of the two “middle layers”. However, which should be selected and in what order: PDM or PLM? Additionally, can a typical manufacturer select just one or the other?
CAD Data Management
Wide adoption of CAD system created a crappy problem – what to do with all CAD files and other information CAD systems produce? People are not good in the organization of their data, in general. Engineers are interesting in how to create product design, but not much interesting in how to organize and manage the results. So, CAD Data Management was born. It called TDM, EDM and lately PDM (Product Data Management). As mentioned in Fisher/Unitech blog, many years of CAD data management implementation made it almost perfect:
The PDM solutions marketed today offer near-perfect CAD integrations, because they are typically developed by the CAD vendors themselves and come with a guarantee that new releases of CAD will be supported by them. Additionally, the many complex features of a 3D parametric CAD system are supported by the PDM system available from the same developer. As an example, SolidWorks Enterprise PDM offers simply the very best CAD integration to SolidWorks available on the market.
However, as soon as functional requirements are going beyond simple CAD file management or going beyond support of a single CAD system / environment, the implementation becomes crappy. PDM is a crappy solution for a crappy problem created by CAD.
Product Development and PLM Implementation Gap
Despite well defined, development of systems that support product development from various standpoints wasn’t so straightforward. For many years, ERP was the only system that was visible on the organizational level to manage processes, materials and production. Engineering was considered as a “black box” that needs to be self managed. Engineering supposed to through the results of their work over the wall to manufacturing and execution. The efficiency of this organization was sufficient probably 15 years ago. However, nowadays it is not so anymore. Global development, competition, cost management and many other factors raised need to create more transparency in product development management.
So, the value proposition of PLM became obvious. Now, PLM implementation became the issue. The PLM implementations are complicated, requires lots of service work and corporate involvement. In the real world, only very big companies can handle it. In order to take PLM implementation to mainstream, software vendors created so called “best practices” or “out of the box solutions”. It was good for marketing. The reality check didn’t show as a success, in my view. Most of the “out of the box” PLM implementations are not going beyond CAD file management.
Another problem of PLM implementation is CAD file management. In most of the organization, PLM implementation has to deal with multiple CAD (and sometime PDM) systems. Quoting the same blog:
Conversely, PLM systems today provide application support for managing product data and it’s metadata. Applications like engineering BOM management, configuration management, portfolio management, quality management, project management and supply chain management are available and native functions of a PLM solution today. However, because of the many 3D parametric CAD brands on the market, the PLM software developers and resulting systems do not normally have robust CAD data management capabilities that are always in step with current releases and design features, as noted above.
What is my conclusion? I can clearly see the gap between an organizational need to have a robust and scalable system to support product development (let’s call it PLM to be consistent with industry terminology) and maturing of PLM and PDM implementation. For me, bottom up approach makes more sense. People are trying to stay away from complexity these days. The next generation of PDM/PLM will need to take it as an axiom for a future success. Just my thoughts…
Best, Oleg
