データテンプレート:インシデント管理
インシデント管理データテンプレート
- 収集を推奨する項目
- プロセスで追跡すべき主要な活動
- データシステム向けの抽出ガイダンス
インシデント管理属性
| 名前 | 説明 | ||
|---|---|---|---|
|
インシデントID
IncidentId
|
各インシデントレコードの一意の識別子です。 | ||
|
説明
Incident ID は各インシデントの主キーで、作成からクローズまでを一意に識別します。関連するアクティビティ、ログ、変更を紐づけ、インシデントのライフサイクルを一貫して把握できるようにします。 プロセスマイニングでは、ケースを定義する基礎的な属性です。同じ Incident ID を持つすべてのイベントは同一のプロセスインスタンスとみなされ、個々のインシデントがどのように処理されたかを再構成・分析できます。
その重要性
これは、インシデントのライフサイクルにおけるすべてのイベントを結び付け、エンドツーエンドのプロセス分析を可能にする必須のケース識別子です。
取得元
これは、HPD:Help DeskフォームのIncident Numberフィールド(フィールドID: 1000000161)です。
例
INC000001234567INC000002345678INC000003456789
|
|||
|
アクティビティ名
ActivityName
|
インシデントのライフサイクル内で発生した具体的なイベント/タスクの名称です。 | ||
|
説明
この属性は、インシデントに対して特定の時点で実行されたアクティビティを表します。例:「Incident Reported」「Group Assigned」「Incident Resolved」など。これらのアクティビティはプロセスマップの基本要素です。 これらの順序や頻度を分析することで、実際のプロセスフローが明らかになり、一般的な経路や標準手順からの逸脱が浮き彫りになります。インシデントを解決するためにどのような行動が取られているかを理解するうえで不可欠です。
その重要性
アクティビティはプロセスマップのステップを定義し、インシデント管理ワークフローの可視化と分析を可能にします。
取得元
通常、「HPD:Help Desk」フォームのStatus(Field ID: 7)およびStatus_Reasonフィールドの変更、または「HPD:Help Desk Audit Log」フォームの変更から導き出されます。
例
インシデント報告済みグループ割り当て解決策実施済みインシデントクローズ済み
|
|||
|
イベントのタイムスタンプ
EventTimestamp
|
アクティビティが発生した正確な日時。 | ||
|
説明
このタイムスタンプは、インシデントのライフサイクルにおける特定のイベントが発生した時刻を記録します。生データからプロセスフローを再構築するために必要な時系列を提供します。 イベントタイムスタンプは、アクティビティ間のサイクルタイムの算出、インシデントが長期間待機するボトルネックの特定、全体の解決時間の測定など、すべての時間ベースの分析に不可欠です。これはプロセス分析の時間的基盤を形成します。
その重要性
このタイムスタンプはイベントの時系列を提供し、期間の算出、ボトルネックの特定、プロセスのタイムラインの理解に不可欠です。
取得元
「Last Modified Date」(Field ID: 6)または「HPD:Help Desk」フォームの特定の日付フィールドです。過去のイベントについては、監査ログのタイムスタンプフィールドを参照します。
例
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:22:05Z
|
|||
|
Assignee
Assignee
|
インシデント対応を担当する個々のユーザーです。 | ||
|
説明
Assignee は、ある時点でインシデントの責任を持つ特定のサポート担当者/技術者を指します。Assigned Group よりも粒度の細かい情報です。 担当者別にパフォーマンスを分析すると、トップパフォーマーの特定、追加トレーニングが必要な担当者の把握、業務量の偏りの可視化に役立ちます。複雑なインシデントで、各担当者が実施したアクションの正確な時系列を追跡する用途にも使われます。
その重要性
ワークロードの分散と個人のパフォーマンスを詳細に可視化し、優秀な担当者やサポートが必要な担当者を特定するのに役立ちます。
取得元
これは、HPD:Help DeskフォームのAssigneeフィールド(フィールドID: 1000000218)です。
例
Bob SmithAlice JohnsonCharlie Brown
|
|||
|
SLA 違反があったか?
IsSlaBreached
|
インシデントが SLA 目標日後に解決されたかどうかを示すフラグ。 | ||
|
説明
この真偽値属性は、インシデントの解決時間が定義されたSLAを超過した場合にTrueとなります。これにより、各インシデントのSLAパフォーマンスについて明確な二値の結果が提供されます。 このフラグは、インシデントSLAパフォーマンス概要 ダッシュボードの作成とインシデントSLA遵守率 KPIの計算に不可欠です。サービスレベル目標を満たせなかったすべてのインシデントを直接フィルタリングおよび集計できるため、分析を簡素化し、SLA違反の理由の調査を容易にします。
その重要性
このフラグはSLA遵守分析を簡素化し、SLA違反のすべてのインシデントを簡単にフィルタリングして根本原因を調査できるようにします。
取得元
「Incident Resolved」イベントのタイムスタンプを「SlaTargetDate」と比較して算出されます。解決タイムスタンプが目標日より後である場合、このフラグはtrueです。
例
truefalse
|
|||
|
インシデントカテゴリ
IncidentCategory
|
インシデントの分類で、多くの場合は階層構造です。 | ||
|
説明
Incident(インシデント)のカテゴリ分類は、インシデントを構造的に分類するための方法であり、通常、多段階の階層(例:Tier 1: Hardware、Tier 2: Laptop、Tier 3: Battery)が用いられます。このデータは、ルーティング、レポート作成、傾向分析に不可欠です。 Process Miningでは、カテゴリ分類は異なる種類のインシデントを個別に分析するために使用されます。初期カテゴリと最終カテゴリを比較することでIncident Categorization Accuracy dashboardをサポートし、Root Cause Trends dashboardの傾向特定に役立ちます。
その重要性
カテゴリ分類により、正確なルーティング、トレンド分析、およびさまざまな種類のインシデント間のパフォーマンス比較が可能になります。
取得元
「HPD:Help Desk」フォームにある「Operational Categorization Tier 1/2/3」フィールドです。
例
Hardware > Laptop > Batteryソフトウェア > エンタープライズアプリ > ログインエラーネットワーク > 接続 > Wi-Fi
|
|||
|
インシデントステータス
IncidentStatus
|
イベント時点におけるインシデントのステータス(現在または履歴)です。 | ||
|
説明
この属性は、インシデントの現在の状態(例:New、In Progress、Pending、Resolved、Closed)を示します。これは、インシデントがそのライフサイクルのどの段階にあるかを示すスナップショットです。 ステータス変更の分析は、インシデント管理プロセスを理解する上で基本となります。これにより、各アクティビティの定義、異なる状態(例:インシデントがPendingである期間)に費やされた時間の測定、および停滞している、または非アクティブなインシデントの特定が可能になります。
その重要性
ステータス変更の追跡は、インシデントの進行状況を理解し、「Pending」や「In Progress」などの特定のステータスで費やされる時間を測定する上で重要です。
取得元
これは、HPD:Help DeskフォームのStatusフィールド(フィールドID: 7)です。
例
新規割り当て済み進行中保留中解決済みクローズ
|
|||
|
インシデント解決時間
IncidentResolutionTime
|
インシデントの初回報告から解決までに経過した総時間です。 | ||
|
説明
これは、インシデント報告アクティビティとインシデント解決済みアクティビティ間の期間を表す算出メトリクスです。インシデント管理において最も一般的で重要なKPIの一つです。 このメトリクスは、解決プロセスの効率性を直接測定します。プロセスマイニングでは、主要なパフォーマンス指標として使用され、異なるインシデントカテゴリ、優先度、およびチーム全体で分析され、改善領域を特定し、プロセス変更による影響を長期にわたって追跡します。
その重要性
これは、インシデント管理プロセスのエンドツーエンドの効率性を測定する重要なKPIであり、ユーザー満足度に直接影響を与えます。
取得元
各インシデントIDについて、最初のイベントのタイムスタンプを「Incident Resolved」イベントのタイムスタンプから減算して算出されます。
例
2592003600864000
|
|||
|
サービス
Service
|
インシデントの影響を受けた業務または技術サービスです。 | ||
|
説明
この属性は、インシデントを構成管理データベース(CMDB)で定義された特定のサービス(例:Email Service、VPN Access、SAP Financialsなど)に紐付けます。 この紐付けは、インシデントのビジネスへの影響を理解するために非常に重要です。サービス別にインシデントを分析することで、大量のインシデントを生み出している問題サービスを特定し、特定のテクノロジーに関連する繰り返しの問題を浮き彫りにし、問題管理のための傾向分析をサポートします。
その重要性
インシデントとビジネスサービスを関連付けることは、影響分析を行い、どのサービスが最も問題発生しやすいかを特定するために不可欠です。
取得元
これは、HPD:Help Deskフォームにおける影響を受ける構成アイテム(CI)を表すServiceCIまたは類似のフィールドです。
例
会社メールSAP ERPリモートアクセスVPN人事ポータル
|
|||
|
優先度
Priority
|
インシデントに設定された優先度で、対応の緊急度を決定します。 | ||
|
説明
優先度とは通常、影響度と緊急度の組み合わせによって決定され、インシデント解決の順序と速度を定めます。一般的な値は「高」から「低」まであります。 プロセスマイニングにおいて、優先度別にインシデントを分析することは、パフォーマンス分析にとって非常に重要です。「優先度の高いインシデントに対してSLAを達成できているか?」「優先度の低いインシデントはより長い遅延が発生していないか?」といった疑問に答えるのに役立ちます。優先度でフィルタリングすることで、最も重要なビジネス課題に焦点を当てた分析が可能になります。
その重要性
この属性は、高優先度のインシデントがより迅速に処理され、特定のサービスレベル目標を達成できるよう、分析をセグメント化するために不可欠です。
取得元
これは、HPD:Help DeskフォームのPriorityフィールド(フィールドID: 1000000164)です。
例
重大高中低
|
|||
|
再オープンされたか?
IsReopened
|
インシデントが「解決済み」ステータスになった後に再オープンされたかどうかを示すフラグ。 | ||
|
説明
この真偽値属性は、インシデントが一度解決済みとマークされた後、再びアクティブな状態(例:進行中)に戻った場合にTrueとなります。これは、最初の修正が効果的でなかった、または不完全であったことを示します。 これは手戻りの直接的な尺度であり、インシデント手戻り率 KPIの計算に用いられます。再オープンされたインシデントを分析することで、品質の低い修正、不十分なテスト、あるいは適切に対処されなかった繰り返しの問題を特定するのに役立ち、手戻りおよびエスカレーションパス ダッシュボードをサポートします。
その重要性
再作業と解決策の品質を直接測定します。再オープン率が高い場合は、不十分な修正とプロセス上の弱点を示しています。
取得元
インシデントのアクティビティのシーケンスを分析して算出されます。「Resolution Implemented」アクティビティの後に「Incident Reopened」または類似のアクティビティが表示された場合、このフラグはtrueに設定されます。
例
truefalse
|
|||
|
割り当てられたグループ
AssignedGroup
|
インシデント対応を担うサポートグループです。 | ||
|
説明
この属性は、インシデントがアサインされたチームまたは部署(例:Service Desk、Network Team、Database Administratorsなど)を識別します。アサイン状況を追跡することは、チーム間のワークフローを理解する上で不可欠です。 この属性は、チーム間の引き継ぎ分析、特定のグループによって引き起こされるボトルネックの特定、およびインシデント再アサイン率の測定に利用されます。組織内でのインシデントの経路を視覚化し、非効率なルーティングや知識のギャップがある領域を明確にするのに役立ちます。
その重要性
どのグループが割り当てられているかを追跡することで、引き継ぎの分析、再割り当てループの特定、および特定のチーム内でボトルネックを特定するのに役立ちます。
取得元
これは、HPD:Help DeskフォームのAssigned Groupフィールド(フィールドID: 1000000217)です。
例
サービスデスクネットワーク運用アプリケーションサポートティア2インフラストラクチャサービス
|
|||
|
SLA目標日
SlaTargetDate
|
SLA に基づき、インシデントの解決が期待される期日・時刻です。 | ||
|
説明
この属性は、適用されるサービスレベル契約(SLA)によって定義されたインシデント解決の期限を記録します。これは、インシデントの優先度と定義されたサービス時間に基づいて計算されます。 このタイムスタンプは、実際の解決時間を測定するためのベンチマークとなります。インシデントSLA遵守率 KPIの計算や、SLAパフォーマンスを視覚化するダッシュボード構築に不可欠です。期限が迫っているインシデントをプロアクティブに監視することを可能にします。
その重要性
これはSLAコンプライアンスを測定するためのベンチマークです。インシデントが期限内に解決されたか、または合意に違反したかを計算することを可能にします。
取得元
このデータは通常、SLM:Measurementフォームに保存され、インシデントに紐付けられます。これはHPD:Help Desk上の直接的なフィールドではありません。
例
2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
|
|||
|
クローズコード
CloseCode
|
インシデントをクローズする際に選択するコードで、解決結果を示します。 | ||
|
説明
Close Code は、インシデントがどのように解決されたかを体系的に示すコードです。例:「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および「インシデント再割り当てサイクル分析」ダッシュボードを直接サポートします。チケットがチーム間でたらい回しにされ、大幅な遅延とプロセスの非効率性を招く「ピンポン効果」の定量化に役立ちます。
その重要性
非効率なルーティングと引き渡しを定量化し、チーム間の再割り当てループで滞留するインシデントの特定に役立ちます。
取得元
イベントログ内で特定のインシデントIDについて「AssignedGroup」の値が変更された回数をカウントして算出されます。
例
0135
|
|||
|
最終データ更新
LastDataUpdate
|
このイベントのデータがソースシステムから最後に更新された日時を示すタイムスタンプです。 | ||
|
説明
この属性は、最新のデータ抽出の日時を記録します。これにより、分析対象データの鮮度に関するコンテキストが提供され、プロセスインサイトがどの程度最新であるかを理解する上で重要です。 最終更新時刻の把握は、レポート作成およびダッシュボード作成において不可欠であり、データの適時性をユーザーに伝え、最新のインシデント活動がどこまで含まれているかに関する期待値を管理するのに役立ちます。
その重要性
データの鮮度を示し、ユーザーがプロセス分析やそこから得られるインサイトがどの程度最新であるかを理解できるようにします。
取得元
この値は通常、データ抽出(ETL)プロセス中にデータセットに生成され、付与されます。
例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
|
|||
|
影響度
Impact
|
インシデントが業務プロセスに与える影響度の指標です。 | ||
|
説明
Impact(影響度)は、インシデントがビジネスに与える悪影響の度合いを評価します。「広範囲/甚大」、「重大/大規模」、「中程度/限定的」、「軽微/局所的」といった尺度で定義されることがよくあります。 Urgency(緊急度)と組み合わせることで、ImpactはインシデントのPriority(優先度)を決定します。影響度によって分析することで、技術的な複雑さにかかわらず、どのインシデントが最もビジネスに大きな混乱をもたらしているかを理解するのに役立ちます。これは、プロセス改善の取り組みを優先する上で重要です。
その重要性
インシデントのビジネス上の重大度を定量化するのに役立ちます。これは、優先度を決定し、影響の大きい問題に分析を集中させるための重要な要素です。
取得元
これは、HPD:Help DeskフォームのImpactフィールド(フィールドID: 1000000163)です。
例
1-Extensive/Widespread2-Significant/Large3-Moderate/Limited4-Minor/Localized
|
|||
|
提出者
Submitter
|
インシデントを最初に報告した人です。 | ||
|
説明
Submitter は、問題を経験し報告したエンドユーザー/顧客を指します。インシデントの作業を行う担当者とは区別されます。 申請者や所属部門別にデータを分析すると、追加のトレーニングが必要なユーザー群や、特定の種類の問題の影響を強く受けているグループの特定に役立ちます。インシデント管理プロセスを顧客視点で捉えるための属性です。
その重要性
問題を報告したユーザーを特定し、ユーザーの部署、場所、役割に基づいて分析を行うことで、ユーザー固有の傾向を発見できます。
取得元
この情報は、HPD:Help Deskフォーム上のSubmitterフィールドまたは顧客情報に関連するフィールドで捕捉されます。
例
John Doeジェーン・スミスPeter Jones
|
|||
|
根本原因
RootCause
|
インシデントの根底にある理由/最終的な原因です。 | ||
|
説明
Root Cause は、対処すればインシデントの再発を防げる根本的な要因です。関連する問題管理の調査で特定されることがよくあります。 すべてのインシデントで根本原因が記録されるわけではありませんが、この属性を分析することは予防的な問題管理に不可欠です。「Root Cause Identification Rate」KPI を支え、再発する事象の傾向を追うダッシュボードの作成に役立ち、恒久対策の実装を後押しします。
その重要性
根本原因の特定は、問題管理および繰り返し発生するインシデント量を削減するための分析に不可欠です。
取得元
この情報は、インシデント上の専用のRoot Causeフィールド、またはより一般的には紐付けられたPBI:Problem Investigationフォームに含まれている場合があります。
例
サーバーのディスク容量不足ネットワーク設定エラーバージョン2.1のソフトウェアのバグセキュリティ証明書の期限切れ
|
|||
|
解決説明
Resolution
|
インシデント解決のために実行された手順の自由記述テキスト。 | ||
|
説明
このフィールドには、最終的な解決策に関する詳細な記述(人間が作成したもの)が含まれています。これは、問題を修正し、ユーザーへのサービスを復旧するために何が行われたかを説明します。 非構造化データであるにもかかわらず、このテキストデータはテキストマイニング技術を用いて分析でき、一般的な解決パターンを特定したり、特定の問題に関連するキーワードを抽出したり、根本原因分析を補完したりするのに役立ちます。構造化データフィールドでは不足しがちな定性的なコンテキストを提供します。
その重要性
解決策に関する定性的な詳細を提供し、テキストマイニングで構造化データでは見られないパターンを見つけるのに使用できます。
取得元
これは、HPD:Help DeskフォームのResolutionフィールド(フィールドID: 1000000156)です。
例
ユーザーのパスワードはActive Directoryを介してリセットされました。ブラウザのキャッシュとクッキーをクリアしたところ、ログインの問題が解決しました。IDFクローゼット3Bのネットワークスイッチを再起動しました。
|
|||
インシデント管理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
インシデントクローズ済み
|
これは、解決が確認された後、または確認期間が経過した後に、インシデント記録の正式なクローズを示す最終アクティビティです。ステータスが「Closed」に設定されると記録されます。 | ||
|
その重要性
これは、インシデントライフサイクルにおける最終的な終了イベントです。解決済みからクローズ済みまでの時間は、ユーザー確認と事務処理完了期間を表します。
取得元
このイベントは、HPD:Help DeskフォームのStatusフィールドがClosedに設定された時点に対応します。タイムスタンプはClosed Dateフィールドと監査ログに記録されます。
取得
「クローズ日時」タイムスタンプ、またはステータスが「クローズ済み」に変更された時点から。
イベントタイプ
inferred
|
|||
|
インシデント報告済み
|
このアクティビティは、システム上でインシデントレコードが初めて作成されたことを示します。コアのインシデント管理フォームに記録された作成タイムスタンプから明示的に取得します。 | ||
|
その重要性
これは、インシデントのライフサイクルにおける主要な開始イベントです。全体の解決時間の算出や、インシデント発生率の把握に不可欠です。
取得元
このイベントは、HPD:Help Deskフォームにおけるレコード作成に対応します。タイムスタンプは通常、Submit DateフィールドまたはReported Dateフィールドから取得されます。
取得
HPD:Help Deskフォームの「提出日時」タイムスタンプから。
イベントタイプ
explicit
|
|||
|
インシデント解決済み
|
このアクティビティは、最終クローズ前に、サービスデスクの観点でインシデントが正式に解決されたことを示します。インシデントのステータスが「Resolved」に設定された時点で取得します。 | ||
|
その重要性
これは、SLAコンプライアンスと解決時間を測定する上で最も重要なマイルストーンです。ユーザーへのサービスの復旧を示します。
取得元
このイベントは、HPD:Help DeskフォームのStatusフィールドがResolvedに設定された時点に対応します。タイムスタンプはLast Resolved Dateフィールドと監査ログに記録されます。
取得
監査ログ内の、ステータスが「解決済み」に変更されたタイムスタンプから。
イベントタイプ
inferred
|
|||
|
グループ割り当て
|
このアクティビティは、調査のためにインシデントが特定のサポートグループへ初めて割り当てられたことを示します。インシデント作成後に「Assigned Group」フィールドへ最初に値が入ったタイミングから推定します。 | ||
|
その重要性
これは、実際の作業の開始を示す重要なマイルストーンです。初回アサインまでの時間を追跡することは、応答時間と初期ルーティング効率を評価するために不可欠です。
取得元
「HPD:Help Desk」フォームの監査ログ (HPD:HelpDesk_AuditLogSystem) から、「Assigned Group」フィールドの最初の設定を捕捉して推測されます。
取得
「割り当てグループ」フィールドが最初に設定されたタイムスタンプから。
イベントタイプ
inferred
|
|||
|
調査開始
|
サポート担当者がインシデントの作業を本格的に開始したことを示します。これは通常、ステータスが「Assigned」から「In Progress」に変更されることで推測されます。 | ||
|
その重要性
このマイルストーンは、キューでの待機から診断への移行を示します。調査開始までの待機時間を分析することで、リソースのボトルネックを特定し、「診断・調査ボトルネック」ダッシュボードをサポートします。
取得元
「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
|
|||
|
インシデントカテゴリ分類済み
|
インシデントが運用上および製品上のカテゴリで分類され、優先度が設定された時点を表します。これは通常、カテゴリ分類フィールドの入力または最終変更から推測されます。 | ||
|
その重要性
正確でタイムリーなカテゴリ分類は、効率的なルーティングとレポート作成に不可欠です。このアクティビティを分析することで、初期トリアージプロセスにおける遅延や不正確さを特定し、「インシデントカテゴリ分類の正確性」ダッシュボードをサポートします。
取得元
「HPD:Help Desk」フォーム上の「Operational Categorization Tier 1-3」、「Product Categorization Tier 1-3」、「Priority」といったフィールドへの変更を追跡する監査ログ (HPD:HelpDesk_AuditLogSystem) から推測されます。
取得
作成後の、分類または優先度フィールドに対する最終更新のタイムスタンプから。
イベントタイプ
inferred
|
|||
|
インシデントキャンセル済み
|
このアクティビティは、誤って作成された、またはもはや関連性がないインシデントの終了を表します。インシデントのステータスが「Cancelled」に設定された時点で取得します。 | ||
|
その重要性
これはインシデントライフサイクルの最終終了状態であり、成功した解決とは異なります。キャンセルされたインシデントを分析することで、インシデント作成チャネルや重複報告に関する問題を浮き彫りにすることができます。
取得元
「HPD:Help Desk」フォームの「Status」フィールドが「Cancelled」に更新されたときに推測されます。タイムスタンプは監査ログに記録されます。
取得
監査ログのステータスが「Cancelled」に変更されたことから推測されます。
イベントタイプ
inferred
|
|||
|
インシデント再オープン済み
|
以前「解決済み」としてマークされていたインシデントが、問題が解決されていないために再アクティブ化された状態を表します。これは、「解決済み」から「進行中」や「割り当て済み」のようなアクティブステータスに戻る変更から推測されます。 | ||
|
その重要性
このアクティビティは手戻りと初期対応の有効性を直接測定します。再オープンされたインシデントが多い場合は修正品質の低さを示す重要なサインであり、「Incident Rework Rate」KPI の指標になります。
取得元
監査ログ (HPD:HelpDesk_AuditLogSystem) から、特定のインシデントIDの「Status」が「Resolved」から「In Progress」または「Assigned」に変更されたことを検出して推測されます。
取得
ステータスが「Resolved」からアクティブな状態に移行したことから推測されます。
イベントタイプ
inferred
|
|||
|
お客様からの入力待ち
|
ユーザーからの情報やアクションを待機している間、インシデントの進行が一時停止しているポイントを表します。これは、「保留中」ステータスへの変更から推測されます。 | ||
|
その重要性
このアクティビティにより、エージェントの作業時間と顧客の待ち時間を切り分けられます。この状態に費やされた時間を分析することは、ユーザーの応答遅延が全体の解決時間に与える影響を把握するうえで不可欠です。
取得元
「HPD:Help Desk」フォームの「Status」フィールドが「Pending」に更新されたときに推測されます。具体的な理由は、「Status_Reason」フィールドによく見られます。
取得
HPD:HelpDesk_AuditLogSystem のステータスが「Pending」に変更されたことから推測されます。
イベントタイプ
inferred
|
|||
|
ユーザー確認受信
|
ユーザーが、提供された解決策によって問題が解決されたことを積極的に確認している状態を表します。これは明示的なイベントである場合もあれば、クローズ前のメモや関連するシステムアクションから推測される場合もあります。 | ||
|
その重要性
これを追跡することで、自動クローズを待つよりも、ユーザー検証プロセスのより正確な全体像を把握できます。「Average User Confirmation Time」KPIを測定し、コミュニケーションのギャップを特定するのに役立ちます。
取得元
これを確実に捕捉することは困難な場合があります。インシデントがクローズ済みとなる直前の作業ログエントリまたは特定のステータス理由の更新から推測できる場合があります。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」フィールドの変更検知から推定します。 | ||
|
その重要性
頻繁な転送は、初期ルーティングの誤りやナレッジギャップを示しています。この活動をトラッキングすることは、「インシデント再割り当てサイクル分析」ダッシュボードおよび「インシデント再割り当て率」KPIにとって不可欠です。
取得元
監査ログ (HPD:HelpDesk_AuditLogSystem) から、「HPD:Help Desk」フォームの「Assigned Group」フィールドが最初に設定された後に、その後の変更を特定して推測されます。
取得
初期割り当て後の「担当グループ」フィールドへの変更を特定します。
イベントタイプ
inferred
|
|||
|
解決策実施済み
|
このアクティビティは、サポートチームが修正または回避策を適用したことを示します。インシデントのステータスが「Resolved」に遷移した際に推定されることがよくあります。 | ||
|
その重要性
これは、解決策が提供されたことを示す重要なマイルストーンです。調査完了後に修正を適用するまでの時間を測定するための重要なデータポイントとなります。
取得元
これは通常、「HPD:Help Desk」フォームでStatusが「Resolved」に変更されたときに判断されます。タイムスタンプは「Last Resolved Date」フィールドと監査ログに記録されます。
取得
「最終解決日時」タイムスタンプ、またはステータスが「解決済み」に変更された時点から。
イベントタイプ
inferred
|
|||