Stratégie

Cinq écueils associés aux projets ITSM et les solutions pour les surmonter

Thomas Smith, directeur des télécommunications et du support IT chez Service Corp. International : « Comprenez toutes les lacunes de votre outil ITSM et dites aux responsables des processus métier que vous avez un plan pour y remédier. »

En faire trop et trop vite, ne pas communiquer suffisamment, ne pas se concentrer sur le métier... Comme dans de nombreuses initiatives IT, ces erreurs courantes peuvent nuire à l'efficacité de l'ITSM. CIO États-Unis passe en revue quelques-uns des pièges classiques des démarches ITSM et propose des pistes pour les éviter.

PublicitéBien menée, la gestion des services IT (ITSM - IT service management) réduit les coûts des actifs et de la gestion IT, augmente la productivité et la satisfaction des employés et donne aux dirigeants un aperçu de la manière dont les ressources IT sont utilisées pour aider l'entreprise et les métiers.

L'ITSM se définit comme l'ensemble des politiques et procédures de conception et de fourniture de services informatiques aux utilisateurs finaux. Il s'étend au-delà du support IT ou du service d'assistance, englobant toute la surveillance, la gestion et le dépannage nécessaires pour améliorer constamment les services informatiques afin de répondre aux besoins des métiers. Une démarche ITSM efficace nécessite, entre autres, d'identifier quels composants technologiques, comme des serveurs et bases de données, prennent en charge quelles applications, de documenter correctement ces connaissances et d'affiner les processus de support. Au fil du temps, à mesure que ces relations et dépendances deviennent plus complexes, l'ITSM peut devenir trop coûteux et trop axé sur la technologie plutôt que sur le métier. Voici quelques écueils courants de l'ITSM et la manière de les éviter.

1. Avoir trop de choses sur le feu

« N'en faites pas trop, trop vite », affirme Christian Hjortkjær, responsable de la gestion des actifs et services IT de l'aéroport de Copenhague. En utilisant la plate-forme ITSM de ServiceNow, « nous avons commencé avec l'ITSM de base, comme la gestion des incidents et la gestion des changements », mais nous avons limité leur utilisation à certains périmètres, comme les ordinateurs portables et les logiciels. L'aéroport a ensuite étendu lentement l'ITSM à d'autres services, comme la commande de cartes d'accès et de permis de stationnement. « Si nous avions offert tous les services dès le début, nous aurions lamentablement échoué, car cela nécessite du temps et des ressources », estime Christian Hjortkjær. La création d'une base de connaissances pour les utilisateurs était un autre sujet, sur lequel l'aéroport a été « trop ambitieux », selon le responsable ITSM, car il n'avait pas mis en place de processus appropriés pour la mettre à niveau et la maintenir. Traquer les inexactitudes et les informations obsolètes nécessite du temps et des efforts pour corriger les problèmes, explique Christian Hjortkjær.

« Commencez petit, avec les fonctions de base, et révisez-les régulièrement. Assurez-vous qu'elles font partie de la culture de votre organisation IT avant de passer à des fonctions avancées telles que l'intelligence artificielle », conseille Chris Matchett, directeur de recherche senior chez Gartner. Documentez et optimisez les processus avant de les automatiser, suggère-t-il. « Si le processus est fondamentalement défectueux, l'automatisation ne peut que déboucher encore et encore sur de mauvais résultats », souligne le directeur de recherche. L'une des premières étapes pour Christian Hjortkjær a été d'exploiter ServiceNow pour créer une source de données partagée, communément appelée configuration management database (CMDB), « avec des liens bien documentés vers des applications métiers. L'utilisation de la CMDB pour suivre, par exemple, quels services dépendent de quels serveurs aide le personnel IT à déterminer les pannes les plus critiques, à commencer à les résoudre et à informer rapidement les utilisateurs des applications touchées du problème », explique le responsable ITSM.

PublicitéLes clients utilisant le cadre ITIL (Information Technology Infrastructure Library) pour l'ITSM doivent s'assurer de créer un catalogue de services informatiques et des processus de gestion clairs et bien définis, souligne Rubén Ávila Calvo, directeur technique (CTO) de la société d'inspection et de test Applus. ITIL « demande que vous ayez une définition claire des processus, des rôles et des responsabilités, où chaque étape est correctement documentée, les responsabilités sont claires et il existe une procédure en place qui garantit que le service est fourni avec un SLA [accord de niveau de service] sur lequel vous vous engagez. Ne pas fournir ces fondamentaux peut entraîner des coûts plus élevés et un service de qualité inférieure, car les problèmes de services sont remontés vers les mauvais interlocuteurs », observe le CTO. Cécile Blackburn, responsable mondiale des services aux utilisateurs finaux dans le groupe de produits chimiques agricoles Corteva, se souvient ainsi d'un week-end où un ticket d'assistance utilisateur a été acheminé vers une équipe d'assistance qui ne travaillait pas pendant le week-end, au lieu de l'équipe qui le faisait. « L'activité a été vraiment perturbée, en raison de la difficulté à associer » le service métier aux composants informatiques qui fournissaient ce service, confie-t-elle.

2. Négliger le métier

Il est tentant de se concentrer sur « l'IT » dans l'ITSM, mais son véritable objectif est de fournir des services aux métiers. Ne pas concevoir l'ITSM avec le métier en tête et ne pas décrire ses avantages en termes business réduit l'adoption et rend son utilisation plus déroutante pour les métiers. « Si je suis côté métier, je me fiche du nombre d'incidents informatiques », illustre Christian Hjortkjær. « Tout ce qui m'importe, c'est mon application, combien d'incidents celle-ci a-t-elle subis et comment les ai-je résolus ? » Le responsable ITSM ne peut fournir des rapports significatifs à son PDG que s'il peut lier « ses incidents à l'élément de configuration correct, qui est ensuite connecté à la bonne application métier » et mettre en contexte la manière dont ces services contribuent à améliorer les opérations aéroportuaires.

Un défi que Corteva a relevé avec ServiceNow ITSM était de savoir comment associer des composants informatiques disparates, de sorte que le propriétaire d'une application n'ait pas à « courir après les équipes chargées des serveurs, des bases de données et du pare-feu juste pour créer une application à livrer au métier. Une telle situation signifie beaucoup de temps perdu. Il y a des retards pour enregistrer les tickets et des retards pour trouver comment résoudre un problème », constate Kshitij Bahadur, responsable de l'intégration des services d'entreprise chez Corteva.

De son côté, Eugene Mejia, directeur adjoint de la technologie de la ville de Gilbert, en Arizona, et son équipe ont fait de l'amélioration de l'expérience des 1 600 employés de la ville un objectif métier clef pour ses efforts ITSM. Lui et l'équipe de direction IT réalisent des sondages mensuels auprès des employés pour mesurer leur succès dans le développement de fonctionnalités telles que la qualité des interfaces Web ou des applications mobiles pour faciliter le travail à distance. Ils utilisent Cisco Unified Communications Manager et Webex Contact Center pour gérer les files d'attente d'appels pour les demandes de service et le dépannage. Mettre ainsi l'accent sur l'expérience des employés est « très motivant » pour les cadres dirigeants qui doivent financer l'ITSM, pointe Will McKeon-White, analyste chez Forrester.

3. Rater la communication

Une communication peu claire rend bien plus difficile l'explication de la valeur de l'ITSM au métier, l'organisation correcte des efforts ITSM, la définition des attentes pour son déploiement et l'obtention d'un financement adéquat pour celui-ci.

Christian Hjortkjær suggère d'utiliser la CMDB pour mapper les composants informatiques avec les applications métiers, attribuer la propriété de ces applications à des sponsors côté IT et métier, et demander à ces sponsors d'expliquer le rôle de chaque application au métier, ainsi que la meilleure façon de les utiliser et éventuellement quand les remplacer. Thomas Smith, directeur des télécommunications et du support IT chez le fournisseur de biens et services funéraires Service Corp. International, recommande quant à lui d'être franc sur les délais. « L'une des plus grosses erreurs que nous ayons commises dans le passé, et que nous commettons encore, est de dire 'Nous allons le faire en trois mois.' Quatre mois plus tard, tout le monde espère toujours trois mois », dit-il. « Comprenez toutes les lacunes de votre outil ou de vos services ITSM, recommande-t-il, et dites aux responsables des processus métier que vous avez un plan pour y remédier ». Rubén Ávila Calvo, d'Applus, affirme pour sa part que les termes des SLA, tels que ceux qu'il a créés à l'aide de la plate-forme HelixITSM de BMC, peuvent aider à définir les attentes et à réduire la frustration des utilisateurs qui « pensent que tout doit être résolu dès que possible ».

Une communication claire peut également aider les propriétaires d'applications métiers à s'entendre pour savoir quand la personnalisation se justifie face aux futurs problèmes de maintenance qui vont en découler, pointe Will McKeon-White. « Tout le monde essaie de répondre aux besoins de l'organisation d'une façon qu'ils comprennent. Mais ils peuvent ne pas être alignés sur des aspects comme les résultats attendus par les clients, la manière de gérer la réduction des risques, etc. », dit-il. Il est également nécessaire, selon Thomas Smith, de définir spécifiquement ce dont les utilisateurs ont besoin dans les outils de support ITSM tels que la plate-forme Ivanti Neurons for ITSM qu'il a utilisée. Cela peut inclure, par exemple, « ce qu'un utilisateur voit sur son formulaire W-9*, dans une interface de prestations sur le Web, ou ce qu'il entend quand il dit que l'écran n'arrête pas de planter », dit-il. De telles exigences peuvent être difficiles à définir, car, par exemple, « un membre de l'équipe RH peut ne pas comprendre la différence entre un incident et une demande de service ». Il consulte les utilisateurs informatiques et métiers pour partager les termes et les définitions, afin de s'assurer que chacun comprend la signification de chaque exigence et s'est mis d'accord sur sa priorité.

4. Faire trop de spécifique

Will McKeon-White, de Forrester, considère la personnalisation excessive comme l'un des plus grands défis qu'il observe dans les projets ITSM. Les clients modifient les systèmes ITSM « pour ce qu'ils estiment être des raisons légitimes », dit-il. Au fur et à mesure que de nouvelles modifications sont apportées au système et que les employés qui ont apporté ces modifications quittent l'entreprise, « il est impossible de retracer quelles modifications ont été apportées ou pourquoi, ce qui rend le système ITSM plus difficile à gérer et à mettre à niveau.... Le problème réside moins dans les fonctions personnalisées au niveau individuel, que dans la manière dont toutes ces personnalisations fonctionnent ensemble », dit-il. En raison du nombre et de la complexité des interactions entre les composants d'une plate-forme ITSM, il constate : « Si vous voulez changer quoi que ce soit, vous ne pouvez pas, car si vous touchez à une chose, cela en cassera une autre. »

Kshitij Bahadur partage cet avis, disant que souvent « les différentes équipes IT établissent chacune leurs propres pratiques de support, et certaines sont plus robustes que d'autres ». Il recommande de résister à la pression pour mettre en oeuvre ces processus comme des exceptions. « Un jour, vous vous rendrez peut-être compte que vous avez plus d'exceptions que ce que vous pouvez gérer, et que l'outil a été tellement personnalisé qu'il devient difficile à maintenir », note le responsable de l'intégration des services de Corteva. « Plutôt que de faire beaucoup de spécifique, nous voulons utiliser autant de workflows prêts à l'emploi que possible et modifier nos propres processus et workflows », explique Eugene Mejia, de la ville de Gilbert, car les créateurs des outils ITIL et ITSM « sont les experts ».

5. Oublier de faire vivre le projet

L'ITSM ne peut pas être entièrement mis en oeuvre en tant que projet limité dans le temps », met en garde Chris Matchett de Gartner. Ne pas assurer une gestion et une formation en continu peut réduire l'efficacité de l'ITSM, en particulier à mesure que les exigences de l'entreprise et l'outil ITSM lui-même changent, dit-il. La plupart des outils ITSM sont proposés en tant que logiciel en tant que service, ce qui signifie que c'est le fournisseur de logiciels plutôt que le client qui gère l'infrastructure sous-jacente. Cependant, selon Will McKeon-White, les clients doivent prévoir « une ou deux personnes pour effectuer une optimisation continue, qu'il s'agisse de servir les clients, d'améliorer la résilience, de réduire les risques de changement, d'améliorer les processus de gestion des incidents, de s'assurer que tous ceux qui aident à résoudre le problème obtiennent toutes les bonnes informations et de comprendre l'état des travaux en cours. »

Christian Hjortkjær affirme que l'ITSM nécessite une formation continue des utilisateurs aux nouveaux processus, en particulier lors du passage à des plates-formes plus avancées. Ces formations peuvent « montrer les fonctionnalités intéressantes, les fonctionnalités sophistiquées, les impacts que l'ITSM peut avoir sur votre travail quotidien, des tableaux de bord aux rapports en passant par les raccourcis... (les) nombreuses façons dont vous pouvez configurer votre écran ITSM pour vous rendre plus productif et vous aider dans votre travail quotidien », illustre le responsable ITSM de l'aéroport de Copenhague.

Comme pour de nombreuses initiatives IT, la gestion des services fonctionne mieux lorsqu'elle est conçue autour des besoins du métier, que ses apports sont clairement communiqués, qu'elle n'entraîne pas de dette technique cachée à long terme et qu'elle est correctement gérée dans le temps.

* Formulaire destiné à l'administration fiscale des États-Unis.

Article de Robert Scheier / CIO États-Unis (Adaptation et traduction par Aurélie Chandèze)