Großschreibung

Übersicht

Die Großschreibung-Anreicherung ist ein Operator zur Datenstandardisierung, der alle Textwerte in ausgewählten Attributen Ihres Datensatzes in Großbuchstaben umwandelt. Diese Transformation sorgt für eine einheitliche Textformatierung in Ihren Prozessdaten und ermöglicht zuverlässige, groß-/kleinschreibungsunabhängige Übereinstimmungs-, Filter- und Analyseoperationen. Wenn Sie mit Daten aus mehreren Quellen arbeiten, bei denen die Groß- und Kleinschreibung inkonsistent variiert – beispielsweise Kundennamen, die in verschiedenen Systemen unterschiedlich eingegeben wurden, oder Produktcodes mit gemischter Großschreibung – erzeugt diese Anreicherung eine einheitliche Großschreibung, die groß-/kleinschreibungsbezogene Datenqualitätsprobleme eliminiert.

Indem Texte auf Großbuchstaben vereinheitlicht werden, adressiert diese Anreicherung häufige Herausforderungen im Process Mining, bei denen dasselbe Objekt aufgrund von Groß-/Kleinschreibung unterschiedlich erscheint. Zum Beispiel würden Kundennamen wie „Acme Corp“, „ACME CORP“ und „acme corp“ ohne Standardisierung als drei verschiedene Werte behandelt werden, was Ihre Analyse fragmentiert. Die Großschreibung-Anreicherung stellt sicher, dass solche Variationen vereinheitlicht werden und liefert präzise Kennzahlen für Kundenanalysen, Produktkategorisierungen und Ressourcennutzungen. Diese Standardisierung ist besonders wichtig bei der Vorbereitung von Daten für die Konformitätsprüfung, wo konsistente Aktivitätsnamen und Attribute für die Mustererkennung unerlässlich sind.

Die Anreicherung verarbeitet String-Attribute auf Fallebene, indem sie jeden Textwert transformiert und dabei die ursprüngliche Datenstruktur beibehält. Im Gegensatz zur manuellen Textmanipulation, die Fehler und Inkonsistenzen verursachen kann, stellt dieser automatisierte Ansatz sicher, dass jede Instanz des ausgewählten Attributs über alle Fälle hinweg einheitlich umgewandelt wird.

Häufige Anwendungsfälle

Standardisierung von Kundennamen und Firmenkennungen für präzise Kundenreisenanalysen und Segmentierung
Normalisierung von Produktcodes und SKUs, die in verschiedenen Systemen uneinheitlich großgeschrieben sind
Vorbereitung von Textattributen für groß-/kleinschreibungsunabhängige Übereinstimmung bei der Datenverknüpfung aus mehreren Quellen
Erstellung konsistenter Aktivitätsnamen für die Prozessentdeckung, wenn Quellsysteme unterschiedliche Großschreibungs-Konventionen nutzen
Standardisierung von Standortcodes, Abteilungsnamen und Organisationseinheiten für präzise Ressourcenauswertung
Einheitliche Formatierung von Referenznummern und Identifikatoren für zuverlässige Filter- und Gruppierungsoperationen
Vorbereitung von Textdaten für die Integration mit externen Systemen, die Großschreibung erfordern

Einstellungen

Attributname: Wählen Sie das Textattribut aus, dessen Werte Sie in Großbuchstaben umwandeln möchten. Die Dropdown-Liste zeigt alle verfügbaren Text- (String-) Attribute Ihres Datensatzes an, ausgenommen versteckte Spalten. Es muss genau ein Attribut ausgewählt werden. Die Anreicherung verarbeitet jeden Wert im ausgewählten Attribut über alle Fälle hinweg und wandelt Klein- und gemischte Schreibweisen in Großbuchstaben um, während bereits großgeschriebener Text unverändert bleibt. Es stehen nur Attribute mit dem Datentyp String zur Auswahl.

Beispiele

Beispiel 1: Standardisierung von Kundennamen in der Auftragsbearbeitung

Szenario: Das Auftragsverwaltungssystem eines Vertriebsunternehmens enthält Kundennamen mit inkonsistenter Großschreibung aus verschiedenen Eingabestellen – Web-Bestellungen, Telefonbestellungen und EDI-Übertragungen – was eine fragmentierte Kundenanalyse und ungenaue Berechnungen des Auftragsvolumens verursacht.

Einstellungen:

Attributname: Customer_Name

Vor der Anreicherung: | 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 |

Nach der Anreicherung: | 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 |

Ergebnis: Alle Werte im Attribut Customer_Name wurden in Großbuchstaben umgewandelt. Die drei Varianten von „Acme Corporation“ sind nun als „ACME CORPORATION“ vereinheitlicht, und beide Varianten von „Beta Industries“ wurden zu „BETA INDUSTRIES“ standardisiert.

Erkenntnisse: Nach der Standardisierung stellte das Unternehmen fest, dass Acme Corporation insgesamt 55.500 Bestellungen repräsentiert (statt drei separater Kunden mit einzelnen Bestellungen) und damit der größte Kunde war. Diese genaue Sicht ermöglichte eine richtige Priorisierung der Kundenkonten und zeigte, dass 30 % des Umsatzes von Kunden stammen, deren Namen Groß-/Kleinschreibungsvarianten aufwiesen.

Beispiel 2: Normalisierung von Produktcodes in der Fertigung

Szenario: Das Qualitätskontrollsystem einer Fertigungsanlage erfasst Defekte nach Produktcode, jedoch werden die Codes von den Bedienern in drei Schichten mit unterschiedlichen Großschreibungsmustern eingegeben, was eine präzise Analyse der Defektrate je Produkt verhindert.

Einstellungen:

Attributname: Product_Code

Vor der Anreicherung: | 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 |

Nach der Anreicherung: | 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 |

Ergebnis: Alle Werte bei Product_Code wurden in Großbuchstaben konvertiert. Die drei Varianten des Produkts A1234 sind als „PRD-A1234“ vereinheitlicht und die beiden Varianten von Produkt B5678 als „PRD-B5678“ standardisiert.

Erkenntnisse: Die Standardisierung zeigte, dass Produkt PRD-A1234 eine Defektrate von 60 % über alle Schichten hinweg hatte (3 Defekte aus 5 Produktionsläufen), was eine sofortige Qualitätsuntersuchung auslöste. Davor schien jede Großschreibungsvariante separat akzeptable Defektraten aufzuweisen.

Beispiel 3: Standardisierung von Abteilungs-Codes im Gesundheitswesen

Szenario: Das Patiententransfersystem eines Krankenhauses verwendet Abteilungscodes, die das Personal mit unterschiedlicher Großschreibung eingibt, was eine genaue Überwachung von Patientenwartezeiten und Abteilungsnutzung erschwert.

Einstellungen:

Attributname: Department_Code

Vor der Anreicherung: | 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 |

Nach der Anreicherung: | 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 |

Ergebnis: Alle Werte bei Department_Code sind jetzt in Großbuchstaben. Die drei Varianten des Notaufnahmecodes sind zu „ER-MAIN“ vereinheitlicht, und die Varianten von ICU West zu „ICU-WEST“.

Erkenntnisse: Nach der Standardisierung identifizierte das Krankenhaus, dass die Abteilung ER-MAIN eine durchschnittliche Wartezeit von 45 Minuten für alle Patienten hatte, was das Ziel von 30 Minuten überstieg. Diese genaue Darstellung ermöglichte eine Ressourcen-Umlagerung, die die Wartezeiten um 25 % reduzierte.

Beispiel 4: Vereinheitlichung von Regionscodes in der Logistik

Szenario: Das Sendungsverfolgungssystem eines Logistikunternehmens enthält Regionscodes mit gemischter Großschreibung aus verschiedenen Buchungskanälen, was eine genaue regionale Leistungsanalyse und Routenoptimierung verhindert.

Einstellungen:

Attributname: Region_Code

Vor der Anreicherung: | 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 |

Nach der Anreicherung: | 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 |

Ergebnis: Alle Region_Code-Werte sind in Großbuchstaben, wodurch unterschiedliche Schreibweisen zu konsistenten Regionskennungen vereinheitlicht wurden.

Erkenntnisse: Die Standardisierung zeigte, dass die Region NA-WEST im Durchschnitt 3 Tage für alle Lieferungen benötigte und die SLA-Anforderungen erfüllte. Vorherige verstreute Daten ließen einige Regionen aufgrund fragmentierter Analysen durch Groß-/Kleinschreibungsvarianten unterperformen erscheinen.

Beispiel 5: Normalisierung von Status-Codes in der Finanzabwicklung

Szenario: Das Kreditantragssystem einer Bank verwendet Statuscodes, die von Mitarbeitern mit unterschiedlicher Großschreibung eingegeben werden, was die genaue Nachverfolgung von Phasen im Kreditprozess und die Identifizierung von Engpässen erschwert.

Einstellungen:

Attributname: Status_Code

Vor der Anreicherung: | 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 |

Nach der Anreicherung: | 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 |

Ergebnis: Alle Status_Code-Werte sind standardisiert in Großbuchstaben, wodurch Statusvariationen in konsistente Werte für eine präzise Pipelineanalyse zusammengeführt werden.

Erkenntnisse: Nach der Standardisierung stellte die Bank fest, dass Kredite im Wert von 170.000 (nicht 50.000 wie zuvor angenommen) den Status „approved“ hatten, was eine sofortige Finanzierungsplanung erforderte. Der Status „pending“ zeigte 185.000 in Anträgen mit durchschnittlich 6 Tagen Bearbeitungsdauer, was den Bedarf an zusätzlichen Underwriting-Ressourcen hervorhob.

Ausgabe

Die Großschreibung-Anreicherung modifiziert das ausgewählte Textattribut direkt vor Ort, indem alle String-Werte in Großbuchstaben umgewandelt werden. Die Transformation betrifft ausschließlich das gewählte Attribut, während alle anderen Attribute unverändert bleiben. Die Anreicherung verarbeitet alle Standardtextzeichen und wandelt Kleinbuchstaben (a-z) in ihre Großbuchstabenäquivalente (A-Z) um, wobei Großbuchstaben, Zahlen, Sonderzeichen und Symbole unverändert bleiben.

Das bearbeitete Attribut behält seinen ursprünglichen Spaltennamen und die Position in der Datenstruktur Ihres Datensatzes. Alle datenbezogenen Zusammenhänge auf Fallebene bleiben erhalten, und das Attribut steht weiterhin für Filter, Berechnungen und andere Anreicherungen zur Verfügung. Leere Strings und Nullwerte werden angemessen behandelt – Nullwerte bleiben Nullwerte, während leere Strings leer bleiben.

Nach Anwendung dieser Anreicherung ermöglicht der standardisierte Großbuchstaben-Text zuverlässige groß-/kleinschreibungsunabhängige Operationen in mindzieStudio. Sie können das transformierte Attribut sicher in der Konformitätsprüfung verwenden, wo konsistente Textabgleiche entscheidend sind. Die Großbuchstabenwerte harmonieren nahtlos mit anderen textbasierten Anreicherungen wie Trim Text oder Replace Text und unterstützen präzise Gruppierungen in Berechnungen und Filtern.

Siehe auch

Trim Text – Entfernt führende und nachfolgende Leerzeichen von Textattributen
Text Start – Extrahiert eine angegebene Anzahl von Zeichen vom Anfang der Textwerte
Text End – Extrahiert eine angegebene Anzahl von Zeichen vom Ende der Textwerte
Replace Text – Ersetzt bestimmte Textmuster innerhalb von Attributwerten
Limit Text Length – Kürzt Textattribute auf eine maximale Zeichenlänge
Categorize Attribute Values – Gruppiert Textwerte in Kategorien basierend auf Mustern oder Regeln

Diese Dokumentation ist Teil der mindzie Studio Process Mining Plattform.