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

Modèle universel de Process Mining
Votre `Template` de Données pour la Gestion des Demandes de Service

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

Modèle universel de Process Mining

Ceci est notre modèle de données générique de Process Mining pour Gestion des demandes de service. Utilisez nos modèles spécifiques au système pour des directives plus précises.

Sélectionnez un système spécifique
  • Champs de données standardisés pour une analyse cohérente entre les systèmes.
  • Activités clés du processus cartographiées pour une découverte complète du processus.
  • Une base polyvalente pour l'optimisation de tout workflow de demande de service.
Nouveau dans les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Attributs de gestion des demandes de service

Ce sont les champs de données recommandés à inclure dans votre `journal d'événements`, offrant un contexte complet pour une analyse approfondie de votre processus de gestion des demandes de service.
5 Obligatoire 6 Recommandé 6 Facultatif
Nom Description
Activité
Activity
Le nom d'une tâche, d'un événement ou d'un changement de statut spécifique qui s'est produit au cours du cycle de vie de la demande de service.
Description

L'attribut Activité décrit une étape ou une action spécifique effectuée sur une demande de service. Ces activités constituent les blocs de construction séquentiels du processus, tels que 'Demande créée', 'Demande affectée', 'Travail en cours' et 'Demande fermée'. Chaque activité représente un point distinct dans le temps du parcours d'une demande de service.

L'analyse des activités est le cœur du Process Mining. Elle permet la découverte et la visualisation du flux de processus réel. En examinant la séquence et la fréquence des activités, les analystes peuvent identifier les chemins courants, les écarts par rapport au processus standard, les goulots d'étranglement où les demandes restent bloquées et les boucles de reprise où les étapes sont répétées inutilement.

Pourquoi c'est important

Il définit les étapes du processus, permettant la découverte du flux de processus réel, des goulots d'étranglement et des écarts.

Où obtenir

Souvent dérivé des journaux de changement de statut, des tables d'événements ou des pistes d'audit associés à l'objet de la demande de service.

Exemples
Demande de service crééeDemande assignéeDemande résolueDemande de service fermée
Heure de début
StartTime
L'horodatage indiquant le début d'une activité ou d'un événement.
Description

L'attribut Heure de Début enregistre la date et l'heure précises du début d'une activité spécifique. Cet horodatage est crucial pour ordonner les événements chronologiquement et pour calculer la durée des activités ainsi que le cycle de vie global du cas. Chaque activité du processus doit avoir une Heure de Début correspondante pour construire un journal d'événements précis.

Dans l'analyse des processus, l'Heure de Début est utilisée pour calculer des indicateurs de performance clés (KPI) tels que le temps de cycle, le temps d'attente entre les activités et le temps de traitement des activités. Elle permet de créer une vue temporelle du processus, mettant en évidence les retards et aidant à identifier les étapes qui consomment le plus de temps. Des horodatages précis sont fondamentaux pour toute analyse liée à la performance.

Pourquoi c'est important

Cet horodatage est essentiel pour ordonner correctement les événements et calculer toutes les métriques liées au temps, telles que les temps de cycle et les goulots d'étranglement.

Où obtenir

Situé dans les tables du journal d'événements ou de la piste d'audit, souvent enregistré comme une 'date de création' ou un 'horodatage d'événement' pour chaque enregistrement d'activité.

Exemples
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
ID de demande de service
CaseId
L'identifiant unique pour chaque cas de demande de service. Il est utilisé pour suivre une seule demande, de sa création à sa clôture.
Description

L'ID de la demande de service est la clé primaire qui identifie de manière unique chaque demande de service tout au long de son cycle de vie. Il agit comme l'identifiant de cas, liant toutes les activités, changements de statut et attributs connexes en une instance de processus cohérente.

Dans l'analyse Process Mining, cet ID est fondamental pour reconstituer le parcours de bout en bout de chaque demande. En regroupant tous les événements sous un CaseId commun, les analystes peuvent visualiser les flux de processus, calculer les durées de cas et identifier les variations dans la manière dont les différentes demandes sont traitées. C'est la pierre angulaire de toute analyse effectuée sur le processus de gestion des demandes de service.

Pourquoi c'est important

Cet identifiant est essentiel pour relier tous les événements d'une demande de service, permettant une vue complète du processus de bout en bout.

Où obtenir

Généralement trouvé dans l'en-tête ou la table de transaction principale des demandes de service.

Exemples
SR-2023-00123REQ0045891TICKET-98765
Dernière mise à jour des données
LastDataUpdate
Le timestamp indiquant la dernière fois que les données ont été actualisées à partir du système source.
Description

Dernière mise à jour des données fournit un horodatage de l'extraction ou de l'actualisation la plus récente des données. Il informe les utilisateurs sur la fraîcheur des données qu'ils analysent, s'assurant qu'ils comprennent si l'analyse reflète l'état actuel ou un instantané passé.

Cet attribut est essentiel pour la surveillance opérationnelle et le reporting, car il fournit un contexte pour la pertinence des informations générées. Il aide les utilisateurs à faire confiance aux données et à prendre des décisions éclairées basées sur leur actualité. Par exemple, un tableau de bord affichant des données mises à jour il y a une semaine serait interprété différemment d'un tableau de bord mis à jour il y a une heure.

Pourquoi c'est important

Indique la fraîcheur des données, ce qui est vital pour garantir que les analyses sont pertinentes et basées sur des informations à jour.

Où obtenir

Il s'agit d'un champ de métadonnées généralement généré et stocké pendant le processus d'extraction de données (ETL).

Exemples
2023-10-27T08:00:00Z2023-10-26T23:59:59Z
Système source
SourceSystem
Identifie le système ou l'application d'où proviennent les données de la demande de service.
Description

L'attribut Système Source spécifie le nom de la plateforme de gestion des services informatiques (ITSM) ou de toute autre application d'où les données ont été extraites. Dans les environnements multi-systèmes, ce champ permet de différencier les sources de données et d'assurer une traçabilité claire des données.

Bien que non directement utilisé dans la plupart des analyses de flux de processus, il est essentiel pour la gouvernance, la validation et le dépannage des données. Lors de la combinaison de données provenant de sources multiples, cet attribut permet aux analystes de segmenter la vue du processus par système, ce qui peut révéler des différences dans l'exécution des processus ou la qualité des données entre les différentes plateformes.

Pourquoi c'est important

Crucial pour la gouvernance des données et le dépannage, il clarifie l'origine des données, en particulier dans les environnements avec plusieurs systèmes intégrés.

Où obtenir

Cette valeur est généralement ajoutée pendant le processus d'extraction de données (ETL) et n'est pas un champ inhérent au système source lui-même.

Exemples
ServiceNowJira Service ManagementZendesk
Agent assigné
AssignedAgent
L'utilisateur ou l'agent individuel actuellement affecté au traitement de la demande de service.
Description

L'agent affecté est la personne spécifique responsable du traitement de la demande de service à un moment donné. Une demande peut être affectée à différents agents tout au long de son cycle de vie.

Cet attribut est essentiel pour l'analyse des performances et de la charge de travail. Il permet aux organisations de mesurer et de comparer les performances des agents individuels, y compris leurs temps de résolution moyens et le volume de demandes qu'ils traitent. Il est également utilisé pour analyser les réaffectations entre agents, ce qui peut indiquer des problèmes liés au triage initial, à la spécialisation des agents ou à l'équilibrage de la charge de travail.

Pourquoi c'est important

Permet l'analyse des performances individuelles des agents, de la répartition de la charge de travail et de la fréquence des réaffectations entre agents.

Où obtenir

Disponible dans l'enregistrement de la demande de service. Les changements dans ce champ sont souvent suivis dans un journal d'audit ou une table d'historique.

Exemples
John SmithJane Doeagent_user_123
Date d'échéance du `SLA`
SlaDueDate
La date et l'heure auxquelles la demande est censée être résolue conformément à son accord de niveau de service (SLA).
Description

La Date d'échéance du SLA est un horodatage cible calculé en fonction de l'accord de niveau de service (SLA) associé à la demande. Elle est déterminée par des facteurs tels que la priorité, le type et l'heure de création de la demande, définissant ainsi le délai de résolution attendu.

Cet attribut constitue la base de toute analyse de conformité aux SLA. En comparant le temps de résolution réel avec la Date d'échéance du SLA, les organisations peuvent déterminer si une demande a été résolue à temps ou si le SLA a été enfreint. Il s'agit d'un KPI essentiel pour mesurer la qualité du service et est utilisé pour identifier les problèmes systémiques qui entraînent des retards et des non-conformités.

Pourquoi c'est important

C'est la référence pour mesurer la performance. Elle est utilisée pour calculer les taux de conformité aux SLA et identifier les demandes qui ne respectent pas les accords.

Où obtenir

Souvent un champ calculé dans l'enregistrement de la demande de service, déterminé par la politique SLA appliquée.

Exemples
2023-10-28T17:00:00Z2023-11-01T09:00:00Z
Équipe assignée
AssignedTeam
Le groupe ou l'équipe de support actuellement affecté(e) à la demande de service.
Description

L'équipe affectée désigne le groupe de support spécifique responsable de la demande de service. Les demandes sont souvent acheminées entre différentes équipes, telles qu'un centre d'assistance de niveau 1, une équipe réseau ou une équipe de développement logiciel, en fonction de l'expertise requise.

L'analyse des transferts entre équipes est un élément central du Process Mining en gestion de services. Cet attribut permet la visualisation des transferts d'équipe à équipe, aidant à identifier les lacunes de communication ou les retards. Il permet également d'établir des points de référence de performance entre les équipes, comparant leur efficacité, le volume de demandes et leur capacité à résoudre les demandes sans escalade supplémentaire.

Pourquoi c'est important

Crucial pour analyser les transferts de processus entre équipes, identifier les retards de transfert et comparer les performances des équipes.

Où obtenir

Un champ standard dans l'enregistrement de la demande de service. Les changements dans ce champ sont suivis dans un journal d'audit.

Exemples
Service Desk L1Opérations RéseauSupport des systèmes RH
Priorité de la demande
RequestPriority
Le niveau de priorité attribué à la demande, indiquant son impact commercial et son urgence.
Description

La priorité de la demande est une classification qui aide les équipes de support à déterminer l'ordre de traitement des demandes. Elle est généralement basée sur une combinaison de l'impact de la demande sur l'entreprise et de son urgence. Les niveaux de priorité courants incluent Faible, Moyen, Élevé et Critique.

Cet attribut est vital pour l'analyse des performances et l'allocation des ressources. Les analystes peuvent comparer les temps de cycle et la conformité aux SLA entre les différents niveaux de priorité pour s'assurer que les demandes de haute priorité sont traitées de manière appropriée. Il aide également à identifier si les demandes de faible priorité sont négligées ou si le système de priorisation est correctement suivi par les équipes de support.

Pourquoi c'est important

Essentiel pour analyser si les demandes sont traitées selon l'importance commerciale et pour comprendre comment la priorité impacte le temps de résolution.

Où obtenir

Généralement un champ standard sur l'enregistrement principal de la demande de service.

Exemples
FaibleMoyenÉlevéCritique
Statut de la demande
RequestStatus
Le statut actuel ou historique de la demande de service au moment d'un événement, tel que 'En cours' ou 'Fermé'.
Description

Le statut de la demande indique l'état de la demande de service à un moment donné de son cycle de vie. Les statuts courants incluent Nouveau, En cours, En attente, Résolue et Fermée. Cet attribut fournit un aperçu de la position de la demande dans le processus global.

L'analyse du statut de la demande est essentielle pour comprendre le flux de processus et les transitions d'état. Il peut être utilisé pour filtrer les cas, identifier les demandes bloquées dans un état particulier et mesurer le temps passé dans chaque statut. Par exemple, l'analyse du temps que les demandes passent en statut 'En attente' peut révéler des retards causés par l'attente d'informations des utilisateurs ou des équipes externes.

Pourquoi c'est important

Il permet d'analyser le temps passé par les demandes dans chaque état, mettant en évidence les goulots d'étranglement ou les retards dans le processus.

Où obtenir

Disponible dans la table principale des demandes de service ou dans les journaux d'historique des statuts.

Exemples
En coursEn Attente ClientRésoluClôturé
Type de service
ServiceType
La catégorie ou le type de service demandé par l'utilisateur.
Description

Le type de service classe la nature de la demande de service. Cela peut aller des demandes de nouveau matériel ou d'accès logiciel aux demandes générales ou au support technique. Cette catégorisation aide à acheminer la demande à la bonne équipe et à comprendre la demande pour différents services.

Dans l'analyse des processus, le type de service est une dimension puissante pour la segmentation des données. En filtrant la cartographie des processus par différents types de service, les organisations peuvent découvrir que certains types de demandes suivent des processus très différents, ont des temps de cycle plus longs ou subissent plus de reprises. Cette information permet des efforts d'amélioration de processus ciblés pour des catégories de services spécifiques.

Pourquoi c'est important

Permet de filtrer et de comparer les processus pour différentes catégories de demandes, révélant des goulots d'étranglement ou des inefficacités uniques pour chaque type.

Où obtenir

Un champ standard dans l'enregistrement de la demande de service, souvent lié à un catalogue de services.

Exemples
Demande de matérielAccès logicielRéinitialisation du mot de passeDemande générale
Canal de soumission
SubmissionChannel
La méthode ou le canal par lequel la demande de service a été soumise.
Description

Le Canal de Soumission indique comment la demande de service a été créée, par exemple, via un portail en self-service, un e-mail, un appel téléphonique ou une API. Différents canaux peuvent avoir des processus associés ou des attentes utilisateurs différentes.

L'analyse du processus par canal de soumission peut révéler des informations importantes. Par exemple, les demandes soumises via un portail en self-service pourraient être plus structurées et résolues plus rapidement que celles soumises par e-mail, qui peuvent nécessiter une saisie manuelle de données. Cette analyse peut aider les organisations à promouvoir des canaux plus efficaces ou à améliorer les processus pour ceux qui le sont moins.

Pourquoi c'est important

Aide à déterminer si la méthode de soumission impacte l'efficacité du processus, le temps de résolution ou le taux de résolution au premier contact.

Où obtenir

Généralement trouvé comme un champ standard sur l'enregistrement de la demande de service.

Exemples
PortailE-mailTéléphoneChat
Code de Résolution
ResolutionCode
Un code ou une catégorie indiquant le résultat final ou la raison de la clôture de la demande.
Description

Le code de résolution offre un moyen structuré de classer le résultat d'une demande de service. Les exemples incluent 'Résolu 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 précieux pour l'analyse des causes profondes. En analysant la fréquence des différents codes de résolution, les organisations peuvent identifier les problèmes récurrents, les solutions courantes et les opportunités de créer des articles de base de connaissances ou des résolutions automatisées. Par exemple, un nombre élevé de résolutions 'Réinitialisation de mot de passe' pourrait justifier l'investissement dans un outil de réinitialisation de mot de passe en libre-service.

Pourquoi c'est important

Permet l'analyse des causes profondes en catégorisant la manière dont les demandes sont résolues, aidant à identifier les tendances et les domaines pour une gestion proactive des problèmes.

Où obtenir

Un champ généralement rempli manuellement par l'agent lors de la résolution ou de la clôture de la demande de service.

Exemples
ExécutéeErreur utilisateurAnnulé par l'utilisateurPlus nécessaire
Département du demandeur
RequestorDepartment
Le département ou l'unité commerciale de l'utilisateur qui a soumis la demande.
Description

Cet attribut identifie le département ou l'unité commerciale de la personne qui a initié la demande de service. Il fournit un contexte organisationnel à la demande.

L'analyse des demandes par département peut aider à identifier les besoins, les tendances ou les problèmes spécifiques à chaque département. Par exemple, un volume élevé d'un certain type de demande du service Financier pourrait indiquer un besoin de formation ciblée ou une amélioration du système. Cela permet également d'établir des rapports de refacturation et de comprendre la demande de services informatiques au sein de l'organisation.

Pourquoi c'est important

Fournit un contexte organisationnel, permettant l'analyse des schémas de demandes et de la demande de services par unité commerciale.

Où obtenir

Cette information est généralement extraite du profil utilisateur du demandeur dans l'annuaire des employés ou le système ITSM.

Exemples
FinanceRessources HumainesMarketingOpérations IT
Heure de fin
EndTime
Le 'timestamp' indiquant quand une activité ou un 'event' a été complété.
Description

L'heure de fin enregistre la date et l'heure précises auxquelles une activité spécifique a été achevée. Alors que l'heure de début marque le début, l'heure de fin marque la conclusion, définissant la durée d'une seule étape de processus. Tous les événements n'ont pas une heure de fin distincte, car certains peuvent être instantanés.

Cet attribut est essentiel pour calculer le temps de traitement des activités individuelles. En soustrayant l'heure de début de l'heure de fin, les analystes peuvent mesurer le temps que les agents ou les systèmes passent à travailler activement sur une tâche. Cela aide à identifier quelles activités spécifiques sont chronophages et sont les principales candidates à l'optimisation ou à l'automatisation.

Pourquoi c'est important

Permet le calcul des temps de traitement des activités, aidant à identifier quelles étapes spécifiques du processus sont les plus chronophages.

Où obtenir

Trouvé dans les tables de journal d'événements ou de piste d'audit. Il peut être nécessaire de le dériver en utilisant l'heure de début de l'activité suivante s'il n'est pas explicitement disponible.

Exemples
2023-10-26T10:05:12Z2023-10-26T15:00:45Z2023-10-28T09:20:00Z
Nombre de Réaffectations
ReassignmentCount
Le nombre total de fois où la demande a été réaffectée entre différents agents ou équipes.
Description

Le nombre de réaffectations est une métrique qui totalise le nombre de fois qu'une demande de service a été transférée d'un agent ou d'une équipe à une autre. Un nombre élevé peut indiquer des problèmes tels qu'un routage initial incorrect, un manque de connaissances de l'agent ou une propriété de processus peu claire.

C'est un indicateur clé de l'inefficacité des processus. En Process Mining, cette métrique aide à quantifier le 'ping-pong' qu'une demande subit. L'analyse des cas avec un nombre élevé de réaffectations peut révéler des opportunités d'améliorer le processus de triage, de renforcer la formation des agents ou d'affiner les responsabilités des équipes pour garantir que les demandes sont acheminées correctement dès la première fois.

Pourquoi c'est important

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

Où obtenir

Il s'agit d'une métrique calculée, dérivée en comptant le nombre de fois où le champ AgentAssigné ou ÉquipeAssignée change pour un IdentifiantCas donné.

Exemples
0135
SLA est enfreint
IsSlaBreached
Un indicateur signalant si la demande de service a été résolue après sa date limite de SLA.
Description

Cet attribut booléen indique si la demande de service n'a pas respecté son accord de niveau de service (SLA) défini. Il est vrai si la demande a été résolue après la Date d'échéance SLA, et faux dans le cas contraire.

Cet attribut simplifie les rapports et l'analyse de conformité aux SLA. Au lieu d'effectuer des comparaisons de dates dans chaque requête, ce simple indicateur permet un filtrage et une agrégation aisés. C'est une métrique primaire pour les dashboards axés sur la performance des SLA et aide à identifier rapidement le volume et le pourcentage de demandes qui ne respectent pas les objectifs de service.

Pourquoi c'est important

Fournit un indicateur clair et simple pour l'analyse des performances SLA, facilitant le filtrage et le reporting sur les demandes en infraction.

Où obtenir

Il s'agit d'un attribut dérivé, calculé en comparant l'horodatage de résolution final avec le champ Date d'échéance SLA lors de la transformation des données.

Exemples
truefaux
Obligatoire Recommandé Facultatif

Activités de gestion des demandes de service

Ce tableau décrit les étapes clés du processus et les jalons critiques à capturer pour une découverte précise des processus au sein de votre `workflow` de demande de service.
7 Recommandé 9 Facultatif
Activité Description
Demande assignée
La demande de service a été affectée à un agent ou une équipe d'exécution spécifique responsable de l'accomplissement du travail. Ceci marque la transition du triage initial à la file d'attente d'exécution.
Pourquoi c'est important

Il s'agit d'une étape cruciale pour mesurer les KPI de temps d'affectation et comprendre la répartition de la charge de travail entre les équipes et les individus.

Où obtenir

Cela est capturé en suivant les changements apportés aux champs Affecté à ou Groupe Affecté dans le journal d'audit ou l'historique de la demande.

Capture

Identifiez le premier horodatage où le champ de l'attributaire ou du groupe d'affectation est renseigné.

Type d'événement explicit
Demande d'informations
L'agent d'exécution nécessite des informations supplémentaires du demandeur pour poursuivre. La demande est généralement placée dans un état en attente ou en pause, interrompant le décompte de l'exécution.
Pourquoi c'est important

Cette activité met en évidence les dépendances vis-à-vis du demandeur et est une cause principale des temps de cycle prolongés. Le suivi de sa fréquence et de sa durée révèle des lacunes de communication.

Où obtenir

Cela est inféré d'un changement de statut vers un état tel que « En attente du client », « En attente d'informations utilisateur » ou « En suspens ».

Capture

Utilisez l'horodatage lorsque le statut de la demande passe à un état indiquant qu'elle est en attente de l'utilisateur.

Type d'événement inferred
Demande de service créée
C'est la première activité du processus, marquant la soumission formelle et l'enregistrement d'une nouvelle demande de service. Elle est capturée lorsqu'un utilisateur soumet une demande via un portail, un e-mail ou un autre canal, générant un identifiant de cas unique.
Pourquoi c'est important

Cette activité établit le début du cycle de vie du processus, ce qui est fondamental pour calculer le temps de cycle global et analyser les volumes de demandes.

Où obtenir

Il s'agit généralement d'un événement de création explicite trouvé dans la table de transaction principale ou de ticket, horodaté lors de la création de l'enregistrement.

Capture

Utilisez l'horodatage de création de l'enregistrement principal de la demande de service.

Type d'événement explicit
Demande de service fermée
La demande de service est formellement clôturée et déplacée vers un état archivé où aucune autre action ne peut être entreprise. Ceci est l'activité finale du cycle de vie.
Pourquoi c'est important

Cette activité marque la fin définitive du processus. Le temps entre la résolution et la clôture peut mettre en évidence des retards de processus dans la confirmation des solutions.

Où obtenir

Il s'agit généralement d'un changement de statut final en « Fermé », se produisant souvent automatiquement après une période définie dans l'état « Résolu ».

Capture

Utilisez l'horodatage du journal d'événements lorsque le statut passe à « Fermé ».

Type d'événement explicit
Demande résolue
L'agent a terminé le travail d'exécution et estime que la demande de service a été satisfaite. La demande est placée dans un état 'Résolue', arrêtant souvent le compteur SLA.
Pourquoi c'est important

C'est l'étape la plus critique du processus de réalisation. Le temps entre la création et la résolution est un KPI primaire pour mesurer la performance.

Où obtenir

Il s'agit presque toujours d'un changement de statut distinct en « Résolu » ou « Réalisé », enregistré dans le journal d'historique de la demande.

Capture

Utilisez l'horodatage du journal d'événements lorsque le statut passe pour la première fois à « Résolu » ou son équivalent.

Type d'événement explicit
Demande rouverte
Une demande de service précédemment résolue est revenue à un état actif. Cela se produit généralement lorsque le demandeur indique que la solution n'était pas efficace ou que le problème est réapparu.
Pourquoi c'est important

Les demandes rouvertes sont un indicateur direct de reprises et d'un faible taux de résolution au premier contact. L'analyse de ces événements est cruciale pour améliorer la qualité du service.

Où obtenir

Cela est inféré d'un changement de statut de « Résolu » ou « Fermé » vers un état ouvert ou en cours.

Capture

Capturez l'horodatage lorsque le statut passe d'un état résolu à un état actif.

Type d'événement inferred
Travail en cours
L'agent ou l'équipe affecté(e) a commencé à travailler activement à l'exécution de la demande de service. Ceci indique que la demande est passée d'une file d'attente à un état de travail actif.
Pourquoi c'est important

Cette activité marque le début du temps de réalisation actif. L'analyse de la durée de cette phase est essentielle pour identifier les inefficacités du processus.

Où obtenir

Cela est généralement inféré du premier changement de statut vers un état « En cours » ou « Actif » après l'affectation.

Capture

Capturez l'horodatage du premier changement de statut vers un état actif comme 'En cours' après que la demande ait été assignée.

Type d'événement inferred
Approbation demandée
La demande de service a été soumise à un approbateur ou un groupe d'approbation désigné et est en attente d'une décision. Cette étape est courante pour les demandes ayant des implications en termes de coûts, de sécurité ou de ressources.
Pourquoi c'est important

Le suivi de cette activité aide à identifier les retards dans la phase d'approbation, qui est souvent un goulot d'étranglement important avant que le travail de réalisation ne puisse commencer.

Où obtenir

Cela est souvent inféré d'un changement de statut vers un état « En attente d'approbation » ou « En attente de validation » dans le journal d'historique de la demande.

Capture

Capturez l'horodatage lorsque le statut de la demande passe à un état en attente d'approbation.

Type d'événement inferred
Demande approuvée
La demande de service a été formellement approuvée par la partie requise. Cette décision permet au processus d'exécution de passer à l'étape suivante.
Pourquoi c'est important

Cela marque une étape clé, concluant le sous-processus d'approbation. Le temps entre « Approbation demandée » et « Demande approuvée » est un KPI critique.

Où obtenir

Cet événement est généralement trouvé dans un journal d'approbation ou inféré d'un changement de statut de « En attente d'approbation » à un état actif.

Capture

Utilisez l'horodatage de l'enregistrement d'approbation ou de l'événement de changement de statut dans le journal d'audit de la demande.

Type d'événement explicit
Demande de service annulée
La demande de service a été retirée avant que l'exécution ne soit achevée. Cela peut être initié soit par le demandeur, soit par le service d'assistance.
Pourquoi c'est important

Cela représente une fin alternative et infructueuse du processus. L'analyse des annulations aide à comprendre pourquoi les demandes deviennent non pertinentes ou ont été créées par erreur.

Où obtenir

Il s'agit généralement d'un changement de statut explicite en « Annulé » ou « Retiré » dans l'historique de statut de la demande.

Capture

Capturez l'horodatage lorsque le statut est mis à jour à un état 'Annulé'.

Type d'événement explicit
Demande réassignée
La propriété de la demande de service a été transférée d'un agent ou d'une équipe à un autre après l'affectation initiale. Ceci indique souvent une demande mal acheminée ou une escalade.
Pourquoi c'est important

Les réaffectations fréquentes peuvent signaler des problèmes liés au triage initial, aux compétences des agents ou à la complexité du processus, conduisant souvent à des temps de résolution plus longs.

Où obtenir

Cela est enregistré en suivant tout changement dans les champs Affecté à ou Groupe Affecté après la première affectation.

Capture

Capturez chaque horodatage où le champ de l'attributaire ou du groupe d'affectation est mis à jour, à l'exclusion de l'affectation initiale.

Type d'événement explicit
Demande rejetée
La demande de service a été officiellement refusée lors d'une phase d'approbation. Il s'agit d'un état terminal qui interrompt le processus avant le début de tout travail de réalisation.
Pourquoi c'est important

L'analyse des demandes rejetées aide à comprendre les raisons du refus et peut révéler des problèmes liés aux définitions des demandes, aux politiques ou aux attentes des utilisateurs.

Où obtenir

Cela est généralement enregistré comme un statut spécifique tel que « Rejeté » ou « Refusé » dans l'historique de statut de la demande.

Capture

Capturez l'horodatage lorsque le statut de la demande est mis à jour à 'Rejetée' ou un état terminal similaire.

Type d'événement explicit
Dépendance externe engagée
La demande de service a été transférée à un fournisseur externe ou à un autre service interne pour action. Ceci place la demande dans un état d'attente de la réponse du tiers.
Pourquoi c'est important

Cela aide à isoler et à mesurer les retards causés par des parties externes, ce qui est essentiel pour une analyse de performance précise et une gestion des SLA.

Où obtenir

Cela est généralement inféré d'un changement de statut vers « En attente du fournisseur » ou « En attente d'une tierce partie », ou d'une affectation à un groupe spécifique au fournisseur.

Capture

Identifiez l'horodatage lorsque le statut passe à un état indiquant une dépendance envers un tiers.

Type d'événement inferred
Informations fournies
Le demandeur a répondu avec les informations nécessaires, permettant à l'agent d'exécution de reprendre le travail. Cet événement déplace généralement la demande hors d'un état en attente.
Pourquoi c'est important

Cela marque la fin d'une période d'attente induite par l'utilisateur. Le temps entre « Informations demandées » et cette activité est une métrique clé pour l'analyse des dépendances.

Où obtenir

Cela est souvent inféré lorsque le statut d'une demande passe d'un état en attente à un état actif, fréquemment déclenché par un commentaire ou une mise à jour de l'utilisateur.

Capture

Capturez l'horodatage lorsque le statut revient à un état actif depuis un état en attente de l'utilisateur.

Type d'événement inferred
Résolution Confirmée
Le demandeur a activement confirmé que le service a été livré de manière satisfaisante et que la demande est résolue. Ceci fournit une confirmation positive d'une résolution réussie.
Pourquoi c'est important

Cette activité fournit des données précieuses pour mesurer la satisfaction client et valide l'efficacité de la résolution avant la clôture finale.

Où obtenir

Cela peut être un changement de statut explicite ou inféré d'une réponse positive à une enquête ou d'un commentaire spécifique ajouté par l'utilisateur après la résolution.

Capture

Identifiez les horodatages des événements de confirmation de l'utilisateur, tels qu'un changement de statut déclenché par l'utilisateur ou une réponse à une enquête liée.

Type d'événement inferred
SLA Non Respecté
Un accord de niveau de service (SLA) basé sur le temps, tel que le temps de réponse ou le temps de résolution, a été violé. Il s'agit d'un événement calculé plutôt que d'une action manuelle de l'utilisateur.
Pourquoi c'est important

Le suivi des violations de SLA est essentiel pour les rapports de conformité et pour identifier les demandes qui ne sont pas traitées en temps voulu.

Où obtenir

Certains systèmes enregistrent cela comme un événement explicite. Dans le cas contraire, cela doit être calculé en comparant les horodatages de résolution aux horodatages cibles des SLA.

Capture

Comparez l'horodatage de résolution ou de réponse à la date limite de SLA définie. Si la date de résolution est ultérieure, générez cet événement.

Type d'événement calculated
Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données pour le Process Mining.

Les méthodes d'extraction varient selon le système. Pour des instructions détaillées,

lisez notre guide ETL

ou sélectionnez un processus et un système spécifiques.