Enterprise Software Upgrades: Less Pain, More Gain
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," this page).
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 J.D. 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 customizations 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 Bridgewater, N.J.-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 $200,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 customizing 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 customizations 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 customize overmuch in an attempt to appease the businesspeople who use the system.



