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

アクティビティ名は、「問題レコード作成」「根本原因特定済み」「恒久対応実装」など、問題管理プロセスの1つのステップを表します。これらのアクティビティは時系列で記録され、問題がどのように処理されたかを示します。

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

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

アクティビティ名は、通常、ステータス変更ログ、監査証跡、または問題レコードに関連するイベントテーブルから取得されます。

イベント時刻、つまりタイムスタンプは、問題のライフサイクルにおける各アクティビティの時系列を示します。イベントを正しい順序に並べ、異なるプロセスステップ間の所要時間を計算するために欠かせません。

プロセスマイニングでは、アクティビティの並べ替え、プロセスモデルの発見、時間に基づくすべての分析に使います。「根本原因調査の平均時間」などの主要業績評価指標を計算したり、根本原因の特定から変更要求の開始までの引き継ぎにかかる遅延を特定したりする基盤となります。

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

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

問題レコード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」）として記録するか、回避策の詳細フィールドにテキストが入力されているかどうかから判定します。

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

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

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

通常、問題レコードのメインテーブルにあり、「担当者」「割り当て先」「コーディネーター」などの名前で表示されます。

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

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

問題を変更管理上の解決策に関連付け、引き継ぎの遅延と解決までのライフサイクル全体を分析できます。

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