変更管理データテンプレート
変更管理データテンプレート
- 詳細な分析に必要な推奨属性
- プロセス内で追跡すべき主要なアクティビティとマイルストーン
- 対象となるソースシステムからデータを抽出する具体的な手順
変更管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
変更管理プロセス内で実行された特定のイベントまたはタスクの名称です。 | ||
|
説明
変更リクエストのライフサイクルにおける1つのステップまたはステータス変更を表す属性です。例として、「Change Request Submitted」や「Change Request Approved」などがあります。これらのアクティビティがプロセスマップを構成します。 アクティビティの順序と所要時間を分析すると、プロセスフローの把握、標準手順からの逸脱の発見、ボトルネックの特定が可能になります。アクティビティ名は通常、システムの監査ログに記録されたステータス遷移から生成されます。
重要な理由
プロセスの各ステップを定義し、プロセスフローの可視化と分析を可能にします。これはプロセスマイニングの中核です。
入手先
「CHG:ChangeRequest_AuditLog」フォームのステータス遷移、または「CHG:Infrastructure Change」フォームの「Status」フィールドの変更追跡から生成されます。
例
変更要求を提出リスク評価を実施変更要求を承認変更の実施完了
|
|||
|
変更リクエストID
ChangeRequestID
|
変更リクエストを識別する、システムが生成した一意の識別子です。ケースの主識別子として使用されます。 | ||
|
説明
変更リクエストIDは、ライフサイクル全体を通じて各変更施策を識別する一意のキーです。関連するすべてのアクティビティ、承認、タスクをまとめ、プロセスマイニングにおける1つのケースの基盤になります。 このIDでプロセスを分析すると、初回のリクエストから最終クローズまで、変更がどのように管理されたかをエンドツーエンドで確認できます。サイクルタイムの追跡、ボトルネックの特定、変更ごとのプロセスのばらつきの把握に欠かせません。
重要な理由
関連するすべてのイベントを1つのプロセスインスタンスに結び付ける基本的な属性です。変更管理プロセスをエンドツーエンドで分析できるようにします。
入手先
「CHG:Infrastructure Change」フォームの「Infrastructure Change ID」フィールド(フィールドID:1000000182)にあります。
例
CRQ0000001234567CRQ0000001234568CRQ0000001234569
|
|||
|
開始時刻
EventStartTime
|
特定のアクティビティまたはイベントが開始した時刻を示すタイムスタンプです。 | ||
|
説明
アクティビティが発生した正確な日時を記録する属性です。たとえば、変更が申請、承認、クローズされた時刻を記録します。 このタイムスタンプは、プロセスの時系列分析に欠かせません。アクティビティ間のサイクルタイムの計算、待ち時間の測定、時間経過に伴うパフォーマンス傾向の把握、イベント順序の特定に使用されます。正確なタイムスタンプは、時間に基づくプロセス分析の基盤です。
重要な理由
期間の計算、パフォーマンス分析、プロセス内のイベント順序の把握に必要な時間情報を提供します。
入手先
「CHG:ChangeRequest_AuditLog」フォームの「Audit Date」フィールド、または特定のステータス変更に関連付けられた「Last Modified Date」から取得されます。
例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
|
|||
|
ソースシステム
SourceSystem
|
データを抽出したシステムの名称です。 | ||
|
説明
プロセスデータの取得元を識別する属性です。この場合は「BMC Helix ITSM」です。複数のシステムのデータを組み合わせて分析する環境では、データガバナンスと追跡可能性の確保に役立ちます。 たとえば、後から変更データを財務システムやプロジェクト管理システムのデータと統合する場合、このフィールドによってデータソースを明確に区別できます。
重要な理由
データの取得元に関する重要な情報を提供し、複数システムを対象とする分析でも、追跡可能性とデータの適切な解釈を確保します。
入手先
通常は、データの抽出、変換、ロード(ETL)処理の際に、データセットの取得元を示す固定値として追加されます。
例
BMC Helix ITSMHelix ITSM ProdBMC Remedy AR System
|
|||
|
最終データ更新日時
LastDataUpdate
|
このレコードのデータがソースシステムから最後に更新された時刻を示すタイムスタンプです。 | ||
|
説明
BMC Helix ITSMからデータが最後に抽出された日時を示す属性です。イベント自体の発生時刻ではなく、データを取得した時刻を示します。分析対象データの鮮度を把握し、データ更新サイクルを管理するうえで重要です。 ダッシュボードやレポートでは、分析がどの時点の情報に基づくものかを確認できます。進行中のプロセスを監視する場合に特に役立ちます。
重要な理由
データの新しさを示します。分析やダッシュボードにプロセスの最新状態を反映するうえで重要です。
入手先
通常は、データ抽出時にETLツールまたはデータパイプラインが生成し、値を設定するメタデータフィールドです。
例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
|
|||
|
ステータス
Status
|
ライフサイクル上の変更リクエストの現在の状態または段階です。 | ||
|
説明
「Status」フィールドは、ある時点における変更リクエストの正確な段階を示します。たとえば、「Draft」、「Request For Authorization」、「Completed」などです。アクティビティはこれらのステータス間の遷移から生成されますが、ステータス自体も現在の作業量を分析するために役立ちます。 この属性は、「Change Throughput & Current Status」ダッシュボードに欠かせません。パイプラインの各段階にある変更件数を一覧で確認できます。管理者は、進行中の作業とリソース配分を把握できます。
重要な理由
変更パイプラインをリアルタイムで把握でき、進行中の作業とすべての変更リクエストの現在の状態を分析できます。
入手先
「CHG:Infrastructure Change」フォームの「Status」フィールドにあります。
例
下書き承認依頼スケジュール済み実装中完了
|
|||
|
リスクレベル
RiskLevel
|
変更の実施に伴う潜在的なリスクを評価したものです。 | ||
|
説明
変更を実施した場合に、悪影響が生じる可能性を定性的または定量的に評価したものです。承認プロセスへの重要な入力情報であり、リスクの高い変更ほど厳密な審査を受けます。 この属性は、「Change Risk Profile Analysis」ダッシュボードの中心となります。変更ポートフォリオ全体のリスクエクスポージャーを把握できます。また、初期のリスク評価が不十分で後から再評価が必要になる、手戻りループの特定にも使用されます。
重要な理由
プロセスのコンプライアンスと効率を分析する重要な切り口です。リスクの高い変更が適切な審査を受けているかを確認できます。
入手先
「CHG:Infrastructure Change」フォームの「Risk Level」フィールドにあります。
例
1 - 重大2 - 高3 - 中4 - 低5 - 計画中
|
|||
|
優先度
Priority
|
変更リクエストに割り当てられた優先度で、ビジネス上の重要度を示します。 | ||
|
説明
通常、優先度は影響度と緊急度を組み合わせて決定され、変更リクエストの処理順序と速度を左右します。優先度の高い変更は、より迅速な処理が必要で、厳しいサービスレベル合意(SLA)が適用される場合があります。 この属性は、「Change SLA Performance」ダッシュボードで、優先度別のパフォーマンスを分類・分析するために使用されます。「優先度の高い変更でSLAを達成できているか」といった問いへの回答や、リソース配分の判断に役立ちます。
重要な理由
ビジネス上の重要度別にパフォーマンスを分析できます。重要度の高い変更を効率よく処理し、目標を達成できているかを確認できます。
入手先
「CHG:Infrastructure Change」フォームの「Priority」フィールドにあります。
例
重大高中低
|
|||
|
変更タイプ
ChangeType
|
Standard、Normal、Emergencyなど、変更の分類です。 | ||
|
説明
変更の性質と従うべきプロセスに基づいて、変更リクエストを分類する属性です。一般的なタイプには、事前承認済みで低リスクのStandard、完全な評価と承認が必要なNormal、緊急の問題に対応するため迅速な処理が必要なEmergencyがあります。 変更タイプ別に分析すると、プロセスのばらつきを把握できます。たとえば、「Emergency Change Volume & Impact」ダッシュボードでは、このフィールドを使って緊急変更の件数とサービス安定性への影響を追跡します。また、変更タイプごとに定められた経路に沿って処理されているかを評価できます。
重要な理由
プロセスを分けて異なる変更ワークフローを分析・比較できます。コンプライアンスとパフォーマンスを分析するうえで重要です。
入手先
「CHG:Infrastructure Change」フォームの「Change Type」フィールドにあります。
例
標準通常緊急影響なし
|
|||
|
実施チーム
ImplementationTeam
|
変更の実施を担当するチームです。 | ||
|
説明
変更リクエストに必要な作業を実行する技術チームまたは運用チームを識別する属性です。変更ライフサイクルの実施段階では、「Assigned Group」に該当することが多い項目です。 この情報は、「Resource Bottlenecks in Change Process」ダッシュボードに欠かせません。実施チーム別にアクティビティの所要時間と件数を分析することで、負荷の偏り、スキル不足、変更の展開を遅らせるその他のリソース上の制約を特定できます。
重要な理由
担当チーム別にパフォーマンスを分析し、実施段階のリソースに関するボトルネックを特定できます。
入手先
「CHG:Infrastructure Change」フォームの「ASGRP」(Assigned Group)フィールドにあります。
例
サーバー運用データベース管理者SAP Basisチームクラウドインフラストラクチャ
|
|||
|
承認者グループ
ApproverGroup
|
特定の段階で変更リクエストを承認する責任を持つチームまたはグループです。 | ||
|
説明
変更のレビューと承認を担当するグループを識別する属性です。変更には複数の承認段階があるため、ライフサイクルの段階ごとに異なるグループを示す場合があります。たとえば、技術承認チームやビジネス承認委員会などです。 「Change Approval Bottlenecks」ダッシュボードでは、承認を担当するグループ別に承認時間を分類できるため、重要な属性となります。負荷が高い、または効率が低く、プロセスの遅延を引き起こしているチームを特定できます。
重要な理由
担当チーム別に承認期間を分析し、承認プロセスのボトルネックを特定できます。
入手先
承認を管理し、変更リクエストに関連付けられた「AP:Signature」フォームから取得されます。承認者のグループはこのレコードに含まれます。
例
変更諮問委員会ITセキュリティネットワークエンジニアリングアプリケーション開発
|
|||
|
SLA状態
SLAState
|
SLA目標に対する変更リクエストの計算済みステータスです。 | ||
|
説明
完了した変更リクエストがSLAを達成したか、違反するリスクがあるか、または違反したかを示す属性です。「SLATargetDate」と実際の完了タイムスタンプを比較して算出されます。 「Change SLA Performance」ダッシュボードの主要指標です。サービスレベルの約束に対するパフォーマンスを明確かつ簡潔に測定し、優先度、変更タイプ、チーム別にデータを分類して、SLA遵守状況が悪い領域を特定できます。
重要な理由
約束したサービスレベルに対するパフォーマンスを直接測定できるため、プロセス効率とサービス品質を示す重要な指標になります。
入手先
計算によって求められる属性です。データ変換時に、最終アクティビティのタイムスタンプと「SLATargetDate」を比較して算出されます。
例
期限内リスクあり期限違反
|
|||
|
SLA目標日時
SLATargetDate
|
変更リクエストを完了すべき目標日時です。 | ||
|
説明
サービスレベル合意(SLA)目標日時は、変更リクエストを完了する期限です。優先度と変更タイプに基づいて決まり、実際の完了時刻を評価する基準になります。 この属性は、「Change SLA Performance」ダッシュボードの基盤です。実際のクローズ時刻と目標日時を比較することで、変更がSLAを達成したかを判定できます。SLAパフォーマンスを分析すると、プロセス全体の効率とサービスレベルの約束に対する遵守状況を評価できます。
重要な理由
パフォーマンスを測定する基準となり、SLA遵守率の計算や、遅延リスクのある変更の特定に役立ちます。
入手先
通常は、関連するSLA管理フォームに保存され、変更リクエストに関連付けられます。変更フォーム自体に表示される場合もあります。
例
2023-11-10T17:00:00Z2023-11-15T09:00:00Z2023-12-01T17:00:00Z
|
|||
|
クローズコード
CloseCode
|
変更をクローズした際の最終結果を示すコードです。 | ||
|
説明
クローズコードは、変更リクエストをクローズした理由を標準化して示します。「Successful」、「Successful with Issues」、「Backed Out」、「Cancelled」などがあります。最終ステータスだけの場合よりも、変更結果を詳細に把握できます。 クローズコードを分析すると、実施した変更の品質と成功率を評価できます。たとえば、「Backed Out」が多い場合、計画やテストに問題がある可能性を示すため、プロセス改善の指標になります。
重要な理由
各変更の結果を明確かつ構造化して記録し、成功率や失敗・キャンセルの理由を分析できます。
入手先
「CHG:Infrastructure Change」フォームの「Status Reason」または同様のクローズコードフィールドにあります。通常、最終段階で有効になります。
例
成功問題ありで成功切り戻し済みキャンセル済み
|
|||
|
変更申請者
ChangeSubmitter
|
変更リクエストを作成して申請した担当者です。 | ||
|
説明
変更リクエストを開始した担当者を識別する属性です。通常は、システム上の「Submitter」または「Reported By」ユーザーとして記録されます。 主要な分析軸ではない場合もありますが、変更リクエストの発生源を把握するために役立ちます。たとえば、特定の部門や職務からの変更が多いかを分析することで、ビジネスニーズや計画プロセスに関する情報を得られます。
重要な理由
変更リクエストの起点となった担当者を特定し、プロセス内の需要パターンやユーザー行動を分析できます。
入手先
「CHG:Infrastructure Change」フォームの「Submitter」フィールドにあります。
例
Allen AllbrookMary MannBob Baxter
|
|||
|
影響を受けるサービス
AffectedService
|
変更によって影響を受けるビジネスサービスまたは技術サービスです。 | ||
|
説明
変更リクエストを、構成管理データベース(CMDB)で定義された特定のサービスに関連付ける属性です。ユーザー向けの「Email Services」などのビジネスサービスや、「Authentication Service」などのバックエンド技術サービスが該当します。 「Emergency Change Volume & Impact」ダッシュボードで、変更と影響を受けるサービスを関連付けるために使用されます。各サービスの安定性を把握し、緊急対応が頻繁に必要なサービスを特定できます。
重要な理由
ビジネス上の重要な背景情報を提供し、技術的な変更をビジネスサービスへの影響に結び付けて、サービス中心のプロセス分析を可能にします。
入手先
「CHG:Infrastructure Change」フォームの「ServiceCI」フィールド、または関連する構成アイテム(CI)の関係から取得されます。
例
社内メールSAP ERP顧客関係管理オンラインバンキングポータル
|
|||
|
影響度
Impact
|
変更がビジネスサービスとITインフラに及ぼす影響を評価したものです。 | ||
|
説明
影響度は、変更が業務、サービス、ユーザーに及ぼす可能性のある影響を示します。緊急度とともに、変更リクエストの優先度を決める重要な要素です。 分析では、「Change Risk Profile Analysis」ダッシュボードで、変更ポートフォリオがもたらす潜在的なビジネス上の影響を把握するために使用されます。影響度の高い変更の分布を理解することで、リスク管理戦略とリソース計画に役立つ情報を得られます。
重要な理由
変更がビジネスにもたらす潜在的な影響を定量化し、サービスへの影響の大きさに基づくリスク分析と優先順位付けを可能にします。
入手先
「CHG:Infrastructure Change」フォームの「Impact」フィールドにあります。
例
1-広範囲/全体2-大規模/重大3-中程度/限定的4-軽微/局所的
|
|||
|
手戻りかどうか
IsRework
|
アクティビティが手戻りループ、またはプロセス上の後戻りに該当するかを示すフラグです。 | ||
|
説明
変更リクエストがライフサイクル上の前の段階に戻った場合にtrueになるブール型属性です。たとえば、「Scheduled」から「Risk Assessment」に戻るケースが該当します。このような後戻りは手戻りを示し、非効率の原因になることがあります。 このフラグは、「Change Rework Rate」KPIの計算と、「Change Rework & Assessment Efficiency」ダッシュボードに使用されます。手戻りの頻度と発生しやすいプロセスステップを定量化し、初期計画や評価の改善箇所を特定できます。
重要な理由
手戻りループに含まれるアクティビティを示すことで、プロセスの非効率を直接特定し、対象を絞った改善を進められます。
入手先
計算によって求められる属性です。ケース内のアクティビティの順序を分析し、プロセスフロー上の後戻りを検出するロジックをデータ変換時に適用します。
例
truefalse
|
|||
|
終了時刻
EventEndTime
|
特定のアクティビティまたはイベントが終了した時刻を示すタイムスタンプです。 | ||
|
説明
アクティビティの完了時刻を示します。プロセスマイニングでは、ケース内の次のアクティビティの開始時刻として計算されることが多く、直前のステップの所要時間を明確にできます。ケースの最後のアクティビティでは、開始時刻と同じ時刻、または特定のクローズ時刻が設定される場合があります。 この属性は、各アクティビティの「ProcessingTime」を計算するために必要です。「ProcessingTime」はパフォーマンス分析とボトルネック特定の基本指標であり、各ステップにかかった時間を詳細に分析できます。
重要な理由
アクティビティの所要時間を正確に計算できるため、ボトルネックの特定とプロセスパフォーマンスの測定に役立ちます。
入手先
計算によって求められる属性です。通常はデータ変換時に、対象ケースのシーケンス内にある次のイベントの開始時刻から算出されます。
例
2023-10-26T14:35:10Z2023-10-27T09:00:00Z2023-10-27T11:20:00Z
|
|||
|
緊急変更かどうか
IsEmergencyChange
|
変更タイプが「Emergency」の場合にtrueになるブール型フラグです。 | ||
|
説明
緊急変更を明確な二値で示し、分析を簡単にする派生フラグです。「ChangeType」属性の値に基づいて設定されます。 主に、「Emergency Change Volume & Impact」ダッシュボードと「Emergency Change Percentage」KPIで使用されます。緊急変更に関するデータを簡単にフィルタリング・集計できるため、分析ツールで複雑な条件を設定せずに、発生頻度や時間経過に伴う傾向を追跡できます。
重要な理由
緊急変更の分析を簡単にし、この重要な変更タイプに関するフィルタリング、ダッシュボード表示、KPI計算を行いやすくします。
入手先
データ変換時に作成される派生属性です。ロジックは、IF「ChangeType」=「Emergency」THEN true ELSE falseです。
例
truefalse
|
|||
|
緊急度
Urgency
|
変更の実施にどれだけ時間的な緊急性があるかを示します。 | ||
|
説明
変更をどれだけ早く実施する必要があるかを示します。影響度とともに、変更リクエスト全体の優先度を算出するために使用されます。 「Change Risk Profile Analysis」ダッシュボードの重要な属性であり、変更管理プロセスにかかる時間的なプレッシャーを把握できます。緊急度の傾向を分析すると、期限の厳しいリクエストが多くなる根本的な問題を特定できます。
重要な理由
変更に時間的な制約があることを示し、異なる緊急度のリクエストをプロセスが適切に処理できているかを分析できます。
入手先
「CHG:Infrastructure Change」フォームの「Urgency」フィールドにあります。
例
1-重大2-高3-中4-低
|
|||
|
関連インシデントID
RelatedIncidentID
|
この変更によって発生したインシデントの識別子です。 | ||
|
説明
変更リクエストを、その後に発生した関連インシデントに結び付ける属性です。変更がサービスの安定性に及ぼした影響を把握するうえで欠かせません。 「Change-Induced Incident Rate」KPIの計算に必要な主要属性です。この関連付けを追跡することで、変更プロセスの品質を測定し、実施後の問題発生率が高い変更タイプ、チーム、サービスを特定できます。
重要な理由
変更による悪影響を直接測定し、変更品質とリスク管理の有効性を評価する重要なKPIになります。
入手先
通常はIncidentフォーム(「HPD:Help Desk」)で設定されます。インシデントの原因として、変更リクエストに関連付けることができます。
例
INC000000987654INC000000987655INC000000987656
|
|||
変更管理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
テスト実施完了
|
変更実施後のテストまたは検証が完了したことを示します。通常は、変更リクエストに関連付けられた専用のテストタスクが完了した時点で記録されます。 | ||
|
重要な理由
このアクティビティを追跡することは、平均テストサイクルタイムの測定と品質確保に欠かせません。最終検証の前に、検証プロセスのボトルネックを特定できます。
入手先
親変更リクエストに関連付けられたCHG:Taskフォームで、テストタスクレコードが完了したことから推定されます。
取得
CHG:Taskの関連する「Testing」または「Validation」タスクが「Closed」または「Completed」とマークされた時刻を特定します。
イベントタイプ
inferred
|
|||
|
リスク評価を実施
|
提案された変更のリスク評価が完了したことを示します。通常は、変更要求のステータスが更新された時点、または特定のリスク評価タスクが終了した時点で取得します。 | ||
|
重要な理由
このアクティビティを追跡することは、変更管理ポリシーへのコンプライアンスを確保するうえで重要です。評価段階の遅延を特定し、プロセスがこのステップに戻った場合は、変更手戻り率を分析できます。
入手先
CHG:Changeフォームのステータス変更(例:「Request For Change」への移行)またはCHG:Taskフォームに関連するタスクの完了から推定します。
取得
CHG:Taskに関連付けられた「Risk Assessment」タスクが「Closed」または「Completed」になった時点のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
変更のクローズ完了
|
システム上で変更リクエストを正式にクローズする最終アクティビティです。変更リクエストのステータスが「Closed」に設定された時点で、このイベントが記録されます。 | ||
|
重要な理由
変更ライフサイクルが正常に終了したことを示します。エンドツーエンドのプロセス期間と全体の処理量を測定するうえで欠かせません。
入手先
CHG:Changeフォームのステータス変更履歴で、ステータスが「Closed」に変更されたことから推定されます。
取得
CHG:Changeの「Status」フィールドが「Closed」に更新された時刻を特定します。
イベントタイプ
inferred
|
|||
|
変更のスケジュール設定完了
|
承認済みの変更を実施する正式なスケジュールが設定された時点を示すアクティビティです。システム上のステータスが「Scheduled」に変更された時点で、このイベントが記録されます。 | ||
|
重要な理由
実施の準備が整ったことを示す重要なマイルストーンです。変更実施サイクルタイムと平均実施待ち時間のKPIを測定する起点になります。
入手先
CHG:Changeフォームのステータス変更履歴で、ステータスが「Scheduled」に変更されたことから推定されます。
取得
CHG:Changeの「Status」フィールドが「Scheduled」に更新された時刻を特定します。
イベントタイプ
inferred
|
|||
|
変更の実施完了
|
変更の実施作業が正常に完了したことを示すアクティビティです。通常は、成功を示す理由とともにステータスが「Completed」に更新された時点で記録されます。 | ||
|
重要な理由
展開フェーズの終了を示す主要なマイルストーンです。変更実施サイクルタイムの計算や、変更に起因するインシデントの分析に欠かせません。
入手先
CHG:Changeフォームで「Status」が「Completed」に設定され、「Status Reason」が「Successful」になったことから推定されます。
取得
CHG:Changeの「Status」フィールドが「Completed」に更新された時刻を特定します。
イベントタイプ
inferred
|
|||
|
変更要求を作成
|
このアクティビティは、システム内で変更要求レコードを最初に作成したことを示します。CHG:Changeフォームの変更要求レコードの作成タイムスタンプからイベントを取得します。 | ||
|
重要な理由
すべての変更要求の開始点であり、ライフサイクル全体の期間を測定し、受け付けた変更の件数を分析するために欠かせません。
入手先
このイベントは、CHG:Changeフォームの監査ログ(例:HPD:Help Desk Audit Log)にある「Submit Date」またはレコード作成タイムスタンプから取得します。
取得
CHG:Changeフォームのレコード作成タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
変更要求を承認
|
変更要求を進める正式な承認を受けた重要な節目です。通常、最終承認後にステータスが「Scheduled」または「Planning In Progress」に変更されたことからイベントを推定します。 | ||
|
重要な理由
承認段階の終了を示し、承認のボトルネックと変更承認時間の平均KPIを測定するうえで重要です。プロセスにおける重要な意思決定ポイントでもあります。
入手先
CHG:Changeフォームのステータス変更履歴から推定します。具体的には、「Request For Authorization」などの承認ステータスから移行した時点を確認します。
取得
CHG:Changeの「Status」フィールドが最終承認段階を通過し、たとえば「Scheduled」に移行した時点のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
変更のキャンセル
|
実施または完了前に変更リクエストがキャンセルされたことを示します。変更リクエストのステータスが「Cancelled」に更新された時点で記録されます。 | ||
|
重要な理由
キャンセルを追跡することで、変更が取り下げられた理由を把握できます。初期計画の不備、優先順位の変更、リソース不足などの問題を明らかにできます。
入手先
CHG:Changeフォームのステータス変更履歴で、ステータスが「Cancelled」に変更されたことから推定されます。
取得
CHG:Changeの「Status」フィールドが「Cancelled」に更新された時刻を特定します。
イベントタイプ
inferred
|
|||
|
変更の検証完了
|
実施とテストの後、関係者によって変更が正常に完了したことを正式に検証したことを示します。通常は、最終クローズ前のステータス変更として記録されます。 | ||
|
重要な理由
検証は、変更をクローズする前の最終的な品質ゲートです。変更が目的を満たし、意図しない悪影響を引き起こしていないことを確認します。
入手先
CHG:Changeフォームで、「Completed」から「Verification」または「Closed」などのステータスに変更されたことから推定されます。
取得
実施作業後、CHG:Changeの「Status」フィールドが「Closed」に変更された時刻を特定します。
イベントタイプ
inferred
|
|||
|
変更要求を却下
|
承認者が変更要求を正式に否認したことを示します。「Rejected」へのステータス変更で取得し、終端状態を表します。 | ||
|
重要な理由
却下を追跡することで、情報不足や高いリスクなど、否認の理由を特定できます。この分析により、今後の変更提出の品質を高められます。
入手先
CHG:Changeフォームのステータス変更履歴から推定します。具体的には、「Rejected」への移行を確認します。
取得
CHG:Changeの「Status」フィールドが「Rejected」に更新された時点のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
変更要求を提出
|
変更要求をレビューと承認のために正式に提出したことを示します。通常は、変更要求のステータスが「Draft」から「Request For Authorization」に移行した時点から推定します。 | ||
|
重要な理由
このアクティビティによって承認プロセスが開始されます。初回レビューを待つ時間を測定し、変更承認時間KPIを分析するために、追跡が欠かせません。
入手先
CHG:Changeフォームの変更要求のステータス変更履歴から推定します。具体的には、「Request For Authorization」への移行を確認します。
取得
CHG:Changeの「Status」フィールドが「Draft」から「Request For Authorization」に変わった時点のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
実施後レビュー
|
変更の実施後に正式なレビューが完了したことを示します。通常は、実施後レビュー(PIR)タスクが完了した時点で記録されます。 | ||
|
重要な理由
組織としての学習とプロセス改善に欠かせないアクティビティです。実施後レビュー率のKPIを測定することで、変更から得た教訓を確実に反映できます。
入手先
親変更リクエストに関連付けられたCHG:Taskフォームで、「Post-Implementation Review」タスクが完了したことから推定されます。
取得
CHG:Taskの関連する「PIR」タスクが「Closed」または「Completed」とマークされた時刻を特定します。
イベントタイプ
inferred
|
|||
|
実装計画を策定
|
変更を実装するための詳細な計画が作成され、文書化されたことを示します。通常は、変更に関連付けられた計画タスクが完了した時点で取得します。 | ||
|
重要な理由
このアクティビティの完了は、スケジュール設定と実装の前提条件です。所要時間を分析することで、変更を実行する前の計画段階における遅延を特定できます。
入手先
親変更リクエストに関連付けられたCHG:Taskフォームで、特定の計画タスクレコードが完了したことから推定されます。
取得
CHG:Taskの関連する「Implementation Planning」タスクが「Closed」または「Completed」とマークされた時刻を特定します。
イベントタイプ
inferred
|
|||
|
影響分析を実施
|
変更によって生じる可能性のある影響を判断するための影響分析が完了したことを示します。通常は、ステータスの更新または関連タスクの終了から推定します。 | ||
|
重要な理由
このアクティビティは、計画の効率と手戻りへの影響を把握するうえで重要です。所要時間と発生頻度を分析することで、初期評価の段階を改善できます。
入手先
CHG:Taskフォームの「Impact Analysis」タスクの完了タイムスタンプ、またはCHG:Changeフォームにおける特定のステータス移行から推定します。
取得
CHG:Taskに関連付けられた「Impact Analysis」タスクが「Closed」または「Completed」になった時点のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
抽出ガイド
準備はできましたか?
このテンプレートを使ってデータを準備し、今日から変更管理プロセスの最適化を始めましょう。価値ある情報を見つけ出し、業務全体の効率化につなげられます。
今すぐ変更管理を最適化し、業務の中断を防止
変更の成功率を95%まで高め、コストのかかるサービス中断を防ぎます。
クレジットカードは不要です。セットアップは数分で完了します。