Votre Template de Données pour la Gestion des Demandes de Service
Votre Template de Données pour la Gestion des Demandes de Service
- Attributs recommandés à collecter
- Activités clés à suivre pour la découverte de processus
- Guide d'extraction des données étape par étape
Attributs de gestion des demandes de service
| Nom | Description | ||
|---|---|---|---|
|
Activité
ActivityName
|
Le nom de l''event' ou de la tâche spécifique survenue au cours du cycle de vie de la demande de service. | ||
|
Description
L'attribut Activité enregistre le nom de chaque étape ou changement de statut dans le processus de demande de service. Cela peut inclure des événements comme 'Demande créée', 'Demande approuvée', 'Attribuée à l'agent' ou 'Demande clôturée'. L'analyse de ces activités permet la visualisation du flux de processus, l'identification des chemins courants et la détection des déviations par rapport à la procédure standard. C'est le fondement pour comprendre ce qui se passe réellement pendant le processus de réalisation de la demande.
Pourquoi c'est important
C'est un attribut obligatoire qui définit les étapes de la carte de processus. Il est fondamental pour toutes les analyses de processus, y compris la découverte des goulots d'étranglement, des boucles de retouches et des problèmes de conformité.
Où obtenir
Dérivé des changements dans les champs 'État' ou 'Étape' des tables comme 'sc_request' ou 'sc_req_item', ou du journal d'audit (sys_audit).
Exemples
Demande de service crééeDemande attribuée au groupeDemande de service résolueInformations demandées à l'utilisateur
|
|||
|
Heure de début
EventTime
|
L'horodatage indiquant le début d'une activité ou d'un événement. | ||
|
Description
Cet attribut capture la date et l'heure exactes auxquelles chaque activité au sein du processus de demande de service s'est produite. Il fournit la séquence chronologique des événements nécessaire à la construction de la carte de processus et à toute analyse basée sur le temps. Des timestamps précis sont cruciaux pour calculer les temps de cycle, les temps d'attente et les durées de traitement. Ces données permettent l'identification des goulots d'étranglement, des violations de SLA et des tendances de performance au fil du temps.
Pourquoi c'est important
C'est un timestamp obligatoire pour ordonner correctement les événements. Il est la base de toutes les analyses de performance et de durée, y compris le temps de cycle et l'identification des goulots d'étranglement.
Où obtenir
Généralement trouvé dans les champs 'sys_updated_on' ou 'sys_created_on' des tables ServiceNow pertinentes (par exemple, sc_request, sc_task) ou dans la piste d'audit (sys_audit).
Exemples
2023-04-15T10:00:00Z2023-04-15T11:30:15Z2023-04-16T09:05:45Z
|
|||
|
ID de demande de service
ServiceRequestID
|
L'identifiant unique pour chaque enregistrement de demande de service. | ||
|
Description
L'ID de la demande de service est la clé primaire qui identifie de manière unique chaque demande de service soumise par un utilisateur ou un système. Il sert de fil conducteur central reliant tous les événements ultérieurs, de l'enregistrement initial à la clôture finale. En process mining, cet ID est essentiel pour reconstituer le parcours de bout en bout de chaque demande, permettant une analyse complète de son cycle de vie.
Pourquoi c'est important
C'est l'ID de cas obligatoire. Il connecte toutes les activités liées en une seule instance de processus, permettant l'analyse des flux de processus, des variations et des temps de cycle.
Où obtenir
Table ServiceNow Request [sc_request], champ 'number'.
Exemples
REQ0010001REQ0010025REQ0010112
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
Le timestamp de la plus récente actualisation ou extraction des données. | ||
|
Description
Cet attribut indique la date et l'heure de la dernière extraction des données du système source et de leur chargement dans l'outil de process mining. Il offre une transparence sur la fraîcheur des données analysées. Les analystes utilisent cette information pour comprendre s'ils examinent les données les plus récentes, ce qui est crucial pour le suivi opérationnel et la prise de décision en temps réel. Cela aide à définir les attentes concernant la récence des insights.
Pourquoi c'est important
Garantit que les utilisateurs sont conscients de la fraîcheur des données, ce qui est crucial pour faire confiance à l'analyse et prendre des décisions opportunes et basées sur les données.
Où obtenir
C'est un champ de métadonnées ajouté pendant le processus d'ingestion des données, reflétant le timestamp de l'achèvement du job ETL.
Exemples
2023-10-27T04:00:00Z
|
|||
|
Système source
SourceSystem
|
Le système d'où proviennent les données. | ||
|
Description
Cet attribut identifie le système source des données, qui dans ce cas est ServiceNow. Il est utile dans les environnements où les données de plusieurs systèmes sont fusionnées pour une vue holistique du processus. Pour une analyse à source unique, cet attribut fournit un contexte important et aide à la gouvernance et à la gestion des données. Il garantit que tout utilisateur comprend l'origine des données qu'il analyse.
Pourquoi c'est important
Fournit des métadonnées essentielles pour la gouvernance des données, la traçabilité et le contexte, en particulier lors de la combinaison de données provenant de plusieurs systèmes d'entreprise.
Où obtenir
Il s'agit généralement d'une valeur statique ajoutée pendant le processus d'extraction et de transformation des données.
Exemples
ServiceNow
|
|||
|
Attribué à
AssignedTo
|
L'utilisateur individuel responsable du traitement de la demande de service à un moment donné. | ||
|
Description
Cet attribut identifie l'agent ou le technicien spécifique assigné à la demande de service. Il change au fur et à mesure que la demande est transférée entre différentes personnes. L'analyse du champ 'Assigned To' est essentielle pour comprendre la répartition de la charge de travail, la performance individuelle et l'impact des passations sur les temps de résolution. Elle aide à répondre aux questions sur l'utilisation des ressources et identifie les opportunités de formation ou de clarification des processus pour réduire les réaffectations.
Pourquoi c'est important
Permet l'analyse de la charge de travail des agents, des performances et des transferts. Il est essentiel pour la gestion des ressources et l'identification des goulots d'étranglement liés à des individus spécifiques.
Où obtenir
Tables ServiceNow Request Item [sc_req_item] ou Catalog Task [sc_task], champ 'assigned_to'.
Exemples
Beth AnglinDavid LooHoward Johnson
|
|||
|
Catégorie
Category
|
La classification principale de la demande de service, telle que Matériel ou Logiciel. | ||
|
Description
La catégorie fournit une classification de haut niveau de la demande de service. Elle est généralement utilisée pour acheminer la demande vers la bonne équipe et pour rendre compte des types de demandes soumises. Dans le Process Mining, la Catégorie est un outil puissant pour le filtrage et l'analyse basée sur les dimensions. Elle permet aux analystes de comparer les flux de processus, les temps de cycle et les taux d'automatisation pour différents types de demandes, révélant des variations qui pourraient ne pas être visibles au niveau agrégé. Par exemple, le processus pour une demande de 'Matériel' peut être fondamentalement différent de celui d'une demande de 'Logiciel'.
Pourquoi c'est important
Permet une segmentation et une comparaison puissantes des processus entre différents types de services, aidant à identifier les problèmes spécifiques à une catégorie et les opportunités d'amélioration.
Où obtenir
Table ServiceNow Request Item [sc_req_item], généralement via la catégorie de l'élément de catalogue [sc_cat_item] associé.
Exemples
HardwareLogicielDemande d'accèsRéseau
|
|||
|
État
State
|
Le statut opérationnel actuel de la demande de service. | ||
|
Description
L'attribut État indique l'étape actuelle de la demande de service dans son cycle de vie, comme 'Ouvert', 'En cours', 'En attente' ou 'Fermé'. Les changements dans ce champ sont souvent utilisés pour générer les activités de la carte de processus. L'analyse de l'État est cruciale pour comprendre combien de temps les demandes passent dans des statuts spécifiques, en particulier les états d'attente ou en suspens. Elle aide à identifier les files d'attente et les retards, tels que le temps passé 'En attente d'informations de l'utilisateur', qui est une source courante de temps de cycle prolongés.
Pourquoi c'est important
Fournit des informations sur le statut de la demande à tout moment, permettant l'analyse des temps d'attente, des files d'attente et de la durée des étapes spécifiques du processus.
Où obtenir
Tables ServiceNow Request [sc_request] ou Request Item [sc_req_item], champ 'state' ou 'stage'.
Exemples
OuvertTravail en CoursEn attente d'informations utilisateurClôturé complet
|
|||
|
Groupe d'assignation
AssignmentGroup
|
L'équipe ou le groupe responsable du traitement de la demande de service. | ||
|
Description
Le Groupe d'assignation représente l'équipe, telle que 'Service Desk', 'Opérations Réseau' ou 'Administration de Base de Données', qui est responsable d'une demande de service à une étape particulière. C'est un attribut clé pour analyser le flux de processus entre différentes zones fonctionnelles. En suivant les changements dans le Groupe d'assignation, les organisations peuvent visualiser les passations entre équipes, mesurer les temps d'attente dans le backlog de chaque groupe et identifier les dépendances ou retards inter-équipes. Ceci est crucial pour optimiser la collaboration interfonctionnelle.
Pourquoi c'est important
Suit la distribution du travail entre les équipes, met en évidence les passations inter-équipes et aide à identifier les goulots d'étranglement ou les problèmes de performance spécifiques à l'équipe.
Où obtenir
Tables ServiceNow Request Item [sc_req_item] ou Catalog Task [sc_task], champ 'assignment_group'.
Exemples
Service DeskSupport IT N2Provisionnement matériel
|
|||
|
Priorité
Priority
|
Le niveau de priorité de la demande de service, qui influence son urgence. | ||
|
Description
La priorité est une classification qui détermine l'importance relative et l'urgence d'une demande de service. Elle est souvent déterminée par une combinaison d'impact et d'urgence et est utilisée pour guider les agents sur les demandes à traiter en premier. L'analyse des données par priorité est essentielle pour comprendre si les demandes à haute priorité sont traitées plus rapidement que celles à basse priorité. Elle permet de filtrer les tableaux de bord pour vérifier si les SLA sont respectés pour les demandes critiques et aide à identifier si le système de priorisation est efficace.
Pourquoi c'est important
Permet la segmentation des demandes pour vérifier que les éléments à haute priorité sont traités plus rapidement. C'est essentiel pour l'analyse des SLA et l'allocation des ressources.
Où obtenir
Tables ServiceNow Request [sc_request] ou Request Item [sc_req_item], champ 'priority'.
Exemples
1 - Critique2 - Élevée3 - Modérée4 - Faible
|
|||
|
SLA respecté
MadeSLA
|
Un indicateur booléen signalant si la demande de service a été résolue dans le respect de son accord de niveau de service (SLA). | ||
|
Description
Cet attribut indique si la demande de service a respecté son Accord de Niveau de Service (SLA) défini pour le temps de résolution. C'est une métrique de résultat critique qui mesure directement la performance du service par rapport aux engagements. L'analyse de ce flag aide à quantifier le KPI du Taux de Conformité aux SLA. Il peut être utilisé comme dimension pour comparer les chemins de processus des demandes conformes aux demandes non conformes, révélant des schémas ou activités courants qui contribuent aux échecs SLA. Ceci est essentiel pour la surveillance proactive des risques et l'amélioration continue du service.
Pourquoi c'est important
Mesure directement la performance par rapport aux engagements de service et permet une analyse des causes profondes des violations de SLA en comparant les cas conformes et non conformes.
Où obtenir
Table ServiceNow Task SLA [task_sla], champ 'has_breached'. La valeur doit être inversée (par exemple, MadeSLA = NOT has_breached).
Exemples
truefaux
|
|||
|
Canal
ContactType
|
La méthode utilisée par le demandeur pour soumettre la demande de service. | ||
|
Description
Le Type de contact, ou canal, spécifie comment la demande de service a été initiée. Les canaux courants incluent le portail de service, l'e-mail, l'appel téléphonique ou l'alerte automatisée. Comprendre le canal est important pour analyser les variations de processus qui peuvent être influencées par la méthode de soumission. Par exemple, les demandes soumises via le portail peuvent être plus structurées et automatisées, conduisant à des temps de traitement plus rapides par rapport à celles soumises par e-mail. Cette analyse aide à promouvoir des canaux plus efficaces.
Pourquoi c'est important
Aide à identifier l'impact des différents canaux de soumission sur l'efficacité des processus, les niveaux d'automatisation et les temps de cycle globaux, orientant les efforts d'optimisation des interactions utilisateur.
Où obtenir
Tables ServiceNow Request [sc_request] ou Interaction [interaction]. Le champ est souvent nommé 'contact_type'.
Exemples
PortailE-mailTéléphoneSelf-service
|
|||
|
Code de Résolution
ResolutionCode
|
Un code qui catégorise la résolution finale de la demande de service. | ||
|
Description
Le Code de résolution est une classification structurée de la manière dont une demande de service a été finalement résolue. Les exemples incluent 'Réalisé par l'automatisation', 'Erreur de l'utilisateur' ou 'N'est plus requis'. Cet attribut est vital pour le dashboard d'analyse des causes profondes des retards. En corrélant les codes de résolution avec des temps de cycle longs ou des taux de retouches élevés, les analystes peuvent identifier les problèmes systémiques. Par exemple, si les demandes avec le code 'Informations incomplètes' sont systématiquement lentes, cela indique un problème dans l'étape initiale de collecte des données.
Pourquoi c'est important
Fournit des données structurées sur les résultats de résolution, permettant l'analyse des causes profondes des retards de processus, des retouches et d'autres inefficacités.
Où obtenir
Table ServiceNow Request Item [sc_req_item] ou une table de tâches associée, le champ est couramment 'close_code' ou 'resolution_code'.
Exemples
Résolu (définitivement)Non Résolu (Non Reproductible)Demande satisfaiteAnnulé par l'utilisateur
|
|||
|
Délai de traitement global
CaseCycleTime
|
Le temps total écoulé entre la création et la clôture finale d'une demande de service. | ||
|
Description
Le temps de cycle du dossier est une métrique calculée qui mesure la durée totale d'une demande de service, de l'horodatage du tout premier événement à l'horodatage du tout dernier événement. Il représente le temps de traitement complet de bout en bout du point de vue du client. Il s'agit d'un indicateur clé de performance (KPI) principal pour l'efficacité globale du processus. Il est utilisé dans les tableaux de bord de haut niveau pour surveiller les performances par rapport aux objectifs et pour analyser les tendances au fil du temps. Il peut être segmenté par des dimensions comme la Catégorie ou la Priorité pour identifier quels types de demandes prennent le plus de temps.
Pourquoi c'est important
C'est un KPI critique qui mesure la performance du processus de bout en bout. Il est essentiel pour le suivi de haut niveau, le benchmarking et l'identification des domaines d'amélioration.
Où obtenir
Calculé en soustrayant le 'Heure de début' minimale du 'Heure de fin' maximale pour chaque
Exemples
2 10:30:000 04:15:2210 00:05:00
|
|||
|
Est Automatisé
IsAutomated
|
Un indicateur qui signale si une activité a été réalisée par un système ou une automatisation. | ||
|
Description
Cet attribut booléen distingue les activités effectuées manuellement par un agent humain de celles exécutées par un système automatisé, tel qu'un workflow ou une intégration. Par exemple, une 'Approbation demandée' peut être automatisée, tandis qu'une 'Demande assignée à l'agent' peut être manuelle. L'analyse de cet attribut est essentielle pour mesurer et augmenter le niveau d'automatisation dans le processus de demande de service. Elle aide à identifier les tâches manuelles les plus chronophages et qui pourraient être candidates à une future automatisation, améliorant ainsi l'efficacité et réduisant les coûts.
Pourquoi c'est important
Permet la mesure des taux d'automatisation et aide à identifier les opportunités d'automatisation des tâches manuelles, conduisant à une efficacité accrue et à une réduction des coûts opérationnels.
Où obtenir
Dérivé en vérifiant si l'utilisateur qui a effectué une action (par exemple, 'sys_updated_by') est un utilisateur système ou d'intégration désigné.
Exemples
truefaux
|
|||
|
Est un retravail
IsRework
|
Un indicateur calculé signalant si une activité est une répétition d'une activité précédente dans le même dossier. | ||
|
Description
Cet indicateur booléen est calculé pour identifier les boucles de retouches au sein d'une demande de service. Il est marqué comme 'vrai' si la même activité s'est déjà produite plus tôt dans le même cas, par exemple, si une demande est attribuée deux fois à la même équipe, ou si des informations sont demandées à l'utilisateur plusieurs fois. Cet attribut est essentiel pour le dashboard des Passations d'agents et des Incidents de retouches et le KPI du Taux de retouches des demandes. Il permet la visualisation et la quantification directes des boucles inefficaces dans le processus, qui sont souvent cachées dans les données agrégées.
Pourquoi c'est important
Signale et quantifie directement les reprises de processus, permettant d'analyser les causes et les impacts des boucles inefficaces qui augmentent les coûts et les temps de cycle.
Où obtenir
Calculé lors de la transformation des données en vérifiant les occurrences précédentes du même nom d'activité dans le même dossier.
Exemples
fauxtrue
|
|||
|
Est une résolution au premier contact
IsFirstPassResolution
|
Un indicateur signalant si la demande a été résolue dès la première tentative, sans aucune réouverture. | ||
|
Description
Cet attribut calculé est un indicateur booléen qui est 'vrai' uniquement si la demande de service a été résolue et clôturée sans jamais être rouverte. C'est un indicateur clé de la qualité et de l'efficacité de la résolution fournie par le service d'assistance. Cette métrique soutient directement le KPI du Taux de résolution au premier contact. Un taux élevé est souhaitable car il indique l'efficacité et un service de haute qualité, conduisant à une meilleure satisfaction client. L'analyse des attributs des cas qui échouent à la résolution au premier contact peut révéler des causes profondes comme une formation insuffisante, une mauvaise documentation ou un diagnostic initial incorrect.
Pourquoi c'est important
Mesure la qualité et l'efficacité du processus de résolution. Un faible taux de résolution au premier contact indique des problèmes sous-jacents qui entraînent des retouches et la frustration des clients.
Où obtenir
Calculé au niveau du dossier. Un dossier est considéré comme une résolution au premier passage si son 'Compteur de réouvertures' est à zéro.
Exemples
truefaux
|
|||
|
Heure de fin
EndTime
|
Le 'timestamp' indiquant quand une activité ou un 'event' a été complété. | ||
|
Description
L'Heure de fin marque la conclusion d'une activité. C'est le timestamp de l'activité suivante dans la séquence, clôturant ainsi la durée de l'actuelle. Cet attribut est essentiel pour calculer le temps que prend chaque étape du processus. En comparant l'Heure de début et l'Heure de fin d'une activité, les analystes peuvent calculer les temps de traitement et les temps d'attente. Ceci est fondamental pour identifier les goulots d'étranglement, mesurer l'efficacité des ressources et surveiller les performances par rapport aux objectifs basés sur le temps.
Pourquoi c'est important
Cet attribut est nécessaire pour calculer la durée de chaque activité, qui est un composant essentiel de l'analyse des performances, de l'identification des goulots d'étranglement et des études d'utilisation des ressources.
Où obtenir
C'est un attribut dérivé, calculé en prenant le 'StartTime' de l'événement suivant dans le cas.
Exemples
2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
|
|||
|
Nombre de réouvertures
ReopenCount
|
Le nombre de fois qu'une demande de service a été rouverte après avoir été résolue. | ||
|
Description
Cet attribut est un compteur qui suit le nombre de fois qu'une demande de service est passée d'un état résolu ou fermé à un état ouvert ou en cours. Un nombre supérieur à zéro indique que la résolution initiale n'a pas été couronnée de succès. Cette métrique est un indicateur direct de retouches et est un composant clé du KPI du Taux de résolution au premier contact. Des nombres élevés de réouvertures suggèrent des problèmes de qualité de résolution, une réalisation incomplète ou une incompréhension des besoins de l'utilisateur, ce qui entraîne une inefficacité des processus et une insatisfaction de l'utilisateur.
Pourquoi c'est important
Quantifie les retouches et la qualité de la résolution. Un nombre élevé de réouvertures indique des inefficacités, de faibles taux de résolution au premier contact et une diminution de la satisfaction client.
Où obtenir
Tables ServiceNow Request [sc_request] ou Request Item [sc_req_item], champ 'reopen_count'.
Exemples
012
|
|||
|
Ouvert par
OpenedBy
|
L'individu qui a initialement soumis la demande de service. | ||
|
Description
Cet attribut identifie l'utilisateur qui a créé la demande de service. Bien que souvent la même personne que celle affectée par la demande, il peut aussi s'agir d'un gestionnaire, d'un délégué ou d'un système automatisé. L'analyse des demandes par l'utilisateur 'Ouvert par' ou leur département aide à identifier des schémas, comme un groupe spécifique d'utilisateurs qui soumettent fréquemment des demandes complexes ou problématiques. Cela peut éclairer des formations ciblées ou souligner le besoin de meilleurs articles de base de connaissances pour encourager le self-service.
Pourquoi c'est important
Aide à analyser les modèles de demandes par utilisateur, département ou rôle, ce qui peut éclairer les initiatives de formation et les améliorations de processus ciblées.
Où obtenir
Table ServiceNow Request [sc_request], champ 'opened_by'.
Exemples
Abel TuterFred LuddyDon Goodliffe
|
|||
|
Score de satisfaction
SatisfactionScore
|
Le score de satisfaction client fourni par le demandeur lors de la clôture. | ||
|
Description
Cet attribut capture le score de satisfaction, souvent sur une échelle de 1 à 5, soumis par l'utilisateur final après la résolution de sa demande de service. C'est une mesure directe de la qualité perçue du service. Ces données sont essentielles pour le dashboard d'analyse d'impact sur la satisfaction client. Elles permettent une corrélation directe entre les métriques de processus, comme le temps de cycle, les retouches et les passations, et l'expérience client finale. Cela aide à prouver la justification commerciale des améliorations de processus en liant l'efficacité opérationnelle aux résultats client.
Pourquoi c'est important
Relie directement les métriques de performance des processus aux résultats pour les clients, aidant à quantifier l'impact des inefficacités des processus sur l'expérience utilisateur.
Où obtenir
Généralement trouvé dans une table Survey [asmt_assessment_instance] liée, qui est elle-même liée à la demande originale.
Exemples
5431
|
|||
|
Temps de traitement
ProcessingTime
|
La durée de temps activement passée à travailler sur une activité spécifique. | ||
|
Description
Le Temps de traitement, également appelé temps actif ou temps de manipulation, est la durée passée à exécuter activement une tâche. Il est calculé comme la différence entre l'heure de fin et l'heure de début d'une activité. Cela contraste avec le temps d'attente, où une demande est inactive. Cette métrique est cruciale pour le dashboard d'analyse des goulots d'étranglement et des files d'attente. En agrégeant les temps de traitement pour chaque type d'activité, les analystes peuvent identifier les étapes qui consomment le plus de ressources et d'efforts. Cela aide à prioriser les initiatives d'amélioration des processus pour se concentrer sur les tâches les plus chronophages.
Pourquoi c'est important
Mesure la durée de travail active pour chaque activité, aidant à identifier les étapes les plus chronophages du processus et à cibler les goulots d'étranglement opérationnels.
Où obtenir
Calculé comme 'Heure de fin' moins 'Heure de début' pour chaque enregistrement d'événement.
Exemples
0 00:05:100 01:14:450 00:09:55
|
|||
Activités de gestion des demandes de service
| Activité | Description | ||
|---|---|---|---|
|
Demande affectée à un agent
|
Cette activité se produit lorsqu'un agent individuel spécifique est assigné pour travailler sur la demande de service. Elle est capturée en surveillant les changements apportés au champ 'Assigned to' de la demande ou de ses tâches de réalisation. | ||
|
Pourquoi c'est important
Ceci est crucial pour mesurer les passations, calculer les charges de travail spécifiques aux agents et analyser les temps d'attente avant qu'un individu ne commence à travailler sur une demande.
Où obtenir
Inférent d'un changement dans le champ assigned_to de la table sc_req_item ou sc_task. L'historique des changements est enregistré dans la table sys_audit.
Capture
Suivre les modifications du champ assigned_to dans sys_audit.
Type d'événement
inferred
|
|||
|
Demande approuvée
|
Cette activité signifie que la demande a été officiellement approuvée et peut passer à l'étape de réalisation. Elle est capturée lorsqu'un approbateur marque l'enregistrement d'approbation associé comme 'approuvé'. | ||
|
Pourquoi c'est important
Cette étape clé marque la transition de la phase d'approbation à la phase de réalisation. L'analyse du temps nécessaire pour atteindre cette étape est cruciale pour comprendre les retards avant la réalisation.
Où obtenir
Inférent du champ d'état de l'enregistrement sysapproval_approver lié passant à 'approved', ce qui déclenche ensuite un changement d'état sur le sc_req_item.
Capture
Identifier le timestamp lorsque sysapproval_approver.state passe à 'approved'.
Type d'événement
inferred
|
|||
|
Demande de service créée
|
Cette activité marque le début du cycle de vie de la demande de service, enregistrée lorsqu'un utilisateur soumet une demande via le catalogue de services. Le système capture ceci comme l'événement de création d'un nouvel enregistrement dans la table sc_req_item (Élément demandé). | ||
|
Pourquoi c'est important
C'est l'événement de début principal du processus. Il est essentiel pour calculer le temps de cycle global et analyser les volumes de demandes et les modèles de soumission.
Où obtenir
C'est un événement explicite capturé à partir du timestamp de création (champ sys_created_on) de l'enregistrement dans la table sc_req_item.
Capture
Utilisez l'horodatage
Type d'événement
explicit
|
|||
|
Demande de service fermée
|
Marque la fin finale et définitive du cycle de vie de la demande de service. Cela se produit généralement automatiquement après une période définie dans l'état 'Resolved', pendant laquelle l'utilisateur peut rouvrir la demande. | ||
|
Pourquoi c'est important
Ceci est l'événement de fin principal réussi pour le processus. Le temps entre 'Resolved' et 'Closed' peut également être analysé pour comprendre les politiques de clôture automatique.
Où obtenir
Inférent de la mise à jour du champ d'état sc_req_item vers un état final fermé, tel que 'Closed Complete'. Ceci est enregistré dans la table sys_audit.
Capture
Identifier l'horodatage lorsque
Type d'événement
inferred
|
|||
|
Demande de service résolue
|
Cette activité indique que l'agent de réalisation a terminé le travail et fourni une solution. Elle est enregistrée lorsque l'état de la demande est mis à jour vers 'Resolved' ou un statut similaire. | ||
|
Pourquoi c'est important
C'est une étape clé qui arrête généralement le chronomètre du SLA. Elle marque la fin du travail de réalisation actif et est un composant clé du calcul du temps de résolution total.
Où obtenir
Inférent de la mise à jour du champ d'état sc_req_item vers 'Resolved' ou un état terminal similaire avant la clôture finale. Le changement est suivi dans la table sys_audit.
Capture
Identifier l'horodatage lorsque
Type d'événement
inferred
|
|||
|
Informations demandées à l'utilisateur
|
Se produit lorsque l'agent de réalisation a besoin de plus d'informations de la part du demandeur initial pour progresser. Ceci est généralement inféré lorsque l'état de la demande est modifié pour une valeur comme 'Awaiting User Info'. | ||
|
Pourquoi c'est important
Cette activité est cruciale pour le dashboard 'Analyse des retards d'information du demandeur', aidant à quantifier le temps perdu en attente d'une saisie externe de l'utilisateur.
Où obtenir
Inférent du champ d'état sc_req_item passant à un statut désigné 'en attente d'informations'. Le changement est enregistré dans la table sys_audit.
Capture
Identifier l'horodatage lorsque
Type d'événement
inferred
|
|||
|
Approbation demandée
|
Représente le point où une demande de service est soumise à l'approbation d'un gestionnaire ou d'un autre approbateur désigné. Ceci est généralement inféré lorsque l'état de la demande passe à 'En attente d'approbation' ou un statut similaire. | ||
|
Pourquoi c'est important
Le suivi des approbations aide à identifier les goulots d'étranglement dans le processus d'approbation et mesure le temps d'attente des demandes d'autorisation avant que la réalisation ne puisse commencer.
Où obtenir
Inférent du champ d'état sc_req_item passant à une valeur d'approbation en attente, ou par la création d'un enregistrement correspondant dans la table sysapproval_approver. Les changements sont enregistrés dans la table sys_audit.
Capture
Identifier l'horodatage lorsque
Type d'événement
inferred
|
|||
|
Demande annulée
|
Cette activité sert d'état terminal pour les demandes annulées avant leur achèvement, soit par l'utilisateur, soit par un agent. Elle est capturée lorsque l'état de la demande est défini sur 'Annulée' ou 'Fermée annulée'. | ||
|
Pourquoi c'est important
Ceci est un événement de fin clé non concluant. L'analyse des raisons pour lesquelles les demandes sont annulées peut fournir des insights sur les besoins des utilisateurs, les inefficacités des processus ou les changements de priorités commerciales.
Où obtenir
Inférent de la mise à jour du champ d'état sc_req_item vers un état final annulé, comme 'Closed Cancelled'. Le changement est enregistré dans la table sys_audit.
Capture
Identifier l'horodatage lorsque
Type d'événement
inferred
|
|||
|
Demande attribuée au groupe
|
Indique que la demande de service a été attribuée à une équipe ou un groupe de réalisation spécifique. Cet événement est inféré en détectant un changement dans le champ du groupe d'assignation sur l'élément de demande ou ses tâches associées. | ||
|
Pourquoi c'est important
Le suivi des attributions de groupe aide à analyser la répartition de la charge de travail entre les équipes et à identifier les retards avant qu'une demande ne soit acheminée vers les bons exécutants.
Où obtenir
Inférent d'un changement dans le champ assignment_group de la table sc_req_item ou sc_task. L'historique des changements est enregistré dans la table sys_audit.
Capture
Suivre les modifications du champ assignment_group dans sys_audit.
Type d'événement
inferred
|
|||
|
Demande rejetée
|
Cette activité représente le résultat où une demande est formellement rejetée pendant la phase d'approbation. C'est un chemin alternatif de clôture et elle est capturée lorsqu'un approbateur marque la demande comme 'rejetée'. | ||
|
Pourquoi c'est important
Le suivi des rejets aide à identifier les demandes invalides ou mal dirigées, les problèmes liés au processus de soumission des demandes, et sert de voie d'exception importante pour l'analyse.
Où obtenir
Inférent du champ d'état de l'enregistrement sysapproval_approver lié passant à 'rejected'. Cela place généralement le sc_req_item parent dans un état fermé et incomplet.
Capture
Identifier le timestamp lorsque sysapproval_approver.state passe à 'rejected'.
Type d'événement
inferred
|
|||
|
Demande rouverte
|
Cette activité capture les cas où une demande précédemment marquée comme résolue est de nouveau mise à l'état ouvert. Ceci est inféré d'un changement d'état de 'Resolved' à 'Work in Progress' ou similaire. | ||
|
Pourquoi c'est important
C'est une mesure directe des retouches et est essentielle pour calculer le KPI du 'Taux de résolution au premier contact'. Des chiffres élevés indiquent une mauvaise qualité de solution ou une résolution incomplète.
Où obtenir
Inférent d'un changement dans le champ d'état sc_req_item, passant d'un état résolu ou fermé à un état ouvert, en cours. Ce changement est enregistré dans sys_audit.
Capture
Détecter le changement d'état de « Résolu » à « En cours » dans
Type d'événement
inferred
|
|||
|
Fournisseur externe engagé
|
Représente la passation d'une demande de service ou d'une de ses tâches à un fournisseur tiers externe pour exécution. Ceci peut être inféré de l'assignation à un groupe spécifique de fournisseur ou d'un flag sur la demande. | ||
|
Pourquoi c'est important
Cette activité permet l'analyse de la performance des fournisseurs et son impact sur le cycle de vie global de la demande, ce qui est crucial pour le dashboard 'Cycle d'engagement des fournisseurs externes'.
Où obtenir
Ceci est généralement inféré. Cela pourrait être basé sur l'attribution du assignment_group à un groupe de fournisseur ou sur l'activation d'un champ flag spécifique sur l'enregistrement sc_req_item ou sc_task.
Capture
Identifier le changement de
Type d'événement
inferred
|
|||
|
Informations fournies par l'utilisateur
|
Cette activité marque le moment où le demandeur a fourni les informations nécessaires. Elle est inférée lorsque la demande sort d'un état 'En attente d'informations de l'utilisateur' pour revenir à un état actif comme 'En cours'. | ||
|
Pourquoi c'est important
Associée à 'Information demandée à l'utilisateur', cette activité permet une mesure précise des retards induits par l'utilisateur et aide à évaluer l'efficacité du processus de communication.
Où obtenir
Inférent du champ d'état sc_req_item passant d'un statut 'en attente d'informations' à un statut actif. Ceci est souvent déclenché par l'ajout d'un commentaire ou la réponse à un e-mail par l'utilisateur.
Capture
Identifier l'horodatage lorsque l'état passe de « En attente d'informations utilisateur » à « En cours ».
Type d'événement
inferred
|
|||
|
Tâche d'exécution créée
|
Représente la création d'un élément de travail ou d'une tâche spécifique nécessaire pour répondre à la demande de service. Ceci est un événement explicite enregistré lorsqu'un nouvel enregistrement est créé dans la table Catalog Task. | ||
|
Pourquoi c'est important
Pour les demandes complexes, l'analyse de la création et de l'achèvement des tâches individuelles offre une vue plus granulaire du processus d'exécution et des points de blocage.
Où obtenir
C'est un événement explicite capturé à partir du timestamp de création (champ sys_created_on) d'un enregistrement dans la table sc_task qui est lié au sc_req_item.
Capture
Utilisez le timestamp sys_created_on des enregistrements sc_task.
Type d'événement
explicit
|
|||