Project Management optimize

How to make an ERP selection

If you've made the decision to implement an ERP, be aware that the selection process could take months. Mark Pimperton talks about the stages his company went through.

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:

  1. 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.
  2. 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:

  1. Identify the business processes that take up most of your time.
  2. Analyze the problems, inefficiencies or opportunities for improvement in these processes.
  3. 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 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 ...

3 comments
mdwalls
mdwalls

Your approach to requirements gathering and specifying functional requirements is exemplary. But in my consulting experience guiding large IT system selections, let me add: -- Remember "nonfunctional" requirements like using your server OS, RDBMSs, support for architecture choices like virtualization, etc. -- Get the vendor to describe in some detail their implementation process, with emphasis on what they will do and what they expect you to do. Get a schedule. -- Get the vendor to describe how they will handle the transition from your existing systems to the new ERP. Get commitments on data migration, training, and change management. -- Get all their promises in writing, as part of the contract. Use the contract elements for a checklist of deliverables. Use the functional & nonfunctional requirements as a framework for acceptance testing. Implementing a system like an ERP is a major undertaking. You and the vendor should treat it as a major project, with formal project management and due attention to all the details. Otherwise you get essentially a box of install disks and a large bill.

rhonin
rhonin

- do a bit more under due diligence. 1 - Find a competitor or similar business that runs the ERP package(s) you are looking at. Ask them if you can benchmark or at least get a "lessons learned" from them. 2 - Ask yourself how good are your processes and procedures. Are they industry standard or home grown. 3 - And last, based on the demo, get the vendors opinion on how well they can handle unique or exception processes. In the end the single biggest question that makes or breaks an ERP project is number 2 once you decide on the vendor.

mark1408
mark1408

I agree this is the time to evaluate your existing business processes and not just set out to replicate what you already do. It's a mistake we made, at least in part. However, I don't know what an industry-standard procedure is, as surely every company is unique? Your point 3 should be taken care of by your functional spec and the scripted demo. What we also found, though, was that suppliers weren't always transparent about what was standard software and what had been specially bespoked for the demo!