Business Process Authority During ERP Transformation
Most ERP transformations do not fail on technology. They fail because no one designed how people would actually work inside the new system. I was the person who designed that.
Every ERP transformation is two projects wearing one name.
Most data governance is designed for the people who read the data. I design for the people who enter it.
If doing it correctly costs more than the workaround, the workaround wins.
The system goes live on a date. The organization transforms over time.
Every ERP transformation is two projects wearing one name.
The first project is technical. It has a budget, a vendor, a plan, and a date.
The second project is the work itself. How a planner builds a routing. How a buyer releases an order. How Finance trusts a number that came out of a system nobody trusted last quarter.
The first project has hundreds of people assigned to it. The second has no one.
I can see it in the first meeting. Everyone is talking about configuration. Nobody is talking about how the work gets done the day the old system is turned off.
The gap does not stay a gap. It compounds.
Configuration decisions get made by whoever happens to be in the room that day. Those decisions become the shape of the work for the next decade, and the people who will live inside them were never asked.
Data integrity gets scheduled as cleanup. It is not cleanup. It is the foundation. A bill of materials that is wrong in the legacy system is wrong in the new system on day one, and now it is wrong at speed.
Decision rights stay undefined until a conflict forces the question, and by then the conflict has already answered it.
So the system goes live and the organization keeps working the old way inside new screens. Workarounds appear. Spreadsheets return. Finance stops trusting the number. What was funded as a transformation delivers a migration.
Most data governance is designed for the people who read the data. I design for the people who enter it. That is how the readers get what they asked for.
Finance needs an accurate cost. Planning needs a reliable lead time. Those requirements travel backward and arrive as new fields on the screen of a planner who was never in the room and whose shift target did not change. Accuracy becomes someone else's unpaid work. That is where the data breaks. The expected outcomes never arrive, because the decision was made without foresight.
Business process authority is a role, not a title. One person owns how the work happens, separate from the person who owns how the system is configured. Configuration serves process. Never the reverse. That takes five conditions.
Every one of them has to be set before the build. None of them can be added after the date.
Authority before configuration
Every process area gets a named owner with the power to decide, before the first design workshop opens. Ambiguity in the room becomes ambiguity in the build, and the build is what people live inside for a decade.
The standard is set at both ends
The function that consumes the data and the person who enters it define it together, in the same session. A definition written by consumers alone is a burden at the source, and burden at the source produces bad data faster than any report can catch it.
Accurate entry is the cheapest path
If doing it correctly costs more time than the workaround, the workaround wins, every time, in every plant. I design the entry conditions, not just the reporting requirement.
One place the number lives
A single source of truth chosen early and defended. Everyone else reads from it. When the same number lives in two places, people spend their time reconciling instead of deciding.
Governance handed over before the date
The project team disbands. The rules cannot. Ownership, cadence, and escalation paths move to the operating organization before anyone celebrates.
A multi-site enterprise operation, migrating a legacy ERP to SAP.
I held business process authority for bill of materials, routings, and capacity planning. The work crossed two countries and two manufacturing cultures, and every condition above was tested against a fixed date.
50 teams across the United States and Germany
Sites that had never shared a definition of a routing agreed to one, with the planners who enter the data in the room when it was written.
The date, or the data. I argued for the data.
Two integrity campaigns could have been deferred until after go-live, which was the faster path and the one usually taken. A wrong bill of materials becomes a wrong cost, and a wrong cost becomes a decision somebody makes with confidence. Both campaigns closed before the date. The date held anyway.
A single source of truth established in SAP
Finance gained COGS accuracy the legacy environment could not produce, which changed what leadership was able to ask of the business.
Governance models handed to the business before go-live
Ownership, cadence, and escalation named and staffed. Still governing the work after the program closed and the team dispersed.
On-time go-live with reduced adoption risk
Cross-functional stakeholders guided through enterprise-wide change, and the work still belonged to them on the other side.
The industry was manufacturing. The problem was not. Any organization running multiple sites, a real supply chain, and a finance function that has to close on time inherits this exact gap, whether it makes aerospace components or lip color.
Finance, plant operations, demand planning, and data architecture, in one room. Current state and future state had to be mapped for senior leadership. The meeting opens and nobody starts.
So I start. Where we are. Where we need to be. The one decision this meeting has to produce, and the requirements that decision has to satisfy. I write it, I clean it, and I put it in the chat before we leave the room.
Then the room moves.
I was the subject matter expert in that room before it started. That is earned in advance, on what you have said and whether it moved anything. What I did in the meeting was simpler than expertise. I removed the ambiguity four functions had been standing still inside.
At the end they said they could not carry the people through the transition, and they looked at me. I took it, and I designed the sustainment that held after the date.
The system goes live on a date.
The organization transforms over time.
That gap is where I work.
Davenport, T. H. (1998). Putting the Enterprise into the Enterprise System. Harvard Business Review, 76(4), 121 to 131.
Markus, M. L., and Tanis, C. (2000). The Enterprise System Experience: From Adoption to Success. In R. W. Zmud (Ed.), Framing the Domains of IT Management. Pinnaflex Educational Resources, 173 to 207.
Ross, J. W., Weill, P., and Robertson, D. C. (2006). Enterprise Architecture as Strategy. Harvard Business School Press.
