The statistics are grim. Depending on which survey you trust, 50-75% of ERP implementations fail to deliver expected ROI. Not because the technology doesn’t work — Dynamics 365, SAP S/4HANA, Oracle Cloud, and NetSuite are mature, capable platforms that power millions of transactions daily.

They fail because every ERP implementation is fundamentally a change management project wearing a technology project’s costume. The technology is the easy part. Convincing 500 people to change how they’ve worked for the last decade is the hard part. And the budget allocates 90% to technology and 10% to change management. It should be the opposite.

The Pattern

Every failed ERP implementation I’ve consulted on follows the same six-phase story with distressing predictability:

Phase 1: Excitement

The vendor demo looks incredible. Automated workflows, real-time reporting, AI-driven insights, mobile access, seamless integration, beautiful dashboards. The executive sponsor watches the demo and sees the future. Budget approval comes easily because the demo answers every question with “yes, the platform can do that.”

What the demo doesn’t show: the 12-18 months of configuration, customization, data migration, testing, and organizational upheaval required to make the demo a reality. The distance between “the platform can do that” and “your organization is doing that” is measured in millions of dollars and years of effort.

Phase 2: Configuration

The implementation partner starts configuring the system. They ask the business team how processes work today. The business team describes their process — the documented, formal, “how it’s supposed to work” version. The implementation partner configures the ERP to match.

This is the first critical failure point, and it happens on every project. The formal process description misses the reality of how work actually gets done. It doesn’t capture the spreadsheet that Susan in accounting uses to reconcile vendor payments because the current system can’t handle her edge cases. It doesn’t capture the email chain that triggers the warehouse to prioritize rush orders. It doesn’t capture the fact that 30% of purchase orders get manually overridden because the approval workflow is too slow.

These informal workarounds, tribal knowledge, and exception-handling processes represent the organization’s actual operating procedure. And none of it appears in requirements documents because nobody thinks to mention it — it’s just “how things work.”

Phase 3: The Gap

The configured system doesn’t match how people actually work. Users start testing and discover that the new system requires five clicks for something that took two in the old system. The finance team finds that the month-end close process now takes three days instead of one because the consolidation logic works differently. The warehouse team discovers that the picking process generates twice as many paper printouts.

The gap between the configured system and the actual workflow creates resistance. Users don’t just dislike the new system — they actively work around it, reverting to spreadsheets, email chains, and manual processes that bypass the ERP entirely.

Phase 4: Customization

To close the gap, the implementation partner builds customizations. “We’ll add a custom button here.” “We’ll build a workflow that automates that step.” “We’ll create a report that matches your old format.”

Each customization adds complexity, extends the timeline, increases cost, and — critically — makes future upgrades harder. A heavily customized ERP is a unique snowflake that can’t benefit from standard vendor updates without regression testing every customization. The implementation partner’s margins improve with every customization because customization is billable hours. The client’s TCO increases with every customization because maintenance is forever.

The project goes over budget. The timeline extends. Scope negotiations become tense.

Phase 5: Go-Live Chaos

The system goes live. Users can’t find things because the navigation is different. Reports look different because the data model is different. Processes require more clicks because the new system enforces controls that the old system didn’t have. The finance team discovers that the closing process takes three days instead of one because nobody tested it end-to-end with a full month of real production data.

Customer orders are delayed because the order processing workflow has bugs that only appear at production volume. The warehouse team reverts to paper-based processes because the mobile scanning integration doesn’t work reliably. The CEO receives a call from the largest customer asking why their shipment is a week late.

Phase 6: Blame

The business blames the implementation partner: “They didn’t understand our requirements.” The implementation partner blames the business: “They didn’t provide complete requirements and changed scope repeatedly.” The vendor blames both: “The platform is capable — the implementation was flawed.” Consultants are hired to fix the mess, adding another layer of cost.

The post-mortem reveals what everyone already knew: the project treated ERP implementation as a technology migration when it was actually an organizational transformation.

What Actually Works

Start with Process, Not Software

Before selecting an ERP — before even issuing an RFP — document your actual processes. Not the ideal processes. Not the processes in your policy manual. The real processes with all their workarounds, exceptions, manual steps, and tribal knowledge.

This requires observation, not interviews. Shadow the people who do the work. Watch how orders actually flow. See where the spreadsheets live. Understand which approvals are genuinely valuable and which are rubber stamps that add delay without adding control.

Then ask the transformative question: which of these processes should change? An ERP implementation is an opportunity to improve processes, not just digitize existing ones. But that improvement needs to be deliberate, planned, and communicated — not discovered accidentally during go-live.

Process redesign before software configuration ensures that the ERP is configured for the desired future state, not a digital replica of the current (often broken) state.

Invest in Change Management Like It’s Your Primary Deliverable

Every hour of training a user receives before go-live saves ten hours of support requests after go-live. This is not an exaggeration — it’s a measured ratio from dozens of implementations across multiple industries.

Change management is not a training session the week before launch. It is not a PDF user guide. It is not a “change champion” poster in the break room. It’s a structured program that runs throughout the entire implementation:

Month 1: Involve users in design. The people who will use the system every day should participate in configuration decisions. Not executives — the actual users. Their input prevents the Phase 3 gap, and their involvement creates buy-in.

Months 3-6: Running parallel operations. Users work in both the old and new systems simultaneously for four to six weeks before cutover. This surfaces integration issues, identifies training gaps, and builds familiarity in a low-risk environment.

Months 4-8: Super user development. Designate “super users” in every department — the respected, technically comfortable team members who become the first line of support for their peers. Train them deeply. Empower them to solve problems. Pay them more.

Post-go-live: 90-day intensive support. Provide intensive support for 90 days after go-live, not the typical 30. The first month catches the obvious issues. Months two and three catch the process gaps that only appear during month-end close, quarter-end reporting, and other periodic workflows.

Accept Data Migration as 40% of the Project

Data migration is always underestimated. Always. Without exception. Every project manager who has done three ERP implementations will tell you this, and every project manager doing their first will underestimate it anyway.

Your legacy ERP has 15 years of data with inconsistencies, duplicates, fields that mean different things in different modules, and business rules embedded in data transformations that nobody documented. Customer records with five different address formats. Product codes that changed naming conventions three times. Vendor records that reference companies that were acquired, merged, or went out of business.

Cleaning, mapping, transforming, and validating that data is not a weekend task. It’s not a two-week sprint. It’s 30-40% of the entire project effort. Budget accordingly. Staff accordingly. And test the migration at least three times with full production data before go-live — not sample data, not subset data, the full dataset.

Minimize Customization Ruthlessly

Every customization is a future liability. Before approving any customization, ask: “Can we change the process to fit the system instead of changing the system to fit the process?”

The answer is often yes. Standard ERP processes exist because they represent best practices refined across thousands of implementations. Your unique process isn’t always better — sometimes it’s just familiar. And familiarity is not a sufficient reason to add customization that will cost $50K/year in maintenance for the next decade.

The technology works. The question is whether your organization is willing to do the hard, unglamorous work of change management, data cleaning, and process redesign that makes the technology useful.

---

The Garnet Grid perspective: We specialize in ERP implementations that succeed — by focusing on organizational readiness, data quality, and change management before the technology is configured. Explore our ERP advisory →