The New ERP – Part 23

The software selection process

Actually, in this section, we will discuss the selection of any technology that your management team intends to deploy as part of your ongoing improvement process. Of course, that may include hardware, software, services and other infrastructure components. However, in order to keep the language simple – and because "software" is typically the focus of most technology acquisitions – we are going to use the term "software selection" to cover the entire gamut. We also engage the "software selection" to cover everything typically included in a traditional ERP – Everything Replacement Project effort because this is the term most often applied to the product selection phase.

Of course, in the traditional Everything Replacement Project approach, the "software selection" stage generally follows the "requirements gathering" work. However, since the traditional ERP approach to requirements gathering has so great a lack of focus on what will really help the organization (the "system") become more effective at increasing Throughput (T) and profit, employing the freshly generated "Requirements List" as a tool provides little in the way of value in the "software selection" process.

The consultant-assisted software selection

One of the possibilities that we did not mention earlier (see prior posts) when discussing the traditional Everything Replacement Project approach to requirements gathering is that the firm undertaking the traditional ERP may elect to hire a consultant to assist them. One of the big things that changes when a consultant schooled in traditional ERP comes to the helm is how thing happen.

You may recall that we sad when commencing an internal requirements gathering effort, the CEO or some other executive of the firm would announce to all that the firm is considering replacing its present accounting or ERP software and that, therefore, he wants each departmental silo to create a list of "requirements" for their particular functions. This process may be radically altered by the arrival of a traditional ERP consultant on the scene.

With a traditional ERP consultant ensconced in the organization, typically one of two paths will be followed:

Option 1

Of course, this dramatic departure from the simpler in-house approach we described earlier does one very important thing – it adds cost to the project while delivering (in most cases) little or no additional benefit to the organization. There are, however, two potentially redeeming reasons for involving the traditional ERP consultant:

1. Doing so may free up time that could be used by executives and managers to deliver real benefit to the organization through increased Throughput or over value metric.
   
   
2. The consultant, if she has been through this process before, may be able to shorten the "requirements gathering" process because, if you compare typical "requirements lists" across multiple and diverse organizations, at their core, these documents have more in common than they have diversity.
   

Option 2

The outstanding advantage of this approach is clear: You have no rank amateurs involved in creating your "requirements list." Instead, you have a professional "requirements list" developer hard at work and on your side. Permit me to give you some real life examples to show you just how much this might benefit your organization.

Requirement No. 1 as prepared by mere amateurs
"We need to be able to import and export data from the new software"

Requirement No. 1 as prepared by a real professional consultant
"Need ability to import and export data in a meaningful way…. Ability to export meaningful data to the reporting database"



Requirement No. 2 as prepared by mere amateurs
"We need a flexible chart of accounts"

Requirement No. 2 as prepared by a real professional consultant
"Flexible chart of accounts, such as multiple levels of accounts"



Requirement No. 3 as prepared by mere amateurs
"We need to be able to print production reports"

Requirement No. 3 as prepared by a real professional consultant
"Production reporting capabilities do exist"



From these few real life examples, I am certain that it is now abundantly clear to you how important it may be to the success of your firm that you not let amateurs entangle themselves in the complex task of "preparing requirements" – as the real pro's prefer to call it (as opposed to "requirements gathering"). After all, who wants to buy software that allows you to import or export "meaningless data" or to import or export "in a meaningless way"? Moreover, I am certain that every accountant knows the significance of the term "multiple levels of accounts" versus the crude description of simply needing "a flexible chart of accounts."

Nevertheless, like a late-night TV advertisement – Wait! There's more!

Without the advice of a real professional in traditional ERP, those responding during the traditional ERP "software selection" cycle might not have the opportunity to scale their responses. The following is an excerpt from a real life "Requirements Document":

Application Requirements
In each of the categories [in the Requirements List], please rate your software's capability to meet the requirement on a scale of 1-5:

• 5 = the requirement is fully met in the base package
  
• 4 = the requirement is 80% covered in the base package
  
• 3 = the requirement is partially met or may require additional expense to purchase
  
• 2 = the requirement can be met with light modification
  
• 1 = the requirement is not met or would take significant (> 24 hours) effort to modify
  

There are several problems with this approach. The most glaring, of course, is that by reading a one or two sentence description of a "requirement," it is impossible to know what the requirement-writer envisions as to the precise form or function in question. Therefore, how is it possible to say at the requirement is "fully met" or the other scale metrics? And what, on earth, does it mean to meet a requirement "partially" or "80%"?

All too many times, a respondent to a "Requirements List" may say, "Yes"; but when it comes down to matching the software to the end-users expectations, there remains a great chasm yet to be bridged. For example, a vendor or reseller responding to "Requirements List" may answer with an honest "Yes," to a requirement that "a cash receipt from a customer may be applied to multiple customer invoices and memos." No deception is intended. However, the prospective end-user functions in a business where they must apply customer payments to accounts that may have several thousand open invoices at any one time. The end-user, in such a case, has one concept of how this function should work and it is likely that that vision does not align with the reality to be found in the software being offered by the vendor or reseller.

[To be continued]