Lücken in Ereignisattributen füllen

Überblick

Die Anreicherung "Lücken in Ereignisattributen füllen" ist ein leistungsstarker Operator für Datenqualität, der intelligente Null- oder Leerwerte in ereignisebene Attributen durch Vorwärtstragen von nicht-null Werten innerhalb eines jeden Falls auffüllt. Dieses essenzielle Bereinigungswerkzeug adressiert ein häufiges Datenqualitätsproblem, bei dem Ereignisattribute unvollständige Informationen enthalten – wie z.B. Auftragsstatus, Genehmigungszustände oder Sendungsverfolgungsnummern, die nicht bei jedem Prozessschritt erfasst werden, aber logisch bis zur Änderung fortbestehen sollten. Die Anreicherung verwendet eine Forward-Fill-Strategie, bei der der zuletzt bekannte Wert an folgende Ereignisse weitergegeben wird, die fehlende oder null Werte haben.

Diese Anreicherung arbeitet auf ereignisebene innerhalb jedes Falls und verarbeitet die Ereignisse in chronologischer Reihenfolge, um sicherzustellen, dass leere Werte den zuletzt nicht-null Wert aus vorherigen Ereignissen im gleichen Fall übernehmen. Der Forward-Fill-Ansatz ist besonders wertvoll für zustandsbasierte Attribute, bei denen das Fehlen eines Wertes typischerweise „keine Änderung“ und nicht „kein Wert“ bedeutet. Durch das Füllen dieser Lücken schaffen Sie eine vollständige, konsistente Sicht auf Attributwerte über den gesamten Lebenszyklus des Falls hinweg, was genauere Prozessanalysen, Filterungen und Berichte ermöglicht, ohne die zeitliche Beziehung zwischen den Ereignissen zu verlieren.

Häufige Anwendungsfälle

Vervollständigung von Auftragsstatusattributen in Purchase-to-Pay-Prozessen, bei denen Statusänderungen nur bei tatsächlichem Wechsel erfasst werden, nicht bei jedem Schritt wiederholt
Auffüllen von Genehmigungszuständen in Workflow-Prozessen, bei denen Genehmigungsentscheidungen über nachfolgende Aktivitäten hinweg bis zur nächsten Genehmigungsstufe bestehen bleiben
Weitergabe von Sendungsverfolgungsnummern oder Referenz-IDs, die früh im Prozess zugewiesen werden, aber für die Analyse in allen Ereignissen benötigt werden
Vervollständigung von Produkt- oder Kundenattributen, die bei der Auftragserstellung erfasst, aber in der Erfüllungs- und Versandphase fehlen
Auffüllen von Frachtführerinformationen, die bei der Versandabwicklung bestimmt werden, aber mit allen folgenden Tracking-Ereignissen verknüpft sein sollten
Erhaltung von Projektphasen- oder Stufenattributen über alle Aktivitäten innerhalb jeder Phase der Projektausführung
Vervollständigung von Vertriebsmitarbeiter- oder Teamzuweisungen, die für alle Ereignisse eines Falls nach der Erstzuweisung gelten

Einstellungen

Event Attribute Name: Wählen Sie das ereignisebene Attribut aus, das leere oder null Werte enthält, die Sie auffüllen möchten. Das Dropdown zeigt alle Ereignisattribute in Ihrem Datensatz an. Die Anreicherung verarbeitet jeden Fall unabhängig und füllt leere Werte, indem der zuletzt bekannte nicht-null Wert aus vorherigen Ereignissen innerhalb desselben Falls vorgetragen wird. Es werden nur Werte gefüllt, die explizit null oder leer sind – bestehende nicht-null Werte bleiben erhalten und dienen als Basis für das Auffüllen nachfolgender Leerwerte. Wählen Sie Attribute, bei denen fehlende Werte logisch „vorherigen Wert verwenden“ und nicht „wirklich kein Wert“ bedeuten, wie Statusfelder, Zustandsindikatoren oder Referenzcodes, die über mehrere Aktivitäten hinweg bestehen.

Beispiele

Beispiel 1: Vervollständigung des Auftragsstatus

Szenario: Das Auftragsverarbeitungssystem eines E-Commerce-Unternehmens erfasst Auftragsstatusänderungen in einem Ereignisattribut namens „Order_Status“, aber dieses Attribut wird nur beim tatsächlichen Statuswechsel befüllt. Die meisten Ereignisse haben null Werte für Order_Status, was es unmöglich macht, Aufträge nach Status in bestimmten Prozessphasen zu filtern oder zu analysieren.

Ereignisdaten vor der Anreicherung: | Case ID | Activity | Timestamp | Order_Status | Order_Amount | |---------|----------|-----------|--------------|--------------| | 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 |

Einstellungen:

Event Attribute Name: Order_Status

Ausgabe:

Ereignisdaten nach der Anreicherung: | Case ID | Activity | Timestamp | Order_Status | Order_Amount | |---------|----------|-----------|--------------|--------------| | 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 |

Die Anreicherung hat die null Werte mit dem jeweils letzten Status aufgefüllt: "Pending" wurde beim Kreditcheck vorgetragen, "Approved" wird bei Kommissionier- und Verpackungsaktivitäten vorgetragen und "Shipped" beim Lieferbestätigungsevent.

Erkenntnisse: Nun können Prozesslandkarten präzise nach "allen Kommissionieraktivitäten mit Status Approved" filtern oder Leistungskennzahlen für genehmigte vs. ausstehende Aufträge in jeder Prozessphase berechnen. Die vollständige Statusinformation ermöglicht eine genaue Engpassanalyse und Compliance-Prüfung in jedem Schritt.

Beispiel 2: Weitergabe von Sendungsverfolgungsnummern

Szenario: Ein Logistikunternehmen weist Sendungsverfolgungsnummern zu, wenn Sendungen erstellt werden, aber das System erfasst die Nummer nur beim Versandereignis. Alle nachfolgenden Scan- und Verfolgungsevents haben null Tracking-Nummern, was eine durchgehende Sendungsanalyse verhindert.

Ereignisdaten vor der Anreicherung: | Case ID | Activity | Timestamp | Tracking_Number | Location | 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 |

Einstellungen:

Event Attribute Name: Tracking_Number

Ausgabe:

Nach der Anreicherung haben alle Ereignisse ab Versand die Tracking-Nummer: | Case ID | Activity | Timestamp | Tracking_Number | Location | 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 |

Die ersten zwei Ereignisse bleiben null, da zu diesem Zeitpunkt noch keine Tracking-Nummer zugewiesen wurde – das Forward-Fill propagiert Werte nur nach ihrem ersten Auftreten.

Erkenntnisse: Der Kundenservice kann jetzt jede Tracking-Nummer suchen und die vollständige Sendung einschließlich aller Scan-Ereignisse anzeigen. Leistungsanalysen können Bearbeitungszeiten an jedem Standort mit korrekter Tracking-Nummernzuordnung messen. Ausnahmebehandlungen erkennen Fälle, in denen Tracking-Nummern an unerwarteten Phasen auftauchen.

Beispiel 3: Versicherungsstatus beim Patienten im Gesundheitswesen

Szenario: Das Patientenverwaltungssystem eines Krankenhauses erfasst Versicherungsverifikationsresultate in einem Ereignisattribut, das Status wird aber nur aktualisiert, wenn eine Verifizierung erfolgt oder sich die Versicherung ändert. Die meisten Behandlungsevents haben null Versicherungsstatus, was die Analyse von Behandlungsmustern nach Versicherungstyp erschwert.

Ereignisdaten vor der Anreicherung: | Case ID | Activity | Timestamp | 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 |

Einstellungen:

Event Attribute Name: Insurance_Status

Ausgabe:

Nach der Anreicherung ist der Versicherungsstatus über den gesamten Patientenverlauf vollständig: | Case ID | Activity | Timestamp | 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 |

Erkenntnisse: Das Krankenhaus kann nun genau nachvollziehen, welche Behandlungen unter welchem Versicherungsstatus durchgeführt wurden. Compliance-Berichte können bestätigen, dass alle Verfahren eine entsprechende Versicherungsgenehmigung hatten. Qualitätsanalysen erkennen Verzögerungen zwischen Versicherungsverifizierung und Behandlungsbeginn.

Beispiel 4: Priorität von Fertigungsaufträgen

Szenario: Eine Fertigungsanlage weist Fertigungsaufträgen Prioritätslevel zu, die Priorität wird aber nur bei Auftragserstellung oder Änderungen aufgrund von Kundenanforderungen erfasst. Produktionsaktivitäten tragen keine Prioritätsinformation, was eine Analyse der Ressourcenzuweisung nach Priorität unmöglich macht.

Ereignisdaten vor der Anreicherung: | Case ID | Activity | Timestamp | 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 |

Einstellungen:

Event Attribute Name: Priority

Ausgabe:

Die Anreicherung trägt Prioritätswerte vorwärts, zeigt genau, wann die Priorität wechselte: | Case ID | Activity | Timestamp | 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 |

Erkenntnisse: Produktionsleiter können nun erkennen, welche Aktivitäten unter dringender Priorität durchgeführt wurden, die Auswirkungen von Prioritätseskalationen auf Zykluszeiten messen und Ressourcenzuordnung basierend auf dem Echtzeit-Prioritätsstatus in jeder Produktionsphase optimieren.

Beispiel 5: Genehmigungsbefugnis bei Finanztransaktionen

Szenario: Das Transaktionsverarbeitungssystem einer Bank erfasst die Genehmigungsbefugnisebene (Filiale, Regional, Konzern) nur, wenn Transaktionen zur Genehmigung eingereicht werden. Alle nachfolgenden Verarbeitungsschritte haben null Befugniswerte, was eine Analyse des Workflow-Routings nach Befugnisebene verhindert.

Ereignisdaten vor der Anreicherung: | Case ID | Activity | Timestamp | Approval_Authority | Amount | Status | |---------|----------|-----------|-------------------|--------|--------| | 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 |

Einstellungen:

Event Attribute Name: Approval_Authority

Ausgabe:

Nach der Anreicherung zeigen alle Ereignisse nach der Weiterleitung die Befugnisebene: | Case ID | Activity | Timestamp | Approval_Authority | Amount | Status | |---------|----------|-----------|-------------------|--------|--------| | 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 |

Erkenntnisse: Die Bank kann nun Bearbeitungszeiten nach Genehmigungsbefugnis messen, Engpässe in regionalen vs. konzernweiten Genehmigungsworkflows erkennen und die Einhaltung von Routing-Richtlinien sicherstellen. Leistungs-Dashboards zeigen durchschnittliche Genehmigungszeiten segmentiert nach Befugnislevel.

Ausgabe

Die Anreicherung "Lücken in Ereignisattributen füllen" ändert das ausgewählte Ereignisattribut inplace, indem null oder leere Werte durch den zuletzt aufgetretenen nicht-null Wert aus vorherigen Ereignissen des gleichen Falls ersetzt werden. Die Anreicherung verarbeitet jeden Fall unabhängig und stellt sicher, dass Werte nie über Fallgrenzen hinaus propagiert werden.

Forward-Fill-Algorithmus: Die Anreicherung verarbeitet Ereignisse in chronologischer Reihenfolge innerhalb jedes Falls und hält eine Variable für den „zuletzt bekannten Wert“ vor. Wenn ein Ereignis einen nicht-null Wert für das ausgewählte Attribut hat, wird dieser zum neuen „zuletzt bekannten Wert“. Hat ein Ereignis einen null- oder leeren Wert, füllt die Anreicherung diesen mit dem aktuellen „zuletzt bekannten Wert“, falls vorhanden. Dieser Forward-Fill erzeugt eine Stufenfunktion, bei der Werte erhalten bleiben, bis sie explizit durch einen neuen nicht-null Wert überschrieben werden.

Umgang mit Nullwerten: Gefüllt werden nur Werte, die explizit null oder leer sind – vorhandene nicht-null Werte werden nie überschrieben, auch wenn sie vom vorherigen Wert abweichen. Haben die ersten Ereignisse eines Falls null Werte und existiert kein vorheriger Wert, bleiben diese initialen null Werte unverändert, bis im Folgeereignis ein nicht-null Wert erscheint.

Fallbezogene Isolierung: Jeder Fall wird vollständig unabhängig verarbeitet. Werte werden niemals von einem Fall auf einen anderen übertragen, um Datenintegrität zu gewährleisten und eine Vermischung von Attributwerten zwischen Fällen zu verhindern. Wenn ein neuer Fall beginnt, wird der „zuletzt bekannte Wert“ auf null zurückgesetzt.

Datentyp-Erhaltung: Die Anreicherung bewahrt den ursprünglichen Datentyp des gefüllten Attributs. Textwerte, Zahlen, Datumsangaben und weitere Datentypen werden korrekt gehandhabt, sodass gefüllte Werte mit dem Typ der ursprünglichen nicht-null Werte übereinstimmen.

Abhängigkeit von der Ereignisreihenfolge: Die Anreicherung ist auf eine korrekte Ereignisreihenfolge innerhalb jedes Falls angewiesen. Ereignisse sollten vor der Anwendung dieser Anreicherung nach Zeitstempel sortiert sein, um eine korrekte chronologische Wertweitergabe sicherzustellen. Ist die Reihenfolge nicht korrekt, kann der Forward-Fill unerwartete Ergebnisse liefern.

Verwendung mit anderen Anreicherungen: Diese Anreicherung sollte typischerweise früh im Anreicherungsworkflow angewendet werden, unmittelbar nach bereinigenden Operationen, die die Ereignisreihenfolge beeinflussen können. Nach dem Füllen der Lücken können andere Anreicherungen und Filter verlässlich auf das Attribut zugreifen, da es vollständige Informationen enthält. Das gefüllte Attribut kann verwendet werden für:

Prozesskartenfilter, die Varianten nach Attributwerten in bestimmten Stufen anzeigen
Berechnungen, die vollständige Attributwerte für alle Ereignisse benötigen
Einhaltungskontrollen, die Attributwerte bei spezifischen Aktivitäten validieren
Leistungsanalysen, die Fälle nach Attributzuständen in verschiedenen Prozessphasen segmentieren

Performance-Auswirkung: Die Anreicherung verarbeitet Daten effizient, indem sie einmal durch die Ereignisse jedes Falls iteriert. Bei großen Datensätzen ist die Laufzeit linear zur Anzahl der Ereignisse. Die Operation ändert Daten im Speicher ohne neue Attribute zu erstellen, was speicherschonend ist.

Wann diese Anreicherung nicht verwenden: Diese Anreicherung ist für zustandsbasierte Attribute konzipiert, bei denen fehlende Werte logisch „keine Änderung“ bedeuten. Nicht verwenden bei:

Messattributen, bei denen null „nicht gemessen“ bedeutet statt „vorherigen Wert verwenden“ (Temperaturwerte, Mengen)
Ereignisspezifischen Daten, die wirklich pro Ereignis variieren (Aktivitätsnamen, Zeitstempel, Ressourcen)
Attributen, bei denen null eine geschäftliche Bedeutung hat, die sich vom vorherigen Wert unterscheidet
Zufälligen oder unabhängigen Werten, die nicht propagiert werden dürfen (Transaktions-IDs, eindeutige Kennungen)

Siehe auch

Convert to Case Attributes – Ereignisattribute automatisch in fallbezogene Attribute umwandeln, wenn Werte sich nicht ändern
Representative Case Attribute – Repräsentativen Wert aus Ereignisattributen wählen, um Fallattribute zu erstellen
Hide Blank Attributes – Attribute ohne Werte aus dem Datensatz entfernen
Anonymize – Sensible Daten schützen und gleichzeitig Analysewert erhalten
Sort Log on Start Time – Vorgänger für korrektes Ereignisordering vor dem Lückenfüllen
Group Attribute Values – Ähnliche Attributwerte in standardisierte Kategorien zusammenfassen
Replace Text – Textwerte in Attributen suchen und ersetzen
Trim Text – Attributwerte durch Entfernen von überflüssigen Leerzeichen bereinigen

Diese Dokumentation ist Teil der mindzieStudio Process Mining Plattform.