アクティビティのカウント
概要
アクティビティのカウントエンリッチメントは、プロセス内の各ケースで特定のアクティビティが何回発生したかを数える強力な統計ツールです。このエンリッチメントは、新しい整数属性を作成し、選択したアクティビティの実行回数の合計を集計します。これにより、アクティビティの頻度やプロセスパターンに関する定量的な洞察を提供します。異常なアクティビティパターンを持つケースの特定、期待されるプロセスステップの遵守状況の測定、異なるプロセス経路における作業負荷の理解に特に有用です。
単純なイベントカウントとは異なり、アクティビティのカウントではケース内のすべてのイベントではなく、関心のある特定のアクティビティに注目できます。この対象を絞ったアプローチにより、重要なプロセスステップの分析、手戻り（リワーク）アクティビティの頻度測定、承認サイクルのカウント、特定の例外発生頻度の追跡が可能になります。さらに、フィルタリングもサポートしており、定義した条件に基づいてケースの特定セグメント内でのみアクティビティをカウントすることができます。
よくある利用例
- 調達や財務プロセスにおける承認サイクル回数の追跡によるボトルネックの特定
- 製造プロセスにおける手戻りアクティビティのカウントによる品質問題やプロセス効率の測定
- 顧客サービスケースにおけるエスカレーション頻度の監視によるサービス品質の評価
- 自動化プロセスにおける手動介入の発生頻度の測定による自動化の機会の特定
- コンプライアンスが重要なプロセスにおける検証・確認ステップのカウントによる適切な管理の確保
- 営業プロセスにおけるフォローアップアクティビティ数の分析による顧客関与パターンの理解
- 例外処理アクティビティの追跡によるプロセス変動と改善機会の特定
設定
フィルター： ケースの特定セグメントにカウントを限定するための任意のフィルターです。フィルターを適用すると、その条件を満たすイベント内のアクティビティのみがカウントされます。特定の期間、ケース種類、条件に基づくアクティビティのカウントに便利です。フィルターを指定しない場合、ケース全体に存在する選択アクティビティのすべての発生がカウントされます。
新しい属性名： 各ケースのアクティビティカウントを格納する新しい整数属性の名前です。この属性はケーステーブルに追加され、選択したアクティビティが発生した合計回数を含みます。「ApprovalCount」「ReworkActivities」「EscalationFrequency」など、何をカウントしているのか明確に示す説明的な名前を選択してください。このフィールドは必須です。
アクティビティ名： カウント対象とするアクティビティを選択するマルチセレクトのドロップダウンです。データセット内のすべてのアクティビティから1つ以上選択できます。選択したすべてのアクティビティの合計発生数がカウントされます。たとえば「Review」と「Approve」を選択した場合、両方のアクティビティの合計カウントが算出されます。このフィールドは必須で、最低1つのアクティビティが必要です。
例
例1：購買注文における承認サイクルのカウント
シナリオ： 調達チームは、複数の承認サイクルを要した購買注文を特定したい。これらのケースは複雑な要件や不完全な書類により調達プロセスの遅延要因となっていることが多いため。
設定：
- 新しい属性名: "Total Approval Steps"
- アクティビティ名: ["Manager Approval", "Director Approval", "VP Approval", "CFO Approval"]
- フィルター: なし
出力： 新しいケース属性「Total Approval Steps」が作成され、整数値が格納される：
- ケース PO-2024-001: Total Approval Steps = 2（マネージャーとディレクター承認）
- ケース PO-2024-002: Total Approval Steps = 4（4段階すべての承認）
- ケース PO-2024-003: Total Approval Steps = 1（マネージャーのみ承認）
- ケース PO-2024-004: Total Approval Steps = 3（マネージャー、ディレクター、VP承認）
洞察： 3つ以上の承認ステップがあるケースを分析し、なぜ高度な承認が必要だったかを理解します。このデータは閾値違反、ポリシーへの例外、ルーチン購買の承認マトリックスの効率化機会の特定に役立ちます。
例2：製造品質管理における手戻りの測定
シナリオ： 製造工場は製品の手戻りや再検査の頻度を測定したい。これらの活動は生産効率や納期に直接影響を与えるため。
設定：
- 新しい属性名: "Rework Count"
- アクティビティ名: ["Quality Rejection", "Rework Process", "Re-inspection", "Repair"]
- フィルター: Department = "Production Line A"
出力： 手戻り頻度を示す「Rework Count」属性が作成される：
- ケース BATCH-5001: Rework Count = 0（初回品質合格）
- ケース BATCH-5002: Rework Count = 3（品質拒否、手戻りプロセス、再検査）
- ケース BATCH-5003: Rework Count = 1（単一の修理アクティビティ）
- ケース BATCH-5004: Rework Count = 5（複数の品質問題による多数の手戻り）
洞察： 手戻り回数が多いバッチは品質問題を示し、原因調査が必要です。シフト時間や操作者教育、原材料サプライヤーとの相関分析を行い、根本原因を特定できます。
例3：顧客サービスにおけるエスカレーションの追跡
シナリオ： 顧客サービスセンターは、サポートチケットが上位レベルにエスカレートされる頻度を監視したい。過剰なエスカレーションは複雑な問題や初期対応の不足を示します。
設定：
- 新しい属性名: "Escalation Count"
- アクティビティ名: ["Escalate to Tier 2", "Escalate to Tier 3", "Escalate to Supervisor", "Transfer to Specialist"]
- フィルター: Case Type = "Technical Support"
出力： 技術サポートケース用に「Escalation Count」が生成される：
- ケース TICKET-8901: Escalation Count = 0（Tier 1で解決）
- ケース TICKET-8902: Escalation Count = 2（Tier 2およびスペシャリストへエスカレーション）
- ケース TICKET-8903: Escalation Count = 1（Tier 2への単一エスカレーション）
- ケース TICKET-8904: Escalation Count = 4（複数回のエスカレーションが必要な複雑案件）
洞察： 多数のエスカレーションは長い解決時間と低い顧客満足度に連動します。この情報を使い、トレーニングの必要性の特定、ナレッジベースの改善、特定の問題タイプの直接的な適切レベルへの振り分けを行うことができます。
例4：自動化プロセスにおける手動介入の監視
シナリオ： 銀行はローン申請プロセスを自動化しているが、手動介入がどの程度必要かを追跡したい。これらの介入はシステムの限界や人間の判断を要する例外的ケースを示す。
設定：
- 新しい属性名: "Manual Intervention Count"
- アクティビティ名: ["Manual Review", "Override Decision", "Exception Handling", "Manual Verification"]
- フィルター: Process Type = "Auto Loan" AND Application Date >= "2024-01-01"
出力： 最近の自動ローン申請に対し「Manual Intervention Count」が作成される：
- ケース LOAN-2024-001: Manual Intervention Count = 0（完全自動処理）
- ケース LOAN-2024-002: Manual Intervention Count = 2（手動レビューと手動検証）
- ケース LOAN-2024-003: Manual Intervention Count = 1（特別条件のための上書き決定）
- ケース LOAN-2024-004: Manual Intervention Count = 3（複数の手動ステップが必要）
洞察： 手動介入がゼロの申請は自動化が成功していることを示し、多数介入のケースはシステム改善の機会や特別対応が必要なエッジケースの特定に役立ちます。
例5：営業プロセスにおけるフォローアップアクティビティの分析
シナリオ： 営業チームは案件管理プロセスでのフォローアップアクティビティ数を測定したい。これは取引成立に要する努力量を示し、リソース予測に役立ちます。
設定：
- 新しい属性名: "Follow Up Activities"
- アクティビティ名: ["Follow-up Call", "Follow-up Email", "Schedule Meeting", "Send Reminder", "Check-in Contact"]
- フィルター: Opportunity Stage != "Closed Lost"
出力： 進行中の案件向けに「Follow Up Activities」カウントが生成される：
- ケース OPP-2024-101: Follow Up Activities = 3（メール2回、電話1回）
- ケース OPP-2024-102: Follow Up Activities = 7（多忙なエンタープライズ案件）
- ケース OPP-2024-103: Follow Up Activities = 1（迅速な成約）
- ケース OPP-2024-104: Follow Up Activities = 5（複数の会議とリマインダー）
洞察： 多数のフォローアップ案件は顧客のためらいや複雑な意思決定プロセスを示し、高頻度案件に対する営業戦略の調整や経営層の関与が有効なケースを特定できます。
出力
アクティビティのカウントエンリッチメントは、「新しい属性名」設定で指定した名前の新しい整数属性をケーステーブルに作成します。この属性には、適用したフィルター条件に従って、選択したアクティビティの発生回数の総数が格納されます。
出力属性の特徴は以下の通りです：
- データ型： 整数（Int32）
- 値の範囲： 0 からいずれかのケースでの最大イベント数まで
- カラムタイプ： 派生属性
- 表示形式： 数値
新しい属性は、以下で即座に利用可能です：
- フィルター：特定のアクティビティカウント範囲のケースを識別（例：「Rework Count > 3」）
- 計算機：平均値、分布、他指標との相関の算出
- ダッシュボード：プロセス全体のアクティビティ頻度パターンの可視化
- 他のエンリッチメント：定量的アクティビティ測定を利用するもの
- プロセス適合性チェック：期待されるアクティビティ発生の検証
選択したアクティビティが一度も発生しなかったケースにはカウント0が設定され、特定プロセスステップを完全に回避したケースを簡単に識別できます。元のイベントデータは保持され、この解析レイヤーが追加されるため、プロセスの完全な透明性を維持しつつ統計的洞察を得られます。
このドキュメントはmindzieStudioプロセスマイニングプラットフォームの一部です。