Votre Template de Données de Gestion des Demandes de Service

Cet attribut décrit l'action spécifique ou la transition de statut qui a eu lieu à un moment donné pour une demande de service. Les exemples incluent 'Demande Créée', 'Demande Assignée', 'Solution Implémentée' et 'Demande Clôturée'.

L'analyse de la séquence et de la fréquence de ces activités est le cœur du Process Mining. Elle permet la visualisation de cartes de processus, l'identification des goulots d'étranglement et la détection des déviations par rapport au workflow standard, ce qui est essentiel pour comprendre l'efficacité et la conformité du processus.

Il définit les étapes du processus, permettant la visualisation de la carte de processus et l'analyse des modèles de workflow et des écarts.

Généralement dérivé de l'historique des transitions de statut d'un ticket Jira. Chaque entrée dans le changelog du ticket pour le champ statut représente une activité.

L'heure de début, ou timestamp d'événement, enregistre le moment exact où une activité s'est produite. C'est un composant essentiel pour toute analyse de Process Mining, car il fournit le contexte temporel de l'ensemble du processus.

Ce timestamp est utilisé pour ordonner les événements séquentiellement, calculer la durée entre les activités, mesurer les temps de cycle totaux des cas et analyser la performance du processus par rapport à des objectifs basés sur le temps comme les SLA. Sans des timestamps précis, il est impossible de comprendre le flux de processus, d'identifier les retards ou de mesurer l'efficacité.

Ce timestamp est essentiel pour ordonner les événements, calculer les durées et les temps de cycle, et identifier les goulots d'étranglement des processus.

C'est le timestamp associé à chaque transition de statut dans le changelog du ticket Jira. L'heure de création du ticket est le champ 'created'.

L'ID de demande de service, souvent appelé Clé de ticket dans Jira, identifie de manière unique chaque demande de service individuelle soumise par un utilisateur ou un système. Il sert de fil conducteur central reliant tous les événements ultérieurs, de la journalisation initiale à la clôture finale, permettant une analyse complète et de bout en bout du parcours de chaque demande de service.

Dans le Process Mining, cet ID est essentiel pour la corrélation des cas. Il garantit que chaque activité, changement de statut et timestamp est correctement associé à la demande spécifique à laquelle il appartient, formant une instance de processus cohérente pour l'analyse.

Cet ID est l'identifiant de cas fondamental qui connecte toutes les activités connexes en un seul flux de processus de bout en bout, rendant l'analyse des processus possible.

Ceci est le champ 'key' pour un ticket dans Jira Service Management.

Cet attribut enregistre la date et l'heure de la dernière extraction de données de Jira Service Management. Il fournit un contexte crucial pour la fraîcheur de l'analyse et les données contenues dans les dashboards et les KPI.

Dans toute analyse, connaître la pertinence des données est essentiel pour prendre des décisions éclairées. Ce timestamp aide les utilisateurs à comprendre s'ils consultent des informations en temps réel ou un instantané d'un point dans le temps précédent, ce qui affecte la pertinence des résultats.

Indique la fraîcheur des données, garantissant que les analyses sont basées sur des informations à jour.

C'est un champ de métadonnées généré et stocké par l'outil ou le script d'extraction de données à la fin de son exécution.

Cet attribut identifie l'origine des données, qui dans ce cas est Jira Service Management. Bien que cela puisse sembler trivial lors de l'analyse des données provenant d'une source unique, cela devient crucial lors de la fusion de données de processus provenant de plusieurs systèmes.

Pour l'analyse, il aide à retracer la lignée des données et à garantir la qualité des données. Il permet également de filtrer et de comparer des processus qui pourraient s'étendre sur ou interagir avec différentes plateformes logicielles.

Identifie l'origine des données, ce qui est crucial pour la gouvernance des données et lors de la combinaison de données de processus provenant de plusieurs systèmes d'entreprise.

Il s'agit généralement d'une valeur statique ajoutée pendant le processus d'extraction et de transformation des données pour étiqueter l'origine du jeu de données.

La date d'échéance SLA est un timestamp calculé qui représente la date limite de résolution d'une demande. Elle est déterminée par la priorité de la demande, son type et les politiques spécifiques d'Accord de Niveau de Service (SLA) configurées dans Jira Service Management.

Cet attribut est fondamental pour le dashboard 'Service Request SLA Performance' et le KPI 'Taux de respect des SLA'. En comparant le temps de résolution réel à cette date d'échéance, le système peut déterminer si chaque demande a été complétée à temps, en retard ou si elle risque de violer son SLA.

Ceci est le référentiel pour mesurer la performance. Il soutient directement le calcul de la conformité SLA et aide à prioriser le travail.

Les informations SLA sont gérées par Jira Service Management et sont accessibles via l'API, souvent stockées dans des champs personnalisés qui se mettent à jour dynamiquement.

La priorité de la demande indique l'urgence et l'impact commercial d'une demande de service. Cette classification détermine l'ordre de traitement des demandes et dicte souvent les délais de résolution cibles et les SLA.

Dans l'analyse des processus, la priorité est une dimension clé pour la segmentation. Elle permet de comparer les temps de cycle et le respect des SLA entre différents niveaux de priorité, garantissant ainsi que les demandes à haute priorité sont effectivement traitées plus rapidement et atteignent leurs objectifs. Cela aide à valider l'efficacité du système de priorisation.

Permet de segmenter l'analyse pour s'assurer que les requêtes de haute priorité sont traitées plus rapidement et respectent des niveaux de service plus stricts.

Cela correspond au champ 'priority' sur un ticket Jira.

L'Assigné est la personne responsable de la prochaine action ou de la résolution de la demande de service. La valeur de cet attribut peut changer plusieurs fois au cours du cycle de vie de la demande, car elle est transmise entre différents agents ou équipes.

Cet attribut est essentiel pour l'analyse de la charge de travail, la mesure des performances et la gestion des ressources. Il permet de filtrer le processus par agent, de comparer les temps de résolution entre individus et d'identifier les besoins potentiels en formation ou les déséquilibres de charge de travail qui provoquent des goulots d'étranglement.

Cet attribut est vital pour analyser la charge de travail des agents, mesurer les performances individuelles et comprendre l'allocation des ressources.

Cela correspond au champ 'assignee' sur un ticket Jira.

Cet attribut représente l'état actuel d'une demande de service, tel que 'Ouvert', 'En cours', 'En attente du client' ou 'Résolu'. Il fournit un aperçu de l'endroit où se trouve la demande à un moment donné.

Bien que le journal d'activités fournisse le flux historique, le statut actuel est utile pour analyser les charges de travail ouvertes et identifier les éléments bloqués. Par exemple, l'analyse peut se concentrer sur les demandes qui sont restées au statut 'En attente du fournisseur' pendant une période exceptionnellement longue, mettant en évidence les dépendances externes et les retards.

Fournit un instantané actuel de chaque cas, permettant l'analyse du travail en cours et l'identification des requêtes bloquées ou vieillissantes.

Ceci est le champ 'status' sur un ticket Jira.

Le type de demande classe la demande de service selon sa nature. Il s'agit d'une dimension fondamentale pour l'analyse, car différents types de demandes ont souvent des processus de résolution, des SLA et des exigences en ressources distincts.

En segmentant l'analyse des processus par type de demande, les organisations peuvent adapter les améliorations à des workflows spécifiques. Par exemple, le goulot d'étranglement pour une demande de 'Réinitialisation de mot de passe' sera très différent de celui d'une demande de 'Provisionnement de nouveau serveur'. Cet attribut est essentiel pour construire des dashboards pertinents comme 'Qualité de résolution par catégorie'.

Cet attribut est essentiel pour comparer les processus, les charges de travail et les performances entre différentes catégories de demandes de service.

Ceci correspond souvent au champ 'issuetype' dans Jira ou à un champ personnalisé 'Type de demande' dans Jira Service Management.

L'attribut Canal identifie la manière dont une demande de service est entrée dans le système. Les canaux courants dans Jira Service Management incluent le portail client, l'e-mail ou la création directe par un agent.

L'analyse du processus par canal est importante pour comprendre le comportement des utilisateurs et optimiser la prestation de services. Elle peut révéler si les demandes provenant de certains canaux prennent plus de temps à être résolues ou nécessitent plus de clarifications, indiquant potentiellement un besoin d'améliorer les formulaires sur le portail ou les règles d'analyse des e-mails. Cela soutient le dashboard 'Service Request Throughput Trends'.

Aide à analyser si le canal de soumission impacte les temps de résolution, la clarté des requêtes ou l'efficacité globale du processus.

Ces informations sont disponibles dans Jira Service Management via le champ 'Request channel type'. Elles peuvent nécessiter un accès API spécifique ou être stockées dans un champ personnalisé.

Le Rapporteur est la personne, souvent un utilisateur final ou un client, qui a soumis la demande de service. Cet attribut identifie la partie prenante qui a initié le processus.

En analyse, le Rapporteur peut être utilisé pour comprendre les modèles de demandes provenant de différents utilisateurs, départements ou segments de clientèle. Il aide à répondre à des questions telles que 'Quels départements soumettent le plus de demandes ?' ou 'Certains utilisateurs rencontrent-ils les mêmes problèmes à plusieurs reprises ?'. Cette information est précieuse pour la gestion proactive des problèmes et l'amélioration de la formation des utilisateurs.

Identifie l'initiateur de la requête, permettant l'analyse des volumes et types de requêtes par utilisateur, département ou client.

Cela correspond au champ 'reporter' sur un ticket Jira.

Le temps de cycle d'un cas (Case Cycle Time) est une métrique calculée qui mesure la durée totale du cycle de vie d'une requête de service. Il est généralement calculé comme la différence entre l'horodatage de 'Requête de service fermée' et l'horodatage de 'Requête de service créée'.

C'est l'un des KPI les plus importants en Process Mining, soutenant directement le KPI 'Temps de cycle moyen des requêtes de service' et le tableau de bord 'Temps de cycle de bout en bout des requêtes de service'. Il fournit une mesure de haut niveau de l'efficacité globale du processus et du temps d'attente du client.

C'est un KPI principal pour mesurer l'efficacité globale du processus et l'expérience client de bout en bout.

Calculé lors de la transformation des données en soustrayant l'horodatage de création de l'horodatage de fermeture finale pour chaque cas.

Ceci est une métrique calculée qui totalise le temps qu'une demande de service a passé dans un état indiquant qu'elle était chez un fournisseur externe. Elle est calculée en trouvant la durée entre les activités 'Engagement Fournisseur Commencé' et 'Engagement Fournisseur Terminé', et en additionnant ces durées si elles se produisent plusieurs fois dans un même cas.

Cet attribut est essentiel pour le dashboard 'Retards d'engagement fournisseur externe' et le KPI 'Temps moyen fournisseur externe'. Il aide à quantifier les retards causés par des dépendances tierces, ce qui est crucial pour gérer les relations avec les fournisseurs et définir des attentes client réalistes.

Isole et quantifie les retards causés par les dépendances externes, fournissant des données pour gérer la performance des fournisseurs et améliorer les prévisions.

Calculé lors de la transformation des données en mesurant le temps entre les événements 'Engagement fournisseur commencé' et 'Engagement fournisseur terminé'.

Cet attribut spécifie l'équipe assignée à une demande, qui est souvent un regroupement de niveau supérieur à l'assigné individuel. C'est utile pour analyser les performances au niveau de l'équipe, comme la comparaison de l'équipe de Support de premier niveau avec l'équipe des Opérations Réseau.

Cette dimension est cruciale pour des dashboards comme 'Agent Workload and Resolution Metrics'. Elle permet d'agréger les métriques de performance au niveau de l'équipe, facilitant des comparaisons équitables et la compréhension de la manière dont les différentes équipes contribuent au processus global de prestation de services.

Permet l'analyse des performances et l'équilibrage de la charge de travail au niveau de l'équipe ou du département, plutôt que par un seul agent.

Il peut s'agir d'un champ personnalisé dans Jira (par exemple, 'Équipe') ou être dérivé des attributs du profil utilisateur de l'assigné.

Cet attribut calculé est un indicateur booléen (vrai/faux) qui est défini sur vrai si le workflow d'une demande inclut une activité 'Demande Rouverte'. Il est dérivé en analysant la séquence des activités pour chaque cas.

Cet indicateur est essentiel pour calculer le KPI 'Taux de réouverture des demandes de service' et pour alimenter le dashboard 'Volume de demandes de service rouvertes'. Un taux de réouverture élevé est un indicateur fort d'une mauvaise qualité de résolution au premier contact, entraînant des retouches et une diminution de la satisfaction client. L'analyse des types de demandes ou de résolutions associés à cet indicateur peut identifier les domaines à améliorer.

Mesure directement les reprises et la qualité de la résolution au premier contact, qui sont des indicateurs clés de l'efficacité du processus et de la satisfaction client.

Calculé lors de la transformation des données en vérifiant si la séquence d'activités pour un cas contient une transition 'Rouvert' après une transition 'Résolu'.

L'état du SLA est un attribut calculé qui catégorise chaque demande de service en fonction de sa performance par rapport à son délai SLA. Les valeurs possibles incluent 'Atteint', 'Violé' ou 'En cours'. Il est déterminé en comparant le timestamp de résolution à la 'SlaDueDate'.

Il s'agit de l'attribut principal pour le dashboard 'Service Request SLA Performance' et est utilisé pour calculer le KPI 'Taux de respect des SLA'. Il offre une vue claire et rapide de la conformité au niveau de service, ce qui est essentiel pour le reporting, la gestion des contrats et le maintien de la qualité de service.

Fournit un indicateur clair et immédiat de la performance SLA, qui est une mesure critique de la qualité de service et de la conformité contractuelle.

Calculé lors de la transformation des données. Si le temps de résolution est antérieur à la 'Date d'échéance SLA', l'état est 'Respecté' ; sinon, il est 'Violé'.

Cet attribut regroupe les rapporteurs par organisations ou départements. Jira Service Management dispose d'une fonctionnalité intégrée 'Organisations' qui permet aux agents de gérer les demandes provenant de plusieurs clients ou équipes internes.

L'analyse par organisation fournit un contexte commercial précieux. Elle peut aider à identifier quels clients ou départements consomment le plus de ressources de support, si des groupes spécifiques rencontrent des problèmes récurrents, et si les SLA sont respectés de manière constante au sein des différentes unités commerciales.

Facilite l'analyse de la demande de service et des performances par client ou département interne, fournissant des insights commerciaux clés.

Ces données proviennent du champ 'Organizations' associé à la demande de service dans Jira Service Management.

Le champ Résolution indique pourquoi une demande de service a été clôturée. Les valeurs courantes incluent 'Terminé', 'Ne sera pas fait', 'Duplicata' ou 'Impossible à reproduire'. Il fournit des détails de clôture au-delà d'un simple statut 'Résolu' ou 'Clôturé'.

L'analyse des résolutions aide à comprendre la qualité et la nature des résultats. Par exemple, un nombre élevé de résolutions 'Duplicata' pourrait signaler un problème avec le processus de soumission des demandes, tandis que le suivi des résolutions qui mènent à des demandes rouvertes peut mettre en évidence des solutions inefficaces.

Fournit un contexte sur le résultat d'une requête, aidant à analyser la qualité de la résolution et à identifier les tendances expliquant pourquoi les requêtes sont clôturées.

Cela correspond au champ 'resolution' sur un ticket Jira, qui est généralement défini lorsque le ticket passe à une catégorie de statut 'terminé'.

Ceci est une métrique de durée calculée qui mesure l'efficacité de la phase initiale de traitement et de routage d'une demande de service. Elle est calculée comme la différence de temps entre l'activité 'Demande Assignée' et l'activité 'Demande Triée'.

Cette métrique est la base du KPI 'Temps moyen de triage à l'assignation' et du dashboard 'Efficacité du triage et de l'assignation'. Une longue durée ici peut indiquer un goulot d'étranglement dans le processus d'admission du service desk, tel qu'un personnel insuffisant pour le triage ou des retards dans la détermination de la bonne équipe d'assignation.

Mesure l'efficacité des premières étapes cruciales du traitement des requêtes, mettant en évidence les retards avant même que le travail ne puisse commencer.

Calculé lors de la transformation des données en soustrayant l'horodatage de l'événement 'Requête triée' de l'événement 'Requête assignée'.