> 継続的なプロセス改善 > 問題管理 > BMC Helix ITSM > データテンプレート

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

BMC Helix ITSM

問題管理の属性(19) 問題管理のアクティビティ(13) データ抽出ガイド(3)

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

このテンプレートでは、BMC Helix ITSMの根本原因調査ワークフローを分析するための構成を紹介します。詳細なイベントログの作成に必要な属性とプロセスアクティビティに加え、データの抽出方法も説明します。このガイドに沿って分析することで、見えにくいボトルネックを特定し、インシデントの恒久的な解決までの流れを効率化できます。

根本原因分析に必要なデータ項目
追跡対象となる標準的なプロセスの節目
BMC Helix ITSMからのデータ抽出手順

イベントログを初めて作成する方はこちら：プロセスマイニング用イベントログの作成方法.

テンプレートをダウンロード

問題管理の属性

この表には、問題管理のライフサイクルを詳しく分析するために、イベントログへ取り込むことを推奨するデータ項目をまとめています。

5 必須 9 推奨 5 任意

	名前	説明
	アクティビティ Activity	実行された特定のタスク、または発生したステータス変更イベントです。
説明この属性は、問題レコードの登録、根本原因の特定、ソリューションデータベースの更新など、問題管理のライフサイクルで実行された具体的なステップを表します。BMC Helixでは、Problem Investigationモジュールのステータス履歴、監査ログ、または個別のトランザクションのタイムスタンプから取得することがよくあります。この属性は、プロセスの発見における中核です。アクティビティの順序を分析すると、プロセスマイニングツールがプロセスマップを作成し、設計されたプロセスと実際の業務の流れを比較できます。ループや手戻り、標準手順からの逸脱も明らかになります。ライフサイクルで実際に何が起きたかを理解するには、正確なアクティビティ名が欠かせません。このデータを使うと、根本原因の特定から変更要求の開始までにかかった時間など、特定のステップ間の移行時間を測定できます。重要な理由プロセスマップのノードを定義し、ワークフローを可視化できます。入手先 PBM:Problem Investigationのステータス履歴またはPBM:AuditLogSystemから取得例問題レコードの登録サポートグループへの割り当て調査開始根本原因の特定
	イベント時刻 EventTime	特定のアクティビティが発生した時刻です。
説明この属性には、アクティビティが発生した正確な日時が記録されます。BMC Helix ITSMでは、「Submit Date」や「Last Modified Date」などのフィールド、またはステータス変更に対応する履歴テーブルの個別のタイムスタンプが該当します。分析では、この属性を使ってイベントを時系列に並べ、所要時間を算出します。調査サイクルタイムや回避策の公開リードタイムなど、プロセス内の任意の2地点間のサイクルタイムを測定できます。ボトルネックの特定には、正確なタイムスタンプが欠かせません。連続するイベント間の時間差を算出することで、初期の割り当て時か最終レビュー段階かを問わず、遅延が発生している箇所を正確に特定できます。重要な理由所要時間に基づくすべてのKPIの算出と、イベントの順序付けに役立ちます。入手先 PBM:Problem Investigationに関連する履歴テーブルまたは監査ログ例 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
	問題レコード ProblemRecord	問題調査ケースを一意に識別するIDです。
説明この属性は、問題管理プロセスにおけるケースの中心的な識別子です。BMC Helix ITSMでは通常、PBM:Problem Investigationフォームの「Problem ID」フィールドが該当します（例：PBI00000012345）。問題の初回記録から最終的なクローズ、実装後レビューまで、関連するすべてのアクティビティを結び付けます。プロセスマイニング分析では、この属性を使って個々のイベントを1つのプロセスインスタンスにまとめます。これにより、特定の問題調査の開始から終了までの流れを可視化できます。この識別子がなければ、異なるサポートグループやコーディネーターが行った一連の作業を関連付けることはできません。このフィールドはイベントログの主キーとして機能し、問題ごとの総サイクルタイムの算出や、優先度別の問題件数の集計など、ケース単位のすべての集計に欠かせません。重要な理由プロセスのビューを作成し、個々の問題のライフサイクルを追跡するために必要な基本のキーです。入手先 PBM:Problem Investigationフォームの「Problem ID」フィールド例 PBI00000004512PBI00000004513PBI00000004514
	ソースシステム SourceSystem	データの取得元となるシステムです。
説明この属性は、プロセスデータの抽出元となったソフトウェアシステムを示します。ここでは「BMC Helix ITSM」です。複数のシステムを使う環境では、プロセスマイニングで複数のITSM、開発、外部ベンダーのツールからデータを集約する場合があるため、特に重要です。分析では、このフィールドをメタデータタグとして使い、レコードの取得元を確認します。問題管理にはBMC Helix、ソフトウェア開発には別のシステム（例：Jira）のデータを使ってプロセスを分析する場合、この属性によってツールごとに分析対象を分けられます。技術的な問題の調査にも役立ちます。データ品質に問題が生じた場合、ソースシステムがわかれば、データエンジニアは該当する抽出処理やソースデータベースまで原因をたどれます。重要な理由特に複数のシステムにまたがるプロセスビューで、データの追跡可能性とコンテキストを確保できます。入手先抽出処理中に固定値を設定例 BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
	最終データ更新日時 LastDataUpdate	データを抽出または最終更新した時刻です。
説明この属性は、プロセスマイニングアプリケーションにデータが最後に読み込まれた日時を示します。分析担当者は、表示しているデータがどの時点のものかを確認できます。通常、抽出スクリプトまたはデータパイプラインツールによって記録されます。分析では、古いデータに基づく判断を防ぐのに役立ちます。たとえば、管理者が未解決の問題レコードを確認する際、データが1時間前に更新されたのか、1週間前に更新されたのかによって、現在の作業負荷の捉え方は大きく変わります。増分データ読み込みにも使用します。最終更新時刻を追跡することで、ETL処理は前回の抽出以降に変更されたレコードだけを取得でき、処理性能を高めてシステム負荷を抑えられます。重要な理由データの鮮度を保ち、増分データ読み込みの方針を立てるのに役立ちます。入手先抽出時点のシステム時刻例 2023-11-01T00:00:00Z2023-11-01T12:00:00Z
	SLA期限 SLADueDate	問題を解決する期限となる日時です。
説明この属性には、サービスレベル契約に基づく問題解決の期限が記録されます。BMC Helixでは、「Target Resolution Date」または計算されたSLAマイルストーンのタイムスタンプとして記録されていることがよくあります。この属性は、「SLA遵守状況と違反傾向」ダッシュボードの基準になります。このタイムスタンプと「解決確認」アクティビティのタイムスタンプを比較し、SLAが守られたか、違反したかを判定します。この日付を可視化すると、チームが期限にどれほど余裕を持って対応しているかを確認できます。数日前に問題を解決しているのか、それとも違反の数分前にようやく完了する状況が続いているのかを把握でき、キャパシティ計画に役立ちます。重要な理由コンプライアンスと期限遵守に関するすべての指標を算出する基準です。入手先 PBM：Problem Investigationフォームの「Target Resolution Date」フィールド例 2023-12-01T17:00:00Z2023-12-02T09:00:00Z
	SLA違反の有無 IsSLABreached	問題の解決に許容時間を超えたかを示すフラグです。
説明この真偽値属性は、問題レコードがサービスレベル契約に違反したかを示します。「解決確認」のタイムスタンプと「SLA期限」を比較して算出するか、SLMのステータスから直接取得します。この属性は「SLA遵守状況と違反傾向」ダッシュボードで重要な役割を果たします。プロセスを「遵守」と「未遵守」に分けて確認できるため、問題が発生したプロセスの特徴（例：「SLA違反のケースには、必ずサポートグループXが関わっているか」）を簡単に調べられます。プロセス上の問題の根本原因を分析する際の主要なフィルターとしても使えます。「IsSLABreached = True」で絞り込み、プロセスマップを確認すると、ベンダーの承認待ちが長いなど、どの段階で時間がかかったかを把握できます。重要な理由コンプライアンスの報告と問題分析を簡潔に行えます。入手先 SLM:Measurementフォームから取得、または計算例 truefalse
	サービス構成アイテム ServiceCI	影響を受けた主要な業務サービスまたは構成アイテムです。
説明この属性は、問題に関連するサービス構成アイテム（CI）を示します。例として、「メールサービス」「SAP ERP」「Wi-Fiネットワーク」などがあります。BMC Helixでは、「Service+」フィールドまたは主要なCIとの関連付けに該当することがよくあります。分析では、製品やサービスごとに問題レコードを分類できます。IT部門の責任者は、どのサービスに問題が起きやすく、問題調査が多く発生しているかを把握できます。製品の切り口を加えることで、「処理量と優先度別件数」ダッシュボードにも役立ちます。この属性と「調査サイクルタイム」を関連付けると、基幹銀行システムのような複雑なサービスでは、印刷のような一般的なサービスよりも調査に時間がかかるかどうかを確認できます。重要な理由プロセスのパフォーマンスを特定の業務製品やサービスに関連付けられます。入手先 PBM:Problem Investigationフォームの「ServiceCI」または「CI Name」フィールド例メールサービス給与システム社内VPN
	サポートグループ SupportGroup	問題調査を現在担当している技術チームです。
説明この属性は、イベント発生時に問題レコードを担当していたサポートグループ（例：「サーバー管理」「データベースサポート」）を示します。BMC Helixでは「Assigned Group」フィールドに該当します。この属性は、「サポートグループの作業負荷分布」や「サポートグループの再割り当て分析」ダッシュボードで重要です。チーム別にプロセスマップを分析できるため、どのグループが多くの案件を処理しているか、調査プロセスのどこにボトルネックがあるかを把握できます。サポートグループ間の引き継ぎを分析すると、解決に至らないままチケットがチーム間を行き来する「たらい回し」を特定できます。多くの場合、これは組織内の責任範囲が不明確であることや、ナレッジ管理が不十分であることを示しています。重要な理由組織単位の分析や、チームレベルでのボトルネックの特定に役立ちます。入手先 PBM:Problem Investigationフォームの「Assigned Group」フィールド例サービスデスクレベル1バックオフィスサポートネットワーク管理
	優先度 Priority	影響度と緊急度に基づいて算出された問題の優先度です。
説明この属性は、問題レコードの優先度（例：重大、高、中、低）を示します。BMC Helixでは通常、「Impact」と「Urgency」の選択内容から算出されます。分析では、「処理量と優先度別件数」ダッシュボードに使用します。組織は、リソースが業務上のニーズに適切に割り当てられているかを確認できます。たとえば、重大な問題は、優先度の低い問題よりも初回割り当てまでの時間が短く、全体のサイクルタイムも短いことが期待されます。優先度で絞り込むと、改善の取り組みを重点化できます。優先度の低いプロセスにボトルネックがあっても許容できる場合がありますが、重大なプロセスで同じ遅延が発生すれば、事業継続やSLA遵守に大きなリスクをもたらします。重要な理由業務上の重要度に応じて分析対象を分け、SLA分析に役立てられます。入手先 PBM:Problem Investigationフォームの「Priority」フィールド例重大高中低
	問題コーディネーター ProblemCoordinator	調査の調整を担当する個人ユーザーです。
説明この属性は、問題レコードの担当者を示します。BMC Helix ITSMでは「Problem Coordinator」フィールドに該当します。ほかの担当者にタスクを委任した場合も、この担当者が問題のライフサイクルを管理します。この属性は、「サポートグループの作業負荷分布」ダッシュボードに役立ちます。特定の担当者に調査が集中していないか、ほかの担当者に余力があるかを管理者が確認できます。また、個人単位のパフォーマンス分析を通じて、研修の必要性や高い成果を上げている担当者を把握できます。プロセスマイニングでは、このフィールドをリソース属性として扱います。担当者間で作業がどのように進むかを可視化し、特定の専門家に過度に依存することでプロセス全体が止まるリスクのある箇所を明らかにできます。重要な理由個人単位のリソース分析と作業負荷の調整に役立ちます。入手先 PBM:Problem Investigationフォームの「Problem Coordinator」フィールド例 John DoeJane Smithシステム管理者
	根本原因のカテゴリ RootCauseCategory	問題の根本原因の分類です。
説明この属性には、根本原因の特定時に選択されたカテゴリ（例：「ソフトウェアエラー」「ハードウェア障害」「プロセスの不備」）が含まれます。BMC Helixでは通常、「Root Cause」または「Generic Categorization」のメニューから選択します。この属性は、「修正の有効性と品質」のビューに欠かせません。根本原因の種類と手戻り率や調査期間の長さを関連付けて分析できます。たとえば、「ソフトウェアエラー」の問題は「ハードウェア障害」の問題よりも、解決までに一貫して2倍の時間がかかることがわかる場合があります。「根本原因の分類率」の算出にも使用します。このフィールドに「不明」や「その他」が多い場合は、技術研修の充実や、より詳細な分類項目の追加が必要であることを示しています。重要な理由システム上の問題の傾向分析や、予防的な問題管理に役立ちます。入手先 PBM:Problem Investigationフォームの「Root Cause」フィールドまたは分類タブのフィールド例ソフトウェアモジュールネットワークインフラストラクチャ人的ミス
	調査のきっかけ InvestigationDriver	問題調査が開始された理由です。
説明この属性は、問題レコードが作成されたきっかけを分類します。例として、「インシデント件数」「重大インシデント」「ベンダーからの通知」「予防的な傾向分析」などがあります。BMC Helixでは「Investigation Driver」フィールドに該当します。この属性は、「予防的な問題特定の傾向」ダッシュボードに役立ちます。インシデントへの対応に追われる事後対応型の運用から、リスクが顕在化する前に特定する予防的な問題管理へ、どの程度移行できているかを測定できます。「調査のきっかけ」別にプロセスの流れを分析すると、対応の違いがわかります。たとえば、予防的に特定された問題は、直ちにサービス停止を引き起こさないため、キューに長くとどまる場合があります。一方、重大インシデントがきっかけとなった問題は、プロセスを急いで進める傾向があります。重要な理由事後対応型と予防型の作業を区別でき、プロセスの成熟度を測る重要な指標になります。入手先 PBM:Problem Investigationフォームの「Investigation Driver」フィールド例リアクティブプロアクティブ繰り返し発生するインシデント
	関連インシデント数 RelatedIncidentCount	この問題レコードに関連付けられたインシデントの件数です。
説明この属性は、問題に関連付けられたインシデントの件数を数え、問題の影響度を示します。BMC Helixでは通常、PBMレコードに関連するHPD:Help Deskフォームのレコード数を表します。この属性は「インシデント関連度」KPIに使われます。件数が多い場合、サービスデスクに大きな負荷をもたらしている、影響度の高い問題であることを示します。「優先度」と照らし合わせることで、件数の多い問題が実際に重大な問題として扱われているかを確認できます。未処理の問題の優先順位付けにも役立ちます。関連インシデントが500件ある問題レコードは、関連インシデントが1件だけの「重大」な問題より優先すべき場合があります。前者を解決すれば、サービスデスクの対応余力をより大きく確保できるためです。重要な理由問題が業務に与える影響と、ユーザーへの負担を数値で把握できます。入手先 HPD:AssociationsまたはHPD:Help Deskの関連行を数えて算出例 15120
	再割り当て回数 ReassignmentCount	サポートグループが変更された回数の合計です。
説明この属性は、1つのケースで「サポートグループへの割り当て」アクティビティが発生した回数を数えます。プロセスの停滞や振り分けの効率を直接示します。この属性は「サポートグループ再割り当て分析」チャートに反映されます。値が大きい場合、担当間で案件が行き来していることを示し、初期トリアージが機能していない、または複雑な問題の担当が明確でない可能性があります。サイクルタイムが長くなる前兆にもなります。管理者は、トレーニングの必要性を特定するためにこの指標を使います。たとえば、サービスデスクが「データベース」の問題をまず「ネットワーク」に再割り当てし、その後「ネットワーク」から「データベース」に戻している状況が続くと、再割り当て回数が増加します。これにより、初期診断の手順を見直す必要性が明らかになります。重要な理由プロセスにおける無駄や停滞、担当の不明確さを特定できます。入手先アクティビティ履歴から算出例 015
	回避策のステータス WorkaroundStatus	有効な回避策が特定され、公開されているかを示します。
説明この属性は、一時的な解決策（回避策）の状態を記録します。「回避策あり」のような真偽値、またはステータス文字列で表されます。BMC Helixでは、「Workaround」フィールドにテキストが入力されているか、特定のステータスフラグが設定されているかをもとに判定されることがよくあります。この属性は「回避策の公開状況」ダッシュボードの要となります。根本原因を調査している間、チームがどの程度効果的に影響を抑えているかを確認できます。「回避策なし」でプロセスを絞り込むと、調査中に業務が問題の影響を全面的に受けているケースを特定できます。品質監査にも役立ちます。恒久対策（変更要求）も回避策もないまま問題レコードをクローズすることは、通常、見直しが必要なプロセス上の不備です。重要な理由調査中に問題の影響をどれだけ抑えられているかを測定します。入手先 PBM：Problem Investigationフォームの「Workaround」フィールドの内容を確認例アクティブなし廃止
	地域 Region	問題に関連する地理的な地域です。
説明この属性は、問題が発生した、または管理されている地理的な場所（例：「北米」「EMEA」）を示します。BMC Helixでは、依頼者または影響を受けた資産に関連付けられた「地域」や「サイト」のフィールドに記録されていることがよくあります。分析では、地域ごとの比較に利用できます。特定の地域で問題の件数が多い、または解決に時間がかかっているかを把握し、各地域のサポート要員やインフラの品質に差がないかを確認できます。グローバルに事業を展開する組織が、サービスを一貫して提供するうえで役立ちます。「APAC」の「調査サイクルタイム」が「NAM」の2倍であれば、その地域のリソース配分やプロセスの遵守状況を調べるきっかけになります。重要な理由地域ごとにプロセスのパフォーマンスを比較できます。入手先 PBM：Problem Investigationフォームの「Region」フィールド例南北アメリカEMEAAPAC
	調査サイクルタイム InvestigationCycleTime	調査開始から根本原因の特定までにかかる時間です。
説明「調査開始」アクティビティから「根本原因特定」アクティビティまでの時間を測定する、計算された期間属性です。問題管理プロセスで価値を生み出す中心的な時間を表します。この指標は「根本原因調査サイクルタイム」ダッシュボードに反映されます。問題の技術的な複雑さや、調査チームの対応効率を把握するのに役立ちます。極端に短い時間は推測による判断を、極端に長い時間は調査の停滞を示している可能性があります。この指標を「サポートグループ」や「優先度」ごとに比較すると、問題をより早く診断するために、ツールやトレーニング、ベンダーの支援が必要なチームを特定できます。重要な理由技術調査の段階における主要な効率指標です。入手先アクティビティのタイムスタンプから算出例 4500000120000
	関連する変更要求ID RelatedChangeRequestId	問題の修正のために起票された変更要求の識別子です。
説明この属性には、問題レコードに関連付けられた変更要求のID（例：CRQ0000...）が記録されます。調査から恒久対策の実施へ移る段階を示します。この属性は「根本原因特定から変更着手までのリードタイム」KPIに必要です。根本原因の特定から変更プロセスの開始までにかかった時間を、プロセスマイニングツールで測定できます。この引き継ぎの段階では、対応の勢いが失われることがよくあります。また、プロセスが完了しているかの確認にも役立ちます。「完了」ステータスでクローズされた問題レコードに、関連する変更要求も回避策もない場合、根本原因は特定されたものの実際には修正されていないという、プロセス上の問題が考えられます。重要な理由問題管理プロセスと変更管理プロセスを関連付けます。入手先 PBM：Investigation AssociationsまたはRelationshipタブ例 CRQ00000021345CRQ00000021346

必須推奨任意

問題管理のアクティビティ

調査から解決までの各段階を把握するために追跡する、基本的なプロセスの手順とステータスの変更です。

9 推奨 4 任意

	アクティビティ	説明
	サポートグループへの割り当て	問題レコードを特定の技術チームに割り当てることです。「Assigned Group」フィールドの変更を監視して記録します。
重要な理由引き継ぎやたらい回しの状況、「初回割り当てまでの平均時間」KPIの測定に欠かせません。入手先 PBM:Problem Investigationフォームの「Assigned Group」フィールドの変更履歴または監査ログ。記録更新前後の「Assigned Group」フィールドを比較イベントタイプ inferred
	問題レコードのキャンセル	解決前に問題レコードが終了したことです。「Status」が「Cancelled」または「Rejected」になった際に記録されます。
重要な理由無駄な作業や妥当な重複を特定します。通常とは異なる終了地点を示します。入手先 PBM:Problem Investigationフォームの「Status」フィールド＝「Cancelled」または「Rejected」。記録「Cancelled」への移行をステータスフィールドで確認イベントタイプ inferred
	問題レコードのクローズ	問題レコードの最終的な事務処理上のクローズです。このイベントでプロセスインスタンスが終了します。
重要な理由標準の終了イベントです。サイクルタイム全体の分析と「インシデント関連付け密度」の算出に必要です。入手先 PBM:Problem Investigationフォームの「Status」フィールド＝「Closed」。記録「Closed」への移行をステータスフィールドで確認イベントタイプ inferred
	問題レコードの登録	システムで問題調査レコードを新規作成することです。PBM:Problem Investigationフォームに新しいレコードを保存した際に、このイベントが明示的に記録されます。
重要な理由プロセスインスタンスの開始を示します。全体のサイクルタイムや初期応答指標の算出に欠かせません。入手先 PBM:Problem Investigationフォームの「Submit Date」タイムスタンプ、または「Status」＝「Draft」の作成ログ。記録 PBM:Problem Investigationレコードの作成時に記録イベントタイプ explicit
	回避策の定義	問題レコードの「Workaround」フィールドにテキストを入力または更新することです。一時的な解決策が文書化されたことを示します。
重要な理由「回避策の公開リードタイム」KPIの測定に役立ち、インシデントの影響を軽減したことを示します。入手先 PBM:Problem Investigationフォームの「Workaround」テキストフィールドの変更。記録「Workaround」フィールドに空でない値が更新されたかを確認イベントタイプ inferred
	変更要求の開始	Infrastructure Change RequestをProblem Investigationに関連付けることです。実装段階の開始を示します。
重要な理由「根本原因特定から変更までのリードタイム」KPIの測定や、問題管理と変更管理のプロセス間にある分断の特定に欠かせません。入手先 PBM:Investigation_Associationsテーブル、または「Infrastructure Change ID」フィールドへの値の入力。記録 PBM:Investigation_Associationsで関連付けを作成した際に記録イベントタイプ explicit
	根本原因の特定	問題レコードが、原因が判明したことを示す状態に移行した時点です。「Status」が「Root Cause Identified」に変わった時点で推定します。
重要な理由「根本原因調査サイクルタイム」ダッシュボードの重要なマイルストーンです。分析から解決策の検討への移行を示します。入手先 PBM:Problem Investigationフォームの「Status」フィールド＝「Root Cause Identified」。記録「Root Cause Identified」への移行をステータスフィールドで確認イベントタイプ inferred
	解決の検証	恒久的な修正が成功したと確認された時点です。「Status」が「Solution Implemented」または「Completed」に変わったことから推定します。
重要な理由「問題のSLA遵守率」の算出に使用します。技術的な作業が完了したことを確認できます。入手先 PBM:Problem Investigationフォームの「Status」フィールド＝「Solution Implemented」または「Completed」。記録「Solution Implemented」への移行をステータスフィールドで確認イベントタイプ inferred
	調査開始	問題レコードがアクティブな分析段階に移行することです。「Status」フィールドが「Under Investigation」に変わった時点で推定します。
重要な理由実作業の開始を示し、「調査サイクルタイム」KPIの測定に役立ちます。入手先 PBM:Problem Investigationフォームの「Status」フィールド＝「Under Investigation」。記録「Under Investigation」への移行をステータスフィールドで確認イベントタイプ inferred
	コーディネーターの再割り当て	サポートグループ内のProblem Coordinatorが変更されたことです。「Problem Coordinator」フィールドを監視して記録します。
重要な理由作業負荷の分布や、個人単位のリソースのボトルネックを分析できます。入手先 PBM:Problem Investigationフォームの「Problem Coordinator」フィールドの変更履歴。記録更新前後の「Problem Coordinator」フィールドを比較イベントタイプ inferred
	ソリューションデータベースの更新	レコードが「Solution Database」ステータスに移行したことです。恒久的な修正が提案または特定されたことを示します。
重要な理由実装前の解決策の定義状況を追跡します。入手先 PBM:Problem Investigationフォームの「Status」フィールド＝「Solution Database」。記録「Solution Database」への移行をステータスフィールドで確認イベントタイプ inferred
	実装後レビューの実施	PIR段階の完了です。PIR状態からのステータス変更、または関連するPIR Taskのクローズによって記録されます。
重要な理由「実装後レビューのコンプライアンス」やプロセス品質監査に直接役立ちます。入手先 PBM:Problem Investigationフォームの「PIR Required」フラグ、または関連する「PIR」タイプのTaskの完了。記録 PIRステータスの完了またはPIR Taskのクローズから算出イベントタイプ inferred
	既知エラーへの登録	問題調査に関連付けられた既知エラーレコードの作成です。関連レコードの作成イベントとして記録されます。
重要な理由問題を正式に記録し、広く共有して長期的に追跡することを示します。入手先 PBM:Problem Investigation IDに関連付けられたPBM:Known Errorレコードの作成。記録 PBM:Known Errorレコードの作成時に記録イベントタイプ explicit

推奨任意

データ抽出ガイド

BMC Helix ITSMから問題管理データを抽出する方法

ステップ

BMC Helix ITSMにログイン Problem MasterまたはReport Administratorの権限を持つ認証情報を使って、mid-tierまたはSmart ITのインターフェースにアクセスします。
レポートコンソールに移動 ApplicationsメニューからAR System Report Consoleを選択します。Smart ITを使用している場合は、レポートダッシュボードに移動し、「Webレポート」を選択します。
新規レポートを作成 新規ボタン（緑色のプラスアイコン）をクリックして、レポートウィザードを開始します。
データソース（フォーム）の選択 「フォーム名」フィールドで、PBM:AuditLogSystem（またはバージョンに応じてPBM:Problem Investigation_AuditLog）を検索して選択します。注：PBM:Problem Investigationフォームには現在のケースデータが含まれますが、データ要件で必要となる行単位のイベント履歴（再割り当て、ステータス変更など）を作成するには、監査ログフォームが必要です。
レポート名と種類の設定 内容がわかるタイトル（例：「問題管理イベントログ」）を入力し、形式がWebレポートに設定されていることを確認します。
列（属性）の追加 使用可能なフィールドの一覧から次の項目を選択し、選択済みフィールドの一覧に移動します。
- Original Request ID（ProblemRecordに対応）
- Submit Date（EventTimeに対応）
- Fields Changed（Activityに対応）
- ユーザー（ユーザー／コーディネーターに対応）
- Log Key 1（通常、生のステータス値を保持）
フィルター（条件）の設定 フィルターまたは条件タブをクリックし、対象範囲を絞るクエリを作成します。
- Form Nameを「PBM:Problem Investigation」に設定し、IncidentおよびChangeの監査記録を除外します。
- Submit Dateに対象期間（例：>= 01/01/2023）を設定します。
保存と実行 レポート設定を保存します。プレビューをクリックしてデータが表示されることを確認し、続けてエクスポートをクリックします。
CSV形式でエクスポート エクスポート形式としてCSV（カンマ区切り値）を選択します。見出しが含まれていることを確認してください。
属性用の追加エクスポート（推奨） PBM:Problem Investigationを対象に、シンプルなレポートをもう1つ作成します。Problem Investigation ID、Priority、ServiceCI、説明をエクスポートします。この「ケース属性」ファイルを分析ツールでイベントログに結合すると、すべての監査ログ行には含まれない推奨の静的属性（優先度、サービスCI）を追加できます。
データ変換（エクスポート後） ProcessMindにアップロードする前に、次の処理を行います。
- Fields Changedの値を標準アクティビティに対応付けます（例：変更された項目が「ステータス」の場合、Log Key 1の値から「調査開始」または「根本原因の特定」を判断します）。
- 必要に応じて、プロセスに関係しない更新（例：表示上の項目変更）を除外します。

設定

フォームの選択：主なデータソースはPBM:AuditLogSystemです。PBM:Problem Investigationから直接抽出すると、現在の状態しか取得できず、「担当者の再割り当て」や「回避策の定義」の履歴を把握できません。
日付による絞り込み：古いケースの最近のアクティビティも取得できるよう、ケースの作成日だけでなく、AuditフォームのSubmit Dateで絞り込みます。
「Form Name」フィールド：重要なフィルターです。Audit SystemフォームはITSM全体で共有されています。IncidentやChangeのログが混在しないよう、必ずForm Name = "PBM:Problem Investigation"で絞り込んでください。
パフォーマンス：Audit Logテーブルは非常に大きいため、エクスポート期間を3～6か月に限定するか、Original Request IDの接頭辞（例：PBM%）で厳密に絞り込んでください。
権限：System Auditフォームを表示する権限が必要です。権限が制限されている場合は、システム管理者にエクスポートを依頼してください。

クエリの例 config

Form: PBM:AuditLogSystem
Type: Web Report (AR System Report Console)

// === SELECTION COLUMNS ===
// These fields form the raw event log structure
1. Original Request ID   (Alias: ProblemRecord)
2. Submit Date           (Alias: EventTime)
3. Submitter             (Alias: User)
4. Fields Changed        (Alias: Activity_Type)
5. Log Key 1             (Alias: New_Value)
6. Log Key 2             (Alias: Previous_Value)
7. Form Name             (Alias: Source_Module)

// === SEARCH QUALIFICATION (FILTER) ===
// Copy this logic into the Advanced Search or Qualification builder

('Form Name' = "PBM:Problem Investigation") AND
('Submit Date' >= "2023-01-01 00:00:00") AND
('Fields Changed' != $NULL$)

// === POST-EXPORT LOGIC (Context for Analyst) ===
// The Audit Log captures changes generically. You must map them:
// IF 'Fields Changed' CONTAINS "Status" AND 'Log Key 1' = "Under Investigation" -> Activity = "Investigation Commenced"
// IF 'Fields Changed' CONTAINS "Work Around" -> Activity = "Workaround Defined"
// IF 'Fields Changed' CONTAINS "PBM Coordinator" -> Activity = "Coordinator Reassigned"
// IF 'Fields Changed' = $NULL$ (Create Event) -> Activity = "Problem Record Logged"

ステップ

前提条件の確認：AR Systemデータベースに対する読み取り（SELECT）権限があることを確認します。特に、PBM_Problem_InvestigationビューとPBM_Problem_WorkLogビューへのアクセスが必要です。ユーザーアカウントに、該当するCompany／Support Groupデータへのアクセス権があることも確認してください。
データベースへの接続：使用するSQLクライアント（SQL Server Management Studio、DBeaver、Oracle SQL Developerなど）を開き、BMC Helix AR Systemのレプリカデータベースまたはレポート用データベースに接続します。
データモデルの確認：使用環境におけるテーブル名またはビュー名を特定します。標準ではPBM_Problem_Investigationですが、カスタマイズされた環境ではPBM_Problem_Investigation_Joinなどが使われている場合があります。Problem_IDとSubmit_Dateの列名も確認してください。
クエリの準備：下の「Query」セクションに記載されたSQLクエリをコピーします。このスクリプトは、問題レコードの主要データと作業ログの履歴を結合し、トランザクション形式のイベントログを作成します。
フィルターの設定：スクリプト内のWHERE句（/* Filter by Date */などのコメントが目印です）を確認し、抽出対象期間を設定します（例：Submit_Date >= '2023-01-01'）。
データの抽出：クエリ全体を実行します。問題レコードや作業ログの件数によっては、数分かかる場合があります。データベースクライアントがタイムアウトしないようにしてください。
データの検証：ProblemRecord、アクティビティ、EventTimeなどの主要な列を確認します。必須項目にNULL値がないことを確認してください。
データのエクスポート：クエリ結果をCSVファイルとして保存します。標準のUTF-8エンコーディングを使用し、ヘッダーを含めてください。
アップロード用の書式確認：CSVを開き、日付形式が統一されていることを確認します。ProcessMindではISO 8601形式のYYYY-MM-DD HH:MM:SSを推奨します。テキスト項目にバイナリ文字や過剰な空白が含まれている場合は削除してください。
ProcessMindへのインポート：整形したCSVをProcessMindにアップロードし、「Settings Overview」に記載されたとおりに列を割り当てます。

設定

対象期間：パフォーマンスとプロセスの可視性のバランスを考慮し、3～6か月分のデータを抽出することを推奨します。
システムビュー：主なビューはPBM_Problem_Investigation（ヘッダーデータ）とPBM_Problem_WorkLog（アクティビティ履歴）です。
日付による絞り込み：ケース全体を取得する場合はProblem InvestigationのSubmit_Dateを、特定期間のスナップショットを取得する場合はEventTimeを主な条件にします。
Companyによる絞り込み：複数のテナントをホストしている場合は、データの混在を防ぐため、すべてのWHERE句にAND Company = 'YourCompany'を追加します。
パフォーマンス：このクエリでは効率的なUNION ALLを使用しますが、WorkLog内の大きなCLOB/Textフィールドを結合すると時間がかかる場合があります。Problem_IDのデータベースインデックスが利用されることを確認してください。

クエリの例 sql

/* Part 1: Problem Record Logged (Creation) */
SELECT
    P.Problem_ID AS ProblemRecord,
    'Problem Record Logged' AS Activity,
    P.Submit_Date AS EventTime,
    'BMC Helix' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    P.Assigned_Group AS SupportGroup,
    P.Priority AS Priority,
    P.PBM_Coordinator AS ProblemCoordinator,
    P.Generic_Category AS RootCauseCategory,
    P.ServiceCI AS ServiceCI,
    P.Investigation_Driver AS InvestigationDriver,
    P.Target_Date AS SLADueDate,
    (SELECT COUNT(*) FROM HPD_Help_Desk_Associations A WHERE A.Problem_ID = P.Problem_ID) AS RelatedIncidentCount,
    CASE WHEN P.Target_Date < P.Closed_Date THEN 'Yes' ELSE 'No' END AS IsSLABreached
FROM PBM_Problem_Investigation P
WHERE P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 2: Investigation Commenced (Status Transition) */
SELECT
    P.Problem_ID,
    'Investigation Commenced',
    /* Prefer explicit status history timestamp if available, else estimate from Last_Modified if current status matches */
    COALESCE(P.Status_History_Under_Inv_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status_History_Under_Inv_Time IS NOT NULL
   OR (P.Status = 1 AND P.Last_Modified_Date IS NOT NULL) /* Status 1 = Under Investigation */
   AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 3: Root Cause Identified (Status Transition) */
SELECT
    P.Problem_ID,
    'Root Cause Identified',
    COALESCE(P.Status_History_Root_Cause_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status_History_Root_Cause_Time IS NOT NULL
   OR (P.Status = 2) /* Status 2 = Root Cause Identified */
   AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 4: Solution Database Updated (Status Transition) */
SELECT
    P.Problem_ID,
    'Solution Database Updated',
    COALESCE(P.Status_History_Solution_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status_History_Solution_Time IS NOT NULL
   OR (P.Status = 3) /* Status 3 = Solution Database */
   AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 5: Resolution Verified (Inferred from Completed Status) */
SELECT
    P.Problem_ID,
    'Resolution Verified',
    COALESCE(P.Status_History_Completed_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status_History_Completed_Time IS NOT NULL
   OR (P.Status >= 4) /* Status 4 = Implemented/Completed */
   AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 6: Problem Record Closed */
SELECT
    P.Problem_ID,
    'Problem Record Closed',
    P.Closed_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status = 5 /* Status 5 = Closed */
  AND P.Closed_Date IS NOT NULL
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 7: Problem Record Cancelled */
SELECT
    P.Problem_ID,
    'Problem Record Cancelled',
    P.Last_Modified_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status = 6 /* Status 6 = Cancelled */
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 8: Workaround Defined (From Worklog) */
SELECT
    P.Problem_ID,
    'Workaround Defined',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE W.Work_Log_Type = 'Workaround' OR W.Description LIKE '%Workaround%'
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 9: Assigned to Support Group (From Worklog) */
SELECT
    P.Problem_ID,
    'Assigned to Support Group',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE W.Description LIKE '%Assigned to Group%'
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 10: Coordinator Reassigned (From Worklog) */
SELECT
    P.Problem_ID,
    'Coordinator Reassigned',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE W.Description LIKE '%Coordinator%' AND W.Description LIKE '%Change%'
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 11: Change Request Initiated (From Worklog or Description) */
SELECT
    P.Problem_ID,
    'Change Request Initiated',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE (W.Description LIKE '%Change Request%' OR W.Description LIKE '%CRQ%')
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 12: Known Error Promoted (From Worklog) */
SELECT
    P.Problem_ID,
    'Known Error Promoted',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE (W.Description LIKE '%Known Error%' OR W.Work_Log_Type = 'Known Error')
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 13: Post-Implementation Review Conducted */
SELECT
    P.Problem_ID,
    'Post-Implementation Review Conducted',
    COALESCE(P.Status_History_Completed_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE (P.Status_Reason = 'PIR' OR P.Investigation_Driver = 'PIR')
  AND P.Status >= 4
  AND P.Submit_Date >= '2023-01-01'

ステップ

前提条件：抽出に使うマシンにPython 3.xがインストールされていることを確認します。requestsとpandasライブラリが必要です。pip install requests pandasでインストールしてください。
APIアクセス：BMC Helix ITSMの管理者に、連携専用ユーザーアカウントを申請します。このユーザーには、「Problem Viewer」および「AR System Administrator」（または同等のAPIアクセス権限）が必要です。
APIゲートウェイの確認：BMC Helix AR System REST APIのベースURLを確認します。通常はhttps://[your-instance].onbmc.com/api/arsys/v1の形式です。
フィールドIDの対応付け：BMC Helixでは内部的にフィールドIDを使用します。スクリプトでは、人が読める名前を取得するためにuseLabels機能を使いますが、実際の環境で「Status」、「Assigned Group」、「Workaround」に対応するフィールドIDをDeveloper Studioまたはテスト用のGETリクエストで確認してください。
スクリプトの設定：提供されたPythonスクリプトのCONFIG辞書を更新します。URL、ユーザー名、パスワード、抽出期間を設定してください。
基本データの抽出：スクリプトは最初にPBM:Problem Investigationフォームを照会します。問題レコードの基本情報を取得し、Submit Dateに基づいて「問題レコード登録」イベントを作成するとともに、現在の属性を取得します。
履歴データの抽出：スクリプトは監査履歴を順次取得します。BMC Helixでは、履歴は多くの場合PBM:AuditLogSystemに保存されるか、関連付けを通じてアクセスできます。提供されたスクリプトはAuditフォームを照会し、「調査開始」などの状態遷移や、「サポートグループへの割り当て」などのフィールド更新を取得します。
データ変換：スクリプトには、BMCのステータスコード（例：「調査中」、「根本原因特定」）をプロセス定義で必要となるアクティビティ名に対応付ける処理が含まれています。
検証：少数のレコードだけを取得するドライランモードでスクリプトを実行し、フィールド名がカスタマイズ内容と一致することを確認します。コンソール出力で接続エラーがないかも確認してください。
実行：抽出処理を実行します。タイムアウトを避けるため、スクリプトはoffsetとlimitパラメーターを使ってページネーションを自動処理します。
出力ファイルの作成：スクリプトはすべてのイベントを1つのDataFrameにまとめ、problem_management_event_log.csvという名前のファイルに出力します。
最終確認：CSVファイルを開き、「EventTime」列が適切な形式（ISO 8601を推奨）になっていること、ProcessMindへのアップロード前に13種類すべてのアクティビティが含まれていることを確認します。

設定

APIエンドポイント：標準のインターフェースはAR System REST APIです。該当するポート（通常は443）での通信が許可されていることを確認してください。
ページネーション：スクリプトの既定のバッチサイズは1000です。ネットワークの遅延やサーバーのタイムアウト設定に応じて調整してください。
日付による絞り込み：抽出対象のメインレコードはSubmit Dateで絞り込みます。クエリの日付形式がAR Systemの形式と一致していることを確認してください。形式はバージョンによって、エポック値または特定の文字列形式です。
フィールドの選択：データ量を抑えるため、必要なフィールドだけを取得します。説明や添付ファイルのフィールドを追加すると、抽出にかかる時間が大幅に延びる場合があります。
認証：JWT（JSON Web Token）認証を使用します。トークンには有効期限があるため、リクエスト前にトークンを取得する処理がスクリプトに含まれています。
ステータスの対応付け：BMCではステータス値に整数ID（例：0、10、20）を使用します。スクリプトはこれらを人が読めるアクティビティ名に対応付けます。実際のITSM設定に照らして、対応付けを確認してください。

クエリの例 python

import requests
import json
import pandas as pd
from datetime import datetime
import time

class=class="hl-string">"hl-comment"># Configuration
CONFIG = {
    class="hl-string">"base_url": class="hl-string">"https://[your-instance].onbmc.com/api/arsys/v1",
    class="hl-string">"username": class="hl-string">"[API_User]",
    class="hl-string">"password": class="hl-string">"[API_Password]",
    class="hl-string">"start_date": class="hl-string">"2023-01-01T00:00:00.000+0000",
    class="hl-string">"output_file": class="hl-string">"problem_management_event_log.csv",
    class="hl-string">"batch_size": 1000
}

class=class="hl-string">"hl-comment"># Status Map (Standard BMC Helix PBM Status values)
STATUS_MAP = {
    class="hl-string">"Draft": class="hl-string">"Problem Record Logged",
    class="hl-string">"Under Investigation": class="hl-string">"Investigation Commenced",
    class="hl-string">"Root Cause Identified": class="hl-string">"Root Cause Identified",
    class="hl-string">"Solution Database": class="hl-string">"Solution Database Updated",
    class="hl-string">"Solution Implemented": class="hl-string">"Resolution Verified",
    class="hl-string">"Completed": class="hl-string">"Resolution Verified",
    class="hl-string">"Rejected": class="hl-string">"Problem Record Cancelled",
    class="hl-string">"Cancelled": class="hl-string">"Problem Record Cancelled",
    class="hl-string">"Closed": class="hl-string">"Problem Record Closed"
}

class=class="hl-string">"hl-comment"># Global Session
session = requests.Session()

def login():
    url = fclass="hl-string">"{CONFIG['base_url']}/jwt/login"
    headers = {class="hl-string">"Content-Type": class="hl-string">"application/x-www-form-urlencoded"}
    data = {
        class="hl-string">"username": CONFIG[class="hl-string">"username"],
        class="hl-string">"password": CONFIG[class="hl-string">"password"]
    }
    response = session.post(url, headers=headers, data=data)
    if response.status_code == 200:
        session.headers.update({class="hl-string">"Authorization": fclass="hl-string">"AR-JWT {response.text}"})
        print(class="hl-string">"Authentication successful.")
    else:
        raise Exception(fclass="hl-string">"Login failed: {response.text}")

def fetch_records(form_name, fields, query_string):
    all_entries = []
    offset = 0
    
    while True:
        url = fclass="hl-string">"{CONFIG['base_url']}/entry/{form_name}"
        params = {
            class="hl-string">"q": query_string,
            class="hl-string">"fields": fclass="hl-string">"values({','.join(fields)})",
            class="hl-string">"offset": offset,
            class="hl-string">"limit": CONFIG[class="hl-string">"batch_size"],
            class="hl-string">"useLabels": class="hl-string">"true"
        }
        
        resp = session.get(url, params=params)
        if resp.status_code != 200:
            print(fclass="hl-string">"Error fetching data: {resp.text}")
            break
            
        data = resp.json()
        entries = data.get(class="hl-string">'entries', [])
        if not entries:
            break
            
        for entry in entries:
            all_entries.append(entry[class="hl-string">'values'])
            
        offset += len(entries)
        print(fclass="hl-string">"Fetched {len(all_entries)} records from {form_name}...")
        
    return all_entries

def generate_event_log():
    class=class="hl-string">"hl-comment"># 1. Fetch Main Problem Records
    print(class="hl-string">"Fetching Problem Investigations...")
    pbm_fields = [
        class="hl-string">"Problem ID", class="hl-string">"Submit Date", class="hl-string">"Last Modified Date", class="hl-string">"Status", 
        class="hl-string">"Assigned Group", class="hl-string">"Priority", class="hl-string">"Problem Coordinator", 
        class="hl-string">"Description", class="hl-string">"Workaround", class="hl-string">"Investigation Driver"
    ]
    class=class="hl-string">"hl-comment"># Query syntax: class="hl-string">'Submit Date' > class="hl-string">"start_date"
    pbm_query = fclass="hl-string">"'Submit Date' > \"{CONFIG[class="hl-string">'start_date']}\class="hl-string">""
    
    problems = fetch_records(class="hl-string">"PBM:Problem Investigation", pbm_fields, pbm_query)
    
    event_log = []
    
    class=class="hl-string">"hl-comment"># Map of Problem ID to attributes for enrichment
    pbm_lookup = {}

    for p in problems:
        pid = p.get(class="hl-string">"Problem ID")
        pbm_lookup[pid] = p
        
        class=class="hl-string">"hl-comment"># Event 1: Problem Record Logged (Creation)
        event_log.append({
            class="hl-string">"ProblemRecord": pid,
            class="hl-string">"Activity": class="hl-string">"Problem Record Logged",
            class="hl-string">"EventTime": p.get(class="hl-string">"Submit Date"),
            class="hl-string">"SupportGroup": p.get(class="hl-string">"Assigned Group"),
            class="hl-string">"Priority": p.get(class="hl-string">"Priority"),
            class="hl-string">"ProblemCoordinator": p.get(class="hl-string">"Problem Coordinator"),
            class="hl-string">"SourceSystem": class="hl-string">"BMC Helix ITSM",
            class="hl-string">"LastDataUpdate": datetime.now().isoformat()
        })

    class=class="hl-string">"hl-comment"># 2. Fetch Audit Logs / History
    class=class="hl-string">"hl-comment"># Note: Fetching PBM:AuditLogSystem or PBM:Problem Investigation_AuditLog
    class=class="hl-string">"hl-comment"># We filter by the Problem IDs we just fetched to optimize
    print(class="hl-string">"Fetching Audit Logs...")
    
    class=class="hl-string">"hl-comment"># In a real scenario, chunk this query if too many IDs, here simplified
    class=class="hl-string">"hl-comment"># We look for field changes relevant to our activities
    audit_fields = [class="hl-string">"Original Request ID", class="hl-string">"Fields Changed", class="hl-string">"Log Date", class="hl-string">"User", class="hl-string">"New Value"]
    
    class=class="hl-string">"hl-comment"># Iterate through problems to get history (Alternative: fetch bulk audit if API allows complex ORs)
    class=class="hl-string">"hl-comment"># For this script, we assume we fetch audit based on the main form query logic mapping
    class=class="hl-string">"hl-comment"># WARNING: Fetching audit for all records can be slow. 
    
    class=class="hl-string">"hl-comment"># For demonstration, we simulate fetching audit entries. 
    class=class="hl-string">"hl-comment"># In production, query class="hl-string">'PBM:Problem Investigation_AuditLog' where class="hl-string">'Original Request ID' IN (...)
    
    class=class="hl-string">"hl-comment"># Placeholder for audit data retrieval logic
    class=class="hl-string">"hl-comment"># Simulating a loop over retrieved problems to get their specific audit trails
    class=class="hl-string">"hl-comment"># This is a logical representation; in high volume, use a bulk export method
    
    for p in problems:
        pid = p.get(class="hl-string">"Problem ID")
        
        class=class="hl-string">"hl-comment"># Query specific audit form for this problem
        class=class="hl-string">"hl-comment"># Using PBM:Problem Investigation_AuditLog as the standard history container
        audit_query = fclass="hl-string">"'Original Request ID' = \"{pid}\class="hl-string">""
        class=class="hl-string">"hl-comment"># We only need specific fields changed
        audit_entries = fetch_records(class="hl-string">"PBM:Problem Investigation_AuditLog", audit_fields, audit_query)
        
        for audit in audit_entries:
            fields_changed = audit.get(class="hl-string">"Fields Changed", class="hl-string">"")
            new_val = audit.get(class="hl-string">"New Value", class="hl-string">"")
            log_date = audit.get(class="hl-string">"Log Date")
            
            activity = None
            
            class=class="hl-string">"hl-comment"># Map Fields to Activities
            if class="hl-string">"Status" in fields_changed:
                class=class="hl-string">"hl-comment"># Map status string to activity
                activity = STATUS_MAP.get(new_val)
                
            elif class="hl-string">"Assigned Group" in fields_changed:
                activity = class="hl-string">"Assigned to Support Group"
                
            elif class="hl-string">"Workaround" in fields_changed:
                activity = class="hl-string">"Workaround Defined"
                
            elif class="hl-string">"Problem Coordinator" in fields_changed:
                activity = class="hl-string">"Coordinator Reassigned"
                
            elif class="hl-string">"Infrastructure Change ID" in fields_changed or class="hl-string">"Change Request" in fields_changed:
                activity = class="hl-string">"Change Request Initiated"
                
            elif class="hl-string">"Known Error" in fields_changed:
                activity = class="hl-string">"Known Error Promoted"

            class=class="hl-string">"hl-comment"># PIR Inference: If status moves to class="hl-string">'Closed' and PIR task exists (simplified here to Status)
            if activity == class="hl-string">"Problem Record Closed" and p.get(class="hl-string">"PIR Required") == class="hl-string">"Yes":
                 class=class="hl-string">"hl-comment"># Insert PIR event just before close if not explicitly found
                 event_log.append({
                    class="hl-string">"ProblemRecord": pid,
                    class="hl-string">"Activity": class="hl-string">"Post-Implementation Review Conducted",
                    class="hl-string">"EventTime": log_date, class=class="hl-string">"hl-comment"># Same time as close for this logic
                    class="hl-string">"SupportGroup": p.get(class="hl-string">"Assigned Group"),
                    class="hl-string">"SourceSystem": class="hl-string">"BMC Helix ITSM",
                    class="hl-string">"LastDataUpdate": datetime.now().isoformat()
                })

            if activity:
                event_log.append({
                    class="hl-string">"ProblemRecord": pid,
                    class="hl-string">"Activity": activity,
                    class="hl-string">"EventTime": log_date,
                    class="hl-string">"SupportGroup": p.get(class="hl-string">"Assigned Group"), class=class="hl-string">"hl-comment"># Use current or historical if parsed
                    class="hl-string">"Priority": p.get(class="hl-string">"Priority"),
                    class="hl-string">"ProblemCoordinator": p.get(class="hl-string">"Problem Coordinator"),
                    class="hl-string">"SourceSystem": class="hl-string">"BMC Helix ITSM",
                    class="hl-string">"LastDataUpdate": datetime.now().isoformat()
                })

    class=class="hl-string">"hl-comment"># Convert to DataFrame
    df = pd.DataFrame(event_log)
    
    class=class="hl-string">"hl-comment"># Sorting
    if not df.empty:
        df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
        df = df.sort_values(by=[class="hl-string">'ProblemRecord', class="hl-string">'EventTime'])
        
        class=class="hl-string">"hl-comment"># Export
        df.to_csv(CONFIG[class="hl-string">'output_file'], index=False)
        print(fclass="hl-string">"Extraction complete. Data saved to {CONFIG['output_file']}")
    else:
        print(class="hl-string">"No events extracted.")

if __name__ == class="hl-string">"__main__":
    try:
        login()
        generate_event_log()
    except Exception as e:
        print(fclass="hl-string">"An error occurred: {e}")

導入の準備はできていますか？

このテンプレートをBMC Helix ITSMのデータに適用し、サービスの安定性向上にお役立てください。設定についてご不明な点がございましたら、担当チームがサポートします。

改善ガイドに戻る

テンプレートをダウンロード

問題管理のボトルネックを今すぐ解消

サイクルタイムを30％短縮し、サービスの安定性を高めます。

無料トライアルを開始しましょう。

クレジットカード不要。数分で設定できます。

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

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

問題管理の属性

問題管理のアクティビティ

データ抽出ガイド

BMC Helix AR System Report Consoleからのエクスポート

ステップ

設定

クエリの例 config

AR Systemデータベースビューへの直接SQLクエリ

ステップ

設定

クエリの例 sql

AR System REST APIを使ったPythonでの抽出

ステップ

設定

クエリの例 python

導入の準備はできていますか？

問題管理のボトルネックを今すぐ解消