The New ERP – Part 17

Requirements gathering as part of the sales process

We are continuing our review of methods and processes applied in the traditional ERP – Everything Replacement Project approach, comparing and contrasting those with what we have seen (in prior posts) about decision-making under the New ERP – Extended Readiness for Profit program. In this portion, we are going to look at the "requirements gathering" that is frequently a part of the sales process used by technology vendors or resellers.

Even if the subject organization has already undertaken its own requirements gathering (as we discussed in Part 16 of this series), another requirements gathering is likely to occur when the salespeople from the vendors or VARs (value-added resellers) get involved with the firm. Frequently, this is even a separate appointment for the sales team. In some cases, the sales team from the vendor may require several days to "gather requirements." This process is usually introduced by the salesperson in charge of the account saying something along the lines of, "Before we can do a 'demo' – or give you 'price', or whatever – we need to come out to do some 'requirements gathering' to make sure you're a good fit."

Now, this is not all bad. When a vendor or reseller gets involved in a technology sales transaction, you certainly want someone from their organization to stand up earlier, rather than later, to tell you if the technology they offer is definitely not a good fit for your intended application. However, think about it! As a manager or executive, do you really want the vendor's salespeople to be the final arbiter of your company's "requirements"? Of all people, they have the greatest incentive to sell you something and they have the least knowledge of those few things that actually need to change in order to effectively help your organization achieve more of the goal of making more money tomorrow and in the future.

In our earlier discussion regarding "internal requirements gathering" (see Part 16), we already indentified the weakness of the typical "requirements gathering" scenario as being the fact that the process itself holds no concept or concern with the "system" as a whole. The process assumes that improvement anywhere in the system will lead to improvement in the performance of the system as a whole. This is entirely false reasoning. This new presales team from the vendor that is now running about visiting silo after silo likely has not the faintest idea about what must change in your organization in order to increase Throughput (T), reduce Inventories or the demand for new investment (I), or how to contain Operating Expenses (OE) while increasing revenues and Throughput. (Although, I will grant you that they may know more about the least important factor – Operating Expenses – than the other two.) Certainly, however, these presales folks from the vendor's team will not be more qualified than is your own management team to identify your system's "bottleneck," or to isolate those few critical "roots" that encompass "what needs to change" in your organization.

Redefining "Requirements"

If we redefine "requirements" to mean "those few critical things that will help my organization – viewed as "system," a whole – become more effective at increasing T, reducing I, and holding the line on or slashing OE while supporting growth in revenues," then "requirements gathering" is best performed using the Current Reality Tree (CRT) as the framework by which to interpret what you already know about what is working and not working across the departmental silos.

Let us simply agree upon one simple matter: the technology vendor's or reseller's salespeople are not typically among those best qualified to determine your organization's "requirements" as we have defined them. We will speak more of this matter in later posts, as well.

[To be continued]