テキスト長の制限

概要

「テキスト長の制限」エンリッチメントは、データセット内のテキスト値を指定した最大文字数に自動的に切り詰めるデータクリーンアップオペレーターです。この基本的なデータ標準化ツールは、望ましい長さの制限を超えるテキストフィールドを管理し、プロセスマイニングデータセット全体で一貫性を保つとともに、後続の分析、可視化、システム統合における問題を防ぎます。複数のソースからのデータを扱う際、テキストフィールドには過度に長い値が含まれることが多く、パフォーマンス、可読性、他システムとの互換性に影響を与えることがあります。

このエンリッチメントは、ケースレベルおよびイベントレベルのテキスト属性の両方を賢く処理し、元の意味を保持しつつ長さの制約を適用します。手動での切り詰めによるデータ破損や不整合のリスクがある方法とは異なり、本オペレーターはデータセット全体に均一な切り詰めルールを適用します。特に、長いテキスト値がレイアウトを乱すダッシュボード用のデータ準備や、特定フィールドに厳格な文字数制限があるシステムとの統合時に有用です。

主な用途

ERPシステムやチケットプラットフォームから得た冗長な記述フィールドの標準化
長いテキスト値が表のレイアウトやグラフの可読性を損なうダッシュボード用データの準備
厳しいフィールド長要件を持つシステムへデータエクスポート前の文字数制限の適用
最も重要な初期情報を保持しつつ長いコメントフィールドを切り詰め
製品名、顧客名、参照コードを一貫した最大長さで標準化
過度に長いテキスト値によるメモリ使用を削減し、プロセスマイニング分析のパフォーマンス向上
レポートやエクスポートドキュメントでの整列性向上のために均一なテキストフィールドを作成

設定

Attribute Name（属性名）： 制限したいテキスト属性を選択します。ドロップダウンには、ケースレベルおよびイベントレベルの両方から利用可能なすべてのテキスト属性が表示されます。文字列/テキスト型の属性のみが有効な選択肢として表示されます。これは必須フィールドであり、データセットのどの列の値を切り詰めるかを決定します。

Maximum Length（最大長）： 保持する最大文字数を指定します。これを超えるテキスト値は、正確にこの文字数に切り詰められます。値は0より大きくなければなりません。デフォルトは100文字です。よく使われる値は以下の通りです：

50文字：短い説明やコード用
100文字：標準的なテキストフィールド用
255文字：多くのデータベースシステムとの互換性のため
500文字：可読性を保ちながら長い説明用

事例

事例1：製造業での製品説明の標準化

シナリオ： 製造会社の製品カタログには1000文字を超える詳細な技術説明が含まれており、プロセスマイニングダッシュボードで問題を引き起こし、レポートの読みやすさを損ねています。

設定：

Attribute Name: Product_Description
Maximum Length: 150

エンリッチメント前： | 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 |

エンリッチメント後： | 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 |

出力結果： 製品説明は正確に150文字に切り詰められています。短い説明は変更されず、長い説明は制限文字数でカットされます。

分析結果： 記述長の標準化後、ダッシュボードのパフォーマンスが40%向上し、製品カテゴリレポートの読みやすさも改善されました。分析チームは重要な製品情報の85%が最初の150文字内に含まれることを発見し、この切り詰めが分析に適していると判断しました。元データは元のまま保持されています。

事例2：サービスプロセスにおける顧客フィードバックコメントの管理

シナリオ： 電気通信会社のカスタマーサービスシステムでは、数段落にわたる詳細な顧客苦情を取得しており、サービスプロセスマイニングでパターンを分析するのが困難です。

設定：

Attribute Name: Customer_Feedback
Maximum Length: 200

イベントデータ前： | 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 |

イベントデータ後： | 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 |

出力結果： 顧客フィードバックは200文字に制限され、主な問題が記述されている冒頭部分が保持されています。

分析結果： 切り詰めたフィードバックのテキストマイニングでは、92%の問題が最初の200文字内で分類可能でした。処理分析では200文字を超えるフィードバックのチケットが35%長い解決時間を要し、複雑な問題であることが示されました。

事例3：システム統合用の購入注文データ準備

シナリオ： 購買部門は、ベンダー名に50文字制限があるレガシー会計システムへ購入注文データをエクスポートする必要がありますが、現在のデータには200文字を超える正式会社名が含まれています。

設定：

Attribute Name: Vendor_Name
Maximum Length: 50

エンリッチメント前： | 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 |

エンリッチメント後： | 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 |

出力結果： ベンダー名は50文字に切り詰められ、システム要件を満たしつつ識別に十分な情報を維持しています。

分析結果： 切り詰めによりレガシーシステムへの統合が成功しました。78%のベンダー名は既に50文字未満で、切り詰めた名前も調達レポートでの固有識別に十分でした。

事例4：プロセスマイニングのアクティビティ名の最適化

シナリオ： 保険請求プロセスではアクティビティ名に詳細なサブプロセス情報が含まれ、プロセスマップが乱雑で読みづらくなっています。

設定：

Attribute Name: Activity_Name
Maximum Length: 30

イベントデータ前： | 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 |

イベントデータ後： | 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 |

出力結果： アクティビティ名は30文字に制限され、プロセス可視化でより簡潔なラベルとなりました。

分析結果： 短縮されたアクティビティ名によりプロセスマップの可読性が60%向上し、ボトルネックの特定が迅速化しました。長さの標準化はアクティビティ頻度分析の精度向上にも寄与しました。

事例5：システム間での参照番号の標準化

シナリオ： 物流会社は複数の運送業者からの出荷データを統合しており、それぞれ異なる形式と長さの参照番号が統一トラッキングダッシュボードで問題となっています。

設定：

Attribute Name: Tracking_Reference
Maximum Length: 25

エンリッチメント前： | 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 |

エンリッチメント後： | 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 |

出力結果： 参照番号は最大25文字に標準化され、最も重要な識別情報を保持しています。

分析結果： 参照番号の長さ標準化により、すべての運送業者の情報を一貫して表示できる統一トラッキングダッシュボードが作成されました。コアの追跡番号は常に最初の25文字以内に収まっているため、報告ニーズに最適な切り詰め方法です。

出力

「テキスト長の制限」エンリッチメントは、新しい属性を作成せずにデータセット内のテキスト属性値を直接変更します。エンリッチメントは選択された属性がケース属性かイベント属性かに関わらず動作します：

ケース属性の場合： データセット内の各ユニークなケースについて、選択されたテキスト属性値がチェックされ、指定された最大長を超えるとその長さで切り詰められます。切り詰めは正確に指定文字数の位置で実施され、単語の途中で切れることがあります。

イベント属性の場合： データセットのすべてのイベント行について、選択されたテキスト属性値がチェックされ、必要に応じて切り詰められます。したがって、同一属性でもイベントごとに切り詰め結果が異なる場合があります。

重要な特性：

元の属性名は変更されません
データ型は文字列/テキストのままです
最大長以下の値はまったく変更されません
Nullまたは空の値は影響を受けません
切り詰めは正確な文字位置で行われ、単語境界は考慮されません
特殊文字、空白、句読点も文字数にカウントされます
切り詰めを示す省略記号（…）などは追加されません

変更された属性値は、フィルター、計算機、他のエンリッチメントで即時に利用可能です。このインプレースの変更により、プロセスマイニング分析の以降すべての操作で標準化されたテキスト長が適用されます。

テキスト長の制限

概要

主な用途

設定

事例

事例1：製造業での製品説明の標準化

事例2：サービスプロセスにおける顧客フィードバックコメントの管理

事例3：システム統合用の購入注文データ準備

事例4：プロセスマイニングのアクティビティ名の最適化

事例5：システム間での参照番号の標準化

出力

関連項目