Majuscules

Aperçu

L'enrichissement Majuscules est un opérateur de normalisation des données qui convertit toutes les valeurs textuelles des attributs sélectionnés en lettres majuscules dans l’ensemble de votre jeu de données. Cette transformation garantit une mise en forme cohérente du texte à travers vos données de processus, permettant des opérations fiables de correspondance, de filtrage et d’analyse insensibles à la casse. Lors du travail avec des données provenant de sources multiples où la casse du texte varie de manière incohérente — comme des noms de clients saisis différemment dans différents systèmes ou des codes produits avec une capitalisation mixte — cet enrichissement crée une mise en forme uniforme en majuscules qui élimine les problèmes de qualité des données liés à la casse.

En normalisant le texte en majuscules, cet enrichissement répond aux défis courants en exploration de processus où la même entité apparaît différemment selon les variantes de capitalisation. Par exemple, les noms de clients comme "Acme Corp", "ACME CORP" et "acme corp" seraient traités comme trois valeurs distinctes sans normalisation, fragmentant ainsi votre analyse. L’enrichissement Majuscules assure l’unification de ces variations, fournissant des métriques précises pour l’analyse client, la catégorisation des produits et l’utilisation des ressources. Cette normalisation est particulièrement critique lors de la préparation des données pour la vérification de conformité, où des noms d’activités et des attributs cohérents sont essentiels à la reconnaissance des motifs.

L’enrichissement traite les attributs textuels au niveau du cas, transformant chaque valeur tout en conservant la structure originale des données. Contrairement à la manipulation manuelle du texte qui comporte des risques d’erreurs et d’incohérences, cette approche automatisée garantit que chaque instance de l’attribut sélectionné est transformée uniformément dans tous les cas de votre jeu de données.

Utilisations courantes

Normaliser les noms des clients et les identifiants d’entreprise pour une analyse et une segmentation précises du parcours client
Uniformiser les codes produits et SKU pouvant avoir une capitalisation incohérente selon les systèmes
Préparer les attributs textuels pour des correspondances insensibles à la casse lors de la jonction de données provenant de plusieurs sources
Créer des noms d’activités cohérents pour la découverte de processus lorsque les systèmes sources utilisent des conventions de capitalisation différentes
Standardiser les codes de localisation, noms de départements et unités organisationnelles pour une analyse précise des ressources
Formater uniformément les numéros de référence et identifiants pour des opérations fiables de filtrage et regroupement
Préparer les données textuelles pour l’intégration avec des systèmes externes nécessitant un formatage en majuscules

Paramètres

Nom de l’attribut : Sélectionnez l’attribut textuel dont vous souhaitez convertir les valeurs en majuscules. La liste déroulante affiche tous les attributs de type texte (string) disponibles dans votre jeu de données, à l’exception des colonnes masquées. Vous devez sélectionner exactement un attribut à transformer. L’enrichissement traitera chaque valeur de l’attribut sélectionné dans tous les cas, convertissant les textes en minuscules et en casse mixte en majuscules tout en laissant inchangés les textes déjà en majuscules. Seuls les attributs de type chaîne sont disponibles pour la sélection.

Exemples

Exemple 1 : Normalisation des noms clients dans le traitement des commandes

Scénario : Le système de gestion des commandes d’une entreprise de distribution contient des noms clients avec une capitalisation incohérente provenant de différents points de saisie — commandes web, commandes téléphoniques et transmissions EDI — entraînant une analyse client fragmentée et des calculs de volume de commande inexactes.

Paramètres :

Nom de l’attribut : Customer_Name

Avant enrichissement : | Case ID | Customer_Name | Order_Value | Region | |---------|--------------|-------------|---------| | ORD-001 | Acme Corporation | 15000 | Nord | | ORD-002 | ACME CORPORATION | 22000 | Nord | | ORD-003 | acme corporation | 18500 | Nord | | ORD-004 | Beta Industries | 9500 | Sud | | ORD-005 | BETA INDUSTRIES | 11000 | Sud |

Après enrichissement : | Case ID | Customer_Name | Order_Value | Region | |---------|--------------|-------------|---------| | ORD-001 | ACME CORPORATION | 15000 | Nord | | ORD-002 | ACME CORPORATION | 22000 | Nord | | ORD-003 | ACME CORPORATION | 18500 | Nord | | ORD-004 | BETA INDUSTRIES | 9500 | Sud | | ORD-005 | BETA INDUSTRIES | 11000 | Sud |

Résultat : Toutes les valeurs de l’attribut Customer_Name sont converties en majuscules. Les trois variantes de "Acme Corporation" sont maintenant unifiées en "ACME CORPORATION", et les deux variantes de "Beta Industries" sont standardisées en "BETA INDUSTRIES".

Perspectives : Après la standardisation, l’entreprise a découvert que Acme Corporation représentait en réalité 55 500 en commandes totales (et non trois clients distincts avec des commandes individuelles), en faisant le plus grand compte. Cette vue précise a permis une bonne priorisation des comptes et a révélé que 30 % du chiffre d’affaires provenait de clients dont les noms comportaient des variations de capitalisation.

Exemple 2 : Normalisation des codes produits en production

Scénario : Le système de contrôle qualité d’une usine de fabrication suit les défauts par code produit, mais les codes sont saisis avec différentes capitalisations par les opérateurs lors des trois équipes, empêchant une analyse précise du taux de défaut par produit.

Paramètres :

Nom de l’attribut : Product_Code

Avant enrichissement : | Case ID | Product_Code | Defect_Type | Shift | Severity | |---------|-------------|-------------|-------|----------| | QC-001 | prd-A1234 | Surface | Jour | Mineur | | QC-002 | PRD-A1234 | Surface | Nuit | Mineur | | QC-003 | Prd-A1234 | Dimension | Soir | Majeur | | QC-004 | prd-b5678 | Assemblage | Jour | Critique | | QC-005 | PRD-B5678 | Assemblage | Nuit | Critique |

Après enrichissement : | Case ID | Product_Code | Defect_Type | Shift | Severity | |---------|-------------|-------------|-------|----------| | QC-001 | PRD-A1234 | Surface | Jour | Mineur | | QC-002 | PRD-A1234 | Surface | Nuit | Mineur | | QC-003 | PRD-A1234 | Dimension | Soir | Majeur | | QC-004 | PRD-B5678 | Assemblage | Jour | Critique | | QC-005 | PRD-B5678 | Assemblage | Nuit | Critique |

Résultat : Toutes les valeurs de Product_Code sont converties en majuscules. Les trois variantes du produit A1234 sont unifiées en "PRD-A1234", et les deux variantes du produit B5678 sont standardisées en "PRD-B5678".

Perspectives : La standardisation a révélé que le produit PRD-A1234 avait un taux de défaut de 60 % sur tous les postes (3 défauts sur 5 runs de production), déclenchant une enquête qualité immédiate. Auparavant, chaque variante de capitalisation semblait avoir un taux de défaut acceptable lorsqu’analysée séparément.

Exemple 3 : Standardisation des codes départements en santé

Scénario : Le système de gestion des flux de patients d’un hôpital utilise des codes départements saisis avec une capitalisation incohérente par le personnel, rendant impossible le suivi précis des temps d’attente et de l’utilisation des départements dans l’établissement.

Paramètres :

Nom de l’attribut : Department_Code

Avant enrichissement : | Case ID | Patient_ID | Department_Code | Wait_Time | Priority | |---------|-----------|----------------|-----------|----------| | ADM-001 | P1234 | ER-main | 45 | Élevée | | ADM-002 | P1235 | er-Main | 38 | Élevée | | ADM-003 | P1236 | ER-MAIN | 52 | Critique | | ADM-004 | P1237 | icu-west | 15 | Moyenne | | ADM-005 | P1238 | ICU-West | 18 | Faible |

Après enrichissement : | Case ID | Patient_ID | Department_Code | Wait_Time | Priority | |---------|-----------|----------------|-----------|----------| | ADM-001 | P1234 | ER-MAIN | 45 | Élevée | | ADM-002 | P1235 | ER-MAIN | 38 | Élevée | | ADM-003 | P1236 | ER-MAIN | 52 | Critique | | ADM-004 | P1237 | ICU-WEST | 15 | Moyenne | | ADM-005 | P1238 | ICU-WEST | 18 | Faible |

Résultat : Toutes les valeurs de Department_Code sont standardisées en majuscules. Les trois variantes du code de salle d’urgence sont unifiées en "ER-MAIN", et les variantes ICU west deviennent "ICU-WEST".

Perspectives : Après normalisation, l’hôpital a identifié que le département ER-MAIN avait un temps moyen d’attente de 45 minutes pour tous les patients, dépassant l’objectif de 30 minutes. Cette vue départementale précise a permis une réaffectation des ressources qui a réduit les temps d’attente de 25 %.

Exemple 4 : Unification des codes régionaux en logistique

Scénario : Le système de suivi des expéditions d’une entreprise logistique contient des codes régionaux avec une capitalisation mixte selon les canaux de réservation, empêchant une analyse précise des performances régionales et l’optimisation des itinéraires.

Paramètres :

Nom de l’attribut : Region_Code

Avant enrichissement : | 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 |

Après enrichissement : | 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 |

Résultat : Toutes les valeurs de Region_Code sont converties en majuscules, unifiant les différentes capitalisations en identifiants régionaux cohérents.

Perspectives : La standardisation a révélé que la région NA-WEST avait une moyenne de 3 jours pour toutes les livraisons, respectant les exigences SLA. Les données dispersées auparavant suggéraient que certaines régions étaient sous-performantes à cause d’une analyse fragmentée liée aux variantes de capitalisation.

Exemple 5 : Normalisation des codes statut en traitement financier

Scénario : Le système de traitement des prêts d’une banque utilise des codes statut saisis avec des capitalisations variables par les agents, rendant difficile le suivi précis des étapes du pipeline de prêt et l’identification des goulets d’étranglement du processus.

Paramètres :

Nom de l’attribut : Status_Code

Avant enrichissement : | 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 |

Après enrichissement : | 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 |

Résultat : Toutes les valeurs de Status_Code sont standardisées en majuscules, consolidant les variations de statut en valeurs cohérentes pour une analyse précise du pipeline.

Perspectives : Après standardisation, la banque a découvert que 170 000 en prêts (et non 50 000 comme précédemment estimé) étaient en statut approuvé, nécessitant une organisation de financement immédiate. Le statut en attente montrait 185 000 en demandes avec un temps moyen de 6 jours en revue, soulignant le besoin de ressources souscription supplémentaires.

Sortie

L’enrichissement Majuscules modifie l’attribut textuel sélectionné sur place, convertissant toutes les valeurs de chaîne en lettres majuscules. La transformation affecte uniquement l’attribut choisi, tout en conservant inchangés tous les autres attributs. L’enrichissement gère tous les caractères textes standards, convertissant les lettres minuscules (a-z) en leurs équivalents majuscules (A-Z) tout en laissant inchangées les lettres majuscules, chiffres, caractères spéciaux et symboles.

L’attribut modifié conserve son nom de colonne original et sa position dans la structure de votre jeu de données. Toutes les relations de données au niveau des cas sont préservées, et l’attribut reste disponible pour les filtres, calculatrices et autres enrichissements. Les chaînes vides et les valeurs nulles sont correctement gérées — les valeurs nulles restent nulles, tandis que les chaînes vides restent vides.

Après l’application de cet enrichissement, le texte standardisé en majuscules permet des opérations insensibles à la casse fiables dans tout mindzie Studio. Vous pouvez utiliser en toute confiance l’attribut transformé pour la vérification de conformité, où la correspondance de texte cohérente est critique. Les valeurs en majuscules fonctionnent parfaitement avec d’autres enrichissements basés sur le texte comme Trim Text ou Replace Text, et supportent une agrégation précise dans les calculatrices et filtres.

Voir aussi

Trim Text - Supprimez les espaces blancs en début et fin des attributs textuels
Text Start - Extrait un nombre spécifié de caractères depuis le début des valeurs textuelles
Text End - Extrait un nombre spécifié de caractères depuis la fin des valeurs textuelles
Replace Text - Remplace des motifs textuels spécifiques dans les valeurs d’attributs
Limit Text Length - Tronque les attributs textuels à une longueur maximale de caractères
Categorize Attribute Values - Regroupe les valeurs textuelles en catégories selon des motifs ou règles

Cette documentation fait partie de la plateforme d’exploration de processus mindzie Studio.