Ordre des Événements

Vue d'ensemble

Le filtre Ordre des Événements identifie les cas en fonction des relations séquentielles entre les activités. Il vous permet de trouver les cas où une activité suit une autre selon des motifs spécifiques : directement (sans activités intermédiaires), éventuellement (à tout moment ultérieur dans le cas), à la même date ou à la même heure. Ce filtre puissant est essentiel pour le contrôle de conformité, l’analyse des variantes de processus et la détection de la présence réelle des séquences d’activités prévues dans vos données de processus.

Le filtre offre quatre types distincts de relations pour répondre à différents besoins d’analyse. Vous pouvez l’utiliser pour vérifier que les séquences requises ont eu lieu (comme « approbation avant paiement »), trouver les cas qui suivent ou violent les procédures standards, ou analyser les relations temporelles entre activités.

Utilisations courantes

Contrôle de conformité : Vérifier que les séquences d’activités requises se produisent dans le bon ordre (par exemple, « Commande d’achat » doit précéder « Réception des marchandises »).
Conformité aux processus : S’assurer que les activités d’approbation précèdent directement les activités d’exécution sans étapes intermédiaires.
Analyse des variantes : Identifier les cas qui suivent des chemins spécifiques du processus en vérifiant si certaines activités suivent éventuellement d’autres.
Investigation des causes profondes : Trouver les cas où des séquences problématiques ont eu lieu (par exemple, « Retouche » suivant « Contrôle qualité »).
Détection d’activités simultanées : Localiser les cas où les activités se sont déroulées au même moment ou à la même date, ce qui peut indiquer des problèmes de qualité de données ou un traitement parallèle.
Gestion des exceptions : Découvrir les cas où des activités d’escalade ont suivi les activités régulières, indiquant des problèmes de processus.

Paramètres

Activity First : La première activité dans la relation de séquence. C’est l’activité qui doit se produire avant la seconde.

Activity Follows : La seconde activité dans la relation de séquence. C’est l’activité qui doit suivre la première selon la méthode de suivi sélectionnée.

Follow Method : Définit le type de relation à vérifier entre les deux activités :

Directly Follows : La seconde activité doit suivre immédiatement la première sans activités intermédiaires
Eventually Follows : La seconde activité doit survenir après la première à n’importe quel moment dans le cas
Same Times : Les deux activités doivent se produire exactement au même instant
Same Dates : Les deux activités doivent se produire à la même date calendaire

Remove Filter : Lorsqu’il n’est pas coché (par défaut), retourne les cas qui correspondent au motif de suivi. Lorsqu’il est coché, retourne les cas qui NE correspondent PAS au motif, inversant ainsi la logique du filtre.

Attribute Name (optionnel) : Spécifie quelle colonne d’attribut d’événement analyser pour les noms d’activité. Si non fourni, utilise la colonne d’activité par défaut de votre journal d’événements.

Compare Attribute Name (optionnel) : Ajoute une contrainte de comparaison d’attribut supplémentaire lors de l’utilisation des méthodes Directly Follows ou Eventually Follows. Cela permet des scénarios de filtrage plus complexes.

Use Date If No Time (optionnel) : Lorsqu’il est coché, utilise le tri basé sur la date pour les activités qui ne possèdent pas d’informations temporelles. Applicable uniquement aux méthodes Directly Follows et Eventually Follows.

Exemples

Exemple 1 : Vérification de Séquence Directe

Scénario : Vous souhaitez trouver toutes les commandes d’achat où la réception des marchandises suit directement la création de la commande, sans activités intermédiaires. Cela aide à identifier les cas les plus fluides et rapides sans complications.

Paramètres :

Activity First : "Create Purchase Order"
Activity Follows : "Goods Receipt"
Follow Method : Directly Follows
Remove Filter : Non coché

Résultat : Retourne uniquement les cas où "Goods Receipt" suit immédiatement "Create Purchase Order" sans activités intermédiaires comme des approbations, modifications ou mises en attente.

Informations : Ces cas représentent le flux idéal du processus. Comparer leurs caractéristiques (fournisseur, département, valeur) avec celles des cas comprenant des étapes supplémentaires révèle quels facteurs favorisent un traitement fluide.

Exemple 2 : Détection de Relation Éventuelle

Scénario : Vous devez vérifier que tous les cas avec une activité de contrôle qualité ont éventuellement atteint l’activité de livraison, quel que soit le nombre d’étapes entre elles.

Paramètres :

Activity First : "Quality Check"
Activity Follows : "Deliver Order"
Follow Method : Eventually Follows
Remove Filter : Non coché

Résultat : Retourne tous les cas où "Deliver Order" est survenu à un moment quelconque après "Quality Check", même s’il y a eu des retouches, approbations ou autres activités entre les deux.

Informations : Cela confirme que les articles contrôlés qualité ont finalement été livrés. Les cas absents de ce filtre peuvent indiquer un traitement incomplet ou des commandes annulées après l’inspection qualité.

Exemple 3 : Détection de Violation de Conformité

Scénario : Vous voulez trouver les cas où le paiement a eu lieu sans approbation préalable, ce qui viole la politique de l’entreprise. L’utilisation du filtre inversé aide à identifier ces cas non conformes.

Paramètres :

Activity First : "Approve Payment"
Activity Follows : "Execute Payment"
Follow Method : Directly Follows
Remove Filter : Coché

Résultat : Retourne les cas où "Execute Payment" ne suit PAS directement "Approve Payment", indiquant des approbations manquantes ou des activités entre l’approbation et le paiement.

Informations : Ces cas représentent des violations potentielles de conformité nécessitant une enquête. Ils peuvent révéler des paiements automatiques, des traitements d’urgence ou des lacunes dans les workflows d’approbation.

Exemple 4 : Analyse d’Activité le Même Jour

Scénario : Vous souhaitez identifier les cas où la création de commande et la livraison ont eu lieu le même jour, ce qui peut indiquer un traitement accéléré ou des problèmes de qualité des données.

Paramètres :

Activity First : "Create Order"
Activity Follows : "Deliver Order"
Follow Method : Same Dates
Remove Filter : Non coché

Résultat : Retourne les cas où les deux activités se sont produites à la même date calendaire, quel que soit le décalage horaire réel.

Informations : Une exécution de commande le même jour peut indiquer :

Des demandes d’expédition express
Des livraisons locales avec traitement rapide
Des commandes d’urgence avec gestion spécifique
D’éventuelles erreurs de timestamp si ce pattern est inattendu

Exemple 5 : Détection de Timestamp Concurent

Scénario : Vous devez trouver les cas où deux systèmes différents ont enregistré des activités avec un timestamp exactement identique, ce qui pourrait indiquer des problèmes de qualité de données ou du traitement par lots.

Paramètres :

Activity First : "System A Update"
Activity Follows : "System B Update"
Follow Method : Same Times
Remove Filter : Non coché

Résultat : Retourne les cas où les deux activités ont des timestamps identiques jusqu’à la seconde.

Informations : Des correspondances exactes de timestamps entre activités différentes peuvent révéler :

Des processus batch automatisés mettant à jour plusieurs systèmes
Des problèmes d’import de données où les timestamps n’ont pas été correctement enregistrés
La nécessité d’une granularité de timestamp plus précise
Des problèmes d’intégration entre systèmes

Exemple 6 : Recherche de Cas Sans Séquences Attendues

Scénario : Vous voulez identifier les cas où une approbation n’a jamais abouti à une exécution, ce qui pourrait indiquer des processus annulés ou bloqués.

Paramètres :

Activity First : "Approve Request"
Activity Follows : "Execute Request"
Follow Method : Eventually Follows
Remove Filter : Coché

Résultat : Retourne les cas où "Execute Request" ne s’est PAS produit après "Approve Request" à aucun moment du cas.

Informations : Ces cas représentent des demandes approuvées jamais exécutées, indiquant potentiellement :

Des approbations annulées
Des cas bloqués après approbation
Des ruptures de processus nécessitant intervention
Des demandes approuvées en attente d’exécution

Résultat

Le filtre retourne un ensemble de données contenant uniquement les cas qui correspondent (ou ne correspondent pas, si Remove Filter est coché) à la relation séquentielle spécifiée. Tous les événements et attributs pour chaque cas sont conservés dans les résultats filtrés. Le nombre de cas en sortie sera généralement inférieur au nombre en entrée, les cas ne répondant pas aux critères étant exclus.

Si aucun cas ne correspond à la relation séquentielle spécifiée, le filtre retourne un ensemble de résultats vide.

Notes techniques

Type de filtre : Filtre au niveau du cas (supprime des cas entiers basés sur les relations d’activité)
Correspondance d’activité : Utilise une correspondance exacte et sensible à la casse des noms d’activité
Logique temporelle : Pour Directly Follows et Eventually Follows, les activités doivent exister dans l’ordre chronologique
Validation : Suggère automatiquement des noms d’activités similaires si les activités spécifiées ne sont pas trouvées
Performance : Optimisé pour une détection efficace des séquences même dans les cas avec beaucoup d’activités
Deux activités requises : Les cas doivent contenir les deux activités spécifiées pour être pris en compte (sauf si logique inversée utilisée)

Cette documentation fait partie de la plateforme mindzieStudio de process mining.