グループ内の前のケースまでの時間

概要

グループ内の前のケースまでの時間(enrichment)は、特定のグループやカテゴリ内で連続するケース間の経過時間を計算します。患者ID、リソース名、機械ID、部門などの共通属性でケースをグループ化することで、このエンリッチメントは、あるケースの開始時刻から同じグループ内の次のケース開始時刻までの間隔を測定します。この強力な時間的分析機能により、組織は作業負荷のパターンを理解し、リソース利用のボトルネックを特定し、詳細なスループットを測定できます。

このエンリッチメントは、キュー時間、リソースの可用性、運用のリズムを分析するのに特に有用です。例えば、医療分野では同じ医師の連続した患者訪問間の時間を測定し、製造業では同じ機械での生産稼働間の時間を追跡し、カスタマーサービスでは同じ担当者が処理するケース間隔を分析できます。このエンリッチメントは自動的に2つの新しいケース属性を作成します：前のケースまでの時間の経過と、その前のケースのケースID、つまり時間的および関係的な洞察を提供します。

単一ケース内の時間測定とは異なり、このエンリッチメントは複数のケースをまたいで作業の流れのパターンを理解します。リソースが十分に活用されているか、活動間の待機時間が過剰でないか、またプロセス内の異なるグループやカテゴリで作業負荷の分布がどのように異なるかを明らかにします。

主な用途

  • 医療リソース活用: 同一医師の連続した患者予約間の時間を測定し、スケジューリングのギャップを特定してクリニックの効率化を図る
  • 製造機械のスループット: 同じ機械の連続生産稼働間の時間を計算し、機械の稼働率を分析してアイドル時間を特定
  • カスタマーサービスのキュー分析: 同一担当者が処理するケース間の時間を追跡し、負荷分布と生産性を理解
  • ITインシデント管理: 同一技術者に割り当てられたチケット間の時間を監視し、負荷の均衡を取り過剰割当を防止
  • 調達サイクル分析: 同一サプライヤーからの連続注文間の時間を測定し、注文頻度の最適化とサプライヤー関係の維持を実現
  • 銀行取引パターン: 同一口座または顧客の取引間隔を分析し、不審なパターンや詐欺の指標を検出
  • 倉庫注文処理: 同じ場所からのピック間の時間を計算し、倉庫レイアウトを最適化して移動時間を短縮

設定

グループ化する属性: グループ化カテゴリーを定義するケース属性を選択します。この属性で同じ値を持つケースは分析のためにグループ化されます。一般的な選択肢にはリソース名（例：「Doctor」「Machine」「Agent」）、部門識別子、ロケーションコード、または作業の論理的なグループを表す任意のカテゴリ属性があります。エンリッチメントは同じグループ内の各ケースの開始時刻から前のケースの開始時刻までの時間を計算します。

新しい属性名: 作成される新しい期間属性の名前を指定します。この属性には、現在のケース開始時刻と同じグループ内の前のケース開始時刻との間の時間（時間単位）が含まれます。例えば「Time_Since_Last_Patient」や「Interval_Between_Orders」など、測定対象がわかる説明的な名前を選んでください。エンリッチメントは自動的に、指定した名前に「_CaseId」を付与した2つ目の属性も作成し、同じグループ内の前のケースのケースIDを保存します。

ケースのフィルタ（オプション）: 計算に含めるケースを制限するためにオプションのフィルタを適用できます。特定タイプのケースのみ分析したい場合や特定のシナリオを除外したい場合に便利です。例えば完了したケースのみ含める、キャンセルされた注文を除外する、特定の期間に絞るなどのフィルタを設定できます。フィルタに合致しないケースはグループ化や時間計算に含まれません。

例

例1: 患者予約スケジューリング分析

シナリオ: 医療クリニックが医師のスケジューリングを最適化するために、連続した患者予約の実際の時間間隔を理解したいと考えています。医師が患者間に過剰な待機時間があるか、予約がきつく詰まって患者の遅延が発生しているかを識別する必要があります。

設定:

  • グループ化する属性: 「Physician_Name」
  • 新しい属性名: 「Time_Since_Previous_Appointment」
  • ケースのフィルタ: なし（すべての予約を分析）

出力:

エンリッチメントは以下の2つの新しいケース属性を作成します：

  • Time_Since_Previous_Appointment: 同じ医師での現在の予約開始時間と直前の予約開始時間の間の時間（時間単位）
  • Time_Since_Previous_Appointment_CaseId: 直前の患者予約のケースID

結果サンプル:

Case ID Physician_Name Appointment_Start Time_Since_Previous_Appointment Time_Since_Previous_Appointment_CaseId
PT-001 Dr. Smith 2024-01-15 08:00 (null) (null)
PT-002 Dr. Smith 2024-01-15 08:30 0.5 PT-001
PT-003 Dr. Smith 2024-01-15 09:15 0.75 PT-002
PT-004 Dr. Jones 2024-01-15 08:00 (null) (null)
PT-005 Dr. Smith 2024-01-15 11:00 1.75 PT-003

洞察: クリニックは、Dr. SmithがPT-003とPT-005の間に1.75時間のギャップがあることを特定でき、これが休憩時間かスケジューリングの非効率によるものかを示唆します。全医師の間隔を分析することで、待機時間の短縮と各医師が患者に十分な時間を費やせるスケジューリングテンプレートの最適化が可能です。

例2: 製造機械の稼働率分析

シナリオ: 製造工場が各機械の連続生産稼働間の時間を分析して設備の活用状況を測定したいと考えています。これにより、未活用の資産を特定し、スループットを最大化するための生産スケジュールの最適化が可能になります。

設定:

  • グループ化する属性: 「Machine_ID」
  • 新しい属性名: 「Machine_Idle_Time」
  • ケースのフィルタ: Production_Status = "Completed"（キャンセルや失敗稼働を除外）

出力:

エンリッチメントは以下を作成します：

  • Machine_Idle_Time: 同じ機械での現在の稼働開始時間と前回稼働開始時間の差（時間単位）
  • Machine_Idle_Time_CaseId: 前の生産稼働のケースID

サンプルデータ:

Case ID Machine_ID Run_Start_Time Product_Type Machine_Idle_Time Machine_Idle_Time_CaseId
RUN-101 MCH-A01 2024-01-15 06:00 Widget-X (null) (null)
RUN-102 MCH-A01 2024-01-15 08:30 Widget-Y 2.5 RUN-101
RUN-103 MCH-A02 2024-01-15 06:00 Widget-Z (null) (null)
RUN-104 MCH-A01 2024-01-15 12:00 Widget-X 3.5 RUN-102
RUN-105 MCH-A02 2024-01-15 14:00 Widget-Y 8.0 RUN-103

洞察: MCH-A02は8時間の間隔があり、未活用かメンテナンスの問題を示唆。MCH-A01は2.5〜3.5時間の比較的一貫した稼働。工場管理者はこのデータを活用して生産スケジュールを調整し、追加能力の機会特定や長時間のアイドル原因調査を行えます。

例3: カスタマーサービス担当者の作業負荷分析

シナリオ: カスタマーサービスセンターが担当者ごとの連続するケース間の時間を測定し、作業負荷の分布を分析したいと考えています。これにより、一部の担当者に過負荷がかかっているかどうかを識別し、ケース振り分けの改善につなげられます。

設定:

  • グループ化する属性: 「Assigned_Agent」
  • 新しい属性名: 「Time_Between_Cases」
  • ケースのフィルタ: Case_Type = "Support Ticket"（内部タスクを除外）

出力:

エンリッチメントは以下を作成します：

  • Time_Between_Cases: 同じ担当者へ連続して割り当てられたケース間の時間（時間単位）
  • Time_Between_Cases_CaseId: 同担当者の前のケースID

サンプルデータ:

Case ID Assigned_Agent Case_Start_Time Priority Time_Between_Cases Time_Between_Cases_CaseId
TKT-501 Agent_Sarah 2024-01-15 09:00 High (null) (null)
TKT-502 Agent_Mike 2024-01-15 09:05 Medium (null) (null)
TKT-503 Agent_Sarah 2024-01-15 09:15 Low 0.25 TKT-501
TKT-504 Agent_Sarah 2024-01-15 09:30 High 0.25 TKT-503
TKT-505 Agent_Mike 2024-01-15 11:00 Medium 1.92 TKT-502

洞察: Agent Sarahは15分ごと(0.25時間)に新ケースを受けており、負荷が高い。一方、Agent Mikeは約2時間間隔で受けており、処理余力がある。サービスセンターはこのデータを利用してケース割り当てを再調整し、公平な作業負荷配分と最適な応答時間を確保できます。

例4: サプライヤー注文頻度分析

シナリオ: 調達部門がサプライヤーへの注文パターンを分析し、在庫管理とサプライヤー関係の最適化を図りたいと考えています。同一サプライヤーへの連続注文間の時間を測定し、注文統合や最適な頻度の維持機会を特定します。

設定:

  • グループ化する属性: 「Supplier_Name」
  • 新しい属性名: 「Days_Since_Last_Order」
  • ケースのフィルタ: Order_Status = "Approved"（却下または保留注文を除外）

出力:

エンリッチメントは以下を作成します：

  • Days_Since_Last_Order: 同じサプライヤーへの注文間の時間（時間単位、24で割れば日数に変換可能）
  • Days_Since_Last_Order_CaseId: 前回注文のケースID

サンプルデータ:

Case ID Supplier_Name Order_Date Total_Amount Days_Since_Last_Order Days_Since_Last_Order_CaseId
PO-1001 Acme Corp 2024-01-05 $5,000 (null) (null)
PO-1002 Beta Supply 2024-01-08 $12,000 (null) (null)
PO-1003 Acme Corp 2024-01-12 $3,200 168.0 PO-1001
PO-1004 Acme Corp 2024-01-15 $4,500 72.0 PO-1003
PO-1005 Beta Supply 2024-01-25 $15,000 408.0 PO-1002

洞察: Acme Corpには3〜7日（72〜168時間）ごとに注文があり、送料削減のため注文統合が有効かもしれません。Beta Supplyは17日ごと(408時間)の間隔で、まとまった注文に適した頻度と考えられます。調達部門はこの分析を駆使し、ボリュームディスカウント交渉や注文頻度最適化、良好なサプライヤー関係の維持に役立てられます。

例5: ITインシデント対応キュー管理

シナリオ: IT部門が技術者間のインシデント割り当ての負荷を分析し、技術者の過負荷を防止して均衡のとれた作業配分を確保したいと考えています。連続するインシデント割り当て間の時間を測定し、負荷不均衡を特定しチケットのルーティングを最適化します。

設定:

  • グループ化する属性: 「Assigned_Technician」
  • 新しい属性名: 「Incident_Assignment_Interval」
  • ケースのフィルタ: Incident_Type != "Informational"（行動不要なチケット除外）

出力:

エンリッチメントは以下を作成します：

  • Incident_Assignment_Interval: 同技術者に割り当てられた連続インシデント間の時間（時間単位）
  • Incident_Assignment_Interval_CaseId: 前回インシデントのケースID

サンプルデータ:

Case ID Assigned_Technician Assignment_Time Severity Incident_Assignment_Interval Incident_Assignment_Interval_CaseId
INC-201 Tech_Alex 2024-01-15 08:00 Critical (null) (null)
INC-202 Tech_Alex 2024-01-15 08:45 High 0.75 INC-201
INC-203 Tech_Jordan 2024-01-15 09:00 Medium (null) (null)
INC-204 Tech_Alex 2024-01-15 09:30 Critical 0.75 INC-202
INC-205 Tech_Jordan 2024-01-15 14:00 Low 5.0 INC-203

洞察: Tech Alexは45分（0.75時間）ごとに重要インシデントを受けており過負荷の可能性あり。一方Tech Jordanは5時間間隔で割り当てられています。IT管理者はこの情報を活用してインシデントルーティングを再調整し、重要案件を迅速に対応しつつ負荷の偏りを解消してサービス品質を維持できます。

出力

このエンリッチメントを実行すると、時間的および関係的な分析のために2つの新しいケース属性が作成されます。

主要期間属性（[指定した名前]）:

  • データ型: TimeSpan（10進数時間として表示）
  • 単位: 時間単位の期間
  • 値: 同じグループ内で前のケース開始時刻から現在ケース開始時刻までの経過時間
  • グループ内の最初のケース: Null値（前のケースが存在しないため）
  • 計算方法: グループごとに時系列でソートされたケースの現在の開始時刻から前のケースの開始時刻を引く

副次的ケースID属性（[指定した名前]_CaseId）:

  • データ型: 文字列（テキスト）
  • 値: 同じグループ内の前のケースのケースID
  • グループ内の最初のケース: Null値（前のケースが存在しないため）
  • 目的: 詳細分析や検証のために特定の前のケースへ遡ることを可能にする

出力値の理解:

期間の例と意味：

  • 0.25 = このグループ内の前のケースから15分経過
  • 2.5 = 2時間30分経過
  • 24.0 = 1日（24時間）経過
  • 168.0 = 1週間（7日）経過
  • null = グループ内の最初のケース、またはグループ属性がnullでグループに属さないケース

重要なグループ化の挙動:

  • ケースは「グループ化する属性」の値が完全一致するもの同士でグループ化される
  • 各グループ内ではケースが開始時刻で昇順にソートされる
  • 各ケースは同じグループ内の「直前のケース」とのみ比較される
  • グループ化属性がnullまたは空白のケースはグループ計算に含まれない
  • フィルタが適用されている場合、フィルタに合致するケースのみが「直前のケース」候補に含まれる

出力属性の利用方法:

これら新規属性はmindzieStudio全体で強力な分析に活用できます：

  • パフォーマンスダッシュボード: グループごとのケース間平均時間を可視化し、過剰なアイドル時間があるリソースや最適利用されているリソースを特定
  • ケースフィルタ: 間隔が極端に短い（過負荷）または長い（未活用）ケースを抽出し、重点的なプロセス改善が可能
  • 統計分析: 平均、中央値、標準偏差などの統計値を計算し、作業負荷分布のばらつきを理解
  • バリアント分析: リソース利用パターンに基づくプロセスバリアントを比較し、ベストプラクティスを明示
  • ボトルネック検出: 一貫して長い間隔のグループ（リソース、部門、ロケーション）を特定し、能力制約や非効率を特定
  • トレンド分析: 時間の経過に伴う間隔の変化を追跡し、プロセス改善や負荷変化の効果を測定
  • 関係分析: _CaseId属性を利用して連続ケース間の関係を作成し、パターンや異常の詳細調査を可能にする

他のエンリッチメントとの連携:

このエンリッチメントは以下と組み合わせて特に効果的です：

  • Categorize Attribute Values: 間隔を「正常」「遅延」「急ぎ」などのカテゴリに分類
  • Duration Between Two Activities: ケース内の活動間の期間とケース間の間隔を比較し包括的なサイクルタイム分析
  • Count Activities: ケースの複雑さ（活動数）とケース間間隔の相関分析によるリソース能力評価
  • Representative Case Attribute: _CaseIdを用いて前のケースから属性を取得し連続ケース比較

参照

関連する時間分析エンリッチメント:

関連するグルーピングと分析:

プロセス分析ツール:

  • Filter Process Log - 新しい間隔属性を含む条件でケースをフィルタリング
  • Performance Analysis - 間隔データをパフォーマンスダッシュボードやメトリクスに活用

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