Problem Managementのデータテンプレート
Problem Managementのデータテンプレート
- 根本原因分析に推奨される属性
- 主要なプロセスの節目とアクティビティ
- ServiceNowからのデータ抽出手順
問題管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
Activity
|
問題レコード上で実行された特定のイベントまたはアクションです。 | ||
|
説明
問題レコードのライフサイクル中に発生する個別のステップまたはステータス変更を表します。例として、「問題レコードの作成」、「根本原因の特定」、「サポートグループへの割り当て」などがあります。この属性は、プロセスマップの作成とイベントの順序の可視化に欠かせません。
重要な理由
プロセスマップのノードを定義し、ワークフローとプロセスバリアントを可視化します。
入手先
「sys_audit」テーブル、「sys_history_line」テーブル、または「problem」テーブルの状態変更から取得されます
例
問題レコードを作成分析完了状態をクローズに変更
|
|||
|
イベントのタイムスタンプ
EventTime
|
アクティビティが発生した正確な日時です。 | ||
|
説明
変更またはアクションがシステムに記録された具体的なタイムスタンプを記録します。このデータは、アクティビティを時系列に並べ、プロセスステップ間のサイクルタイムやリードタイムなどの所要時間指標を計算するための基礎となります。
重要な理由
イベントの順序付けと、時間に基づくすべてのKPIの計算に必要です。
入手先
監査・履歴テーブルのServiceNow「sys_created_on」フィールド
例
2023-10-12T08:30:00Z2023-10-12T14:45:12Z
|
|||
|
問題レコード
ProblemNumber
|
問題レコードを一意に識別するIDです。 | ||
|
説明
ServiceNow内の特定の問題レコードに割り当てられた一意の英数字キーです(例:PRB000123)。この識別子は、最初の記録から根本原因分析、最終的なクローズまで、すべてのプロセスアクティビティをつなぐ中心的なキーです。プロセスマイニング分析ではCase IDとして機能し、問題解決のエンドツーエンドの経路を再構成できます。
重要な理由
一意のケースを区別し、プロセスグラフ内で関連するイベントをグループ化するための主キーです。
入手先
ServiceNowの「problem」テーブル、「number」フィールド
例
PRB004512PRB009823PRB001122
|
|||
|
ソースシステム
SourceSystem
|
データの取得元となったシステムの名称です。 | ||
|
説明
問題管理データを抽出した特定のServiceNowインスタンスまたは環境を識別します。複数システムの環境では、データの系譜を追跡し、分析時のシステム固有の差異に対応するうえで特に役立ちます。
重要な理由
複数のITSMツールからデータを統合する際に、データの出所を把握するための文脈を提供します。
入手先
抽出時に固定値として設定されます(例:「ServiceNow Production」)
例
ServiceNow本番環境ServiceNow EMEA
|
|||
|
最終データ更新日時
LastDataUpdate
|
データを抽出した時点、または最後に更新した時点のタイムスタンプです。 | ||
|
説明
分析に使用するデータセットがどの時点のものかを示します。リアルタイムデータを見ているのか、過去時点のスナップショットを見ているのかを分析担当者が把握できるため、未完了ケースのステータスを正しく解釈するうえで重要です。
重要な理由
正確な業務レポート作成に必要なデータの鮮度を利用者が把握できるようにします。
入手先
ETL実行時点のシステム時刻
例
2023-11-01T12:00:00Z
|
|||
|
サポートグループ
AssignmentGroup
|
問題の解決を担当する技術チームです。 | ||
|
説明
現在、問題に割り当てられている特定のサポートグループまたはチームを示します。この属性は、「サポートグループ再割り当て分析」ダッシュボードでチーム間の引き継ぎを追跡し、組織間のサイロを特定するために欠かせません。
重要な理由
部門間のボトルネックを特定し、引き継ぎの効率を分析するために重要です。
入手先
ServiceNow「problem」テーブルの「assignment_group」フィールド
例
ネットワーク運用データベース管理者サービスデスク
|
|||
|
優先度
Priority
|
問題レコードに設定された優先度です。 | ||
|
説明
通常は影響度と緊急度から算出される、問題の重要度と緊急性を示します。この属性により、重要度別に分析を分けられ、「SLA違反と優先度のモニタリング」ダッシュボードを支援できます。
重要な理由
業務上の重要度別にプロセスパフォーマンスを分けて分析できます。
入手先
ServiceNow「problem」テーブルの「priority」フィールド
例
1 - 重大2 - 高3 - 中程度
|
|||
|
再割り当て回数
ReassignmentCount
|
問題がグループ間で再割り当てされた回数です。 | ||
|
説明
割り当て先グループが変更された頻度を追跡するカウンターです。「問題レコード再割り当て回数」KPIの直接のデータソースとなり、チケットがチーム間を行き来する「ピンポン」状態の特定に役立ちます。
重要な理由
プロセス上の摩擦と、責任の所在が明確でない状態を直接示す指標です。
入手先
ServiceNow「problem」テーブルの「reassignment_count」フィールド
例
0312
|
|||
|
問題の状態
ProblemState
|
問題レコードのライフサイクル上のステータスです。 | ||
|
説明
「オープン」、「根本原因分析」、「修正対応中」、「クローズ」など、問題レコードの現在の段階を示します。「長期滞留問題レコードの経過分析」では、バックログの構成をフィルタリングして把握するための主要な項目です。
重要な理由
オープンケースとクローズ済みケースをフィルタリングするための主要なステータス指標です。
入手先
ServiceNow「problem」テーブルの「state」フィールド
例
新規評価根本原因分析解決済み
|
|||
|
担当ユーザー
AssignedTo
|
問題への対応を担当する特定の個人です。 | ||
|
説明
現在、問題レコードの対応責任を負うユーザーを識別します。この属性を分析すると、作業負荷の分布、個人のパフォーマンス、リソースレベルで発生する可能性のあるボトルネックを把握できます。
重要な理由
リソースの効率と個人の作業負荷を分析するための重要な項目です。
入手先
ServiceNow「problem」テーブルの「assigned_to」フィールド
例
Alice SmithBob Jonesシステム管理者
|
|||
|
根本原因カテゴリ
RootCauseCategory
|
特定された根本原因の分類です。 | ||
|
説明
ソフトウェアのバグ、人的ミス、ハードウェア障害など、問題の根本的な原因を分類します。この属性は「根本原因分類の正確性」ダッシュボードの基盤となり、組織的な障害パターンの特定に役立ちます。
重要な理由
障害パターンを分析し、戦略的な改善につなげられます。
入手先
ServiceNow「problem」テーブルの「rca_category」または「u_root_cause_category」フィールド
例
ソフトウェア欠陥設定エラーベンダーの問題
|
|||
|
関連インシデント数
RelatedIncidentCount
|
この問題レコードに関連付けられたインシデントの数です。 | ||
|
説明
関連するインシデントの数を数え、問題の影響度を定量化します。特に既知のエラーでこの値が大きい場合、「既知のエラーとインシデント再発」ダッシュボードに反映されます。
重要な理由
問題によって生じたユーザー影響の規模を測定します。
入手先
ServiceNow「problem」テーブルの「related_incidents」フィールド(フィールド名は異なる場合があります)または関連レコード数
例
1501200
|
|||
|
PIR結果
PostImplementationReviewResult
|
実装後レビューの結果または完了ステータスです。 | ||
|
説明
PIRの結果またはステータスを保存します(例:「完了」、「不要」、「保留中」)。主要な問題がレビューされていることを確認する「実装後レビューのコンプライアンス」ダッシュボードに必要な属性です。
重要な理由
重大なインシデントから学びを得ているかを確認する品質管理指標です。
入手先
ServiceNow「problem」テーブルの「pir_state」フィールドまたは同様のカスタムフィールド
例
完了免除保留中
|
|||
|
SLA期限
SlaDueDate
|
SLAに基づく問題解決の目標日時です。 | ||
|
説明
サービスレベル合意を満たすために問題を解決しなければならない日時を示すタイムスタンプです。「SLA違反と優先度のモニタリング」ダッシュボードの基準となり、コンプライアンス率の計算にも使われます。
重要な理由
SLA違反ステータスを計算するための基準です。
入手先
問題に関連付けられたServiceNow「task_sla」テーブル
例
2023-12-31T17:00:00Z
|
|||
|
保留時間
PendingDuration
|
問題が停止中または保留中の状態にあった合計時間です。 | ||
|
説明
「ベンダー待ち」や「保留中」などのステータスに費やした時間を集計します。「保留状態と待機時間の分析」で、社内処理時間と外部要因による遅延を分けるために使われます。
重要な理由
チームの非効率と外部依存関係を区別します。
入手先
計算式:StateがPendingまたはOn Holdである期間の所要時間の合計
例
5日0分
|
|||
|
回避策を公開
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時間
|
|||
問題管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
サポートグループに割り当て
|
問題レコードを調査担当の特定の技術チームへ振り分けることです。このアクティビティは担当の移動を追跡し、引き継ぎを分析するうえで重要です。 | ||
|
重要な理由
Support Group Reassignment Analysisダッシュボードで、チーム間のたらい回しやボトルネックを特定するために必要です。
入手先
「assignment_group」フィールドの変更を記録するServiceNowの「sys_audit」または「sys_history_line」テーブル
取得
状態フィールドの変更前と変更後を比較
イベントタイプ
inferred
|
|||
|
問題レコードをクローズ
|
レコードが非アクティブになるライフサイクル上の最終イベントです。以降の作業は想定されません。 | ||
|
重要な理由
プロセスインスタンスの確定した終了点です。総サイクルタイムの算出に必要です。
入手先
ServiceNowの「problem」テーブルの「closed_at」フィールド、または「Closed」状態への遷移
取得
トランザクションClose Problemの実行時に記録
イベントタイプ
explicit
|
|||
|
問題レコードを作成
|
ServiceNowシステムで問題レコードを最初に作成することです。問題管理ライフサイクルの開始点となり、経過時間の指標に使用する基準タイムスタンプを設定します。 | ||
|
重要な理由
すべてのサイクルタイム計算とSLA測定の開始時刻を設定します。受け付けた問題調査の件数を特定するための主要な基準点です。
入手先
ServiceNowの「problem」テーブル、「sys_created_on」フィールド
取得
トランザクションNew Recordの実行時に記録
イベントタイプ
explicit
|
|||
|
回避策を特定
|
問題レコードの「Workaround」フィールドにテキストを入力することです。アナリストが暫定対応を文書化した時点を記録します。 | ||
|
重要な理由
技術的な解決策が初めて判明した時点を設定し、Workaround Publication Performanceダッシュボードを支援します。
入手先
「fieldname」が「workaround」であるServiceNowの「sys_audit」テーブル
取得
状態フィールドの変更前と変更後を比較
イベントタイプ
inferred
|
|||
|
変更リクエストを開始
|
Change Request(RFC)をProblem Recordに関連付けることです。Problem ManagementからChange Managementへ実装を引き継いだことを示します。 | ||
|
重要な理由
Change Request Transition Efficiencyダッシュボードに必要です。修正の発見から変更プロセスの開始までに生じた遅延を特定します。
入手先
「problem」テーブルの「rfc」参照フィールドへの入力を記録するServiceNowの「sys_audit」テーブル
取得
トランザクションCreate Normal Changeの実行時に記録
イベントタイプ
explicit
|
|||
|
恒久対応を適用
|
問題がResolvedとしてマークされた時点です。関連するChange Requestのクローズを契機とすることが多く、技術的な作業が完了したことを示します。 | ||
|
重要な理由
アクティブな修正サイクルの終了点を決定します。SLAに対する総解決時間の算出に使用します。
入手先
ServiceNowの「sys_audit」テーブルで、「state」フィールドが「Resolved」へ遷移(通常は値106)
取得
状態フィールドの変更前と変更後を比較
イベントタイプ
inferred
|
|||
|
根本原因を特定
|
「Root Cause」コードが入力されるか、状態が「Fix in Progress」へ移行した時点です。問題の診断に成功したことを示します。 | ||
|
重要な理由
Mean Time to Root Causeを算出し、Root Cause Investigation Cycle Timeダッシュボードを支援します。プロセス上の重要な節目です。
入手先
「root_cause」カテゴリー・フィールドの変更、または「Fix in Progress」状態への遷移を記録するServiceNowの「sys_audit」テーブル
取得
状態フィールドの変更前と変更後を比較
イベントタイプ
inferred
|
|||
|
調査を開始
|
問題レコードの状態が「New」から「Assess」または「Root Cause Analysis」へ遷移することです。アナリストが問題への対応を実際に開始したことを示します。 | ||
|
重要な理由
初期キューでの待機時間の終了と、アクティブな調査段階の開始を示し、Pending State分析を支援します。
入手先
「state」フィールドの変更を記録するServiceNowの「sys_audit」テーブル(設定により値が102または103へ変更されます)
取得
状態フィールドの変更前と変更後を比較
イベントタイプ
inferred
|
|||
|
回避策を公開
|
「Communicate Workaround」アクションを実行することです。関連するインシデントに回避策を反映するか、Known Error記事を作成します。単に回避策を入力することとは異なります。 | ||
|
重要な理由
ナレッジ共有の速度を測定するうえで重要です。ここでの遅延は、インシデントの再発件数に直接影響します。
入手先
ServiceNowの「sys_journal_field」または特定のUI Actionログ。タイプが「Known Error」の「kb_knowledge」レコードが作成された場合から推定することもできます。
取得
トランザクションCommunicate Workaroundの実行時に記録
イベントタイプ
explicit
|
|||
|
導入後レビューを完了
|
PIRタスクを完了するか、PIRフラグを設定することです。重大な問題について振り返り分析を実施したことを確認します。 | ||
|
重要な理由
Post-Implementation Review Complianceダッシュボードを直接支援します。優先度の高い問題でこのアクティビティが欠落している場合、コンプライアンス違反を示します。
入手先
ServiceNowの「problem_task」テーブル(type=PIR)のクローズ、または「problem」テーブルの「pir_state」フィールドの変更
取得
フィールドXとYを比較して導出
イベントタイプ
inferred
|
|||
|
提案された解決策を起案
|
「Fix Notes」または「Resolution Code」フィールドにデータを入力することです。アナリストが原因の理解から恒久対応の設計へ進んだことを示します。 | ||
|
重要な理由
設計段階の所要時間を切り出し、Solution Drafting and Fix Applicationダッシュボードを支援します。
入手先
「fix_notes」フィールドの更新を記録するServiceNowの「sys_audit」テーブル
取得
状態フィールドの変更前と変更後を比較
イベントタイプ
inferred
|
|||
|
状態をFix in Progressに変更
|
修正の構築または展開中であることを示す状態へレコードが遷移することです。通常はChange Managementの対応待ちを含みます。 | ||
|
重要な理由
アクティブな調査時間と「変更待ち」時間を区別し、ボトルネック分析の精度を高めます。
入手先
ServiceNowの「sys_audit」テーブルで、「state」フィールドが「Fix in Progress」へ遷移(通常は値104)
取得
状態フィールドの変更前と変更後を比較
イベントタイプ
inferred
|
|||
|
解決を検証
|
解決策が有効であることを確認する検証ステップです。プロセスの成熟度に応じて、特定の状態またはチェックボックスで記録します。 | ||
|
重要な理由
クローズ前の品質管理を確実にします。このステップを省略すると、Process Deviation分析が可能になります。
入手先
ServiceNowの「sys_audit」テーブル。状態変更(Resolved → Closed)または設定された「u_resolution_verified」フィールドで記録できます。
取得
状態フィールドの変更前と変更後を比較
イベントタイプ
inferred
|
|||
|
評価を却下
|
有効な問題ではないため、評価段階で問題レコードが以前の状態に戻されるか、キャンセルされることです。 | ||
|
重要な理由
インシデントが誤って問題へ昇格されるプロセス上の無駄を特定します。
入手先
ServiceNowの「sys_audit」テーブルで、「state」フィールドが「Assess」から「Closed/Cancelled」または「New」へ遷移
取得
状態フィールドの変更前と変更後を比較
イベントタイプ
inferred
|
|||
抽出ガイド
始める準備はできていますか?
完全版テンプレートをダウンロードし、Problem Managementのデータを具体的な改善案につなげてください。プロセスマイニングの導入から運用まで、各段階でチームがサポートします。
Problem Managementを最適化し、解決を迅速化
プロセスマイニングで調査サイクルを30%短縮
クレジットカードは不要です。数分で設定できます。