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

BMC Helix ITSM
インシデント管理のデータテンプレート

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

このテンプレートでは、インシデント管理プロセスの最適化に必要なデータを収集する方法を詳しく説明します。記録すべき属性とアクティビティに加え、データの抽出方法もご案内します。データ準備を効率よく進め、プロセス分析をスムーズに始めるためにお役立てください。
  • 収集を推奨する属性
  • プロセスで記録すべき主なアクティビティ
  • データシステムからの抽出方法
イベントログを初めて作成する方はこちら: プロセスマイニング用イベントログの作成方法.

インシデント管理の属性

インシデント管理プロセスを詳しく分析するために、イベントログに含めることを推奨するデータ項目です。
3 必須 8 推奨 10 任意
名前 説明
インシデントID
IncidentId
各インシデントレコードを一意に識別するIDです。
説明

インシデントIDは各インシデントの主キーであり、作成からクローズまでレコードを一意に識別します。関連するすべてのアクティビティ、ログ、変更を結び付け、インシデントのライフサイクル全体を把握できるようにします。

プロセスマイニングでは、この属性がケースを定義するため、欠かせません。同じインシデントIDを持つすべてのイベントを1つのプロセスインスタンスとして扱うことで、個々のインシデントへの対応を再構成し、分析できます。

重要な理由

インシデントのライフサイクルにおけるすべてのイベントを結び付けるケース識別子です。これにより、プロセスをエンドツーエンドで分析できます。

入手先

「HPD:Help Desk」フォームの「Incident Number」フィールド(フィールドID:1000000161)です。

例
INC000001234567INC000002345678INC000003456789
アクティビティ名
ActivityName
インシデントのライフサイクルで発生した特定のイベントまたはタスクの名前です。
説明

この属性は、「インシデントの報告」「グループの割り当て」「インシデントの解決」など、インシデントに対して特定の時点で実施されたアクティビティを表します。これらのアクティビティがプロセスマップを構成します。

アクティビティの順序や頻度を分析すると、実際のプロセスフローを把握し、よくある経路を特定して、標準手順からの逸脱を明らかにできます。インシデントの解決にどのような対応が行われているかを理解するうえで欠かせません。

重要な理由

アクティビティはプロセスマップの各ステップを定義し、インシデント管理のワークフローを可視化して分析できるようにします。

入手先

通常、「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違反のインシデントを絞り込み、根本原因を調査しやすくなります。

入手先

「Incident Resolved」イベントのタイムスタンプと「SlaTargetDate」を比較して算出します。解決日時が目標日時を過ぎている場合、このフラグはtrueになります。

例
truefalse
インシデントカテゴリ
IncidentCategory
多くの場合、階層構造で分類されるインシデントの種類です。
説明

インシデントのカテゴリ分けでは、階層を設けてインシデントを体系的に分類します。たとえば、第1階層:ハードウェア、第2階層:ノートパソコン、第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)で定義された特定のサービスに関連付けます。例として、「社内メールサービス」「VPNアクセス」「SAP財務」などがあります。

この関連付けは、インシデントが業務に与える影響を把握するうえで重要です。サービス別にインシデントを分析すると、多数のインシデントを引き起こしているサービスや、特定の技術に関連する繰り返し発生する問題を特定できます。また、問題管理における傾向分析にも役立ちます。

重要な理由

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

入手先

「HPD:Help Desk」フォームの「ServiceCI」フィールド、または影響を受けた構成アイテム(CI)を示す同等のフィールドです。

例
社内メールSAP ERPリモートアクセスVPN人事ポータル
優先度
Priority
インシデントに設定された優先度です。対応の緊急性を決定します。
説明

優先度は通常、影響度と緊急度を組み合わせて決まり、インシデントを解決する順序と速度を左右します。一般的な値は「重大」から「低」までです。

プロセスマイニングでは、優先度別のインシデント分析がパフォーマンスの評価に欠かせません。「優先度の高いインシデントでSLAを達成できているか」「優先度の低いインシデントでは遅延が長くなっていないか」といった問いに答えられます。優先度で絞り込むことで、業務への影響が大きい問題に焦点を当てて分析できます。

重要な理由

この属性を使うと、分析対象を分けて確認できます。優先度の高いインシデントに迅速に対応し、それぞれに定められたサービスレベル目標を達成するうえで欠かせません。

入手先

「HPD:Help Desk」フォームの「Priority」フィールド(フィールドID:1000000164)です。

例
重大高中低
再オープンの有無
IsReopened
インシデントが「解決済み」になった後に再オープンされたかどうかを示すフラグです。
説明

この真偽値属性は、インシデントが「解決済み」と記録された後に、ステータスが「対応中」などのアクティブな状態に戻った場合にtrueになります。最初の修正が有効でなかった、または不完全だったことを示します。

手戻りを直接測定でき、「インシデント手戻り率」の重要業績評価指標(KPI)の算出に利用されます。再オープンされたインシデントを分析すると、修正の品質不足、テスト不足、適切に対処されていない再発問題を特定できます。「手戻りとエスカレーション経路」ダッシュボードにも役立ちます。

重要な理由

手戻りと解決の品質を直接測定できます。再オープン率が高い場合、修正の有効性やプロセスに問題がある可能性があります。

入手先

インシデントのアクティビティの順序を分析して算出します。「Resolution Implemented」アクティビティの後に「Incident Reopened」または同等のアクティビティがある場合、このフラグはtrueになります。

例
truefalse
割り当て先グループ
AssignedGroup
インシデントの対応を担当するサポートグループです。
説明

この属性は、インシデントの担当チームや部門を示します。例として、「サービスデスク」「ネットワークチーム」「データベース管理者」などがあります。担当の記録を追うことで、チーム間で業務がどのように引き継がれているかを把握できます。

チーム間の引き継ぎの分析、特定のグループに起因するボトルネックの特定、インシデント再割り当て率の測定に利用できます。組織内でインシデントがたどる経路を可視化し、非効率な振り分けや知識の不足がある箇所を明らかにします。

重要な理由

担当グループを追跡すると、引き継ぎの分析や再割り当ての繰り返しの特定、特定のチーム内で発生するボトルネックの把握に役立ちます。

入手先

「HPD:Help Desk」フォームの「Assigned Group」フィールド(フィールドID:1000000217)です。

例
サービスデスクネットワーク運用アプリケーションサポート第2階層インフラストラクチャサービス
担当者
Assignee
インシデント対応を割り当てられた個人ユーザーです。
説明

担当者は、特定の時点でインシデント対応を担うサポート担当者または技術者です。割り当て先グループよりも細かな情報を確認できます。

担当者別に実績を分析すると、優れた実績を上げている担当者や追加のトレーニングが必要な担当者、業務負荷の偏りを把握できます。また、複雑なインシデントに対応した個人の作業手順を正確に追跡する際にも役立ちます。

重要な理由

業務負荷の分布や個人の実績を詳しく確認でき、優れた実績を上げている担当者や支援が必要な担当者の特定に役立ちます。

入手先

「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
インシデントのクローズ時に選択する、解決結果を示すコードです。
説明

クローズコードは、インシデントの解決方法を体系的に記録します。例として、「ユーザーが解決」「障害なし」「重複インシデント」「恒久対策を適用」などがあります。

この属性は、解決の有効性や結果の分析に役立ちます。実際の修正を行わずにクローズされたインシデントや、ユーザー自身が頻繁に問題を解決しているカテゴリを特定できます。こうした情報は、ナレッジベースの記事やセルフサービスツールの改善機会を見つける手がかりになります。

重要な理由

解決結果を体系的に記録し、修正の有効性やインシデントのクローズ方法の傾向を分析できます。

入手先

通常、「HPD:Help Desk」フォームの解決情報またはクローズ情報に含まれます。

例
リモートで解決重複する問題ユーザーの操作ミス対応不要
ソースシステム
SourceSystem
インシデントデータの抽出元のシステムです。
説明

この属性はデータの取得元を示します。複数のITSMツールや連携システムを使う環境で特に役立ちます。特定のBMC Helix ITSMインスタンスなど、データが想定したソースから取得されたことを確認できます。

分析では、本番、開発、レガシーシステム間で異なる可能性のあるプロセスやデータの特性を区別できます。これにより、データの来歴を明確にし、信頼性を確保できます。

重要な理由

データの取得元を特定します。データの検証や、複数の連携システムにまたがる分析の管理に欠かせません。

入手先

通常、データの抽出、変換、読み込み(ETL)の過程で追加される固定値です。

例
BMCHelixITSM_ProdITSM-EU-InstanceServiceManagement-APAC
再割り当て回数
ReassignmentCount
インシデントが別のグループに再割り当てされた合計回数です。
説明

この指標は、インシデントのライフサイクル中に「AssignedGroup」フィールドが変更された回数を数えます。回数が多い場合、最初の振り分けに問題がある、最初の問い合わせで解決できていない、または複数のチームの対応が必要な複雑な問題である可能性があります。

「インシデント再割り当て率」の重要業績評価指標(KPI)や「インシデント再割り当てサイクル分析」ダッシュボードに直接役立ちます。チケットがチーム間を何度も行き来する状況を数値化できます。こうしたやり取りは、大幅な遅延やプロセスの非効率につながります。

重要な理由

非効率な振り分けや引き継ぎを数値化し、チーム間で再割り当てが繰り返されているインシデントの特定に役立ちます。

入手先

イベントログで、特定のインシデントIDに対する「AssignedGroup」の値の変更回数を数えて算出します。

例
0135
最終データ更新
LastDataUpdate
このイベントのデータがソースシステムから最後に更新された日時を示すタイムスタンプです。
説明

この属性は、直近のデータ抽出日時を記録します。分析対象のデータがどの程度新しいかを示すため、プロセス分析のインサイトがどの時点までの状況を反映しているかを把握するうえで重要です。

最終更新時刻を把握することは、レポートやダッシュボードの作成にも欠かせません。データの鮮度を利用者に伝え、最新のインシデント対応が含まれているかどうかについて、適切な見通しを持てるようにします。

重要な理由

データの鮮度を示し、プロセス分析やそこから得られるインサイトがどの時点までの状況を反映しているかを把握できるようにします。

入手先

通常、データ抽出(ETL)の過程でデータセットに生成・記録される値です。

例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
受付チャネル
Channel
インシデントの報告に使われた方法です。
説明

この属性は、インシデントの報告方法を示します。電話、メール、セルフサービスポータル、窓口への直接訪問などがあります。サポートプロセスにインシデントが登録された経路を確認できます。

チャネル別に分析すると、効果の高いチャネルや、解決しやすい、または難しいインシデントが多く寄せられるチャネルを把握できます。また、どこに自動化やユーザートレーニングの投資が必要かを検討する際にも役立ちます。たとえば、初期情報をより詳しく収集できるセルフサービスポータルの利用を促す判断に役立ちます。

重要な理由

受付チャネルを把握すると、各受付方法の効率を分析でき、セルフサービスや自動化への投資判断にも役立ちます。

入手先

「HPD:Help Desk」フォームの「Reported Source」フィールド(フィールドID:1000000215)です。

例
メール電話セルフサービス直接入力
報告者
Submitter
最初にインシデントを報告した人です。
説明

報告者は、問題を経験して報告したエンドユーザーまたは顧客です。インシデント対応を担当する割り当て先とは異なります。

報告者やその所属部門別にデータを分析すると、追加のトレーニングが必要なユーザーグループや、特定の種類の問題の影響を受けているグループを特定できます。インシデント管理プロセスを顧客の視点から把握できます。

重要な理由

問題を報告したユーザーを特定できます。部門、勤務地、役割などに基づいて分析し、ユーザーごとの傾向を把握できます。

入手先

「HPD:Help Desk」フォームの「Submitter」フィールド、または顧客情報に関連するフィールドに記録されます。

例
John DoeJane SmithPeter Jones
影響度
Impact
インシデントが業務プロセスに及ぼす影響の大きさです。
説明

影響度は、インシデントが業務に及ぼす悪影響の大きさを示します。「広範囲」「大きい」「限定的」「局所的」などの段階で定義されることがあります。

緊急度と組み合わせて、インシデントの優先度を決定します。影響度別に分析すると、技術的な複雑さにかかわらず、業務に大きな支障を与えるインシデントを把握できます。プロセス改善の取り組みの優先順位を決めるうえで役立ちます。

重要な理由

インシデントが業務に与える深刻さを数値化し、優先度の決定や影響の大きい問題に焦点を当てた分析に役立ちます。

入手先

「HPD:Help Desk」フォームの「Impact」フィールド(フィールドID:1000000163)です。

例
1:広範囲2:大きい3:限定的4:局所的
根本原因
RootCause
インシデントの根本的な理由、または最終的な原因です。
説明

根本原因とは、対処することでインシデントの再発を防げる根本的な問題です。関連する問題調査の過程で特定されることがよくあります。

すべてのインシデントで根本原因が文書化されるとは限りませんが、この属性の分析は予防的な問題管理に欠かせません。「根本原因特定率」の重要業績評価指標(KPI)を算出する際に利用でき、再発する問題の傾向を追跡するダッシュボードの作成にも役立ちます。恒久的な解決策の実施に向けた取り組みを支援します。

重要な理由

根本原因の特定は、問題管理や、インシデントの再発を減らすための分析に欠かせません。

入手先

インシデント専用の「Root Cause」フィールドに記録されている場合もありますが、多くの場合、関連する「PBI:Problem Investigation」フォームに記録されています。

例
サーバーのディスク容量不足ネットワーク設定エラーバージョン2.1のソフトウェアの不具合セキュリティ証明書の有効期限切れ
解決内容
Resolution
インシデントの解決に行った手順を自由記述で説明する項目です。
説明

このフィールドには、最終的な解決内容を担当者が詳しく記述します。問題を修正し、ユーザーがサービスを再び利用できるようにするために行った対応を説明します。

構造化されていないテキストですが、テキストマイニングで分析することで、よくある解決パターンの特定や、特定の問題に関連するキーワードの抽出、根本原因分析の補足に役立てられます。構造化データだけでは得られない定性的な背景情報を確認できます。

重要な理由

解決内容の定性的な情報を含み、テキストマイニングによって構造化データからは見えないパターンを特定できます。

入手先

「HPD:Help Desk」フォームの「Resolution」フィールド(フィールドID:1000000156)です。

例
Active Directoryでユーザーのパスワードをリセットしました。ブラウザーのキャッシュとCookieを削除し、ログインの問題を解決しました。IDFの3Bクローゼットにあるネットワークスイッチを再起動しました。
必須 推奨 任意

インシデント管理のアクティビティ

プロセスを正確に把握し、フローを可視化するためにイベントログに記録すべき主な手順と節目です。
5 推奨 9 任意
アクティビティ 説明
インシデントのクローズ
最終アクティビティとして、解決が確認された後、または確認期間が過ぎた後にインシデントレコードを正式にクローズしたことを示します。ステータスが「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:Help Desk」フォームの監査ログ(「HPD:HelpDesk_AuditLogSystem」)から、「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」重要業績評価指標の基礎となります。サービス上の約束を守れなかったインシデントを直接特定します。

入手先

「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」重要業績評価指標の確認に役立ちます。

入手先

特定のインシデントIDについて、監査ログ(「HPD:HelpDesk_AuditLogSystem」)で「Status」が「Resolved」から「In Progress」または「Assigned」に変わったことを検出して推定します。

記録

「Resolved」から対応中の状態へのステータス変更から推定します。

イベントタイプ inferred
インシデントの分類
インシデントに業務上および製品上の分類が設定され、優先度が決まった時点を示します。通常、分類フィールドへの値の入力または最終更新から推定します。
重要な理由

正確かつ迅速な分類は、効率的な振り分けとレポート作成に欠かせません。このアクティビティを分析すると、初期トリアージの遅れや誤りを特定でき、「Incident Categorization Accuracy」ダッシュボードに役立ちます。

入手先

「HPD:Help Desk」フォームの「Operational Categorization Tier 1-3」、「Product Categorization Tier 1-3」、「Priority」などのフィールドの変更を記録する監査ログ(「HPD:HelpDesk_AuditLogSystem」)から推定します。

記録

作成後に分類または優先度のフィールドが最後に更新された時点のタイムスタンプから取得します。

イベントタイプ inferred
ユーザーからの確認
提供された解決策によって問題が解決したことを、ユーザーが明示的に確認した状態を示します。明示的なイベントとして記録される場合と、クローズ前のメモや関連システムの操作から推定される場合があります。
重要な理由

このアクティビティを追跡すると、自動クローズを待つだけの場合よりも、ユーザーによる確認の状況を正確に把握できます。「Average User Confirmation Time」重要業績評価指標の測定や、コミュニケーション上の課題の特定にも役立ちます。

入手先

この情報を確実に取得するのは難しい場合があります。インシデントが「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」重要業績評価指標の確認に欠かせません。

入手先

「HPD:Help Desk」フォームで「Assigned Group」フィールドに初めて値が入力された後の変更を、監査ログ(「HPD:HelpDesk_AuditLogSystem」)から特定します。

記録

初回割り当て後の「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からデータを取得する方法

始める準備はできましたか?

このテンプレートを使ってプロセスマイニングを始め、インシデント管理データから改善につながるインサイトを見つけてください。今日から業務の改善に取り組みましょう。

BMC Helix ITSMで繰り返し発生するインシデントを今すぐ改善しましょう。

MTTRを35%短縮し、SLA違反をなくして、ユーザー満足度を高めましょう。

無料トライアルを開始しましょう

クレジットカードは不要です。14日間の無料トライアルをご利用いただけます。