> 継続的なプロセス改善 > 変更管理 > ServiceNow > データテンプレート

変更管理データテンプレート

ServiceNow

← 改善ガイドに戻る

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

変更管理データテンプレート

このテンプレートでは、変更管理ワークフローをプロセスマイニングで分析するために必要なデータを、体系的に収集できます。追跡を推奨する属性とアクティビティに加え、データ抽出の手順も紹介します。分析と改善に向けたデータの準備にお役立てください。

収集を推奨する属性
プロセスを正確に把握するために追跡する主なアクティビティ
ServiceNowからデータを抽出する手順

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

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

変更管理の属性

変更管理プロセスを詳しく分析するために、イベントログに含めることを推奨するデータフィールドです。

3 必須 7 推奨 9 任意

	名前	説明
	イベント時刻 EventTime	特定のアクティビティまたはイベントが発生した正確な時刻です。
説明イベント時刻には、アクティビティが実行された日時、または状態変更が記録された日時が保存されます。イベントを時系列に並べる際や、所要時間に基づく分析全般に欠かせないタイムスタンプです。プロセスマイニングでは、この属性を使ってサイクルタイム、処理時間、アクティビティ間の待ち時間を算出します。「変更承認サイクルタイム」や「変更プロセス全体のフロー」など、パフォーマンスを分析するダッシュボードにも欠かせません。正確なタイムスタンプは、遅延の特定やSLAに照らしたプロセス効率の測定の基盤となります。重要な理由イベントを正しい順序に並べ、サイクルタイム、所要時間、SLAの遵守状況など、時間に関するすべての指標を算出するうえで重要です。入手先 ServiceNowテーブル：sys_audit、フィールド：sys_created_on。記録された変更ごとのタイムスタンプを取得できます。例 2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
	変更要求ID ChangeRequestNumber	変更要求を一意に識別するIDです。関連するすべてのイベントをまとめるための主なケースIDとして使います。
説明変更要求IDは、変更管理プロセスの分析の基盤となる情報です。「CHG0030001」のように各変更要求に割り当てられる一意の番号で、関連するすべてのアクティビティ、承認、タスクを結び付けます。プロセスマイニングでは、この属性を使って個々の変更の一連の流れを再構成します。作成からクローズまでのライフサイクル全体を追跡できるため、各変更がシステム内でどのように進むかを一貫して把握できます。このIDでプロセスをグループ化して分析することは、サイクルタイムの算出、再作業の繰り返しの特定、プロセスのバリアントの把握に欠かせません。重要な理由変更のライフサイクル全体を追跡するために欠かせないIDです。要求ごとのプロセスフロー、所要時間、コンプライアンスを詳しく分析できます。入手先 ServiceNowテーブル：change_request、フィールド：number 例 CHG0030001CHG0030045CHG0030112
	アクティビティ名 ActivityName	変更管理プロセスで発生した特定のイベントまたはタスクの名前です。
説明アクティビティ名は、変更要求のライフサイクルにおける個別の手順や状態変更を表します。例として、「変更要求の評価待ち」「承認依頼」「変更の実施完了」などがあります。これらのアクティビティが、検出されたプロセスマップのノードになります。アクティビティを分析すると、プロセスフローを詳しく調べられます。アクティビティの順序や発生頻度を追跡することで、組織はよくある経路、標準プロセスからの逸脱、変更が滞りやすいボトルネックを特定できます。プロセスの可視化や、手順間の遷移時間などの指標の算出にも欠かせません。重要な理由プロセスマップの基盤となり、プロセスフローの可視化、ボトルネックの特定、逸脱の分析に役立ちます。入手先 change_requestテーブルの「state」フィールドやその他の主要な状態フィールドの変更から取得します。多くの場合、記録先は「sys_audit」テーブルです。例変更承認実施開始変更のクローズ変更のキャンセル
	リスクレベル RiskLevel	評価された変更のリスクレベルです。「高」「中」「低」などがあります。
説明リスクレベルは、変更要求のリスク評価プロセスの結果です。変更を実施した場合に悪影響が生じる可能性を数値化し、必要な精査や承認の水準を決める際に役立ちます。この属性は、「リスク評価の標準化」ダッシュボードで、同様の変更に一貫したリスク評価が行われているかを確認するために使います。リスクレベル別にプロセスフローを分析すると、高リスクの変更が低リスクの変更よりも厳格な承認・テストの手順に従っているかも確認できます。これは重要なコンプライアンスチェックです。重要な理由コンプライアンス分析に欠かせません。高リスクの変更が適切に精査され、より厳格なプロセスに従っているかを確認できます。入手先 ServiceNowテーブル：change_request、フィールド：risk 例高中低
	優先度 Priority	変更要求の影響度と緊急度に基づいて決まる優先度です。
説明優先度は変更要求の重要性を示し、対応する順序を決めるために使います。変更の影響度と緊急度から決まることが多く、「重大」「高」「中」「低」などの値があります。優先度別の分析は、優先度の高い変更を低い変更よりも速やかに処理できているかを確認するうえで欠かせません。「重大な変更のパフォーマンス」ダッシュボードでは、特に重要な変更のサイクルタイムや失敗率を追跡できます。優先度の低い変更が高い変更よりも早く完了している場合、リソース配分やプロセスの実行に問題がある可能性があります。重要な理由最も重要な変更にリソースが適切に割り当てられているかを評価し、そのパフォーマンスを個別に監視するうえで重要です。入手先 ServiceNowテーブル：change_request、フィールド：priority 例 1 - 重大2 - 高3 - 中4 - 低
	変更状態 ChangeState	変更要求の現在または過去の状態です。「Assess」「Authorize」「Implement」「Closed」などがあります。
説明変更状態属性は、ある時点における変更要求の状態を表します。変更のライフサイクルのどの段階にあるかを大まかに把握できます。特定のイベントを表すアクティビティとは異なり、状態はそのイベントの結果として生じた状況を示します。分析では、変更状態を使ってケースを分類し、結果を把握します。たとえば、「Closed」の変更だけを分析したり、多くの変更が「Authorize」状態で滞留している理由を調べたりする際に役立ちます。「Failed」状態がある場合は、「変更失敗率」などの重要業績評価指標（KPI）の分析にも直接役立ちます。重要な理由変更要求の状態を把握し、結果の分析、ケースの絞り込み、滞留している変更の特定に役立ちます。入手先 ServiceNowテーブル：change_request、フィールド：state 例評価承認スケジュール済み実施レビュークローズキャンセル
	変更種別 ChangeType	変更の分類です。「Standard」「Normal」「Emergency」などがあります。
説明変更種別は、変更要求の性質、リスク、承認要件に基づいて分類します。「Standard」は事前承認済み、「Normal」は通常のプロセスに従い、「Emergency」は迅速な経路で処理します。変更種別ごとに正当なプロセスモデルが異なるため、プロセス分析の基本的な切り口となります。「Normal」と「Emergency」のパフォーマンスを比較すると、プロセスの遵守状況や効率に関する重要なインサイトが得られます。「リスク評価の標準化」などのダッシュボードでも使われ、同様の変更が一貫して扱われているかを確認できます。重要な理由変更種別ごとに承認されたプロセスフローやパフォーマンスの基準が異なるため、分析対象を分けて確認できます。入手先 ServiceNowテーブル：change_request、フィールド：type 例標準通常緊急
	担当グループ AssignmentGroup	変更要求を担当するチームまたはグループです。
説明担当グループは、変更要求を現在担当しているチームを示します。「CAB Approval」「Network Engineering」「Database Administrators」などがあります。部門ごとのプロセスパフォーマンスを分析する際の重要な切り口です。この属性を使ってチーム単位の効率を測定し、特定のグループ内のボトルネックを特定し、チーム間の引き継ぎの有効性を分析できます。「部門横断の引き継ぎ効率」や「変更実施の処理量」などのダッシュボードでは、このデータを使って部門間の依存関係による遅延を特定します。重要な理由チーム別のパフォーマンスを分析し、グループ固有のボトルネックを把握するとともに、部門間の引き継ぎの効率を測定できます。入手先 ServiceNowテーブル：change_request、フィールド：assignment_group 例 CAB承認ネットワークチームサーバーサポートデータベース管理者
	構成アイテム ConfigurationItem	変更の対象となる特定のITコンポーネント、サービス、またはシステムです。
説明構成アイテム（CI）は、変更の影響を受ける構成管理データベース（CMDB）内の資産です。サーバー、ソフトウェアアプリケーション、ネットワーク機器、業務サービスなどが該当します。この属性は、変更に関する重要なコンテキストを示します。プロセスマイニングでは、変更対象の資産の種類ごとに分析できます。たとえば、「変更テスト期間分析」ダッシュボードでは、この属性を使ってアプリケーションやシステムごとのテスト時間を比較し、テストサイクルが長いCIを特定します。重要な理由業務上の重要なコンテキストを示し、影響を受けるアプリケーション、サービス、システムで分析を絞り込んで、コンポーネント固有の問題を特定できます。入手先 ServiceNowテーブル：change_request、フィールド：cmdb_ci 例 SAP ERPOracle Database 19cメールサービスWebServer-01
	終了時刻 EndTime	アクティビティが終了した時刻です。多くの場合、次のアクティビティの開始時刻から算出します。
説明終了時刻は、アクティビティが完了した時刻を示します。ソースシステムにはイベントの開始時刻が記録されることが多いため、終了時刻は推定する場合があります。通常、同じケース内で次に発生するアクティビティのタイムスタンプを使って算出します。この属性は、処理時間と呼ばれる各アクティビティの所要時間を算出するために欠かせません。各手順にかかる時間を把握することは、プロセスのボトルネックや非効率な箇所の特定に役立ちます。ケースの最後のアクティビティでは、終了時刻と開始時刻は同じです。重要な理由アクティビティの処理時間を算出できるため、ボトルネックの特定や個々のプロセス手順にかかる時間の測定に役立ちます。入手先通常、データ変換時に、同じケースで次に発生するイベントのStartTimeを使って算出します。例 2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
	SLAの状態 SlaState	変更依頼のサービスレベル契約（SLA）に対する状況です。「順調」「リスクあり」「期限超過」などがあります。
説明 SLAの状態は、変更依頼がSLAで定められた期限内に進んでいるかを示します。プロセスの各段階で状況を追跡できます。この属性は、サービスレベルの合意事項へのコンプライアンスを監視するうえで欠かせません。「変更SLAパフォーマンスの概要」ダッシュボードと「変更SLA遵守率」KPIの主なデータソースです。SLAの期限超過が発生する箇所と理由を分析することで、組織全体に及ぶ遅延に対処し、サービス提供の予測可能性を高められます。重要な理由期限に対するパフォーマンスを直接測定し、SLAの期限超過を先回りして監視・分析することで、サービス提供の改善に役立ちます。入手先 ServiceNowのtask_slaテーブルから取得できます。このテーブルでは、変更依頼などのタスクに関連するSLAを追跡します。または、期限のフィールドをもとに算出できます。例順調リスクあり期限超過
	クローズコード CloseCode	変更依頼を終了した際の結果を示すコードです。「成功」や「失敗」などがあります。
説明クローズコードには、完了した変更依頼の最終結果が記録されます。変更が問題なく実施されたか、問題が発生したか、またはロールバックされたかを正式に示します。この属性は「変更失敗率」KPIの算出に直接使われます。クローズコードの内訳を分析することで、変更施策の成功状況を定量的に把握できます。プロセスマップでクローズコードが「失敗」の変更を絞り込むと、失敗につながる共通のプロセスパターンが見つかり、根本原因の分析に役立ちます。重要な理由変更の結果を直接測定し、変更失敗率の算出や失敗した変更の根本原因分析に必要なデータを提供します。入手先 ServiceNowのテーブル：change_request、フィールド：close_code 例成功問題ありで成功失敗／ロールバック
	サイクルタイム CycleTime	変更依頼の作成から終了までにかかった合計時間です。
説明サイクルタイムは、変更依頼のライフサイクル全体にかかった時間を測定するケース単位の指標です。変更依頼ごとに、最初のイベントと最後のイベントのタイムスタンプの差として算出します。プロセス全体の処理速度を測る重要業績評価指標（KPI）です。「変更プロセスのエンドツーエンドフロー」ダッシュボードで、プロセスのパフォーマンスを概観するために使われます。サイクルタイムの推移を分析し、変更タイプや優先度などの属性ごとに比較すると、組織がプロセスを改善する機会を見つけやすくなります。重要な理由変更プロセス全体にかかる時間を測定し、プロセス全体の処理速度と効率を示す重要な指標となります。入手先データ分析時にケース単位で算出します。各CaseIdについて、StartTimeの最大値から最小値を差し引きます。例 60480012096002592000
	ソースシステム SourceSystem	データの抽出元のシステムです。通常は「ServiceNow」です。
説明この属性は、プロセスデータの取得元を示します。ここではServiceNowが想定されていますが、データガバナンスや複数システムのデータを統合する場合にも欠かせないフィールドです。分析では、データの来歴を明確にし、データの取得元を検証するのに役立ちます。複数のITSMツールや統合システムを使う組織では、この属性で異なるプラットフォームのプロセスを絞り込み、比較できます。重要な理由プロセスデータの取得元を文書化して来歴を明確にするため、データガバナンスや複数システムの分析に役立ちます。入手先通常、データの抽出・変換（ETL）時に追加される固定値です。例 ServiceNowServiceNow_PRODSNOW_ITSM
	最終データ更新時刻 LastDataUpdate	このレコードのデータがソースシステムから最後に更新された時刻を示すタイムスタンプです。
説明この属性には、データを最後に抽出した時刻が記録されます。分析対象のデータがどの程度新しいかを把握するための重要なメタデータです。分析担当者はこのタイムスタンプを確認し、最新の情報を使っていることや、データの更新時期を把握します。進行中のプロセスのパフォーマンスを監視する運用ダッシュボードでは特に重要です。古いデータに基づいて判断することを防げます。重要な理由データの新しさを示し、分析やダッシュボードで最新かつ関連性の高い情報を使えるようにします。入手先データの抽出・変換（ETL）時に生成されるメタデータで、データを取得した時刻を示します。例 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	影響度 Impact	変更が業務に及ぼす可能性のある影響です。「高」「中」「低」などの段階で評価します。
説明影響度は、変更要求が適切に処理されなかった場合に業務へ及ぶ可能性のある影響を示します。緊急度とともに、変更の優先度を決める際の重要な要素です。影響度別に分析すると、重要なサービスに影響する変更が適切な注意を払って管理されているかを確認できます。「重大な変更のパフォーマンス」ダッシュボードでは、業務への影響が大きい変更を絞り込んで監視します。また、リスク評価の一貫性を検証し、影響度の高い変更に正当な理由なく低いリスクレベルが割り当てられていないかを確認できます。重要な理由業務への影響の可能性に基づいて変更の優先順位を付け、影響度の高い変更が適切な注意を払って管理されているかを検証できます。入手先 ServiceNowテーブル：change_request、フィールド：impact 例 1 - 高2 - 中3 - 低
	手戻りかどうか IsRework	アクティビティが同じケース内の前のステップの繰り返しにあたる場合にtrueとなるブール値フラグです。
説明この計算属性は、手戻りにあたるアクティビティを特定します。手戻りとは、承認後に変更が却下されて再評価に戻される場合のように、すでに完了したステップにプロセスが戻ることです。このフラグは、プロセスの非効率性を定量化するうえで重要です。「変更手戻り率」KPIと「変更の失敗と手戻り分析」ダッシュボードに直接利用できます。「手戻りかどうか」がtrueのアクティビティに絞り込むと、初期評価の不足や要件の変更など、手戻りの原因を特定して調査し、無駄の削減につなげられます。重要な理由繰り返し作業を特定してプロセスの非効率性を定量化し、プロセスのループや無駄な作業の根本原因を見つけて対処するのに役立ちます。入手先データ変換時に、該当するCaseIdで同じアクティビティ（または標準フロー上のそれ以前のアクティビティ）がすでに発生しているかを判定して算出します。例 truefalse
	担当ユーザー AssignedToUser	特定の時点で変更要求を担当するユーザーです。
説明この属性は、変更要求の作業を担当するユーザーを示します。要求が異なる段階やチームに移る過程で、担当者が何度も変わることがあります。ユーザー別に分析すると、作業負荷の分布や個人のパフォーマンスを把握し、トレーニングが必要な箇所を特定できます。担当グループと組み合わせると、担当者間で作業がどれだけ効率よく引き継がれているかを分析する際にも役立ちます。重要な理由ユーザーごとの作業負荷やパフォーマンスの追跡に役立ち、担当者間の引き継ぎの遅延を分析するうえでも重要です。入手先 ServiceNowテーブル：change_request、フィールド：assigned_to 例 Beth AnglinDavid LooAbel Tuter
	緊急度 Urgency	変更を解決する必要性の高さを、高・中・低などの段階で示したものです。
説明緊急度は、変更をどれだけ早く実施する必要があるかを示します。業務の観点から、依頼の時間的な切迫度を表します。影響度とともに、全体の優先度を算出するために使われます。分析では優先度が主な項目となりますが、緊急度を確認することで、背景をさらに把握できます。特定の変更が緊急とされる理由や、安定性を損なわずにプロセスで対応できているかを調べる際に役立ちます。また、組織が緊急度の高い依頼への事後対応に追われていないかを確認できます。重要な理由変更の時間的な切迫度を把握し、期限の厳しい依頼にプロセスが適切に対応できているかを分析するための情報です。入手先 ServiceNowのテーブル：change_request、フィールド：urgency 例 1 - 高2 - 中3 - 低

必須推奨任意

変更管理のアクティビティ

変更管理プロセスを正確に把握するために、イベントログに記録する主なプロセスステップとマイルストーンです。

7 推奨 6 任意

	アクティビティ	説明
	リスクと影響の評価完了	変更要求のリスクと影響の分析が完了したことを示します。承認を求める前の重要な節目であり、状態が「Assess」から「Authorize」または「Awaiting Approval」に変わった時点から推定することがよくあります。
重要な理由評価段階にかかった時間を追跡することは、「平均リスク評価サイクルタイム」の重要業績評価指標（KPI）の算出に欠かせません。評価プロセスの標準化や、分析に時間がかかりすぎている箇所の特定にも役立ちます。入手先 change_requestテーブルの「state」フィールドが「Assess」から「Authorize」に変わったことから推定します。イベントのタイムスタンプは、この状態変更の監査ログから取得します。記録「state」フィールドが「Assess」から「Authorize」などの次の状態に変わった時点を特定します。イベントタイプ inferred
	変更のキャンセル	実施が完了する前に、変更要求が取り下げられた、または中止された状態です。「state」フィールドが「Canceled」に設定された時点で記録される、別の終了状態です。
重要な理由キャンセルされた変更を分析すると、不要な要求が作成されている、承認待ちが長引いている間に要求が古くなっているなど、プロセスの非効率な箇所が見つかることがあります。入手先 change_requestテーブルの「state」フィールドが「Canceled」に設定されたことから推定します。この状態変更のタイムスタンプは監査ログから取得します。記録「state」フィールドが「Canceled」に更新された時刻を記録します。イベントタイプ inferred
	変更のクローズ	変更要求が正常に完了し、レビューも終えて、終了した状態です。プロセスの主な完了地点であり、変更の状態が「Closed」に変わった時点で記録されます。
重要な理由変更のライフサイクルが正常に完了したことを示します。プロセス全体の所要時間とSLAの遵守状況を測定する際の終了イベントです。入手先 change_requestテーブルの「state」フィールドが「Closed」に設定されたことから推定します。この最終状態への変更時刻は監査履歴から取得します。記録「state」フィールドが「Closed」に更新された時刻を記録します。イベントタイプ inferred
	変更のスケジュール設定	承認された変更に計画上の開始日と終了日が設定され、正式に実施カレンダーに登録された状態です。変更要求の状態が「Scheduled」に変わった時点から推定します。
重要な理由このアクティビティは、計画・承認段階と実施段階を区切ります。この状態にとどまった時間から、承認後に作業を開始するまでの遅延を把握できます。入手先 change_requestテーブルの「state」フィールドが「Scheduled」に変わったことから推定します。タイムスタンプは、対応する監査ログの記録から取得します。記録 change_requestテーブルの監査履歴で、「state」フィールドが「Scheduled」に変わった記録を追跡します。イベントタイプ inferred
	変更の実施完了	実施作業が完了し、変更のレビュー、検証、またはテストに進める状態です。変更要求の状態が「Implement」から「Review」に変わった時点から推定します。
重要な理由実施段階の完了を示す重要な節目です。「変更失敗率」と「変更再作業率」の重要業績評価指標（KPI）の算出に欠かせないイベントです。入手先状態が「Implement」から「Review」などの次の状態に変わったことから推定します。タイムスタンプは、change_requestテーブルの「state」フィールドの監査履歴から取得します。記録「state」フィールドが「Implement」から「Review」に変わった時点を特定します。イベントタイプ inferred
	変更承認	変更要求に必要な承認がすべて完了し、スケジュール設定と実施に進める状態です。最終承認が下り、「approval」フィールドが「approved」に設定された時点で記録される重要な節目です。
重要な理由この節目をもって承認段階が完了します。承認サイクルの所要時間の測定や、意思決定プロセスのボトルネックの特定に欠かせません。入手先 change_requestテーブルの「approval」フィールドが「approved」に変わったことから推定します。タイムスタンプは、この変更の監査履歴から取得します。記録「approval」フィールドが「approved」になった時刻を記録します。イベントタイプ inferred
	変更要求の作成	システムに新しい変更要求レコードが作成されたことを示すアクティビティです。change_requestテーブルに新しいレコードが追加された時点で記録され、変更管理プロセスの正式な開始となります。
重要な理由このプロセスの主な開始イベントです。このアクティビティからほかのアクティビティまでの時間を分析すると、全体のリードタイムを把握し、プロセスの初期段階で発生する遅延を特定できます。入手先 ServiceNowのchange_requestテーブルにあるレコード作成時刻（sys_created_on）に対応するイベントです。記録 change_requestテーブルのsys_created_onタイムスタンプを使用します。イベントタイプ explicit
	レビュー中	変更が成功し、目標を達成したかを確認するため、実施後レビュー（PIR）を行っている状態です。変更要求の状態が「Review」に設定された時点で記録されます。
重要な理由レビュー段階にかかった時間を分析すると、変更の成功を検証する際の遅延を特定できます。また、この手順が省略されたコンプライアンス違反の変更も把握できます。入手先 change_requestテーブルの「state」フィールドが「Review」に変わったことから推定します。この状態変更のタイムスタンプは監査ログから取得します。記録 change_requestの監査履歴から、「state」フィールドが「Review」に変わった時刻を記録します。イベントタイプ inferred
	変更の再オープン	変更要求が後の段階に進んだ後、「Implement」や「Assess」などの前の状態に戻されたことを示します。通常とは異なる状態遷移から推定され、再作業が発生したことを表します。
重要な理由このアクティビティは、再作業の繰り返しを特定し、「変更再作業率」を算出するうえで重要です。再オープンが頻繁に発生する場合、実施の品質、テスト、または計画に問題がある可能性があります。入手先 change_requestの監査履歴にある状態変更の順序を分析して推定します。後の状態（例：「Review」）から前の状態（例：「Implement」）への遷移が、再オープンを示します。記録「state」フィールドの履歴から、順序どおりではない後戻りの遷移を検出します。イベントタイプ inferred
	変更却下	承認者またはCABが変更要求を却下した状態です。修正して再提出しない限り、要求はここで終了します。「approval」フィールドが「rejected」に設定された時点で記録されます。
重要な理由却下を追跡すると、情報不足やリスクの高さなど、よくある却下理由を特定できます。この分析は、今後提出される変更要求の品質向上に役立ちます。入手先 change_requestテーブルの「approval」フィールドが「rejected」に変わったことから推定します。タイムスタンプは監査履歴から取得します。記録「approval」フィールドが「rejected」になった時刻を記録します。イベントタイプ inferred
	変更要求の評価待ち	変更要求が提出され、技術面と業務面の評価を待っている状態です。通常、変更要求の状態が「Assess」などに変わった時点から推定します。これは、下書きの段階を終えたことを示します。
重要な理由このアクティビティを使うと、申請者から評価チームへの最初の引き継ぎにかかる時間を測定できます。ここで遅延が発生している場合、初期データの品質や評価に必要なリソースの確保に問題がある可能性があります。入手先 change_requestテーブルの「state」フィールドが、通常は「Assess」などの値に変わったことから推定します。タイムスタンプには、このフィールドの変更に関する監査履歴（sys_audit）を使用します。記録 change_requestテーブルの監査履歴で、「state」フィールドが「Assess」に変わった記録を追跡します。イベントタイプ inferred
	実施開始	変更の実施作業が始まった状態です。変更要求の「state」フィールドが「Implement」に更新された時点で記録され、計画から実行への移行を示します。
重要な理由実際の実施作業の開始を示します。「平均実施期間」の重要業績評価指標（KPI）の測定や、チームの業務効率の分析における起点となります。入手先 change_requestテーブルの「state」フィールドが「Implement」に変わったことから推定します。この状態変更のタイムスタンプは監査ログから取得します。記録 change_requestの監査履歴から、「state」フィールドが「Implement」に変わった時刻を記録します。イベントタイプ inferred
	承認依頼	変更要求が、通常はマネージャーまたは変更諮問委員会（CAB）に正式に提出され、承認を求めていることを示します。変更要求の承認状態が「requested」に設定された時点で記録されます。
重要な理由承認サイクルの開始を示します。このイベントから「変更承認」までの時間を測定すると、「変更承認の平均所要時間」の重要業績評価指標（KPI）を直接算出できます。入手先 change_requestテーブルの「approval」フィールドが「requested」に変わったことから推定します。タイムスタンプは、このフィールドに関するsys_auditテーブルの記録から取得します。記録 change_requestテーブルの「approval」フィールドが「requested」に設定された時刻です。イベントタイプ inferred

推奨任意

データ抽出ガイド

ServiceNowからデータを取得する方法

ステップ

itilロール、または変更管理モジュールに対する同等の読み取り権限を持つユーザーアカウントで、ServiceNowインスタンスにログインします。
変更要求の基本データをエクスポート：Change > Allを開き、すべての変更要求を表示します。フィルターの漏斗アイコンを使って、対象期間（例：作成日が過去3か月以内）を指定します。
エクスポートする列の設定：任意の列見出しを右クリックし、Configure > List Layoutを選択します。次の列を「Selected」リストに追加します：数値、sys_created_on、sys_updated_on、state、assignment_group、type、priority、risk、cmdb_ci。保存をクリックします。
変更要求データのエクスポート：リスト表示にフィルターを適用し、列を設定したら、任意の列見出しを再度右クリックします。Exportに移動し、CSVを選択します。システムがダウンロード用のファイルを作成します。このファイルには、状態に基づくアクティビティに必要なデータが含まれます。
承認データのエクスポート：ナビゲーションフィルターにsysapproval_approver.listと入力し、Enterキーを押します。すべての承認を一覧表示する画面が開きます。
承認の絞り込みとエクスポート：フィルターの漏斗アイコンを使い、変更に関する承認だけを表示します。条件をSource table is change_request AND 作成日が過去3か月以内に設定します。承認者、ステータス、作成済み、更新済み、文書ID（変更要求番号が含まれます）などの列をリストレイアウトに追加します。このリストを別のCSVファイルにエクスポートします。
データの結合と変換：この手作業には、表計算ソフトまたは簡単なスクリプトが必要です。2つのCSVファイルを開き、アクティビティごとに1行を含む単一のイベントログを作成します。
変更要求のステータス変更を対応付け：変更要求データファイルに、各ステータス遷移の行を作成します。例：
- 変更要求の作成：sys_created_onのタイムスタンプを使用します。
- 変更の評価待ち：stateフィールドが初めて'Assess'になったときのsys_updated_onを使用します。
- 実装開始：stateフィールドが初めて'Implement'になったときのsys_updated_onを使用します。
- その他のステータスに基づくアクティビティ（変更のスケジュール済み、変更の実装済み、レビュー中、変更のクローズ、変更のキャンセル）は、stateフィールドが該当する値に変わったときのsys_updated_onから推定します。
承認イベントの対応付け：承認データファイルで、文書ID（変更要求番号）を使ってデータをメインの変更要求ファイルに結合します。
- 承認依頼：承認レコードのステータスが'requested'である場合、そのレコードの作成済みタイムスタンプを使用します。
- 変更の承認：変更のステータスを'approved'にした最終承認レコードの更新済みタイムスタンプを使用します。
- 変更の却下：承認レコードのステータスが'rejected'になったときの更新済みタイムスタンプを使用します。
最終イベントログの作成：これまでの手順で作成した行を1つのテーブルにまとめます。列名が正しく設定されていることを確認します：ChangeRequestNumber、ActivityName、EventTime、その他の推奨属性。
保存とアップロード：結合して形式を整えたデータを単一のCSVファイルとして保存します。このファイルをプロセスマイニングツールにアップロードできます。

設定

主なテーブル：基本データは、変更の詳細と状態遷移を記録するchange_requestと、承認イベントを記録するsysapproval_approverの2つのテーブルから抽出します。
日付範囲のフィルター：通常は作成日（sys_created_on）を基準に、すべてのエクスポートに一貫した日付範囲のフィルターを適用します。初回の分析では、3～6か月分のデータを推奨します。
状態モデル：抽出ロジックは、組織で使用しているServiceNowの変更依頼の状態モデルに大きく左右されます。標準の状態はAssess、Authorize、Scheduled、Implement、Review、Closed、Canceledです。設定と一致することを確認してください。
必要な権限：エクスポートを行うユーザーには、少なくともitilロール、またはchange_requestとsysapproval_approverの両テーブルへの読み取りアクセス権を持つカスタムロールが必要です。
エクスポート形式：データの加工や結合がしやすいCSV形式でエクスポートしてください。XLS形式では行数に制限がある場合があり、日付形式が変わることもあります。

クエリの例 config

This method uses the ServiceNow UI for filtering and exporting, not a direct script. The configuration below outlines the filters and columns for each required export.

**Export 1: Change Request Data**
*   **Navigate to Table**: `change_request.list`
*   **Filter Conditions**:
    *   `Created` `on` `Last 3 months` (or your desired date range)
    *   AND `Type` `is one of` `Normal, Standard, Emergency` (as needed)
*   **Columns to Select/Export**:
    *   `number` (maps to ChangeRequestNumber)
    *   `sys_created_on` (used for 'Change Request Created' EventTime)
    *   `sys_updated_on` (used as EventTime for most state changes)
    *   `state` (maps to ChangeState)
    *   `assignment_group` (maps to AssignmentGroup)
    *   `type` (maps to ChangeType)
    *   `priority` (maps to Priority)
    *   `risk` (maps to RiskLevel)
    *   `cmdb_ci` (maps to ConfigurationItem)

**Export 2: Approval Data**
*   **Navigate to Table**: `sysapproval_approver.list`
*   **Filter Conditions**:
    *   `Source table` `is` `change_request`
    *   AND `Created` `on` `Last 3 months` (or your desired date range)
*   **Columns to Select/Export**:
    *   `document_id` (used to link to the Change Request Number)
    *   `state` (approval state: requested, approved, rejected)
    *   `sys_created_on` (used for 'Approval Requested' EventTime)
    *   `sys_updated_on` (used for 'Change Approved'/'Change Rejected' EventTime)

**Post-Export Transformation Logic (to be performed in a spreadsheet or script)**:

For each unique Change Request Number, create the following rows based on the data from the exported files. Timestamps should be from `sys_updated_on` unless specified otherwise.

1.  `ActivityName`: 'Change Request Created', `EventTime`: `sys_created_on` from change_request export.
2.  `ActivityName`: 'Change Awaiting Assessment', `EventTime`: Timestamp when `state` becomes 'Assess'.
3.  `ActivityName`: 'Risk And Impact Assessed', `EventTime`: Timestamp when `state` changes from 'Assess' to 'Authorize'.
4.  `ActivityName`: 'Approval Requested', `EventTime`: `sys_created_on` from sysapproval_approver export where approval `state` is 'requested'.
5.  `ActivityName`: 'Change Approved', `EventTime`: `sys_updated_on` from sysapproval_approver export when final approval `state` becomes 'approved'.
6.  `ActivityName`: 'Change Rejected', `EventTime`: `sys_updated_on` from sysapproval_approver export when approval `state` becomes 'rejected'.
7.  `ActivityName`: 'Change Scheduled', `EventTime`: Timestamp when `state` becomes 'Scheduled'.
8.  `ActivityName`: 'Implementation Started', `EventTime`: Timestamp when `state` becomes 'Implement'.
9.  `ActivityName`: 'Change Implemented', `EventTime`: Timestamp when `state` changes from 'Implement' to 'Review'.
10. `ActivityName`: 'Review In Progress', `EventTime`: Timestamp when `state` becomes 'Review'.
11. `ActivityName`: 'Change Reopened', `EventTime`: Inferred from a non-linear state change (e.g., 'Review' back to 'Implement'). This is difficult to capture with this method and often requires manual inspection or analysis of audit data.
12. `ActivityName`: 'Change Closed', `EventTime`: Timestamp when `state` becomes 'Closed'.
13. `ActivityName`: 'Change Canceled', `EventTime`: Timestamp when `state` becomes 'Canceled'.

ステップ

前提条件と認証：itilおよびrest_serviceロールを持つServiceNowユーザーアカウントを用意します。このロールにより、変更依頼データの読み取りとREST APIの利用に必要な権限が付与されます。このユーザーの認証情報を、基本認証（ユーザー名とパスワード）または、より安全なプログラムによるアクセスが可能なOAuth 2.0クライアントの設定で用意します。
ServiceNowインスタンスの確認：ServiceNowインスタンスのURLを確認します。通常、形式はhttps://[your-instance].service-now.comです。
抽出環境の準備：REST APIを呼び出すスクリプトを実行できるNode.jsやPythonなどの環境を用意します。ここに示すクエリ例では、Node.js環境でJavaScriptを使用します。
初回データ取得（変更依頼）：まずchange_requestテーブルをクエリします。sysparm_query URLパラメーターを使い、分析対象期間内に作成された変更依頼に絞り込みます（例：sys_created_onBETWEENjavascript:gs.dateGenerate('YYYY-MM-DD','start')@javascript:gs.dateGenerate('YYYY-MM-DD','end')）。この最初の呼び出しでは、各ケースの基本データとしてsys_id、number、および「変更依頼を作成」イベントのタイムスタンプ（sys_created_on）を取得します。
監査履歴の取得：前の手順で取得した各sys_idについて、sys_auditテーブルを呼び出します。tablenameがchange_requestで、documentkeyが変更依頼のsys_idと一致する監査レコードに絞り込みます。これにより、各ケースのフィールド変更履歴をすべて取得できます。
アクティビティ用の監査データ処理：変更依頼ごとにsys_auditレコードを確認します。スクリプトで、プロセスアクティビティに該当する特定の変更を識別します。たとえば、fieldnameがstateで、newvalueがScheduledのレコードは、「変更をスケジュール」アクティビティを表します。監査レコードのsys_created_onタイムスタンプをEventTimeとして使います。
「再開」アクティビティの特定：「再開」イベントを記録するには、標準的な状態の順序（例：Assess -> Authorize -> Scheduled -> Implement -> Review -> Closed）を定義します。状態変更ごとにoldvalueとnewvalueの順序を比較します。新しい状態が定義した順序で古い状態より前にある場合は、「変更を再開」アクティビティを作成します。
データの結合と対応付け：change_requestテーブルのデータ（作成イベント用）と、処理済みのsys_auditデータを1つのリストにまとめます。ServiceNowのフィールド名を、numberからChangeRequestNumber、sys_created_onからEventTime、導出したイベント名からActivityNameなど、必要なイベントログの列名に対応付けます。
イベントログの構成：結合したデータを構造化されたイベントログに整形します。各行には1つのアクティビティを記録し、最低限ChangeRequestNumber、ActivityName、EventTimeを含めます。
CSVへのエクスポート：最終的なイベントログをCSVファイルとして保存します。ProcessMindへのアップロードと分析に使えるよう、ヘッダー行を含め、UTF-8エンコーディングで保存してください。

設定

APIエンドポイント：主にクエリするテーブルはchange_requestとsys_auditです。APIエンドポイントは次のとおりです。
- https://[your-instance].service-now.com/api/now/table/change_request
- https://[your-instance].service-now.com/api/now/table/sys_audit
認証：スクリプトでは簡便さを優先して基本認証を使います。本番環境では、セキュリティを高めるためOAuth 2.0の利用を強く推奨します。OAuthを使う場合は、トークンの取得と更新の処理に対応するようスクリプトを変更してください。
日付範囲の指定：データ量を抑えるため、change_requestテーブルへの初回クエリには日付範囲のフィルターを必ず適用してください。プロセスマイニング分析では、通常3～12か月分のデータを対象にします。フィルターの例：sysparm_query=sys_created_on>=2023-01-01 00:00:00。
フィールドの選択（sysparm_fields）：APIのパフォーマンスを高め、ネットワーク通信量を減らすため、sysparm_fieldsパラメーターで必要な列だけを指定します。change_requestでは、sys_id、number、sys_created_on、assignment_group、type、priority、risk、cmdb_ciを指定します。
ページネーションの処理：大規模なデータセットの場合、ServiceNowはレコードを複数ページに分けて返します。sysparm_limitとsysparm_offsetパラメーターを使い、クエリ対象のレコードをすべて取得するまでページを順に処理するよう、スクリプトを設定してください。
監査テーブルの前提条件：この方法ではsys_auditテーブルを全面的に利用します。イベントログの作成に必要な履歴が記録されるよう、change_requestテーブルと、特にstate、approval、activeフィールドで監査が有効になっていることを確認してください。

クエリの例 javascript

const axios = require('axios');
const fs = require('fs');

// --- Configuration ---
const SN_INSTANCE = '[your-instance].service-now.com';
const SN_USER = '[your_username]';
const SN_PASSWORD = '[your_password]';
const START_DATE = '2023-01-01 00:00:00'; // Start date for changes to extract
const END_DATE = '2023-12-31 23:59:59';   // End date for changes to extract
const OUTPUT_FILE = 'servicenow_change_management_log.csv';

const auth = { username: SN_USER, password: SN_PASSWORD };

// Maps ServiceNow integer state values to human-readable names. Configure based on your system.
const STATE_MAP = {
    '-5': 'Draft',
    '-4': 'Assess',
    '-3': 'Authorize',
    '-2': 'Scheduled',
    '-1': 'Implement',
    '0': 'Review',
    '3': 'Closed',
    '4': 'Canceled',
    // Add any custom state values here
};

// Defines the standard process flow for detecting 'Reopened' events
const STATE_SEQUENCE = { 'Assess': 1, 'Authorize': 2, 'Scheduled': 3, 'Implement': 4, 'Review': 5, 'Closed': 6 };

// Function to fetch data with pagination
async function fetchAllRecords(table, query, fields) {
    let offset = 0;
    const limit = 1000;
    let allRecords = [];
    let hasMore = true;

    while (hasMore) {
        console.log(`Fetching ${table} records, offset: ${offset}`);
        const url = `https://${SN_INSTANCE}/api/now/table/${table}`;
        try {
            const response = await axios.get(url, {
                auth,
                params: {
                    sysparm_query: `${query}^sysparm_offset=${offset}^sysparm_limit=${limit}`,
                    sysparm_display_value: 'false', // Get raw values for mapping
                    sysparm_exclude_reference_link: true,
                    sysparm_fields: fields
                }
            });
            const records = response.data.result;
            if (records.length > 0) {
                allRecords = allRecords.concat(records);
                offset += limit;
            } else {
                hasMore = false;
            }
        } catch (error) {
            console.error(`Error fetching from ${table}:`, error.response ? error.response.data : error.message);
            hasMore = false;
        }
    }
    return allRecords;
}

// Main extraction function
async function extractChangeLog() {
    const eventLog = [];

    // 1. Get all change requests in the date range
    const changeQuery = `sys_created_on>=${START_DATE}^sys_created_on<=${END_DATE}`;
    const changeFields = 'sys_id,number,sys_created_on,assignment_group,type,priority,risk,cmdb_ci,state';
    const changes = await fetchAllRecords('change_request', changeQuery, changeFields);

    for (const change of changes) {
        // Activity: Change Request Created
        eventLog.push({
            ChangeRequestNumber: change.number,
            ActivityName: 'Change Request Created',
            EventTime: change.sys_created_on,
            ChangeState: STATE_MAP[change.state] || 'Unknown',
            AssignmentGroup: change.assignment_group,
            ChangeType: change.type,
            Priority: change.priority,
            RiskLevel: change.risk,
            ConfigurationItem: change.cmdb_ci
        });

        // 2. Get audit history for this change
        const auditQuery = `documentkey=${change.sys_id}^tablename=change_request^fieldnameINstate,approval`;
        const auditFields = 'sys_created_on,fieldname,oldvalue,newvalue';
        const auditRecords = await fetchAllRecords('sys_audit', auditQuery, auditFields);

        for (const audit of auditRecords) {
            let activityName = null;

            if (audit.fieldname === 'state') {
                const oldStateName = STATE_MAP[audit.oldvalue] || audit.oldvalue;
                const newStateName = STATE_MAP[audit.newvalue] || audit.newvalue;

                switch (newStateName) {
                    case 'Assess': activityName = 'Change Awaiting Assessment'; break;
                    case 'Authorize': activityName = 'Risk And Impact Assessed'; break;
                    case 'Scheduled': activityName = 'Change Scheduled'; break;
                    case 'Implement': activityName = 'Implementation Started'; break;
                    case 'Review':
                        // Per requirements, create two distinct events for the same timestamp
                        eventLog.push({ ...change, ActivityName: 'Change Implemented', EventTime: audit.sys_created_on, ChangeState: newStateName });
                        eventLog.push({ ...change, ActivityName: 'Review In Progress', EventTime: audit.sys_created_on, ChangeState: newStateName });
                        continue; // Skip the generic push at the end
                    case 'Closed': activityName = 'Change Closed'; break;
                    case 'Canceled': activityName = 'Change Canceled'; break;
                }
                // Check for 'Reopened' event
                if (STATE_SEQUENCE[oldStateName] && STATE_SEQUENCE[newStateName] && STATE_SEQUENCE[newStateName] < STATE_SEQUENCE[oldStateName]) {
                    eventLog.push({ ...change, ActivityName: 'Change Reopened', EventTime: audit.sys_created_on, ChangeState: newStateName });
                }

            } else if (audit.fieldname === 'approval') {
                if (audit.newvalue === 'requested') activityName = 'Approval Requested';
                if (audit.newvalue === 'approved') activityName = 'Change Approved';
                if (audit.newvalue === 'rejected') activityName = 'Change Rejected';
            }

            if (activityName) {
                eventLog.push({
                    ChangeRequestNumber: change.number,
                    ActivityName: activityName,
                    EventTime: audit.sys_created_on,
                    ChangeState: STATE_MAP[change.state] || 'Unknown', // Use the final state of the change for context
                    AssignmentGroup: change.assignment_group,
                    ChangeType: change.type,
                    Priority: change.priority,
                    RiskLevel: change.risk,
                    ConfigurationItem: change.cmdb_ci
                });
            }
        }
    }

    // 3. Convert to CSV and save
    if (eventLog.length > 0) {
        const header = Object.keys(eventLog[0]).join(',');
        const rows = eventLog.map(row => Object.values(row).map(val => `"${val || ''}"`).join(','));
        fs.writeFileSync(OUTPUT_FILE, `${header}\n${rows.join('\n')}`);
        console.log(`Extraction complete. Saved ${eventLog.length} events to ${OUTPUT_FILE}`);
    } else {
        console.log('No events found for the specified criteria.');
    }
}

extractChangeLog();

ステップ

前提条件：システムにPython 3.6以降がインストールされていることを確認します。コマンドラインまたはターミナルでpip install requests pandasを実行し、必要なPythonライブラリをインストールします。
ServiceNow APIユーザーの設定：ServiceNowで、このデータ抽出専用のサービスアカウントを作成します。最低限、change_requestテーブルへの読み取りアクセス権を持つitilロールを付与します。履歴データにアクセスするには、sys_auditおよびsysapproval_approverテーブルへの読み取りアクセス権も必要です。必要に応じて、テストを簡単にするためrest_api_explorerロールを割り当てます。
Pythonスクリプトの設定：提供されたPythonスクリプトをダウンロードします。ファイルを開き、先頭にあるプレースホルダー変数SERVICENOW_INSTANCE、SERVICENOW_USER、SERVICENOW_PASSWORDを、対象のインスタンスURLと前の手順で作成したユーザーの認証情報に置き換えます。
抽出パラメーターの設定：スクリプト内のsysparm_query変数を変更し、抽出する日付範囲と対象を指定します。初期設定では、過去180日間に更新された変更依頼を取得します。日付範囲を調整したり、結果を絞り込むためにactive=trueや特定の会社コードなどのフィルターを追加したりできます。
スクリプトの実行：ターミナルでpython your_script_name.pyを実行します。スクリプトがServiceNow REST APIに接続して認証を行い、変更依頼、その状態変更、承認履歴のデータを取得します。
ページネーションの処理：ServiceNowで設定された1ページあたりの上限を超えるレコードがある場合、スクリプトは複数回APIを呼び出してページネーションを自動処理します。進行状況はコンソールに表示されます。
データ変換：スクリプトはAPIから取得した生のデータをメモリ上で処理し、作成、状態遷移、承認などの主なイベントを特定します。次に、システムイベントを、イベントログに必要な「変更の評価待ち」や「変更を承認」などのわかりやすいActivityNameに対応付けます。
イベントログの統合：個々のイベントを1つの構造化されたpandas DataFrameにまとめます。このDataFrameには、各イベントに必要な属性と推奨属性が含まれ、すべての変更依頼の完全なタイムラインが作成されます。
出力の確認：スクリプトの実行が完了すると、同じディレクトリにservicenow_change_management_log.csvというCSVファイルが作成されます。ファイルを開き、抽出されたデータに問題がないことを確認します。
アップロードの準備：生成されたCSVファイルはProcessMindのイベントログ仕様に沿って整形されています。追加の整形は不要で、そのままアップロードできます。

設定

認証：スクリプトではユーザー名とパスワードによる基本認証を使います。セキュリティを高めるには、ServiceNowがサポートするOAuth 2.0を使うようスクリプトを変更してください。
ServiceNowのエンドポイント：スクリプトでは主に、変更の基本データ用の/api/now/table/change_request、過去のフィールド変更（特にstateフィールド）用の/api/now/table/sys_audit、承認と却下のイベント用の/api/now/table/sysapproval_approverという3つのREST APIエンドポイントを使います。
日付範囲の指定：日付範囲は、change_requestテーブルへのAPIリクエストでsysparm_queryパラメーターを使って指定します。詳細さとパフォーマンスのバランスを取るため、3～6か月分のデータを抽出することを推奨します。まずはsys_updated_on>=javascript:gs.daysAgo(180)のようなクエリから始められます。
レコード数の制限：APIへの過剰な負荷を避けるため、スクリプトはsysparm_limitパラメーターを使ってレコードをまとめて取得します。get_all_records関数が、繰り返し処理とオフセットの調整を自動で行います。
前提条件：少なくともitilロールを持つServiceNowユーザーアカウントが必要です。sys_auditとsysapproval_approverテーブルへの読み取りアクセス権も必要です。ServiceNowインスタンスでカスタムロールを使っている場合は、抽出対象のすべてのフィールドに読み取り権限があることを確認してください。
パフォーマンスに関する注意点：sys_auditテーブルへのクエリは、ServiceNowインスタンスのリソースを多く消費する場合があります。パフォーマンスへの影響を抑えるため、大規模なデータ抽出は業務の閑散時間帯に実行し、日付範囲を厳密に指定してください。

クエリの例 python

import requests
import pandas as pd
import getpass
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Enter your ServiceNow instance URL, for example, https://your-instance.service-now.com
SERVICENOW_INSTANCE = class="hl-string">"[Your ServiceNow Instance URL]"
SERVICENOW_USER = class="hl-string">"[Your ServiceNow API Username]"
class=class="hl-string">"hl-comment"># It is recommended to use a secure method for password management, such as environment variables or a secrets manager.
SERVICENOW_PASSWORD = getpass.getpass(class="hl-string">"Enter ServiceNow Password: ")

class=class="hl-string">"hl-comment"># --- State and Approval Mapping ---
class=class="hl-string">"hl-comment"># Maps ServiceNow integer state values to human-readable activity names
STATE_MAP = {
    class="hl-string">'-4': class="hl-string">'Change Awaiting Assessment',
    class="hl-string">'-3': class="hl-string">'Risk And Impact Assessed', class=class="hl-string">"hl-comment"># Mapped from leaving Assess state
    class="hl-string">'-2': class="hl-string">'Change Scheduled',
    class="hl-string">'-1': class="hl-string">'Implementation Started',
    class="hl-string">'0': class="hl-string">'Review In Progress',
    class="hl-string">'3': class="hl-string">'Change Closed',
    class="hl-string">'4': class="hl-string">'Change Canceled'
}

class=class="hl-string">"hl-comment"># Function to handle pagination and fetch all records from an endpoint
def get_all_records(endpoint, query_params):
    records = []
    offset = 0
    limit = 1000
    while True:
        query_params[class="hl-string">'sysparm_offset'] = str(offset)
        query_params[class="hl-string">'sysparm_limit'] = str(limit)
        response = requests.get(endpoint, auth=(SERVICENOW_USER, SERVICENOW_PASSWORD), params=query_params)
        response.raise_for_status()
        data = response.json().get(class="hl-string">'result', [])
        if not data:
            break
        records.extend(data)
        offset += limit
        print(fclass="hl-string">"Fetched {len(records)} records from {endpoint.split('/')[-1]}...")
    return records

def main():
    print(class="hl-string">"Starting ServiceNow Change Management data extraction...")
    event_log = []

    class=class="hl-string">"hl-comment"># 1. Fetch Change Request base data
    print(class="hl-string">"\nStep 1: Fetching core Change Request data...")
    cr_endpoint = fclass="hl-string">"{SERVICENOW_INSTANCE}/api/now/table/change_request"
    cr_params = {
        class="hl-string">'sysparm_display_value': class="hl-string">'true',
        class="hl-string">'sysparm_fields': class="hl-string">'number,sys_id,sys_created_on,sys_updated_on,state,assignment_group,type,priority,risk,cmdb_ci',
        class="hl-string">'sysparm_query': class="hl-string">'sys_updated_on>=javascript:gs.daysAgo(180)' class=class="hl-string">"hl-comment"># Adjust date range as needed
    }
    change_requests = get_all_records(cr_endpoint, cr_params)
    
    if not change_requests:
        print(class="hl-string">"No change requests found for the specified period. Exiting.")
        return

    cr_sys_ids = [cr[class="hl-string">'sys_id'] for cr in change_requests]
    cr_map = {cr[class="hl-string">'sys_id']: cr for cr in change_requests}
    cr_id_query_part = class="hl-string">'^documentkeyIN' + class="hl-string">','.join(cr_sys_ids)

    class=class="hl-string">"hl-comment"># 2. Fetch all relevant Audit (sys_audit) records for state changes
    print(class="hl-string">"\nStep 2: Fetching audit history for state changes...")
    audit_endpoint = fclass="hl-string">"{SERVICENOW_INSTANCE}/api/now/table/sys_audit"
    audit_params = {
        class="hl-string">'sysparm_display_value': class="hl-string">'false', class=class="hl-string">"hl-comment"># We need the integer state values
        class="hl-string">'sysparm_fields': class="hl-string">'documentkey,sys_created_on,oldvalue,newvalue',
        class="hl-string">'sysparm_query': fclass="hl-string">'tablename=change_request^fieldname=state^{cr_id_query_part}'
    }
    audit_records = get_all_records(audit_endpoint, audit_params)

    class=class="hl-string">"hl-comment"># 3. Fetch all relevant Approval (sysapproval_approver) records
    print(class="hl-string">"\nStep 3: Fetching approval history...")
    approval_endpoint = fclass="hl-string">"{SERVICENOW_INSTANCE}/api/now/table/sysapproval_approver"
    approval_params = {
        class="hl-string">'sysparm_display_value': class="hl-string">'true',
        class="hl-string">'sysparm_fields': class="hl-string">'sysapproval,sys_created_on,sys_updated_on,state',
        class="hl-string">'sysparm_query': fclass="hl-string">'sysapprovalIN' + class="hl-string">','.join(cr_sys_ids)
    }
    approval_records = get_all_records(approval_endpoint, approval_params)

    print(class="hl-string">"\nStep 4: Transforming data into event log format...")
    class=class="hl-string">"hl-comment"># Process each change request to build the event log
    for cr_id, cr_data in cr_map.items():
        base_attributes = {
            class="hl-string">'ChangeRequestNumber': cr_data.get(class="hl-string">'number'),
            class="hl-string">'ChangeState': cr_data.get(class="hl-string">'state'),
            class="hl-string">'AssignmentGroup': cr_data.get(class="hl-string">'assignment_group'),
            class="hl-string">'ChangeType': cr_data.get(class="hl-string">'type'),
            class="hl-string">'Priority': cr_data.get(class="hl-string">'priority'),
            class="hl-string">'RiskLevel': cr_data.get(class="hl-string">'risk'),
            class="hl-string">'ConfigurationItem': cr_data.get(class="hl-string">'cmdb_ci')
        }

        class=class="hl-string">"hl-comment"># Event: Change Request Created
        event_log.append({
            **base_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Change Request Created',
            class="hl-string">'EventTime': cr_data.get(class="hl-string">'sys_created_on'),
            class="hl-string">'EndTime': None
        })
        
        class=class="hl-string">"hl-comment"># Events from Audit History (State Changes)
        cr_audit_records = sorted([r for r in audit_records if r[class="hl-string">'documentkey'] == cr_id], key=lambda x: x[class="hl-string">'sys_created_on'])
        
        last_state = None
        for audit in cr_audit_records:
            new_state = audit[class="hl-string">'newvalue']
            old_state = audit[class="hl-string">'oldvalue']
            event_time = audit[class="hl-string">'sys_created_on']

            class=class="hl-string">"hl-comment"># Activity: Risk and Impact Assessed (when moving out of Assess state)
            if old_state == class="hl-string">'-4': class=class="hl-string">"hl-comment"># Assess
                 event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': class="hl-string">'Risk And Impact Assessed',
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'EndTime': None
                })

            class=class="hl-string">"hl-comment"># Map new state to activity
            if new_state in STATE_MAP:
                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': STATE_MAP[new_state],
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'EndTime': None
                })
            
            class=class="hl-string">"hl-comment"># Activity: Change Reopened (non-linear transition, e.g., Review (0) -> Implement (-1))
            if old_state and new_state and int(old_state) > int(new_state):
                class=class="hl-string">"hl-comment"># Basic check for moving to a numerically lower state, indicating rework
                if not (old_state == class="hl-string">'3' and new_state == class="hl-string">'0'): class=class="hl-string">"hl-comment"># Exclude closed to review which might be valid
                    event_log.append({
                        **base_attributes,
                        class="hl-string">'ActivityName': class="hl-string">'Change Reopened',
                        class="hl-string">'EventTime': event_time,
                        class="hl-string">'EndTime': None
                    })
            last_state = new_state

        class=class="hl-string">"hl-comment"># Events from Approval History
        cr_approval_records = sorted([r for r in approval_records if r[class="hl-string">'sysapproval'][class="hl-string">'value'] == cr_id], key=lambda x: x[class="hl-string">'sys_created_on'])
        for approval in cr_approval_records:
            class=class="hl-string">"hl-comment"># Activity: Approval Requested
            event_log.append({
                **base_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Approval Requested',
                class="hl-string">'EventTime': approval[class="hl-string">'sys_created_on'],
                class="hl-string">'EndTime': None
            })

            class=class="hl-string">"hl-comment"># Activity: Change Approved or Rejected
            if approval[class="hl-string">'state'] == class="hl-string">'Approved':
                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': class="hl-string">'Change Approved',
                    class="hl-string">'EventTime': approval[class="hl-string">'sys_updated_on'],
                    class="hl-string">'EndTime': None
                })
            elif approval[class="hl-string">'state'] == class="hl-string">'Rejected':
                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': class="hl-string">'Change Rejected',
                    class="hl-string">'EventTime': approval[class="hl-string">'sys_updated_on'],
                    class="hl-string">'EndTime': None
                })

    print(fclass="hl-string">"Transformation complete. Total events created: {len(event_log)}")

    class=class="hl-string">"hl-comment"># 5. Create and Save DataFrame
    if not event_log:
        print(class="hl-string">"No events were generated. The output file will be empty.")
        return

    print(class="hl-string">"\nStep 5: Saving event log to CSV file...")
    df = pd.DataFrame(event_log)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'ChangeRequestNumber', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Calculate EndTime as the start of the next event for the same case
    df[class="hl-string">'EndTime'] = df.groupby(class="hl-string">'ChangeRequestNumber')[class="hl-string">'EventTime'].shift(-1)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    column_order = [
        class="hl-string">'ChangeRequestNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'EndTime', class="hl-string">'ChangeState',
        class="hl-string">'AssignmentGroup', class="hl-string">'ChangeType', class="hl-string">'Priority', class="hl-string">'RiskLevel', class="hl-string">'ConfigurationItem'
    ]
    df = df[column_order]

    output_filename = class="hl-string">'servicenow_change_management_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%d %H:%M:%S')
    print(fclass="hl-string">"Successfully saved event log to {output_filename}")

if __name__ == class="hl-string">'__main__':
    main()

始める準備はできていますか？

このテンプレートを使ってデータを準備し、ServiceNowの変更管理プロセスに関するインサイトを見つけましょう。今すぐ効率向上に取り組めます。

改善ガイドに戻る

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

変更の失敗を防ぎ、ServiceNowの成果を高めましょう

ボトルネックを特定し、変更の成功率95％を目指しましょう。

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

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

変更管理データテンプレート

変更管理データテンプレート

変更管理の属性

変更管理のアクティビティ

データ抽出ガイド

ServiceNowのリスト表示からCSV／XLSにエクスポート

ステップ

設定

クエリの例 config

RESTクエリを使ったServiceNow Table APIからのデータ抽出

ステップ

設定

クエリの例 javascript

ServiceNow REST APIを使ったPythonスクリプトによるデータ抽出

ステップ

設定

クエリの例 python

始める準備はできていますか？

変更の失敗を防ぎ、ServiceNowの成果を高めましょう