The five biggest barriers to ERP adoption (and how to avoid them)

The five biggest barriers to ERP adoption are a lack of ownership, too little change management, one-off training, no metrics and stagnation after go-live. You avoid them by giving each process an owner, involving users, training them beyond go-live and measuring system use.

Adoption means your people actually work in your enterprise resource planning (ERP) system. If everyone works in IFS but the planning still lives in Excel, adoption is not finished.

Why do IFS implementations fail after go-live?

An IFS implementation can stall after go-live because the project stops there, while the change in people’s work only starts. In the white paper IFS Implementation Methodology (June 2020, still written for IFS Applications), go-live is the final phase. The solution is then handed over to what IFS calls the governance organisation, and the project is evaluated and closed.

The same methodology defines the solution governance model before go-live, together with the detailed cut-over plan. Check whether yours says who tracks usage after go-live, who leads the key users and who decides on improvements. If it doesn’t, nobody takes over the project team’s work. Add it now.

Hypercare, a period of agreed extra support, follows straight after go-live. The questions and workarounds raised during hypercare show you where to start. If the cause lies earlier, in design, testing or data migration, read IFS implementation in four steps and how to rescue an IFS programme.

What are the five biggest barriers to ERP adoption?

Below, Erry de Boer, CEO of Eqeep, explains the five barriers and how to address them. If you are already live, ownership, measurement and further development can still be put right; the sections after them show how.

Barrier 1: Lack of ownership makes ERP an IT-only affair

ERP is often seen as “an IT issue”, while the departments that use it have to carry it. This lack of ownership shows up straight away in the results. No one feels responsible for data quality, and process agreements turn into optional suggestions. Improvements stall because nobody owns them.

So assign a clear owner for each process or KPI. This person becomes responsible for data quality, compliance with agreements and initiating improvements. Make the role explicit and give the owner the authority to actually make changes. This gets the departments themselves involved and stops ERP from remaining a purely technical project.

Barrier 2: Change management is not a luxury but a necessity

Too many organisations concentrate on the technology and forget the people. That leads to resistance among employees, low willingness to use the system and a wholesale return to old tools such as Excel and email.

Start communicating early about why the change is happening. Involve key users in process design and let end users help shape the configuration. Organise workshops where employees can raise concerns and propose solutions.

Barrier 3: Training does not stop at go-live

Training courses are often short, one-off and far too generic. Employees get a standard tour of the system and must work out the rest themselves. As a result, they use only a fraction of what it can do and fall back on cumbersome workarounds.

Plan role-based training that matches the daily work of each user group. A salesperson needs different functions from someone in finance. Provide practical reference material that people can turn to.

Organise refresher sessions a few months after go-live, when users run into their first problems.

Barrier 4: Without metrics, you navigate by instinct

Many organisations do not define what successful adoption means. They do not measure how many users actually log in, which functions they use or which process improvements they achieve. Without these insights, improvements stay invisible and support from both management and users fades.

Decide in advance which KPIs and metrics you will use to measure adoption. Examples are actual system usage, process lead times, data quality and user satisfaction. Record a baseline and track changes alongside the cost of training and support. Make these metrics visible to the people involved and discuss them regularly.

Barrier 5: Standing still after go-live

After go-live, ERP often disappears from the agenda. The project team is disbanded, the consultants leave and everyone goes back to business as usual. Meanwhile, business processes, market demands and user needs keep changing. The system that fitted at go-live fits the work less and less.

So make further development part of your long-term planning. Schedule regular reviews of your processes. Collect feedback from users and turn it into concrete improvements. Set aside budget for optimisations and new functions.

How can you tell whether people really use IFS?

You can tell whether people really use IFS from the traces their work leaves there, and from what happens alongside it. Logins alone say little. Look for these signals:

• Reports nobody opens. Ask your key users which ones they still use.
• Work outside the agreed process. IFS Process Intelligence uses your transaction data to show how work actually moves through IFS, and where practice departs from the design.
• Orders and data that are entered or corrected after the fact.
• Questions that keep coming back. The monthly report from Eqeep’s service desk shows which modules generate the most questions and which users call most often.

A lobby in IFS Cloud lets you put these signals on one page. Review them monthly with the process owners. People decide: the process owner chooses which signal gets attention first. See how to choose KPIs that steer.

How do you show the board what IFS has delivered?

A baseline per process and fixed signals, explained by each process owner, show the board what IFS has delivered. If there is no baseline, record now where the work stands, for example in lead times and data quality. Put the signals from the lobby next to it, with the cost of training and support. The board then sees per process what has changed and what it cost.

How do you stop key users from being overloaded?

You prevent overload by protecting key users’ time and spreading questions across more people. The IFS support policy (version 2026-02) makes the customer responsible for first-line and end-user support, including training and application configuration.

After go-live, colleagues’ questions therefore land with your own people. Without clear agreements, that means the key users. What IFS expects of your key user is covered in our article on in-house application management.

Build a network of key users and deputies per process or site, each with set time for questions every week. You can also place the first line with Eqeep’s service desk. See how to keep IFS knowledge when key users leave.

Why does adoption start again with every release update?

Adoption starts again with every release update, because a release can change how screens and steps work. IFS Cloud gets two releases a year, usually one in spring and one in autumn under the IFS support policy.

IFS itself states that its improvements may require additional training of key users and users. Plan a short refresher round at the two release updates, not at every service update. Those usually come monthly and are designed to have minimum impact on existing functionality. See how Eqeep sets up IFS training by role.

Your team decides which new functions you adopt, with the owner of the process that changes. See which features are already in your IFS Cloud. For how far behind you may fall, see IFS maintenance and support.

When does more adoption work not help?

More adoption work does not help when the system genuinely does not support the work. A stubborn workaround can mean a step is missing from the configuration, or a mandatory step adds nothing. Extra training will not fix that; it takes a change in IFS. Whether configuration is enough or customisation is needed is covered in IFS development and optimisation.

Questions about ERP adoption

How do you measure ERP adoption in IFS Cloud?

With signals from the system and from daily practice, set against a baseline. Look at reports nobody uses, departures from the agreed process and repeat support questions per module.

Who is responsible for adoption after go-live?

Your own organisation, with an owner for each process who decides on agreements and improvements.

When do you have an adoption problem, and when a configuration problem?

You have an adoption problem when the work can be done in IFS but people do it differently. If even a key user cannot do it without a workaround, the cause lies in the configuration.

Tell us where you stand with IFS. After one conversation you will have a clear next step. Describe the workarounds you see and where your key users get stuck. Discuss your IFS question.