Data Quality and a Cure
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.
A consultant for a national firm commented on the original article's point on 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:
- 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.
- 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.
- 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.
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 90s 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.
About the Author
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 Olin@ProcessERP.com.