Welcome once again to our annual vendor survey on enterprise resource planning (ERP) software. Every year we have a different theme for the article that accompanies our ERP survey results. This year we decided to look at the fine print in ERP contracts and the good, the bad and the ugly about requests for proposals (RFP) used in software selection.\nTHE CHARTS\nOur survey includes more than 100 systems and more than 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 e-commerce.\nThe survey results are available both in pdf form and in the form of a handy chart that allows you to compare up to three products at a time. You can also complete an online survey and then view the 10 best ERP systems for your needs based on percentage fit calculations available at http://www.180systems.com/tools/systems-analysis-tool/erp/. \nAs 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.\nTIERS\nThe 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.\nCRITERIA\n\n \n \n \n \n \n Tier 1\n \n \n Tier 2\n \n \n Tier 3\n \n \n \n \n \n \n Customer revenue\n \n \n > $200M\n \n \n $10M - $200M\n \n \n < $10M\n \n \n \n \n Customer employees\n \n \n > 500\n \n \n 50 - 500\n \n \n < 50\n \n \n \n \n Licence fees\n \n \n > $300K\n \n \n $50K - $300K\n \n \n < $50K\n \n \n \n \n Implementation fees: Licence fees\n \n \n > 2:1\n \n \n 1:1 - 2:1\n \n \n < 1:1\n \n \n \n\nTHE FINE PRINT\nYou don’t really need to deal with the fine print until you reach the very end of a long software selection process; and by that time, many organizations are weary and eager to complete the process. ERP vendors know how to maximize their profits and minimize risks in their contracts so it’s important to pay close attention to the details at this stage of the negotiation. Let’s start with the licence. \nYou might have a hard time getting an ERP price-per-user licence from vendors; they would prefer to give you an all-in price without a breakdown. Not only should you know the current ERP user licence fee, but also what it will be in the future, as you will likely grow and need more licences. 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 licence fee is three times the SaaS annual fee. Vendors could also increase licence fees by as much as a 6% 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. \nAnother big-ticket item is maintenance but vendors are less likely to negotiate this item, because it represents their primary source of income. You should try to have the maintenance percentage 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, time needed to respond and resolve problems.\nThe implementation contract, often called the Statement of Work (SOW), can be even trickier than the user licence agreement. The first and most important concern is the definition of scope. 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. This will cause a problem if you have any requirements that are different from what the vendors call best practice. Theirs might be for smaller or larger customers or for industries that are not quite the same as yours and 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 you can compare the estimates with each other and get a sense of which vendor might be underestimating its quote. It’s also good to get the vendors’ time estimates by module. Once you have these estimates, make sure the vendor will issue bi-weekly or weekly reports showing 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 vendor 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. \nContract negotiation should also include a discount of rates, which usually range from $175/hr to $200/hr. 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 that you understand what the vendors are suggesting and that you have the ability to do it. For example, you may be responsible for documenting the 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.\nTHE GOOD, THE BAD AND THE UGLY ABOUT RFPS\nThe 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 will 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. \nThe bad: Some organizations and consultants rely on massive requirement checklists for their RFPs. These RFPs might 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 potentially the impression that the needs of the organization are overly complex.\nThe ugly: Unfortunately, requirements are often poorly defined or not defined at all. Requirements should be clear, unambiguous and address what matters most to an organization. They should also be prioritized. Some organizations take shortcuts believing that if a system can work for leading organizations in their industry, it will work for them too. This is a recipe for a lawsuit when things do get ugly.