Biting the Bullet on IT Investment

By Eric Chabrow  |  Posted 02-07-2008

Biting the Bullet on IT Investment

Far too often, companies keep legacies systems well beyond their practical usefulness, says Accenture CIO Frank Modruson, who contends many IT executives fail to focus on the long-term benefits of investing in new IT as they tweak existing systems. In an interview with CIO Insight editor Eric Chabrow, Modruson discusses how Accenture reduces overall costs by investing more up front and the benefits of having all its applications Web-ready. Here's an edited transcript of that conversation.

CIO Insight: Accenture research suggests that companies aren't aggressively investing in IT. How so?

Modruson: Companies spend more time running and operating their existing systems than they do keeping them up to date. It's like a house; it's much more expensive per square foot to rehab a house than to build a new one. At some point--this is a very emotional thing for people--you're better off bulldozing the house and building a new one, right? I'm not recommending that we should always bulldoze systems and put up new ones, but in a lot of cases, it's less expensive to start over and put a new application in.

For example?

We had a packaged scheduling system that had some performance and information usability issues. We could have invested in improving that application. But the best answer for us was to drop the package and put in place an easier-to-use, simpler, customized Web-based application. The new application is dramatically less expensive to operate because it scales better and uses hardware better. We drove down the operating cost of the application.

It used to cost about $6 million a year to run this app. The new app costs about $3 million. It paid for itself in a year, but the counter-intuitive thing is that replacing the old app was actually a much better business case than tweaking the existing app. Most companies fall into the trap of, "Instead of spending a million bucks to replace it, I'll spend $200,000 to tweak it." Plus, the new app helped us schedule people better and faster, reducing the time to match people to engagements by 70 percent. That's actual money in our business, right?

Page 2: Web Ready

Biting the Bullet on IT Investment

pagebreak title = 'Web Ready'}

Most of Accenture's applications are Web-accessible. Why is that important?

Our philosophy around applications is anytime, anywhere access. Our people can work at our clients' sites, at a hotel, at an office, at home, so we architected all our applications to be Web-accessible. There are some workstation-based applications that aren't technically Web-based, although many of those will be up for replacement over time. One of them, our time and expense application, is in the crosshairs. We're starting a project on that. That's probably the largest used, non-Web app. I'd be hard-pressed to name a second because they've all been replaced and moved to the Web.

Does making your apps Web-accessible suggest a move toward more use of Software as a Service?

SaaS is a great opportunity in the right circumstance. It's like anything: Just because you have a hammer doesn't mean everything is a nail. But SaaS is a very important hammer.

Look at recruiting as one example. Recruiting is a very encapsulated business process. Somebody applies, they're evaluated and a decision is made on whether to hire or not. It's a serial process with a discrete beginning and end, and then there's only really one interface to be done. When we looked at alternatives to consolidate our 40 recruiting systems, SaaS met our functional needs. Though there was some configuration, we could deploy the app faster because we didn't have to acquire the hardware, install the software.

Still, don't circumstances exist when you need to customize such applications?

With packaged software and SaaS, you generally want to take what they offer. You want to leverage the intellectual investment and capital of the greater organizations using the technology. You don't want to fall victim to getting off that track by having too many customizations. The vendors provide some level of configuration and you want to take advantage of that.

You might go back to them and say, "Your software does these five functions but doesn't do this sixth one. I might invest in you to write that functionality, or I might be the seed user, if you will include it in the base product." That gets attractive; there's a synergistic relationship. What you don't want to do is say, "Hey, I like your system, but modify these three places." They respond, "Well, no one else wants it that way." Now you're on this fork of code, which is really very negative.