Mayúsculas

Resumen

La enriquecimiento Upper Case es un operador de estandarización de datos que convierte todos los valores de texto en los atributos seleccionados a letras mayúsculas en todo tu conjunto de datos. Esta transformación asegura un formato de texto consistente a lo largo de tus datos de proceso, permitiendo operaciones confiables de coincidencia, filtrado y análisis insensibles a mayúsculas o minúsculas. Al trabajar con datos provenientes de múltiples fuentes donde el uso de mayúsculas varía inconsistente —como nombres de clientes ingresados de forma diferente en distintos sistemas o códigos de producto con capitalización mixta— este enriquecimiento crea un formato uniforme en mayúsculas que elimina problemas de calidad de datos relacionados con la capitalización.

Al estandarizar texto en mayúsculas, este enriquecimiento aborda desafíos comunes en minería de procesos donde una misma entidad aparece distinta debido a variaciones en mayúsculas y minúsculas. Por ejemplo, nombres de cliente como "Acme Corp", "ACME CORP" y "acme corp" serían tratados como tres valores distintos sin estandarización, fragmentando tu análisis. El enriquecimiento Upper Case asegura que estas variaciones se unifiquen, proporcionando métricas precisas para el análisis de clientes, categorización de productos y utilización de recursos. Esta estandarización es especialmente crítica al preparar datos para la verificación de conformidad, donde nombres y atributos de actividades consistentes son esenciales para el reconocimiento de patrones.

El enriquecimiento procesa atributos de tipo cadena a nivel de caso, transformando cada valor de texto mientras preserva la estructura original de los datos. A diferencia de la manipulación manual de texto que puede generar errores e inconsistencias, este enfoque automatizado asegura que cada instancia del atributo seleccionado sea transformada uniformemente en todos los casos de tu conjunto de datos.

Usos Comunes

Estandarizar nombres de clientes e identificadores de empresa para un análisis preciso del recorrido del cliente y segmentación
Normalizar códigos de producto y SKU que pueden tener capitalización inconsistente entre sistemas
Preparar atributos de texto para coincidencia insensible a mayúsculas al unir datos de múltiples fuentes
Crear nombres de actividad consistentes para el descubrimiento de procesos cuando los sistemas fuente usan convenciones diferentes de capitalización
Estandarizar códigos de ubicación, nombres de departamentos y unidades organizativas para un análisis preciso de recursos
Formatear números de referencia e identificadores de forma consistente para operaciones confiables de filtrado y agrupamiento
Preparar datos de texto para integración con sistemas externos que requieren formato en mayúsculas

Configuración

Nombre del Atributo: Selecciona el atributo de texto cuyos valores quieres convertir a mayúsculas. La lista desplegable muestra todos los atributos disponibles de texto (string) en tu conjunto de datos, excluyendo columnas ocultas. Debes seleccionar exactamente un atributo para transformar. El enriquecimiento procesará cada valor en el atributo seleccionado en todos los casos, convirtiendo texto en minúsculas o con mayúsculas mixtas a mayúsculas, mientras deja sin cambios el texto que ya está en mayúsculas. Solo los atributos con tipo de dato string están disponibles para selección.

Ejemplos

Ejemplo 1: Estandarización de nombres de clientes en procesamiento de pedidos

Escenario: El sistema de gestión de pedidos de una empresa de distribución contiene nombres de clientes con capitalización inconsistente procedente de diferentes puntos de entrada de datos —pedidos web, pedidos telefónicos y transmisiones EDI— causando análisis fragmentados de clientes y cálculos inexactos de volumen de pedidos.

Configuración:

Nombre del Atributo: Customer_Name

Antes del Enriquecimiento: | 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 |

Después del Enriquecimiento: | 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 |

Resultado: Todos los valores del atributo Customer_Name son convertidos a mayúsculas. Las tres variaciones de "Acme Corporation" ahora están unificadas como "ACME CORPORATION", y ambas variaciones de "Beta Industries" están estandarizadas a "BETA INDUSTRIES".

Conclusiones: Después de la estandarización, la empresa descubrió que Acme Corporation en realidad representaba 55,500 en órdenes totales (en lugar de tres clientes separados con órdenes individuales), convirtiéndolos en la cuenta más grande. Esta vista precisa permitió una correcta priorización de cuentas y reveló que el 30% de los ingresos provenían de clientes cuyos nombres tenían variaciones en capitalización.

Ejemplo 2: Normalización de códigos de producto en manufactura

Escenario: El sistema de control de calidad de una planta manufacturera rastrea defectos por código de producto, pero los códigos son ingresados con diferentes patrones de capitalización por operadores en tres turnos, impidiendo un análisis preciso de la tasa de defectos por producto.

Configuración:

Nombre del Atributo: Product_Code

Antes del Enriquecimiento: | 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 |

Después del Enriquecimiento: | 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 |

Resultado: Todos los valores de Product_Code son convertidos a mayúsculas. Las tres variaciones del producto A1234 se unifican como "PRD-A1234", y ambas variaciones del producto B5678 se estandarizan como "PRD-B5678".

Conclusiones: La estandarización reveló que el producto PRD-A1234 tenía una tasa de defectos del 60% en todos los turnos (3 defectos de 5 producciones), lo que provocó una investigación inmediata de calidad. Anteriormente, cada variante de capitalización parecía tener tasas aceptables de defectos cuando se analizaba por separado.

Ejemplo 3: Estandarización de códigos de departamento en salud

Escenario: El sistema de flujo de pacientes de un hospital utiliza códigos de departamento que el personal ingresa con capitalización inconsistente, imposibilitando rastrear con precisión los tiempos de espera y la utilización de departamentos en toda la instalación.

Configuración:

Nombre del Atributo: Department_Code

Antes del Enriquecimiento: | 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 |

Después del Enriquecimiento: | 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 |

Resultado: Todos los valores de Department_Code se estandarizan a mayúsculas. Las tres variaciones del código de sala de emergencias se unifican como "ER-MAIN", y las variaciones de ICU West se convierten en "ICU-WEST".

Conclusiones: Tras la estandarización, el hospital identificó que el departamento ER-MAIN tenía un tiempo promedio de espera de 45 minutos para todos los pacientes, excediendo el objetivo de 30 minutos. Esta vista precisa permitió redistribuir recursos que redujeron los tiempos de espera en un 25%.

Ejemplo 4: Unificación de códigos de región en logística

Escenario: El sistema de seguimiento de envíos de una empresa logística contiene códigos de región con capitalización mixta procedente de diferentes canales de reserva, dificultando un análisis preciso del desempeño regional y la optimización de rutas.

Configuración:

Nombre del Atributo: Region_Code

Antes del Enriquecimiento: | 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 |

Después del Enriquecimiento: | 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 |

Resultado: Todos los valores de Region_Code se convierten a mayúsculas, unificando las diferentes capitalizaciones en identificadores regionales consistentes.

Conclusiones: La estandarización reveló que la región NA-WEST tenía un promedio de 3 días para todas las entregas, cumpliendo los requisitos de SLA. Datos dispersos anteriormente sugerían que algunas regiones tenían bajo rendimiento debido al análisis fragmentado por variantes en la capitalización.

Ejemplo 5: Normalización de códigos de estado en procesamiento financiero

Escenario: El sistema de procesamiento de préstamos de un banco tiene códigos de estado que los agentes ingresan con capitalización variable, dificultando el seguimiento exacto de las etapas del pipeline de préstamos e identificación de cuellos de botella en el proceso.

Configuración:

Nombre del Atributo: Status_Code

Antes del Enriquecimiento: | 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 |

Después del Enriquecimiento: | 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 |

Resultado: Todos los valores de Status_Code están estandarizados a mayúsculas, consolidando las variaciones de estado en valores consistentes para un análisis preciso del pipeline.

Conclusiones: Después de la estandarización, el banco descubrió que había 170,000 en préstamos (no 50,000 como se pensaba anteriormente) en estado aprobado, requiriendo una disposición inmediata de fondos. El estado pendiente mostró 185,000 en solicitudes con un promedio de 6 días en revisión, destacando la necesidad de recursos adicionales en suscripción.

Salida

El enriquecimiento Upper Case modifica el atributo de texto seleccionado in situ, convirtiendo todos los valores string a letras mayúsculas. La transformación afecta solo el atributo elegido mientras preserva todos los demás atributos sin cambios. El enriquecimiento maneja todos los caracteres de texto estándar, convirtiendo letras minúsculas (a-z) a sus equivalentes en mayúsculas (A-Z) mientras deja sin cambios letras mayúsculas, números, caracteres especiales y símbolos.

El atributo modificado mantiene su nombre de columna original y posición en la estructura de tu conjunto de datos. Se preservan todas las relaciones de datos a nivel de caso, y el atributo permanece disponible para uso en filtros, calculadoras y otros enriquecimientos. Las cadenas vacías y valores nulos son manejados apropiadamente: los valores nulos permanecen nulos, mientras que las cadenas vacías siguen siendo cadenas vacías.

Después de aplicar este enriquecimiento, el texto estandarizado en mayúsculas permite operaciones confiables insensibles a mayúsculas en todo mindzie Studio. Puedes usar con confianza el atributo transformado en la verificación de conformidad, donde la coincidencia de texto consistente es crítica. Los valores en mayúsculas funcionan sin problemas con otros enriquecimientos basados en texto como Trim Text o Replace Text, y soportan agrupamientos precisos en calculadoras y filtros.

Véase También

Trim Text - Eliminar espacios en blanco al principio y al final de atributos de texto
Text Start - Extraer un número especificado de caracteres del inicio de valores de texto
Text End - Extraer un número especificado de caracteres del final de valores de texto
Replace Text - Reemplazar patrones específicos de texto dentro de valores de atributos
Limit Text Length - Truncar atributos de texto a una longitud máxima de caracteres
Categorize Attribute Values - Agrupar valores de texto en categorías basadas en patrones o reglas

Esta documentación es parte de la plataforma de minería de procesos mindzie Studio.