The New ERP – Part 24

It is all academic

We have covered several aspects in the matter of developing a "requirements list" so far. (See prior posts.) Of course, whether you are developing your requirements list in-house or your firm is retaining as traditional Everything Replacement Project consultant to do it for you, it is entirely academic and suffers from the same bad assumptions and lack of focus.

As I am writing this, I have before me a real-life "Request for Information" (RFI) stemming from a real-life traditional Everything Replacement Project. This particular document presents 286 "requirements." Sadly, it is quite likely that the folks behind this RFI – because they are employing traditional ERP concepts and methods – have absolutely no idea which of these "requirements" reflects the small handful of things that will actually permit their organization to improve by increasing Throughput (T), reducing demand for new Investment (I), or cutting or holding the line on Operating Expenses (OE) as their firm grows. In fact, they probably "hope" – but cannot state with any certainty – that any of these requirements will actually aid the firm in growing beyond its natural trajectory as of today.

The danger of lack of focus

It is precisely this lack of focus as reflected in a 286-item "Requirements List" that drives firms to undertake an Everything Replacement Project rather than identifying and changing that very small number of things that will actually deliver results by permitting the firm to elevate or even break a constraint and, thus, to increase Throughput – or to make significant improvements in I or OE, for that matter.

The firm that unwisely elects to spend half-a-million dollars on an Everything Replacement Project when a more focused investment of some (likely, significantly) smaller amount would deliver effective and valuable improvement has wasted capital that it will never be able to reclaim.

The Everything Replacement Project approach is supported by the false underlying assumption that, if we just throw enough money and technology at our organization, our organization will somehow improve. As evidence, I quote a gentleman who once said to me the following regarding a time-consuming and costly implementation of SAP that he had ongoing in his organization: "We've spent so much money already, it's got to work." (Emphasis is his.)

This unfortunate lack of focus in a traditional Everything Replacement Project, is to be contrasted with the New ERP – Extended Readiness for Profit approach that we are introducing here. The New ERP encourages you and your management team to focus on "what needs to change" (by looking at the roots of your Current Reality Tree [CRT]) – that relatively small handful of things that will actually lead to measurable improvement. Then, and only then, should you take your precious cash and other resources to apply them in a focused way, knowing in advance the measurable outcomes you expect from each critical investment.

What does all this have to do with "software selection"?

While traditional Everything Replacement Project methods will have you and your organization searching for software (and, potentially, other technologies) to replace – well – "everything" based on the all too traditional "Requirements List," the focusing steps of the Extended Readiness for Profit method will direct your team to consider only those particular technologies that will actually lead to real and rapid improvement (read: return on investment). Rather than a shotgun approach – throwing time, energy, money and technology – at everything – the New ERP gives your management team the option to become sharpshooters for improvement and new profits.

The New ERP approach will

• Conserve cash
  
• Provide more targeted uses for capital
  
• Avoid the waste of spending on IT projects that result in little or no real value-add to the "system" – the organization, as a whole
  

Going back to the example company (see early prior posts in this series), since the management team understands precisely "what needs to change" in order to improve the "system" – the organization – as a whole (namely, integrated bar code printing, integrated and automated ASN generation and transmission, and reducing or eliminating paper-based pick-pack-ship operations), they do not need to look at replacing everything. Rather, this wise team is prepared to turn to vendors and do "software selection" based on a very small domain of critical functions.

Rather than spending several hundreds of thousands of dollars on an Everything Replacement Project, our example team can set – as we previously described – a reasonable budget for the accomplishment of just the critical changes they have identified and for which they have already created measurable objectives.
[To be continued]

(c)2008, 2009 Richard D. Cushing

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]