日次アクティビティカウント

概要

日次アクティビティカウント計算機は、各カレンダー日のそれぞれのアクティビティが何回発生したかを追跡し、時間の経過に伴うアクティビティ頻度の詳細な内訳を提供します。日次イベントカウント計算機が日ごとのイベント総数を示すのに対し、この計算機はアクティビティタイプごとにカウントを分けるため、特定のアクティビティにおけるパターンや異常を識別できます。

この計算機はイベントレベルで動作し、アクティビティ名と日付の両方でデータをグループ化します。これにより、作業量の分布を理解したり、特定アクティビティのデータ品質の問題を特定したり、個々のプロセスステップにおける運用パターンを監視するのに特に有用です。

主な用途

特定の日にボリュームが急増または急減するアクティビティを特定する
特定アクティビティに影響するデータ品質の問題（特定日でのアクティビティデータの欠落など）を検出する
時間を通じた個々のプロセスステップの作業負荷パターンを分析する
日別のアクティビティごとの作業負荷を追跡し、人員配置のニーズを監視する
重要なアクティビティのデータ抽出の完全性を検証する
アクティビティ頻度の傾向を比較し、プロセス変更やボトルネックを特定する
特定プロセスアクティビティの季節的または周期的パターンを追跡する

設定

期間: 設定には期間オプションが含まれますが、計算機は現在カレンダー日（時間部分を無視し、日付部分のみ）で全データをグループ化しています。つまり、アクティビティの発生した時間に関係なく、全てのアクティビティカウントが日単位に集約されます。

標準フィールド:

タイトル: 計算機出力の任意のカスタムタイトル
説明: ドキュメント用の任意の説明文

例

例1: アクティビティ固有のデータ問題の検出

シナリオ: 請求処理チームが「Approve Invoice」アクティビティが特定の日にイベントログから欠落しているようだと報告しました。これはデータ抽出の問題なのか、実際に承認処理が行われなかったのかを確認したい。

設定:

タイトル: 「承認アクティビティの日次追跡」
説明: 「請求書承認データの完全性を検証」

出力:

計算機は3つの列を持つ表を表示します:

日付: イベントログの各カレンダー日
アクティビティ名: 発生した各アクティビティ名
カウント: その日そのアクティビティが何回発生したか

例の出力:

Date         Activity Name       Count
2024-03-10   Submit Invoice      234
2024-03-10   Approve Invoice     198
2024-03-10   Pay Invoice         156
2024-03-11   Submit Invoice      248
2024-03-11   Approve Invoice       0
2024-03-11   Pay Invoice          12
2024-03-12   Submit Invoice      241
2024-03-12   Approve Invoice     215
2024-03-12   Pay Invoice         187

洞察: 3月11日に「Approve Invoice」がゼロ件である一方、送信と支払いは継続しています。このパターンは実際の業務停止ではなく、支払いがある（前日156件、11日12件）にも関わらず承認がないため、データ抽出の問題を示しています。198件から0件への急激な減少と翌日の215件への回復は、1日分のデータ欠落があり調査が必要であることを確認します。

例2: アクティビティ作業負荷パターンの分析

シナリオ: カスタマーサービスのプロセスを管理しており、異なるタイプの顧客対応の毎日のボリュームパターンを理解し、適切な人員配置を最適化したい。

設定:

タイトル: 「カスタマーサービスアクティビティボリューム分析」
説明: 「人員配置最適化のための毎日ボリューム追跡」

出力:

出力は「Create Case」「Update Case」「Escalate Case」「Close Case」など複数週にわたるアクティビティの日次カウントを示します。各アクティビティごとに1本のラインを持つ折れ線グラフで表示すると以下が見えてきます:

「Create Case」は月曜日にピーク（週末の未処理が集約）
「Close Case」は金曜日にピーク（週末前の後処理）
「Escalate Case」は一貫して低ボリュームだが月末に急増
「Update Case」は平日に比較的安定

洞察: 月曜の新規ケース作成ピーク（他の平日より40～50%高い）は月曜の受付スタッフ増員が必要であることを示唆します。金曜の終了ピークは週末前の案件処理優先を示します。月末のエスカレーション増は請求サイクルに伴う顧客の緊急度上昇に対応し、上級スタッフをその期間に配置すべきことを示唆しています。

例3: 時間経過によるプロセス変更の特定

シナリオ: 組織は6月1日に新しい調達承認ワークフローを導入しました。新しい「Pre-Approval Review」アクティビティが一貫して使われているか、従来の「Standard Approval」の代替か補完かを検証したい。

設定:

タイトル: 「調達ワークフロー移行分析」
説明: 「新しい事前承認ステップの採用状況追跡」

出力:

5月と6月の両方の承認アクティビティの日次カウントを示します:

6月1日前:

Date         Activity Name           Count
2024-05-28   Standard Approval       145
2024-05-28   Pre-Approval Review       0
2024-05-29   Standard Approval       152
2024-05-29   Pre-Approval Review       0

6月1日以降:

Date         Activity Name           Count
2024-06-01   Standard Approval        89
2024-06-01   Pre-Approval Review      58
2024-06-02   Standard Approval        72
2024-06-02   Pre-Approval Review      78
2024-06-03   Standard Approval        45
2024-06-03   Pre-Approval Review     103

洞察: 新たなPre-Approval Reviewアクティビティは6月1日から現れ、その件数はスタッフが新プロセスを採用するに連れて日々増加しています（58、78、103）。一方Standard Approvalの件数は減少（145→89→72→45）しており、ワークフロー変更が意図通り機能していることを示します。合計（6月3日は147）は変更前（145〜152程度）とほぼ同じなので、新ステップは追加作業ではなく補完的役割を果たしています。6月中旬にはPre-Approval Reviewでほとんどの案件を処理し、Standard Approvalは例外的なケースで使われると予想されます。

出力

計算機は以下の列を含むデータテーブルを生成します:

Date (DateTime): アクティビティ発生のグループ化されたカレンダー日。時間部分は常に00:00:00（深夜）に設定され、日付のみでグループします。

Activity Name (Text): イベントログに表示されるアクティビティの正確な名称。アクティビティ名は大文字・小文字を区別し、完全一致がグループ化の条件です。

Count (Number): その特定日・特定アクティビティで発生した回数。常に正の整数で、個々のイベントの発生回数を表します。

出力は以下のように可視化可能です:

折れ線グラフ: 複数アクティビティの時間的推移（アクティビティごとに1本の線）
積み上げ棒グラフ: 日別アクティビティボリュームの構成比較
ヒートマップ: カレンダーグリッドで日付とアクティビティタイプごとの発生強度を表示
ピボットテーブル: アクティビティごとにグループ化し日付範囲の合計を表示、あるいは日付ごとにグループ化しアクティビティ分布を表示
フィルタービュー: 特定アクティビティや日付範囲に絞って表示

注意: ある日付に特定アクティビティが発生しなかった場合、そのアクティビティ日付の行は出力に含まれません（カウントが0で表示されることはありません）。実際に発生したイベントのみが記録されます。タイムスタンプが欠落しているイベントやアクティビティ名がnullのイベントは、データ品質に応じて除外されるか一括でグループ化されることがあります。

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