Articles on ESM Guide

ITSM, SaaS or self-hosted: how to decide

Tue, 22 Sep 2026 00:00:00 +0000

In short:

The decision is not about licence price but about five cost lines, of which operations is the most underestimated.

SaaS transfers operations to the vendor and, in return, fixes the upgrade rhythm.

Self-hosting keeps control of the calendar but assumes a team available in three years, not only today.

Three non-financial constraints often decide before cost: data location, integration depth, internal skills.

What the decision actually covers

Presented as a choice between two prices, SaaS versus self-hosting is really a choice between two ways of splitting the work. In one, the vendor carries infrastructure, backup and upgrades. In the other, the organisation does, or its integrator.

Choosing an ITSM platform: the criteria grid

Wed, 16 Sep 2026 00:00:00 +0000

In short:

Six criteria genuinely separate ITSM platforms, and functional richness is not among them.

On core processes, incident, request and change, every serious platform performs alike.

The billing unit, technician or end user, weighs more on five-year cost than any single feature.

The service catalogue is written before the consultation, not after: it is what makes demos comparable.

What to settle before looking at any tool

Most tenders start with a feature grid sent to vendors. That is the reverse of the order that produces a good decision. Until scope is written down, every vendor answers on its own ground and the answers are not comparable.

Automated IT inventory: the methods compared

Wed, 09 Sep 2026 00:00:00 +0000

In short:

Three collection methods coexist: agent, agentless, network discovery by scanning.

The agent returns the most complete software inventory and works outside the corporate network.

Network discovery is the only method that detects unmanageable equipment.

A real estate almost always combines all three, at different collection frequencies by device type.

Why manual inventory does not hold

An IT estate moves constantly: workstations replaced, software installed on user initiative, virtual machines created then forgotten. A manually maintained IT inventory is wrong the day it is published. The question is therefore not whether to automate, but by which method.

CMDB: what it is for and how to feed it

Wed, 02 Sep 2026 00:00:00 +0000

In short:

A CMDB records configuration items and, above all, the dependency relationships linking them.

Its primary use is impact analysis, before a change or during a major incident.

An inventory lists assets, a CMDB adds dependencies: they are two different objects.

Manual population always drifts: automated collection is the only sustainable option.

What a CMDB actually contains

A CMDB, for Configuration Management Database, records the configuration items of an information system: servers, workstations, applications, services, contracts. But the list is not the point. What separates a CMDB from a spreadsheet is the relationships between those items: which server hosts which database, which database feeds which application, which application delivers which business service.

Defining support SLAs that actually hold

Fri, 28 Aug 2026 00:00:00 +0000

In short:

An SLA rests on a priority matrix crossing urgency and impact, never on urgency as declared by the requester.

Two distinct commitments are required: response time and restoration time.

Calibration is done on the median actually observed, not on a theoretical target.

Without pausing the clock while waiting on the requester, the metric becomes unfair and stops being used.

What an SLA actually commits to

A service level agreement is a commitment made to users on measurable turnaround times. It does not describe an ambition, it describes an enforceable promise. This is why an SLA set above the team’s real capacity produces the opposite of the intended effect: breaches become the norm, and nobody looks at the indicator any more.

Service desk and help desk: the vocabulary sorted

Wed, 26 Aug 2026 00:00:00 +0000

In short:

A help desk handles faults, a service desk handles faults and service requests.

ITIL keeps only the term service desk, defined as the single point of contact between provider and users.

The three-tier pattern, generalist then specialist then vendor, remains the reference structure.

First-line resolution rate depends directly on the quality of the knowledge base made available.

Three terms, three scopes

The help desk emerged from the need to centralise the reporting of IT faults. Its scope is corrective: a user sees a malfunction, reports it, a team fixes it.

Incident and problem management: stop confusing them

Fri, 21 Aug 2026 00:00:00 +0000

In short:

An incident is measured in time to restore, a problem in incidents avoided.

A workaround closes an incident but never closes a problem.

Grouping recurring incidents is the main entry signal for problem management.

A known error is a problem with an identified cause and a documented workaround, ahead of the permanent fix.

Two practices, two clocks

An incident is an unplanned interruption to a service or a reduction in its quality. The associated practice pursues one objective: restore service as quickly as possible. Restart, fail over, reassign a licence, the means hardly matter, including when they fix nothing fundamental.

ITIL 4: the 7 guiding principles explained

Wed, 19 Aug 2026 00:00:00 +0000

In short:

ITIL 4, published in 2019, places seven guiding principles ahead of its 34 management practices.

These principles are rules of conduct, not processes to execute: they exist to arbitrate, not to run.

Three of them, start where you are, keep it simple and progress iteratively, are enough to frame most projects.

The framework cannot certify an organisation: that certification falls under the ISO/IEC 20000 standard.

Why ITIL 4 starts with principles

Earlier ITIL versions mostly described processes. ITIL 4 reverses the order and sets out seven guiding principles, valid in any context, before going into practice detail. The intent is explicit: avoid the mechanical application of a procedure catalogue to an organisation whose actual maturity nobody has examined.

ESM vs ITSM: what actually changes

Fri, 14 Aug 2026 00:00:00 +0000

In short:

ITSM and ESM rest on the same objects: service catalogue, ticket, priority, turnaround commitment, knowledge base.

The only structural difference is scope: IT for ITSM, every support function for ESM.

Moving from one to the other is a governance project, not a technical one.

Three technical capabilities gate the transition: multiple catalogues, multiple assignment queues, partitioned access rights.

Two acronyms, one mechanism

ITSM organises the services delivered by the IT department. ESM applies the same reasoning to every function delivering an internal service. The building blocks are identical: describe a service, open a channel to request it, assign the request to someone, commit to a deadline, measure.

Enterprise Service Management: definition and scope

Wed, 12 Aug 2026 00:00:00 +0000

In short:

ESM applies to non-IT departments the service management practices born in IT: catalogue, request portal, workflows and measured turnaround times.

The four functions most often involved are human resources, facilities, finance and legal.

An ESM initiative is not a tool purchase: it starts with a written service catalogue and its committed turnaround times.

The ITIL 4 framework describes 34 management practices, a large majority of which apply as-is outside the IT perimeter.

What Enterprise Service Management covers

Enterprise Service Management means applying, across the whole organisation, the service management principles formalised in IT since the 1990s. The reasoning is straightforward: a badge request sent to facilities and a password reset sent to IT raise exactly the same organisational problem. Who receives it, within what deadline, following which procedure, and how does the requester track progress.