問題管理データテンプレート
問題管理データテンプレート
- 根本原因分析に推奨される属性
- 主要なプロセスの節目とアクティビティ
- 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)。この識別子は、最初の記録から根本原因の分析、最終的なクローズまで、プロセス内のすべてのアクティビティを結び付けます。プロセスマイニング分析ではケース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
|
|||
|
割り当て先ユーザー
AssignedTo
|
問題への対応を割り当てられた担当者です。 | ||
|
説明
問題レコードを現在担当しているユーザーを特定します。この属性を分析すると、作業負荷の分布や個人のパフォーマンス、担当者レベルで発生しているボトルネックを把握できます。
重要な理由
リソースの効率と個人の作業負荷を分析するための重要な項目です。
入手先
ServiceNowの「problem」テーブルの「assigned_to」フィールド
例
アリス・スミスボブ・ジョーンズシステム管理者
|
|||
|
問題の状態
ProblemState
|
問題レコードのライフサイクル上のステータスです。 | ||
|
説明
オープン、根本原因分析、修正対応中、クローズなど、問題レコードの現在の段階を示します。「長期滞留問題レコードの滞留期間分析」でバックログの内訳を絞り込み、把握する際の主要な項目です。
重要な理由
オープンケースとクローズ済みケースを絞り込むための主要なステータス項目です。
入手先
ServiceNowの「problem」テーブルの「state」フィールド
例
新規評価根本原因分析解決済み
|
|||
|
根本原因のカテゴリ
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
|
|||
|
ビジネスサービス
BusinessService
|
問題の影響を受ける上位レベルのビジネスサービスです。 | ||
|
説明
技術コンポーネントではなく、「給与サービス」や「顧客ポータル」など、ビジネス側から見たサービスを表します。関係者への報告をビジネスの視点で行えます。
重要な理由
技術的な問題をビジネス上のバリューストリームに結び付けます。
入手先
ServiceNowの「problem」テーブルの「business_service」フィールド
例
オンラインバンキング社内メール
|
|||
|
保留期間
PendingDuration
|
問題が一時停止または保留状態にあった合計時間です。 | ||
|
説明
「ベンダー待ち」や「保留中」などのステータスにあった時間を合計します。「保留状態と待機時間の分析」で、社内の処理時間と外部要因による遅延を分けて把握するために使います。
重要な理由
チームの非効率と外部依存による遅延を区別できます。
入手先
算出方法:状態が「保留/一時停止」の期間の所要時間を合計
例
5日0分
|
|||
|
回避策を公開
WorkaroundPublished
|
回避策が文書化され、共有されているかを示します。 | ||
|
説明
一時的な修正方法が特定され、ナレッジベースまたは既知エラーデータベースに公開されているかを示す真偽値またはステータスです。「回避策の公開状況」ダッシュボードに使用します。
重要な理由
最終的な修正前に、業務への影響をどれだけ早く軽減できたかを測るうえで重要です。
入手先
ServiceNowの「problem」テーブルの「work_around」フィールド(テキストの有無)または特定のステータス
例
truefalse
|
|||
|
変更要求番号
ChangeRequestNumber
|
問題の修正のために起票された変更要求の識別子です。 | ||
|
説明
問題レコードを変更管理レコード(RFC)に関連付けます。この関連付けにより、「変更要求への移行効率」ダッシュボードで、問題の診断からインフラ変更の実施までの引き継ぎ時間を測定できます。
重要な理由
問題管理から変更管理への移行を追跡します。
入手先
ServiceNowの「problem」テーブルの「rfc」フィールド
例
CHG003001CHG004552
|
|||
|
既知エラーかどうか
IsKnownError
|
問題が既知エラーに分類されているかを示すフラグです。 | ||
|
説明
問題レコードが既知エラーに変換されたか、既知エラーとしてマークされたかを特定します。「既知エラーとインシデントの再発」分析で、ナレッジ管理プロセスの有効性を確認するために必要です。
重要な理由
調査中の問題と、回避策がある既知の不具合を区別できます。
入手先
ServiceNowの「problem」テーブルの「known_error」フィールド
例
truefalse
|
|||
|
構成アイテム
ConfigurationItem
|
問題の影響を受けた特定の資産またはサービスです。 | ||
|
説明
問題レコードに関連付けられた構成アイテム(CI)を特定します。これを分析すると、問題と特定のハードウェア、ソフトウェア、サービスとの関連を把握でき、「根本原因の分類精度」ダッシュボードに役立ちます。
重要な理由
プロセス上の問題を、特定の物理資産または論理資産に関連付けます。
入手先
ServiceNowの「problem」テーブルの「cmdb_ci」フィールド
例
SAP ERPサーバー01ExchangeメールサービスOracle本番データベース
|
|||
|
解決策の立案時間
SolutionDraftingTime
|
根本原因の特定から解決策の提案までにかかる時間です。 | ||
|
説明
原因の特定後、修正方法を検討する設計段階の所要時間を追跡します。「解決策の立案と修正の適用」ダッシュボードに使用します。
重要な理由
修正方法の設計段階におけるパフォーマンスを切り分けて把握できます。
入手先
算出方法:「解決策の提案」時のタイムスタンプから「根本原因の特定」時のタイムスタンプを差し引く
例
2日4時間
|
|||
問題管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
サポートグループに割り当て
|
調査を担当する特定の技術チームに問題レコードを振り分けます。このアクティビティは担当の移り変わりを追跡し、引き継ぎの分析に欠かせません。 | ||
|
重要な理由
サポートグループ再割り当て分析ダッシュボードで、チーム間の行き来やボトルネックを特定するために必要です。
入手先
ServiceNowの「sys_audit」または「sys_history_line」テーブルで、「assignment_group」フィールドの変更を追跡。
記録
ステータスフィールドの変更前後を比較
イベントタイプ
inferred
|
|||
|
問題レコードをクローズ
|
レコードが非アクティブになる、ライフサイクルの最終イベントです。以降の作業は想定されません。 | ||
|
重要な理由
プロセスインスタンスの確定した終了点です。サイクルタイムの合計を算出するために必要です。
入手先
ServiceNowの「problem」テーブルの「closed_at」フィールド、または「state」フィールドが「Closed」に移行したこと。
記録
Close Problemトランザクションの実行時に記録
イベントタイプ
explicit
|
|||
|
問題レコードを作成
|
ServiceNowシステムで問題レコードを最初に作成することです。問題管理のライフサイクルが始まり、滞留期間を測定するための基準時刻が記録されます。 | ||
|
重要な理由
サイクルタイムの計算とSLAの測定における開始時刻を設定します。新たに開始する問題調査の件数を把握するための基準となります。
入手先
ServiceNowの「problem」テーブルの「sys_created_on」フィールド。
記録
New Recordトランザクションの実行時に記録
イベントタイプ
explicit
|
|||
|
回避策を特定
|
問題レコードの「Workaround」フィールドにテキストを入力します。アナリストが暫定対策を文書化した時点を記録します。 | ||
|
重要な理由
回避策公開パフォーマンスダッシュボードで、技術的な解決策が最初に判明した時点を特定するために使います。
入手先
ServiceNowの「sys_audit」テーブルで、「fieldname」が「workaround」のレコード。
記録
ステータスフィールドの変更前後を比較
イベントタイプ
inferred
|
|||
|
変更リクエストを開始
|
変更リクエスト(RFC)を問題レコードに関連付けます。実施に向けてProblem ManagementからChange Managementへ引き継いだことを示します。 | ||
|
重要な理由
変更リクエスト移行効率ダッシュボードに必要です。修正の発見から変更プロセスの開始までの遅延を特定します。
入手先
ServiceNowの「sys_audit」テーブルで、「problem」テーブルの「rfc」参照フィールドへの値の設定を追跡。
記録
Create Normal Changeトランザクションの実行時に記録
イベントタイプ
explicit
|
|||
|
恒久対策を適用
|
問題が「Resolved」としてマークされた時点です。関連する変更リクエストのクローズをきっかけとすることがよくあります。技術的な作業が完了したことを示します。 | ||
|
重要な理由
修正対応の終了時点を特定します。SLAに対する合計解決時間の算出に使います。
入手先
ServiceNowの「sys_audit」テーブルで、「state」フィールドが「Resolved」に移行したことを記録(通常の値は106)。
記録
ステータスフィールドの変更前後を比較
イベントタイプ
inferred
|
|||
|
根本原因を特定
|
「Root Cause」コードが入力されるか、状態が「Fix in Progress」に移行した時点です。問題の診断が完了したことを示します。 | ||
|
重要な理由
根本原因の判明までの平均時間を算出し、根本原因調査サイクルタイムダッシュボードを支えます。プロセス上の重要な節目です。
入手先
ServiceNowの「sys_audit」テーブルで、「root_cause」カテゴリフィールドの変更、または状態が「Fix in Progress」に移行したことを追跡。
記録
ステータスフィールドの変更前後を比較
イベントタイプ
inferred
|
|||
|
調査を開始
|
問題レコードの状態が「New」から「Assess」または「Root Cause Analysis」に移行します。アナリストが問題への対応を実際に開始したことを示します。 | ||
|
重要な理由
初期キューでの待機時間の終了と、調査段階の開始を示します。保留状態の分析にも利用できます。
入手先
ServiceNowの「sys_audit」テーブルで、「state」フィールドの変更を追跡(設定に応じて値が102または103に変更)。
記録
ステータスフィールドの変更前後を比較
イベントタイプ
inferred
|
|||
|
回避策を公開
|
「Communicate Workaround」アクションを実行し、関連するインシデントに回避策を通知するか、既知のエラー記事を作成します。回避策を入力するだけの場合とは異なります。 | ||
|
重要な理由
ナレッジ共有の速度を測定するうえで重要です。ここでの遅延は、インシデントの再発件数に直接影響します。
入手先
ServiceNowの「sys_journal_field」テーブルまたは特定のUI Actionログ。タイプが「Known Error」の「kb_knowledge」レコードの作成から推定することもできます。
記録
Communicate Workaroundトランザクションの実行時に記録
イベントタイプ
explicit
|
|||
|
導入後レビューを完了
|
PIRタスクの完了、またはPIRフラグの設定です。重大な問題について振り返り分析が行われたことを示します。 | ||
|
重要な理由
導入後レビュー遵守ダッシュボードに直接反映されます。優先度の高い問題でこのアクティビティが欠けている場合、コンプライアンス違反を示します。
入手先
ServiceNowの「problem_task」テーブル(type=PIR)のクローズ、または「problem」テーブルの「pir_state」フィールドの変更。
記録
フィールドXとYの比較から導出
イベントタイプ
inferred
|
|||
|
状態をFix in Progressに変更
|
修正の作成または展開が進行中であることを示す状態に移行します。多くの場合、Change Managementの対応待ちです。 | ||
|
重要な理由
調査中の時間と「変更待ち」の時間を区別し、ボトルネック分析の精度を高めます。
入手先
ServiceNowの「sys_audit」テーブルで、「state」フィールドが「Fix in Progress」に移行したことを記録(通常の値は104)。
記録
ステータスフィールドの変更前後を比較
イベントタイプ
inferred
|
|||
|
解決を検証
|
解決策が有効であることを確認する検証手順です。プロセスの成熟度に応じて、特定の状態やチェックボックスで記録されます。 | ||
|
重要な理由
クローズ前の品質管理を確実にします。この手順を省略した場合は、プロセス逸脱の分析が可能です。
入手先
ServiceNowの「sys_audit」テーブル。状態変更(ResolvedからClosed)または設定済みの「u_resolution_verified」フィールドで記録できます。
記録
ステータスフィールドの変更前後を比較
イベントタイプ
inferred
|
|||
|
解決策の案を作成
|
「Fix Notes」または「Resolution Code」フィールドにデータを入力します。アナリストが原因の把握から恒久対策の設計に進んだことを示します。 | ||
|
重要な理由
解決策の起案と修正適用ダッシュボードで、設計段階の所要時間を切り分けて確認できます。
入手先
ServiceNowの「sys_audit」テーブルで、「fix_notes」フィールドの更新を追跡。
記録
ステータスフィールドの変更前後を比較
イベントタイプ
inferred
|
|||
|
評価を却下
|
問題として有効でないため、評価段階で問題レコードが前の状態に戻されるか、キャンセルされます。 | ||
|
重要な理由
インシデントが誤って問題として登録されることによる、プロセス上の無駄を特定します。
入手先
ServiceNowの「sys_audit」テーブルで、「state」フィールドが「Assess」から「Closed/Cancelled」または「New」に移行したことを記録。
記録
ステータスフィールドの変更前後を比較
イベントタイプ
inferred
|
|||
データ抽出ガイド
始める準備はできましたか?
テンプレート一式をダウンロードして、問題管理データを具体的な改善案につなげましょう。プロセスマイニングを進める各段階で、弊社チームがサポートします。
問題管理を見直し、今すぐ解決を迅速化
プロセスマイニングで調査サイクル時間を30%短縮
クレジットカード不要。数分で設定できます。