Votre modèle de données pour la gestion des demandes de service

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 l'essence 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 points de blocage et les boucles de retraitement inutiles.

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

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.

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 impératif 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 prennent le plus de temps. Des horodatages précis sont indispensables à toute analyse liée à la performance.

Cet horodatage est indispensable pour ordonner correctement les événements et calculer toutes les métriques liées au temps, telles que les temps de cycle et les points de blocage.

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 de l'événement' pour chaque enregistrement d'activité.

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 indispensable pour reconstituer le parcours complet 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 base de toute analyse effectuée sur le processus de gestion des demandes de service.

Cet identifiant est nécessaire pour lier tous les événements d'une demande de service, permettant une vision globale du processus complet.

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

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 la réactualisation 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 indispensable 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.

Indique la la réactualisation des données, ce qui est indispensable à garantir que les analyses sont pertinentes et basées sur des informations à jour.

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).

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 indispensable 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.

Primordial 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.

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.

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 indispensable 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.

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.

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.

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 sert de base à 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.

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.

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

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 facilite 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.

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

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

La priorité de la demande est une classification qui aide les équipes de support à déterminer l'ordre de traitement des demandes. Elle 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 indispensable à 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.

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

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

Le statut de la demande indique l'état de la demande de service à un moment donné de son cycle de vie. Les statuts courants 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 indispensablele 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.

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

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

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.

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

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

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.

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.

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

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 informationsns 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.

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.

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.

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 indispensable 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.

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

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.

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.

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.

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é.

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 dans l'organisation.

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

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

Cet attribut booléen indique si la demande de service n'a pas respecté 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.

Fournit un indicateur clair « what-if »mple pour l'analyse des performances SLA, facilitant le filtrage et le reporting sur les demandes en infraction.

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.