インシデント管理データテンプレート
インシデント管理データテンプレート
- 収集を推奨する属性
- プロセスで追跡すべき主要なアクティビティ
- データシステムからデータを抽出する方法
インシデント管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
インシデントID
IncidentId
|
各インシデントレコードを一意に識別する識別子です。 | ||
|
説明
インシデントIDは、各インシデントを作成からクローズまで一意に識別する主キーです。関連するすべてのアクティビティ、ログ、変更を結び付け、インシデントのライフサイクルをエンドツーエンドで把握できるようにします。 プロセスマイニングでは、この属性がケースを定義するため、基本的な項目です。同じインシデントIDを持つすべてのイベントが同じプロセスインスタンスの一部とみなされ、個々のインシデントがどのように処理されたかを再構成・分析できます。
重要な理由
インシデントのライフサイクルにおけるすべてのイベントを結び付ける、不可欠なケース識別子です。これにより、プロセスをエンドツーエンドで分析できます。
入手先
「HPD:Help Desk」フォームの「Incident Number」フィールド(フィールドID:1000000161)です。
例
INC000001234567INC000002345678INC000003456789
|
|||
|
アクティビティ名
ActivityName
|
インシデントのライフサイクル内で発生した特定のイベントまたはタスクの名前です。 | ||
|
説明
この属性は、インシデントについて特定の時点で実行されたアクティビティを示します。たとえば、「Incident Reported」、「Group Assigned」、「Incident Resolved」などです。これらのアクティビティがプロセスマップを構成します。 アクティビティの順序と頻度を分析すると、実際のプロセスフロー、一般的な経路、標準手順からの逸脱が明らかになります。インシデント解決のためにどのような対応が行われているかを理解するうえで欠かせません。
重要な理由
アクティビティはプロセスマップ上のステップを定義し、インシデント管理ワークフローの可視化と分析を可能にします。
入手先
通常は、「HPD:Help Desk」フォームの「Status」(フィールドID:7)と「Status_Reason」フィールドの変更、または「HPD:Help Desk Audit Log」フォームから取得します。
例
インシデント報告グループ割り当て解決策の実施インシデントのクローズ
|
|||
|
イベントタイムスタンプ
EventTimestamp
|
アクティビティが発生した正確な日付と時刻です。 | ||
|
説明
このタイムスタンプは、インシデントのライフサイクルにおける特定のイベントが発生した時点を記録します。生のデータからプロセスフローを再構成するために必要な時系列を提供します。 イベントタイムスタンプは、アクティビティ間のサイクル時間の計算、インシデントが長時間待機するボトルネックの特定、全体の解決時間の測定など、時間に基づくすべての分析に欠かせません。プロセス分析の時間的な基盤となります。
重要な理由
このタイムスタンプはイベントの時系列を示します。期間の計算、ボトルネックの特定、プロセスの時間経過の把握に欠かせません。
入手先
「HPD:Help Desk」フォームの「Last Modified Date」(フィールドID:6)または特定の日付フィールドです。過去のイベントについては、監査ログのタイムスタンプフィールドから取得します。
例
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:22:05Z
|
|||
|
SLA違反の有無
IsSlaBreached
|
インシデントがSLA目標日時を過ぎてから解決されたかどうかを示すフラグです。 | ||
|
説明
このブール型属性は、インシデントの解決時間が定義されたSLAを超えた場合にtrueになります。各インシデントのSLAパフォーマンスを明確に二値で示します。 インシデントSLAパフォーマンス概要ダッシュボードの作成や、「インシデントSLAコンプライアンス率」KPIの算出に欠かせません。サービスレベル目標を満たせなかったインシデントを直接フィルタリングして集計できるため、違反の原因を簡単に調査できます。
重要な理由
このフラグによりSLAコンプライアンスの分析が簡単になり、SLA違反のインシデントをすべて抽出して根本原因を調査できます。
入手先
「Incident Resolved」イベントのタイムスタンプと「SlaTargetDate」を比較して算出します。解決時刻が目標日時より後の場合、このフラグはtrueになります。
例
truefalse
|
|||
|
インシデントカテゴリ
IncidentCategory
|
インシデントの分類です。通常は階層構造で管理されます。 | ||
|
説明
インシデントのカテゴリ分けでは、通常、複数レベルの階層を使ってインシデントを体系的に分類します(例:Tier 1:ハードウェア、Tier 2:ノートパソコン、Tier 3:バッテリー)。このデータは、振り分け、レポート作成、傾向分析に欠かせません。 プロセスマイニングでは、カテゴリごとにインシデントを分けて分析します。初期カテゴリと最終カテゴリを比較することで、インシデントカテゴリ分類精度ダッシュボードを支援します。また、根本原因の傾向ダッシュボードで傾向を特定する際にも役立ちます。
重要な理由
カテゴリ分けにより、正確な振り分け、傾向分析、インシデントの種類ごとのパフォーマンス比較が可能になります。
入手先
「HPD:Help Desk」フォームの「Operational Categorization Tier 1/2/3」フィールドです。
例
ハードウェア > ノートパソコン > バッテリーソフトウェア > エンタープライズアプリ > ログインエラーネットワーク > 接続性 > Wi-Fi
|
|||
|
インシデントステータス
IncidentStatus
|
イベント発生時点における、インシデントの現在または過去のステータスです。 | ||
|
説明
この属性は、「New」、「In Progress」、「Pending」、「Resolved」、「Closed」など、インシデントの状態を示します。インシデントのライフサイクル上の位置を把握するためのスナップショットです。 ステータスの変更を分析することは、インシデント管理プロセスを理解するうえで基本となります。アクティビティの定義、各状態に費やされた時間の測定(たとえば、インシデントが「Pending」である時間)、滞留または非アクティブなインシデントの特定に利用します。
重要な理由
ステータスの変更を追跡することは、インシデントの進行を理解し、「Pending」や「In Progress」などの特定の状態にどれだけ滞在しているかを測定するうえで重要です。
入手先
「HPD:Help Desk」フォームの「Status」フィールド(フィールドID:7)です。
例
新規割り当て済み対応中保留解決済みクローズ済み
|
|||
|
サービス
Service
|
インシデントの影響を受けたビジネスサービスまたは技術サービスです。 | ||
|
説明
この属性は、インシデントを構成管理データベース(CMDB)で定義された特定のサービスに関連付けます。たとえば、「Email Service」、「VPN Access」、「SAP Financials」などです。 この関連付けは、インシデントがビジネスに与える影響を理解するうえで重要です。サービス別にインシデントを分析すると、大量のインシデントを発生させている問題のあるサービスを特定し、特定の技術に関連する繰り返しの問題を把握できます。また、問題管理における傾向分析にも役立ちます。
重要な理由
インシデントをビジネスサービスに関連付けることは、影響分析や、問題が発生しやすいサービスの特定に欠かせません。
入手先
「HPD:Help Desk」フォームで、影響を受けた構成アイテム(CI)を示す「ServiceCI」または同等のフィールドです。
例
社内メールSAP ERPリモートアクセスVPN人事ポータル
|
|||
|
優先度
Priority
|
インシデントに割り当てられた優先度で、対応の緊急性を決定します。 | ||
|
説明
優先度は通常、影響度と緊急度の組み合わせから決まり、インシデントを解決する順序と速度を左右します。一般的な値は「Critical」から「Low」までです。 プロセスマイニングでは、優先度別にインシデントを分析することがパフォーマンス分析に欠かせません。「高優先度のインシデントでSLAを達成できているか」「低優先度のインシデントで遅延が長くなっていないか」といった問いに答えられます。優先度で絞り込むことで、特に重要なビジネス上の問題を重点的に分析できます。
重要な理由
この属性は、分析を分類し、高優先度のインシデントをより迅速に処理して、固有のサービスレベル目標を達成できているかを確認するうえで欠かせません。
入手先
「HPD:Help Desk」フォームの「Priority」フィールド(フィールドID:1000000164)です。
例
重大高中低
|
|||
|
再オープンの有無
IsReopened
|
「Resolved」ステータスに設定された後、インシデントが再オープンされたかどうかを示すフラグです。 | ||
|
説明
このブール型属性は、インシデントが「Resolved」とマークされた後に、ステータスが「In Progress」などの対応中の状態へ戻った場合にtrueになります。初回の修正が有効でなかった、または不十分だったことを示します。 これは手戻りを直接測定する指標で、「インシデント手戻り率」KPIの算出に使います。再オープンされたインシデントを分析することで、品質の低い修正、不十分なテスト、適切に対処されなかった再発問題を特定できます。手戻りとエスカレーション経路ダッシュボードにも役立ちます。
重要な理由
手戻りと解決品質を直接測定します。再オープン率が高い場合、修正の有効性やプロセスに問題がある可能性があります。
入手先
インシデントのアクティビティの順序を分析して算出します。「Resolution Implemented」アクティビティの後に「Incident Reopened」などのアクティビティが現れた場合、このフラグはtrueになります。
例
truefalse
|
|||
|
割り当てグループ
AssignedGroup
|
インシデントへの対応を担当するサポートグループです。 | ||
|
説明
この属性は、インシデントに割り当てられたチームまたは部門を示します。たとえば、「Service Desk」、「Network Team」、「Database Administrators」などです。割り当てを追跡することで、チーム間の作業の流れを把握できます。 この属性は、チーム間の引き継ぎの分析、特定のグループが原因となるボトルネックの特定、「Incident Reassignment Rate」の測定に利用します。インシデントが組織内をどのように移動したかを可視化し、非効率な振り分けや知識不足がある領域を明らかにします。
重要な理由
担当グループを追跡すると、引き継ぎの分析、再割り当てのループの特定、特定のチーム内にあるボトルネックの把握が可能になります。
入手先
「HPD:Help Desk」フォームの「Assigned Group」フィールド(フィールドID:1000000217)です。
例
サービスデスクネットワーク運用アプリケーションサポート第2層インフラストラクチャサービス
|
|||
|
担当者
Assignee
|
インシデントへの対応を担当する個人ユーザーです。 | ||
|
説明
担当者は、特定の時点でインシデントを担当するサポート担当者または技術者です。「Assigned Group」よりも詳細な粒度で情報を把握できます。 担当者別にパフォーマンスを分析すると、優れた成果を上げている担当者、追加研修が必要な担当者、作業負荷の偏りを特定できます。また、複雑なインシデントに対応した個人の行動を正確な順序で追跡するためにも利用できます。
重要な理由
作業負荷の分布と個人のパフォーマンスを詳細に把握し、成果を上げている担当者や支援が必要な担当者を特定できます。
入手先
「HPD:Help Desk」フォームの「Assignee」フィールド(フィールドID:1000000218)です。
例
Bob SmithAlice JohnsonCharlie Brown
|
|||
|
SLA目標日時
SlaTargetDate
|
SLAに基づき、インシデントを解決する必要がある期限日時です。 | ||
|
説明
この属性には、該当するサービスレベル合意(SLA)で定められたインシデント解決の期限が保存されます。インシデントの優先度と定義されたサービス時間に基づいて算出されます。 このタイムスタンプを基準に、実際の解決時間を測定します。「インシデントSLAコンプライアンス率」KPIの算出や、SLAパフォーマンスを可視化するダッシュボードの作成に欠かせません。期限が近づいているインシデントを事前に監視できます。
重要な理由
SLAコンプライアンスを測定する基準です。インシデントが期限内に解決されたか、SLA違反となったかを算出できます。
入手先
通常、「SLM:Measurement」フォームに保存され、インシデントに関連付けられます。「HPD:Help Desk」の直接のフィールドではありません。
例
2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
|
|||
|
クローズコード
CloseCode
|
インシデントのクローズ時に選択するコードで、解決結果を示します。 | ||
|
説明
クローズコードは、インシデントがどのように解決されたかを体系的にまとめたものです。例として、「Resolved by User」、「No Fault Found」、「Duplicate Incident」、「Permanent Fix Applied」などがあります。 この属性は、解決の有効性や結果を分析するうえで役立ちます。実際の修正が行われないままクローズされたインシデントや、ユーザー自身で解決されることが多いカテゴリを特定できます。これにより、ナレッジベース記事の拡充やセルフサービスツールの改善機会を見つけられます。
重要な理由
解決結果に関する体系的なデータを提供し、修正の有効性やインシデントのクローズ方法に関する傾向の分析に役立ちます。
入手先
通常、「HPD:Help Desk」フォームの解決またはクローズに関する情報の一部です。
例
リモートで解決重複した問題ユーザーエラー対応不要
|
|||
|
ソースシステム
SourceSystem
|
インシデントデータを抽出したシステムです。 | ||
|
説明
この属性はデータの出所を示します。複数のITSMツールや連携システムがある環境で特に役立ちます。特定のBMC Helix ITSMインスタンスなど、想定したソースからデータが取得されていることを確認できます。 分析では、本番、開発、レガシーシステム間で異なる可能性があるプロセスやデータの特性を区別するのに役立ち、データの系譜を明確で信頼できるものにします。
重要な理由
データの出所を特定します。データの検証や、複数の連携システムにまたがる分析の管理に欠かせません。
入手先
通常は、データの抽出、変換、ロード(ETL)処理の際に追加される固定値です。
例
BMCHelixITSM_ProdITSM-EU-InstanceServiceManagement-APAC
|
|||
|
チャネル
Channel
|
インシデントの報告に使われた方法です。 | ||
|
説明
インシデントがどのように登録されたかを示す属性です。電話、メール、セルフサービスポータル、窓口への直接来訪などが該当します。インシデントがサポートプロセスに入った経路を示します。 チャネル別にインシデントを分析すると、どのチャネルが最も効果的か、また、解決しやすいインシデントや解決に時間がかかるインシデントをどのチャネルが生み出しているかを把握できます。さらに、より正確な初期データを収集できるセルフサービスポータルの利用を促すなど、自動化やユーザー教育への投資先を検討する際にも役立ちます。
重要な理由
登録チャネルを把握することで、受付方法ごとの効率を分析し、セルフサービスや自動化への投資判断に役立てられます。
入手先
「HPD:Help Desk」フォームの「Reported Source」フィールドです(フィールドID:1000000215)。
例
メール電話セルフサービス直接入力
|
|||
|
再割り当て回数
ReassignmentCount
|
インシデントが別のグループに再割り当てされた回数の合計です。 | ||
|
説明
この指標は、インシデントのライフサイクル中に「AssignedGroup」フィールドが変更された回数を数えます。回数が多い場合、初期振り分けの問題、初回対応での解決不足、複数チームの関与が必要な複雑な問題が考えられます。 この属性は、「インシデント再割り当て率」KPIと「インシデント再割り当てサイクル分析」ダッシュボードに直接役立ちます。チケットがチーム間を何度も行き来する「ピンポン」状態を定量化し、大幅な遅延やプロセスの非効率を明らかにできます。
重要な理由
非効率な振り分けや引き継ぎを定量化し、チーム間の再割り当てループに陥っているインシデントを特定できます。
入手先
イベントログで、特定のIncident IDに対する「AssignedGroup」の値の変更回数を数えて算出します。
例
0135
|
|||
|
最終データ更新
LastDataUpdate
|
このイベントのデータがソースシステムから最後に更新された時点を示すタイムスタンプです。 | ||
|
説明
この属性は、直近のデータ抽出が行われた日付と時刻を記録します。分析対象データの鮮度を把握するための情報となり、プロセス分析で得られる情報がどの時点の状況を示しているかを理解するうえで重要です。 最終更新時刻を把握することは、レポートやダッシュボードに欠かせません。データの適時性を利用者に伝え、直近のインシデントアクティビティが含まれているかどうかについて、適切な期待値を設定できます。
重要な理由
データの鮮度を示し、プロセス分析とそこから得られる情報がどの時点の状況を示しているかを利用者が理解できるようにします。
入手先
通常は、データ抽出(ETL)処理の際にデータセットへ生成・付与されます。
例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
|
|||
|
影響度
Impact
|
インシデントが業務プロセスに及ぼす影響の大きさです。 | ||
|
説明
影響度は、インシデントが業務に及ぼす悪影響の範囲を評価します。通常、「Extensive/Widespread」、「Significant/Large」、「Moderate/Limited」、「Minor/Localized」などの段階で定義します。 緊急度と組み合わせて、影響度はインシデントの優先度を決定します。影響度別に分析することで、技術的な複雑さにかかわらず、業務に最も大きな混乱をもたらすインシデントを把握できます。これは、プロセス改善の取り組みに優先順位を付けるうえで重要です。
重要な理由
インシデントが業務に及ぼす深刻度を定量化し、優先度の決定や影響の大きい問題への分析集中に役立ちます。
入手先
「HPD:Help Desk」フォームの「Impact」フィールドです(フィールドID:1000000163)。
例
1-広範囲/全体的2-重大/大規模3-中程度/限定的4-軽微/局所的
|
|||
|
根本原因
RootCause
|
インシデントの背後にある理由、または最終的な原因です。 | ||
|
説明
根本原因とは、対処すればインシデントの再発を防げる根本的な問題です。通常、関連する問題調査プロセスの一環として特定します。 すべてのインシデントで根本原因が記録されるとは限りませんが、この属性の分析は予防的な問題管理に欠かせません。「根本原因特定率」KPIを支援し、再発する問題の傾向を追跡するダッシュボードの作成にも役立ちます。これにより、恒久的な解決策の導入に向けた取り組みを進められます。
重要な理由
根本原因の特定は、問題管理や、インシデントの再発件数削減を目的とした分析に欠かせません。
入手先
インシデントの専用「Root Cause」フィールドに記録される場合がありますが、通常は関連付けられた「PBI:Problem Investigation」フォームに記録されます。
例
サーバーのディスク容量不足ネットワーク設定エラーバージョン2.1のソフトウェアバグセキュリティ証明書の期限切れ
|
|||
|
登録者
Submitter
|
最初にインシデントを報告した人です。 | ||
|
説明
登録者は、問題を経験して報告したエンドユーザーまたは顧客です。インシデントに対応する担当者とは異なります。 登録者やその所属部門別にデータを分析すると、追加のトレーニングが必要なユーザーグループや、特定の種類の問題の影響を受けているグループを特定できます。インシデント管理プロセスを顧客中心の視点で把握できます。
重要な理由
問題を報告したユーザーを特定し、部門、所在地、役割などに基づいて分析することで、ユーザー固有の傾向を見つけられます。
入手先
「HPD:Help Desk」フォームの「Submitter」フィールド、または顧客情報に関するフィールドに記録されます。
例
John DoeJane SmithPeter Jones
|
|||
|
解決内容
Resolution
|
インシデントの解決に向けて実施した手順を自由記述で説明したものです。 | ||
|
説明
このフィールドには、最終的な解決内容を人が記述した詳細な要約が入ります。問題を修正し、ユーザーへのサービスを復旧するために何を行ったかを説明します。 非構造化テキストですが、テキストマイニングの手法で分析することで、一般的な解決パターンの特定、特定の問題に関するキーワードの抽出、根本原因分析の補足が可能です。構造化されたデータフィールドだけでは得られない定性的な背景情報を提供します。
重要な理由
解決内容に関する定性的な詳細を提供します。テキストマイニングにより、構造化データからは見えないパターンを見つけられます。
入手先
「HPD:Help Desk」フォームの「Resolution」フィールドです(フィールドID:1000000156)。
例
Active Directoryを使用してユーザーのパスワードをリセットしました。ブラウザーのキャッシュとCookieを消去し、ログインの問題を解決しました。IDFの3B通信機器室にあるネットワークスイッチを再起動しました。
|
|||
インシデント管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
インシデントのクローズ
|
これは最後のアクティビティで、解決が確認された、または確認期間が経過した後に、インシデントレコードを正式にクローズしたことを示します。ステータスが「Closed」に設定された時点で取得します。 | ||
|
重要な理由
これはインシデントのライフサイクルにおける確定的な終了イベントです。「Resolved」から「Closed」までの時間は、ユーザー確認と管理上の後処理にかかる期間を示します。
入手先
「HPD:Help Desk」フォームの「Status」フィールドが「Closed」に設定された時点に対応します。タイムスタンプは「Closed Date」フィールドと監査ログに記録されます。
取得
「Closed Date」のタイムスタンプ、または「Closed」へのステータス変更から取得します。
イベントタイプ
inferred
|
|||
|
インシデント報告
|
このアクティビティは、システム上でインシデントレコードが最初に作成された時点を示します。インシデント管理の主要フォームに記録された作成時刻から明示的に取得します。 | ||
|
重要な理由
これはインシデントのライフサイクルにおける主な開始イベントです。全体の解決時間を計算し、インシデントの受付件数を把握するために欠かせません。
入手先
「HPD:Help Desk」フォームでレコードが作成された時点に対応します。タイムスタンプには通常、「Submit Date」または「Reported Date」フィールドの値を使用します。
取得
「HPD:Help Desk」フォームの「Submit Date」タイムスタンプから取得します。
イベントタイプ
explicit
|
|||
|
インシデント解決
|
このアクティビティは、最終的なクローズ前に、サービスデスクの観点でインシデントが正式に解決されたことを示します。インシデントのステータスが「Resolved」に設定された時点で取得します。 | ||
|
重要な理由
これはSLAコンプライアンスと解決時間を測定するうえで最も重要な節目です。ユーザー向けのサービスが復旧したことを示します。
入手先
「HPD:Help Desk」フォームの「Status」フィールドが「Resolved」に設定された時点に対応します。タイムスタンプは「Last Resolved Date」フィールドと監査ログから取得します。
取得
監査ログで「Resolved」へのステータス変更が発生した時点のタイムスタンプから取得します。
イベントタイプ
inferred
|
|||
|
グループ割り当て
|
このアクティビティは、調査を担当する特定のサポートグループにインシデントが最初に割り当てられた時点を示します。インシデント作成後、「Assigned Group」フィールドに初めて値が入力された時点から推定します。 | ||
|
重要な理由
これは、実際の対応が始まったことを示す重要な節目です。初回割り当てまでの時間を追跡することは、応答時間と初期の振り分け効率を評価するうえで重要です。
入手先
「HPD:HelpDesk_AuditLogSystem」の監査ログで、「HPD:Help Desk」フォームの「Assigned Group」フィールドに初めて値が入力された時点を取得し、推定します。
取得
「Assigned Group」フィールドに初めて値が入力された時点のタイムスタンプから取得します。
イベントタイプ
inferred
|
|||
|
調査開始
|
サポート担当者がインシデントへの対応を実際に開始したことを示します。通常は、ステータスが「Assigned」から「In Progress」に変わった時点から推定します。 | ||
|
重要な理由
この節目は、キューで待機している状態から、実際の診断に移行したことを示します。調査開始までの待機時間を分析すると、リソースのボトルネックを特定でき、「Diagnosis & Investigation Bottlenecks」ダッシュボードを支援できます。
入手先
「HPD:Help Desk」フォームのステータス変更から推定します。「Status」フィールドが「In Progress」に変わった時点でイベントを発生させ、タイムスタンプは監査ログから取得します。
取得
HPD:HelpDesk_AuditLogSystemで「In Progress」へのステータス変更から推定します。
イベントタイプ
inferred
|
|||
|
SLA違反
|
インシデントの解決時間が定義されたサービスレベル合意の目標を超えたときに発生する計算イベントです。解決時刻とSLA期限日を比較して導出します。 | ||
|
重要な理由
このアクティビティは、「Incident SLA Performance Overview」ダッシュボードと「Incident SLA Compliance Rate」KPIの基盤となります。サービスの約束を満たせなかったインシデントを直接特定します。
入手先
「HPD:Help Desk」フォームの「Last Resolved Date」と「Target Date」(SLA期限日)を比較して計算します。まだ解決していない場合は、現在時刻と比較して計算できます。
取得
計算イベント:「Last Resolved Date」>「Target Date」の場合に発生します。
イベントタイプ
calculated
|
|||
|
インシデントのキャンセル
|
誤って作成された、または不要になったインシデントを終了するアクティビティです。インシデントのステータスが「Cancelled」に設定された時点で取得します。 | ||
|
重要な理由
これはインシデントの終端状態であり、正常な解決とは異なります。キャンセルされたインシデントを分析すると、インシデントの作成経路や重複報告に関する問題を把握できます。
入手先
「HPD:Help Desk」フォームの「Status」フィールドが「Cancelled」に更新された時点から推定します。タイムスタンプは監査ログから取得します。
取得
監査ログで「Cancelled」へのステータス変更から推定します。
イベントタイプ
inferred
|
|||
|
インシデントの再オープン
|
解決済みとされたインシデントが、問題が継続しているため再び有効になった状態を示します。「Resolved」から「In Progress」や「Assigned」などのアクティブな状態に戻るステータス変更から推定します。 | ||
|
重要な理由
このアクティビティは、手戻りと初回解決策の有効性を直接測定します。再オープンされたインシデントが多い場合、修正の品質が低い可能性を示す重要な指標となり、「Incident Rework Rate」KPIを支援します。
入手先
「HPD:HelpDesk_AuditLogSystem」の監査ログで、特定のインシデントIDについて「Status」が「Resolved」から「In Progress」または「Assigned」に変わったことを検出して推定します。
取得
「Resolved」からアクティブな状態へのステータス遷移から推定します。
イベントタイプ
inferred
|
|||
|
インシデントの分類
|
インシデントに運用上および製品上の分類が設定され、優先度が決まった時点を示します。通常は、分類フィールドへの値の入力または最終更新から推定します。 | ||
|
重要な理由
正確かつ迅速な分類は、効率的な振り分けとレポート作成に欠かせません。このアクティビティを分析すると、初期トリアージにおける遅延や誤りを特定でき、「Incident Categorization Accuracy」ダッシュボードを支援できます。
入手先
「HPD:HelpDesk_AuditLogSystem」監査ログで、「HPD:Help Desk」フォームの「Operational Categorization Tier 1-3」、「Product Categorization Tier 1-3」、「Priority」などのフィールドの変更を追跡し、推定します。
取得
作成後に分類または優先度フィールドが最後に更新された時点のタイムスタンプから取得します。
イベントタイプ
inferred
|
|||
|
ユーザー確認の受領
|
提供した解決策によって問題が解決したことを、ユーザーが明示的に確認した状態を示します。明示的なイベントとして記録される場合もあれば、クローズ前のメモや関連システムの操作から推定する場合もあります。 | ||
|
重要な理由
これを追跡すると、自動クローズを待つだけの場合よりも、ユーザーによる検証プロセスを正確に把握できます。「Average User Confirmation Time」KPIの測定や、コミュニケーション上の不足の特定にも役立ちます。
入手先
信頼性の高い取得が難しい場合があります。インシデントが「Closed」に移行する直前の作業ログや特定のステータス理由の更新から推定できる可能性があります。「HPD:WorkLog」フォームの分析が必要になる場合があります。
取得
クローズ前の特定の作業ログエントリまたはステータス理由の更新から推定します。
イベントタイプ
inferred
|
|||
|
ユーザー確認待ち
|
解決策の実施後、サポートチームがユーザーによる解決確認を待っている状態です。通常は「Resolved」ステータスで表され、この時点から自動クローズまでの時間計測が始まります。 | ||
|
重要な理由
このアクティビティは、「User Confirmation & Verification Delays」ダッシュボードに欠かせません。修正の提供からユーザーによる検証までの遅延を定量化し、インシデントのライフサイクルが実際以上に長くなっている箇所を把握できます。
入手先
「HPD:Help Desk」フォームの「Status」が「Resolved」に変わった時点で始まります。期間は「Last Resolved Date」から、インシデントが「Closed」または「Reopened」になるまでを測定します。
取得
「Resolved」へのステータス変更で開始し、「Closed」または「In Progress」へのステータス変更で終了します。
イベントタイプ
inferred
|
|||
|
別のグループへ転送
|
このアクティビティは、インシデントがあるサポートグループから別のサポートグループへ再割り当てされたときに発生します。初回割り当て後の「Assigned Group」フィールドの変更を検出して推定します。 | ||
|
重要な理由
転送が頻繁に発生している場合、初期の振り分けが適切でないか、知識が不足している可能性があります。このアクティビティの追跡は、「Incident Reassignment Cycle Analysis」ダッシュボードと「Incident Reassignment Rate」KPIに欠かせません。
入手先
「HPD:HelpDesk_AuditLogSystem」の監査ログで、「HPD:Help Desk」フォームの「Assigned Group」フィールドについて、初回入力後に発生した subsequent changesを特定して推定します。
取得
初回割り当て後の「Assigned Group」フィールドの変更を特定します。
イベントタイプ
inferred
|
|||
|
解決策の実施
|
このアクティビティは、サポートチームが修正または回避策を適用したことを示します。多くの場合、インシデントのステータスが「Resolved」に変わった時点から推定します。 | ||
|
重要な理由
これは解決策が提供されたことを示す重要な節目です。調査完了後、修正を適用するまでの時間を測定するための重要なデータポイントです。
入手先
通常は、「HPD:Help Desk」フォームの「Status」が「Resolved」に変更された時点から推定します。タイムスタンプは「Last Resolved Date」フィールドと監査ログから取得します。
取得
「Last Resolved Date」のタイムスタンプ、または「Resolved」へのステータス変更から取得します。
イベントタイプ
inferred
|
|||
|
顧客からの情報待ち
|
ユーザーからの情報や対応を待つ間、インシデントの進行が一時停止している状態を示します。ステータスが「Pending」に変わった時点から推定します。 | ||
|
重要な理由
このアクティビティにより、担当者の作業時間と顧客の待機時間を分けて把握できます。この状態に費やされた時間を分析することは、ユーザーの回答遅延が全体の解決時間に与える影響を理解するうえで重要です。
入手先
「HPD:Help Desk」フォームの「Status」フィールドが「Pending」に更新された時点から推定します。具体的な理由は、「Status_Reason」フィールドに記録されていることが多いです。
取得
HPD:HelpDesk_AuditLogSystemで「Pending」へのステータス変更から推定します。
イベントタイプ
inferred
|
|||
抽出ガイド
始める準備はできていますか?
このテンプレートを使ってプロセスマイニングを始め、インシデント管理データから価値ある発見を得てください。今すぐ業務の最適化を始めましょう。
BMC Helix ITSMで繰り返し発生するインシデントを今すぐ解決
MTTRを35%短縮し、SLA違反をなくして、ユーザー満足度を高めます。
クレジットカードは不要です。14日間無料でお試しいただけます。