問題管理データテンプレート

アクティビティ名は、「問題レコードの作成」「根本原因の特定」「恒久的な修正の実装」など、問題管理プロセスの個々のステップを表します。問題への対応の流れを把握できるよう、これらのアクティビティは時系列で記録されます。

プロセスマイニングでは、この属性を使って、実際の作業の流れを視覚的に示すプロセスマップを作成します。アクティビティの順序、頻度、経路を分析すると、問題解決プロセスの逸脱、ボトルネック、非効率な箇所を見つけられます。

プロセスの各ステップを定義する属性です。一般的な経路や逸脱を含むプロセスフローを可視化し、分析できます。

アクティビティ名は、問題レコードに関連付けられたステータス変更ログ、監査証跡、イベントテーブルから取得することがよくあります。

イベント日時（タイムスタンプ）は、問題のライフサイクルにおける各アクティビティの時系列を示します。イベントを正しい順序に並べ、プロセスの各ステップにかかった時間を計算するために必要です。

プロセスマイニングでは、アクティビティの順序付け、プロセスモデルの発見、時間に基づく分析にこの属性を使います。「根本原因調査の平均時間」などの重要業績評価指標（KPI）の計算や、根本原因の特定から変更リクエストの開始までの引き継ぎなど、ステップ間の遅延の特定にも使われます。

各アクティビティのタイムスタンプは、イベントの順序付けや、サイクルタイム、ボトルネックの継続時間など、時間に基づく指標の計算に欠かせません。

通常、イベントログまたは監査証跡テーブルで、アクティビティ名やケースIDとともに記録されています。

問題レコードIDは、問題の作成から最終的な解決まで、ライフサイクル全体を追跡するための主キーです。複数のインシデントに関連付けられる場合がある各問題には、ほかの問題と区別するための一意のIDが割り当てられます。

プロセスマイニングでは、この属性によってケースが定義され、関連するすべてのアクティビティを1つのプロセスインスタンスにまとめられるため、欠かせません。プロセスフローの分析、ボトルネックの特定、ケース所要時間の計算には、問題レコードを正しく識別することが必要です。

関連するすべてのイベントをまとめる基本的なケースIDです。各問題調査の開始から終了までの流れを追跡できます。

通常、ITサービス管理（ITSM）システムの問題テーブルまたはチケットテーブルにあります。

この属性は、問題管理データの取得元を示します。たとえば、ServiceNow、Jira、独自開発のITSMツールなどです。複数のシステムのデータを組み合わせて全体を分析する環境では、特に重要です。

プロセスマイニングでは、ソースシステムをフィルターとして使い、事業部門やプラットフォームごとのプロセスパフォーマンスや違いを比較できます。また、データの取得元を確認できるため、データの検証や問題の調査にも役立ちます。

データの取得元を示します。データの検証や、異なるシステムまたは組織単位間でのプロセス比較に欠かせません。

通常、データ抽出時に特定のソースシステムから取得したレコードを識別するため、固定値として追加されます。

この属性には、直近のデータ取得日時が記録されます。分析対象のデータがどの時点のものかを明確にし、関係者が分析の対象期間を把握できるようにします。

ダッシュボードやレポートでは、情報を正しく解釈するために欠かせない情報です。リアルタイムの情報なのか、特定時点のスナップショットなのかを確認でき、「長期滞留中の問題のバックログ」などの指標の解釈に役立ちます。

データの最終更新時点を示し、分析やダッシュボードを正しく解釈するための重要なコンテキストを提供します。

通常、データの取り込み時に、データ抽出・変換・ロード（ETL）ツールまたはスクリプトによって生成、保存されます。

SLA期限は、問題解決の正式な目標日時です。通常、問題の優先度とサービスレベル契約（SLA）の条件に基づいて決まります。

この属性は、「SLA適合状況の概要」ダッシュボードに欠かせません。実際の解決時間をSLA期限と比較することで、SLAの達成率を算出できます。さらにプロセスマイニングで分析を掘り下げると、どのプロセスステップやチームがSLA違反に最も影響しているかを特定できます。

解決目標を定め、SLAの適合状況の測定と報告の基準となります。

通常、問題の作成日時と優先度に基づいて算出され、問題レコードに保存されます。

この真偽値属性は、サービスレベル契約を達成したかどうかを直接示します。通常、問題の解決日時がSLA期限より後の場合にtrueに設定されます。

結果を直接示すこのフラグは、概要レベルのダッシュボードやレポートに役立ちます。プロセスマイニングでは、適合性チェックの作成や、SLA違反が発生したすべてのケースの抽出に使えます。違反があった問題と、なかった問題のプロセスマップを比較すると、SLA未達につながるパターン、ボトルネック、特定のアクティビティを見つけられます。

SLAの達成・未達を明確に示し、違反につながるプロセス経路を簡単に抽出して分析できます。

多くの場合、解決日時とSLA期限を比較して算出する項目です。

サポートグループは、問題を担当するチームを示します。問題の進行に伴い、レベル2のサポートチームからネットワークエンジニアリングの専門チームへ移るなど、担当グループが変更される場合があります。

この属性は、チームのパフォーマンスやチーム間の引き継ぎを分析するうえで重要です。プロセスマイニングを使うと、担当変更による遅延や、各グループが問題を担当する期間を把握し、特定の種類の問題を効率よく解決しているチームを特定できます。「サポートグループ間の引き継ぎ分析」などのダッシュボードにも役立ちます。

チームのパフォーマンス分析、引き継ぎによるボトルネックの特定、チーム間の業務量の把握に役立ちます。

通常、ITSMシステムの問題レコードにある担当履歴または詳細テーブルに保存されています。

優先度は、ビジネスへの影響と緊急度に基づいて問題を分類するための重要な属性です。チームが重大な問題から優先して対応できるようにします。優先度は通常、「重大」「高」「中」「低」などに標準化されています。

プロセス分析では、優先度を軸に分析対象を絞り、比較できます。優先度の高い問題と低い問題のプロセスフローを比較し、対応方法や効率に違いがあるかを確認できます。また、SLAは優先度に応じて設定されることが多いため、SLAの適合性チェックにも欠かせません。

重大な問題と通常の問題への対応を比較する分析に使え、SLAの遵守状況を測定するうえでも欠かせません。

多くのITSMプラットフォームで、問題レコードのメインテーブルに標準項目として用意されています。

この指標は、問題の担当が引き継がれた回数を数えます。再割り当て回数が多い場合、最初の振り分けが適切でない、チームの役割が明確でないなど、プロセスの非効率が考えられます。

プロセスマイニングでは、プロセスの停滞を示す重要な指標です。問題がチーム間を行き来する「たらい回し」のケースを特定できます。再割り当て回数の多いケースを分析すると、大幅な遅延や無駄な作業につながる知識不足やプロセス上の問題が見つかります。

過剰な引き継ぎを追跡してプロセスの非効率を数値化できます。引き継ぎの多さは、不適切な振り分け、知識不足、責任範囲の不明確さを示すことがあります。

通常、担当が変更されるたびに問題レコード上で加算されるカウンター項目です。イベントログから算出することもできます。

この属性は、問題をITインフラ内の特定のコンポーネントやサービスに関連付けます。たとえば、「メールサービス」や「顧客関係管理プラットフォーム」などです。技術的な問題をビジネスの観点から捉えるための情報を提供します。

プロセスマイニングでは、影響を受けるサービスを使って、ビジネスを軸にプロセスを分析できます。「どのサービスで問題が最も多く発生しているか」「重要な財務システムに影響する問題の平均解決時間はどのくらいか」といった問いに答えられます。ビジネスへの影響に基づいて改善の優先順位を決めるうえで、このコンテキストが役立ちます。

技術的な問題と影響を受けるサービスを関連付けてビジネス上の背景を示し、ビジネス上の重要度に基づく優先順位付けを可能にします。

通常、構成管理データベース（CMDB）から関連付けられ、問題レコードの「構成アイテム」または「サービス」項目に保存されます。

調査の完了後、根本原因カテゴリを使って問題の根本的な原因を分類します。たとえば、「ソフトウェアの不具合」「ハードウェア障害」「設定エラー」などです。この分類は、計画的な改善に欠かせません。

この属性は、「根本原因調査のパフォーマンス」ダッシュボードの基盤となります。根本原因カテゴリごとの発生頻度を分析すると、組織全体で繰り返し発生する問題を特定し、長期的な修正の優先順位を決められます。問題発生後の対応から、事前の予防へと重点を移すのに役立ちます。

組織全体で問題を引き起こしている要因の傾向や、構造的な問題の特定に役立つため、戦略的な分析に欠かせません。

通常、問題レコードの専用項目に記録され、クローズ時またはその前に入力されます。

この属性は、問題によって発生したユーザー向けインシデントの数を示し、問題の影響度を数値化します。関連インシデント数が多い問題は、通常、ビジネスへの影響も大きくなります。

この指標は、優先順位付けや影響分析に役立ちます。プロセスマイニングでは、インシデント数と調査時間や解決優先度との関係を分析できます。問題の規模を把握し、1つの修正で防げたインシデント数を示すことで、問題管理に必要なリソースの根拠を明らかにできます。

問題のビジネスへの影響を数値化し、調査の優先順位付けや解決策の効果測定に役立ちます。

問題レコード上の計算項目として、関連付けられたインシデントレコード数を数えることがよくあります。

問題ステータスは、ワークフローにおける問題の現在の段階を示します。最初の記録から最終的な解決まで、各時点で問題がどの段階にあるかを把握できます。

アクティビティ名がステータス変更のイベントを記録するのに対し、問題ステータスは現在のバックログの分析に役立ちます。各ステータスの未解決問題数を示すダッシュボードを作成し、業務量の管理や、特定の段階に長期間とどまっているレコードの特定に利用できます。

問題の現在の段階を示します。バックログの分析や、特定の段階で停滞している問題の特定に欠かせません。

問題のライフサイクルに応じて更新される、問題レコードのメインテーブルの標準項目です。

この属性は、恒久的な修正の開発中に問題の影響を抑えるため、一時的な解決策が提供されたかどうかを記録します。問題管理のライフサイクルにおける重要なマイルストーンです。

この属性は、「回避策の効果と提供速度」ダッシュボードに欠かせません。プロセスマイニングを使って回避策の提供までの平均時間を算出し、回避策の提供後に関連インシデントの新規発生数が減ったかを分析できます。根本原因の修正前に、チームがどれだけ速くサービスを復旧できるかを測定できます。

サービスが一時的に復旧したかどうかを示し、チームがビジネスへの影響をどれだけ速く抑えられるかを分析できます。

「WorkaroundPublished」などの真偽値フラグを使う方法や、回避策の詳細項目にテキストが入力されているかどうかから判定する方法があります。

この属性は、各時点で問題を担当する個人を示します。サポートグループがチームを示すのに対し、担当ユーザーは調査を担当するエージェント、エンジニア、コーディネーターを示します。

担当ユーザー別に分析すると、個人の業務量やパフォーマンス、トレーニングの必要性を把握できます。特定の担当者がボトルネックになっていないか、チーム内で業務が均等に分担されているかも確認できます。サポートグループの分析を補完する視点です。

個人の業務量やパフォーマンスを分析し、優れた成果を上げている担当者や、追加の支援・トレーニングが必要な担当者の特定に役立ちます。

通常、問題レコードのメインテーブルにあり、「Assignee」「Assigned To」「Coordinator」などの項目名が付いています。

この属性は、問題管理プロセスと変更管理プロセスを直接関連付けます。問題の根本原因を解決するために、コード変更、ハードウェア交換、その他の変更が必要な場合に使います。

この関連付けを分析すると、「変更管理への引き継ぎの遅延」を把握できます。プロセスマイニングでは、根本原因の特定から変更リクエストの作成まで、また変更の実施から問題のクローズまでにかかる時間を測定できます。2つのプロセス間の連携における非効率な箇所の特定に役立ちます。

問題と変更管理上の解決策を関連付け、引き継ぎの遅延や解決までの一連の流れを分析できます。

通常、問題レコードにある参照項目で、変更管理システムまたはモジュール内の対応するレコードにリンクします。