People adopt a new business system when it helps them complete specific work with enough time, clear guidance and support when something goes wrong. A project announcement, demonstration or short training session is rarely enough. Change management starts with a practical question: what will change for the person who issues invoices, plans production, approves purchasing or closes the month?
Organisational change management is often presented through plans, deadlines and communication campaigns. All of these matter, but employees assess change through different questions: Will I know what to do? Will this new step take more of my time? Who can I contact when information is missing? Will an error be treated as a process issue or as my personal mistake?
The answers determine whether adoption of a new system becomes part of daily work or whether the team keeps parallel spreadsheets, email threads and informal arrangements.
Informing people is an important starting point. They need to know why the organisation is introducing a new ERP, which business problems it intends to address, which roles will change and when changes can be expected. An unclear message creates room for rumours, especially when responsibilities, approval sequences or data visibility are changing.
However, an announcement is not adoption. A message such as "we will work in the new system from Monday" does not answer working-level questions. More useful communication states:
It is useful to separate information for the whole organisation from information for individual roles. A warehouse manager, accountant and sales representative do not need the same level of detail on the same day. Each person needs the change explained in the language of their own work.
People who perform a process see exceptions that do not appear in a diagram. They know what happens when material arrives without notice, when a customer requests an order change after confirmation, when an invoice is waiting for a document that has not arrived, or when production must respond to the actual condition of a machine.
For that reason, involving users is neither a formality nor an invitation to a meeting to approve a decision already made. It means working through questions such as:
This does not mean accepting every existing habit. Sometimes a system introduces necessary order or requires clearer accountability. The difference is that the decision is explained through real work, rather than through an abstract message about standardisation.
Before configuration, it is useful to review workflows and set priorities. ERP and process screening can provide a structured starting point for discussing processes, data and unresolved decisions. This gives the project a clearer view of actual work before new rules become mandatory in the system.
Training with empty examples can show where a menu item is located, but it does not show how work moves through several roles. Adoption of a new system requires a trial of scenarios that actually occur in the organisation.
Consider a customer order for a product with insufficient available material. Sales receives the order. Planning checks whether delivery is possible. Purchasing starts a material order. The warehouse receives the goods. Production records consumption and completion of work. Accounting checks the documents and issues an invoice.
This scenario is worth running from start to finish, with real roles and realistic data. During the trial, questions appear that a presentation often skips:
The aim is not a perfect trial without mistakes. Its purpose is to identify missing decisions, unclear instructions and handovers of responsibility that remain invisible until every role completes its part. Month-end closing, returns, urgent orders, corrections and other less frequent tasks deserve particular attention because they carry greater risk when they occur.
Go-live is not the end of change management. This is when users first work under real pressure from deadlines, customers, deliveries and accounting obligations. Even a well-prepared process can raise a question that did not arise during testing.
Users therefore need visible support. This does not have to mean a separate team for every issue, but it does require a clear route:
Short, regular reviews of open issues can help separate urgent blockers from improvements that can be planned later. It is important not to promise an immediate change for every suggestion. Users need to understand what will be resolved now, what will enter assessment and why a particular change is not justified.
When an employee fears the response, a problem often stays hidden. The result can be an incorrect entry, bypassing the process or a return to private spreadsheets. This is not evidence of a lack of willingness. It most often points to unclear instructions, unavailable help, excessive time pressure or unclear allocation of responsibility.
A safe channel for reporting issues should allow a description without looking for someone to blame. A useful report can include:
This record helps the team analyse the cause. Is better guidance needed? Is data missing? Is the process rule unclear? Does an authorisation or system setting need adjustment? The discussion then becomes part of learning, rather than an assessment of someone's ability.
User involvement takes time, and a project cannot wait until every detail has been discussed. Too many meetings can tire key people and slow decisions. On the other hand, closing decisions too quickly leads to surprises after go-live.
A practical trade-off is to select representatives for each role, prepare specific decisions and set a response deadline. For each decision, it is useful to record the owner, the reason and the effect on other teams. Not every request needs to become a system customisation. It is often better to simplify a procedure, clarify responsibility or align data.
Support after go-live should also not become permanent dependence on a few "super users". If only they can resolve a routine task, the organisation has created new bottlenecks. Guidance, decisions and answers should gradually become available to the wider team.
Instead of asking in general whether people are ready for change, choose one important working day or one process involving several roles. Review it with the people who actually perform it: from the first data point to the final document, including the most common exception. Record where waiting, uncertainty and manual transfers of information arise.
This review provides a concrete basis for ERP implementation and for discussing process connections in connected operations . ORKA can help structure decisions, scenarios and support in this work, but real adoption happens when people can reliably complete their work in the new system.