ERP Failures Start Before Day One: Here’s Why

By Liviu Ghiuzan

ERP (Enterprise Resource Planning) systems promise a single digital backbone for finance, operations, supply chain, sales, and HR. In theory, they should end the chaos of long spreadsheets and heavy manual data entry. In practice, many companies still run ERP and Excel in parallel and spend more time collecting data than making decisions.

I believe most professionals have faced this at some point. I’ve seen manual data collection that takes hours, reports that don’t match real needs, and endless rework. In one case, I even found a solution that was ten times cheaper and better suited to the job. We couldn’t evaluate it because the ERP was fully coordinated by the IT department and contractually locked to a single vendor, including database backups. That experience reinforced a simple lesson: when ERP becomes an IT project instead of a business project, flexibility disappears and costs grow.

The core mistake

ERP isn’t about servers or licenses. ERP is your operating model written in software. If the people who run production, planning, purchasing, logistics, finance, and sales are not shaping it from the start, the system will mirror assumptions instead of reality. IT is essential, but business must lead, because business owns the outcomes.

When ERP sits only inside IT, the RFP (Request for Proposal) turns into a feature checklist instead of a clear description of how the company actually works. “Go-live” becomes the success metric, while the business cares about OTD (On-Time Delivery), inventory accuracy, days to close, waste, and margin. In that gap, vendors end up deciding the fine details of your processes, simply because someone has to.

Why Excel survives after go-live

Leaders sign a system to escape Excel. Few months later, Excel is everywhere. The reasons are practical, not emotional.

The standard flow rarely covers messy exceptions like rush orders, rework, substitutions, partial shipments, or returns, so teams keep side trackers. Decision-makers need views the ERP doesn’t provide; they export and rebuild the report. ERP data might refresh at end of day, while the team needs a live list for this morning’s work. Early data quality issues break trust, so people keep a “golden spreadsheet” as a safety net. And when it takes ten clicks across several screens to do something that takes seconds in a table, users choose speed.

This isn’t resistance to change. It’s a design problem. If a system doesn’t support real work at real speed, people keep the tools that do.

The vendor’s basic package

Vendors are very good at sales. The basic package looks affordable and demos look perfect. But the basic package is usually a skeleton: generic processes, generic data, basic reports, minimal integrations. Everything else—approvals, alerts, exceptions, dashboards, interfaces—arrives later as paid changes. With unclear requirements or late involvement of key users, the total cost rises quickly. This isn’t bad faith; it’s the model. A vendor’s job is to sell software. Designing your business is your job.

Where failure starts

Most problems begin before anyone configures a single field. The company hasn’t mapped its core flows end to end: order to cash, procure to pay, plan to produce, record to report. Key users aren’t co-designers; they are invited late to UAT (User Acceptance Testing). Outcomes are vague: there are phases, but not targets like “close in five days” or “improve OTD by five points.” Contracts are imprecise, pushing everything into chargeable change. Master data ownership is unclear. Governance is slow and reactive, with decisions bouncing from meeting to meeting. These are pre-implementation issues, which is why failures start before day one.

Make ERP a business product

Treat the system as a product the business owns, not a project that IT executes alone. Give one accountable Product Owner from the business—operations, finance, or supply chain—who can make trade-offs fast. Bring supervisors, planners, controllers, and buyers in as co-designers early, not just as testers. Tie the roadmap to outcomes: shorter close, better OTD, higher inventory accuracy, fewer manual entries. Review working software every two weeks with real data and real users. Let the system speak for itself, not just slides. Define “done” as adoption and KPI (Key Performance Indicator) movement, not “ticket closed”.

Do the hard work up front

Before choosing a vendor, run a few focused workshops with process owners and key users. Capture how work really flows today. List the decisions people make and when they need data—real-time, hourly, daily. Catalogue common exceptions instead of pretending they don’t exist. Draft a short data dictionary with critical fields, definitions, and ownership.

These simple artifacts become your operating model pack. They ground the RFP, shape the demos, and reduce expensive “discoveries” later.

Write the RFP like a business

Describe how your company runs, not just what features you want. Use short scenarios: “A planner builds a feasible plan under capacity limits.” “A shift supervisor escalates a quality issue with photos and lot tracing.” Separate must-haves from nice-to-haves and add acceptance criteria: “Available-to-promise by 10:00 daily, including backorders.” Attach sample data so vendors feel the complexity. Define integration boundaries and which system is the source of truth for items, customers, suppliers, bills of materials, and the acceptable data latency. Add simple mockups of the reports leaders will use to decide. Keep everyone focused on outcomes, not checkboxes.

Negotiate to protect the business

A clear contract prevents the endless change-request cycle. Fix the fee for must-haves, tied to acceptance criteria. Cap the rates for changes and include a price catalog per workflow, report, and interface. Allow a small discovery buffer to avoid nickel-and-diming. Require knowledge transfer: train-the-trainer, admin manuals, and environment access. Clarify data migration responsibilities and cycles. Secure exit rights so you can access your data and configurations if you move on. The goal isn’t to squeeze the vendor; it’s to align incentives and keep control.

Plan a real exit from Excel

You won’t kill Excel on day one. Be honest and plan it. List the top spreadsheets by decision criticality. For each, decide whether to replace, integrate, or retire later. Build simple self-service views for real users: filter, export, refresh. Set retirement dates for parallel files and name owners who will switch them off. Track progress publicly and celebrate every spreadsheet you retire. This keeps momentum and reduces frustration.

Design for adoption

Users don’t resist change; they resist friction. Make screens role-based with smart defaults. Reduce clicks for common tasks and write clear error messages. Hold a short weekly forum where users show a problem, see a fix, and agree on the next improvement. Protect time for learning and data cleanup; if leaders don’t free up capacity, adoption becomes unpaid overtime. Recognize teams that retire legacy spreadsheets or hit adoption milestones. Adoption is not a training event. It is a design choice and a management duty.

The costs you avoid

Doing the work above cuts the biggest hidden costs: repeated change requests, integration surprises, custom reports that never end, retraining because workflows don’t match reality, and long-term ERP plus Excel in parallel. It also accelerates the wins that matter: a faster close, better service levels, fewer stockouts, less rework, clearer planning, higher OTD.

Five rules to avoid extra work

• If a meeting doesn’t make a decision, cancel it.
• If a report doesn’t change a behavior, drop it.
• If a feature doesn’t move a KPI, it’s not a must-have.
• If users still need Excel, find the reason and fix that.
• If you can’t name a business Product Owner, you’re not ready.

A note on smart and AI-enabled systems

The smarter a system claims to be, the more clarity you need. Define the decisions it will automate or recommend, the data quality it requires and who owns it, the exceptions that stay human, and who governs model or rule changes. Smart systems amplify your culture. If processes are unclear and data ownership is fuzzy, smart will make confusion faster and more expensive.

Conclusion

ERP can be your backbone, a shared source of truth that reduces manual work and helps people decide faster. Or it can become your cage, an expensive system that pushes teams back to spreadsheets and heavy data entry.

The difference is decided before day one. You can buy a basic skeleton and hope it grows organs, or you can bring a clear operating model and ask vendors to encode it. Treat ERP as a business product. Put process owners and key users in charge. Define outcomes. Write the RFP like a business. Negotiate a contract that keeps you in control. Design for adoption. Plan a realistic exit from Excel. Do that, and you won’t just implement software; you’ll build a system that works the way your company works.