Find the cause

7 Signs Your Operating Model Is Blocking Digital Transformation

Seven signs that responsibilities, incentives or ways of working are holding back digital change, and what to examine before changing technology.

Tafadzwa Boriwondo17 August 202611 min read

Use this insight to

Identify what evidence would help explain the problem and who needs to respond.

Digital transformation is often blamed on technology when the organisation has made change structurally difficult.

A new platform can be delivered on time and still create little value if nobody owns the end-to-end process, teams optimise conflicting targets, decision rights are unclear, data is fragmented and incentives reward the old way of working.

That is an operating-model problem.

A useful operating model describes how strategy becomes coordinated work across:

accountability;
decision rights;
processes;
teams and capabilities;
data;
technology;
governance;
measures and incentives.

Here are seven signs that this system is blocking transformation.

Executive sponsorship matters, but sponsorship is not operational ownership.

A transformation may affect marketing, sales, finance, operations and technology. If each function owns only its own step, nobody owns the customer or business outcome end to end.

Symptoms include:

issues being passed between departments;
local improvements that create downstream work;
nobody accountable for total cycle time;
handoffs treated as somebody else's problem;
transformation steering committees debating ownership after launch.

The fix is to identify the process or journey owner early.

For example, “quote to cash” needs someone accountable for the performance of the whole chain, not five departments individually declaring their step successful.

Sign 2: decision rights are unclear

Transformation slows when every material decision requires a meeting because nobody knows who can decide.

Common questions become political:

Who can change the process?
Who approves customer-facing changes?
Who owns data definitions?
Who accepts implementation risk?
Who can stop a failing pilot?
Who resolves conflict between functions?

A simple decision-rights model can define:

decision owner;
required input;
approver where necessary;
escalation path;
time expectation.

Governance should make decisions faster and safer. If it only adds steps, it is administration wearing a lanyard.

Sign 3: teams are measured to optimise against each other

Incentives reveal the real operating model.

Imagine:

Marketing is rewarded for lead volume.
Sales is rewarded for closed revenue.
Operations is rewarded for cost reduction.
Customer service is rewarded for average handling time.

The organisation may create more leads than Sales can qualify, sell services Operations struggles to fulfil and rush customers off support calls while repeat contact rises.

Each team can hit its target while the customer journey deteriorates.

Transformation requires measures that connect local performance to shared outcomes.

Examples:

qualified pipeline rather than raw leads;
first-contact resolution rather than only handling time;
profitable revenue rather than bookings alone;
end-to-end cycle time rather than departmental queue time.

Sign 4: process knowledge lives in people, not in the organisation

Ask three employees how a critical process works and you may get four answers.

This creates several problems:

automation is built around an incomplete workflow;
exceptions appear late;
key-person risk is high;
onboarding is slow;
controls depend on memory;
system requirements become contradictory.

Before digitising a process, map:

trigger;
inputs;
standard path;
decisions;
exceptions;
roles;
systems;
controls;
outputs;
performance measures.

Do not automate folklore.

Sign 5: data ownership is fragmented

Transformation programmes frequently discover that the organisation has many systems but no shared understanding of core entities.

Examples:

“customer” means an account in CRM and an invoice entity in ERP;
product codes differ between ecommerce and finance;
regional spreadsheets override central data;
no team owns data-quality remediation;
reports reconcile manually every month.

Technology cannot solve a definition dispute that leadership has never resolved.

Create explicit ownership for critical data domains and metrics.

This does not require a giant governance programme. Start with the data needed for the transformation outcome.

Sign 6: technology architecture reflects organisational boundaries rather than customer journeys

Systems are often procured department by department.

The result can be:

duplicate customer records;
repeated manual entry;
brittle point-to-point integrations;
inconsistent identity;
fragmented permissions;
no end-to-end telemetry.

The architecture mirrors the org chart while the customer experiences one journey.

Transformation should identify the capabilities the journey requires, then decide which systems should own which responsibilities.

That may involve integration, platform consolidation, API development, replatforming or process redesign. It does not automatically mean replacing everything.

Sign 7: transformation is funded as projects, but value requires continuous ownership

Projects have end dates. Digital products and processes keep changing.

A programme can deliver:

new CRM;
new portal;
new data platform;
new automation;

then dissolve the team that understood why it was built.

The organisation is left with:

a backlog nobody owns;
adoption problems;
unresolved process exceptions;
data-quality issues;
maintenance decisions;
no budget for improvement.

A live digital capability needs an operating owner, measures and a continuous improvement mechanism.

GOV.UK's service guidance captures the same principle in a different context: the live phase includes sustainable operation, ongoing research, performance metrics, security, quality assurance and iteration. Going live is a transition, not the end of responsibility.

Diagnose the operating model before choosing the intervention

A useful transformation assessment can score five dimensions.

1. Direction

Is the business outcome clear?
Are priorities explicit?
Is the scope coherent?

2. Ownership

Is there an accountable outcome owner?
Are decision rights clear?
Are cross-functional dependencies governed?

3. Flow

Is the end-to-end process understood?
Where are the handoffs and delays?
Which exceptions dominate effort?

4. Capability

Do teams have product, data, technology, process and change skills?
Is key knowledge concentrated in individuals?

5. Evidence

Are shared metrics trusted?
Can the organisation measure baseline and realised value?

Weakness in any one area can undermine a technically strong implementation.

Example: CRM transformation

A business replaces its CRM because sales reporting is poor.

The implementation succeeds technically, but:

marketing and sales still disagree on lead definitions;
salespeople are not required to update opportunity stages;
account ownership rules remain unclear;
finance revenue does not link to CRM accounts;
management continues using spreadsheets.

The platform was not the original problem.

The operating model never established ownership, data standards or management behaviour.

Example: customer self-service

A company launches a portal to reduce service costs.

Customers can submit requests online, but staff still process the requests through email because internal systems are not integrated.

Digital adoption appears weak.

The portal may be usable. The operating process behind it is unchanged.

The transformation question is not “How do we drive portal traffic?”

It is “What must change end to end for self-service to actually remove work?”

The transformation backlog should contain operating changes too

Do not create a roadmap containing only technology deliverables.

Include items such as:

clarify process ownership;
align KPI definitions;
remove an approval layer;
create product-management capability;
redesign incentive measures;
establish data stewardship;
train frontline staff;
change service-level agreements;
decommission redundant workflows.

Technology enables the target operating model. It does not constitute the whole model.

Sequence change around constraints

Trying to redesign the entire organisation before delivering anything creates paralysis.

Instead:

Define the target business outcome.
Map the current journey or process.
Identify the operating constraint with the strongest evidence.
Decide which process, role, data and technology changes are required together.
Deliver a coherent slice.
Measure the outcome.
Expand.

This keeps operating-model work grounded in value rather than becoming an abstract reorganisation exercise.

Questions leadership should ask

Before approving a major digital investment, ask:

Who owns the outcome after the project ends?
Which cross-functional process is changing?
Which decisions need new ownership?
Which measures or incentives currently conflict?
What data definitions must be resolved?
Which teams need new capability?
What old workflow will be retired?
How will value be measured after launch?

If those answers are missing, the business may be funding technology before it has designed the organisation that must use it.

Sign 1: every transformation project has a sponsor but no process owner