問題管理データテンプレート
Problem Management問題管理データテンプレート
- 根本原因分析に推奨される属性
- 主要なプロセスの節目とアクティビティ
- ServiceNow抽出のステップバイステップガイド
問題管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
Activity
|
課題レコードに対して実行された特定のイベントまたはアクション。 | ||
|
説明
課題レコードのライフサイクル中に発生する個別のステップやステータス変更を表します。例としては、「課題レコード作成済み」、「根本原因特定済み」、「サポートグループにアサイン済み」などがあります。この属性は、プロセスマップを構築し、イベントのシーケンスを視覚化するために不可欠です。
その重要性
プロセスマップ内のノードを定義し、ワークフローとプロセスバリアントの可視化を可能にします。
取得元
例
課題レコード作成済み分析完了状態が「クローズ済み」に変更されました
|
|||
|
イベントのタイムスタンプ
EventTime
|
活動が発生した正確な日付と時刻。 | ||
|
説明
システムで変更またはアクションがログに記録された特定のタイムスタンプを記録します。このデータポイントは、活動を時系列に並べ、サイクルタイムやプロセスステップ間のリードタイムなどの期間メトリクスを計算する上で不可欠です。
その重要性
イベントの順序付けと全ての時間ベースのKPI計算に不可欠です。
取得元
監査/履歴テーブルのServiceNow「sys_created_on」フィールド
例
2023-10-12T08:30:00Z2023-10-12T14:45:12Z
|
|||
|
課題レコード
ProblemNumber
|
課題レコードの一意の識別子。 | ||
|
説明
ServiceNow内で特定の課題レコードに割り当てられる一意の英数字キー(例:PRB000123)。この識別子は、初期ログ記録から根本原因分析、最終クローズまでのすべてのプロセス活動を結びつける中心的なスレッドとして機能します。プロセスマイニング分析では、この属性がケースIDとして機能し、問題解決のエンドツーエンドの経路を再構築することを可能にします。
その重要性
プロセスグラフ内でユニークなケースを区別し、関連するイベントをグループ化するための主キーです。
取得元
ServiceNowの「problem」テーブル、「number」フィールド
例
PRB004512PRB009823PRB001122
|
|||
|
ソースシステム
SourceSystem
|
`データ`の`発信元``システム`名です。 | ||
|
説明
課題管理データが抽出された特定のServiceNowインスタンスまたは環境を識別します。これは、複数システム環境でデータの系統を追跡し、分析におけるシステム固有のニュアンスを処理するのに特に役立ちます。
その重要性
特に複数のITSMツールからのデータを統合する際に、データソースのコンテキストを提供します。
取得元
抽出時にハードコードされます(例: 「ServiceNow本番環境」)。
例
ServiceNow 本番ServiceNow EMEA
|
|||
|
最終データ更新
LastDataUpdate
|
データが抽出または最終更新されたときのタイムスタンプ。 | ||
|
説明
分析に使用されたデータセットの鮮度を示します。アナリストがリアルタイムデータを見ているのか、それとも過去のスナップショットを見ているのかを理解するのに役立ち、未解決ケースのステータスを正しく解釈するために重要です。
その重要性
ユーザーが正確な運用レポートのためにデータの鮮度を把握できるようにします。
取得元
ETL実行時のシステム時間
例
2023-11-01T12:00:00Z
|
|||
|
`サポートグループ`
AssignmentGroup
|
問題解決を担当する技術チーム。 | ||
|
説明
現在課題に割り当てられている特定のサポートグループまたはチームを指定します。この属性は、「サポートグループ再アサインメント分析」ダッシュボードにとって重要であり、チーム間の引き継ぎを追跡し、組織のサイロを特定するのに役立ちます。
その重要性
部門間のボトルネックを特定し、引き継ぎの効率を分析するために非常に重要です。
取得元
ServiceNowの「problem」テーブル、「assignment_group」フィールド
例
ネットワーク運用データベース管理者サービスデスク
|
|||
|
優先度
Priority
|
課題レコードに割り当てられた優先度レベル。 | ||
|
説明
課題の重要度と緊急度を示し、通常は影響度と緊急度から計算されます。この属性により、重要度別に分析をセグメント化でき、「SLA違反と優先度監視」ダッシュボードをサポートします。
その重要性
ビジネスの重要度に基づいてプロセスパフォーマンスをセグメント化できます。
取得元
ServiceNowの「problem」テーブル、「priority」フィールド
例
1 - Critical2 - High3 - Moderate
|
|||
|
再割り当て回数
ReassignmentCount
|
問題がグループ間で再アサインされた回数。 | ||
|
説明
アサインメントグループがどれくらいの頻度で変更されたかを追跡するカウンターです。これは「課題レコード再アサインメント回数」KPIの直接的な情報源であり、チケットがチーム間で行き来する「ピンポン」効果を特定するのに役立ちます。
その重要性
プロセスの摩擦と明確なオーナーシップの欠如を直接示す指標。
取得元
ServiceNowの「problem」テーブル、「reassignment_count」フィールド
例
0312
|
|||
|
問題の状態
ProblemState
|
課題レコードのライフサイクルステータス。 | ||
|
説明
課題レコードの現在の段階(例: オープン、根本原因分析中、修正進行中、クローズ済みなど)を反映します。これは、「古い課題レコードの熟成分析」におけるバックログの構成をフィルタリングし、理解するための主要なドライバーです。
その重要性
オープンケースとクローズドケースをフィルタリングするために使用される主要なステータスインジケータ。
取得元
ServiceNowの「problem」テーブル、「state」フィールド
例
新規評価根本原因分析解決済み
|
|||
|
担当ユーザー
AssignedTo
|
課題の作業を担当する特定の担当者。 | ||
|
説明
現在、課題レコードの責任者であるユーザーを識別します。この属性を分析することは、ワークロードの配分、個々のパフォーマンス、およびリソースレベルでの潜在的なボトルネックを理解するのに役立ちます。
その重要性
リソース効率と個々のワークロードを分析するための鍵。
取得元
ServiceNowの「problem」テーブル、「assigned_to」フィールド
例
Alice Smithボブ・ジョーンズシステム管理者
|
|||
|
根本原因カテゴリ
RootCauseCategory
|
特定された根本原因の分類。 | ||
|
説明
ソフトウェアバグ、人的エラー、ハードウェア障害など、課題の根本原因を分類します。この属性は「根本原因分類精度」ダッシュボードを強化し、体系的な障害パターンを特定するのに役立ちます。
その重要性
障害パターン分析を可能にし、戦略的な改善を推進します。
取得元
ServiceNowの「problem」テーブル、「rca_category」フィールドまたは「u_root_cause_category」フィールド
例
ソフトウェアの欠陥設定エラーベンダー課題
|
|||
|
関連インシデント数
RelatedIncidentCount
|
この課題レコードにリンクされているインシデントの数。 | ||
|
説明
問題に関連するインシデントの数を数えることで、その問題の影響を定量化します。このフィールドの高いカウントは、特に既知のエラーの場合、「既知のエラーとインシデント再発」ダッシュボードに反映されます。
その重要性
問題が引き起こすユーザーへの影響の大きさを測定します。
取得元
ServiceNowの「problem」テーブル、「related_incidents」フィールド(フィールド名は様々)またはリンクされたレコードのカウント
例
1501200
|
|||
|
`SLA`期日
SlaDueDate
|
SLAに基づく問題解決の目標日時。 | ||
|
説明
サービスレベル契約を満たすために問題が解決されるべき時刻を示すタイムスタンプ。これは「SLA違反と優先度監視」ダッシュボードのベースラインであり、コンプライアンス率を計算するために使用されます。
その重要性
SLA違反ステータスを計算するための基準。
取得元
問題にリンクされたServiceNowの「task_sla」テーブル
例
2023-12-31T17:00:00Z
|
|||
|
PIR結果
PostImplementationReviewResult
|
導入後レビューの結果または完了ステータス。 | ||
|
説明
PIRの結果またはステータス(例:完了、不要、保留中)を保存します。この属性は、「導入後レビューコンプライアンス」ダッシュボードで主要な問題が確実にレビューされるために必要です。
その重要性
重大なインシデントから確実に学習するための品質管理指標。
取得元
ServiceNowの「problem」テーブル、「pir_state」フィールドまたは類似のカスタムフィールド
例
完了済み免除済み保留中
|
|||
|
RCA期間
RootCauseAnalysisDuration
|
問題の作成から根本原因の特定までにかかった時間。 | ||
|
説明
調査フェーズの効率を測定する計算された期間です。これは「平均根本原因特定時間」KPIを直接サポートし、技術的なスキルギャップや複雑性の問題を特定するのに役立ちます。
その重要性
調査フェーズの主要な効率指標。
取得元
計算値: 「根本原因特定」アクティビティのタイムスタンプから「課題レコード作成」時間を引いたもの
例
3日4時間12時間
|
|||
|
保留期間
PendingDuration
|
問題が中断または保留状態で費やした合計時間。 | ||
|
説明
「ベンダー保留中」や「保留中」などのステータスで費やされた時間を集計します。この指標は、「保留ステートと待機時間分析」に使用され、内部処理時間と外部遅延を区別します。
その重要性
チームの非効率性と外部依存関係を区別します。
取得元
計算値: ステートが「保留中/一時停止中」である期間の合計
例
5 days0分
|
|||
|
回避策公開済み
WorkaroundPublished
|
ワークアラウンドが文書化され、共有されているかどうかを示します。 | ||
|
説明
一時的な修正策が特定され、ナレッジベースまたは既知のエラーデータベースに公開されたかどうかを示すブール値またはステータスフラグです。「ワークアラウンド公開パフォーマンス」ダッシュボードをサポートします。
その重要性
最終的な修正が行われる前に、ビジネスへの影響がどれだけ迅速に軽減されるかを測定するために重要です。
取得元
ServiceNowの「problem」テーブル、「work_around」フィールド(テキストの存在)または特定のステータス
例
truefalse
|
|||
|
変更要求番号
ChangeRequestNumber
|
問題を修正するために開始された変更要求の識別子。 | ||
|
説明
課題レコードと変更管理レコード(RFC)をリンクさせます。この接続は、「変更要求移行効率」ダッシュボードにとって不可欠であり、課題診断とインフラ変更実行間の引き継ぎ速度を測定するために使用されます。
その重要性
問題管理から変更管理への移行を追跡します。
取得元
ServiceNowの「problem」テーブル、「rfc」フィールド
例
CHG003001CHG004552
|
|||
|
既知のエラーである
IsKnownError
|
課題が既知のエラーとして分類されているかどうかを示すフラグ。 | ||
|
説明
課題レコードが既知のエラーに変換されたか、または既知のエラーとしてマークされたかを識別します。これは、「既知のエラーとインシデント再発」分析において、ナレッジ管理プロセスが効果的であるかを確認するために不可欠です。
その重要性
アクティブな調査と、ワークアラウンドで受け入れられた欠陥を区別します。
取得元
ServiceNowの「problem」テーブル、「known_error」フィールド
例
truefalse
|
|||
|
業務サービス
BusinessService
|
問題によって影響を受ける上位のビジネスサービス。 | ||
|
説明
技術的なコンポーネントではなく、ビジネスに直面するサービス(例:「給与計算サービス」、「顧客ポータル」)を表します。これにより、ステークホルダーへの報告においてビジネス中心の視点を提供します。
その重要性
技術的な問題をビジネスのバリューストリームに接続します。
取得元
ServiceNowの「problem」テーブル、「business_service」フィールド
例
オンラインバンキング内部メール
|
|||
|
構成アイテム
ConfigurationItem
|
問題の影響を受ける特定の資産またはサービス。 | ||
|
説明
課題レコードにリンクされている構成アイテム(CI)を識別します。これを分析することで、問題を特定のハードウェア、ソフトウェア、またはサービスと関連付けるのに役立ち、「根本原因分類精度」ダッシュボードをサポートします。
その重要性
プロセスの問題を特定の物理的または論理的な資産にリンクさせます。
取得元
ServiceNowの「problem」テーブル、「cmdb_ci」フィールド
例
SAP ERPサーバー01ExchangeメールサービスOracle DB 本番
|
|||
|
解決策草案作成時間
SolutionDraftingTime
|
根本原因の特定と解決策の提案にかかる時間。 | ||
|
説明
原因判明後に修正が開発される設計フェーズの期間を追跡します。これは「解決策草案作成と修正適用」ダッシュボードをサポートします。
その重要性
「修正設計」フェーズのパフォーマンスを分離します。
取得元
計算値: 「提案された解決策ドラフト作成」のタイムスタンプから「根本原因特定」のタイムスタンプを引いたもの
例
2日4時間
|
|||
問題管理活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
サポートグループに割り当て済み
|
調査のために課題レコードを特定の技術チームにルーティングすること。この活動は所有権の流れを追跡し、引き継ぎを分析するために不可欠です。 | ||
|
その重要性
サポートグループ再アサインメント分析ダッシュボードにとって不可欠であり、チーム間のピンポン効果やボトルネックを特定するのに役立ちます。
取得元
ServiceNowの「sys_audit」または「sys_history_line」テーブルで「assignment_group」フィールドの変更を追跡。
取得
ステータスフィールドを前後で比較
イベントタイプ
inferred
|
|||
|
回避策特定済み
|
課題レコードの「回避策」フィールドにテキストを入力する行為。これは、アナリストによって一時的な解決策が文書化された瞬間を捉えます。 | ||
|
その重要性
技術的な解決策が最初に判明した時期を特定することで、回避策公開パフォーマンスダッシュボードをサポートします。
取得元
ServiceNowの「sys_audit」テーブルで「fieldname」が「workaround」の場合。
取得
ステータスフィールドを前後で比較
イベントタイプ
inferred
|
|||
|
変更要求開始済み
|
変更要求(RFC)と課題レコードの関連付け。これは、問題管理から変更管理への実装のための引き継ぎを示します。 | ||
|
その重要性
変更要求移行効率ダッシュボードにとって不可欠です。修正の発見から変更プロセスの開始までの遅延を特定します。
取得元
ServiceNowの「sys_audit」テーブルで、「problem」テーブルの「rfc」参照フィールドへのデータ入力状況を追跡。
取得
通常変更作成のトランザクションが実行された際に記録されます。
イベントタイプ
explicit
|
|||
|
恒久的な修正適用済み
|
問題が解決済みとしてマークされる瞬間。多くの場合、関連する変更要求のクローズによってトリガーされます。これは技術的な作業が完了したことを示します。 | ||
|
その重要性
アクティブな修正サイクルの終了を決定します。SLAに対する総解決時間を計算するために使用されます。
取得元
ServiceNowの「sys_audit」テーブル、「state」フィールドが「Resolved」に遷移(通常値106)。
取得
ステータスフィールドを前後で比較
イベントタイプ
inferred
|
|||
|
根本原因特定済み
|
「根本原因」コードが入力されるか、状態が「修正進行中」に移行する時点。これは問題の診断が成功したことを表します。 | ||
|
その重要性
平均根本原因特定時間を計算し、根本原因調査サイクル時間ダッシュボードをサポートします。これは主要なプロセスの節目です。
取得元
ServiceNowの「sys_audit」テーブルで、「root_cause」カテゴリフィールドの変更、または「Fix in Progress」状態への遷移を追跡。
取得
ステータスフィールドを前後で比較
イベントタイプ
inferred
|
|||
|
課題レコードクローズ済み
|
レコードが非アクティブになる最終的なライフサイクルイベント。これ以上の作業は想定されていません。 | ||
|
その重要性
プロセスインスタンスの最終的な終点。総サイクル時間の計算に必要です。
取得元
ServiceNowの「problem」テーブル、「closed_at」フィールドまたは「state」が「Closed」に遷移。
取得
課題クローズのトランザクションが実行された際に記録されます。
イベントタイプ
explicit
|
|||
|
課題レコード作成済み
|
ServiceNowシステムにおける課題レコードの最初の作成。これは問題管理ライフサイクルの始まりを示し、熟成メトリクスのベースラインとなるタイムスタンプを設定します。 | ||
|
その重要性
全てのサイクル時間計算とSLA測定の開始時間を確立します。これは、流入する課題調査の量を特定するための主要な基準となります。
取得元
ServiceNowの「problem」テーブル、「sys_created_on」フィールド。
取得
新規レコード作成のトランザクションが実行された際に記録されます。
イベントタイプ
explicit
|
|||
|
調査開始
|
課題レコードの状態が「新規」から「評価」または「根本原因分析」に遷移すること。これは、アナリストが問題に対して積極的に作業を開始したことを示します。 | ||
|
その重要性
初期キュー待機時間の終了と、アクティブな調査フェーズの開始を示し、保留ステート分析をサポートします。
取得元
ServiceNowの「sys_audit」テーブルで、「state」フィールドの変更(例:設定に応じて値が102または103に移動)を追跡。
取得
ステータスフィールドを前後で比較
イベントタイプ
inferred
|
|||
|
回避策公開済み
|
関連するインシデントに回避策をプッシュしたり、既知のエラー記事を作成したりする「回避策の連絡」アクションの実行。これは単に回避策を入力することとは異なります。 | ||
|
その重要性
知識共有の速度を測定するために不可欠です。ここでの遅延は、再発インシデントの数に直接影響します。
取得元
ServiceNowの「sys_journal_field」または特定のUIアクションログ。タイプ「Known Error」の「kb_knowledge」レコードが作成された場合にも推測できます。
取得
ワークアラウンド連絡のトランザクションが実行された際に記録されます。
イベントタイプ
explicit
|
|||
|
導入後レビュー完了
|
PIRタスクの完了またはPIRフラグの設定。これにより、主要な問題に対して事後分析が実行されたことが確認されます。 | ||
|
その重要性
導入後レビューコンプライアンスダッシュボードを直接サポートします。優先度の高い課題でこのアクティビティが欠落している場合、コンプライアンス違反を示します。
取得元
ServiceNowの「problem_task」テーブル(タイプ=PIR)のクローズ、または「problem」テーブルの「pir_state」フィールドの変更。
取得
項目XとYを比較して派生
イベントタイプ
inferred
|
|||
|
提案された解決策が作成された
|
「修正ノート」または「解決コード」フィールドへのデータ入力。アナリストが原因の理解から恒久的な修正の設計へと移行したことを示します。 | ||
|
その重要性
設計フェーズの期間を分離することで、解決策草案作成と修正適用ダッシュボードをサポートします。
取得元
ServiceNowの「sys_audit」テーブルで「fix_notes」フィールドの更新を追跡。
取得
ステータスフィールドを前後で比較
イベントタイプ
inferred
|
|||
|
状態が「修正進行中」に変更されました
|
レコードは、修正が構築または展開中であることを示す状態に遷移します(多くの場合、変更管理を待機中)。 | ||
|
その重要性
アクティブな調査時間と「変更待ち」時間を区別し、ボトルネック分析を洗練させます。
取得元
ServiceNowの「sys_audit」テーブル、「state」フィールドが「Fix in Progress」に遷移(通常値104)。
取得
ステータスフィールドを前後で比較
イベントタイプ
inferred
|
|||
|
解決検証済み
|
解決策が効果的であることを確認する検証ステップです。これは、プロセスの成熟度に応じて、特定のステートまたはチェックボックスとして表現される場合があります。 | ||
|
その重要性
クローズ前の品質管理を確実にします。このステップをバイパスすると、プロセス逸脱分析が可能になります。
取得元
ServiceNowの「sys_audit」テーブル。状態変更(解決済み→クローズ済み)または、設定されている場合は特定のフィールド「u_resolution_verified」である可能性があります。
取得
ステータスフィールドを前後で比較
イベントタイプ
inferred
|
|||
|
評価却下
|
問題レコードが有効な問題ではなかったため、評価フェーズ中に以前の状態に戻されるか、キャンセルされました。 | ||
|
その重要性
インシデントが誤って課題に昇格されるプロセスにおける無駄を特定します。
取得元
ServiceNowの「sys_audit」テーブル、「state」フィールドが「Assess」から「Closed/Cancelled」または「New」に遷移。
取得
ステータスフィールドを前後で比較
イベントタイプ
inferred
|
|||