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.
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
Part One of this article, we discussed
the lessons learned from previous enterprise software selections and how they
apply to PLM.
is Part Two of a five-part tutorial, which addresses this situation from the
viewpoint of the Buyers and Vendors.
One Lessons Learned from Previous Enterprise Software Selections
Two Overview of the Problems in Selecting PLM Software
Three Presents a Solution
Four Presents Examples of Applying the Solution
Five Makes User Recommendations
Prospective customers typically struggle with the following issues when selecting enterprise technologies:
Their selection project teams have no effective way to define their business
requirements and thereby identify the critical vendor and product questions
(criteria) necessary to successfully initiate the evaluation process. This
time consuming problem rears its ugly head at a very early stage of the project,
resulting in a rapid loss of the initial staff's enthusiasm to implement new
technologies. One possible option is to hire an outside consultant that will
lead you through a number of interviews, meetings, workshops, etc. to determine
your requirements. When you count the number of man-hours your team had to
forsake to do this plus a hefty invoice for consultants' valuable hours, you
may want an alternate approach. In a somewhat better case scenario, you might
be paying a less exorbitant amount of money for a slightly tweaked request
for information/proposal (RFI/RFP) document that has already been used many
times before for different companies.
When these criteria have eventually been pinpointed and submitted to (hopefully)
the most appropriate vendors, project teams often have no ability to effectively
prioritize the different criteria relative to one another. As a result, final
priorities are often more the result of internal political agendas than true
needs and requirements. Without having a valid statistical tool to keep these
priorities in check and to conduct simulations of results after changing priorities,
it is likely that some department's needs (e.g., engineering) have, at the
end of the day, been the unreasonably high contributor (e.g., well over 50%)
of the total decision.
Also, project teams have no ability to obtain objective, validated, updated
data on the available vendor alternatives. Unfortunately, most project teams
have no true ability to separate fact from hype, especially because its strategic
technology selections are often either the first of its kind or the first
in an extended period within a specific organization.
As a result, the vast majority of enterprise technology evaluations run over time and budget, and once selected, majority of the implementations fail to meet functional, return on investment (ROI) and total cost of ownership (TCO) expectations. At the same time, the number of companies, which are able to substantiate (quantify) the rationale of the decisions to go with some product in the past, is sadly negligible. A much higher number of decision makers rely solely on frivolous justifications like their gut-feel, executive mandate, or tiresome spreadsheet compilations without ability to discern the best solution (other than to arithmetically count the number of pluses and minuses, without taking into considerations their true importance).
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. In other words, even after all the pain, many are unable to benchmark whether to maintain the status quo or try their luck in selecting the right product this time. The enterprise applications users' predicament has been duly covered at the TEC web site in the past, and many companies are repeating the same mistakes when selecting a PLM solution.
Vendors, their value added resellers (VARs) and system integrators (SIs) are not in an easier situation either, despite their tendency to often oversell their products. On the vendor side, the challenge of educating the potential client of their offerings results in painfully long and costly sales cycles, painstaking and numerous RFI responses time and again, and the potential for pursuing a mismatch opportunity, resulting in projects that can go terribly awry. These failed projects do not bode well for the vendor, since the sales cycle costs can only rise even more, and their reputation can suffer. The consequences can be much more severe for the client where it can, in extreme cases, lead to business failure.
For implementers, the issue is similar: having inadequate fit-gap information for the implementation phase means an inability to properly plan and execute the implementation, or for a consultant to assist the end client in making proper technology decisions. Implementers (which can be internal IT departments as well as outside consultants) can also find that decision-maker indecision leads to lengthened sales cycles, missed opportunities, and risk of competitive intrusion.
Often the users don't know why a particular product was selected in the first place, and the vendors and VARs are not sure why they have won/lost some opportunities. Even winning serendipitously is not good, as it does not grant recurrence. Did we win because we had the best product, because we demonstrated it best, or maybe because Vendor X and Vendor Y were not invited to bid?
Many vendors turn to industry analysts and IT research firms to provide them with a view of the future and/or to assist them in their product marketing strategy. The firms can often provide very valuable visionary and strategic level research to vendors to help them determine their future direction (e.g., buying market forecasts, whether to embrace Web Services, etc.). While this insight can help vendors decide on high-level strategy, this by no means answers all the questions vendors often need to answer. For example:
What and how many product functional and/or technological features do we have
to achieve to be the absolute frontrunner in the market segment or to beat
the Vendor X in a particular face off? Does the newly released module or the
latest product upgrade make us significantly more eligible to compete in the
Why are we one of the leaders in a certain industry, for merely a number of
installations? How many of these have come from, e.g., our collaboration or
technology solution only as opposed to from our sharp industry solution per
se? Were we perhaps the first one to tackle the market segment; if so, is
our solution still stronger than a newcomer's one, with fewer customers but
with a formidable offering we don't know much about yet?
Should we compete (and commit to the non-refundable hefty expenses and resources
involved) in a selection against a large vendor that certainly has more functionality,
but is less flexible than we are? What other tradeoffs should we present to
the customer knowing our strengths/weaknesses, and will it fly? Do we have
any more concrete documentation to back up our claims other than an Analyst
A's fluffy report that arbitrarily praises our product (the opponent will
likely have a similar report from Analyst B)? What about competing against
a dark horse vendor we've never seen before, but the market seems to be raving
about its product?
The actionable, quantifiably substantiated, and in no uncertain terms answers to the above questions, while arguably obtainable from traditional analyst houses, would likely be exorbitantly expensive, given the annual subscription fees for much less granular information and service these firms traditionally charge.
Therefore, despite apparent adversarial relationships, all parties have meanwhile realized the need for thought and research to build data and process information in a meaningful context, which takes time and costs money for all parties going through the selection process. But without spending time, thought, research, and money there is increased business risk to all, unless there is an existing inexpensive solution to provide a structured, repeatable process for evaluating technology solutions and the vendors that provide them.
Most business managers, whether within vendors, prospective clients or implementers/resellers, have long yearned for an enabling system to minimize project risk for all sides of technology utilization. For instance, by narrowing products down to a shortlist based on functional and technical features, vendors/VARs benefit from not pursuing unfruitful clients, and clients benefit because the short list is usually reduced to a manageable size, while everybody benefits because this tedious phase that can be streamlined.
There is certainly room to ask the fundamental question of whether the traditional practice of RFI/RFP processes has been adequate to the task of selecting complex systems. The record indicates there is much room for improvement. In essence, for complex selections like the case of PLM software, the human-machine combination has to work together to drive the solution. Both sides have to be understood and complement each other in the process. It is easy for the human to be overwhelmed, or simply run out of time, and the machine interface and engine to be inadequate to the task. However, the results must benefit the process if human and machine can function effectively together to process information and avoid the pitfalls of past selection processes.
concludes Part Two of a five-part tutorial. Part Three will discuss an RFI/RFP
process that can effectively address the problem.
About the Authors
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.
can be reached at firstname.lastname@example.org.
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.