Matrice Attribut-Activité
Vue d'ensemble
Le calculateur Matrice Attribut-Activité fournit une table de correspondance complète montrant la relation entre les attributs et les activités dans votre journal d'événements. Pour chaque combinaison d'attribut et d'activité, il affiche le nombre de cas qui ont des valeurs, aidant ainsi les administrateurs à comprendre les schémas de complétude des données et à identifier les problèmes de qualité des données.
IMPORTANT : Il s'agit d'un calculateur réservé aux administrateurs, conçu pour l'analyse technique et l'évaluation de la qualité des données. Il génère une matrice montrant comment les attributs sont renseignés à travers différentes activités, ce qui est essentiel pour comprendre les schémas d'extraction des données, identifier les données manquantes et valider la structure du journal d'événements.
Ce calculateur est principalement utilisé par les administrateurs système et les spécialistes de la qualité des données qui ont besoin de comprendre les schémas de population des attributs à travers les activités du processus pour le dépannage, la validation ou l'optimisation des ensembles de données.
Utilisations courantes
- Identifier quelles activités renseignent quels attributs pour comprendre le flux de données dans le processus
- Détecter les valeurs d'attribut manquantes pour des activités spécifiques qui devraient contenir des données
- Valider que les attributs critiques sont renseignés aux étapes attendues du processus
- Diagnostiquer les problèmes d'extraction des données en identifiant les lacunes systématiques dans la population des attributs
- Comprendre les dépendances des attributs à certaines activités pour la conception ETL
- Documenter quelles activités contribuent aux données de quels attributs pour les spécifications techniques
Paramètres
Ce calculateur ne nécessite aucune configuration spécifique. Lors de son exécution, il génère automatiquement une matrice affichant tous les attributs (au niveau du cas et au niveau des événements) en ligne contre toutes les activités en colonne, avec les valeurs dans les cellules indiquant le nombre de cas où cet attribut a une valeur pour cette activité.
Remarque : Pour les ensembles de données avec beaucoup d’attributs et d’activités, cette matrice peut être très grande. Le calculateur affiche la matrice complète, ce qui peut nécessiter un défilement pour examiner toutes les combinaisons.
Exemples
Exemple 1 : Validation de la complétude des données d'approbation
Scénario : Vous avez mis en place un nouveau système de suivi des approbations et vous devez vérifier que les attributs liés à l'approbation sont correctement renseignés à chaque étape d'approbation dans votre processus de commande d'achat.
Paramètres :
- Titre : "Analyse de la population des attributs d'approbation"
- Description : "Valider la capture des données d'approbation dans le processus P2P"
Sortie :
Le calculateur affiche une matrice avec les activités en colonnes et les attributs en lignes. Pour les attributs liés à l'approbation, vous observez :
| Attribut | Créer PO | Soumettre pour approbation | Approbation L1 | Approbation L2 | Approbation Finance | Envoyer au fournisseur |
|---|---|---|---|---|---|---|
| ApproverName | 0 | 0 | 1 847 | 456 | 234 | 0 |
| ApprovalLevel | 0 | 0 | 1 847 | 456 | 234 | 0 |
| ApprovalTimestamp | 0 | 0 | 1 847 | 456 | 234 | 0 |
| ApprovalComments | 0 | 0 | 1 523 | 398 | 189 | 0 |
| DelegatedBy | 0 | 0 | 234 | 67 | 23 | 0 |
Observations : La matrice confirme que les attributs d'approbation sont correctement renseignés uniquement lors des activités d'approbation (L1, L2 et approbation finance), avec une population nulle lors des autres activités comme prévu. Les 1 847 cas atteignant l'approbation L1 ont les attributs ApproverName, ApprovalLevel et ApprovalTimestamp remplis, indiquant une capture complète des données. Cependant, ApprovalComments affiche une population plus faible (1 523 cas au lieu de 1 847 à L1), révélant que 324 cas manquent de commentaires d'approbation – ce qui peut être acceptable si les commentaires sont optionnels, mais mérite une enquête. L'attribut DelegatedBy apparaît uniquement pour un sous-ensemble d'approbations, capturant correctement les scénarios de délégation.
Exemple 2 : Identification des lacunes dans l'extraction des données
Scénario : Après avoir fusionné des données issues de plusieurs systèmes sources dans votre processus order-to-cash, vous suspectez que certains attributs ne sont pas renseignés de manière cohérente sur toutes les activités attendues.
Paramètres :
- Titre : "Vérification de la complétude des données multi-sources"
- Description : "Valider la population des attributs issus des systèmes CRM, ERP et expédition"
Sortie :
| Attribut | Créer commande | Vérification crédit | Préparer articles | Emballer articles | Expédier | Générer facture | Recevoir paiement |
|---|---|---|---|---|---|---|---|
| CustomerName | 2 456 | 2 456 | 2 456 | 2 456 | 2 456 | 2 456 | 2 456 |
| CreditScore | 2 456 | 2 456 | 2 456 | 2 456 | 2 456 | 2 456 | 2 456 |
| WarehouseLocation | 0 | 0 | 2 456 | 2 456 | 2 456 | 0 | 0 |
| CarrierName | 0 | 0 | 0 | 0 | 2 456 | 0 | 0 |
| TrackingNumber | 0 | 0 | 0 | 0 | 2 234 | 0 | 0 |
| InvoiceAmount | 0 | 0 | 0 | 0 | 0 | 2 456 | 2 456 |
| PaymentMethod | 0 | 0 | 0 | 0 | 0 | 0 | 1 987 |
Observations : La matrice révèle plusieurs problèmes de qualité des données. CustomerName et CreditScore sont des attributs au niveau du cas (populés sur toutes les activités pour tous les cas), ce qui est attendu. WarehouseLocation apparaît correctement uniquement pour les activités d'entrepôt (Préparer, Emballer, Expédier). Cependant, TrackingNumber affiche seulement 2 234 cas au lieu des 2 456 attendus pour l'activité Expédier, révélant que 222 envois n'ont pas de numéro de suivi – un écart critique nécessitant une enquête. PaymentMethod est renseigné pour seulement 1 987 cas à Recevoir paiement au lieu de 2 456, indiquant que 469 paiements manquent de méthode de paiement, suggérant un problème d'intégration avec le système de paiement.
Exemple 3 : Comprendre le cycle de vie des attributs
Scénario : Vous devez documenter à quel moment certains attributs deviennent disponibles lors du cycle de vie du processus afin d'orienter la conception des analyses et des rapports en aval.
Paramètres :
- Titre : "Documentation du cycle de vie des attributs"
- Description : "Cartographier le moment où chaque attribut est renseigné dans le traitement des factures"
Sortie :
| Attribut | Réception facture | Validation facture | Correspondance PO | Validation paiement | Planification paiement | Paiement effectué | Clôture du cas |
|---|---|---|---|---|---|---|---|
| InvoiceNumber | 3 456 | 3 456 | 3 456 | 3 456 | 3 456 | 3 456 | 3 456 |
| VendorID | 3 456 | 3 456 | 3 456 | 3 456 | 3 456 | 3 456 | 3 456 |
| PONumber | 0 | 0 | 3 456 | 3 456 | 3 456 | 3 456 | 3 456 |
| MatchStatus | 0 | 0 | 3 456 | 3 456 | 3 456 | 3 456 | 3 456 |
| ApprovedAmount | 0 | 0 | 0 | 3 456 | 3 456 | 3 456 | 3 456 |
| PaymentDate | 0 | 0 | 0 | 0 | 3 456 | 3 456 | 3 456 |
| ActualPaymentDate | 0 | 0 | 0 | 0 | 0 | 3 456 | 3 456 |
| ClosureReason | 0 | 0 | 0 | 0 | 0 | 0 | 3 456 |
Observations : Cette matrice montre clairement le cycle de vie des attributs. InvoiceNumber et VendorID sont renseignés dès le début (attributs au niveau du cas définis à la réception de la facture). PONumber et MatchStatus deviennent disponibles uniquement après l'activité Correspondance PO, les rendant indisponibles pour les étapes antérieures du processus. ApprovedAmount apparaît à Validation paiement et persiste dans les activités suivantes. PaymentDate (date prévue) apparaît à Planification paiement, tandis que ActualPaymentDate n'apparaît qu'à Paiement effectué, différenciant les dates prévues des dates réelles. ClosureReason est renseigné uniquement à l'activité finale. Cette compréhension du cycle de vie est cruciale pour concevoir des analyses dépendant de certains attributs.
Exemple 4 : Détection des problèmes systématiques de qualité des données
Scénario : Les utilisateurs signalent une disponibilité incohérente des données dans leurs analyses. Vous devez identifier si certaines activités échouent systématiquement à renseigner les attributs attendus.
Paramètres :
- Titre : "Analyse des lacunes systématiques des données"
- Description : "Identifier les activités avec population d'attributs manquante"
Sortie :
| Attribut | Vérifier demande | Affecter ressource | Début travail | Contrôle qualité | Finaliser travail | Documenter résultats |
|---|---|---|---|---|---|---|
| RequestID | 5 678 | 5 678 | 5 678 | 5 678 | 5 678 | 5 678 |
| AssignedTo | 0 | 5 678 | 5 678 | 5 678 | 5 678 | 5 678 |
| WorkCategory | 0 | 5 678 | 5 678 | 5 678 | 5 678 | 5 678 |
| StartTime | 0 | 0 | 5 678 | 5 678 | 5 678 | 5 678 |
| QualityScore | 0 | 0 | 0 | 4 234 | 4 234 | 4 234 |
| CompletionNotes | 0 | 0 | 0 | 0 | 5 678 | 5 678 |
| DocumentationLink | 0 | 0 | 0 | 0 | 0 | 3 456 |
Observations : La matrice met en évidence un problème critique de qualité des données. QualityScore devrait être renseigné à Contrôle qualité pour tous les cas (5 678), mais seulement 4 234 cas ont cet attribut, soit 1 444 cas (25 %) sans score qualité. Il s'agit d'une lacune systématique qui pourrait indiquer un problème avec le système d'inspection qualité ou l'extraction des données. De plus, DocumentationLink manque pour 2 222 cas (39 %) à l'activité Documenter résultats, suggérant que la documentation est omise pour une partie significative du travail. Ces lacunes systématiques nécessitent une attention immédiate pour garantir l'intégrité des données.
Exemple 5 : Validation de l'intégration multi-systèmes
Scénario : Votre processus intègre des données de trois systèmes différents (CRM, ERP et logistique), et vous devez vérifier que les attributs de chaque système sont correctement associés aux activités appropriées.
Paramètres :
- Titre : "Validation de l'intégration multi-systèmes"
- Description : "Vérifier la population des attributs provenant des systèmes CRM, ERP et logistique"
Sortie :
| Attribut | Saisie commande (CRM) | Réservation inventaire (ERP) | Allocation stock (ERP) | Expédition (Logistique) | Livraison (Logistique) | Confirmation réception (CRM) |
|---|---|---|---|---|---|---|
| CustomerID (CRM) | 8 945 | 8 945 | 8 945 | 8 945 | 8 945 | 8 945 |
| SalesRepID (CRM) | 8 945 | 8 945 | 8 945 | 8 945 | 8 945 | 8 945 |
| SKU (ERP) | 8 945 | 8 945 | 8 945 | 8 945 | 8 945 | 8 945 |
| InventoryLocation (ERP) | 0 | 8 945 | 8 945 | 8 945 | 8 945 | 8 945 |
| StockLevel (ERP) | 0 | 8 945 | 8 945 | 8 945 | 8 945 | 8 945 |
| CarrierID (Logistics) | 0 | 0 | 0 | 8 945 | 8 945 | 8 945 |
| DeliveryStatus (Logistics) | 0 | 0 | 0 | 8 945 | 8 945 | 8 945 |
| ReceivedBy (CRM) | 0 | 0 | 0 | 0 | 0 | 7 234 |
Observations : La matrice valide que la plupart des intégrations système fonctionnent correctement. Les attributs CRM (CustomerID, SalesRepID) sont disponibles tout au long du processus comme attendu pour des attributs au niveau du cas. Les attributs ERP (InventoryLocation, StockLevel) apparaissent correctement à partir de l'activité Réservation inventaire. Les attributs logistiques (CarrierID, DeliveryStatus) apparaissent correctement à partir de l'activité Expédition. Cependant, un problème important concerne l'attribut ReceivedBy – seulement 7 234 cas sur 8 945 l'ont renseigné dans Confirmation réception, ce qui signifie que 1 711 livraisons (19 %) n'ont pas de confirmation de la personne ayant réceptionné la commande. Ceci nécessite une enquête sur le workflow de confirmation CRM.
Exemple 6 : Planification de la stratégie d'enrichissement des attributs
Scénario : Vous souhaitez identifier quels attributs ont une population clairsemée et pourraient bénéficier d'un enrichissement par des données de référence ou l'amélioration des processus de capture des données.
Paramètres :
- Titre : "Analyse des opportunités d'enrichissement des attributs"
- Description : "Identifier les attributs clairsemés nécessitant un enrichissement"
Sortie :
| Attribut | Soumettre réclamation | Examiner documents | Évaluer dégâts | Approuver montant | Émettre paiement | Clôturer réclamation |
|---|---|---|---|---|---|---|
| ClaimNumber | 12 456 | 12 456 | 12 456 | 12 456 | 12 456 | 12 456 |
| PolicyNumber | 12 456 | 12 456 | 12 456 | 12 456 | 12 456 | 12 456 |
| AdjusterID | 0 | 12 456 | 12 456 | 12 456 | 12 456 | 12 456 |
| AdjusterName | 0 | 0 | 0 | 0 | 0 | 0 |
| DamageCategory | 0 | 0 | 12 456 | 12 456 | 12 456 | 12 456 |
| EstimatedCost | 0 | 0 | 12 456 | 12 456 | 12 456 | 12 456 |
| ApprovalReason | 0 | 0 | 0 | 12 456 | 12 456 | 12 456 |
| PaymentMethodCode | 0 | 0 | 0 | 0 | 12 456 | 12 456 |
| PaymentMethodName | 0 | 0 | 0 | 0 | 0 | 0 |
Observations : La matrice révèle d'excellentes opportunités d'enrichissement. AdjusterID est renseigné pour tous les cas à partir de l'activité Examiner documents (12 456 cas), mais AdjusterName n'est jamais renseigné. Enrichir AdjusterID avec les noms des experts à partir d'une table de référence des employés rendrait les analyses plus conviviales. De même, PaymentMethodCode est renseigné pour tous les paiements (12 456 cas) mais PaymentMethodName est manquant. Enrichir les codes de méthode de paiement avec des noms descriptifs améliorerait significativement la lisibilité des rapports. Ces enrichissements ajouteraient une valeur substantielle avec un effort minimal puisque les identifiants de référence sont déjà présents.
Sortie
Le calculateur Matrice Attribut-Activité affiche une table matricielle complète avec la structure suivante :
Lignes : Chaque ligne représente un attribut de votre journal d'événements, incluant à la fois les attributs au niveau du cas (qui s'appliquent à l'ensemble du cas) et les attributs au niveau de l'événement (qui peuvent varier selon l'activité).
Colonnes : Chaque colonne représente une activité unique de votre processus.
Valeurs des cellules : Chaque cellule contient un nombre représentant combien de cas ont une valeur pour cet attribut à cette activité. Une valeur de 0 signifie que l'attribut n'est renseigné pour aucun cas à cette activité.
Comprendre les valeurs des cellules
Attributs au niveau du cas : Pour les attributs au niveau du cas (comme CustomerID, OrderNumber, etc.), la valeur dans la cellule sera la même sur toutes les activités pour cette ligne, montrant le nombre total de cas où l'attribut a une valeur.
Attributs au niveau de l'événement : Pour les attributs au niveau de l'événement (comme ApproverName, WarehouseLocation, etc.), les valeurs des cellules varient selon l'activité, montrant où dans le processus cet attribut est renseigné.
Valeurs nulles (0) : Une valeur nulle dans une cellule indique que l'attribut n'est jamais renseigné à cette activité, ce qui peut être un comportement attendu ou un indicateur de problème de qualité des données selon votre processus.
Fonctionnalités interactives
Tri et filtre : Cliquez sur les en-têtes de colonne pour trier la matrice par activité. Utilisez la recherche dans le navigateur pour localiser rapidement des attributs spécifiques.
Exportation des résultats : Exportez la matrice complète vers Excel ou CSV pour une analyse détaillée hors ligne, une documentation ou un partage avec les équipes techniques.
Matrices volumineuses : Pour les processus comportant de nombreuses activités et attributs, la matrice peut être très grande. Pensez à utiliser le défilement horizontal et vertical pour naviguer dans la matrice complète.
Interprétation des schémas de population
Population constante : Si un attribut affiche la même valeur non nulle sur toutes les activités, il s'agit d'un attribut au niveau du cas renseigné tôt dans le processus.
Population progressive : Si un attribut affiche des zéros pour les activités initiales et des valeurs non nulles pour les activités suivantes, cela indique que l'attribut est renseigné à une étape spécifique du processus.
Population partielle : Si un attribut affiche une valeur inférieure au nombre total de cas, certains cas manquent cet attribut, ce qui peut indiquer des problèmes de qualité des données ou des champs optionnels.
Population spécifique à certaines activités : Si un attribut affiche des valeurs non nulles uniquement pour certaines activités, il s'agit d'un attribut au niveau de l'événement pertinent uniquement pour ces activités.
Considérations de performance
- Grandes bases de données : Pour des ensembles de données contenant des centaines d'attributs et d'activités, ce calculateur peut nécessiter un temps de traitement important
- Utilisation des ressources : Le calculateur analyse toutes les combinaisons attribut-activité, ce qui est gourmand en calcul
- Bonnes pratiques : Exécutez ce calculateur en heures creuses pour des bases de données très volumineuses
Accès administratif
Ce calculateur est réservé aux utilisateurs ayant le rôle Administrateur. Les utilisateurs réguliers devant comprendre les caractéristiques d'un ensemble de données doivent utiliser le calculateur Informations sur le Dataset, qui fournit des métriques résumées sans le détail attribut-activité.
Cette documentation fait partie de la plateforme de process mining mindzie Studio.