Remplir les Champs Vides dans un Attribut d'Événement

Présentation

L’enrichissement Remplir les Champs Vides dans un Attribut d'Événement est un opérateur puissant de qualité des données qui remplit intelligemment les valeurs nulles ou vides dans les attributs au niveau des événements en propageant les valeurs non nulles vers l’avant au sein de chaque cas. Cet outil essentiel de nettoyage des données résout un problème courant de qualité des données où les attributs des événements contiennent des informations incomplètes – comme les statuts de commande, les états d’approbation ou les numéros de suivi, qui peuvent ne pas être enregistrés à chaque étape du processus mais devraient logiquement persister jusqu’à leur modification. L’enrichissement utilise une stratégie de remplissage vers l’avant, en reportant la dernière valeur connue vers les événements suivants ayant des valeurs manquantes ou nulles.

Cet enrichissement opère au niveau des événements dans chaque cas, traitant les événements dans l’ordre chronologique pour s’assurer que les valeurs vides héritent de la valeur non nulle la plus récente des événements précédents du même cas. L’approche de remplissage vers l’avant est particulièrement utile pour les attributs basés sur un état où l’absence de valeur signifie généralement « pas de changement » plutôt que « pas de valeur ». En remplissant ces champs vides, vous créez une vue complète et cohérente des valeurs d’attribut tout au long du cycle de vie du cas, permettant une analyse, un filtrage et un reporting des processus plus précis sans perdre la relation temporelle entre les événements.

Utilisations Courantes

Compléter les attributs de statut de commande dans les processus achat-paiement où les changements de statut sont enregistrés uniquement lorsqu’ils se produisent, sans être répétés à chaque étape
Remplir les états d’approbation dans les processus de workflow où les décisions d’approbation persistent tout au long des activités suivantes jusqu’à la prochaine étape d’approbation
Propager les numéros de suivi ou identifiants de référence attribués tôt dans le processus mais nécessaires pour l’analyse de tous les événements
Compléter les attributs de produit ou client capturés à la création de commande mais absents des événements de traitement et d’expédition
Remplir les informations du transporteur d’expédition déterminées lors de l’expédition mais devant être associées à tous les événements de suivi ultérieurs
Maintenir les attributs de phase ou d’étape du projet à travers toutes les activités de chaque phase d’exécution projet
Compléter les assignations de représentants commerciaux ou équipes qui s’appliquent à tous les événements d’un cas après l’assignation initiale

Paramètres

Nom de l’Attribut d’Événement : Sélectionnez l’attribut au niveau de l’événement qui contient des valeurs vides ou nulles que vous souhaitez remplir. La liste déroulante affiche tous les attributs d’événement présents dans votre jeu de données. L’enrichissement traitera chaque cas indépendamment, remplissant les valeurs vides en reportant la dernière valeur non nulle connue des événements précédents dans le même cas. Seules les valeurs explicitement nulles ou vides sont remplies – les valeurs non nulles existantes sont conservées et utilisées comme base pour remplir les champs vides suivants. Choisissez des attributs où l’absence de valeur signifie logiquement « utiliser la valeur précédente » plutôt que « véritablement pas de valeur », comme les champs de statut, indicateurs d’état ou codes de référence qui persistent à travers plusieurs activités.

Exemples

Exemple 1 : Complétion du Statut de Commande

Scénario : Le système de traitement des commandes d’une entreprise d’e-commerce enregistre les changements de statut dans un attribut d’événement appelé "Order_Status", mais cet attribut est rempli uniquement au changement de statut. La plupart des événements ont des valeurs nulles pour Order_Status, ce qui empêche de filtrer ou d’analyser les commandes par leur statut à différentes étapes du processus.

Données d’Événements Avant Enrichissement : | Case ID | Activité | Horodatage | Order_Status | Montant_Commande | |---------|----------|------------|--------------|------------------| | PO-1001 | Create Order | 2024-01-10 08:00 | Pending | 1500.00 | | PO-1001 | Credit Check | 2024-01-10 08:15 | null | 1500.00 | | PO-1001 | Approve Order | 2024-01-10 09:30 | Approved | 1500.00 | | PO-1001 | Pick Items | 2024-01-10 10:00 | null | 1500.00 | | PO-1001 | Pack Items | 2024-01-10 11:00 | null | 1500.00 | | PO-1001 | Ship Order | 2024-01-10 14:00 | Shipped | 1500.00 | | PO-1001 | Delivery Confirmed | 2024-01-10 16:00 | null | 1500.00 |

Paramètres :

Nom de l’Attribut d’Événement : Order_Status

Résultat :

Données d’Événements Après Enrichissement : | Case ID | Activité | Horodatage | Order_Status | Montant_Commande | |---------|----------|------------|--------------|------------------| | PO-1001 | Create Order | 2024-01-10 08:00 | Pending | 1500.00 | | PO-1001 | Credit Check | 2024-01-10 08:15 | Pending | 1500.00 | | PO-1001 | Approve Order | 2024-01-10 09:30 | Approved | 1500.00 | | PO-1001 | Pick Items | 2024-01-10 10:00 | Approved | 1500.00 | | PO-1001 | Pack Items | 2024-01-10 11:00 | Approved | 1500.00 | | PO-1001 | Ship Order | 2024-01-10 14:00 | Shipped | 1500.00 | | PO-1001 | Delivery Confirmed | 2024-01-10 16:00 | Shipped | 1500.00 |

L’enrichissement a rempli les valeurs nulles avec le statut le plus récent : "Pending" a été reporté à Credit Check, "Approved" aux activités de picking et packing, et "Shipped" à la confirmation de livraison.

Analyse : Vous pouvez désormais filtrer précisément les cartes de processus pour afficher « toutes les activités de picking où le statut était Approved » ou calculer des métriques de performance pour les commandes approuvées vs en attente à n’importe quelle étape. L’information complète de statut permet une analyse fine des goulots d’étranglement et du respect des procédures à chaque étape.

Exemple 2 : Propagation du Numéro de Suivi Expédition

Scénario : Une société logistique attribue des numéros de suivi lors de la création des expéditions, mais son système n’enregistre le numéro que dans l’événement d’expédition. Tous les événements de scan et de suivi ultérieurs ont des numéros de suivi nuls, empêchant l’analyse complète du parcours des expéditions.

Données d’Événements Avant Enrichissement : | Case ID | Activité | Horodatage | Tracking_Number | Emplacement | Scanner_ID | |---------|----------|------------|-----------------|-------------|------------| | SHIP-501 | Create Shipment | 2024-01-15 06:00 | null | Warehouse A | SYS001 | | SHIP-501 | Assign to Route | 2024-01-15 06:30 | null | Warehouse A | USER123 | | SHIP-501 | Dispatch | 2024-01-15 07:00 | TRK-789456123 | Warehouse A | SCAN001 | | SHIP-501 | In Transit Scan | 2024-01-15 10:00 | null | Hub Central | SCAN045 | | SHIP-501 | Arrival Scan | 2024-01-15 14:00 | null | Hub East | SCAN089 | | SHIP-501 | Out for Delivery | 2024-01-15 16:00 | null | Branch 12 | SCAN102 | | SHIP-501 | Delivered | 2024-01-15 18:30 | null | Customer | SCAN102 |

Paramètres :

Nom de l’Attribut d’Événement : Tracking_Number

Résultat :

Après enrichissement, tous les événements à partir de l’expédition ont le numéro de suivi : | Case ID | Activité | Horodatage | Tracking_Number | Emplacement | Scanner_ID | |---------|----------|------------|-----------------|-------------|------------| | SHIP-501 | Create Shipment | 2024-01-15 06:00 | null | Warehouse A | SYS001 | | SHIP-501 | Assign to Route | 2024-01-15 06:30 | null | Warehouse A | USER123 | | SHIP-501 | Dispatch | 2024-01-15 07:00 | TRK-789456123 | Warehouse A | SCAN001 | | SHIP-501 | In Transit Scan | 2024-01-15 10:00 | TRK-789456123 | Hub Central | SCAN045 | | SHIP-501 | Arrival Scan | 2024-01-15 14:00 | TRK-789456123 | Hub East | SCAN089 | | SHIP-501 | Out for Delivery | 2024-01-15 16:00 | TRK-789456123 | Branch 12 | SCAN102 | | SHIP-501 | Delivered | 2024-01-15 18:30 | TRK-789456123 | Customer | SCAN102 |

Notez que les deux premiers événements restent nuls car aucun numéro de suivi n’avait encore été assigné – le remplissage vers l’avant ne propage que les valeurs après leur première apparition.

Analyse : Le service client peut maintenant chercher un numéro de suivi et voir le parcours complet incluant tous les événements de scan. L’analyse de performance peut mesurer les temps de gestion à chaque emplacement avec une bonne attribution du numéro de suivi. La gestion des exceptions peut identifier les cas où les numéros apparaissent à des étapes imprévues.

Exemple 3 : Statut d’Assurance Patient en Santé

Scénario : Le système de gestion des patients d’un hôpital enregistre les résultats de vérification d’assurance dans un attribut d’événement, mais ce statut ne se met à jour que lors de la vérification ou en cas de changement d’assurance. La plupart des événements de traitement ont un statut d’assurance nul, compliquant l’analyse des schémas de traitement selon la couverture assurance.

Données d’Événements Avant Enrichissement : | Case ID | Activité | Horodatage | Insurance_Status | Treatment_Code | Provider | |---------|----------|------------|------------------|----------------|----------| | PAT-2001 | Registration | 2024-02-01 08:00 | Pending | null | Clerk A | | PAT-2001 | Insurance Verification | 2024-02-01 08:15 | Verified | null | System | | PAT-2001 | Triage Assessment | 2024-02-01 08:30 | null | TRIAGE-01 | Nurse B | | PAT-2001 | Physician Consult | 2024-02-01 09:00 | null | CONSULT-01 | Dr. Smith | | PAT-2001 | Lab Test Order | 2024-02-01 09:30 | null | LAB-CBC | Dr. Smith | | PAT-2001 | Lab Collection | 2024-02-01 10:00 | null | LAB-CBC | Tech C | | PAT-2001 | Insurance Re-verification | 2024-02-01 11:00 | Approved | null | System | | PAT-2001 | Treatment | 2024-02-01 12:00 | null | TX-MINOR | Dr. Jones | | PAT-2001 | Discharge | 2024-02-01 14:00 | null | DISCHARGE | Nurse D |

Paramètres :

Nom de l’Attribut d’Événement : Insurance_Status

Résultat :

Après enrichissement, le statut d’assurance est complet tout au long du parcours patient : | Case ID | Activité | Horodatage | Insurance_Status | Treatment_Code | Provider | |---------|----------|------------|------------------|----------------|----------| | PAT-2001 | Registration | 2024-02-01 08:00 | Pending | null | Clerk A | | PAT-2001 | Insurance Verification | 2024-02-01 08:15 | Verified | null | System | | PAT-2001 | Triage Assessment | 2024-02-01 08:30 | Verified | TRIAGE-01 | Nurse B | | PAT-2001 | Physician Consult | 2024-02-01 09:00 | Verified | CONSULT-01 | Dr. Smith | | PAT-2001 | Lab Test Order | 2024-02-01 09:30 | Verified | LAB-CBC | Dr. Smith | | PAT-2001 | Lab Collection | 2024-02-01 10:00 | Verified | LAB-CBC | Tech C | | PAT-2001 | Insurance Re-verification | 2024-02-01 11:00 | Approved | null | System | | PAT-2001 | Treatment | 2024-02-01 12:00 | Approved | TX-MINOR | Dr. Jones | | PAT-2001 | Discharge | 2024-02-01 14:00 | Approved | DISCHARGE | Nurse D |

Analyse : L’hôpital peut maintenant suivre précisément quels traitements ont eu lieu sous quel statut d’autorisation d’assurance. Le reporting de conformité peut vérifier que toutes les procédures disposaient d’une approbation d’assurance adéquate. L’analyse qualité peut identifier les délais entre la vérification d’assurance et le début du traitement.

Exemple 4 : Priorité des Ordres de Travail en Fabrication

Scénario : Une usine de fabrication attribue des niveaux de priorité aux ordres de travail, mais la priorité n’est enregistrée qu’à la création de l’ordre ou lorsqu’elle change à cause de demandes clients. Les activités de production ne portent pas l’information de priorité, ce qui empêche d’analyser l’allocation des ressources par niveau de priorité.

Données d’Événements Avant Enrichissement : | Case ID | Activité | Horodatage | Priority | Machine | Operator | |---------|----------|------------|----------|---------|----------| | WO-3005 | Create Work Order | 2024-03-01 06:00 | Normal | null | System | | WO-3005 | Material Allocation | 2024-03-01 07:00 | null | null | Planner A | | WO-3005 | Setup Machine | 2024-03-01 08:00 | null | MC-205 | Tech B | | WO-3005 | Start Production | 2024-03-01 09:00 | null | MC-205 | Operator C | | WO-3005 | Priority Escalation | 2024-03-01 11:00 | Urgent | null | Supervisor | | WO-3005 | Quality Check | 2024-03-01 13:00 | null | QC-12 | Inspector D | | WO-3005 | Finish Production | 2024-03-01 15:00 | null | MC-205 | Operator C | | WO-3005 | Packaging | 2024-03-01 16:00 | null | PKG-08 | Packer E |

Paramètres :

Nom de l’Attribut d’Événement : Priority

Résultat :

L’enrichissement propage les valeurs de priorité vers l’avant, montrant exactement quand la priorité a changé : | Case ID | Activité | Horodatage | Priority | Machine | Operator | |---------|----------|------------|----------|---------|----------| | WO-3005 | Create Work Order | 2024-03-01 06:00 | Normal | null | System | | WO-3005 | Material Allocation | 2024-03-01 07:00 | Normal | null | Planner A | | WO-3005 | Setup Machine | 2024-03-01 08:00 | Normal | MC-205 | Tech B | | WO-3005 | Start Production | 2024-03-01 09:00 | Normal | MC-205 | Operator C | | WO-3005 | Priority Escalation | 2024-03-01 11:00 | Urgent | null | Supervisor | | WO-3005 | Quality Check | 2024-03-01 13:00 | Urgent | QC-12 | Inspector D | | WO-3005 | Finish Production | 2024-03-01 15:00 | Urgent | MC-205 | Operator C | | WO-3005 | Packaging | 2024-03-01 16:00 | Urgent | PKG-08 | Packer E |

Analyse : Les responsables de production peuvent désormais identifier les activités sous priorité urgente, mesurer l’impact des escalades de priorité sur les temps de cycle, et optimiser l’allocation des ressources en fonction de la priorité en temps réel à chaque étape de production.

Exemple 5 : Autorité d’Approbation des Transactions Financières

Scénario : Le système de traitement des transactions d’une banque enregistre le niveau de l’autorité d’approbation (Agence, Régional, Corporate) uniquement lorsque les transactions sont soumises à approbation. Les étapes de traitement suivantes ont des valeurs d’autorité nulles, empêchant l’analyse des parcours de workflow par niveau d’autorité.

Données d’Événements Avant Enrichissement : | Case ID | Activité | Horodatage | Approval_Authority | Montant | Statut | |---------|----------|------------|--------------------|---------|--------| | TXN-8001 | Initiate Transfer | 2024-04-01 09:00 | null | 250000.00 | Pending | | TXN-8001 | Risk Assessment | 2024-04-01 09:15 | null | 250000.00 | Pending | | TXN-8001 | Route for Approval | 2024-04-01 09:30 | Regional | 250000.00 | Pending | | TXN-8001 | Document Review | 2024-04-01 10:00 | null | 250000.00 | Pending | | TXN-8001 | Compliance Check | 2024-04-01 10:30 | null | 250000.00 | Pending | | TXN-8001 | Regional Approval | 2024-04-01 11:00 | null | 250000.00 | Approved | | TXN-8001 | Execute Transfer | 2024-04-01 11:15 | null | 250000.00 | Completed | | TXN-8001 | Confirmation Sent | 2024-04-01 11:20 | null | 250000.00 | Completed |

Paramètres :

Nom de l’Attribut d’Événement : Approval_Authority

Résultat :

Après enrichissement, tous les événements après routage affichent le niveau d’autorité : | Case ID | Activité | Horodatage | Approval_Authority | Montant | Statut | |---------|----------|------------|--------------------|---------|--------| | TXN-8001 | Initiate Transfer | 2024-04-01 09:00 | null | 250000.00 | Pending | | TXN-8001 | Risk Assessment | 2024-04-01 09:15 | null | 250000.00 | Pending | | TXN-8001 | Route for Approval | 2024-04-01 09:30 | Regional | 250000.00 | Pending | | TXN-8001 | Document Review | 2024-04-01 10:00 | Regional | 250000.00 | Pending | | TXN-8001 | Compliance Check | 2024-04-01 10:30 | Regional | 250000.00 | Pending | | TXN-8001 | Regional Approval | 2024-04-01 11:00 | Regional | 250000.00 | Approved | | TXN-8001 | Execute Transfer | 2024-04-01 11:15 | Regional | 250000.00 | Completed | | TXN-8001 | Confirmation Sent | 2024-04-01 11:20 | Regional | 250000.00 | Completed |

Analyse : La banque peut désormais mesurer les temps de traitement par niveau d’autorité d’approbation, identifier les goulots d’étranglement dans les workflows régionaux vs corporatifs, et garantir le respect des politiques de routage par niveau d’autorité. Les tableaux de bord de performance peuvent afficher les temps moyens d’approbation segmentés par niveau.

Résultat

L’enrichissement Remplir les Champs Vides dans un Attribut d'Événement modifie l’attribut d’événement sélectionné en place, remplaçant les valeurs nulles ou vides par la valeur non nulle la plus récente survenue dans les événements précédents du même cas. L’enrichissement traite chaque cas indépendamment, garantissant que les valeurs ne se propagent jamais au-delà des frontières d’un cas.

Algorithme de Remplissage vers l’Avant : L’enrichissement traite les événements dans l’ordre chronologique au sein de chaque cas, maintenant une variable de « dernière valeur connue ». Lorsqu’un événement a une valeur non nulle pour l’attribut sélectionné, cette valeur devient la nouvelle « dernière valeur connue ». Lorsqu’un événement a une valeur nulle ou vide, l’enrichissement la remplit avec la valeur actuelle « dernière valeur connue » s’il y en a une. Cette approche crée une fonction échelon où les valeurs persistent jusqu’à leur modification explicite par une nouvelle valeur non nulle.

Gestion des Valeurs Nulles : L’enrichissement ne remplit que les valeurs explicitement nulles ou vides – il ne remplace jamais les valeurs non nulles existantes, même si elles diffèrent de la valeur précédente. Si les premiers événements d’un cas ont des valeurs nulles sans valeur précédente à reporter, ces valeurs initiales restent inchangées jusqu’à l’apparition d’une première valeur non nulle dans un événement ultérieur.

Isolation par Cas : Chaque cas est traité complètement indépendamment. L’enrichissement ne reporte jamais de valeur d’un cas à un autre, assurant l’intégrité des données et évitant la contamination croisée des valeurs d’attribut entre différents cas. Lorsqu’un nouveau cas débute, la variable « dernière valeur connue » est réinitialisée à null.

Préservation du Type de Données : L’enrichissement conserve le type de données original de l’attribut rempli. Les valeurs de texte, numériques, dates et autres types sont toutes correctement gérées, garantissant que les valeurs remplies correspondent au type des valeurs non nulles originales.

Dépendance à l’Ordre des Événements : L’enrichissement dépend d’un bon ordonnancement des événements dans chaque cas. Les événements doivent être triés par horodatage avant d’appliquer cet enrichissement pour garantir que les valeurs se propagent dans la séquence chronologique correcte. En cas d’absence d’ordre correct, le remplissage vers l’avant peut produire des résultats imprévus.

Usage avec d’Autres Enrichissements : Cet enrichissement doit typiquement être appliqué tôt dans votre flux de travail d’enrichissement, immédiatement après toute opération de nettoyage des données affectant l’ordre des événements. Une fois les champs vides remplis, d’autres enrichissements et filtres peuvent référencer l’attribut en toute confiance sachant qu’il contient une information complète. L’attribut rempli peut être utilisé dans :

Filtres de cartes de processus pour afficher des variantes selon la valeur d’attribut à des étapes spécifiques
Calculs nécessitant des valeurs d’attribut complètes sur tous les événements
Vérification de conformité qui valide les valeurs d’attribut à certaines activités
Analyse de performance segmentant les cas par états d’attribut durant différentes phases de processus

Impact en Performance : L’enrichissement traite les données efficacement en itérant une seule fois sur les événements de chaque cas. Pour de grands jeux de données, la performance est linéaire par rapport au nombre d’événements. L’opération modifie les données en mémoire sans créer de nouveaux attributs, ce qui optimise la mémoire.

Quand ne Pas Utiliser Cet Enrichissement : Cet enrichissement est conçu pour les attributs basés sur un état où les valeurs manquantes signifient « pas de changement ». Ne pas l’utiliser pour :

Attributs de mesure où null signifie « non mesuré » plutôt que « utiliser la valeur précédente » (mesures de température, quantités)
Données spécifiques à l’événement qui varient réellement à chaque événement (noms d’activités, horodatages, ressources)
Attributs où null a une signification métier différente de la valeur précédente
Valeurs aléatoires ou indépendantes qui ne doivent pas se propager (IDs de transactions, identifiants uniques)

Voir Aussi

Convertir en Attributs de Cas – Convertir automatiquement des attributs d’événement en attributs de cas lorsque les valeurs ne changent pas
Attribut de Cas Représentatif – Sélectionner une valeur représentative des attributs d’événement pour créer des attributs de cas
Masquer les Attributs Vides – Supprimer les attributs sans valeurs du jeu de données
Anonymiser – Protéger les données sensibles tout en conservant la valeur analytique
Trier le Journal sur le Temps de Début – Assurer un bon ordre des événements avant de remplir les champs vides
Regrouper les Valeurs d’Attribut – Combiner des valeurs similaires d’attribut en catégories standardisées
Remplacer le Texte – Trouver et remplacer des valeurs textuelles dans les attributs
Supprimer les Espaces – Nettoyer les valeurs d’attribut en supprimant les espaces superflus

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