A Plunge into the Unknown...

Software upgrades are often necessitated by the fact that the software
undergoes a functionality change, enhancements to the existing functionality
undergoes a major bug fixation and this necessitates a change due to changes in
the native operating system. Whatever be the reason, any software upgrade
deployment becomes a CIO’s nightmare as it is often termed–taking a plunge
into the unknown.

Software upgrades could be classified in two categories:

n  Upgrades to
software that runs on a standalone mode without interfaces to major running
applications and any impact would be local in nature; and

n  Upgrades to
software which run across the enterprise with a major impact across all facets
of your corporation and having strong interfaces to other running applications
across another corporate.

Software vendors are ever evolving their software to catch up with their
competition and announce upgrades at the drop of the hat. They also would like
to give the user a sense of security that he is dealing with the latest and that
he is getting a real value for the software annual maintenance charges .

While deciding to upgrade, the CIO has to evaluate and take a decision based
on the following parameters.

n  Is the
upgrade/enhancement necessary in terms of the functionality that is being
offered and the requirements of his business?

n  What would
be the cost of upgrading the software in terms of...

  l  Downtimes
to the existing running application?  

  l  The
sheer magnitude of the effort of deploying the changes across every desktop of
his corporate?

  l  The
real benefits?

The decision becomes more difficult when you need to decide whether to apply
patches to an existing ERP system. During an ERP implementation cycle one goes
through a process of iterative configuration and testing phase. It is after
months of testing that a rollout takes place. A typical test scenario for a
single upgrade could take a week with a test team size of four to five members.
It is of utmost importance that a test bed is created to test the different
scenarios.

It is an impossible task to carry out the complete testing cycle for every
update patch that is shipped out by the vendor. The tendency is to skip out
patches, which do not have any relevance to your installation and enterprise
functionality. The problem with this approach is that after having skipped about
20 patches you would find a relevant patch which you would need to update, but
you may not be able to proceed with it as some systems make it mandatory for you
to maintain continuity in hot packs that need to be applied. Some CIOs have
taken the easy way out by not applying any of the hot packs and going in for a
fresh version change at a periodic interval. This way you need to upgrade to a
higher and a better version once they carry out the iterative upgrade test once.
Needless to say, you would have taken the upgrade to the new version only after
the new version has stabilized worldwide.

Although the upgrade document very clearly documents the benefits of the
current upgrade and the impact that it could have on the other function module,
the dirty and the painful job of testing can never be wished away as every SAP
instance is different as the site configurations are different. Never whip a
running horse. Never upgrade a running software unless it is imperative. The
common practice has been to use the shipped software upgrades as tea coasters or
give them to your child to be used as flying saucers.

Ravi Parasuram