問題管理データテンプレート
BMC Helix ITSM問題管理データテンプレート
- 根本原因分析に不可欠なデータフィールド
- 追跡のための標準化されたプロセス指標
- BMC Helix ITSM向けの具体的な抽出ガイド
問題管理属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
Activity
|
発生した特定のタスクまたはステータス変更イベント。 | ||
|
説明
この属性は、「問題レコードログ記録」、「根本原因特定」、「ソリューションデータベース更新」など、問題管理ライフサイクルで実行された特定のステップを表します。BMC Helixでは、これらは多くの場合、ステータス履歴、監査ログ、または問題調査モジュール内の特定のトランザクションタイムスタンプから導き出されます。\n\nこの属性はプロセスディスカバリの核となります。これらのアクティビティのシーケンスを分析することで、プロセスマイニングツールはプロセスマップを構築し、設計されたプロセスと比較して実際の作業フローを明らかにします。これにより、ループ、再作業、標準運用手順からの逸脱が浮き彫りになります。\n\n正確なアクティビティ名は、ライフサイクル中に実際に何が起こったかを理解するために不可欠です。このデータにより、根本原因の特定から変更リクエストの開始までの時間など、特定のステップ間の移行時間を測定できます。
その重要性
プロセスマップ内のノードを定義し、ワークフローの可視化を可能にします。
取得元
PBM:Problem Investigationのステータス履歴またはPBM:AuditLogSystemから派生。
例
問題レコードがログに記録されましたサポートグループに割り当て済み調査開始根本原因特定済み
|
|||
|
イベント日時
EventTime
|
特定のアクティビティが発生したタイムスタンプ。 | ||
|
説明
この属性は、アクティビティが行われた正確な日時を記録します。BMC Helix ITSMでは、これは「Submit Date」、「Last Modified Date」などのフィールド、またはステータス変更に対応する履歴テーブルに記録された特定のタイムスタンプに相当します。\n\n分析において、この属性はイベントを時系列に並べ、期間を計算するために使用されます。これにより、「調査サイクルタイム」や「回避策公開リードタイム」など、プロセス内の任意の2点間のサイクルタイムの測定が可能になります。\n\n正確なタイムスタンプはボトルネックを特定するために不可欠です。連続するイベント間の時間差を計算することで、アナリストは、それが初期のアサインメント中であろうと最終レビューフェーズであろうと、遅延がどこで発生しているかを正確に特定できます。
その重要性
すべての期間ベースKPIの計算とイベントのシーケンスを可能にします。
取得元
PBM:Problem Investigationに関連する履歴テーブルまたは監査ログ。
例
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
|
|||
|
問題レコード
ProblemRecord
|
問題調査ケースの一意の識別子。 | ||
|
説明
この属性は、問題管理プロセスの中央ケース識別子として機能します。BMC Helix ITSMでは、これは通常、PBM:Problem Investigationフォームにある「Problem ID」フィールド(例:PBI00000012345)です。これは、問題の初期ログ記録から最終的なクローズ、実装後レビューまでのすべての関連アクティビティをリンクします。\n\nプロセスマイニング分析において、この属性は個々のイベントを単一のプロセスインスタンスにグループ化するために使用されます。これにより、アナリストは特定の調査の最初から最後までのジャーニーを可視化できます。この識別子がないと、異なるサポートグループや調整担当者によって取られた一連のアクションを相関させることは不可能になります。\n\nこのフィールドはイベントログのプライマリキーとして機能し、問題ごとの総サイクルタイムの計算や優先度レベルごとの問題数のカウントなど、すべてのケースレベル集計に不可欠です。
その重要性
プロセスビューを構築し、特定の問題のライフサイクルを追跡するために必要な基本的なキーです。
取得元
PBM:Problem Investigation form, field 'Problem ID'
例
PBI00000004512PBI00000004513PBI00000004514
|
|||
|
ソースシステム
SourceSystem
|
データの発信元システム。 | ||
|
説明
この属性は、プロセスデータが抽出されたソフトウェアシステムを特定します。このケースでは「BMC Helix ITSM」です。これは、プロセスマイニングがさまざまなITSM、開発、または外部ベンダーツールからのデータを集約する可能性があるマルチシステム環境において特に重要です。\n\n分析において、このフィールドはレコードの出所を検証するメタデータタグとして機能します。プロセスマイニングビューが問題管理のためにBMC Helixからのデータと、ソフトウェア開発のための別のシステム(例:Jira)からのデータを組み合わせる場合、この属性は分析をツール起源別にセグメント化するのに役立ちます。\n\nまた、技術的なトラブルシューティングにも役立ちます。データ品質の問題が発生した場合、ソースシステムを知ることで、データエンジニアは問題を特定の抽出ルーチンまたはソースデータベースまで追跡できます。
その重要性
特に複数システムプロセスビューにおいて、追跡可能性とコンテキストを提供します。
取得元
抽出プロセス中にハードコードされます
例
`BMC Helix ITSM`Remedy OnDemandBMC ITSM本番
|
|||
|
最終データ更新
LastDataUpdate
|
データが抽出または最終更新されたときのタイムスタンプ。 | ||
|
説明
この属性は、データがプロセスマイニングアプリケーションに最後にロードされた時期を示します。これにより、アナリストは閲覧しているデータの鮮度を確実に把握できます。通常、抽出スクリプトまたはデータパイプラインツールによって生成されます。\n\n分析では、これにより古いデータに基づいた意思決定を防ぐのに役立ちます。例えば、マネージャーが「未解決の問題レコード」を見ている場合、データが1時間前に更新されたのか、1週間前に更新されたのかを知ることは、現在のワークロードの解釈を大きく変えます。\n\nまた、増分データロードにも使用されます。最終更新時間を追跡することで、ETLプロセスは前回の抽出以降に変更されたレコードのみを取得でき、パフォーマンスを最適化し、システム負荷を軽減します。
その重要性
データの鮮度を確保し、増分データロード戦略を支援します。
取得元
抽出時点のシステム時刻
例
2023-11-01T00:00:00Z2023-11-01T12:00:00Z
|
|||
|
`SLA`期日
SLADueDate
|
問題が解決されるべき目標日時。 | ||
|
説明
この属性には、サービスレベル契約に基づいた問題解決の期限が保持されます。BMC Helixでは、これはしばしば「Target Resolution Date」または計算されたSLAマイルストーンのタイムスタンプです。\n\nこの属性は、「SLAコンプライアンスと違反トレンド」ダッシュボードのベースラインとなります。このタイムスタンプと「解決策確認済み」アクティビティのタイムスタンプを比較することで、システムはSLAが達成されたか、または違反したかを計算します。\n\nこの日付を可視化することで、アナリストはチームがいかにギリギリで対応しているかを確認できます。彼らは問題を数日前に解決しているのか、それとも違反の数分前に常に完了しているのか。この洞察はキャパシティプランニングを推進します。
その重要性
すべてのコンプライアンスおよびタイムリー性メトリクスを計算するための参照点です。
取得元
PBM:Problem Investigation form, 'Target Resolution Date' field
例
2023-12-01T17:00:00Z2023-12-02T09:00:00Z
|
|||
|
`サポートグループ`
SupportGroup
|
現在、問題調査にアサインされている技術チーム。 | ||
|
説明
この属性は、イベント発生時に問題レコードを担当していた特定のサポートグループ(例:「サーバー管理者」、「データベースサポート」など)を反映します。BMC Helixでは、これは「Assigned Group」フィールドです。\n\nこの属性は、「サポートグループワークロード分散」および「サポートグループ再割り当て分析」ダッシュボードにとって非常に重要です。これにより、アナリストはプロセス全体をチーム別に切り分け、どのグループが最も多くの量を処理しているか、そして調査プロセスにおけるボトルネックはどこかを明らかにできます。\n\nサポートグループ間の引き継ぎを分析することは、解決策なしにチケットがチーム間をたらい回しされる「ピンポン」動作を特定するのに役立ちます。これは多くの場合、組織内の責任の不明確さや知識管理の不十分さを示唆しています。
その重要性
チームレベルでの組織分析とボトルネック検出を可能にします。
取得元
PBM:Problem Investigation form, field 'Assigned Group'
例
サービスデスクレベル1バックオフィスサポートネットワーク管理
|
|||
|
SLA違反
IsSLABreached
|
問題解決が許容時間を超過したかどうかを示すフラグ。 | ||
|
説明
このブール属性は、問題レコードがサービスレベル契約に違反したかどうかを示します。これは、「解決策確認済み」のタイムスタンプを「SLA期日」と比較するか、SLMステータスから直接抽出することによって計算されます。\n\nこの属性は、「SLAコンプライアンスと違反トレンド」ダッシュボードにとって重要です。これにより、プロセスを準拠と非準拠という単純な二値でセグメント化できます。これにより、失敗したプロセスの特性を簡単に分離できます(例:「違反したケースは常にサポートグループXが関与しているのか?」)。\n\nこれはプロセス障害の根本原因分析の主要なフィルターとして機能します。アナリストは「IsSLABreached = True」でフィルターし、プロセスマップを調べて時間の損失がどこで発生したか(例:ベンダー承認のための長い待機時間)を確認できます。
その重要性
コンプライアンスレポートと障害分析を簡素化します。
取得元
SLM:測定フォームまたは計算値
例
truefalse
|
|||
|
サービスCI
ServiceCI
|
影響を受ける主要なビジネスサービスまたは構成アイテム。 | ||
|
説明
この属性は、「メールサービス」、「SAP ERP」、「Wi-Fiネットワーク」など、問題に関連するサービス構成アイテム(CI)を特定します。BMC Helixでは、これはしばしば「Service+」フィールドまたは主要なCI関係です。\n\n分析では、これにより問題レコードを製品またはサービス別にセグメント化できます。どのサービスが最も脆弱で、最も多くの問題調査を引き起こしているかをITリーダーシップが理解するのに役立ちます。これは、製品ディメンションを追加することで「スループットと優先度ボリューム」ダッシュボードに反映されます。\n\nこの属性を「調査サイクルタイム」と相関させることで、特定の複雑なサービス(基幹銀行システムなど)が、汎用サービス(印刷など)と比較して本質的に長い調査期間を必要とするかどうかを示すことができます。
その重要性
プロセスパフォーマンスを特定のビジネス製品またはサービスにリンクします。
取得元
PBM:Problem Investigation form, field 'ServiceCI' or 'CI Name'
例
メールサービス給与システム社内VPN
|
|||
|
優先度
Priority
|
影響度と緊急度に基づいて計算された問題の優先度。 | ||
|
説明
この属性は、問題レコードの優先度レベル(例:緊急、高、中、低)を示します。BMC Helixでは、これは通常、影響度と緊急度の選択から導き出される計算フィールドです。\n\n分析では、これは「スループットと優先度ボリューム」ダッシュボードで使用されます。これにより、組織はリソースがビジネスニーズと適切に整合しているかを確認できます。例えば、「緊急」の問題は理論的に「低」優先度の問題と比較して、初期アサインメント時間が速く、全体のサイクルタイムが短いべきです。\n\n優先度でフィルタリングすることで、改善の取り組みを集中させるのに役立ちます。「低」優先度プロセスのボトルネックは許容されるかもしれませんが、「緊急」プロセスでの同じ遅延は、ビジネスの継続性とSLAコンプライアンスにとって重大なリスクとなります。
その重要性
ビジネスの重要度別に分析をセグメント化し、SLA分析をサポートします。
取得元
PBM:Problem Investigation form, field 'Priority'
例
クリティカル高中低
|
|||
|
問題調整担当者
ProblemCoordinator
|
調査の調整をアサインされた個々のユーザー。 | ||
|
説明
この属性は、問題レコードの責任者である特定の人物を指します。BMC Helix ITSMでは、これは「Problem Coordinator」フィールドです。この人物は、タスクが他の人に委任されたとしても、問題のライフサイクル全体を所有します。\n\nこの属性は、「サポートグループワークロード分散」ダッシュボードをサポートします。これにより、特定の個人が調査で過負荷になっている一方で、他の人が能力を持っているかどうかをマネージャーが特定するのに役立ちます。また、個々のレベルでのパフォーマンス分析も可能にし、トレーニングニーズや高業績者を特定するのに役立ちます。\n\nプロセスマイニングでは、このフィールドはリソース属性として機能します。個人間でどのように作業が流れるかを可視化し、プロセスが特定の専門家に過度に依存している単一障害点を浮き彫りにすることができます。
その重要性
個人レベルでのリソース分析とワークロードバランス調整を可能にします。
取得元
PBM:Problem Investigation form, field 'Problem Coordinator'
例
John DoeJane Smithシステム管理者
|
|||
|
根本原因カテゴリ
RootCauseCategory
|
問題の根本原因の分類。 | ||
|
説明
この属性には、根本原因が特定されたときに選択されたカテゴリ(例:「ソフトウェアエラー」、「ハードウェア障害」、「プロセスギャップ」など)が含まれます。BMC Helixでは、これは通常、「Root Cause」または「Generic Categorization」メニューから選択されます。\n\nこの属性は、「修正の有効性と品質」ビューにとって不可欠です。特定の種類の根本原因と再作業率や長い調査時間を関連付けることができます。例えば、「ソフトウェアエラー」の問題は「ハードウェア障害」の問題の2倍の解決時間を要することが常に示されるかもしれません。\n\nまた、「根本原因分類率」の計算にも使用されます。このフィールドに「不明」または「その他」の値が高い割合で含まれている場合、より良い技術トレーニングまたはより詳細な分類オプションの必要性を示唆しています。
その重要性
システム的な問題の傾向分析を可能にし、プロアクティブなプロブレム管理をサポートします。
取得元
PBM:問題調査フォームの「根本原因」または「分類」タブのフィールド
例
ソフトウェアモジュールネットワークインフラストラクチャヒューマンエラー
|
|||
|
調査ドライバー
InvestigationDriver
|
問題調査が開始された理由。 | ||
|
説明
この属性は、「インシデント量」、「重大インシデント」、「ベンダー通知」、「プロアクティブな傾向分析」など、問題レコードのトリガーを分類します。BMC Helixでは、これは「Investigation Driver」フィールドです。\n\nこの属性は、「プロアクティブ特定トレンド」ダッシュボードをサポートします。これにより、組織はリアクティブな応急処置(インシデント対応)からプロアクティブな問題管理(顕在化する前のリスク特定)への移行を測定できます。\n\n「Investigation Driver」別にプロセスフローを分析すると、異なる挙動が明らかになります。例えば、「プロアクティブ」な問題は即座の停止を引き起こさないためキューに長く留まる可能性がありますが、「重大インシデント」に起因する問題はプロセスを急いで進められます。
その重要性
リアクティブな作業とプロアクティブな作業を区別し、主要な成熟度指標となります。
取得元
PBM:Problem Investigation form, field 'Investigation Driver'
例
リアクティブプロアクティブ再発インシデント
|
|||
|
関連インシデント数
RelatedIncidentCount
|
この問題レコードにリンクされているインシデントの数。 | ||
|
説明
この属性は、問題に関連するインシデントの数をカウントすることで、問題の影響を定量化します。BMC Helixでは、これは通常、PBMレコードに関連するHPD:Help Deskフォームのレコード数です。\n\nこの属性は、「インシデント連携密度」KPIを推進します。高いカウントは、サービスデスクに大きな影響を与える高インパクトな問題を示します。これを「優先度」と関連付けることで、大量発生する問題が実際に緊急として扱われていることを保証します。\n\nまた、バックログの優先順位付けにも役立ちます。500件のリンクされたインシデントを持つ問題レコードは、1件のリンクされたインシデントしか持たない「緊急」問題よりも優先されるべきです。前者を解決する方が、より多くのサービスデスクキャパシティを解放できるためです。
その重要性
問題に関連する運用上の影響とユーザーの不満を定量化します。
取得元
HPD:AssociationsまたはHPD:Help Deskの関連する行を数えることで計算されます。
例
15120
|
|||
|
再割り当て回数
ReassignmentCount
|
サポートグループが変更された合計回数。 | ||
|
説明
この属性は、単一のケースに対して「サポートグループにアサイン済み」アクティビティが実行された回数をカウントします。これは、プロセスの摩擦とルーティング効率を直接測定するものです。\n\nこの属性は、「サポートグループ再割り当て分析」チャートにデータを提供します。高い値(たらい回し)は、初期トリアージが失敗しているか、複雑な問題に対する明確な所有権がないことを示します。これはサイクルタイム増加の先行指標となります。\n\nマネージャーはこれを使用してトレーニングの機会を特定します。サービスデスクが「データベース」の問題を常に最初に「ネットワーク」に再アサインし、その後「ネットワーク」が「データベース」に送り返す場合、再割り当て回数が急増し、より良い初期診断スクリプトの必要性を浮き彫りにします。
その重要性
プロセスにおける無駄、摩擦、オーナーシップの欠如を特定します。
取得元
アクティビティ履歴から計算
例
015
|
|||
|
回避策ステータス
WorkaroundStatus
|
有効な回避策が特定され、公開されたかどうかを示します。 | ||
|
説明
この属性は、一時的な解決策(回避策)の状態を追跡します。これは単純なブール値(回避策あり)である場合もあれば、ステータス文字列である場合もあります。BMC Helixでは、これはしばしば「Workaround」フィールドにテキストが存在するか、特定のステータスフラグから導き出されます。\n\nこの属性は、「回避策公開パフォーマンス」ダッシュボードの鍵となります。根本原因を調査しながら、チームがどれだけ効果的に影響を軽減しているかを明らかにします。「回避策なし」でフィルターされたプロセスビューは、調査中にビジネスが全面的に影響を受けているケースを強調表示します。\n\nまた、品質監査もサポートします。恒久的な修正(変更リクエスト)も回避策もないまま問題レコードをクローズすることは、一般的にレビューが必要なプロセス上の問題です。
その重要性
調査中の影響緩和の有効性を測定します。
取得元
PBM:問題調査フォームの「ワークアラウンド」フィールドの内容確認
例
アクティブなし廃止済み
|
|||
|
地域
Region
|
問題に関連する地理的地域。 | ||
|
説明
この属性は、問題が発生した、または管理されている地理的位置(例:「北米」、「EMEA」など)を指定します。BMC Helixでは、これはしばしばリクエスターまたは影響を受けるアセットに関連付けられた「Region」または「Site」フィールドに見られます。\n\n分析において、これは地理的セグメンテーションをサポートします。特定の地域で問題の量が多いか、解決時間が遅いかを特定するのに役立ちます。これにより、異なる場所間でのサポート人員配置やインフラストラクチャ品質の不均衡が浮き彫りになります。\n\nこれはグローバル組織が一貫したサービス提供を確保するために価値があります。「APAC」の「調査サイクルタイム」が「NAM」の2倍である場合、その地域のリソース配分またはプロセス遵守について調査を促します。
その重要性
プロセスパフォーマンスの地理的比較を可能にします。
取得元
PBM:Problem Investigation form, 'Region' field
例
アメリカ大陸EMEAAPAC
|
|||
|
調査サイクルタイム
InvestigationCycleTime
|
調査開始から根本原因特定までの期間。 | ||
|
説明
これは、「調査開始」アクティビティと「根本原因特定済み」アクティビティ間の時間を測定する計算期間属性です。これは、問題管理プロセスにおけるコアとなる付加価値時間を示します。\n\nこのメトリックは「根本原因調査サイクルタイム」ダッシュボードに反映されます。これにより、マネージャーは問題の技術的複雑性と調査チームの効率を理解するのに役立ちます。ここでの異常(例:極端に短い時間)は推測を示している可能性があり、極端に長い時間は調査の停滞を示しています。\n\nこのメトリックを「サポートグループ」と「優先度」全体で比較することで、組織は問題をより迅速に診断するためにどのチームがより良いツール、トレーニング、またはベンダーサポートを必要としているかを特定できます。
その重要性
技術調査フェーズにおける主要な効率性指標です。
取得元
アクティビティのタイムスタンプから計算
例
4500000120000
|
|||
|
関連変更リクエストID
RelatedChangeRequestId
|
問題を修正するために開始された変更リクエストの識別子。 | ||
|
説明
この属性には、問題レコードにリンクされた変更リクエストのID(例:CRQ0000...)が含まれます。これは、調査から恒久的な修正の実装への移行を表します。\n\nこの属性は、「根本原因から変更へのリードタイム」KPIに必要です。プロセスマイニングツールが、根本原因の発見から変更プロセスの開始までの遅延を測定することを可能にします。これは勢いが失われやすい一般的な引き渡し点です。\n\nまた、「プロセスの完全性」の検証にも役立ちます。「完了」ステータスでクローズされた問題レコードであっても、関連する変更リクエスト(または回避策)がない場合、根本原因が特定されたにもかかわらず実際に修正されなかったプロセス違反を示している可能性があります。
その重要性
プロブレム管理プロセスと変更管理プロセスをリンクします。
取得元
PBM:調査関連付けまたは関連タブ
例
CRQ00000021345CRQ00000021346
|
|||
問題管理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
サポートグループに割り当て済み
|
問題レコードを特定の技術チームにアサインすること。「Assigned Group」フィールドの変更を監視することで捕捉されます。 | ||
|
その重要性
ハンドオフ、ピンポン効果、および「初回割り当てまでの平均時間」KPIの測定に不可欠です。
取得元
PBM:Problem Investigationフォーム、「Assigned Group」フィールド履歴または監査ログ。
取得
更新前後の「Assigned Group」フィールドを比較
イベントタイプ
inferred
|
|||
|
問題レコードがキャンセルされました
|
解決前の問題レコードの終了。ステータスが「Cancelled」または「Rejected」になったときに捕捉されます。 | ||
|
その重要性
無駄な労力または有効な重複を特定します。代替の終了点を示します。
取得元
PBM:Problem Investigation form, 'Status' field = 'Cancelled' or 'Rejected'.
取得
キャンセル済みへの移行についてステータスフィールドを比較
イベントタイプ
inferred
|
|||
|
問題レコードがクローズされました
|
問題レコードの最終的な管理上のクローズ。このイベントはプロセスインスタンスを終了させます。 | ||
|
その重要性
標準的な終了イベント。フルサイクルタイム分析および「インシデント連携密度」の計算に必要です。
取得元
PBM:Problem Investigation form, 'Status' field = 'Closed'.
取得
クローズ済みへの移行についてステータスフィールドを比較
イベントタイプ
inferred
|
|||
|
問題レコードがログに記録されました
|
システムでの問題調査レコードの初期作成。このイベントは、PBM:Problem Investigationフォームに新しいエントリが保存されたときに明示的に捕捉されます。 | ||
|
その重要性
プロセスインスタンスの開始を示します。全体的なサイクルタイムと初期応答メトリクスを計算するために不可欠です。
取得元
PBM:問題調査フォームの「提出日」タイムスタンプ、または「ステータス」=「下書き」の作成ログ
取得
PBM:Problem Investigationレコードが作成されたときにログに記録されます。
イベントタイプ
explicit
|
|||
|
回避策定義済み
|
問題レコードの「Workaround」フィールドへのテキストの入力または更新。このイベントは、一時的な解決策が文書化されたことを示します。 | ||
|
その重要性
「回避策公開リードタイム」KPIをサポートします。インシデントの影響軽減を示します。
取得元
PBM:Problem Investigation form, changes to the 'Workaround' text field.
取得
Null以外の更新について「Workaround」フィールドの内容を比較
イベントタイプ
inferred
|
|||
|
変更リクエスト開始
|
問題調査へのインフラストラクチャ変更リクエストのリンク。これは実装フェーズの開始を示します。 | ||
|
その重要性
「根本原因から変更までのリードタイム」KPIにとって重要であり、プロブレムプロセスと変更プロセスの間のサイロを特定するのに役立ちます。
取得元
PBM:Investigation_Associationsテーブルまたは「Infrastructure Change ID」フィールドのデータ入力。
取得
PBM:Investigation_Associationsで関連付けが作成されたときにログに記録されます。
イベントタイプ
explicit
|
|||
|
根本原因特定済み
|
問題レコードが原因が既知であることを示す状態に遷移する時点。ステータスが「Root Cause Identified」に変更されたときに推測されます。 | ||
|
その重要性
「根本原因調査サイクルタイム」ダッシュボードにとって重要なマイルストーン。分析から解決策の策定への移行を示します。
取得元
PBM:Problem Investigation form, 'Status' field = 'Root Cause Identified'.
取得
根本原因特定済みへの移行についてステータスフィールドを比較
イベントタイプ
inferred
|
|||
|
解決策確認済み
|
恒久的な修正が成功したと確認される時点。ステータスが「Solution Implemented」または「Completed」に変更されたときに推測されます。 | ||
|
その重要性
「問題SLA遵守率」に使用されます。技術作業の完了を確認します。
取得元
PBM:Problem Investigation form, 'Status' field = 'Solution Implemented' or 'Completed'.
取得
ソリューション実装済みへの移行についてステータスフィールドを比較
イベントタイプ
inferred
|
|||
|
調査開始
|
問題レコードがアクティブな分析フェーズに移行すること。これはステータスフィールドが「Under Investigation」に変更されたときに推測されます。 | ||
|
その重要性
実際の作業フェーズの開始を示し、「調査サイクルタイム」KPIをサポートします。
取得元
PBM:Problem Investigation form, 'Status' field = 'Under Investigation'.
取得
調査中への移行についてステータスフィールドを比較
イベントタイプ
inferred
|
|||
|
コーディネーター再割り当て
|
サポートグループ内の個々のプロブレムコーディネーターの変更。「Problem Coordinator」フィールドを監視することで捕捉されます。 | ||
|
その重要性
ワークロードの配分と個々のリソースボトルネックの分析に役立ちます。
取得元
PBM:Problem Investigationフォーム、「Problem Coordinator」フィールド履歴。
取得
更新前後の「Problem Coordinator」フィールドを比較
イベントタイプ
inferred
|
|||
|
ソリューションデータベースが更新されました
|
レコードが「Solution Database」ステータスに移行すること。これは恒久的な修正が提案または特定されたことを示します。 | ||
|
その重要性
実装前の解決策定義の進捗を追跡します。
取得元
PBM:Problem Investigation form, 'Status' field = 'Solution Database'.
取得
ソリューションデータベースへの移行についてステータスフィールドを比較
イベントタイプ
inferred
|
|||
|
実装後レビュー実施済み
|
PIRフェーズの完了。PIR状態からのステータス遷移、またはリンクされたPIRタスクのクローズによって捕捉されます。 | ||
|
その重要性
「導入後レビュー遵守」とプロセス品質監査を直接サポートします。
取得元
PBM:問題調査フォームの特定のフラグ「PIRが必要」、または関連するタスクタイプ「PIR」の完了
取得
PIRステータスの完了またはPIRタスクのクローズから派生。
イベントタイプ
inferred
|
|||
|
既知のエラー昇格済み
|
問題調査にリンクされた既知のエラーレコードの作成。これは関連レコード作成イベントです。 | ||
|
その重要性
問題がより広範なコミュニケーションと長期的な追跡のために正式化されたことを示します。
取得元
PBM:Problem Investigation IDにリンクされたPBM:Known Errorでのレコード作成。
取得
PBM:Known Errorレコードが作成されたときにログに記録されます。
イベントタイプ
explicit
|
|||