The New ERP – Part 16

Requirements Gathering

Now, let us consider some of the other aspects of what the management team from another firm that is following the traditional ERP – Everything Replacement Project model. One of those, of course, would be the standard "requirements gathering" effort.

In the traditional ERP – Everything Replacement Project, most organizations go through some form of requirements gathering. The method may vary and, in fact, may happen multiple times over the life of a single project. Here are some typical ways in which requirements gathering may be carried out.

In-House Requirements Gathering

The leadership in an organization that is considering an Everything Replacement Project (traditional ERP) may decide to do their own requirements gathering. If they do, this typically entails senior management announcing to functional managers all across the organizational silos that the firm is thinking about replacing their ERP software. "Therefore," the executives opine, "management needs to have each silo create a list of all the features and functions that they believe will be 'required' (hence the term: 'requirements gathering') in the new software."

The silos may also be at liberty to add to the "requirements list" features or functions that are, in fact, not requirements at all. We know that they are not requirements because these features and functions are to be specifically designated with some useful term such as "Nice-to-haves" or "Wish list items."

Even the "requirements" (so-called) may not necessarily be actual requirements. (This gets confusing, does it not?) In some organizations, the silos may be permitted to "rank" requirements in a "1-2-3" fashion. By this the organization intends to suggest that everything on the "Requirements List" with a ranking of "1" is a real and actual "requirement." Items with rankings of "2" or "3" are sort of "requirements – if we can get them and they don't cost too much."

So, what is the problem with this approach?

Let us assume that your organization has ten departmental silos and each of these silos comes up with 30 "requirements." Forget about whether these are real requirements or just maybe requirements.

You and your management team now have a list of 10 times 30, or 300, "requirements." However, the list, by itself, assumes that each "requirement" bears an equal responsibility for aiding the organization in effectively reaching its goal of making more money tomorrow than it is making today. No manager or executive can look at the list and empirically assign priorities based on the dollar-benefits or ROI of having or not having each one of the 300 so-called "requirements."

To make matters worse, since ERP software today is more alike than it is different in most aspects of its functionality – that is to say, the genuine differences between ERP applications today are found around the edges and not at the core – a good many of the 300 "requirements" that have been diligently gathered by the organization will likely exist (in one form or another) in almost every competing product. That may mean that only ten percent (say, 30 of the 300) really have any significance in the search for a product in the traditional Everything Replacement Project.

Next, consider the fact that the very nature of the announcement from the executives that each silo was to submit a list of "requirements" suggests that the management team holds to the concept that improvement anywhere in the organization will somehow improve the "system" (i.e., the organization) as a whole. This is a false assumption. As we have previously stated: Only improvement in the weakest link will strengthen a chain – and your organization is "chain" of dependent functions.

Of course, the management team could be admitting something even worse. They could be admitting that they really don't intend to improve everything, because we really don't know what to change to bring effective improvement or how to reach more of their goal. So, instead, they are going to undertake an Everything Replacement Project – yanking everything out and replacing it with "new and improved" – in the hope that, in the end, they get better results. Such "hope" is not a strategy.

While it is true that some silo-based changes may contribute to some positive aspect changes within an organization, that is not what should be of concern to an executive management team. What executive management should be concerned with is this: What few things need to change in our organization in order to effectively increase Throughput (T), decrease Inventories or drive down or out demand for new Investment (I), and reduce or hold the line on Operating Expenses (OE) while the firm grows?

By now you may have recognized that by using the Current Reality Tree (CRT – see prior posts) from the Thinking Processes, the real and practical "requirements" that will have an immediate effect on T, I and OE are made plainly evident in the roots of the tree. That is a key and critical difference between the traditional ERP – Everything Replacement Project approach and the New ERP – Extended Readiness for Profit program.

[To be continued]