The process for selecting a new ERP system has hardly changed in the past 30 years. The core of the process has always been assembling the feature-function list that itemizes, in painstaking detail, the functionality that is needed from a new system.
In most cases, this feature-function list makes up 90 percent of the request for proposal (RFP) that is sent out to prospective software vendors. Automated tools and services like BuySmart and TEC that sprung up in the 1990s reduced the drudgery of going through this process, but the process itself did not change much. The other aspect of the selection process that has not changed much is the fact that it is the IT department of the company that drives the process in over 90 percent of such projects.
While the venerable feature-function list is valuable tool for facilitating the comparison of candidate software packages and may never disappear, it is gradually taking a back seat to what should really be driving the selection process – the overall process improvement objectives of the business.
After all, is it not the desire of the company to improve its business processes that is driving the need for change? The business process reengineering (BPR) thrust that surfaced in the late 1990s was certainly on the right track, but it faded from view as BPR projects gained the reputation for being huge expenditures that failed to deliver on the promises. So, it’s back to the basics – a strategy that usually proves to be the best.
“The basics” in this case are the desired business process improvements that are being sought. Even more basic than the business processes is the reason for seeking the improvement in the first place – the desire for increased profitability. Having the software selection team dive right into the chore of assembling a feature-function list almost always pushes the profit motive aside in favor of the search for the Holy Grail, i.e. the perfect match to the feature-function list. It is no wonder that the company’s executives become apprehensive. They seek higher profitability, yet the selection team is thrashing around in the weeds with a different set of goals.
During my 30+ years in the ERP field and my involvement in more than 100 ERP software selection projects, I have learned there is a better way to go about this process – and it really works!
The key business stakeholders, not the IT department, must lead the charge so as not to lose sight of the overarching goal of increasing profitability. This is certainly not a put-down of the IT professionals – they too are very important stakeholders and their efforts will be one of the most important keys to a successful implementation. The IT folks must be prominent members of the team, but it is unfair to them and to the company to saddle them with the overall project leadership role.
Now you’re probably asking yourself: how are the non-IT stakeholders – who are not software functionality experts – going to lead this effort? The answer is pretty simple. There is no need for them to be software functionality experts at all. Their expertise is in running business operations, and it’s those operations, not the functionality of the software, that drive profitability. Don’t get me wrong, software functionality is very important – ERP system functionality must support the business process improvements, but it cannot bring about those improvements – the business stakeholders must do that. So why not start there?
The ideal way to begin the process is to have the stakeholders, including the IT experts, get together and develop the plan for improving the business processes.
The best way to start this exercise is by taking a look at current industry best practices (I realize that is a somewhat overworked term, but we’re stuck with it until another buzzword surfaces) that are supported by ERP systems. This is a whole lot easier than perusing a list of 2,000 or more feature/function goodies and getting overwhelmed by the enormous scope of the decision.
It is usually best to bring in a consultant armed with a current list of ERP-related best practices. Then, with the help of the consultant, the stakeholder team narrows down the list to those best practices that hold the most promise for reducing costs and/or increasing revenues.
During this exercise, the team should focus on two important items: 1) what are the company’s primary pain points in need of relief, and 2) what new technologies and/or techniques are on the market that can make the business run more effectively, even if we don’t feel pain in the specific areas they address. This is where the IT professionals can bring some winners to the table.
They can show the other stakeholders new technologies such as business intelligence (BI), enterprise performance management (EPM), management dashboards and electronic workflow can increase both the efficiency and the effectiveness of business operations. Adoption of some of these new technologies should be among the team’s list of best practice drivers.
It is important that for each best practice improvement initiative, the team assesses two aspects of each: 1) the degree of change management effort that will be involved, and 2) the estimated profit contribution of the initiative. Armed with this information, the team can prioritize the initiatives into a list of detailed objectives that everyone from the shop foremen to the executive suite can embrace.
Now comes the tricky part – do we still need the traditional detailed list of features and functions? Some will demand it be assembled and some may not. My take on it is this: if the list of best practice-driven business process improvement initiatives is backed up with solid descriptions of what the new processes entails, it’s probably better than an exhaustive list of features and functions anyway – and process improvement initiatives list is probably what should drive the eventual software demonstrations.
