ESM
ITSM ou ESM : faut-il vraiment étendre la logique service aux RH et au Facility ?
L'ESM séduit les directions, mais pas tous les contextes s'y prêtent. Voici les conditions concrètes pour réussir l'extension de la logique service aux fonctions métier.
Photo : Moe Magners sur Pexels
L'ESM (Enterprise Service Management) est devenu en quelques années un argument de vente standard pour les éditeurs d'outils ITSM. La promesse est séduisante : appliquer aux RH, aux services généraux ou aux achats les mêmes principes qui ont structuré la gestion des services IT. Catalogue, workflows, SLA, suivi des demandes. Une logique unifiée pour toute l'organisation.
Sur le papier, c'est cohérent. Sur le terrain, c'est plus nuancé.
Pourquoi l'ESM séduit autant les directions
L'argument central est financier. Une fois qu'une organisation a investi dans un outil ITSM, l'étendre à d'autres fonctions revient moins cher que de déployer un outil dédié pour chacune. Une seule licence, une seule équipe de support, une seule logique de gouvernance.
L'argument secondaire est managérial. Les directions générales apprécient l'idée d'une vue consolidée sur la performance des fonctions support. Combien de demandes, combien de délais respectés, combien de tickets ouverts. Un tableau de bord transverse.
Le troisième argument est culturel. À l'heure où la qualité de l'expérience employé devient un enjeu de fidélisation, l'ESM permet de standardiser le niveau de service délivré à un collaborateur, quelle que soit la direction sollicitée.
Mais l'extension n'est pas mécanique
Une fonction métier n'est pas une copie de la DSI. Les processus RH ont leurs propres règles de confidentialité. Les achats fonctionnent avec des cycles de validation longs et structurés. Les services généraux gèrent des demandes très hétérogènes, souvent ponctuelles, qui ne se prêtent pas toujours à la standardisation.
Plaquer mécaniquement un modèle ITSM sur ces fonctions est la cause d'échec la plus fréquente que nous observons. Les équipes métier ne se reconnaissent pas dans les processus imposés, contournent l'outil, et la promesse de la vue consolidée s'évapore.
Les conditions concrètes pour réussir
L'ESM amplifie une organisation existante, il ne la crée pas.
Trois conditions sont nécessaires pour qu'une démarche ESM produise vraiment de la valeur.
Une fonction métier mûre dans sa propre gestion
Si votre direction RH n'a pas formalisé ses processus en interne, l'outil ne va pas faire le travail à sa place. Il va simplement digitaliser un désordre, et le rendre plus visible.
Avant de déployer un outil ESM sur une fonction, il faut s'assurer que cette fonction a déjà clarifié son catalogue de services, ses rôles et responsabilités, et ses niveaux d'engagement vis-à-vis du reste de l'organisation.
Un sponsor interne à la fonction concernée
L'ESM piloté uniquement par la DSI ne fonctionne pas. La fonction qui adopte l'outil doit avoir son propre sponsor, qui porte le projet en interne, arbitre les choix de configuration, et défend l'outil auprès de ses équipes.
Sans ce relais, l'extension reste un projet IT vu de loin par les autres directions. Avec lui, l'outil devient un levier de transformation de la fonction elle-même.
Un pilotage incrémental, pas un big bang
Étendre l'outil à plusieurs fonctions en parallèle est tentant. C'est aussi le meilleur moyen d'échouer partout simultanément.
Une approche par vagues est plus prudente. Une fonction pilote sur 6 mois, retours d'expérience, ajustements, puis extension à une seconde fonction. C'est plus long, mais le taux d'adoption final est sans commune mesure.
Quand ne pas faire d'ESM
Si votre organisation n'a pas encore stabilisé sa propre gestion des services IT, faire de l'ESM est prématuré. Les fondations doivent tenir d'abord.
Si vos fonctions métier ont des processus très spécifiques (un outil de paie pour les RH, un ERP pour les achats), forcer une couche ESM par-dessus crée plus de friction qu'elle n'apporte de valeur.
Si votre DSI n'a pas la bande passante pour accompagner sérieusement chaque fonction qui adopte l'outil, mieux vaut différer le projet plutôt que livrer une coquille vide.
Ce qu'il faut retenir
L'ESM est une belle idée, mais c'est avant tout un projet de transformation managériale, pas un déploiement technique. La technologie ne fait que cristalliser ce que l'organisation a déjà clarifié, ou échoué à clarifier.
Si votre DSI vous propose de passer à l'ESM, posez-lui trois questions simples : quelle fonction est mûre pour cette transition, qui en sera le sponsor côté métier, et sur combien de temps prévoit-on de déployer. Si les réponses ne sont pas claires, ce n'est probablement pas le bon moment.