Why value trumps price when buying enterprise software
Panasonic POV: We saw this story and wanted to share it with our readers. We know this perspective holds true for buyers of enterprise mobility solutions. It’s not the purchase price that should be considered, it’s the cost (and value) of the device over time. The right device is always better than the most affordable one. The Benjamin Franklin quote in the second paragraph says it all.
The corporate procurement process traditionally focuses on achieving the best purchase price. While this may be the right approach when buying commodity items, when it comes to buying enterprise software it is completely wrong. A far better approach is to focus on the value provided by the software rather than its price.
To paraphrase Benjamin Franklin “The bitterness of poor functional fit remains long after the sweetness of a low price is forgotten.” If you pay too much for software, all you lose is a little money. If you buy on price, you risk losing everything, because software that does not adequately meet requirements will eventually be replaced. Government departments that take the lowest bid when purchasing software often fall prey to this problem, and it also happens in private enterprise.
The source of software value
Value is in the eye of the beholder. It is determined by the buyer and what they are prepared to pay. When it comes to enterprise software, the value does not flow from deliverables like meeting project milestones. Rather value is in the outcomes that flow from using that software, i.e. from the ability of the software to meet the organization’s particular requirements.
By its very nature, enterprise software is extremely complex. For example, if a mid to large sized company is considering ERP software, a thorough analysis can yield numbers approaching ten thousand requirements. The value of the software comes from adequately satisfying these requirements. Only the buyer can decide how much satisfaction is worth to them, and therefore how much they will pay.
Determining software value
The starting point for determining software value is identifying the requirements that must be satisfied, including both functional and nonfunctional requirements. There is a grave risk of the wrong software being selected without an adequate requirements analysis being done up front. Once all significant requirements have been identified, including unknown requirements, and rated for importance to the organization, a gap analysis is done to measure how well the potential software products being considered meet those requirements.
No software product is a perfect fit, and all involve some degree of compromise. However, knowing how well products meet those requirements allows you to estimate their value to your organization. It is wise to factor in the cost of not meeting certain requirements into the calculation as well. Once you know the value, you can decide if the price of a particular software product is reasonable or not.
Sometimes the wrong software is bought, which sets a ceiling on how well it can meet the organization’s needs. If that ceiling is too low, the software will eventually be replaced. Even if the best-fit software was bought, a thorough requirements analysis is still vital to avoiding the pains typically associated with these projects.
Why the value approach works
When requirements are not discovered in the analysis phase, they will be found during implementation. If they are not satisfied “out of the box”, then the implementation team must decide how to meet them by configuring the software. If they can’t be adequately satisfied with configuration, the implementation team must develop a workaround, e.g. add extra cost options, find suitable add-on products, write custom code, re-engineer business processes, etc. All of this takes time and money, which is why finding substantial numbers of so-called “new” requirements during implementation causes schedules to slip and costs to balloon. When go-live dates are repeatedly pushed out, you can be sure there is serious trouble on the horizon. Think back through your own experience: how many projects where implementation slipped badly were eventually an outstanding success?
The value of enterprise software comes from its ability to satisfy requirements. If a thorough requirements analysis is done up front and no significant requirements are discovered during implementation, the project stays on schedule and within budget. Users are happy because the software works as expected and there is minimal business disruption moving to the new system. Projected cost savings are realized, and the software delivers on the promised value.
If software is bought on price, you can absolutely guarantee that shortcuts were taken, and a thorough requirements analysis was not done. Such projects always carry a serious business risk. On the other hand, organizations undertaking the rigor of a mature software selection process and selecting a product by value are far more likely to achieve the desired outcomes. The software with the greatest value is the product that best satisfies requirements for the price. At the end of the day it really is about the value of requirements satisfied, and not about the price.
This article was written by Chris Doig from CIO and was legally licensed through the NewsCred publisher network.
###
The Panasonic Solutions for Business blog occasionally posts licensed third party content we believe is relevant to our audience.
