テキストのトリム

概要

Trim Text エンリッチメントは、データセット内のテキスト属性からすべての先頭および末尾の空白文字を自動的に削除するデータクリーンアップオペレーターです。この基本的なデータ整備ツールは、意図しないスペースやタブ、その他の不可視文字を排除することでテキストフィールドの一貫性を確保し、データの照合、フィルタリング、および分析における問題を防ぎます。ERPシステム、スプレッドシート、手入力システムなど様々なソースからのデータ処理時に、テキストフィールドに意図しない空白が含まれることがあり、正確なプロセスマイニング分析の妨げになります。

手動データクリーニングとは異なり、このエンリッチメントはケースレベルおよびイベントレベルのすべてのテキスト属性を一括で処理します。空の文字列をnull値に変換する賢い処理により、データセットの整合性が保たれます。この自動クリーンアップは、正確なテキスト照合が重要となる適合性検証のためのデータ準備に特に役立ちます。

主な用途

固定幅データベース列による末尾スペースが含まれるERPシステムからのインポートデータのクリーンアップ
フォームや手動入力システムでオペレーターが誤って追加したスペースを含むユーザー入力テキストフィールドの標準化
一貫したテキスト形式を保証して正確な照合・フィルタリング処理を準備
ドロップダウンフィルターで重複に見える値を引き起こす不可視空白文字の削除
正確なプロセス発見や適合性分析のためのアクティビティ名やリソース名のクリーニング
不均一なスペースが含まれている可能性のある製品コード、顧客ID、参照番号の正規化
連結や結合処理の前に、余計なスペースによる書式問題を防ぐためのテキスト属性の準備

設定

このエンリッチメントはすべてのテキスト属性に対して自動的に動作し、設定は不要です。データセット内のすべての文字列カラムを処理し、ケース属性およびイベント属性に一貫してトリム処理を適用します。

例

例1: ERPシステムのエクスポートデータのクリーンアップ

シナリオ: 製造会社がSAPシステムからエクスポートした注文データにおいて、製品コードや顧客名に固定幅データベース列による末尾スペースが含まれ、製品分類や顧客分析に問題が生じています。

エンリッチメント前: | Case ID | Product_Code | Customer_Name | Order_Status | |---------|--------------|---------------|--------------| | ORD-001 | "PRD-1234 " | "Acme Corp " | "APPROVED " | | ORD-002 | " PRD-5678" | " Beta Inc " | "PENDING" | | ORD-003 | "PRD-1234" | "Acme Corp" | "APPROVED" |

エンリッチメント後: | Case ID | Product_Code | Customer_Name | Order_Status | |---------|--------------|---------------|--------------| | ORD-001 | "PRD-1234" | "Acme Corp" | "APPROVED" | | ORD-002 | "PRD-5678" | "Beta Inc" | "PENDING" | | ORD-003 | "PRD-1234" | "Acme Corp" | "APPROVED" |

出力: すべてのテキスト属性がトリムされ、前後のスペースが除去されました。これにより、ORD-001およびORD-003の製品PRD-1234が正しく同一製品として認識され、顧客名も一貫した形式になりました。

考察: トリム後、同じように見えた150のユニークな製品コードが実は95の異なる製品であることが判明しました。これにより在庫分析が正確になり、Acme Corpが計算当初より40%多くの注文を占めていることが明らかになりました。

例2: 医療機関の手動入力データの標準化

シナリオ: 病院の患者入院システムで、アクティビティ名や部門フィールドに手動入力による不均一なスペースが存在し、正確なプロセスフロー分析や部門利用率指標が妨げられています。

イベントデータ前: | Case ID | Activity | Department | Resource | |---------|----------|------------|----------| | PAT-101 | " Patient Registration" | "Emergency " | "Nurse Johnson " | | PAT-101 | "Triage " | " Emergency" | "Dr. Smith" | | PAT-102 | "Patient Registration" | "Emergency" | " Nurse Johnson" |

イベントデータ後: | Case ID | Activity | Department | Resource | |---------|----------|------------|----------| | PAT-101 | "Patient Registration" | "Emergency" | "Nurse Johnson" | | PAT-101 | "Triage" | "Emergency" | "Dr. Smith" | | PAT-102 | "Patient Registration" | "Emergency" | "Nurse Johnson" |

出力: アクティビティ名、部門名、リソース名の余計なスペースを除去して標準化しました。これにより、別々に見えていた「Patient Registration」アクティビティが一つに統合されました。

考察: クリーンアップにより、緊急部門を経由する患者の流れが正しく反映され、全患者が同一の初期登録プロセスをたどっていることが判明しました。リソース利用レポートも正確になり、Nurse Johnsonが登録の75%を担当していることが一目瞭然となりました。

例3: 金融取引データのクリーンアップ

シナリオ: 銀行のローン処理システムで、各支店システムからエクスポートされた取引種別や承認コードに様々な空白の問題があり、承認パターンの追跡やプロセス遵守が困難になっています。

ケース属性前: | Loan_ID | Loan_Type | Branch_Code | Approval_Level | |---------|-----------|-------------|----------------| | LN-5001 | "Personal Loan " | " NYC-01 " | "Manager " | | LN-5002 | " Personal Loan" | "NYC-01" | "Manager" | | LN-5003 | " Business Loan " | " LA-02" | " Director " |

ケース属性後: | Loan_ID | Loan_Type | Branch_Code | Approval_Level | |---------|-----------|-------------|----------------| | LN-5001 | "Personal Loan" | "NYC-01" | "Manager" | | LN-5002 | "Personal Loan" | "NYC-01" | "Manager" | | LN-5003 | "Business Loan" | "LA-02" | "Director" |

出力: すべてのローンタイプ、支店コード、承認レベルが一貫してフォーマットされました。LN-5001とLN-5002の個人ローンは正しくグルーピングされ、地域分析も正確に行えます。

考察: クリーンアップ後、個人ローンは全体の65%を占めていることが判明し、これまではスペースの差異で異なるローンタイプとしてカウントされていました。これによりリスク評価やリソース配分が適切に行えるようになりました。

例4: 調達プロセスデータの正規化

シナリオ: 調達システムは複数のベンダープラットフォームからデータを統合しており、ベンダー名、材料カテゴリ、注文状況に不均一な空白が含まれているため、正確な支出分析やベンダー評価ができません。

エンリッチメント前: | PO_Number | Vendor_Name | Material_Category | Status | |-----------|-------------|-------------------|---------| | PO-8001 | "TechSupply Inc " | " Electronics " | "Delivered " | | PO-8002 | " TechSupply Inc" | "Electronics" | " Delivered" | | PO-8003 | "TechSupply Inc" | " Electronics" | "Pending" |

エンリッチメント後: | PO_Number | Vendor_Name | Material_Category | Status | |-----------|-------------|-------------------|---------| | PO-8001 | "TechSupply Inc" | "Electronics" | "Delivered" | | PO-8002 | "TechSupply Inc" | "Electronics" | "Delivered" | | PO-8003 | "TechSupply Inc" | "Electronics" | "Pending" |

出力: ベンダー名と材料カテゴリがすべての発注で標準化されました。3件すべての注文が同一ベンダー・カテゴリに正しく関連付けられています。

考察: クリーンアップにより、TechSupply Incが実は年間230万ドルの支出を持つ最大のベンダーであることがわかり、従来の分割された小型ベンダーではないことが判明。これによりベンダー交渉が改善され、量割引の機会も明確になりました。

例5: プロセス発見のためのアクティビティ名のクリーンアップ

シナリオ: 物流会社の出荷追跡システムで、スキャン装置や手入力で異なるスペースの問題があるアクティビティ名が存在し、プロセス発見結果が断片的で誤ったフローを示しています。

イベントログ前: | Case_ID | Activity | Location | Timestamp | |---------|----------|----------|-----------| | SHIP-901 | "Package Received " | "Warehouse A " | 2024-01-10 08:00 | | SHIP-901 | " Sorting" | "Warehouse A" | 2024-01-10 09:00 | | SHIP-902 | "Package Received" | " Warehouse A" | 2024-01-10 08:30 | | SHIP-902 | "Sorting " | "Warehouse A " | 2024-01-10 09:30 |

イベントログ後: | Case_ID | Activity | Location | Timestamp | |---------|----------|----------|-----------| | SHIP-901 | "Package Received" | "Warehouse A" | 2024-01-10 08:00 | | SHIP-901 | "Sorting" | "Warehouse A" | 2024-01-10 09:00 | | SHIP-902 | "Package Received" | "Warehouse A" | 2024-01-10 08:30 | | SHIP-902 | "Sorting" | "Warehouse A" | 2024-01-10 09:30 |

出力: アクティビティ名とロケーションの空白がすべてトリムされました。全出荷で「Package Received」から「Sorting」へのクリーンで直線的なフローが示されます。

考察: プロセス発見は、8つに分かれていたアクティビティのバリエーションではなく、標準の2ステッププロセスを正確に表示します。これにより、全パッケージが同じ初期処理をたどっていることが判明し、物流倉庫Aでの研修とリソース最適化を標準化できます。

出力

Trim Text エンリッチメントは、新しい属性を作成するのではなく、既存のテキスト属性をその場で修正します。ケースレベルおよびイベントレベルのすべての文字列型カラムが自動的に処理されます。エンリッチメントは以下の変換を適用します：

テキスト処理ルール:

先頭の空白（スペース、タブ、その他の不可視文字）をすべて削除
末尾の空白（スペース、タブ、その他の不可視文字）をすべて削除
テキスト内部のスペースは保持（先頭と末尾のみトリム）
トリム後に空になった文字列はnull値に変換
既にトリム済みのテキストは変更せず、パフォーマンスを最適化
非テキスト属性（数値、日付、ブール値）は変更しない
システムデータを保護するため、隠しカラムは変更しない

本エンリッチメントはmindzieStudioの他機能とシームレスに連携します。トリム済みテキスト属性は、正確な照合のためのフィルター、精密な連結計算、そして一貫したテキスト形式を必要とする他のエンリッチメントで即座に利用可能です。データをその場で修正するため、既存のビジュアライゼーション、ダッシュボード、分析は再設定なしにクリーニング済みデータの恩恵を自動で受けられます。

後続処理では、クリーンアップされたテキストにより、適合検証オペレーターが正しく一致するアクティビティを特定し、ルックアップエンリッチメントがデータセット間で正確にマッチングし、グループ化処理で関連ケースを適切に集約します。空文字列のnull変換はデータベース操作問題を防ぎ、プラットフォーム全体での空値ハンドリングを一貫させます。

本ドキュメントはmindzie Studioプロセスマイニングプラットフォームの一部です。