The Digital Operating Model: Who Decides What After the Transformation

The Digital Operating Model: Who Decides What After the Transformation

Two companies with the same strategy and the same systems can get different results. The difference is not necessarily execution quality. It is often something that has not been written down: who decides what, when a decision escalates, and who can stop a phase.

Operating-model work can stall when there is agreement that the structure should change but no record of which decision moves to whom. The map below addresses that question for one journey and can be used to draft an initial version in a focused session.

A decision rights map

AY prepared this six-row map for this guide and presents it for you to complete. Its compact format is intended to make it easier to use and revisit. Fill it for a single customer journey or one core process:

Two rules help make the map usable. The third column should be completed by whoever holds the decision today, not by the proposed future owner, so the transfer is explicit rather than merely suggested. Give the last row particular attention: if the authority to stop a phase is unclear, delivery may continue without an agreed decision point.

What you do once it is filled: rows where columns two and three differ identify potential changes. If none differ, verify whether the current operating model is the constraint or whether the problem sits elsewhere.

Start with one journey, not an org chart

Designing the whole enterprise at once may produce a diagram that is difficult to apply. Choosing one journey — who owns it, who decides what within it, which systems support it and what is measured — produces something that can be tested against real work.

Choose the journey using three criteria: clear commercial impact; it crosses at least two departments, so coordination can be tested; and it has an executive sponsor willing to review decision rights. The third criterion may be difficult to satisfy, so confirm it before work begins.

Three reasons this can be preferable to a full redesign: it can produce a visible result early, test the design before wider adoption, and allow the work to be paused if needed. The second journey benefits from the first, because the standards and governance built for it are reused.

Centralised, distributed, hybrid — and where each one breaks

The shape is not merely a management preference. It is a trade-off between consistency and speed, and each shape carries predictable operational risks:

What you do: if you choose hybrid, write the boundary explicitly: which decisions belong to the centre, which to the unit, and what happens when they disagree. Without a written rule for resolving disagreements, the model may become centralised in practice and distributed in rhetoric.

The factors that decide it in your organisation: how many genuinely different businesses sit under one entity, how much the customer base overlaps, how strong the central capability is in practice rather than only on paper, and how strict the requirements applicable to your data are.

Centralised suits an organisation that needs strict consistency and has a central capability able to keep up with demand. Distributed suits one whose units are genuinely different businesses with separate customer bases. Hybrid suits one that needs both in different places and can write down the boundary between them. There is no single arrangement that is correct for Saudi enterprises as a group — applicable requirements narrow the options in specific areas rather than dictating the whole structure.

Decision latency: the indicator that usually goes unrecorded

An operating model can directly influence an important indicator whose baseline may go unrecorded: how long an ordinary change waits for approval. Record it before redesign, even over a short observation period, because it is one useful signal of change in practice rather than on paper.

Alongside it, three indicators may be sufficient for an initial view: time from request to live change; share of work completed inside the designed process; and the number of parallel procedures.

The last measure can be especially revealing because it counts where people find it easier to work around the system — a spreadsheet kept beside it, an approval given over a messaging app, or a separate personal log. These workarounds may not be volunteered, so ask about them explicitly and without blame.

What leadership actually has to change

The common version of this advice is "leadership commitment matters", but that statement is too general to be actionable. Three specific things are what commitment consists of here:

Giving up a decision right visibly. When a sponsor assigns a row to a different accountable owner, it demonstrates that the transfer is real. This can reinforce the model more effectively than communications alone.

Working inside the model themselves. If an executive team repeatedly requests reports outside the designed process, employees may interpret the process as optional. Leadership behaviour and documented exceptions therefore matter alongside communications.

Changing what people are measured on. If a department continues to be measured by the old targets, employees may return to the old way of working. Adjust targets during the transition and review obsolete tasks when new ones are introduced.

Whether this sits with a chief digital officer or an existing executive matters less than whether the decision rights are written and supported by actual authority. A title alone does not establish ownership; the map should name the accountable decision holder.

Where the model touches technology, and where it does not

Two technology decisions belong to the operating model rather than to the technology function, because they are decision-rights questions wearing technical clothing:

• Who may define a metric. If more than one team can define the same figure, technology alone may not resolve the inconsistency. Row two addresses this by naming an accountable owner.
• Who may accept an exception to a control. Security and data-protection controls can generate exception requests. The model should define who may approve an applicable exception, under what conditions and for how long — row five.

Other choices — such as cloud platform, analytics stack or automation tooling — are usually separate design decisions. Bringing them into the operating-model discussion too early can distract from the decision-rights questions.

What you do with this: when a model discussion turns into a tooling discussion, ask which row of the map is being decided. If none, the discussion belongs in a different meeting.

When to review the structure, and when to review only the indicators

Review the indicators on a regular cycle. Review the structure when a defined trigger occurs, such as a material change in strategy, organisation, scale or core technology. Record the cycle and triggers when the model is approved.

Reviewing the structure too often may create costly churn; leaving it unreviewed may preserve a model designed for a company that has since changed. Define the review cycle and triggers in advance so that the distinction is applied consistently.

The adjacent decisions, and where they are made

• What am I buying, and what sets its price? The digital transformation services guide.
• Which of my existing systems do I keep, replace or retire? The digital modernization guide.
• How do I evaluate and compare transformation companies? The guide to choosing a transformation company.
• Do I build this capability in-house or buy it? The guide to choosing a transformation provider.
• How do I get this approved and funded internally? The transformation business case guide.

How AY works

In operating model work, the role that suits an external party is facilitation rather than adjudication: getting the decision holders around one journey and bringing the disagreement about authority into the open, in writing. Transferring authority is an internal executive decision and should not be issued by an adviser.

Examples are in our work, and the scope is set out in enterprise digital transformation.

One boundary worth stating plainly: a marketing partner can own the demand and experience layer within the model, and should not be the sole party designing decision rights across finance, operations and IT. Where a scope crosses that boundary, it belongs in the contract rather than being discovered during delivery.

Next step

Pick one journey, bring its owners into a focused workshop, and draft the map. Rows where columns two and three differ identify potential areas of work; rows where no one can fill column three may need an executive decision before technical work begins.

If the session cannot happen because ownership itself is unsettled, that is the point at which involving an outside party becomes useful. Talk to us about whether an assessment fits your case and what it would cover — the scope and outputs of any assessment are agreed before it starts rather than assumed in advance.