データテンプレート: インシデント管理
お客様のインシデント管理データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- Jira Service Managementからのデータ抽出ガイド
インシデント管理アトリビュート
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
インシデントで発生した特定のイベントまたはステータス変更の名前です。 | ||
|
説明
アクティビティは、「インシデント作成」「インシデント割り当て」「解決策提案」のように、インシデント管理ライフサイクルにおける明確なステップまたはイベントを表します。これらは通常、Jira課題の履歴や変更ログに記録されたステータス遷移や特定の更新イベントから派生します。これらのアクティビティの順序と期間を分析することがプロセスマイニングの主要な目標であり、これにより実際のプロセスフロー、ボトルネック、および逸脱が明らかになります。
その重要性
アクティビティは、プロセスマップの基盤となり、インシデントライフサイクルの可視化と分析を可能にします。
取得元
Jiraの課題履歴および変更ログデータから導出され、ステータス遷移と主要なフィールド更新をキャプチャします。
例
インシデント割り当て済み調査開始インシデント解決済み
|
|||
|
インシデントID
IncidentId
|
Jira Service Managementにおける各インシデントチケットの一意の識別子です。 | ||
|
説明
インシデントIDは、Jiraでは課題キーと呼ばれることも多く、報告された各インシデントの主要な一意の識別子として機能します。これは、作成から最終的なクローズまでのすべての関連するアクティビティ、コメント、およびステータス変更をリンクします。プロセスマイニングにおいて、このIDは個々のインシデントのエンドツーエンドのライフサイクルを再構築するために不可欠であり、プロセス全体の包括的な分析を可能にします。
その重要性
これは、すべての関連イベントを単一のケースに関連付けるために使用されるコア識別子であり、プロセスマイニング分析の基盤となります。
取得元
これは、Jira Service Managementにおける課題の標準Key フィールドです(例:ITSM-123)。
例
INC-10234HELPDESK-5678OPS-9901
|
|||
|
開始時刻
EventTimestamp
|
アクティビティが発生した正確な日時。 | ||
|
説明
この属性は、インシデントのライフサイクルにおけるすべてのアクティビティのタイムスタンプを記録します。プロセス内の異なるステップ間の期間、サイクルタイム、待機時間を計算する上で不可欠です。正確なタイムスタンプにより、詳細なパフォーマンス分析、SLA監視、ボトルネック特定が可能になります。解決時間や診断期間など、すべてのパフォーマンス指標はこれらのタイムスタンプから導き出されます。
その重要性
タイムスタンプは、すべての時間ベースのメトリックの計算、プロセス期間の理解、およびパフォーマンスボトルネックの発見に不可欠です。
取得元
これは、Jira 課題のチェンジログまたは履歴の各エントリに関連付けられたcreated 日付です。
例
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
|
|||
|
ソースシステム
SourceSystem
|
データを抽出した元システム。 | ||
|
説明
この属性は、データの発生源を特定します。本ケースではJira Service Managementが発生源となります。複数のシステムからのデータを組み合わせてプロセス全体像を把握する環境において、特に有用です。ソースシステムを明記することで、データリネージを明確にし、データ品質や抽出に関する問題の診断に役立ちます。このモデルでは、値は静的です。
その重要性
データの発生源に関する重要なコンテキストを提供し、特にマルチシステム分析において、透明性と追跡可能性を確保します。
取得元
これは、データ抽出プロセス中に追加されるべき静的な値です。
例
Jira Service ManagementJira Cloud
|
|||
|
最終データ更新
LastDataUpdate
|
ソースシステムからデータが最後に更新されたことを示すタイムスタンプです。 | ||
|
説明
この属性は、データセットが最後に更新された日時を記録します。これは、プロセスを分析するすべての人に重要なコンテキストを提供し、データの鮮度を認識させる役割があります。最新の情報がタイムリーな意思決定に不可欠となる継続的な監視ダッシュボードでは、特に重要な意味を持ちます。値は通常、単一のデータ抽出バッチ内のすべてのイベントで同じです。
その重要性
データの適時性についてユーザーに通知します。これは分析の妥当性と正確性にとって極めて重要です。
取得元
これは、データ変換プロセス中に追加されるデータ抽出実行のタイムスタンプです。
例
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
Assignee
Assignee
|
現在インシデントに対応するために割り当てられているユーザーです。 | ||
|
説明
担当者は、特定の時点でインシデントを担当する個々のエージェントまたはユーザーです。担当者への変更を追跡することは、引き継ぎの分析、ワークロードの分散の理解、および特定のプロセスステップに関与する個人の特定に不可欠です。この属性は、サポートチーム内における個人のパフォーマンスとリソース配分に関する疑問に答えるのに役立ちます。
その重要性
個人のワークロードを追跡し、特定の担当者に関連するボトルネックを特定し、ハンドオフが解決時間に与える影響を分析するのに役立ちます。
取得元
Jira課題の標準的な「担当者」フィールドです。
例
John Smithエミリー・ジョーンズServiceDeskAgent1
|
|||
|
ステータス
Status
|
インシデントのライフサイクルにおける現在のステージです。 | ||
|
説明
ステータスフィールドは、「オープン」「進行中」「顧客待ち」「解決済み」など、定義されたワークフローにおけるインシデントの現在の状態を示します。ステータス変更は、プロセスマイニングのアクティビティログを生成するための主要な情報源です。各ステータスで費やされた時間を分析することは、ボトルネックを特定し、インシデントが最も多くの時間を費やす場所を理解するために不可欠です。
その重要性
インシデントの進行状況を直接反映し、プロセスステップと待機時間を特定するための主要な情報源となります。
取得元
Jira課題の標準的な「ステータス」フィールドです。
例
進行中顧客からの返信待ち解決済みクローズ
|
|||
|
作成日
CreatedDate
|
システムでインシデントが最初に作成された日時です。 | ||
|
説明
この属性は、インシデントのライフサイクルの公式な開始を示します。これは、総解決時間などの全体的な指標を計算する基準となるタイムスタンプです。作成日は各インシデントの静的な値であり、プロセスマイニング分析におけるケース全体の出発点となります。
その重要性
すべてのエンドツーエンドのサイクルタイム計算とSLA測定の開始点として機能します。
取得元
Jira課題の標準的な「作成日」フィールドです。
例
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
|
|||
|
優先度
Priority
|
インシデントに割り当てられた優先度レベルで、解決の緊急性を示します。 | ||
|
説明
priority(優先度)は、インシデント対応に求められる速度を決定します。これは多くの場合、影響と緊急度の組み合わせであり、SLA目標に直接影響を与えます。優先度別にインシデントを分析することで、高優先度インシデントが低優先度インシデントよりも迅速に処理されているか、また優先順位付けが一貫して適用されているかを理解するのに役立ちます。これは、プロセスパフォーマンスのフィルタリングと比較のための重要な要素です。
その重要性
SLA パフォーマンス分析や、最も重要なインシデントにリソースが適切に割り当てられているかを確認する上で不可欠です。
取得元
Jira課題の標準的な「優先度」フィールドです。
例
最高高中低
|
|||
|
担当グループ
AssignmentGroup
|
インシデントの処理を担当するチームまたはグループです。 | ||
|
説明
担当グループは、インシデントに割り当てられたチームを表します。これには、「L1ヘルプデスク」のようなサポート階層、「ネットワーク運用」のような専門チーム、または開発チームが含まれます。担当グループ間の遷移を分析することは、プロセスエスカレーションと引き継ぎを理解する上で重要です。これにより、チームのパフォーマンス測定、チームレベルのボトルネック特定、およびチーム間の依存関係の分析が可能になります。
その重要性
チームのパフォーマンス、スループット、および異なるサポートティアや専門グループ間の作業フローを分析するために不可欠です。
取得元
これは、多くの場合Jiraのカスタムフィールドとして実装されます(例:TeamやAssignment Group)。Jira ComponentsやProject Rolesから導き出される場合もあります。
例
Tier 1 サポートインフラストラクチャチームデータベース管理者
|
|||
|
解決サイクルタイム
IncidentResolutionCycleTime
|
インシデント作成から解決までの経過時間合計です。 | ||
|
説明
これは、CreatedDateからResolutionDateまでの期間を表す算出されたメトリックです。インシデント管理において最も重要なKPIの一つであり、プロセス全体の効率性を直接測定するものです。優先度、アサインメントグループ、コンポーネントなどの異なる次元でこのメトリックを分析することで、パフォーマンスに最も大きな影響を与える要因の特定に役立ちます。
その重要性
インシデント管理プロセスのエンドツーエンドの効率性を直接測定し、パフォーマンス追跡の主要なKPIとなります。
取得元
('ResolutionDate' - 'CreatedDate')として計算されます。
例
2h 30m1d 4h5d 1h 15m
|
|||
|
解決日
ResolutionDate
|
インシデントが解決済みとマークされた日時です。 | ||
|
説明
この属性は、インシデントが最初に解決済みのステータスに移行した際のタイムスタンプを捕捉します。これはアクティブな作業フェーズの終了を示し、解決までの時間を計算するための終点となります。解決日と作成日を比較することで、プロセス効率の主要な尺度が得られます。また、SLAコンプライアンスを決定する上での重要な要素でもあります。
その重要性
解決プロセスの終了を示し、総cycle timeとSLAパフォーマンスの計算を可能にします。
取得元
Jira課題の標準的な「解決済み」フィールドです。
例
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
|
|||
|
SLA違反
SlaBreach
|
インシデントの**解決時間**がSLA**目標**を超過したかどうかを示す**フラグ**。 | ||
|
説明
この算出されたブーリアン属性は、インシデントがそのTime to Resolution SLAに違反したかどうかを示します。IncidentResolutionCycleTimeがTimeToResolutionTargetよりも大きい場合にtrueとなります。このフラグにより、分析と可視化が簡素化され、全体的なSLA 違反率 KPIの計算を容易にします。これは、SLA パフォーマンス 監視ダッシュボードの主要な成果指標となります。
その重要性
SLAパフォーマンスに対して明確な二元的な結果を提供し、違反率の計算と問題領域の特定を容易にします。
取得元
('IncidentResolutionCycleTime' > 'TimeToResolutionTarget')として計算されます。
例
truefalse
|
|||
|
TimeToResolutionTarget
TimeToResolutionTarget
|
インシデント解決のためのSLA目標期間です。 | ||
|
説明
この属性は、特定の優先度やタイプのインシデントが解決されるまでの最大時間を定義します。SLAコンプライアンスを判断する際に、実際の解決時間と比較する基準となるベンチマークです。この値は通常、優先度、重大度、課題の種類などの要因を考慮したルールに基づき動的に設定されます。SLAパフォーマンス監視ダッシュボードにとって不可欠な要素です。
その重要性
SLAコンプライアンスを測定するためのベンチマークを提供し、インシデントSLA違反率KPIの基礎となります。
取得元
これは、Jira Service Management内のSLA 設定から導き出されます。特定の目標(例:Time to resolution)を特定する必要があります。
例
4h8h3d
|
|||
|
コンポーネント
Component
|
インシデントによって影響を受けるシステム、アプリケーション、またはインフラストラクチャの一部です。 | ||
|
説明
コンポーネントはJiraプロジェクトのサブセクションであり、課題を「User Interface」「Database」「API」などの小さな部分にグループ化するために使用されます。コンポーネントごとにインシデントを分析することで、システムのどの部分が最も問題を起こしやすいかを正確に特定できます。この情報は根本原因分析に有用であり、サービス改善や技術的負債の削減に向けた取り組みを導くことができます。
その重要性
影響を受けた特定の製品やシステム領域に基づき、フィルタリングや分析を行うことで、テクノロジーのホットスポットを特定するのに役立ちます。
取得元
Jira課題の標準的な「コンポーネント」フィールドです。
例
認証サービスレポーティングダッシュボードモバイルアプリ
|
|||
|
ハンドオフ数
HandoffCount
|
インシデントが異なるグループまたはユーザーに再割り当てされた回数です。 | ||
|
説明
この算出されたメトリックは、インシデントのライフサイクル中にAssigneeまたはAssignmentGroupフィールドが変更された回数をカウントします。引き継ぎの回数が多いと、プロセスの非効率性、初回解決の不足、または知識ギャップを示していることが多く、解決時間の長期化につながります。このKPIを分析することで、割り当てプロセスの合理化とチームコラボレーションの改善に役立ちます。
その重要性
再割り当てによって生じるプロセス上の摩擦や非効率性を定量化し、プロセス改善の機会特定を支援します。
取得元
課題の変更ログで、'Assignee'または'AssignmentGroup'フィールドの変更数を数えることで計算されます。
例
015
|
|||
|
報告者
Reporter
|
最初にインシデントを作成または報告したユーザーです。 | ||
|
説明
報告者は、通常エンドユーザーまたは別のシステムであり、最初にインシデントを記録した個人です。報告者別にインシデントを分析することで、頻繁に問題が発生するユーザーや部門を特定するのに役立ちます。また、「顧客からの返信待ち」や「顧客が返信済み」のようなアクティビティを分析する際に、コミュニケーションパターンを理解するためにも使用できます。
その重要性
インシデントの発生源を分析し、特定のユーザーや部門に関連するパターンを特定し、顧客とのやり取りにおける遅延を理解するのに役立ちます。
取得元
Jira課題の標準的な「報告者」フィールドです。
例
Alice JohnsonBob Williamsmonitoring-tool@example.com
|
|||
|
手戻り
IsRework
|
インシデントに手戻り(再オープンなど)が発生したかどうかを示す**フラグ**。 | ||
|
説明
この算出されたブーリアン属性は、プロセスの以前の段階に戻されたインシデント、特に解決された後に再オープンされたインシデントを識別します。手戻りループは、非効率性と顧客不満の重大な原因です。このフラグにより、手戻り率の定量化が容易になり、インシデントが最初に正しく解決されない原因の分析に焦点を当てるのに役立ちます`。
その重要性
繰り返し作業が必要なインシデントにフラグを立てることで、プロセス品質の問題や非効率性を浮き彫りにし、再作業分析を直接的に支援します。
取得元
イベントログ内の特定のステータス遷移のシーケンス(例:'Resolved' -> 'Reopened')を検出することで計算されます。
例
truefalse
|
|||
|
根本原因カテゴリ
RootCauseCategory
|
インシデントの根本原因の分類です。 | ||
|
説明
この属性は、「ソフトウェア欠陥」「ハードウェア障害」「ユーザーエラー」など、インシデントが発生した根本的な理由を捉えます。通常、調査後に設定され、効果的な問題管理と将来のインシデントの防止に不可欠です。根本原因カテゴリを分析することで、システム上の弱点を特定し、改善イニシアチブの優先順位付けを行うのに役立ちます。「不明」な根本原因の割合が高い場合、より良い調査プロセスの必要性を示唆する可能性があります。
その重要性
インシデントの根本原因を特定し、その発生源に対処することで、事後対応型から事前対応型のアプローチへの移行を支援し、根本原因分析を可能にします。
取得元
これは、Jiraではほとんどの場合カスタムフィールドです。その名前とオプションは、組織の特定の設定に大きく依存します。
例
設定エラーネットワーク障害ソフトウェアバグ
|
|||
|
解決
Resolution
|
インシデントを解決した最終的な結果または理由です。 | ||
|
説明
解決フィールドは、インシデントが解決済みの状態に移行した理由を説明します。一般的な解決策には、「修正済み」「重複」「対応しない」「再現不可」などがあります。解決タイプの分布を分析することで、受信レポートの品質と解決プロセスの有効性に関する洞察が得られます。例えば、「重複」解決の数が多い場合、インシデント作成またはトリアージ段階に問題がある可能性を示唆します。
その重要性
インシデントの結果にコンテキストを与え、解決策を分類し、インシデントがどのようにクローズされたかの傾向を特定するのに役立ちます。
取得元
Jira課題の標準的な「解決」フィールドです。このフィールドは通常、課題が「完了」ステータスカテゴリに移行されたときに設定されます。
例
完了修正済み重複修正しない
|
|||
|
課題タイプ
IssueType
|
インシデント、サービスリクエスト、問題などの課題タイプです。 | ||
|
説明
Jiraでは、さまざまな種類のタスクを区別するために課題タイプを使用します。インシデント管理のコンテキストでは、主要なタイプは「Incident」ですが、「Sub-task」のような他のタイプも関連する場合があります。この属性は、インシデントのみを含むようにデータセットをフィルタリングする上で非常に重要であり、それによってプロセスマイニング分析を正しいプロセスに集中させることができます。
その重要性
分析がインシデントに適切に限定され、サービスリクエストや変更といった他の作業タイプと明確に区別されるようになります。
取得元
Jira課題の標準的な「課題タイプ」フィールドです。
例
インシデントITヘルプバグ
|
|||
|
重大度
Severity
|
インシデントのビジネスへの影響度を示す指標です。 | ||
|
説明
重要度は、単一ユーザーへの影響から深刻なシステム停止まで、インシデントがビジネスに与える影響の大きさを定義します。優先度が作業の順序を決定するのに対し、重要度はビジネス全体への影響を示します。重要度別に分析することで、ビジネスにとって最も重要なインシデントのプロセスパフォーマンスを理解するのに役立ち、より詳細な分析のために優先度と組み合わせて使用されることがよくあります。
その重要性
ビジネスへの影響を可視化し、事業運営に最も損害を与えるインシデントに焦点を当てた分析を可能にします。
取得元
通常、Jiraのカスタムフィールドとして扱われます。標準システムフィールドではないため、Jira Service Managementのプロジェクト設定をご確認ください。
例
クリティカル重大軽微軽微
|
|||
|
関連課題ID
LinkedProblemId
|
このインシデントにリンクされている問題チケットの識別子です。 | ||
|
説明
より大きな根本的な問題の症状であるインシデントは、多くの場合、問題チケットにリンクされます。このフィールドには、関連する問題のIDが保存されます。これらのリンクを分析することは、インシデントと問題の関係を理解し、問題管理プロセスの有効性を測定し、恒久的な修正が必要な繰り返しのインシデントを特定するのに役立ちます。
その重要性
インシデントを根本的な問題に関連付けることで、組織が将来のインシデントを防ぐために根本原因にどれだけ効果的に対処しているかを分析できるようになります。
取得元
この情報は、Jira 課題のIssue Linksセクションに保存されます。
例
PROB-123PROB-456なし
|
|||
|
顧客リクエストタイプ
CustomerRequestType
|
顧客がサービスポータルを通じて提出した特定のリクエストタイプです。 | ||
|
説明
このフィールドは、Jira Service Management ポータルに表示される顧客の視点(例:システム問題の報告など)からリクエストを分類します。内部のIssue Typeとは異なり、インシデントのユーザーフレンドリーな分類を提供します。この属性を分析することで、顧客が問題をどのように認識し報告するかについての洞察を得て、ポータルのデザインとサービス提供の改善に役立てることができます。
その重要性
インシデントカテゴリを顧客中心の視点で提供し、需要分析や顧客体験の向上に役立ちます。
取得元
Jira Service Managementプロジェクトに固有の「顧客リクエストタイプ」フィールド。
例
IT ヘルプ > システムの問題を報告メール > アクセスリクエスト
|
|||
インシデント管理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
インシデントクローズ済み
|
インシデントチケットが解決・検証された後の、最終的な事務処理上のクローズを表します。「クローズ済み」へのステータス遷移から推測されます。 | ||
|
その重要性
これはプロセスの終端イベントです。ResolvedとClosedの間の時間を分析することで、管理上のクリーンアップやユーザー確認プロセスにおける遅延を明らかにすることができます。
取得元
課題のステータス変更履歴から推測されます。このイベントは、ステータスが最終的なクローズ済みの状態に移行したタイムスタンプに対応します。
取得
「クローズ済み」へのステータス遷移のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
インシデント作成済み
|
インシデントレポートが提出され、Jiraで新しい課題が作成されたときに、インシデントライフサイクルの公式な開始を示します。このイベントは、「Incident」タイプの新しい課題がシステムに記録されたときに明示的に捕捉されます。 | ||
|
その重要性
これは、プロセスの主要な開始イベントです。このアクティビティから解決までの時間を分析することは、全体的なサイクルタイムとSLA 順守を測定する上で不可欠です。
取得元
これは、Jiraのインシデント課題のcreated タイムスタンプから取得された明示的なイベントです。課題作成イベントは、課題の履歴に記録されます。
取得
課題作成タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
インシデント再割り当て済み
|
初回のアサイン後にインシデントが別々のエージェントまたはグループに転送されたときに発生します。このイベントは、「Assignee」または「Assigned Group」フィールドの変更から推測されます。 | ||
|
その重要性
再割り当ての追跡は、引き継ぎ分析にとって不可欠です。再割り当ての回数が多いと、プロセスの非効率性、知識ギャップ、または不正確な初期ルーティングを示していることが多く、解決の遅延を招くことになります`。
取得元
担当者フィールドが最初に設定された後のすべての更新を検出することで、課題履歴から推測されます。各変更が再割り当てイベントとなります。
取得
最初の割り当て後、「担当者」フィールドへの変更を特定します。
イベントタイプ
inferred
|
|||
|
インシデント解決済み
|
このアクティビティは、インシデントが正常に解決され、サービスが復旧したことの確認を示します。これは、「解決済み」ステータスへの移行と一致することが多いです。 | ||
|
その重要性
これはプロセスにおける主要な成功マイルストーンです。この時点までの期間は、Time to Resolution (TTR)を表す最も一般的なKPIです。
取得元
解決済みへのステータス変更から推測されます。多くのワークフローにおいて、これは解決策提案済みと同じイベントであり、主要な解決ポイントを表します。
取得
「解決済み」へのステータス遷移のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
解決策の提案
|
このアクティビティは、解決策が特定および実施され、インシデントが確認または最終検証を待っていることを示します。これは、「解決済み」へのステータス遷移から推測されます。 | ||
|
その重要性
これは、サポートチームによるアクティブな作業の終了を示す主要なマイルストーンとなります。多くの場合、SLAの計時を停止させるイベントです。
取得元
課題のステータス変更履歴から推測されます。このイベントのタイムスタンプは、ステータスが解決済みまたは同等の状態に移行したときです。
取得
「解決済み」へのステータス遷移のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
調査開始
|
担当エージェントがインシデントの診断作業を積極的に開始したことを示します。これは通常、インシデントのステータスがオープンまたは新規から進行中に移行したときに推測されます。 | ||
|
その重要性
この主要なマイルストーンは、積極的な解決努力の開始を意味します。このアクティビティまでの時間を測定することは、初期のキューイング遅延やリソース可用性問題を特定する上で役立ちます。
取得元
課題のステータス変更履歴から推測されます。このイベントのタイムスタンプは、ステータスが進行中などのアクティブな作業を示す状態に移行したときです。
取得
「進行中」へのステータス遷移のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
顧客からの返信待ち
|
サポートチームが顧客からの情報やアクションを待っている時点を示します。これは、「Waiting for customer」のような専用の待機ステータスへの移行から推測されます。 | ||
|
その重要性
この保留時間を切り分けることは、解決時間の計算から除外されることが多いため、正確なSLA測定にとって非常に重要です。顧客の応答遅延を分析するのに役立ちます。
取得元
課題のステータス変更履歴から推測されます。このイベントは、ステータスが顧客からの応答待ちまたは類似の状態に変化したタイムスタンプに対応します。
取得
「顧客待ち」へのステータス遷移のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
インシデント優先順位付け済み
|
インシデントの優先度や重要度(緊急度とビジネスへの影響を決定するもの)の設定を表します。これは通常、作成後に「優先度」または「重要度」フィールドが初めて入力または更新されたときに推測されます。 | ||
|
その重要性
優先順位付けの追跡は、インシデントが迅速かつ一貫して評価されているかを分析する上で役立ちます。このステップでの遅延は、SLA 計算やリソース割り当てに直接影響を与える可能性があります。
取得元
全てのフィールドの変更を追跡する課題履歴ログから推測されます。課題作成イベント後に優先度またはカスタム重大度フィールドへの最初の更新を探します。
取得
課題履歴内の'Priority'フィールドへの最初の変更を検出します。
イベントタイプ
inferred
|
|||
|
インシデント再オープン済み
|
以前に解決されたインシデントが、問題の再発や修正の無効性により再アクティブ化される状況を表します。「解決済み」または「クローズ済み」からオープンステータスへの変更によって推測されます。 | ||
|
その重要性
再オープンされたインシデントは、解決品質の直接的な尺度であり、手戻りの主要な指標です。これらのイベントを分析することで、時期尚早なクローズや効果のない解決策を特定できます。
取得元
課題のステータス変更履歴から推測されます。このイベントは、ステータスが解決済みやクローズ済みのような終端状態からオープンまたは進行中に戻ったときに記録されます。
取得
'Resolved'または'Closed'からオープンステータスへの変更を検出します。
イベントタイプ
inferred
|
|||
|
インシデント割り当て済み
|
このアクティビティは、インシデントが処理のためにサポートエージェントまたはグループに最初に割り当てられたことを示します。「担当者」または「割り当てグループ」フィールドが最初に設定されたことを追跡することで取得されます。 | ||
|
その重要性
初動対応とアサインメントの時間を測定します。これはSLAメトリクスの主要な要素であり、本格的な調査が始まる前の遅延を特定するのに役立ちます。
取得元
担当者フィールドの最初の変更で、以前の値が未割り当てであったものを特定することで、課題履歴から推測されます。
取得
課題履歴内の'Assignee'フィールドへの最初の更新を検出します。
イベントタイプ
inferred
|
|||
|
コメント追加
|
ユーザーがインシデントチケットにコメントを追加する、あらゆるコミュニケーションまたはメモのイベントを表します。これは、コメントが投稿されるたびに捕捉される明示的なイベントです。 | ||
|
その重要性
コメントの頻度を分析すると、コミュニケーションパターン、コラボレーションの効率性、そしてインシデントの複雑さについて洞察が得られます。これは、過剰なコミュニケーションを必要とするインシデントを特定するのに役立ちます。
取得元
これは明示的なイベントです。Jiraは、すべてのコメントをタイムスタンプと作成者とともに保存しており、課題のコメント履歴またはAPIを通じて利用可能です。
取得
課題に追加された各コメントのタイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
ワークアラウンド提示
|
恒久的な解決策の開発中にサービスを復旧させるための一時的な修正の実施を表します。これはステータス変更または特定のコメントから推測できます。 | ||
|
その重要性
回避策を提供するまでの時間を測定することは、サービス復旧速度の重要な指標です。一時的な緩和策と恒久的な解決策を区別するのに役立ちます。
取得元
これは多くの場合、推測される情報です。Workaround Provided ステータスへの移行や、workaroundなどの特定のキーワードを含む公開コメントの追加によって推測される場合があります。
取得
特定のステータス遷移、またはコメント内のキーワードを特定します。
イベントタイプ
inferred
|
|||
|
専門チームにエスカレーション済み
|
インシデントが高度なサポートのために専門チーム(例:Tier 2、開発チーム)にエスカレートされたことを示します。これはカスタム「サポートチーム」フィールドの変更、または特定の再割り当てから推測されます。 | ||
|
その重要性
専門知識を必要とするインシデントを強調し、異なるサポートレベル間の流れを追跡します。これにより、専門チーム内のボトルネックを特定し、エスカレーションパターンを分析するのに役立ちます。
取得元
割り当てられたチームを表すカスタムフィールドへの変更を追跡するか、既知の専門家グループのメンバーへの担当者の変更を特定することで、課題履歴から推測されます。
取得
'Assigned Team'用のカスタムフィールドの変更、または特定の担当者の変更を検出します。
イベントタイプ
inferred
|
|||
|
課題チケットにリンク済み
|
根本原因分析のためにインシデントが「問題」課題にリンクされたときに発生します。これは、「relates to」または「caused by」リンクが問題課題タイプに作成されたときに明示的に捕捉されるイベントです。 | ||
|
その重要性
このリンクを追跡することは、組織がインシデント緩和から根本原因分析および予防へとどのように効果的に移行するかを理解する上で不可欠です。
取得元
これは、課題のリンク履歴に記録された明示的なイベントです。各リンクの作成にはタイムスタンプがあり、Problem 課題タイプへのリンクでフィルタリングが可能です。
取得
「Problem」課題タイプへの課題リンク作成タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
顧客が応答
|
顧客が要求された情報を提供し、インシデントが先に進めることを示します。これは、ステータスが顧客からの応答待ちからアクティブなステータスに戻ったときに推測されます。 | ||
|
その重要性
このアクティビティは、顧客が原因の遅延の終了を示します。「顧客からの返信待ち」とこのイベント間の期間を分析することで、平均顧客応答時間が明らかになります。
取得元
課題のステータス変更履歴から推測されます。このイベントは、ステータスが顧客からの応答待ちから進行中のようなステータスに移行したときに発生し、多くの場合、顧客がコメントを追加することによってトリガーされます。
取得
'Waiting for customer'から'In Progress'へのステータス変更を検出します。
イベントタイプ
inferred
|
|||