The Service Management System Discovery — 2
What a Service Management System Actually Is (and Isn't)
Setting the Stage
This article is part 2 of 4 in the "Service Management System Discovery" series. In part 1 we looked at the symptoms of running ITSM without an SMS. In part 3 we explore why an SMS is the real backbone of governance and compliance. In part 4 we discuss how to avoid framework religion and build a living system that fits your organisation.
In part 1, we ended with a simple observation: many organisations have ITSM, but lack a Service Management System around it. To move forward, we need to be precise. What exactly is this thing? And just as important: what is it not?
From "we have processes" to "we have a management system"
ISO/IEC 20000‑1 defines a Service Management System (SMS) as the management system that establishes policies, objectives and processes for planning, implementing, operating, monitoring, reviewing, maintaining and improving IT services. It sounds dry, but there is real power in that definition:
Systemic
About how pieces fit together, not about one process at a time.
Explicit
Scope, roles and routines are defined well enough to be explained, audited and improved.
Cyclical
Built around continual improvement, not one‑off projects.
This logic is the same in ISO/IEC 27001 for information security management systems (ISMS) and ISO 9001 for quality management. These standards are not just checklists; they describe how an organisation manages a domain over time.
A Service Management System applies that thinking to IT services.
What a Service Management System contains in practice
In a real IT organisation, an SMS that is "just enough" typically includes:
1
Scope
A clear description of which services, units, locations and suppliers are covered by the SMS – and which are not (yet). For example, infrastructure and end‑user services may be fully in scope, while some local application support is only partially covered.
2
Policies and Principles
Short, understandable rules for how services are managed: risk appetite, change principles, incident escalation behaviour, supplier expectations, data handling norms. These link directly to business goals, security needs and regulatory requirements.
3
Roles and Responsibilities
A small but sharp role model: SMS owner, service owners, process/routine owners, supplier managers. ISO 20000‑1 explicitly expects top management to assign and communicate such responsibilities.
4
Core Management Routines
The handful of cross‑cutting routines that really matter: incident/major incident, change, service request, problem, supplier, risk, maybe configuration/asset. In a USM mindset, these are designed as generic workflows that can apply across different domains.
5
Measures, Reviews and Evidence
A lean set of metrics (e.g. availability, incident patterns, change failure rate, supplier performance) and regular reviews that close the loop: monthly SMS/SMO review, quarterly management review, annual scope and risk review.
If you put all this on a single A3, you have something surprisingly powerful: a visible management system for IT services, plus the governance to keep it alive.
How an SMS differs from your IT Operating Model
Many CIOs will ask: "Isn't that just our IT Operating Model?" Not quite.
IT Operating Model
Your overall blueprint: how IT is structured (central vs federated), which capabilities you have, how product teams, platforms, shared services and vendors fit together, and how you interact with the business.
Service Management System
The management system that runs inside that blueprint for all service‑related work: policies, service portfolio, management routines, measurements and continual improvement – aligned with standards like ISO 20000 and often integrated with ISMS and QMS.
You can change your operating model (for example, move to product teams) without changing underlying service‑management routines. You can also strengthen your Service Management System without redrawing your org chart. The magic happens when you intentionally align the two.
In part 3, we will show how this alignment is exactly what makes ITSM governable.
What a Service Management System is not
To avoid confusion, it helps to be explicit about the negative space.
Not just your ITSM tool
The tool implements practices and holds data, but the SMS decides why those practices exist, how they connect, and how they are governed and improved over time.
Not just process documentation
You can have 200 pages of beautifully formatted processes and still have no real SMS. If there is no agreed scope, no owner, no review cadence and no link to risk and business objectives, you have a library, not a system.
Not a framework religion
ISO 20000, ITIL and USM each bring useful ideas: ISO 20000 defines what an SMS must cover. ITIL provides detailed practice guidance. USM offers a very lean management‑system structure and generic processes. Your SMS is how your organisation chooses and combines these elements. If you start from the framework, you risk over‑engineering. If you start from your SMS, you tend to simplify.
Not only about certification
Certification can be strategically valuable – signalling quality, discipline and competitive differentiation. But the primary purpose of an SMS is to actually run and improve services, manage risk and meet obligations like NIS2 in an auditable, sustainable way.
In Service Management System Discovery — 3, we will look at how this seemingly "boring" management‑system layer is exactly what gives you credible governance, risk control and regulatory confidence – without drowning everyone in bureaucracy.