Votre modèle de données pour la gestion des demandes de service
Votre modèle de données pour la gestion des demandes de service
- Attributs recommandés pour une analyse détaillée
- Activités clés à suivre pour la découverte de processus
- Guide d'extraction pour Jira Service Management
Attributs de gestion des demandes de service
| Nom | Descriptionn | ||
|---|---|---|---|
|
Activité
ActivityName
|
Le nom de l'événement ou de la tâche spécifique survenue au cours du cycle de vie de la demande de service. | ||
|
Descriptionn
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 l'essence du Process Mining. Elle facilite la visualisation de cartes de processus, l'identification des points de blocage et la détection des écarts par rapport au workflow standard, ce qui est indispensable pour comprendre l'efficacité et la conformité du processus.
Pourquoi est-ce important ? :
Il définit les étapes du processus, pour visualiser de la carte de processus et l'analyse des modèles de workflow et des écarts.
Source des données :
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é.
Exemples
Demande triéeDemande d'informationsSolution implémentéeDemande de service fermée
|
|||
|
Heure de début
EventTime
|
La date et l'heure précises auxquelles une activité ou un événement spécifique s'est produit. | ||
|
Descriptionn
L'heure de début, ou horodatage de l'événement, enregistre le moment exact où une activité s'est produite. C'est un élément clé pour toute analyse de Process Mining, car il fournit le contexte temporel de l'ensemble du processus. Ce horodatage 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 horodatages précis, il est impossible de comprendre le flux de processus, d'identifier les retards ou de mesurer l'efficacité.
Pourquoi est-ce important ? :
Ce horodatage est indispensable pour ordonner les événements, calculer les durées et les temps de cycle, et identifier les points de blocage des processus.
Source des données :
C'est l'horodatage associé à chaque transition de statut dans le changelog du ticket Jira. L'heure de création du ticket est le champ 'created'.
Exemples
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
|
|||
|
ID de demande de service
ServiceRequestId
|
L'identifiant unique pour chaque demande de service, servant de clé primaire pour tous les événements associés. | ||
|
Descriptionn
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 élément central reliant tous les événements ultérieurs, de la journalisation initiale à la clôture finale, pour une analyse complète et complet du parcours de chaque demande de service. Dans le Process Mining, cet ID est indispensable pour la corrélation des cas. Il garantit que chaque activité, changement de statut et horodatage est correctement associé à la demande spécifique à laquelle il appartient, formant une instance de processus cohérente pour l'analyse.
Pourquoi est-ce important ? :
Cet ID est l'identifiant de cas clé qui connecte toutes les activités connexes en un seul flux de processus complet, rendant l'analyse des processus possible.
Source des données :
Ceci est le champ 'key' pour un ticket dans Jira Service Management.
Exemples
SR-2023-001IT-45892HELP-105
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
L'horodatage indiquant la dernière actualisation des données depuis le système source. | ||
|
Descriptionn
Cet attribut consigne la date et l'heure de la dernière extraction de données de Jira Service Management. Il fournit un contexte essentiel pour la récence 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 indispensable pour prendre des décisions éclairées. Ce horodatage 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.
Pourquoi est-ce important ? :
Indique la la réactualisation des données, garantissant que les analyses sont basées sur des informations à jour.
Source des données :
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.
Exemples
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Système source
SourceSystem
|
Le système à partir duquel les données de la demande de service ont été extraites. | ||
|
Descriptionn
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 traçabilité 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.
Pourquoi est-ce important ? :
Identifie l'origine des données, ce qui est impératif pour la gouvernance des données et lors de la combinaison de données de processus provenant de plusieurs systèmes d'entreprise.
Source des données :
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.
Exemples
Jira Service ManagementJiraSM
|
|||
|
Date d'échéance du SLA
SlaDueDate
|
La date et l'heure cibles auxquelles la demande de service devrait être résolue conformément à son SLA. | ||
|
Descriptionn
La date d'échéance SLA est un horodatage 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 indispensable pour le tableau de bord 'Service Request SLA Performance' et le KPI 'Taux de résolutionpect 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é terminée à temps, en retard ou si elle risque de violer son SLA.
Pourquoi est-ce important ? :
Ceci est le référentiel pour mesurer la performance. Il contribue directement au le calcul de la conformité SLA et aide à prioriser le travail.
Source des données :
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.
Exemples
2023-10-28T16:00:00Z2023-11-01T09:00:00Z
|
|||
|
Priorité de la demande
RequestPriority
|
Le niveau de priorité attribué à la demande de service, tel que Faible, Moyen, Élevé ou Critique. | ||
|
Descriptionn
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.
Pourquoi est-ce important ? :
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.
Source des données :
Cela correspond au champ 'priority' sur un ticket Jira.
Exemples
La plus élevéeÉlevéMoyenFaible
|
|||
|
Responsable assigné
Assignee
|
L'utilisateur ou l'agent actuellement assigné pour travailler sur la demande de service. | ||
|
Descriptionn
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 indispensable 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 points de blocage.
Pourquoi est-ce important ? :
Cet attribut est indispensable à analyser la charge de travail des agents, mesurer les performances individuelles et comprendre l'allocation des ressources.
Source des données :
Cela correspond au champ 'assignee' sur un ticket Jira.
Exemples
Alice JohnsonBob WilliamsNon assigné
|
|||
|
Statut de la demande
RequestStatus
|
Le statut actuel de la demande de service dans son cycle de vie. | ||
|
Descriptionn
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.
Pourquoi est-ce important ? :
Fournit un instantané actuel de chaque cas, permettant l'analyse du travail en cours et l'identification des requêtes bloquées ou vieillissantes.
Source des données :
Ceci est le champ 'status' sur un ticket Jira.
Exemples
OuvertEn coursEn Attente ClientRésolu
|
|||
|
Type de Demande
RequestType
|
La classification de la demande de service, telle que 'Demande d'accès' ou 'Problème matériel'. | ||
|
Descriptionn
Le type de demande classe la demande de service selon sa nature. Il s'agit d'une dimension clée 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 indispensable pour construire des dashboards pertinents comme 'Qualité de résolution par catégorie'.
Pourquoi est-ce important ? :
Cet attribut est indispensable pour comparer les processus, les charges de travail et les performances entre différentes catégories de demandes de service.
Source des données :
Ceci correspond souvent au champ 'issuetype' dans Jira ou à un champ personnalisé 'Type de demande' dans Jira Service Management.
Exemples
Demander un nouveau compteObtenir de l'aide informatiqueIntégrer un nouvel employé
|
|||
|
Canal
Channel
|
La méthode de soumission utilisée pour créer la demande de service, telle que Email, Portail ou API. | ||
|
Descriptionn
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 tableau de bord 'Service Request Throughput Trends'.
Pourquoi est-ce important ? :
Aide à analyser si le canal de soumission impacte les temps de résolution, la clarté des requêtes ou l'efficacité globale du processus.
Source des données :
Ces informationsns 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é.
Exemples
portailemailapi
|
|||
|
Déclarant
Reporter
|
L'utilisateur qui a initialement créé ou signalé la demande de service. | ||
|
Descriptionn
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.
Pourquoi est-ce important ? :
Identifie l'initiateur de la requête, permettant l'analyse des volumes et types de requêtes par utilisateur, département ou client.
Source des données :
Cela correspond au champ 'reporter' sur un ticket Jira.
Exemples
Charles DarwinMarie CurieIsaac Newton
|
|||
|
Équipe assignée
AssignedTeam
|
L'équipe ou le groupe responsable du traitement de la demande de service. | ||
|
Descriptionn
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 indispensablele 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.
Pourquoi est-ce important ? :
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.
Source des données :
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é.
Exemples
Support IT - Niveau 1Équipe d'InfrastructureSupport Applicatif
|
|||
|
État du SLA
SlaState
|
Indique si la requête de service a respecté, violé ou est conforme à son SLA défini. | ||
|
Descriptionn
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 l'horodatage de résolution à la 'SlaDueDate'. Il s'agit de l'attribut principal pour le tableau de bord 'Service Request SLA Performance' et est utilisé pour calculer le KPI 'Taux de résolutionpect des SLA'. Il offre une vue claire et rapide de la conformité au niveau de service, ce qui est indispensable pour le reporting, la gestion des contrats et le maintien de la qualité de service.
Pourquoi est-ce important ? :
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.
Source des données :
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é'.
Exemples
AtteintDépasséEn cours
|
|||
|
Incident rouvert
IsReopened
|
Un indicateur booléen qui indique si une requête de service a été rouverte après avoir été résolue. | ||
|
Descriptionn
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 indispensable pour calculer le KPI 'Taux de réouverture des demandes de service' et pour alimenter le tableau de bord '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.
Pourquoi est-ce important ? :
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.
Source des données :
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'.
Exemples
truefaux
|
|||
|
Organisation
Organization
|
L'organisation cliente ou le département interne auquel appartient le rapporteur. | ||
|
Descriptionn
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, « what-if » les SLA sont respectés de manière constante danss différentes unités commerciales.
Pourquoi est-ce important ? :
Facilite l'analyse de la demande de service et des performances par client ou département interne, fournissant des insights commerciaux clés.
Source des données :
Ces données proviennent du champ 'Organizations' associé à la demande de service dans Jira Service Management.
Exemples
Acme CorporationService FinancierGlobal Tech Inc.
|
|||
|
Résolution
Resolution
|
Le résultat final ou la conclusion d'une demande de service résolue. | ||
|
Descriptionn
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.
Pourquoi est-ce important ? :
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.
Source des donné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é'.
Exemples
TerminéRefuséDoublonCorrigé
|
|||
Activités de gestion des demandes de service
| Activité | Descriptionn | ||
|---|---|---|---|
|
Demande assignée
|
Cette activité se produit lorsqu'une demande de service est assignée à un agent ou une équipe spécifique pour résolution. Jira suit explicitement les changements du champ 'Assignee', fournissant un horodatage clair du moment où l'assignation a été effectuée. | ||
|
Pourquoi est-ce important ? :
C'est une étape clé pour mesurer le temps de triage à l'assignation et la distribution de la charge de travail des agents. Elle marque la transition de la file d'attente au traitement actif.
Source des données :
Capturé à partir de l'historique des tickets en recherchant la première instance du champ 'Assigné' ayant été défini ou modifié depuis 'non assigné'.
Capture
Utilisez l'horodatage du premier changement du champ 'Assignee' dans l'historique du ticket.
Type d'événement
explicit
|
|||
|
Demande de service créée
|
Cette activité marque le début du cycle de vie de la demande de service lorsqu'un utilisateur soumet officiellement une demande via un portail, un e-mail ou un autre canal. Cet événement est explicitement capturé dans Jira lors de la création d'un nouveau ticket de type 'Service Request', enregistrant l'horodatage de création. | ||
|
Pourquoi est-ce important ? :
C'est l'événement de démarrage principal pour le processus. Il est indispensable pour calculer le temps de cycle global et comprendre le volume des demandes et les modèles d'arrivée.
Source des données :
Ceci est un événement explicite capturé dans la table d'historique des tickets. L'horodatage d'activité est le champ 'created' sur le ticket Jira.
Capture
Utilisez l'horodatage de création du ticket à partir de la table ou de l'historique des 'issues'.
Type d'événement
explicit
|
|||
|
Demande de service fermée
|
Représente la clôture administrative finale de la requête de service, intervenant souvent automatiquement après une période définie dans l'état 'Résolu'. C'est le point terminal du cycle de vie du ticket dans Jira. | ||
|
Pourquoi est-ce important ? :
C'est l'événement de fin définitif du processus. Le temps entre 'Résolu' et 'Clôturé' peut être analysé pour comprendre les frais généraux administratifs ou les politiques de clôture automatique.
Source des données :
Déduit de l'historique des tickets. L'horodatage correspond au changement de statut final vers 'Fermé' ou un statut terminal équivalent.
Capture
Identifier l'horodatage du changement de statut final vers un statut 'Fermé'.
Type d'événement
inferred
|
|||
|
Demande de service résolue
|
Marque le moment officiel où la requête est considérée comme satisfaite et la solution est enregistrée. Jira renseigne le champ 'Date de résolution' lorsqu'un ticket entre pour la première fois dans un statut de la catégorie 'Terminé'. | ||
|
Pourquoi est-ce important ? :
C'est un jalon de fin principal pour le processus, essentiel pour calculer le temps de résolution et le respect des SLA. Il signifie la fin du travail actif.
Source des données :
Ceci est un événement explicite. L'horodatage est la valeur du champ 'Resolution Date' du ticket Jira, qui est défini lors de la première transition vers un statut de catégorie 'Terminé'.
Capture
Utilisez le champ 'resolutiondate' du ticket Jira. Ce champ est renseigné automatiquement.
Type d'événement
explicit
|
|||
|
Résolution Proposée
|
Dans de nombreux workflows de service desk, il s'agit d'une étape distincte où une solution est proposée au demandeur pour son approbation. Cela est déduit lorsque le statut du ticket passe à un état comme 'En attente d'acceptation client' ou 'En attente de confirmation'. | ||
|
Pourquoi est-ce important ? :
Cette activité isole le temps passé à attendre le retour d'information du client après qu'une solution a été fournie, aidant à le différencier du temps de travail interne.
Source des données :
Déduit de l'historique des tickets, capturé à l'horodatage lorsque le statut passe à un état indiquant que la solution est en attente de validation par le client.
Capture
Identifier l'horodatage du changement de statut à 'En attente d'acceptation client' ou équivalent.
Type d'événement
inferred
|
|||
|
Demande d'informations
|
Marque le moment où un agent a besoin de plus d'informations du demandeur pour poursuivre la résolution. Cela est généralement déduit par la transition du ticket vers un statut comme 'En attente du client' ou 'En attente de saisie'. | ||
|
Pourquoi est-ce important ? :
Des cycles de 'Demande d'informations' fréquents ou longs peuvent indiquer des soumissions initiales peu claires ou une communication inefficace, représentant une source significative de retards.
Source des données :
Déduit de l'historique des tickets. L'horodatage correspond au moment où le statut du ticket passe à 'En attente du client' ou à un statut équivalent.
Capture
Identifier l'horodatage lorsque le champ 'statut' passe à une valeur indiquant que le processus est en attente du client.
Type d'événement
inferred
|
|||
|
Demande rouverte
|
Cette activité capture les instances où une demande de service précédemment résolue est renvoyée à un état actif. Cela est déduit d'un changement de statut d'un état résolu ou clôturé à un état ouvert ou en cours. | ||
|
Pourquoi est-ce important ? :
Le suivi des demandes rouvertes est indispensable pour mesurer la qualité de la résolution et le taux de résolution au premier contact. Un taux de réouverture élevé indique des solutions inefficaces ou des problèmes récurrents.
Source des données :
Déduit de l'historique des tickets en identifiant une transition de statut d'une catégorie 'Résolu' ou 'Fermé' vers une catégorie 'Ouvert' ou 'En cours'.
Capture
Recherchez un changement de statut d'une catégorie 'Terminé' vers une catégorie 'À faire' ou 'En cours'.
Type d'événement
inferred
|
|||
|
Demande triée
|
Représente l'évaluation initiale d'une requête de service, où sa priorité, sa catégorie et son impact sont déterminés. Cette activité est généralement déduite d'un changement de statut, comme le passage de 'Nouveau' à 'En cours' ou à un statut dédié 'Trié'. | ||
|
Pourquoi est-ce important ? :
L'analyse du temps de triage aide à évaluer l'efficacité du processus initial de traitement des requêtes. Des retards à ce stade peuvent impacter significativement les temps de résolution globaux et le respect des SLA.
Source des données :
Déduit de l'historique des tickets en identifiant le premier horodatage d'un changement de statut d'un état initial 'Nouveau' ou 'Ouvert' vers un état actif comme 'En cours'.
Capture
Identifier le premier changement de statut de 'Nouveau' ou d'un statut initial équivalent basé sur le workflow du projet.
Type d'événement
inferred
|
|||
|
Engagement Fournisseur Initié
|
Cette activité signifie que la demande de service a été escaladée ou nécessite une action d'un fournisseur externe ou d'une tierce partie. Cela est déduit du passage du ticket à un statut comme 'En attente du fournisseur' ou 'Avec un tiers'. | ||
|
Pourquoi est-ce important ? :
Le suivi de l'engagement des fournisseurs est impératif pour identifier les dépendances externes et les retards qui échappent au contrôle direct du service desk interne.
Source des données :
Déduit de l'historique des tickets. L'horodatage correspond au moment où le statut du ticket passe à un statut désigné 'fournisseur'.
Capture
Identifier l'horodatage lorsque le champ 'statut' passe à une valeur telle que 'En attente du fournisseur'.
Type d'événement
inferred
|
|||
|
Engagement Fournisseur Terminé
|
Représente le moment où le fournisseur externe a terminé son action et où la demande de service est retournée à l'équipe interne. Cela est déduit lorsque le problème quitte le statut 'En attente du fournisseur'. | ||
|
Pourquoi est-ce important ? :
Mesurer la durée de l'engagement des fournisseurs aide à gérer leur performance et à comprendre l'impact des parties externes sur les temps de résolution globaux.
Source des données :
Déduit de l'historique des tickets. L'horodatage correspond au moment où le statut du ticket passe d'un statut 'fournisseur' à un état 'En cours'.
Capture
Identifier l'horodatage lorsque le champ 'statut' passe d'un état 'fournisseur' à un état 'actif'.
Type d'événement
inferred
|
|||
|
Informations fournies
|
Se produit lorsque le demandeur répond avec les informations nécessaires, permettant à l'agent de reprendre le travail. Cela est déduit lorsque le ticket sort d'un statut 'En attente du client', souvent déclenché par l'ajout d'un commentaire par le demandeur. | ||
|
Pourquoi est-ce important ? :
Cette activité complète la boucle de demande-réponse avec le client. Le temps entre la demande et la réception des informations est une composante clé du temps d'attente du processus.
Source des données :
Déduit de l'historique des tickets. L'horodatage correspond au moment où le statut du ticket passe de 'En attente du client' à un état 'En cours'.
Capture
Identifier l'horodatage lorsque le champ 'statut' passe d'un état 'en attente' à un état 'actif'.
Type d'événement
inferred
|
|||
|
Résolution Confirmée
|
Se produit lorsque le demandeur accepte formellement la solution proposée, déclenchant souvent une transition automatisée vers le statut 'Résolu'. Cet événement est généralement déduit de ce changement de statut. | ||
|
Pourquoi est-ce important ? :
Ce jalon valide l'efficacité de la solution et est le déclencheur pour arrêter le compte à rebours du SLA. Il aide à mesurer le temps que les clients mettent à confirmer les correctifs.
Source des données :
Déduit de l'historique des tickets. L'horodatage correspond au moment où le statut du ticket passe de 'En attente d'acceptation client' à 'Résolu' ou 'Fermé'.
Capture
Identifier l'horodatage du changement de statut de 'En attente d'acceptation client' à un statut 'Résolu' ou 'Fermé'.
Type d'événement
inferred
|
|||
|
Solution implémentée
|
Indique que l'agent a effectué les actions nécessaires ou développé une solution pour répondre à la requête de service. Cela est souvent déduit d'un changement de statut vers 'En attente de révision' ou directement vers 'Résolu'. | ||
|
Pourquoi est-ce important ? :
Ce jalon marque l'achèvement du travail de résolution principal. Le temps précédant cette activité représente souvent la partie principale à valeur ajoutée du processus.
Source des données :
Déduit de l'historique des tickets, correspondant à l'horodatage du changement de statut vers 'Résolu', 'En attente d'acceptation', ou un statut similaire de prélèvement.-clôture.
Capture
Identifier l'horodatage lorsque le champ 'statut' passe à une valeur indiquant que le travail est terminé.
Type d'événement
inferred
|
|||