When a user maintains a private spreadsheet, delays entry or asks a colleague to complete a step, the easiest conclusion is that they resist change. Sometimes that is true. More often, the behaviour shows that the system does not provide information at the point of decision, the process does not match real work or the consequence of an error feels larger than the benefit the user sees.
The goal is not to excuse every workaround. It is to distinguish four causes: lack of knowledge, poor process design, unreliable data and deliberate avoidance of accountability. Each cause requires a different response. More training will not fix an unnecessary step, and a new feature will not solve missing ownership.
If sales does not trust the ERP delivery date, the cause may be late material records, inaccurate routings, unclear customer priority or no scenario for partial delivery. Banning the spreadsheet without fixing the source only hides the problem. The correct step is to determine which fact is missing for the ERP date to become usable in a customer conversation.
Ticket volume and training attendance are not enough. Track how much of the process is completed without exports, how far records lag behind real events, how many entries require later correction and where users most often return to parallel tools. Adoption becomes visible when the system is the easiest reliable path to a result.
User resistance should be taken seriously, but not literally. Behaviour shows where to investigate process, data, knowledge or accountability.