Change management in ERP and AI implementation starts before system configuration. Involve users in mapping work, decisions about the target process, testing real scenarios and training for their roles. Communication explains what is changing, but participation reveals whether the new way of working can function in practice. This reduces the need for parallel spreadsheets, informal workarounds and bypassing the new process after go-live.
A user who continues to keep a separate record or skips a new step is not necessarily unmotivated. That behaviour often reveals a specific obstacle: a required data point is missing, the approval sequence does not reflect real responsibility, an exception has no owner, or a new screen slows down a critical task.
It is useful to separate three questions:
Communication matters for the first question. It does not resolve the second and third on its own. The project owner should organise working decisions with people who know orders, production, warehousing, accounting, approvals and reporting. For AI system adoption, include people who assess inputs, review system suggestions and take responsibility for the decision.
An initial process map is not an interview about how work should look. It needs to show how work actually moves through the organisation. In addition to managers, involve operational users from different shifts, locations and levels of responsibility.
For every important process, collect:
Workarounds deserve particular attention. A personal spreadsheet, a message to a colleague or manual re-entry of data may be a risk, but it may also reveal a real need that the formal process has missed. Before removing a workaround, establish what function it serves, who relies on it and how the target solution will cover the same need.
In an ERP implementation, it is useful to distinguish the standard flow from exceptions. The standard flow provides a basis for configuration. Exceptions determine whether users remain in the system when an incomplete order, changed deadline, partial delivery or incorrect document appears.
A target process is not only a diagram. It is a set of business decisions: which data is mandatory, who may change a status, when posting occurs, what needs approval and how an exception is handled.
Workshops should end with a clear decision record. For every important point, record:
Not every detail is open for discussion. A legal obligation, accounting control or an existing management decision may set a boundary. Users can still help shape a workable step within that boundary. Clearly identify what is fixed, what needs input from the team and who makes the final decision. Ambiguity creates an appearance of participation and later erodes trust.
Testing is not only a technical configuration check. It is a rehearsal of work. A user in the real role should complete a scenario with data and documents similar to everyday work.
A sound scenario set includes:
For example, when processing an incoming invoice, it is not enough to check whether the invoice can be recorded. The team needs to test what happens when a purchase order is missing, the quantity does not match the receipt, the invoice requires additional approval or a correction must be recorded. These cases often determine whether accounting trusts the new flow.
For an AI component, the scenario also needs to cover limits of use. Define who reviews a system suggestion, which inputs the user must confirm, when an output is insufficient for a decision and where a case goes for human escalation. AI system adoption does not rest on a message that the tool is available. It rests on a clear working rule for use, review and accountability.
Record findings by their effect on the process, not only by a technical error category. An unclear field label is different from a situation where a user cannot complete a calculation, issue a document or identify the owner of an exception.
A general system presentation rarely prepares people for a working day. Training should follow the role, tasks and decisions of each group.
A training plan can include separate modules for:
The most useful format is a guided exercise based on a realistic scenario. Participants should not only find a function. They need to recognise the input, complete the step, verify the result and know what to do when a deviation occurs. For an AI workflow, this includes assessing input quality, reviewing a suggestion and correctly marking a case that requires a human decision.
Go-live is not the end of change management. The first weeks show the difference between a test scenario and real workload. Organise a short stabilisation cycle with a clear issue-reporting channel, owners for triage and regular review of recurring obstacles.
Track operational signals such as the number of manual workarounds, open exceptions, repeated questions about the same step, approval bottlenecks and the quality of key data. These signals are not evidence of user failure. They are material for improving the process, training or configuration.
It is also important to set a point for retiring the old way of working. A parallel record may be justified during a controlled transition, but without an owner, scope and end date it can easily become a permanent alternative. Before switching off the old record, check whether critical exceptions are resolved, whether users know whom to contact and whether a reliable way exists to export required data.
Change communication usually includes an announcement, the reason, a timeline and a description of benefits or obligations. It is necessary, especially when a change affects responsibilities and priorities.
Real participation requires more. A user contributes to process mapping, walks through a prototype or scenario, reports an obstacle, takes part in an exception decision and sees what happened to the finding. The project team does not have to accept every proposal. It should explain the decision and show where the request was resolved, deferred or declined.
This approach also involves tradeoffs. Involving more roles takes time and disciplined workshop management. Discussion that is too broad can slow a decision, and a local preference can conflict with the need for a consistent rule. The project owner should therefore define representatives, the scope of decisions and an escalation mechanism in advance.
Before configuration starts, compile a list of key processes, user representatives, decisions the project must make and scenarios that need testing. If it is difficult to establish the real work flow or ownership of exceptions, ERP and process screening can provide a structured starting view. For a broader framework of responsibilities, indicators and operating rhythms, see the Operational management guide .