アクティビティ間の時間
概要
アクティビティ間の時間フィルターは、2つの特定のアクティビティ間の期間に基づいてケースを選択します。このケースレベルのフィルターは、一方のアクティビティの選択された発生（最初または最後）と他方のアクティビティの選択された発生（最初または最後）との時間差を計算し、その比較ロジックを適用してケースをフィルタリングします。このフィルターは、異常な処理時間を持つケースの特定、ボトルネックの検出、時間ベースのサービスレベルアグリーメント（SLA）遵守の確認、プロセスパフォーマンスの分析に役立ちます。
時間の計算は常に次の式を使用します：（ActivityName2.Time - ActivityName1.Time）。どちらのアクティビティが時系列で先に発生したかに関わらず適用されます。一方または両方のアクティビティが見つからないケースは自動的に結果から除外されます。
よくある用途
- SLA遵守: 要求から履行までの時間がSLAの閾値を超えるケースの特定。
- ボトルネック検出: プロセス段階間の期間が異常に長いケースの発見。
- 迅速処理の特定: 主要なマイルストーン間で例外的に迅速に処理されたケースの発見。
- プロセス効率分析: 異なるケースカテゴリ間でのアクティビティ間の時間比較。
- 品質調査: ステップ間の経過時間が不十分なケース（品質上の手抜きの可能性）。
- ワークフロー最適化: アクティビティ間の時間パターンを分析し改善機会を特定。
設定
First Activity Name: 時間計算の最初のアクティビティを選択します。このアクティビティが複数回現れる場合、最初の発生か最後の発生かを選べます。
First Activity Occurrence: 各ケース内で最初のアクティビティの「最初」または「最後」の発生を選択します。
Second Activity Name: 時間計算の2番目のアクティビティを選択します。時間差は2番目のアクティビティのタイムスタンプから1番目のアクティビティのタイムスタンプを引いたものとして計算されます。
Second Activity Occurrence: 各ケース内で2番目のアクティビティの「最初」または「最後」の発生を選択します。
Comparison Method: 計算された時間差をどのように比較するかを選びます：
- Equal: 時間差が指定された値と正確に等しい
- Greater Than: 時間差が指定された値を超える
- Greater Than or Equal: 時間差が指定された値以上である
- Less Than: 時間差が指定された値未満である
- Less Than or Equal: 時間差が指定された値を超えない
- Between: 時間差が指定された範囲内にある（最小値を含み最大値を含まない）
Compare Value / Time Range: 比較方法に応じて、単一の時間閾値または最小および最大の時間境界を指定します。
例
例1: 注文から配送までの過剰な時間を持つケースの特定
シナリオ: 注文作成から配送までの時間が10日を超え、標準配送SLAに違反している購入注文を特定したい。
設定:
- First Activity Name: "Create Order"
- First Activity Occurrence: First
- Second Activity Name: "Deliver Order"
- Second Activity Occurrence: Last
- Comparison Method: Greater Than
- Compare Value: 10日
結果: 最初の「Create Order」イベントから最後の「Deliver Order」イベントまでに10日を超える時間が経過しているケースのみが返されます。
洞察: これらのケースはSLA違反であり、サプライチェーンの遅延、ベンダーのパフォーマンス問題、処理のボトルネックの調査が必要な可能性があります。
例2: 急速処理の検出
シナリオ: 提出から承認まで2時間未満で処理された保険請求を特定し、レビュー時間が不足している可能性を確認したい。
設定:
- First Activity Name: "Submit Claim"
- First Activity Occurrence: First
- Second Activity Name: "Approve Claim"
- Second Activity Occurrence: First
- Comparison Method: Less Than
- Compare Value: 2時間
結果: 請求の提出から承認まで2時間未満であったケースが選択されます。
洞察: これらの急速処理ケースは、適切な手続きや必要な文書の確認が行われたかの品質レビューが必要かもしれません。
例3: 支払い期間遵守のモニタリング
シナリオ: 請求書受領から30日以上60日未満の間に支払いが行われたケースを特定し、支払条件を満たしつつ早期割引を利用しなかったケースを見つけたい。
設定:
- First Activity Name: "Receive Invoice"
- First Activity Occurrence: First
- Second Activity Name: "Process Payment"
- Second Activity Occurrence: Last
- Comparison Method: Between
- Minimum Time: 30日
- Maximum Time: 60日
結果: 請求書受領から30日以上59日以下の間に支払いが行われたケースを返します（上限は除外）。
洞察: 支払いタイミングのパターン分析や運転資本の最適化、早期割引活用の機会を特定するのに役立ちます。
例4: 承認ターンアラウンドタイムの分析
シナリオ: ローン申請の提出から24時間以内に承認決定が行われたケースを特定したい。
設定:
- First Activity Name: "Submit Application"
- First Activity Occurrence: First
- Second Activity Name: "Approval Decision"
- Second Activity Occurrence: First
- Comparison Method: Less Than or Equal
- Compare Value: 24時間
結果: 提出から決定まで24時間以内のケースが選択されます。
洞察: 迅速な処理で、顧客の期待に応える効率的な運用例です。
例5: 製造の停滞ケースの発見
シナリオ: 最後の品質検査から最初の出荷準備活動まで48時間以上経過した製造ケースを発見したい。
設定:
- First Activity Name: "Quality Inspection"
- First Activity Occurrence: Last
- Second Activity Name: "Prepare Shipment"
- Second Activity Occurrence: First
- Comparison Method: Greater Than or Equal
- Compare Value: 48時間
結果: 最後の検査から出荷準備開始まで少なくとも48時間の遅延があるケースを返します。
洞察: 検査後の遅延を示し、在庫保持、リソース制約、調整問題の可能性を示唆します。
例6: 最低レビュー期間の検証
シナリオ: 初回レビュー開始から最終承認まで15分未満で完了した契約レビューを見つけ、適切な精査が行われなかった可能性を確認したい。
設定:
- First Activity Name: "Start Review"
- First Activity Occurrence: First
- Second Activity Name: "Approve Contract"
- Second Activity Occurrence: Last
- Comparison Method: Less Than
- Compare Value: 15分
結果: レビュー開始から最終承認まで15分未満のケースを選択。
洞察: これらのケースはルースタンプ承認の可能性があり、追加の精査やプロセス改善が必要かもしれません。
出力
このフィルターは、2つのアクティビティ間の指定された時間条件を満たすケースのみを含む新しいデータセットを返します。どちらかのアクティビティが見つからないケースは自動的に除外されます。
フィルター適用後のデータセットは、選択されたケースの元のすべてのイベントと属性を保持します。比較はケースレベルで行われるため、時間閾値を満たすかどうかに応じてケース全体が含まれるか除外されます。
このドキュメントはmindzieStudioプロセスマイニングプラットフォームの一部です。