02 December 2009

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]

1 comment:

The ERP Doctor said...

This is again an accurate description of what happens and again it is largely a waste of time

We are now ten to fifteen years past the point where there was a question as to whether any of the big brand ERP's could do the job

They can ALL do the job for just about any organization on the planet -- the question "which ERP is best suited" is the WRONG QUESTION so it universally produces the wrong answer

The REAL question should be "which implementer demonstrates the best insight into my business and the most relevant experience of other clients with similar strategic drivers in similar industries

Again, the question of industry is irrelevant before we know what the strategic driver is -- I know of three retailers one of which has a banking economic driver, one has an investment house economic driver and one has a true retail driver -- in terms of strategic economic driver -- they require completely different implementation approaches

Once you have found the implementer who can really evidence strategic fit with your organization AND is willing to contract the NAMED individuals that you have met to the project THEN find out what ERP they use and buy that

The issue is HOW YOU IMPLEMENT NOT what you buy

IF you want to get really radical, appoint a totally independent executive level advisor to help you define the requirement and facilitate you through the procurement process

Once you have made the buying decision then start with high level strategic analysis and progress to precision configuration

Process analysis comes later, MUCH later

Refer my LinkedIn profile for links to more informaiton http://za.linkedin.com/in/drjamesarobertsonerpdoctor