Lege Velden Invullen in Evenementattribuut

Overzicht

De verrijking Lege Velden Invullen in Evenementattribuut is een krachtige operator voor datakwaliteit die intelligent null- of lege waarden in gebeurtenisniveau attributen invult door niet-nul waarden door te geven naar volgende events binnen elk geval. Deze essentiële datacleaning tool pakt een veelvoorkomend datakwaliteitsprobleem aan waarbij evenementattributen onvolledige informatie bevatten, zoals orderstatussen, goedkeuringsstatussen of trackingnummers die mogelijk niet bij elke processtap worden vastgelegd, maar logisch gezien moeten blijven bestaan totdat ze veranderen. De verrijking gebruikt een forward-fill strategie, waarbij de laatst bekende waarde wordt doorgegeven aan volgende events die ontbrekende of null-waarden hebben.

Deze verrijking werkt op het gebeurtenisniveau binnen elk geval en verwerkt events in chronologische volgorde om ervoor te zorgen dat lege waarden de meest recente niet-nul waarde van eerdere events in hetzelfde geval erven. De forward-fill aanpak is vooral waardevol voor statusgebaseerde attributen waar de afwezigheid van een waarde doorgaans "geen verandering" betekent in plaats van "geen waarde". Door deze lege velden in te vullen, creëert u een compleet en consistent overzicht van attribuutwaarden gedurende de hele levenscyclus van het geval, wat meer accurate procesanalyse, filtering en rapportage mogelijk maakt zonder de temporele relatie tussen events te verliezen.

Veelvoorkomende Toepassingen

Orderstatus attributen compleet maken in purchase-to-pay processen waarbij statuswijzigingen alleen worden vastgelegd als ze plaatsvinden en niet bij elke stap worden herhaald
Goedkeuringsstatussen invullen in workflowprocessen waar goedkeuringsbeslissingen blijven gelden voor volgende activiteiten totdat de volgende goedkeuringsfase wordt bereikt
Trackingnummers of referentie-ID's doorgeven die vroeg in het proces worden toegewezen maar nodig zijn voor analyse gedurende alle events
Product- of klantattributen compleet maken die bij orderaanmaak worden vastgelegd maar ontbreken in fulfilment- en verzendevents
Vervoerderinformatie invullen die bij verzending wordt bepaald maar aan alle latere traceerevenementen moet worden gekoppeld
Projectfase- of stadiumattributen consistent houden over alle activiteiten binnen elke projectfase
Salesvertegenwoordiger- of teamtoewijzingen compleet maken die op alle events in een geval van toepassing zijn na initiële toewijzing

instellingen

Naam Evenementattribuut: Selecteer het gebeurtenisniveau attribuut dat lege of null-waarden bevat die u wilt invullen. De dropdown toont alle gebeurtenisattributen in uw dataset. De verrijking verwerkt elk geval onafhankelijk en vult lege waarden in door de laatst bekende niet-nul waarde van eerdere events binnen hetzelfde geval door te geven. Alleen expliciet null- of lege waarden worden ingevuld - bestaande niet-nul waarden blijven behouden en worden gebruikt om volgende lege velden in te vullen. Kies attributen waarbij ontbrekende waarden logisch "gebruik de vorige waarde" betekenen in plaats van "echt geen waarde", zoals statusvelden, statusindicatoren of referentiecodes die over meerdere activiteiten blijven gelden.

Voorbeelden

Voorbeeld 1: Completeren Orderstatus Inkooporder

Scenario: Het orderverwerkingssysteem van een e-commercebedrijf registreert orderstatuswijzigingen in een evenementattribuut genaamd "Order_Status", maar dit attribuut wordt alleen gevuld als de status daadwerkelijk wijzigt. De meeste events hebben null-waarden voor Order_Status, waardoor filteren of analyseren van orders op status in specifieke procesfasen onmogelijk is.

Evenementgegevens vóór verrijking: | Case ID | Activiteit | Timestamp | Order_Status | Order_Bedrag | |---------|------------|-----------|--------------|--------------| | PO-1001 | Maak Order | 2024-01-10 08:00 | Pending | 1500.00 | | PO-1001 | Kredietcontrole | 2024-01-10 08:15 | null | 1500.00 | | PO-1001 | Order goedkeuren | 2024-01-10 09:30 | Approved | 1500.00 | | PO-1001 | Artikelen pakken | 2024-01-10 10:00 | null | 1500.00 | | PO-1001 | Artikelen verpakken | 2024-01-10 11:00 | null | 1500.00 | | PO-1001 | Order verzenden | 2024-01-10 14:00 | Shipped | 1500.00 | | PO-1001 | Levering bevestigd | 2024-01-10 16:00 | null | 1500.00 |

Instellingen:

Naam Evenementattribuut: Order_Status

Resultaat:

Evenementgegevens na verrijking: | Case ID | Activiteit | Timestamp | Order_Status | Order_Bedrag | |---------|------------|-----------|--------------|--------------| | PO-1001 | Maak Order | 2024-01-10 08:00 | Pending | 1500.00 | | PO-1001 | Kredietcontrole | 2024-01-10 08:15 | Pending | 1500.00 | | PO-1001 | Order goedkeuren | 2024-01-10 09:30 | Approved | 1500.00 | | PO-1001 | Artikelen pakken | 2024-01-10 10:00 | Approved | 1500.00 | | PO-1001 | Artikelen verpakken | 2024-01-10 11:00 | Approved | 1500.00 | | PO-1001 | Order verzenden | 2024-01-10 14:00 | Shipped | 1500.00 | | PO-1001 | Levering bevestigd | 2024-01-10 16:00 | Shipped | 1500.00 |

De verrijking vulde null-waarden met de meest recente status: "Pending" wordt doorgedragen naar Kredietcontrole, "Approved" naar het pakken en verpakken, en "Shipped" naar de leveringsbevestiging.

Inzichten: U kunt nu proceskaarten nauwkeurig filteren om “alle pakactiviteiten met status Approved” te tonen, of prestatiekengetallen berekenen voor goedgekeurde versus in afwachting zijnde orders in elke procesfase. De complete statusinformatie maakt exacte knelpuntenanalyse en compliance-checking op elk moment mogelijk.

Voorbeeld 2: Doorgeven Trackingnummer Zending

Scenario: Een logistiek bedrijf wijst trackingnummers toe bij het aanmaken van zendingen, maar registreert het trackingnummer slechts in de verzendactiviteit. Alle volgende scan- en traceerevents hebben null trackingnummers, wat end-to-end analyse verhindert.

Evenementgegevens vóór verrijking: | Case ID | Activiteit | Timestamp | Tracking_Number | Locatie | Scanner_ID | |---------|------------|-----------|-----------------|---------|------------| | SHIP-501 | Maak zending | 2024-01-15 06:00 | null | Magazijn A | SYS001 | | SHIP-501 | Toewijzen route | 2024-01-15 06:30 | null | Magazijn A | USER123 | | SHIP-501 | Verzenden | 2024-01-15 07:00 | TRK-789456123 | Magazijn A | SCAN001 | | SHIP-501 | In transit scan | 2024-01-15 10:00 | null | Hub Centraal | SCAN045 | | SHIP-501 | Aankomst scan | 2024-01-15 14:00 | null | Hub Oost | SCAN089 | | SHIP-501 | Uitgeleverd | 2024-01-15 16:00 | null | Vestiging 12 | SCAN102 | | SHIP-501 | Afgeleverd | 2024-01-15 18:30 | null | Klant | SCAN102 |

Instellingen:

Naam Evenementattribuut: Tracking_Number

Resultaat:

Na verrijking is het trackingnummer bij alle events na verzending ingevuld: | Case ID | Activiteit | Timestamp | Tracking_Number | Locatie | Scanner_ID | |---------|------------|-----------|-----------------|---------|------------| | SHIP-501 | Maak zending | 2024-01-15 06:00 | null | Magazijn A | SYS001 | | SHIP-501 | Toewijzen route | 2024-01-15 06:30 | null | Magazijn A | USER123 | | SHIP-501 | Verzenden | 2024-01-15 07:00 | TRK-789456123 | Magazijn A | SCAN001 | | SHIP-501 | In transit scan | 2024-01-15 10:00 | TRK-789456123 | Hub Centraal | SCAN045 | | SHIP-501 | Aankomst scan | 2024-01-15 14:00 | TRK-789456123 | Hub Oost | SCAN089 | | SHIP-501 | Uitgeleverd | 2024-01-15 16:00 | TRK-789456123 | Vestiging 12 | SCAN102 | | SHIP-501 | Afgeleverd | 2024-01-15 18:30 | TRK-789456123 | Klant | SCAN102 |

Merk op dat de eerste twee events null blijven omdat er toen nog geen trackingnummer was toegewezen - de forward-fill geeft alleen waarden door nadat ze voor het eerst verschijnen.

Inzichten: Klantenservice kan nu op elk trackingnummer zoeken en de complete reis inclusief alle scanmomenten zien. Prestatieanalyse kan behandeltijden per locatie meten met juiste trackingnummer-toewijzing. Uitzonderingsafhandeling kan cases identificeren waarin trackingnummers op onverwachte momenten verschijnen.

Voorbeeld 3: Verzekeringsstatus Patiënt Zorg

Scenario: Het patiëntbeheersysteem van een ziekenhuis registreert verzekeringsverificaties in een evenementattribuut, maar de status wordt alleen bijgewerkt bij verificatie of bij verzekeringswijzigingen. De meeste behandel-events hebben null verzekeringsstatus, wat analyse van behandelpatronen op verzekeringsdekking bemoeilijkt.

Evenementgegevens vóór verrijking: | Case ID | Activiteit | Timestamp | Insurance_Status | Treatment_Code | Zorgverlener | |---------|------------|-----------|------------------|----------------|--------------| | PAT-2001 | Registratie | 2024-02-01 08:00 | Pending | null | Medewerker A | | PAT-2001 | Verzekeringscontrole | 2024-02-01 08:15 | Verified | null | Systeem | | PAT-2001 | Triagering | 2024-02-01 08:30 | null | TRIAGE-01 | Verpleegkundige B | | PAT-2001 | Arts consult | 2024-02-01 09:00 | null | CONSULT-01 | Dr. Smith | | PAT-2001 | Lab opdracht | 2024-02-01 09:30 | null | LAB-CBC | Dr. Smith | | PAT-2001 | Lab afname | 2024-02-01 10:00 | null | LAB-CBC | Technicus C | | PAT-2001 | Hercontrole verzekering | 2024-02-01 11:00 | Approved | null | Systeem | | PAT-2001 | Behandeling | 2024-02-01 12:00 | null | TX-MINOR | Dr. Jones | | PAT-2001 | Ontslag | 2024-02-01 14:00 | null | DISCHARGE | Verpleegkundige D |

Instellingen:

Naam Evenementattribuut: Insurance_Status

Resultaat:

Na verrijking is de verzekeringsstatus compleet door de hele patiëntreis: | Case ID | Activiteit | Timestamp | Insurance_Status | Treatment_Code | Zorgverlener | |---------|------------|-----------|------------------|----------------|--------------| | PAT-2001 | Registratie | 2024-02-01 08:00 | Pending | null | Medewerker A | | PAT-2001 | Verzekeringscontrole | 2024-02-01 08:15 | Verified | null | Systeem | | PAT-2001 | Triagering | 2024-02-01 08:30 | Verified | TRIAGE-01 | Verpleegkundige B | | PAT-2001 | Arts consult | 2024-02-01 09:00 | Verified | CONSULT-01 | Dr. Smith | | PAT-2001 | Lab opdracht | 2024-02-01 09:30 | Verified | LAB-CBC | Dr. Smith | | PAT-2001 | Lab afname | 2024-02-01 10:00 | Verified | LAB-CBC | Technicus C | | PAT-2001 | Hercontrole verzekering | 2024-02-01 11:00 | Approved | null | Systeem | | PAT-2001 | Behandeling | 2024-02-01 12:00 | Approved | TX-MINOR | Dr. Jones | | PAT-2001 | Ontslag | 2024-02-01 14:00 | Approved | DISCHARGE | Verpleegkundige D |

Inzichten: Het ziekenhuis kan nu nauwkeurig volgen welke behandelingen onder welke verzekeringsstatus plaatsvonden. Compliance rapportage kan verifiëren dat alle procedures passende verzekeringsgoedkeuring hadden. Kwaliteitsanalyse kan vertragingen identificeren tussen verzekeringscontrole en behandelingsstart.

Voorbeeld 4: Prioriteit Werkorder Fabriek

Scenario: Een fabriek wijst prioriteitsniveaus toe aan werkorders, maar prioriteit wordt alleen vastgelegd bij aanmaak of bij wijziging door klantverzoeken. Productieactiviteiten dragen geen prioriteitsinformatie, waardoor analyse van resourceallocatie per prioriteit onmogelijk is.

Evenementgegevens vóór verrijking: | Case ID | Activiteit | Timestamp | Prioriteit | Machine | Operator | |---------|------------|-----------|------------|---------|----------| | WO-3005 | Maak werkorder | 2024-03-01 06:00 | Normaal | null | Systeem | | WO-3005 | Materiaal toewijzen | 2024-03-01 07:00 | null | null | Planner A | | WO-3005 | Machine opstarten | 2024-03-01 08:00 | null | MC-205 | Technicus B | | WO-3005 | Productie starten | 2024-03-01 09:00 | null | MC-205 | Operator C | | WO-3005 | Prioriteit escalatie | 2024-03-01 11:00 | Dringend | null | Supervisor | | WO-3005 | Kwaliteitscontrole | 2024-03-01 13:00 | null | QC-12 | Inspecteur D | | WO-3005 | Productie afronden | 2024-03-01 15:00 | null | MC-205 | Operator C | | WO-3005 | Verpakken | 2024-03-01 16:00 | null | PKG-08 | Verpakker E |

Instellingen:

Naam Evenementattribuut: Prioriteit

Resultaat:

De verrijking draagt prioriteitswaarden door, toont precies wanneer prioriteit veranderde: | Case ID | Activiteit | Timestamp | Prioriteit | Machine | Operator | |---------|------------|-----------|------------|---------|----------| | WO-3005 | Maak werkorder | 2024-03-01 06:00 | Normaal | null | Systeem | | WO-3005 | Materiaal toewijzen | 2024-03-01 07:00 | Normaal | null | Planner A | | WO-3005 | Machine opstarten | 2024-03-01 08:00 | Normaal | MC-205 | Technicus B | | WO-3005 | Productie starten | 2024-03-01 09:00 | Normaal | MC-205 | Operator C | | WO-3005 | Prioriteit escalatie | 2024-03-01 11:00 | Dringend | null | Supervisor | | WO-3005 | Kwaliteitscontrole | 2024-03-01 13:00 | Dringend | QC-12 | Inspecteur D | | WO-3005 | Productie afronden | 2024-03-01 15:00 | Dringend | MC-205 | Operator C | | WO-3005 | Verpakken | 2024-03-01 16:00 | Dringend | PKG-08 | Verpakker E |

Inzichten: Productiemanagers kunnen nu zien welke activiteiten onder dringende prioriteit vielen, de impact van prioriteitsscalaties op cyclustijden meten en resourceallocatie optimaliseren gebaseerd op realtime prioriteitsstatus in elke productiefase.

Voorbeeld 5: Goedkeuringsautoriteit Financiële Transactie

Scenario: Het transactieverwerkingssysteem van een bank registreert het goedkeuringsautorititeitsniveau (Vestiging, Regionaal, Corporate) alleen bij indiening voor goedkeuring. Latere verwerkingsstappen hebben null autoriteitswaarden, waardoor analyse van workflowrouting per autoriteitsniveau onmogelijk wordt.

Evenementgegevens vóór verrijking: | Case ID | Activiteit | Timestamp | Approval_Authority | Bedrag | Status | |---------|------------|-----------|--------------------|--------|--------| | TXN-8001 | Transfer starten | 2024-04-01 09:00 | null | 250000.00 | Pending | | TXN-8001 | Risicobeoordeling | 2024-04-01 09:15 | null | 250000.00 | Pending | | TXN-8001 | Routing voor goedkeuring | 2024-04-01 09:30 | Regionaal | 250000.00 | Pending | | TXN-8001 | Documentreview | 2024-04-01 10:00 | null | 250000.00 | Pending | | TXN-8001 | Compliance controle | 2024-04-01 10:30 | null | 250000.00 | Pending | | TXN-8001 | Regionale goedkeuring | 2024-04-01 11:00 | null | 250000.00 | Approved | | TXN-8001 | Transfer uitvoeren | 2024-04-01 11:15 | null | 250000.00 | Completed | | TXN-8001 | Bevestiging verstuurd | 2024-04-01 11:20 | null | 250000.00 | Completed |

Instellingen:

Naam Evenementattribuut: Approval_Authority

Resultaat:

Na verrijking tonen alle events vanaf routing het autoriteitsniveau: | Case ID | Activiteit | Timestamp | Approval_Authority | Bedrag | Status | |---------|------------|-----------|--------------------|--------|--------| | TXN-8001 | Transfer starten | 2024-04-01 09:00 | null | 250000.00 | Pending | | TXN-8001 | Risicobeoordeling | 2024-04-01 09:15 | null | 250000.00 | Pending | | TXN-8001 | Routing voor goedkeuring | 2024-04-01 09:30 | Regionaal | 250000.00 | Pending | | TXN-8001 | Documentreview | 2024-04-01 10:00 | Regionaal | 250000.00 | Pending | | TXN-8001 | Compliance controle | 2024-04-01 10:30 | Regionaal | 250000.00 | Pending | | TXN-8001 | Regionale goedkeuring | 2024-04-01 11:00 | Regionaal | 250000.00 | Approved | | TXN-8001 | Transfer uitvoeren | 2024-04-01 11:15 | Regionaal | 250000.00 | Completed | | TXN-8001 | Bevestiging verstuurd | 2024-04-01 11:20 | Regionaal | 250000.00 | Completed |

Inzichten: De bank kan nu verwerkingstijden meten per goedkeuringsniveau, knelpunten in regionale versus corporate goedkeuringsworkflows identificeren en compliant routing policies monitoren. Prestatieoverzichten kunnen gemiddelde goedkeuringstijden per autoriteitsniveau tonen.

Output

De verrijking Lege Velden Invullen in Evenementattribuut wijzigt het geselecteerde evenementattribuut ter plaatse en vervangt null- of lege waarden door de laatst voorkomende niet-nul waarde van eerdere events binnen hetzelfde geval. Elk geval wordt onafhankelijk verwerkt, waardoor waarden nooit tussen gevallen worden doorgegeven.

Forward-Fill Algoritme: De verrijking verwerkt events chronologisch binnen elk geval en houdt een variabele "laatst bekende waarde" bij. Als een event een niet-nul waarde bevat voor het geselecteerde attribuut, wordt die waarde de nieuwe "laatst bekende waarde". Heeft een event een null- of lege waarde, dan wordt deze ingevuld met de huidige "laatst bekende waarde" als die bestaat. Deze forward-fill benadering creëert een trapfunctie waarbij waarden blijven bestaan totdat ze expliciet veranderen naar een nieuwe niet-nul waarde.

Omgaan met Null Waarden: De verrijking vult alleen expliciet null- of lege waarden in - bestaande niet-nul waarden worden nooit overschreven, zelfs niet als ze verschillen van de vorige waarde. Als de eerste events in een geval null-waarden hebben en er is geen eerdere waarde om door te geven, blijven deze initieel null totdat de eerste niet-nul waarde verschijnt.

Gevalniveau-isolatie: Elk geval wordt volledig onafhankelijk verwerkt. De verrijking draagt nooit waarden over van het ene naar het andere geval, waarmee dataintegriteit wordt gewaarborgd en kruiscontaminatie van attribuutwaarden tussen cases wordt voorkomen. Bij een nieuw geval reset de "laatst bekende waarde" naar null.

Behoud van Datatype: De verrijking behoudt het oorspronkelijke datatype van het ingevulde attribuut. Tekstwaarden, getallen, datums en andere datatypes worden correct verwerkt zodat ingevulde waarden conform het type van oorspronkelijke niet-nul waarden zijn.

Afhankelijkheid van Evenementvolgorde: De verrijking is afhankelijk van juiste eventvolgorde binnen elk geval. Events moeten gesorteerd zijn op timestamp voordat deze verrijking wordt toegepast om correcte chronologische opvolging van waarden te garanderen. Onjuiste volgorde kan onverwachte resultaten opleveren.

Gebruik met Andere Verrijkingen: Deze verrijking wordt doorgaans vroeg in de verrijkingsworkflow toegepast, direct na datacleansingsacties die eventvolgorde beïnvloeden. Zodra lege velden zijn ingevuld, kunnen andere verrijkingen en filters op het attribuut vertrouwen dat het complete informatie bevat. Het ingevulde attribuut kan gebruikt worden in:

Proceskaartfilters om varianten te tonen op basis van attribuutwaarde in specifieke fases
Berekeningen die complete attribuutwaarden voor alle events vereisen
Conformiteitscontroles die attribuutwaarden bij specifieke activiteiten valideren
Prestatieanalyses die cases segmenteren op basis van attribuutstatussen in verschillende procesfasen

Prestatie-impact: De verrijking werkt efficiënt door elke event slechts eenmaal te verwerken per geval. Voor grote datasets is de prestatie lineair in het aantal events. De operatie wijzigt data in het geheugen zonder nieuwe attributen aan te maken, wat geheugenefficiënt is.

Wanneer Niet Gebruiken: Deze verrijking is bedoeld voor statusgebaseerde attributen waarbij ontbrekende waarden logisch "geen verandering" betekenen. Gebruik deze niet voor:

Meetattributen waar null "niet gemeten" betekent in plaats van "gebruik vorige waarde" (temperatuurmetingen, aantallen)
Evenement-specifieke data die per event verschillend is (activiteitsnamen, timestamps, resources)
Attributen waarbij null een zakelijke betekenis heeft die anders is dan de vorige waarde
Willekeurige of onafhankelijke waarden die niet moeten worden doorgegeven (transactie-ID's, unieke identifiers)

Zie Ook

Convert to Case Attributes - Zet gebeurtenisattributen automatisch om naar gevalniveau als waarden niet veranderen
Representative Case Attribute - Selecteer een representatieve waarde uit gebeurtenisattributen voor het aanmaken van gevalattributen
Hide Blank Attributes - Verwijder attributen zonder waarden uit de dataset
Anonymize - Bescherm gevoelige data met behoud van analysemogelijkheden
Sort Log on Start Time - Zorg voor juiste eventvolgorde vóór invullen van lege velden
Group Attribute Values - Combineer vergelijkbare attribuutwaarden in gestandaardiseerde categorieën
Replace Text - Zoek en vervang tekstwaarden in attributen
Trim Text - Ruim attribuutwaarden op door overtollige witruimte te verwijderen

Deze documentatie maakt deel uit van het mindzieStudio process mining platform.