Who should be involved in deciding on an ERP?

An ERP selection needs three clearly separated roles: a decision maker from the management board who settles it in the end, a small core group of process owners from the main areas who evaluate, and named specialists who contribute on individual questions. What matters is not who is present, but that it is established beforehand who evaluates, who contributes and who decides.

What steering looks like in the project afterwards: Who steers your project when it gets hard?

The selection approach in overview: ERP selection: criteria, approach and checklist

The three roles

The first role is the decision maker. As a rule that is a member of the management board, and this person decides in the end, including against a majority in the evaluation group. An ERP decision binds the company for many years and affects investment, staffing and processes. It therefore does not belong in a vote but at the table where such decisions are otherwise taken.

The second role is the core group. It consists of the owners of the processes with the largest share in the system, typically finance, sales, production or logistics, and IT. Four to six people is a good guide. This group evaluates, documents and presents a reasoned recommendation to the decision maker.

The third role are the contributors. These are specialists who give information on individual points without being permanently part of the group: the person who prepares the annual accounts, the foreman who knows the machine data, the colleague who looks after the interface to the shipping provider. They are asked deliberately, not involved continuously.

Why IT should not decide alone

When IT carries the selection alone, a familiar pattern emerges. The technical assessment is sound, the integration well considered, and the result still fails on acceptance because the business areas experience the system as imposed on them. Conversely, a selection carried out by the business areas alone leads to a system that is not sustainable in operation.

The task of IT in the selection is therefore a different one: it assesses operability, interfaces, data protection and the question of what running operations cost and who delivers them. That is an evaluating role with clear weight, but not a deciding one.

The opposite mistake is just as common: management delegates the selection entirely and reappears only to sign. The decision then lacks backing, and the first serious difficulty in the project makes it wobble.

How to keep the group from growing too large

The most common road to paralysis is well intentioned: so that nobody feels passed over, every area is invited. Six people become fourteen, meetings become hard to schedule, and evaluations dilute into compromises nobody stands behind.

What works is separating involvement from decision. Every area is heard, but not every area evaluates. That can be organised transparently: the core group collects the requirements of all areas in a structured way, documents them and makes visible what was taken up and what was not.

It is important that rejections are explained. A requirement that was declined with a reason creates far less resistance than one that disappears without comment. That documentation later also forms the basis for classifying change requests during the project.

What the group must settle before the first vendor meeting

Three things should be in place before the first vendor is invited. First the goals: what should be different after implementation, and how would you measure it? Without that answer you evaluate functions instead of effect.

Second the criteria with weighting. Not as a list of two hundred points, but as a manageable set of requirements that genuinely differentiate, with a deliberate weighting. Third the decision path with dates: who evaluates what and when, when the recommendation is ready and when the decision is taken.

This preparation looks laborious and saves a multiple later. It is also the best protection against the most common course of a selection: that dates slip, criteria drift during the process, and in the end the vendor who presented last wins.