ERP software has matured over the years thanks to standardization and improvements in technology. The difference between products is sometimes so fine because it’s universally expected that products deliver a minimum set of capabilities out-of-the-box. The question is no longer if a software package delivers a solution but how the product solves the problem.
For example, every distribution company expects an ERP solution to provide Sales Order and Fulfillment capabilities. So, the focus has shifted from if the feature/function exists to how a salesperson might enter an order, document exceptions, access information; and then moving through the warehouse pick, pack, ship fulfillment process flow. Buyers today are now focused on:
Therefore, I suggest that the buying criteria today is more subjective than ever. Let’s face it, during most software selections, buyers can narrow down the field of finalists to 2-3 software packages and randomly select one, knowing that it will deliver the majority of capabilities required. But, the questions are more about ergonomics now.
Accepting the fact that buyers may not select us simply because they don’t like the look and feel of the software package is difficult but we’ve adapted our approach accordingly. Of course, a successful evaluation starts with a complete discovery of a prospects’ business requirements, processes and team. Then, we walk through a brief overview of the solution explaining how an end user would navigate through the product, access critical information and define routine tasks. Next, during a proof of concept presentation, we focus on the usability of the software so the audience has an appreciation for how they will perform their daily activities. Finally, we conclude with the personalization capabilities of the software that help complement the business processes and unique requirements a prospect may have.
I recommend that evaluators think of software as a tool to solve a problem. Selecting the right tool, how they use the tool and the training we provide them to use the tool is what separates successful projects from failures.
Sometimes, there’s a love connection and other times there isn’t. But, we think this approach is best for us and the buyer because it flushes out some of the common risks of project failure . After all, what have you gained from a software purchase that is unused and the benefits are unrealized?
