Executive Summary
Past experience shows us that the vast majority of enterprise technology evaluations run over time and budget, and once selected, the majority of the implementations fail to meet functional, return on investment (ROI) and total cost of ownership (TCO) expectations. Many companies have consequently been stuck with under-performing software products and dejected users, and are still unable to gauge their system to determine how far they are from the ideal solution for their business requirements
Enterprise technology selections for ERP, CRM, SCM, and other enterprise applications provide valuable lessons that can be applied to selecting PLM (Product Lifecycle Management) software, but there are some key differences that need to be recognized. In PLM, there is no single vendor that can meet all of the requirements, and the market is still immature, so almost every product can be the right solution provided a certain set of requirements. The Catch 22 for both buyers and vendors is to pinpoint the right opportunity in this ongoing "dating game".
Selecting a piece of enterprise application software has never been an exact science. Vendors' hype, consultants' potential conflict of interest and consequent bias, users' doubts, tediously long selection processes, and unclear decisions rationale are some of the unfortunate watchwords for the selection practice so far.
It
is daunting for corporate IT buyers to discern the true capabilities, strengths
and weaknesses of a given enterprise application suite, given the propaganda
that pervades vendors' endeavors to differentiate themselves (see Beware
of Vendors Bearing Solutions). When making strategic IT acquisitions, buyer's
project teams, inundated with an abundance of available products and technologies,
have a difficult time translating the content of glitzy marketing slides and
grandstanding presentations into the deliverable products. Given the relative
immaturity of the PLM movement, this problem can be compounded by user's lack
of understanding of their business needs and documentation of the associated
software requirements.
This
is Part One of a five-part tutorial, which addresses this situation from the
viewpoint of the Buyers and Vendors.
Part
One Lessons Learned from Previous Enterprise Software Selections
Part
Two Overview of the Problems in Selecting PLM Software
Part
Three Presents a Solution
Part
Four Presents examples of applying the Solution
Part
Five Makes User Recommendations
Lessons Learned
Many companies have been through the software selection process before, whether it was for ERP, SCM, CRM, or other enterprise application suites. Many of the lessons learned from these selections still apply because PLM expands traditional engineering applications with business processes that stretch further into the enterprise and even further into the value chain. The multi-departmental, multi-company nature of PLM is changing the way that engineering-related systems are bought and sold, and has caught the attention of the CIO and Corporate IT who apply enterprise application evaluation criteria and processes to PLM selections.
Key Lessons That Apply To PLM
Of the key lessons learned from past enterprise software selections, there are several that deserve specific mention.
-
The first is that that successful selections focus on defining business requirements
in advance. Business requirements that are defined in advance and then broken
down into the associated software requirements help to focus the selection
process on the appropriate strategic needs of the business.
- The second
lesson learned is that industry specific requirements should be included in
the evaluation process. Most PLM vendors focus on specific vertical industries,
and their solutions have been developed to solve the specific needs of those
industries. For more information on industry specific requirements, see "PLM
Is An Industry Affair Or Is It?"
and "Find
The Software's Fatal Flaws To Avoid Failure".
- The third lesson
learned from past experience is that enterprise solutions should not be selected
in a vacuum. The needs and requirements of multiple departments and even business
partners must be represented in the documented requirements and also on the
selection team.
New Lessons
PLM selections have differences from other enterprise software selections as well. The relative immaturity of most company's PLM initiatives and the PLM software market provide some unique challenges. ERP solutions, for the most part, cover the same basic functionality "footprint". Some have gone so far as to call ERP software a commodity, although that ignores the fact that there are still key differences between many solutions.
The
PLM market, on the other hand, covers a wide range of previously unrelated software
applications and the suites offered from different vendors can vary dramatically.
Applications include Product Portfolio Management, Project Management, and others
in addition to traditional engineering applications like PDM and CAD. No vendor
provides all of the required solutions for a full PLM initiative, so almost
all solutions will involve best of breed components. See "The
PLM Program, An Incremental Approach To The Strategic Value Of PLM", "
for more information on the components of a complete PLM solution. ERP selections
are typically run as a one-time selection process to find an integrated solution.
In contrast, the PLM Program for any one company may include multiple selection
projects. Each selection project might be targeted to find the tools that are
right for any particular solution area or phase of the PLM Program. For example,
separate selection processes may be needed to find best of breed solutions for
PDM, Portfolio Management and Requirements Management until a single vendor
emerges that meets the needs for all.
The PLM market is still expanding despite some recent consolidation in the market. Because PLM is a relatively new market, there are still many small, innovative vendors that should be considered depending on the required functionality. Finding and evaluating these small, specialty vendors can be a challenge but can provide big returns in terms of increased product functionality.
Finally, PLM solutions are oriented around product innovation processes as opposed to transactions. This difference means that requirements can not be as easily defined objectively, and more objective opinions from experienced users is likely to be required, particularly in the areas of design tools.
There
are still more lessons, undoubtedly, to be learned about selecting PLM applications.
We look forward to the comments and feedback on the experience our readers have
on selecting and implementing PLM applications. While we are learning the new
lessons and how they apply to PLM we should also be careful to use the best
practices learned from our previous, collective experience in selecting enterprise
software.
This
concludes Part One of a five-part tutorial.
Part
Two will discuss typical problems found in enterprise application selections
such as PLM.
About the Authors
Jim
Brown has over 15 years of experience in management consulting and
application software focused on the manufacturing industries. Jim
is a recognized expert in software solutions for manufacturing and has broad
knowledge of applying Product Lifecycle Management, Supply Chain Planning, ERP,
Supply Chain Execution, and e-business applications to improve business performance.
Jim served as an executive for software companies specializing
in manufacturing solutions before starting his consulting firm, Tech-Clarity
Associates. He holds a bachelor's degree in mechanical engineering from the
University of Maryland, College Park.
Jim
can be reached at jim.brown@tech-clarity.com
Predrag
Jakovljevic is a research director with TechnologyEvaluation.com
(TEC), with a focus on the enterprise applications market. He has over 15 years
of manufacturing industry experience, including several years as a power user
of IT/ERP, as well as being a consultant/implementer and market analyst. He
holds a bachelor's degree in mechanical engineering from the University of Belgrade,
Yugoslavia, and he has also been certified in production and inventory management
(CPIM) and in integrated resources management (CIRM) by APICS.