The launch date arrives. Data has been migrated, employees have been trained, and the new system is live. Within weeks, the old spreadsheets return. Teams rebuild familiar reports. Approvals still travel through email. The technology changed and the operating model survived.
Software does not arrive in an empty company. It inherits the definitions, exceptions, incentives, and power arrangements already in place. If two departments disagree about when an order is complete, the new system needs a field that records the disagreement. If nobody owns the handoff, automation moves the ambiguity faster.
This is why configuration sessions become political. A screen appears technical, but every required field and approval rule expresses a business decision. Teams that avoided those decisions before implementation often bury the conflict inside customization.
Training cannot resolve that problem. Employees can learn where to click and still lack a shared answer about who decides, which standard applies, or when work is allowed to move. Adoption then becomes a polite label for unresolved design.
The strongest transformation work begins before configuration. Define the outcome, map the current transaction, identify exceptions that still have economic value, and assign ownership to the points where work changes hands. The software should enforce those decisions, not substitute for them.
A successful launch is not evidence that the company changed. The evidence appears later, when the old workaround is no longer necessary and people trust the new process enough to stop rebuilding the previous one.