he IT Operating Model Discovery – Part 2
What an IT operating model really is (and what it isn't)
An Operating Model is your answer to "How do we actually run IT here?"
Let's strip away the corporate jargon for a moment. An IT Operating Model isn't a complex framework or a binder gathering dust; it is simply your shared, honest answer to a single, pragmatic question:
"How does IT actually work here, on a Tuesday afternoon, when something breaks or something new has to go live?"
Consider that Tuesday afternoon test. An incident hits the dashboard, a change request lands in a queue, or a new business requirement arrives from the executive floor. Who picks it up? Who makes the final decision? Who talks to whom, and which specific tools are opened to track the resolution? That chain of events, from initial demand to eventual delivery, is your operating model, whether you’ve deliberately designed it or left it to chance.
If you can't sketch that answer on a single page in a way your leadership team broadly recognizes, you don’t have an operating model; you have a collection of org charts, process diagrams, and folklore. These are not the same thing. Org charts merely represent hierarchy, not the flow of work. Process diagrams often document what you hope happens, rather than the messy reality. Folklore is what your staff actually does—the unwritten rules, the workarounds, and the "who-you-know" shortcuts that live exclusively in people’s heads. Relying on folklore is a liability; you lose consistency and speed every time a key person leaves, a team is restructured, or a new supplier is onboarded.
Crucially, this answer must be shared. An operating model only functions when the people who run IT and the business stakeholders who depend on it hold a common understanding of how the gears turn. When this alignment is missing, you end up with the friction that powers most of those frustrated "why does IT always take so long?" conversations.
When we talk about it formally, an Operating Model is the blueprint that effectively connects your high-level strategy to the realities of everyday work:
The Blueprint Covers
- How services are structured and delivered
- How work and decisions flow across teams and suppliers
- Which information and tools people rely on
- Which governance routines keep everything aligned with business goals and risk appetite
In IT, That Means
- How incidents, changes and requests move from demand to resolution
- How product teams, platform teams, shared services and suppliers interact
- How you translate "cloud‑first" or "NIS2‑compliant" into concrete roles, controls and workflows
If that sounds suspiciously close to "how IT actually operates", that's the point. The Operating Model is not another document; it's the design of reality.
The Operating Model Canvas: A simple way to see the whole
In Andrew Campbell's work on the Operating Model Canvas, an Operating Model is described as the high‑level design of how an organisation delivers value in practice – how it organises people, work, locations, information, suppliers and management routines so that strategy turns into day‑to‑day operations.
An IT Operating Model is the shared blueprint for how IT actually works here – who does what, using which assets and information, with which suppliers, under which governance.
A practical way to visualise this is Andrew Campbell's Operating Model Canvas, often remembered as POLISM:
P
Processes (Work)
O
Organisation (People)
L
Locations (in IT: Assets & Sourcing)
I
Information
S
Suppliers
M
Management System
Place Andrew Campbell's Operating Model Canvas diagram here – POLISM on one page
From Operating Model Canvas by Andrew Campbell and others
In an IT / digital context, each of these boxes becomes very concrete
Processes (Work)
The key value streams and workflows: incident to resolution, request to fulfilment, change to deploy, "idea to live", "threat detected to risk mitigated". This is where your ITIL / USM activities sit – not as isolated processes, but as end‑to‑end flows across teams and suppliers.
Organization (People)
The teams and roles that execute the work: service owners, product teams, platform teams, operations, SMO, CCoE, security, vendor managers. In IT, this also includes how you structure SIAM/SMO capabilities and how responsibilities are split between internal teams and external providers.
Locations – adapted to IT: Assets & Sourcing
In classic OMC, "Locations" covers where work is carried out and which physical assets you rely on. In an IT Operating Model, this maps to your technical and sourcing footprint:
- On‑prem data centres, network zones and OT/edge sites
- Public cloud landing zones, subscriptions, accounts
- SaaS estate and major platforms
- Service maps, applications and configuration items (CIs) in your CMDB/CMDB‑lite
- IT assets and their lifecycle (hardware, software, licences)
- Sourcing model choices: what is run in‑house, what is outsourced, what is "Software-as‑a‑service, AI-sourcing"
In other words: the "L" box becomes the place where you make explicit how your services sit on top of infrastructure, CIs, IT assets and sourcing decisions – not just geography.
Information
This is the nervous system of your Operating Model—the data, systems, and information flows required to run the enterprise. It encompasses everything from ITSM and AIOps tooling, monitoring and observability platforms, and org. data to financial chargeback models, risk registers, compliance records, and supplier contract performance. Good information design is the bedrock of the "Management System"; without it, your governance forums are flying blind. When this layer is fragmented or poorly designed, you fall victim to tool sprawl and manual reconciliation, where every team maintains its own dashboard. The result is a total loss of trust in data, where leadership is routinely presented with three different reports telling three different, contradictory stories about the state of the business.
Suppliers
External providers: infrastructure partners, cloud providers, SaaS vendors, network providers, outsourcing partners, SOC/MDR providers. The Operating Model needs to show where they plug into services and value streams, not just list them in contracts.
Management System
The governance and improvement engine: steering committees, CABs, cloud governance boards, risk and NIS2 forums, service reviews, KPI/XLA regimes, improvement cycles. This is where USM and ITIL practices come together as a single management system instead of parallel frameworks.
When you apply OMC thinking to ITSM, the questions you ask change
Incident Process
Not "do we have an incident process?", but "How does incident‑to‑resolution actually flow across these teams and vendors, and who decides what?"
Request Catalogue
Not "do we have a request catalogue?", but "How does our service structure map to platforms, contracts and cost models?"
Change Advisory Board
Not "do we have a CAB?", but "Where do changes enter the service value stream, and which forum really owns the risk trade‑offs?"
In my experience, you can get an honest picture in a single whiteboard session – if you insist on drawing reality, not the process manual. The gaps you uncover are usually not new; they're just finally visible.
What an IT operating model is not
This is where a lot of confusion comes from, so let's be concrete.
It's not your org chart
Org charts show reporting lines and sometimes cost centres. They don't show how work actually flows across teams, who owns which decisions, or how suppliers are integrated into services.
You can have the same operating model implemented with different org structures (e.g. more central vs. more federated) – and you can have totally different operating models inside the same org chart.
It's not your process manual
Process documentation answers "what should happen, step by step, if the world behaves".
An operating model answers "how we've actually chosen to run this, given our constraints, risks and suppliers".
You can have 200 pages of ITIL‑compliant processes that nobody follows, and still no operating model. Conversely, you can have a one‑page model that everyone understands, and lean, pragmatic process descriptions that support it.
It's not your ITSM tool configuration
Your ITSM platform is an implementation of parts of your operating model, not the model itself. If the only place your operating model exists is inside ServiceNow or Jira – in groups, queues, forms and workflows – then it's very hard for leadership to discuss or change it, it's strongly biased by whatever was easiest to configure at the time, and it mostly reflects history, not deliberate design.
In other words: the tool is the plumbing, not the blueprint of the house.
It's not your Business Model
Business model = how the organisation makes money or delivers public value.
Operating model = how you organise yourself internally to do that reliably and repeatedly.
They should be tightly connected, of course. If you change your business model (e.g. move from project to product, or from on‑prem software to SaaS), your operating model has to change too – and this is where many "digital transformations" stumble.
Tools and frameworks are ingredients – the operating model is the recipe
Here is the uncomfortable pattern I see again and again:
01
New platform or framework push
Organisation buys a new ITSM platform, or rolls out a new framework push ("we're doing ITIL now").
02
Months of busy work
Everyone is busy for months re‑designing processes, migrating data, building forms and dashboards.
03
Eerily familiar
Twelve months later, the experience on the ground is… eerily familiar.
The problem is not that the tools or frameworks are bad. ServiceNow, Jira, ITIL – they're all powerful ingredients when used well. The issue is that many organisations confuse ingredients with the recipe.
Tool
Where work is recorded, routed and visualised
Framework
Proven building blocks and vocabulary
Operating Model
How you've chosen to put these together to run IT
If you skip the recipe and jump straight into cooking, you'll get… something. But it's unlikely to be consistent, repeatable or aligned with your actual strategy.
In my experience, the most expensive ITSM projects are the ones that try to compensate for a missing operating model with configuration. Every time a structural question comes up ("who really owns this?", "how do these two teams interact?"), someone adds another field, another group, another approval. It works for a while – until the weight of exceptions and local variants becomes unmanageable.
Where USM fits: foundation vs. furniture
This is where the Unified Service Management (USM) method is particularly helpful.
USM isn't "ITIL 5.5" or "just another framework". It deliberately positions itself as a universal, principle‑based management system: a small, coherent set of management processes and activities you can apply across all services – IT, HR, facilities, you name it.
Think of it like this:
The Layering
- Operating Model Canvas gives you the structural blueprint—the fundamental architecture of your organisation. It defines what services exist, who delivers them, which suppliers are involved, how information flows, and how governance is enacted. It forces you to answer the "what" and "who" before you ever worry about the "how."
- USM provides the Management System—the consistent, repeatable pattern for how you manage services day to day. It covers the full Service Management lifecycle: Defining services, handling incidents, changes, service requests, risks and improvements. Its universality is key: the same management logic applies whether you're running IT, HR, or facilities, making it a genuine foundation rather than just another IT framework.
- ITIL, COBIT, IT4IT are valuable libraries of good ideas, but they work best when you have an existing Operating Model and Management System. Without that foundation, wholesale adoption often leads to "compliance theatre"—teams following the letter of the framework without the spirit because the underlying structure can't support it. Once the foundation is set, you can selectively implement the practices that provide real value and discard the rest.
Ultimately, this layering creates a stable foundation that doesn't fracture every time a framework releases a new version or you adopt a new tool. The Operating Model and Management System are durable; the tools and practices can evolve on top without destabilising your entire service delivery.
The Key is the Layering
1
2
3
1
Furniture & Decoration
Tool configuration, detailed practices, dashboards
2
Service Architecture
USM – how we manage services and teams consistently
3
Foundation
Operating model – how we run IT here
When you get the layering wrong – for example, by letting the tool dictate the Operating Model – you spend years rearranging the furniture while the foundations stay crooked.
Get a good introduction to USM here.
A stance some people won't like
If you don't have at least a one‑page view of your IT Operating Model that your leadership team recognises, you have no business re‑platforming your ITSM tool.
You'll still be able to deliver a project. There will be a go‑live, some automation, some nicer reports. But you'll mostly be pouring new concrete around an old, undocumented foundation – and you'll be back in the same discussions two years from now.
Start with the model. Then let the tools and frameworks follow.
What's next
In Part 3 of this series, we'll connect the dots between ITSM and cloud governance:
Why "cloud operating model" and "ITSM operating model" should not be two separate worlds
How a technology‑agnostic operating model helps you span on‑prem, cloud and SaaS
What this means for cost transparency, risk, and NIS2‑style obligations