A manufacturer can complete every task on the implementation plan and still watch the whole thing come apart in the first month after go-live. ERP readiness, the real kind, was already decided long before that. The data was migrated. The training sessions happened. The test scripts passed. And yet three weeks in, production teams are back on whiteboards, inventory gets keyed in after the fact, and the finance team spends its days validating numbers instead of trusting them. The software works. The operation doesn’t. This is the quiet failure mode that no status report predicts, and it has almost nothing to do with the system itself. It lives in a set of operating decisions most manufacturers postpone until it is far too expensive to make them well. This article is about those decisions, and why they quietly determine everything that follows configuration.
Here is the short version. ERP readiness before implementation means your organization has already decided who owns each process, how work will actually be executed on the floor, and what happens when the exceptions hit, before a consultant ever translates any of it into system logic. Configuration is not where those answers get created. It is where they get enforced. When the answers exist, configuration is fast and the system holds under pressure. When they don’t, the implementer configures around assumptions, and every unmade decision becomes a defect that surfaces later: on the shop floor, in the month-end close, or in a reconciliation that suddenly no longer ties out.
Why “Ready” Usually Means “Tasks Completed”
Most readiness assessments measure the wrong thing. They track what has been finished: data migrated, users trained, test cycles run, go-live date confirmed. All of it feels like progress because it is visible and easy to put in a report. None of it tells you whether the business has actually agreed on how it will run day to day.
That gap is subtle, which is exactly why it hides so well. A project can be green on every milestone and still be built on sand. Consider two plants inside the same company, both recording inventory transactions in the same new system with the same configuration. In one plant, a receipt is logged the moment material hits the dock. In the other, it is entered at the end of the shift, sometimes the next morning. Same software, same setup, two completely different sets of numbers flowing into the same reports. No test script catches this, because the script only checks that a transaction can be recorded, not whether everyone records it the same way at the same time.
This is the core misunderstanding worth naming plainly. When ERP is treated as a project, readiness becomes a phase inside that project, something you complete and move past. But an ERP is not a project you finish. It is the operating system you run the business on. And you cannot run a business on decisions nobody actually made. The checklist confirms the system is installed. It says nothing about whether the organization is prepared to operate inside it.
The Decisions Configuration Can’t Make For You
A configuration console can set approval limits, define a workflow, and map a field to a screen. It cannot decide who is accountable when two departments disagree about a number. It cannot tell you whether “close enough” is acceptable on the shop floor. It cannot invent standard work where none exists. Those are business decisions, and they have to be made by the people who run the operation, not quietly encoded by an implementer guessing at what you probably meant.
Three decisions matter most, and manufacturers routinely defer all three until the build forces the issue. The first is ownership: who is accountable for the accuracy of each master record and each process, not in principle but by name. When no one owns the truth, everyone maintains their own version of it, and the system faithfully inherits every contradiction. This is precisely why the question of who really owns the truth inside your organization has to be settled before configuration, never after.
The second decision is standard work: the agreement that a given task is done one way, by everyone, every time, not five ways depending on who is on shift. The third is exception handling, which is where most operations quietly break. What happens when reality refuses to follow the process, because it always eventually does? A late inbound shipment, a partial receipt, a rush order that jumps the queue. If there is no shared answer, each person improvises a reasonable-looking workaround, and the data fragments in a hundred small, invisible ways. Configuration can support any of these decisions beautifully. It can never substitute for them.
What Unmade Decisions Actually Cost
This is not a soft cultural concern that lives in a change-management slide. It shows up in money and time with brutal consistency. A 2026 organizational-change study found that human and process factors weigh roughly six times more heavily than technical factors in whether an ERP delivers its promised value. Read that again slowly: the part most projects under-resource is the part that most determines the outcome. A separate 2026 implementation analysis found that companies which skip serious strategy and readiness work watch their timelines run two to three times longer than projected. The rush straight to configuration is, reliably, the slowest possible path to a working system.
The failures scale right along with the company. Zimmer Biomet, a global medical device manufacturer with roughly eight billion dollars in annual revenue, filed a $172 million lawsuit over an ERP program meant to consolidate nine legacy systems. The widely reported problem was not that the software could not technically do the job. It was governance and readiness: the decisions, ownership, and validation that were never locked down before the build began. When a company that size can lose that much, the lesson for a mid-sized manufacturer is not “we are too small for this to happen to us.” It is the exact opposite. The same fault line runs through smaller projects; it simply produces quieter write-offs instead of headlines. On its own, leaving vague objectives unresolved past design sign-off can inflate a project’s timeline and cost by fifty percent or more.
Readiness Doesn’t Belong to IT
Here is where operations leadership has to step forward, because readiness is often quietly handed to IT, and IT cannot own decisions it has no authority to make. IT can stand up the environment, manage the migration, and validate that the system behaves. It cannot rule that a specific manager owns bill-of-material accuracy, or that the receiving process works one way across every plant. Those calls belong to the people who run production, planning, and finance.
When readiness is framed as a technical workstream, the organizational decisions fall into a gap. Everyone assumes someone else is handling them, so no one does, and the project sails through its milestones with the hardest questions unanswered. The manufacturers who get this right treat readiness as an operating discipline led from the business, with IT as a partner rather than the owner. Weak adoption almost always traces back to this exact gap, which is why user adoption is so often the number one reason ERP investments fail. People do not reject a system because it is unfamiliar. They reject it because it was configured around decisions they were never asked to make, so it does not match how the work truly happens.
The Work That Actually De-Risks a Rollout
The fix is not more documentation for its own sake. It is making the real decisions early and treating that as the actual project. Experienced teams now recommend spending ten to fifteen percent of the total budget on genuine pre-implementation work: mapping how the operation actually runs, cleaning and governing the data, and assigning clear ownership before a single module is touched. That data point deserves emphasis, because ERP data hygiene is a board-level issue long before it is a technical chore. A system fed inconsistent bills of material and outdated cost assumptions will calculate margins that look precise to the decimal and mean almost nothing.
Map the real workflow, including the exceptions and the informal shortcuts people actually use to keep things moving, and you transform configuration from guesswork into straightforward translation. This is the shift from configuration to capability, the difference between a system that mirrors your intentions and one that quietly bleeds value because it was built on convenient assumptions. Done properly, the payoff is measurable, not theoretical. Manufacturers that modernize on a genuinely solid foundation report operational cost reductions in the range of five to twenty-five percent. The foundation is the decisions. The software only executes them.
Before You Configure Anything
Here is the test worth applying before your next implementation begins. Ask whether your organization could describe, without hesitation and without contradicting itself, who owns each core process, how each critical task gets done, and what happens when something goes wrong. If those answers come quickly and consistently across the room, you are ready, and configuration will move fast because there is nothing left to guess. If the answers stall or splinter, no amount of technical skill will rescue the rollout, because the implementer will be building on top of disagreements you never resolved.
The manufacturers who succeed with ERP are rarely the ones with the most advanced software or the most aggressive timeline. They are the ones who did the uncomfortable, unglamorous work of deciding how the business would run before they asked a system to run it. That work forces a kind of clarity most organizations avoid until they have no choice. It is also the single thing that most reliably separates the go-lives that hold from the ones that quietly unravel in week three. Start there, and configuration becomes the easy part.
