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

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

BMC Helix ITSM

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

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

このテンプレートは、BMC Helix ITSM内の根本原因調査ワークフローを分析するための詳細な構成を提供します。詳細なイベントログを作成するために必要な属性とプロセスアクティビティに加え、実際の抽出手順も示します。このガイドに従うことで、隠れたボトルネックを特定し、インシデントを恒久的に解決するまでのプロセスを効率化できます。

根本原因分析に必要なデータ項目
追跡用に標準化されたプロセス上のマイルストーン
BMC Helix ITSM向けの具体的な抽出手順

イベントログを初めて扱いますか。学ぶプロセスマイニングのイベントログを作成する方法.

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

問題管理の属性

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

5 必須 9 推奨 5 任意

	名前	説明
	アクティビティ Activity	実行された特定のタスクまたはステータス変更イベントです。
説明この属性は、Problem Managementのライフサイクルで実行された具体的なステップを表します。たとえば、「Problem Record Logged」、「Root Cause Identified」、「Solution Database Updated」などです。BMC Helixでは、Status History、Audit Logs、またはProblem Investigationモジュール内の特定のトランザクションタイムスタンプから導出されることが多い項目です。この属性はプロセスディスカバリーの中心です。これらのアクティビティの順序を分析することで、プロセスマイニングツールはプロセスマップを構築し、設計されたプロセスと実際の作業の流れを比較できます。ループ、手戻り、標準手順からの逸脱も明らかになります。実際のライフサイクルで何が起きたかを理解するには、正確なアクティビティ名が欠かせません。このデータにより、根本原因の特定から変更リクエストの開始までなど、特定のステップ間の移行時間を測定できます。重要な理由プロセスマップのノードを定義し、ワークフローを可視化できます。入手先 PBM:Problem Investigationのステータス履歴またはPBM:AuditLogSystemから導出例 Problem Recordの記録サポートグループに割り当て調査開始根本原因を特定
	イベント時刻 EventTime	特定のアクティビティが発生した時点のタイムスタンプです。
説明この属性は、アクティビティが実行された正確な日時を記録します。BMC Helix ITSMでは、「Submit Date」、「Last Modified Date」、またはステータス変更に対応する履歴テーブルに記録された特定のタイムスタンプが該当します。分析では、この属性を使ってイベントを時系列に並べ、期間を計算します。「Investigation Cycle Time」や「Workaround Publication Lead Time」など、プロセス上の任意の2地点間のサイクル時間を測定できます。ボトルネックを特定するには、正確なタイムスタンプが欠かせません。連続するイベント間の時間差を計算することで、初期割り当て中か最終レビュー段階かを問わず、遅延が発生している場所を正確に特定できます。重要な理由期間に基づくすべてのKPIを計算し、イベントを時系列に並べるために使用します。入手先 PBM:Problem Investigationに関連する履歴テーブルまたは監査ログ例 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
	問題レコード ProblemRecord	問題調査ケースを一意に識別するIDです。
説明この属性は、Problem Managementプロセスにおけるケースの中心的な識別子です。BMC Helix ITSMでは通常、PBM:Problem Investigationフォームにある「Problem ID」フィールド（例：PBI00000012345）が該当します。問題の初回記録から最終的なクローズ、実装後レビューまで、関連するすべてのアクティビティを結び付けます。プロセスマイニング分析では、この属性を使って個々のイベントを1つのプロセスインスタンスにまとめます。これにより、特定の問題調査が最初から最後までどのように進んだかを可視化できます。この識別子がなければ、異なるサポートグループやコーディネーターが実施した一連のアクションを関連付けることはできません。このフィールドはイベントログの主キーとして機能し、問題ごとの合計サイクル時間や優先度別の問題件数など、ケース単位の集計すべてに欠かせません。重要な理由プロセスビューを構築し、特定の問題のライフサイクルを追跡するために必要な基本キーです。入手先 PBM:Problem Investigationフォームの「Problem ID」フィールド例 PBI00000004512PBI00000004513PBI00000004514
	ソースシステム SourceSystem	データの取得元となったシステムです。
説明この属性は、プロセスデータを抽出したソフトウェアシステムを識別します。ここでは「BMC Helix ITSM」が該当します。複数のITSM、開発、外部ベンダーのツールからデータを集約する環境では、特に重要です。分析では、このフィールドをメタデータタグとして使い、レコードの出所を確認します。プロセスマイニングのビューが、Problem ManagementのBMC Helixとソフトウェア開発の別システム（例：Jira）のデータを組み合わせる場合、この属性によって元のツール別に分析を分けられます。技術的なトラブルシューティングにも役立ちます。データ品質の問題が発生した場合、ソースシステムが分かれば、特定の抽出処理やソースデータベースまで原因を追跡できます。重要な理由特に複数システムをまたぐプロセスビューで、追跡可能性と背景情報を提供します。入手先抽出処理中にハードコード例 BMC Helix ITSMRemedy OnDemandBMC ITSM 本番環境
	最終データ更新 LastDataUpdate	データを抽出または最後に更新した時点のタイムスタンプです。
説明この属性は、データが最後にプロセスマイニングアプリケーションへ読み込まれた時点を示します。分析対象のデータがどの程度新しいかを把握できます。通常は、抽出スクリプトまたはデータパイプラインツールによって生成されます。分析では、古いデータに基づく判断を防ぐのに役立ちます。たとえば、管理者が「Open Problem Records」を確認する際、データが1時間前に更新されたのか、1週間前に更新されたのかによって、現在の作業量に対する解釈は大きく変わります。増分データロードにも使用します。最終更新時刻を追跡することで、ETLプロセスは前回の抽出以降に変更されたレコードだけを取得でき、処理性能を高めてシステム負荷を抑えられます。重要な理由データの鮮度を保ち、増分データロードの方針を支えます。入手先抽出時点のシステム時刻例 2023-11-01T00:00:00Z2023-11-01T12:00:00Z
	SLA期限 SLADueDate	問題を解決しなければならない目標日時です。
説明この属性には、サービスレベル合意に基づく問題解決の期限が入ります。BMC Helixでは、「Target Resolution Date」または算出されたSLAマイルストーンのタイムスタンプに該当することが多い項目です。この属性は、「SLA Compliance and Breach Trends」ダッシュボードの基準になります。このタイムスタンプと「Resolution Verified」アクティビティのタイムスタンプを比較し、SLAを達成したか、超過したかを計算します。この日付を可視化すると、チームがどの程度余裕を持って対応しているかを確認できます。数日前に問題を解決しているのか、それとも超過の数分前に終える状況が続いているのかを把握できます。この分析結果はキャパシティ計画に役立ちます。重要な理由すべてのコンプライアンス指標と適時性指標を計算するための基準点です。入手先 PBM:Problem Investigationフォームの「Target Resolution Date」フィールド例 2023-12-01T17:00:00Z2023-12-02T09:00:00Z
	SLA違反の有無 IsSLABreached	問題の解決が許容時間を超えたかどうかを示すフラグです。
説明このブール型属性は、問題レコードがサービスレベル合意（SLA）に違反したかどうかを示します。「Resolution Verified」のタイムスタンプと「SLA Due Date」を比較して計算するか、SLMのステータスから直接取得します。この属性は、「SLA Compliance and Breach Trends」ダッシュボードに欠かせません。プロセスを「準拠」と「非準拠」に二分して分類できます。これにより、失敗したプロセスの特徴を簡単に絞り込めます（例：「違反したケースには必ずSupport Group Xが関与しているか」）。プロセス失敗の根本原因分析における主要なフィルターとしても機能します。アナリストは「IsSLABreached = True」で絞り込み、プロセスマップを確認して、どこで時間が失われたか（例：ベンダー承認の長い待ち時間）を調べられます。重要な理由コンプライアンス報告と失敗分析を簡単にします。入手先 SLM:Measurementフォームまたは計算値例 truefalse
	サービスCI ServiceCI	影響を受けた主要なビジネスサービスまたは構成アイテムです。
説明この属性は、問題に関連するService Configuration Item（CI）を示します。例として、「Email Service」、「SAP ERP」、「Wi-Fi Network」などがあります。BMC Helixでは、「Service+」フィールドまたは主要なCI関連付けに該当することが多い項目です。分析では、問題レコードを製品やサービス別に分けられます。どのサービスが不安定で、最も多くの問題調査を発生させているかをIT部門の責任者が把握できます。「Throughput and Priority Volume」ダッシュボードに製品の切り口を追加する際にも役立ちます。この属性と「Investigation Cycle Time」を関連付けることで、コアバンキングシステムのような複雑なサービスは、印刷のような標準的なサービスより本質的に調査期間が長いのかを確認できます。重要な理由プロセスのパフォーマンスを特定のビジネス製品やサービスに関連付けます。入手先 PBM:Problem Investigationフォームの「ServiceCI」または「CI Name」フィールド例メールサービス給与計算システム社内VPN
	サポートグループ SupportGroup	現在、問題調査を担当している技術チームです。
説明この属性は、イベント発生時点で問題レコードを担当していた特定のサポートグループ（例：「Server Admin」、「Database Support」）を示します。BMC Helixでは「Assigned Group」フィールドに該当します。この属性は、「Support Group Workload Distribution」および「Support Group Reassignment Analysis」ダッシュボードに欠かせません。チーム別にプロセスマップを分析し、どのグループが最も多くの案件を処理しているか、また調査プロセスのどこでボトルネックになっているかを明らかにできます。サポートグループ間の引き継ぎを分析すると、チケットが解決されないままチーム間を行き来する「たらい回し」の状態を特定できます。これは、組織内の責任分担が不明確であることや、ナレッジマネジメントが不十分であることを示している場合があります。重要な理由組織単位での分析と、チームレベルでのボトルネック検出が可能になります。入手先 PBM:Problem Investigationフォームの「Assigned Group」フィールド例サービスデスクレベル1バックオフィスサポートネットワーク管理
	優先度 Priority	影響度と緊急度に基づいて算出された問題の優先度です。
説明この属性は、問題レコードの優先度（例：Critical、High、Medium、Low）を示します。BMC Helixでは通常、ImpactとUrgencyの選択内容から算出されるフィールドです。分析では、「Throughput and Priority Volume」ダッシュボードに使用します。組織は、リソースがビジネス上の必要性に適切に配分されているかを確認できます。たとえば、理論上は「Critical」の問題ほど、初期割り当て時間と全体のサイクル時間が「Low」の問題より短くなるはずです。優先度で絞り込むと、改善すべき領域に集中できます。「Low」優先度のプロセスにあるボトルネックは許容できる場合がありますが、「Critical」プロセスで同じ遅延が発生すると、事業継続とSLAコンプライアンスに大きなリスクとなります。重要な理由ビジネス上の重要度別に分析を分け、SLA分析を支えます。入手先 PBM:Problem Investigationフォームの「Priority」フィールド例重大高中低
	問題コーディネーター ProblemCoordinator	調査の調整を担当する個人ユーザーです。
説明この属性は、問題レコードを担当する特定の担当者を示します。BMC Helix ITSMでは「Problem Coordinator」フィールドに該当します。タスクを他の担当者に委任した場合でも、この担当者が問題のライフサイクルを管理します。この属性は「Support Group Workload Distribution」ダッシュボードを支えます。管理者は、特定の担当者に調査が集中していないか、他の担当者に余力があるかを確認できます。また、個人レベルでのパフォーマンス分析にも役立ち、トレーニングが必要な担当者や高い成果を上げている担当者を特定できます。プロセスマイニングでは、このフィールドをリソース属性として扱います。個人間で作業がどのように引き継がれているかを可視化し、特定の専門家に依存しすぎている単一障害点を明らかにできます。重要な理由個人レベルでのリソース分析と作業量の平準化が可能になります。入手先 PBM:Problem Investigationフォームの「Problem Coordinator」フィールド例 John DoeJane Smithシステム管理者
	根本原因カテゴリ RootCauseCategory	問題の根本的な原因を分類したものです。
説明この属性には、根本原因の特定時に選択されたカテゴリ（例：「Software Error」、「Hardware Failure」、「Process Gap」）が入ります。BMC Helixでは通常、「Root Cause」または「Generic Categorization」メニューから選択します。この属性は、「Fix Effectiveness and Quality」ビューに欠かせません。特定の根本原因の種類と、手戻り率や調査の長期化との関係を組織が確認できます。たとえば、「Software Error」の問題は「Hardware Failure」の問題より解決に2倍の時間がかかることが分かる場合があります。「Root Cause Categorization Rate」の計算にも使用します。このフィールドで「Unknown」や「Other」の割合が高い場合、技術トレーニングの強化や、より細かな分類項目の追加が必要である可能性を示します。重要な理由組織的な問題の傾向分析を可能にし、先回りしたProblem Managementを支えます。入手先 PBM:Problem Investigationフォームの「Root Cause」または分類タブのフィールド例ソフトウェアモジュールネットワークインフラストラクチャ人的ミス
	調査の起点 InvestigationDriver	問題調査を開始した理由です。
説明この属性は、問題レコードの発生要因を分類します。例として、「Incident Volume」、「Major Incident」、「Vendor Notification」、「Proactive Trend Analysis」などがあります。BMC Helixでは「Investigation Driver」フィールドに該当します。この属性は「Proactive Identification Trends」ダッシュボードを支えます。インシデントに対応する受け身の消火活動から、リスクが顕在化する前に特定する先回り型のProblem Managementへ、組織がどの程度移行しているかを測定できます。「Investigation Driver」別にプロセスフローを分析すると、異なる傾向が見えてきます。たとえば、「Proactive」の問題は直ちに障害を引き起こさないためキューに長く滞留する一方、「Major Incident」を起点とする問題はプロセスを急いで進む場合があります。重要な理由受け身の作業と先回りした作業を区別し、成熟度を示す重要な指標になります。入手先 PBM:Problem Investigationフォームの「Investigation Driver」フィールド例事後対応型予防対応型再発インシデント
	関連インシデント件数 RelatedIncidentCount	この問題レコードに関連付けられたインシデントの件数です。
説明この属性は、関連付けられたインシデントの件数によって問題の影響度を定量化します。BMC Helixでは通常、PBMレコードに関連するHPD:Help Deskフォームのレコード件数です。この属性は「Incident Linkage Density」KPIの基礎になります。件数が多い場合、サービスデスクに大きな負荷を与えている影響度の高い問題であることを示します。「Priority」と関連付けることで、件数の多い問題が実際にCriticalとして扱われているかを確認できます。バックログの優先順位付けにも役立ちます。関連インシデントが500件ある問題レコードは、関連インシデントが1件しかない「Critical」問題より優先すべき場合があります。前者を解決すれば、サービスデスクのキャパシティをより多く解放できるためです。重要な理由問題に伴う業務上の影響とユーザーの負担を定量化します。入手先 HPD:AssociationsまたはHPD:Help Deskの関連行をカウントして算出例 15120
	再割り当て回数 ReassignmentCount	サポートグループが変更された合計回数です。
説明この属性は、1つのケースで「Assigned to Support Group」アクティビティが発生した回数を数えます。プロセス上の摩擦とルーティング効率を直接測定する指標です。この属性は、「Support Group Reassignment Analysis」チャートに表示されます。値が高い状態（何度も行き来する状態）は、初期トリアージが機能していないか、複雑な問題の担当が明確でないことを示します。サイクル時間の増加を予測する先行指標でもあります。管理者は、この指標からトレーニングの機会を特定できます。Service Deskが「Database」の問題を一貫して最初に「Network」へ再割り当てし、その後「Network」が「Database」へ戻している場合、再割り当て回数が急増します。これにより、初期診断スクリプトを改善する必要性が明らかになります。重要な理由プロセス内の無駄、摩擦、担当の不明確さを特定します。入手先アクティビティ履歴から計算例 015
	回避策のステータス WorkaroundStatus	有効な回避策が特定され、公開されているかどうかを示します。
説明この属性は、一時的な解決策（Workaround）の状態を追跡します。単純なブール値（Has Workaround）やステータス文字列の場合があります。BMC Helixでは、多くの場合、「Workaround」フィールドにテキストが入力されているか、特定のステータスフラグが設定されているかによって判定されます。この属性は、「Workaround Publication Performance」ダッシュボードの基盤となります。根本原因を調査している間、チームが影響をどの程度効果的に抑えているかを確認できます。「No Workaround」でプロセスビューを絞り込むと、調査中に業務が全面的な影響を受けているケースを特定できます。品質監査にも役立ちます。恒久的な修正（Change Request）も回避策もないまま問題レコードをクローズする場合、通常はプロセス上の不備にあたり、確認が必要です。重要な理由調査中の影響抑制の有効性を測定します。入手先 PBM:Problem Investigationフォーム、「Workaround」フィールドの内容確認例有効なし廃止
	地域 Region	問題に関連する地理的な地域です。
説明この属性は、問題が発生した、または管理されている地理的な場所（例：「North America」、「EMEA」）を示します。BMC Helixでは、依頼者または影響を受けた資産に関連する「Region」または「Site」フィールドに記録されることが多い項目です。分析では、地域別の比較を可能にします。特定の地域で問題件数が多い、または解決時間が長いかを確認できます。地域ごとのサポート要員配置やインフラ品質の差を明らかにすることにも役立ちます。グローバル組織が一貫したサービスを提供するうえで有用です。「APAC」の「Investigation Cycle Time」が「NAM」の2倍であれば、その地域のリソース配分やプロセス遵守状況を調査するきっかけになります。重要な理由地域別にプロセスパフォーマンスを比較できます。入手先 PBM:Problem Investigationフォームの「Region」フィールド例南北アメリカEMEAAPAC
	根本原因の特定までの調査サイクル時間 InvestigationCycleTime	調査の開始から根本原因の特定までの期間です。
説明これは、「Investigation Commenced」アクティビティから「Root Cause Identified」アクティビティまでの時間を測定する、計算によって求められる期間属性です。問題管理プロセスにおける、中心的な付加価値時間を表します。この指標は、「Root Cause Investigation Cycle Time」ダッシュボードに取り込まれます。問題の技術的な複雑さや、調査チームの効率を管理者が把握するのに役立ちます。ここで極端に短い時間が見られる場合は推測による判断を示している可能性があり、極端に長い時間は調査が停滞していることを示します。「Support Groups」と「Priorities」ごとにこの指標を比較すると、問題をより迅速に診断するために、より良いツール、トレーニング、またはベンダーの支援を必要とするチームを組織が特定できます。重要な理由技術調査フェーズにおける主要な効率指標です。入手先アクティビティのタイムスタンプから計算例 4500000120000
	関連変更リクエストID RelatedChangeRequestId	問題を修正するために開始された変更リクエストの識別子です。
説明この属性には、問題レコードに関連付けられたChange RequestのID（例：CRQ0000...）が入ります。調査から恒久対応の実装へ移行したことを示します。この属性は「Root Cause to Change Lead Time」KPIに必要です。根本原因の特定から変更プロセスの開始までの遅延を、プロセスマイニングツールで測定できます。ここは、作業の勢いが失われやすい一般的な引き継ぎポイントです。「process completeness」の確認にも役立ちます。「Completed」ステータスでクローズされた問題レコードに、関連する変更リクエスト（または回避策）がない場合、根本原因は特定されたものの実際には修正されていない、プロセス違反の可能性があります。重要な理由 Problem ManagementプロセスとChange Managementプロセスを関連付けます。入手先 PBM:Investigation AssociationsまたはRelationshipタブ例 CRQ00000021345CRQ00000021346

必須推奨任意

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

調査フェーズと解決フェーズを完全に可視化するため、追跡すべき基本的なプロセス手順とステータス変更を示します。

9 推奨 4 任意

	アクティビティ	説明
	Problem Recordの記録	システムにProblem Investigationレコードを初めて作成した時点です。PBM:Problem Investigationフォームに新しいエントリが保存された際に、このイベントが明示的に記録されます。
重要な理由プロセスインスタンスの開始を示します。全体のサイクル時間と初期応答指標を計算するために欠かせません。入手先 PBM:Problem Investigationフォームの「Submit Date」タイムスタンプ、または「Status」＝「Draft」の作成ログ。取得 PBM:Problem Investigationレコードの作成時に記録イベントタイプ explicit
	Problem Recordをキャンセル	解決前に問題レコードを終了することです。ステータスが「Cancelled」または「Rejected」になった時点で記録します。
重要な理由無駄な作業や正当な重複を特定するために使用します。代替となる終了地点を示します。入手先 PBM:Problem Investigationフォームの「Status」フィールド＝「Cancelled」または「Rejected」。取得 Cancelledへの移行についてStatusフィールドを比較イベントタイプ inferred
	Problem Recordをクローズ	問題レコードを最終的に管理上クローズすることです。このイベントでプロセスインスタンスが終了します。
重要な理由標準の終了イベントです。サイクル時間全体の分析と「Incident Linkage Density」の計算に必要です。入手先 PBM:Problem Investigationフォームの「Status」フィールド＝「Closed」。取得 Closedへの移行についてStatusフィールドを比較イベントタイプ inferred
	サポートグループに割り当て	問題レコードを特定の技術チームに割り当てることです。「Assigned Group」フィールドの変更を監視して記録します。
重要な理由引き継ぎ、たらい回しの影響、「Mean Time to Initial Assignment」KPIを測定するために重要です。入手先 PBM:Problem Investigationフォームの「Assigned Group」フィールド履歴または監査ログ。取得更新前後の「Assigned Group」フィールドを比較イベントタイプ inferred
	回避策を定義	問題レコードのWorkaroundフィールドにテキストを入力または更新することです。このイベントは、一時的な解決策が文書化されたことを示します。
重要な理由「Workaround Publication Lead Time」KPIを支えます。インシデントの影響が軽減されたことを示します。入手先 PBM:Problem Investigationフォームの「Workaround」テキストフィールドの変更。取得「Workaround」フィールドの内容を比較し、nullではない更新を確認イベントタイプ inferred
	変更リクエストを開始	Infrastructure Change RequestをProblem Investigationに関連付けることです。実装段階の開始を示します。
重要な理由「Root Cause to Change Lead Time」KPIの測定と、ProblemプロセスとChangeプロセスの間にあるサイロの特定に重要です。入手先 PBM:Investigation_Associationsテーブル、または「Infrastructure Change ID」フィールドへの値の設定。取得 PBM:Investigation_Associationsに関連付けが作成された時点で記録イベントタイプ explicit
	根本原因を特定	問題レコードが原因の判明を示す状態へ移行した時点です。「Status」が「Root Cause Identified」に変更された時点から推定します。
重要な理由「Root Cause Investigation Cycle Time」ダッシュボードにおける重要なマイルストーンです。分析から解決策の策定への移行を示します。入手先 PBM:Problem Investigationフォームの「Status」フィールド＝「Root Cause Identified」。取得 Root Cause Identifiedへの移行についてStatusフィールドを比較イベントタイプ inferred
	解決を検証	恒久対応が正常に完了したことを確認した時点です。「Status」が「Solution Implemented」または「Completed」に変更されたことから推定します。
重要な理由「Problem SLA Adherence Rate」に使用します。技術的な作業が完了したことを確認します。入手先 PBM:Problem Investigationフォームの「Status」フィールド＝「Solution Implemented」または「Completed」。取得 Solution Implementedへの移行についてStatusフィールドを比較イベントタイプ inferred
	調査開始	問題レコードがアクティブな分析段階へ移行したことを示します。「Status」フィールドが「Under Investigation」に変更された時点から推定します。
重要な理由実際の作業段階の開始を示し、「Investigation Cycle Time」KPIを支えます。入手先 PBM:Problem Investigationフォームの「Status」フィールド＝「Under Investigation」。取得調査開始への移行についてStatusフィールドを比較イベントタイプ inferred
	Known Errorへ昇格	問題調査に関連付けられたKnown Errorレコードを作成することです。関連レコードの作成イベントです。
重要な理由問題を正式に整理し、広く共有するとともに長期的に追跡できる状態になったことを示します。入手先 PBM:Problem Investigation IDに関連付けられたPBM:Known Errorレコードの作成。取得 PBM:Known Errorレコードの作成時に記録イベントタイプ explicit
	Solution Databaseを更新	レコードが「Solution Database」ステータスへ移行したことです。恒久対応が提案または特定されたことを示します。
重要な理由実装前の解決策定義の進捗を追跡します。入手先 PBM:Problem Investigationフォームの「Status」フィールド＝「Solution Database」。取得 Solution Databaseへの移行についてStatusフィールドを比較イベントタイプ inferred
	コーディネーターを再割り当て	サポートグループ内でProblem Coordinatorが変更されたことです。「Problem Coordinator」フィールドを監視して記録します。
重要な理由作業量の分配と、個人単位のリソースボトルネックの分析に役立ちます。入手先 PBM:Problem Investigationフォームの「Problem Coordinator」フィールド履歴。取得更新前後の「Problem Coordinator」フィールドを比較イベントタイプ inferred
	実装後レビューを実施	PIR段階が完了したことです。PIR状態から移行したこと、または関連するPIR Taskがクローズされたことによって記録します。
重要な理由「Post Implementation Review Compliance」とプロセス品質監査を直接支えます。入手先 PBM:Problem Investigationフォームの「PIR Required」フラグ、または「PIR」タイプの関連Taskの完了。取得 PIRステータスの完了、またはPIR Taskのクローズから導出イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

BMC Helix ITSMへのログイン Problem MasterまたはReport Administrator権限を持つ認証情報で、ミッドティアまたはSmart ITの画面にアクセスします。
Report Consoleへの移動 ApplicationsメニューからAR System Report Consoleを選択します。Smart ITを使用している場合は、Reportingダッシュボードに移動して「Web Report」を選択します。
新規レポートの作成 新規ボタン（緑色のプラスアイコン）をクリックして、レポートウィザードを開始します。
データソース（フォーム）の選択 「Form Name」フィールドで、PBM:AuditLogSystem（バージョンによってはPBM:Problem Investigation_AuditLog）を検索して選択します。注：PBM:Problem Investigationフォームには現在のケースデータが含まれますが、データ要件で必要とされる行単位のイベント履歴（再割り当てやステータス変更など）を生成するには、Audit Logフォームが必要です。
レポート名と種類の定義 説明的なタイトル（例：「Problem Management Event Log」）を入力し、形式をWeb Reportに設定します。
列（属性）の追加 Available Fieldsの一覧から次のフィールドを選択し、Selected Fieldsの一覧に移動します。
- Original Request ID（ProblemRecordにマッピング）
- Submit Date（EventTimeにマッピング）
- Fields Changed（アクティビティにマッピング）
- ユーザー（ユーザー／コーディネーターにマッピング）
- Log Key 1（通常は生のステータス値を保持）
フィルター（Qualification）の設定 フィルターまたはQualificationタブをクリックし、対象範囲を絞るクエリを作成します。
- Form Nameを「PBM:Problem Investigation」と等しく設定し、IncidentおよびChangeの監査を除外します。
- Submit Dateに対象期間を設定します（例：>= 01/01/2023）。
保存と実行 レポート設定を保存します。プレビューをクリックしてデータが返されることを確認し、その後Exportをクリックします。
CSVとしてエクスポート エクスポート形式としてCSV（Comma Separated Value）を選択します。ヘッダーが含まれていることを確認します。
属性用の追加エクスポート（推奨） PBM:Problem Investigationを対象に、2つ目のシンプルなレポートを作成します。Problem Investigation ID、Priority、ServiceCI、説明をエクスポートします。この「Case Attribute」ファイルを分析ツールでイベントログと結合すると、すべての監査ログ行に含まれていない推奨静的属性（Priority、Service CI）を追加できます。
データ変換（エクスポート後） ProcessMindにアップロードする前に、次の処理を行います。

Fields Changedの値を標準アクティビティにマッピングします（例：Field Changed = 「Status」の場合、Log Key 1の値を使用して「Investigation Commenced」または「Root Cause Identified」かを判定します）。
必要に応じて、プロセスに関係しない更新（外観上のフィールド更新など）を除外します。

設定

フォームの選択：主なデータソースにはPBM:AuditLogSystemを使用します。PBM:Problem Investigationから直接抽出すると、現在の状態しか取得できず、「Coordinator Reassigned」や「Workaround Defined」の履歴を記録できません。
日付による絞り込み：古いケースの最近のアクティビティも取得できるよう、ケースの作成日だけでなく、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フォームを表示する権限が必要です。制限されている場合は、システム管理者がこのエクスポートを実行する必要があります。

a サンプルクエリ 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 Server Management Studio、DBeaver、Oracle SQL Developerなどのお使いのSQLクライアントを開き、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へのインポート： 「Settings Overview」で定義されているとおりに列をマッピングし、整形済みCSVをProcessMindにアップロードします。

設定

期間：パフォーマンスとプロセスの可視性のバランスを考慮し、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のデータベースインデックスが利用されていることを確認してください。

a サンプルクエリ 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フォームを検索します。これにより、Problem Recordの基本情報を取得し、Submit Dateに基づいて「Problem Record Logged」イベントを作成するとともに、現在の属性を取得します。
履歴データの抽出：スクリプトは監査証跡を反復的に取得します。BMC Helixでは、履歴はPBM:AuditLogSystemに保存されているか、関連付けを通じて参照できる場合があります。提供されたスクリプトはAuditフォームを検索し、「Investigation Commenced」などの状態遷移や、「Assigned to Support Group」などのフィールド更新を取得します。
データ変換：スクリプトには、BMCのStatusコード（例：「Under Investigation」、「Root Cause Identified」）を、プロセス定義で必要となる特定のアクティビティ名にマッピングする処理が含まれています。
検証：少数のレコードだけを取得するドライランモードでスクリプトを実行し、フィールド名がカスタマイズ内容と一致することを確認します。コンソール出力で接続エラーがないか確認してください。
実行：抽出全体を実行します。スクリプトは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設定に照らして、マッピングを確認してください。

a サンプルクエリ 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からのエクスポート

ステップ

設定

a サンプルクエリ config

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

ステップ

設定

a サンプルクエリ sql

AR System REST APIを使用したPythonによる抽出

ステップ

設定

a サンプルクエリ python

準備はできましたか？

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

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

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

問題管理の属性

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

抽出ガイド

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

ステップ

設定

a サンプルクエリ config

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

ステップ

設定

a サンプルクエリ sql

AR System REST APIを使用したPythonによる抽出

ステップ

設定

a サンプルクエリ python

準備はできましたか？

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

プライバシーを大切にしています