Algorithme d'Ordre des Événements

Vue d'ensemble

L'enrichissement Algorithme d'Ordre des Événements est une configuration au niveau système qui contrôle la manière dont mindzieStudio ordonne les événements au sein de chaque cas lorsque les horodatages manquent de granularité suffisante ou lorsque plusieurs événements partagent le même horodatage. Cet enrichissement est essentiel pour garantir une analyse et une visualisation précises du flux de processus, notamment lorsqu'on traite des sources de données qui enregistrent uniquement les dates sans les heures spécifiques, ou lorsque des événements sont insérés dans le journal après le chargement initial des données.

En fouille de processus, la séquence des activités est fondamentale pour comprendre le comportement du processus, calculer les durées, identifier les goulots d'étranglement et détecter les problèmes de conformité. Cependant, de nombreux systèmes sources enregistrent uniquement la date d’un événement sans l’heure précise, ou plusieurs événements peuvent être consignés avec des horodatages identiques. L'enrichissement Algorithme d'Ordre des Événements fournit des stratégies de tri intelligentes pour établir un ordre cohérent et significatif pour ces événements, garantissant que votre analyse de processus reflète la véritable séquence des opérations.

Cet enrichissement agit au niveau du journal des événements et impacte la manière dont toutes les analyses, visualisations et calculs ultérieurs interprètent les séquences d'événements. Il est généralement configuré une fois au début de votre pipeline d'enrichissements, bien que vous puissiez devoir l’ajuster si vous découvrez que vos données ont des exigences d’ordre spécifiques ou si vous ajoutez de nouvelles sources de données avec des caractéristiques d’horodatage différentes.

Usages Courants

Établir un ordre déterministe des événements lorsque les horodatages du système source n’indiquent pas l’heure de la journée (dates uniquement)
Gérer les importations de données où les événements sont insérés dans le journal avec des horodatages actuels plutôt que les heures réelles des événements
Assurer une séquence d'événements cohérente entre différentes extractions de données et reconstructions de journaux
Améliorer la précision de la visualisation du flux de processus en traitant des données avec des horodatages de faible résolution
Supporter la vérification de conformité en fournissant des séquences prévisibles d'événements pour comparaison avec les modèles attendus
Optimiser les performances en éliminant les opérations de tri inutiles lorsque l’ordre des événements est déjà correct
Gérer les migrations de données anciennes où les événements historiques peuvent être chargés avec des horodatages d’insertion

Paramètres

Order Event Algorithm : Spécifie l'algorithme utilisé pour ordonner les événements au sein de chaque cas. Ce paramètre détermine comment mindzieStudio résout la séquence des événements lorsque les seuls horodatages sont insuffisants pour établir un ordre définitif. Les options disponibles sont :

Insert Date Events Before (Par défaut) : Il s'agit de l'algorithme recommandé pour la plupart des scénarios. Il trie les événements dans chaque cas par horodatage, et lorsque plusieurs événements partagent le même horodatage (notamment lorsque l'horodatage ne contient qu'une date sans heure), il utilise l'attribut Expected Order pour déterminer la séquence. Cet algorithme suppose que les événements avec horodatage date seulement ont été insérés dans le journal a posteriori et doivent être ordonnés à l'aide de métadonnées supplémentaires. L'attribut Expected Order est généralement défini par l'enrichissement Expected Order, qui vous permet de définir la séquence logique des activités dans votre processus. Cette option offre une gestion intelligente des horodatages à précision mixte tout en maintenant de bonnes performances.
Insert Date Events Before (Old) : Version legacy de l'algorithme Insert Date Events Before maintenue pour compatibilité avec d'anciens journaux d'événements. Il implémente la même logique de tri mais utilise un chemin de code plus ancien qui peut présenter des caractéristiques de performance différentes sur de très grands ensembles de données. Utilisez cette option uniquement si vous devez maintenir la cohérence avec des résultats d'analyses historiques ou si vous rencontrez des problèmes spécifiques de compatibilité avec le nouvel algorithme. Pour les nouvelles analyses, l'option standard Insert Date Events Before est préférée.
No Sorting : Cette option désactive entièrement le tri automatique des événements, préservant l’ordre original dans lequel les événements apparaissent dans la source de données. Utilisez ce paramètre lorsque vos données sources ont déjà les événements dans l'ordre chronologique correct et que vous souhaitez maximiser les performances en évitant les opérations de tri inutiles. Ceci est approprié pour les sources de données qui fournissent des horodatages très précis (y compris les millisecondes) et lorsque vous êtes certain que l’ordre d’insertion correspond à l’ordre chronologique. Cependant, soyez prudent avec cette option, car elle peut conduire à des flux de processus incorrects si vos données sources ne garantissent pas un ordre correct. Si vous ajoutez plus tard des événements calculés ou fusionnez des données de plusieurs sources, vous devrez peut-être passer à un algorithme de tri actif.

Exemples

Exemple 1 : Traitement des commandes avec horodatages uniquement dates

Scénario : Un système d'approvisionnement suit les commandes à travers leur approbation, mais le système ERP legacy n'enregistre que la date d’approbation sans les heures spécifiques. Plusieurs étapes d’approbation (chef de département, contrôleur financier, approbation exécutive) peuvent avoir lieu le même jour, mais l’horodatage indique uniquement "2024-03-15" pour ces trois approbations. Sans un ordre correct, la fouille de processus montrerait des séquences aléatoires, rendant impossible l’identification du véritable chemin d’approbation ou le calcul précis des temps de transfert.

Paramètres :

Order Event Algorithm : Insert Date Events Before

Configuration supplémentaire : Avant l’application de cet enrichissement, vous auriez utilisé l’enrichissement Expected Order pour définir que :

L'approbation du chef de département vient toujours en premier
L'approbation du contrôleur financier vient deuxième
L'approbation exécutive vient en dernier

Sortie : Avec Insert Date Events Before sélectionné, les événements partageant l’horodatage "2024-03-15 00:00:00" sont désormais correctement ordonnés :

Case ID	Activité	Horodatage initial	Position triée	Expected Order
PO-1234	Approbation Chef de Département	2024-03-15	1	10
PO-1234	Approbation Contrôleur Financier	2024-03-15	2	20
PO-1234	Approbation Exécutive	2024-03-15	3	30

Le flux de processus montre maintenant correctement la hiérarchie d’approbation, les calculs de durée entre étapes deviennent significatifs, et la vérification de conformité peut valider que la séquence d’approbation attendue a été respectée.

Insights : Cette configuration garantit que même avec des horodatages date uniquement, votre analyse de fouille de processus représente fidèlement la hiérarchie obligatoire d’approbation. Sans cet enrichissement, les trois approbations pourraient apparaître dans un ordre aléatoire selon les cas, obscurcissant les motifs et rendant impossible la détection des cas où les approbations sont hors séquence.

Exemple 2 : Analyse haute performance avec horodatages précis

Scénario : Un système d’exécution de fabrication (MES) enregistre chaque étape de production avec des horodatages à précision milliseconde. Chaque poste de travail enregistre les temps de début et de fin pour des opérations telles que "Matériel Chargé", "Soudure Terminée", "Inspection Qualité", et "Emballage Terminé" avec des horodatages du type "2024-03-15 14:32:18.437". Le volume de données est important (millions d'événements), et vous souhaitez optimiser les performances de l’enrichissement puisque les horodatages fournissent déjà un ordre non ambigu.

Paramètres :

Order Event Algorithm : No Sorting

Sortie : Les événements sont traités dans leur ordre original d’insertion sans tri supplémentaire :

Case ID	Activité	Horodatage	Ordre original préservé
WO-5678	Matériel Chargé	2024-03-15 14:32:18.437	Position 1
WO-5678	Soudure Terminée	2024-03-15 14:35:42.891	Position 2
WO-5678	Inspection Qualité	2024-03-15 14:38:15.234	Position 3
WO-5678	Emballage Terminé	2024-03-15 14:41:03.567	Position 4

Le traitement de l’enrichissement est terminé 15-20% plus rapidement comparé à l’utilisation d’algorithmes de tri actifs, particulièrement visible lors de la régénération de la vue cas après l’application de plusieurs enrichissements.

Insights : Lorsque vos données sources fournissent des horodatages haute qualité et haute précision, désactiver le tri peut améliorer significativement les performances sur de grands ensembles de données sans sacrifier la précision. Ceci est particulièrement utile dans des scénarios de fouille de processus en temps réel ou quasi temps réel où la rapidité d’enrichissement est importante. Cependant, surveillez soigneusement vos flux de processus lors de la première mise en œuvre de ce paramètre pour vous assurer que vos données sources maintiennent vraiment un ordre correct.

Exemple 3 : Migration de données historiques avec horodatages mixtes

Scénario : Une société de services financiers migre 10 ans de données de demande de prêt depuis un système legacy vers une nouvelle plateforme de fouille de processus. Les événements historiques (2015-2020) ont uniquement des horodatages date, tandis que les événements récents (2021-présent) incluent des horodatages précis. De plus, certains événements historiques ont été chargés en masse dans le système actuel et portent des horodatages d’insertion correspondant à la date de migration plutôt qu’aux dates réelles des événements. L’enrichissement Expected Order a été configuré pour définir la séquence standard d’octroi de prêt : Réception de la Demande, Vérification de Crédit, Vérification des Revenus, Revue Souscription, Décision d’Approbation.

Paramètres :

Order Event Algorithm : Insert Date Events Before

Sortie : Pour un cas historique de 2017 :

Case ID	Activité	Horodatage stocké	Date de l'événement	Position triée	Expected Order
LN-9012	Réception Demande	2017-06-12	2017-06-12	1	10
LN-9012	Vérification Crédit	2017-06-12	2017-06-12	2	20
LN-9012	Vérification Revenus	2017-06-13	2017-06-13	3	30
LN-9012	Revue Souscription	2017-06-13	2017-06-13	4	40
LN-9012	Décision Approbation	2017-06-14 10:30:00	2017-06-14	5	50

Pour un cas récent de 2024 :

Case ID	Activité	Horodatage stocké	Position triée
LN-9876	Réception Demande	2024-03-15 09:15:23	1
LN-9876	Vérification Crédit	2024-03-15 09:47:11	2
LN-9876	Vérification Revenus	2024-03-15 14:22:35	3
LN-9876	Revue Souscription	2024-03-16 08:30:12	4
LN-9876	Décision Approbation	2024-03-16 16:45:08	5

Insights : L'algorithme Insert Date Events Before gère parfaitement les scénarios de qualité de données mixtes, en utilisant Expected Order pour ordonner les événements du même jour dans les données historiques tout en s’appuyant sur les horodatages précis pour les données récentes. Cela vous permet d’effectuer une analyse de processus cohérente sur l’ensemble de votre jeu de données quelle que soit la précision des horodatages, facilitant une analyse de tendance précise et une comparaison entre la performance historique et actuelle du processus. L'algorithme détecte automatiquement quand les horodatages ne contiennent pas l’heure et applique la logique d'ordre appropriée.

Exemple 4 : Intégration multi-système

Scénario : Un fournisseur de soins de santé combine les données du parcours patient issues de trois systèmes : un système de planification de rendez-vous (horodatages à la seconde), un système de dossiers médicaux électroniques (EMR) (horodatages uniquement date pour de nombreuses entrées historiques), et un système de facturation (horodatages à la minute). Des événements comme "Rendez-vous Planifié", "Patient Arrivé", "Signes Vitaux Enregistrés", "Consultation Médecin", "Demande de Laboratoire", "Résultats de Laboratoire", "Prescription Émise", et "Facturation Terminée" proviennent de différentes sources avec des précisions d’horodatage variées. L’enrichissement Expected Order définit la séquence typique de la visite patient.

Paramètres :

Order Event Algorithm : Insert Date Events Before

Sortie : Pour une visite patient le 15 mars 2024 :

Case ID	Activité	Système source	Horodatage original	Position triée	Expected Order appliqué
PT-4455	Rendez-vous Planifié	Scheduling	2024-03-10 14:30:00	1	Non (heure précise)
PT-4455	Patient Arrivé	Scheduling	2024-03-15 09:00:00	2	Non (heure précise)
PT-4455	Signes Vitaux Enregistrés	EMR	2024-03-15	3	Oui (date seule, ordre 30)
PT-4455	Consultation Médecin	EMR	2024-03-15	4	Oui (date seule, ordre 40)
PT-4455	Demande de Laboratoire	EMR	2024-03-15	5	Oui (date seule, ordre 50)
PT-4455	Résultats de Laboratoire	EMR	2024-03-15	6	Oui (date seule, ordre 60)
PT-4455	Prescription Émise	EMR	2024-03-15	7	Oui (date seule, ordre 70)
PT-4455	Facturation Terminée	Billing	2024-03-15 17:00	8	Non (heure/minute)

Insights : L’algorithme Insert Date Events Before s’adapte intelligemment aux différentes précisions d’horodatages entre les sources de données intégrées. Il préserve l’ordre chronologique fourni par les horodatages précis tout en utilisant Expected Order pour ordonner les événements provenant de systèmes à résolution d’horodatage moindre. Cela permet une fouille de processus complète de bout en bout à travers des systèmes hétérogènes sans nécessiter de coûteuses améliorations de qualité des données ou d’enrichissement des horodatages au niveau des systèmes sources. Les flux de processus résultants représentent fidèlement les parcours patients, permettant l’analyse des transmissions, temps d’attente et utilisation des ressources.

Exemple 5 : Compatibilité descendante pour analyses historiques

Scénario : Une équipe de fouille de processus analyse les processus de réalisation de commandes depuis trois ans avec une ancienne version de mindzieStudio. Ils ont publié plusieurs rapports, tableaux de bord et indicateurs clés basés sur ces analyses. Après la mise à jour vers une version plus récente de la plateforme, ils remarquent de légères différences dans certains métriques de processus, notamment pour les activités du même jour. L’investigation révèle que l’algorithme d’ordre des événements a été mis à jour avec des améliorations de performance. Pour maintenir la cohérence des rapports historiques et assurer la validité des comparaisons année après année, ils doivent utiliser l’algorithme d’ordre legacy.

Paramètres :

Order Event Algorithm : Insert Date Events Before (Old)

Sortie : Les métriques de processus et diagrammes de flux correspondent exactement aux analyses publiées précédemment :

Analyse actuelle (utilisation de l’algorithme Old) :

Temps moyen de traitement de commande : 4,2 jours
Taux de livraison à temps : 87,3 %
Distribution des variantes de processus correspond à la référence historique
Taux de conformité : 91,2 %

Comparaison avec le Nouvel Algorithme :

Temps moyen de traitement de commande : 4,2 jours (pas de changement, horodatages précis)
Taux de livraison à temps : 87,3 % (pas de changement)
Distribution des variantes de processus : 2 nouvelles variantes rares détectées (0,1 % des cas)
Taux de conformité : 91,0 % (légère baisse due à un ordre plus fin)

Insights : L’option Old assure une continuité pour les initiatives de fouille de processus à long terme où la cohérence avec l’analyse historique est critique. Alors que le nouvel algorithme offre de meilleures performances et un ordre potentiellement plus précis dans certains cas limites, l’ancien algorithme garantit que les KPI établis, références et analyses de tendance restent comparables lors de la transition. Les équipes peuvent utiliser cette option lors d’une période de transition, valider les différences entre algorithmes sur un sous-ensemble de données, puis passer au nouvel algorithme pour les analyses futures une fois les comparaisons de base établies. Cette approche maintient la confiance des parties prenantes tout en permettant la modernisation de la plateforme.

Sortie

L'enrichissement Algorithme d'Ordre des Événements ne crée pas de nouveaux attributs ni ne modifie les valeurs existantes des données. Il configure plutôt un paramètre système qui contrôle comment mindzieStudio ordonne en interne les événements lors de la construction de la vue cas pour l’analyse et la visualisation. L'impact de cet enrichissement est visible dans :

Visualisation du Flux de Processus : Les cartes de processus, l’analyse de variantes et les graphes directement-suivis refléteront les séquences d’événements déterminées par l’algorithme choisi. Les cas comportant des événements au même horodatage afficheront des flux logiques et cohérents plutôt qu’un ordre aléatoire.

Calculs de Durée : Les enrichissements qui calculent le temps entre activités (comme « Durée entre Deux Activités » ou « Durée entre Activité et Début de Cas ») produiront des résultats pertinents car les événements sont dans la bonne séquence. Sans un ordre approprié, les calculs de durée entre événements au même horodatage seraient nuls ou pourraient montrer des durées négatives si les événements apparaissaient dans l’ordre inverse.

Vérification de Conformité : Les enrichissements de conformité qui valident les séquences d’activités par rapport aux modèles attendus identifieront correctement les déviations. Un bon ordre des événements garantit que les violations de conformité reflètent des problèmes réels de processus plutôt que des soucis de qualité de données.

Analyse de Performance : Les enrichissements de catégorisation de performance qui classifient les cas sur la base de seuils de durée ou de critères temporels fonctionneront sur des événements séquencés correctement, assurant des évaluations de performance exactes.

Enrichissements en aval : Tous les enrichissements suivants dans votre pipeline dépendant de l’ordre des événements (position d’activité, relations prédécesseur/successeur, calculs d’étape de cas) fonctionneront correctement selon l’ordre établi par cet enrichissement.

L’enrichissement fonctionne pendant la phase de génération de la vue cas, qui a lieu après le chargement du journal d’événements et chaque fois que des enrichissements sont appliqués. L’impact sur les performances varie selon l’algorithme :

No Sorting offre la meilleure performance en sautant entièrement l’étape de tri
Insert Date Events Before équilibre précision et performance, optimisé pour les ensembles de données modernes
Insert Date Events Before (Old) maintient la compatibilité descendante mais peut être plus lent sur des très gros ensembles

Lorsque vous appliquez cet enrichissement, mindzieStudio régénère la vue cas en utilisant l’algorithme sélectionné. La séquence interne des événements est mise à jour, mais les valeurs originales des horodatages dans vos données restent inchangées. Cela signifie que vous pouvez changer d’algorithme sans modifier vos données sources, vous permettant d’expérimenter différentes stratégies d’ordre pour trouver celle qui représente le mieux la réalité de votre processus.

Voir aussi

Expected Order – Définit la séquence logique des activités dans votre processus, utilisée par les algorithmes Insert Date Events Before pour ordonner les événements au même horodatage
Freeze Log Time – Définit un point de référence fixe pour les calculs basés sur le temps, utile lors de l’analyse de données historiques ou pour réaliser des analyses reproductibles
Shift Activity Time – Ajuste les horodatages par un décalage spécifié, pratique pour corriger des problèmes de fuseau horaire ou aligner des données provenant de sources différentes

Cette documentation fait partie de la plateforme de fouille de processus mindzieStudio.