Application Erosion: Eating Away at
Your Hard Earned Value

by Olin Thompson

Do you have Application Erosion?

At a recent meeting of CIOs, all talked about the same phenomena. Eventually, they came up with the term "Application Erosion" to describe their common problem. These CIOs each had the same ERP system installed for from four to nine years. Each observed that through time, the system value had become less and less. The system had not changed; but the users were using less and less of the system for no apparent reason.

In another conversation, a friend who works for an ERP vendor told me he was working with a company who wanted to replace their existing ERP system. By coincidence, eight years ago, my friend had been the consultant who worked with that company to install the existing ERP system. When he reviewed their requirements list for the replacement system, he reported some amazing facts:

  • Thirty percent of the requirements for the new system were functions that he had helped the company install eight years ago.

  • Another twenty percent were functions that they had available in the existing system but had never implemented.

  • An additional 20% were available from the supplier of the existing ERP system.

What had happened? For the first 30%, the answer is Application Erosion. For the next 50%, it means they might be taking the more expensive and difficult path of replacement over working with their existing relationship.

Why does Application Erosion Happen?

Many factors lead to application erosion, and in most cases, most of the factors play a role.

  1. The old saying "use it or lose it" applies to existing users. Functions not frequently used tend to be forgotten. These users did not decide to stop using these functions, but since users are human, they just forgot. The CIO group reported that many user requests for enhancements end up with a "look under option 7" reply with the requesting user saying, "Oh yea, I forgot about that."

  2. Staff turnover also impacts value. Unless a company decides to have a formal training program for incoming users, the existing users train new users. Even with the best intent, the existing users teach only 70-80% of what they know. That means the first generation's 100% of knowledge goes to 70-80% for the second generation and 49-64% for the third generation. The numbers of generations of users experienced in any one are is an indicator of how much erosion you have experienced. When people do not know how to fully use the system, they cannot generate the full value of that system.

  3. Of course the business changes. But in most companies, it changes so slowly that there is no plan to insure that systems support reflects those changes. We begin to see more and more functions being done on spreadsheets or manually with less and less being part of the formal system. The impact on value - it declines as the system drifts away from the needs of the business.

Do all these forces mean that the erosion takes years? No, it starts the day you turn on any new system. If continues constantly. While you were reading this article, you have lost some value.

Preventing or Reversing Application Erosion

If you do nothing, application erosion will happen. To prevent it, you need a plan. If you suffer from it today, you need a plan to regain the value you once had.

People - The biggest cause of application erosion is people. We can be 100% certain that people will continue to be people. Some one has to do something to prevent the people from allowing the applications to erode.

The most obvious effort is in training. If you can afford a formal training program for new users, much of the erosion can be avoided. If you retrain existing users, some of the erosion can be reversed. However, getting the backing of management to retrain users or have an on-going training program is never easy. It is hard to see the value of training when the system is already running. No event happens that forces management to see the need for training - the system loses value everyday, but never at the rate that it is obvious.

Super-Users - When you first installed, you had "super-users" who knew the system very well and were advocates for its use. Other users knew they could go to the super-users to get answers. Where are your super-users today? Most have moved on. To halt or reverse erosion, you need to create a new generation of super-users. You need to identify people who have the enthusiasm (or who can get the enthusiasm) for the system. You need to excite them and bring up their level of knowledge. How? Training, attendance to user group activities or putting them with super-users from other companies are all examples of how to recreate super-users. Maybe you need formal recognition of the super-users, make them proud of their knowledge and role.

Business Change - As your business slowly evolves, recognize that the systems will not automatically evolve with the needs or the business. The users and how they use the system will evolve, but without the assistance of super-users or a seeker of value, they will evolve away from the system. You fix this problem by recognizing the problem and accepting the fact that it takes resources to avoid it.

A consultant for a national firm discussed the role of business change. He stated that businesses must change to stay competitive. The problem of change is the inability of the system to keep up with the changing demands of the business. He points out three issues.

  1. Most software packages are relatively inflexible once installed. Software vendors need to do a better job of architecting products that allow the implementation of the product to evolve with time. Since it is very difficult to change the way the product is implemented, it does not get changed. How a product can evolve is rarely a consideration in the selection of a new system but it is a major consideration in the long-term value of the system.

  2. Many IS organizations are not aligned so that they understand the changes to the business. These IS organizations are focused on maintaining the status quo while the business is focused on evolving the status quo. Aligning the IS organization with the business functions with clear cut responsibilities for staying immersed in the business, not in the technology, is critical to avoiding application erosion.

  3. Regardless of the technology used or the efforts of IS, the formal system and the actual business processes will have a widening gap over time. A periodic review of this gap will help focus attention on the problem. Identifying the gap will allow management to quantify the cost of the gap in terms of the effort required to work around the gap and the impact on the running of the business. He suggests that part of the review be people who are not involved with the day-to-day business. It is hard to see slow changes if you see them everyday. A person who has only a periodic view can see the changes more easily than the person who is involved everyday.

Advocate - One CIO has had results in reversing the erosion of value in his company by have a staff member who is their "seeker of value" who serves as an advocate for the system. The person is more an internal sales person than a consultant. The seeker of value's job is to understand the software and get others to use more of it or design more ways to get value out of what they are already doing. In this example, the seeker of value is actually someone who was with the vendor as a pre-sales consultant. If you cannot afford your own full time seeker of value, maybe an external person with the right experience, business skills and communications skills on a part-time basis is your answer.

Data Quality - The CIO of a midsized company tells us that a symptom of application erosion is the decline in the quality of the data in the system. That decline can be measured in terms of its latency, the time between the physical action (shipping a product) and the time that the database reflects that action. In a real time system, the latency is zero. In good implementations, the latency is minimal, measured in minutes or maybe hours. As erosion sets in the latency increases to hours or days, as the users find it less important to update the system.

The decline in the quality of the data can also be measured in accuracy. If the numbers are wrong, one reason can be that the users no longer consider it important that they are correct. Alternatively, the business process does not generate the same numbers as in the past so the system reflects something other than reality.

Our CIO experienced this symptom. His action was to increase the visibility of the data within the enterprise, with an emphasis on top management. He implemented a business intelligence (BI) project. Since his BI solution was pre-built for his ERP system, he started seeing results within weeks of his final decision on a product. BI allowed top management and all the users to see the data in a more valuable format. This increased visibility had several effects:

  • Using analytics that reflect the current situation (today's shipments) highlighted latency problems.

  • Inaccurate data stands out when viewed by people knowledgeable about the business, highlighting problem areas.

  • Highlighting latency and accuracy issues led to fixing both the data and (more importantly) the business processes that created the problems.

  • Users, knowing that many people were looking at, depending on and benefiting from the data, became more aware of latency and accuracy issues.

His BI project had many hard benefits in the availability of information and the quality of decision-making. A side benefit which is hard to quantify is how it helped reverse application erosion.

Vendors Share the Blame - One veteran of many ERP implementations lays some of the blame for application erosion on the vendors. He reported, "Today, the method of selling employed by most software vendors is the "churn and burn method". They spend most of their sales money on attracting new customers and not on farming their customer base. The stock market of the 90's worshipped new accounts and that pushed the lever over to the new account side of the scale at the expense of service to existing customers."

"In the old days an account manager was responsible for a group of accounts that were customers. These account managers, to be successful, had to gain acceptance of the customer as a valued member of the team and sought a position of influence in the planning organization of the customer," he added.

If the account was managed correctly, the application manager played a role in minimizing application erosion. The Account Manager helped the customer decide which functions of the current and future product are of value to them. A properly trained account manager acted as a conduit from the users to the planning groups constantly updating the steering committees on what processes are working and what processes are having trouble. The application manager could suggest training and can help the users explore all the functions provided by the software. If he is truly successful with his function then both the customer and the vendor prospered. Some people will say this is not the function of the selling company (to provide an active account manager) because they will be biases to the installed company. This is not true. Customers are smarter than that. They see through any insincerity on the part of the Account Manager. If he is not there to help, he will be ineffectual and will be replaced.


The day any new system goes live, you have created value. You paid for that value in money, time, disruption, frustration and many other currencies. But you will lose the value you already paid for if you do not do something to avoid application erosion. If you have already suffered some erosion, how do you regain what you lost? It takes recognition of the problem and the willingness to fix it. No one will ever come into your office complaining, "Today we lost some value". Therefore, the problem is not easy to see and it is not easy to motivate the company to combat what is a slow but unyielding problem.

Olin Thompson, a principal of Process ERP Partners, has over 25 years experience as an executive in the software industry with the last 17 in process industry related ERP, SCP, and e-business related segments. Olin has been called "the Father of Process ERP." He is a frequent author and an award-winning speaker on topics of gaining value from ERP, SCP, e-commerce and the impact of technology on industry. He can be reached at .

Many more articles in The CIO Refresher in The CEO Refresher Archives


Copyright 2004 by Olin Thompson. All rights reserved.

Current Issue - Archives - CEO Links - News - Conferences - Recommended Reading