We have prepared an analysis of ERP systems on behalf of CPA Magazine and issued surveys to all the ERP vendors we know, collated the results and wrote an accompanying article.
ERP Comparison Chart
We have over 100 different systems and over 500 different questions in our ERP Comparison report. Click here to get the 2017 ERP Comparison report.
ERP 2017 Article
Welcome to our annual vendor survey on enterprise resource planning (ERP) software. Each year we have a different theme for the article that accompanies the ERP survey results. This year the theme is the fine print in ERP contracts and the good, bad and ugly about Requests for Proposals (RFPs) used in software selection.
Our survey includes over 100 systems and over 500 questions about target market, geographical and industry support, generic features, business intelligence, financials, budgeting and forecasting, fixed assets, distribution, manufacturing, professional services, construction, service management, human resources, document management, CRM and eCommerce.
As with all our surveys, it can be challenging to validate the information supplied to us by the vendors. Fortunately, it is in the best interests of vendor’s to provide honest and truthful responses as ultimately their credibility is at risk if the representations made are deemed to be false or misleading.
The ERP systems have been segregated into tiers based on customer revenue, employees and product cost. This is a convenient, albeit not perfect, means of differentiation. We caution against using this information to calculate the costs for a specific system, since these numbers reflect averages from the survey population.
|Tier 1||Tier 2||Tier 3|
|Customer revenue||> $200M||$10M – $200M||< $10M|
|Customer employees||> 500||50 – 500||< 50
|Licence fees||> $300K||$50K – $300K||< $50K|
|Implementation fees: Licence fees||> 2:1||1:1 – 2:1||< 1:1|
The Fine Print
The fine print is not something you find until the very end of a long software selection process; and by that time, many organizations are weary and eager to complete the process expeditiously. ERP vendors know how to maximize their profits and minimize risks in their contracts and fine print so it’s important that you pay close attention to the details at this stage in the negotiation. Let’s start with the license.
You may have a hard time getting an ERP price per user license from the vendor who would prefer to give you a total price without a breakdown. You should not only know the current ERP user license fee but also know what it will cost in the future as you will likely grow and need more licenses. Mid-market ERP systems average about $3,500 per concurrent user but that price will vary based on the number of users and the software functionality required. A rule of thumb for the annual cost of hosted or SaaS (Software as a Service) ERP systems is that on average the one-time (on premise) license fee is 3 times the SaaS annual fee, One might think that the ratio between license and annual fee should be greater, but that does not take into account the additional hosted services provided by the SaaS vendors or the maintenance fees which are billed annually by on premise vendors at approximately 20% of the license fee. It’s still early days for SaaS and as competition heats up the license to annual fee ratio will increase.
Vendors could also charge as much as a 6% increase in license fees per year whereas a cost of living increase or a capped 3% increase would be more tolerable. Ideally you should get the vendor to freeze the price for a number of years. Another big-ticket item is maintenance but the vendors are less likely to negotiate this as it represents their primary source of income. You should endeavour to have the maintenance % based on the net price (after discounts). Some vendors include support while others just include software enhancements and bug fixes with support being an additional cost as you use it. You also need to know the level of support included, for example, the length of time to respond and to resolve problems.
The implementation contract, often called the Statement Of Work (SOW), can be even more tricky than the user license agreement. The first and most important concern is a definition of scope. The vendors like to provide a very high-level definition but you should get them to link it to the requirements in the RFP. Beware of assumptions linking their estimate to the implementation of what they consider best practice which will cause a problem if you have any requirements that are different than what the vendors call best practice, which could be for smaller or larger customers or for industries not quite the same as your industry that do not include any of your unique requirements. You should know how much time is allotted to the main tasks such as training, testing and project management so that you can compare the estimates to each other and get a sense of which vendor might be underestimating their quote. It’s also good to get their time estimates by module. Once you have these estimates, make sure that they will issue bi-weekly or weekly reports that show the budget compared to the actuals plus estimated time to complete by task. This way, you will know in advance when there is a problem and may be able to do something about it before it’s too late. One way to limit the risk on implementation is to have the vendors conduct a business needs analysis before the finalization of the contract so that you and the vendor will have a very clear understanding of the implementation scope and costs in advance. This was discussed in last year’s article (see below)
Contract negotiation should also include a discount of rates which usually range from $175/hour to $200/hour. Be sure to check the fine print on how much that rate can go up each year. Last but not least, look carefully at roles and responsibilities which are usually included in the SOW. Make sure you understand what the vendors are suggesting and that you have the ability to do it. For example, you may be responsible for documenting design of the new system or preparing test plans, and this may be something you know nothing about or lack the appropriate resources to complete.
The Good, Bad and the Ugly about RFPs
The good – The RFP which contains the requirements should be the most important document in the software selection process. It is used to select which vendors to participate in the demonstration. It should be used in the demonstrations to make sure they can do what they said they could do. And it should also be used in the contract to define scope.
The bad – Some organizations and consultants rely on massive requirement checklists for their RFPs. These RFPs may not address the most important requirements as the requirements are not based on a business process review (BPR). A BPR will identify requirements based on what the existing system does and the new system should continue to do. Requirements are also based on applying best practice to the problems that are identified in the BPR. Once the BPR has been completed, next it is a good idea to use RFP templates to determine if any significant requirements were not already covered. The massive templates can also scare off good vendors because of the time it takes to respond to it, and the impression that potentially the impression that the needs of the organization are overly complex.
The ugly –- Unfortunately, requirements are often not defined well or not at all. Requirements should be clear, unambiguous and address what matters most to an organization. The requirements should also be prioritized. Some organizations take short cuts believing that if a system can work for leading organizations in their industry, then it will work for them too. This is a recipe for a lawsuit when things do get ugly.