Durée Entre Deux Attributs d'Événement

Vue d'ensemble

L'enrichissement Durée Entre Deux Attributs d'Événement calcule la différence temporelle entre deux champs de type timestamp ou durée (timespan) au sein d'un même enregistrement d'événement. Cet enrichissement puissant vous permet de mesurer le temps écoulé entre deux points de données temporelles liés qui existent sur des événements individuels, comme le temps entre un rendez-vous programmé et l'arrivée réelle, ou entre la soumission d'une demande et son approbation dans un même enregistrement de transaction.

Contrairement aux enrichissements qui mesurent la durée entre différents événements dans un cas, cet opérateur fonctionne exclusivement au niveau de l'événement, en comparant deux attributs datetime ou timespan déjà présents sur chaque événement. Cela le rend particulièrement utile pour analyser les délais, temps d'attente et métriques de délai de traitement où les horodatages de début et de fin sont capturés comme des champs distincts dans votre système source. L'enrichissement prend en charge à la fois les types DateTime et TimeSpan, offrant une flexibilité maximale pour des scénarios temporels variés.

L'enrichissement crée un nouvel attribut de durée (timespan) au niveau de l'événement contenant la durée calculée, qui peut ensuite être utilisé dans des filtres, visualisations et analyses de performance pour identifier les goulets d'étranglement, mesurer la conformité aux niveaux de service, et comprendre les variations de temps dans vos instances de processus. Le calcul est effectué comme (Attribut Dernier - Attribut Premier), permettant à la fois des durées positives (quand les événements sont en retard) et négatives (quand les événements se terminent tôt ou arrivent avant l'heure prévue).

Usages courants

  • Calculer le retard d'un rendez-vous en mesurant le temps entre l'heure prévue du rendez-vous et l'heure d'arrivée effective du patient dans les processus de santé
  • Mesurer le délai d'approbation en comparant le timestamp de soumission de la requête avec le timestamp d'approbation dans un même enregistrement de transaction
  • Suivre les retards d'expédition en calculant la différence entre la date de livraison promise et la date de livraison réelle
  • Analyser le temps de réponse en mesurant la durée entre le timestamp d'une demande client et le timestamp de la première réponse
  • Évaluer l'adhérence au planning en comparant l'heure de début prévue avec l'heure de début réelle pour les activités de maintenance
  • Mesurer l'efficacité du traitement en calculant le temps entre le timestamp de réception d'un document et le timestamp d'achèvement du traitement
  • Surveiller la conformité aux SLA en mesurant le temps entre la création d'un ticket et la première réponse dans les enregistrements de tickets de support
  • Suivre la variation du planning de production en comparant les temps de début de production prévus et réels

Paramètres

Nom du Nouvel Attribut : Le nom du nouvel attribut événementiel qui stockera la différence de temps calculée. Cet attribut sera créé avec le type de données TimeSpan et apparaîtra dans votre table d'événements aux côtés des autres attributs. Choisissez un nom descriptif qui indique clairement la durée mesurée, par exemple "Délai d'Approbation", "Variations de Livraison", ou "Temps de Traitement". Le nom de l'attribut doit suivre les conventions de nommage de votre organisation et être significatif lorsqu'il est utilisé dans des filtres et visualisations. Ce champ accepte tout nom d'attribut valide et devient l'identifiant pour accéder à la durée calculée dans les étapes d'analyse ultérieures.

Nom de l'Attribut Premier : L'attribut événementiel contenant le timestamp antérieur dans le calcul de durée. Il doit s'agir d'un attribut DateTime ou TimeSpan existant dans votre table d'événements. L'enrichissement l'utilisera comme point de départ pour la mesure de la durée. Par exemple, pour mesurer les retards de rendez-vous, ce serait le champ "Heure de rendez-vous prévue". Le menu déroulant filtre automatiquement pour ne montrer que les attributs DateTime et TimeSpan valides de votre table d'événements, excluant les attributs calculés et cachés. Ceci garantit que vous ne pouvez sélectionner que des données temporelles appropriées pour le calcul.

Nom de l'Attribut Dernier : L'attribut événementiel contenant le timestamp ultérieur dans le calcul de durée. Il doit s'agir d'un attribut DateTime ou TimeSpan existant dans votre table d'événements. L'enrichissement l'utilisera comme point final pour la mesure de la durée. Par exemple, dans le cas de mesure de retard de rendez-vous, ce serait le champ "Heure d'arrivée réelle". Le calcul est effectué comme (Nom de l'Attribut Dernier - Nom de l'Attribut Premier), donc assurez-vous de sélectionner ici le timestamp chronologiquement plus tardif. Les résultats positifs indiquent que le second timestamp survient après le premier (délai ou durée), tandis que les résultats négatifs indiquent que le second est antérieur au premier (fin anticipée).

Exemples

Exemple 1 : Analyse du retard aux rendez-vous médicaux

Scénario: Une clinique médicale souhaite mesurer les retards des patients aux rendez-vous en comparant l'heure prévue du rendez-vous avec l'heure d'arrivée réelle. Les deux timestamps sont enregistrés dans leur système de gestion des rendez-vous comme des champs séparés sur chaque événement rendez-vous. Comprendre ces retards aide à optimiser la planification et améliorer la satisfaction du patient.

Paramètres :

  • Nom du Nouvel Attribut : Délai de Rendez-vous
  • Nom de l'Attribut Premier : Heure prévue
  • Nom de l'Attribut Dernier : Heure d'arrivée réelle

Résultat : L'enrichissement crée un nouvel attribut événementiel appelé "Délai de Rendez-vous" contenant des valeurs TimeSpan représentant la différence entre l'heure prévue et l'heure réelle :

  • Les événements où les patients arrivent en avance auront des durées négatives (par exemple, -00:15:00 pour 15 minutes d'avance)
  • Les événements où les patients arrivent à l'heure auront des durées nulles ou proches de zéro (par exemple, 00:02:00 pour 2 minutes de retard)
  • Les événements où les patients arrivent en retard auront des durées positives (par exemple, 00:45:00 pour 45 minutes de retard)

Exemple de données : | ID Patient | Heure prévue | Heure d'arrivée réelle | Délai de Rendez-vous | |------------|--------------|------------------------|----------------------| | P-1001 | 2024-01-15 09:00 | 2024-01-15 09:12 | 00:12:00 | | P-1002 | 2024-01-15 10:30 | 2024-01-15 10:25 | -00:05:00 | | P-1003 | 2024-01-15 14:00 | 2024-01-15 14:38 | 00:38:00 |

Perspectives : La clinique a découvert que 35 % des patients arrivent plus de 15 minutes en retard pour les rendez-vous de l'après-midi, ce qui entraîne des retards en cascade dans le planning. Ils ont ajusté leur algorithme de planification pour ajouter un temps tampon entre les créneaux de l'après-midi, réduisant le temps d'attente global de 22 %.

Exemple 2 : Délai d'approbation des bons de commande

Scénario: Le service des achats doit mesurer le temps écoulé entre la soumission d'un bon de commande et son approbation. Les deux timestamps existent dans leur système ERP comme des champs séparés sur chaque enregistrement de BC. Suivre ce délai permet d'identifier les goulets d'étranglement d'approbation et garantir des décisions d'achat rapides.

Paramètres :

  • Nom du Nouvel Attribut : Délai d'approbation
  • Nom de l'Attribut Premier : DateHeure Soumission
  • Nom de l'Attribut Dernier : DateHeure Approbation

Résultat : Un nouvel attribut événementiel "Délai d'approbation" est créé montrant le temps écoulé pour chaque approbation de bon de commande :

  • Approbations rapides : 00:15:30 (15 minutes 30 secondes)
  • Approbations standards : 1.08:20:00 (1 jour, 8 heures, 20 minutes)
  • Approbations retardées : 5.14:30:00 (5 jours, 14 heures, 30 minutes)

Exemple de données : | Numéro BC | Montant | DateHeure Soumission | DateHeure Approbation | Délai d'approbation | |-----------|---------|----------------------|----------------------|---------------------| | PO-8821 | 450 $ | 2024-02-10 08:30 | 2024-02-10 09:15 | 00:45:00 | | PO-8822 | 15 200 $ | 2024-02-10 10:00 | 2024-02-12 14:30 | 2.04:30:00 | | PO-8823 | 89 500 $ | 2024-02-10 11:20 | 2024-02-16 09:45 | 5.22:25:00 |

Perspectives : L'analyse a montré que les bons de commande supérieurs à 50 000 \(prennent en moyenne 4,5 jours pour approbation, tandis que ceux en dessous de 1 000\) sont approuvés en moins de 2 heures. L'organisation a mis en place des workflows d'approbation automatisés pour les achats à faible valeur, réduisant le délai d'approbation global de 40 %.

Exemple 3 : Respect du planning de production

Scénario: Une usine suit les heures de début planifiées par rapport aux heures de début réelles des séries de production. Chaque ordre de production contient à la fois l'heure de début prévue et l'heure de début réelle enregistrée dans leur MES (Manufacturing Execution System). Mesurer cette variance aide à identifier la précision de la planification et l'efficacité de la planification des capacités.

Paramètres :

  • Nom du Nouvel Attribut : Variance de l'heure de début
  • Nom de l'Attribut Premier : Heure de début prévue
  • Nom de l'Attribut Dernier : Heure de début réelle

Résultat : L'attribut "Variance de l'heure de début" indique si les productions ont commencé en avance (négatif), à l'heure (proche de zéro) ou en retard (positif) :

  • Les débuts en avance indiquent une capacité disponible ou une flexibilité dans le planning
  • Les débuts en retard révèlent des conflits d'ordonnancement ou des retards en amont
  • Des patterns cohérents permettent d'optimiser la planification de la production

Exemple de données : | Ordre de travail | Ligne de produit | Heure de début prévue | Heure de début réelle | Variance de l'heure de début | |------------------|------------------|-----------------------|-----------------------|------------------------------| | WO-5501 | Ligne A | 2024-03-05 06:00 | 2024-03-05 06:00 | 00:00:00 | | WO-5502 | Ligne B | 2024-03-05 08:00 | 2024-03-05 09:45 | 01:45:00 | | WO-5503 | Ligne C | 2024-03-05 12:00 | 2024-03-05 11:50 | -00:10:00 |

Perspectives : L'usine a identifié que la Ligne B commence systématiquement avec 1 à 2 heures de retard dû à des temps de changement prolongés provenant du quart précédent. En mettant en place des activités de changement en parallèle, ils ont réduit la variance moyenne de l'heure de début de 90 minutes à 15 minutes, augmentant la capacité de production quotidienne de 8 %.

Exemple 4 : Temps de réponse du support client

Scénario: Une organisation de support client doit mesurer la rapidité avec laquelle les agents fournissent la première réponse aux tickets entrants. Leur système de tickets enregistre à la fois le timestamp de création du ticket et celui de la première réponse comme champs séparés. Surveiller ce temps de réponse est essentiel pour la conformité SLA et la satisfaction client.

Paramètres :

  • Nom du Nouvel Attribut : Temps de Première Réponse
  • Nom de l'Attribut Premier : DateHeure Création du ticket
  • Nom de l'Attribut Dernier : DateHeure Première Réponse

Résultat : L'enrichissement produit un attribut "Temps de Première Réponse" indiquant le temps écoulé avant la première réponse pour chaque ticket :

  • Excellente réponse : 00:08:30 (8 minutes 30 secondes)
  • Respect du SLA : 00:55:20 (55 minutes 20 secondes)
  • Violation du SLA : 02:15:45 (2 heures 15 minutes 45 secondes)

Exemple de données : | ID Ticket | Priorité | DateHeure Création | DateHeure Première Réponse | Temps de Première Réponse | |-----------|----------|--------------------|----------------------------|----------------------------| | TKT-9001 | Haute | 2024-04-12 10:22 | 2024-04-12 10:30 | 00:08:00 | | TKT-9002 | Moyenne | 2024-04-12 11:15 | 2024-04-12 12:05 | 00:50:00 | | TKT-9003 | Basse | 2024-04-12 14:30 | 2024-04-12 16:55 | 02:25:00 |

Perspectives : L'équipe support a constaté que les tickets à haute priorité ont en moyenne 12 minutes avant la première réponse, bien en dessous du SLA de 30 minutes, tandis que les tickets à priorité moyenne ont une moyenne de 75 minutes contre un objectif de 60 minutes. Ils ont ajusté leur processus de triage et les niveaux de personnel pour prioriser les tickets à priorité moyenne, améliorant la conformité SLA de 78 % à 94 %.

Exemple 5 : Performance de livraison logistique

Scénario: Une entreprise logistique doit analyser la performance des livraisons en comparant les dates de livraison promises avec les dates de livraison réelles. Les deux dates sont capturées dans leur système de suivi des expéditions au moment de la création de la commande et de la confirmation de livraison. Comprendre la variance de livraison permet d'identifier les problèmes de performance des transporteurs et d'améliorer les attentes clients.

Paramètres :

  • Nom du Nouvel Attribut : Variation de Livraison
  • Nom de l'Attribut Premier : Date de Livraison Promise
  • Nom de l'Attribut Dernier : Date de Livraison Réelle

Résultat : L'attribut "Variation de Livraison" indique si les livraisons ont été en avance (négatif), à l'heure (zéro ou petit positif) ou en retard (positif) :

  • Livraisons anticipées : -1.00:00:00 (1 jour en avance)
  • Livraisons à l'heure : 00:00:00 à 04:00:00 (à l'heure à 4 heures de retard)
  • Livraisons en retard : 2.08:30:00 (2 jours 8 heures 30 minutes de retard)

Exemple de données : | ID Expédition | Transporteur | Livraison Promise | Livraison Réelle | Variation de Livraison | |--------------|--------------|-------------------|------------------|-----------------------| | SHP-7701 | FastShip | 2024-05-20 17:00 | 2024-05-20 15:30 | -01:30:00 | | SHP-7702 | QuickCargo | 2024-05-21 12:00 | 2024-05-21 11:45 | -00:15:00 | | SHP-7703 | StandardPost | 2024-05-22 10:00 | 2024-05-24 14:20 | 2.04:20:00 |

Perspectives : L'analyse a révélé que 18 % des livraisons ont eu plus d'un jour de retard, dont 65 % sont attribuables à StandardPost. L'entreprise a renégocié les niveaux de service avec les transporteurs et mis en place un algorithme dynamique de sélection des transporteurs basé sur la performance historique, réduisant les livraisons tardives de 18 % à 7 % et améliorant les scores de satisfaction client de 15 points.

Résultat

L'enrichissement Durée Entre Deux Attributs d'Événement crée un unique nouvel attribut au niveau de l'événement avec les caractéristiques suivantes :

Type de Données : TimeSpan - Le nouvel attribut stocke des valeurs de durée au format TimeSpan, représentant la différence de temps entre les deux attributs sélectionnés. Les valeurs TimeSpan peuvent être positives (quand le second timestamp est plus tard), négatives (quand le second timestamp est plus tôt) ou nulles (quand les deux horodatages sont identiques).

Emplacement de l'Attribut : Le nouvel attribut est ajouté à la table d'événements et apparaît avec les autres attributs événements dans votre jeu de données. Il est marqué comme un attribut dérivé et sera visible dans les filtres d'événements, les listes d'attributs événements, et peut être agrégé au niveau du cas via des enrichissements statistiques.

Méthode de Calcul : Pour chaque événement, l'enrichissement calcule : (Nom de l'Attribut Dernier - Nom de l'Attribut Premier). Si un des attributs source est nul ou manquant pour un événement donné, le nouvel attribut restera nul pour cet événement, garantissant l'intégrité des données sans créer de fausses valeurs zéro.

Format d'Affichage : Les valeurs TimeSpan sont affichées en format durée standard (jours.heures:minutes:secondes). Par exemple :

  • 00:15:30 représente 15 minutes et 30 secondes
  • 1.08:20:00 représente 1 jour, 8 heures et 20 minutes
  • -00:05:00 représente moins 5 minutes (arrivée anticipée)

Intégration avec d'autres fonctionnalités : L'attribut de durée calculée peut être utilisé de multiples façons :

  • Filtres d'événements : Filtrer les événements selon des seuils de durée (par ex., ne montrer que les événements où le temps de réponse dépasse 1 heure)
  • Agrégations de cas : Utiliser les enrichissements Somme, Moyenne, Min ou Max pour agréger les durées événementielles au niveau cas
  • Analyse de performance : Visualiser les distributions de durée dans des graphiques et identifier les valeurs aberrantes
  • Calculatrices : Référencer la durée dans des expressions de calculateur personnalisées pour une logique métier complexe
  • Vérification de conformité : Définir des règles de conformité basées sur des plages de durée acceptables

Dépendances : L'enrichissement dépend des deux attributs source spécifiés dans la configuration. Si un des attributs source est renommé, caché, ou supprimé du jeu de données, l'attribut durée calculé devra être reconfiguré ou pourra devenir invalide. L'enrichissement suit ces dépendances et avertira les utilisateurs en cas de modification des attributs source.

Considérations de Performance : Cet enrichissement effectue une simple opération de soustraction pour chaque événement et a un impact minimal sur la performance, même sur des jeux de données volumineux avec des millions d'événements. Le calcul est réalisé une seule fois lors de l'exécution de l'enrichissement et les résultats sont stockés, les opérations analytiques ultérieures utilisant les valeurs pré-calculées sans surcharge de recalcul.

Voir aussi

Cette documentation fait partie de la plateforme de process mining mindzie Studio.