There is a moment on every ERP programme when a decision needs to be made — a process will work this way and not that way, this field is mandatory, this region conforms to the template or is granted an exception — and the room goes quiet. Not because no one has an opinion, but because no one is sure whose opinion is binding. That silence is the most expensive sound in enterprise transformation, and it is entirely avoidable. It just has to be dealt with before design, not during it.
Decision rights are the plumbing of a programme. When they are clear, the work flows; when they are ambiguous, everything backs up behind the question of who is allowed to turn the tap. And ambiguity is the default state, because the parties in the room each have a reason to assume someone else is holding the pen.
The five decisions that need an owner
Before you design anything, five kinds of authority have to be named — with a person attached, not a committee, and with the explicit power to say no.
Authority that must be assigned first
- Process authority — who decides how the business will actually run, end to end
- Data authority — who owns master data definitions and the right to change them
- Template authority — who grants or refuses a deviation from the global design
- Funding authority — who can approve a scope change and the cost that comes with it
- Release authority — who decides that something is ready to go live
Why the integrator can't hold these for you
A good systems integrator will advise on all five, and a great one will push you to decide them. But none of the five can actually belong to them, because every one is a statement about how your business will operate and where your money goes. When a client leaves these decisions to the delivery partner by default, two things happen. The operating model ends up shaped by the template's path of least resistance rather than by deliberate choice, and the client loses the ability to hold the partner to account — because you cannot independently judge a decision you never made and cannot reconstruct. Ownership is not a governance nicety; it is the precondition for accountability.
You cannot hold a delivery partner to a decision you never made. Ownership is the precondition for accountability, not a governance nicety.
Committees decide slowly; programmes need decisions daily
The instinct is to route decisions to a steering committee. But steering committees meet monthly and deal in escalations, while a live programme generates binding choices every day. If the daily decisions have to wait for the monthly forum, they don't wait — they get made informally, in configuration, by whoever is unblocked enough to move. The design then reflects a thousand small defaults nobody consciously chose. The fix is not more governance meetings; it is naming, per domain, the individual who can decide in the moment and be answerable for it afterwards.
Write it down before you need it
Decision rights that live in people's heads evaporate under pressure — which is exactly when they matter. The programmes that hold together are the ones where each of the five authorities has a name against it in writing before design begins, where a deviation from the template leaves a record of who approved it and why, and where a "yes" to new scope is logged as a decision with a cost, not absorbed as a favour. None of this is bureaucracy. It is the difference between a programme you can steer and one that steers itself into the nearest wall.
Where we sit. Roltrader's delivery layer, Orchestra, exists to make decision ownership visible — every binding choice logged, owned and linked to the work it drives — and our assurance layer checks that what shipped matches what was decided. But the principle stands with or without us: settle the five authorities before design, attach a name to each, and write them down. The quiet room is a choice you can decline.