Catalogue ServiceNow : transformer les demandes en workflows clairs

Construire une offre de service compréhensible

Un catalogue décrit ce qu’un utilisateur peut demander et ce qui se passe ensuite. Les intitulés doivent employer son vocabulaire, pas uniquement celui des équipes techniques. Demander un accès à une application est plus clair que créer une tâche de provisionnement. Pour chaque service, indiquez les conditions, les informations nécessaires, les étapes et les délais convenus. Une présentation utile réduit les demandes envoyées au mauvais endroit. Le catalogue n’a pas besoin de reproduire toute l’organisation interne : sa structure doit aider une personne à reconnaître le service correspondant à son besoin.

Distinguer demande, article et tâches de réalisation

L’article de catalogue représente une offre ou un formulaire. Une demande créée à partir de cet article contient les informations d’un cas particulier. Les tâches de réalisation répartissent ensuite le travail entre les équipes concernées. Ces niveaux évitent de mélanger l’expérience du demandeur avec l’organisation technique du traitement. Par exemple, obtenir un ordinateur peut nécessiter une préparation matérielle, une configuration et une livraison. Le demandeur suit un résultat global, tandis que les équipes disposent de tâches distinctes dont les statuts et les dépendances restent visibles.

Concevoir un formulaire qui pose les bonnes questions

Chaque champ doit servir une décision, une validation ou une réalisation. Demander des informations déjà connues fatigue l’utilisateur et augmente les erreurs de saisie. Utilisez les données de son profil lorsque c’est approprié et affichez seulement les questions utiles au choix effectué. Expliquez le format attendu et contrôlez les valeurs côté plateforme. Une condition d’affichage ne constitue pas une autorisation : les accès et les règles doivent être vérifiés à l’enregistrement et à l’exécution. Testez aussi le formulaire au clavier et sur mobile, car un parcours interne reste une expérience utilisateur.

Définir les validations sans créer des files inutiles

Une validation doit répondre à une question précise : budget autorisé, éligibilité du demandeur ou droit d’accès sensible. Faire approuver chaque étape par plusieurs personnes peut allonger les délais sans réduire le risque. Identifiez le bon approbateur, le délai de réponse, la délégation et le traitement des refus. Présentez les informations nécessaires à la décision. Si une demande est modifiée après validation, vérifiez si cette modification remet l’accord en cause. La traçabilité doit distinguer une approbation réelle, une préautorisation et une décision prise automatiquement par une règle définie.

Exemple complet : préparer l’arrivée d’un salarié

Un manager renseigne la date d’arrivée, l’équipe, le lieu et les services nécessaires. Le workflow contrôle les informations et déclenche les validations requises pour les accès. Il crée ensuite des tâches pour préparer le poste, attribuer les comptes et organiser la remise du matériel. Certaines tâches peuvent être parallèles, d’autres dépendent d’une validation précédente. Le suivi global indique ce qui bloque l’arrivée. Si la date change ou si le recrutement est annulé, le processus doit mettre à jour ou arrêter les tâches restantes, plutôt que laisser les équipes travailler sur une demande devenue inutile.

Relier les systèmes externes avec des contrats fiables

L’automatisation peut appeler un annuaire, un outil de messagerie ou un service de gestion du matériel. Définissez les paramètres, les identifiants de corrélation et les résultats attendus. Une réponse réseau réussie ne prouve pas toujours que l’opération métier est terminée. Prévoyez une confirmation ou une vérification de statut lorsque le système distant fonctionne de manière asynchrone. Les comptes techniques doivent avoir des droits limités et les secrets ne doivent pas apparaître dans les journaux. Vérifiez aussi les capacités et abonnements nécessaires aux intégrations de votre instance ServiceNow.

Gérer l’échec partiel et les nouvelles tentatives

Une demande peut avoir obtenu un ordinateur mais pas encore un compte. Il faut afficher cet état partiel sans prétendre que tout est terminé. Définissez quelles opérations peuvent être répétées sans doublon et lesquelles nécessitent une vérification préalable. Si un appel expire après avoir créé un compte, relancer aveuglément peut produire une seconde ressource. Utilisez des identifiants d’opération et des recherches de contrôle. Prévoyez une reprise manuelle et indiquez à l’équipe ce qui a déjà été exécuté. Le traitement des exceptions fait partie du produit, pas seulement de la maintenance future.

Donner une visibilité utile au demandeur

Le suivi doit expliquer les étapes dans un langage compréhensible. En attente de validation du manager est plus informatif qu’un code de statut interne. Indiquez les informations manquantes et la prochaine action attendue. Les notifications doivent être pertinentes et éviter de répéter chaque changement technique. Permettez aux utilisateurs de retrouver l’historique et de compléter une demande sans en créer une nouvelle. Une bonne visibilité réduit les relances et améliore la confiance, même quand une opération prend du temps. Elle suppose que les tâches et leurs statuts reflètent réellement le travail effectué.

Tester le parcours complet avant sa publication

Ne testez pas seulement la soumission du formulaire. Vérifiez approbation, refus, délégation, annulation, changement de date et panne d’un système externe. Utilisez différents profils pour contrôler la visibilité des articles et des données. Vérifiez que les tâches sont attribuées au bon groupe et que les doublons sont évités lors des reprises. Faites participer les équipes qui réalisent le service et les personnes qui le demandent. Un workflow peut être techniquement exécutable tout en collectant des informations inutiles ou en créant des tâches qu’aucune équipe ne reconnaît comme sa responsabilité.

Améliorer le catalogue à partir des usages

Suivez le temps de réalisation, le taux d’abandon, les demandes retournées pour information et les relances. Analysez les articles peu utilisés et les demandes qui continuent d’arriver par e-mail : elles peuvent révéler une offre difficile à trouver ou un formulaire mal adapté. Tuplify Studio peut développer les articles, applications et intégrations nécessaires à vos processus internes. Commencez avec quelques parcours à forte valeur et améliorez-les avant d’étendre le catalogue. La réussite se mesure à un service plus simple à demander et plus fiable à réaliser, pas au nombre de formulaires publiés.

Atelier : transformer une demande par e-mail en parcours de catalogue

Choisissez un e-mail de demande récurrente et identifiez les informations réellement nécessaires à sa réalisation. Séparez ce que l’utilisateur connaît de ce que le système peut retrouver. Décrivez les approbations, les tâches et leurs dépendances. Écrivez ensuite les cas de refus, annulation et information manquante avant de configurer le formulaire. Faites le tester par une personne qui ne connaît pas l’organisation interne. Si elle doit demander à un technicien quelle catégorie choisir, le vocabulaire mérite probablement d’être amélioré. Comparez enfin le parcours automatisé à l’ancien processus : temps de saisie, relances et clarté du suivi sont des critères plus utiles qu’un simple nombre de clics supprimés.

Questions fréquentes : formulaires et workflows

Un formulaire long est-il plus complet ? Il peut surtout produire davantage de données inutiles ou incorrectes. La complétude doit être liée à la réalisation et aux décisions nécessaires.

Toutes les demandes exigent-elles une approbation ? Non : le niveau de contrôle dépend du risque, du coût et des règles de l’organisation. Une préautorisation peut être adaptée à une offre standard bien bornée.

Peut-on considérer la demande terminée dès la création des tâches ? La création du travail ne signifie pas sa réalisation. Définissez le résultat attendu et les conditions de clôture, avec un traitement explicite des tâches échouées, annulées ou devenues inutiles après un changement de besoin.