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

Activity Nameは、インシデント管理プロセスの一部として実行される個別のステップまたはタスクを記述します。これらのアクティビティはプロセスマップの構成要素であり、SLA Breach Detectedのような自動化されたシステムイベントや、Agent AssignedやWorkaround Providedのような手動のユーザーアクションを含めることができます。

プロセスマイニング分析において、この属性は非常に重要です。プロセスグラフ内のノードを定義し、アナリストが作業の流れを可視化し、一般的な経路を特定し、ボトルネックを発見し、標準手順からの逸脱を分析することを可能にします。アクティビティ名の粒度と明確さは、得られる洞察の質と深さに直接影響します。

この属性は、プロセス内のステップを定義し、インシデントライフサイクルフローの可視化と分析を可能にします。

インシデント管理システム内のevent logs（イベントログ）、audit trails（監査証跡）、ステータス変更記録、またはタスク記述field（フィールド）の組み合わせから導き出されることがよくあります。

Event Timestamp は、アクティビティが発生した正確な時点を示します。インシデントのライフサイクル内の各アクティビティには、出来事を時系列に並べるための対応するタイムスタンプが必要です。

この属性は、時間に基づくプロセスマイニング分析の要です。アクティビティ間のサイクルタイム、各ステップの所要時間、インシデントの総解決時間の算出を可能にします。タイムスタンプを分析することで、ボトルネックの特定、SLA順守状況の測定、パフォーマンスの経時変化の把握ができます。平均解決時間などの主要KPIを計算するための基盤でもあります。

イベントの時系列順を提供し、期間の計算、ボトルネックの特定、時間経過に伴うプロセスパフォーマンスの分析に不可欠です。

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

Incident ID は、システム内で各インシデントを一意に識別する英数字コードです。新規インシデント作成時に採番され、アーカイブまたは削除されるまで不変です。

プロセスマイニングでは、Incident ID が分析の要となる Case ID です。関連するすべてのイベント、ステータス変更、アクティビティをひとつの一貫したプロセスインスタンスに結び付けます。共通の Incident ID でイベントを束ねることで、起票から最終的な解決・クローズまで、各インシデントのエンドツーエンドの軌跡を正確に可視化できます。

プロセスマイニングにおいて、関連するすべてのアクティビティとイベントを紐付け、エンドツーエンドのインシデントライフサイクルを再構築するために不可欠です。

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

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

プロセスマップの描画に直接は使用されませんが、この属性はデータ検証およびガバナンスにとって重要です。アナリストがデータを発生源まで遡って追跡し、システム間の潜在的な不一致を理解し、分析をセグメント化するのに役立ちます。例えば、同じ組織内でServiceNowとJiraという異なる2つのシステムに実装されているインシデント管理プロセスを比較できます。

データの発生源に関するコンテキストを提供し、複数システム環境におけるデータ検証、トラブルシューティング、比較分析に不可欠な情報となります。

これは多くの場合、データ抽出プロセス中に追加される静的な値であるか、またはソースシステムのテーブルで利用可能なフィールドです。

Last Data Update のタイムスタンプは、ソースシステムからデータを直近で抽出・同期した時点を表します。分析対象データの鮮度を示すメタデータです。

プロセスマイニングの分析において、得られるインサイトのタイムリーさを理解するために重要な属性です。リアルタイムの情報なのか、過去時点のスナップショットなのかを判断できます。これは運用監視に不可欠であり、現状に即したデータに基づいて意思決定するための前提となります。

データの鮮度を示すことで、アナリストが自身のプロセス分析がどの程度最新の状態にあるかを把握できるようにします。

この値は通常、データ抽出および変換（ETL）プロセス中に生成され、各レコードに記録されます。

Incident Category は、インシデントの性質に基づいて体系的に分類するための項目です。通常は階層型で、より詳細なレベルへ段階的に掘り下げられるため、レポートや分析に適した形で論理的にグループ化できます。

分類は、根本原因分析やトレンド分析に不可欠です。カテゴリでフィルタしたプロセスマップを分析すると、特定のインシデント種別に紐づく再発やパターンを把握できます。たとえば「ソフトウェア」と「ハードウェア」では、解決プロセスの姿が大きく異なることがあります。このデータは、初期分類の正確性や再発インシデント率といったKPIの算出に活用されます。

根本原因分析、再発するインシデントのトレンド特定、そして異なる種類の問題がどのように処理されているかを理解するために不可欠です。

これは、分類に使用されるインシデントレコード上の標準的で、多くの場合必須となるフィールドセットです。

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

この属性はプロセス分析の基礎で、ステータスの変化がプロセスマップ上のアクティビティを形作ることが多いからです。各ステータスでの滞留時間を分析すると、長時間「保留」に置かれているなどのボトルネックが見えてきます。また、オープン件数（バックログ）の算出や、解決に向けた進捗の追跡にも用いられます。

インシデントの進捗を把握する上で重要であり、プロセスマップ用のアクティビティを生成するためにもよく利用されます。各ステータスに費やされた時間を分析することで、遅延の発生箇所を特定するのに役立ちます。

通常、インシデントの主要記録のメインフィールド、またはインシデントの履歴ログとして利用可能です。

priority（優先度）は、インシデントの相対的な重要度と対応速度を決定するための重要なattribute（属性）です。これは通常、インシデントのimpact（影響度）とurgency（緊急度）の組み合わせから導き出されます。レベルは一般的に「重大」から「低」まで設定されています。

Process mining（プロセスマイニング）では、インシデントをpriority（優先度）別に分析することで、プロセスが異なる緊急度レベルの事象をどのように処理しているかについて、より深い理解が得られます。アナリストは、高priority（優先度）のインシデントと低priority（優先度）のインシデントの解決時間を比較し、SLA（サービスレベルアグリーメント）が遵守されているか、resource（リソース）が効果的に配分されているかを確認できます。「最も重要なインシデントを本当に最速で処理できているか」といった疑問に答えるのに役立ちます。

異なる緊急度レベルにおけるプロセスパフォーマンスの分析を可能にし、重要なインシデントが重要でないインシデントよりも迅速に処理されているかを確認するのに役立ちます。

主要なインシデント記録上の標準フィールドとして利用可能です。影響度と緊急度に基づいて手動で設定されるか、自動的に計算される場合があります。

Reporting Channel は、インシデントがどこから提出されたかを示します。電話のような直接連絡か、システム監視アラートのような自動通知かなど、ユーザーがサポート機能とどのように接点を持っているかを追跡します。

チャネル別にプロセスを分析すると、効率性の違いが明らかになります。たとえばセルフサービスポータル経由のインシデントは、事前に構造化された情報が含まれることが多く、解決が速い傾向があります。こうした分析により、サポートチャネルの最適化や、より効率的な手段の利用促進につなげられます。

インシデントの発生源に基づいて、その効率と解決経路を分析するのに役立ち、チャネル戦略やリソース配分を検討するための情報を提供します。

この情報は通常、インシデントが作成された際に自動的に捕捉されるか、またはエージェントによって選択されます。

Assigned Group は、その時点でインシデントの対応責任を持つチームを示します。インシデントは、レベル1（L1）サービスデスク、レベル2（L2）ネットワーク、レベル3（L3）アプリケーションサポートなど、複数のグループ間で回されることがよくあります。

この属性は、引き継ぎ（ハンドオフ）やワークロードの分析に不可欠です。プロセスマイニングではこのデータを使って、チーム間のインシデントの流れを可視化し、各チームのキューでの滞留時間を測定し、度重なる再割り当てで生じるボトルネックを特定します。チームの効率性や連携の把握に役立ち、「ハンドオフ・再割り当て分析」ダッシュボードの基盤となります。

チーム間の引き継ぎを分析し、キュー時間を測定し、チーム固有のパフォーマンスとワークロードの分布を理解するために不可欠です。

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

Assigned Agentは、インシデントを担当する特定の人物を特定します。Assigned Groupがチームを指すのに対し、エージェントは解決に取り組む個々の実行者です。

この属性により、より詳細なパフォーマンスおよびワークロード分析が可能になります。担当者レベルでの割り当てを追跡することで、管理者は個人の生産性を評価し、トレーニングの必要性を特定し、作業のバランスの取れた配分を確保できます。プロセスマイニングでは、グループレベルでは隠れている可能性のある複雑な再割り当てパターンを明らかにすることができ、解決時間への個々の貢献を理解するのに役立ちます。

チーム内またはチーム間の個々のワークロード、パフォーマンス、および再割り当てパターンの詳細な分析を可能にします。

主なインシデントレコードにあり、エージェントが所有権を取得したりインシデントを割り当てられたりしたときにこのフィールドが更新されます。

Resolution Method は、インシデントの結果と、どのように解決したかを示します。標準化されたコードの場合も、実施内容を記述した自由記述の場合もあります。例：「ユーザー教育」「ソフトウェアパッチ適用」「異常なし」「重複インシデント」など。

この属性はプロセスの終端に重要な文脈を与えます。プロセスマイニングで解決方法別に分析すると、各手段の有効性を把握できます。実質的な対処なくクローズしているケースの可視化や、特定カテゴリでよく見られる解決パターンの特定につながり、ナレッジベースの整備や一次解決率（First Contact Resolution）の向上に役立ちます。

問題がどのように解決されているかについての洞察を提供し、自動化、ナレッジベースの改善、トレーニングの機会を特定するために重要です。

通常、「解決済み」または「クローズ済み」のステータスにインシデントが移行する際に、サポートエージェントが入力するフィールドです。

深刻度（Severity）は、インシデントがビジネスに与える影響のレベルを定義します。これは、緊急性とは別に、問題がどの程度深刻であるかという問いに答えるものです。例えば、システム全体の停止は高深刻度インシデントですが、軽微な表示上のバグは低深刻度となります。

深刻度別にインシデントを分析することで、組織はどの種類の問題が最も大きな混乱を引き起こすかを理解できます。プロセスマイニングは、高深刻度インシデントが異なる、より効率的な解決経路をたどるかどうかを明らかにすることが可能です。この属性は、根本原因分析や、最も深刻なインシデントの再発を防ぐためのプロアクティブな問題管理において、リソースの優先順位付けを行う上で不可欠です。

インシデントをセグメント化し、高影響の問題が低影響の問題とは異なる方法で、あるいはより効率的に解決されているかを把握するのに役立ちます。

インシデント記録上の標準フィールドで、多くの場合、緊急度と併用して優先度を決定するために使用されます。

SLAステータスは、対応時間や解決時間といった事前に定められた時間目標に対するインシデントのパフォーマンスを示す指標です。一般的なステータスには「進行中」、「リスクあり」、「違反」などがあります。

この属性は、サービス品質を直接測る指標であり、SLAパフォーマンス概要ダッシュボードの重要な入力データとなります。プロセスマイニングでは、SLA違反したインシデントと違反していないインシデントのプロセスフローを比較できます。これにより、SLA失敗の主な原因となっている特定のアクティビティ、遅延、手戻りループを特定し、的を絞ったプロセス改善を可能にします。

これは目標に対するパフォーマンスを直接的に測る尺度です。違反したインシデントを分析することで、サービス提供の質の低下につながるプロセスの失敗を特定するのに役立ちます。

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

依頼者（Requester）は、問題を経験し、インシデントの起票を行った個人です。社内従業員の場合もあれば、外部の顧客の場合もあります。必要に応じて、依頼者の所属部門や組織も記録します。

依頼者や依頼者部門別にインシデントを分析すると、特定のユーザー群に課題が集中していないかを把握できます。これは、トレーニングの必要性や部門特有の環境要因による問題を示唆します。プロセスマイニングでは、サポートプロセスをユーザー中心に捉え、異なるユーザー層の体験を理解するのに役立ちます。

ユーザー中心の分析を可能にし、特定のユーザー、部署、または場所が異常に多くのインシデントを発生させていないかを特定するのに役立ちます。

インシデント記録上の標準フィールドで、通常、チケットを作成したユーザー、またはそのユーザーの代理で作成されたユーザーによって入力されます。

Reassignment Count は、インシデントのライフサイクルで発生した引き継ぎ（再割り当て）の回数を表す指標です。回数が多い場合は、初期の振り分けミスや非効率、サポートチーム内のナレッジ不足が疑われます。

これはプロセスマイニング分析で強力な属性です。再割り当て自体は可視化できますが、回数が事前に計算されていることで、フィルタやKPI測定が容易になります。「ハンドオフ・再割り当て分析」ダッシュボードで直接活用でき、チケットがチーム間を行き来する「ピンポン」状態を特定し、解決遅延やユーザー不満の要因を明らかにします。

この指標は、プロセスの非効率性を直接定量的に示します。高い件数はしばしば解決時間の長期化と相関し、ルーティングやチームの能力に問題があることを示唆します。

インシデント記録上の標準カウンターfield（フィールド）として利用できることが多いです。利用できない場合は、インシデントのaudit log（監査ログ）におけるアサイン変更の回数を数えることで算出できます。

Affected Serviceは、インシデントをITインフラストラクチャ内の特定のコンポーネント（ビジネスアプリケーション、サーバー、ネットワークデバイスなど）にリンクさせます。これは多くの場合、構成管理データベース（CMDB）と連携しています。

この属性は、インシデントに不可欠なビジネスコンテキストを提供します。プロセスマイニングでは、特定のサービスやアセットの信頼性に焦点を当てた分析を可能にします。組織は、どのサービスが最も多くのインシデントを発生させているかを特定し、その解決プロセスを分析し、重要なビジネスサービスの安定性を向上させるための問題管理の取り組みに優先順位を付けることができます。これは、ITインシデントがビジネス全体に与える影響を理解するための重要な要素です。

インシデントを特定のビジネスサービスやITコンポーネントと紐付け、どのサービスが最も問題を起こしやすいか、そしてその影響度を分析することができます。

通常、構成管理データベース（CMDB）からリンクされるか、インシデントフォーム上のサービスカタログリストから選択されます。