類似した時間内のアクティビティを削除

概要

「類似した時間内のアクティビティを削除」フィルターは、別のアクティビティの定義された時間ウィンドウ内で発生した特定のアクティビティイベントをケースから削除します。このイベントレベルのフィルターは、時間的に近すぎる冗長または重複したアクティビティを取り除くことでプロセスログをクリーンアップするために設計されています。削除対象のアクティビティ、比較対象のアクティビティ(または全アクティビティ)、および削除をトリガーする最大の時間差を指定します。

一般的な用途

  • 数秒または数分以内に発生する重複または冗長なアクティビティの削除
  • 失敗直後に発生する自動再試行イベントの除去によるログのクリーンアップ
  • トリガーアクティビティに対して近接して発生する冗長な通知イベントの除去
  • 短時間内にログされた重複データ入力アクティビティのフィルタリング
  • 同じアクティビティが誤って複数回ログされた場合のプロセスログの整理
  • 初回アクティビティの直後に発生するフォローアップアクティビティの除去

設定

削除するアクティビティ: ケースから削除したいアクティビティの名前。

比較対象のアクティビティ: 時間を比較する基準となるアクティビティ。空欄の場合は全てのアクティビティと比較します。

時間しきい値: イベント間の最大時間差。この時間ウィンドウ内に削除対象アクティビティが比較対象アクティビティの後に発生した場合、削除されます。

設定項目 目的
削除するアクティビティ 削除対象とするアクティビティイベントを指定 "Email Notification"
比較対象のアクティビティ タイミング比較の基準アクティビティ "Order Confirmed" または空欄
時間しきい値 削除をトリガーする最大時間差 "00:05:00"(5分)

例1: 重複するメール通知の削除

シナリオ: 注文管理システムが注文確認後数分以内に重複したメール通知を送信する場合があります。これらの重複する「Email Sent」イベントはプロセスログを散らかし、意味のあるプロセスステップを表しません。"Order Confirmed"アクティビティから5分以内に発生する「Email Sent」イベントを削除したい場合。

設定:

  • 削除するアクティビティ: "Email Sent"
  • 比較対象のアクティビティ: "Order Confirmed"
  • 時間しきい値: "00:05:00"(5分)

結果:

同じケース内で「Order Confirmed」イベントの5分以内に発生した「Email Sent」イベントは削除されます。例えば、ケース#12345で10:00:00に「Order Confirmed」があり、10:02:30に「Email Sent」がある場合、そのメールイベントは削除されます。一方で、別のケースで10:08:00に「Email Sent」があれば(8分後)、5分の時間しきい値を超えているため削除されずに残ります。

インサイト: この設定により、注文確認直後に必ず発生する冗長な通知イベントが除去されるため、実際のプロセスフローの把握が容易になります。残るメールイベントは正当な別個の通信を示し、重複通知はフィルタリングされるためログがクリーンになります。

例2: 自動再試行イベントの除去

シナリオ: 支払い処理システムは失敗した取引を30秒以内に自動的に再試行します。これらの自動生成された「Retry Payment」イベントは分析から除外し、後で行われる手動再試行のみを保持したい場合。

設定:

  • 削除するアクティビティ: "Retry Payment"
  • 比較対象のアクティビティ: "Payment Failed"
  • 時間しきい値: "00:00:30"(30秒)

結果:

「Payment Failed」の30秒以内に発生した「Retry Payment」イベントはログから削除されます。例えばケース#PAY-789で2:15:00に「Payment Failed」があり、2:15:15に「Retry Payment」がある場合、その再試行は削除されます。何時間後かの手動再試行はログに残ります。

インサイト: 自動システムによる再試行イベントを除去することで、重要な支払い処理ステップや手動介入に集中できます。正確なサイクルタイムや人間の介入が必要なケースの特定に役立ちます。

例3: 冗長なステータスチェックの削除

シナリオ: アプリケーションは自動監視により、「Status Check」アクティビティが他のアクティビティ直後にすぐに発生することがあります。これらは意味のあるプロセスステップではなく自動システムチェックなので、どのアクティビティの後でも1秒以内に発生する「Status Check」イベントを削除したい場合。

設定:

  • 削除するアクティビティ: "Status Check"
  • 比較対象のアクティビティ: (空欄、すべてのアクティビティと比較)
  • 時間しきい値: "00:00:01"(1秒)

結果:

任意のアクティビティの1秒以内に発生した「Status Check」イベントは削除されます。例えばケース#APP-456で11:30:00.000に「Document Upload」があり、11:30:00.500に「Status Check」が発生した場合(500ミリ秒後)、ステータスチェックは削除されます。1秒以上遅れて発生したステータスチェックは保持されます。

インサイト: 自動システム監視によるプロセスログの散らかりを防ぎ、ユーザーやスケジュールされたプロセスによる意図的なステータスチェックのみを保持します。プロセスの可視化がより正確になります。

例4: 重複するデータ入力のクリーンアップ

シナリオ: データ移行の際、同じ「Update Customer Info」アクティビティが1分以内に誤って2回ログされたことがあります。これらの重複した更新を削除し、履歴データをクリーンにしたい場合。

設定:

  • 削除するアクティビティ: "Update Customer Info"
  • 比較対象のアクティビティ: (空欄)
  • 時間しきい値: "00:01:00"(1分)

結果:

同じケースで「Update Customer Info」イベントが1分以内に発生した場合、2回目のイベントが削除されます。例えばケース#CUST-321で15:45:00と15:45:30に2つの同アクティビティがある場合、後者が削除されます。

インサイト: 移行時の重複や二重入力エラーによる履歴データのクリーンアップに役立ちます。ほぼ同時発生した重複を除去し、実際の顧客情報更新とプロセスメトリクスの精度向上を実現します。

出力

このフィルターはイベントレベルで動作し、ケースから個々のイベントを削除します:

  • 指定された「削除するアクティビティ」のイベントのみが対象
  • 時間しきい値内で比較対象アクティビティの後に発生したイベントが削除される
  • 時間比較は方向性を持ち(比較対象イベントの後のみを見る)
  • イベントが削除されてもケースはデータセット内に残る
  • その他すべてのイベント属性・プロパティは保持される
  • 削除条件に合致するイベントがなければ元データがそのまま返される

このフィルターを使用して、冗長、重複、またはシステム生成のアクティビティを取り除き、意味のあるプロセスステップに近いクリーンなログを作成できます。


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