Companies undertaking a new ERP vendor selection often begin the effort by using a standard template of ERP system requirements. Though requirements checklists may appear to be a time-saving way to get to a requirements specification, this approach can actually make the project longer and cost more than it should. Moreover, the use of requirements templates can actually lead to the wrong ERP system being selected.

In this post, we identify the problems with the use of ERP requirements templates and outline a better way for specifying requirements for new ERP systems.

So Many Templates to Choose From

The first ERP requirements templates were developed by the large consulting and accounting firms, for use by their consultants in ERP selection projects. The benefits were obvious: first, save a tremendous amount of time by not having to develop ERP requirements from scratch. Second, be able to leverage junior consultants who don’t have very deep knowledge of ERP systems.

Over time, a number of “template providers” (for lack of a better term) rose up to turn ERP requirements checklists into a little cottage industry, not just for ERP but also for CRM, HCM, supply chain management (SCM), and a whole host of enterprise systems. The template providers could then make money in three primary ways:

1. Selling templates to ERP buyers. This would be the low-cost option. For just a few hundred dollars you can buy an ERP requirements template, with thousands of pre-written requirements. Some template providers even offer short templates for free (in exchange for your contact information, more on that later).
2. Selling vendor short lists to buyers. The template providers then solicit vendors for their standard responses to the requirements and build a database of vendor capabilities. This allows the template providers to sell a vendor matching service to ERP buyers. They allow the buyer to pick and choose requirements, auto-match them to the capabilities database, and sell the buyer a short list of vendors that appear to be the best fit.
3. Selling buyer contact information to vendors. The template provider now has your contact information, either because you used their matching service, or because you registered for “free research.” This allows the template provider to sell you as a sales lead to the ERP vendors. For some of the template providers, this is their primary way of making money.

Today, there are a significant number of template providers offering various types of low-cost or free services, showing that the business model has some viability.

ERP Requirements Templates Pose Problems for Buyers

Although buyers may not appreciate having their contact information sold to vendors, there are bigger problems with requirements templates. In over 25 years of ERP selection consulting, we have attempted to use many of these requirements templates and found a number of issues.

1. Lack of context. Template providers often develop their requirements based on specific selection projects. This can lead to requirements that are difficult to understand outside of the context of that original buyer. Here is an example: “Does the system support a variety of order policies, including but not limited to least unit cost, economic order quantity, fixed order quantity, part period balancing, and fixed day of week?” This may have made sense to the original buyer, but others may be hard pressed to understand what it means.
   Furthermore, it is a multi-part question. Does the buyer need all five order policies, or only some of them? If the vendor provides four of the order policies but not the fifth, how should the vendor answer?
2. Over-specification. When the template has several thousand requirements, buyers tend to over-specify what they need. The problem is confounded when many of the requirements are confusingly worded (see #1). This is either because buyers do not want to admit they do not understand, or because they think it is safer to say “yes” to something they don’t really need than it is to say “no” and find out later that they need it.
3. Template RFI, template response. When vendors repeatedly receive requests for information (RFIs) with over one thousand requirements, they tend to build internal systems to automate their responses. After all, if buyers are using requirements templates, vendors can hardly be blamed for using their own templates for their responses. As noted earlier, some template providers sell the ability to respond electronically to buyers using their templates. In other words, the buyer is mechanically developing the RFI, and the vendor is mechanically answering it. It is not a meaningful exercise for either the buyer or seller.
4. Vendor exaggeration. The purpose of an RFI is usually to gather information on a long list of potential vendors in order to decide on the top two or three to take into the demonstration phase. Vendors quickly learn that buyers generally pick those with the greatest percentage of “yes” answers. Therefore, vendors are tempted to exaggerate their capabilities, especially when they know buyers tend to overstate their real requirements (see #2). Some of the matching services seek to solve this problem by verifying vendor responses (they actually charge the vendors to become “certified”—another way to make money), but this can only catch the most flagrant exaggerations. When the vendor is paying to be certified, the template provider has an incentive not to push back too hard.
5. More work for everyone. No buyer enjoys having to read through, select, and prioritize thousands of requirements. No vendor likes to respond to such an RFI. And no buyer likes to review responses from vendors created through such a process. Perhaps the effort would be worth it if led efficiently to a decision on which two or three vendors to demo. But too often, it doesn’t. Buyers don’t understand key differences between vendors, and vendors do not get insight into the real needs of buyers (see #2). This is evident in software demonstrations where neither the buyer nor the vendor refer back to the RFI.

The most serious problem, however, is that the process can lead to the wrong vendor winning the deal. When a company over-specifies its requirements (problem #2), some vendors may be eliminated even though they could satisfy that company’s most important needs. Or, a vendor that exaggerates its capabilities (problem #4) may get through software demonstration without the buyer catching the exaggeration. Ultimately, the cost may be a failed ERP implementation.

A Better Way

After many years of experience, we have found a better way to develop client requirements for ERP, CRM, HCM, SCM, and other enterprise system selections. These principles include use of requirements templates, but only in a limited way.

Our typical RFI has between 50 and 200 requirements. We limit these to what we call differentiators: things that make your company different from others, and things that make ERP systems different from one another. For example, an engineer-to-order manufacturer has some needs that are unique and not shared by make-to-stock or even many make-to-order manufacturers. Moreover, many ERP systems do not support engineer-to-order requirements. An example would be the ability for a customer to place a sales order for a product that does not yet have an item number.

We then write every RFI as an original work product, with each requirement having its source in client interviews and our knowledge of industry best practices. Although we may use requirements from past projects as a reference source, we do not recycle RFIs from one client to another.

The approach using custom-written, key requirements produces an RFI that is meaningful to the client and informative to the vendor. Vendors who cannot meet key requirements, therefore, are more likely to take themselves out of the deal before investing too much presales time and expense, and clients are more likely to end up with a short list of vendors that can meet their key needs.