Compte d'Événements

Vue d'ensemble

L'enrichissement Compte d'Événements est un opérateur statistique fondamental qui compte le nombre d'événements dans chaque cas de votre jeu de données de processus. Cet enrichissement fournit des métriques essentielles pour comprendre la complexité des cas, les variations de processus et la répartition de la charge de travail à travers vos processus métier. Contrairement au simple comptage des cas, cet opérateur compte les activités ou événements individuels qui composent chaque cas, vous offrant ainsi des insights sur la granularité des cas et l'intensité du processus.

L'enrichissement Compte d'Événements devient particulièrement puissant lorsqu'il est combiné à des filtres, vous permettant de compter des types spécifiques d'événements ou d'activités répondant à certains critères. Par exemple, vous pouvez compter uniquement les activités manuelles, les événements système ou les activités réalisées par des ressources spécifiques. Ce comptage ciblé permet une analyse sophistiquée des comportements de processus et aide à identifier les cas qui dévient des distributions normales de fréquence des événements.

Usages courants

  • Analyse de la complexité des processus : Mesurer la complexité des cas individuels en comptant leur nombre total d'événements
  • Évaluation de la charge de travail : Identifier les cas avec un nombre d'événements exceptionnellement élevé ou faible pour comprendre la répartition de la charge
  • Contrôle qualité : Compter les événements d'inspection ou de révision pour assurer la conformité aux normes qualité
  • Opportunités d'automatisation : Compter les événements manuels versus automatisés pour identifier le potentiel d'automatisation
  • Étalonnage des performances : Comparer les comptes d'événements entre différents types de cas, régions ou périodes
  • Détection d'exceptions : Identifier les cas atypiques avec des fréquences d'événements anormales pouvant indiquer des problèmes
  • Planification des ressources : Comprendre les volumes d'événements pour mieux allouer ressources et capacités

Paramètres

Filtre : Configuration optionnelle qui permet de compter uniquement les événements spécifiques répondant aux critères définis. En l'absence de filtre, tous les événements de chaque cas sont comptés. Utilisez des filtres pour compter des événements basés sur les noms d'activités, horodatages, ressources ou autres attributs d'événement. Ce paramètre permet une analyse ciblée comme compter uniquement les activités manuelles, les événements d'erreur ou les activités réalisées durant certains shifts.

Nom du nouvel attribut : Le nom du nouvel attribut de cas qui stockera la valeur du compte d'événements. Cet attribut sera ajouté à votre table de cas en tant que champ entier. Choisissez un nom descriptif qui indique clairement quels événements sont comptés, surtout si vous utilisez des filtres. Par exemple, utilisez "Total_Event_Count" pour tous les événements, "Manual_Activity_Count" pour les activités manuelles filtrées ou "Error_Event_Count" pour les événements liés aux erreurs.

Exemples

Exemple 1 : Compte total d'événements dans les commandes d'achat

Scénario : Une équipe d'approvisionnement a besoin de comprendre la complexité de leurs processus de commandes d'achat en comptant le nombre total d'événements dans chaque cas pour identifier quelles commandes nécessitent le plus d'efforts de traitement.

Paramètres :

  • Filtre : Aucun (compte tous les événements)
  • Nom du nouvel attribut : Total_PO_Events

Résultat : L'enrichissement crée un nouvel attribut de cas "Total_PO_Events" contenant des valeurs entières :

  • Commandes standards : 8-12 événements (création, approbation, envoi fournisseur, réception des marchandises, facture, paiement)
  • Commandes complexes : 25-40 événements (multiples approbations, demandes de modification, livraisons partielles, litiges)
  • Commandes urgentes : 5-7 événements (processus simplifié avec moins d'étapes)

Insights : L'analyse révèle que 15% des commandes d'achat ont plus de 25 événements, indiquant un traitement complexe. Ces cas à fort nombre d'événements correspondent à des commandes nécessitant plusieurs négociations fournisseurs et escalades d'approbation, suggérant des opportunités de simplification du processus.

Exemple 2 : Compte des activités manuelles dans les réclamations d'assurance

Scénario : Une compagnie d'assurance souhaite mesurer l'effort manuel impliqué dans le traitement des réclamations en comptant uniquement les activités effectuées par des agents humains, en excluant les événements systèmes automatisés.

Paramètres :

  • Filtre : Activity Type equals "Manual" OR Resource Not equals "System"
  • Nom du nouvel attribut : Manual_Activity_Count

Résultat : L'enrichissement crée "Manual_Activity_Count" avec des valeurs représentant les interactions humaines :

  • Réclamations auto-approuvées : 2-3 activités manuelles (examen initial, approbation finale)
  • Réclamations standards : 6-10 activités manuelles (examen, enquête, ajustement, approbation)
  • Réclamations complexes : 15-25 activités manuelles (multiples examens, enquêtes terrain, négociations)
  • Réclamations frauduleuses : 30+ activités manuelles (enquêtes et cycles d'examen approfondis)

Insights : Les réclamations avec plus de 20 activités manuelles ont des temps de traitement 3 fois plus longs et des coûts 2 fois plus élevés. La mise en place d'une vérification documentaire automatisée pourrait réduire les activités manuelles de 40% pour les cas standards.

Exemple 3 : Suivi des événements d'erreur en production

Scénario : Une usine de fabrication doit compter les défaillances du contrôle qualité et les événements d'erreur dans leur processus de production afin d'identifier les lots problématiques nécessitant une attention accrue.

Paramètres :

  • Filtre : Activity contains "Error" OR Activity contains "Reject" OR Activity contains "Rework"
  • Nom du nouvel attribut : Quality_Issue_Count

Résultat : L'enrichissement génère "Quality_Issue_Count" montrant la fréquence des erreurs par lot de production :

  • Lots haute qualité : 0-1 événement d'erreur
  • Lots standards : 2-4 événements d'erreur (ajustements mineurs)
  • Lots problématiques : 8-15 événements d'erreur (multiples problèmes qualité)
  • Lots échoués : 20+ événements d'erreur (retravail important requis)

Insights : Les lots avec plus de 10 événements d'erreur présentent une corrélation à 90% avec des équipements ou des patterns de shifts spécifiques. Une intervention précoce lorsque le compte d'erreurs dépasse 5 événements prévient 60% des échecs totaux de lots.

Exemple 4 : Compte d'interactions clients dans le service d'assistance

Scénario : Un service d'assistance souhaite mesurer l'intensité des interactions clients en comptant tous les événements où les clients interagissent directement avec le système de support, en excluant les activités de traitement internes.

Paramètres :

  • Filtre : Resource contains "Customer" OR Activity contains "Customer" OR Activity in ["Email Received", "Chat Started", "Call Logged", "Feedback Submitted"]
  • Nom du nouvel attribut : Customer_Touch_Points

Résultat : Crée l'attribut "Customer_Touch_Points" avec des comptes d'interactions :

  • Résolution en self-service : 1-2 interactions (demande initiale uniquement)
  • Support standard : 3-5 interactions (demande, clarification, confirmation de résolution)
  • Problèmes escaladés : 8-12 interactions (multiples suivis et clarifications)
  • Incidents critiques : 15+ interactions (mises à jour et communications continues)

Insights : Les tickets avec plus de 8 interactions clients ont des scores de satisfaction inférieurs de 70%. Une communication proactive après 5 interactions réduit le nombre total d'interactions de 30% et améliore la satisfaction.

Exemple 5 : Compte des vérifications de conformité dans les transactions financières

Scénario : Une banque doit compter le nombre d'activités de conformité et de vérification effectuées sur chaque transaction afin d'assurer le respect des exigences réglementaires et identifier les transactions nécessitant une diligence renforcée.

Paramètres :

  • Filtre : Activity Type equals "Compliance" OR Activity contains "Verify" OR Activity contains "AML" OR Activity contains "KYC"
  • Nom du nouvel attribut : Compliance_Check_Count

Résultat : L'enrichissement produit "Compliance_Check_Count" avec des comptes d'activités de vérification :

  • Transactions standards : 2-3 contrôles de conformité (AML basique, filtrage sanctions)
  • Transactions à haute valeur : 5-8 contrôles de conformité (diligence renforcée)
  • Transferts internationaux : 10-15 contrôles de conformité (vérifications multi-juridictionnelles)
  • Transactions signalées : 20+ contrôles de conformité (protocole d'enquête complet)

Insights : Les transactions avec moins de 2 contrôles de conformité présentent un risque réglementaire. Celles avec plus de 15 contrôles ont un temps de traitement 5 fois plus long mais seulement 2% aboutissent à des problèmes effectifs, suggérant un surcontrôle dans certains cas.

Sortie

L'enrichissement Compte d'Événements crée un seul nouvel attribut entier dans votre table de cas contenant le nombre d'événements pour chaque cas. L'attribut stocke des nombres entiers représentant le nombre total d'événements correspondant à vos critères de filtre (ou tous les événements si aucun filtre n'est appliqué). Cet attribut est de type Int32 avec un format d'affichage "Number" pour un formatage numérique approprié dans les analyses et tableaux de bord.

Le nouvel attribut peut être utilisé immédiatement dans :

  • Filtres : Créez des filtres de cas basés sur des plages de compte d'événements (ex. « Cas à haute complexité » où nombre d'événements > 20)
  • Calculatrices : Utilisez le compte dans des expressions mathématiques, moyennes ou calculs statistiques
  • Catégorisations : Regroupez les cas en catégories de complexité selon des seuils de compte d'événements
  • Visualisations : Affichez la distribution des comptes d'événements dans des histogrammes, boîtes à moustaches ou cartes thermiques
  • Corrélations : Analysez les relations entre les comptes d'événements et d'autres attributs de cas comme durée, coût ou résultat
  • Alertes : Configurez des règles de surveillance basées sur des modèles inhabituels de compte d'événements

L'attribut compte d'événements s'intègre parfaitement avec les autres fonctionnalités de mindzie Studio, vous permettant de le combiner avec les calculs de durée, analyses de coûts et métriques de performance pour une intelligence processus complète.

Voir aussi

  • [[Count Activities]] : Compter des activités spécifiques par nom dans chaque cas
  • [[Case Duration]] : Calculer des métriques basées sur le temps souvent corrélées aux comptes d'événements
  • [[Representative Case Attribute]] : Identifier les motifs les plus fréquents dans les cas à compte d'événements élevé ou faible
  • [[Filter Cases]] : Utiliser les comptes d'événements pour filtrer et segmenter vos données de processus
  • [[Categorize Attribute Values]] : Créer des catégories de comptes d'événements (complexité faible/moyenne/élevée)

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