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

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

プロセスマイニング分析では、この属性が基盤になります。プロセスグラフのノードを定義し、作業の流れを可視化したり、一般的な経路を特定したり、ボトルネックを見つけたり、標準手順からの逸脱を分析したりできます。アクティビティ名の粒度と明確さは、導き出せる分析結果の品質と深さに直接影響します。

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

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

イベントタイムスタンプは、アクティビティが実行された正確な時点を示します。インシデントのライフサイクルに含まれる各アクティビティには、イベントの時系列を確立するための対応するタイムスタンプが必要です。

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

イベントの時系列を示します。所要時間の計算、ボトルネックの特定、時間経過に伴うプロセスパフォーマンスの分析に欠かせません。

イベントログ、監査履歴テーブル、または関連する特定のレコードの「最終更新日時」や「作成日時」として記録されています。

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

プロセスマイニングでは、インシデントIDが分析の基盤となり、ケースIDとして機能します。関連するすべてのイベント、ステータス変更、アクティビティを1つの一貫したプロセスインスタンスに結び付けることができます。共通のインシデントIDで全イベントをグループ化することで、アナリストは初回報告から最終的な解決とクローズまで、各インシデントのエンドツーエンドの経過を正確にマッピングできます。

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

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

ソースシステム属性は、データの発生元を識別します。複数のITSMツールや統合システムがある環境では、このフィールドによって異なるソースのレコードを区別できます。

プロセスマップの作成に直接使われるわけではありませんが、データの検証とガバナンスに役立つ属性です。データを発生元まで追跡し、システム間の差異を把握し、分析を分割できます。たとえば、同じ組織内でServiceNowとJiraという2つの異なるシステムに実装されたインシデント管理プロセスを比較できます。

データの発生元に関する背景情報を提供します。複数システム環境でのデータ検証、トラブルシューティング、比較分析に欠かせません。

データ抽出時に追加される固定値、またはソースシステムのテーブルで利用できるフィールドであることが一般的です。

最終データ更新のタイムスタンプは、データがソースシステムから最後に抽出または同期された時点を示します。分析対象データの鮮度を表すメタデータフィールドです。

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

データの鮮度を示し、アナリストがプロセス分析の最新性を把握できるようにします。

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

インシデントカテゴリは、性質に基づいてインシデントを体系的に分類する方法を提供します。通常は階層型のフィールドで、より詳細な分類を段階的に行い、報告や分析のためにインシデントを論理的なグループへ整理できます。

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

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

分類に使われる、標準的で必須となることも多いインシデントレコードのフィールド群です。

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

この属性はプロセス分析の基盤です。ステータスの変更がプロセスマップ上のアクティビティを定義することが多いためです。各ステータスに費やした時間を分析すると、「Pending」状態で長時間待機しているインシデントなどのボトルネックを特定できます。また、オープン中のインシデントのバックログを計算し、解決に向けた進捗を追跡するためにも使われます。

インシデントの進捗を把握するための重要な属性であり、プロセスマップのアクティビティ生成にもよく使われます。各ステータスに費やした時間を分析すると、遅延箇所を特定できます。

通常、メインのインシデントレコードの主要フィールド、またはインシデントの履歴ログで利用できます。

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

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

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

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

割り当てエージェントは、インシデントを担当する具体的な人物を示します。割り当てグループがチームを示すのに対し、エージェントは解決作業を行う個人です。

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

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

メインのインシデントレコードにあり、エージェントが担当を引き受けたとき、またはインシデントが割り当てられたときに更新されます。

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

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

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

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

報告チャネルは、インシデントが送信された経路を示します。電話などの直接的な連絡手段や、システム監視アラートなどの自動的な方法を通じて、ユーザーがサポート機能とどのようにやり取りしているかを追跡できます。

報告チャネル別にプロセスを分析すると、効率性の違いを明らかにできます。たとえば、セルフサービスポータルから報告されたインシデントは、最初から構造化された情報が多く含まれるため、より速く解決される可能性があります。この分析により、組織はサポートチャネルを最適化し、より効率的な方法の利用を促せます。

発生元に基づいてインシデントの効率性と解決経路を分析でき、チャネル戦略やリソース配分の検討に役立ちます。

通常、インシデントの作成時に自動取得されるか、エージェントが選択します。

解決方法は、インシデントの結果と解決手段を表します。標準化されたコードの場合も、実施した対応を自由記述したものの場合もあります。例として、「ユーザー教育」「ソフトウェアパッチ適用」「障害原因なし」「重複インシデント」などがあります。

この属性は、プロセスの終点に重要な背景情報を加えます。プロセスマイニングで解決方法別にインシデントを分析すると、さまざまな解決策の有効性を把握できます。実際の修正なしにクローズされたケースを明らかにしたり、特定のインシデントカテゴリに共通する解決パターンを特定したりできます。こうしたパターンは、ナレッジベースの構築や初回接触解決率の向上に役立ちます。

問題がどのように解決されているかを把握でき、自動化、ナレッジベースの改善、トレーニングの機会を特定するうえで役立ちます。

通常、インシデントを「Resolved」または「Closed」ステータスへ移行する際に、サポートエージェントが入力するフィールドです。

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

重大度別にインシデントを分析すると、どの種類の問題が最も大きな混乱を引き起こしているかを把握できます。プロセスマイニングにより、重大度の高いインシデントが、より効率化された異なる解決経路をたどっているかを明らかにできます。この属性は、根本原因分析や、重大なインシデントの再発を防ぐ予防的な問題管理に向けたリソースの優先順位付けに欠かせません。

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

インシデントレコードの標準フィールドであり、通常は緊急度と組み合わせて優先度の決定に使われます。

SLAステータスは、応答時間や解決時間など、あらかじめ定めた時間目標に対するインシデントのパフォーマンスを示します。一般的なステータスには、「In Progress」「At Risk」「Breached」があります。

この属性はサービス品質を直接測定するものであり、SLAパフォーマンス概要ダッシュボードへの重要な入力です。プロセスマイニングでは、SLA違反インシデントと未違反インシデントのプロセスフローを比較できます。SLA未達の主な要因となる具体的なアクティビティ、遅延、再作業ループを特定し、対象を絞ったプロセス改善につなげられます。

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

通常、ITSMツール内で計算されるフィールドです。インシデントの優先度、経過時間、定義されたSLAルールに基づいて動的に更新されます。

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

依頼者または依頼者の部署別にインシデントを分析すると、特定のユーザーグループが他のグループより多くの問題を経験しているかを把握できます。トレーニングの必要性や、特定の環境に限られた問題が見つかることもあります。プロセスマイニングでは、サポートプロセスをユーザー中心の視点で分析し、異なるユーザー層の体験を理解できます。

ユーザー中心の分析が可能になり、特定のユーザー、部署、地域が不釣り合いに多くのインシデントを発生させているかを特定できます。

インシデントレコードの標準フィールドです。通常、チケットを作成したユーザー、またはその代理で作成されたユーザーが入力されます。

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

プロセスマイニング分析に役立つ属性です。プロセスマイニングで再割り当てを可視化できますが、事前に計算された回数があれば、フィルタリングやKPI測定を簡単に行えます。引き継ぎ・再割り当て分析ダッシュボードで直接使われ、チーム間でチケットが何度も行き来する「ピンポン」状態を特定できます。こうした状態は、解決時間の長期化やユーザーの不満につながります。

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

通常、インシデントレコードの標準カウンターフィールドとして利用できます。ない場合は、インシデントの監査ログにある割り当て変更の回数を数えて算出できます。

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

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

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

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