When an employee asks why a system is changing in a workshop, the answer should not be just a project explanation. It is an opportunity to find out what the digital change may disrupt in real work. Empathy in business is not giving in to every request. It is a way to understand the consequence for the person, the process and accountability before making a decision.
People who ask difficult questions are not necessarily resisting change. They may be the first to notice a step the project plan did not see.
The introduction of an ERP system, a new integration or a different approval process is often described through deadlines, data migration and training. For an employee, something more concrete changes: the way they know a task has been done correctly.
Shortcuts built over years disappear. Data once checked in a personal note must now be found in the system. An error that could previously be corrected quietly becomes visible to the next person in the process. For some people, the sequence of tasks changes. For others, the boundary of responsibility changes.
This is why employee experience during change does not begin on the training day. It begins while the process is still being designed, when a team can ask where people pause, what they need to check again and when they lack enough information to make a safe decision.
This kind of conversation does not slow down change management. It can prevent a team from digitising a procedure that already creates unnecessary risk, duplicate work or dependence on one person.
A user may say they want the same screen as in the old application, an extra button or an exception to a new rule. That may be a useful suggestion, but it is not yet necessarily the problem that needs to be solved.
Rather than moving immediately towards a feature, ask a few simple questions:
The answer may reveal that a person checks data before sending a document, does not trust an automated calculation or takes responsibility for an exception that the formal procedure does not recognise.
The team can then address the cause. Sometimes the result genuinely is a new button. In another case, it may be a clearer status, a more understandable error message, better-defined decision ownership or a different sequence of steps. The distinction matters because a feature that only copies the old way of working often preserves the old problem as well.
In ERP and process screening , these questions help separate a real need from the first solution proposed. This gives the team a clearer basis for process and system decisions.
Not every worthwhile change is easier immediately. Data cleansing, learning new rules, aligning master data and ending parallel records can require more attention for a time than the old way of working.
The problem begins when a project leaves this unsaid or promises that everything will be simpler from day one. People do not lose trust because they have to learn. They lose trust because their experience is denied.
It helps to explain openly:
These are not merely communication messages. They are working information that allows an employee to assess the next step. Empathy in business means the project provides this information in time, without glossing over difficulties and without placing the burden of figuring things out on the user.
A workshop without feedback can do more harm than good. If people take the time to explain a real problem and then receive no information about the decision, they are more likely to remain silent next time or solve the problem through a workaround.
For every collected insight, return one of four clear messages:
A refusal with a reason is fairer than silence. It shows that the team heard the question, assessed the consequences and made a decision. It also prevents expectations from becoming unspoken promises.
In practice, keep a simple list of insights with an owner, a decision and an agreed response back to the user. It does not need to be a complex document. What matters is that the person who raised the issue can find out what happened to their question.
A process map shows steps, data and responsibilities. It is also useful to mark the moments when people feel least certain. This is often where needs are hidden that a standard specification does not reveal.
A person may think: "Will my knowledge still matter?" The project needs to explain their future role and the reason for change, not only announce a new tool.
The question is often: "Am I allowed to make a mistake?" People need a safe environment to practise, available help and clear guidance on what to do when something fails.
A person may wonder: "What if I hold up other people?" Visible task status, an understandable next step and a recovery path when an error occurs are helpful here.
A common thought is: "The new system does not understand my work." The project needs to define who makes the decision on an exception and how feedback returns to the user.
The question becomes: "Is anyone still listening to us?" A regular channel for improvement is needed, not only support for technical faults.
These questions are not a project weakness. They show where information, authority or accountability is not yet clear enough. For a broader view of day-to-day operations and management decisions, see the Operational management guide .
Go-live is a technical date. Human change continues until people can independently complete real work, understand a common exception and trust that a problem will be heard.
Alongside the number of reported errors, a team can observe other signs of adjustment:
These signs do not by themselves mean that the system is poor. They show where the process has not yet settled and where a user needs a clearer answer, support or a different rule.
There is also a real trade-off. Not every request can be accepted, and too many adaptations can make a process harder to maintain and delay stabilisation. Empathy is therefore not the same as agreeing with everything. It means understanding the consequence before deciding, explaining the decision and leaving a reliable path for resolving problems.
At your next workshop, do not first ask which feature people want. Ask at which moment they stop, what they check outside the system and what they fear before confirming an action. Their answers will give the technical plan real context. For further topics on processes and digital change, visit the ORKA Knowledge Centre .