Graphes de Suivi

Remarque : Ceci est une calculatrice réservée aux administrateurs, conçue pour les tests et l'analyse de la qualité des données. La plupart des utilisateurs devraient utiliser la calculatrice Carte de Processus pour une analyse visuelle des processus.

Vue d'ensemble

La calculatrice Graphes de Suivi génère des données détaillées sur la manière dont les activités sont liées les unes aux autres dans votre processus. Elle calcule deux types de relations : les relations de suivi direct où une activité suit immédiatement une autre, et les relations de suivi éventuel où une activité survient avant une autre à n'importe quel moment dans le cas, indépendamment des activités intermédiaires.

Contrairement à la calculatrice Carte de Processus qui fournit des visualisations interactives, Graphes de Suivi effectue des calculs complets de graphes et produit des tableaux de données structurées adaptés à une analyse détaillée, aux tests, à l’évaluation des performances et à la validation de la qualité des données. Cette calculatrice est principalement utilisée par les administrateurs et les analystes en fouille de processus qui ont besoin d'accéder aux données brutes du graphe pour une analyse technique ou pour export vers des outils externes.

Usages courants

  • Tester et valider la justesse et la performance des algorithmes de calcul de graphes
  • Évaluer les performances de calcul selon la taille et la complexité des jeux de données
  • Identifier les problèmes de qualité des données lorsque des événements ont des horodatages identiques
  • Exporter des données détaillées du graphe pour analyse externe dans des outils comme R, Python ou Gephi
  • Analyser en détail les distributions de durée pour des paires d’activités spécifiques
  • Valider les algorithmes de fouille de processus lors du développement et des tests de régression

Paramètres

Cette calculatrice ne dispose d’aucun paramètre configurable. Elle traite tous les cas et événements pour générer des données complètes du graphe à chaque exécution.

Exemples

Exemple 1 : Identification de problèmes de qualité des données avec des horodatages identiques

Scénario : Vous suspectez que votre journal d'événements a des problèmes de précision d’horodatage où plusieurs activités ont des horodatages identiques, ce qui rend impossible l’ordre correct. Vous souhaitez identifier les paires d’activités concernées et la fréquence de ces occurrences.

Paramètres :

Aucun paramètre requis.

Sortie :

La calculatrice génère cinq tableaux de données. Les tables 2 et 3 montrent les paires indéterminées où les événements ont des horodatages identiques :

Table DirectlyFollows-Indeterminate :

  • Create Invoice et Send Invoice : 127 occurrences
  • Receive Payment et Record Payment : 89 occurrences
  • Approve Request et Notify Approver : 45 occurrences

La table EventuallyFollows-Indeterminate affiche les mêmes paires plus toute relation eventually-follows avec une durée nulle.

La table Stats montre :

  • Temps de calcul : 2 347 millisecondes
  • Temps de remplissage des tables : 156 millisecondes
  • Total des calculs : 1 247 893

Perspectives : Le nombre élevé de paires indéterminées indique des problèmes importants de précision d’horodatage dans votre journal d’événements. Le problème le plus commun concerne Create Invoice et Send Invoice se produisant exactement au même moment dans 127 cas. Cela suggère que ces événements sont soit enregistrés avec une précision à la date uniquement, soit horodatés simultanément par votre système source. Vous devriez vérifier si ces activités surviennent réellement en même temps ou si votre processus d’extraction des données perd les informations sur l’heure de la journée. Ce problème de qualité des données peut impacter la précision de l’analyse des processus et doit être corrigé en améliorant la précision des horodatages dans les données sources.

Exemple 2 : Évaluation des performances selon la taille des jeux de données

Scénario : Vous optimisez votre infrastructure de fouille de processus et devez comprendre comment les performances du calcul du graphe évoluent avec la taille du jeu de données. Vous souhaitez mesurer le temps de calcul pour différentes volumes afin de planifier les ressources.

Paramètres :

Aucun paramètre requis.

Sortie :

Exécution de la calculatrice sur des jeux de données de taille croissante et examen de la table Stats :

Jeu de données de 10 000 cas :

  • Temps de calcul : 847 millisecondes
  • Total des calculs : 186 234

Jeu de données de 50 000 cas :

  • Temps de calcul : 4 521 millisecondes
  • Total des calculs : 931 170

Jeu de données de 100 000 cas :

  • Temps de calcul : 9 234 millisecondes
  • Total des calculs : 1 862 340

La table DirectlyFollows compte 156 paires d’activités uniques tandis que la table EventuallyFollows en contient 2 847, illustrant la nature exhaustive des relations eventually follows.

Perspectives : Le temps de calcul évolue approximativement de façon linéaire avec le nombre de cas pour ce jeu de données où les cas ont une moyenne constante d’événements. Cependant, le nombre total de calculs montre que le calcul du graphe eventually follows est nettement plus coûteux que celui des graphes directly follows, comme attendu étant donné la complexité quadratique de l’algorithme pour les cas avec beaucoup d’événements. Pour des jeux de données dépassant 100 000 cas, il faudrait envisager de filtrer sur les cas les plus pertinents avant d’exécuter cette calculatrice ou allouer des ressources supplémentaires. Le temps de remplissage des tables reste faible et stable sur tous les volumes, indiquant que la conversion en tables n’est pas un goulet d’étranglement.

Exemple 3 : Exportation des données de processus pour analyse externe en recherche

Scénario : Vous collaborez avec une équipe universitaire qui étudie les algorithmes d’optimisation de processus. Ils ont besoin des données brutes du graphe de processus dans un format standardisé pour tester leur nouvelle approche. Vous souhaitez exporter vos relations de processus avec des statistiques complètes de durée.

Paramètres :

Aucun paramètre requis.

Sortie :

La calculatrice génère la table DirectlyFollows avec 243 paires d’activités uniques :

Extraits des lignes de la table DirectlyFollows :

  • Submit Claim -> Validate Documents : Count=1 847, Mean=2.3 jours, Median=1.8 jours, StDev=3.2 jours
  • Validate Documents -> Approve Claim : Count=1 245, Mean=4.7 jours, Median=3.1 jours, StDev=6.8 jours
  • Validate Documents -> Request Additional Info : Count=602, Mean=1.2 jours, Median=0.9 jours, StDev=2.1 jours

La table EventuallyFollows contient 4 892 paires montrant toutes les relations possibles, y compris non consécutives.

Perspectives : Vous pouvez exporter la table DirectlyFollows au format CSV et la fournir à l’équipe de recherche. La table inclut toutes les informations essentielles pour la fouille de processus : noms des activités, fréquences des relations, et statistiques complètes de durée comprenant moyenne, médiane, écart-type, minimum et maximum. La table EventuallyFollows offre une image encore plus complète des relations d’activité pour les chercheurs étudiant les dépendances à longue distance dans les processus. Le format structuré facilite l’importation dans des outils d’analyse comme R ou Python pour la modélisation statistique.

Exemple 4 : Validation des modifications d’algorithme de fouille de processus

Scénario : Votre équipe de développement a modifié l’algorithme de calcul du graphe pour améliorer la performance. Vous devez vérifier que les changements produisent des résultats identiques à la version précédente afin d’assurer qu’aucune régression n’a eu lieu.

Paramètres :

Aucun paramètre requis.

Sortie :

Exécution des versions ancienne et nouvelle de l’algorithme sur un jeu de test connu avec 5 cas et 11 événements :

Table DirectlyFollows (les deux versions) :

  • 8 paires d’activités uniques
  • Comptages identiques pour chaque paire
  • Statistiques de durée identiques

Table EventuallyFollows (les deux versions) :

  • 28 paires d’activités uniques
  • Tous les comptages correspondent exactement
  • Toutes les statistiques de durée concordent à la précision flottante près

Comparaison de la table Stats :

  • Ancien algorithme : 89 millisecondes
  • Nouvel algorithme : 42 millisecondes
  • Total des calculs : 138 pour les deux

Perspectives : La validation confirme que l’optimisation de l’algorithme a réussi à réduire le temps de calcul de 53 % sans modifier aucun résultat. Toutes les paires d’activités, comptages et statistiques de durée sont strictement identiques entre les versions, prouvant qu’aucune régression n’a eu lieu. Le nombre constant de calculs confirme que les deux algorithmes traitent les mêmes paires d’événements. Ce type de validation est essentiel lors d’améliorations de performance pour garantir la précision. Vous pouvez désormais déployer en toute confiance l’algorithme optimisé en production.

Exemple 5 : Analyse de la variabilité de durée pour des paires d’activités spécifiques

Scénario : Votre équipe des opérations rapporte des temps de traitement incohérents entre les activités de validation et d’approbation de documents. Vous souhaitez des statistiques détaillées de durée pour cette paire d’activités spécifique afin de comprendre la variabilité et identifier s’il existe plusieurs profils distincts.

Paramètres :

Aucun paramètre requis.

Sortie :

Examen de la table DirectlyFollows pour la paire "Validate Documents -> Approve" :

Activity1 : Validate Documents
Activity2 : Approve
Count : 3 247 occurrences
Durée moyenne : 5,8 jours
Durée médiane : 2,3 jours
Écart-type : 12,4 jours
Durée minimum : 0,2 jours
Durée maximum : 87,3 jours

La grande différence entre moyenne et médiane suggère une distribution avec un biais à droite et quelques valeurs extrêmes. L’écart-type élevé indique une variabilité importante.

Perspectives : La différence marquée entre la durée médiane (2,3 jours) et la durée moyenne (5,8 jours) indique que si la plupart des cas sont traités relativement rapidement, un sous-ensemble prend beaucoup plus de temps ce qui tire la moyenne vers le haut. La durée maximale de 87,3 jours montre des valeurs aberrantes extrêmes à investiguer. Le minimum de 0,2 jours suggère que certains cas sont accélérés. Ce profil de variabilité suggère de segmenter les cas pour distinguer les traitements rapides, normaux et lents. Vous pouvez approfondir les données brutes des paires d’événements pour identifier les cas à durées extrêmes et analyser leurs caractéristiques.

Sortie

La calculatrice Graphes de Suivi génère cinq tableaux de données structurées contenant des informations complètes sur le graphe de processus :

Table 0 : DirectlyFollows

Montre toutes les relations de suivi direct où une activité suit immédiatement une autre sans activité intermédiaire.

Colonnes : Key (identifiant de la paire d’activités), Activity1 (première activité), Activity2 (deuxième activité), Count (fréquence), MeanDuration, MedianDuration, StdevDuration, MinDuration, MaxDuration

Cette table contient généralement moins de relations que EventuallyFollows car elle ne comprend que les paires d’activités consécutives.

Table 1 : EventuallyFollows

Montre toutes les relations de suivi éventuel où une activité survient avant une autre à n’importe quel moment dans le cas.

Colonnes : même structure que la table DirectlyFollows

Cette table est beaucoup plus volumineuse car elle inclut toutes les paires possibles d’activités, même avec des activités intermédiaires. Pour un cas avec 10 événements, cela capture 45 paires possibles contre seulement 9 pour le suivi direct.

Table 2 : DirectlyFollows-Indeterminate

Identifie les paires de suivi direct où les événements ont des horodatages identiques, rendant l’ordre indéterminé.

Colonnes : Key (identifiant de la paire non orientée), Activity1, Activity2, Count

Un journal d’événements bien structuré avec des horodatages précis devrait avoir zéro ou très peu de paires indéterminées. Des comptages élevés indiquent des problèmes de qualité de données.

Table 3 : EventuallyFollows-Indeterminate

Identifie les paires de suivi éventuel avec horodatages identiques.

Colonnes : même structure que la table DirectlyFollows-Indeterminate

Contient généralement les mêmes paires que DirectlyFollows-Indeterminate puisque les problèmes d’horodatage affectent les deux types de relations.

Table 4 : Stats

Contient les métriques de performance du calcul.

Colonnes : CalculationTime (millisecondes pour calculer les graphes), FillTablesTime (millisecondes pour convertir en tables), Calculations (nombre total de comparaisons de paires d’événements)

Utilisez cette table pour suivre les performances et identifier quand les jeux de données deviennent trop volumineux pour un traitement efficace.

Options d’exportation de données :

Toutes les tables peuvent être exportées au format CSV ou Excel pour une analyse approfondie dans des outils externes. Le format structuré facilite l’import dans des logiciels statistiques, outils de visualisation de graphes, ou scripts d’analyse personnalisés.


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