Every digital system needs this simple operating model

We saw many digital systems failing when nobody was quite sure who owned them.

A few months after the launch, the questions start arriving. Who approves this change? Who do we call when the integration stops syncing? 

In a lot of organisations, these get answered informally, in scattered emails. 

The missing piece is a better operating model. A clear agreement on how the system will be run after it goes live: how decisions get made, which data must be trusted, how changes are handled, who provides support, how adoption happens, and who is accountable for the whole thing.

Let’s see how you can go about it without overcomplicating things.

Key Takeaways

• A digital system is finished only when there is a clear agreement on how it will be run.
• An operating model doesn’t have to be a governance binder. It is a one-page set of rules of thumb covering six things: decisions, data, changes, support, adoption, and accountability.
• AI raises the stakes because it amplifies whatever operating model, or absence of one, you already have.
• The goal is clarity, so the system keeps delivering value after the vendor leaves.
• If you cannot name a person for each of the six areas, you do not yet have an operating model. You have a system and a set of assumptions.

What is an operating model?

An operating model is the agreement on how a digital system runs in daily life. It answers a simple question. Once this is live, how do we actually operate it?

• It helps to be clear about what it is not, because the phrase scares people.
• It doesn’t have to be a sixty-page document that gets opened twice a year.
• It is not an organizational chart.
• It is not a one-time responsibility matrix that looks tidy in a slide and means nothing by the next quarter.

Interestingly, even the analysts who sell governance frameworks now argue against the heavy version. Gartner notes that traditional, centralised governance cannot keep pace with how technology is built today. They noticed how decision rights and accountability work best when they are embedded directly into how people work, through dynamic, principles-based approaches. 

In plain terms, a page of clear rules beats a binder of rules nobody reads. That is the spirit here. Lightweight, but real.

The digital system is rarely the problem

Boston Consulting Group has studied transformations for years and found that only about 30% succeed in meeting their objectives, and that the determining factor is usually the people dimension, the organisation, operating model, processes, and culture, rather than the technology itself. 

A more recent 2024 BCG study found that only 30% of companies fully meet timeline, budget, and scope on large-scale technology implementations.

Read those two numbers together and you can notice a pattern. Organisations are failing because the digital system landed in an environment that was never set up to run it.

The pressure is already visible. In Gartner’s 2025 CIO research, 62% of strategy leaders said an overburdened legacy operating model can no longer support their current and future objectives. Moreover, 73% of IT leaders are reworking how their organisation operates around technology. 

The strain shows up in the model, not the tool.

AI makes this sharper, not softer. As we argued in our piece on whether AI is really a cost-saver, AI does not reward surface-level digitalisation. It amplifies whatever is underneath. 

If five teams handle the same request in five different ways, AI will not magically fix that. It will simply make the inconsistency run faster. 

The one-page operating model

Here is the good news. You do not need a transformation programme to fix this. Capability gets built practically, and this is the practical version.

A working operating model answers six questions. Each one should be answerable in a sentence, and each one should have a name attached to it.

1. Decisions: Who can say yes, and to what

Every system generates decisions. 

• Add this field or not
• Spend on that integration or wait
• Prioritise the sales team’s request or the finance team’s 

The question is who gets to decide.

The most common failure is assuming the team decides. In practice, when everyone decides, no one does, and the request sits there until somebody loses patience.

Rule of thumb: Name a person who can approve changes, costs, and trade-offs, and define what they can decide alone versus what gets escalated.

2. Data: What the system must be able to trust

A system is only as reliable as the data underneath it. This is where the idea of minimum viable data earns its place. It is the smallest set of fields the system needs (at a minimum) to work without cracks and issues. 

It should help you decide:

• What fields can never be empty? 
• Whose definition wins when two teams disagree? 
• Who is responsible for quality at the point where the data is created?

Again, you do not need to clean everything. You need to know what must be right, and who is responsible for keeping it right. That is the heart of data readiness.

Rule of thumb: Define the minimum data the system must trust, fit for purpose rather than perfect, and give each critical field an owner.

3. Changes: How the system evolves without breaking

Good systems change. The problem is the change that arrives as “this small thing.” The problem is that in a connected system, there is no such thing as a change that touches only itself. 

• A new field touches a data model
• A new approval step touches a workflow, a notification, a permission…

So decide, in advance, how change works. 

• Where requests go 
• Who looks at the ripple effects before saying yes
• Where the line sits between a quick fix and something that deserves to be treated as a small project with its own change management.

Rule of thumb: Agree on how changes get requested, sized, and approved before the first “can we just” arrives.

4. Support: Who keeps it running

A surprising number of systems go live with no clear answer to a basic question: when this breaks, who answers, and how fast? 

A system with no named support owner is a system on borrowed time. It works fine until the day it does not, and then nobody is responsible for the silence.

Rule of thumb: Name who responds when the system fails, set an expected response time, and decide who watches it proactively instead of waiting for complaints.

5. Adoption: How people actually use it

A system that no one uses well is an expensive shelf. Gartner found that just 32% of business leaders said the last change they led achieved healthy adoption by their people. Most of the value leaks out here as people fall back on old habits or invent workarounds.

Adoption is a process. Someone has to own onboarding and training, watch whether the system is being used correctly, and catch the workarounds before they harden into shadow processes. 

This is squarely a people readiness question that we have answered recently.

Rule of thumb: Treat adoption as an owned process, and define how you will know people are using the system well, not just that it exists.

6. Accountability: Who owns the outcome

Finally, the question that ties the other five together. A year from now, who is accountable for whether this system still delivers value? 

By “who”, we are talking about a person with a name, a surname, and a role in the company.

Organizations need someone to check whether the new digital system is still earning its place, whether it should be improved, or whether it should be retired. Clear ownership is what keeps a system honest over time.

Rule of thumb: Assign one named owner who is accountable for whether the system still delivers value and whose job includes improving or retiring it.

Your operating model on one page

Put together, that is the whole thing. Six questions, six clear answers. Here is the version a leader can fill in before or just after, go-live.

1. Decisions. Who can approve a change, a cost, or a trade-off? (A person, not a committee.)
2. Data. Which fields must be trusted, and who owns their quality? (Minimum viable, not perfect.)
3. Changes. Where do change requests go, and who sizes their real impact?
4. Support. Who answers when it breaks, and how quickly?
5. Adoption. Who owns training and usage, and how will you know it is being used well?
6. Accountability. Who owns whether this still delivers value in a year?

There is a rule of thumb for the whole page, too. If you cannot put a name next to each line, you do not yet have an operating model. You have a system and a set of assumptions.

How to use the operating model checklist without overengineering

To be clear, a simple internal tool used by one team does not need a formal operating model.

The test is dependency. 

Any system that more than one team relies on, or that touches customers, money, or compliance, deserves these six answers written down somewhere a person can actually find them.

And the cheapest moment to answer them is earlier than most companies think. These questions are far easier to settle during analysis than during a dispute after launch, which is part of why the analysis phase pays for itself. 

Writing the operating model before the build is not extra work. In our experience, the organisations that take twenty minutes to answer these six questions up front are not the ones calling in a panic six months in.

Finally, clarity is the operating model

The operating model is what turns a delivered system into a durable one. 

At Net Group, we believe a serious digital partner should leave you with two things, not one. The system, and a clear way to run it. 

The first is what you paid for. The second is what makes it last.