The first thing that surprised me about leading an ERP implementation was how little of the difficult work involved software.
I managed a rollout with 11 workstreams across 6 phases. Before go-live, we had to decide which processes would become standard, who would gain approval authority, and which informal workarounds would disappear. The system needed a configuration for each decision, but the decisions belonged to the organization.
Scope started growing before the project began. Logistics wanted another feature. Finance needed a custom report. Manufacturing wanted the system to support a workflow outside the original brief. Most requests were reasonable, which made them harder to reject.
Each addition still required configuration, testing, training, and support. The scope expanded while the deadline stayed in place. Saying no created friction, but accepting every request would have created a system nobody could deliver or maintain.
Users describe what they do. ERP systems describe how transactions move. A procurement manager might ask for re-approval whenever a price changes by more than 5 percent. Turning that request into a reliable rule requires details about tolerances, currencies, exceptions, and who can override the block. A simple sentence becomes a chain of decisions.
When the system cannot match the process, teams create a workaround. That workaround becomes normal. A few years later, nobody remembers the original requirement and the next change has to account for rules that were never documented.
Training is part of the same problem. Users need to test real scenarios before launch, including the awkward cases that do not fit a standard demo. They also need an honest picture of day one. A new ERP will not behave like a mature system after six months of corrections and use.
ERP projects also change visibility. Some teams gain reporting they never had. Others lose the freedom to work around weak controls. Resistance is not always a training issue. Sometimes a person understands the system perfectly and dislikes the accountability it introduces.
What helped us was a visible project command center with module coverage, user-testing status, risks, and open issues. We tested with realistic data and fixed serious problems before launch. That did not remove the politics, but it made the decisions and their owners harder to hide.
Go-live is not the finish line. It is the point where the configured system meets the actual business. The gap closes through support, clear ownership, and steady correction. Projects struggle when the implementation team hands over that gap and treats it as somebody else's problem.