Classification de l'Ordre des Activités

Aperçu

L'enrichissement Classification de l'Ordre des Activités analyse automatiquement les horodatages de votre journal d'événements pour identifier les cas où la séquence des activités ne peut pas être déterminée avec certitude en raison des limitations des horodatages. Cet enrichissement de la qualité des données est essentiel pour la précision du process mining, car un ordre d'activités incertain peut conduire à des modèles de processus incorrects, des métriques de performance trompeuses et des résultats non fiables lors du contrôle de conformité.

De nombreux systèmes sources enregistrent uniquement les dates sans composant horaire, ou plusieurs activités partagent le même horodatage exact en raison d'importations de données en masse, de traitements par lots, ou de la granularité limitée des horodatages. Quand des événements au sein d'un cas ont des horodatages identiques (que ce soit la même date ou la même date-heure), la séquence réelle dans laquelle ces activités ont eu lieu devient ambiguë. Cet enrichissement détecte et catégorise automatiquement ces motifs d'incertitude, créant des attributs qui vous permettent d'évaluer la fiabilité de vos résultats de découverte de processus et d'identifier les cas où les hypothèses d'ordre peuvent être incorrectes.

L'enrichissement ne nécessite aucune configuration et effectue une analyse complète des horodatages à la fois au niveau de la date et du temps, catégorisant les motifs d'incertitude en "SameDay" (date enregistrée mais sans composant horaire), "SameTime" (valeurs datetime identiques), ou "SameDayAndTime" (le cas contient les deux motifs). Cela vous permet de comprendre l'étendue et la nature de l'incertitude liée aux horodatages dans votre journal d'événements et de prendre des décisions éclairées concernant les besoins en qualité des données et la fiabilité de l'analyse de processus.

Utilisations Courantes

  • Évaluer la qualité des données avant de réaliser une découverte de processus ou un contrôle de conformité
  • Identifier les cas où les séquences d'activités sont ambiguës à cause des limitations des horodatages
  • Détecter des événements importés en masse ou traités par lots partageant des horodatages identiques
  • Évaluer si la granularité des horodatages dans le système source est suffisante pour l'analyse de processus
  • Signaler les cas nécessitant des hypothèses manuelles sur l'ordre pour une analyse précise
  • Mesurer la prévalence de l'incertitude d'horodatage dans l'ensemble du journal d'événements
  • Filtrer les cas de faible qualité où un ordre incertain compromettrait les résultats d'analyse

Paramètres

Cet enrichissement ne nécessite aucune configuration. Il analyse automatiquement tous les horodatages de votre journal d'événements et crée des attributs complets qui catégorisent les motifs d'incertitude d'horodatage au niveau des événements et des cas. Il vous suffit d’ajouter cet enrichissement à votre workflow pour commencer à analyser la qualité des horodatages.

Exemples

Exemple 1 : Analyse du Parcours Patient dans le Secteur de la Santé

Scénario : Un hôpital analyse le parcours des patients dans son service des urgences mais constate que de nombreuses activités sur une même journée ne comportent pas de composant horaire, ce qui rend impossible la détermination de la séquence réelle des traitements et examens.

Paramètres :
Aucune configuration requise - l'enrichissement détecte automatiquement l'incertitude des horodatages.

Résultat :
L'enrichissement crée les attributs suivants :

Attributs au niveau des événements :

  • OrderUncertainty : TRUE pour les événements dont l’ordre ne peut pas être déterminé avec certitude
  • OrderUncertaintyCategory : "SameDay" pour les événements qui partagent une date avec d'autres événements mais sans composant horaire

Attributs au niveau des cas :

  • UncertainEventOrder : TRUE (ce cas présente un ordre incertain)
  • UncertainEventOrderCount : 8 (huit événements dans ce cas ont un ordre incertain)
  • UncertainEventOrderCategory : "SameDay"

Pour un cas patient avec les événements enregistrés comme suit :

  • 2024-03-15 00:00:00 - Enregistrement du patient
  • 2024-03-15 00:00:00 - Évaluation au triage
  • 2024-03-15 00:00:00 - Prise des signes vitaux
  • 2024-03-15 00:00:00 - Consultation médicale
  • 2024-03-15 14:30:00 - Résultats de laboratoire reçus
  • 2024-03-15 14:30:00 - Décision thérapeutique
  • 2024-03-15 14:30:00 - Administration des médicaments
  • 2024-03-15 18:00:00 - Sortie du patient

Les quatre premiers événements (à 00:00:00) sont marqués comme incertains "SameDay" car ils partagent une date mais le composant horaire est manquant. Les trois événements à 14:30:00 sont marqués "SameTime" car ils ont un datetime identique. Ce cas est donc catégorisé "SameDayAndTime" car il présente les deux motifs.

Enseignements : L'hôpital découvre que 67 % des cas d’urgences ont un ordre d’événements incertain en raison de l’absence de composant horaire dans leur système d’enregistrement. Cela révèle un problème critique de qualité des données à traiter avant de pouvoir réaliser une découverte de processus précise. Ils peuvent désormais filtrer les cas pour n’analyser que ceux avec horodatages complets ou collaborer avec le service informatique pour améliorer la granularité des horodatages dans leurs systèmes sources.

Exemple 2 : Traitement des Transactions Financières

Scénario : Une banque analyse les processus d'approbation des transactions par carte bancaire mais remarque que les transactions traitées par lots partagent souvent des horodatages identiques, rendant impossible la détermination de la séquence réelle des contrôles anti-fraude, des autorisations et des décisions d'approbation.

Paramètres :
Aucune configuration requise.

Résultat :
Pour un cas de transaction traité par lot :

  • 2024-10-15 02:15:33 - Transaction reçue
  • 2024-10-15 02:15:33 - Évaluation du risque de fraude
  • 2024-10-15 02:15:33 - Vérification du plafond de crédit
  • 2024-10-15 02:15:33 - Vérification du commerçant
  • 2024-10-15 02:15:33 - Transaction approuvée
  • 2024-10-15 02:15:34 - Confirmation envoyée

Attributs événements :

  • Cinq premiers événements : OrderUncertainty = TRUE, OrderUncertaintyCategory = "SameTime"
  • Dernier événement : OrderUncertainty = FALSE

Attributs cas :

  • UncertainEventOrder : TRUE
  • UncertainEventOrderCount : 5
  • UncertainEventOrderCategory : "SameTime"

Enseignements : La banque identifie que toutes les transactions traitées par lots (environ 40 % du volume journalier) ont un ordre incertain pour les contrôles critiques de fraude et de crédit. Cette découverte les incite à enquêter pour savoir si leur système de traitement par lots maintient un numéro de séquence interne pouvant être utilisé pour établir l’ordre réel ou si la précision des horodatages dans leur système de journalisation doit être améliorée.

Exemple 3 : Analyse de la Ligne de Production Industrielle

Scénario : Une entreprise manufacturière analyse les flux de production mais constate que les points de contrôle qualité sont enregistrés avec des horodatages uniquement à la date, tandis que les opérations machine disposent d’horodatages précis, créant ainsi des motifs d’incertitude mixtes.

Paramètres :
Aucune configuration requise.

Résultat :
Pour un cas de production :

  • 2024-10-20 08:15:22 - Matière première chargée
  • 2024-10-20 08:18:45 - Usinage démarré
  • 2024-10-20 00:00:00 - Inspection visuelle
  • 2024-10-20 08:45:12 - Usinage terminé
  • 2024-10-20 00:00:00 - Contrôle des dimensions
  • 2024-10-20 00:00:00 - Validation qualité
  • 2024-10-20 09:10:30 - Emballage démarré

Attributs événements :

  • Inspection visuelle, contrôle des dimensions, validation qualité : OrderUncertainty = TRUE, OrderUncertaintyCategory = "SameDay"
  • Autres événements : OrderUncertainty = FALSE

Attributs cas :

  • UncertainEventOrder : TRUE
  • UncertainEventOrderCount : 3
  • UncertainEventOrderCategory : "SameDay"

Enseignements : L’entreprise découvre que son système manuel de contrôle qualité enregistre uniquement les dates tandis que les opérations automatisées capturent des horodatages précis. Cette précision mixte empêche de savoir si les contrôles qualité ont eu lieu dans la séquence documentée ou si parfois les contrôles dimensionnels précèdent les inspections visuelles. Ils peuvent désormais prioriser la mise à niveau de leur système de journalisation qualité ou adapter l’analyse de processus pour tenir compte de cette incertitude.

Exemple 4 : Exécution des Commandes en E-commerce

Scénario : Un distributeur en ligne analyse les flux de traitement des commandes mais remarque que les événements du système de gestion d’entrepôt partagent souvent des horodatages identiques en raison des opérations de scan très rapides dépassant la précision d’une seconde du système.

Paramètres :
Aucune configuration requise.

Résultat :
Pour une commande exécutée rapidement :

  • 2024-10-21 10:23:45 - Commande reçue
  • 2024-10-21 10:24:18 - Inventaire alloué
  • 2024-10-21 10:24:18 - Liste de picking générée
  • 2024-10-21 10:24:18 - Articles prélevés
  • 2024-10-21 10:24:18 - Qualité vérifiée
  • 2024-10-21 10:24:18 - Emballage terminé
  • 2024-10-21 10:25:03 - Étiquette d’expédition créée

Attributs événements :

  • Cinq événements à 10:24:18 : OrderUncertainty = TRUE, OrderUncertaintyCategory = "SameTime"

Attributs cas :

  • UncertainEventOrder : TRUE
  • UncertainEventOrderCount : 5
  • UncertainEventOrderCategory : "SameTime"

Enseignements : Le distributeur découvre que ses opérations d’entrepôt sont si efficaces que plusieurs étapes se produisent dans une même seconde, mais la précision du système d’horodatage est insuffisante pour capter la véritable séquence. Ils constatent que 25 % des commandes ont un ordre incertain pour les activités d’entrepôt. Cela les encourage à envisager d’ajouter une précision au sous-seconde dans leur système ou d’implémenter des numéros de séquence pour les événements survenant dans la même seconde.

Exemple 5 : Résolution des Tickets du Service Informatique

Scénario : Un département informatique analyse les processus de résolution des tickets de support mais constate que les mises à jour de statut en masse et les actions automatisées du système partagent souvent les mêmes horodatages, créant une incertitude sur la séquence réelle des étapes de dépannage.

Paramètres :
Aucune configuration requise.

Résultat :
Pour un cas de ticket support :

  • 2024-10-18 09:15:00 - Ticket créé
  • 2024-10-18 09:15:00 - Attribution automatique à une équipe
  • 2024-10-18 09:15:00 - Priorité définie
  • 2024-10-18 09:15:00 - Démarrage du compteur SLA
  • 2024-10-18 10:30:22 - Ingénieur assigné
  • 2024-10-18 00:00:00 - Enquête initiale
  • 2024-10-18 00:00:00 - Identification de la cause racine
  • 2024-10-18 00:00:00 - Résolution appliquée
  • 2024-10-18 14:45:10 - Ticket fermé

Attributs événements :

  • Quatre premiers événements : OrderUncertainty = TRUE, OrderUncertaintyCategory = "SameTime"
  • Trois événements suivants : OrderUncertainty = TRUE, OrderUncertaintyCategory = "SameDay"

Attributs cas :

  • UncertainEventOrder : TRUE
  • UncertainEventOrderCount : 7
  • UncertainEventOrderCategory : "SameDayAndTime"

Enseignements : Le département informatique découvre que les étapes automatisées de création de ticket partagent toutes le même horodatage, et que les activités d’enquête sont consignées avec une précision limitée à la date. Ce motif d’incertitude mixte concerne 55 % des tickets et révèle que leurs résultats de process mining peuvent présenter des séquences d’activités incorrectes. Ils peuvent désormais collaborer avec leur fournisseur de système de gestion de services IT pour améliorer la granularité des horodatages et obtenir des résultats de découverte de processus plus fiables.

Résultat

L'enrichissement Classification de l'Ordre des Activités crée des attributs complets aux niveaux événement et cas pour permettre une analyse détaillée de l’incertitude des horodatages dans vos données de processus.

Attributs au Niveau Événement :

OrderUncertainty (Booléen) : Indique si cet événement spécifique présente un ordre incertain par rapport aux autres événements du même cas. Défini à TRUE lorsque l'événement partage un horodatage identique (date seule ou datetime complet) avec au moins un autre événement du cas, rendant la séquence ambiguë. Défini à FALSE lorsque l'événement a un horodatage unique dans le cas.

OrderUncertaintyCategory (Texte) : Catégorise le type d'incertitude d'horodatage pour cet événement :

  • "SameDay" : L'événement partage une date avec d'autres événements mais n'a pas de composant horaire (horodatage se terminant par 00:00:00), indiquant une précision à la date seule dans le système source
  • "SameTime" : L'événement a un datetime identique (composant temps inclus) avec d'autres événements, indiquant soit une exécution simultanée, soit une granularité insuffisante des horodatages
  • "SameDayAndTime" : L'événement présente les deux motifs (initialement signalé comme SameDay, puis également comme SameTime)

Attributs au Niveau Cas :

UncertainEventOrder (Booléen) : Indique si ce cas contient un ou plusieurs événements avec un ordre incertain. Défini à TRUE s’il existe au moins un événement dans le cas avec un ordre ambigu dû à la duplication d'horodatage. Défini à FALSE uniquement lorsque tous les événements du cas ont des horodatages uniques et que la séquence peut être déterminée avec certitude.

UncertainEventOrderCount (Entier) : Nombre total d'événements dans ce cas présentant un ordre incertain. Ce compte vous aide à évaluer la sévérité de l’incertitude des horodatages — un cas avec deux événements incertains est moins problématique qu'un cas avec des dizaines d'événements partageant le même horodatage.

UncertainEventOrderCategory (Texte) : Résume le motif d’incertitude des horodatages pour l’ensemble du cas :

  • "SameDay" : Le cas contient uniquement une incertitude au niveau date (certains événements partagent des dates sans composant horaire)
  • "SameTime" : Le cas contient uniquement une incertitude au niveau temps (certains événements partagent des datetime identiques)
  • "SameDayAndTime" : Le cas contient les deux motifs d’incertitude

Détails sur le Type de Données :

  • Les attributs booléens utilisent les valeurs TRUE/FALSE et peuvent être utilisés dans des filtres avec les conditions "égal à TRUE" ou "égal à FALSE"
  • Les attributs entiers peuvent être utilisés dans des filtres de plage et des calculs pour mesurer la prévalence de l’incertitude
  • Les attributs texte peuvent être regroupés et filtrés pour analyser séparément les différents motifs d’incertitude

Utilisation dans l’Analyse :
Ces attributs permettent de filtrer votre jeu de données pour exclure les cas à ordre incertain, créer des métriques montrant le pourcentage de cas affectés par l’incertitude des horodatages, identifier les systèmes sources ou les processus présentant la pire qualité d'horodatage, et prioriser les améliorations de qualité des données basées sur l’impact sur vos résultats de process mining. Les attributs s’intègrent parfaitement aux fonctionnalités de contrôle de conformité, découverte de processus et analyse de performance dans mindzieStudio.

Voir Aussi

  • Allowed Case End Activities - Enrichissement de conformité nécessitant un ordre d’activités fiable
  • Allowed Case Start Activities - Enrichissement de conformité affecté par les horodatages incertains du premier événement
  • Duration Between Two Activities - Enrichissement de performance produisant des résultats non fiables lorsque l’ordre des activités est incertain
  • Freeze Log Time - Enrichissement de nettoyage des données pouvant normaliser les horodatages pour améliorer la cohérence

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