Home
 > Research and Reports > TEC Blog > The Subjective Criteria of ERP Selection

The Subjective Criteria of ERP Selection

Written By: Aleksey Osintsev
Published On: September 25 2009

I hope our readers, to greater or lesser degrees, are familiar with our business software selection methodology—as we have been writing a lot on this matter. But the lion’s share of these publications often refer to either the functional or technical sides of the selection process, or what type of business processes a future system can support and how can be achieved. Here, I would like to bring your attention to another aspect of business software selection that is also quite important and in some instances outweighs the other considerations—and can (sometimes surprisingly) tip the scales in favor of another software solution. I am talking about the subjective criteria involved in selecting a software product and vendor that are strong enough to have a substantial effect on the entire result of the process—and that could turn your decision around at the last minute.

In terms of software evaluation, the major difference between subjective (or qualitative) criteria and those that are judgmental (or objective) is that it is much more difficult to measure the latter when building any type of rating method to compare solutions. Very often, these criteria fall into the category “I like it” or “I don’t like it” or depend on the user’s previous positive or negative experience. Trying to systematize these “hard-to-compare” factors, TEC came up with the following classification, which you can see running any Evaluation Center project on our Web site (http://www.technologyevaluation.com/products/evaluation-centers/). These factors are usually considered after the detailed comparison of the software functionality of the short-listed vendors is done.

Market data. There are a few criteria in this category; some of this market data comprises the vendor’s corporate and financial profile. Market data as a criterion looks quite simple and does not invite any questions at first glance; however, it is not that obvious. For example, the commonly used approach, where the larger the vendor, the better it is perceived as being for the customer, is not applicable in many situations. Local companies with smaller numbers on the balance sheet but with a better understanding of the local specifics and business practices might be preferable. And even the comparison of financial numbers might not be so helpful in making a decision, as you might discover that there is no direct relationship between the vendor’s size and the quality of its services.

Another subgroup here is a comparison of a vendor based on implementation, consulting, training, and support services. Most vendors provide the whole spectrum of services for their clients—but again, this doesn’t mean that a vendor is less competent if it does not provide, say, business management consulting-type services. It is very possible that the vendor doesn’t want to scatter its resources and needs to concentrate on the activities related directly to its area of expertise.

It might seem strange, but pricing is also one of the “hard-to-compare” factors. The cheapest solution is not always the best choice, nor is the most expensive solution. Making the best choice depends on additional information and, of course, on an analysis of the ratio of available and required functionality per system total cost. Also the methods of pricing and payment should be considered from a long-term perspective, if possible.

It can also be beneficial to take a closer look at how the vendor deals with its customers after the implementation is done. Good advice here is to see if there are user groups available to communicate with (on-line or in person), and if a vendor organizes annual user meetings or provides documentation to its prospects. Another sign of a potentially good vendor could be that the vendor is open to public discussions and criticism, and maintains user communities where existing customers can meet each other and discuss their problems and achievements. Potential customers might find it very useful to participate in annual user conferences—or at least be made aware of them.

Ease of use. This set of criteria is purely subjective and depends on the judges’ conception and interpretation of what is good or not good for the company and its users. A software system’s graphical capabilities, interface intuitiveness, colors and shapes, multiscreen mode, navigation limitations, and interface modification capabilities are all examples of “ease-of-use” characteristics that are, actually, the face of the program and the only perspective from which most users see the actual software. The entire project’s success or failure may depend on these criteria and definitely cannot be excluded from the consideration.

There have been plenty of battles about what the best choice for users is, which interface logic is easier to perceive, what screen color is the most comfortable for long-term use, how menus and numerous functionality options should be organized, and how simple their modifications could be. These and many others types of questions should be asked and answered during the selection process. Software can be rich in functionality and full of technical features and the newest technologies, but at the same time, be very painful to implement because it was written by programmers who presume users have a similar level of expertise (which is not realistic). As a result, the client’s personnel don’t express a necessary level for support of the new project.

References. Another important set of questions is related to existing clients’ appraisal of the software vendor’s performance and how well the vendor delivered on promises made. Specifically, it’s nice to obtain references on the company’s general performance and the adequacy of the implemented package(s); the promised and actual service and support levels; the vendor’s employees’ attitude before, during, and after the implementation; as well as software maintenance capabilities.

These subjective criteria can be applied to any business software selection project, but they are especially important for all types and sizes of enterprise resource planning systems (ERP) selection, such as discrete manufacturing, or process manufacturing, or a combination of both of them (mixed-mode ERP). These three groups—market data, ease of use, and references—are extremely important and have a great impact on the final decision.
 
comments powered by Disqus

Recent Searches
Others A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

©2014 Technology Evaluation Centers Inc. All rights reserved.