貴社の変更管理データテンプレート
貴社の変更管理データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- 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
|
単一の変更リクエストケースのユニークな識別子で、開始からクローズまでのすべての関連アクティビティをグループ化します。 | ||
|
説明
変更リクエストIDは、そのライフサイクルを通じて各変更イニシアチブを一意に識別する主キーです。プロセスマイニングではケース識別子として機能し、提出、評価、承認、実装などのすべてのイベントを単一のまとまったプロセスインスタンスにリンクさせます。 変更リクエストIDを使用してデータを分析することで、変更管理プロセスの完全なエンドツーエンドビューが可能になります。これにより、個々の変更の追跡、総サイクルタイムの計算、各リクエストに固有のプロセス逸脱やボトルネックの特定が可能になります。
その重要性
これは、すべての関連イベントを接続する不可欠なケース識別子であり、変更リクエストの全過程を追跡し、そのパフォーマンスを分析することを可能にします。
取得元
これは通常、Ivanti Cherwellにおける変更リクエストビジネスオブジェクトの主要な識別子です。
例
CR-105421CR-105422CR-105423
|
|||
|
ソースシステム
SourceSystem
|
データが抽出された記録システム。このビューでは「Ivanti Cherwell」となります。 | ||
|
説明
この属性は、イベントデータの発生元システムを識別します。異種環境では、異なるソースからのデータを区別するのに役立ちます。この特定のデータモデルでは、データがIvanti Cherwellから来ることを示す定数値となります。 単一ソースモデルでは静的に見えるかもしれませんが、データガバナンス、トレーサビリティ、および将来の他のシステムとの統合にとって不可欠です。データの出所に関する明確さを確保し、データ品質の管理に役立ちます。
その重要性
データの出所に関する不可欠なコンテキストを提供します。これは、データガバナンス、トラブルシューティング、およびトレーサビリティの確保に不可欠です。
取得元
データ抽出・変換の過程で付与する固定値で、データセットのソースを示すラベルとして利用します。
例
Ivanti Cherwell
|
|||
|
最終データ更新
LastDataUpdate
|
このイベントのデータがソースシステムから最後に抽出または更新された時点を示すタイムスタンプ。 | ||
|
説明
この属性は、データがIvanti Cherwellから最後に取得された日時を記録します。プロセス自体におけるイベントを表すものではなく、データの鮮度に関するメタデータです。 これは、ダッシュボード利用者が分析の現在の状態を理解するために重要です。データ更新スケジュールを管理し、既知の年代のデータに基づいて意思決定が行われることを保証するのに役立ちます。
その重要性
データの鮮度を示します。これは、ユーザーが分析を信頼し、現在の業務状態との関連性を理解するために不可欠です。
取得元
このタイムスタンプは、データ抽出、変換、ロード(ETL)プロセス中に各レコードに生成および付与されます。
例
2024-05-21T02:00:00Z
|
|||
|
変更ステータス
ChangeStatus
|
「クローズ済み」、「却下済み」、「進行中」など、変更リクエストの現在または最終ステータス。 | ||
|
説明
変更ステータスは、特定の時点での変更リクエストの状態または最終的な結果を示します。これはケース解決を理解し、例外を特定するための重要な属性です。 プロセス分析では、この属性は、却下またはキャンセルされた変更のみを分析するなど、特定の成果でフィルタリングするために使用されます。「変更リクエスト却下率」のようなKPIを強化し、変更管理プロセス全体の健全性と効率性を理解するために不可欠です。
その重要性
変更リクエストの結果を定義し、却下率、完了率、オープンケースとクローズドケースの分布に関する重要な分析を可能にします。
取得元
これは、Ivanti Cherwellの変更リクエストビジネスオブジェクトの「ステータス」フィールドに対応します。
例
承認済み却下クローズ取り消し済み承認待ち
|
|||
|
変更タイプ
ChangeType
|
「標準」、「通常」、「緊急」など、変更の分類。 | ||
|
説明
変更タイプは、変更リクエストをその性質、緊急性、および影響に基づいて分類します。一般的なタイプには、標準(事前承認済み、低リスク)、通常(完全な評価と承認が必要)、緊急(即時実装が必要)が含まれます。 この属性により、異なるカテゴリ間でのプロセスパフォーマンスを比較するためのセグメント化された分析が可能になります。たとえば、緊急変更が異なる、より速い経路をたどるのか、または標準変更が実際に最小限の摩擦で処理されるのかを判断するのに役立ちます。これは「問題のある変更タイプパフォーマンス」ダッシュボードの鍵となります。
その重要性
変更タイプ別にプロセスをセグメント化することは、パフォーマンスを比較し、「緊急」などの特定のカテゴリがボトルネックや逸脱の原因となっているかどうかを特定するために不可欠です。
取得元
例
標準通常緊急
|
|||
|
変更チーム
ChangeTeam
|
現在、変更リクエストに責任を負うチームまたはグループ。 | ||
|
説明
変更チームとは、変更リクエストに割り当てられたグループまたは部門です。変更オーナーと同様に、これはプロセス全体で変化する可能性があり、サービスデスクからネットワークエンジニアリングチームへの責任の移行など、チーム間の引き継ぎを示します。 この属性は、チーム間の引き継ぎを分析し、特定のチームによって引き起こされるシステム的な遅延を特定するために不可欠です。どのチームが過負荷であるか、またはコミュニケーションの断絶がどこで発生しているかといった疑問に答えるのに役立ち、「変更の引き継ぎとリソース利用」分析を直接サポートします。
その重要性
チームレベルの責任を特定し、これはプロセスボトルネックの分析、チームパフォーマンスの測定、およびグループ間のハンドオフ遅延の理解に不可欠です。
取得元
この情報は通常、変更リクエストオブジェクトの「Owned By Team」または類似のグループ割り当てフィールドに保存されます。
例
ネットワーク運用データベース管理アプリケーションサポート
|
|||
|
変更リスクレベル
ChangeRiskLevel
|
「低」、「中」、「高」など、変更に関連する評価されたリスクレベル。 | ||
|
説明
変更リスクレベルとは、評価フェーズ中に割り当てられる分類であり、変更の潜在的な負の影響を定量化します。この評価は、多くの場合、承認プロセスと必要な精査のレベルに影響を与えます。 プロセスマイニングでは、この属性はリスク評価の一貫性を分析し、リスクとプロセス動作を関連付けるために使用されます。例えば、高リスクの変更がより厳格な承認経路をたどるか、またはより長い実装時間を要するかどうかを確認できます。これは「変更リスク評価の一貫性」ダッシュボードを直接サポートします。
その重要性
リスクがプロセスフロー、承認サイクル、成功率にどのように影響するかを分析することを可能にし、高リスク変更が適切な精査を受けることを確実にするのに役立ちます。
取得元
この値は、変更リクエストオブジェクト上の「リスクレベル」または類似のフィールドに保存され、通常はリスク評価アクティビティ中に設定されます。
例
低中高クリティカル
|
|||
|
変更所有者
ChangeOwner
|
現在、変更リクエストに責任を負うユーザーまたは個人。 | ||
|
説明
変更オーナーとは、特定の段階で変更リクエストに割り当てられ、責任を負う人物です。この属性は、リクエストがライフサイクルを進むにつれて変化することが多く、個人間の引き継ぎを示します。 変更オーナーを分析することで、リソースの作業負荷を理解し、特定の個人に関連するボトルネックを特定するのに役立ちます。また、遅延の主要な原因となる引き継ぎの分析にも不可欠です。この属性は「変更の引き継ぎとリソース利用」ダッシュボードをサポートします。
その重要性
個人の責任を追跡し、作業負荷の分散、引き継ぎ頻度、およびリソース固有のボトルネックの分析を可能にします。
取得元
通常、変更リクエストビジネスオブジェクトの「所有者」または「担当者」フィールドです。
例
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
目標完了日
TargetCompletionDate
|
変更実装完了のための計画または合意された期限。 | ||
|
説明
目標完了日とは、変更が完全に実装され検証されると予想されるタイムスタンプです。この日付はサービスレベル契約(SLA)の一部であることが多く、パフォーマンスの主要なベンチマークとして機能します。 この属性は、期日厳守と期限遵守を監視するために不可欠です。実際の完了日と比較され、「期日内変更完了率」や「変更SLA遵守率」といったKPIを計算します。目標達成が危ぶまれる変更を積極的に特定するのに役立ちます。
その重要性
期日内パフォーマンスとSLA遵守を測定するためのベースラインを提供します。これらは、プロセス効率と信頼性の重要な指標です。
取得元
これは通常、変更リクエストオブジェクト上の特定の日付フィールドであり、しばしば「目標日」、「期日」、「SLA目標」とラベル付けされます。
例
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
|
|||
|
ビジネスユニット
BusinessUnit
|
変更を要求した、または変更から利益を得るビジネスユニットまたは部門。 | ||
|
説明
この属性は、変更リクエストを「財務」、「マーケティング」、「運用」など、組織の特定の部門と関連付けます。これにより、技術的なプロセスにビジネスコンテキストが提供されます。 ビジネスユニット別に分析することで、変更の需要がどこから発生しているかという視点が得られます。これは、チャージバックモデル、IT変更が異なるビジネス機能に与える影響の理解、および特定のユニットが他のユニットよりも複雑な変更や遅延の多い変更を抱えているかどうかの特定に役立ちます。
その重要性
ビジネスコンテキストを提供し、組織の視点から変更の需要、影響、パフォーマンスを分析できるようにします。
取得元
これは変更リクエストオブジェクトのフィールドであるか、リクエスト者のユーザープロファイルから継承される可能性があります。
例
財務人事`セールス`&`マーケティング`運用
|
|||
|
却下理由
ChangeRejectionReason
|
変更リクエストが却下された理由を説明するテキストによる説明またはカテゴリです。 | ||
|
説明
変更リクエストが却下された際、この属性には承認者によって提供された理由が記録されます。これは、事前に定義されたリストからの選択肢である場合もあれば、自由記述のテキスト説明である場合もあります。\n\nこの情報は、「却下された変更リクエスト分析」ダッシュボードにとって極めて重要です。却下理由を分類・分析することで、組織は情報不足、リスク評価の不十分さ、ビジネス上の衝突など、変更申請における一般的な問題点を特定できます。これらの洞察は、将来の変更リクエストの品質向上に活用できます。
その重要性
変更が失敗する理由への直接的な洞察を提供し、提出および評価プロセスへの的を絞った改善を可能にして、全体の却下率を低減します。
取得元
このデータは、多くの場合、専用の「却下理由」フィールド、またはステータスが「却下済み」に変更されたときにデータが入力されるメモフィールドに記録されます。
例
実装計画の詳細不足リスク評価不完全他のスケジュールされた変更との競合
|
|||
|
変更優先度
ChangePriority
|
変更リクエストの優先度レベル。その緊急性とビジネスへの影響を示します。 | ||
|
説明
変更優先度とは、変更の緊急性と影響を組み合わせて決定される分類です。これはチームが作業の優先順位をつけ、リソースを効果的に割り当てるのに役立ち、最も重要な変更が最初に対処されるようにします。 分析では、優先度を使用して、高優先度の変更が低優先度の変更よりも速く処理されるかどうかを確認できます。この期待からの逸脱は、優先順位付けまたは実行プロセスにおける非効率性またはボトルネックを示す可能性があります。
その重要性
プロセスが影響の大きい変更を正しく優先順位付けしているか、またそれらの変更が意図したとおりに真に迅速化されているかを分析するのに役立ちます。
取得元
通常、変更リクエストオブジェクト上の「優先度」という名前のフィールドです。手動で設定されるか、影響度および緊急度フィールドから導出される場合があります。
例
1 - Critical2 - High3 - Medium4 - Low
|
|||
|
変更提出者
ChangeSubmitter
|
変更リクエストを最初に作成または提出したユーザー。 | ||
|
説明
この属性は、変更リクエストを開始した人物を特定します。これは、プロセスの後半で実装の責任を負う変更オーナーとは異なる場合があります。 変更提出者を分析することで、リクエストの品質に関連するパターンを特定するのに役立ちます。例えば、特定の個人やチームが、却下や手戻りにつながる不完全なリクエストを頻繁に提出していることが明らかになる可能性があります。この洞察は、的を絞ったトレーニングを提供し、提出物の全体的な品質を向上させるために使用できます。
その重要性
変更リクエストの起源を追跡するのに役立ち、個人またはチームによる提出品質の分析や、トレーニング機会の特定を可能にします。
取得元
これは通常、変更リクエストオブジェクトの「作成者」または「要求者」フィールドです。
例
Susan MillerDavid ChenMaria Garcia
|
|||
|
実装サイクルタイム
ImplementationCycleTime
|
変更の実装が開始されてから完了するまでの計算された期間。 | ||
|
説明
このメトリックは、変更の実装フェーズにかかる時間を定量化します。「変更実装開始」アクティビティと「変更実装済み」アクティビティ間の期間として計算されます。 この属性は、「平均変更実装時間」KPIの計算に使用され、「変更実装フローと遅延」ダッシュボードをサポートします。計画の遅延と実行の遅延を区別するのに役立ち、チームが技術的な実装作業自体に改善努力を集中できるようにします。
その重要性
実際の実装フェーズのパフォーマンスを分離し、承認の遅延とは別に技術的またはリソースベースのボトルネックを特定するのに役立ちます。
取得元
プロセスマイニングツール内またはデータ変換時に、実装開始および終了イベントのタイムスタンプ間の時間差を見つけることで計算されます。
例
4時間15分1日2時間30分
|
|||
|
実際の完了日
ActualCompletionDate
|
変更が実際に実装され、完了が検証された際のタイムスタンプ。 | ||
|
説明
実際の完了日とは、変更リクエストの実装作業が終了した時点を示します。これは、パフォーマンスを測定するために計画された期限と比較される重要なマイルストーンです。 この属性は、目標完了日と併用され、変更が期日通りに完了したかどうかを判断します。「期日内変更完了率」などのKPIを計算し、実装フェーズにおける遅延の原因を分析するための基本的な入力となります。
その重要性
実際の完了時間を捕捉し、定時納品率を計算し、遅延の規模を分析するために必要です。
取得元
この日付は、変更リクエストステータスが「実装済み」または「完了」に移行したときに記録されることがよくあります。専用のフィールドであるか、そのステータス変更のタイムスタンプから推論される場合があります。
例
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
|
|||
|
影響を受けるサービス
ServiceAffected
|
変更によって影響を受ける主要なビジネスサービスまたは構成アイテム(CI)。 | ||
|
説明
この属性は、変更リクエストの対象となる主要なITサービス、アプリケーション、またはインフラストラクチャの一部を特定します。変更管理プロセスをより広範なITサービス管理の状況にリンクさせます。 影響を受けるサービス別に分析することは、「最も問題のある変更タイプ」KPIにとって極めて重要であり、どのサービスが最も頻繁に変更を受けているか、またどのサービスが高い却下率や遅延に関連しているかを特定するのに役立ちます。これにより、サービスオーナーが安定性を改善し、技術的負債を管理するための貴重な洞察が得られます。
その重要性
変更を特定のビジネスサービスにリンクさせることで、どのサービスが最も不安定であるか、または最も問題のある変更を生み出しているかを特定するための分析が可能になります。
取得元
これは通常、構成管理データベース(CMDB)からリンクされ、変更リクエストオブジェクトの「主要CI」または「サービス」フィールドに保存されます。
例
メールサービス (Exchange)ERPシステム (SAP)コアネットワークスイッチ (CISCO-4500X)
|
|||
|
承認サイクルタイム
ApprovalCycleTime
|
変更が承認のために提出されてから最終承認を受けるまでの計算された期間。 | ||
|
説明
このメトリックは、主要な承認マイルストーン間で経過した時間を測定します。「評価のために提出された変更」イベントと「CABによって承認された変更」イベントの間の時間差を特定することで、ケースレベルで計算されます。 この計算された期間は、「変更承認サイクルタイム」ダッシュボードおよび関連するKPIのコアメトリックです。その分布を分析することは、特定の承認者、チーム、または変更タイプに関連するかどうかに関わらず、承認フェーズにおけるボトルネックを特定するのに役立ちます。
その重要性
承認フェーズの効率を直接測定し、変更の実装承認における遅延を特定・排除するのに役立ちます。
取得元
データ後処理中、または特定の承認関連アクティビティのタイムスタンプ間の期間を測定することで、プロセスマイニングツール内で計算されます。
例
2日4時間18時間30分5 days
|
|||
|
期日内完了
IsOnTimeCompletion
|
変更が目標日までに完了した場合にtrueとなる計算フラグです。 | ||
|
説明
これは、「実際の完了日」と「目標完了日」を比較して導出されるブール属性です。各変更リクエストの期日内パフォーマンスを明確な二値指標で提供することで、分析を簡素化します。 このフラグは「期日内変更完了率」KPIの計算の基礎となります。ダッシュボードのフィルターとして使用することで、遅延した変更を簡単に分離して分析し、遅延の一般的な根本原因を特定するのに役立ちます。
その重要性
期日達成の明確な成功または失敗の結果を提供することで、パフォーマンス分析を簡素化し、期日内完了KPIに直接貢献します。
取得元
この属性はソースシステムにはありません。「実際の完了日」が「目標完了日」以下であるかを比較することで、データ変換中に計算されます。
例
truefalse
|
|||
変更管理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
CABによる変更承認済み
|
変更諮問委員会(CAB)または指定された権限者が変更の進行を承認する重要な節目です。これは、変更リクエストのステータスが「承認済み」に更新されたときに推測されます。 | ||
|
その重要性
このアクティビティは、承認サイクルタイムを測定するための終点です。プロセスを解放し、計画と実装を開始可能にするため、変更承認サイクルタイムKPIにとって極めて重要です。
取得元
変更リクエストオブジェクトの監査履歴から、「ステータス」フィールドが「承認済み」に変わった際のタイムスタンプを具体的に捕捉して推論されます。
取得
「承認済み」へのステータス変更から推論されます。
イベントタイプ
inferred
|
|||
|
変更クローズ済み
|
このアクティビティは、変更管理プロセスの最終的で成功した終点です。変更リクエストのステータスが「クローズ済み」に設定され、すべての作業が完了したことを示すときに捕捉されます。 | ||
|
その重要性
主要な成功終点として、このアクティビティは、正常に完了した変更のエンドツーエンドのサイクルタイムを計算するために不可欠です。これにより、すべてのプロセスステップが終了したことが確認されます。
取得元
これは、変更リクエストオブジェクトの監査履歴において、「クローズ済み」への最終ステータス変更のタイムスタンプから推論されます。
取得
「クローズ済み」への最終ステータス変更から推論されます。
イベントタイプ
inferred
|
|||
|
変更スケジュール済み
|
このアクティビティは、変更の実装日時が正式に確認され、記録される時点を示します。ステータスが「スケジュール済み」に更新されたときに捕捉されます。 | ||
|
その重要性
これは主要なコミットメントマイルストーンです。承認されたコンセプトから計画されたアクションへと変更を移行させ、実装の前提条件となります。
取得元
変更リクエストオブジェクトの履歴から、「ステータス」フィールドが「スケジュール済み」に更新された際のタイムスタンプを捕捉して推論されます。
取得
「スケジュール済み」へのステータス変更から推論されます。
イベントタイプ
inferred
|
|||
|
変更リクエスト作成済み
|
このアクティビティは、システム内での新しい変更リクエストの開始を示します。通常、変更リクエストビジネスオブジェクトに新しいレコードが作成されたときに捕捉され、プロセス全体の出発点を確立します。 | ||
|
その重要性
これはプロセスの主要な開始イベントです。このアクティビティから他のアクティビティまでの時間を分析することで、総ライフサイクル期間が明らかになり、フロントエンドの遅延を特定するのに役立ちます。
取得元
このイベントは、変更リクエストレコードの作成タイムスタンプから捕捉されます。Ivanti Cherwellでは、通常、変更リクエストビジネスオブジェクトの「CreatedDateTime」フィールドに保存されます。
取得
レコード作成のタイムスタンプから直接取得されます。
イベントタイプ
explicit
|
|||
|
変更実装済み
|
このマイルストーンは、変更のための技術作業が完了したことを示します。変更リクエストのステータスが「実装済み」または検証保留中の類似の状態に更新されたときに捕捉されます。 | ||
|
その重要性
これは重要な成功マイルストーンであり、期日内変更完了率および平均変更実装時間KPIの主要な入力です。実行フェーズの終了を示します。
取得元
変更リクエストオブジェクトの監査ログから、「実装済み」または「検証保留中」へのステータス変更のタイムスタンプを使用して推論されます。
取得
「実装済み」へのステータス変更から推論されます。
イベントタイプ
inferred
|
|||
|
導入後レビュー実施済み
|
このアクティビティは、完了した変更の成功を評価し、教訓を収集するための正式なレビューが実施されたことを示します。多くの場合、「導入後レビュー」へのステータス変更によって推論されます。 | ||
|
その重要性
これを追跡することで、変更に関するフィードバックループが閉じられることを保証します。これは継続的な改善に不可欠であり、導入後レビュー率KPIを直接サポートします。
取得元
変更リクエストオブジェクトの監査履歴から、「ステータス」が「導入後レビュー」のような状態に移行した際のタイムスタンプを捕捉して推論されます。
取得
「導入後レビュー」へのステータス変更から推論されます。
イベントタイプ
inferred
|
|||
|
影響とリスクを評価済み
|
このアクティビティは、変更リクエストのリスクと影響分析の完了を示します。通常、変更リクエストのステータスが「承認待ち」のような承認準備完了を示す状態に移行したときに推論されます。 | ||
|
その重要性
このアクティビティを追跡することで、評価フェーズの期間を測定し、リスク分析が承認前に一貫して実施されることを確実にし、リスク評価遵守率KPIをサポートします。
取得元
変更リクエストオブジェクトの履歴から推論されます。これは、「ステータス」フィールドが「評価中」から「CAB承認待ち」のようなステータスに更新されたタイムスタンプで捕捉されます。
取得
「CAB承認待ち」へのステータス変更から推論されます。
イベントタイプ
inferred
|
|||
|
変更キャンセル済み
|
承認済みまたは進行中の変更リクエストが完了前に撤回される最終状態を表します。このイベントは、ステータスが「キャンセル済み」に更新されたときに捕捉されます。 | ||
|
その重要性
これは代替のプロセス終点です。変更がキャンセルされる理由とタイミングを分析することで、計画、リソース割り当て、またはビジネス優先順位の変更に関する問題が明らかになる可能性があります。
取得元
監査履歴から、変更リクエストオブジェクトの「ステータス」フィールドが「キャンセル済み」に更新された際のタイムスタンプを捕捉して推論されます。
取得
「キャンセル済み」へのステータス変更から推論されます。
イベントタイプ
inferred
|
|||
|
変更却下済み
|
このアクティビティは、承認フェーズ中に変更リクエストを却下するという最終決定を表します。変更リクエストのステータスが「却下済み」に設定されたときに捕捉されます。 | ||
|
その重要性
これは致命的な失敗の終点です。却下された変更とその理由を分析することは、初期リクエストの品質向上に役立ち、「変更リクエスト却下率」KPIをサポートします。
取得元
監査履歴で変更リクエストオブジェクトの「ステータス」フィールドが「却下済み」に更新された際のタイムスタンプから推論されます。
取得
「却下済み」へのステータス変更から推論されます。
イベントタイプ
inferred
|
|||
|
変更実装開始
|
変更の技術的な実行の開始を表します。これは通常、変更リクエストのステータスが「進行中」または「実装中」に移行したときに推論されます。 | ||
|
その重要性
このアクティビティは、実装期間の開始を示します。これと「変更実装済み」の間の時間は、実際の実現期間であり、全体のサイクルタイムの主要な構成要素です。
取得元
変更リクエストオブジェクトの監査履歴から推論されます。「ステータス」フィールドが「進行中」または「実装中」のような値に更新された際のタイムスタンプです。
取得
「進行中」へのステータス変更から推論されます。
イベントタイプ
inferred
|
|||
|
変更承認待ち
|
このアクティビティは、変更リクエストが正式にCAB(変更諮問委員会)または他の承認機関からの決定を待っている期間を表します。「承認保留中」や「CAB待ち」のようなステータスから推論されます。 | ||
|
その重要性
これは重要な待機時間アクティビティです。その期間を分析することは、承認ワークフローにおけるボトルネックを特定するのに役立ちます。これは変更管理における遅延の一般的な原因です。
取得元
取得
「承認待ち」ステータスへの移行によって特定されます。
イベントタイプ
inferred
|
|||
|
変更検証実行済み
|
変更が成功し、悪影響を及ぼさなかったことを確認するためのテストおよび検証フェーズを表します。これは「検証」または「テスト中」へのステータス変更から推論されます。 | ||
|
その重要性
このアクティビティの頻度と期間を分析することで、品質保証ステップがスキップされないことを確実にします。これは、変更に起因するインシデントを防止するための重要なステップです。
取得元
取得
「検証」へのステータス変更から推論されます。
イベントタイプ
inferred
|
|||
|
変更評価のために提出済み
|
新規作成された変更リクエストの初期評価のための正式な提出を表します。これは一般的に、変更リクエストのステータスが「新規」または「ドラフト」の状態から「評価中」のようなステータスに移行したときに推論されます。 | ||
|
その重要性
このアクティビティは、初期データ入力後の正式な変更プロセスの開始を示します。作成と提出の間の時間は、ユーザーのトレーニングニーズやプロセス上の摩擦を示唆する可能性があります。
取得元
変更リクエストオブジェクトの監査ログまたは履歴から、「ステータス」フィールドが「評価中」または「提出済み」のような値に変わった際のタイムスタンプを特定して推論されます。
取得
「新規」から「評価中」へのステータス変更から推論されます。
イベントタイプ
inferred
|
|||
|
実装計画策定済み
|
タスク、リソース、およびバックアウト計画の定義を含む、変更の詳細な計画の完了を示します。これは、変更が「承認済み」から「スケジュール済み」に移行する際に推論されることがよくあります。 | ||
|
その重要性
このアクティビティの期間は、変更計画フェーズの効率性を示します。ここでの遅延は、承認が与えられた後でも、変更全体のタイムラインに影響を与える可能性があります。
取得元
これは、「承認済み」から「スケジュール済み」へのステータス変更のタイムスタンプから推論できます。または、特定の計画フィールドの入力に関連付けることも可能です。
取得
「承認済み」から「スケジュール済み」へのステータス変更から推論されます。
イベントタイプ
inferred
|
|||