イベント順序

概要

イベント順序フィルターは、アクティビティ間の連続的な関係性に基づいてケースを識別します。特定のパターンに従って、あるアクティビティが別のアクティビティの後に続くケース(直接的に、最終的に、同日、または同時刻)を発見することができます。この強力なフィルターは、適合性チェック、プロセスバリアント分析、そして期待されるアクティビティの順序が実際にプロセスデータで発生したかを検出するために重要です。

このフィルターは4つの異なる関係タイプを提供し、異なる分析ニーズに対応します。必須のシーケンスが発生しているか検証したり(例:「支払い前の承認」)、標準手順に従うケースや違反ケースを見つけたり、アクティビティ間の時間的関係を分析したりするために使用できます。

主な用途

  • 適合性チェック: 必要なアクティビティシーケンスが正しい順序で発生しているか検証(例:「購入注文」は「入荷」より前にある必要がある)。
  • プロセス遵守: 承認アクティビティが実行アクティビティの直前にあり、その間に他のステップがないことを保証。
  • バリアント分析: 特定のアクティビティが最終的に別のアクティビティに続くケースを識別し、特定のプロセス経路に従うケースを抽出。
  • 根本原因調査: 問題のあるシーケンスが発生したケース(例:「品質チェック」の後の「手直し」)を特定。
  • 同時進行アクティビティ検出: 同時刻または同日に発生したアクティビティを持つケースを抽出し、データ品質問題や並列処理を示唆。
  • 例外処理: 定型アクティビティの後にエスカレーションアクティビティが発生したケースを見つけ、プロセス上の問題を検出。

設定

Activity First: シーケンス関係における最初のアクティビティ。2番目のアクティビティの前に発生するべきアクティビティです。

Activity Follows: シーケンス関係における2番目のアクティビティ。選択されたフォローメソッドに従い、1番目のアクティビティの後に発生するべきアクティビティです。

Follow Method: 2つのアクティビティ間でチェックする関係タイプを定義します:

  • Directly Follows: 2番目のアクティビティは、間に他のアクティビティがなく1番目に直後に続く必要があります
  • Eventually Follows: 2番目のアクティビティはケース内の任意の時点で1番目の後に発生する必要があります
  • Same Times: 両方のアクティビティは正確に同じタイムスタンプで発生する必要があります
  • Same Dates: 両方のアクティビティは同じカレンダー日付に発生する必要があります

Remove Filter: チェックが外れている場合(デフォルト)、フォローパターンにマッチするケースを返します。チェックが入っている場合は、パターンにマッチしないケースを返し、フィルターの論理を反転させます。

Attribute Name(オプション): アクティビティ名として分析するイベント属性カラムを指定します。指定がなければ、イベントログのデフォルトアクティビティカラムを使用します。

Compare Attribute Name(オプション): Directly FollowsまたはEventually Followsメソッドを使用する際に、追加の属性比較制約を追加します。より複雑なフィルタリング条件の構成が可能です。

Use Date If No Time(オプション): チェックが入っている場合、時間情報のないアクティビティに対して日付を使った並べ替えを適用します。Directly FollowsとEventually Followsメソッドにのみ関連します。

事例

事例1: 直接シーケンスの検証

シナリオ: 入荷が購入注文の作成に直接続くケースをすべて見つけたい。間にアクティビティがない、最もスムーズで迅速なケースの特定に役立ちます。

設定:

  • Activity First: "Create Purchase Order"
  • Activity Follows: "Goods Receipt"
  • Follow Method: Directly Follows
  • Remove Filter: オフ

結果: 「Create Purchase Order」の直後に「Goods Receipt」が発生し、承認や変更、保留などの他のアクティビティが挟まらないケースのみ返します。

インサイト: これらのケースは理想的なプロセスフローを示します。追加ステップがあるケースと比較することで、どの要因がスムーズな処理を可能にしているかが明らかになります(例えば、サプライヤー、部署、金額など)。

事例2: 最終的な関係の検出

シナリオ: 品質検査アクティビティのあるすべてのケースで、最終的に配送アクティビティに到達しているか確認したい。間に何ステップあっても関係ありません。

設定:

  • Activity First: "Quality Check"
  • Activity Follows: "Deliver Order"
  • Follow Method: Eventually Follows
  • Remove Filter: オフ

結果: 「Quality Check」の後、ケース内の任意の時点で「Deliver Order」が発生したすべてのケースを返します。途中に手直しや承認、他のアクティビティがあっても問題ありません。

インサイト: 品質検査済みのアイテムが最終的に配送されたことを確認できます。このフィルター結果に含まれないケースは、処理が完了していないか、品質検査後にキャンセルされた可能性があります。

事例3: 違反の検出

シナリオ: 承認なしに支払いが実行されたケースを見つけたい。会社方針違反の可能性があるため、フィルターを反転させて非準拠ケースを特定します。

設定:

  • Activity First: "Approve Payment"
  • Activity Follows: "Execute Payment"
  • Follow Method: Directly Follows
  • Remove Filter: オン

結果: 「Execute Payment」が「Approve Payment」に直接続かないケースを返します。承認が抜けているか、承認と支払いの間に他のアクティビティが発生していることを示します。

インサイト: 調査が必要な潜在的な適合違反を示すケースです。自動支払い、緊急処理、承認ワークフローの欠落が明らかになる可能性があります。

事例4: 同日発生日分析

シナリオ: 注文作成と配送が同日発生したケースを特定したい。迅速処理やデータ品質の問題を示唆します。

設定:

  • Activity First: "Create Order"
  • Activity Follows: "Deliver Order"
  • Follow Method: Same Dates
  • Remove Filter: オフ

結果: 実際の時間差に関係なく、両方のアクティビティが同じカレンダー日付で発生したケースを返します。

インサイト: 同日内での注文処理は以下を示す可能性があります:

  • エクスプレス出荷の要求
  • 迅速処理が可能なローカル配送
  • 特別対応の緊急注文
  • 予期しない場合はタイムスタンプエラーの可能性

事例5: 同時刻発生日検出

シナリオ: 異なる2つのシステムが正確に同じタイムスタンプでアクティビティを記録したケースを見つけたい。データ品質問題やバッチ処理の可能性があります。

設定:

  • Activity First: "System A Update"
  • Activity Follows: "System B Update"
  • Follow Method: Same Times
  • Remove Filter: オフ

結果: 両方のアクティビティが秒単位で完全に同一のタイムスタンプを持つケースを返します。

インサイト: 完全一致するタイムスタンプは以下を示唆します:

  • 複数システムを同時に更新する自動バッチ処理
  • タイムスタンプ記録の問題やデータインポートのエラー
  • より精密なタイムスタンプ精度の必要性
  • システム間統合の問題

事例6: 期待されるシーケンスがないケースの発見

シナリオ: 承認が最終的に実行に至らなかったケースを識別したい。キャンセルや停止したプロセスの可能性があります。

設定:

  • Activity First: "Approve Request"
  • Activity Follows: "Execute Request"
  • Follow Method: Eventually Follows
  • Remove Filter: オン

結果: 「Approve Request」の後に「Execute Request」がケース内で一度も発生しなかったケースを返します。

インサイト: 承認されたが実行されていないリクエストを示し、以下の可能性が考えられます:

  • キャンセルされた承認
  • 承認後に停止したケース
  • 介入が必要なプロセスの不具合
  • 実行待ちの承認リクエスト

出力

フィルターは、指定された連続的関係にマッチ(またはRemove Filterがチェックされている場合はマッチしない)するケースのみを含むデータセットを返します。各ケースのすべてのイベントおよび属性はフィルター結果に保持されます。出力されるケース数は通常、条件を満たさないケースが除外されるため、入力より少なくなります。

指定したシーケンス関係にマッチするケースが存在しない場合、フィルターは空の結果セットを返します。

技術的注意点

  • フィルタータイプ: ケースレベルフィルター(アクティビティの関係に基づきケース全体を削除)
  • アクティビティマッチング: アクティビティ名は大文字小文字を区別した完全一致で判定
  • 時間的論理: Directly FollowsとEventually Followsでは、アクティビティが時系列順に存在する必要あり
  • 検証: 指定したアクティビティが存在しない場合、類似のアクティビティ名を自動提案
  • パフォーマンス: 多数のアクティビティを含むケースでも高速にシーケンス検出できるよう最適化
  • 両アクティビティ必須: 含めるケースは指定した2つのアクティビティ両方を含むもの(反転ロジック時を除く)

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