Enterprise Transformation

The Operating Model Is a Complexity Decision

Why leaders should evaluate operating-model design by the complexity it creates across value flows, interfaces, capabilities, customers and transformation.

EraNorth Insights · 30 Aug 2026 · 8 min read

Transformation programs often try to remove complexity that the organisation's own structure recreates every day.

A customer request crosses sales, product, engineering, operations, finance and service. Each function has a rational process, budget, manager and measure. Yet the customer experiences only the total flow.

When that flow becomes slow, organisations often launch improvement projects inside the functions. Procurement simplifies procurement. Finance standardises finance. Technology rationalises applications. Operations reduces local waste.

Each initiative can succeed and the enterprise can remain difficult to navigate.

The problem is not necessarily poor execution. It may be that the operating model itself generates too many handoffs, conflicting incentives and decision interfaces.

The Strategic Context

Accenture's 2017 Breaking Through the Complexity Barrier argues that fragmented, function-driven transformation often produces incremental local gains while leaving underlying customer, supplier and employee challenges unresolved. Its proposed response is an integrated operating model organised more strongly around end-to-end value perspectives, with clearer roles for corporate, regional, divisional and shared capabilities.

The paper uses the distinctive term "prime value chains" for these end-to-end flows. That construct should remain attributed to Accenture rather than presented as a universal standard.

Oehmen and colleagues provide a systems rationale for the same broader issue. Their engineering-systems perspective emphasises that organisational and technological structures are tightly coupled. A product architecture affects team coordination; organisational structure affects information flow; technical interfaces and human interfaces shape one another.

Deloitte's Agile/PPM material adds another supporting dimension: value streams can become a useful organising unit when teams, funding and work are connected to customer value rather than only to temporary project boundaries.

The enterprise implication is significant. Operating-model design determines where complexity lives.

What Leaders Commonly Misread

The first misread is to treat silos as inherently bad. Functions exist for reasons: expertise, control, scale, professional standards and career development. The issue is not whether functions exist. It is whether value creation requires excessive negotiation across them.

The second is to solve enterprise complexity with functional optimisation. A faster local process can make an end-to-end flow worse if it creates queues or transfers cost to another function.

The third is to assume that integration means centralisation. Integrated value flows can still use decentralised teams, shared services, external partners and specialist centres. The important issue is clarity of interfaces and end-to-end accountability.

The fourth is to redesign structure without redesigning incentives. If leaders are measured only on functional performance, asking them to optimise enterprise value can conflict with how the system rewards them.

The fifth is to create a new layer called "transformation" without changing the operating system below it. A program office can coordinate change, but it cannot permanently compensate for decision rights and processes that recreate complexity after the program closes.

Reframing the Issue

An operating model should be evaluated not only for cost and control, but for its complexity economics.

Every organisational boundary creates potential benefits and coordination costs.

A specialised function can increase expertise and consistency. It can also create a handoff.

A shared platform can reduce duplication. It can also create a common dependency.

A central approval can reduce local risk. It can also create decision latency.

A persistent value-stream team can improve customer focus. It can also duplicate specialist capability if every stream becomes self-contained.

There is no universally simple operating model. The leadership task is to place complexity where the organisation is best able to manage it.

Four Sources of Operating-Model Complexity

1. Excessive handoffs

When work repeatedly crosses organisational boundaries, information is translated, priorities are renegotiated and accountability becomes diffuse.

2. Conflicting measures

One function optimises utilisation, another lead time, another compliance, another revenue. Local optimisation can create enterprise friction even when every manager meets target.

3. Ambiguous decision rights

Cross-functional issues become slow when no one clearly owns the trade-off. Committees emerge to compensate, adding another interface.

4. Misaligned technology architecture

A fragmented technical landscape can force organisational workarounds. Equally, a central platform can become a bottleneck if governance and capacity do not match enterprise dependence.

These sources interact. This is why operating-model redesign must be socio-technical, not only organisational.

Organisational Ambidexterity Without Two Organisations

Accenture's paper argues that integrated operating models can support organisational ambidexterity: managing today's business efficiently while developing capabilities required for tomorrow.

The principle is strategically important, but the structural answer should not be copied mechanically.

Some organisations separate exploratory ventures from core operations. Others create protected teams inside existing businesses. Others use shared platforms with differentiated governance. The right choice depends on risk, culture, regulation, scale and the extent to which new capabilities must integrate with the existing customer base.

The key test is whether the operating model can support both exploitation and exploration without forcing one to use the other's management logic.

A mature core process may need standardisation and efficiency. An emerging digital service may need experimentation. If both are forced through identical controls, one side pays the cost.

Decision Framework

Use an Operating-Model Complexity Test before a major reorganisation or transformation.

QuestionWhat to examine
Value flowWhere does customer, supplier or employee value cross boundaries?
HandoffsWhich boundaries create delay, rework or repeated interpretation?
Decision rightsWho resolves cross-functional trade-offs?
MeasuresDo local incentives reinforce or conflict with enterprise value?
TechnologyWhere does architecture create coupling or bottlenecks?
ScaleWhich capabilities genuinely benefit from centralisation or sharing?
AdaptabilityCan the model support both stable operations and emerging work?
Transition costWhat disruption will redesign create before benefits appear?

The last question matters. An operating-model change can reduce long-term complexity while creating substantial short-term complexity. Leaders must sequence the transformation so the business can continue operating.

Related article: A Transformation Portfolio Must Be Sequenced as a System

From Strategy to Execution

Immediate action is to trace one critical end-to-end value flow across the current organisation. Do not start with the organisation chart. Start with a customer outcome, supplier transaction or employee service and identify where value waits, changes hands or requires conflicting approvals.

Medium-term capability is to redesign the most expensive interfaces. Some may need standardised data, clearer service agreements, delegated authority, cross-functional teams or platform investment. Others may justify structural change.

Long-term positioning is to align portfolio governance with the target operating model. Transformation initiatives should not be selected independently if they reshape the same value flows, technologies or organisational capabilities. Sequence them as a system and measure whether enterprise friction is actually falling.

Related article: Capacity Is a Strategic Constraint: Match Ambition to What the Organisation Can Absorb

Signals to Monitor

The operating model may be generating avoidable complexity when:

  • customers experience delays that no single function owns;
  • cross-functional issues require frequent executive intervention;
  • functions report improvement while end-to-end performance remains flat;
  • shared services become bottlenecks for strategic initiatives;
  • teams create duplicate capabilities to avoid central queues;
  • transformation projects repeatedly "fix" the same interfaces;
  • technology and organisation designs are changed separately;
  • the number of coordination roles grows faster than value-producing roles.

Questions for the Leadership Team

  1. Which organisational boundaries create the greatest end-to-end delay?
  2. Where does functional optimisation conflict with enterprise value?
  3. Which capabilities should be shared because scale matters, and which should sit closer to the value flow?
  4. What decision rights are unclear across functions?
  5. Where has technology architecture become an operating-model constraint?
  6. Which parts of the business need stability and which need protected experimentation?
  7. Will the proposed transformation reduce long-term complexity or merely relocate it?

Closing Perspective

Organisational complexity is not only something leaders inherit. It is something design choices create.

A strong operating model does not eliminate functions, controls or shared platforms. It makes their contribution to value explicit and reduces unnecessary friction between them.

Before launching another transformation to manage complexity, leaders should ask whether the organisation is structured to stop recreating it.


About EraNorth Insights
EraNorth Insights publishes practical analysis on strategy, projects, operations, transformation and decision intelligence for professional and organisational use. About EraNorth.