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

アクティビティ名とは、「問題記録作成済み」、「根本原因特定済み」、「恒久的な修正実装済み」など、問題管理プロセスにおける単一のステップを記述するものです。これらのアクティビティは、問題がどのように処理されたかの経緯を構築するために時系列で記録されます。

プロセスマイニングにおいて、この属性は実際の作業の流れを視覚的に表現するプロセスマップを構築するために非常に重要です。これらのアクティビティの順序、頻度、経路を分析することで、問題解決プロセスにおける逸脱、ボトルネック、非効率性を明らかにすることができます。

この属性は、プロセスのステップを定義し、一般的なパスや逸脱を含むプロセスフローの可視化と分析を可能にします。

アクティビティ名は、主に問題記録に関連するステータス変更ログ、監査証跡、またはイベントテーブルから導き出されることがよくあります。

イベントタイム、すなわちタイムスタンプは、問題のライフサイクルにおける各アクティビティの時系列的な文脈を提供します。イベントを正しく順序付けし、異なるプロセスステップ間の期間を計算するために不可欠です。

プロセスマイニングでは、この属性はアクティビティを順序付けし、プロセスモデルを発見し、すべての時間ベースの分析を実行するために使用されます。「平均根本原因調査時間」のような主要業績評価指標（KPI）を計算するための基礎であり、根本原因の特定と変更要求の開始との間の引き継ぎなど、ステップ間の遅延を特定するためにも利用されます。

各アクティビティのタイムスタンプは、イベントの順序付けや、サイクルタイムやボトルネック期間などの時間ベースのすべてのメトリクスを計算する上で極めて重要です。

このタイムスタンプは通常、アクティビティ名とケース識別子とともにイベントログまたは監査証跡テーブルに配置されます。

問題記録IDは、問題の作成から最終解決までのライフサイクル全体を追跡するための主キーとして機能します。複数のインシデントにリンクされている可能性のある各問題には、他のすべての問題と区別するためのユニークなIDが割り当てられます。

プロセスマイニングにおいて、この属性はケースを定義するための基礎であり、ツールがすべての関連アクティビティを単一のプロセスインスタンスにグループ化できるようにします。プロセスフローの分析、ボトルネックの特定、ケース期間の計算はすべて、各ユニークな問題記録の正しい識別にかかっています。

これは、関連するすべてのイベントをグループ化し、各問題調査のエンドツーエンドのジャーニーを追跡することを可能にする、必要不可欠なケースIDです。

この識別子は通常、ITサービスマネジメント（ITSM）システムの主要な問題またはチケットテーブルに見られます。

この属性は、問題管理データの出所（例：ServiceNow、Jira、自社開発のITSMツールなど）を特定します。複数のシステムからのデータが統合され、全体的な分析が行われる環境では特に重要です。

プロセスマイニングの文脈では、ソースシステムをフィルターとして使用し、異なる事業部門やプラットフォーム間のプロセスパフォーマンスと差異を比較できます。また、データの出所に関するコンテキストを提供することで、データ検証とトラブルシューティングを支援します。

データの出所を特定します。これはデータ検証や、異なるシステムまたは組織単位間のプロセスを比較するために非常に重要です。

これは通常、データ抽出プロセス中に特定のソースシステムからのレコードにラベルを付けるために追加される静的な値です。

この属性は、最新のデータ取得日時を記録します。分析対象データの鮮度に関する透明性を提供し、関係者が分析がカバーする期間を確実に理解できるようにします。

ダッシュボードやレポートにおいて、この情報はコンテキストにとって極めて重要です。ユーザーがリアルタイム情報を見ているのか、特定の時点のスナップショットを見ているのかを知るのに役立ち、それは「滞留問題バックログ」のような指標の解釈に影響を与えます。

データの鮮度に関する重要なコンテキストを提供し、分析やダッシュボードが最終データ更新に基づいて正しく解釈されるようにします。

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

SLA期限は、問題解決の正式な目標を設定します。この目標は通常、問題の優先度とサービスレベル契約（SLA）で定義された条件に基づいて決定されます。

この属性は、「SLAコンプライアンス概要」ダッシュボードに不可欠です。実際の解決時間とSLA期限を比較することで、組織はSLA達成率を計算できます。プロセスマイニングはさらにこれを掘り下げて、どのプロセスステップやチームがSLA違反に最も貢献しているかを特定することができます。

解決目標を定義し、すべてのSLAコンプライアンス測定およびレポートの基礎を形成します。

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

サポートグループは、問題に割り当てられているチームを示します。問題が進行するにつれて、レベル2サポートチームから専門のネットワークエンジニアリングチームなど、異なるグループ間で再割り当てされることがあります。

この属性は、チームパフォーマンスとチーム間の引き継ぎを分析するために不可欠です。プロセスマイニングは、再割り当てによる遅延を浮き彫りにし、問題が各グループに滞留する期間を測定し、特定の種類の問題解決に最も効果的なチームを特定できます。これは「サポートグループ引き継ぎ分析」のようなダッシュボードを直接サポートします。

チームのパフォーマンス分析、引き継ぎによるボトルネックの特定、および異なるチーム間のワークロード分散の理解に不可欠です。

この情報は通常、ITSMシステム内の問題レコードの割り当て履歴または主要な詳細テーブルに保存されます。

この真偽値属性は、サービスレベル契約（SLA）が達成されたかどうかをシンプルかつ直接的に示す指標となります。通常、問題の解決タイムスタンプがSLA期日よりも遅い場合にtrueに設定されます。

直接的な成果指標として、このフラグは高レベルのダッシュボード作成やレポート作成に非常に有用です。プロセスマイニングでは、コンプライアンスチェックを作成したり、すべての違反ケースをフィルタリングしたりするために使用できます。SLA違反した問題と違反していない問題のプロセスマップを分析することで、SLA失敗の一般的な原因となるパターン、ボトルネック、または特定のアクティビティを明らかにすることができます。

SLAコンプライアンスの成功または失敗の明確な結果を提供し、違反につながるプロセスパスを簡単にフィルタリングして分析できるようにします。

これは多くの場合、解決タイムスタンプとSLA期日を比較することによって決定される、導出または計算されるフィールドです。

優先度は、問題のビジネスへの影響と緊急性に基づいて問題を分類するために使用される重要な属性です。これにより、チームは最も重要な問題に最初に取り組むことができます。優先度レベルは通常、重大、高、中、低などのように標準化されています。

プロセス分析において、優先度はフィルタリングと比較のための強力なディメンションです。アナリストは、高優先度の問題と低優先度の問題のプロセスフローを比較して、それらが異なって、またはより効率的に処理されているかどうかを確認できます。SLAは優先度レベルに結びつけられることが多いため、SLAコンプライアンス分析の基礎でもあります。

重要問題と通常の問題がどのように処理されているかを比較するために分析をセグメント化することができ、SLA遵守状況を測定するために不可欠です。

これは、ほとんどのITSMプラットフォームの主要な問題レコードテーブルにおける標準フィールドです。

この指標は、問題の責任が何回移転されたかを数えます。再割り当て回数が多い場合、初期ルーティングの誤りやチームの責任範囲の不明確さなど、プロセスの非効率性を示すことがよくあります。

プロセスマイニングにおいて、これはプロセス摩擦の主要な指標です。問題がチーム間でたらい回しにされる「ピンポン」シナリオを特定するために使用できます。再割り当て回数が多いケースを分析することで、著しい遅延と無駄な労力につながる知識ギャップやプロセス上の欠陥を明らかにできます。

過剰な引き継ぎを追跡することでプロセスの非効率性を定量化するのに役立ちます。これはしばしば、誤ったルーティング、知識のギャップ、または不明確な責任を示唆します。

これは多くの場合、割り当て変更のたびに問題レコード上で増加するカウンターフィールドです。イベントログから計算することも可能です。

この属性は、問題とITインフラ内の特定のコンポーネントまたはサービス（例：「メールサービス」や「顧客関係管理プラットフォーム」）を関連付けます。これにより、技術的な問題に重要なビジネスコンテキストを提供します。

プロセスマイニング分析において、影響サービスはプロセスをビジネス中心の視点で見られるようにします。「どのサービスが最も多くの問題を発生させているか？」「重要な財務システムに影響を与える問題の平均解決時間はどれくらいか？」といった疑問に答えるのに役立ちます。このコンテキストは、ビジネスへの影響に基づいて改善活動の優先順位を決定する上で不可欠です。

技術的な問題を影響を受けるサービスにリンクさせることでビジネスコンテキストを提供し、ビジネスの重要性に基づいた優先順位付けを可能にします。

これは通常、構成管理データベース（CMDB）からリンクされ、問題レコードの「Configuration Item（構成アイテム）」または「Service（サービス）」フィールドに保存されます。

調査が完了すると、根本原因カテゴリは、「ソフトウェア欠陥」「ハードウェア障害」「設定エラー」など、問題の根本的な原因を分類するために使用されます。この分類は、戦略的改善に不可欠です。

この属性は、「根本原因調査パフォーマンス」ダッシュボードの礎石となります。異なる根本原因カテゴリの頻度を分析することで、組織は繰り返し発生するシステム的な問題を特定し、長期的な修正に優先順位を付けることができます。これにより、反応的な問題解決から、プロアクティブな予防へと焦点を移すことができます。

これは戦略的分析にとって重要であり、組織全体で問題を引き起こしている体系的な問題や傾向を特定するのに役立ちます。

この情報は通常、問題レコードの専用フィールドで取得され、多くの場合、クローズフェーズの前または最中に記入されます。

この属性は、問題が引き起こしたユーザー向けインシデントの数を示すことで、問題の影響を定量化します。関連インシデント数が多い問題は、通常、ビジネスへの影響がより大きくなります。

この指標は、優先順位付けと影響分析のための強力なツールです。プロセスマイニングでは、インシデント数と調査時間や解決の優先順位を相関させるために使用できます。これにより、組織は問題の規模を理解し、1つの修正によってどれだけのインシデントが防止されるかを示すことで、問題管理に費やされたリソースを正当化するのに役立ちます。

問題のビジネス影響を定量化し、調査の優先順位付けと解決策の有効性測定に役立ちます。

この値は多くの場合、問題レコード上の計算フィールドであり、リンクされたインシデントレコードの数をカウントします。

この属性は、恒久的な修正が開発されている間に、問題の影響を軽減するための一時的な解決策が利用可能になったかどうかを追跡します。これは問題管理ライフサイクルにおける重要なマイルストーンです。

これは「回避策の有効性と速度」ダッシュボードにとって極めて重要な属性です。プロセスマイニングは、回避策を提供するまでの平均時間を計算するために使用でき、その後の分析では、回避策の提供と新規関連インシデントの減少を相関させることができます。これにより、根本原因が修正される前であっても、サービスを迅速に復旧するチームの能力を測定するのに役立ちます。

サービスが一時的に復旧したかどうかを示し、チームがビジネスへの影響をどの程度迅速に軽減できるかを分析できます。

これは真偽値フラグ（「WorkaroundPublished」）であるか、回避策の詳細フィールドにテキストが存在することから導き出すことができます。

問題ステータスは、ワークフローにおける問題の現在の段階を示します。初期ログから最終解決まで、任意の時点における問題の状況のスナップショットを提供します。

アクティビティ名がステータス変更のイベントを捕捉する一方で、問題ステータス自体は現在のバックログを分析するのに役立ちます。これにより、各状態におけるオープンな問題の数を示すダッシュボードを作成でき、ワークロード管理や特定のフェーズに長期間停滞している記録の特定に役立ちます。

問題の現在の段階を示します。これは、バックログ分析や特定のフェーズで停滞している問題を特定するために不可欠です。

これは、問題がライフサイクルを通じて進むにつれて更新される、主要な問題レコードテーブルの標準フィールドです。

この属性は、いかなる時点においても問題を担当する特定の人物を特定します。サポートグループがチームを定義する一方、担当ユーザーは調査を処理する個々のエージェント、エンジニア、またはコーディネーターを指します。

担当ユーザー別に分析することで、個人の作業負荷、パフォーマンス、およびトレーニングの必要性を理解するのに役立ちます。これにより、特定の個人がボトルネックになっているか、チーム内で作業が均等に分配されていないかを浮き彫りにすることができます。この見方はサポートグループ分析を補完するものです。

個々のワークロードとパフォーマンスの分析を可能にし、優秀な従業員や追加のサポートまたはトレーニングが必要な従業員を特定するのに役立ちます。

このフィールドは通常、主要な問題レコードテーブルに見られ、多くの場合「担当者（Assignee）」、「割り当て先（Assigned To）」、または「調整者（Coordinator）」とラベル付けされています。

この属性は、問題管理プロセスと変更管理プロセスの間に直接的なリンクを作成します。これは、問題の根本原因を解決するために、コード変更、ハードウェア交換、またはその他の修正が必要な場合に使用されます。

このリンクを分析することは、「変更管理引き渡し遅延」を理解する上で重要です。プロセスマイニングは、根本原因が特定されてから変更リクエストが作成されるまでの時間、および変更が実装されてから問題が最終的にクローズされるまでの時間を測定できます。これにより、これら二つのプロセス間の相互作用における非効率性を特定するのに役立ちます。

問題と変更管理におけるその解決策をリンクし、引き継ぎの遅延とエンドツーエンドの解決ライフサイクルを分析可能にします。

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