ESM
ITSM or ESM: should you really extend the service logic to HR and Facilities?
ESM appeals to leadership teams, but not every context is ready for it. Here are the concrete conditions for successfully extending the service logic to business functions.
Photo: Moe Magners on Pexels
ESM (Enterprise Service Management) has become, in just a few years, a standard sales pitch from ITSM vendors. The promise is appealing: apply to HR, facilities or procurement the same principles that have structured IT service management. Catalogues, workflows, SLAs, request tracking. A unified logic across the whole organisation.
On paper, it's consistent. On the ground, it's more nuanced.
Why ESM appeals to leadership
The central argument is financial. Once an organisation has invested in an ITSM tool, extending it to other functions costs less than deploying a dedicated tool for each one. A single licence, a single support team, a single governance logic.
The secondary argument is managerial. Executive committees like the idea of a consolidated view on the performance of support functions. How many requests, how many deadlines met, how many open tickets. A cross-functional dashboard.
The third argument is cultural. As employee experience becomes a retention lever, ESM offers a way to standardise the level of service delivered to a colleague, regardless of which function they reach out to.
But extension is not mechanical
A business function isn't a copy of the IT department. HR processes have their own confidentiality rules. Procurement runs on long, structured validation cycles. Facilities handles very heterogeneous, often one-off requests that don't always lend themselves to standardisation.
Mechanically applying an ITSM model to these functions is the most frequent cause of failure we observe. The business teams don't recognise themselves in the imposed processes, they work around the tool, and the promise of a consolidated view evaporates.
The concrete conditions for success
ESM amplifies an existing organisation, it doesn't create one.
Three conditions are necessary for an ESM initiative to genuinely create value.
A business function mature in its own management
If your HR department hasn't formalised its processes internally, the tool isn't going to do the work for them. It will simply digitise disorder, and make it more visible.
Before deploying an ESM tool on a function, you have to make sure that function has already clarified its service catalogue, its roles and responsibilities, and its commitments to the rest of the organisation.
An internal sponsor within the function
ESM driven solely by the IT department doesn't work. The function that adopts the tool must have its own sponsor, who carries the project internally, arbitrates configuration choices, and defends the tool to its teams.
Without that relay, the extension stays an IT project seen from a distance by the other departments. With it, the tool becomes a transformation lever for the function itself.
Incremental rollout, not big bang
Extending the tool to several functions in parallel is tempting. It's also the best way to fail everywhere simultaneously.
A wave-based approach is more prudent. One pilot function over 6 months, lessons learned, adjustments, then extension to a second function. It's slower, but the final adoption rate is in a different league.
When not to do ESM
If your organisation hasn't yet stabilised its own IT service management, doing ESM is premature. The foundations have to hold first.
If your business functions have very specific processes (a payroll tool for HR, an ERP for procurement), forcing an ESM layer on top creates more friction than value.
If your IT department doesn't have the bandwidth to seriously support every function that adopts the tool, it's better to delay the project than deliver an empty shell.
What to remember
ESM is a fine idea, but it's first and foremost a managerial transformation project, not a technical deployment. Technology only crystallises what the organisation has already clarified, or failed to clarify.
If your IT department is proposing to move to ESM, ask three simple questions: which function is mature enough for this transition, who will be its business-side sponsor, and over what timeline. If the answers aren't clear, it's probably not the right moment.