process-mining-insights

プロセスマイニングの分析情報

概要

このスキルは、ServiceNow Process Mining のデータを分析し、プロセスのバリアントを調査してボトルネックを特定し、コンプライアンス違反を検出し、最適化の機会を提案することで、実行可能な分析情報を生成します。未加工のプロセスデータを、意思決定に活用できるインテリジェンスに変換します。

• プロセス定義、バリアント、アクティビティデータを取得して分析します
• ケースが不釣り合いに長い時間を費やしているボトルネックのアクティビティを特定します
• コンプライアンス違反を検出します：ステップの省略、順序どおりでないアクティビティ、権限のない実行者
• バリアントのパフォーマンスを比較して、最も効率的なプロセスパスを特定します
• プロセス KPI を算出します：処理時間、手戻り率、自動化の可能性
• 推定される影響を含む最適化の推奨事項を生成します

使用する場面： ビジネスプロセスの効率を分析する場合、プロセスのコンプライアンスを調査する場合、プロセス改善の提案を準備する場合、またはプロセスパフォーマンスのエグゼクティブダッシュボードを構築する場合に使用します。

前提条件

• ロール： process_mining_admin、process_mining_analyst、または admin
• プラグイン： com.snc.process_mining（Process Mining）
• アクセス権： sn_process_mining_process、sn_process_mining_variant、sn_process_mining_activity、sn_process_mining_case に対する読み取り権限
• 知識： プロセスマイニングの概念（バリアント、アクティビティ、遷移、適合性）への理解
• データ： イベントデータがインポートされたプロセスマイニングプロジェクトが少なくとも 1 つあること

手順

ステップ 1：プロセス定義を取得する

利用可能なプロセスマイニングプロジェクトとそのメタデータを一覧表示します。

MCP を使用する場合（Claude Code/Desktop）：

Tool: SN-Query-Table
Parameters:
  table_name: sn_process_mining_process
  query: active=true
  fields: sys_id,name,description,source_table,total_cases,total_variants,total_activities,created_on,updated_on
  limit: 20

REST API を使用する場合：

GET /api/now/table/sn_process_mining_process?sysparm_query=active=true&sysparm_fields=sys_id,name,description,source_table,total_cases,total_variants,total_activities,created_on,updated_on&sysparm_limit=20

ステップ 2：プロセスバリアントを分析する

頻度順にバリアントを取得して、最も一般的なプロセスパスを把握します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: sn_process_mining_variant
  query: process=[process_sys_id]^ORDERBYDESCcase_count
  fields: sys_id,name,process,case_count,avg_duration,median_duration,activity_sequence,conformance_status
  limit: 25

REST API を使用する場合：

GET /api/now/table/sn_process_mining_variant?sysparm_query=process=[process_sys_id]^ORDERBYDESCcase_count&sysparm_fields=sys_id,name,process,case_count,avg_duration,median_duration,activity_sequence,conformance_status&sysparm_limit=25

主なバリアント分析：

バリアント	ケース数	平均所要時間	適合性	備考
正常系	1,245	2.3 days	適合	理想的なプロセスフロー
手戻りあり	389	6.1 days	逸脱	レビューと修正の間のループ
承認の省略	67	1.1 days	非準拠	マネージャーの承認が欠落
緊急パス	42	0.4 days	適合	正当な理由に基づく迅速処理

ステップ 3：ボトルネックのアクティビティを特定する

アクティビティレベルのデータを照会し、ケースが最も長い時間を費やしている箇所を特定します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: sn_process_mining_activity
  query: process=[process_sys_id]^ORDERBYDESCavg_duration
  fields: sys_id,name,process,case_count,avg_duration,median_duration,min_duration,max_duration,avg_wait_time
  limit: 20

REST API を使用する場合：

GET /api/now/table/sn_process_mining_activity?sysparm_query=process=[process_sys_id]^ORDERBYDESCavg_duration&sysparm_fields=sys_id,name,process,case_count,avg_duration,median_duration,min_duration,max_duration,avg_wait_time&sysparm_limit=20

ボトルネックの特定基準：

• 所要時間のボトルネック：アクティビティの avg_duration > プロセス平均の 2 倍
• 待ち時間のボトルネック：アクティビティの avg_wait_time > 平均処理時間（作業時間ではなく待ち時間）
• ボリュームのボトルネック：アクティビティの case_count が後続のアクティビティより大幅に多い（キューの滞留）
• ばらつきのボトルネック：max_duration / min_duration > 10 倍（実行に一貫性がない）

ステップ 4：アクティビティ間の遷移を分析する

ケースがアクティビティ間をどのように進むかを調べ、手戻りループや通常と異なるパスを検出します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: sn_process_mining_transition
  query: process=[process_sys_id]^ORDERBYDESCcase_count
  fields: sys_id,source_activity,target_activity,case_count,avg_duration,process
  limit: 50

REST API を使用する場合：

GET /api/now/table/sn_process_mining_transition?sysparm_query=process=[process_sys_id]^ORDERBYDESCcase_count&sysparm_fields=sys_id,source_activity,target_activity,case_count,avg_duration,process&sysparm_limit=50

以下を確認します：

• 手戻りループ：想定される順序で、遷移先のアクティビティがそれ以前に出現している遷移
• スキップパターン：期待される遷移のうち、ケース数がゼロまたは非常に少ないもの
• 通常と異なるパス：参照モデルに存在しない遷移

ステップ 5：コンプライアンス違反を検出する

実際のプロセス実行を、参照モデル（正常系）と比較します。

逸脱のカテゴリ：

種類	説明	リスクレベル
アクティビティの省略	必須のステップが完全に省略された	高
順序違いの実行	アクティビティが誤った順序で実行された	中
権限のない実行者	適切なロールを持たないユーザーがアクティビティを実行した	重大
過剰な手戻り	アクティビティがしきい値（例：3 回）を超えて繰り返された	中
SLA 違反	アクティビティの所要時間が定義済みの SLA を超えた	高
ドキュメントの欠落	必須のメモまたは添付ファイルが存在しない	低

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: sn_process_mining_variant
  query: process=[process_sys_id]^conformance_status=non_compliant
  fields: sys_id,name,case_count,activity_sequence,conformance_status,deviation_details
  limit: 20

ステップ 6：プロセス KPI を算出する

プロセスデータから主要業績評価指標を導き出します。

=== PROCESS MINING KPI DASHBOARD ===
Process: Incident Management
Period: Last 90 days

Throughput Metrics:
  Total Cases:           1,743
  Avg Cycle Time:        3.2 days
  Median Cycle Time:     1.8 days
  90th Percentile:       8.4 days

Efficiency Metrics:
  Happy Path Rate:       71.4% (1,245/1,743)
  Rework Rate:           22.3% (389 cases with loops)
  First-Time-Right:      77.7%
  Automation Rate:       34.2% (activities performed by system)

Compliance Metrics:
  Conformance Rate:      96.2% (1,676/1,743 compliant)
  Skipped Steps:         67 cases (3.8%)
  SLA Compliance:        89.1%

Resource Metrics:
  Avg Handoffs:          3.1 per case
  Avg Wait vs Work:      62% wait / 38% work
  Busiest Activity:      "Approval" (avg 1.4 days wait)

ステップ 7：最適化の推奨事項を作成する

分析に基づき、優先順位を付けた推奨事項を作成します。

=== OPTIMIZATION RECOMMENDATIONS ===

1. [HIGH IMPACT] Reduce Approval Wait Time
   Finding: "Manager Approval" averages 1.4 days wait, 62% of total cycle time
   Root Cause: Approvals queue in manager inbox without SLA enforcement
   Recommendation: Implement auto-approval for low-risk items (<$500) and
   add escalation after 4 hours for standard items
   Estimated Impact: -0.8 days avg cycle time, 25% throughput improvement

2. [HIGH IMPACT] Eliminate Rework Loop: Review-Fix-Review
   Finding: 389 cases (22.3%) cycle between Review and Fix steps
   Root Cause: Incomplete initial submissions missing required fields
   Recommendation: Add mandatory field validation at submission and
   pre-review checklist
   Estimated Impact: -2.8 days for affected cases, 15% rework reduction

3. [MEDIUM IMPACT] Address Skipped Approval Deviation
   Finding: 67 cases bypassed mandatory approval step
   Root Cause: Users with admin role can override state transitions
   Recommendation: Add business rule to enforce approval regardless of role,
   with emergency override requiring documented justification
   Estimated Impact: 100% conformance on approval step

4. [MEDIUM IMPACT] Automate Assignment Activity
   Finding: "Assignment" activity is manual, avg 2.1 hours
   Root Cause: No auto-assignment rules configured for this category
   Recommendation: Implement predictive assignment (see itsm/predict-assignment)
   Estimated Impact: -2 hours per case, 95% auto-assignment rate

ステップ 8：調査結果をエクスポートして報告する

ステークホルダー向けに、調査結果を構造化されたレポートにまとめます。

MCP を使用する場合：

Tool: SN-Add-Work-Notes
Parameters:
  sys_id: [process_sys_id]
  work_notes: |
    === PROCESS MINING ANALYSIS REPORT ===
    Process: [process_name]
    Analysis Date: [current_date]
    Period: [date_range]

    EXECUTIVE SUMMARY:
    [2-3 sentence summary of key findings]

    TOP BOTTLENECKS:
    [Ranked list with impact metrics]

    COMPLIANCE STATUS:
    [Conformance rate and critical deviations]

    RECOMMENDATIONS:
    [Prioritized list with estimated impact]

    NEXT STEPS:
    [Action items with owners and timelines]

ツールの使用方法

ツール	目的	使用するタイミング
SN-Query-Table	プロセス、バリアント、アクティビティ、遷移のデータを取得する	分析の中核となるデータの収集
SN-Natural-Language-Search	自然言語でプロセスやケースを検索する	臨時の調査
SN-Update-Record	分析結果でプロセスレコードを更新する	調査結果の保存
SN-Add-Work-Notes	分析と推奨事項を記録する	レポートと監査証跡
SN-Get-Table-Schema	プロセスマイニングのテーブル構造を確認する	セットアップとフィールドの確認

ベストプラクティス

1. ハッピーパスから始める -- 逸脱を分析する前に、理想的なプロセスを理解します
2. 件数の多いバリアントに注目する -- 最も多くのケースに影響する経路から優先的に最適化します
3. 待ち時間と作業時間を区別する -- ボトルネックの多くは処理時間ではなく待ち時間です
4. 状況を踏まえて逸脱を検証する -- 「逸脱」の中には正当な例外（緊急事態）もあります
5. 影響を定量化する -- 推奨事項には必ず指標（削減できる時間やコスト）を添えます
6. 期間を比較する -- 傾向分析により、プロセスが改善しているか悪化しているかが分かります
7. プロセスオーナーを巻き込む -- 調査結果を、対応できる人々と共有します
8. 定期的に繰り返す -- 改善状況を追跡し、後退を検知するため、毎月分析を実施します
9. 成果と関連付ける -- プロセスバリアントをビジネス成果（CSAT、解決品質）に関連付けます
10. 適合性チェックを活用する -- 利用可能な場合は、BPMN の参照モデルと比較します

トラブルシューティング

「プロセスマイニングデータが見つかりません」

原因： プロセスマイニングプロジェクトが設定されていないか、データがインポートされていません
解決策： sn_process_mining_process に有効なレコードがあることを確認します。ソーステーブルからイベントログデータがインポートされていることを確認します。

「バリアント数が非常に多い」

原因： プロセスの変動が大きいか、イベントデータにノイズ（システムイベント、重複したタイムスタンプ）が含まれています
解決策： フィルターを適用して、システムが生成したアクティビティを除外します。通常、ケースの 80% 以上を占める上位 20 のバリアントに注目します（パレートの法則）。

「アクティビティの所要時間が正しくないようです」

原因： タイムスタンプが営業時間ではなく、週末や祝日を含む暦時間を示している可能性があります
解決策： プロセスマイニングプロジェクトで業務カレンダーの設定が使用されているか確認します。営業時間外を除外するよう、所要時間の計算を調整します。

「バリアントの適合性ステータスが空白です」

原因： プロセスの参照モデルが定義されていません
解決策： プロセスマイニングプロジェクトの設定で参照モデル（ハッピーパス）を作成します。参照モデルがないと、適合性チェックを実行できません。

例

例 1：インシデント管理プロセスの分析

プロセス： インシデント管理（90 日間で 1,743 件のケース）

主な調査結果：

• ハッピーパス（作成 > 割り当て > 調査 > 解決 > クローズ）はケースの 71% を占めます
• ボトルネック：手動での振り分けにより、割り当ての平均所要時間は 2.1 時間です
• 手戻り：ケースの 22% が調査と再割り当ての間を繰り返します
• コンプライアンス：P1 インシデントの 3.8% で必須の承認が省略されています

最優先の推奨事項： 自動割り当てを導入し、2.1 時間の振り分け遅延を解消します。

例 2：変更管理プロセスへの準拠

プロセス： 変更管理（90 日間で 412 件の変更）

主な調査結果：

• 全体の準拠率は 94％です
• 26 件（6.3％）の変更で CAB レビューが省略されていました。すべて、本来「Normal」の変更が誤って「Standard」としてマークされていました
• 緊急変更（42 件）の実装後レビュー完了率は 98％でした
• ボトルネック：CAB のスケジュール調整にかかる待ち時間は平均 3.2 日です

最優先の推奨事項： 「Normal」の変更で「Standard」の変更ワークフローを使用できないよう、検証を追加します。

例 3：サービスカタログの履行効率

プロセス： サービスカタログの履行（90 日間で 2,891 件のリクエスト）

主な調査結果：

• 5 種類の履行経路が特定されました
• 最速のパターン（ソフトウェアの自動プロビジョニング）では平均 0.3 日です
• 最も遅いパターン（調達を伴うハードウェア）では平均 14.2 日です
• サイクルタイム全体の 78％は待ち時間（承認＋調達）です
• アイテムの選択ミスにより、承認後にキャンセルされたリクエストは 12％です

最優先の推奨事項： アイテム選択をガイドするウィザードを追加し、12％のキャンセル率を下げます。

関連スキル

• itsm/predict-assignment - プロセス分析で推奨された自動割り当てを実装します
• itsm/change-management - 変更管理プロセスを理解します
• reporting/trend-analysis - プロセスデータの傾向分析を補完します
• reporting/sla-analysis - SLA 準拠を分析します
• genai/flow-generation - 最適化候補として特定されたプロセスのステップを自動化します