Votre template de données pour la gestion des demandes de service

L’attribut Activité décrit une étape ou une action précise effectuée sur une demande de service. Ces activités constituent les éléments successifs du processus, par exemple « Demande créée », « Demande affectée », « Travail en cours » et « Demande clôturée ». Chaque activité représente un moment distinct dans le parcours d’une demande de service.

L’analyse des activités est au cœur du Process Mining. Elle permet de découvrir et de visualiser le flux réel du processus. En examinant leur séquence et leur fréquence, les analystes peuvent repérer les parcours courants, les écarts par rapport au processus standard, les goulots d’étranglement où les demandes restent bloquées et les boucles de reprise où certaines étapes sont répétées inutilement.

Cet attribut définit les étapes du processus et permet de découvrir le flux réel, les goulots d’étranglement et les écarts.

Il est souvent dérivé des journaux de changements de statut, des tables d’événements ou des pistes d’audit associées à l’objet de demande de service.

L’heure de début enregistre la date et l’heure précises auxquelles une activité donnée a commencé. Cet horodatage est essentiel pour classer les événements dans l’ordre chronologique et calculer la durée des activités ainsi que celle du cycle de vie global du dossier. Chaque activité du processus doit disposer d’une heure de début correspondante afin de constituer un Event Log fiable.

Dans l’analyse des processus, l’heure de début sert à calculer des indicateurs de performance tels que le délai de traitement, le temps d’attente entre les activités et le temps consacré à chaque activité. Elle permet de créer une vue temporelle du processus, de mettre en évidence les retards et d’identifier les étapes qui consomment le plus de temps. Des horodatages précis sont indispensables à toute analyse des performances.

Cet horodatage est essentiel pour classer correctement les événements et calculer les indicateurs liés au temps, notamment les délais de traitement et les goulots d’étranglement.

Il se trouve dans les tables de l’Event Log ou de la piste d’audit, souvent sous la forme d’une « date de création » ou d’un « horodatage d’événement » pour chaque activité.

L’identifiant de la demande de service est la clé primaire qui identifie de manière unique chaque demande pendant tout son cycle de vie. Il sert d’identifiant de dossier et relie les activités, les changements de statut et les attributs associés pour former une instance de processus cohérente.

Dans une analyse de Process Mining, cet identifiant est indispensable pour reconstituer le parcours complet de chaque demande. En regroupant tous les événements sous un même CaseId, les analystes peuvent visualiser les flux de processus, calculer la durée des dossiers et repérer les différences dans le traitement des demandes. Il constitue le fondement de toute analyse du processus de gestion des demandes de service.

Cet identifiant est indispensable pour relier tous les événements d’une demande de service et obtenir une vue complète du processus de bout en bout.

Il se trouve généralement dans l’en-tête ou la table principale des transactions relatives aux demandes de service.

La dernière mise à jour des données fournit l’horodatage de l’extraction ou de l’actualisation la plus récente. Elle informe les utilisateurs sur l’actualité des données analysées et leur permet de déterminer si l’analyse reflète l’état actuel ou une situation antérieure.

Cet attribut est essentiel au suivi opérationnel et au reporting, car il précise l’actualité des analyses produites. Il aide les utilisateurs à faire confiance aux données et à prendre des décisions éclairées en fonction de leur date de mise à jour. Par exemple, un Dashboard dont les données ont été actualisées il y a une semaine ne s’interprète pas de la même manière qu’un Dashboard mis à jour il y a une heure.

Cet attribut indique l’actualité des données, un élément essentiel pour garantir que les analyses restent pertinentes et reposent sur des informations à jour.

Il s’agit d’un champ de métadonnées généralement généré et stocké lors du processus d’extraction des données (ETL).

L’attribut Système source indique le nom de la plateforme de gestion des services informatiques (ITSM) ou de l’application depuis laquelle les données ont été extraites. Dans les environnements qui regroupent plusieurs systèmes, ce champ permet de distinguer les sources et d’assurer la traçabilité des données.

Bien qu’il ne soit pas directement utilisé dans la plupart des analyses de flux de processus, il est essentiel à la gouvernance des données, à la validation et au dépannage. Lors de la combinaison de données provenant de plusieurs sources, cet attribut permet aux analystes de segmenter la vue du processus par système et de repérer d’éventuelles différences d’exécution ou de qualité des données entre les plateformes.

Essentiel à la gouvernance des données et au dépannage, cet attribut précise l’origine des données, notamment dans les environnements intégrant plusieurs systèmes.

Cette valeur est généralement ajoutée lors du processus d’extraction des données (ETL) et ne constitue pas un champ natif du système source.

L’agent désigné est la personne responsable du traitement de la demande de service à un moment donné. Une demande peut être affectée à plusieurs agents au cours de son cycle de vie.

Cet attribut est essentiel à l’analyse des performances et de la charge de travail. Il permet aux organisations de mesurer et de comparer les performances individuelles, notamment les délais moyens de résolution et le volume de demandes traitées. Il sert également à analyser les réaffectations entre agents, qui peuvent révéler des problèmes de tri initial, de spécialisation ou de répartition de la charge.

Cet attribut permet d’analyser les performances individuelles, la répartition de la charge de travail et la fréquence des réaffectations entre agents.

Disponible dans l’enregistrement de la demande de service. Les modifications de ce champ sont souvent suivies dans une piste d’audit ou une table historique.

La date d’échéance du SLA est un horodatage cible calculé à partir de l’accord de niveau de service associé à la demande. Elle dépend notamment de la priorité, du type et de la date de création de la demande, et définit le délai de résolution attendu.

Cet attribut constitue la base de toute analyse du respect des SLA. En comparant le délai réel de résolution à la date d’échéance du SLA, les organisations peuvent déterminer si la demande a été résolue dans les délais ou si le SLA n’a pas été respecté. Il s’agit d’un KPI important pour mesurer la qualité du service et repérer les problèmes systémiques à l’origine des retards et des dépassements.

Cette date sert de référence pour mesurer les performances. Elle permet de calculer les taux de respect des SLA et d’identifier les demandes pour lesquelles le délai a été dépassé.

Il s’agit souvent d’un champ calculé de l’enregistrement de la demande de service, déterminé par la politique de SLA appliquée.

L’équipe désignée correspond au groupe de support responsable de la demande de service. Les demandes sont souvent orientées entre différentes équipes, par exemple un centre de support de niveau 1, une équipe réseau ou une équipe de développement logiciel, selon l’expertise requise.

L’analyse des transferts entre équipes constitue un volet essentiel du Process Mining appliqué à la gestion des services. Cet attribut permet de visualiser les transferts d’une équipe à l’autre et de repérer les lacunes dans les échanges ou les retards. Il permet également de comparer les performances des équipes, notamment leur efficacité, le volume de demandes traité et leur capacité à résoudre les demandes sans nouvelle escalade.

Essentiel pour analyser les transferts entre équipes, repérer les retards d’orientation et comparer les performances des équipes.

Champ standard de l’enregistrement de la demande de service. Les modifications de ce champ sont suivies dans une piste d’audit.

La priorité de la demande est une classification qui aide les équipes de support à déterminer l’ordre de traitement des demandes. Elle repose généralement sur une combinaison de l’impact de la demande sur l’activité et de son urgence. Les niveaux courants sont « Faible », « Moyenne », « Élevée » et « Critique ».

Cet attribut est essentiel à l’analyse des performances et à l’allocation des ressources. Les analystes peuvent comparer les délais de traitement et le respect des SLA selon les niveaux de priorité afin de vérifier que les demandes prioritaires sont traitées comme prévu. Ils peuvent également repérer les demandes de faible priorité négligées ou les écarts dans l’application des règles de priorisation par les équipes de support.

Essentiel pour vérifier que les demandes sont traitées selon leur importance pour l’activité et comprendre l’incidence de la priorité sur le délai de résolution.

Il s’agit généralement d’un champ standard de l’enregistrement principal de la demande de service.

Le statut de la demande indique l’état de la demande de service à un moment donné de son cycle de vie. Les statuts courants sont notamment « Nouvelle », « En cours », « En attente », « Résolue » et « Fermée ». Cet attribut fournit une vue instantanée de la position de la demande dans le processus global.

L’analyse du statut de la demande est essentielle pour comprendre le flux du processus et les transitions entre les états. Elle permet de filtrer les dossiers, d’identifier les demandes bloquées dans un état donné et de mesurer le temps passé dans chaque statut. Par exemple, l’analyse de la durée passée dans l’état « En attente » peut révéler des retards liés à l’attente d’informations de la part des utilisateurs ou d’équipes externes.

Cet attribut permet d’analyser le temps passé par les demandes dans chaque état et de mettre en évidence les goulots d’étranglement ou les retards du processus.

Disponible dans la table principale des demandes de service ou dans les journaux historiques des statuts.

Le type de service caractérise la nature de la demande de service. Il peut s’agir d’une demande de nouveau matériel, d’un accès logiciel, d’une question générale ou d’un support technique. Cette catégorisation facilite l’orientation de la demande vers l’équipe compétente et permet de comprendre la demande pour chaque service.

Dans l’analyse des processus, le type de service constitue une dimension utile pour segmenter les données. En filtrant la carte du processus selon les différents types de service, les organisations peuvent constater que certaines demandes suivent des processus très différents, présentent des délais plus longs ou nécessitent davantage de reprises. Ces résultats permettent de cibler les actions d’amélioration sur des catégories de services précises.

Cet attribut permet de filtrer et de comparer les processus selon les catégories de demandes, afin de révéler les goulots d’étranglement ou les inefficacités propres à chaque type.

Champ standard de l’enregistrement de la demande de service, souvent associé à un catalogue de services.

Le canal de soumission indique comment la demande de service a été créée, par exemple via un portail en libre-service, un e-mail, un appel téléphonique ou une API. Chaque canal peut être associé à des processus ou à des attentes différentes de la part des utilisateurs.

L’analyse du processus par canal de soumission peut révéler des éléments importants. Par exemple, les demandes envoyées via un portail en libre-service peuvent être mieux structurées et résolues plus rapidement que celles reçues par e-mail, qui nécessitent parfois une saisie manuelle. Cette analyse peut aider les organisations à promouvoir les canaux les plus efficaces ou à améliorer les processus associés aux canaux moins performants.

Cet attribut permet de déterminer si le mode de soumission influe sur l’efficacité du processus, le délai de résolution ou le taux de résolution au premier contact.

Il s’agit généralement d’un champ standard de l’enregistrement de la demande de service.

Le code de résolution fournit une méthode structurée pour classer le résultat d’une demande de service. Il peut notamment prendre les valeurs « Résolue par l’utilisateur », « Matériel remplacé », « Logiciel déployé » ou « Demande en double ». Ces informations sont généralement saisies par l’agent lors de la clôture de la demande.

Ces codes sont utiles pour l’analyse des causes racines. En étudiant la fréquence des différents codes de résolution, les organisations peuvent repérer les problèmes récurrents, les solutions courantes et les possibilités de créer des articles dans la base de connaissances ou des résolutions automatisées. Par exemple, un nombre élevé de résolutions « Réinitialisation du mot de passe » peut justifier la mise en place d’un outil libre-service de réinitialisation des mots de passe.

Cet attribut permet d’analyser les causes racines en classant les modes de résolution des demandes, afin de repérer les tendances et les possibilités d’une Gestion des problèmes proactive.

Champ généralement renseigné manuellement par l’agent lors de la résolution ou de la clôture de la demande de service.

L’heure de fin enregistre la date et l’heure précises auxquelles une activité donnée s’est terminée. Alors que l’heure de début marque le commencement, l’heure de fin marque l’achèvement et définit la durée d’une étape du processus. Tous les événements ne disposent pas d’une heure de fin distincte, certains étant instantanés.

Cet attribut est essentiel pour calculer le temps de traitement de chaque activité. En soustrayant l’heure de début de l’heure de fin, les analystes peuvent mesurer le temps pendant lequel les agents ou les systèmes travaillent effectivement sur une tâche. Cela permet de repérer les activités les plus longues, qui sont souvent prioritaires pour l’optimisation ou l’automatisation.

Cet attribut permet de calculer le temps de traitement des activités et d’identifier les étapes du processus qui consomment le plus de temps.

Il se trouve dans les tables de l’Event Log ou de la piste d’audit. S’il n’est pas disponible explicitement, il peut être déduit de l’heure de début de l’activité suivante.

Le nombre de réaffectations est une métrique qui totalise le nombre de fois où une demande de service a été transférée d’un agent ou d’une équipe à un autre. Un nombre élevé peut révéler des problèmes tels qu’un routage initial incorrect, un manque de connaissances des agents ou une répartition peu claire des responsabilités du processus.

Il s’agit d’un indicateur essentiel de l’inefficacité d’un processus. Dans le cadre du Process Mining, cette métrique permet de quantifier les allers-retours auxquels une demande est soumise. L’analyse des cas présentant un nombre élevé de réaffectations peut révéler des possibilités d’amélioration du processus de triage, de renforcement de la formation des agents ou de clarification des responsabilités des équipes, afin que les demandes soient correctement orientées dès le premier traitement.

Une métrique essentielle pour identifier les inefficacités des processus. Un nombre élevé de réaffectations est souvent associé à des délais de résolution plus longs et à une insatisfaction des utilisateurs.

Il s’agit d’une métrique calculée, obtenue en comptant le nombre de changements des champs « AssignedAgent » ou « AssignedTeam » pour un « CaseId » donné.

Cet attribut identifie le service ou l’unité opérationnelle de la personne à l’origine de la demande de service. Il fournit un contexte organisationnel à la demande.

L’analyse des demandes par service peut aider à repérer les besoins, les tendances ou les problèmes propres à chaque entité. Par exemple, un volume élevé de demandes d’un certain type provenant du service financier peut révéler un besoin de formation ciblée ou d’amélioration du système. Cet attribut permet également d’établir des rapports de refacturation et de comprendre la demande de services informatiques dans l’organisation.

Cet attribut fournit un contexte organisationnel et permet d’analyser les tendances des demandes ainsi que la demande de services par unité opérationnelle.

Ces informations sont généralement extraites du profil utilisateur du demandeur dans l’annuaire des employés ou le système ITSM.

Cet attribut booléen indique si la demande de service n’a pas respecté l’accord de niveau de service défini. Sa valeur est vraie si la demande a été résolue après « SlaDueDate », et fausse dans le cas contraire.

Cet attribut simplifie le reporting et l’analyse du respect des SLA. Au lieu d’effectuer une comparaison de dates dans chaque requête, cet indicateur permet de filtrer et d’agréger facilement les résultats. Il constitue une mesure essentielle pour les Dashboards consacrés aux performances des SLA et permet d’identifier rapidement le volume et le pourcentage de demandes qui ne respectent pas les objectifs de service.

Cet indicateur simple et explicite facilite l’analyse des performances des SLA, ainsi que le filtrage et le reporting des demandes dont le délai a été dépassé.

Il s’agit d’un attribut dérivé, calculé en comparant l’horodatage final de résolution au champ « SlaDueDate » lors de la transformation des données.