Limiter la Longueur du Texte

Vue d'ensemble

L'enrichissement Limiter la Longueur du Texte est un opérateur de nettoyage de données qui tronque automatiquement les valeurs textuelles de votre jeu de données à un nombre maximal de caractères spécifié. Cet outil essentiel de standardisation des données aide à gérer les champs de texte dépassant les limites de longueur souhaitées, assurant la cohérence à travers votre jeu de données de mining de processus et évitant les problèmes lors des analyses, visualisations et intégrations système en aval. Lorsqu'on travaille avec des données provenant de différentes sources, les champs textuels contiennent souvent des valeurs excessivement longues qui peuvent impacter les performances, la lisibilité et la compatibilité avec d'autres systèmes.

Cet enrichissement traite intelligemment les attributs textuels au niveau du cas et au niveau des événements, en préservant le sens original tout en appliquant les contraintes de longueur. Contrairement aux approches manuelles de troncature qui risquent la corruption ou l'incohérence des données, cet opérateur applique des règles uniformes sur l'ensemble de votre jeu de données. Cet enrichissement est particulièrement utile lors de la préparation des données pour des tableaux de bord où des valeurs textuelles longues peuvent perturber la mise en page, ou lors de l'intégration avec des systèmes disposant de limites strictes sur la longueur de certains champs.

Utilisations courantes

Standardiser les champs de description contenant des textes verbeux provenant de systèmes ERP ou plateformes de ticketing
Préparer les données pour la visualisation dans des tableaux de bord où des valeurs textuelles longues cassent la mise en page des tableaux ou la lisibilité des graphiques
Appliquer des limites de caractères avant l’exportation vers des systèmes avec des exigences strictes sur la longueur des champs
Tronquer des champs de commentaires longs tout en préservant les informations initiales les plus importantes
Standardiser les noms de produits, noms clients ou codes de référence à des longueurs maximales cohérentes
Améliorer les performances de l’analyse de mining de processus en réduisant l’utilisation mémoire causée par des valeurs textuelles excessivement longues
Créer des champs textuels uniformes pour une meilleure alignement dans les rapports et documents exportés

Paramètres

Nom de l’attribut : Sélectionnez l’attribut textuel que vous voulez limiter. Le menu déroulant affiche tous les attributs textuels disponibles, provenant à la fois des données au niveau du cas et des événements. Seuls les attributs de type chaîne/texte sont affichés comme choix valides. Ce champ est requis et détermine quelle colonne dans votre jeu de données aura ses valeurs tronquées.

Longueur maximale : Spécifiez le nombre maximal de caractères à conserver. Toute valeur textuelle dépassant cette longueur sera tronquée exactement à ce nombre de caractères. La valeur doit être supérieure à 0. La valeur par défaut est de 100 caractères. Valeurs courantes :

50 caractères pour descriptions courtes ou codes
100 caractères pour champs texte standards
255 caractères pour compatibilité avec de nombreux systèmes de bases de données
500 caractères pour des descriptions plus longues tout en gardant une bonne lisibilité

Exemples

Exemple 1 : Standardisation des descriptions produit en fabrication

Scénario : Le catalogue produit d’une entreprise de fabrication contient des descriptions techniques détaillées pouvant dépasser 1000 caractères, ce qui cause des problèmes dans leurs tableaux de bord de mining de processus et rend les rapports difficiles à lire.

Paramètres :

Nom de l’attribut : Product_Description
Longueur maximale : 150

Avant enrichissement : | Case ID | Product_Description | Order_Value | |---------|-------------------|-------------| | ORD-001 | "High-precision CNC machined aluminum component with aerospace-grade 7075-T6 alloy, featuring complex 5-axis milling patterns, anodized finish in matte black, tolerances within 0.001 inches, designed for critical aviation applications requiring maximum strength-to-weight ratio and corrosion resistance in extreme environmental conditions including salt spray, temperature variations from -60C to 150C, and high vibration environments typical of turbine engine mounting applications" | $12,500 | | ORD-002 | "Standard steel bracket, zinc plated" | $45 | | ORD-003 | "Custom fabricated stainless steel assembly with multiple welded joints, polished to mirror finish, designed for pharmaceutical clean room applications with full FDA compliance and documentation package included" | $3,200 |

Après enrichissement : | Case ID | Product_Description | Order_Value | |---------|-------------------|-------------| | ORD-001 | "High-precision CNC machined aluminum component with aerospace-grade 7075-T6 alloy, featuring complex 5-axis milling patterns, anodized finis" | $12,500 | | ORD-002 | "Standard steel bracket, zinc plated" | $45 | | ORD-003 | "Custom fabricated stainless steel assembly with multiple welded joints, polished to mirror finish, designed for pharmaceutical clean room ap" | $3,200 |

Résultat : Les descriptions produits sont tronquées exactement à 150 caractères. Les descriptions courtes restent inchangées tandis que les longues sont coupées à la limite de caractères.

Remarques : Après standardisation des longueurs de descriptions, la performance des tableaux de bord s’est améliorée de 40% et les rapports de catégorisation des produits sont devenus plus lisibles. L’équipe a découvert que 85% des informations critiques apparaissaient dans les 150 premiers caractères, rendant cette troncature adaptée à l’analyse tout en conservant les descriptions complètes dans le système source.

Exemple 2 : Gestion des commentaires client dans les processus de service

Scénario : Le système de service client d’une société de télécommunications capture des plaintes clients détaillées pouvant contenir plusieurs paragraphes, rendant difficile l’analyse des tendances dans leur mining de processus de service.

Paramètres :

Nom de l’attribut : Customer_Feedback
Longueur maximale : 200

Données événements avant : | Case ID | Activity | Customer_Feedback | Timestamp | |---------|----------|------------------|-----------| | TICKET-001 | Create Ticket | "Internet connection has been extremely unreliable for the past three weeks. Speed drops to almost nothing during evening hours between 7-10 PM. Have restarted modem multiple times, checked all cables, even replaced the router with my own but problem persists. This is affecting my ability to work from home and my children cannot complete their online homework. Previous technician visit on March 15 did not resolve the issue. Need immediate resolution as I'm considering switching providers if this continues. Very frustrated with the lack of consistent service despite paying for the premium package." | 2024-03-20 14:30 | | TICKET-002 | Create Ticket | "Bill incorrect - charged twice" | 2024-03-20 15:15 |

Données événements après : | Case ID | Activity | Customer_Feedback | Timestamp | |---------|----------|------------------|-----------| | TICKET-001 | Create Ticket | "Internet connection has been extremely unreliable for the past three weeks. Speed drops to almost nothing during evening hours between 7-10 PM. Have restarted modem multiple times, checked all ca" | 2024-03-20 14:30 | | TICKET-002 | Create Ticket | "Bill incorrect - charged twice" | 2024-03-20 15:15 |

Résultat : Les retours clients sont limités à 200 caractères, conservant le début de chaque message où le problème principal est généralement exprimé.

Remarques : L’analyse textuelle des retours tronqués a montré que 92% des problèmes pouvaient être catégorisés à partir des 200 premiers caractères. L’analyse de processus a révélé que les tickets avec des retours de plus de 200 caractères avaient des temps de résolution 35% plus longs, indiquant des problèmes complexes nécessitant une escalade.

Exemple 3 : Préparation des données de commandes pour intégration système

Scénario : Un service achat doit exporter les données de commandes à un système comptable ancien limitant les noms de fournisseur à 50 caractères, alors que les données actuelles contiennent les noms légaux complets pouvant dépasser 200 caractères.

Paramètres :

Nom de l’attribut : Vendor_Name
Longueur maximale : 50

Avant enrichissement : | Case ID | Vendor_Name | PO_Amount | |---------|------------|-----------| | PO-2024-001 | "International Business Machines Corporation (IBM) Global Technology Services Division" | $125,000 | | PO-2024-002 | "Acme Inc." | $3,500 | | PO-2024-003 | "Johnson & Johnson Consumer Healthcare Products Manufacturing and Distribution Limited Partnership" | $45,750 |

Après enrichissement : | Case ID | Vendor_Name | PO_Amount | |---------|------------|-----------| | PO-2024-001 | "International Business Machines Corporation (IBM" | $125,000 | | PO-2024-002 | "Acme Inc." | $3,500 | | PO-2024-003 | "Johnson & Johnson Consumer Healthcare Products Ma" | $45,750 |

Résultat : Les noms des fournisseurs sont tronqués à 50 caractères pour répondre aux exigences du système tout en conservant suffisamment d’information pour l’identification.

Remarques : La troncature a permis une intégration réussie avec le système ancien tout en maintenant la possibilité d'identifier les fournisseurs. L’analyse a montré que 78% des noms étaient déjà inférieurs à 50 caractères et que les noms tronqués conservaient assez d’informations pour une identification unique dans les rapports achats.

Exemple 4 : Optimisation des noms d’activités en mining de processus

Scénario : Un processus de gestion de sinistres d’assurance a des noms d’activités incluant des informations détaillées de sous-processus, rendant les cartes de processus encombrées et difficiles à lire.

Paramètres :

Nom de l’attribut : Activity_Name
Longueur maximale : 30

Données événements avant : | Case ID | Activity_Name | Resource | Timestamp | |---------|--------------|----------|-----------| | CLAIM-001 | "Initial Claim Review and Documentation Verification by Senior Adjuster" | John Smith | 2024-03-15 09:00 | | CLAIM-001 | "Medical Records Request Sent to Healthcare Provider via Secure Portal" | Sarah Johnson | 2024-03-15 10:30 | | CLAIM-001 | "Approve" | Mark Davis | 2024-03-15 14:00 |

Données événements après : | Case ID | Activity_Name | Resource | Timestamp | |---------|--------------|----------|-----------| | CLAIM-001 | "Initial Claim Review and Docu" | John Smith | 2024-03-15 09:00 | | CLAIM-001 | "Medical Records Request Sent " | Sarah Johnson | 2024-03-15 10:30 | | CLAIM-001 | "Approve" | Mark Davis | 2024-03-15 14:00 |

Résultat : Les noms d’activités sont limités à 30 caractères, créant des étiquettes plus concises pour la visualisation des processus.

Remarques : Les noms d’activités raccourcis ont amélioré la lisibilité des cartes de processus de 60% tout en conservant l’information essentielle sur chaque étape. Les analystes ont pu identifier plus rapidement les goulets d’étranglement, et les longueurs standardisées ont rendu l’analyse des fréquences d’activités plus précise.

Exemple 5 : Standardisation des numéros de référence dans les systèmes

Scénario : Une entreprise de logistique consolide les données d’expéditions de plusieurs transporteurs, chacun utilisant des formats de numéros de référence différents avec des longueurs variables, causant des problèmes dans leur tableau de bord de suivi unifié.

Paramètres :

Nom de l’attribut : Tracking_Reference
Longueur maximale : 25

Avant enrichissement : | Case ID | Tracking_Reference | Carrier | Status | |---------|-------------------|---------|--------| | SHIP-001 | "UPS1Z9999999999999999-EXPEDITED-INTERNATIONAL-PRIORITY" | UPS | In Transit | | SHIP-002 | "FEDEX777888999000" | FedEx | Delivered | | SHIP-003 | "DHL-EXPR-WORLDWIDE-DOC-999888777666555-PREPAID-MORNING-DELIVERY" | DHL | Processing |

Après enrichissement : | Case ID | Tracking_Reference | Carrier | Status | |---------|-------------------|---------|--------| | SHIP-001 | "UPS1Z9999999999999999-EXP" | UPS | In Transit | | SHIP-002 | "FEDEX777888999000" | FedEx | Delivered | | SHIP-003 | "DHL-EXPR-WORLDWIDE-DOC-99" | DHL | Processing |

Résultat : Les références de suivi sont standardisées à une longueur maximale de 25 caractères tout en conservant les informations les plus importantes pour l’identification.

Remarques : La standardisation des longueurs a permis la création d’un dashboard de suivi unifié affichant de manière cohérente les informations de tous les transporteurs. L’entreprise a constaté que le numéro de suivi principal apparaissait toujours dans les 25 premiers caractères, rendant cette troncature idéale pour leurs besoins de reporting.

Résultat

L’enrichissement Limiter la Longueur du Texte modifie directement les valeurs des attributs textuels dans votre jeu de données sans créer de nouveaux attributs. L’enrichissement s’applique à l’attribut sélectionné qu’il s’agisse d’un attribut de cas ou d’un attribut d’événement :

Pour les attributs de cas : Chaque cas unique dans votre jeu de données voit sa valeur d’attribut textuel sélectionné vérifiée et tronquée si elle dépasse la longueur maximale spécifiée. La troncature se fait exactement à la limite de caractères spécifiée, pouvant couper les mots en plein milieu.

Pour les attributs d’événement : Chaque ligne d’événement dans votre jeu de données voit sa valeur d’attribut textuel sélectionné vérifiée et tronquée si nécessaire. Cela signifie que le même attribut peut être tronqué différemment au fil des événements selon les valeurs originales.

Caractéristiques importantes :

Les noms originaux des attributs restent inchangés
Le type des données reste chaîne/texte
Les valeurs plus courtes ou égales à la longueur maximale restent inchangées
Les valeurs nulles ou vides ne sont pas affectées
La troncature se fait au position exacte de caractère sans tenir compte des limites de mots
Les caractères spéciaux, espaces et ponctuations comptent dans la limite de caractères
Aucun point de suspension (...) ni autre indicateur n’est ajouté pour montrer la troncature

Les valeurs modifiées d’attribut sont immédiatement disponibles pour l’utilisation dans les filtres, calculateurs et autres enrichissements. Cette modification sur place garantit que toutes les opérations suivantes dans votre analyse de mining de processus utilisent les longueurs textuelles standardisées.

Voir aussi

Élaguer le texte - Supprimer les espaces au début et à la fin des champs textuels
Mettre en majuscules - Convertir les attributs textuels en majuscules pour la standardisation
Début du texte - Extraire un nombre spécifié de caractères depuis le début des valeurs textuelles
Fin du texte - Extraire un nombre spécifié de caractères depuis la fin des valeurs textuelles
Chercher et remplacer - Remplacer des motifs textuels spécifiques dans les valeurs d’attribut
Concaténer les attributs - Combiner plusieurs attributs textuels en un seul champ

Cette documentation fait partie de la plateforme de mining de processus mindzie Studio.