Organisations that treat IT as a strategic asset will outperform those that don't

There's a persistent belief in many organisations that technology is important — but not central. It supports the business. It enables processes. It delivers systems. But it doesn't shape how the business operates.

That distinction used to be manageable. When technology was primarily about keeping the lights on — running payroll, processing transactions, maintaining infrastructure — treating IT as a service function made sense. The business decided what it needed, IT delivered it, and success was measured in delivery terms: on time, on budget, to scope.

But that model belongs to a different era. In most industries today, technology is no longer just supporting the operating model. It is the operating model. How an organisation captures demand, fulfils orders, manages inventory, closes its books, serves customers, and makes decisions — all of it runs through technology. And the organisations that understand this, that have repositioned IT from a service function to a strategic capability, are starting to pull away from those that haven't.

This isn't a technology argument. It's an organisational design argument. And the gap it creates is compounding.

The structural divide

At a surface level, most organisations in the same industry look similar. They run the same ERP platforms. They invest in similar tools. They work with the same system integrators. They face the same market pressures. And yet the outcomes are strikingly different.

Some organisations implement technology faster, adapt more easily to changing requirements, and consistently extract value from their investments. Others struggle to deliver, depend heavily on external partners for capability they should own, and repeatedly fail to realise the benefits their business cases promised.

The difference isn't the technology. The difference is how technology is positioned inside the organisation — whether it's treated as a function that responds to the business, or a capability that shapes how the business operates. This is a structural distinction, not a philosophical one. It shows up in where IT sits in the organisational hierarchy, how technology leaders are involved in strategic decisions, who owns architecture and data, how much capability is built internally versus rented from partners, and whether technology investment is governed as a cost to be managed or a capability to be built.

IT as a service function

In many organisations, IT still operates as a service layer. The business defines requirements, IT delivers solutions, and success is measured by whether the solution was delivered on time and within budget. For stable operations — maintaining existing systems, supporting established processes — this model is efficient and appropriate.

The problem is that this model breaks down the moment an organisation needs to transform rather than maintain. ERP programmes, data platform migrations, digital transformations — these aren't requests for IT to build something the business has specified. They're programmes that reshape how the business operates, and they require technology decisions and business decisions to be made together.

When IT operates as a service function during transformation, IT is engaged after key strategic decisions have already been made — decisions about operating model, process design, organisational structure — and is then expected to implement technology that supports those decisions. But the decisions themselves were made without understanding their technology implications. A process redesign is approved without anyone assessing whether the data structures can support it. A timeline is committed to without understanding the technical complexity involved.

I've seen this pattern in programme after programme. The business makes a decision about how a process should work. IT is told to configure the system accordingly. During build or testing, it becomes clear that the decision has implications — for data, for integration, for system performance — that weren't considered when it was made. The programme either absorbs the cost of rework, or it delivers something that technically satisfies the requirement but doesn't actually solve the problem.

IT as a strategic capability

In stronger organisations, technology leaders are in the room when operating model decisions are made — not to provide a technical opinion after the fact, but to shape the decision itself. They understand that data structures, system architecture, and integration patterns aren't technical details to be resolved during implementation. They're design decisions that define how the organisation will operate.

This changes the nature of the relationship. Instead of a transactional dynamic — business requests, IT delivers — it becomes a collaborative one. IT co-owns outcomes, not just delivery. It shapes process design, not just system configuration. It influences how the operating model is structured, not just how the technology supports it.

When IT is embedded in strategic decisions, the implications of those decisions are understood before they're committed to. A process redesign is assessed for its data dependencies before it's approved. A timeline is informed by technical complexity before it's promised to the board. This doesn't slow decisions down. In my experience, it accelerates them — because it eliminates the cycle of deciding, discovering the implications, and then reworking.

Where it breaks down

Many organisations believe they treat IT as strategic. Their annual reports describe technology as a core capability. Their CIO sits on the executive committee. But their behaviour tells a different story.

IT is engaged after key decisions are made, not during them. Architecture is dictated by programme timelines rather than designed to support long-term capability. External partners make critical design choices that internal teams should own. Internal technical capability is underdeveloped because the organisation has relied on system integrators to fill the gap for so long that it's become structural.

The gap between intent and reality is often widest during transformation programmes. An organisation that describes IT as strategic but hasn't built the internal capability to match that description will discover the gap during its next ERP implementation — when it finds itself dependent on a delivery partner for architecture decisions, data strategy, integration design, and testing approach. The decisions being made are decisions about how the organisation will operate for the next decade, and they're being made by people who won't be there to live with the consequences.

The compounding effect

Organisations that treat IT as a strategic capability build knowledge with each programme. Their internal teams develop deeper expertise in architecture, data, integration, and process design. They build reusable patterns, maintain institutional knowledge, and improve their ability to deliver with each cycle.

Organisations that treat IT as a service function start from scratch each time. Every transformation requires a new partner engagement, a new ramp-up period, a new process of knowledge transfer that never quite completes. Design decisions from the previous programme are poorly documented because the people who made them were contractors who've moved on.

The result is a divergence that compounds over time. The first organisation gets faster, more capable, and more confident with each programme. The second gets slower, more dependent, and more cautious. The gap isn't linear — it's exponential, because capability begets capability.

ERP as the dividing line

ERP transformations make this structural difference impossible to hide. ERP sits at the centre of how an organisation operates — connecting finance, operations, supply chain, procurement, and HR. The decisions made during an ERP transformation define how the organisation will run for years.

In an organisation that treats IT as strategic, an ERP transformation is an opportunity to simplify the operating model. Processes are standardised. Data structures are designed intentionally. Architecture is owned internally.

In an organisation that treats IT as a service function, the same ERP transformation looks very different. The system is implemented around existing complexity. Customisation preserves local variations that should have been standardised. Data issues from legacy systems are carried forward. The ERP goes live, but the organisation hasn't actually transformed — it's replicated its existing complexity on a new platform.

The hidden risk: external dependency

Every organisation uses partners for transformation. The question isn't whether you use partners. It's what you use them for, and what happens when they leave.

When partners define your architecture, make your critical design decisions, hold your technical knowledge, and build your integration layer, you're not building capability. You're renting it. And rented capability has a shelf life. The partner's consultants move on. The knowledge they carry goes with them. And the next time you need to make a change, you're back to square one.

The organisations that manage this well draw a clear line between what partners deliver and what the organisation must own. Partners bring implementation expertise, technical specialisms, and delivery capacity. But the architecture, the data strategy, the integration design, and the decisions about how the technology estate supports the operating model — these must be owned internally. Not because internal teams are better, but because these are decisions the organisation needs to live with long after the partner has gone.

Why the gap will keep widening

Data is becoming central to decision-making in a way that demands structured, governed, high-quality data assets. AI is increasing the dependency on well-governed information. Integration complexity is growing, not shrinking.

Each of these trends favours organisations that have embedded IT as a strategic capability. And each one makes it harder for organisations that haven't to catch up — because catching up requires a fundamental change in how the organisation positions, governs, and develops its technology capability. That's an organisational change, not a procurement decision, and it takes years to execute.

What good looks like

The bottom line

The gap between organisations is no longer defined by strategy alone. It's defined by execution capability — the ability to turn strategic intent into operational reality. And in most modern enterprises, execution runs through technology.

Organisations that treat IT as a strategic asset don't just deliver systems more effectively. They operate differently. They make better decisions. They adapt faster. They compound their advantage because each programme builds on the last.

The organisations that still treat IT as a service function will continue to deliver. But they'll deliver more slowly, more expensively, and with less lasting value. And the gap will continue to widen.

That gap is already visible. It's about to become defining.