ケース属性への変換

概要

「ケース属性への変換」エンリッチメントは、高度なデータ最適化オペレーターであり、イベントレベルの属性の値が各ケース内で一定である場合に、それらを自動的にケースレベルの属性に変換します。この強力なクリーンアップツールはデータセット全体を解析し、ケース内で変わらないイベント属性（顧客ID、製品カテゴリ、地域コードなど、イベントレベルで不必要に繰り返されている情報）を検出し、パフォーマンス向上とデータモデルの簡潔化のためにそれらをケース属性に引き上げます。

このエンリッチメントは、ソースシステムがイベントレベルに冗長なデータをエクスポートすることによって生じるプロセスマイニングの一般的なデータ品質問題を解決します。安定した属性を自動検出してケースレベルに変換することで、データの冗長性を削減し、クエリパフォーマンスを向上させ、より論理的なデータ構造を作成します。変換プロセスは完全に自動で設定不要のため、情報の完全性を保ちながらデータセットサイズを大幅に削減できるデータ準備の重要な初期ステップとなります。

一般的な用途

顧客情報が注文内で変わらず、イベント毎に繰り返されるERPデータの最適化
製造プロセスにおける製品のカテゴリ、ファミリー、タイプなどの静的属性をイベントレベルからケースレベルに変換
プロジェクト管理データセットでプロジェクトマネージャー、予算、所属部門など固定のプロジェクト属性を引き上げ
医療データで年齢層、保険種別、入院タイプなどの恒常的な患者属性をケースレベルへ移動
銀行プロセスデータにおいてローンタイプ、金利、支店コードなど安定した金融属性の変換
調達データのベンダ情報、契約番号、支払条件をケースレベルで整理
物流データの配送先国、サービスレベル、運送業者などの発送属性をケース属性に変換して最適化

設定

このエンリッチメントは完全に自動で動作し、設定は不要です。データセットのすべてのイベント属性を分析し、ケース内の値の一貫性に基づいて、ケース属性に安全に変換できるものをインテリジェントに判別します。

例

例1: 注文処理データの最適化

シナリオ: あるEコマース企業の注文処理システムは、顧客情報、配送詳細、注文特性を各イベントで不必要に繰り返してエクスポートし、データセットが必要以上に60%大きくなっている。

エンリッチメント前のイベントデータ: | Case ID | Activity | Customer_Name | Customer_Region | Order_Priority | Product_Category | Timestamp | |---------|----------|---------------|-----------------|----------------|------------------|-----------| | ORD-001 | Create Order | John Smith | North America | High | Electronics | 2024-01-10 08:00 | | ORD-001 | Verify Payment | John Smith | North America | High | Electronics | 2024-01-10 08:15 | | ORD-001 | Pick Items | John Smith | North America | High | Electronics | 2024-01-10 09:00 | | ORD-001 | Ship Order | John Smith | North America | High | Electronics | 2024-01-10 14:00 | | ORD-002 | Create Order | Jane Doe | Europe | Normal | Clothing | 2024-01-10 08:30 | | ORD-002 | Verify Payment | Jane Doe | Europe | Normal | Clothing | 2024-01-10 08:45 |

エンリッチメント後のケース属性: | Case ID | Customer_Name | Customer_Region | Order_Priority | Product_Category | |---------|---------------|-----------------|----------------|------------------| | ORD-001 | John Smith | North America | High | Electronics | | ORD-002 | Jane Doe | Europe | Normal | Clothing |

エンリッチメント後のイベントデータ: | Case ID | Activity | Timestamp | |---------|----------|-----------| | ORD-001 | Create Order | 2024-01-10 08:00 | | ORD-001 | Verify Payment | 2024-01-10 08:15 | | ORD-001 | Pick Items | 2024-01-10 09:00 | | ORD-001 | Ship Order | 2024-01-10 14:00 | | ORD-002 | Create Order | 2024-01-10 08:30 | | ORD-002 | Verify Payment | 2024-01-10 08:45 |

成果: Customer_Name、Customer_Region、Order_Priority、およびProduct_Categoryが各ケース内で変わらないことを検出し、自動的にケース属性に変換しました。イベントテーブルは60%小さくなり、重要なイベント固有情報のみを保持します。

洞察: 変換後、データ量減少によりダッシュボードのクエリ速度が3倍に向上。顧客セグメントや製品カテゴリのケースレベルでの絞り込みが直感的になり、ケース属性とイベント詳細の区別が明確になったことで、分析が容易になりました。

例2: 医療患者ジャーニーの最適化

シナリオ: 病院の患者管理システムが、患者の人口統計情報、保険情報、医療分類を治療の各イベントに繰り返しエクスポートしており、データセットが不必要に複雑で解析が遅くなっている。

エンリッチメント前のイベントデータ: | Case ID | Activity | Patient_Age_Group | Insurance_Type | Admission_Type | Department | Diagnosis_Code | Resource | |---------|----------|------------------|----------------|----------------|------------|---------------|----------| | PAT-501 | Registration | 45-60 | Private | Emergency | ER | CARD-01 | Nurse Smith | | PAT-501 | Triage | 45-60 | Private | Emergency | ER | CARD-01 | Dr. Jones | | PAT-501 | Treatment | 45-60 | Private | Emergency | ER | CARD-01 | Dr. Jones | | PAT-501 | Discharge | 45-60 | Private | Emergency | ER | CARD-01 | Nurse Brown |

エンリッチメント後:

ケース属性: | Case ID | Patient_Age_Group | Insurance_Type | Admission_Type | Diagnosis_Code | |---------|------------------|----------------|----------------|---------------| | PAT-501 | 45-60 | Private | Emergency | CARD-01 |

イベント属性（変動する値を保持）: | Case ID | Activity | Department | Resource | |---------|----------|------------|----------| | PAT-501 | Registration | ER | Nurse Smith | | PAT-501 | Triage | ER | Dr. Jones | | PAT-501 | Treatment | ER | Dr. Jones | | PAT-501 | Discharge | ER | Nurse Brown |

成果: 患者の人口統計や固定医療情報をケースレベルへ移動し、DepartmentやResourceは変動の可能性があるためイベント属性として残しました。データセットは40%小さくなり、より論理的に整理されました。

洞察: 最適化されたデータ構造により、患者コホート分析が高速化し、保険種別や年齢層のフィルターがケースレベルで即時に実行可能に。診断別のプロセスマイニング効率も向上し、病院は冗長なイベントデータを処理せずに特定患者群の治療パターンを迅速に把握できます。

例3: 製造プロセスデータのクリーンアップ

シナリオ: 製造工場のMESシステムは、生産ステップごとに製品仕様、注文詳細、品質基準が重複し、プロセス分析のパフォーマンスに問題が生じている。

エンリッチメント前: すべての生産イベントに含まれる属性：Product_ID、Product_Type、Material_Grade、Quality_Standard、Customer_Code、Order_Size、Target_Date

エンリッチメント後:

ケース属性に変換: Product_ID、Product_Type、Material_Grade、Quality_Standard、Customer_Code、Order_Size、Target_Date（生産単位内ではすべて一定）
イベント属性に残存: Activity、Timestamp、Machine_ID、Operator、Temperature、Pressure（変動値）

成果: 生産単位内で変わらない7つの属性が自動的にケースレベルに引き上げられました。イベントテーブルは、活動ごとに異なるプロセス実行の詳細に特化しています。

洞察: 変換によりデータセットサイズが65%減少し、これまでデータ量のために不可能だったリアルタイムプロセス監視が可能になりました。ケースレベルで製品タイプや材料グレードフィルターを簡単に使え、異なる製品カテゴリのKPIの監視も効率化されました。

例4: 金融ローン処理の簡素化

シナリオ: 銀行のローン処理システムは、申請データでローンパラメータ、顧客プロファイル、規制区分を各ワークフローステップに繰り返しエクスポートしており、コンプライアンスレポート作成やプロセス最適化が複雑化している。

エンリッチメント前のイベントデータ例: 各イベントに含まれる属性：Loan_Type、Interest_Rate、Loan_Amount、Credit_Score_Range、Branch、Region、Product_Code、Regulatory_Class、Customer_Segment

エンリッチメント後:

ケースレベル: 全ローンパラメータと顧客分類（9属性）をケーステーブルへ移動
イベントレベル: Activity、Timestamp、Approver、Decision、Commentsのみ残存

成果: ローンパラメータと顧客情報が申請プロセス中に不変であることを検出し、ケース属性に変換。イベントテーブルは主要なワークフロー情報のみとなりました。

洞察: 規制コンプライアンスレポートの処理が数時間から数分に短縮。信用スコア範囲やローンタイプ別の承認パターン分析がケースデータで即座に可能となり、プロセスマイニングは冗長イベントを処理せずに特定顧客セグメントのボトルネックを明確化します。

例5: サプライチェーンデータの最適化

シナリオ: ロジスティクス企業の追跡システムは、各スキャンポイントでサービスレベル、配送先、重量クラス、顧客アカウントといった固定された配送属性を何百万回も繰り返し記録している。

エンリッチメント前: 500,000件の出荷 × 15回のスキャンポイント × 8つの静的属性 = 6,000万個の冗長データポイント

エンリッチメント後:

ケース属性: Service_Level、Origin_Country、Destination_Country、Weight_Class、Customer_Account、Declared_Value、Shipment_Type、Contract_ID
イベント属性: Activity（スキャン位置）、Timestamp、Scanner_ID、Location_Code、Exception_Flag

成果: 8つの配送属性がケースレベルに変換され、各出荷に1度だけ保持し、スキャンごとの繰り返しを排除。イベントテーブルサイズは70%削減され、動的追跡情報のみ保持。

洞察: 配送先やサービスレベル別のルート分析がケースレベルのクエリで10倍高速化。顧客セグメント別の配送パターン把握や出荷特性に基づくルート最適化が効率化されました。リアルタイム追跡パフォーマンスも飛躍的に向上し、従来は不可能だったライブダッシュボード更新が可能になりました。

出力

「ケース属性への変換」エンリッチメントは、イベントレベルの属性をケースレベルにインテリジェントに移動することで、データセット構造を変更します。ケース内で値が変わらないイベント属性を包括的に分析し、自動的にケース属性に変換して最適なデータ構造を実現します。

変換プロセスの詳細:

Activity、Timestamp、Resourceなどのシステム列を除くすべてのイベントレベルデータ列を分析
属性ごとに、データセット内のすべてのケースで値が一定か判定
各ケース内のすべてのイベントで同一値の属性のみを変換対象とする
元の属性名およびデータ型を保持したまま変換
値がnullでない最後の値を利用してデータ整合性を維持

変換される属性例:

ケース内で一定のイベント属性（顧客ID、製品コード、カテゴリなど）
イベントレベルで不必要に繰り返される静的プロパティ（地域、タイプ、区分など）
ケースレベルに論理的に属する参照データ（契約番号、プロジェクトコード、注文特性など）

イベントレベルに残る属性例:

システム列（Activity、Timestamp、Start Time、Resource、Expected Order）
ケース内で変動する属性（異なるリソース、状態の変化、測定値など）
修正すべきでない非表示システム属性
すでに同じ名前のケース属性が存在するもの

データセットへの影響: このエンリッチメントにより、情報が論理的なレベルに整理されたよりクリーンで効率的なデータ構造が作成されます。ケースレベルのフィルタリングや集計が直感的となり、データ冗長性の削減によりクエリパフォーマンスが大幅に向上します。データセットのサイズは通常、冗長イベントデータの量によって30～70%減少します。

変換された属性はmindzieStudioの全機能とシームレスに連携します。フィルターはイベントデータをスキャンせずにケース属性を効率的にクエリ可能であり、計算機も集計関数なしにケース属性を直接参照できます。また他のエンリッチメントも最適化されたデータ構造の恩恵を受けます。プロセスディスカバリーやコンフォーマンスチェックは精錬されたイベントデータ上でより効率的に動作し、必要に応じてケース属性へのフルアクセスを維持します。

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