イベント数

概要

イベント数エンリッチメントは、プロセスデータセット内の各ケースに含まれるイベント数をカウントする基本的な統計オペレーターです。このエンリッチメントは、ケースの複雑さ、プロセスの変動、ビジネスプロセス全体の負荷分布を理解するための重要な指標を提供します。単純なケース数のカウントとは異なり、このオペレーターは各ケースを構成する個々の活動やイベントを数えるため、ケースの粒度やプロセスの強度についての洞察が得られます。

特定の条件に合致するイベントや活動のみをカウントできるフィルターと組み合わせることで、イベント数エンリッチメントは特に強力になります。例えば、手動活動のみ、システムイベントのみ、特定のリソースによって実行された活動のみをカウントすることが可能です。この対象を絞ったカウントにより、プロセスの挙動パターンの高度な分析が可能となり、通常のイベント頻度分布から逸脱したケースの特定に役立ちます。

主な用途

  • プロセス複雑性分析: ケースごとのイベント総数をカウントして複雑さを測定
  • 負荷評価: 異常に多いまたは少ないイベント数のケースを特定し、負荷分布を理解
  • 品質管理: 検査やレビューイベントのカウントによる品質基準の遵守確認
  • 自動化の機会評価: 手動イベントと自動化イベントのカウントで自動化可能性を特定
  • パフォーマンスベンチマーキング: ケースの種類、地域、期間ごとのイベント数を比較
  • 例外検出: 異常なイベント頻度のケースを特定し、プロセスの問題を検出
  • リソース計画: イベント数の量を把握してリソースやキャパシティの適切な割り当てを支援

設定

Filter（フィルター）: 定義された条件を満たす特定のイベントのみをカウントするための任意のフィルター設定。フィルターを適用しない場合は、各ケースのすべてのイベントがカウントされます。アクティビティ名、タイムスタンプ、リソース、その他のイベント属性に基づいたフィルターで、手動活動のみ、エラーイベントのみ、特定のシフト中に実行された活動のみをカウントするなどの目的に応じた分析が可能です。

New Attribute Name（新規属性名）: カウントしたイベント数を格納する新しいケース属性の名前。この属性は整数フィールドとしてケーステーブルに追加されます。特にフィルターを使用する場合は、どのイベントがカウントされているか明確に示す説明的な名前を選択してください。例: すべてのイベントの場合は "Total_Event_Count"、手動活動に絞った場合は "Manual_Activity_Count"、エラー関連イベントであれば "Error_Event_Count"。

事例

事例1: 購買注文の総イベント数

シナリオ: 調達チームは各ケースの総イベント数をカウントすることで、購買注文プロセスの複雑さを把握し、最も処理が多い注文を特定したい。

設定:

  • Filter: なし（すべてのイベントをカウント）
  • New Attribute Name: Total_PO_Events

出力: 「Total_PO_Events」という新しいケース属性が作成され、整数値を格納：

  • 標準注文: 8〜12イベント（作成、承認、ベンダーへの送付、受領、請求書、支払い）
  • 複雑な注文: 25〜40イベント（複数回の承認、変更要求、部分納品、紛争）
  • 急ぎの注文: 5〜7イベント（ステップを縮小した効率的な処理）

洞察: 調査では15％の購買注文が25イベント以上で、複雑な処理であることが判明。これらの高イベント数ケースは複数のベンダー交渉や承認エスカレーションと相関し、プロセス簡略化の機会を示唆している。

事例2: 保険請求における手動活動数

シナリオ: 保険会社は、システム自動イベントを除き、人間のエージェントが実行した活動だけをカウントし、請求処理にかかる手動作業の量を測定したい。

設定:

  • Filter: Activity Type equals "Manual" OR Resource Not equals "System"
  • New Attribute Name: Manual_Activity_Count

出力: 「Manual_Activity_Count」が作成され、人間の関与度を示す値を格納：

  • 自動承認済み請求: 2〜3回の手動活動（初回レビュー、最終承認）
  • 標準請求: 6〜10回の手動活動（レビュー、調査、調整、承認）
  • 複雑請求: 15〜25回の手動活動（複数レビュー、現地調査、交渉）
  • 不正請求: 30回以上の手動活動（広範な調査とレビューサイクル）

洞察: 20回以上の手動活動がある請求は処理時間が3倍、コストが2倍に。自動文書検証の導入により標準請求の手動活動を40％削減可能。

事例3: 製造業におけるエラーイベント追跡

シナリオ: 製造工場は、品質管理の失敗およびエラーイベント数をカウントし、注意が必要な生産ロットを特定したい。

設定:

  • Filter: Activity contains "Error" OR Activity contains "Reject" OR Activity contains "Rework"
  • New Attribute Name: Quality_Issue_Count

出力: 「Quality_Issue_Count」が作成され、生産バッチごとのエラー頻度を示す：

  • 高品質バッチ: 0〜1回のエラーイベント
  • 標準バッチ: 2〜4回のエラーイベント（軽微な調整）
  • 問題のあるバッチ: 8〜15回のエラーイベント（複数の品質問題）
  • 失敗したバッチ: 20回以上のエラーイベント（大規模な手直しが必要）

洞察: 10回以上のエラーイベントを持つバッチは特定の装置やシフトパターンと90％の相関。5回を超えた段階で早期介入すれば総バッチ失敗の60％を防止可能。

事例4: サービスデスクにおける顧客インタラクション数

シナリオ: サービスデスクでは、顧客が直接サポートシステムとやり取りしたイベントのみをカウントし、顧客との接触強度を測りたい。内部処理イベントは除外。

設定:

  • Filter: Resource contains "Customer" OR Activity contains "Customer" OR Activity in ["Email Received", "Chat Started", "Call Logged", "Feedback Submitted"]
  • New Attribute Name: Customer_Touch_Points

出力: 「Customer_Touch_Points」属性が作られ、インタラクション数を格納：

  • セルフサービス解決: 1〜2回のインタラクション（初回要求のみ）
  • 標準サポート: 3〜5回（要求、確認、解決確認）
  • エスカレーション対応: 8〜12回（複数のフォローアップと確認）
  • 重大インシデント: 15回以上（継続的な更新とコミュニケーション）

洞察: 8回以上の顧客インタラクションがあるチケットは満足度が70％低下。5回以降の積極的なコミュニケーションにより総インタラクション数が30％減少し満足度が向上。

事例5: 金融取引におけるコンプライアンスチェック数

シナリオ: 銀行は規制遵守のために各取引について実施されたコンプライアンスおよび検証活動数をカウントし、強化されたデュー・ディリジェンスが必要な取引を特定したい。

設定:

  • Filter: Activity Type equals "Compliance" OR Activity contains "Verify" OR Activity contains "AML" OR Activity contains "KYC"
  • New Attribute Name: Compliance_Check_Count

出力: 「Compliance_Check_Count」が生成され、検証活動数を示す：

  • 標準取引: 2〜3回のコンプライアンスチェック（基本的なAML、制裁スクリーニング）
  • 高額取引: 5〜8回のチェック（強化デュー・ディリジェンス）
  • 国際送金: 10〜15回のチェック（複数の管轄区検証）
  • フラグ付取引: 20回以上のチェック（完全な調査手順）

洞察: 2回未満のチェックは規制リスクが高い。15回以上のチェックは処理時間が5倍に増加するが、実際のコンプライアンス問題は2％に留まり、過検査の可能性が示唆される。

出力

イベント数エンリッチメントは、各ケースのイベント数を格納する単一の新しい整数属性をケーステーブルに作成します。この属性は、フィルター条件に合致した（またはフィルターがなければすべての）イベントの総数を表す整数値を格納し、データ型は Int32、表示形式は数値として設定されているため、分析やダッシュボードでの適切な数値フォーマットが保証されます。

新しい属性はすぐに以下の用途で使用可能です：

  • フィルター: イベント数の範囲に基づくケースフィルターの作成（例：「高複雑度ケース」イベント数 > 20）
  • 計算式: 数学的表現、平均値、統計計算でのイベント数活用
  • 分類: イベント数の閾値に基づくケースの複雑度カテゴリ分け
  • 可視化: ヒストグラム、箱ひげ図、ヒートマップによるイベント数分布の表示
  • 相関分析: イベント数とケースの他の属性（期間、コスト、結果）との関係分析
  • アラート: 異常なイベント数パターンに基づく監視ルールの設定

イベント数属性は、mindzie Studioの他の機能とシームレスに連携し、期間計算、コスト分析、パフォーマンス指標と組み合わせた包括的なプロセスインテリジェンスを実現します。

関連項目

  • [[Count Activities]]: 各ケース内で特定のアクティビティを名前でカウント
  • [[Case Duration]]: イベント数と相関関係にある時間ベースの指標を計算
  • [[Representative Case Attribute]]: 高イベント数または低イベント数のケースで最も一般的なパターンを特定
  • [[Filter Cases]]: イベント数を用いたプロセスデータのフィルターおよびセグメント化
  • [[Categorize Attribute Values]]: イベント数でカテゴリ（低/中/高複雑度）を作成

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