Selecting an ERP solution

This is a cross-post from the SYSPRO SmarterERP blog

Whether you call them RFIs, RFPs, RFQs* or some other acronym, and whether you are a vendor or a customer, those three letters conjure up the same impression in many minds – pages and pages of detailed questions about a software product’s functionality, which takes weeks to create, days to respond, and weeks again to review.

Frankly, no one likes these documents, but businesses evaluating ERP software keep producing them, and vendors keep responding. Isn’t there a better, more efficient, ‘leaner’ way? According to one view:

Regardless of how many consultants a client uses to select software, many would have been far better selecting out of a hat.

The people who see value in ERP selection documents are the consultants whose job it is to create those documents. I know of cases where the client didn’t really understand the reason and the purpose of several questions. I have also been on a project where literally hundreds of selection questions were used, but once the implementation started those questions – and the answers – were effectively forgotten.

The now undeniable truth is that the selection of software plays little part in the final success or failure of an ERP project. What makes the difference during selection is addressing the real questions.

  • Has the organization identified the major business challenges that they want the ERP system to address, as well as the key business drivers the ERP system must support?
  • Are the business processes which operate in the business clearly understood and defined, and how should the ERP software assist or improve those processes?
  • Have executives clearly communicated the reason for, and objectives of, the ERP project to the rest of the enterprise, and more importantly, have they taken the time to get buy-in from the staff?

If those questions can be answered, here is an alternative process for selecting an ERP system:

  1. Check with other organizations, or industry groups, what ERP software deployment they know of, and their experiences around it.
  2. Do some of your own research. These days a bit of time using a search engine, and looking for some relevant blogs can give you a reasonable idea of issues in the ERP world.
  3. How do the vendors you have now identified articulate the direction and focus of future functionality in their product roadmaps, and is that consistent with your organization’s goals and plans?
  4. How are the vendors represented in your area? Do they have a local presence for training and support? What is the quality and quantity of skilled resources the vendor or reseller have available in your area?
  5. From the list you have now created, invite the vendors or their resellers to present to you. Provide them with some key requirements you need in an ERP and ask them to do a live demonstration or proof of concept using their software. Do they show an understanding of your business and its key issues? Can they show proven functionality in areas that concern you specifically? Lastly, what will it all cost?

The result of this process will be a few vendors with proven understanding and experience, who can then be engaged in more detailed negotiations. You might also ask these vendors to summarize in writing how their proposals address your key requirements. The vendors who understand the business issues should not only do a good summary but may also give you additional ideas you hadn’t thought of.

The key point is – don’t sweat the small stuff; avoid getting into too much detail on small issues of functionality. Focus on the important issues of the business and how the ERP software will allow you to improve them. No ERP system will address every single requirement perfectly, so make sure the ‘must have’ requirements are met.

Let me know if you have other ideas for selecting an ERP solution.

* RF = Request For. I = Information. P = Proposal. Q = Quote


2 thoughts on “Selecting an ERP solution

  1. You are perfectly right when you say that companies looking for software need to “make sure the ‘must have’ requirements are met”. But, they don’t always know what functionality they need and/or they don’t know how to phrase it in the vendor’s language.

    In other words, if you don’t have detailed RFIs to choose criteria from, companies may create lists o requirements that are too general and all vendors will claim to support them. They will also create demo scripts that are not detailed enough to show them the essential functionality for their business.

    In conclusion, i think it’s better to gather thousands of lines of responses from vendors and then focus on the criteria that you need most, than send them general requirements and then try to understand the details that matter to you.

    So my advice is: get as much details as you can, but make them demonstrate only the ones that matter to you.

  2. Thanks for the input. My issue is that when I’ve worked with companies, usually small- and mid-size ones, that have had RFI with hundreds of questions, they have got bogged down in the detail – they miss the forest for the trees – and then wonder why the project goes awry. On the other hand, I’ve seen a few companies that took the route I mentioned, and they seemed more able to identify where value was in a solution and make use of it.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s