Professional Documents
Culture Documents
Finding and selecting the product lifecycle management (PLM) solution that can best meet your organizations immediate and longterm needs is a complex and demanding task. If you select the right software and implementation partner, your organization will have short time-to-value as well as all the benefits PLM can provide for many years to come. But making the wrong selection often results in budget overruns, implementation delays, user dissatisfaction and rejection, and maybe even the need to go through a similar evaluation process again after only a few years to add missing functionality or replace the entire system. So, what can you do to ensure your organization finds and selects the right system among the dozens of systems available today? Since making a wrong decision can be costly and have a long lasting negative effect on your company, it is worthwhile to take a methodical approach and use proven practices that have worked for other companies and have reliably led to the selection of the right PLM solution. To identify what works and what doesnt, we talked with various organizations that have evaluated and implemented PLM. We analyzed over a dozen companies in the automotive supplier, aerospace and defense, consumer goods, life science, machinery equipment and high-tech and electronics industries to find out what made their PLM evaluation projects successful, why they had difficulties, or why they failed. Based on these companies and our own experience, we identified 10 best practices for evaluating PLM that will help you in the selection of the best PLM solution for your organization and lay the groundwork for a successful subsequent implementation.
-1-
For most companies PLM is not a core competency and, consequently, they often do not possess the necessary knowledge, information, and experience to ensure a proper evaluation and selection of the right technology and implementation partner. Yet many companies rely only on their own staff to find the appropriate system, quite often with a futile outcome. The most common factor among companies that successfully selected and implemented PLM is that they all involved an experienced partner or consultant with extensive PLM knowledge and integration expertise very early in the evaluation process. Such a partner has done it many times before and will therefore save you time and money, help to avoid common pitfalls, knows to ask the right questions, and provide guidance throughout the entire selection process. An additional benefit is when the same partner is not only able to help during the evaluation, but can later also assist in the implementation and operation of the system. Another very important factor is to seek a partner or system integrator who is vendor and technology independent and to not rely too much on software vendors for help. The latter often try to influence or change the requirements so that their product best meets the criteria, a problem one company representative described as follows: Relying on a software vendor to help with the evaluation is like trusting a fox to guard the henhouse. A neutral partner will ensure that your PLM solution is selected based on your companys business needs and not based on the possibly limited functionality of a particular system.
Early in the evaluation process it is imperative to learn as much as possible about PLM by reading related literature, attending PLM seminars, talking with consultants, and visiting companies that have gone through a selection process. This will enable you to assess the information given by outside sources and to make good decisions throughout the selection process. Appendix 1 contains recommended articles and literature on the topic of PLM.
-2-
Important in this early phase is to acquire knowledge as much as possible from neutral sources, such as industry analysts, consultants, and other companies already using PLM, but resist the temptation to contact system vendors. Although the latter is a convenient source of an abundance of free information, the knowledge you build is biased and can early on lead you in the wrong direction. One of the best ways to learn about PLM is to talk to companies using it, and one of the best ways to find such companies is to ask your PLM partner or consultant. They will be able to introduce you to companies that can share their experiences and lessons learned both good and bad which is precisely what you need to make good decisions, reduce the risk, and avoid making mistakes along the way.
PLM can affect almost every part of an organization. As a result, investments in software and services as well as internal efforts to evaluate, implement, deploy, and maintain such solutions are usually significant. To ensure that the necessary resources are available throughout the project it is critically important to secure the support and sponsorship of executive management before starting. Just having the support is not enough though. It is as important for management to openly express their backing and to let the entire organization know that this project is critical and requires the attention and support of all employees, whether directly involved or not. The importance of this point cannot be stressed enough. As indicated above, PLM projects are usually resource intensive, and only management can make sure that the project receives the attention and priority it needs to be successful. Not having strong management support and not explicitly informing the organization about managements view of the importance of the project are, in our experience, among the most important reasons why PLM projects fail.
Ciscos CIO said about his companys approach to evaluating and implementing an important business system: Our orientation in pulling people out of their jobs [to work on this project] was that if it was easy we
-3-
were pulling the wrong people. We pulled people out that the business absolutely did not want to give up. The same approach should be taken when evaluating and implementing PLM. Organizations commonly use a PLM system much longer than it takes to evaluate and implement it. Any upfront investments, be it for external expertise or internal resources, are usually recovered within only a short period of time if the upfront work is done proficiently by people who really understand the business and PLM. Involving only the best people from all affected areas of the organization in the PLM project team is a good assurance for success. Mistakes, oversights, and omissions on the other hand whether committed knowingly or not often result in very costly consequences and corrective actions at some point in the future.
Evaluating and implementing a PLM system without simultaneously optimizing related practices and processes is like buying a Ferrari to drive it on gravel roads. In both cases the technology cannot be utilized to its fullest potential. One of the most beneficial aspects of PLM is its ability to integrate data and processes, as illustrated in figure 1.
-4-
Traditionally, companies have divided their operations in various subprocesses or activities that are each carried out independently by separate departments. Each sub-process is preceded by a lead-in period, in which task owners prepare the required activity and gather necessary data and information for its execution. Between sub-processes data often has to be transferred from one database and format to another because departments store their data in separate databases and distinct formats. Studies have shown that lead-in periods and data transfer activities can cause up to 70% of the entire work effort. Although a PLM system cannot entirely eliminate these non-value added lead-in and data transfer activities, reductions of as much as 90% and resulting overall process efficiency improvements of over 60% have been achieved through enterprise-wide data and process integration. The first step in exploiting the full potential and achieving all the benefits of PLM is to conduct a detailed process and technology analysis with the objective of identifying existing process discontinuities, redundancies, non-value added activities, and isolated data repositories. The next step is to develop a PLM integration concept that includes the design and definition of optimized and integrated processes, taking into consideration and fully utilizing the capabilities of available PLM technologies. The latter aspect is an important reason why the process reengineering activities and the evaluation of a PLM system should be done in a coordinated effort and with participation of experts who have a deep understanding of both process improvements and integration as well as existing PLM technologies.
People and organizations dont plan to fail, but they fail to plan. The objective of developing a PLM strategy is to provide a decision framework for the long-term implementation, deployment, and use of PLM within the extended enterprise. The strategy should address which parts of the organization will be using PLM, what needs it ought to address initially and in the long-term, and how the system will fit into the organizations application framework, i.e. what will be done in PLM versus other applications, which existing systems PLM will replace, which it will complement, and whether
-5-
integrations to other systems, such as ERP or CRM, are desired or required. Developing a long-term PLM strategy for the entire organization is an important prerequisite for defining appropriate application requirements and selecting the right system. A too-narrow focus on only a few functional areas and short-term needs can result in the selection of a system that may do one thing well but does not provide a solution for another in industry terms often referred to as a point solution. Choosing such a point solution can be beneficial if it is done intentionally, but unfortunate if done by mistake. The latter usually means that the company has to find and implement one or more additional systems that address the needs not covered by the first one and, in addition, often develop costly integrations between the different systems. A PLM strategy also allows a company to prioritize the implementation of different functionalities and to determine the areas of the organization in which to deploy first. But most importantly, it helps to avoid the creation of an application patchwork with point solutions over time and, instead, ensures that a comprehensive and integrated solution is selected that will meet the long-term needs of the organization, even though various elements of the selected system are implemented and deployed gradually.
When evaluating PLM systems, many companies start gathering information by reading product brochures, studying vendors websites, attending trade shows, and inviting system vendors for initial sales meetings or even product demonstrations. These activities are often done without having established a clear understanding of the needs of the entire organization and the ensuing company-specific requirements for PLM. In this situation, software vendors often offer their help by suggesting certain functionalities a PLM system should provide. This, unfortunately, serves almost exclusively the vendors interests. The reason is that software vendors have one major objective: To sell their software. To do this, vendors often try to influence the requirements in favor of their application a common tactic in the sales process. Vendors attempt to do this either by providing a list of requirements that are tailored to their
-6-
system or by demonstrating the strengths of their system early in the process. If a vendor can introduce functional requirements that only his product can meet, his chances of selling his software increase dramatically. Another possibility for defining requirements for your future PLM system is to use so-called RFP templates, which can be bought on the Internet. They usually promise to save months of work and help to avoid costly mistakes by employing an industry standard approach in defining application requirements. And this is exactly the problem in most cases: They provide a list of standard requirements that are supposed to be applicable for any company in a specific industry. This implies that your needs are not different than those of your competitors, and this can hardly be the case if you want to create a competitive advantage through the use of PLM. The best approach is to define a list of detailed application requirements that take into consideration your organizations specific situation and needs. Input for your requirements should come from the process and technology analysis, the integration concept, your PLM strategy, and from product-independent or neutral PLM experts that have no bias towards a specific solution.
In a recent survey conducted by a PLM industry analyst 68% of respondents indicated that their investment in PLM either did not produce the expected return on investment or ROI (30%), they werent sure whether they achieved the expected ROI (22%), or they did not have metrics, i.e. were not able to calculate or did not know the ROI (16%). The conclusion of this survey result is that apparently more than two thirds of the companies that have made investments in PLM have done so either by using wrong assumptions or without determining its real value prior to making a purchase. How can this happen? Many companies attempt to rationalize an investment in PLM often only after a project budget is established, and frequently they turn to software vendors for help with the justification. This approach is problematic insofar as vendors have an inherent interest in a positive result, for any negative outcome will preclude them from selling their software. This often
-7-
encourages parties involved in the justification to modify assumptions in order to inflate the value of the desired improvements or potential savings and thereby artificially increase the projected return of investment. Organizations should first determine the value of the improvements that can be achieved with PLM, independent of any vendor or system. This information can then be used to set the budget for the solution, under consideration of a desired or required return on investment or net present value (NPV) of the improvement. If the cost of the proposed PLM solution is within the budget, i.e. less than the value of the improvement, the organization will achieve the desired ROI or NPV and an investment will make sense. If the cost exceeds the budget or does not provide a sufficient ROI or NPV, either the scope has to be changed or the project abandoned. This budget or cost limit can also become an openly stated requirement that potential vendors will have to meet in order to be further considered. Using proper assumptions and a systematic, proven method to determine the ROI of an investment in PLM ensures that you will not spend too much money on something you do not really need and that you are among the 32% of companies that achieve the expected results from their investments in PLM.
Investments and expenditures in PLM can quickly exceed $100,000 or more for all necessary software, maintenance, implementation and support services, training, and hardware, even for smaller deployments. A major part of this is software and first year maintenance, which usually represent between 40% - 50% of the overall costs. Considering this, it makes sense to buy the software only when you know that it can do what you need and what the vendor promises. The best way to verify this is by conducting a test or pilot project with the selected PLM system. Generally this is a project of about three to four months duration in which the preferred PLM system is tested against two or three for your company critical use cases or scenarios. Depending on the situation this can be done either with test data in a non-productive environment often also called conference room pilot or with a limited set of data in a production pilot for a real, but non-critical project.
-8-
Software vendors are generally willing to provide the necessary software licenses for the duration of the pilot on a trial basis for free. It is common and fair though to pay the implementation partner for the services that are necessary to install and configure the pilot, for the training of the pilot users, and for the required hardware. If done correctly there is not much extra cost for such a pilot as virtually all the work performed and hardware purchased can later be leveraged or used for the production environment. The potential downside of a pilot is the additional three or four months it takes to conduct it properly. The upside on the other hand can be significant: Having the confirmation that the software can really meet your companys requirements and knowing how the implementation partner performs before large amounts of money are committed to either part.
One reason why PLM projects fail is user dissatisfaction or even rejection. To avoid this, it is important to inform everyone early and regularly. Evaluating PLM is not only about selecting new technology, it also means preparing the organization and the employees for change. And change is best managed by involving people as much as possible in the process and by providing honest information about the predicted benefits, effects, and consequences. Of course it may not be possible to involve the entire organization in the system evaluation. However, it can be very beneficial to ask all affected employees what they expect of the new system, to consider their input as much as possible, and to continually inform them about the project status and the reasons why management and the selection team are making certain decisions. It will help to increase the acceptance and maybe even generate a certain anticipation of the new PLM system, and as a result, contribute to a successful outcome of the project.
-9-
About Metafore
Metafore helps organizations to drive innovation, accelerate revenues, increase productivity, reduce costs, improve quality, ensure compliance, and shorten time-to-market through the integration and resourceful utilization of product lifecycle management. We make PLM easy and affordable by assisting companies in the evaluation, implementation, and operation of the most appropriate PLM processes, practices, and technologies. For more information call us at 949-705-6452, send an e-mail to info@meta-fore.com, or go to our website at www.meta-fore.com. Copyright 2006 Metafore, LLC. All rights reserved. This positioning paper may be copied and distributed in its entirety at no charge.
- 10 -
Notice: The reports and literature marked with an asterisk (*) are available only for a fee or to members and subscribers of the publishers services. Product Lifecycle Management - Definition; Wikipedia (http://en.wikipedia.org/wiki/Product_Lifecycle_Management) What factors should be considered in developing a sensible business justification (ROI) for PLM?; CIMdata; December 2005 (http://www.innovateforum.com/innovate/article/articleDetail.jsp?id=262771) Making a Pitch for PLM; IndustryWeek; August 2004 (http://www.industryweek.com/ReadArticle.aspx?ArticleID=1490) PDM to PLM: Evolving to the Future; CIMdata; February 2004 (http://www.coe.org/newsnet/feb04/industry.cfm) The PLM Revolution; IndustryWeek; February 2004 (http://www.industryweek.com/ReadArticle.aspx?ArticleID=1386) Theres a New App in Town; CIO Magazine; May 2003 (http://www.cio.com/archive/051503/app.html) PLM Aids Product Makers, Buyers; eWeek; February 2003 (http://www.eweek.com/article2/0,1759,895601,00.asp) *PLM Market Analysis Report for 2004, Module I and II; CIMdata; July 2005 (http://www.cimdata.com/publications/reports.html) *The Value of PLM and How to Get It; AMR Research; April 2003 (http://www.amrresearch.com/Content/View.asp?pmillid=15973) *Building the Case for PLM; AMR Research; March 2003 (http://www.amrresearch.com/Content/View.asp?pmillid=15907)
For more white papers, literature, reports, and articles about PLM call us at 949-705-6452 or send an e-mail to info@meta-fore.com indicating the topics you are interested in.
- 11 -