The New ERP – Part 22

What else might change the value proposition of a technology initiative?

We have already pointed out the foibles of the traditional "aim-and-shoot" approach to IT initiatives and their proclivity toward considering every matter in terms of "cost," rather than "value." (See prior post in this series.) We even pointed out some of the factors that may change the value proposition for an IT initiative well after the project launch. But, what else might have an effect on the value proposition of an IT project aimed at "improving" a company like yours?

Earlier we mentioned things like the introduction of new products, changes in the economy, or even public policy changes that might change the value proposition for a technology deployment. Now, however, we need to turn our eye to technology-specific elements that might also affect the value proposition of a project already underway.

I am not sure why, but my more than 25 years in dealing with business technologies has clearly proven to me that firms reaching out to make technology purchases assume (far too frequently) some measure of clairvoyance on the part of their technology vendors. It is clear, and the purchasing companies' management teams seem to recognize, that they cannot know everything there is to know about the technology they are buying. However, that same management team will somehow come to the tacit conclusion that the technology vendor must know and understand all there is to know about the company that wishes to buy and deploy their technology.

Okay! Maybe I'm exaggerating; but just a tiny bit.

The managers on the buying side may not actually assume that the vendor's team understands or knows everything about the buying company's firm and operations, but they generally do assume that the vendor's team knows and understands enough about the prospective purchaser's company and operations to ask every possible question in order to assure that every facet of the product or services provided will fit precisely the customer's expectations. Never mind that "expectations" are never plainly visible to either party in the transaction. Expectations far transcend anything placed in any agreement or "requirements" document. Expectations may be reduced to the number of mouse-clicks it takes to navigate a certain transaction, or the "look-and-feel" of screens, or where data is placed in the user interface. The list of expectations is, literally, without end. In fact, the purchasers themselves may not know or be able to articulate their expectations. They only know when their expectations have not been met.

The point is this: As a buyer, you and your management team need to recognize that, when first engaging a technology vendor, the vendor knows proportionately as little about every facet and detail of your enterprise as you know about every facet and detail of their technology and services. In essence, you have witnessed "a demo" of their technology and they have experienced "a demo" of what your company is like. Therefore, it is incumbent upon you, as the buyer, to beware – caveat emptor. You and your team must thoroughly and precisely know what you want and need the technology vendor to do in order to effect the change you have in mind – the change derived from your Current Reality Tree that will help your company reach more of its goal of making more money.

At this point, an "on the other hand" would be nice to hear. Am I right?

On the other hand, there actually is an upside to this mutual blindness between technology seller and technology buyer. Frequently I have experienced situations where, as the vendor and the buyer learned more about each other's technologies (on the one side) and operational requirements (on the other), fresh new insights emerged about how the buying firm could leverage to great advantage previously undisclosed features or functions in the technology. A management team employing the value-based New ERP approach can readily see that the presence of some unanticipated feature, function or capability might radically increase the value proposition to the organization. Unfortunately, this kind of value serendipity is sometimes missed entirely by tradition-bound managers and vendors totally enmeshed in "meeting documented requirements," deadlines and budgets.

[To be continued]

©2008, 2009 Richard D. Cushing

The New ERP – Part 21

Getting to the "system" view of technology deployment projects (continued)

Sometimes there is an even a selfish motive lurking beneath the surface of one applying the traditional approach to IT deployment projects. If the organization – whether it be your own organization, or the vendor's or reseller's – rewards those responsible for IT implementations based on their projects being on-time or on-budget rather than basing rewards on the value returned to the target organization as measured in terms of beneficial changes in Throughput (T), Investment (I) or Operating Expenses (OE), then it is not only possible, it is highly likely that there is a personal and selfish motive to how these managers plan and implement.

Now, I am by no means suggesting that managers of IT deployment should be frivolous in the treatment of available time or funds for project completion. Far from it, for from a "system" improvement point of view, delays mean reduced Throughput and additional money carelessly spent on an IT project drives Investment higher. Both of these are absolutely negative in my view.

However, what I am saying is, executives and managers holding only a cost-world view of the IT deployments will likely miss opportunities to produce even better results (in terms of T, I and OE) if they hold to the traditional aim-and-shoot approach.

The holistic value-view of technology projects

A management team with a holistic value-view of any change involving technologies should hold a much different view of the one we have described (in Part 20 and above) as the traditional IT project view. If your managers, vendors or resellers want to participate as an active partner with you in an Extended Readiness for Profit – the New ERP program, they need to have a clear understanding of all of the tools that have brought you and your team up to this point. They need a clear framework through which to view and understand what is happening across all of the departmental silos in your organization. In short, they need to understand have a "system" view, not a departmental or functional view. Working through your Current Reality Tree (CRT) with these stakeholders in your project's success should help them gain this essential footing and view.

Next, since (hopefully) no one on the project team is relying upon a set of nearly meaningless "requirements" prepared either by internal silos or external consultants, each of the team leaders should have a clear set of measurable objectives with regard to any initiative being undertaken. (A clear and measurable objective might be: "To increase the number of shipments able to be picked, packed and shipped from the current 20 per hour to a minimum of 40 per hour at current staffing levels.") These participants will know precisely how much a specific IT initiative is to deliver in terms of increased T or reduced OE. There is no guesswork about value creation under the New ERP – Extended Readiness for Profit approach.

Armed with a clear, controlling framework and measurable objectives for the IT initiative at hand, such managers are armed and able to make effective value-based judgments throughout the entire duration of the project. The reasons this is necessary are several:

• "Today" – whatever day that is in the project – the managers have learned something they did not know "yesterday" that will affect delivered value
  
  
• "Today" – whatever day that is in the project lifecycle – the managers do not know some things that they will learn "tomorrow," and these unknowns may also affect the value proposition of the project
  
  
• Making changes in the immediate future (say, within a week, or a month, depending on the project) to the technology is very likely more difficult and more costly that making the same changes at some later date (the increased costs and difficulty being caused by factors such as lack of time for planning, current workloads, potential overtime pay requirements)
  
  
• Having the liberty to make changes incrementally into the future, as the value proposition changes and unfolds, allows the managers to guide the overall IT project to the highest value optimized against the lowest total cost of ownership (TCO)
  

This is really where the traditional approach falls down so dramatically. If the IT initiative under consideration is going to last more than 30 or 45 days, it is almost a certainty that something will change – or something not changed, but only lately coming to light for consideration – that will affect the value proposition of the proposed deployment. New products are introduced – if not by your company, then by your competitors or your suppliers. Changes in the economy or public policy may affect the way or with whom you can or must do business. These and likely some 10,000 other factors could change the value proposition of the IT project that is underway.

This means that the "target" that you and your team were originally aiming for on Day One of the project may not be the target you really want to hit on your scheduled completion date. The value-based manager is prepared to take those revelations in stride and to make effective adjustments as soon as new estimates of T, I and OE can be made. (And, if you recall from our earlier posts, estimates of T, I and OE can be done pretty rapidly meaning no paralysis by analysis for the team.) Then, the team will apply the simple formulas we have previous supplied using the new estimates:

Benefit ($) = delta-T – delta-OE

Or

ROI = (delta-T – delta-OE)/delta-I

The value-based manager should always understand that the value he beholds today in any given improvement initiative (technology-based or not) may not be the value of the same initiative tomorrow. The further into the future the manager tries to see, the less certainty there is that today's value proposition will still hold true.

[To be continued]

The New ERP – Part 20

Getting to the "system" view of the organization

We will talk more about this when we get to the matter of customizations and modifications; however, if the organization is brought together to see that what is needed is an improvement in the effectiveness of the whole organization – i.e., the "system" – in order to achieve more of the goal of making more money, then many of the petty so-called "requirements" may quite naturally fall away.

When I am applying the New ERP – Extended Readiness for Profit with my clients, I frequently have a very frank discussion with the management team about our holist (or "system") view of the organization. In the course of these discussions, I try to point out that, in general, the goal of any improvement is to achieve at least one of the following three things for the whole system:

1. Increase Throughput (T)
   
2. Reduce Inventories or demands for new Investment (I)
   
3. Cut or hold the line on Operating Expenses (OE) while sustaining substantial growth
   

The caveat to that statement is that achieving that end as the result of any given change in the system (i.e., the organization) will not necessarily mean that the level of effort in every functional area will be decreased. In fact, although it is rare, it is possible that a change may lead to some increase in level of effort in a department or departments that already have excess capacity.

I find that, if the executive management team has created and has a full understanding of the impact of their own Current Reality Tree (CRT) – and maybe a Transition Tree (TrT) – the executives' use of the CRT (and TrT) in explaining what needs to change and why to the whole organization usually results in excellent buy-in on the matter of any workload redistribution that may result.

Getting to the "system" view of technology deployment projects

While we are on the subject of seeing your organization as a "system" – that is, from a holist point of view – we want to compare another important difference between the traditional – Everything Replacement Project approach to technology deployments with the approach we take with the New ERP – Extended Readiness for Profit.

The traditional method applied in most IT deployments under management internally or by vendors or resellers is what we call the aim-and-shoot approach. In a (usually vain) effort to minimize risk, the general concept is to get all the details "nailed down" before management turns vendors and resources loose on the work. Executives and managers who hold to this approach sincerely believe that they are acting in the best interests of their firm. Managers from vendors and resellers also generally hold with all sincerity that this approach is the "safest," if nothing else. But let us take a look at just what risk it is that this approach seeks to minimize.

As we said, the way the traditional approach is formulated, the project leadership attempts to "nail down" or "cast in concrete" all the pertinent details as early in the project as possible. Frequently, executives and managers on both sides try to get every detail settled before the final agreement is signed for services. From that point, their thinking is, all they have to do is follow what has been defined to the letter and they will hit their "target" of success at the end of the project.

It is possible that taking this approach minimizes the risk of cost-overruns. (Although, there is a virtual plethora of data available from the experience of thousands of companies over the last 25 years that militates strongly against this concept that this approach actually does reduce the frequency or size of cost-overruns.) More importantly, however, is the very fact that applying the term "cost-overrun" strongly suggests that the project is being measured solely by "cost" and not by "value delivered." Rather than thinking about the value created through increasing T, or reducing I or OE (if you don't know what T, I and OE mean, yet, then go back and read some earlier posts in this series), such managers and executives can conceive of no concept greater than "cost" by which to set goals and measure "success."

Let me assert right now: Any project that is ON-TIME, ON-BUDGET, and of HIGH QUALITY is still a failure – not a "success" – if it fails to increase the system's production of T, or fails to reduce the system's values of I or OE while sustaining significant growth.

[To be continued]

The New ERP – Part 19

Another reason traditional "requirements gathering" approaches may be unnecessary

As we have already discussed (see prior posts in this series), some of the reasons that traditional ERP – Everything Replacement Project approaches to "requirements gathering" – whether internal or as performed by a vendor or VAR (value-added reseller) – fail to deliver real value or results for the organization purchasing new technologies. Now we want to turn our attention to one other matter that we believe will help you see why traditional approaches to "requirements gathering" may be a huge waste of time, energy and (in some cases) money.

Think back to the scenario we described (in a prior post) where some executive makes the announcement regarding his firm's intent to replace their existing ERP software, sending off silo leaders to develop a list of "requirements." Two or three weeks later the firm has assembled a list of 300 or so "requirements."

Unless the organization is very unusual, the truth is that more than 80 percent of the typical "requirements list" contents will be found in some form or other in almost all of the contending software packages to be considered. In the middle market – software designed for small- to mid-sized businesses – there are far more similarities in features and functions across the different packages than there are differences. Furthermore, most of the distinctions (i.e., differences) between the most common competitors in mid-market ERP are to be found around the edges of the application software, not in its core functions. For this reason, it is quite likely that about 80% of the "requirements" collected will be present and therefore little value was added to the process by collecting and documenting such "requirements."

Next, it is worth noting that many of the so-called "requirements" listed by staff from the various organizational silos will not be genuine "requirements" at all. Many so-called "requirements" will be nothing more than what the silo staff is used to in their existing software application. Stating these as "requirements" merely fixes in the mind of staffers from the various functional silos that they can and will all get a relatively precise duplication of existing functions plus added features in their functional domains. This sets many wrong expectations and may lead to demands for modifications and customizations where, in a more open-minded environment, adaptation to new methods or processes would have been perfectly acceptable or even an improvement in itself. Never mind whether any of these now cast-in-concrete "requirements" will actually have any effect on increasing Throughput (T), reducing Inventories or demand for new Investment (I), or cut or hold the line on Operating Expenses (OE) while allowing the firm to sustain significant growth.

[To be continued]

The New ERP – Part 18

Post-sales requirements gathering

As we continue our review of traditional ERP – Everything Replacement Project methods and processes, while comparing them to the New ERP – Extended Readiness for Profit, we have been discussing the various aspects of "requirements gathering." So far we have covered both in-house and pre-sales requirements gathering. However, even if one or, indeed, both of the preceding forms of "requirements gathering" have been performed, it is not at all unusual for yet another aspect of "requirements gathering" to be done following the close of the software sale. We refer to this, naturally, as post-sales requirements gathering.

Many technology vendors and value-added resellers (VARs) maintain a process that looks something like this:

What's wrong with this picture?

The problem is that, most likely, it was the salespeople that did the pre-sales high-level requirements gathering. Then, they sold your company the technology!

Now, after you and your organization have already made what is probably a non-refundable purchase commitment of their technology, the vendor is sending in the people that really know whether the technology is "a good fit" for your specific organization and its application of it. Only now are they discovering your real and practical requirements.

Of course, the vendor's technical team's analysis will still not be based on a holistic view of your organization – they will not be looking at your entire organization as a "system." They will be looking at individual organizational silos and functional areas, frequently assigning different personnel to oversee "requirements gathering" in the different silos. Supposedly, this is to make things "better," because the different persons will each be "specialists" in their respective assignments. But, if they are like far too many vendors and resellers, no one has the training or experience to really see how your organization functions as an integrated "system" or "chain" of dependent events and actions. Thus, their "requirements gathering" will also fail to seek out and discover how to optimize the "system" in order to help your organization achieve more of its goal to make more money tomorrow and in the future.

In the best-case scenario, this post-sales "requirements gathering" process will stumble upon one or more of the things that must change to increase Throughput (T), reduce Inventory or demand for new Investment (I), or hold the line on Operating Expenses (OE) while permitting your organization to sustain substantial growth. Absent a holistic – a "system" view and theory – this new "requirements gathering" team will still be operating entirely under the assumption that if, in the Everything Replacement Project, they improve every functional area or even some functional areas as a result, the whole organization will benefit and be more successful at achieving its goal. As we have seen, since an organization is a "chain," only strengthening the weakest link will improve the organization as a whole. Time, money and energy spent elsewhere are substantially wasted.

That was the good news. Here's the bad news:

In the worst-case scenario, this new "requirements gathering" team will complete their more detailed "requirements gathering" and determine that, yes, they can make the technology that you have already purchased "fit" your firm's "requirements," but it is going to take a whole lot more time and money than you and your management team had anticipated. But, what can you do? You've already made an irrevocable commitment to purchase the vendor's technology.

If your team has been working along with us up to this point, you may have recognized that the work you have done in creating your own Current Reality Tree (CRT) and the analysis of the "roots" of your CRT was your "requirements gathering." If you have done your work correctly and effectively, you already know the critical requirements you must address with technology (where it applies). In the example company we have been using (see prior posts), the management team has already identified (among others) the following critical requirements that will require technological support in order to improve the performance of the whole "system":

1. Integrated bar code printing
   
2. Integrated ASN (advanced shipping notice) generation and processing
   
3. Reduction or elimination of paper-based picking and shipping processes
   

Our example firm's management team is already well prepared to seek from vendors and resellers specific and targeted "requirements" focused on the specific and targeted functions that must be improved (changed) to increase Throughput (T), reduce Inventories or the demand for new Investment (I), or slash or hold the line on Operating Expenses while sustaining substantial growth. They do not feel the need to do an Everything Replacement Project – traditional ERP, because they are already well aware of the few and limited things that need to change to bring effective improvement in moving toward their goal of making more money.

[To be continued]

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]

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]