Welcome to our annual vendor survey on enterprise resource planning (ERP) software. Our survey now includes 100 systems. When we launched the survey back in 1999, most people had never heard of ERP – and it was geared for large corporations. But the technology has now become mainstream and is being implemented by both small and large organizations in all industries. Also, ERP used to be installed on the company’s premises and required strong IT support. Today, cloud computing has also become mainstream, making it possible for smaller organizations to implement ERP without worrying about networks, databases or even security. (See Cloud security: fact or fiction? for more about cloud security.)\nThe charts\nOur attached vendor list contains hundreds of questions about target customers, cost and ERP features. The results are available both in pdf form and in the form of a handy chart that allows you to compare up to four 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/. As with all our surveys, we were unable to validate the information supplied to us by the vendors. However, we don’t think there will be that many intentional mistakes, partly because the vendors will lose credibility if they are caught making false claims.\nTiers\nThe ERP systems have been segregated into tiers based on customer revenue and employees and product cost. This is a convenient, albeit not perfect, means of differentiation. Be cautious if you’re trying to calculate the costs for a system, since these numbers are just averages.\nCriteria\n\n \n \n \n \n Tier 1\n \n \n Tier 2\n \n \n Tier 3\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\nSOFTWARE SELECTION\nWhatever type of ERP system you are looking for, it’s always useful to have a roadmap for the process. In CAmagazine, one of CPA Magazine’s legacy magazines, we published a four-part series called “System selection done right” in 2012 (see attached pdfs).\nSystem selection, done right — Part 1\nSystem selection, done right — Part 2\nSystem selection, done right — Part 3\nSystem selection, done right — Part 4\nOne best practice discussed briefly in the second part was a paid consulting engagement (business needs analysis) with the vendor.\nBusiness needs analysis\nYou naturally want to minimize risks and avoid cost overruns before signing a long-term contract for a new ERP system. Your prospective vendor also wants to minimize risk, but is usually not able to do more than give an implementation estimate based on assumptions about scope, roles and responsibilities. These assumptions could be fairly accurate, but could also be way off, which could lead to surprises and costly change orders. Neither you nor the vendor wants this to happen. For the vendor, you could turn into an unhappy client who cannot be referenced, or even worse, one who wants to abandon the project.\nThat’s why it’s worth considering a pre-contract business needs analysis. A BNA provides the vendor with more detailed information about your environment, information it can use to firm up its understanding and provide a fixed fee for the implementation. In the absence of a BNA, this work would normally be done by the vendor during the implementation, after the contract is signed.\nThe more thorough the BNA, the lower the risk. One approach is to identify the requirements that are the most challenging and/or unique and make sure the vendors understand them so they can figure out how to handle them in detail before the contract is finalized. Although the vendors charge for their time to complete the BNA process, they would be charging for this time during the implementation anyway, and by doing the work upfront, they can integrate the risky parts into the implementation contract and reduce the likelihood of surprises.\nA BNA should include:\n• Implementation scope linked to requirements in the RFP\n• Conceptual design with agreed-upon design decisions\n• Functional specifications for any requirement requiring customization\n• Statement of work, which includes costs, scope, roles and responsibilities of vendor and customer and timelines.\nThe vendors might resist – they might want to just close the deal or might be reluctant to assign resources to a client that may not sign a long-term contract. But if the risks are high, both vendor and client are protected using the BNA approach.