> 継続的なプロセス改善 > 変更管理 > 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	評価された変更のリスクレベルです。「High」、「Moderate」、「Low」などがあります。
説明リスクレベルは、変更要求のリスク評価プロセスの結果です。変更を実装した場合に不利益な結果が生じる可能性を数値化し、必要な精査と承認のレベルを決めるのに役立ちます。「リスク評価の標準化」ダッシュボードでは、類似した変更に一貫したリスク評価が付与されているかを確認するために使用します。リスクレベル別にプロセスフローを分析すると、高リスクの変更が低リスクの変更よりも厳格な承認・テスト経路に正しく従っているかも確認できます。これは重要なコンプライアンスチェックです。重要な理由コンプライアンス分析に欠かせません。高リスクの変更が適切な精査を受け、より厳格なプロセスに従っていることを確認できます。入手先 ServiceNowテーブル：change_request、フィールド：risk 例高中低
	優先度 Priority	影響度と緊急度に基づいて決まる、変更要求の優先度です。
説明優先度は変更要求の重要性を示し、対応する順序を決めます。多くの場合、変更の影響度と緊急度から導出され、「Critical」、「High」、「Moderate」、「Low」などの値を取ります。優先度別に分析することは、高優先度の変更が低優先度の変更よりも速く処理されているかを確認するために欠かせません。「重要変更パフォーマンス」ダッシュボードでは、特に重要な変更のサイクルタイムと失敗率を追跡できます。低優先度の変更が高優先度の変更より速く完了している場合、リソース配分やプロセス実行に問題がある可能性があります。重要な理由最も重要な変更にリソースが適切に配分されているかを評価し、そのパフォーマンスを個別に監視するために欠かせません。入手先 ServiceNowテーブル：change_request、フィールド：priority 例 1 - 重大2 - 高3 - 中4 - 低
	割り当てグループ AssignmentGroup	変更要求を担当するチームまたはグループです。
説明割り当てグループは、現在変更要求を担当しているチームを示します。「CAB Approval」、「Network Engineering」、「Database Administrators」などがあります。機能領域ごとのプロセスパフォーマンスを分析するための重要な軸です。この属性を使ってチーム単位の効率を測定し、特定のグループ内のボトルネックを特定し、チーム間の引き継ぎの有効性を分析できます。「部門横断の引き継ぎ効率」や「変更実装スループット」などのダッシュボードでは、チーム間の依存関係による遅延を特定するためにこのデータを利用します。重要な理由チーム別のパフォーマンス分析を可能にし、グループ固有のボトルネックを明らかにするとともに、異なる機能領域間の引き継ぎ効率を測定します。入手先 ServiceNowテーブル：change_request、フィールド：assignment_group 例 CAB承認ネットワークチームサーバーサポートデータベース管理者
	変更タイプ ChangeType	変更の分類です。「Standard」、「Normal」、「Emergency」などがあります。
説明変更タイプは、性質、リスク、承認要件に基づいて変更要求を分類します。Standard変更は事前承認済み、Normal変更は通常のプロセスに従い、Emergency変更は短縮された経路で処理します。これはプロセス分析の基本的な軸です。変更タイプごとに、正当なプロセスモデルが異なるためです。Normal変更とEmergency変更のパフォーマンスを比較すると、プロセス遵守状況や効率に関する重要な傾向を把握できます。「リスク評価の標準化」などのダッシュボードで、類似した変更が一貫して処理されているかを確認する際にも使用します。重要な理由変更タイプごとに承認されたプロセスフローやパフォーマンスの期待値が異なるため、分析を分けて確認できます。入手先 ServiceNowテーブル：change_request、フィールド：type 例標準通常緊急
	変更状態 ChangeState	変更要求の現在または過去の状態です。「Assess」、「Authorize」、「Implement」、「Closed」などがあります。
説明変更状態属性は、特定の時点における変更要求のステータスを表します。変更がライフサイクルのどの段階にあるかを大まかに示します。特定のイベントを表すアクティビティとは異なり、状態はそのイベントの結果として生じる条件を示します。分析では、変更状態を使ってケースを分類し、結果を把握します。例えば「Closed」の変更だけを分析したり、多くの変更が「Authorize」状態で滞留する理由を調査したりできます。「Failed」状態が存在する場合は、変更失敗率などのKPIにも直接役立ちます。重要な理由変更要求のステータスを把握できるため、結果の分析、ケースのフィルタリング、滞留している変更の特定に役立ちます。入手先 ServiceNowテーブル：change_request、フィールド：state 例評価承認スケジュール済み実装レビュークローズキャンセル
	構成アイテム ConfigurationItem	変更の対象となる特定のITコンポーネント、サービス、またはシステムです。
説明構成アイテム（CI）は、変更の影響を受ける構成管理データベース（CMDB）上の資産です。サーバー、ソフトウェアアプリケーション、ネットワーク機器、業務サービスなどが該当します。この属性は、変更に関する重要な背景情報を提供します。プロセスマイニングでは、変更対象の資産タイプ別に分析できます。例えば「変更テスト期間分析」ダッシュボードでは、この属性を使って異なるアプリケーションやシステムのテスト時間を比較し、テストサイクルが長いCIを特定します。重要な理由業務上必要な背景情報を提供し、影響を受けるアプリケーション、サービス、システムで分析を絞り込んで、コンポーネント固有の問題を特定できます。入手先 ServiceNowテーブル：change_request、フィールド：cmdb_ci 例 SAP ERPOracle Database 19cメールサービスWebServer-01
	終了時刻 EndTime	アクティビティが完了した時刻です。多くの場合、後続アクティビティの開始時刻から導出します。
説明終了時刻は、アクティビティの完了時点を示します。ソースシステムではイベントの開始時刻が記録されることが多い一方、終了時刻は推定される場合が多くあります。通常は、同じケースにおける次のアクティビティのタイムスタンプを使って算出します。この属性は、各アクティビティの処理時間を算出するために欠かせません。各ステップにかかる時間を把握することは、プロセスのボトルネックや非効率を特定する基本となります。ケースの最後のアクティビティでは、終了時刻は開始時刻と同じです。重要な理由アクティビティの処理時間を算出できるため、ボトルネックの特定や特定のプロセスステップの所要時間測定に役立ちます。入手先通常はデータ変換時に、同じCaseIdを持つ次のイベントのStartTimeを使用して算出します。例 2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
	SLA状態 SlaState	「On Track」「At Risk」「Breached」など、変更リクエストのService Level Agreement（SLA）に対する現在の状況です。
説明 SLA Stateは、変更リクエストがSLAで定められた期限内に進行しているかどうかを示します。このステータスは、プロセスの各段階で追跡できます。この属性は、サービスレベルの合意事項に対するコンプライアンスを監視するうえで欠かせません。「Change SLA Performance Overview」ダッシュボードと「Change SLA Adherence Rate」KPIの主要なデータソースです。SLA違反が発生した場所と原因を分析することで、組織は構造的な遅延に対処し、サービス提供の予測可能性を高められます。重要な理由期限に対するパフォーマンスを直接測定できるため、SLA違反を先回りして監視・分析し、サービス提供の改善につなげられます。入手先 ServiceNowの「task_sla」テーブルから取得できます。このテーブルでは、変更リクエストなどのタスクに関連するSLAを追跡します。または、期限のフィールドを基に算出することもできます。例予定どおりリスクありSLA違反
	サイクルタイム CycleTime	変更リクエストの作成からクローズまでに経過した合計時間です。
説明サイクルタイムは、変更リクエストのライフサイクル全体にかかった時間を測定するケースレベルの指標です。対象の変更リクエストについて、最初のイベントのタイムスタンプと最後のイベントのタイムスタンプの差として算出します。プロセス全体の処理速度を測定する重要なKPIです。「End-to-End Change Process Flow」ダッシュボードで、プロセスパフォーマンスを俯瞰するために使用します。サイクルタイムの推移を分析し、Change TypeやPriorityなどの異なる切り口で比較することで、組織はプロセスを戦略的に改善できる領域を見つけられます。重要な理由変更プロセスの開始から終了までにかかる時間を測定し、プロセス全体の処理速度と効率を示す重要な指標となります。入手先データ分析時にケースレベルで算出します。各CaseIdについて、最大のStartTimeから最小のStartTimeを差し引きます。例 60480012096002592000
	ソースシステム SourceSystem	データを抽出したシステムです。通常は「ServiceNow」です。
説明プロセスデータの取得元を示す属性です。この場合はServiceNowが想定されますが、データガバナンスや複数システムのデータを統合する場面では重要なフィールドです。分析では、データの系譜を明確にし、データソースを検証するのに役立ちます。複数のITSMツールや統合システムを利用する組織では、この属性によって異なるプラットフォーム間でプロセスをフィルタリングし、比較できます。重要な理由プロセスデータの取得元を記録してデータの系譜を明確にし、データガバナンスや複数システムの分析を支えます。入手先通常は、データ抽出および変換（ETL）処理の際に追加される固定値です。例 ServiceNowServiceNow_PRODSNOW_ITSM
	再作業フラグ IsRework	同じケース内で、アクティビティが以前のステップの繰り返しに該当する場合にtrueとなるブール型フラグです。
説明再作業に該当するアクティビティを特定する計算属性です。再作業は、承認後に変更が却下され、再評価に戻される場合など、完了済みのステップにプロセスが戻ることで発生します。このフラグは、プロセスの非効率を定量化するために欠かせません。「変更再作業率」KPIや「変更の失敗・再作業分析」ダッシュボードに直接役立ちます。「再作業フラグ」がtrueのアクティビティに絞ることで、初期評価の不足や要件変更など、再作業の原因を特定して分析し、無駄の削減につなげられます。重要な理由繰り返し作業を示すことでプロセスの非効率を直接定量化し、プロセスループや無駄な作業の根本原因を特定して対処できます。入手先データ変換時に、指定されたCaseIdについて同じアクティビティ（または標準フロー上の以前のアクティビティ）がすでに発生しているかを検出して算出します。例 truefalse
	最終データ更新日時 LastDataUpdate	このレコードのデータがソースシステムから最後に更新された時刻を示すタイムスタンプです。
説明データが最後に抽出された時刻を示す属性です。分析対象データの鮮度を把握するうえで重要なメタデータフィールドです。分析担当者はこのタイムスタンプを使って、最新の情報を扱っていることを確認し、データの新しさを把握できます。継続中のプロセスパフォーマンスを監視する業務用ダッシュボードでは特に重要で、古いデータに基づいて判断することを防ぎます。重要な理由データの鮮度を示し、分析やダッシュボードが最新かつ関連性の高い情報に基づいていることを確認できます。入手先データ抽出および変換（ETL）処理で生成されるメタデータフィールドです。データを取得した時刻を示します。例 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	完了コード CloseCode	変更要求を完了した際の結果を示すコードです。「Successful」や「Unsuccessful」などがあります。
説明完了コードは、完了した変更要求の最終結果を記録します。変更が正常に実装されたか、問題が発生したか、ロールバックされたかを正式に示します。この属性は「変更失敗率」KPIの直接的な入力値です。完了コードの分布を分析することで、組織は変更施策の成功度を定量化できます。「Unsuccessful」完了コードの変更に絞ってプロセスマップを分析すると、失敗につながる共通のプロセスパターンを明らかにでき、根本原因分析に役立ちます。重要な理由変更の結果を直接測定し、変更失敗率の算出や失敗した変更の根本原因分析に必要な主要データを提供します。入手先 ServiceNowテーブル：change_request、フィールド：close_code 例成功問題ありで成功失敗／ロールバック済み
	影響度 Impact	変更が業務に及ぼす可能性のある影響です。High、Medium、Lowなどの尺度で評価します。
説明影響度は、変更要求が適切に処理されなかった場合に業務へ及ぶ可能性のある影響を測定します。緊急度とともに、変更全体の優先度を決める主要な入力値です。影響度別に分析すると、重要なサービスに影響する変更が適切な注意を払って管理されているかを確認できます。「重要変更パフォーマンス」ダッシュボードでは、業務への影響が大きい変更を抽出して監視できます。また、高影響度の変更に正当な理由なく低いリスクレベルが割り当てられていないかを確認し、リスク評価の一貫性を検証するためにも使用します。重要な理由業務への潜在的な影響に基づいて変更の優先順位を決め、高影響度の変更が適切な注意を払って管理されているかを検証できます。入手先 ServiceNowテーブル：change_request、フィールド：impact 例 1 - 高2 - 中3 - 低
	担当ユーザー AssignedToUser	特定の時点で変更要求を担当する個人ユーザーです。
説明変更要求の作業を担当する個人を示す属性です。要求が異なる段階やチーム間を移動する過程で、担当者が複数回変わる場合があります。ユーザー別に分析すると、作業負荷の分布や個人のパフォーマンスを把握し、トレーニングの必要性を特定できます。Assignment Groupと組み合わせれば、個人間で作業がどれだけ効率的に引き継がれているかを確認でき、引き継ぎの分析にも役立ちます。重要な理由個々のユーザーの作業負荷とパフォーマンスを追跡し、異なる担当者間の引き継ぎ遅延を分析するうえで重要です。入手先 ServiceNowテーブル：change_request、フィールド：assigned_to 例 Beth AnglinDavid LooAbel Tuter
	緊急度 Urgency	変更を解決する必要がある速さです。High、Medium、Lowなどの尺度で評価します。
説明緊急度は、変更をどれだけ早く実装する必要があるかを示します。業務の観点から見た要求の時間的な制約を表します。影響度とともに、全体の優先度の算出に使用します。分析では優先度が主なフィールドになりますが、緊急度から追加の背景情報を得られます。特定の変更が緊急と判断された理由や、安定性を損なわずにプロセスが対応できているかを調査できます。組織が過度に場当たり的で緊急度の高い対応に追われていないかを確認する際にも役立ちます。重要な理由変更の時間的な制約を把握し、時間的に重要な要求をプロセスが適切に処理できているかを分析できます。入手先 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
	変更のスケジュール設定	承認された変更に予定開始日と終了日が割り当てられ、実装カレンダーに正式に登録された状態です。変更要求のstateが「Scheduled」に移行した時点から推定します。
重要な理由このアクティビティにより、計画・承認段階と実際の実装フェーズを区別できます。この状態にとどまる時間から、承認後に作業が開始されるまでの遅延を把握できます。入手先 change_requestテーブルのstateフィールドが「Scheduled」に変更されたことから推定します。タイムスタンプには、対応する監査ログの記録時刻を使用します。取得 change_requestテーブルの監査履歴で、stateフィールドが「Scheduled」に変更された記録を追跡します。イベントタイプ inferred
	変更の実装完了	実装作業が完了し、レビュー、検証、テストに進める状態です。変更要求のstateが「Implement」から「Review」へ移行した時点から推定します。
重要な理由実装フェーズを完了する重要なマイルストーンです。「変更失敗率」および「変更再作業率」KPIの算出に使用します。入手先「Implement」から「Review」などの後続状態への状態遷移から推定します。タイムスタンプには、change_requestテーブルのstateフィールドに関する監査履歴の時刻を使用します。取得 stateフィールドが「Implement」から「Review」へ変更された時点を特定します。イベントタイプ inferred
	変更完了	変更要求が正常に完了し、レビューを終えて、処理済みと見なされる状態です。プロセスの主要な成功終端点であり、変更のstateが「Closed」に移行した時点で記録されます。
重要な理由変更ライフサイクルが正常に完了したことを示します。プロセス全体の所要時間とSLA遵守状況を測定するための終了イベントです。入手先 change_requestテーブルのstateフィールドが「Closed」に設定されたことから推定します。タイムスタンプには、この最終状態変更の監査履歴に記録された時刻を使用します。取得 stateフィールドが「Closed」に更新された時刻のタイムスタンプを記録します。イベントタイプ 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）を実施し、変更が成功し、目的を達成したかを確認している状態です。変更要求のstateが「Review」に設定された時点で記録されます。
重要な理由レビューにかかった時間を分析すると、変更の成功を検証する際の遅延を特定できます。また、この手順が省略されたコンプライアンス違反の変更も明らかにできます。入手先 change_requestテーブルのstateフィールドが「Review」に変更されたことから推定します。タイムスタンプには、この状態変更の監査ログに記録された時刻を使用します。取得 change_requestの監査履歴から、「Review」への状態変更時刻を記録します。イベントタイプ inferred
	変更の再オープン	変更要求が後の段階に進んだ後、「Implement」や「Assess」などの以前の状態に戻された状態です。非線形の状態遷移から推定し、再作業の発生を示します。
重要な理由このアクティビティは、再作業ループの特定と「変更再作業率」の算出に欠かせません。再オープンが頻繁に発生する場合、実装品質、テスト、計画に問題がある可能性があります。入手先 change_requestの監査履歴にある状態変更の順序を分析して推定します。後の状態（例：「Review」）から前の状態（例：「Implement」）への遷移は、再オープンイベントを示します。取得 stateフィールドの履歴から、順序に沿わない後戻りの遷移を検出します。イベントタイプ inferred
	変更却下	変更要求が承認者またはCABによって却下された状態です。再作業のうえ再提出されない限り、要求の終端状態となります。approvalフィールドが「rejected」に設定された時点で記録されます。
重要な理由却下を追跡すると、情報不足や高いリスクなど、却下の主な理由を特定できます。この分析により、今後の変更提出の品質を高められます。入手先 change_requestテーブルのapprovalフィールドが「rejected」に変更されたことから推定します。タイムスタンプには監査履歴の時刻を使用します。取得 approvalフィールドが「rejected」になった時刻のタイムスタンプを記録します。イベントタイプ inferred
	変更要求の評価待ち	変更要求が提出され、技術面および業務面での評価を待っている状態です。通常は、変更要求のstateが「Assess」または同様のステータスに遷移した時点から推定します。これは、下書き段階を終えたことを示します。
重要な理由このアクティビティにより、依頼者から評価チームへの初回引き継ぎ時間を測定できます。ここでの遅延は、初期データの品質や、評価に必要なリソースの確保に問題があることを示している場合があります。入手先 change_requestテーブルのstateフィールドが、通常は「Assess」などの値に変更されたことから推定します。タイムスタンプには、このフィールド変更を記録した監査履歴（sys_audit）の時刻を使用します。取得 change_requestテーブルの監査履歴で、stateフィールドが「Assess」に変更された記録を追跡します。イベントタイプ inferred
	実装開始	変更の実装作業が実際に開始された状態です。変更要求のstateが「Implement」に更新された時点で記録され、計画から実行への移行を示します。
重要な理由実装作業の開始点です。「平均実装期間」KPIの測定や、チームの効率分析に利用します。入手先 change_requestテーブルのstateフィールドが「Implement」に変更されたことから推定します。タイムスタンプには、この状態遷移の監査ログに記録された時刻を使用します。取得 change_requestの監査履歴から、「Implement」への状態変更時刻を記録します。イベントタイプ inferred
	承認依頼	変更要求が正式に承認へ提出されたことを示します。通常は、マネージャーまたはChange Advisory Board（CAB）に提出されます。変更要求の承認ステータスが「requested」に設定された時点で記録されます。
重要な理由承認サイクルの開始点です。このイベントから「変更承認」までの時間を測定することで、「平均変更承認時間」KPIを直接算出できます。入手先 change_requestテーブルのapprovalフィールドが「requested」に変更されたことから推定します。タイムスタンプには、このフィールドの変更を記録したsys_auditテーブルの時刻を使用します。取得 change_requestテーブルのapprovalフィールドが「requested」に設定された時刻のタイムスタンプです。イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

ServiceNowインスタンスにログイン：Change Managementモジュールに対する少なくともitilロール、または同等の読み取り権限を持つユーザーアカウントでログインします。
変更リクエストの基本データをエクスポート：Change > Allに移動し、すべての変更リクエストの一覧を表示します。フィルターのじょうごアイコンで対象期間を指定します。例：Created on last 3 months。
エクスポートする列を設定：任意の列見出しを右クリックし、Configure > List Layoutを選択します。次の列を「Selected」リストに追加します：Number、sys_created_on、sys_updated_on、state、assignment_group、type、priority、risk、cmdb_ci。Saveをクリックします。
変更リクエストデータをエクスポート：リストビューのフィルターと設定が完了したら、再度任意の列見出しを右クリックし、ExportからCSVを選択します。システムがダウンロード用ファイルを準備します。このファイルには、状態ベースのアクティビティに必要なデータが含まれます。
承認データをエクスポート：ナビゲーションフィルターにsysapproval_approver.listと入力してEnterキーを押します。すべての承認を表示するリストビューが開きます。
承認をフィルタリングしてエクスポート：フィルターのじょうごアイコンで変更関連の承認だけを表示します。Source table is change_request AND Created on last 3 monthsに設定します。リストレイアウトにApprover、State、Created、Updated、Document ID（変更リクエスト番号を含む）などの列を追加します。このリストを別のCSVファイルにエクスポートします。
データを結合・変換：この手作業には、スプレッドシートツールまたは簡単なスクリプトが必要です。2つのCSVファイルを開きます。目的は、アクティビティごとに1行を持つ単一のイベントログファイルを作成することです。
変更リクエストの状態変更をマッピング：変更リクエストのデータファイルで、状態遷移ごとに行を作成します。例：
- Change Request Created：sys_created_onのタイムスタンプを使用します。
- Change Awaiting Assessment：stateフィールドが初めて「Assess」になった時点のsys_updated_onを使用します。
- Implementation Started：stateフィールドが初めて「Implement」になった時点のsys_updated_onを使用します。
- その他の状態ベースのアクティビティ（Change Scheduled、Change Implemented、Review In Progress、Change Closed、Change Canceled）は、stateフィールドが対応する値に変わった時点のsys_updated_onから推定します。
承認イベントをマッピング：承認データファイルで、Change Request番号（Document ID）を使ってメインの変更リクエストファイルと結合します。
- Approval Requested：承認のStateが「requested」であるレコードのCreatedタイムスタンプを使用します。
- Change Approved：変更が「approved」状態になった最終承認レコードのUpdatedタイムスタンプを使用します。
- Change Rejected：承認のStateが「rejected」になったレコードのUpdatedタイムスタンプを使用します。
最終イベントログを作成：前の手順で生成したすべての行を1つのテーブルにまとめます。列名が正しく設定されていることを確認します：ChangeRequestNumber、ActivityName、EventTime、その他の推奨属性。
保存してアップロード：結合・整形したデータを1つの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では行数に制限があり、日付形式が変更される場合があります。

a サンプルクエリ 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の利用に必要な権限が付与されます。Basic Authentication（ユーザー名とパスワード）またはOAuth 2.0クライアントを設定して、このユーザーの認証情報を作成します。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、および「Change Request Created」イベントのタイムスタンプ（sys_created_on）を取得します。
監査履歴を取得：前の手順で取得した各sys_idについて、sys_auditテーブルを対象に追加のAPI呼び出しを行います。tablenameが「change_request」で、documentkeyが変更リクエストのsys_idと一致する監査レコードに絞り込みます。これにより、各ケースのフィールド変更履歴をすべて取得できます。
アクティビティ用に監査データを処理：各変更リクエストのsys_auditレコードを順に処理します。スクリプトでは、プロセスアクティビティに対応する特定の変更を特定する必要があります。たとえば、fieldnameが「state」で、newvalueが「Scheduled」のレコードは、「Change Scheduled」アクティビティを表します。監査レコードのsys_created_onタイムスタンプがEventTimeになります。
「Reopened」アクティビティを特定：再オープンイベントを取得するには、標準的な状態の順序（例：Assess -> Authorize -> Scheduled -> Implement -> Review -> Closed）を定義します。各状態変更について、定義した順序におけるoldvalueとnewvalueの位置を比較します。新しい状態が古い状態より前にある場合は、「Change Reopened」アクティビティを作成します。
データを結合・マッピング：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
認証：スクリプトでは、簡便さを優先してBasic Authenticationを使用します。本番環境では、セキュリティを高めるため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、数値、sys_created_on、assignment_group、type、priority、risk、cmdb_ciなどを指定します。
ページネーションの処理：大規模なデータセットでは、ServiceNowはレコードをページ単位で返します。sysparm_limitとsysparm_offsetパラメーターを使用してページを順番に処理し、クエリ対象のすべてのレコードを取得するまでループする必要があります。
監査テーブルの前提条件：この方法はsys_auditテーブルに全面的に依存します。イベントログの生成に履歴が必要なため、change_requestテーブルと、特にstate、approval、アクティブフィールドで監査が有効になっていることを確認します。

a サンプルクエリ 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値（「Change Awaiting Assessment」や「Change Approved」など）にマッピングします。
イベントログを統合：すべてのイベントを1つの構造化されたpandas DataFrameにまとめます。このDataFrameには、各イベントに必要な属性と推奨属性が含まれ、各変更リクエストの完全なタイムラインを作成できます。
出力を確認：スクリプトが完了すると、同じディレクトリにservicenow_change_management_log.csvというCSVファイルが作成されます。ファイルを開き、抽出データに問題がないことを確認します。
アップロードの準備：生成されたCSVファイルは、ProcessMindのイベントログ仕様に沿って整形されています。追加の整形は必要ありません。そのままアップロードできます。

設定

認証：スクリプトではユーザー名とパスワードによるBasic Authenticationを使用します。セキュリティを高めるには、ServiceNowが対応しているOAuth 2.0を使うようスクリプトを変更することを検討してください。
ServiceNowエンドポイント：スクリプトは主に3つのREST APIエンドポイントとやり取りします。基本的な変更データには/api/now/table/change_request、フィールド変更履歴（特に「state」フィールド）には/api/now/table/sys_audit、承認・却下イベントには/api/now/table/sysapproval_approverを使用します。
期間フィルタリング：期間は、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インスタンスに大きな負荷をかける場合があります。大規模な抽出は業務のピーク時間を避けて実行し、期間を厳密に指定してパフォーマンスへの影響を抑えてください。

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

ステップ

設定

a サンプルクエリ config

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

ステップ

設定

a サンプルクエリ javascript

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

ステップ

設定

a サンプルクエリ python

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

失敗する変更を止め、ServiceNowの成果を今すぐ高めましょう。

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

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

変更管理の属性

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

抽出ガイド

ServiceNowのリストビューをCSV／XLSにエクスポート

ステップ

設定

a サンプルクエリ config

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

ステップ

設定

a サンプルクエリ javascript

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

ステップ

設定

a サンプルクエリ python

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

失敗する変更を止め、ServiceNowの成果を今すぐ高めましょう。

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