The Identity Change Beneath the Operating Model Change
The operating model transformation from IT cost centre to business value enabler is often described in terms of metrics, governance, and reporting changes. These are real and necessary. They are also insufficient without the more fundamental change they depend on: a shift in IT’s organisational identity.
The cost centre IT model has an implicit identity: IT is the department that manages the technology infrastructure that the business uses. In this identity, IT’s role is custodial. It maintains the systems that the business depends on. It manages the risk of those systems going wrong. It delivers the changes that the business requests. It is a support function with technology as its domain.
The internal service provider identity is different in its orientation, not just its metrics. IT in the internal service provider model is a capability provider: it designs, builds, and operates the technology capabilities that enable business outcomes, and it manages those capabilities as products with internal customers. The difference is orientation: custodial IT is oriented toward maintaining what exists; service provider IT is oriented toward enabling what the business needs.
This second article in the three-part operating model series examines what the internal service provider model requires in operational terms.
The Service Catalogue That Speaks Business Language
The first operational requirement of the internal service provider model is a service catalogue that describes IT’s offerings in business language rather than technology language.
A technology-language service catalogue lists: server provisioning, network configuration, application deployment, security patching, database administration. These describe what IT does. They do not describe what the business gets from IT’s work.
A business-language service catalogue lists: new product launch capability, digital channel optimisation, supply chain visibility platform, customer data insight, operational automation. These describe the business capabilities that IT enables. They connect IT’s work to the business outcomes it supports.
The service catalogue is not merely a communication exercise. It is the mechanism that defines the relationship between IT and its internal customers. When the service catalogue describes business capabilities, the conversation between IT and the business is about which capabilities the business needs and how well IT is providing them. This conversation is qualitatively different from the conversation about service desk tickets and infrastructure availability that characterises the cost centre IT relationship.
Building a business-language service catalogue requires IT leaders to understand the business’s priorities and processes well enough to describe their technology offerings in business terms. This understanding comes from the business engagement that the cost centre model typically does not provide, which is why building the service catalogue often requires building the business relationships first.
Service Level Agreements Defined by Business Outcome
The second operational requirement is service level agreements that measure business outcomes rather than infrastructure metrics.
Infrastructure-based SLAs measure what IT controls: system availability, response time, incident resolution time. These are meaningful operational metrics. They are not the metrics that business stakeholders use to assess whether IT is delivering value.
Business outcome-based SLAs measure what the business experiences: the availability of the business capability IT provides, not of the infrastructure it runs on; the performance of the business process that depends on IT, not of the application that supports it; the time to deliver a new feature that generates business value, not the time to resolve an infrastructure ticket.
The distinction matters for accountability as much as for measurement. An infrastructure-based SLA creates accountability for keeping the infrastructure running. A business outcome-based SLA creates accountability for enabling the business outcome, which includes the infrastructure, the application, the integration, and the process that together determine whether the outcome is achievable. The internal service provider is accountable for the whole, not just the infrastructure component of the whole.
Making this transition in practice requires negotiating with business stakeholders to define the business outcomes that IT’s services are designed to enable, and establishing measurement mechanisms that can track those outcomes. This is a more complex measurement programme than monitoring infrastructure availability, and it requires the IT organisation to accept accountability for outcomes that depend on more than infrastructure performance.
The Product Management Function at IT’s Core
The third operational requirement, and the one most frequently absent in IT operating model transformation efforts, is a product management function that manages the IT service portfolio as a portfolio of products rather than a set of infrastructure services.
The IT service provider without product management builds what it knows how to build, maintains what it has already built, and responds to requests from business stakeholders who may or may not be asking for the right things. The result is a service portfolio that reflects the IT team’s capabilities and history rather than the business’s evolving needs.
The IT service provider with product management has someone whose job is to understand what the business needs, to define the IT capabilities that meet those needs, to manage the roadmap for how those capabilities develop over time, and to measure whether the capabilities are delivering the value they were designed to provide. Product management connects the IT service portfolio to the business strategy that it is designed to enable.
The product management capability does not require IT to hire a large product management function from day one. It requires IT leadership to commit to the product-oriented way of managing the service portfolio, and to develop or acquire the skills required to practice it. In many organisations, the product management discipline is already present in the digital product teams that IT supports; the challenge is applying it to the internal IT services themselves.
The Customer Engagement Model
The fourth operational requirement is a customer engagement model that treats business units as clients rather than requestors.
In the cost centre model, business units submit requests to IT through a service desk or project intake process. IT assesses the requests, prioritises them against available capacity, and delivers them according to the project delivery process. The business unit is a source of demand; IT is a source of supply. The relationship is transactional.
In the internal service provider model, IT engages with business units as an advisor and capability provider. Account managers or business relationship managers maintain regular engagement with their business unit counterparts, understanding their strategic priorities and operational challenges, and proactively identifying how IT capabilities can address them. The relationship is consultative.
This engagement model requires a different skill set from IT leaders than the project delivery model requires. Technical depth is still necessary. Business acumen, communication skill, and the ability to translate between business priorities and technology decisions are equally necessary. The IT professionals who are most effective in the internal service provider model are those who can operate fluently in both domains.
The Transition That Takes Longer Than It Looks
Moving from cost centre IT to internal service provider IT typically takes longer than the operating model transformation plan assumes. The reasons are structural rather than accidental.
The business-IT relationship that the internal service provider model requires is built on trust that has to be earned incrementally. Business leaders who have experienced IT as a cost centre function and a request-processing entity do not immediately treat IT as a strategic partner when IT declares itself to be one. The trust that makes the strategic partnership credible is built through a sequence of engagements in which IT demonstrates that it understands the business well enough to add value beyond service delivery.
This trust-building process cannot be accelerated by announcement. It requires consistent demonstration over time. The IT organisations that transition most successfully are those that identify the specific business relationships where they have the highest credibility and the best opportunities to demonstrate business advisory capability, and build the internal service provider model from those relationships outward.
The third article in this series provides the metrics architecture that measures whether the transformation is working.