First of all, do you actually need ERP (or just "joined-up business software" as I like to think of it)? If you need convincing, I suggest that you:

Take an audit of your current information systems and business processes. Do you have multiple systems? Or duplicate data entry? Do you rely on spreadsheets or databases on individual PCs? If so, the chances are that you could benefit from ERP.

Do some reading. A search on "Does a small company need ERP?" will lead you to supplier-specific articles but also general reviews and advice like this or this.

(As I said recently on this forum, if you asked most people at my company the question would be "Why would you NOT want it?". But that's easy for us to say - we've been using it (in various guises) for 20 years.)

Having made the decision to go for it, expect to spend several months on your specification and selection project. In our case, it took about 12 months from inception to signing a contract, but you might well be able to do it much faster. What matters more are the stages you go through to arrive at your choice. Here are the ones we used.

Requirements gathering

At every level from shop floor to manager to director, we asked for input. Directors were asked to provide strategic input, highlighting specific aims or directions for the company. Other staff were simply asked for their opinions on the current system. The majority, however, were asked to think in terms of business processes. We asked them to do three things:

Identify the business processes that take up most of your time.

Analyze the problems, inefficiencies or opportunities for improvement in these processes.

Describe the benefits of changing the process.

The end result was a lengthy User Requirements Document, broken down roughly by business area. From this we distilled a Project Benefits Document highlighting the key areas of improvement. (Both of these are essential reference points when you're embroiled in an implementation and can easily forget what it was you set out to achieve!)

Pre-qualification

Based on our existing knowledge and Internet searches we drew up a list of 18 possible suppliers. We emailed them asking if they wanted to receive a brief questionnaire as the first stage of a selection process. The questionnaire was based on our Project Benefits Document and invited the suppliers to tell us about their company, their product and how it would help us achieve our hoped-for benefits. 15 suppliers responded.

Request for proposal

Our RFP documents were unashamedly adapted from templates we found on the Internet. The end results were:

A Word document giving a detailed description of us, our project and our current system, together with information on how the RFP process would work.

An Excel spreadsheet with tabs for supplier information, references, prices and, most importantly, a detailed functional specification covering every area of the system.

The functional spec is critical. Break it down by business areas such as general ledger, accounts payable, purchasing, sales order processing, stock control, etc. Within each area list what you need the software to do. For example, in our Stock Control section we included the following:

Supports the recording of actual cost by product

Supports user-defined Unit of Measures (UOM)

Supports multiple inventory locations and bins per warehouse

For each criterion we labeled it as Essential or Desirable. The supplier then had to respond with a code indicating how far their system met the requirement (or not). We also gave them a column to enter free text comments.

We allowed the suppliers to send supporting documentation but were insistent that they complete our spreadsheet in detail. We resisted supplier requests to come and see us at this stage.

Having received five responses to the RFP, we used a further spreadsheet to aggregate the scores and give us an overall picture. Based on the functionality score and the price, we put three of the five through to the next stage.

Demonstrations

Finally we allowed suppliers to come and see us! But this was not the standard sales presentation; we again required them to demonstrate the product against our specific requirements. We created a script based on our functional spec and expected them to follow it. For each criterion in the script we had staff assigning scores according to whether the product fitted the bill - and how easy it looked to use. The idea was again to try to make the comparison objective as far as we could.

This stage eliminated one supplier and we actually had the other two back for a second visit to look at specific areas of concern.

Selection and due diligence

In the end it was a close-run thing between the final two. And, it has to be said, we deliberately allowed subjective opinion to creep in. No matter what the scores and prices told us, there was still an element of gut reaction involved in the final choice. Nevertheless, we could say with some pride that the process was rigorous and systematic. (Apart from anything else, this is a comfort when we hit problems and somebody asks why we chose this particular system!)

The very last stage was that of "due diligence" - checking out the preferred supplier by reviewing their accounts, and visiting or speaking to existing customers.

We negotiated a deal, signed a contract - and then the fun began!

Summary

Choosing an ERP supplier is about the software and about the supplier. Run a systematic selection process to find the product that best meets your needs. It won't be perfect but you'll greatly increase your chances of a successful implementation and reaping the benefits for your business.

About Mark Pimperton

Mark Pimperton BSc PhD has worked for a small UK electronics manufacturer for over 20 years in areas as diverse as engineering, technical sales, publications, and marketing. He's been involved in IT since 1999, when he project-managed implementation ...

Full Bio

Mark Pimperton BSc PhD has worked for a small UK electronics manufacturer for over 20 years in areas as diverse as engineering, technical sales, publications, and marketing. He's been involved in IT since 1999, when he project-managed implementation of a new ERP system, and has been IT Manager since 2008. The first major project he undertook in that role was a second ERP deployment. While still involved in operations, system management, and even a bit of development, Mark is now also responsible for IT risk management. He finds that risk assessment leads to many improvement initiatives, such as a current project to switch from tape backup to disk-based and online backup. Mark is fanatical about documentation, taking special care to record unfamiliar processes. His TechRepublic articles on SSL certificates and PCI DSS compliance are prime examples. Mark is married with two grown-up children.