Change management, because a system nobody uses has not been delivered

You can, and it is the most common approach. It is also why the old spreadsheet is still open next to the new system a year later. Training tells people how; it does not address whether they believe the change is worth the disruption.

Resistance is usually rational. People have often been through a change that made their job worse, or they can see a problem the project has not considered. Treating it as information rather than an obstacle is generally more productive, and occasionally saves the project.

At the same time as the build, not after it. The most valuable input from users arrives during design, when acting on it is still cheap.

By what is actually used rather than what was logged into. Usage by feature, whether the previous process is still running, and data completeness are all more honest than a login count.

Scale it to the change. A tool used by three people needs a conversation, not a programme. A system that changes how forty people work every day is a different proposition.

Then find out why rather than pushing harder. Persistent workarounds usually indicate the system does not fit the work, and that is design feedback — the alternative is enforcing a process people are routing around for good reasons.