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

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

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

このテンプレートでは、変更管理プロセスの分析に必要なデータを収集するための道筋を示します。収集すべき重要な属性、追跡すべき主要なアクティビティ、ソースシステムから情報を抽出する具体的な方法をまとめています。このリソースを使って、プロセスマイニングに役立つイベントログを作成してください。
  • 収集を推奨する属性
  • 追跡すべき主要なアクティビティ
  • Ivanti Cherwellからの抽出ガイド
イベントログを初めて扱いますか。学ぶ プロセスマイニングのイベントログを作成する方法.

変更管理の属性

以下は、変更管理を詳細に分析し、インサイトに富んだプロセスディスカバリーを行うため、イベントログに含めることを推奨するデータ項目です。
5 必須 6 推奨 8 任意
名前 説明
アクティビティ名
ActivityName
変更管理プロセス内のある時点で発生した、特定のイベントまたはタスクの名称です。
説明

アクティビティ名は、変更要求のライフサイクルにおける具体的なステップまたはマイルストーンを表します。たとえば、「Change Submitted For Assessment」や「Change Approved by CAB」などです。これらのアクティビティが、発見されたプロセスマップのノードになります。

分析では、プロセスフローの可視化、イベントの順序の特定、標準手順からの逸脱の検出に欠かせない属性です。アクティビティ間の遷移時間の算出や、遅延が発生している箇所の把握にも使われます。

重要な理由

実際のプロセスフローを発見して可視化するために欠かせない属性です。ボトルネック、手戻りループ、コンプライアンスに反する経路を特定できます。

入手先

Ivanti CherwellのChange Requestオブジェクトに関連するステータス変更、ジャーナルエントリ、または特定のイベントログから生成されます。

変更を評価に提出変更の承認待ち変更の実装完了
イベント時刻
EventTime
変更要求について、特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプです。
説明

イベント時刻はタイムスタンプとも呼ばれ、アクティビティが実行された正確な日付と時刻を記録します。この時系列データは、イベントを時系列に並べるために欠かせず、時間を基準とするプロセスマイニング分析の基盤になります。

この属性は、アクティビティ間の所要時間やケース全体のサイクル時間の算出、プロセス内の待機時間や遅延の特定に使われます。変更承認サイクル時間など、時間ベースの目標に対するパフォーマンスを監視するダッシュボードの作成にも欠かせません。

重要な理由

このタイムスタンプは、パフォーマンスと所要時間に関するすべての分析の基盤です。サイクル時間の算出、ボトルネックの特定、SLAの監視が可能になります。

入手先

通常、Ivanti CherwellのChange Requestオブジェクトに関連するステータス変更ログ、監査証跡、またはジャーナルエントリのタイムスタンプに記録されています。

2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
変更要求ID
ChangeRequestId
1件の変更要求ケースを一意に識別し、開始からクローズまでの関連アクティビティをまとめる一意の識別子です。
説明

Change Request IDは、変更のライフサイクル全体を通じて各変更イニシアチブを一意に識別する主キーです。プロセスマイニングではケース識別子として機能し、申請、評価、承認、実装などのすべてのイベントを、1つの一貫したプロセスインスタンスに結び付けます。

Change Request IDを使ってデータを分析すると、変更管理プロセスをエンドツーエンドで把握できます。個々の変更の追跡、合計サイクル時間の算出、各要求に固有のプロセス逸脱やボトルネックの特定が可能になります。

重要な理由

関連するすべてのイベントを結び付ける基本的なケース識別子です。変更要求の全体の経過を追跡し、そのパフォーマンスを分析できます。

入手先

通常、Ivanti CherwellのChange Requestビジネスオブジェクトにおける主識別子です。

CR-105421CR-105422CR-105423
ソースシステム
SourceSystem
データを抽出した記録元のシステムです。このビューでは「Ivanti Cherwell」です。
説明

イベントデータの発生元システムを識別する属性です。異種システムが混在する環境では、異なるソースのデータを区別するのに役立ちます。このデータモデルでは、Ivanti Cherwellから取得したデータであることを示す固定値になります。

単一ソースのモデルでは静的に見える場合がありますが、データガバナンス、追跡可能性、将来の他システムとの連携に欠かせません。データの出所を明確にし、データ品質の管理にも役立ちます。

重要な理由

データの出所に関する重要なコンテキストを提供します。データガバナンス、トラブルシューティング、追跡可能性の確保に欠かせません。

入手先

通常、データ抽出および変換の処理中に、データセットの出所を示す固定値として追加されます。

Ivanti Cherwell
最終データ更新日時
LastDataUpdate
このイベントのデータがソースシステムから最後に抽出または更新された時刻を示すタイムスタンプです。
説明

Ivanti Cherwellからデータが最後に取得された日付と時刻を記録します。プロセス内のイベントを表すものではなく、データの鮮度に関するメタデータです。

ダッシュボードの利用者が、分析結果がどの時点の情報かを理解するために重要です。データ更新スケジュールの管理に役立ち、データの経過時間が明確な状態で意思決定できるようにします。

重要な理由

データの鮮度を示します。分析結果への信頼を保ち、現在の業務状況との関連性を理解するために欠かせません。

入手先

データの抽出、変換、ロード(ETL)処理中に各レコードへ生成・付与されるタイムスタンプです。

2024-05-21T02:00:00Z
変更ステータス
ChangeStatus
変更要求の現在または最終的なステータスです。「Closed」、「Rejected」、「In Progress」などがあります。
説明

変更ステータスは、ある時点における変更要求の状態、または最終的な結果を示します。ケースの解決状況を把握し、例外を特定するために欠かせない属性です。

プロセス分析では、却下またはキャンセルされた変更だけを分析するなど、特定の結果でフィルタリングするために使われます。「Change Request Rejection Rate」などのKPIを支え、変更管理プロセス全体の健全性と効率を把握するために欠かせません。

重要な理由

変更要求の結果を定義し、却下率、完了率、オープンケースとクローズケースの分布に関する重要な分析を可能にします。

入手先

Ivanti CherwellのChange Requestビジネスオブジェクトにある「Status」フィールドに対応します。

承認済み却下済みクローズ済みキャンセル済み承認待ち
変更タイプ
ChangeType
変更の分類です。「Standard」、「Normal」、「Emergency」などがあります。
説明

変更タイプは、性質、緊急度、影響に基づいて変更要求を分類します。一般的なタイプには、事前承認済みでリスクの低いStandard、完全な評価と承認が必要なNormal、即時実装が必要なEmergencyがあります。

この属性により、カテゴリごとにプロセスのパフォーマンスを比較できます。たとえば、Emergencyの変更が異なる高速な経路をたどるか、Standardの変更が本当に最小限の負荷で処理されているかを確認できます。「Problematic Change Type Performance」ダッシュボードの基盤となる属性です。

重要な理由

変更タイプでプロセスを分けることは、パフォーマンスを比較し、「Emergency」など特定のカテゴリがボトルネックや逸脱を引き起こしているかを特定するために欠かせません。

入手先

Change Requestビジネスオブジェクトにある「Change Type」または「Category」という名称の分類フィールドに対応すると考えられます。

標準通常緊急
変更リスクレベル
ChangeRiskLevel
変更に関連する評価済みのリスクレベルです。「Low」、「Medium」、「High」などがあります。
説明

変更リスクレベルは、変更による潜在的な悪影響を定量化するため、評価段階で割り当てられる分類です。この評価は、承認プロセスや必要な審査の厳格さに影響することがよくあります。

プロセスマイニングでは、リスク評価の一貫性を分析し、リスクとプロセスの動きを関連付けるために使われます。たとえば、高リスクの変更がより厳格な承認経路をたどるか、実装時間が長くなるかを確認できます。「Change Risk Assessment Consistency」ダッシュボードを直接支援します。

重要な理由

リスクがプロセスフロー、承認サイクル、成功率に与える影響を分析できます。高リスクの変更に適切な審査が行われているかを確認するのにも役立ちます。

入手先

通常、Change Requestオブジェクトの「Risk Level」または同様のフィールドに保存され、リスク評価アクティビティ中に入力されます。

重大
変更担当チーム
ChangeTeam
現在、変更要求を担当しているチームまたはグループです。
説明

変更担当チームは、変更要求に割り当てられたグループまたは部門です。変更担当者と同様に、プロセスの途中で変わることがあり、サービスデスクからネットワークエンジニアリングチームへ移る場合など、チーム間の責任移管を示します。

この属性は、チーム間の引き継ぎを分析し、特定のチームが原因となる構造的な遅延を特定するために欠かせません。どのチームに負荷が集中しているか、どこでコミュニケーションの断絶が起きているかを把握でき、「Change Handoff & Resource Utilization」分析を直接支援します。

重要な理由

チーム単位の責任を特定します。プロセスのボトルネック分析、チームパフォーマンスの測定、グループ間の引き継ぎ遅延の把握に役立ちます。

入手先

通常、Change Requestオブジェクトの「Owned By Team」または同様のグループ割り当てフィールドに保存されています。

ネットワーク運用データベース管理アプリケーションサポート
変更担当者
ChangeOwner
現在、変更要求を担当しているユーザーまたは個人です。
説明

変更担当者は、特定の段階で変更要求に割り当てられ、説明責任を負う担当者です。要求がライフサイクルを進む中で変わることが多く、担当者間の引き継ぎを示します。

変更担当者を分析することで、リソースの負荷を把握し、特定の担当者に関連するボトルネックを特定できます。遅延の大きな原因となる引き継ぎの分析にも欠かせません。「Change Handoff & Resource Utilization」ダッシュボードを支援します。

重要な理由

個人単位の責任を追跡し、作業負荷の分布、引き継ぎ頻度、リソース固有のボトルネックを分析できます。

入手先

通常、Change Requestビジネスオブジェクトの「Owned By」または「Assigned To」フィールドです。

Alice JohnsonBob WilliamsCharlie Brown
目標完了日
TargetCompletionDate
変更の実装を完了するために計画または合意された期限です。
説明

目標完了日は、変更の実装と検証を完全に終える予定の日時です。サービスレベル合意(SLA)の一部となることが多く、パフォーマンスを測る主要な基準になります。

この属性は、期限の遵守と適時性を監視するために欠かせません。実際の完了日と比較して、「On-Time Change Completion Rate」および「Change SLA Adherence Rate」KPIを算出します。目標を逃すリスクのある変更を早期に特定するのにも役立ちます。

重要な理由

予定どおりのパフォーマンスとSLA遵守を測定する基準となります。プロセスの効率と信頼性を示す重要な指標です。

入手先

通常、Change Requestオブジェクトにある日付フィールドで、「Target Date」、「Due Date」、「SLA Target」などの名称が付けられています。

2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
事業部門
BusinessUnit
変更を要求した、または変更によるメリットを受ける事業部門または部署です。
説明

変更要求を組織内の特定の部門に関連付ける属性です。「Finance」、「Marketing」、「Operations」などがあります。技術的なプロセスにビジネス上の背景を付加します。

事業部門別に分析することで、変更需要がどこから生じているかを把握できます。チャージバックモデル、IT変更が各業務機能に与える影響の理解、特定の部門で変更が複雑化または遅延していないかの特定に役立ちます。

重要な理由

ビジネス上の背景を提供し、組織の観点から変更需要、影響、パフォーマンスを分析できます。

入手先

Change Requestオブジェクトのフィールドである場合と、申請者のユーザープロファイルから引き継がれる場合があります。

財務人事営業・マーケティング業務運用
却下理由
ChangeRejectionReason
変更要求が却下された理由を説明するテキストまたはカテゴリです。
説明

変更要求が却下された際に、承認者が示した理由を記録します。あらかじめ定義されたリストから選択する場合と、自由記述で入力する場合があります。

「Rejected Change Request Analysis」ダッシュボードに欠かせない情報です。却下理由を分類して分析することで、情報不足、リスク評価の不備、ビジネス上の競合など、変更申請に共通する問題を組織が特定できます。得られた情報を、今後の変更要求の品質向上に役立てられます。

重要な理由

変更が失敗する理由を直接把握し、申請および評価プロセスを対象とした改善を行うことで、全体の却下率を下げられます。

入手先

通常、「Rejection Reason」専用フィールド、またはステータスが「Rejected」に変更された際に入力されるメモフィールドに記録されます。

実装計画の詳細が不十分リスク評価が未完了他のスケジュール済み変更と競合
変更優先度
ChangePriority
変更要求の優先度です。緊急度とビジネスへの影響を示します。
説明

変更優先度は、変更の緊急度と影響を組み合わせて決定する分類です。チームが作業の優先順位を付け、リソースを適切に配分し、最も重要な変更から対応できるようにします。

分析では、優先度の高い変更が低い変更より速く処理されているかを確認できます。期待と異なる結果は、優先順位付けや実行プロセスの非効率、またはボトルネックを示している可能性があります。

重要な理由

影響の大きい変更が適切に優先され、意図どおり迅速に処理されているかを分析できます。

入手先

通常、Change Requestオブジェクトの「Priority」という名称のフィールドです。手動で設定する場合と、影響度や緊急度のフィールドから導出する場合があります。

1 - 重大2 - 高3 - 中4 - 低
変更申請者
ChangeSubmitter
変更要求を最初に作成または申請したユーザーです。
説明

変更要求を開始した人物を特定する属性です。後のプロセスで実装責任を担う変更担当者とは異なる場合があります。

変更申請者を分析することで、申請品質に関する傾向を特定できます。たとえば、特定の個人やチームが、却下や手戻りにつながる不完全な要求を頻繁に申請していることが分かる場合があります。この情報を対象を絞ったトレーニングに役立て、申請全体の品質を高められます。

重要な理由

変更要求の起点を追跡し、個人またはチームごとの申請品質を分析するとともに、トレーニングの機会を特定できます。

入手先

通常、Change Requestオブジェクトの「Created By」または「Requested By」フィールドです。

Susan MillerDavid ChenMaria Garcia
実装サイクル時間
ImplementationCycleTime
変更実装の開始から完了までの計算上の所要時間です。
説明

変更の実装段階にかかった時間を定量化する指標です。「Change Implementation Started」アクティビティから「Change Implemented」アクティビティまでの時間として算出されます。

「Average Change Implementation Time」KPIの算出に使われ、「Change Implementation Flow & Delays」ダッシュボードを支援します。計画上の遅延と実行上の遅延を区別し、技術的な実装作業そのものに改善の重点を置けるようにします。

重要な理由

実際の実装段階のパフォーマンスを切り分け、承認の遅延とは別に、技術またはリソースに起因するボトルネックを特定できます。

入手先

実装の開始イベントと終了イベントのタイムスタンプの差分を求め、プロセスマイニングツールまたはデータ変換時に算出されます。

4時間15分1日2時間30分
実際の完了日
ActualCompletionDate
変更が実際に実装され、完了したことを検証した時刻です。
説明

実際の完了日は、変更要求の実装作業が終了した時点を示します。計画上の期限と比較してパフォーマンスを測定する重要なマイルストーンです。

この属性は目標完了日と組み合わせ、変更が期限内に完了したかを判定します。「On-Time Change Completion Rate」などのKPIの算出や、実装段階で遅延が発生した原因の分析に欠かせません。

重要な理由

実際の完了時刻を記録し、期限内完了率の算出や遅延の規模の分析を可能にします。

入手先

通常、変更要求のステータスが「Implemented」または「Completed」に移行した時点で記録されます。専用フィールドに保存される場合と、そのステータス変更時刻から推定される場合があります。

2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
影響を受けるサービス
ServiceAffected
変更によって影響を受ける主要なビジネスサービスまたは構成アイテム(CI)です。
説明

変更要求の対象となる主要なITサービス、アプリケーション、またはインフラストラクチャを特定する属性です。変更管理プロセスを、より広いITサービスマネジメントの領域に結び付けます。

影響を受けるサービス別の分析は、「Top Problematic Change Types」KPIに欠かせません。変更が頻繁に行われるサービスや、却下率または遅延が高いサービスを特定できます。サービスオーナーが安定性を高め、技術的負債を管理するための情報になります。

重要な理由

変更を特定のビジネスサービスに結び付け、どのサービスが最も不安定か、問題の多い変更を最も多く発生させているかを分析できます。

入手先

通常、構成管理データベース(CMDB)から関連付けられ、Change Requestオブジェクトの「Primary CI」または「Service」フィールドに保存されます。

メールサービス(Exchange)ERPシステム(SAP)コアネットワークスイッチ(CISCO-4500X)
期限内完了フラグ
IsOnTimeCompletion
変更が目標日以前に完了した場合にtrueとなる計算済みフラグです。
説明

「ActualCompletionDate」と「TargetCompletionDate」を比較して導出するブール型の属性です。各変更要求の期限内パフォーマンスを明確な二値で示し、分析を簡単にします。

このフラグは「On-Time Change Completion Rate」KPIの算出基盤です。ダッシュボードのフィルターとして使い、遅延した変更だけを抽出して分析することで、遅延の共通する根本原因を特定できます。

重要な理由

期限を守れたかどうかを明確な成功または失敗の結果として示し、パフォーマンス分析を簡単にします。期限内完了KPIの直接的な基盤です。

入手先

ソースシステムには存在しない属性です。データ変換時に「ActualCompletionDate」<=「TargetCompletionDate」を比較して算出されます。

truefalse
必須 推奨 任意

変更管理アクティビティ

正確なプロセスディスカバリーとパフォーマンス測定に向け、イベントログに取得すべき主要なプロセス手順とマイルストーンです。
7 推奨 7 任意
アクティビティ 説明
CABによる変更承認
変更諮問委員会(CAB)または指定された承認権限者が、変更の実施を承認する重要なマイルストーンです。変更要求のステータスが「Approved」に更新されたことから推定されます。
重要な理由

このアクティビティは、承認サイクル時間を測定する際の終点です。プロセスの停滞を解消し、計画と実装を開始できる状態にします。また、変更承認サイクル時間KPIの算出に欠かせません。

入手先

Change Requestオブジェクトの監査履歴から推定されます。具体的には、「Status」フィールドが「Approved」に変更された時刻を取得します。

取得

ステータスが「Approved」に変更されたことから推定されます。

イベントタイプ inferred
変更のクローズ
変更管理プロセスが正常に完了したことを示す最終的な終点です。変更要求のステータスが「Closed」に設定され、すべての作業が完了した時点で取得されます。
重要な理由

主要な成功の終点として、正常に完了した変更のエンドツーエンドのサイクル時間を算出するために欠かせません。プロセスの全ステップが終了したことを確認できます。

入手先

Change Requestオブジェクトの監査履歴における、最終的な「Closed」へのステータス変更時刻から推定されます。

取得

最終的なステータス変更で「Closed」になったことから推定されます。

イベントタイプ inferred
変更のスケジュール確定
変更の実装日時が正式に確定し、記録された時点を示します。ステータスが「Scheduled」に更新された時点で取得されます。
重要な理由

重要なコミットメントのマイルストーンです。承認済みの構想を計画済みのアクションへ移行し、実装に進むための前提となります。

入手先

Change Requestオブジェクトの履歴から、「Status」フィールドが「Scheduled」に更新された時刻を取得して推定されます。

取得

ステータスが「Scheduled」に変更されたことから推定されます。

イベントタイプ inferred
変更の実装完了
変更に関する技術作業が完了したことを示すマイルストーンです。変更要求のステータスが「Implemented」または検証待ちの同様の状態に更新された時点で取得されます。
重要な理由

重要な成功のマイルストーンであり、予定どおりの変更完了率および平均変更実装時間KPIの主要な入力値です。実行段階の終了を示します。

入手先

Change Requestオブジェクトの監査ログから、「Implemented」または「Pending Verification」へのステータス変更時刻を使って推定されます。

取得

ステータスが「Implemented」に変更されたことから推定されます。

イベントタイプ inferred
変更リクエストの作成
このアクティビティは、システムで新しい変更リクエストが開始されたことを示します。通常は、Change Requestビジネスオブジェクトに新しいレコードが作成された時点で記録され、プロセス全体の開始点となります。
重要な理由

これはプロセスの主な開始イベントです。このアクティビティから他のアクティビティまでの時間を分析すると、ライフサイクル全体の所要時間を把握し、初期段階の遅延を特定できます。

入手先

このイベントは、Change Requestレコードの作成Timestampから取得します。Ivanti Cherwellでは通常、Change Requestビジネスオブジェクトの「CreatedDateTime」フィールドに保存されています。

取得

レコードの作成Timestampから直接取得します。

イベントタイプ explicit
実装後レビューの実施
完了した変更について正式なレビューを実施し、成功度を評価するとともに、得られた教訓を記録したことを示します。多くの場合、「Post Implementation Review」へのステータス変更から推定されます。
重要な理由

このアクティビティを追跡することで、変更に関するフィードバックの循環を完了できます。継続的な改善に欠かせず、実装後レビュー率KPIを直接支援します。

入手先

Change Requestオブジェクトの監査履歴から、「Status」が「Post Implementation Review」などの状態に移行した時刻を取得して推定されます。

取得

ステータスが「Post Implementation Review」に変更されたことから推定されます。

イベントタイプ inferred
影響度とリスクの評価完了
このアクティビティは、変更リクエストのリスクと影響の分析が完了したことを示します。通常は、変更リクエストのステータスが「Awaiting Approval」など、承認に進める状態へ移行した時点で推定します。
重要な理由

このアクティビティを追跡すると、評価フェーズの所要時間を測定し、承認前にリスク分析が一貫して実施されていることを確認できます。Risk Assessment Adherence Rate KPIの評価にも役立ちます。

入手先

Change Requestオブジェクトの履歴から推定します。「Status」フィールドが「Assessing」から「Awaiting CAB Approval」などのステータスに更新されたTimestampで記録します。

取得

「Awaiting CAB Approval」へのステータス変更から推定します。

イベントタイプ inferred
変更のキャンセル
承認済みまたは進行中の変更要求が、完了前に取り下げられた最終状態を表します。ステータスが「Cancelled」に更新された時点で取得されます。
重要な理由

代替となるプロセスの終点です。変更がキャンセルされた理由と時期を分析することで、計画、リソース配分、または変化するビジネス上の優先順位に関する問題を明らかにできます。

入手先

監査履歴から、Change Requestオブジェクトの「Status」フィールドが「Cancelled」に更新された時刻を取得して推定されます。

取得

ステータスが「Cancelled」に変更されたことから推定されます。

イベントタイプ inferred
変更の承認待ち
このアクティビティは、変更リクエストがChange Advisory Board(CAB)またはその他の承認権限者による正式な判断を待っている期間を示します。「Pending Approval」や「Awaiting CAB」などのステータスから推定します。
重要な理由

これは重要な待機時間のアクティビティです。所要時間を分析することで、変更管理で遅延の一般的な原因となる承認ワークフローのボトルネックを特定できます。

入手先

Change Requestビジネスオブジェクトの「Status」フィールドが「Pending Approval」または同等の値に更新されたTimestampから取得します。

取得

「Pending Approval」ステータスへの移行によって特定します。

イベントタイプ inferred
変更を評価に提出
新しく作成された変更リクエストを初期評価に正式提出したことを示します。通常は、変更リクエストのステータスが「New」または「Draft」から「Assessing」などの状態に移行した時点で推定します。
重要な理由

このアクティビティは、初期入力後に正式な変更プロセスが始まったことを示します。作成から提出までの時間は、ユーザートレーニングの必要性やプロセス上の摩擦を示す場合があります。

入手先

Change Requestオブジェクトの監査ログまたは履歴から、「Status」フィールドが「Assessing」や「Submitted」などの値に変更されたTimestampを特定して推定します。

取得

「New」から「Assessing」へのステータス変更から推定します。

イベントタイプ inferred
変更却下
承認段階で変更要求を却下する最終判断を表すアクティビティです。変更要求のステータスが「Rejected」に設定された時点で取得されます。
重要な理由

重大な失敗の終点です。却下された変更とその理由を分析することで、初回申請の品質向上に役立ち、変更要求却下率KPIを支援します。

入手先

監査履歴において、Change Requestオブジェクトの「Status」フィールドが「Rejected」に更新された時刻から推定されます。

取得

ステータスが「Rejected」に変更されたことから推定されます。

イベントタイプ inferred
変更実装の開始
変更の技術的な実行が始まったことを表します。通常、変更要求のステータスが「In Progress」または「Implementing」に移行した時点から推定されます。
重要な理由

実装期間の開始を示すアクティビティです。ここから「Change Implemented」までの時間が実際の実装所要時間となり、全体のサイクル時間を構成する重要な要素です。

入手先

Change Requestオブジェクトの監査履歴から推定されます。「Status」フィールドが「In Progress」や「Implementing」などの値に更新された時刻です。

取得

ステータスが「In Progress」に変更されたことから推定されます。

イベントタイプ inferred
変更検証の実施
変更が正常に完了し、悪影響を引き起こしていないことを確認するテストおよび検証段階を表します。「Verification」または「Testing」へのステータス変更から推定されます。
重要な理由

このアクティビティの頻度と所要時間を分析することで、品質保証の手順が省略されていないかを確認できます。変更に起因するインシデントを防ぐための重要なステップです。

入手先

Change Requestオブジェクトのステータス変更時刻から取得されます。たとえば、「Verification」または「User Acceptance Testing」への移行時刻です。

取得

ステータスが「Verification」に変更されたことから推定されます。

イベントタイプ inferred
実装計画の策定完了
タスク、リソース、ロールバック計画の定義を含む、変更の詳細計画が完了したことを示します。多くの場合、変更が「Approved」から「Scheduled」に移行した時点から推定されます。
重要な理由

このアクティビティの所要時間から、変更計画段階の効率を把握できます。承認後であっても、ここでの遅延は変更全体のスケジュールに影響します。

入手先

「Approved」から「Scheduled」へのステータス変更時刻から推定できます。または、特定の計画項目が入力された時点と関連付けることもできます。

取得

「Approved」から「Scheduled」へのステータス変更から推定されます。

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

抽出ガイド

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

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

このテンプレートを使って、変更管理プロセスの分析を始め、改善を進めてください。より効率的で最適化された更新に向けた取り組みを、今日から始められます。

変更成功率95%を実現:今すぐIvanti Cherwellを最適化

ボトルネックをなくし、リスクを抑え、変更成功率95%を実現します。

無料トライアルを開始

クレジットカードは不要です。すぐに始められます。