Part 1 of this blog series started with the assertion that product lifecycle management (PLM) solutions are becoming increasingly important to enterprises, to a strategic degree. However, not all PLM products are created equal, especially in light of their different origins.

My post then explored the strengths and weaknesses of the first group of PLM solutions: those coming from stalwart computer-aided design (CAD)/computer-aided manufacturing (CAM) providers including Siemens PLM Software, Dassault Systemes, and PTC, with Autodesk and Gerber Technology only lately joining the PLM fray. Then I analyzed the advantages of the second PLM group: the Big Three enterprise resource planning (ERP) vendors, who are SAP, Oracle, and Infor. NGC Software would be an ERP and PLM combination in the fashion/apparel industry.

One advantage that ERP providers have over PLM vendors with a CAD background is that their vast suites of business applications allow users to integrate product development with program management/product portfolio management (PPM), supply chain management (SCM), manufacturing execution, and customer relationship management (CRM). ERP players have the ability to intersperse data about financial results, resources, products, and workflows throughout their product intelligence capabilities, thereby enabling key product strategy and execution decisions. SAP, Oracle, and Infor’s goal with their PLM software, based on their respective SAP NetWeaver, Oracle Fusion Middleware (OFM), and Infor10 business process platforms, is to improve efficiency across the entire supply chain, create more visibility for new product development stakeholders, and enable easier collaboration through centralized data management.

IT managers see ERP-based PLM offerings as an opportunity to reduce costs and improve data transparency across product development, sourcing, manufacturing operations, the back-office, and customer-facing activities. In the case of SAP, customers that purchase the SAP Business Suite and SAP ERP get a free SAP PLM license and can add new users at a low cost. Moreover, companies don’t have to support additional technologies and have full integration to ERP data, which should be a big order winner. This is all music to a CIO’s ears, right?

Not So Fast . . . the Cons of ERP-based PLM Solutions

But ERP providers do not offer their own CAD solutions: rather, they provide basic integration to these product authoring tools. Experience has shown that the research and development (R&D), engineering departments, and related users are not exactly big proponents of ERP systems. Although ERP providers have many capabilities in their PLM portfolios, not all are best-in-class. If a vendor doesn’t have its own computer-aided technology (CAx) offerings, fully understanding the real needs of engineering departments, especially with regards to interdisciplinary systems engineering, can be very difficult.

CAD and PLM systems are independent systems that are often acquired and installed at different times by different groups of users. Product designers in different parts of the same company may even choose different CAD desktop software packages. There are many, for example, PTC Creo Elements (formerly Pro/E or Co-Create) design customers who don’t necessarily use Windchill PLM and, vice versa. This situation also persists with Siemens and Dassault Systemes’ respective CAD and PLM offerings.

When a company decides that it needs to manage the entire product lifecycle, it will likely need to support multiple CAD tools, a PLM system, and an ERP system to boot. While buying CAD and PLM software from the same supplier has its benefits in theory (i.e., best integration, contract volume discounts, one source of support, etc.), there are other important considerations to take into account, including the best PLM capabilities, the best ERP integration, specific industry support and savvy, etc.

Ironically, a “whole enchilada” system by a single ERP-PLM provider might require higher costs and time to implement or upgrade as compared to implementing separate enterprise pieces. Limited (or non-existent) digital product and manufacturing simulation capabilities by ERP providers mean that at least a computer aided engineering (CAE) and CAM solutions at least will have to come from another supplier.

In cases of environments with multiple ERP systems or multiple customized instances of the same ERP brand, the question of a single provider becomes immediately moot. At the end of the day, the lack of knowledge of product design will really keep the ERP providers out of the PLM business in some industries, as the core modules in PLM suites should support the engineering processes first.

SAP and Oracle’s visualization capabilities (see Part 1) will certainly help with the non-engineering PLM users (who don’t necessarily need the data-intensive CAD models). In SAP’s experience, most customers who want to integrate their third-party PLM solution with ERP start by generating the manufacturing bills of materials (MBOM) directly. With that they lose the control over an end-to-end change management process.

This is why many design decisions are not reflected in manufacturing processes and, conversely, ad-hoc changes from manufacturing operations are not told to engineering. This combination is a nightmare when it comes to product variant configuration processes as the engineer to order (ETO), configure to order (CTO), or assembly to order (ATO) process gets broken when “as designed” is not same as “as manufactured.”

Current (Sad) State of Affairs of PLM Implementations

Indications are, and recent user surveys show, that PLM systems (including CAD, CAM, CAE, and MES) rarely meet all of their touted expectations. Instead of arguing about systems and their origins, many PLM constituents would prefer to discuss how to help customers solve the major problems of bringing products to the market faster, more efficiently, and compliant.

The reality is that a PLM implementation often means a product data management (PDM) implementation in an engineering department without implementation of very many collaborative PLM processes with other departments and trading partners. See Kurt Chen’s blog post on the differing scopes of PDM and PLM.

Another reality is that most of CAD-based PLM vendors’ revenues still come from their CAD businesses (over two thirds of revenue). On the other hand, SAP’s 8,000 PLM customers on paper make it the PLM market leader. Some PLM market-sizing firms such as CIMdata put SAP and Oracle amid the Top 5 PLM providers (based on their PLM revenues). But the skeptic in us asks how many total active (maintenance) PLM seats does SAP have and how many PLM seats are bundled with ERP seats and therefore not necessarily in use, i.e., in the “bought but not implemented” category?

This is where the PLM math gets a bit fuzzy: do PPM and ideation, both modules of PLM, count as a full-fledged PLM user? SAP’s PLM revenue includes much PPM revenue: as many as 500 or so customers in our estimates that use PPM in their IT, R&D, and marketing departments. Moreover, SAP PLM is a part of SAP ERP—the best example is the SAP PLM 7.01 version, which is also called SAP Enhancement Pack 5 for SAP ERP 6.0. SAP likely allocates a percentage of its ERP deals, as well as a percentage of the maintenance revenue, to PLM licenses.

To bump up the PLM revenue numbers, some of the PLM vendors might be using the old trick of presenting mere CAD integration as PLM. Until recently, most PLM users were engineering change order (ECO) management users or just PDM users. In this scenario, a CAD system would dump flat files into a PDM system, and a workflow engine would then push the PDM data into an ERP system. ERP vendors have low-cost document-based integration to CAD, which may pull a large number of users, but this is not necessarily a real PLM implementation.

In spite of the potential benefits from PLM collaboration, switching from one PLM system to another (regardless of its CAD or ERP origin) in a rip-and-replace manner will not necessarily solve most of the aforementioned issues for the following reasons:

• Most companies don’t have mature intradepartmental PLM processes and/or the industry is forcing processes to continually change. This is why standalone PPM tools such as Sopheon, Oracle Primavera, or Microsoft Project are frequently used. One can easily change and upgrade them without impacting the rest of the group. Unfortunately, standalone solutions add time, costs, and risks. As cycle times are compressed, the chances of errors are increased.
• The cost to switch a broad PLM suite and retrain in another is high. As with ERP system, is there really a tangible return on investment (ROI) to switching? Someone once said that an ERP system replacement is like brain surgery – to be performed only if the patient will die otherwise. If you suffer from the aforementioned issue of PLM process immaturity, there is likely no ROI in switching systems.
• One overall PLM process offering from a single supplier with tight integration to all of the PLM functionalities and departmental applications is not a reality for most companies.
• Not unlike in the ERP realm, the material resource planning (MRP) concept was relatively straightforward (as is PDM within PLM). MRP II, ERP, extended-ERP, and whatever broader enterprise systems we have nowadays, bring in more departments and trading partners in the process. With additional each group, they want their data and their way with their  processes. They don’t always mesh with general ledger (G/L) or transactional regulatory restrictions. Likewise, in general, a CAD/formulation/PDM module works fairly well for engineers and maybe engineering support groups. They have well defined deliverables and, as a matter of fact, like the “limited formality” situation.

As in the case of rigid and monolithic old ERP replacements  (see Workday’s recent ongoing success), the fact is that some companies are switching PLM systems too when they have a failure condition. Not everyone will keep what they have forever no matter how bad it is – if that were the case, the technology industry would be void of innovation and customers would not be looking for new solutions.

The final part of this series will introduce the third group of PLM providers, a new crop of so-called organic PLM/PDM products, such as those by Arena Solutions, Aras Corp., Omnify Software, Tradestone Software, etc. The next challenge for all PLM providers is process simplification. By solving this problem, this new generation of PLM vendors strives to decrease the complexity and cost of PLM implementations.

In the meantime, your views, comments, opinions, etc. about the PLM, CAD, and ERP software are welcome as usual. We would also be interested in your experiences with these software categories if you are an existing user or with your current and possibly ineffective product development practices. What PLM solution have you selected and why?