The software selection is done. The vendor is chosen. The contract is being reviewed by legal. Everyone is relieved that the hard part is over.
It isn’t. In most cases, the hard part hasn’t started.
The decision to implement a new ERP — or to reimplement an existing one, which carries its own distinct risks — is one of the most consequential operational commitments a mid-market manufacturer can make. It touches every function, disrupts every workflow, and demands organizational behavior change at a scale most leadership teams significantly underestimate. And yet the vast majority of implementations proceed with the technology selection as the primary focus and the people and process work as an afterthought scheduled for sometime after go-live.
That sequencing is exactly backwards. And the data on what happens as a result is unambiguous.
What the Numbers Actually Say
Discrete manufacturing ERP implementations fail to meet their objectives at a rate of 73%, according to Panorama Consulting Group’s 2025 ERP Report — the highest failure rate across all industries. The top three causes account for more than 75% of those failures: inadequate change management, poor data migration, and inexperienced implementation teams. None of these are technology failures. All three are organizational failures that were entirely predictable and entirely preventable. (Panorama Consulting Group / Godlan, ERP Implementation Failure Statistics 2025)
Gartner’s projection is equally pointed: 70% of ERP initiatives will fail to meet their stated business goals by 2027. Not fail technically. Not fail to go live. Fail to deliver the business outcomes the investment was justified against.
The counterpoint is instructive. Among organizations that did succeed, 77% identified leadership support as the single most critical success factor. Sixty percent cited effective stakeholder communication as the key capability that separated their implementation from those that struggled. Neither of those factors appears in an RFP. Neither gets evaluated in a vendor demo. Both are entirely within the organization’s control — and both have to be built before the implementation begins, not discovered to be missing after it’s already in trouble.
The Process Problem Nobody Wants to Confront
Here’s what most manufacturers don’t want to hear before an ERP implementation: if your current processes are broken, a new ERP will not fix them. It will automate them, accelerate them, and make them more visible — but it will not fix them.
An ERP system is a codification of how an organization operates. Every configuration decision — how purchase orders get approved, how production schedules get generated, how inventory gets valued, how customer orders flow from entry to shipment — embeds a process assumption into the system. When those configuration decisions get made without a clear understanding of how the business actually operates today and how it needs to operate tomorrow, the result is a system that enforces the wrong processes with software-level precision.
This is the origin of the spreadsheet shadow systems that appear in virtually every underperforming ERP environment. Finance keeps a parallel spreadsheet because the system’s inventory valuation doesn’t reflect how the business actually costs products. Operations maintains a separate scheduling board because the system’s production planning doesn’t account for the floor constraints the planners manage manually every day. Sales builds its own reporting because the ERP’s customer data doesn’t match the way the sales team organizes its book of business.
Each of those shadow systems is a process gap that wasn’t resolved before go-live. And each one represents a portion of the promised ROI that will never materialize.
The work required to prevent this is not glamorous. It involves sitting in rooms with the people who actually do the work — not the people who manage those people, but the people who execute the transactions — and understanding with granular specificity how work actually flows today. Where does data get entered twice? Where do manual workarounds substitute for system capability? Where do different departments operate from different versions of the same data? Where does institutional knowledge substitute for documented process?
That inventory of operational reality is the foundation on which a successful implementation is built. Without it, the implementation team is configuring a system to support a business they don’t actually understand.
The People Problem That Starts Before the Contract
Organizational resistance to ERP implementation is both predictable and rational. The people being asked to change how they work every day — sometimes dramatically — are being asked to bear a significant personal cost in service of a business benefit they may not fully understand and may not personally experience. The warehouse manager who has spent fifteen years developing expertise in working around a legacy system’s limitations is not being irrational when she views a new system with skepticism. She’s protecting the operational competency she’s built.
The mistake most organizations make is treating that resistance as a communication problem to be managed rather than a legitimate signal to be understood. When experienced operational people push back on an ERP implementation, they are often pointing at real process misalignments, data integrity problems, or configuration choices that will create exactly the kind of operational friction they’re worried about. The organizations that listen to that feedback before go-live avoid the problems. The ones that override it discover the feedback was correct about six months after launch.
The implication is that people alignment has to start before vendor selection — not after contract signing. The employees who will use the system daily need to be part of the requirements process, not briefed on the requirements after they’ve been written by a consulting team. Their operational knowledge is the most important input into what the system needs to do. Their early involvement is also the most effective change management tool available, because people who shaped a decision are fundamentally more committed to making it work than people who had a decision handed to them.
This isn’t naive idealism about participatory management. It’s a practical observation about what drives adoption. The research is consistent: implementations where frontline users were involved in the design process achieve materially higher adoption rates than those where they weren’t. The time invested in early engagement pays back in implementation velocity and post-go-live stability.
The Leadership Question That Has to Be Answered First
Before any ERP implementation begins — before vendor selection, before requirements gathering, before budget approval — there is one question that leadership has to answer honestly: who owns this?
Not in the project management sense of who is the implementation lead. In the authority sense. Who has the organizational mandate to make binding decisions about process design when operations, finance, and IT disagree? Who can tell a department head that their preferred workaround is not going to be accommodated in the new system? Who can escalate to the executive team when a scope decision is heading in the wrong direction?
ERP implementations involve legitimate competing interests. IT focuses on system integrity and technical architecture. Operations prioritizes production continuity and schedule stability. Finance protects reporting accuracy and compliance requirements. External implementation consultants are focused on milestone delivery and contract terms. Without a clearly designated decision authority with genuine organizational mandate, those competing interests get resolved through negotiation and compromise rather than through principled process design. Configuration choices reflect political accommodation rather than operational logic. Accountability for outcomes becomes diffuse.
The organizations that navigate this well don’t necessarily have the most sophisticated project governance structures. They have a senior operational leader — someone with deep credibility on the plant floor and in the boardroom — who has been given explicit authority to make implementation decisions and who is visibly committed to the outcome. That person’s engagement signals to the entire organization that this implementation is a strategic priority, not an IT project.
When that leadership engagement is absent or nominal — the executive sponsor who attends the kickoff meeting and the go-live celebration but nothing in between — the implementation team is operating without the organizational authority to resolve the conflicts that will inevitably arise. And they will arise.
What the Pre-Work Actually Looks Like
The people and process work that has to happen before a successful ERP implementation isn’t a single initiative. It’s a sustained organizational effort that typically takes three to six months before the implementation clock starts.
It begins with an honest current-state assessment — not a consultant-led gap analysis, but a genuine operational inventory that documents how work actually flows today, where the process breaks are, and what institutional knowledge is substituting for system capability. That assessment surfaces the decisions that have to be made before configuration begins.
It continues with process design work that answers the question of how the business needs to operate after go-live — not how the software works, but how the business works, with the software supporting it. That design work has to involve the people who will operate the processes, not just the people who will configure the software.
It culminates in a readiness assessment that evaluates not whether the organization has selected a good system, but whether the organization is genuinely prepared to adopt it. Is the data clean enough to migrate? Are the processes documented well enough to configure? Is the change management infrastructure in place to support adoption? Is the leadership engagement real and sustained?
Most organizations skip this work because it’s slower, less tangible, and harder to invoice than software configuration. The ones that do it produce implementations that go live on time, stay within budget, and deliver the business outcomes the investment was justified against. The ones that don’t produce another data point in the 73% failure rate.
The vendor selection is not the hard part. It never was.
Sources:
– Panorama Consulting Group / Godlan, ERP Implementation Failure Statistics: 2025 Research — godlan.com
– Bluelinker ERP, 75 Must-Know ERP Statistics and Trends — bluelinkerp.com
– CE Interim, ERP Implementation Failures and How to Avoid Them — ceinterim.com
Independent editorial. No vendor relationships influence coverage.
Sources: