Home
 > Research and Reports > TEC Blog > What's Wrong With Application Software? Business Changes,...

What's Wrong With Application Software? Business Changes, Software Must Change with the Business.

Written By: Olin Thompson
Published On: May 31 2004

<

Premise

Business changes constantly in small ways and large. It is rare to find an application product that can change once it is implemented. This gap is a reality leading to dissatisfaction and the application being a drag on the business. This gap, the lack of the ability to change, costs the business dearly. Software needs to be the agent of change, not the enemy of change.

Change Happens

Successful companies are increasingly taking on new business models and business processes as an ongoing way to outmaneuver their competition. These companies have found that there is an inherent conflict between the fluidity and agility with which they want to run their businesses and the rigidity and control with which their systems operate. This incompatibility between agile businesses and static systems has hampered efforts to change the business effectively and rapidly to capitalize on business opportunities. Whether a company is aggressive in its adoption of change or conservative, change is inevitable and ongoing.

A gap exists between the change needed by the business and the ability of the enterprise architecture to accommodate or facilitate those changes.

What is the cost associated with this gap? The costs of not being able to change are real but difficult to calculate. What does it cost a company when customer satisfaction erodes? What are the costs when the company cannot respond to competitive pressures? What is the cost of manual or semi-manual work-arounds in terms of time, lack of integration, accountability, quality, etc.? What is the cost of the IT department and IT leadership being seen as a hindrance to moving the business forward? These costs are real and significant.

The Software Industry's Efforts at Accommodating Change

The need for change is not new to the software industry. The enemy of change has always been cost, time, and quality; these barriers will continue. Attempts have been made in the past to overcome these barriers within the practical limits of the technology available at the time.

The current state of the market is "standard, configurable" applications. The assumption is that standard software applications can bring best practices to a business and be made flexible enough to accommodate the majority of businesses without significant modification. Through the use of complex tables and switches, the software could be pre-configured to handle a large number of pre-determined, "flexible" options. But in truth, the flexibility is only to choose from a list of existing, predetermined options. If the required option does not exist, there is no real flexibility available. If a decision is made on which of the options is best, and that decision needs to be changed in the future, that flexibility is often non-existent.

However, this approach came with very heavy costs in terms of the increased complexity of software code, which led to erratic quality, extensive implementation lead-times, and difficulties in changing the software once implemented. The issue of flexibility was solved for an initial implementation, but ongoing business innovation was not supported. Software templates and quick implementation tools helped to solve the problem of long implementations due to complex tables and switches, but they did nothing to address the underlying problem of becoming inflexible after implementation.

A key objective of "standard, configurable" applications was to eliminate the need for modifications. While this has been the stated goal of many companies, the statistics prove that it is not, in fact, how the majority of companies are running. An October 2002 Pulse survey by ERP Toolbox (http://ERP.ITtoolbox.com) found that 42.16% of enterprise resource planning (ERP) customers had modified their systems "Quite a lot". The real truth about standard software application is that very few companies really run them as standard products.

Today, the ability for application systems to support the company in remaining competitive usually involves working around the system and waiting for the next release, or implementing a redundant system that over-rides the base ERP system. This leaves companies at a competitive disadvantage because they are continuously suffering from either the opportunity cost of not changing the business, or the operational cost of working around the system—and often a combination of the two. Further, the core objectives of installing an ERP system in the first place (best practices, integration, etc.) are challenged over time.

SAP, the largest provider of packaged enterprise applications, announced the formation of their new Custom Development Services Organization (CDSO) at their recent European user conference in September 2002. The stated mission of this organization is to meet the customization needs of its largest customers. It seems, in fact, that even the largest customers using software from the largest vendor require customization.

The "no modifications" assumption is one of the most basic made by companies about their enterprise applications. Most enterprise vendors believed the "no modifications" assumption when they architected their products. This assumption is basically untrue.

What Do We Need?

The next generation of enterprise architecture must allow for business change to be adopted on an on-demand basis as the business evolves. As we stated in What's Wrong with Application Software? It's the Economics enterprise architecture must provide the cost, time, and quality characteristics to make change a practical choice for the business.

What are some of the business characteristics required to meet the challenge of change?

Lower the penalties for modifications Today, the penalties for modifying are so high that companies find it difficult to justify all but the most important changes. With the dropping of the cost, time, and quality penalties, it becomes increasingly practical for the system to be responsive to the needs of the business.
Provide flexibility for options not initially conceived by the vendor Companies need best practice, but they also need "our practice" and the ability to respond to the needs of customers and others. If the vendor has not built in the option, the company should be still being able to provide the function required.
Change on demand The change process should be quick and painless. The delay between need and solution should be minimized.
Provide feasible small modifications as well as large Modification projects are often very large, but to be responsive, the system must be economically changed for both small and large requirements.
Controlled change process The change process must be a solid, controlled process with built in management and quality.
Provide the business user visualization and evaluation of potential modifications Assist the business user to understand what the system will look like and how it will operate after the change to avoid surprises, rework, and to further user acceptance.
Evaluate and pinpoint the change effort The full impact of any change must be known in advance. This includes the impact on the system and the cost and time required to make the change. This information will increase the management process and avoid surprises
Continually maintain the "as installed" version of the system Any change should be reflected in the "total system" including documentation, user manuals, help text, etc.
Sustainable product enhancements Modifications should be maintainable in the future to evolve with the needs of the business and the advances made by the vendor.
Integrate the acceptance of new vendor releases with modifications New releases from the vendor will come and any modification should be easily re-evaluated and reapplied as applicable at a realistic time, cost, and quality.

Summary

Change happens. It will always continue to happen. A system should be an aid to changing the business, not an obstacle to be overcome as it is today. Future enterprise architecture should accept and assist in the reality that business changes and software must change with the business.

About the Author

Olin Thompson is a principal of Process ERP Partners. He has over twenty-five years experience as an executive in the software industry. Thompson 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.

 
comments powered by Disqus

Recent Searches
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.