One of the interesting things about working across different ERP transformations is realizing that the technology is often the least surprising part. Systems behave more or less the way systems behave. They require configuration, testing, data, integrations, training, and a healthy tolerance for meetings with acronyms. What varies dramatically is the organization surrounding the technology, and I have become increasingly convinced that an ERP implementation is one of the most effective organizational stress tests a company can put itself through.
We usually assess ERP readiness by looking at technology, resources, data, timelines, scope, and whether the organization has enough people available to participate in the project. Those things obviously matter, but there is another kind of readiness that is much harder to put into a project plan. How does the organization make decisions? Who actually owns the business processes? What happens when two departments disagree? Can leadership establish a direction and have the organization move together, or does every decision begin another round of negotiations? You can buy excellent software and hire excellent people, but eventually the implementation is going to ask those questions whether you are ready for them or not.
I have recently had the opportunity to experience transformations in organizations at very different levels of organizational maturity, and the contrast has been fascinating. In one environment, getting everyone moving in the same direction could become a project within the project. Ownership was not always clear, processes had evolved differently across the business, and decisions could depend heavily on the individuals involved. The ERP implementation did not create those conditions, but it certainly gave them a very large conference room in which to introduce themselves.
In another environment, I have watched a transformation begin with people remarkably aligned around where the organization is going. There are still questions, competing priorities, and undoubtedly plenty of challenges ahead because apparently nobody has invented the ERP implementation where everyone agrees about everything and goes home early. The difference is that the organization has mechanisms for dealing with those challenges. People understand their roles, leadership is aligned, governance exists, and there is a shared expectation that decisions ultimately need to move the organization forward.
That contrast has made me think differently about what organizational maturity actually means. It does not mean having more policies, more approvals, or enough governance documents to require their own SharePoint administrator. A mature organization can still be entrepreneurial, move quickly, challenge decisions, and change direction when new information emerges. The difference is that it knows how to convert disagreement into decisions and decisions into coordinated action.
ERP implementations expose this because they force an organization to make thousands of interconnected choices about how the business actually operates. Suddenly, it is no longer enough for Finance to have one understanding of a process while Operations has another and someone in IT quietly keeps both versions functioning through an integration nobody wants to touch. The new system wants an answer. Who owns the process? What is the standard? Who approves the exception? Which data is correct? Somewhere along the way, someone usually discovers that the answer to at least one of those questions is, “Well, it depends,” which is rarely the comforting response an implementation team was hoping to hear.
That is why I think struggling ERP projects are sometimes diagnosed too narrowly. We look at testing delays, unresolved decisions, process gaps, resource constraints, resistance, and governance issues as separate project problems. Sometimes they are. But when several of them appear together, I wonder whether the implementation is actually showing us something much bigger about the organization itself.
The danger is blaming the implementation for everything it exposes. When decisions repeatedly stall, we can blame the project methodology. When departments cannot agree on a process, we can blame the system design. When ownership is unclear, we can create another RACI and hope that this particular spreadsheet possesses powers the previous spreadsheets did not. Sometimes those interventions are necessary, but sometimes the project is simply revealing how the organization has always operated.
This does not mean mature organizations have easy ERP implementations. They absolutely do not. Data will still be messy, requirements will change, testing will uncover surprises, and somebody will inevitably discover a critical scenario approximately seventeen minutes before a meeting in which everyone was hoping to declare victory. Organizational maturity does not eliminate complexity. What it provides is the ability to respond to complexity without the organization itself becoming part of the problem.
An ERP implementation can replace technology, standardize processes, improve data, and create entirely new capabilities, but it cannot manufacture organizational maturity simply because the project plan says it should exist. That work belongs to leadership, and ideally it begins long before anyone starts configuring the software.
Maybe that is one of the most useful things an ERP transformation gives an organization. Long before the new system produces its first report, the implementation has already produced something valuable: a remarkably honest picture of how the organization behaves when the pressure is on.
