Ultimately, enterprise software is bought to deliver value, and that value flows from how well the software meets requirements. To maximize returns on software investments you need to complete a value analysis before making the purchase.
Buying enterprise software is not like buying a car or a house where there is pride of ownership. Nobody buys software for the sheer joy of owning it. Rather it is bought for the value of the benefits that flow from using it.
Market leading software is often seen as delivering this value, but without a detailed value analysis, there is no way to know this before making the purchase. Too often, software is bought only to find that it does not deliver the expected value because it is not a good match for the particular requirements. However, once the purchase has been made it is too late to do anything about it. Invariably organizations buying software because it is the market leader tend to be near the bottom of the Software Selection Maturity Scale.
Sources of value
Like beauty, value is in the eye of the beholder or, in this case, the organization making the purchase. The value of enterprise software comes from two areas, namely cost savings or revenue & opportunity enhancements. While these are different for every purchase, costs savings are usually easier to quantify. Cost savings are very important but are limited to the total amount being spent, and invariably are only a fraction of this. The greater the desired cost saving, the harder it is to achieve because of the law of diminishing returns.
On the other hand, the value generated by revenue and opportunity enhancement is effectively unlimited. For example, if the proposed new software can improve operations so that previously unreachable customers can now be serviced, that will compound over time and deliver increasing value. For that reason, it usually pays to put more emphasis on revenue and opportunity enhancement than on cost savings.
In the enterprise software world where a company is considering ERP, Customer Experience Management, Human Capital Management, Marketing Automation, and so on, the value of the software comes from both cost savings and revenue & opportunity enhancements. To quantify the value of the software you need to estimate the ROI and use this to compare the different products.
The value of software comes from the benefits that flow from meeting requirements. Thus, you need to measure how well potential software products meet the specific requirements of the organization, which means a full evaluation and selection project. Since you are buying software as opposed to writing it, you can know all requirements upfront, even unknown ones. It is well worth the effort of front loading requirements analysis because this reduces the risk of selecting software that is not the best fit, and of missing requirements only to have them discovered during implementation where they increase costs and make schedules slip. The output of this exercise is a short list of potential software products ranked by how well they meet organizational needs.
Once potential best-fit products have been shortlisted, the total cost of ownership (TCO) can be estimated for each potential software product, and the ROI updated. Each product will have a different ROI, especially if you are comparing cloud with data center products.
Use the estimated software implementation time as a guide to decide the period over which the ROI should be calculated. For example, if the software can be implemented in less than six months, you can use three years, for six to twelve months, use five years. If it will take longer than twelve months to implement, you may want to use ten years.
To maximize the value of enterprise software you want to select the product with the greatest ROI, which means doing a thorough value analysis before purchasing. Making investments without adequate research is gambling. Likewise buying enterprise software without a proper value analysis is also gambling, this time with your company’s future and even your career. Is it worth taking that risk?
This article was originally published on CIO.com on November 9, 2015