Capturing the Hidden ROI in Applications

When ROI (return on investment) is used in an IT context, it invariably boils down to how quickly a company can realize a return on hardware, software licensing and the day-to-day expenses of running a data center. Enterprises’ results in this area have been impressive, with many companies realizing cost-savings benefits in the tens of millions of dollars.

But this isn’t the only ROI.

The return on investment for applications continues to be an underexploited area for organizations—and as long as it remains underexploited, firms stand to lose millions in squandered employee productivity, lost revenue and service opportunities, and best-of-class operational workflows. “We see this all of the time in our applications, and especially with our CRM systems,” said one financial services sales and marketing vice president. “Over one year ago, we purchased a CRM (customer relationship management) package to help us better understand our customers and their needs. Now after one year of use, if we’re using 1% of its capability, we’re lucky.”

Other companies tell similar war stories. So what causes under-exploitation of application software?

We’ve all heard about the 80/20 rule. It also applies to applications. “The biggest concern we have with the users of our application, quite frankly, is that they are only using a portion of what the software can do for them,” said one supply chain software vendor. This means that the remaining 80% of application functionality is sitting on the shelf.

One contributing factor to application under-exploitation is the project implementation process itself. Within IT’s end-to-end “to do” list, an application project may be only one line item. This makes it easy for IT (and even end business users) to be satisfied that they got a new application or software package installed—and that they have implemented it with at least a baseline of functionality that everyone is trained on. After this point, there is a tendency for IT to retreat to a “maintain” mode, and for end users to take some time to further adapt the software to the everyday operation. Meanwhile, no one is evaluating other features included in the software and assembling a continuous implementation plan that will progressively incorporate even more functionality from the applications into the business. Consequently, the company risks losing out on a majority of what it has paid for in the application.

In many cases, software application vendors don’t help the situation, either. Documentation and training for applications traditionally are under-invested in by these vendors—and it’s often not an easy job for someone in IT or an end-user department to figure out what else they might plug into the business from the software, and how it will work.

After the baseline application is installed and running, there initially are a large number of calls that come into the IT help desk. Here again, the dots may not be connected to improve user use of the application for the long haul. One contributing factor is the customary “disconnect” between the help desk and the applications group. Generally, application development works with the help desk when the help desk is unable to answer or solve an end user problem—but there isn’t a flow of most frequently asked questions or software issues from the help desk back to applications that allows the applications group to research these issues and then to proactively determine how to better design applications in the future to assure maximum application utilization in the business.

As was mentioned earlier, IT and end users both tend to be satisfied when a new application or software package is at last installed and up and running. This sense of relief can be so overwhelming that little thought is given to followup on how fully the application is being used. Metrics tend to focus on meeting application implementation deadlines—and not on measuring how completely an application is being used, or quantifying the value that the application is bringing to the end business.Given these situations, is it possible for sites to get their arms around these challenges and improve their application ROI? The answer is yes. Here are several recommended best practices:

Establish application ROI metrics: IT has successfully established ROI for hardware, measuring elements like data center square footage, licensing costs, energy usage, staff time, and so on. It isn’t such a big stretch to also set up metrics tailored for software. These metrics could include an analysis of the total software package—and an evaluation of just how much of the total functionality is being used (e.g., 20% initially—with a goal of 40% by the following year). If the application was developed or purchased to produce competitive advantage through operational savings or increased revenues, targets should also be set with the CFO, sales VP or others.

Include applications ROI as a vendor measurement and evaluative factor: When companies put out RFPs (requests for proposal), they should make it clear to software application vendors that ROI will also be an evaluative factor. One way to establish this return is to set forth a metric in the RFP as to how quickly an organization should be able to uptake the total functionality of the application. This challenges the vendor to provide stronger training and educational support in order to earn the business—and it helps the business avoid the unenviable situation where one year later, executives feel only 1% of the software is being used.

Performing application ROI audits: IT should measure the ROI progress of an application in the same way that it measures the ROI of hardware and the data center. These internal audits of software effectiveness should be conducted minimally on an annual basis. If an application is falling behind on its ROI goals, or if the business has drifted to the point where the applications can no longer deliver ROI, an appropriate deimplementation or exit strategy can also be devised.

There are many factors that can quickly dissuade IT from taking a more comprehensive ROI position on software. First and foremost is the length of the IT project list. In other words, if application ROI is not being asked for, why offer it? Unfortunately, the amount of waste that is accumulating from failing to fully exploit all that a given software package offers for the business is fast reaching a point where businesses cannot afford to keep absorbing it.

“We dedicate an enormous percent of our implementation time to assisting end users with how our business analytics solution can really help them manage their assets better,” said one analytics vendor. “If we didn’t do this, we know that the first thing companies would ask us is to just convert the set of 20-some odd batch reports that they have been using for the past twenty years.”

Clearly, it’s time for IT and the end business to take a more aggressive ROI approach to software applications—and to stop leaving all that untapped functionality on the table.

Learn more about Strategy: Predictive Analytics for IT by subscribing to Network Computing Pro Reports (free, registration required).