アクティビティのケース所要時間カテゴリ
概要
アクティビティのケース所要時間カテゴリ エンリッチメントは、各ケース内で特定のアクティビティが発生するすべての回数に対して費やされた合計時間を分析し、その所要時間を「Fast（速い）」、「Normal（通常）」、「Slow（遅い）」、「Extreme（極端）」のパフォーマンスレベルに分類します。このエンリッチメントは、特定のアクティビティが過剰な時間を消費しているケースを特定し、プロセス改善に集中できるようにするのに非常に役立ちます。
単純な所要時間計算とは異なり、このエンリッチメントは、実際のデータ分布に基づいて統計的パーセンタイルを用いて最適なパフォーマンス閾値を自動的に決定します。各ケース内の選択したアクティビティのすべての所要時間を合計し、ケースライフサイクル全体でその特定のアクティビティにどのくらいの時間が投入されているかを包括的に把握します。これにより、承認、レビュー、品質チェックなど、ケース内で複数回発生する可能性があるアクティビティの分析に最適です。
主な活用例
- 購入注文処理: 総承認時間に基づいて案件を分類し、長時間の承認サイクルに陥っている注文を特定
- クレーム処理: 複数の調査アクティビティの総調査時間を分析し、多くのレビューが必要な複雑なクレームを発見
- 製造品質管理: 累積検査時間を測定し、繰り返し品質チェックが必要な製品を特定
- カスタマーサービス: 複数のサポート連絡における総顧客対応時間を追跡し、手間のかかる案件を特定
- ローン申請: 総アンダーライティング時間に基づいて申請を分類し、承認プロセスを効率化
- 医療患者フロー: 総診断検査時間を分析して患者の経路と資源配分を最適化
- ソフトウェア開発: 複数のコードレビューサイクルにわたる総コードレビュー時間を測定し、開発速度を向上
設定
Activity Name: パフォーマンス分類のために分析したいアクティビティを選択します。このエンリッチメントはケース内のこのアクティビティのすべての発生回数を合計し、所要時間の合計を分類します。必須であり、イベントログ内の既存アクティビティ名と完全に一致する必要があります。
Case Filter (Optional): 分析対象のケースを絞り込むためのフィルターを適用できます。ケース属性、時間範囲、その他の条件でフィルター可能です。性能閾値の計算はフィルター適用後のケースのみで行われ、新しいパフォーマンスカテゴリ属性もそのケースにのみ付与されます。フィルター外のケースは分類されません。
Fast Duration Threshold: ケースが「Fast」と分類される最大所要時間（時間単位）です。デフォルト（0）の場合、システムは選択したアクティビティのすべてのケース所要時間の20パーセンタイルを自動的に計算します。たとえば2時間に設定すると、2時間までの総アクティビティ時間のケースがFastに分類されます。
Normal Duration Threshold: ケースが「Normal」と分類される最大所要時間（時間単位）です。デフォルト（0）の場合、システムは80パーセンタイルを自動計算します。Fast閾値とこの値の間の所要時間はNormalパフォーマンスとみなされます。
Slow Duration Threshold: ケースが「Slow」と分類される最大所要時間（時間単位）です。デフォルト（0）の場合、システムは90パーセンタイルを自動計算します。NormalとSlow閾値の間はSlowに分類され、これを超えると「Extreme」となります。
例
例1: 請求承認のパフォーマンス
シナリオ: 財務チームは、承認プロセスで過剰な時間を費やしている請求書を特定したいと考えています。そうした請求書は手動介入や複雑な検証が必要なケースが多いためです。
設定:
- Activity Name: "Approve Invoice"
- Case Filter: なし（すべての請求書を分析）
- Fast Duration Threshold: 0（自動計算）
- Normal Duration Threshold: 0（自動計算）
- Slow Duration Threshold: 0（自動計算）
出力: エンリッチメントは「Approve Invoice - Case Performance」という新しいケース属性を作成し、以下の値を付与します。
- Fast: 総承認時間が下位20％（例：2時間未満）の請求書
- Normal: 標準的な承認時間（例：2～24時間）
- Slow: 通常より長い時間（例：24～72時間）
- Extreme: 例外的に遅延が生じている（例：72時間超）
洞察: 財務チームは「Extreme」ケースをフィルターして調査し、書類の不備、金額の紛争、プロセス上のボトルネックなどの原因を特定できます。
例2: 患者診断検査
シナリオ: 病院は救急部門の来院患者を、診断検査（レントゲン、CTスキャン、検査室作業）に費やされた総時間に基づいて分類し、患者フローと資源割り当てを改善したいと考えています。
設定:
- Activity Name: "Perform Diagnostic Test"
- Case Filter: Department = "Emergency"
- Fast Duration Threshold: 1（時間）
- Normal Duration Threshold: 3（時間）
- Slow Duration Threshold: 5（時間）
出力: 「Perform Diagnostic Test - Case Performance」という新属性が作成され、来院患者ごとに分類されます:
- Fast: 最小限の検査時間（総合計1時間未満）
- Normal: 標準的な診断処理時間（1－3時間）
- Slow: 複雑かつ時間を要する検査（3－5時間）
- Extreme: 診断に非常に長時間要する重症例（5時間超）
洞察: 「Extreme」ケースは複数の専門医を必要とすることが多く、検査間の待機時間を減らすために専任の複雑症例コーディネーターの導入が有効と判明。
例3: ソフトウェアコードレビューログ
シナリオ: 開発チームは、複数回のレビューサイクルにわたって過剰に時間を要しているプルリクエストを特定し、デプロイ速度への影響を理解したいと考えています。
設定:
- Activity Name: "Code Review"
- Case Filter: Repository = "Core Platform"
- Fast Duration Threshold: 0（自動計算）
- Normal Duration Threshold: 0（自動計算）
- Slow Duration Threshold: 0（自動計算）
出力: 「Code Review - Case Performance」という新属性を自動計算閾値で生成します。
- Fast: 迅速にレビューされたPR（例：総レビュー時間4時間未満）
- Normal: 標準的なレビュー時間（4～16時間）
- Slow: 詳細なレビューが必要なPR（16～24時間）
- Extreme: 例外的に多大なレビュー工数（24時間超）
洞察: 「Extreme」ケースはアーキテクチャ変更やドキュメント不足が主因であることが多く、チームはより良いPRテンプレートと設計レビュー体制の導入を決定。
例4: 製造品質検査
シナリオ: 製造工場は、過剰な品質検査時間を要する製品を特定し、生産上の問題や設計欠陥を早期に発見したいと考えています。
設定:
- Activity Name: "Quality Inspection"
- Case Filter: Product Line = "Premium Series"
- Fast Duration Threshold: 0.5（30分）
- Normal Duration Threshold: 2（時間）
- Slow Duration Threshold: 4（時間）
出力: 「Quality Inspection - Case Performance」という属性を新規作成し、以下の値を付与します:
- Fast: 迅速に通過した製品（合計30分未満の検査時間）
- Normal: 標準検査時間（30分～2時間）
- Slow: 詳細検査が必要な製品（2～4時間）
- Extreme: 重大な品質問題を抱える製品（4時間超）
洞察: 「Extreme」カテゴリーの製品は特定の生産バッチと強く関連し、設備の調整不良が判明し事前対応が可能に。
出力
このエンリッチメントは以下の特徴を持つ新しいケース属性を生成します。
属性名: 「[Activity Name] - Case Performance」（例: "Approve Invoice - Case Performance"）
データ型: 文字列（カテゴリカル）
可能な値:
- Fast: 総アクティビティ時間が最速パフォーマンスのケース（Fast閾値未満）
- Normal: 通常範囲内の時間（FastとNormal閾値の間）
- Slow: 通常より長い時間（NormalとSlow閾値の間）
- Extreme: 期待範囲を超える長時間（Slow閾値以上）
- Negative: 計算結果が負の値となった稀なケース（データ品質問題）
- Null: 選択したアクティビティが発生しなかったケース
閾値の動作: 閾値を0（デフォルト）に設定すると、システムは以下のように自動計算します:
- Fast閾値: 全正の所要時間の20パーセンタイル
- Normal閾値: 全正の所要時間の80パーセンタイル
- Slow閾値: 全正の所要時間の90パーセンタイル
この統計的アプローチにより、プロセス特性に適した有意義な分類が自動的に行われ、データの自然分布に適応します。
出力の利用方法: 生成されたパフォーマンスカテゴリ属性は以下に活用できます:
- パフォーマンスダッシュボード: ケースのパフォーマンス分布を可視化
- 原因分析（ルートコーズ分析）: 「Extreme」ケースを抽出しプロセスの問題解明
- プロセス比較: ケース属性ごとにパフォーマンス分類を比較
- 予測分析: ケース結果や遅延予測の特徴量として利用
- SLA監視: 各カテゴリのケース比率を目標と比較して監視
関連情報
関連パフォーマンスエンリッチメント:
- Performance Matrix - プロセス全体のパフォーマンスパターン分析
- Duration Between Two Activities - 特定のアクティビティ間の所要時間計算
関連分析ツール:
- Case Filters - ケース選択のための高度なフィルター作成
- Performance Dashboards - パフォーマンス指標の可視化
- Statistical Analysis - 所要時間分布の分析
このドキュメントはmindzie Studioプロセスマイニングプラットフォームの一部です。