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

L’attribut Activité décrit une étape ou une action précise effectuée dans le cadre d’une demande de service. Ces activités constituent les étapes successives du processus, par exemple « Demande créée », « Demande attribuée », « Travail en cours » et « Demande clôturée ». Chacune correspond à un moment distinct du parcours de la demande.

L’analyse des activités est au cœur du Process Mining. Elle permet de découvrir et de visualiser le flux réel du processus. En examinant leur séquence et leur fréquence, les analystes peuvent repérer les parcours les plus courants, les écarts par rapport au processus standard, les goulots d’étranglement où les demandes restent bloquées et les boucles de reprise dues à la répétition inutile de certaines étapes.

Cet attribut définit les étapes du processus et permet de découvrir le flux réel, les goulots d’étranglement et les écarts.

Souvent extrait des journaux de changement de statut, des tables d’événements ou des pistes d’audit associées à l’objet de demande de service.

L’heure de début indique la date et l’heure précises auxquelles une activité a commencé. Cet horodatage permet de classer les événements dans l’ordre chronologique et de calculer la durée des activités ainsi que celle du cycle de vie complet du cas. Chaque activité du processus doit avoir une heure de début correspondante pour constituer un journal d’événements exact.

Dans l’analyse des processus, l’heure de début sert à calculer des indicateurs clés, comme le temps de cycle, le temps d’attente entre les activités et leur durée de traitement. Elle permet de représenter le processus dans le temps, de mettre en évidence les retards et de repérer les étapes les plus longues. Des horodatages exacts sont indispensables à toute analyse des performances.

Cet horodatage permet de classer correctement les événements et de calculer les indicateurs liés au temps, notamment les temps de cycle et les goulots d’étranglement.

Il figure dans le journal d’événements ou les tables de pistes d’audit, souvent sous la forme d’une « date de création » ou d’un « horodatage d’événement » pour chaque activité.

L’ID de demande de service est la clé primaire qui identifie chaque demande de manière unique tout au long de son cycle de vie. Il sert d’identifiant de cas et relie les activités, les changements de statut et les attributs associés pour former une instance de processus cohérente.

Dans une analyse de Process Mining, cet ID est indispensable pour reconstituer le parcours complet de chaque demande. En regroupant tous les événements sous un même CaseId, les analystes peuvent visualiser les flux de processus, calculer la durée des cas et repérer les différences de traitement entre les demandes. C’est la base de toute analyse du processus de gestion des demandes de service.

Cet ID est indispensable pour regrouper tous les événements d’une demande de service et obtenir une vue complète du processus, de bout en bout.

On le trouve généralement dans l’en-tête ou dans la table principale des transactions de demandes de service.

La dernière mise à jour des données indique la date et l’heure de l’extraction ou de l’actualisation la plus récente. Elle renseigne les utilisateurs sur l’actualité des données analysées et leur permet de savoir si l’analyse reflète la situation actuelle ou un état antérieur.

Cet attribut est important pour le suivi opérationnel et la création de rapports, car il précise à quel moment les analyses ont été produites. Il aide les utilisateurs à se fier aux données et à prendre des décisions éclairées en tenant compte de leur ancienneté. Par exemple, un Dashboard fondé sur des données mises à jour il y a une semaine ne s’interprète pas comme un Dashboard actualisé il y a une heure.

Indique l’actualité des données, un élément essentiel pour s’assurer que les analyses restent pertinentes et reposent sur des informations à jour.

Il s’agit d’un champ de métadonnées généralement créé et enregistré lors de l’extraction des données (ETL).

L’attribut Système source indique le nom de la plateforme de gestion des services informatiques (ITSM) ou d’une autre application depuis laquelle les données ont été extraites. Dans un environnement comprenant plusieurs systèmes, ce champ permet de distinguer les sources et de retracer clairement l’origine des données.

Bien qu’il ne soit pas directement utilisé dans la plupart des analyses de flux de processus, cet attribut est important pour la gouvernance des données, leur validation et le dépannage. Lorsque les données de plusieurs sources sont réunies, les analystes peuvent segmenter la vue du processus par système et ainsi repérer des différences dans son exécution ou dans la qualité des données entre les plateformes.

Cet attribut est important pour la gouvernance des données et le dépannage. Il précise leur origine, notamment dans les environnements où plusieurs systèmes sont intégrés.

Cette valeur est généralement ajoutée lors de l’extraction des données (ETL) et ne fait pas partie des champs natifs du système source.

L’agent attribué est la personne chargée de traiter la demande de service à un moment donné. Une demande peut être confiée à différents agents au cours de son cycle de vie.

Cet attribut est utile pour analyser les performances et la charge de travail. Il permet aux organisations de mesurer et de comparer les performances des agents, notamment leur délai moyen de résolution et le nombre de demandes traitées. Il sert également à analyser les réattributions entre agents, qui peuvent révéler des problèmes de tri initial, de spécialisation ou de répartition de la charge de travail.

Permet d’analyser les performances de chaque agent, la répartition de la charge de travail et la fréquence des réattributions.

Disponible dans l’enregistrement de la demande de service. Les modifications de ce champ sont souvent consignées dans un journal d’audit ou une table d’historique.

L’échéance du SLA est un horodatage cible calculé selon l’accord de niveau de service associé à la demande. Elle dépend notamment de la priorité et du type de demande, ainsi que de sa date de création, et définit le délai de résolution attendu.

Cet attribut sert de référence pour toute analyse du respect des SLA. En comparant l’heure réelle de résolution à l’échéance du SLA, les organisations peuvent déterminer si la demande a été résolue à temps ou si le SLA n’a pas été respecté. Cet indicateur clé de performance mesure la qualité du service et aide à repérer les problèmes systémiques à l’origine des retards et des manquements.

Cette échéance sert de référence pour mesurer les performances. Elle permet de calculer le taux de respect des SLA et de repérer les demandes pour lesquelles l’échéance n’a pas été tenue.

Il s’agit souvent d’un champ calculé dans l’enregistrement de la demande de service, déterminé par la politique de SLA appliquée.

L’équipe attribuée est le groupe d’assistance chargé de la demande de service. Selon l’expertise requise, les demandes sont souvent transférées entre différentes équipes, par exemple le centre de services de niveau 1, l’équipe réseau ou l’équipe de développement logiciel.

L’analyse des transferts entre équipes est un volet essentiel du Process Mining appliqué à la gestion des services. Cet attribut permet de visualiser ces transferts et de repérer les problèmes de communication ou les retards. Il permet aussi de comparer les performances des équipes, notamment leur efficacité, le volume de demandes traité et leur capacité à résoudre les demandes sans nouvelle escalade.

Permet d’analyser les transferts entre équipes, de repérer les retards et de comparer leurs performances.

Champ standard de l’enregistrement de la demande de service. Les modifications sont consignées dans un journal d’audit.

La priorité de la demande aide les équipes d’assistance à déterminer l’ordre de traitement des demandes. Elle repose généralement sur une combinaison de l’impact de la demande sur l’activité et de son urgence. Les niveaux de priorité courants sont « Low », « Medium », « High » et « Critical ».

Cet attribut est important pour l’analyse des performances et la répartition des ressources. Les analystes peuvent comparer les temps de cycle et le respect des SLA selon les niveaux de priorité afin de vérifier que les demandes prioritaires sont traitées comme il se doit. Ils peuvent également déterminer si les demandes moins prioritaires sont négligées ou si les équipes d’assistance appliquent correctement les règles de priorisation.

Permet de vérifier si les demandes sont traitées en fonction de leur importance pour l’activité et de comprendre l’incidence de leur priorité sur le délai de résolution.

Champ standard généralement présent dans l’enregistrement principal de la demande de service.

Le statut de la demande indique son état à un moment donné de son cycle de vie. Les statuts courants comprennent « New », « In Progress », « Pending », « Resolved » et « Closed ». Cet attribut donne un aperçu de l’avancement de la demande dans le processus global.

L’analyse du statut de la demande est essentielle pour comprendre le flux du processus et les transitions entre les états. Elle permet de filtrer les cas, de repérer les demandes bloquées dans un état particulier et de mesurer le temps passé dans chaque statut. Par exemple, la durée passée par les demandes au statut « Pending » peut révéler des retards liés à l’attente d’informations des utilisateurs ou d’équipes externes.

Permet d’analyser le temps passé par les demandes dans chaque état et de repérer les goulots d’étranglement ou les retards.

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

Le type de service décrit la nature de la demande. Il peut s’agir, par exemple, d’une demande de nouveau matériel ou d’accès à un logiciel, d’une question générale ou d’une demande d’assistance technique. Cette catégorisation facilite l’acheminement de la demande vers l’équipe compétente et permet de comprendre la demande pour chaque type de service.

Dans l’analyse des processus, le type de service constitue un axe de segmentation utile. En filtrant la carte du processus selon les types de service, les organisations peuvent découvrir que certaines demandes suivent des processus très différents, ont des temps de cycle plus longs ou donnent lieu à davantage de reprises. Ces constats permettent de cibler les améliorations sur des catégories de services précises.

Permet de filtrer et de comparer les processus selon les catégories de demandes, afin de repérer les goulots d’étranglement ou les inefficacités propres à chaque type.

Champ standard de l’enregistrement de la demande de service, souvent associé à un catalogue de services.

Le canal de soumission indique comment la demande de service a été créée, par exemple depuis un portail en libre-service, par courriel, par téléphone ou via une API. Les processus associés et les attentes des utilisateurs peuvent varier selon le canal.

L’analyse du processus par canal de soumission peut révéler des différences importantes. Par exemple, les demandes envoyées depuis un portail en libre-service sont parfois mieux structurées et résolues plus rapidement que celles reçues par courriel, qui peuvent nécessiter une saisie manuelle. Cette analyse aide les organisations à promouvoir les canaux les plus efficaces ou à améliorer les processus associés aux autres.

Permet de déterminer si le canal de soumission a une incidence sur l’efficacité du processus, le délai de résolution ou le taux de résolution dès le premier contact.

Champ standard généralement présent dans l’enregistrement de la demande de service.

Le code de résolution permet de classer de manière structurée le résultat d’une demande de service. Il peut s’agir, par exemple, de « Résolu par l’utilisateur », « Matériel remplacé », « Logiciel déployé » ou « Demande en double ». L’agent renseigne généralement cette information lors de la clôture de la demande.

Ces codes sont utiles pour analyser les causes profondes. En étudiant la fréquence des différents codes de résolution, les organisations peuvent repérer les problèmes récurrents, les solutions courantes et les possibilités de créer des articles dans une base de connaissances ou de mettre en place des résolutions automatisées. Par exemple, un grand nombre de résolutions par « Réinitialisation du mot de passe » peut justifier l’investissement dans un outil de réinitialisation en libre-service.

Permet d’analyser les causes profondes en classant les modes de résolution des demandes, afin de repérer les tendances et les pistes d’amélioration préventive.

Champ généralement renseigné manuellement par l’agent lors de la résolution ou de la clôture de la demande de service.

L’heure de fin indique la date et l’heure précises auxquelles une activité s’est achevée. Alors que l’heure de début marque le commencement, l’heure de fin en marque la conclusion et détermine la durée d’une étape du processus. Certains événements, instantanés, n’ont pas d’heure de fin distincte.

Cet attribut permet de calculer la durée de traitement de chaque activité. En soustrayant l’heure de début de l’heure de fin, les analystes mesurent le temps consacré par les agents ou les systèmes à une tâche. Ils peuvent ainsi repérer les activités les plus longues et celles qui pourraient être optimisées ou automatisées.

Permet de calculer la durée de traitement des activités et de repérer les étapes du processus qui prennent le plus de temps.

Il figure dans les tables du journal d’événements ou des pistes d’audit. S’il n’est pas disponible explicitement, il peut être déduit de l’heure de début de l’activité suivante.

Le nombre de réattributions correspond au nombre de fois où une demande de service a été transférée d’un agent ou d’une équipe à un autre. Un nombre élevé peut signaler un mauvais acheminement initial, un manque de connaissances chez les agents ou une répartition des responsabilités peu claire.

Cet indicateur permet de mesurer les inefficacités du processus. Dans le cadre du Process Mining, il quantifie les allers-retours d’une demande entre agents ou équipes. L’analyse des cas ayant fait l’objet de nombreuses réattributions peut révéler des pistes pour améliorer le tri initial, renforcer la formation des agents ou clarifier les responsabilités des équipes afin que les demandes soient acheminées correctement dès le départ.

Indicateur clé des inefficacités du processus. Un nombre élevé de réattributions est souvent associé à des délais de résolution plus longs et à une insatisfaction des utilisateurs.

Cette métrique est calculée en comptant le nombre de modifications des champs « AssignedAgent » ou « AssignedTeam » pour un « CaseId » donné.

Cet attribut indique le service ou l’unité opérationnelle de la personne à l’origine de la demande de service. Il apporte un contexte organisationnel à la demande.

L’analyse des demandes par service peut faire ressortir des besoins, des tendances ou des problèmes propres à certains services. Par exemple, un volume élevé d’un type de demande particulier au service financier peut signaler un besoin de formation ciblée ou d’amélioration du système. Cette analyse permet également de répartir les coûts et de comprendre la demande de services informatiques dans l’ensemble de l’organisation.

Apporte un contexte organisationnel et permet d’analyser les types de demandes et la demande de services par unité opérationnelle.

Cette information provient généralement 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é l’accord de niveau de service défini. Sa valeur est vraie si la demande a été résolue après la date « SlaDueDate », et fausse dans le cas contraire.

Cet attribut simplifie le suivi et l’analyse du respect des SLA. Au lieu de comparer les dates dans chaque requête, il suffit de filtrer et d’agréger cet indicateur. Il s’agit d’une métrique principale des Dashboards consacrés aux performances des SLA, qui permet de repérer rapidement le nombre et la proportion de demandes ne respectant pas les objectifs de service.

Fournit un indicateur simple et clair pour analyser les performances des SLA et filtrer facilement les demandes dont l’échéance n’a pas été respectée.

Cet attribut dérivé est calculé lors de la transformation des données en comparant l’horodatage final de résolution au champ « SlaDueDate ».