日別アクティブケース数

概要

日別アクティブケース数計算機は、カレンダーの日ごとにどれだけのケースが進行中であったかを測定します。ケースは、開始されているがまだ完了していない場合に、その日「アクティブ」と見なされます。つまり、その日以前に少なくとも1つのイベントがあり、その日以降にも少なくとも1つのイベントがあるケースです。

この計算機は、作業負荷の把握、能力制約の特定、ボトルネックの検出に特に有用です。活動数をカウントするイベントベースの計算機とは異なり、この計算機は進行中のユニークなケース数をカウントし、時間経過での進行中作業(WIP)レベルの洞察を提供します。

注: これはmindzie Studioの隠し計算機であり、標準の計算機メニューには直接表示されませんが、プログラム的または高度な設定経由でアクセス可能です。

主な用途

  • WIPレベルの監視による能力ボトルネックやリソース制約の特定
  • システム的問題を示すケースの過剰蓄積期間の検出
  • 季節的な作業負荷パターンの分析による人員配置とリソース配分の最適化
  • ケーススループットとサイクルタイムに対するプロセス変更の影響分析
  • ケース完了率がケース生成率に追いついているかの検証
  • 過去のアクティブケース数理解による能力計画の支援
  • 突発的なWIPスパイクなどの異常検出によるプロセス破綻の兆候把握

設定

この計算機は標準のフィルターコンテキスト以外の設定変更はありません。フィルターされたデータセット内のすべてのケースに対し、それぞれのカレンダー日付で進行中(アクティブ)であったケースを自動的に分析します。

アクティブケースの計算方法:

特定の日付でケースがアクティブとカウントされる条件は:

  • ケースの最初のイベントがその日付以前(ケースが開始済み)
  • ケースの最後のイベントがその日付以降(ケースがまだ完了していない)
  • すなわち、開始日から完了日まで(含む)の期間はケースがアクティブ

標準フィールド:

  • Title: 計算結果に対する任意のカスタムタイトル
  • Description: ドキュメント目的の任意説明文

例1: 能力ボトルネックの特定

シナリオ: 注文処理が遅延しており、管理側は増加するケース数がチームの処理能力を上回っているかを把握したい。アクティブケース数が完了数を上回る期間を特定する必要があります。

設定:

  • Title: 「注文処理のWIP分析」
  • Description: 「容量制約の特定のためのアクティブケース水準の追跡」

出力:

計算機は2列のテーブルを表示します:

  • Date: イベントログの期間中の日付
  • Active Case Count: その日に進行中だったケース数

出力例:

Date         Active Case Count
2024-01-15   487
2024-01-16   492
2024-01-17   501
2024-01-18   523
2024-01-19   558
2024-01-20   562
2024-01-21   559
2024-01-22   612
2024-01-23   648
2024-01-24   687
2024-01-25   724

洞察: 10日間で487から724にアクティブケース数が安定して増加していることは、新たなケースが既存のケース完了数を上回って到着していることを示します。この49%増加は能力ボトルネックを示唆します。増加率が初期の1日あたり+5ケースから後期の+37ケースに加速しているため、ボトルネックは悪化しています。管理側は人員レベルの適正やプロセスの遅延要因を調査すべきです。

例2: プロセス改善の影響評価

シナリオ: 3月15日に手動承認ステップを削減してケーススループットを加速するためのプロセス自動化を導入。自動化がWIPレベルを減少させたか測定したい。

設定:

  • Title: 「プロセス自動化の影響評価」
  • Description: 「自動化導入前後のWIPレベル比較」

出力:

自動化導入前後2週間のアクティブケース数:

自動化前(3月1日〜14日):

Date         Active Case Count
2024-03-01   856
2024-03-05   871
2024-03-10   883
2024-03-14   892

自動化後(3月16日〜30日):

Date         Active Case Count
2024-03-16   879
2024-03-20   823
2024-03-25   761
2024-03-30   698

洞察: 自動化は大きな効果をもたらしました。導入前は856から892へ(約4%増加)WIPが増加傾向にありましたが、導入後は879から698へ(約21%減少)WIPが減少しています。ケースの到着より完了が速くなり、スループットが向上したことを示します。2週間の安定した減少は一時的な効果ではなく持続的な改善です。

例3: 週末・祝日パターンの検出

シナリオ: 顧客サービスのチケット処理で、週末や祝日がWIPにどのように影響するかを分析し、週末対応の導入または自然な変動の許容を検討。

設定:

  • Title: 「顧客サービスWIPの週間パターン分析」
  • Description: 「週末の蓄積パターンを特定」

出力:

典型的な1ヶ月のアクティブケース数。折れ線グラフで可視化すると:

  • 月曜から金曜にかけて徐々に増加(約450から520へ)
  • 土曜・日曜は横ばいかわずかに増加(作業なしだが新規ケース到着)
  • 月曜は週末分の蓄積で急増(約580まで)
  • このパターンが週ごとに繰り返す

1週間のサンプルデータ:

Date         Active Case Count  Day of Week
2024-02-12   452               Monday
2024-02-13   463               Tuesday
2024-02-14   478               Wednesday
2024-02-15   495               Thursday
2024-02-16   518               Friday
2024-02-17   527               Saturday
2024-02-18   531               Sunday
2024-02-19   587               Monday

洞察: 週末にケース完了が停止し新着ケースが続くため、週末から月曜にかけて一貫した蓄積パターンが見られます(金曜518 → 日曜531 → 月曜587)。月曜の急増分56ケース(約10%増)は繰り返すキャパシティ課題を生みます。週末の蓄積を防ぐための限定対応、または月曜の人員増強が必要です。このパターンが複数週にわたり一貫しているため、偶発的変動ではなく構造的問題と推測されます。

例4: 季節的能力要求の分析

シナリオ: 買掛金処理が四半期末に大幅に増加する。季節的WIP変動を定量化し、ピーク時の一時的な人員増員の正当化を図る。

設定:

  • Title: 「四半期ごとの買掛金能力分析」
  • Description: 「通常期間と四半期末期間でのWIP比較」

出力:

四半期全体のアクティブケース数、明確なパターンが確認される:

通常期(四半期中頃):

Date         Active Case Count
2024-02-15   245
2024-02-20   238
2024-02-25   251

四半期末期間(最終週):

Date         Active Case Count
2024-03-25   312
2024-03-26   367
2024-03-27   423
2024-03-28   489
2024-03-29   537
2024-03-30   582
2024-03-31   641

洞察: 通常期間のWIP平均245に対し、四半期末の最終日は641まで増加(162%増)。最終週の急激な増加(312→641件、6日で329件増)は極度の能力圧迫を示します。このデータは四半期末の最後の週に一時的な追加人員を要請するか、「ソフトクローズ」ポリシーで請求処理を月内に平準化する根拠となります。

例5: データ品質問題の特定

シナリオ: データエンジニアリングチームがレガシーシステムからイベントログを移行したばかり。移行がケースのライフサイクル情報を正しく維持しているか、連続性に不自然なギャップがないか検証したい。

設定:

  • Title: 「データ移行検証 - ケース連続性チェック」
  • Description: 「アクティブケース数が論理的で連続しているか確認」

出力:

計算機が以下の異常データを検出:

Date         Active Case Count
2024-01-10   1,247
2024-01-11   1,289
2024-01-12   1,312
2024-01-13   47
2024-01-14   52
2024-01-15   1,278
2024-01-16   1,301

洞察: 1月13日に1,312から47へ急減し、1月15日に1,278まで回復するのは実ビジネスでは不可能な変動です。96%の一晩でのWIP減少と翌日の2,359%増加は移行エラーを示唆。1月13-14日のイベントが正しく移行されず、12日でケースが人工的に完了したように見えています。該当日付の移行スクリプト調査と欠落イベントの再取り込みを推奨します。

出力

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

Date (DateTime): イベントログ期間の各日のカレンダー日付。時間成分は常に00:00:00(真夜中)に固定されており、日付単位で集約します。日付範囲はフィルター適用後の最も古いイベントから最も新しいイベントまで。

Active Case Count (Number): その日に進行中だったユニークケース数。ケース開始日が当日以前で、終了日が当日以降のすべてのケースを含む。1日に複数イベントがあっても各ケースは1回のみカウント。

出力の可視化例:

  • 折れ線グラフ: WIPレベルの傾向、パターン、異常を特定するのに最適
  • 面グラフ: WIP作業量を塗りつぶした領域で表示し効果的
  • 棒グラフ: 特定期間や日付範囲でのWIP比較に有用
  • トレンド解析: 移動平均の適用で日々の変動を平滑化し基調を識別
  • 統計要約: 平均、中央値、標準偏差計算で典型的なWIPレベルと変動を把握

解釈のポイント:

  • 増加傾向: ケースの到着が完了より速い(能力不足またはボトルネック)
  • 減少傾向: ケース完了が到着より速い(過剰能力または需要減)
  • 安定パターン: 到着と完了が均衡している
  • 急激なスパイク: データ品質問題、プロセス異常、異常事象の可能性
  • 週間パターン: 週末効果や人員変動等を示すことが多い
  • 季節パターン: 循環的な業務需要を示し能力計画に活用可能

注意: 開始または終了のタイムスタンプが欠落したケースは分析対象から外れたり誤カウントされる可能性があります。すべてのイベントに有効なタイムスタンプがあることを確認して正確なアクティブケース数を取得してください。


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