Suppression des Activités Répétées

Aperçu

L'enrichissement Suppression des Activités Répétées simplifie votre processus en consolidant les activités consécutives dupliquées en occurrences uniques tout en préservant des informations importantes sur le nombre de fois que chaque activité a été répétée. Cet outil puissant de nettoyage des données est essentiel pour analyser des processus où la même activité peut être exécutée plusieurs fois de suite, que ce soit en raison du comportement du système, des actions des utilisateurs ou de la conception du processus.

Lorsque des activités se répètent consécutivement dans un cas, elles peuvent masquer le véritable flux du processus et rendre difficile l'identification de modèles significatifs. Cet enrichissement élimine le bruit en regroupant les activités répétées tout en créant un attribut de comptage qui suit combien de fois l'activité s'est produite. Vous pouvez également choisir de préserver les valeurs des attributs au niveau des événements des activités répétées en les concaténant, garantissant qu'aucune information critique n'est perdue lors de la consolidation.

L'enrichissement offre deux modes de fonctionnement : répétition consécutive stricte (où les activités doivent se suivre directement) ou répétition flexible (où toutes les instances d'une activité sont regroupées indépendamment des activités intermédiaires). Cette flexibilité vous permet d'adapter l'enrichissement à vos besoins spécifiques d'analyse de processus.

Usages Courants

Simplifier les flux de processus en éliminant les répétitions causées par la logique de nouvelle tentative automatisée
Nettoyer les journaux d'événements où les utilisateurs cliquent plusieurs fois sur des boutons ou actualisent des pages
Consolider les activités de sondage ou de vérification d'état qui se produisent consécutivement
Réduire la complexité du processus lors de l'analyse des activités de surveillance à haute fréquence
Préparer les données pour la découverte de processus en éliminant le bruit répétitif
Suivre le nombre de fois où les activités ont été répétées avant de passer à l'étape suivante
Préserver les valeurs d'attribut des activités répétées via la concaténation pour les pistes d'audit

Paramètres

Activity Name : Sélectionnez l'activité que vous souhaitez consolider lorsqu'elle se répète consécutivement. L'enrichissement identifiera toutes les occurrences où cette activité se produit plusieurs fois et les regroupera en un seul événement. Choisissez des activités connues pour se répéter dans votre processus, telles que les tentatives de nouvelle tentative, les vérifications d'état ou les interactions utilisateur.

Count Column Name : Spécifiez le nom du nouvel attribut qui stockera le nombre de fois que l'activité a été répétée. Cet attribut est automatiquement renseigné avec le nombre d'occurrences consécutives consolidées. Le modèle de nommage par défaut est "[Activity Name]_Count", mais vous pouvez le personnaliser pour correspondre aux conventions de nommage de votre organisation. Par exemple, si vous supprimez des activités répétées de "Payment Retry", vous pourriez nommer cet attribut "Payment_Retry_Attempts".

Concatenate Attributes (Optional) : Sélectionnez un ou plusieurs attributs chaîne au niveau de l'événement dont vous souhaitez préserver les valeurs depuis les activités répétées. Lorsque plusieurs instances sont regroupées, les valeurs de ces attributs seront concaténées avec une séparation par des virgules. Ceci est particulièrement utile lorsque chaque répétition contient des informations contextuelles différentes, telles que des messages d'erreur, des horodatages ou des identifiants utilisateur. Seuls les attributs événement de type chaîne qui ne sont pas calculés et non cachés sont disponibles pour la concaténation.

Must Follow Directly : Contrôlez la manière dont l'enrichissement identifie les activités répétées :

Activé (par défaut) : Ne supprime que les activités qui se produisent consécutivement sans activités intermédiaires. Par exemple, dans la séquence "A, B, B, B, C", il regroupera les trois B consécutifs en un seul. C'est l'approche la plus courante et la plus conservatrice.
Désactivé : Supprime toutes les instances de l'activité sélectionnée dans le cas, en ne conservant que la première occurrence, indépendamment des activités intermédiaires. Par exemple, dans la séquence "A, B, C, B, D, B", il ne conservera que le premier B et supprimera les autres. Utilisez ce mode avec précaution car il modifie fondamentalement le flux du processus.

Exemples

Exemple 1 : Logique de Nouvelle Tentative de Paiement

Scénario : Une plateforme e-commerce dispose d'une logique de nouvelle tentative automatisée pour le traitement des paiements. Lorsque le paiement échoue à cause de problèmes réseau ou d'autorisation temporaire de carte, le système réessaye automatiquement jusqu'à 5 fois avant d'abandonner. Ces tentatives encombrent la carte du processus et rendent difficile la visualisation du parcours réel du client.

Paramètres :

Activity Name : "Process Payment"
Count Column Name : "Payment_Retry_Count"
Concatenate Attributes : "Error_Message", "Gateway_Response"
Must Follow Directly : Activé

Résultat :
L'enrichissement consolide les tentatives consécutives de traitement de paiement en une seule activité "Process Payment" avec un contexte supplémentaire :

Nouvel attribut : "Payment_Retry_Count" contenant des valeurs comme 1 (pas de tentative), 2 (une nouvelle tentative), ou 5 (quatre nouvelles tentatives)
Attribut événement "Error_Message" contenant tous les messages d'erreur concaténés : "Network timeout, Network timeout, Card declined"
Attribut événement "Gateway_Response" contenant toutes les réponses : "503, 503, 402"

Transformation d'un cas type :

Avant : Process Payment (échec) -> Process Payment (échec) -> Process Payment (échec) -> Process Payment (succès)
Après : Process Payment (succès) avec Payment_Retry_Count = 4

Insights : L’entreprise peut maintenant analyser plus précisément les taux de succès des paiements en voyant combien de tentatives étaient nécessaires. Les cas avec un nombre élevé de tentatives peuvent indiquer des problèmes d’intégration avec certaines passerelles de paiement ou des soucis lors des pics de trafic.

Exemple 2 : Vérifications d'État du Service Client

Scénario : Un système de ticketing du service client réalise automatiquement des vérifications d’état du ticket toutes les 5 minutes en attendant une réponse du client. Ces vérifications génèrent des centaines d’événements dans les cas de longue durée, rendant l’analyse du processus quasiment impossible.

Paramètres :

Activity Name : "Check Ticket Status"
Count Column Name : "Status_Check_Count"
Concatenate Attributes : (aucun sélectionné)
Must Follow Directly : Activé

Résultat :
Les activités consécutives de vérification d'état sont consolidées en événements uniques. Un cas qui comprenait 50 vérifications entre "Send Email to Customer" et "Customer Response Received" montre désormais une seule activité "Check Ticket Status" avec Status_Check_Count = 50.

Insights : Les analystes peuvent désormais visualiser le véritable flux d’interaction client sans le bruit généré par le sondage automatisé. Le compteur de vérifications indique la durée moyenne d’attente pour la réponse client, ce qui peut être corrélé avec les temps de résolution et la satisfaction client.

Exemple 3 : Retests de Contrôle Qualité en Fabrication

Scénario : Dans un processus pharmaceutique, les échecs aux inspections qualité déclenchent des retests immédiats jusqu’à 3 fois avant rejet du lot. L’entreprise souhaite suivre combien de retests ont lieu tout en maintenant des flux de processus clairs pour l’analyse.

Paramètres :

Activity Name : "Quality Inspection"
Count Column Name : "Inspection_Attempts"
Concatenate Attributes : "Inspector_ID", "Test_Results", "Failure_Reason"
Must Follow Directly : Activé

Résultat :
Les inspections qualité consécutives sont consolidées avec toutes les informations d’audit :

Inspection_Attempts : nombre de fois que le lot a été inspecté (1-4)
Inspector_ID concaténé : "INSP_001, INSP_001, INSP_002" (montre si différents inspecteurs sont intervenus)
Test_Results concaténé : "FAIL, FAIL, PASS" (montre la progression)
Failure_Reason concaténé : "pH out of range, pH out of range, " (montre les défauts)

Insights : L’entreprise peut analyser les taux de réussite au premier passage (Inspection_Attempts = 1) contre les taux de retouche (Inspection_Attempts > 1) tout en gardant la traçabilité complète de qui a inspecté et pourquoi les tests ont échoué.

Exemple 4 : Réaffectation de Tickets Support IT

Scénario : Un support informatique voit des tickets réassignés plusieurs fois entre agents avant résolution. Chaque réaffectation crée une activité "Reassign Ticket", compliquant l’analyse des étapes réelles de résolution.

Paramètres :

Activity Name : "Reassign Ticket"
Count Column Name : "Reassignment_Count"
Concatenate Attributes : "Assigned_To", "Reassignment_Reason"
Must Follow Directly : Activé

Résultat :
Les réaffectations consécutives sont consolidées :

Reassignment_Count : nombre total de réaffectations (indique les allers-retours du ticket)
Assigned_To concaténé : "Agent_A, Agent_B, Agent_C, Agent_D" (montre le chemin d’escalade)
Reassignment_Reason concaténé : "Wrong department, Requires senior agent, Requires system admin" (montre les raisons)

Insights : Un nombre élevé de réaffectations indique un mauvais routage initial des tickets ou une responsabilité peu claire. Les noms concaténés des agents révèlent les schémas d'escalade communs, aidant à optimiser les règles de distribution des tickets.

Exemple 5 : Révisions du Workflow d'Approbation de Documents

Scénario : Un système de gestion documentaire permet aux relecteurs de renvoyer plusieurs fois un document pour révision. L’organisation souhaite suivre les cycles de révision tout en gardant les cartes de processus concentrées sur le workflow global d’approbation.

Paramètres :

Activity Name : "Request Revisions"
Count Column Name : "Revision_Cycles"
Concatenate Attributes : "Reviewer_Comments"
Must Follow Directly : Activé

Résultat :
Les demandes de révision consécutives sont consolidées :

Revision_Cycles : nombre de fois que le document a été renvoyé (indicateur de qualité)
Reviewer_Comments concaténé : "Fix formatting, Update references, Correct calculations" (historique complet des retours)

Insights : Les documents nécessitant de nombreux cycles de révision peuvent refléter des exigences peu claires ou un contrôle qualité initial insuffisant. Les commentaires concaténés fournissent une piste d’audit complète du processus de relecture tout en gardant la carte de processus claire et exploitable.

Résultat

L'enrichissement Suppression des Activités Répétées modifie votre journal d'événements de deux manières majeures :

Réduction des événements : Les occurrences consécutives de l’activité sélectionnée sont consolidées en un seul événement. L’enrichissement conserve la première occurrence et masque toutes les répétitions suivantes, réduisant ainsi le nombre total d’événements dans votre jeu de données. Cette consolidation se fait au niveau des cas, donc différents cas peuvent voir des nombres différents d’événements supprimés selon leurs motifs de répétition.

Nouvel attribut de comptage : Un nouvel attribut entier au niveau de l’événement est créé avec le nom que vous avez spécifié dans "Count Column Name". Cet attribut est renseigné sur l’événement consolidé avec le nombre total d’occurrences regroupées. Pour les événements sans répétition, la valeur est 1. Pour les événements consolidés, la valeur indique combien de fois l’activité s’est produite consécutivement (par exemple, 4 signifie que l’activité est arrivée 4 fois d’affilée).

Valeurs d’attribut concaténées : Si vous avez sélectionné des attributs à concaténer, les valeurs de tous les événements répétés sont combinées en une chaîne unique séparée par des virgules et stockées dans l’événement consolidé. Cela préserve des informations contextuelles importantes qui peuvent varier entre les répétitions, comme des messages d’erreur, des identifiants utilisateur ou des horodatages. La concaténation s’effectue dans l’ordre chronologique, vous permettant de voir la progression des valeurs au fil des répétitions.

Impact sur la vue des processus : Après avoir appliqué cet enrichissement, vos cartes de processus et variantes afficheront des flux simplifiés sans les boucles répétitives causées par des activités identiques consécutives. Les cas montrant auparavant des boucles comme "A -> B -> B -> B -> C" s’afficheront désormais sous la forme "A -> B -> C", facilitant l’identification de la structure principale du processus. Vous conservez cependant la possibilité d’analyser les motifs de répétition à l’aide de l’attribut de comptage dans les filtres et calculateurs.

Cas d’utilisation de l’attribut de comptage : Le nouvel attribut de comptage peut être utilisé dans :

Filtres : "Afficher uniquement les cas où Payment_Retry_Count > 3" pour trouver les problèmes de traitement de paiements
Calculateurs : Moyenne ou somme du comptage sur les cas pour mesurer les taux de nouvelle tentative globaux
Analyse de performance : Corréler des comptages élevés avec des temps de traitement plus longs
Indicateurs de qualité : Suivre les taux de réussite au premier passage en comptant les événements où count = 1
Visualisations : Créer des histogrammes montrant la répartition des tentatives de nouvelle tentative

Intégrité des données : L’enrichissement maintient une intégrité complète des données en préservant les informations d’horodatage (utilise l’horodatage de la première occurrence) et en permettant la concaténation des valeurs d’attribut importantes. Aucune donnée n’est supprimée définitivement ; les événements répétés sont marqués comme cachés et peuvent être révélés si nécessaire en supprimant l’enrichissement.

Cette documentation fait partie de la plateforme d'exploration de processus mindzieStudio.