Why value trumps price when buying enterprise software
When it comes to enterprise software, value is far more important than price.
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 like ERP 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, you will lose a little money. If you buy on price, you risk losing everything you spent, 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. For an explanation of where the money is lost see The 5 costs of poor software purchasing.
The source of software value
Value is determined by the buyer and what they are prepared to pay. When it comes to enterprise software, the value is in the outcomes that flow from using that software, i.e. from the ability of the software to meet the organization’s functional requirements and support the business strategy.
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 between two and 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 determining the dollar value of the software in supporting the business strategy. For example, a manufacturer believes that process improvement could increase their gross margin by 10%, and that replacing an old ERP system with one better suited to the business could help them achieve that goal. Their annual revenue is $300 million and if the margin goal is achieved the new software could have a value of $30 million per year, i.e. the ROI on the software could be up to $30 million annually.
Next, identify the business 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 weighted for importance to the organization, a gap analysis is done to measure how well 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. Once you know the value, you can decide if the cost of a particular software product is reasonable or not. In addition to selecting best-fit software, a thorough requirements analysis is also used to prepare the organization for that new software.
Why the value approach works
When significant requirements are not discovered in the analysis phase, they will be found during implementation, when going live, or in production. The later these significant requirements are discovered, the more they cost to satisfy. For example, if new significant requirements are discovered during implementation, then the team must see if they can be met 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” significant requirements during implementation causes schedules to slip and costs to spiral out of control. 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 answer to that rhetorical question is “virtually none.”)
The value of enterprise software comes from its ability to satisfy requirements and support the business strategy. 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.
If you want ideas for developing the value of new software to your organization, see the Wayferry value proposition page. If you would like assistance in determining the value of new software like ERP click the [Contact Wayferry] button below and let’s explore if we can help you. Wayferry is an independent consulting firm specializing in software and ERP evaluation and selection.