大文字変換

概要

大文字変換エンリッチメントは、選択した属性のすべてのテキスト値をデータセット全体で大文字に変換するデータ標準化オペレーターです。この変換により、プロセスデータ全体で一貫したテキストフォーマットが保証され、大文字・小文字を区別しない照合、フィルタリング、分析操作が信頼性をもって実行できます。顧客名がシステムごとに異なる大文字・小文字で入力されている場合や製品コードに混在した大文字・小文字が含まれている場合など、複数ソースのデータでテキストの大文字・小文字が不一致である際に、このエンリッチメントは大文字の一貫したフォーマットを作成し、大文字・小文字に起因するデータ品質の問題を解消します。

テキストを大文字で標準化することで、同じ実体が大文字・小文字の違いで異なって見えてしまうというプロセスマイニングにおける一般的な課題に対応できます。たとえば、「Acme Corp」、「ACME CORP」、「acme corp」という顧客名は、標準化されなければ3つの異なる値として扱われ、分析結果が分散してしまいます。大文字変換エンリッチメントはこれらの変種を統一し、顧客分析、製品分類、リソース利用効率の正確な指標を提供します。この標準化は、パターン認識のために一貫したアクティビティ名や属性が必要となる適合性チェックの準備時に特に重要です。

このエンリッチメントは文字列属性をケース単位で処理し、元のデータ構造を保持しつつすべてのテキスト値を変換します。手動によるテキスト操作とは異なり、エラーや不整合を招くリスクがなく、自動化されたアプローチによりデータセット内のすべてのケースにおける選択属性のすべてのインスタンスが一様に変換されます。

主な用途

顧客名や企業識別子を標準化して正確な顧客ジャーニー分析とセグメンテーションを実現
異なるシステム間で大文字・小文字が不一致な製品コードやSKUを正規化
複数ソースのデータ統合時に大文字・小文字を区別しない照合の準備
ソースシステムが異なる大文字・小文字の慣習を使用している場合のアクティビティ名の一貫性確保
地域コード、部門名、組織単位の標準化による正確なリソース分析
フィルタリングやグルーピング操作の信頼性向上のための参照番号や識別子の一貫したフォーマット
外部システム連携で大文字フォーマットが求められる場合のテキストデータ準備

設定

Attribute Name: 大文字に変換したいテキスト属性を選択します。ドロップダウンリストにはデータセット内の非表示列を除くすべてのテキスト（文字列）属性が表示されます。必ず1つの属性を選択してください。このエンリッチメントは選択された属性のすべての値を処理し、小文字や混在したケースのテキストを大文字に変換し、既に大文字のものはそのまま保持します。選択可能なのは文字列型の属性のみです。

例

例 1: 受注処理における顧客名の標準化

シナリオ: 配送会社の受注管理システムには、ウェブ注文、電話注文、EDI伝送など異なる入力経路から一貫性のない大文字・小文字で顧客名が登録されており、顧客分析や受注量計算が断片化しています。

設定:

Attribute Name: Customer_Name

加工前: | ケース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 |

加工後: | ケース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 |

出力: Customer_Name属性のすべての値が大文字に変換されました。「Acme Corporation」の3つのバリエーションは「ACME CORPORATION」として統一され、「Beta Industries」の2バリエーションも「BETA INDUSTRIES」として標準化されました。

洞察: 標準化後、Acme Corporationは合計発送量が55,500であり（3つの別々の顧客としてではなく）、最大の取引先であることを特定しました。この正確な全体像により、適切な取引先の優先順位付けが可能になり、売上の30%が大文字・小文字の違いのある顧客から発生していることも明らかになりました。

例 2: 製造業における製品コードの正規化

シナリオ: 製造工場の品質管理システムでは、欠陥を製品コード別に追跡していますが、3つのシフトでオペレーターが異なる大文字・小文字のパターンでコードを入力しており、製品別の正確な欠陥率分析ができていません。

設定:

Attribute Name: Product_Code

加工前: | ケース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 |

加工後: | ケース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 |

出力: すべてのProduct_Code値が大文字に変換されました。製品A1234の3つの表記は「PRD-A1234」として統一され、製品B5678の2つの表記も「PRD-B5678」として標準化されました。

洞察: 標準化により、製品PRD-A1234は全シフトで60%の欠陥率（5回の製造で3つの欠陥）があることが判明し、迅速な品質調査が開始されました。以前は大文字・小文字の違う各バリエーション別に欠陥率が評価されていました。

例 3: 医療における部門コードの標準化

シナリオ: 病院の患者フロー管理システムで、スタッフが部門コードを不統一な大文字・小文字で入力しているため、患者の待機時間や部門利用率の正確なトラッキングが困難になっています。

設定:

Attribute Name: Department_Code

加工前: | ケースID | Patient_ID | Department_Code | Wait_Time | Priority | |---------|-----------|----------------|-----------|----------| | ADM-001 | P1234 | ER-main | 45 | 高 | | ADM-002 | P1235 | er-Main | 38 | 高 | | ADM-003 | P1236 | ER-MAIN | 52 | 緊急 | | ADM-004 | P1237 | icu-west | 15 | 中 | | ADM-005 | P1238 | ICU-West | 18 | 低 |

加工後: | ケースID | Patient_ID | Department_Code | Wait_Time | Priority | |---------|-----------|----------------|-----------|----------| | ADM-001 | P1234 | ER-MAIN | 45 | 高 | | ADM-002 | P1235 | ER-MAIN | 38 | 高 | | ADM-003 | P1236 | ER-MAIN | 52 | 緊急 | | ADM-004 | P1237 | ICU-WEST | 15 | 中 | | ADM-005 | P1238 | ICU-WEST | 18 | 低 |

出力: すべてのDepartment_Code値が大文字で標準化されました。救急部門コードの3つのバリエーションは「ER-MAIN」に統一され、ICU西部の表記も「ICU-WEST」になりました。

洞察: 標準化により、ER-MAIN部門の患者平均待機時間が45分で目標の30分を超過していることが特定され、リソースの再配分で待機時間を25%削減する対応が可能になりました。

例 4: 物流における地域コードの統一

シナリオ: 物流会社の配送追跡システムは、複数の予約チャネルから混在した大文字・小文字の地域コードが登録されており、地域別パフォーマンス分析やルート最適化に支障が生じています。

設定:

Attribute Name: Region_Code

加工前: | ケース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 |

加工後: | ケース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 |

出力: すべてのRegion_Code値が大文字に変換され、異なる大文字・小文字の表記が一貫した地域識別子として統一されました。

洞察: 標準化により、NA-WEST地域の全配送平均日数が3日でSLA要件を満たしていることが明確になりました。以前はばらばらの大文字・小文字のデータで分析が断片化し、一部地域のパフォーマンス低下が誤って示されていました。

例 5: 金融処理におけるステータスコードの正規化

シナリオ: 銀行の融資処理システムで、担当者が異なる大文字・小文字でステータスコードを入力しており、融資パイプライン段階の正確な追跡やプロセスのボトルネック特定が困難になっています。

設定:

Attribute Name: Status_Code

加工前: | ケース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 |

加工後: | ケース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 |

出力: すべてのStatus_Code値が大文字に標準化され、ステータスのバリエーションが統一され正確なパイプライン分析が可能になりました。

洞察: 標準化後、銀行は承認済みステータスの融資残高が170,000あることを明確に把握し（以前は50,000と誤認）、即時の資金調達手配が必要であると特定しました。保留中のステータスは185,000の申請が平均6日間審査中であり、追加の引受リソースが求められています。

出力

大文字変換エンリッチメントは選択されたテキスト属性をインプレースで変更し、すべての文字列値を大文字に変換します。変換は選択属性にのみ適用され、他の属性は変更されません。エンリッチメントは標準のテキスト文字すべてを扱い、小文字のアルファベット（a-z）を対応する大文字（A-Z）に変換し、大文字、数字、特殊文字、記号は変更しません。

変換後の属性は元の列名と位置を保持し、ケースレベルのデータ関係は維持されます。また、この属性はフィルター、計算式、その他のエンリッチメントで引き続き利用可能です。空文字列とnull値は適切に処理され、null値はnullのまま、空文字列は空文字列のまま保持されます。

このエンリッチメント適用後、標準化された大文字テキストはmindzie Studioの全体で信頼性の高い大文字・小文字を区別しない操作を可能にします。適合性チェックのように一貫したテキスト照合が重要な場面でも安心して利用できます。大文字値はTrime TextやReplace Textなど他のテキストベースのエンリッチメントとシームレスに連携し、計算やフィルターでの正確なグルーピングも支援します。

大文字変換

概要

主な用途

設定

例

例 1: 受注処理における顧客名の標準化

例 2: 製造業における製品コードの正規化

例 3: 医療における部門コードの標準化

例 4: 物流における地域コードの統一

例 5: 金融処理におけるステータスコードの正規化

出力

関連項目