Hoofdletters

Overzicht

De Upper Case verrijking is een operator voor datastandardisatie die alle tekstwaarden in geselecteerde attributen omzet naar hoofdletters in uw hele dataset. Deze transformatie zorgt voor consistente tekstopmaak in uw procesdata, waardoor betrouwbare hoofdletterongevoelige matching, filtering en analysemethoden mogelijk zijn. Bij het werken met data uit meerdere bronnen waarbij de tekst soms inconsistente hoofdlettergebruik kent — zoals klantnamen die op verschillende manieren zijn ingevoerd in verschillende systemen of productcodes met gemengde kapitalisatie — creëert deze verrijking een uniforme hoofdletteropmaak die problemen met de gegevenskwaliteit veroorzaakt door hoofdletterverschillen elimineert.

Door tekst te standaardiseren naar hoofdletters, lost deze verrijking veelvoorkomende uitdagingen in process mining op waarbij dezelfde entiteit er anders uitziet door verschillen in kapitalisatie. Bijvoorbeeld, klantnamen zoals "Acme Corp", "ACME CORP" en "acme corp" worden zonder standaardisatie als drie verschillende waarden beschouwd, wat uw analyse versnipperd maakt. De Upper Case verrijking zorgt ervoor dat deze variaties worden samengevoegd, waardoor nauwkeurige statistieken mogelijk zijn voor klantanalyse, productcategorisering en resourcegebruik. Deze standaardisatie is vooral cruciaal bij het voorbereiden van data voor conformiteitscontrole, waarbij consistente activiteitsnamen en attributen essentieel zijn voor patroonherkenning.

De verrijking verwerkt stringattributen op casusniveau door elke tekstwaarde om te zetten, terwijl de oorspronkelijke datastructuur behouden blijft. In tegenstelling tot handmatige tekstmanipulatie die fouten en inconsistenties kan veroorzaken, zorgt deze geautomatiseerde aanpak ervoor dat elke instantie van het geselecteerde attribuut uniform wordt getransformeerd in alle cases van uw dataset.

Veelvoorkomende toepassingen

Klantnamen en bedrijfsidentificaties standaardiseren voor nauwkeurige analyse van klanttrajecten en segmentatie
Productcodes en SKU’s normaliseren die over verschillende systemen inconsistent worden gespeld qua hoofdletters
Tekstattributen voorbereiden voor hoofdletterongevoelige matching bij het koppelen van data uit meerdere bronnen
Consistente activiteitsnamen creëren voor procesontdekking wanneer bronsystemen verschillende kapitalisatieconventies gebruiken
Locatiecodes, afdelingsnamen en organisatorische eenheden standaardiseren voor nauwkeurige resource-analyse
Referentienummers en identifiers consistent formatteren voor betrouwbare filter- en groepeerbewerkingen
Tekstdata voorbereiden voor integratie met externe systemen die hoofdletterformatie vereisen

Instellingen

Attribute Name: Selecteer het tekstattribuut waarvan u de waarden naar hoofdletters wilt converteren. De keuzelijst toont alle beschikbare tekst (string) attributen in uw dataset, uitgezonderd verborgen kolommen. U moet exact één attribuut selecteren om te transformeren. De verrijking zal elke waarde binnen het geselecteerde attribuut in alle cases verwerken door kleine letters en gemengde hoofdletters om te zetten naar hoofdletters, terwijl tekst die al in hoofdletters is, ongewijzigd blijft. Alleen attributen van het datatype string zijn beschikbaar voor selectie.

Voorbeelden

Voorbeeld 1: Standaardiseren van klantnamen in orderverwerking

Scenario: Het ordermanagementsysteem van een distributiebedrijf bevat klantnamen met inconsistente kapitalisatie vanuit verschillende invoerpunten — weborders, telefonische bestellingen en EDI-transmissies — wat leidt tot versnipperde klantanalyses en onnauwkeurige berekeningen van ordervolumes.

Instellingen:

Attribute Name: Customer_Name

Voor verrijking: | Case ID | Customer_Name | Order_Value | Region | |---------|--------------|-------------|---------| | ORD-001 | Acme Corporation | 15000 | North | | ORD-002 | ACME CORPORATION | 22000 | North | | ORD-003 | acme corporation | 18500 | North | | ORD-004 | Beta Industries | 9500 | South | | ORD-005 | BETA INDUSTRIES | 11000 | South |

Na verrijking: | Case ID | Customer_Name | Order_Value | Region | |---------|--------------|-------------|---------| | ORD-001 | ACME CORPORATION | 15000 | North | | ORD-002 | ACME CORPORATION | 22000 | North | | ORD-003 | ACME CORPORATION | 18500 | North | | ORD-004 | BETA INDUSTRIES | 9500 | South | | ORD-005 | BETA INDUSTRIES | 11000 | South |

Output: Alle waarden in het Customer_Name attribuut zijn omgezet naar hoofdletters. De drie variaties van "Acme Corporation" zijn nu verenigd als "ACME CORPORATION", en de twee variaties van "Beta Industries" zijn gestandaardiseerd als "BETA INDUSTRIES".

Inzichten: Na standaardisatie ontdekte het bedrijf dat Acme Corporation in totaal 55.500 aan orders vertegenwoordigde (niet drie losse klanten met individuele bestellingen), waardoor het de grootste klant werd. Deze nauwkeurige weergave maakte juiste prioritering mogelijk en toonde aan dat 30% van de omzet afkomstig was van klanten waarvan de naam kleine verschillen in kapitalisatie had.

Voorbeeld 2: Normaliseren van productcodes in productie

Scenario: Het kwaliteitscontrolesysteem van een fabriek registreert defecten per productcode, maar codes worden door operators in drie verschillende ploegendiensten met verschillende kapitalisatiestijlen ingevoerd, waardoor nauwkeurige analyse van defectpercentages per product onmogelijk is.

Instellingen:

Attribute Name: Product_Code

Voor verrijking: | Case ID | Product_Code | Defect_Type | Shift | Severity | |---------|-------------|-------------|-------|----------| | QC-001 | prd-A1234 | Surface | Day | Minor | | QC-002 | PRD-A1234 | Surface | Night | Minor | | QC-003 | Prd-A1234 | Dimension | Evening | Major | | QC-004 | prd-b5678 | Assembly | Day | Critical | | QC-005 | PRD-B5678 | Assembly | Night | Critical |

Na verrijking: | Case ID | Product_Code | Defect_Type | Shift | Severity | |---------|-------------|-------------|-------|----------| | QC-001 | PRD-A1234 | Surface | Day | Minor | | QC-002 | PRD-A1234 | Surface | Night | Minor | | QC-003 | PRD-A1234 | Dimension | Evening | Major | | QC-004 | PRD-B5678 | Assembly | Day | Critical | | QC-005 | PRD-B5678 | Assembly | Night | Critical |

Output: Alle Product_Code waarden zijn omgezet naar hoofdletters. De drie variaties van product A1234 zijn verenigd als "PRD-A1234", en de twee variaties van product B5678 zijn gestandaardiseerd als "PRD-B5678".

Inzichten: Standaardisatie toonde aan dat product PRD-A1234 een defectpercentage van 60% had over alle diensten (3 defecten uit 5 productiecycli), wat een onmiddellijke kwaliteitsinspectie triggerde. Voorheen leek elke kapitalisatievariant afzonderlijk acceptabele defectpercentages te hebben.

Voorbeeld 3: Standaardiseren van afdelingcodes in de gezondheidszorg

Scenario: Het patiëntstroomsysteem van een ziekenhuis gebruikt afdelingcodes die medewerkers met verschillende kapitalisatiewijzen invoeren, waardoor het onmogelijk is om nauwkeurig de wachttijden en het gebruik van afdelingen binnen de faciliteit te volgen.

Instellingen:

Attribute Name: Department_Code

Voor verrijking: | Case ID | Patient_ID | Department_Code | Wait_Time | Priority | |---------|-----------|----------------|-----------|----------| | ADM-001 | P1234 | ER-main | 45 | High | | ADM-002 | P1235 | er-Main | 38 | High | | ADM-003 | P1236 | ER-MAIN | 52 | Critical | | ADM-004 | P1237 | icu-west | 15 | Medium | | ADM-005 | P1238 | ICU-West | 18 | Low |

Na verrijking: | Case ID | Patient_ID | Department_Code | Wait_Time | Priority | |---------|-----------|----------------|-----------|----------| | ADM-001 | P1234 | ER-MAIN | 45 | High | | ADM-002 | P1235 | ER-MAIN | 38 | High | | ADM-003 | P1236 | ER-MAIN | 52 | Critical | | ADM-004 | P1237 | ICU-WEST | 15 | Medium | | ADM-005 | P1238 | ICU-WEST | 18 | Low |

Output: Alle Department_Code waarden zijn gestandaardiseerd naar hoofdletters. De drie variaties van de spoedeisende hulpcode zijn verenigd als "ER-MAIN", en de ICU-west variaties zijn "ICU-WEST" geworden.

Inzichten: Na standaardisatie constateerde het ziekenhuis dat de afdeling ER-MAIN een gemiddelde wachttijd van 45 minuten had bij alle patiënten, wat boven het doel van 30 minuten ligt. Deze nauwkeurige afdelingsoverzicht maakte herverdeling van middelen mogelijk die de wachttijden met 25% verminderde.

Voorbeeld 4: Uniformeren van regiocodes in logistiek

Scenario: Het verzendingstrackingsysteem van een logistiek bedrijf bevat regiocodes met gemengde kapitalisatie uit verschillende boekingskanalen, wat nauwkeurige regionale prestatieanalyse en route-optimalisatie verhindert.

Instellingen:

Attribute Name: Region_Code

Voor verrijking: | Case ID | Shipment_ID | Region_Code | Delivery_Days | Service_Type | |---------|------------|-------------|---------------|--------------| | SHP-001 | S1234 | na-west | 3 | Express | | SHP-002 | S1235 | NA-WEST | 2 | Express | | SHP-003 | S1236 | Na-West | 4 | Standard | | SHP-004 | S1237 | eu-central | 5 | Standard | | SHP-005 | S1238 | EU-Central | 6 | Economy |

Na verrijking: | Case ID | Shipment_ID | Region_Code | Delivery_Days | Service_Type | |---------|------------|-------------|---------------|--------------| | SHP-001 | S1234 | NA-WEST | 3 | Express | | SHP-002 | S1235 | NA-WEST | 2 | Express | | SHP-003 | S1236 | NA-WEST | 4 | Standard | | SHP-004 | S1237 | EU-CENTRAL | 5 | Standard | | SHP-005 | S1238 | EU-CENTRAL | 6 | Economy |

Output: Alle Region_Code waarden zijn omgezet naar hoofdletters, waardoor de verschillende kapitalisaties zijn verenigd in consistente regiocodes.

Inzichten: Standaardisatie liet zien dat de regio NA-WEST gemiddeld 3 dagen nodig had voor alle leveringen, wat aan de SLA-vereisten voldeed. De eerder versnipperde data suggereerde dat sommige regio’s onderpresteerden vanwege de gefragmenteerde analyse door kapitalisatievarianten.

Voorbeeld 5: Normaliseren van statuscodes in financiële verwerking

Scenario: Het leningverwerkingssysteem van een bank heeft statuscodes die door medewerkers met verschillende kapitalisatie worden ingevoerd, waardoor het moeilijk is om nauwkeurig de fasen van de leningenpijplijn te volgen en knelpunten te identificeren.

Instellingen:

Attribute Name: Status_Code

Voor verrijking: | Case ID | Loan_ID | Status_Code | Amount | Days_In_Status | |---------|---------|------------|--------|----------------| | LN-001 | L1234 | approved | 50000 | 2 | | LN-002 | L1235 | APPROVED | 75000 | 3 | | LN-003 | L1236 | Approved | 45000 | 2 | | LN-004 | L1237 | pending | 100000 | 5 | | LN-005 | L1238 | PENDING | 85000 | 7 |

Na verrijking: | Case ID | Loan_ID | Status_Code | Amount | Days_In_Status | |---------|---------|------------|--------|----------------| | LN-001 | L1234 | APPROVED | 50000 | 2 | | LN-002 | L1235 | APPROVED | 75000 | 3 | | LN-003 | L1236 | APPROVED | 45000 | 2 | | LN-004 | L1237 | PENDING | 100000 | 5 | | LN-005 | L1238 | PENDING | 85000 | 7 |

Output: Alle Status_Code waarden zijn gestandaardiseerd naar hoofdletters, waarmee varianties van status zijn samengevoegd tot consistente waarden voor nauwkeurige pijplijnanalyse.

Inzichten: Na standaardisatie ontdekte de bank dat er voor 170.000 aan leningen (in plaats van 50.000 zoals eerder gedacht) de status "APPROVED" hadden, wat directe financieringsafspraken vereiste. De status "PENDING" toonde 185.000 aan aanvragen met gemiddeld 6 dagen in beoordeling, wat de noodzaak voor extra onderwrijvingscapaciteit benadrukte.

Output

De Upper Case verrijking wijzigt het geselecteerde tekstattribuut direct door alle stringwaarden om te zetten naar hoofdletters. De transformatie beïnvloedt alleen het gekozen attribuut, terwijl alle andere attributen onaangetast blijven. De verrijking verwerkt alle standaard tekstkarakters door kleine letters (a-z) om te zetten naar hun hoofdletterequivalenten (A-Z), en laat hoofdletters, cijfers, speciale tekens en symbolen ongewijzigd.

Het gewijzigde attribuut behoudt zijn oorspronkelijke kolomnaam en positie in uw datastructuur. Alle dataverbanden op casusniveau blijven behouden, en het attribuut blijft beschikbaar voor gebruik in filters, calculators en andere verrijkingen. Lege strings en null-waarden worden correct behandeld — null-waarden blijven null, terwijl lege strings leeg blijven.

Na toepassing van deze verrijking maakt de gestandaardiseerde hoofdlettertekst betrouwbare hoofdletterongevoelige bewerkingen mogelijk in heel mindzie Studio. U kunt het getransformeerde attribuut met vertrouwen gebruiken bij conformiteitscontrole, waar consistente tekstmatching cruciaal is. De hoofdletterwaarden werken naadloos samen met andere tekstrijke verrijkingen zoals Trim Text of Replace Text, en ondersteunen nauwkeurige groepering in calculators en filters.

Zie ook

Trim Text - Verwijder leading en trailing spaties uit tekstattributen
Text Start - Extraheer een opgegeven aantal tekens vanaf het begin van tekstwaarden
Text End - Extraheer een opgegeven aantal tekens vanaf het einde van tekstwaarden
Replace Text - Vervang specifieke tekstpatronen binnen attribuutwaarden
Limit Text Length - Verkort tekstattributen tot een maximum aantal tekens
Categorize Attribute Values - Groepeer tekstwaarden in categorieën gebaseerd op patronen of regels

Deze documentatie maakt deel uit van het mindzie Studio process mining platform.