Nobody Owns an ERP Program. The Decision Chain Does.

This article closes the three-part series "The Real Point of Failure." The first piece argued that ERP programs fail in the decision chain, not in the technology. The second showed what a governance that actually decides is built from. This one answers the question both of them left open: who owns the chain.

If governance is a chain of decision, then who actually owns the program? Ask a room of executives that, and the instinct is to look for a single neck. One person to hold accountable, one name at the top of the org chart, one throat to choke when it all goes wrong. It fits on a slide.

It's the wrong question. Reaching for a single owner is usually the first step toward a program nobody really owns.

A program doesn't belong to a person, it belongs to a chain of roles, a sequence where each role decides on its own patch and then hands off to the next. The failure of ownership is almost never an empty chair at the top. It's a role that swallows the ones around it, or a role that quietly isn't there at all. I've seen both, and they break a program in mirror-image ways.

When one role eats the others

Start with too much. On one program the business side, the functional owners who also held the budget, were expected to sign off on every design and every business decision the program produced. All of it ran through them.

Two things happened, both obvious in hindsight. They became the bottleneck first of all, because nothing could move toward arbitration until they'd personally blessed it, and there's only so much one direction can review before the whole program is queuing behind their calendar. The second effect was worse. Their weight grew so dominant that by the time anything reached the arbitration committee, there was nothing left to arbitrate. The choices had already been made upstream. The committee's job shrank to formally validating decisions that were settled before the meeting even started, which is the exact theater I described two articles before, an arbitration body with no real power to rule. Except this time it wasn't caused by who funded the program. It was caused by one role being allowed to occupy the space that belonged to the whole chain.

That's the tell. When a single role has to touch everything, every decision queues at one point of passage, and the roles downstream are left with nothing real to decide. The chain collapses into a waiting line, and the arbitration at the end becomes a rubber stamp.

The chain that actually owns the program

So if no single role should own it, what does? The sequence does. And the order of that sequence matters, because the whole point is that a decision travels and changes shape as it moves from one set of hands to the next.

It starts with the business teams. Their job is to state what they actually need and how they actually work, the concrete requirement, and then to stop. They don't get to design the solution. The moment business teams start specifying the how, the chain is already bent out of shape.

The requirement passes next to the MOA, the functional owners who frame it and validate it. This is the role that filters out the far-fetched, the requests that are really just old habit dressed up as need. It's also where harmonization happens, where rules that differ pointlessly from one direction to another get pushed toward a common standard before they harden into the build.

From there it reaches IT, whose job is to hold the need up against the standard first, the fit-to-standard reflex, and then to lay out two or three ways to deliver it. Most standard to most custom, each one carried with its effort, its risks, and a timeline. Not a single option to approve. A genuine choice.

And only then does it land with the arbitration committee, ideally independent of the program, which picks an option. That's the handoff that closes the loop.

Around this sequence sit the roles that support it without being it. The program sponsor arbitrates the big calls, leans in when a direction outside the program is blocking it, and negotiates budget extensions when they're needed. The program director, who should come from IT for the architectural judgment the job demands, runs the milestones, the staffing, the delivery risk, and carries the budget day to day with the sponsor backing him regularly. The business process owner directors sit opposite the program director as guardians of the management rules the solution has to honor. These roles matter. But they orbit the chain, they don't replace it. And notice that none of them holds the budget the way the failed program's business owners did. The money sits with a dedicated arbitration setup and a sponsor who backs the program director, not with the people originating the demands.

When a role quietly goes missing

Now the mirror image. The role most often missing from an ERP program is the MOA, and it's the one whose absence does the quietest damage.

A MOA function gets underestimated and left out all the time. Programs staff the business teams, they staff IT, they appoint a sponsor, and then they assume the framing of needs will somehow take care of itself in the gap between the business asking and IT building. It won't. With no MOA, nobody filters the far-fetched requests before they hit IT, so they arrive raw and get costed and argued over as if they were real requirements. And nobody is pushing the different directions toward common management rules, so the program quietly piles up divergence that surfaces later, at considerable expense.

Put the two cases next to each other and the point is hard to miss. In the first, the business framing role had too much power and choked the chain. In the second, the same kind of framing role is missing and the chain runs with no filter at all. Same function, opposite mistakes, same outcome: the sequence breaks. What matters isn't how much authority any one role carries. It's whether the chain is complete and in balance.

The decider of last resort is not the owner

There's one objection worth heading off, because it's the natural misreading. If decisions travel through a chain, who breaks a tie? Something has to give someone the final word.

Something does. When the chain genuinely deadlocks, the call goes up, to the program sponsor, the CIO, sometimes the CFO. That authority is real and it has to exist. But it's a circuit breaker, not an owner. You pull it when something has tripped, not as a way of running the house. A program where the sponsor or the CIO is deciding things every week isn't a well-governed program with a strong hand at the top. It's a program whose chain has stopped working, so every contested decision escalates. The goal is a chain that resolves almost everything on its own, which leaves the last-resort decider as something you rarely have to reach for. The less you see them decide, the healthier the chain.

What this means for an IT leader

So don't go hunting for the single owner. There isn't one, and the hunt tends to produce exactly the strangled chain it was supposed to prevent.

Look at the chain instead. Is every role actually present, the MOA above all, the one everyone forgets? Is any single role allowed to swallow the others, the way a budget-holding business function will if you let it? Does a requirement genuinely travel the chain — business states it, MOA frames it, IT turns it into options, arbitration picks one — or does it short-circuit somewhere along the way? And is your last-resort decider truly a last resort, or are they signing off on something every week?

Get the chain complete and in balance, and the program has an owner. The owner just isn't a person. It's the sequence.

Which is what finally lets us move from how a program is governed to what it actually has to decide. The first of those decisions lands before anyone writes a line of configuration, and it's the one most programs get wrong right at the start. That's where the next article goes: Big-Bang or Phased: The False Debate That Hides the Real One.

---

If you want a second pair of eyes on your program's role setup — who decides what, where the chain might break, and whether your MOA actually exists — reach out.