Strategy No. 1 - Don't Stop Thinking About Tomorrow.

Companies put off upgrading their enterprise software because the process is a shock to their system - not just the IT system but the business system. Some postpone the process until they will lose support for an old software version if they don't upgrade (see "It's the Functionality, Stupid", below).

To avoid desperate upgrades, CIOs need to create a continuous planning process that includes users, not just IT.

At Ventura Foods, a Los Angeles-based food distributor, Richard Chamberlain has set up a cross-functional team of IT and businesspeople who are responsible for each module of the company's JD Edwards ERP system. Those module leads are the superusers who help their business departments understand and use the system. The committee has a flowchart of the entire ERP system that shows all the business processes affected by the different components. When an update is released, the committee can map the new functions to the current system and the business processes that are affected to determine whether the updates are worth incorporating.

The module leads, along with IT managers, are responsible for tracking the updates. That keeps them involved and makes it easier to enlist their support for doing an upgrade - or resisting it. "The different module leads come together and say, OK, here's an update, what does this mean to all of us?" says Chamberlain, who is director of innovations and e-solutions.

Like most ERP customers, Chamberlain keeps three different ERP environments running at once: the system that the company uses day-to-day - the production environment; a much smaller development environment for playing with new software and any customisations that are necessary; and a testing environment to see if new versions of the software will work properly before they are brought to the production system.

But in a testament to how complex enterprise software upgrades can be, Dennis Upton, CIO at Brother International, a New Jersey-based office equipment maker, had to set up a second test environment when he upgraded from SAP 3.0E to the SAP 4.5B product because the new software was so different from the old. "You have to create a duplicate environment for your upgrade," he says. "It's a fact of life."

It was also about $US200,000 in extra cost.

Strategy No. 2 - Flush the Custom Code.

CIOs know that putting an upgrade through its paces in a test environment is critical because most companies wind up customising their enterprise software to fill gaps in the functionality, adapt to a specific industry or legal requirement, or simply because the users want the software to act differently than it does out of the box. It's not that customisations represent a failure - they are often legitimate and may even add a bit of competitive advantage to an otherwise vanilla software program. But companies tend to customise overmuch in an attempt to appease the businesspeople who use the system.

That's why some CIOs see upgrades as a prime opportunity to flush custom code from the system and replace it with a standard software program or interface from a vendor. Removing custom code makes it easier to upgrade because you don't have to rewrite the code each time a new enterprise version comes out. It also makes it easier to integrate the software with other software systems inside the company.

"I think the effort required to upgrade is directly related to the amount of custom code you have," says Rafael Sanchez, CIO of Burger King. The Miami-based restaurant chain built a custom software program to handle its real estate dealings when it first installed SAP R/3 in 1995. But this year Sanchez replaced it with standard functionality from SAP. "We reduced the custom code in the real estate package by 90 per cent, in finance we got rid of 60 per cent, and in HR we'll lose 60 to 80 per cent," he says. "All that means is that we'll have fewer software applications to support internally."