Inconsistent and opaque ERP software pricing is part of the game. Most vendors hide their list prices from all but the most serious of prospects who submit a request-for-proposal (there are a few exceptions, including Microsoft, Salesforce, and Oracle).

This veil of secrecy prevents buyers from doing any meaningful upfront pricing work. The vendors feel that if they can get an ERP selection committee’s emotional buy-in to their products, they won’t have to worry about pricing.

Further complicating ERP buyer’s lives is the fact that no two vendors price the same way. Some price by module, others by whole package. Some price by named user, others by concurrent user. And, some cloud vendors price relative to the amount of cloud capacity the prospective customer will use. In most cases, alternative pricing models are available: unlimited users or fees relative to some company metric, such as: revenues, employee count, COGS, among other things.

Given all of this complexity, ERP buyers can still take steps to gain meaningful pricing information during the early stages of a selection project.

In this post, I focus on helping the ERP buyer narrow the potential variance between projected and actual ERP acquisition costs.

Getting the Vendors the Information they Need

The buyer first has to understand that acquiring an ERP package is more like buying a build-your-own pizza than buying an all-dressed pizza. In the cases of the build-your-own pizza and ERP, the final price is heavily influenced by the selection of toppings. With respect to ERP, the pricing reflects the way that the system is assembled, configured and customized to the buyer’s needs. The ERP core application is the pizza crust. Software customizations, add-on modules, and third-party software applications are the toppings.

The buyer’s first task, therefore, is to help the ERP vendor figure out which toppings to include. The buyer does this by providing the vendor with a list of its functional and technical needs. In my previous post, ERP Selection: Three Steps to Analyzing Functional Needs, I explain how to develop such a list.

Though a specifications list is necessary, it is far from sufficient. To illustrate, allow me to stretch the pizza analogy a little further than it should probably go. Just as a pizza parlor would be unable to price a pizza based on toppings information alone, an ERP vendor would be unable to price its solution based on a specifications list alone. In the pizza case, the parlor would need to know the size of the order. In the ERP case, the vendor would need to know capacity of the system. ERP capacity is generally measured in terms of user licenses.

The buyer’s next task, therefore, is to project the number of system users. The first thing that the buyer needs to note is that there are generally two types of ERP user licenses: concurrent and named. Concurrent licenses refer to the number of users that are allowed to use the system at any one time. Named licenses, meanwhile, refer to specifically dedicated people who are authorized to use the system.

Some vendors price their 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 critical for pricing purposes. For example, consider the case of an ERP buyer that projects 45 concurrent ERP users but fails to account for named users. An analysis of various proposals leads the buyer to a select what it thinks is a reasonably priced ERP solution. However, the buyer has failed to realize that the selected vendor has priced its software on the basis of named users. The buyer has also failed to realize that it has a 3:1 named-to-concurrent user ratio. Consequently, the ERP buyer has unwittingly selected a system with licenses costs that could exceed projections by 300% should the buyer decide to acquire all required licenses.

As a further tip, the buyer should ask the vendors to price multiple user scenarios. The buyer’s projected ERP capacity might evolve as the scope of the ERP project crystallizes. Since different vendors offer different pricing discounts at different capacity levels, the buyer wants to make sure that it is has considered how different users scenarios could impact its costs. For scenario planning purposes, the size of the user increments should be somewhat relative to capacity needs. For example, a buyer who projects 45 concurrent users might submit scenarios in increments of 5 to 15 users. Meanwhile, a buyer who projects 200 concurrent users might submit scenarios in increments of 20 to 40 users.

Analyzing Pricing Proposals

Once the buyer has submitted its specifications and user scenarios to the various ERP vendors, the buyer has put itself in a position to receive meaningful pricing proposals. Though there are no guarantees that the vendors will oblige, most tend to respond with useful pricing information.

Even assuming that the buyer might have received useful information, its pricing work is far from complete. The submissions are unlikely to be in a form that permits vendor-to-vendor comparison. The first thing that the buyer will probably note is that each vendor has unique packaging and pricing methodologies. For example, one vendor might have a seemingly lower core module cost, but might have priced 15 or 20 add-on modules. Another vendor, meanwhile, might have priced a more expensive core module, but with only four or five add-on modules.

The buyer’s next task, therefore, is to reorganize each of the responses into a format that permits apples-to-apples comparisons. For each of our clients, we create a customized pro forma Statement of ERP Costs. In these pro formas, we aggregate each vendor’s line items into common categories and sub-categories that 1) are relevant to our client, and 2) that apply to all vendors. For example, in the license cost category, we might have line items for the following: core license, vendor add-on modules and 3^rd-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). The following spreadsheet extract shows a samplepro forma Statement of ERP Costs:

[image]

When analyzing the pricing submissions, it is critical for the buyer to dig deeply into the vendors’ numbers. It cannot blindly rely on the vendors’ pricing quotations. In many cases, the vendors’ assumptions are based on an incomplete understanding of the buyer’s needs.Each of the line items in the above table represents a calculation. For example, the line item for Vendor Module in the License Costs category is the sum total of the module costs.

In the example above, the buyer had to adjust the vendor’s pricing for the HR module, which amount is subsumed in the Vendor Module line item. The vendor priced this module according its assumption that the buyer would need eight users. The buyer, however, only requires five HR user licenses. It adjusted the proposed pricing accordingly. The buyer also recorded the adjustment in the Notes and Assumptions section. In this section, the buyer should track all adjustments and assumptions. Effective use of this section helps the buyer avoid having to comb through the original vendor submissions to: 1) find reasons behind certain adjustments; and 2) understand the vendor’s assumptions.

The HR example is one where the buyer was capable of making the adjustment with the information it already had. There will be other situations where the buyer will need to go back to the vendor for additional information.

Once all of the adjustments have been made, the buyer has put itself in a position to perform an apples-to-apples pricing comparison. Its next step, therefore, is to compare the prices at different time intervals. At a minimum, pricing comparisons should be performed for Year 1 and for an assumed period that covers the system’s lifespan. This latter period is generally assumed to be 10 years and is the costs incurred over this period reflect the total cost of ownership.

Buyers need to perform a total cost of ownership analysis because the relative costs of different systems might change over different periods. Ranking changes can usually be explained by the costs associated with annually recurring maintenance and support obligations. Every year, an ERP buyer will typically have to pay maintenance and support costs that are equal to 16% to 22% of total, undiscounted license costs.

Your R.E.Q (Relevant Experiences and Questions)

• With respect to license costs, what caused the variance between your organization’s initial ERP pricing projections and the actual costs?
• What tips can you offer with respect to the assessment vendor pricing proposals?
• How have you worked with ERP vendors to obtain relevant pricing?

Substantially similar to version published by Manufacturing AUTOMATION on October 26, 2010
Published by Software Advice, cited on SupplyChainBrain