With the early generations of PDM/PLM systems aging, the need to replace a PDM/PLM system is rising. According to more than 400 PLM initiatives that Technology Evaluation Centers (TEC) surveyed over the past three years (over 100 per year), system replacement (either to replace a legacy system or to replace a current vendor) has become a more popular reason triggering the selection of a new PLM solution (Figure 1).
Figure 1. Percentages indicating two reasons why a PLM system is replaced
While more users are thinking of implementing their second, third, or even a greater ordinal number of PLM systems, migration is a prominent issue that has to be tackled during the implementation stage. Compared with first-time PLM implementation, replacements have more constraints in the users’ decision-making process—you can’t simply discard your existing PLM data, processes, and user habits that have been with you for years and start over from the scratch.
On the supply side, PLM vendors are investing noticeably in PLM migration from both technology and marketing perspectives in order to echo the increasing requirements of PLM replacements. Encouraging existing customers to migrate to a newer major version (rather than a minor update) and converting customers that are currently using systems from competitors are two growing marketing strategies I have seen in the PLM market. Without a doubt, PLM vendors and implementers are helpful in making a smooth transition when there is a need to migrate. However, I personally feel that before going deeper and evaluating vendors and addressing technical and organizational issues related to PLM migration, as a PLM adopter, it is important that you first refresh your understanding to the PLM methodology and the PLM market.
If you have implemented PDM/PLM systems years ago and haven’t paid much attention to the PLM market after the implementation, you may need to refresh some of your PLM thoughts:
1. PLM is for the product design and development department.
It is true that product design is where today’s PLM originated. The product design and development department has been and will remain the major user of PLM systems. However, it is also true that today’s product development is an organization-wide (and very often cross-organization) endeavor, and that one critical capability of PLM is to streamline internal and external collaborations. With product design and digital manufacturing tools (e.g., computer-aided design [CAD], computer-aided engineering [CAE], and computer-aided manufacturing [CAM]) and basic data and process management systems becoming commodities for today’s manufacturers, the competition for product excellence is moving to the orchestration of activities along with the entire product life cycle.
Manufacturers should be aware that siloed product development processes often seen in old PDM/PLM systems have become an obstacle when trying to obtain product excellence. If you happen to be in the “considering a PLM migration” stage, try to think of these two questions:
1) Who will benefit from the rich content generated on the product design stage?
2) Who will provide valuable inputs to the design and development department?
I’m sure that after answering these questions you will be convinced that you have to plan your PLM system in the setting of an extended enterprise environment.
2. PLM manages product only.
As explicitly implied by the term itself, PLM manages the product’s life cycle. During the early days of PDM/PLM systems, “product” mainly referred to products with a complicated structure such as automobiles, aircrafts, and industrial equipment. More recently, with more manufacturers from the sectors producing products with much simpler structures (such as consumer packaged goods and fashion products) adopting the PLM methodology, the connotation of “product” has been enlarged. Although different types of products may require different interpretations and functionality, when it comes to a PLM system, there is one thing in common—the life cycle perspective is applied to the objects being managed. Following this thought, it is not difficult to imagine what else can be managed using the life cycle management principle:
Manufacturing facilities: Not only do your products have life cycles, your facilities that produce all these products also have life cycles—from the planning of the acquisition to the retirement and disposal.
Aftermarket services: For certain types of manufacturers (e.g., engineering-to-order [ETO]), aftermarket services have become an important revenue source. Be aware that aftermarket services are an inseparable part of the entire life cycle of your products.
Other intangible entities: Besides the services (i.e., intangible products) that you provide, you may have other intangible entities (e.g., marketing collateral and training content) that may be worth considering a life cycle approach in management.
You may not need to (and probably not be able to at the moment) manage the life cycle of the above mentioned items as granularly as you can do to your products, and you may have some other systems for managing these items, but the life cycle approach should be rewarding if applied properly. Since you are considering a new PLM implementation, it is the time for you to think of tying different types of life cycles together.
3. PLM is a data source for other systems period.
TEC is currently conducting interviews with PLM users regarding their current PLM systems. Although the data collection and analysis are still in progress, by looking into currently available information, I have the impression that many PLM users are aware of the PLM to enterprise resource planning (ERP) integration but not the other way around. Today’s PLM systems often play an important role in providing product definition information to other systems. However, it was not equally considered that data from other enterprise systems can be valuable inputs for generating product definition information.
As mentioned earlier, today’s product development is a wide range collaboration that involves almost every department within an organization in order to assure a manufacturable, marketable, serviceable, sustainable, and, of course, profitable product before hitting the actual production. In this manner, during the design phase, product designers and engineers need convenient and constant access to information stored in other systems (such as sourcing information and knowledge) at their own will. Shopping around for ideas and inputs for product development through e-mails, phone calls, and meetings is still an important approach for collaboration, however, letting other systems provide relevant information directly to the PLM system, the one that designers are the most familiar with, paves a broader way of information gathering and knowledge sharing.
4. Buying software is the only way to have a PLM system.
For many years, buying software licenses was the only way to acquire a PLM system. More recently, leasing and hosting were added to offer some financial and operational convenience to the adopting organizations, but these two alternatives have never become strong in the PLM market. Free and open source software (FOSS) and software as a service (SaaS) have changed some business software areas (for example, FOSS in enterprise content management [ECM] and SaaS in customer relationship management [CRM]) quite noticeably, and now they are seen in the PLM market, not quite significantly but representing a trend nonetheless.
FOSS PLM: Aras Innovator, the only enterprise open source PLM solution, has been offered for over three years without asking for license fees. The partner and user communities of Aras Innovator have been growing very fast since the company changed the licensing model on January 15, 2007. For more information, please read this product note on Aras Innovator.
SaaS PLM: Although it is not a prominent phenomenon in the PLM market, recently SaaS PLM is getting more attention from both the vendor and the user. Certainly, there are issues (check out a few concerns related to SaaS PLM in this blog post) to be addressed in order to increase the acceptance of the SaaS model in the PLM market. Nevertheless, its pace seems unstoppable.
5. A new PLM system will solve all the problems.
First of all, solving existing problems is not the only reason why you should migrate to a new PLM system even though problems are often the trigger of the migration. Another important reason is to seize the opportunity to achieve benefits that won’t be feasible in your current system. I recommend combining the reactive approach (problem solving) and proactive approach (intentionally looking for better) together.
Secondly, addressing all the problems in one PLM implementation sounds too luxurious. Even it is possible for you to do so, you will find that new issues emerge shortly after the implementation. A better approach is to prioritize your requirements and start from the low-hanging fruit. I heard from different PLM users that their organizations have benefited more from PLM as the methodology rather than from PLM as the system. For your on-going PLM journey, being a perfectionist in the lifecycle approach with reasonable tolerance to your PLM system is the way to get far.
Here’s an interesting analogy about PLM solutions: A PLM solution is like an unsharpened kitchen knife. It can be described as a paring knife (for a light-weight PLM product for small organizations) or a cleaver (for a sophisticated PLM suite for large enterprises). No matter what size and purpose the knife is created for, it can’t perform a satisfactory job unless the edge is sharp enough. Your insights of how to use the PLM approach and technology is the whetstone that makes your knife work well. Before switching to another PLM system, think about the scope of the implementation, how it can best collaborate with other systems, which acquisition options you may have, and lead your PLM initiative by a holistic blueprint with a phased approach. The time spent on sharpening your knife will be well compensated when you start cutting.