Executive guide to ERP, Part 3: The ERP selection process

In this third part of the series, Thinking about ERP, we begin covering the issues that a business and its executives will tackle when selecting an ERP system. From here on, thinking and planning have to be converted into action. Part one Thinking about ERP Part 1 blog discussed the initial key questions that executives must address about an ERP implementation. Part two Thinking about ERP Part 2 blog introduced the concept of ‘Dimensions of Change’ as an approach to thinking about the process, system and structural changes of an ERP implementation.

Once an organization gets to the selection phase, this is where spending time, money and effort starts. The decisions made during ERP selection have profound implications in later phases. If a business does a good job in the selection phase, the easier it is to keep time, costs and disruption in the subsequent implementation phase under control.

1.The role of executives in the ERP selection process

The role the executive decision-maker fulfils in the strategy for selecting an ERP system is to define the process of selection, not the selection itself. What system is selected is not as important as to how it is selected from amongst the list of alternatives. While selecting an ERP system does not necessarily guarantee a successful outcome to the project, the confidence that the right decision has been made means the project is more likely to succeed.

2.Making the right decisions in the ERP selection process

Most organizations will purchase a new ERP system very infrequently, maybe once every decade. That means most of the people involved in the selection process will have little or no experience in the process. Think of it as a young person buying their first car; they will probably need advice from an older adult who has some experience in the matter. That is why many businesses hire an experienced external consultant as a project manager. There are two key points when hiring a project manager.

  • Clearly specify the decision-making authorities of the project manager, the executive decision-maker and the chief executive, if this is someone other than the executive decision-maker.
  • Make sure the project manager is vendor-independent and does not have a vested interest in which system is selected.


3.Decisions the different role players can make

The decision-making hierarchy should be:

Top: executive decision-maker

Next: steering committee

Then: project manager

The steering committee is chaired by the executive decision-maker and is responsible for:

  • deciding on project resources, both in terms of money and personnel;
  • monitoring the progress of the selection process;
  • empowering the project manager and project team to make decisions;
  • verifying the trimming down of the list of ERP solutions being considered;
  • the final decision on an ERP system, based on the recommendations of the selection team.

The steering committee’s decision is not final until the board, or a similar group above the CEO has ratified it.

The project manager reports to the steering committee and is tasked with:

  • managing the activities involved in the selection process;
  • manage the scope of the selection process;
  • managing conflicts that may arise;
  • maintaining communication at all levels inside and outside the project team;
  • making the decisions that the steering committee delegates and escalating those that require steering committee resolution.

Do not let this be an IT-directed project. The selection team should comprise both IT staff and representatives from functional areas who work with core business processes. The representatives from the functional areas are called ‘process owners’ and have to authorize the sign off that the new ERP system can support the business process design of their functional areas.

Process owners should:

  • provide functional knowledge;
  • contribute to the design of new business processes;
  • assist in documenting the requirements and findings of the selection process;
  • ensure that business processes are integrated between functional areas.

The selection team needs to know the parameters that they can operate in – what is ‘on the table’, what is not, and where the team may ‘push the boundaries.’

4.The issue of ‘best practice’

When documenting how business processes will be changed (to-be processes), one trap to avoid is falling for so-called ‘best practice’ processes. To quote Peter Senge in the Fifth Discipline:

“I do not believe great organizations have ever been built by trying to emulate another”.

There are other reasons why ‘best practice’ is a fallacy.

  1. There is no such thing as industry best practice. Best practice may work for a particular company in a particular industry at a particular time. What works in one company may not work in another.
  2. New ideas are continually coming up, and ideas that worked yesterday can become outdated quickly.
  3. Companies that look for this are not leading edge.
  4. Adopting new practices considered ‘best’ is hard and may not be feasible in terms of time, money and effort.


Instead, businesses should focus on:

  • adapting best practices intelligently to the organization’s culture and situation;
  • defining quality processes that have the best chance of delivering quality products and services at the time and cost required;
  • having experienced people who have the ability to think critically, strategically, and creatively.


5.The customization question

For the selection team, the ability of an ERP solution to perform customizations and modifications should be a major factor in the selection process. However, discussions around this can degenerate into arguments rather than being part of an informed debate. In the Thinking about ERP book, there is a 4×4 customization matrix.

This matrix can be used to identify what to watch out for. Customization or modification that changes the look and feel of the software have negligible impact. At the other extreme, to write code to create new functionality carries a high risk and would be a long and costly process. In that case, consider a third-party ISV solution.

1.The ERP selection process

The selection team should use business processes as the basis to identify the requirements that an ERP system should meet. However there are other requirements, some of them may be subjectively assessable. These can include the stability of the software vendor, and the scalability of the system.

Then there is always cost. The selection team should not only consider the acquisition cost but also the cost of implementation and the running of the system. There may also be hardware costs and additional software license fees. A recommended costing analysis is to look at the costs over a five-year period to compare all the costs associated with each ERP system.

A successful selection phase comprises a structured and rigorous process that can be adjusted as the selection team learns more about the environment. Here is a suggested five-step process.

  1. Plan the acquisition and assemble the team. Compile the evaluation criteria and requirements that will be used to select a particular ERP system.
  2. Gather system information from selected vendors and develop a ‘long list’ of all the alternatives. Then filter the entries on the list using the evaluation criteria and requirements to reduce the number of possible alternatives to a shortlist of no more than four. The filtering process will be iterative, using different criteria in each iteration. For example, the first iteration would eliminate ERP systems where the cost would be too high.
  3. Evaluate the shortlist. This is done by asking for demonstrations on a pre-defined ‘script’ with the selection team scoring and ranking different ERP systems based on predefined criteria and requirements. The issue of implementation cost may come up here.
  4. Select an ERP system that best meets the criteria and requirements. This decision should be made by the executive decision-maker in conjunction with the steering committee, using the recommendations of the selection team.
  5. Negotiate the deal.

The rationale and details behind all the decisions should be documented and kept for future reference. This is in case decisions are challenged later, and to justify how and why time, effort and cost is spent on later phases of the ERP project.

Without a careful selection strategy, and without an appropriately assembled team, an organization can end up selecting an ERP system that is inappropriate, launch an implementation project that cannot tie the money and time spent to the results achieved, and end up operating a system because it’s there, not because it adds value.

In the next part of this series, we will look at how the selection strategy is also determined by the Degrees of Change model.

Download our Thinking About ERP eBook to learn more.

This eBook shows executives how to drive ERP implementation from the top and focus on key performance measures. Through clearly defining what the ERP project is meant to achieve, organizations can pursue their strategic objectives. If you do nothing else before starting your ERP project, read this book – it will make all the difference.

Download Now

Stay ahead of the rest...

SYSPRO blog gives you weekly industry insights supplied by experts.

Leave a Comment