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.
