2つのイベント属性間の期間

概要

「2つのイベント属性間の期間」エンリッチメントは、同一イベントレコード内の2つのタイムスタンプまたはタイムスパンフィールド間の時間差を計算します。この強力なエンリッチメントにより、個々のイベントに存在する関連する時間的データポイント間の経過時間を測定できます。たとえば、予定されたアポイントメント時間と実際の到着時間の差、または単一取引記録内のリクエスト送信と承認の間の時間などが挙げられます。

同一ケース内の異なるイベント間の期間を測定するエンリッチメントとは異なり、このオペレーターはイベントレベルの操作に特化しており、各イベントに既に存在する2つの日時またはタイムスパン属性を比較します。これにより、開始および終了タイムスタンプがソースシステムの別々のフィールドでキャプチャされている遅延、リードタイム、およびターンアラウンド指標の分析に特に有用です。エンリッチメントはDateTime型とTimeSpan型の両方の属性タイプをサポートし、多様なタイミングシナリオで最大の柔軟性を提供します。

このエンリッチメントは計算された期間を含む新しいイベントレベルのタイムスパン属性を作成し、これをフィルター、可視化、パフォーマンス分析で使用してボトルネックの特定、サービスレベル遵守の測定、プロセスインスタンス全体のタイミング変動の理解を支援します。計算は（Attribute Last - Attribute First）として実行され、イベントが遅延した場合は正の期間、早期に完了または予定より早い場合は負の期間が得られます。

よくある利用例

医療プロセスで、予定されたアポイントメント時間と実際の患者到着時間の間の時間差を測定して、アポイントメント遅延を計算
同一取引記録内でリクエスト送信タイムスタンプと承認タイムスタンプを比較して承認ターンアラウンドを測定
約束された配達日と実際の配達日の差を計算し、出荷遅延を追跡
顧客問い合わせのタイムスタンプと最初の対応タイムスタンプの間の時間差を測定して応答時間を分析
メンテナンス作業の予定開始時間と実際の開始時間を比較しスケジュール遵守を評価
書類受領タイムスタンプと処理完了タイムスタンプの間の時間を計算し処理効率を測定
サポートチケットの作成から最初の対応までの時間を計測しSLA遵守を監視
製造スケジュールの計画開始時間と実際の開始時間の差を比較し製造スケジュールのばらつきを追跡

設定

新規属性名: 計算された時間差を格納する新しいイベント属性の名前。この属性はTimeSpanデータ型として作成され、他のイベント属性とともにイベントテーブルに表示されます。「承認遅延」「配達ばらつき」「処理時間」など、何の期間を測定しているかが明確に分かる説明的な名前を選択してください。組織の命名規則に準拠し、フィルターや可視化で意味を成す名前であることが重要です。有効な属性名を受け入れ、後続分析で計算された期間を参照する識別子となります。

Attribute Name First: 期間計算における開始時刻を含むイベント属性。この属性は既存のDateTimeまたはTimeSpan属性でなければなりません。たとえばアポイントメント遅延の測定では「Scheduled Appointment Time」フィールドが該当します。ドロップダウンは有効なDateTimeおよびTimeSpan属性のみを表示し、計算済みや非表示属性は除外されます。これにより適切な時間的データの選択が保証されます。

Attribute Name Last: 期間計算における終了時刻を含むイベント属性。この属性も既存のDateTimeまたはTimeSpan属性でなければなりません。アポイントメント遅延の例なら「Actual Arrival Time」が該当します。計算は（Attribute Name Last - Attribute Name First）として行われるため、時間的に後のタイムスタンプをここで選択してください。正の値は2つ目のタイムスタンプが1つ目の後であることを示し（遅延や期間）、負の値は2つ目のタイムスタンプが1つ目の前であることを示します（早期完了）。

例

例1: 医療アポイントメント遅延分析

シナリオ: 医療クリニックが、予定アポイントメント時間と実際の到着時間を比較し患者の遅延を測定したい。両タイムスタンプは予約システムの各予約イベントの個別フィールドとして記録されている。これらの遅延を把握することでスケジューリングの最適化と患者満足度向上を図る。

設定:

新規属性名: Appointment Delay
Attribute Name First: Scheduled Time
Attribute Name Last: Actual Arrival Time

出力: 「Appointment Delay」という新しいイベント属性が作成され、予定時間と実際到着時間の差をTimeSpan値で表す：

早く来院したイベントは負の期間（例：15分早い場合は -00:15:00）
ほぼ時間通りのイベントはゼロまたはほぼゼロ（例：2分遅れは 00:02:00）
遅れて到着したイベントは正の期間（例：45分遅れは 00:45:00）

サンプルデータ: | Patient ID | Scheduled Time | Actual Arrival Time | Appointment Delay | |------------|----------------|---------------------|-------------------| | P-1001 | 2024-01-15 09:00 | 2024-01-15 09:12 | 00:12:00 | | P-1002 | 2024-01-15 10:30 | 2024-01-15 10:25 | -00:05:00 | | P-1003 | 2024-01-15 14:00 | 2024-01-15 14:38 | 00:38:00 |

インサイト: クリニックは午後のアポイントメントで患者の35％が15分以上遅刻し、これがスケジュールの連鎖的遅延を引き起こしていることを発見。午後のスロット間にバッファ時間を追加するスケジューリングアルゴリズムへ調整し、全体の待ち時間を22％削減した。

例2: 購入発注承認ターンアラウンド

シナリオ: 調達部門が、購入発注の提出から承認までの時間を計測する必要がある。両タイムスタンプはERPシステムの各POレコード上の個別フィールドとして存在。承認のボトルネック特定やタイムリーな購買決定に役立つ。

設定:

新規属性名: Approval Turnaround Time
Attribute Name First: Submission DateTime
Attribute Name Last: Approval DateTime

出力: 「Approval Turnaround Time」という新しいイベント属性が作成され、各購入発注の承認までの経過時間を表示：

迅速な承認: 00:15:30 (15分30秒)
標準的な承認: 1.08:20:00 (1日8時間20分)
遅延した承認: 5.14:30:00 (5日14時間30分)

サンプルデータ: | PO Number | Amount | Submission DateTime | Approval DateTime | Approval Turnaround Time | |-----------|--------|---------------------|-------------------|--------------------------| | PO-8821 | $450 | 2024-02-10 08:30 | 2024-02-10 09:15 | 00:45:00 | | PO-8822 | $15,200 | 2024-02-10 10:00 | 2024-02-12 14:30 | 2.04:30:00 | | PO-8823 | $89,500 | 2024-02-10 11:20 | 2024-02-16 09:45 | 5.22:25:00 |

インサイト: 5万ドル以上の発注は平均4.5日で承認される一方、1000ドル以下のものは2時間未満で承認されていることが判明。低額購入に自動承認ワークフローを導入し、全体の承認時間を40％短縮した。

例3: 製造スケジュール遵守

シナリオ: 製造工場が生産の計画開始時間と実際の開始時間を追跡。各生産指示に予定開始時間と実際開始時間がMES（製造実行システム）に記録されている。ばらつきを測定しスケジュール精度と能力計画の効果を評価。

設定:

新規属性名: Start Time Variance
Attribute Name First: Planned Start Time
Attribute Name Last: Actual Start Time

出力: 「Start Time Variance」属性は生産開始の早遅を示す（早ければ負、時間通りならゼロ近傍、遅ければ正）：

早い開始は利用可能能力やスケジュール柔軟性を示す
遅い開始はスケジュールコンフリクトや上流遅延を表す
一貫したパターンは生産計画最適化に役立つ

サンプルデータ: | Work Order | Product Line | Planned Start Time | Actual Start Time | Start Time Variance | |------------|--------------|-------------------|-------------------|---------------------| | WO-5501 | Line A | 2024-03-05 06:00 | 2024-03-05 06:00 | 00:00:00 | | WO-5502 | Line B | 2024-03-05 08:00 | 2024-03-05 09:45 | 01:45:00 | | WO-5503 | Line C | 2024-03-05 12:00 | 2024-03-05 11:50 | -00:10:00 |

インサイト: ラインBは前のシフトの切替時間が長いため1～2時間遅れて始まることが一貫して判明。切替作業を並行化することで平均開始遅延を90分から15分に短縮し、生産能力を8％増加させた。

例4: カスタマーサポート応答時間

シナリオ: カスタマーサポート組織が、エージェントがサポートチケットへの最初の応答を行うまでの時間を計測。チケットシステムはチケット作成タイムスタンプと最初の応答タイムスタンプを個別フィールドとして記録。応答時間の監視はSLA遵守と顧客満足度の重要指標。

設定:

新規属性名: First Response Time
Attribute Name First: Ticket Created DateTime
Attribute Name Last: First Response DateTime

出力: 「First Response Time」属性が作成され、各チケットの最初の応答までの経過時間を示す：

優秀な応答: 00:08:30 (8分30秒)
SLA遵守: 00:55:20 (55分20秒)
SLA違反: 02:15:45 (2時間15分45秒)

サンプルデータ: | Ticket ID | Priority | Created DateTime | First Response DateTime | First Response Time | |-----------|----------|------------------|-------------------------|---------------------| | TKT-9001 | High | 2024-04-12 10:22 | 2024-04-12 10:30 | 00:08:00 | | TKT-9002 | Medium | 2024-04-12 11:15 | 2024-04-12 12:05 | 00:50:00 | | TKT-9003 | Low | 2024-04-12 14:30 | 2024-04-12 16:55 | 02:25:00 |

インサイト: 高優先度チケットの最初の応答は平均12分で、30分のSLA内であることを確認。一方で中優先度は平均75分で60分目標を超過。トリアージプロセスと人員配置を見直し、中優先度チケットを優先して処理することでSLA遵守率が78％から94％に向上。

例5: ロジスティクス配達実績

シナリオ: ロジスティクス企業が配達実績を分析するため、約束された配達日と実際の配達日を比較。両日付は出荷追跡システムで注文作成時と配達確認時に記録。配達ばらつき分析は運送業者のパフォーマンス問題の特定や顧客期待値管理に有用。

設定:

新規属性名: Delivery Variance
Attribute Name First: Promised Delivery Date
Attribute Name Last: Actual Delivery Date

出力: 「Delivery Variance」属性は配達が早い（負）、時間通り（ゼロまたは小さい正の数）、遅い（正）を示す：

早期配達: -1.00:00:00 (1日早い)
時間通り配達: 00:00:00 ～ 04:00:00 (時間通り～4時間遅れ)
遅延配達: 2.08:30:00 (2日8時間30分遅れ)

サンプルデータ: | Shipment ID | Carrier | Promised Delivery | Actual Delivery | Delivery Variance | |-------------|---------|------------------|-----------------|-------------------| | SHP-7701 | FastShip | 2024-05-20 17:00 | 2024-05-20 15:30 | -01:30:00 | | SHP-7702 | QuickCargo | 2024-05-21 12:00 | 2024-05-21 11:45 | -00:15:00 | | SHP-7703 | StandardPost | 2024-05-22 10:00 | 2024-05-24 14:20 | 2.04:20:00 |

インサイト: 配達の18％が1日以上遅延しており、そのうち65％はStandardPostに起因。運送業者とのサービスレベルを再交渉し、過去のパフォーマンスに基づく動的な運送業者選択アルゴリズムを導入。遅延配達率を18％から7％に削減し、顧客満足度スコアを15ポイント向上させた。

出力

「2つのイベント属性間の期間」エンリッチメントは単一の新しいイベントレベル属性を以下の特徴で作成します：

データ型: TimeSpan - 新属性はTimeSpan形式で期間値を格納し、2つの選択属性間の時間差を表します。TimeSpan値は正（2つ目のタイムスタンプが後）、負（2つ目が前）、またはゼロ（両者同時）になります。

属性の場所: 新属性はイベントテーブルに追加され、他のイベント属性と共にデータセットに表示されます。派生属性としてマークされ、イベントフィルターやイベント属性リストで閲覧可能であり、統計的エンリッチメントを使ってケースレベルに集約することも可能です。

計算方法: 各イベントで（Attribute Name Last - Attribute Name First）を計算します。いずれかのソース属性がnullまたは欠損の場合、そのイベントの新属性はnullのままとなり、誤ったゼロ値が生成されません。

表示形式: TimeSpan値は標準期間フォーマット（days.hours:minutes:seconds）で表示されます。例：

00:15:30 は15分30秒
1.08:20:00 は1日8時間20分
-00:05:00 は5分早い（負の値）

他機能との連携: 計算された期間属性は様々な用途で使用可能：

イベントフィルター: 期間閾値に基づくイベントのフィルタリング（例：応答時間が1時間超のイベントのみ表示）
ケース集約: Sum, Average, Min, Max エンリッチメントを用いてイベントレベル期間をケースレベルに集約
パフォーマンス分析: チャートで期間分布を可視化し外れ値を特定
計算式: カスタム計算式内で期間を参照し複雑なビジネスロジックに活用
適合性チェック: 許容期間範囲に基づく適合ルール定義

依存関係: エンリッチメントは設定で指定された2つのソース属性に依存します。ソース属性が名前変更、非表示、削除された場合、計算された期間属性は再設定が必要な場合や無効になることがあります。依存関係を追跡し、ソース属性の変更時には警告を表示します。

パフォーマンス考慮: 本エンリッチメントは各イベントごとに単純な減算演算を行うため、数百万件規模の大規模データセットでもパフォーマンス影響は最小限です。計算はエンリッチメント実行時に一度だけ行われ、結果が保存されるため、後続の分析では再計算の負荷がありません。

2つのイベント属性間の期間

概要

よくある利用例

設定

例

例1: 医療アポイントメント遅延分析

例2: 購入発注承認ターンアラウンド

例3: 製造スケジュール遵守

例4: カスタマーサポート応答時間

例5: ロジスティクス配達実績

出力

関連項目