An Overview of Product Lifecycle Management Implementation Challenges

Introduction

According to CIMdata (http://www.cimdata.com/PLM/plm.html), product lifecycle management (PLM) can be defined as "a strategic business approach that applies a consistent set of business solutions in support of the collaborative creation, management, dissemination, and use of product definition information across the extended enterprise from concept to end of life—integrating people, processes, business systems, and information."

Part One of the series An Overview of Product Lifecycle Management Implementation Challenges.

Wikipedia defines PLM as follows:
"Product Lifecycle Management describes the process of managing the entire lifecycle of a product from the concept and design phase, product analysis (finite element analysis) through production planning, visualization and marketing to the end of life of a product." (http://www.en.wikipedia.org/wiki/Product_Lifecycle_Management[accessed March 2006])

Thus, we conclude that PLM systems support the management of a portfolio of products, processes, and services, from initial concept, through design, launch, production, and use, to final disposal.

The Need for PLM

As CIMdata's president Ed Miller correctly emphasizes, "PLM supports innovation-oriented initiatives such as integrated product development, design collaboration, intellectual supply chain management, and global resource utilization." PLM applications hold the promise of seamlessly flowing all of the information produced throughout all phases of a product's life cycle to everyone in an organization, along with key suppliers and customers.

For example, an automotive company can reduce the time it takes to introduce new models in a number of ways. Product engineers can dramatically shorten the cycle of implementing and approving engineering changes across an extended and globally dispersed design chain (covering suppliers, customers, and senior manufacturing and senior design engineers) which can access all data through a web-based PLM system. Procurement divisions can work more effectively with suppliers to reuse parts. Thus, the product can be manufactured faster, paving the way for capturing the market earlier than the competition.

Implementation Challenges

When we move from one system to another system, it is to improve the process, and save money and time. However, it is imperative that we overcome certain challenges whenever we do this. We can broadly categorize the PLM implementation challenges as follows:

1. Preparation of the vision document
2. Gathering employee support for change
3. Software evaluation and selection
4. Implementation management
5. Mapping of current process to the features of the selected software system
6. Identifying customizations and prioritization
7. Legacy data loading into the newly built PLM system
8. Technical training on PLM software for maintenance
9. Hands-on user training on usage of new system.
10. Kickoff of new PLM system

Preparation of the Vision Document

Any major change in the way an organization work needs to be guided with a vision. The chief information officers (CIOs) who drive the implementation of systems such as PLM should have a clear vision and roadmap of what is to be done, and what they want to achieve with it.

The CIO's initial role with PLM is that of change agent, through working with engineering to sell the business case to senior management. From there, they need to oversee a cross-functional PLM project team charged with mapping and defining common business processes. With the engineering and operations groups as co-sponsors, they need to launch a campaign to sell the benefits of PLM to the company's different constituencies. Once an agreement is reached, this needs to be documented, and it will drive the entire implementation.

Thus, the output at this stage is a PLM implementation vision document clearly describing the key milestones, implementation methodology, various phases, and checkpoints. Finally, it explains the benefits that are expected in the short and the long run. Apart from this, it should indicate when to expect return on investment (ROI).

Gathering Employee Support for Change

Once a vision document is made, it is clear that it has won over the senior management. But the success of any implementation lies completely with the people who actually use the system.

i) Psychological aversion
to change Any change in the existing system provokes a psychological reaction in the mind of many people: the system they have is good, so why change it? They scream, saying that they have been working with it since so many years; why do they need to change and learn something new? This resistance to change is unavoidable. But as technology grows, it is vital to change current processes, machines, and software to save time and money.

The human tendency by and large is to oppose change. This because of the fears and concerns of people regarding the new system's potential usefulness and impact on their day-to-day life.

ii) Overcoming aversion—managing people It is crucial to sell the change, otherwise employee morale will be affected. The following ideas point to a few things that can be done to achieve this. The best way to do this is to organize team meetings on the need for change, and ask the employees to come up with solutions. This might involve organizing brainstorming sessions and discussions to explore the possibility of achieving benefits without investing in change. If it is not possible, employees themselves may feel the need for a new system. Any solution that evolves will surely benefit the organization. Then they will cooperate in evaluating current and new systems: they will be ready to change, and will be enthusiastic to learn how to improve their way of doing things.

Those who do have previous expertise in implementation of PLM systems can conduct sessions on how their daily routine work can be done efficiently, and can discuss how it can help them personally (as well as the whole organization). It should be clarified that there will not be any threat to job security; rather, improved performance of systems will provide a boost to management to introduce new products—and thus finally raise employment levels by streamlining current processes.

Software Evaluation and Selection

This is a competitive world, and there are hundreds of PLM software vendors. One needs to evaluate them in order to choose the right one for the organization. We took part in PLM implementations in the automotive, hi-tech, and food industries. We have gathered the inputs of these experiences, and upon studying the various means of software selection pertaining to PLM, we summarize the following process for vendor selection.

i) PLM system document preparation
An enterprise has to prepare a document on how they envision their PLM system: this is their company's "PLM system document."

First of all, let all the stakeholders of the proposed PLM system imagine (with the ideas that evolved in change management sessions, as described above) how they envision a system that would help them work efficiently. All inputs gathered here need to be documented.

Let us give a couple of examples. Some engineers might come up with the idea of accessing designs from home, an internet caf, or even for that matter from another country. From this concept, we might get the idea of a PLM system being web-based. Some people might come up with the idea that PLM systems should provide an option to see what will be the cost if new components are added by removing old components, and vice versa. What this means is that the PLM system may need to provide a "what-if" kind of cost analysis. Thus, upon brainstorming, the most important features (agreed by majority) need to be gathered, and documented in the name of the PLM system document. This completes the document, and is an expert committee's baseline for evaluating various software vendors.

ii) Software evaluation
The software product evaluation methods suggested by Ireland's Centre for Software Engineering (http://www.cse.dcu.ie) can be efficiently used. They are based on international standards such as ISO/IEC 9126 and the proposed ISO/IEC 14598 (see http://www.cse.dcu.ie/essiscope/sm4/14598-5.html) for evaluating a software system. Our evaluation approach is based on this baseline, and is discussed below.

The industry practice is to form a committee or group of people who have good experience on using PLM software, functional experts in the area of implementation, technical experts, and experts from the respective design, manufacturing, production, and procurement departments.

Once a committee is formed, it needs to contact software vendors by all available means, such as inviting tenders, contacting vendors' marketing departments, and so on. This will ensure the attention of various vendors. Once this committee starts receiving responses, then it should share its vision and PLM system document with those vendors, and specify budgetary limits. This reduces much of the pain in trying to make a short list among the many vendors who do not have what an enterprise is looking for: only those vendors with offerings matching the expectations (at least nearly) will approach. Finally, there will be limited set of vendors which can offer a solution as per needs.

Once there is a list of short-listed vendors, meetings with the vendor marketing departments should take place. However, an organization should not satisfied with the typical demos. Instead, they need to insist on being shown the features in practical contexts, with at least small quantities of legacy data. At this stage, information regarding the integrations that vendor software supports needs to be obtained. This is to ensure that systems currently in use (like enterprise resource planning [ERP] or computer-assisted design [CAD] systems) can be integrated with the new PLM System

At the point where an enterprise has completed the list of PLM features it's looking for (in the form of a PLM system document), a scorecard can be prepared for prospective vendors. This can be managed by defining a weight for each of the features. Based on this (and the features supported by each vendor software), generate a scorecard. This will give a score-based view of each vendor's capability. This data can then be analyzed using bar graphs, pie charts, 2-D graphs, and so forth. Even a simple comparison of total scores in the form a scorecard table will also help to decide who is better. Table 1 shows a typical scorecard.

Table 1

Before making a decision on buying software, a clear understanding is needed of the kind of infrastructure required to implement the PLM software. For example, how many server machines will be required? How many client machines? What should the local area network (LAN) speed be? Is there any need to buy third-party software? All these issues have to be considered, and the budget estimate should include this infrastructure cost as well. Now, a final decision should be taken, keeping budget in mind.

The scorecard shows eight features an organization is looking for, and the scores of various vendors with respect to a predefined weight. Vendor 3 may be a better choice on the face of it. But on careful observation, we see that Vendor 4 provides consistent medium or less customization (or out-of-the-box) solution, whereas Vendor 3—even though it scored high—cannot satisfy feature 2. Additionally, some features needs heavy to medium customization. Thus, we come to the conclusion that Vendor 4 is a better option.

However if cost comes into the picture, further refinements in the decision may be possible. As per this scorecard, Vendor 1 also offers a decent solution. Suppose that Vendor 4 offers the software at a cost of $100,000 (USD), while Vendor 1 offers the software for $60,000 (USD). The choice is fairly evident, even though Vendor 4 may offer a better product. Also, there is need to look at post-implementation and post-buy support, as some vendors show interest only until their solution is bought. To avoid this, do a reference check of the vendor's previous clients about their experience with this vendor's software.

Thus, by taking into consideration all the propositions above, it becomes easier to select a suitable vendor.

In Part Two of this series, we explore the implementation process itself.