変更管理データテンプレート
変更管理データテンプレート
- 詳細な分析に必要な、収集を推奨する属性
- プロセス内で追跡する主要なアクティビティとマイルストーン
- 関連するソースシステムからデータを抽出する具体的な手順
変更管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
変更管理プロセスで実行された特定のイベントまたはタスクの名前です。 | ||
|
説明
変更要求のライフサイクルにおける1つのステップまたはステータス変更を示す属性です。たとえば、「変更要求の提出」や「変更要求の承認」などがあります。これらのアクティビティがプロセスマップを構成します。 アクティビティの順序と所要時間を分析すると、プロセスの流れを把握し、標準手順からの逸脱を見つけ、ボトルネックを特定できます。アクティビティ名は通常、システムの監査ログに記録されたステータスの変更から取得します。
重要な理由
プロセスの各ステップを定義する属性です。プロセスの流れを可視化して分析できるため、プロセスマイニングの基盤となります。
入手先
「CHG:ChangeRequest_AuditLog」フォームのステータス変更、または「CHG:Infrastructure Change」フォームの「Status」フィールドの変更を追跡して取得します。
例
変更要求の提出リスク評価の実施変更要求の承認変更の実施
|
|||
|
変更要求ID
ChangeRequestID
|
変更要求を識別する、システムが自動生成した一意のIDです。ケースを識別する主キーとして使用します。 | ||
|
説明
変更要求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」など、特定の時点における変更要求の正確な段階を示します。アクティビティはこれらのステータス間の移行から導き出されますが、ステータス自体も現在の作業量を分析するうえで役立ちます。 この属性は、「変更の処理量と現在の状態」ダッシュボードに欠かせません。パイプラインの各段階にある変更の件数を把握できます。進行中の作業とリソース配分を理解するのにも役立ちます。
重要な理由
変更のパイプラインをリアルタイムで把握し、進行中の作業とすべての変更要求の現在の状態を分析できます。
入手先
「CHG:Infrastructure Change」フォームの「Status」フィールドにあります。
例
下書き承認申請中スケジュール済み実施中完了
|
|||
|
リスクレベル
RiskLevel
|
変更の実施に伴う潜在的なリスクの評価です。 | ||
|
説明
リスクレベルは、変更を実施した場合に悪影響が生じる可能性を定性的または定量的に評価したものです。承認プロセスの重要な判断材料となり、リスクの高い変更ほど慎重な審査が行われます。 この属性は「変更のリスクプロファイル分析」ダッシュボードの中心となる項目です。変更ポートフォリオ全体のリスクを関係者が把握するのに役立ちます。また、初期のリスク評価が不十分で、後から再評価が必要となる手戻りのループを特定するためにも使います。
重要な理由
プロセスのコンプライアンスと効率を分析するうえで重要な観点です。リスクの高い変更が適切に審査されているかを確認できます。
入手先
「CHG:Infrastructure Change」フォームの「Risk Level」フィールドにあります。
例
1 - 重大2 - 高3 - 中4 - 低5 - 計画中
|
|||
|
優先度
Priority
|
変更要求に割り当てられた優先度です。業務上の重要性を示します。 | ||
|
説明
優先度は通常、影響度と緊急度を組み合わせて決定し、変更要求の処理順序と速度を左右します。優先度の高い変更は、より迅速な処理が必要となり、より厳しいサービスレベル合意(SLA)が適用される場合があります。 この属性は「変更のSLAパフォーマンス」ダッシュボードで、優先度ごとのパフォーマンスを分類して分析するために使います。「優先度の高い変更でSLAを達成できているか」といった問いへの回答や、リソース配分の判断に役立ちます。
重要な理由
業務上の重要性に応じてパフォーマンスを分析できます。特に重要な変更を効率よく処理し、目標を達成できているかを確認できます。
入手先
「CHG:Infrastructure Change」フォームの「Priority」フィールドにあります。
例
重大高中低
|
|||
|
変更タイプ
ChangeType
|
標準、通常、緊急など、変更の分類です。 | ||
|
説明
変更の性質と適用されるプロセスに基づいて、変更要求を分類する属性です。一般的なタイプには、事前承認済みでリスクの低い「Standard」、詳細な評価と承認が必要な「Normal」、緊急の問題に対応するため迅速な処理が必要な「Emergency」があります。 変更タイプ別の分析は、プロセスの違いを把握するうえで重要です。たとえば、「緊急変更の件数と影響」ダッシュボードでは、このフィールドを使って緊急変更とサービスの安定性への影響を追跡します。また、変更タイプごとに定められた手順に沿って処理されているかを評価できます。
重要な理由
プロセスを変更ワークフローごとに分けて比較できます。コンプライアンスとパフォーマンスの分析に役立ちます。
入手先
「CHG:Infrastructure Change」フォームの「Change Type」フィールドにあります。
例
標準通常緊急影響なし
|
|||
|
実装チーム
ImplementationTeam
|
変更の実装を担当するチームです。 | ||
|
説明
この属性は、変更申請に必要な作業を行う技術または運用グループを示します。変更ライフサイクルの実装段階では、「Assigned Group」として記録されることがよくあります。 この情報は「変更プロセスのリソースボトルネック」ダッシュボードに欠かせません。実装チームごとのアクティビティの所要時間と件数を分析すると、管理者は負荷の偏り、スキル不足、その他のリソース上の制約を特定できます。これらの制約は、変更の展開を遅らせる原因になります。
重要な理由
担当チームごとにパフォーマンスを分析することで、実装段階におけるリソース関連のボトルネックを特定できます。
入手先
「CHG:Infrastructure Change」フォームの「ASGRP」(Assigned Group)フィールドにあります。
例
サーバー運用データベース管理者SAP Basisチームクラウドインフラストラクチャ
|
|||
|
承認グループ
ApproverGroup
|
特定の段階で変更申請を承認するチームまたはグループです。 | ||
|
説明
この属性は、変更の審査と承認を担当するグループを示します。変更には複数の承認段階があるため、ライフサイクルの各段階で異なるグループが割り当てられる場合があります。たとえば、技術承認チームや業務承認委員会などです。 この属性は「変更承認のボトルネック」ダッシュボードに欠かせません。担当グループごとに承認時間を分けて分析できるため、過剰な負荷や非効率によって遅延を招いているチームを特定できます。
重要な理由
担当チームごとの承認所要時間を分析することで、承認プロセスのボトルネックを特定できます。
入手先
承認を管理し、変更申請に関連付けられている「AP:Signature」フォームから取得します。承認者のグループはこのレコードに含まれます。
例
変更諮問委員会ITセキュリティネットワークエンジニアリングアプリケーション開発
|
|||
|
SLA状態
SLAState
|
SLA目標に対する変更申請の算出済みステータスです。 | ||
|
説明
この属性は、完了した変更申請がサービスレベル契約(SLA)を達成したか、未達のリスクがあったか、または未達となったかを示します。「SLATargetDate」と実際の完了日時を比較して算出します。 「変更のSLAパフォーマンス」ダッシュボードの主要指標です。サービスの約束に対するパフォーマンスを明確かつ簡潔に示します。また、優先度、変更の種類、チームごとにデータを分類して、SLA遵守状況に課題のある領域を特定できます。
重要な理由
約束に対するパフォーマンスを直接測定できるため、プロセス効率とサービス品質を示す重要な指標となります。
入手先
データ変換時に、最終アクティビティの日時と「SLATargetDate」を比較して算出する属性です。
例
期限内リスクあり未達
|
|||
|
SLA目標日時
SLATargetDate
|
変更申請の完了期限となる日時です。 | ||
|
説明
サービスレベル契約(SLA)の目標日時は、変更申請の優先度と種類に基づいて定められる完了期限です。実際の完了時間を測る基準となります。 この属性は「変更のSLAパフォーマンス」ダッシュボードの基礎となります。実際の完了時間を目標と比較することで、変更がSLAを満たしたかどうかを判定できます。SLAパフォーマンスを分析すると、プロセス全体の効率とサービスレベルの約束の遵守状況を評価できます。
重要な理由
パフォーマンスを測定する基準となり、SLA遵守率の算出やリスクのある変更の特定に役立ちます。
入手先
通常、関連するSLA管理フォームに保存され、変更申請に紐付けられています。変更フォーム自体に表示される場合もあります。
例
2023-11-10T17:00:00Z2023-11-15T09:00:00Z2023-12-01T17:00:00Z
|
|||
|
クローズコード
CloseCode
|
変更をクローズした際の最終結果を示すコードです。 | ||
|
説明
クローズコードは、変更申請を終了した理由を「成功」「問題ありで成功」「差し戻し」「キャンセル」などの標準化された値で示します。最終ステータスだけの場合よりも、変更結果を詳しく把握できます。 クローズコードを分析すると、実施した変更の品質や成功率を評価できます。たとえば、「差し戻し」の件数が多い場合、計画やテストに問題がある可能性があります。プロセス改善に役立つ指標となります。
重要な理由
変更ごとの結果を明確な形式で記録し、成功率や失敗・キャンセルの理由を分析できます。
入手先
「CHG:Infrastructure Change」フォームの「Status Reason」または同様のクローズコード用フィールドにあります。最終段階で有効になります。
例
成功問題ありで成功差し戻しキャンセル
|
|||
|
変更申請者
ChangeSubmitter
|
変更申請を作成して提出した人です。 | ||
|
説明
この属性は、変更申請を開始した人を示します。通常、システムでは「Submitter」または「Reported By」ユーザーとして記録されます。 分析の主要な切り口とは限りませんが、変更申請の発生源を把握する際に役立ちます。たとえば、特定の部門やロールから変更の大半が発生しているかを分析すると、業務ニーズや計画プロセスについて理解を深められます。
重要な理由
変更申請の起点となった人を特定し、プロセスにおける需要の傾向やユーザーの行動を分析できます。
入手先
「CHG:Infrastructure Change」フォームの「Submitter」フィールドにあります。
例
Allen AllbrookMary MannBob Baxter
|
|||
|
影響を受けるサービス
AffectedService
|
変更によって影響を受ける業務サービスまたは技術サービスです。 | ||
|
説明
この属性は、変更申請を構成管理データベース(CMDB)で定義された特定のサービスに関連付けます。「メールサービス」のようなユーザー向け業務サービスや、「認証サービス」のようなバックエンドの技術サービスが該当します。 「緊急変更の件数と影響」ダッシュボードでは、変更と影響を受けるサービスを関連付けるために使用します。これにより、各サービスの安定性を把握し、緊急対応が頻繁に必要となるサービスを特定できます。
重要な理由
技術的な変更と業務サービスへの影響を結び付けることで、重要な業務コンテキストを提供し、サービスを軸にしたプロセス分析を可能にします。
入手先
「CHG:Infrastructure Change」フォームの「ServiceCI」フィールド、または関連する構成アイテム(CI)の関係から取得します。
例
社内メールSAP ERP顧客関係管理オンラインバンキングポータル
|
|||
|
影響度
Impact
|
変更が業務サービスやITインフラに及ぼす影響の評価です。 | ||
|
説明
影響度は、変更が業務、サービス、ユーザーに及ぼす可能性のある影響を示します。緊急度とともに、変更要求の優先度を決める重要な要素です。 分析では、「変更のリスクプロファイル分析」ダッシュボードで影響度を使い、変更ポートフォリオが業務に及ぼす可能性のある影響を詳しく把握します。影響度の高い変更の分布を理解すると、リスク管理の方針やリソース計画の検討に役立ちます。
重要な理由
変更が業務に及ぼす可能性のある影響を定量化し、サービスへの影響の大きさに基づくリスク分析と優先順位付けに役立ちます。
入手先
「CHG:Infrastructure Change」フォームの「Impact」フィールドにあります。
例
1 - 広範囲2 - 大規模3 - 中程度4 - 軽微
|
|||
|
手戻りの有無
IsRework
|
アクティビティが手戻りのループ、またはプロセスの後戻りに該当するかを示すフラグです。 | ||
|
説明
このブール属性は、変更申請がライフサイクルの前段階に戻った場合にtrueになります。たとえば、「スケジュール済み」から「リスク評価」に戻る場合です。このような後戻りは手戻りにあたり、非効率の原因となることがよくあります。 このフラグは「変更の手戻り率」KPIの算出と、「変更の手戻りと評価効率」ダッシュボードに使用します。手戻りの頻度を数値化し、発生しやすいプロセスの段階を特定することで、初期の計画や評価における改善点を見つけられます。
重要な理由
手戻りループに含まれるアクティビティを特定し、プロセスの非効率を明らかにすることで、対象を絞った改善につなげられます。
入手先
ケース内のアクティビティの順序を分析して算出する属性です。データ変換時にロジックを適用し、プロセスフローの後戻りを検出します。
例
truefalse
|
|||
|
終了時刻
EventEndTime
|
特定のアクティビティまたはイベントが終了した日時です。 | ||
|
説明
終了時刻は、アクティビティが完了した時点を示します。プロセスマイニングでは、前のステップの所要時間を明確にするため、同じケース内で次のアクティビティが始まった時刻を終了時刻として算出することがよくあります。ケース内の最後のアクティビティでは、開始時刻と同じ時刻、または特定の完了日時を使用する場合があります。 この属性は、各アクティビティの
重要な理由
アクティビティの所要時間を正確に算出できます。ボトルネックの特定やプロセスのパフォーマンス測定に欠かせません。
入手先
計算によって求める属性です。通常、データ変換時に、同じケース内で次に発生するイベントの開始時刻から算出します。
例
2023-10-26T14:35:10Z2023-10-27T09:00:00Z2023-10-27T11:20:00Z
|
|||
|
緊急変更の有無
IsEmergencyChange
|
変更の種類が「緊急」の場合にtrueとなるブールフラグです。 | ||
|
説明
この派生フラグにより、緊急変更を明確な二値で示し、分析を簡素化できます。「ChangeType」属性の値に基づいています。 主に「緊急変更の件数と影響」ダッシュボードと「緊急変更率」KPIに使用します。複雑な絞り込みロジックを分析ツールに設定しなくても、緊急変更に関するデータを簡単に絞り込み、集計できます。これにより、発生頻度や経時的な傾向を把握できます。
重要な理由
緊急変更の分析を簡素化し、この重要な変更種別に関するデータの絞り込み、ダッシュボードでの表示、KPIの算出を容易にします。
入手先
データ変換時に作成する派生属性です。ロジックは「IF 'ChangeType' = 'Emergency' THEN true ELSE false」です。
例
truefalse
|
|||
|
緊急度
Urgency
|
変更の実施を急ぐ必要性を示す、時間的な緊急度です。 | ||
|
説明
緊急度は、変更をどれだけ早く実施する必要があるかを示します。影響度とともに、変更要求の優先度を算出する重要な要素です。 「変更のリスクプロファイル分析」ダッシュボードでは、緊急度を使って変更管理プロセスにかかる時間的な圧力を把握できます。緊急度の傾向を分析すると、期限の厳しい要求が多く発生する根本的な問題を特定できる場合があります。
重要な理由
変更に求められる時間的な緊急性を示し、時間的制約の異なる要求をプロセスが適切に処理できているかを分析できます。
入手先
「CHG:Infrastructure Change」フォームの「Urgency」フィールドにあります。
例
1 - 重大2 - 高3-中4-低
|
|||
|
関連インシデントID
RelatedIncidentID
|
この変更が原因で発生したインシデントの識別子です。 | ||
|
説明
この属性は、変更申請と、その後に発生した可能性のあるインシデントを関連付けます。この関係は、変更がサービスの安定性に及ぼす影響を把握するうえで重要です。 「変更起因インシデント率」の重要業績評価指標(KPI)の算出に必要な主要属性です。この関連を追跡することで、組織は変更プロセスの品質を測定し、実施後の問題発生率が高い変更の種類、チーム、サービスを特定できます。
重要な理由
変更による悪影響を直接測定できるため、変更の品質とリスク管理の有効性を評価する重要なKPIとなります。
入手先
通常、インシデントフォーム(「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
|
|||
|
変更のスケジュール設定
|
承認済みの変更について、実施スケジュールが正式に設定された時点を示します。システムのステータスが「Scheduled」に変わった時点から取得します。 | ||
|
重要な理由
実施の準備が整ったことを示す重要な節目です。変更実施サイクルタイムと平均実施待ち時間の重要業績評価指標(KPI)を測定する起点となります。
入手先
CHG:Changeフォームのステータス変更履歴で、ステータスが「Scheduled」に変わった時点から判定します。
記録
CHG:Changeの「Status」フィールドが「Scheduled」に更新された日時を特定します。
イベントタイプ
inferred
|
|||
|
変更の完了
|
システム上で変更要求を正式に完了したことを示す最後のアクティビティです。変更要求のステータスが「Closed」に設定された時点で記録されます。 | ||
|
重要な理由
変更のライフサイクルが正常に終了したことを示します。プロセス全体の所要時間と処理量を測定するうえで欠かせません。
入手先
CHG:Changeフォームのステータス変更履歴で、ステータスが「Closed」に変わった時点から判定します。
記録
CHG:Changeの「Status」フィールドが「Closed」に更新された日時を特定します。
イベントタイプ
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%に高め、サービスの中断による損失を防ぎましょう。
クレジットカードは不要です。設定は数分で完了します。