Technical vs. Human: The Bane of ERP Selection
I recently saw a thread in the ERP Community Group debating the merits (or lack thereof) of an RFP (Request For Proposal) as a tool in the ERP selection process. The feedback, including my own, was overwhelmingly in favor of forever doing away with the RFP process and securing it away in a special circle of Hell. But that led to me pondering what REALLY matters then during the ERP selection process?
- Is it features and functions?
- Is it having a slick demo?
- Is it having a "yes" answer for every item listed on an RFP?
- Is it the pricing model of the software?
- Is it meeting industry specific needs out of the box?
- How about having a really slick interface or being a household name?
The answer to all of those questions is a solid maybe. Sure there are going to be certain ERP applications that excel in one are over others but might also be somewhat deficient in another area. Some are on-premise while others are hybrid and some are SaaS. And if you have a small budget vs a huge budget that's going to narrow the search. So with all the big things aside, you're still looking at probably 5-10 very viable solutions even after you answer all of those questions. So what next?
The harsh truth is that most ERP systems competing in a specific space are going to pretty much work the same. And this can make the selection process even more difficult because before you know it all the literature and demos and conversations with sales people all start to run together. Any ERP is generally going to have finance and distribution and probably some document management and CRM capabilities. So when wadding through the quicksand of a selection process how to you decide which way to go?
I know your next question: When is this guy going to stop asking questions and start giving some answers?!?!?! Well, here we go!
This is where I think people and relationships are exponentially more important than the technical nuts and bolts. Rather than creating 30 page RFPs and sitting through day long demos, meet with the people that will be implementing your solution. Learn about their experience and history in the business and ask about their implementation methodology. Have a conversation about the intricacies of your business and how they will utilize whatever technology selected to solve those challenges. Build a rapport and then make your selection based on which team demonstrates the ability to solve problems and provide creative solutions and not just the ability to fill out forms and sell software.
--------------------------------------
About the author:
David Dozer is an ERP professional that has worked in different facets of the industry ranging from IT Management, Quality Assurance, Accounting, Consulting Services and ERP Product Management. Currently, David is a Senior Business Consultant at Algorithm Inc.
See other articles:
CEO at Jonar and CIO at ParagonERP
7 年Great article. As a company marketing a new approach to ERP we recently decided to politely refuse answering RFPs because we agree with most of the above.
We help companies replace obsolete ERP while avoiding new software that doesn’t support achieving business goals.
7 年The objectives of an ERP selection are 1) Discover all requirements, including unknowns 2) Select the software that meets your requirements "like a glove fits your hand." 3) Design the evaluation to collect critical information needed for a successful implementation (on time, within budget, minimal business disruption). Relationships are always important, but the key to success is a robust selection process, which provides the foundation for a successful implementation. The reason why ERP implementations are always late is that buyers don’t do their homework and keep on finding “new” requirements. Dealing with too many “new” requirements takes time, which makes schedules slip and costs increase. In an effort to minimize schedule slip things are left for “phase 2” which is what causes business disruption when going live. While it is not nearly enough, at least an RFP forces users to start thinking about their requirements.
Taking a break from Linkedin; but I'm an ERP observer, blogger and author. Please contact me if you think that I might have knowledge that is useful to you.
7 年At the risk of being accused of playing with the Queen's English; the major problem that I have seen with RFPs is that they describe what companies want to do, and not what they want to achieve. So they describe in detail they way companies currently work and any alternative that is not a carbon copy match counts as a 'fail'. Then companies complain that they have not benefited from their investment in a 'new' system.
Independent Acumatica Consultant & TRAILD Software Ambassador - #Acumatica #ERP #CloudERP #TRAILD
7 年Totally agree, especially with "people and relationships are exponentially more important than the technical nuts and bolts." If you read any client success story from an ERP vendor, you can usually sense that the implementation partner played the key role in the success, not the software itself.
Passionate Leader | Finance Transformation | Operational Improvement | Rugby Mum
7 年In my experience doing a upfront requirements gathering with the client lays a good foundation to make sure you understand the clients needs and can take those recommendations to the the vendors.