ESM implementation: a roadmap from first department to full rollout

An ESM implementation rarely goes wrong on the technology. The platform can almost always do it. It goes wrong on the things around it: who owns it, how you stop every department building its own island, and whether the catalogue speaks the language of the user or of IT. This article gives a roadmap from the first department beyond IT to a full rollout, with an emphasis on the pitfalls that strand most projects.

Before you start, it helps to be clear on what ESM is and how it differs from ITSM. That is covered in ITSM vs ESM. In short: ESM is the same service desk approach, applied to departments beyond IT.

Step 0: make sure your ITSM is solid

The first step is one many organizations skip. Before you roll service management out to HR or facilities, it has to run well in IT itself. If your own service desk still struggles with the basics, you export those problems to the rest of the organization.

So first map where you stand. An ITSM maturity assessment shows whether the foundation is solid enough to build on. If ITSM is not running yet, improve there first before you widen.

Step 1: pick the first department

Do not start with a big rollout to all departments at once. Pick one department with a concrete problem and enough volume to make it worthwhile. HR is often a good first, because the joiner-mover-leaver process touches IT anyway and the pain is visible: a new employee who does not have everything ready on day one is a problem everyone recognises.

More important than which department you pick is that the department sees the value itself. A department that did not ask for it and experiences it as a burden will avoid the portal. Look for a department with an internal champion who wants it.

Step 2: set up the service in customer language

This is the pitfall most ESM projects run aground on. IT thinks in incidents, changes and configuration items. An HR employee thinks in "register a new employee" or "request leave". If you force the new department to work in IT terms, you shut out exactly the people who have to use it.

So set up the service catalogue from the user's point of view. What does someone want to request, and what do they call it themselves? How to approach that is covered in a service catalogue in customer language. This is not cosmetic: the difference between a catalogue that gets used and one that gets avoided often sits exactly here.

Step 3: arrange governance and ownership

An ESM rollout without clear governance becomes sprawl over time. Every department builds its own forms, its own statuses, its own way of working, and after a year you have six separate systems behind one portal. That is the opposite of what you wanted.

So arrange a few things up front:

• An owner per department. Someone in HR, facilities or finance responsible for the quality of their own service in the platform. Without that person it fades.
• A central agreement about the shared parts. Statuses, priorities and the base setup stay shared, so the platform remains one whole instead of separate islands.
• Clear roles and permissions. HR should not see IT tickets and vice versa. During tool choice, check whether the platform separates that properly per department.

Governance sounds heavy, but it does not have to be bureaucratic. It comes down to a few clear agreements about what stays shared and what may differ per department. That is service management without ITIL dogma applied to ESM: only rules where they deliver something.

Step 4: connect the processes that touch each other

The real gain of ESM sits in processes that touch multiple departments. The joiner-mover-leaver process is the clearest example: one request in HR automatically triggers tasks at IT (account, laptop) and facilities (workplace, badge). If that runs as one chain through the organization, nothing is missing anymore.

Build those connections only once the separate departments work on their own. Connecting a chain between two processes that still rattle internally makes the problem bigger, not smaller. Watch the technical side too: connections between HR systems and the ITSM platform need maintenance and an owner. What goes wrong there is covered under integrations in choosing an ITSM or ESM tool.

Step 5: measure, learn, and only then expand

Before you move to the next department, check whether the first genuinely delivers something. Are requests handled faster? Do users find the portal? Is the department owner satisfied? Only once that demonstrably runs is it worth expanding.

Take the lessons of the first department into the next. What worked in the catalogue, which governance agreements held, where it got stuck. That way each next rollout gets easier instead of repeating the same mistakes. ESM grows organically with the organization, instead of as a big programme that has to land everywhere at once.

The pitfalls at a glance

The most common reasons an ESM implementation strands:

• Starting too broad. All departments at once instead of one done well. The result is half-finished work everywhere.
• The catalogue in IT language. The new department has to think in incidents and changes, and drops out.
• No owner per department. The platform is there, but nobody guards the quality of the service.
• No central governance. Every department builds its own island, and the coherence disappears.
• Expanding before the first works. Adding the next department while the previous one does not run yet stacks the problems.

Avoid these five and the rest is mostly patience and discipline: start small, measure, learn, and only expand once it stands.

Frequently asked questions

Where do you start with an ESM implementation? First make sure your IT service management is solid, then pick one department with a concrete problem and enough volume, often HR at onboarding. Set the service up in customer language, arrange an owner in that department, and only expand once the first demonstrably runs.

What is the biggest pitfall with ESM? Setting up the catalogue in IT language. If the new department has to think in incidents, changes and configuration items, you shut out exactly the people who have to use it. Set up the catalogue from the user's request, in their own words.

Do you need separate governance for ESM? Yes, but it does not have to be bureaucratic. Arrange an owner per department, keep the shared setup (statuses, priorities) central, and separate roles and permissions per department. A few clear agreements prevent every department from building its own island.

How long does an ESM implementation take? That depends on how many departments you connect and how mature your ITSM already is. Count in months per department, not weeks, and only expand once the previous department runs. A broad rollout all at once almost always yields half-finished work everywhere.

Want to roll out ESM without it becoming a programme that gets stuck on governance and ownership? book a call and we will decide together on the first department and the approach. For support with the rollout, see our ESM implementation service.

Further reading

• Enterprise service management (Wikipedia)
• What is ESM? (Atlassian)
• ITSM glossary (Gartner)
• ITIL (AXELOS)