インシデント管理用データテンプレート

アクティビティ名は、インシデント管理プロセスで実行された個別のステップやタスクを表します。プロセスマップを構成するこれらのアクティビティには、「SLA違反を検出」のような自動システムイベントや、「担当者割り当て」「回避策を提示」のような手動操作があります。

プロセスマイニング分析では、この属性が基本となります。プロセスグラフのノードを定義し、作業の流れを可視化して、よくある経路やボトルネック、標準手順からの逸脱を分析できます。アクティビティ名の粒度と明確さは、得られるインサイトの質と深さに直接影響します。

この属性でプロセスのステップを定義し、インシデントのライフサイクルの流れを可視化して分析できます。

イベントログ、監査証跡、ステータス変更記録、またはインシデント管理システムのタスク説明欄を組み合わせて導出することがよくあります。

イベントのタイムスタンプは、アクティビティが発生した正確な時刻を示します。インシデントのライフサイクルに含まれる各アクティビティには、イベントの時系列を把握するためのタイムスタンプが必要です。

この属性は、時間に基づくプロセスマイニング分析に欠かせません。アクティビティ間のサイクルタイムや各ステップの所要時間、インシデントの解決にかかった全体時間を算出できます。タイムスタンプを分析することで、組織はボトルネックを特定し、SLAの遵守状況を測定し、時間の経過に伴うプロセスのパフォーマンスの変化を把握できます。また、平均解決時間などの重要業績評価指標を算出する基礎にもなります。

イベントの時系列を把握できるため、所要時間の算出、ボトルネックの特定、時間の経過に伴うプロセスパフォーマンスの分析に役立ちます。

イベントログ、監査履歴テーブル、または関連レコードの「最終更新日時」や「作成日時」から取得できます。

インシデントIDは、システム内の各インシデントを区別する一意の英数字コードです。新しいインシデントの作成時に生成され、完全にアーカイブまたは削除されるまで変わりません。

プロセスマイニングでは、インシデントIDが分析の基盤となり、ケースIDとして機能します。このIDを使って、関連するイベント、ステータス変更、アクティビティを1つのプロセスインスタンスにまとめます。共通のインシデントIDでイベントをグループ化することで、アナリストは最初の報告から最終的な解決、クローズまで、各インシデントの一連の流れを正確に可視化できます。

プロセスマイニングでインシデントのライフサイクル全体を再構成するには、関連するすべてのアクティビティとイベントを結び付ける必要があります。

インシデントの主キーです。通常、各インシデントテーブルまたはオブジェクトのヘッダーやメインレコードにあります。

ソースシステム属性は、データの取得元を示します。複数のITSMツールや連携システムを使う環境では、この項目によって異なるソースのレコードを区別できます。

プロセスマップの作成に直接使う属性ではありませんが、データの検証とガバナンスに役立ちます。データの取得元をたどり、システム間の不一致の可能性を把握し、分析対象を分けることができます。たとえば、同じ組織内でServiceNowとJiraに実装されたインシデント管理プロセスを比較できます。

データの取得元を把握できるため、複数のシステムを使う環境でのデータ検証、問題の調査、比較分析に役立ちます。

データ抽出時に追加される固定値である場合や、ソースシステムのテーブルにある項目である場合が一般的です。

最終データ更新日時のタイムスタンプは、データがソースシステムから最後に抽出または同期された日時を示します。分析対象のデータがどの程度新しいかを表すメタデータ項目です。

プロセスマイニング分析では、生成されたインサイトがどの時点の情報に基づいているかを把握するうえで重要です。リアルタイムの情報を見ているのか、過去のある時点のスナップショットを見ているのかを確認できます。このコンテキストは、業務のモニタリングや、最新かつ関連性のあるデータに基づく意思決定に欠かせません。

データがどの程度新しいかを示すため、分析対象のプロセス情報が最新かどうかを把握できます。

通常、データ抽出・変換（ETL）処理中に生成され、各レコードに記録されます。

インシデントカテゴリは、インシデントの性質に基づいて分類するための体系的な方法です。通常は階層型の項目で、段階的に詳細な分類を行い、レポートや分析に向けてインシデントを論理的なグループに整理できます。

カテゴリ分類は、根本原因や傾向の分析に欠かせません。カテゴリで絞り込んだプロセスマップを分析すると、特定の種類のインシデントに関連する再発問題やパターンを特定できます。たとえば、「ソフトウェア」のインシデントと「ハードウェア」のインシデントでは、解決までのプロセスが大きく異なる場合があります。このデータは、初期分類の正確性やインシデント再発率などの重要業績評価指標に役立ちます。

根本原因の分析、再発するインシデントの傾向の特定、問題の種類ごとの対応方法の把握に欠かせません。

インシデントレコードにある標準項目で、分類に必須となっていることもよくあります。

インシデントステータスは、特定の時点におけるインシデントの段階を示します。解決プロセスのどこまで進んでいるかを大まかに把握できます。一般的なステータスには、新規、割り当て済み、作業中、保留、解決済み、クローズがあります。

この属性はプロセス分析の基本です。ステータスの変更が、プロセスマップ上のアクティビティを定義することがよくあります。各ステータスの継続時間を分析すると、「保留」のまま長期間進まないインシデントなど、遅延の原因となるボトルネックを特定できます。また、未解決インシデントのバックログの算出や、解決に向けた進捗の追跡にも使われます。

インシデントの進捗を把握するうえで重要な属性です。プロセスマップのアクティビティの作成にもよく使われます。各ステータスの継続時間を分析すると、遅延を特定できます。

通常、インシデントのメインレコードの主要項目、またはインシデントの履歴ログで確認できます。

優先度は、インシデントの相対的な重要度と必要な応答速度を判断するための主要な属性です。インシデントの影響度と緊急度を組み合わせて決めることがよくあります。レベルは通常、重大から低まで設定されます。

プロセスマイニングで優先度別にインシデントを分析すると、緊急度に応じてプロセスがどのように対応しているかを詳しく把握できます。優先度の高いインシデントと低いインシデントの解決時間を比較し、SLAが守られているか、リソースが適切に割り当てられているかを確認できます。また、「最も重大なインシデントに最も迅速に対応できているか」といった問いにも答えられます。

緊急度別にプロセスのパフォーマンスを分析し、重大なインシデントがそれ以外のインシデントより迅速に処理されているかを確認できます。

インシデントのメインレコードにある標準項目です。手動で設定する場合と、影響度と緊急度に基づいて自動計算する場合があります。

割り当てグループは、各時点でインシデントを担当するチームを示します。インシデントは、レベル1のサービスデスク、レベル2のネットワークチーム、レベル3のアプリケーションサポートチームなど、複数のグループ間で振り分けられることがあります。

この属性は、引き継ぎや作業量の分析に欠かせません。プロセスマイニングでは、チーム間のインシデントの流れを可視化し、各チームのキューでの滞留時間を測定して、頻繁な再割り当てによるボトルネックを特定できます。チームの効率や連携に関する問いに答えるための基礎となり、引き継ぎ・再割り当て分析ダッシュボードにも使われます。

チーム間の引き継ぎやキューでの待ち時間を分析し、チームごとのパフォーマンスと作業量の分布を把握するうえで重要です。

通常、この情報はインシデントレコードに保存され、インシデントが新しいチームに割り当てられるたびに更新されます。

報告チャネルは、インシデントがどの経路から申請されたかを示します。電話などの直接的な連絡手段や、システム監視アラートなどの自動的な手段を通じて、ユーザーがサポート窓口にどのように連絡しているかを記録します。

報告チャネル別にプロセスを分析すると、効率の違いを把握できます。たとえば、セルフサービスポータルから報告されたインシデントは、最初から情報が整理されていることが多く、より早く解決できる場合があります。この分析は、組織がサポートチャネルを見直し、より効率的な方法の利用を促すうえで役立ちます。

報告元に応じたインシデントの対応効率や解決経路を分析できます。チャネルの方針やリソース配分の検討にも役立ちます。

通常、この情報はインシデントの作成時に自動で記録されるか、担当者が選択します。

担当者は、インシデントを担当する個人を示します。割り当てグループがチームを示すのに対し、担当者は解決に取り組む個人です。

この属性を使うと、パフォーマンスや作業量をより細かく分析できます。担当者単位で割り当てを追跡することで、管理者は個人の生産性を評価し、研修の必要性を特定し、作業が偏らないように調整できます。プロセスマイニングでは、グループ単位の分析では見えにくい複雑な再割り当てのパターンを明らかにし、解決時間に対する個人の貢献を把握できます。

チーム内外における個人の作業量、パフォーマンス、再割り当てのパターンを詳しく分析できます。

インシデントのメインレコードにある項目です。担当者が対応を引き受けたとき、またはインシデントが割り当てられたときに更新されます。

解決方法は、インシデントの結果と解決に至った方法を表します。標準コードの場合も、実施した対応を自由記述で示す場合もあります。例として、「ユーザーへの説明」「ソフトウェアパッチを適用」「障害は確認されず」「重複インシデント」などがあります。

この属性は、プロセスの終点を理解するための重要なコンテキストを提供します。解決方法別にインシデントを分析すると、異なる解決策の有効性を把握できます。実際の修正を行わずにクローズされたケースを見つけたり、特定のインシデントカテゴリでよく使われる解決パターンを特定したりできます。こうした情報は、ナレッジベースの構築や初回問い合わせ解決率の向上に役立ちます。

問題の解決方法を把握できるため、自動化、ナレッジベースの改善、研修の機会を特定するうえで役立ちます。

通常、インシデントのステータスを「解決済み」または「クローズ」に変更する際に、サポート担当者が入力する項目です。

重大度は、インシデントがビジネスに与える影響の大きさを示します。緊急度とは別に、問題の深刻さを表します。たとえば、システム全体の停止は重大度が高く、軽微な表示上の不具合は重大度が低いインシデントです。

重大度別にインシデントを分析すると、どのような問題が最も大きな支障をもたらすかを組織が把握できます。プロセスマイニングにより、重大度の高いインシデントが、より効率的な別の解決経路をたどっているかどうかも確認できます。この属性は根本原因の分析に欠かせません。また、深刻なインシデントの再発を防ぐため、予防的な問題管理に向けたリソースの優先順位付けにも役立ちます。

インシデントを影響度別に分け、影響の大きい問題が影響の小さい問題と異なる方法で、またはより効率的に解決されているかを把握できます。

インシデントレコードの標準項目です。優先度の決定にあたり、緊急度と組み合わせて使われることがよくあります。

SLAステータスでは、応答時間や解決時間など、あらかじめ定められた時間目標に対するインシデントの状況を確認できます。一般的なステータスには、「進行中」「リスクあり」「違反」があります。

この属性はサービス品質を直接示すもので、SLAパフォーマンスの概要ダッシュボードに欠かせないデータです。プロセスマイニングでは、SLA違反のインシデントと違反していないインシデントのプロセスフローを比較できます。これにより、SLA違反の主な原因となっているアクティビティ、遅延、手戻りのループを特定し、対象を絞ったプロセス改善につなげられます。

目標に対するパフォーマンスを直接測定できます。SLA違反のインシデントを分析すると、サービス品質の低下につながるプロセス上の問題を特定できます。

通常、ITSMツール内で算出される項目です。インシデントの優先度や経過時間、定義済みのSLAルールに基づいて動的に更新されます。

再割り当て回数は、インシデントのライフサイクル中に発生した引き継ぎの回数を示す指標です。回数が多い場合、非効率な対応、最初の振り分けの誤り、またはサポートチームの知識不足が考えられます。

プロセスマイニング分析に役立つ属性です。プロセスマイニングで再割り当てを可視化できますが、あらかじめ算出された回数があれば、絞り込みや重要業績評価指標の測定が容易になります。引き継ぎ・再割り当て分析ダッシュボードで直接使われます。また、チケットがチーム間を何度も行き来する「たらい回し」の状況を特定し、解決時間の長期化やユーザーの不満につながる原因を把握できます。

この指標は、プロセスの非効率さを直接数値で示します。回数が多い場合、解決時間の長期化と相関することが多く、振り分けやチームの対応能力に問題がある可能性を示します。

インシデントレコードの標準カウンター項目として用意されていることがあります。ない場合は、インシデントの監査ログにある割り当て変更の回数から算出できます。

影響を受けたサービスは、インシデントを業務アプリケーション、サーバー、ネットワーク機器など、ITインフラ内の特定のコンポーネントに関連付けます。構成管理データベース（CMDB）と連携していることがよくあります。

この属性は、インシデントを理解するための重要なビジネスコンテキストを提供します。プロセスマイニングでは、特定のサービスや資産の信頼性に焦点を当てた分析が可能です。組織は、どのサービスでインシデントが最も多く発生しているかを特定し、その解決プロセスを分析して、重要な業務サービスの安定性を高めるための問題管理の優先順位を決められます。ITインシデントがビジネス全体に与える影響を把握するうえで重要な要素です。

インシデントを特定の業務サービスやITコンポーネントに関連付けることで、問題が発生しやすいサービスとその影響を分析できます。

通常、構成管理データベース（CMDB）から関連付けるか、インシデントフォームのサービスカタログから選択します。

申請者は、問題を経験し、インシデントを最初に報告した人です。社内の従業員の場合も、社外の顧客の場合もあります。申請者の部署や組織を記録することもできます。

申請者やその部署ごとにインシデントを分析すると、特定のユーザーグループで問題が多く発生していないかを特定できます。研修の必要性や、特定の環境に限られた問題が見つかることもあります。プロセスマイニングでは、ユーザーを中心にサポートプロセスを分析し、ユーザーグループごとの体験を把握できます。

ユーザーを中心に分析し、特定のユーザー、部署、または拠点からインシデントが偏って多く報告されていないかを特定できます。

インシデントレコードの標準項目です。通常、チケットを作成したユーザー、または代理で作成された場合はその対象者が設定されます。