<
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.