What Is ITIL and ITSM? A Practical ITIL 4 Guide

The two terms get used interchangeably in almost every IT service conversation, yet the distinction is simple: ITSM answers "what should we do", ITIL answers "how can we do it". Getting that separation right also clarifies which discussion belongs at which level of the organisation.

What is ITSM?

ITSM (IT Service Management) is the practice of treating an organisation's IT capabilities not as technical assets — servers, applications, licences — but as services delivered to end users. The focus is not the technology itself, but the value that technology contributes to business outcomes.

In practice, ITSM institutionalises the answers to a handful of questions:

• Which services do we offer, and who owns each one?
• When a user raises a request, what resolution time have we committed to?
• When an outage occurs, who responds, and in what order?
• When the same fault recurs for the third time, who investigates the root cause?
• Who approves a change to production, and what is the rollback plan?

Gains on the IT side: repeatable and scalable processes, clearly defined roles and responsibilities, a shorter gap between detection and resolution, recurring problems closed permanently, and data that makes performance measurable.

Gains on the business side: employees know which service to request and where, outages become less frequent and shorter, IT costs become visible, and IT responds faster to market change.

What is ITIL, and how does it differ from ITSM?

ITIL (Information Technology Infrastructure Library) is the most widely adopted best-practice framework for implementing ITSM. It is neither a product nor a standard — it is accumulated industry experience on planning, delivering and continually improving services.

ITIL is not the only option. ISO/IEC 20000-1 offers an auditable standard, COBIT focuses on governance and control, DevOps prioritises flow and automation, and SIAM addresses multi-supplier environments. In mature organisations these usually coexist as layers rather than alternatives.

What changed from ITIL v3 to ITIL 4?

The older ITIL v3 model was built on a linear five-stage lifecycle: Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement. It worked in its era, but as cloud, Agile and DevOps spread it became too heavy and too sequential.

ITIL 4, published in 2019, dropped the linear lifecycle and reorganised around the Service Value System:

• The narrow notion of "process" gave way to the broader notion of "practice" — 34 in total: 14 general management, 17 service management and 3 technical management.
• Value is no longer a one-way street where IT delivers and the business consumes; it is co-created.
• Agile, Lean and DevOps sit inside ITIL rather than opposite it.

The four building blocks of ITIL 4

Seven guiding principles

Focus on value; start where you are; progress iteratively with feedback; collaborate and promote visibility; think and work holistically; keep it simple and practical; optimise and automate.

Four dimensions

Organisations and people; information and technology; partners and suppliers; value streams and processes. Design a service without all four — deploying a tool but never defining roles, for example — and the result will be incomplete.

Service value chain

The six operational activities above are not a fixed sequence; they combine differently across value streams depending on the type of demand.

Practices

You do not need to adopt all 34 — attempting to is the single most common mistake. Most organisations start with five.

The five most commonly adopted practices

Putting ITIL to work: Jira Service Management

A framework does not run on its own; it needs a platform where requests arrive, get assigned and get measured. Atlassian's Jira Service Management (called Jira Service Desk until 2020) covers most ITIL practices with ready-made templates:

• Service catalogue and request types — self-service portal, conditional forms, approval flows
• Incident management — impact/urgency matrix, alerting and on-call, post-incident review
• Problem management — linking incidents to problem records, known error records
• Change enablement — risk-scored automatic approval; change records triggered from CI/CD tooling
• Asset and configuration management — hierarchical inventory schemas in Assets (formerly Insight), assignment workflows, dependency mapping
• Knowledge management — Confluence integration; suggesting articles as the user types a request
• AI — a Rovo-powered virtual service agent closing repetitive requests at first contact

There is independent validation of that coverage too: Atlassian announced that the product had earned PinkVERIFY certification — the industry reference for ITSM tooling — for the core ITIL processes (Atlassian's announcement). Two caveats are worth stating: the certification dates from when the product was called Jira Service Desk, and it was awarded against ITIL v3/2011 process definitions. Alignment with ITIL 4 practices depends far less on the tool than on configuring it around the organisation's real service structure.

Almbase's contribution goes beyond installing the product: modelling the service catalogue against how the organisation actually works, configuring SLA calendars correctly, designing an Assets schema that can carry real inventory and assignment processes, and building a reporting layer that answers management's questions.

The next step: taking ITSM beyond IT

Requests, approvals and SLAs are not unique to IT. HR onboarding and leave, legal contract approvals, finance purchase requests, facilities services by location — all can run on the same structure. This is ESM (Enterprise Service Management), and it is usually the natural step once ITSM has matured within IT.

The hardest part of that expansion is deskless, field-based teams. FieldSnap, developed by Almbase, integrates with JSM so field teams can raise fault and work reports from a mobile device — without needing a JSM licence or a corporate email account.

Where to start

Four common mistakes

1. Trying to adopt all 34 practices at once. Conforming to the framework is not the goal; improving service quality is.
2. Substituting a tool for a process. An implementation without defined roles, ownership and escalation logic simply digitises the existing chaos.
3. Starting without a baseline. If you don't know your current MTTR, you can't prove any improvement.
4. Writing the catalogue in IT language. Not "Exchange mailbox quota increase" but "My mailbox is full" — users search in their own words.

Frequently asked questions

Are ITIL and ITSM the same thing?

No. ITSM is the name of the discipline; ITIL is the framework used to practise it.

What is an ITIL 4 certification for?

It certifies individual competence. Organisations are certified against ISO/IEC 20000-1, not ITIL.

Does ITIL conflict with Agile and DevOps?

No. ITIL 4 explicitly incorporates them; "optimise and automate" is one of its guiding principles.

Is ITIL too heavy for a small IT team?

If you adopt all of it, yes. A start limited to request and incident management delivers measurable benefit even for a team of five.

Is Jira Service Management ITIL compliant?

JSM ships ready-made process templates for the core ITIL practices, and the product earned PinkVERIFY certification for core ITIL processes back when it was called Jira Service Desk. Even so, compliance comes not from the tool but from configuring it around the organisation's real service structure.