重複イベントの削除

概要

重複イベントの削除エンリッチメントは、プロセスケース内の重複イベントを自動的に特定して削除する強力なデータ品質ツールです。ケース内で同じイベントが複数回、同一の属性値（アクティビティ名、タイムスタンプ、その他すべてのイベント属性）で出現した場合、このエンリッチメントは冗長なコピーを排除し、初回の出現のみを保持します。

このエンリッチメントは、複数のソースシステムからのデータ、データ統合プロセス、またはレガシーシステムで誤って重複イベントが作成される場合に特に有用です。重複を削除することで、プロセス分析が実際のプロセス実行を反映し、データ品質の問題に左右されることなく、正確なサイクルタイム、アクティビティ頻度、プロセスフローの可視化を実現します。

他のアクティビティ関連のエンリッチメントがイベントの修正や分類を行うのに対し、本エンリッチメントは重複イベントレコードを物理的にイベントログから削除し、データセットを恒久的にクリーンにします。元のデータソースからのすべてのイベント属性（計算・派生属性ではない）を比較して、2つのイベントが本当に同一であるかを判断します。

主な用途

  • 重複イベントレコードを含む可能性のある複数のソースシステムからインポートしたデータセットのクリーンアップ
  • データ統合プロセスやETLパイプラインで作成された冗長なイベントの削除
  • システムエラーやデータ同期問題によって生じた重複アクティビティ記録の排除
  • プロセスマイニング分析の前にデータ品質を改善し、正確な指標を確保
  • 重複イベントによるノイズを除去し、適合性検査用データセットの準備
  • レガシーシステムの問題により蓄積された重複を含む過去データのクリーンアップ
  • 重複イベントノイズを排除し、正確なアクティビティ頻度やサイクルタイム測定を実現

設定

このエンリッチメントに設定は不要です。各ケース内のすべてのイベントを自動的にスキャンし、重複を検出して削除するワンクリック操作です。

エンリッチメントは高度な比較アルゴリズムを使用し、

  • 各イベントの元のソースデータ属性（アクティビティ名、タイムスタンプ、ケースID、その他のイベントレベル属性）をすべて比較
  • 以前のエンリッチメントで追加された計算・派生属性は無視
  • 各ユニークなイベントの最初の出現を保持
  • すべての属性値が一致する重複イベントの後続分を削除

使用手順：

  1. 任意の分析画面から右上の「Log Enrichment」をクリックして「Log Enrichment」へ移動
  2. 「Add New」をクリックして新規エンリッチメントを作成
  3. Activitiesセクションから「Remove Duplicate Events」を選択
  4. 「Create」をクリック（追加設定は不要）
  5. 「Calculate Enrichment」をクリックしてデータセットを処理

事例

事例1：マルチシステム受注処理

シナリオ: EC企業がウェブ店舗、倉庫管理システム、会計システムの3つのシステムから注文データを取り込みます。データ統合の問題で、同じ注文のイベントが複数回、同一のタイムスタンプと値で記録されることがあります。

設定：

  • 無設定 - エンリッチメントが自動的に重複イベントを検出して削除

出力： エンリッチメント前のサンプルケースは以下のようなイベントを含むことがあります。

  • 2024-03-15 09:00:00 - Order Received - Order#12345 - Customer: ABC Corp - Amount: $1,500
  • 2024-03-15 09:00:00 - Order Received - Order#12345 - Customer: ABC Corp - Amount: $1,500（重複）
  • 2024-03-15 10:30:00 - Payment Processed - Order#12345 - Amount: $1,500
  • 2024-03-15 10:30:00 - Payment Processed - Order#12345 - Amount: $1,500（重複）
  • 2024-03-15 14:00:00 - Order Shipped - Order#12345

エンリッチメント後は、重複イベントが削除されます。

  • 2024-03-15 09:00:00 - Order Received - Order#12345 - Customer: ABC Corp - Amount: $1,500
  • 2024-03-15 10:30:00 - Payment Processed - Order#12345 - Amount: $1,500
  • 2024-03-15 14:00:00 - Order Shipped - Order#12345

洞察: 同社は、注文から出荷までのサイクルタイムを正確に5時間と測定できるようになり、重複イベントによる歪みを排除しました。アクティビティ頻度も実際のプロセス実行に基づく正確な数字になります。

事例2：医療患者経路

シナリオ: 病院がEHRシステム、放射線システム、調剤システムから患者データを統合。レガシーシステムからの移行時に患者イベントが複製され、患者のタイムラインに同じ処置が複数回表示され、アクティビティ数が膨らんでしまいました。

設定：

  • 無設定

出力： エンリッチメント前の患者ケース：

  • 2024-06-20 08:00:00 - Patient Admission - Patient ID: P9876 - Ward: Cardiology
  • 2024-06-20 09:15:00 - Blood Test Ordered - Test Type: CBC
  • 2024-06-20 09:15:00 - Blood Test Ordered - Test Type: CBC（検査システムによる重複）
  • 2024-06-20 11:30:00 - ECG Performed - Result: Normal
  • 2024-06-20 11:30:00 - ECG Performed - Result: Normal（放射線システムによる重複）
  • 2024-06-20 15:00:00 - Medication Prescribed - Drug: Aspirin
  • 2024-06-20 15:00:00 - Medication Prescribed - Drug: Aspirin（調剤システムによる重複）
  • 2024-06-21 10:00:00 - Patient Discharge

エンリッチメント後は重複が除去されます。

  • 2024-06-20 08:00:00 - Patient Admission - Patient ID: P9876 - Ward: Cardiology
  • 2024-06-20 09:15:00 - Blood Test Ordered - Test Type: CBC
  • 2024-06-20 11:30:00 - ECG Performed - Result: Normal
  • 2024-06-20 15:00:00 - Medication Prescribed - Drug: Aspirin
  • 2024-06-21 10:00:00 - Patient Discharge

洞察: 病院は患者経路を正確に追跡でき、各処置間の待機時間も真実値となりました。リソース利用率も重複分が除かれ、実態を反映します。

事例3：製造生産ライン

シナリオ: 製造工場のSCADAシステムがネットワーク同期問題で同じ機械操作を2回記録することがあり、これが生産分析を歪めています。

設定：

  • 無設定

出力： エンリッチメント前の生産ケース：

  • 2024-05-10 06:00:00 - Material Loaded - Batch: B1234 - Machine: Press-01
  • 2024-05-10 06:05:00 - Press Operation Start - Batch: B1234
  • 2024-05-10 06:05:00 - Press Operation Start - Batch: B1234（ネットワーク重複）
  • 2024-05-10 06:45:00 - Press Operation Complete - Batch: B1234
  • 2024-05-10 06:45:00 - Press Operation Complete - Batch: B1234（ネットワーク重複）
  • 2024-05-10 07:00:00 - Quality Inspection - Result: Pass
  • 2024-05-10 07:15:00 - Material Unloaded - Batch: B1234

エンリッチメント後：

  • 2024-05-10 06:00:00 - Material Loaded - Batch: B1234 - Machine: Press-01
  • 2024-05-10 06:05:00 - Press Operation Start - Batch: B1234
  • 2024-05-10 06:45:00 - Press Operation Complete - Batch: B1234
  • 2024-05-10 07:00:00 - Quality Inspection - Result: Pass
  • 2024-05-10 07:15:00 - Material Unloaded - Batch: B1234

洞察: 生産のサイクルタイム計算が正確になり、機械稼働率や真のボトルネック把握にノイズがなくなりました。

事例4：金融取引処理

シナリオ: 銀行の取引処理システムで、リアルタイム処理システムとバッチ照合システム両方を経由する際に重複ログが作成されることがあります。これらの重複は、取引パターンやコンプライアンス分析の前に除去する必要があります。

設定：

  • 無設定

出力： エンリッチメント前の取引ケース：

  • 2024-07-15 14:30:00 - Transaction Initiated - Amount: $5,000 - Account: 12345
  • 2024-07-15 14:30:05 - Fraud Check Performed - Risk Score: Low
  • 2024-07-15 14:30:05 - Fraud Check Performed - Risk Score: Low（照合システムによる重複）
  • 2024-07-15 14:30:10 - Authorization Approved - Auth Code: A789
  • 2024-07-15 14:30:10 - Authorization Approved - Auth Code: A789（照合システムによる重複）
  • 2024-07-15 14:30:15 - Transaction Completed - Status: Success

エンリッチメント後：

  • 2024-07-15 14:30:00 - Transaction Initiated - Amount: $5,000 - Account: 12345
  • 2024-07-15 14:30:05 - Fraud Check Performed - Risk Score: Low
  • 2024-07-15 14:30:10 - Authorization Approved - Auth Code: A789
  • 2024-07-15 14:30:15 - Transaction Completed - Status: Success

洞察: 銀行は取引処理時間を正確に測定し、実際の遅延箇所を特定可能になりました。コンプライアンス報告も重複による膨張がなくなります。

事例5：ITサービス管理

シナリオ: ITサービスデスクが複数の監視システムからチケットデータを取り込みます。システム間でインシデントがエスカレーションされる際、同じステータス変更イベントが複数回記録され、解決時間が長く見えることがあります。

設定：

  • 無設定

出力： エンリッチメント前のインシデントケース：

  • 2024-08-22 10:00:00 - Incident Created - Ticket: INC0012345 - Priority: High
  • 2024-08-22 10:15:00 - Assigned to L1 Support - Agent: John Smith
  • 2024-08-22 10:30:00 - Escalated to L2 - Reason: Complex Issue
  • 2024-08-22 10:30:00 - Escalated to L2 - Reason: Complex Issue（エスカレーションシステムによる重複）
  • 2024-08-22 11:45:00 - Issue Resolved - Resolution: Network Config Fix
  • 2024-08-22 11:45:00 - Issue Resolved - Resolution: Network Config Fix（エスカレーションシステムによる重複）
  • 2024-08-22 12:00:00 - Incident Closed - Satisfaction: 5/5

エンリッチメント後：

  • 2024-08-22 10:00:00 - Incident Created - Ticket: INC0012345 - Priority: High
  • 2024-08-22 10:15:00 - Assigned to L1 Support - Agent: John Smith
  • 2024-08-22 10:30:00 - Escalated to L2 - Reason: Complex Issue
  • 2024-08-22 11:45:00 - Issue Resolved - Resolution: Network Config Fix
  • 2024-08-22 12:00:00 - Incident Closed - Satisfaction: 5/5

洞察: IT部門はMTTR（平均解決時間）を正確に測定し、イベントの重複によるタイムライン分析の歪みを排除して真のパフォーマンスボトルネックを特定可能です。

出力内容

重複イベントの削除エンリッチメントは、イベントログから重複イベントレコードを物理的に削除します。新しい属性を追加するエンリッチメントとは異なり、ログ中のイベント総数を減らします。

削除されるもの：

  • 同じケース内で、すべての元のソースデータ属性（アクティビティ名、タイムスタンプ、ケースID、およびその他のイベント属性）が以前のイベントと一致するイベント
  • 各ユニークイベントの初回出現は残し、それ以降の重複だけを削除

保持されるもの：

  • 各ユニークイベントの最初の出現
  • 属性値のいずれかが異なるイベント（タイムスタンプやアクティビティ名が同じでも差異があれば保持）
  • 既存の計算属性や他エンリッチメントによる付加情報

データセットへの影響：

  • イベント数: 重複数に応じてイベント総数が減少
  • ケース数: 変更なし
  • アクティビティ統計: 実際のプロセス実行に基づく正確な頻度が反映
  • サイクルタイム: 重複によるゼロ期間計算がなくなり、より正確に
  • プロセスフロー: よりクリーンで正確なプロセスマップとバリアント分析

重要事項：

  • 本エンリッチメントは作業中のデータセットから重複イベントを恒久的に削除します。重複を含むオリジナルデータを保持したい場合は、適用前にバックアップやデータセットスナップショットを取得してください。
  • 比較対象は元のソースデータ列のみであり、以前のエンリッチメントで追加された計算・派生属性は含まれません。
  • 元の全属性値が完全に一致した場合のみ重複と見なされます。
  • イベントは時系列順に処理され、常に最初の出現が保持されます。

クリーンなデータの活用： 本エンリッチメント実行後は、

  • 重複ノイズのない正確なプロセスディスカバリーが可能
  • 信頼性の高いパフォーマンス指標やKPI計算
  • クリーンなデータによる適合性検査
  • 正確なプロセス可視化やダッシュボード作成
  • 他のエンリッチメントと組み合わせ、基盤データの信頼性が確保可能です

関連情報

関連するデータ品質エンリッチメント：

  • Remove Repeated Activities - 連続して発生する同一アクティビティを除去（本エンリッチメントは完全一致の重複イベントを削除）
  • Sort Log on Start Time - 分析前にイベントを正しい時系列順に並べる
  • Hide Attribute - 解析ビューから不要な属性を削除
  • Filter Process Log - 条件によりケースやイベントを除外
  • Anonymize - イベント属性の機微情報を削除または匿名化

データ品質のベストプラクティスについて：

  • データ品質ベストプラクティス - クリーンなプロセスデータの準備ガイドライン
  • Log Enrichment 概要 - mindzieStudioにおけるエンリッチメントのワークフロー理解

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