ERP pricing: A guide to avoiding sticker shock
October 26, 2010
By Jonathan Gross
On a recent ERP system selection project, our client eliminated a functionally competitive ERP software package because of its disproportionately high price tag. In fact, our client dismissed the manufacturing and distribution ERP package during the first round of cuts, before the vendor was even given a chance to perform a live software demonstration.
The point of the story is that ERP value – like most things – is partially judged in relation to cost. Even though most ERP buyers appreciate the importance of cost, many fail to give it the treatment it requires. The general result: unexpected sticker shock.
In most cases of "mystery surprise" pricing, an impartial observer could not be faulted for laying blame both on the ERP vendor and on the buyer. More often than not, the vendor can be blamed for maintaining opaque pricing practices that preclude meaningful up-front research. Very few vendors publish their list prices. Many buyers, meanwhile, can be blamed for not giving the vendor sufficient information from which to prepare a meaningful pricing proposal. They can also be blamed for not doing enough good analysis on the vendor responses.
The purpose of this article is to help empower ERP buyers to make better-informed buying decisions. It is primarily focused on vendor pricing practices relating to ERP licenses.
Getting vendors the information they need
When an organization acquires an ERP system, it is getting something that is, in many ways, unique. The uniqueness reflects the way that the system is assembled, configured and customized.
An ERP buyer needs to understand that the vendors cannot deliver useful proposals without understanding its unique combination of needs. It would be akin to ordering a build-your-own pizza without identifying the toppings you want.
Much like the build-your-own-pizza model, an ERP vendor starts with a core application. Then, it adds toppings in the form of software customizations, add-on modules and third-party software.
The buyer’s first task, therefore, is to develop a list of basic ingredients that allows the vendor to price a complete ERP solution. The list of ingredients should be made up of actual functional and technical needs. In my article, ERP selection: Three steps to analysing functional needs, I explain how to develop such a list. Only once this list is delivered to the vendor will it be in a position to determine the best mix of applications and customizations.
Now, bear with me while I stretch the pizza analogy further than it should probably go. Just as a pizza parlour would not be able to price a pizza based on toppings information alone, a vendor would not be able to price an ERP solution based on specifications information alone. In the case of the pizza parlour, the missing information is size. In the case of the ERP vendor, the missing information is capacity.
In ERP terms, capacity refers to the number of licensed users. The buyer’s next task, therefore, is to project its ERP users. A word of caution to the buyer: user licenses come in two forms – concurrent and named. Some vendors price licenses on the basis of concurrent users, while others do so on the basis of named users. There are even some that offer both alternatives.
Distinguishing between user types is important because most buyers do not have a 1:1 ratio of concurrent-to-named users. In terms of definitions, concurrent licenses refer to the number of users that are allowed to use the system at any one time. In contrast, named licenses refer to specifically dedicated people who are authorized to use the system. Given different vendor licensing practices, the buyer is advised to project both concurrent and named users.
The buyer would also be well advised to have the vendors price multiple user scenarios, because the real future might be different from the projected future. Any variance between actual and projected user counts could affect relative pricing, because different vendors have different ways of pricing license increments.
Analysing pricing proposals
After submitting its specifications and user scenarios, the buyer has put itself in a position to receive meaningful pricing proposals. Though there are no guarantees that the vendors will oblige, most vendors respond with useful pricing information.
Even if the responses do contain useful pricing information, the forms in which they are received are generally not conducive to comparative analysis. The buyer’s next task, therefore, is to reorganize the responses into a format that permits "apples-to-apples" comparisons (whether manually or by automated program).
For each client, we create a customized pro forma Statement of ERP Costs that we use to analyse each vendor response. For each vendor, we aggregate the line items into common categories and sub-categories. For example, in the license cost category, we might have line items for the following: core license, vendor add-on modules and third-party software. We might also have line items to highlight the costs of non-standard high-priority items (e.g. shop-floor data collection licenses).
Once all of the responses are entered into the pro formas, we make whatever pricing adjustments are needed to perform an apples-to-apples comparison. In some cases, the vendor has given us sufficient information to make the required adjustments. In other cases, we need to ask the vendor to re-price certain items based on a different set of assumed circumstances.
Once all of the adjustments have been made, the buyer has put itself in a position to perform an "apples-to-apples" comparison. In terms of relevant time periods, the analysis should, at a minimum, be performed for Year 1 and for an assumed system lifespan period. The costs over a system’s expected life are known as the total cost of ownership. For ERP systems, we generally assume a 10-year total cost of ownership period.
This 10-year total cost of ownership analysis is a must because the most significant ERP costs are typically in the form of recurring annual maintenance costs. Every year, the buyer generally pays maintenance and support costs that are equal to 16 to 22 percent of total, undiscounted license costs.
In my next article, I intend to delve deeper into these maintenance annuity obligations, and offer some tips on negotiating more favourable terms. In the meantime, I hope that this article has provided you with helpful tips to guide you on your ERP selection project.
Jonathan Gross is vice-president of Pemeco, Inc., a consulting firm specializing in ERP selection and implementation. He can be reached at email@example.com.