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