ServiceNow ITSM : incidents, problèmes et changements

Partir du service rendu, pas seulement du ticket

L’ITSM organise la manière dont une équipe fournit et améliore des services informatiques. Un ticket est une trace de travail, pas l’objectif final. Pour une messagerie indisponible, l’enjeu est de permettre aux collaborateurs de communiquer ; pour un portail de commande, il s’agit de préserver l’activité commerciale. Définissez donc les services, leurs utilisateurs et leurs responsables. Cette vision permet de hiérarchiser les incidents selon leur impact réel et d’éviter qu’un grand nombre de petites demandes masque une interruption critique pour l’entreprise.

Qualifier correctement un incident

À l’ouverture, recueillez un symptôme observable, le service concerné, le périmètre et l’heure de début. Une description comme tout est bloqué est moins exploitable que les utilisateurs de deux agences ne peuvent plus valider leur panier depuis neuf heures. L’impact représente l’étendue des conséquences ; l’urgence correspond à la vitesse à laquelle il faut agir. Votre matrice de priorité doit être comprise par les équipes et adaptée au métier. Ne laissez pas chaque demandeur choisir automatiquement la priorité maximale, car cela rend les files de traitement et les engagements de service inutilisables.

Affectation, escalade et communication

Un incident doit avoir un groupe responsable et un propriétaire du suivi. L’affectation peut dépendre du service, du composant, du lieu ou de la catégorie, mais des règles trop complexes deviennent difficiles à maintenir. Prévoyez une escalade quand la première équipe manque de compétences ou lorsque le risque de dépassement augmente. La communication doit indiquer ce qui est connu, les contournements disponibles et la prochaine mise à jour. Un incident techniquement traité mais mal communiqué peut continuer à générer des appels et des doublons, ce qui aggrave la charge du support.

Résoudre, vérifier puis fermer

Rétablir un service ne signifie pas toujours corriger définitivement la cause. Un redémarrage peut remettre une application en ligne sans expliquer sa panne. Documentez la résolution, les éléments vérifiés et les limites du contournement. Vérifiez avec les utilisateurs ou avec un contrôle fonctionnel que le service répond au besoin attendu. La fermeture suit les règles convenues avec l’organisation et ne doit pas servir à améliorer artificiellement les statistiques. Si les symptômes reviennent, les liens avec les incidents précédents deviennent essentiels pour détecter une tendance et décider d’une investigation de problème.

Ouvrir un problème pour comprendre la récurrence

Un problème rassemble l’investigation d’une cause réelle ou potentielle d’incidents. Il peut être créé après plusieurs pannes similaires ou de manière proactive lorsqu’un risque est découvert. Rassemblez chronologie, symptômes, changements récents et éléments techniques plutôt que de recopier simplement les descriptions des tickets. Une hypothèse doit être distinguée d’une cause démontrée. Si un contournement fiable existe, publiez-le dans une connaissance accessible au support. La valeur de cette démarche se mesure notamment à la réduction des récurrences et au temps gagné lors des incidents suivants, pas seulement au nombre de problèmes clôturés.

Faire le lien avec une demande de changement

Une correction durable peut nécessiter une modification de configuration, une mise à jour ou un ajout de capacité. La demande de changement décrit l’objectif, les ressources touchées, le risque, les étapes d’exécution, les contrôles et le retour arrière. Tous les changements n’exigent pas le même circuit : un changement standard préautorisé et répétitif diffère d’une évolution à haut risque. Le processus d’urgence doit accélérer une décision nécessaire sans supprimer la traçabilité. Une validation n’est utile que si la personne dispose des informations permettant d’évaluer les conséquences de l’intervention.

Scénario complet : des lenteurs récurrentes sur un portail

Le support constate que le portail devient inutilisable chaque lundi matin. Les incidents sont reliés au même service. Une augmentation temporaire des ressources restaure l’usage, puis un problème analyse les métriques et les traitements planifiés. L’équipe identifie un travail de synchronisation qui surcharge la base. Un changement déplace ce traitement et ajoute une protection contre la concurrence. Après déploiement, les équipes surveillent les lundis suivants avant de conclure à l’amélioration. Les trois processus se complètent, mais chaque fiche conserve son objectif : restaurer, comprendre puis modifier de manière contrôlée.

Configurer ServiceNow avec des données cohérentes

La configuration commence par les groupes, rôles, services, catégories et règles réellement nécessaires. Réutilisez autant que possible les capacités de la plateforme avant d’ajouter des développements spécifiques. Les champs obligatoires doivent être utiles à l’étape concernée : demander une cause racine dès l’ouverture d’un incident force souvent des valeurs inventées. Reliez les éléments de configuration pertinents sans transformer le formulaire en inventaire exhaustif. Les abonnements, plugins et interfaces disponibles doivent être vérifiés pendant le cadrage ; une démonstration d’une fonctionnalité ne signifie pas qu’elle est incluse dans toutes les instances.

Choisir des indicateurs qui n’encouragent pas les mauvais comportements

Suivez le délai de prise en charge, le temps de rétablissement, les réouvertures, le respect des engagements et la satisfaction des utilisateurs. Analysez les résultats par service et par priorité pour éviter les comparaisons trompeuses. Un temps moyen peut masquer quelques incidents très longs et très coûteux. Si l’objectif unique est de fermer vite, les équipes risquent de clôturer prématurément ou de multiplier les transferts. Associez les chiffres à des revues de cas. Pour la gestion des problèmes, recherchez surtout une baisse des incidents récurrents et une meilleure utilisation des connaissances.

Déployer progressivement et améliorer avec les équipes

Commencez par un service pilote, une matrice de priorité claire et un petit nombre de règles d’affectation. Testez création, changement de groupe, mise en attente, résolution, réouverture et droits de lecture. Formez le support aux différences entre incident, problème et changement avec des exemples internes. Tuplify Studio peut configurer ces parcours, intégrer vos outils et développer les compléments nécessaires dans ServiceNow. Après mise en production, organisez des revues régulières pour retirer les champs inutiles, corriger les règles et ajuster les indicateurs. Un processus compris et utilisé vaut mieux qu’un formulaire très complet que tout le monde contourne.

Atelier : tester vos règles avec un incident simulé

Décrivez une interruption d’un service important et faites parcourir le scénario à plusieurs profils. Le demandeur déclare les symptômes ; le support qualifie l’impact ; un groupe technique propose un contournement. Vérifiez que les transferts conservent un responsable et que les personnes concernées reçoivent des informations utiles. Simulez ensuite une récurrence pour décider si un problème doit être ouvert. Préparez un changement et vérifiez les données requises avant validation. Cet exercice révèle les champs inutiles, les affectations absentes et les étapes de communication oubliées. Il doit être effectué dans un environnement de test, avec des données adaptées, avant de conclure que le processus est prêt pour des incidents réels.

Questions fréquentes : priorité, SLA et changements urgents

Un incident prioritaire doit-il toujours être traité avant tout le reste ? La priorité organise la décision, mais dépend d’une qualification cohérente de l’impact et de l’urgence. Elle ne remplace pas le jugement en situation exceptionnelle.

Un SLA dépassé signifie-t-il que toute la prestation est mauvaise ? Il indique un engagement non respecté dans le périmètre défini. Examinez causes, pauses éventuelles, données et conséquences réelles plutôt que conclure sur un compteur isolé.

Un changement urgent contourne-t-il les règles ? Il suit un circuit adapté à l’urgence, avec une décision et une traçabilité. Il ne doit pas devenir une catégorie utilisée pour éviter systématiquement la préparation et l’évaluation des risques.