ERP projects: user training decides whether Business Central is adopted

In an ERP project, training almost always comes at the end of the plan. By then the budget is partly spent and the project team has a single goal: hold the go-live date. Yet training is what decides whether the system will be adopted or merely endured. Business Central is more than a set of new screens. It imposes processes, data entry discipline and a setup logic that users must understand if they are not to work around it.

An accountant who does not know why a customer's "Gen. Bus. Posting Group" determines its entries will end up filling it in at random. Repeated by a few dozen people, that approximation is enough to strip the implementation of much of its value. Among the seven main risks of an ERP project, this fourth one is probably the easiest to sacrifice.

Manifestations and symptoms in the field

The scenario repeats itself from one project to the next with almost mechanical regularity. In the first days after go-live, support is flooded with basic questions: how to find an order, how to correct an invoice that has already been posted, why a field refuses an entry. Then the urgency subsides and a quieter problem takes over.

After a few weeks, errors surface in the data: incomplete item cards, duplicate customers, dimensions assigned to the wrong values. The first month-end close often acts as a revealer, when discrepancies prevent the books from being closed on the usual schedule.

Then come the workarounds. A spreadsheet reappears to track what nobody knows how to get out of the system, a parallel process takes root and nobody reports it. Productivity stays below its former level long after the normal adjustment period, and one sentence keeps coming back in the departments: "it was simpler before". It would be convenient to see this as ill will. Part of the criticism targets a setup that genuinely needs improvement, the rest reflects an incomplete command of the tool. That is precisely the distinction a poorly trained organization can no longer make.

Financial, operational and human impact

The cost does not stop at go-live. Operationally, the data degrades without a sound: mandatory fields filled with the first value that comes to mind, coding conventions ignored, master data polluted record after record. Six months later, the dashboards show figures nobody believes any more, and management goes back to its manual extracts.

The financial bill arrives later. Support has to be extended, training repeated and data corrected by hand. It is not unusual either to adjust the setup to compensate for a lack of knowledge rather than to meet a real need. These time-and-materials days, rarely foreseen in the initial contract, weigh heavily on the project's final balance.

The human cost lasts longest. Users left to fend for themselves with a tool they do not master keep a stubborn distrust, of the system and of those who chose it. That distrust resurfaces with every update, every new feature and every subsequent project.

Root cause analysis and governance errors

The first cause is budgetary. In the estimate, training is one line among many, and often the first to be trimmed when the project drifts. It is treated as a cost, rarely as the condition for any return on investment.

The schedule makes things worse. Everything happens in a narrow window, sometimes too early: training delivered three months before go-live is largely forgotten when the day comes. A skill is built through repetition, and repetition only really starts when users process their own transactions.

Content is another problem. Designed by the partner, it describes the tool page by page, often on the CRONUS demonstration company. Users learn where to click without seeing how their own items, their customers and their special cases fit into what they are shown.

Finally, the teaching approach stays uniform. A room, a projector and a hundred-page manual suit some profiles and leave others behind. A warehouse operator does not learn the way a financial controller does.

Action plan, preventive and corrective measures

Training should be managed as a workstream in its own right, with a budget, an owner and milestones. It takes place in several stages: an initial session held as close as possible to go-live, catch-up sessions for those who were absent, then support during the following weeks.

The most effective lever remains the key users. Trained early and involved in user acceptance testing, they know both their business and the chosen setup. They then train their colleagues, with the vocabulary and examples of their own department. Acceptance testing is itself a form of training, provided it is carried out in a sandbox loaded with a copy of real data, not in the demonstration company.

Formats should vary: workshops on real cases, short videos per process, one-page quick reference sheets, individual coaching for sensitive positions. Profiles and pages tailored to each role also lighten the learning curve, since everyone sees only what concerns them.

After go-live, the arrangement should be reinforced rather than dismantled. That means stronger support during the first weeks, open office hours for the questions people hesitate to ask, and a review after the first month-end close. Mastery should also be measured. A few regular checks on incomplete records or duplicates show better than a satisfaction survey where the next training effort should go.

Conclusion

Many companies invest little in training, sometimes nothing at all. They are wrong. After paying for licenses, months of setup and a data migration, they leave unprotected the one condition that makes all of it profitable: actual use of the system. Every training gap gives employees an opportunity not to adopt the tool, to bypass it or to use only half of it. After a few months, those individual choices become the way the company operates.

It would be tempting to hand this responsibility to the partner. That is not realistic. The partner trains at go-live, but cannot go down to the detail of every position or follow how practices evolve department by department. Above all, it has no control over what weakens knowledge the most: staff turnover. People leave, others arrive, and each departure takes away part of the know-how gained during the project. Believing that the partner preserves this knowledge on its client's behalf is an illusion.

Mastery of Business Central must therefore become an internal asset, just like the system itself. That requires key users recognized in their role, procedures kept up to date and an onboarding path for every newcomer. A company that does not take over this role does not lose its ERP overnight. It loses it little by little, with every departure.