選択されたアクティビティ頻度

概要

選択されたアクティビティ頻度フィルターは、各ケース内で特定のアクティビティが何回発生したかに基づいてケースを特定します。このケースレベルのフィルターはアクティビティの発生回数をカウントし、さまざまな比較演算子(より大きい、小さい、等しいなど)を使って閾値と比較します。このフィルターは、再作業パターン、繰り返しのアクティビティ、品質問題、および予想よりも多頻度または少頻度で発生するプロセスの非効率性を検出する際に非常に役立ちます。

アクティビティの存在または非存在をチェックするフィルターとは異なり、このフィルターは頻度のパターンに焦点を当てており、過剰な繰り返しや不十分な発生回数のケースを見つけることが可能です。包含モード(条件に合致するケースを保持)と除外モード(条件に合致するケースを削除)をサポートしています。

主な用途

  • 再作業検出: 承認やレビューのアクティビティが複数回行われたケースを特定し、再作業やプロセスの非効率性を示します。
  • 品質分析: 複数回の品質チェックアクティビティがあるケースを見つけ、潜在的な品質問題や過剰な検査を示唆します。
  • 例外処理: 頻繁にエラー処理アクティビティが発生するケースを見つけ、注視が必要な問題のあるケースを特定します。
  • プロセス遵守: 特定のアクティビティが正確に1回、または許容される頻度範囲内で発生しているかを確認し、規制遵守を支援します。
  • 異常検出: 通常のプロセスフローから逸脱した異常なアクティビティ繰り返しパターンのケースを発見します。
  • 効率最適化: 同じ作業を複数回実施しているケースを特定し、ボトルネックやプロセス改善の機会を明らかにします。

設定

アクティビティ: 各ケース内で発生回数を数えるアクティビティ名を選択します。ドロップダウンメニューには利用可能なアクティビティ名とその頻度統計が表示されます。

比較演算子: アクティビティの発生回数を閾値と比較する方法を選択します:

  • より大きい: アクティビティがN回より多く発生したケースを見つける
  • より小さい: アクティビティがN回未満に発生したケースを見つける
  • 等しい: アクティビティがちょうどN回発生したケースを見つける
  • 以上: アクティビティがN回以上発生したケースを見つける
  • 以下: アクティビティがN回以下に発生したケースを見つける
  • 等しくない: アクティビティがN回以外の回数発生したケースを見つける

閾値: 比較対象の数値を入力します(例:1、2、3)。

保持/削除: 条件に合致するケースを保持するか削除するかを選択します。

注意: アクティビティ名の比較は大文字・小文字を区別し、完全一致が必要です。フィルターの検証システムは、誤記されたアクティビティ名の訂正案を提示します。

例 1: 複数回の承認があるケースの検出

シナリオ: 「Approve Purchase Order」アクティビティが複数回発生し、再作業や複数承認ラウンドを示す購買注文を特定したい。

設定:

  • アクティビティ: "Approve Purchase Order"
  • 比較演算子: より大きい
  • 閾値: 1
  • 保持/削除: 条件に合致するケースを保持

結果: 「Approve Purchase Order」が2回以上発生したケースを返す。

洞察: このケースは以下を示す可能性があります:

  • 初回承認拒否による再提出
  • 発注内容の変更による再承認
  • 承認ワークフローの非効率性
  • 承認者のトレーニング機会
  • 承認遅延による潜在的なコスト影響

例 2: 過剰な再提出を除外

シナリオ: 「Submit Application」が3回を超えて発生するケースを除外したい。これらは異常値であり解析結果を歪める可能性がある。

設定:

  • アクティビティ: "Submit Application"
  • 比較演算子: より大きい
  • 閾値: 3
  • 保持/削除: 条件に合致するケースを削除

結果: 「Submit Application」が4回以上発生するケースを除外し、0〜3回のケースのみを保持。

洞察: 以下を支援します:

  • 通常ケースに解析を集中
  • 極端な異常値の除外
  • 特別調査対象の別グループの識別
  • 平均パフォーマンス指標の改善

例 3: 単一支払いトランザクションの検証

シナリオ: 各ケースで「Process Payment」が正確に1回発生していることを確認したい。複数回の支払いは返金や修正、データ品質の問題を示す可能性がある。

設定:

  • アクティビティ: "Process Payment"
  • 比較演算子: 等しい
  • 閾値: 1
  • 保持/削除: 条件に合致するケースを保持

結果: 「Process Payment」が正確に1回発生したケースのみ返す。

洞察: 除外されたケース(0回または2回以上の支払い)は以下を調査すべき:

  • 支払いアクティビティの欠如
  • 支払いの重複処理
  • 返金や修正のケース
  • データ品質の問題

例 4: 品質介入を要するケースの特定

シナリオ: 「Quality Check」が2回を超えて発生し、複数回の検査を必要とする品質問題を抱えた製品のケースを探したい。

設定:

  • アクティビティ: "Quality Check"
  • 比較演算子: より大きい
  • 閾値: 2
  • 保持/削除: 条件に合致するケースを保持

結果: 「Quality Check」が3回以上発生したケースを選択。

洞察: 以下を明らかにする可能性がある:

  • 繰り返す品質欠陥の製品
  • サプライヤ品質の問題
  • プロセス能力の課題
  • 根本原因分析の必要性
  • 製造スタッフへのトレーニング要件

例 5: 1回以上の発生があるケースの検出

シナリオ: 「Send Reminder」が1回以上発生したすべてのケースを識別したい。正確な頻度は問わない。

設定:

  • アクティビティ: "Send Reminder"
  • 比較演算子: より大きい
  • 閾値: 0
  • 保持/削除: 条件に合致するケースを保持

結果: 「Send Reminder」が1回以上含まれるケースを返す。

洞察: 以下を示す:

  • フォローアップのリマインダーが必要なケース
  • 顧客の応答パターン
  • コミュニケーションの有効性
  • 潜在的なプロセス遅延

例 6: アクティビティがないケースを除外

シナリオ: 「Customer Contacted」が全く発生しなかった(0回)ケースを除外したい。

設定:

  • アクティビティ: "Customer Contacted"
  • 比較演算子: 以下
  • 閾値: 0
  • 保持/削除: 条件に合致するケースを削除

結果: 「Customer Contacted」が0回のケースを除外し、少なくとも1回は顧客連絡があるケースのみ保持。

洞察: 分析を顧客対応のあるケースに集中させる:

  • 自動処理のケース除外
  • システム生成ケースの除外
  • 内部限定のワークフロー除外

出力

フィルターは指定された頻度条件に一致するケースのみを含む新しいデータセットを返します。返された各ケースは元のすべてのイベントと属性を保持します。指定されたアクティビティは、条件に応じて0回、1回、または複数回出現することがあります。

条件に合致するケースがなければ、フィルターは空の結果セットを返します。

出力は、以下のようなアクティビティの繰り返しパターンの理解に役立てられます:

  • 条件に合致するケースにおける平均繰り返し回数
  • 繰り返しアクティビティ発生間の時間
  • アクティビティ頻度と他の属性との相関
  • アクティビティの繰り返しがケースの期間やコストに及ぼす影響

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