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

ServiceNow
貴社の変更管理データテンプレート

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

このテンプレートは、変更管理ワークフローの効果的なプロセスマイニングに必要な重要なデータを収集するための構造化されたアプローチを提供します。推奨される属性と追跡すべきアクティビティを、データ抽出に関する実用的なガイダンスとともに示しています。このリソースを活用して、包括的な分析と最適化のためにデータを準備してください。
  • 収集を推奨する項目
  • 正確なプロセスディスカバリのために追跡すべき主要なアクティビティ
  • ServiceNowからのデータ抽出ガイド
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

変更管理属性

これらは、変更管理プロセスの包括的な分析のためにイベントログに含めることを推奨するデータフィールドです。
3 必須 7 推奨 10 任意
名前 説明
イベント日時
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は、変更管理プロセス分析の要石です。「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 - Critical2 - High3 - Moderate4 - Low
変更ステータス
ChangeState
変更要求の現在または過去のステータスで、「Assess」、「Authorize」、「Implement」、「Closed」などがあります。
説明

変更ステータス属性は、特定の時点における変更要求のステータスを表します。変更がライフサイクルのどこにあるかについての大まかな概要を提供します。特定のアクティビティを表す「Activity」とは異なり、「State」はそのイベントから生じる条件です。

分析において、変更ステータスはケースを分類し、その結果を理解するために使用されます。たとえば、「Closed」の変更のみを分析したり、なぜ多くの変更が「Authorize」ステータスで停滞しているのかを調査したりするなど、変更をフィルタリングするための基本です。「Failed」ステータスが存在する場合、「変更失敗率」のようなKPIを直接サポートします。

その重要性

変更要求のステータススナップショットを提供し、結果の分析、ケースのフィルタリング、停滞した変更の特定を可能にします。

取得元

ServiceNowテーブル:change_request、フィールド:state(ステータス)

評価承認スケジュール済み実装レビュークローズキャンセル済み
変更タイプ
ChangeType
「標準」、「通常」、「緊急」などの変更の分類。
説明

変更タイプは、変更要求をその性質、リスク、承認要件に基づいて分類します。標準変更は事前に承認され、通常変更は全プロセスに従って処理され、緊急変更は迅速なパスを利用します。

これは、異なる変更タイプにはそれぞれ固有の正当なプロセスモデルが存在するため、プロセス分析の基本的な軸となります。通常変更と緊急変更のパフォーマンスを比較することで、プロセスの遵守状況や効率性に関する重要な洞察が得られます。また、「リスク評価の標準化」のようなダッシュボードでも使用され、類似する変更が一貫して処理されることを保証します。

その重要性

異なる変更タイプはそれぞれ承認済みのプロセスフローやパフォーマンスに対する独自の期待値を持つため、分析のセグメンテーションが可能になります。

取得元

ServiceNowテーブル:change_request、フィールド:type(タイプ)

標準通常緊急
担当グループ
AssignmentGroup
変更要求を担当するチームまたはグループ。
説明

割り当てグループは、現在変更要求を担当しているチームを示します。例えば、「CAB承認」、「ネットワークエンジニアリング」、「データベース管理者」などです。これは、異なる機能領域間でのプロセスパフォーマンスを分析するための重要な次元です。

この属性は、チームレベルの効率を測定し、特定のグループ内のボトルネックを特定し、チーム間の引き継ぎの有効性を分析するために使用されます。「部門横断型引き継ぎ効率」や「変更実装スループット」といったダッシュボードは、チーム間の依存関係によって引き起こされる遅延を正確に特定するために、このデータに大きく依存しています。

その重要性

チームごとのパフォーマンス分析を可能にし、グループ固有のボトルネックを明確にするとともに、異なる機能領域間の引き渡しの効率性を測定します。

取得元

ServiceNowテーブル:change_request、フィールド:assignment_group(割り当てグループ)

CAB承認ネットワークチームサーバーサポートデータベース管理者
構成アイテム
ConfigurationItem
変更の対象となる特定のITコンポーネント、サービス、またはシステム。
説明

構成アイテム(CI)とは、変更の影響を受ける構成管理データベース(CMDB)内の資産です。これは、サーバー、ソフトウェアアプリケーション、ネットワークデバイス、またはビジネスサービスである可能性があります。

この属性は、変更に関する重要なコンテキストを提供します。プロセスマイニングでは、変更される資産のタイプ別に分析をセグメント化できます。例えば、「変更テスト期間分析」ダッシュボードは、この属性を使用して異なるアプリケーションやシステム間のテスト時間を比較し、どのCIがより長いテストサイクルに関連しているかを特定するのに役立ちます。

その重要性

必須のビジネスコンテキストを提供し、影響を受けるアプリケーション、サービス、またはシステムによって分析をフィルタリングして、コンポーネント固有の問題を特定できるようにします。

取得元

ServiceNowテーブル:change_request、フィールド:cmdb_ci(CMDB構成アイテム)

SAP ERPOracle Database 19cメールサービスWebServer-01
終了日時
EndTime
アクティビティが終了したときのタイムスタンプ。多くの場合、後続のアクティビティの開始時刻から導き出されます。
説明

終了時刻はアクティビティの完了を示します。ソースシステムはイベントの開始をログに記録することが多いですが、終了時刻は推測されることが頻繁にあります。通常、同じケースの次のアクティビティのタイムスタンプとして計算されます。

この属性は、処理時間として知られる各アクティビティの期間を計算するために不可欠です。各ステップにどれくらいの時間がかかるかを理解することは、プロセスにおけるボトルネックと非効率性を特定するための基本です。ケースの最終アクティビティの場合、終了時刻は開始時刻と同じになります。

その重要性

アクティビティ処理時間の計算を可能にし、ボトルネックの特定や特定のプロセスステップの期間測定にとって不可欠です。

取得元

この属性は通常、同じケースIDの次のイベントの開始時刻を取得することにより、データ変換中に計算されます。

2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
SLA状態
SlaState
サービスレベル契約(SLA)に対する変更要求のステータスで、「順調」、「リスクあり」、「違反」などがあります。
説明

SLAステータスは、変更要求がSLAで定義された期間内に進行しているかどうかを示します。このステータスはプロセスの各段階で追跡できます。

この属性は、サービスレベルコミットメントに対するコンプライアンスを監視するために不可欠です。「変更SLAパフォーマンス概要」ダッシュボードおよび「変更SLA遵守率」KPIの主要なデータソースです。SLAが違反される場所と理由を分析することで、組織は体系的な遅延に対処し、サービス提供の予測可能性を向上させることができます。

その重要性

期限に対するパフォーマンスを直接測定し、SLA違反のプロアクティブな監視と分析を可能にして、サービス提供を改善します。

取得元

これは、変更要求などのタスクに関連するSLAを追跡するServiceNowの「task_sla」テーブルから取得することも、期日フィールドに基づいて計算することもできます。

順調リスクあり違反
クローズコード
CloseCode
変更要求がクローズされた際の結果を示すコードで、「Successful(成功)」や「Unsuccessful(失敗)」などの値があります。
説明

クローズコードは、完了した変更要求の最終的な処理結果を提供します。変更が正常に実装されたか、問題があったか、またはロールバックされたかを正式に記録します。

この属性は、「変更失敗率」KPIへの直接的なインプットです。クローズコードの分布を分析することで、組織は変更イニシアチブの成功を定量化できます。「Unsuccessful」のクローズコードを持つ変更に対してプロセスマップをフィルタリングすることは、根本原因分析の強力な手法であり、失敗につながる一般的なプロセスパターンを明らかにします。

その重要性

変更の結果を直接測定し、変更失敗率の計算や失敗した変更の根本原因分析に必要な主要データを提供します。

取得元

ServiceNowテーブル:change_request、フィールド:close_code(クローズコード)

成功問題ありで成功失敗 / ロールバック済み
サイクルタイム
CycleTime
変更要求の作成からクローズまでの経過時間。
説明

サイクルタイムは、変更要求のライフサイクル全体の期間を測定するケースレベルの指標です。これは、特定の変更要求における最初のアクティビティのタイムスタンプと最後のアクティビティのタイムスタンプの差分として計算されます。

これは、プロセス全体の処理速度を測定するための重要なKPIです。「エンドツーエンド変更プロセスフロー」ダッシュボードで利用され、プロセスパフォーマンスの全体像を把握するのに役立ちます。サイクルタイムの傾向を分析し、変更タイプや優先度などの異なる切り口で比較することで、組織は戦略的なプロセス改善の機会を特定しやすくなります。

その重要性

変更プロセスのエンドツーエンドの期間を測定し、全体的なプロセス速度と効率の主要な指標を提供します。

取得元

データ分析時、各CaseIdについて、最大StartTimeから最小StartTimeを差し引くことでケースレベルで計算されます。

60480012096002592000
ソースシステム
SourceSystem
データが抽出されたシステムで、通常は「ServiceNow」です。
説明

この属性は、プロセスデータの発生元を特定します。このケースではServiceNowであると予想されますが、データガバナンスおよび複数のシステムからのデータが統合される可能性があるシナリオでは、重要なフィールドです。

分析において、データリネージが明確であることを保証し、データのソースを検証するのに役立ちます。複数のITSMツールや統合システムを持つ組織の場合、この属性により、異なるプラットフォーム間でのプロセスをフィルタリングおよび比較できます。

その重要性

明確なデータリネージを提供し、プロセスデータの出所が文書化されていることを保証します。これはデータガバナンスとマルチシステム分析にとって不可欠です。

取得元

これは通常、データ抽出および変換(ETL)プロセス中に追加される静的な値です。

ServiceNowServiceNow_PRODSNOW_ITSM
最終データ更新
LastDataUpdate
このレコードのデータがソースシステムから最後に更新された日時を示すタイムスタンプ。
説明

この属性は、最後のデータ抽出のタイムスタンプを提供します。分析されるデータの鮮度を理解するために重要なメタデータフィールドです。

アナリストは、このタイムスタンプを使用して、最新の情報で作業していることを確認し、データの新しさを理解します。特に、継続的なプロセスパフォーマンスを監視する運用ダッシュボードにとって重要であり、決定が古いデータに基づかないことを保証します。

その重要性

データの鮮度を示し、分析やダッシュボードが最新かつ関連性の高い情報に基づいていることを保証します。

取得元

これは、データ抽出および変換(ETL)プロセス中に生成されるメタデータフィールドであり、データ取得時刻を示します。

2023-11-01T02:00:00Z2023-11-02T02:00:00Z
処理時間
ProcessingTime
単一のアクティビティの期間。終了時刻と開始時刻の差として計算されます。
説明

処理時間(アクティビティ期間とも呼ばれる)は、特定のタスクに積極的に費やされた時間を測定します。これは、アクティビティの開始時刻から終了時刻を差し引くことで計算されます。

この計算された指標は、パフォーマンス分析の基本です。プロセス内で最も時間のかかるステップを特定することを可能にし、それらのステップは最適化の主要なターゲットとなることが多いです。テスト期間やリスク評価サイクルタイムを分析するダッシュボードは、関連するアクティビティに対してこの指標に直接基づいています。

その重要性

個々のアクティビティの期間を測定し、最適化の主要な候補となる最も時間のかかるステップを特定することを可能にします。

取得元

データ変換時に計算されます: EndTime - StartTime。

259200360086400
影響度
Impact
ビジネス運用に対する変更の潜在的な影響。高、中、低などの尺度で評価されます。
説明

影響度とは、変更要求が適切に処理されない場合にビジネスに与える潜在的な影響を測るものです。これは、緊急度と並んで、変更全体の優先度を決定する重要なインプットとなります。

影響度別に分析することで、基幹サービスに影響を与える変更が適切に管理されていることを確認できます。「重要変更パフォーマンス」ダッシュボードでは、ビジネス影響度の高い変更を特定して監視するために使用されます。また、リスク評価の一貫性を検証し、影響度の高い変更が正当な理由なく低リスクレベルに割り当てられていないかを確認するためにも使用されます。

その重要性

潜在的なビジネス影響に基づいて変更の優先順位付けを支援し、影響度の高い変更が適切な注意をもって管理されていることを検証するために使用されます。

取得元

ServiceNowテーブル:change_request、フィールド:impact(影響度)

1 - High2 - Medium3 - Low
手戻り
IsRework
同じケース内で、あるアクティビティが以前のステップの繰り返しを示す場合に`true`となるブール値フラグです。
説明

この計算された属性は、手戻りを構成するアクティビティを特定します。手戻りとは、承認後に変更が却下され、再評価のために差し戻されるなど、プロセスが既に完了したステップにループバックする必要がある場合に発生します。

このフラグは、プロセスの非効率性を定量化するために不可欠です。「変更手戻り率」KPIと「変更失敗と手戻り分析」ダッシュボードを直接サポートします。「手戻りである」が真のアクティビティをフィルタリングすることで、アナリストは不完全な初期評価や要件変更などの手戻りの原因を特定し、調査し、無駄を削減するための措置を講じることができます。

その重要性

繰り返し作業を検出することで、プロセスの非効率性を直接定量化し、プロセスループや無駄な労力の根本原因を特定・対処するのに役立ちます。

取得元

データ変換時に、指定されたCaseIdに対して同じアクティビティ(または標準フローでそれ以前のアクティビティ)がすでに発生しているかを検出することで計算されます。

truefalse
担当ユーザー
AssignedToUser
特定の時点における変更要求の責任者である個々のユーザー。
説明

この属性は、変更要求の作業を担当する特定の人物を特定します。これは、要求が異なる段階やチーム間を移動するにつれて、ライフサイクル全体で複数回変更される可能性があります。

ユーザー別に分析することで、作業負荷の分散、個人のパフォーマンス、およびトレーニングニーズの特定に役立ちます。また、割り当てグループと組み合わせることで、作業が個人間でどれだけ効率的に引き継がれているかを分析する上で重要な鍵となります。

その重要性

個々のユーザーの作業負荷とパフォーマンスを追跡し、異なるリソース間の引き継ぎの遅延を分析する上で重要です。

取得元

ServiceNowテーブル:change_request、フィールド:assigned_to(担当者)

Beth AnglinDavid LooAbel Tuter
緊急度
Urgency
変更を解決する必要がある速度で、高、中、低などの尺度で評価されます。
説明

緊急度は、変更がどれだけ迅速に実装される必要があるかを定義します。ビジネス視点から見た要求の時間的制約を反映しています。影響度とともに、全体の優先度を計算するために使用されます。

優先度が分析の主要なフィールドである一方で、緊急度は追加のコンテキストを提供します。特定の変更がなぜ緊急としてマークされているのか、またプロセスが安定性を損なうことなくそれらに効果的に対応しているかどうかを調査するために使用できます。組織が受動的で緊急度の高いモードに陥りすぎていないか、という疑問に答えるのに役立ちます。

その重要性

変更の時間的制約に関するコンテキストを提供し、プロセスが時間的に重要な要求を効果的に処理しているかどうかを分析するのに役立ちます。

取得元

ServiceNowテーブル:change_request、フィールド:urgency(緊急度)

1 - High2 - Medium3 - Low
必須 推奨 任意

変更管理アクティビティ

これらは、正確な変更管理プロセスディスカバリのためにイベントログに記録すべき主要なプロセスステップとマイルストーンです。
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テーブルの監査履歴で「Scheduled」へのステータスフィールドの変更を追跡します。

イベントタイプ inferred
変更リクエスト作成済み
このアクティビティは、システム内での新しい変更要求レコードの作成を示します。これは変更管理プロセスの正式な開始であり、change_requestテーブルに新しいエントリが挿入されたときに記録されます。
その重要性

これはプロセスの主要な開始イベントです。このアクティビティから他のアクティビティまでの時間を分析することで、総リードタイムが明らかになり、プロセスの最初期における遅延を特定するのに役立ちます。

取得元

このイベントは、ServiceNowのchange_requestテーブルにおけるレコード作成タイムスタンプ(sys_created_on)に対応します。

取得

change_requestテーブルのsys_created_onタイムスタンプを使用します。

イベントタイプ explicit
変更実装済み
実装作業が完了し、変更はレビュー、検証、またはテストの準備が整いました。このアクティビティは、変更要求のステータスが「Implement」から「Review」に移行したときに推測されます。
その重要性

これは、実装フェーズを締めくくる重要なマイルストーンです。「変更失敗率」と「変更手戻り率」のKPIを計算するための主要なイベントです。

取得元

'Implement'から'Review'のような後続のステータスへのステータス移行から推測されます。タイムスタンプはchange_requestテーブルの'state'フィールドの監査履歴から取得されます。

取得

'state'フィールドが'Implement'から'Review'に変化する時点を特定します。

イベントタイプ inferred
変更承認済み
変更要求は、スケジューリングおよび実装フェーズに進むために必要なすべての承認を受けました。これは、最終承認が付与され、「approval」フィールドが「approved」に設定されたときに記録される重要なマイルストーンです。
その重要性

このマイルストーンは承認フェーズを締めくくります。承認サイクルタイムを測定し、意思決定プロセスにおけるボトルネックを特定するために不可欠です。

取得元

change_requestテーブルの'approval'フィールドが'approved'に変更されたことから推測されます。タイムスタンプはこの変更の監査履歴から取得されます。

取得

「approval」フィールドが「approved」になったときのタイムスタンプを取得します。

イベントタイプ inferred
レビュー進行中
変更が成功し、その目的を達成したかを確認するために、実装後レビュー(PIR)が実施されます。これは、変更要求のステータスが「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
変更評価待機中
変更要求が提出され、現在、技術的およびビジネス的な評価を待っています。これは通常、変更要求のステータスが「Assess」または同様のステータスに移行し、ドラフト段階を離れたことを示すときに推測されます。
その重要性

このアクティビティは、要求者から評価チームへの最初の引き継ぎ時間を測定するのに役立ちます。ここでの遅延は、初期データ品質の問題や評価のためのリソースの可用性の問題を示している可能性があります。

取得元

change_requestテーブルの'state'フィールドの変更、通常は'Assess'のような値への変更から推測されます。タイムスタンプはこのフィールド変更の監査履歴(sys_audit)から取得されます。

取得

change_requestテーブルの監査履歴で「Assess」へのステータスフィールドの変更を追跡します。

イベントタイプ inferred
実装開始
変更の実装作業が活発に開始されました。これは、変更要求のステータスが「Implement」に更新されたときに記録され、計画から実行への移行を示します。
その重要性

これは実践的な実装作業の開始を示します。「平均実装期間」KPIを測定し、チームの効率を分析するための出発点です。

取得元

change_requestテーブルの'state'フィールドが'Implement'に変更されたことから推測されます。タイムスタンプはこのステータス移行の監査ログから取得されます。

取得

change_requestの監査履歴から、「Implement」へのステータス変更のタイムスタンプを取得します。

イベントタイプ inferred
承認依頼
このアクティビティは、変更要求が正式に承認のために提出されたことを示します。通常はマネージャーまたは変更諮問委員会(CAB)に提出されます。このイベントは、変更要求の承認ステータスが「requested」に設定されたときに記録されます。
その重要性

これは承認サイクルの開始を示します。このイベントから「Change Approved」までの時間を測定することで、「平均変更承認時間」KPIが直接計算されます。

取得元

change_requestテーブルの'approval'フィールドが'requested'に変更されたことから推測されます。タイムスタンプはこのフィールドのsys_auditテーブルから記録されます。

取得

change_requestテーブルの「approval」フィールドが「requested」に設定されたときのタイムスタンプ。

イベントタイプ inferred
推奨 任意

抽出ガイド

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