By this point in the series we've established three things:
- ITSM without an operating model turns into theatre.
- An IT operating model is your shared answer to "how IT actually works here" – best made visible with something like Andrew Campbell's Operating Model Canvas plus a management method like USM.
- ITSM and cloud governance only really make sense when they sit on the same map.
The natural objection I hear from CIOs and Heads of IT is: "Fine. But we don't have time for a giant TOM project. Where do we start without derailing everything else?"
Resist the urge to "fix the whole IT organisation". That's how you end up in a 6‑month deck factory.
Instead:
- Business‑critical or NIS2‑relevant, and
- Crosses multiple teams, platforms and suppliers (so the pain is visible).
Service/product owner, platform lead(s), SMO/ITSM lead, someone from cloud/security, someone who actually handles incidents/changes.
Sketch "how this really works today", not how the process sheet claims it works.
Fill in the six boxes for that single service:
Incident→resolution, change→deploy, request→fulfilment, "threat detected→risk mitigated".
Which teams and roles actually touch this work.
On‑prem DC, Azure/AWS landing zones, SaaS, OT sites, key components.
CMDB/CMDB‑lite, monitoring, logs, cost data, risk register, contracts.
Which vendors, suppliers and partners sit where in the flow.
Which boards and routines make which decisions (CAB, cloud board, risk committee, service review, NIS2 incident review).
If you keep people honest, this first sketch will already surface 70–80% of the structural issues:
- "We sort of assume this team owns it, but…"
- "In theory, that goes through CAB – in practice we bypass it."
- "Nobody really checks this control end‑to‑end."
Once you have the rough canvas for one service, you can start asking a very different question:
"Given this reality, which management activities do we actually need to keep this under control?"
This is where USM earns its keep. USM provides a small, principle‑based set of management processes and activities that you can apply consistently across all services, rather than inventing unique process variants for every domain.
Start from a thick practice book and ask "where can we apply all this?"
Start from your service and ask:
- Which activities do we need around incidents, requests, changes, continuity, capacity, contracts, improvements – and who runs them for this service?
- Where do these activities show up on the canvas – in Work, Organisation, Management System?
- Where are we currently doing this in a completely ad‑hoc way?
You can still absolutely use ITIL, COBIT or IT4IT for detailed guidance – but now as libraries you draw from, not as Operating Model diagrams you just copy.
USM itself suggests three deployment strategies – do‑it‑yourself, training, or supported deployment – all based on small, incremental steps and internal ownership rather than "big consultant army" projects. That mindset fits perfectly with Operating Model work:
The worst thing you can do now is disappear for three months to turn the sketch into a perfect Visio.
Instead, stress‑test the rough model in real life:
Use it as the backdrop: "According to this canvas, who actually owns this decision? Who provides which data? Where does this change live?"
"If this service fails, which roles, controls and suppliers matter most – and do we see them clearly here?"
"Does our canvas help us understand what just went wrong in terms of flow, ownership and information?"
Within a couple of meetings, you'll see:
- Missing roles ("we assumed security would do that, they assumed we would").
- Broken interfaces ("this is where cloud and ITSM use different names for the same thing").
- Tool gaps ("we rely on a spreadsheet here because nothing else fits").
There are a few reliable ways to kill Operating Model work. Worth naming them up front:
This leads straight back to the 6‑month PowerPoint factory and change fatigue.
If your "Operating Model" magically mirrors your current ServiceNow group structure or Azure subscription layout, you've probably just automated today's complexity and mess.
External help can facilitate, challenge and bring patterns – but if the model mainly lives in a consultant's slides, it will die as soon as they leave the room.
Strategy decks without a matching operating model give you elegant intent and chaotic execution.
In my view, success looks almost boring: a handful of services gradually get proper canvases, those canvases start showing up in meetings, and people begin sentences with, "If we look at this on the operating model…" instead of "In my area we do it like this…".
You can do a lot of this internally. But there are moments where an outside perspective pays for itself quickly:
You've tried to clarify ownership and flow for a critical service several times and always get stuck in the same politics.
You're about to make a big ITSM, ServiceNow or cloud governance decision and have an uneasy feeling you're pouring concrete around a fuzzy foundation.
NIS2, GDPR or sector regulations are raising the stakes and you need to show a credible, end‑to‑end story to auditors or a CIO operational reliability check.
What you want at that point is not someone to "own" the model for you, but a neutral facilitator who:
Knows patterns that work in similar organisations.
Can translate between ITSM, cloud, risk and business languages.
Is not trying to sell you a particular tool.
This is exactly the gap TransparIT is set up to work in.
The focus is very narrow on purpose: making IT and digital operations transparent through IT Operating Models, ITSM/USM‑based service management and practical Cloud Governance – including NIS2‑driven setups.
Typical starting points are deliberately small:
A review of one or two critical services, using Andrew Campbell's Operating Model Canvas to map how services, platforms, teams and suppliers actually fit together today.
Leadership and key practitioners co‑create the first canvas and identify the 3–5 most important structural improvements.
A second opinion on a planned ITSM tool change, ServiceNow governance model or cloud governance/NIS2 initiative – specifically checking whether the operating model is clear enough to justify the investment.
From there, the engagement can grow if it needs to – but the principle stays the same:
- Use simple, visual operating model techniques (like Campbell's canvas).
- Use USM as the management method and ITIL as the activity library, not as religions.
- Connect it all to real governance, risk and compliance expectations, including Danish public‑sector cloud guidance and NIS2.
- Build your internal capability so your people can maintain and evolve the operating model without long‑term dependency.
If you recognise yourself in any part of this series, here's a low‑friction experiment:
With the right people in the room.
Getting started with your IT operating model (without a 6‑month programme)