変更管理データテンプレート
変更管理データテンプレート
- 収集を推奨する属性
- 追跡する主要なアクティビティ
- Ivanti Cherwellからのデータ抽出ガイド
変更管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
変更管理プロセスの中で、特定の時点に発生したイベントまたはタスクの名前です。 | ||
|
説明
アクティビティ名は、変更要求のライフサイクルにおける具体的なステップやマイルストーンを示します。たとえば、「評価のために変更を提出」や「CABによる変更の承認」などです。これらのアクティビティが、検出されたプロセスマップのノードになります。 分析では、プロセスフローの可視化、イベントの順序の特定、標準手順からの逸脱の検出に欠かせない属性です。アクティビティ間の移行時間を算出し、遅延が発生している箇所を把握するためにも使います。
重要な理由
実際のプロセスフローを検出して可視化するうえで重要な属性です。ボトルネック、手戻りのループ、コンプライアンスに沿わない経路を特定できます。
入手先
Ivanti Cherwellの変更要求オブジェクトに関連するステータス変更、ジャーナルエントリー、または特定のイベントログから生成されます。
例
変更要求を評価に提出変更の承認待ち変更の実装完了
|
|||
|
イベント時刻
EventTime
|
変更要求に関する特定のアクティビティまたはイベントが発生した時刻です。 | ||
|
説明
イベント時刻はタイムスタンプとも呼ばれ、アクティビティが発生した正確な日時を記録します。この時間データはイベントを時系列に並べるために必要であり、時間に基づくプロセスマイニング分析の基礎となります。 この属性を使ってアクティビティ間の所要時間やケース全体のサイクルタイムを算出し、プロセス内の待ち時間や遅延を特定します。また、変更承認のサイクルタイムなど、時間に関する目標に対するパフォーマンスを監視するダッシュボードの作成にも欠かせません。
重要な理由
このタイムスタンプは、パフォーマンスや所要時間の分析の基礎となります。サイクルタイムの算出、ボトルネックの特定、SLAの監視に役立ちます。
入手先
通常、Ivanti Cherwellの変更要求オブジェクトに関連するステータス変更ログ、監査証跡、またはジャーナルエントリーのタイムスタンプに記録されています。
例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
変更要求ID
ChangeRequestId
|
1件の変更要求ケースを一意に識別するIDです。開始からクローズまで、関連するすべてのアクティビティをまとめます。 | ||
|
説明
変更要求IDは、変更のライフサイクル全体を通じて各変更案件を一意に識別する主キーです。プロセスマイニングではケース識別子として機能し、申請、評価、承認、実装などのイベントを1つのプロセスインスタンスに結び付けます。 変更要求IDを使ってデータを分析すると、変更管理プロセスを最初から最後まで把握できます。個々の変更の追跡、総サイクルタイムの算出、要求ごとのプロセス逸脱やボトルネックの特定が可能になります。
重要な理由
関連するすべてのイベントを結び付ける重要なケース識別子です。変更要求の全過程を追跡し、パフォーマンスを分析できます。
入手先
通常、Ivanti Cherwellの変更要求ビジネスオブジェクトを識別する主キーです。
例
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」などが該当します。 | ||
|
説明
変更ステータスは、特定の時点における変更要求の状態、または最終的な結果を示します。ケースの解決状況を把握し、例外を特定するための重要な属性です。 プロセス分析では、却下またはキャンセルされた変更だけを分析するなど、特定の結果で絞り込むために使います。「変更要求の却下率」などの重要業績評価指標(KPI)の算出に使われ、変更管理プロセス全体の健全性と効率を把握するうえで欠かせません。
重要な理由
変更要求の結果を示し、却下率や完了率、未完了ケースとクローズ済みケースの内訳を分析できます。
入手先
Ivanti Cherwellの変更要求ビジネスオブジェクトにある「Status」フィールドに対応します。
例
承認済み却下クローズ済みキャンセル済み承認待ち
|
|||
|
変更タイプ
ChangeType
|
変更の分類です。「Standard」「Normal」「Emergency」などがあります。 | ||
|
説明
変更タイプは、変更要求の性質、緊急度、影響に基づいて分類します。一般的なタイプには、事前承認済みでリスクの低い「Standard」、詳細な評価と承認が必要な「Normal」、即時の実装が必要な「Emergency」があります。 この属性を使うと、カテゴリごとにプロセスのパフォーマンスを比較できます。たとえば、緊急変更が通常とは異なる迅速な経路をたどるか、標準変更が実際に最小限の手間で処理されているかを確認できます。「問題のある変更タイプのパフォーマンス」ダッシュボードの分析に欠かせません。
重要な理由
変更タイプごとにプロセスを分けて分析することは、パフォーマンスの比較に欠かせません。「Emergency」など特定のカテゴリがボトルネックや逸脱の原因になっているかを特定できます。
入手先
変更要求ビジネスオブジェクトにある「Change Type」または「Category」などの分類フィールドに対応します。
例
標準通常緊急
|
|||
|
変更リスクレベル
ChangeRiskLevel
|
変更に伴う評価済みのリスクレベルです。「Low」「Medium」「High」などがあります。 | ||
|
説明
変更リスクレベルは、変更によって生じる可能性のある悪影響を数値化するため、評価段階で割り当てる分類です。この評価は、承認プロセスや必要な審査の厳しさに影響することがあります。 プロセスマイニングでは、この属性を使ってリスク評価の一貫性を分析し、リスクとプロセスの動きとの関係を調べます。たとえば、高リスクの変更がより厳格な承認経路をたどるか、実装に時間がかかるかを確認できます。「変更リスク評価の一貫性」ダッシュボードの分析に直接役立ちます。
重要な理由
リスクがプロセスフロー、承認サイクル、成功率に与える影響を分析できます。高リスクの変更が適切な審査を受けているか確認するのに役立ちます。
入手先
この値は変更要求オブジェクトの「Risk Level」または同様のフィールドに保存され、通常はリスク評価のアクティビティ中に入力されます。
例
低中高重大
|
|||
|
変更担当チーム
ChangeTeam
|
変更要求を現在担当しているチームまたはグループです。 | ||
|
説明
変更担当チームは、変更要求を担当するグループまたは部門です。変更責任者と同様に、プロセスの途中で担当が変わることがあります。たとえば、サービスデスクからネットワークエンジニアリングチームへ責任が移る場合です。 この属性は、チーム間の引き継ぎを分析し、特定のチームが原因となる組織的な遅延を特定するうえで重要です。どのチームの業務負荷が高いか、どこでコミュニケーションに問題が生じているかを把握でき、「変更の引き継ぎとリソース利用状況」の分析に役立ちます。
重要な理由
チーム単位の責任を特定できます。プロセスのボトルネックの分析、チームのパフォーマンス測定、グループ間の引き継ぎによる遅延の把握に役立ちます。
入手先
通常、この情報は変更要求オブジェクトの「Owned By Team」または同様のグループ割り当てフィールドに保存されています。
例
ネットワーク運用データベース管理アプリケーションサポート
|
|||
|
変更責任者
ChangeOwner
|
変更要求を現在担当しているユーザーまたは担当者です。 | ||
|
説明
変更責任者は、特定の段階で変更要求を担当し、その遂行に責任を負う人です。要求のライフサイクルに沿って担当者が変わることがあり、担当者間の引き継ぎを示します。 変更責任者を分析すると、リソースの業務負荷を把握し、特定の担当者に関係するボトルネックを特定できます。また、遅延の大きな原因となることがある引き継ぎの分析にも欠かせません。「変更の引き継ぎとリソース利用状況」ダッシュボードの分析に役立ちます。
重要な理由
個人ごとの責任を追跡し、業務負荷の分布、引き継ぎの頻度、特定のリソースに関するボトルネックを分析できます。
入手先
通常、変更要求ビジネスオブジェクトの「Owned By」または「Assigned To」フィールドに該当します。
例
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
目標完了日
TargetCompletionDate
|
変更の実装を完了するために計画または合意された期限です。 | ||
|
説明
目標完了日は、変更の実装と検証が完了する予定の日時です。サービスレベル契約(SLA)に含まれることが多く、パフォーマンスを測る主要な基準となります。 この属性は、期限の遵守状況を監視するうえで欠かせません。実際の完了日と比較し、「変更の期限内完了率」や「変更のSLA遵守率」の重要業績評価指標(KPI)を算出します。目標期限に間に合わないリスクがある変更を、事前に特定するのにも役立ちます。
重要な理由
期限内の完了状況とSLAの遵守状況を測る基準となり、プロセスの効率と信頼性を示す重要な指標です。
入手先
通常、変更要求オブジェクトにある日付フィールドで、「Target Date」「Due Date」「SLA Target」などの名前が付いています。
例
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
|
|||
|
事業部門
BusinessUnit
|
変更を要求した、または変更による効果を受ける事業部門や部署です。 | ||
|
説明
この属性は、変更要求を「Finance」「Marketing」「Operations」など、組織内の特定の部門に関連付けます。技術的なプロセスに事業上のコンテキストを加えます。 事業部門ごとに分析すると、変更の需要がどこから生じているかを把握できます。費用配賦モデルの検討、IT変更が各事業機能に与える影響の把握、特定の部門で複雑化や遅延が多いかどうかの特定に役立ちます。
重要な理由
事業上のコンテキストを示し、組織の視点から変更の需要、影響、パフォーマンスを分析できます。
入手先
変更要求オブジェクトのフィールドに保存される場合と、申請者のユーザープロフィールから引き継がれる場合があります。
例
財務人事営業・マーケティング運用
|
|||
|
却下理由
ChangeRejectionReason
|
変更要求が却下された理由を説明する文章またはカテゴリです。 | ||
|
説明
変更要求が却下された場合、この属性には承認者が示した理由が記録されます。あらかじめ定義されたリストから選択する場合と、自由記述で説明する場合があります。 この情報は、「却下された変更要求の分析」ダッシュボードに欠かせません。却下理由を分類して分析すると、情報不足、不十分なリスク評価、事業上の競合など、変更申請に共通する問題を特定できます。こうしたインサイトを今後の変更要求の品質向上に役立てられます。
重要な理由
変更が却下される理由を直接把握できます。申請と評価のプロセスを的確に改善し、全体の却下率を下げるのに役立ちます。
入手先
通常、「Rejection Reason」専用フィールド、またはステータスが「Rejected」に変更された際に入力されるメモ欄に記録されます。
例
実装計画の詳細が不十分リスク評価が未完了ほかの予定済み変更と競合
|
|||
|
変更の優先度
ChangePriority
|
変更要求の優先度です。緊急度と事業への影響を示します。 | ||
|
説明
変更の優先度は、変更の緊急度と影響を組み合わせて決定する分類です。チームが作業の優先順位を付け、リソースを適切に配分し、最も重要な変更から対応できるようにします。 分析では、優先度の高い変更が低い変更より速く処理されているかを確認できます。この想定から外れている場合、優先順位付けや実行プロセスに非効率やボトルネックがある可能性があります。
重要な理由
影響の大きい変更が適切に優先され、意図どおりに迅速な対応を受けているかを分析できます。
入手先
通常、変更要求オブジェクトの「Priority」フィールドに該当します。手動で設定する場合と、影響度や緊急度のフィールドから算出する場合があります。
例
1 - 重大2 - 高3 - 中4 - 低
|
|||
|
変更申請者
ChangeSubmitter
|
変更要求を最初に作成または申請したユーザーです。 | ||
|
説明
この属性は、変更要求を開始した人を特定します。プロセスの後半で実装を担当する変更責任者とは異なる場合があります。 変更申請者を分析すると、要求の品質に関する傾向を特定できます。たとえば、特定の個人やチームが不完全な要求を頻繁に提出し、却下や手戻りにつながっていることが分かる場合があります。こうしたインサイトを対象を絞ったトレーニングに役立て、申請全体の品質を高められます。
重要な理由
変更要求の起点を追跡し、個人やチームごとの申請品質を分析できます。トレーニングが必要な領域の特定にも役立ちます。
入手先
通常、変更要求オブジェクトの「Created By」または「Requested By」フィールドに該当します。
例
Susan MillerDavid ChenMaria Garcia
|
|||
|
実装サイクルタイム
ImplementationCycleTime
|
変更の実装開始から完了までにかかった時間です。 | ||
|
説明
変更の実装フェーズにかかった時間を示す指標です。「Change Implementation Started」アクティビティから「Change Implemented」アクティビティまでの期間として算出します。 この属性は、重要業績評価指標(KPI)「変更実装の平均時間」の算出に使い、「変更実装のフローと遅延」ダッシュボードにも対応します。計画段階の遅延と実行段階の遅延を区別できるため、技術的な実装作業そのものに改善の取り組みを集中できます。
重要な理由
実際の実装フェーズのパフォーマンスを切り分けて確認できます。承認の遅れとは別に、技術面やリソース面のボトルネックを特定するのに役立ちます。
入手先
プロセスマイニングツールまたはデータ変換時に、実装の開始イベントと終了イベントのタイムスタンプの差を求めて算出します。
例
4時間15分1日2時間30分
|
|||
|
実際の完了日
ActualCompletionDate
|
変更が実際に実装され、完了が確認された時刻です。 | ||
|
説明
実際の完了日は、変更要求の実装作業が終了した時点を示します。計画上の期限と比較してパフォーマンスを測る重要なマイルストーンです。 この属性を目標完了日と組み合わせて、変更が期限内に完了したかを判定します。「変更の期限内完了率」などの重要業績評価指標(KPI)の算出や、実装段階で遅延が発生した原因の分析に欠かせません。
重要な理由
実際の完了時刻を記録します。期限内の完了率の算出や、遅延の程度の分析に必要です。
入手先
通常、変更要求のステータスが「Implemented」または「Completed」に変更された時点で記録されます。専用フィールドに保存される場合と、ステータス変更のタイムスタンプから推定される場合があります。
例
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
|
|||
|
影響を受けるサービス
ServiceAffected
|
変更によって主に影響を受ける事業サービスまたは構成アイテム(CI)です。 | ||
|
説明
この属性は、変更要求の対象となる主なITサービス、アプリケーション、またはインフラストラクチャを特定します。変更管理プロセスと、より広範なITサービス管理の全体像を結び付けます。 影響を受けるサービスごとの分析は、「問題のある変更タイプ上位」の重要業績評価指標(KPI)に欠かせません。変更が最も頻繁に行われるサービスや、却下率や遅延が高いサービスを特定できます。サービス責任者が安定性を高め、技術的負債を管理するための参考になります。
重要な理由
変更を特定の事業サービスに結び付け、最も不安定なサービスや問題のある変更が多いサービスを分析できます。
入手先
通常、構成管理データベース(CMDB)から関連付けられ、変更要求オブジェクトの「Primary CI」または「Service」フィールドに保存されます。
例
メールサービス(Exchange)ERPシステム(SAP)コアネットワークスイッチ(CISCO-4500X)
|
|||
|
期限内完了かどうか
IsOnTimeCompletion
|
変更が目標日までに完了した場合に真となる、計算で求めるフラグです。 | ||
|
説明
「ActualCompletionDate」と「TargetCompletionDate」を比較して求める真偽値属性です。各変更要求が期限内に完了したかどうかを明確に示すため、分析しやすくなります。 このフラグは、重要業績評価指標(KPI)「変更の期限内完了率」の算出に使います。ダッシュボードのフィルターとして使えば、期限に遅れた変更を抽出して分析し、遅延の共通原因を特定できます。
重要な理由
期限を守れたかどうかを明確に示すため、パフォーマンス分析がしやすくなり、期限内完了に関する重要業績評価指標(KPI)の算出にも直接使えます。
入手先
この属性はソースシステムにはありません。データ変換時に「ActualCompletionDate」<=「TargetCompletionDate」を比較して算出します。
例
truefalse
|
|||
変更管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
CABが変更を承認
|
変更諮問委員会(CAB)または指定された承認権限者が、変更の実施を承認する重要な節目です。変更要求の状態が「承認済み」に更新された時点で推定します。 | ||
|
重要な理由
このアクティビティは、承認サイクルタイムの測定終了点です。承認によってプロセスが次に進み、計画や実施を開始できます。変更承認サイクルタイムの重要業績評価指標(KPI)の把握にも欠かせません。
入手先
変更要求オブジェクトの監査履歴から推定します。特に、「状態」フィールドが「承認済み」に変わったタイムスタンプを取得します。
記録
状態が「承認済み」に変わった時点から推定。
イベントタイプ
inferred
|
|||
|
変更のクローズ
|
このアクティビティは、変更管理プロセスが正常に完了したことを示す最終地点です。変更要求のステータスが「Closed」に設定され、すべての作業が完了した時点で記録されます。 | ||
|
重要な理由
成功した変更の主要な完了地点であり、エンドツーエンドのサイクルタイムを算出するうえで欠かせません。プロセスのすべてのステップが終了したことを確認できます。
入手先
変更要求オブジェクトの監査履歴に記録された、最終ステータスが「Closed」に変更された時刻から推定します。
記録
最終ステータスが「Closed」に変更されたことから推定します。
イベントタイプ
inferred
|
|||
|
変更の実装完了
|
このマイルストーンは、変更に関する技術的な作業が完了したことを示します。変更要求のステータスが「Implemented」または検証待ちの同様の状態に更新された時点で記録されます。 | ||
|
重要な理由
これは、成功を判断するうえで重要なマイルストーンであり、「変更の期限内完了率」と「変更の平均実装時間」の重要業績評価指標(KPI)の算出に必要なデータです。実行フェーズの終了を示します。
入手先
変更要求オブジェクトの監査ログから、「Implemented」または「Pending Verification」へのステータス変更時刻を使って推定します。
記録
ステータスが「Implemented」に変更されたことから推定します。
イベントタイプ
inferred
|
|||
|
変更をスケジュール
|
このアクティビティは、変更の実施日時が正式に確定し、記録された時点を示します。状態が「スケジュール済み」に更新されたときに記録します。 | ||
|
重要な理由
これは、重要な確約を示すマイルストーンです。変更を承認済みの構想から計画済みの作業へ移行させるもので、実装に進むための前提となります。
入手先
変更要求オブジェクトの履歴から、「Status」フィールドが「Scheduled」に更新された時刻を取得して推定します。
記録
ステータスが「Scheduled」に変更されたことから推定します。
イベントタイプ
inferred
|
|||
|
変更要求を作成
|
このアクティビティは、システムで新しい変更要求が作成された時点を示します。通常、変更要求のビジネスオブジェクトに新しいレコードが作成されたときに記録され、プロセス全体の開始点となります。 | ||
|
重要な理由
これはプロセスの主な開始イベントです。このアクティビティから他のアクティビティまでの時間を分析すると、ライフサイクル全体の所要時間を把握し、初期段階の遅延を特定できます。
入手先
このイベントは、変更要求レコードの作成タイムスタンプから取得します。Ivanti Cherwellでは通常、変更要求のビジネスオブジェクトにある「CreatedDateTime」フィールドに保存されています。
記録
レコードの作成タイムスタンプから直接取得。
イベントタイプ
explicit
|
|||
|
実装後レビューの実施
|
このアクティビティは、完了した変更について正式なレビューを行い、成功の度合いを評価して教訓を記録したことを示します。多くの場合、ステータスが「Post Implementation Review」に変更されたことから推定します。 | ||
|
重要な理由
このアクティビティを追跡することで、変更に関するフィードバックが確実に反映されているか確認できます。継続的な改善に欠かせず、「実装後レビュー率」の重要業績評価指標(KPI)にも直接関係します。
入手先
変更要求オブジェクトの監査履歴から、「Status」が「Post Implementation Review」などの状態に変わった時刻を取得して推定します。
記録
ステータスが「Post Implementation Review」に変更されたことから推定します。
イベントタイプ
inferred
|
|||
|
影響とリスクを評価
|
このアクティビティは、変更要求のリスクと影響の分析が完了したことを示します。通常、変更要求の状態が「承認待ち」など、承認に進める状態に変わった時点で推定します。 | ||
|
重要な理由
このアクティビティを追跡すると、評価段階の所要時間を測定し、承認前にリスク分析が一貫して実施されているかを確認できます。リスク評価遵守率の重要業績評価指標(KPI)の把握にも役立ちます。
入手先
変更要求オブジェクトの履歴から推定します。「状態」フィールドが「評価中」から「CAB承認待ち」などに更新されたタイムスタンプを取得します。
記録
状態が「CAB承認待ち」に変わった時点から推定。
イベントタイプ
inferred
|
|||
|
変更のキャンセル
|
承認済みまたは進行中の変更要求が、完了前に取り下げられた終端状態を示します。ステータスが「Cancelled」に更新された時点で記録されます。 | ||
|
重要な理由
これは、プロセスのもう1つの終了地点です。変更がキャンセルされた理由や時期を分析すると、計画、リソース配分、または変化する事業上の優先事項に関する問題が見つかることがあります。
入手先
変更要求オブジェクトの「Status」フィールドが「Cancelled」に更新された時刻を監査履歴から取得して推定します。
記録
ステータスが「Cancelled」に変更されたことから推定します。
イベントタイプ
inferred
|
|||
|
変更の実装開始
|
変更に関する技術的な作業の開始を示します。通常、変更要求のステータスが「In Progress」または「Implementing」に変更された時点から推定します。 | ||
|
重要な理由
このアクティビティは、実装期間の開始を示します。この時点から「変更の実装完了」までの時間が実際の実装所要時間となり、全体のサイクルタイムを構成する重要な要素です。
入手先
変更要求オブジェクトの監査履歴から推定します。「Status」フィールドが「In Progress」や「Implementing」などに更新された時刻が該当します。
記録
ステータスが「In Progress」に変更されたことから推定します。
イベントタイプ
inferred
|
|||
|
変更の承認待ち
|
変更要求が変更諮問委員会(CAB)または別の承認権限者による正式な判断を待っている期間を示します。「承認保留中」や「CAB待ち」などの状態から推定します。 | ||
|
重要な理由
これは重要な待ち時間を示すアクティビティです。所要時間を分析すると、変更管理でよく遅延の原因となる承認ワークフローのボトルネックを特定できます。
入手先
変更要求のビジネスオブジェクトにある「状態」フィールドが「承認保留中」または同等の値に更新されたタイムスタンプから取得します。
記録
「承認保留中」状態への移行によって特定。
イベントタイプ
inferred
|
|||
|
変更の検証実施
|
変更が成功し、悪影響が生じていないことを確認するためのテストと検証の段階を示します。ステータスが「Verification」または「Testing」に変更されたことから推定します。 | ||
|
重要な理由
このアクティビティの頻度と所要時間を分析することで、品質保証の手順が省略されていないか確認できます。変更に起因するインシデントを防ぐうえで欠かせないステップです。
入手先
変更要求オブジェクトのステータス変更時刻から記録します。「Verification」や「User Acceptance Testing」への変更などが該当します。
記録
ステータスが「Verification」に変更されたことから推定します。
イベントタイプ
inferred
|
|||
|
変更を却下
|
承認段階で変更要求を却下する最終判断を示します。変更要求の状態が「却下」に設定された時点で記録します。 | ||
|
重要な理由
これは重要な失敗の終点です。却下された変更とその理由を分析することで、申請時の品質を高め、変更要求却下率の重要業績評価指標(KPI)の把握に役立てられます。
入手先
監査履歴で、変更要求オブジェクトの「状態」フィールドが「却下」に更新されたタイムスタンプから推定します。
記録
状態が「却下」に変わった時点から推定。
イベントタイプ
inferred
|
|||
|
変更要求を評価に提出
|
新しく作成された変更要求を初期評価に正式に提出したことを示します。通常、変更要求の状態が「新規」または「下書き」から「評価中」などに変わった時点で推定します。 | ||
|
重要な理由
このアクティビティは、初期データの入力後に正式な変更プロセスが始まったことを示します。作成から提出までの時間から、ユーザートレーニングの必要性やプロセス上の障害を把握できます。
入手先
変更要求オブジェクトの監査ログまたは履歴から、「状態」フィールドが「評価中」や「提出済み」などに変わったタイムスタンプを特定して推定します。
記録
状態が「新規」から「評価中」に変わった時点から推定。
イベントタイプ
inferred
|
|||
|
実施計画を策定
|
タスク、リソース、ロールバック計画の定義など、変更の詳細な計画が完了したことを示します。多くの場合、変更の状態が「承認済み」から「スケジュール済み」に変わった時点で推定します。 | ||
|
重要な理由
このアクティビティの所要時間から、変更計画段階の効率を把握できます。承認後であっても、ここでの遅延は変更全体のスケジュールに影響します。
入手先
状態が「承認済み」から「スケジュール済み」に変わったタイムスタンプから推定できます。または、特定の計画フィールドへの入力を基準にすることもできます。
記録
状態が「承認済み」から「スケジュール済み」に変わった時点から推定。
イベントタイプ
inferred
|
|||
データ抽出ガイド
始める準備はできていますか?
このテンプレートを使って変更管理プロセスの分析を始め、改善につなげましょう。変更作業の効率化に向けて、今日から取り組みを始められます。
変更成功率95%を目指す:今すぐIvanti Cherwellを最適化
ボトルネックを解消し、リスクを減らして、変更成功率95%を目指しましょう。
クレジットカードは不要です。すぐに始められます。