貴社の変更管理データテンプレート
BMC Helix ITSM貴社の変更管理データテンプレート
- 徹底的な分析のために収集すべき推奨`属性`
- プロセス内で追跡すべき主要なアクティビティとマイルストーン
- 関連するソースシステム向けの具体的な抽出ガイダンス
変更管理属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
変更管理プロセス内で実行された特定のイベントまたはタスクの名前。 | ||
|
説明
この属性は、変更要求のライフサイクルにおける単一のステップまたはステータス変更(「変更要求提出済み」や「変更要求承認済み」など)を表します。これらのアクティビティは、プロセスマップの構成要素となります。 これらのアクティビティのシーケンスと期間を分析することは、プロセスフローを特定し、標準手順からの逸脱を発見し、ボトルネックを正確に突き止めるのに役立ちます。アクティビティ名は通常、システムの監査ログに記録されたステータス遷移から派生します。
その重要性
プロセスのステップを定義し、プロセスフローの可視化と分析を可能にするため、プロセスマイニングの核となります。
取得元
「CHG:ChangeRequest_AuditLog」フォームのステータス遷移、または「CHG:Infrastructure Change」フォームの「Status」フィールドへの変更追跡から派生します。
例
変更リクエスト提出済みリスク評価実施済み変更リクエスト承認済み変更実装済み
|
|||
|
変更リクエストID
ChangeRequestID
|
変更要求の一意なシステム生成識別子であり、プライマリケース識別子として機能します。 | ||
|
説明
変更要求IDは、各変更イニシアティブをライフサイクル全体で識別する一意のキーです。関連するすべてのアクティビティ、承認、タスクをグループ化し、プロセスマイニングにおける単一のケースの基礎を形成します。 このIDによるプロセス分析は、初期要求から最終的なクローズまで、変更がどのように管理されているかをエンドツーエンドで把握することを可能にします。これは、サイクルタイムの追跡、ボトルネックの特定、および個々の変更におけるプロセスバリエーションの理解に不可欠です。
その重要性
これは、関連するすべてのイベントを単一のプロセスインスタンスに接続し、変更管理プロセスのエンドツーエンド分析を可能にする基本的な属性です。
取得元
「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 ITSM`Helix ITSM ProdBMC Remedy ARシステム
|
|||
|
最終データ更新
LastDataUpdate
|
このレコードのデータがソースシステムから最後に更新された日時を示すタイムスタンプ。 | ||
|
説明
この属性は、データがBMC Helix ITSMから最後に抽出された日時を示します。これはイベント自体の時間ではなく、データが取得された時間です。この情報は、分析されているデータの鮮度を理解し、データ更新サイクルを管理するために不可欠です。 ダッシュボードやレポートでは、このタイムスタンプは分析がどの程度最新であるかをユーザーに知らせるものであり、進行中のプロセスを監視する上で特に重要です。
その重要性
データの新しさを示します。これは、分析やダッシュボードがプロセスの最新の状態を反映していることを保証するために重要です。
取得元
これは、通常、データ抽出時にETLツールまたはデータパイプラインによって生成および入力されるメタデータフィールドです。
例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
|
|||
|
ステータス
Status
|
変更要求のライフサイクルにおける現在の状態またはフェーズ。 | ||
|
説明
ステータスフィールドは、特定の時点における変更要求の正確な段階(「Draft」(下書き)、「Request For Authorization」(承認要求)、「Completed」(完了)など)を示します。アクティビティはこれらのステータス間の遷移から派生しますが、ステータス自体は現在のワークロードを分析するのに役立ちます。 この属性は「変更スループットと現在のステータス」ダッシュボードにとって不可欠であり、パイプラインの各段階にどれだけの変更があるかのスナップショットを提供します。これにより、マネージャーは作業中の進捗状況とリソース配分を理解するのに役立ちます。
その重要性
変更パイプラインのリアルタイムビューを提供し、現在進行中の作業とすべての変更要求の現状を分析できるようにします。
取得元
「CHG:Infrastructure Change」フォームの「Status」フィールドにあります。
例
下書き承認要求スケジュール済み実装中完了済み
|
|||
|
リスクレベル
RiskLevel
|
変更の実装に伴う潜在的リスクの評価です。 | ||
|
説明
リスクレベルは、変更が実施された場合に生じる潜在的な負の結果に対する定性的または定量的な評価です。これは承認プロセスにおける重要な入力であり、リスクの高い変更はより厳密な精査を受けます。 この属性は「変更リスクプロファイル分析」ダッシュボードの中心であり、ステークホルダーが変更ポートフォリオ全体のリスクエクスポージャーを理解するのに役立ちます。また、初期のリスク評価が不十分であったために後の再評価につながるリワークループを特定するためにも使用されます。
その重要性
プロセスのコンプライアンスと効率性を分析するための重要な側面を提供し、リスクの高い変更が適切に精査されることを保証するのに役立ちます。
取得元
「CHG:Infrastructure Change」フォームの「Risk Level」フィールドにあります。
例
1 - Critical2 - High3 - Medium4 - Low5 - 計画中
|
|||
|
優先度
Priority
|
変更要求に割り当てられた優先度レベルで、そのビジネス上の重要性を示します。 | ||
|
説明
優先度は通常、インパクトと緊急度を組み合わせて決定され、変更要求の処理順序と速度を規定します。優先度の高い変更は通常、より迅速な処理を必要とし、より厳格なSLAが適用される場合があります。 この属性は「変更SLAパフォーマンス」ダッシュボードで、異なる優先度レベルのパフォーマンスをセグメント化して分析するために使用されます。「高優先度の変更のSLAを達成しているか?」といった疑問に答え、リソース配分に関する意思決定を支援します。
その重要性
ビジネス上の重要度別にパフォーマンス分析をセグメント化できるため、最も重要な変更が効率的に処理され、目標を達成していることを確認できます。
取得元
「CHG:Infrastructure Change」フォームの「Priority」フィールドにあります。
例
クリティカル高中低
|
|||
|
変更タイプ
ChangeType
|
標準、通常、緊急といった変更の分類。 | ||
|
説明
この属性は、変更要求をその性質と従うべきプロセスに基づいて分類します。一般的なタイプには、標準(事前承認済み、低リスク)、通常(完全な評価と承認が必要)、緊急(緊急の問題により迅速な処理が必要)が含まれます。 変更タイプによる分析は、プロセスバリエーションを理解するために不可欠です。例えば、「緊急変更量と影響」ダッシュボードは、このフィールドに依拠して緊急変更とサービス安定性への影響を追跡します。また、異なる変更タイプが規定されたパスに従っているかどうかを評価するのにも役立ちます。
その重要性
プロセスをセグメント化して、異なる変更ワークフローを分析・比較できるため、コンプライアンスとパフォーマンス分析の鍵となります。
取得元
「CHG:Infrastructure Change」フォームの「Change Type」フィールドにあります。
例
標準通常緊急影響なし
|
|||
|
実装チーム
ImplementationTeam
|
変更の実装を実行する責任を負うチーム。 | ||
|
説明
この属性は、変更要求によって要求される作業を実行するために割り当てられた技術的または運用グループを識別します。これは多くの場合、変更ライフサイクルの実装フェーズにおける「Assigned Group」(割り当てグループ)です。 この情報は、「変更プロセスにおけるリソースボトルネック」ダッシュボードにとって極めて重要です。実装チームごとのアクティビティ期間とボリュームを分析することで、マネージャーは負荷の不均衡、スキルギャップ、または変更の展開を遅らせるその他のリソース関連の制約を特定できます。
その重要性
担当チームごとのパフォーマンス分析を可能にすることで、実装フェーズにおけるリソース関連のボトルネックを特定するのに役立ちます。
取得元
「CHG:Infrastructure Change」フォームの「ASGRP」(割り当て済みグループ)フィールドにあります。
例
サーバー運用データベース管理者SAPベーシスチームクラウドインフラストラクチャ
|
|||
|
承認者グループ
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
|
変更がクローズされた際の最終結果を示すコードです。 | ||
|
説明
クローズコードは、「Successful」(成功)、「Successful with Issues」(問題ありで成功)、「Backed Out」(バックアウト)、「Cancelled」(キャンセル済み)など、変更要求がクローズされた標準化された理由を提供します。この属性は、最終ステータスだけよりも変更の結果に関するより詳細なビューを提供します。 クローズコードを分析することは、実装された変更の品質と成功率を評価するのに役立ちます。例えば、「Backed Out」された変更の数が多い場合、計画やテストに問題がある可能性を示唆し、プロセス改善のための貴重な指標となります。
その重要性
各変更について明確で構造化された結果を提供し、成功率や失敗・キャンセルの理由を分析できるようにします。
取得元
「CHG:Infrastructure Change」フォームの「Status Reason」または同様のクローズコードフィールドにあります。これは最終段階でアクティブになります。
例
成功問題ありで成功差し戻し済み取り消し済み
|
|||
|
処理時間
ProcessingTime
|
アクティビティに費やされた時間の期間で、開始時刻と終了時刻から計算されます。 | ||
|
説明
処理時間(サイクルタイムとも呼ばれます)は、アクティビティの開始から終了までの経過時間を測定します。これは、プロセスの各ステップにおける「EventEndTime」と「EventStartTime」の差として計算されます。 これはプロセスマイニングにおける基本的なメトリックであり、ボトルネックの特定、効率性の測定、パフォーマンスベースラインの設定に使用されます。「変更承認ボトルネック」のようなダッシュボードや、「平均変更承認時間」のようなKPIは、この計算された値を集計することに直接基づいています。
その重要性
プロセスステップの期間を定量化するために使用される主要なパフォーマンス指標であり、ボトルネック分析と効率改善のために不可欠です。
取得元
これは計算されたメトリックであり、データ変換中に「EventEndTime」から「EventStartTime」を差し引くことによって派生します。
例
864000001728000003600000
|
|||
|
変更申請者
ChangeSubmitter
|
変更要求を作成し提出した個人。 | ||
|
説明
この属性は、変更要求を開始した人物を識別します。これは通常、システム内で「Submitter」(提出者)または「Reported By」(報告者)ユーザーとして記録されます。 常に主要な分析ディメンションではありませんが、変更要求の発生源を理解するのに役立ちます。例えば、ほとんどの変更が特定の部門や役割から発生しているかどうかを分析することで、ビジネスニーズや計画プロセスに関する洞察を得ることができます。
その重要性
変更リクエストの起案者を特定するのに役立ち、これによりプロセス内の需要パターンやユーザー行動を分析できます。
取得元
「CHG:Infrastructure Change」フォームの「Submitter」フィールドにあります。
例
アレン・オールブルックメアリー・マンボブ・バクスター
|
|||
|
影響を受ける**サービス**
AffectedService
|
変更によって影響を受けるビジネスサービスまたは技術サービス。 | ||
|
説明
この属性は、変更要求を構成管理データベース(CMDB)で定義された特定のサービスにリンクします。これは、「Eメールサービス」のようなユーザー向けビジネスサービスの場合もあれば、「認証サービス」のようなバックエンド技術サービスの場合もあります。 「緊急変更量と影響」ダッシュボードで使用され、変更とそれが影響するサービスを関連付けます。これは、異なるサービスの安定性を理解し、頻繁な緊急介入を必要とするサービスを特定するのに役立ちます。
その重要性
重要なビジネスコンテキストを提供し、技術的な変更がビジネスサービスに与える影響を関連付け、サービス中心のプロセス分析を可能にします。
取得元
「CHG:Infrastructure Change」フォームの「ServiceCI」フィールド、または関連する構成アイテム(CI)のリレーションシップから取得されます。
例
会社メールSAP ERP顧客関係管理オンラインバンキングポータル
|
|||
|
影響度
Impact
|
ビジネスサービスとITインフラに対する変更の評価された影響。 | ||
|
説明
影響度は、変更がビジネス運用、サービス、ユーザーに与える潜在的な影響を測定します。これは、緊急度と並んで、変更リクエストの優先度を決定する上で重要な要素です。 分析では、「変更リスクプロファイル分析」ダッシュボードで影響度が使用され、変更ポートフォリオの潜在的なビジネスへの影響について包括的な視点を提供します。影響度の高い変更の分布を理解することは、リスク管理戦略とリソース計画に役立ちます。
その重要性
変更の潜在的なビジネスへの影響を定量化するのに役立ち、サービスがどの程度深刻な影響を受ける可能性があるかに基づいてリスク分析と優先順位付けを可能にします。
取得元
「CHG:Infrastructure Change」フォームの「Impact」フィールドにあります。
例
1-Extensive/Widespread2-Significant/Large3-Moderate/Limited4-Minor/Localized
|
|||
|
手戻り
IsRework
|
あるアクティビティが手戻りループまたはプロセスの後戻りを表すかどうかを示すフラグです。 | ||
|
説明
このブール属性は、変更要求がライフサイクルの前の段階に戻った場合にtrueに設定されます。例えば、「Scheduled」(スケジュール済み)から「Risk Assessment」(リスク評価)に戻る場合などです。このような後方移動はリワークを表し、しばしば非効率性の原因となります。 このフラグは「変更リワーク率」KPIの計算に使用され、「変更リワークと評価効率」ダッシュボードをサポートします。これにより、リワークの頻度を定量化し、それが最も頻繁に発生する特定のプロセスステップを特定するのに役立ち、初期計画と評価における改善領域を示します。
その重要性
手戻りループの一部であるアクティビティにフラグを立てることで、プロセスの非効率性を直接特定し、ターゲットを絞った改善活動を可能にします。
取得元
これは、ケースのアクティビティのシーケンスを分析することで派生する計算された属性です。データ変換中にロジックが適用され、プロセスフローの後方移動を検出します。
例
truefalse
|
|||
|
終了日時
EventEndTime
|
特定の`活動`または`イベント`が`完了`した`時刻`を示す`タイムスタンプ`です。 | ||
|
説明
終了時刻はアクティビティの完了を示します。プロセスマイニングでは、これは多くの場合、ケース内の後続アクティビティの開始時刻として計算され、先行するステップの明確な期間を提供します。ケース内の最後のアクティビティの場合、その開始時刻と同じか、特定のクローズタイムスタンプである可能性があります。 この属性は、各アクティビティの
その重要性
アクティビティ期間の正確な計算を可能にし、ボトルネックの特定とプロセスパフォーマンスの測定に不可欠です。
取得元
これは計算された属性であり、通常、データ変換中に、特定のケースのシーケンスにおける次のイベントの開始時刻を取得することによって派生します。
例
2023-10-26T14:35:10Z2023-10-27T09:00:00Z2023-10-27T11:20:00Z
|
|||
|
緊急変更かどうか
IsEmergencyChange
|
変更が「緊急」タイプである場合にtrueとなるブール値フラグです。 | ||
|
説明
この派生フラグは、緊急変更に対する明確なバイナリインジケーターを提供することで分析を簡素化します。これは「ChangeType」属性の値に基づいています。 この属性は主に「緊急変更量と影響」ダッシュボードと「緊急変更割合」KPIをサポートするために使用されます。これにより、分析ツールで複雑なフィルタリングロジックを使用することなく、緊急変更に関連するデータを簡単にフィルタリングおよび集計でき、その頻度と経時的な傾向を追跡することが容易になります。
その重要性
緊急変更の分析を簡素化し、この重要な変更タイプに関連するKPIのフィルター、ダッシュボード表示、計算を容易にします。
取得元
これはデータ変換中に作成される派生属性です。ロジックは次のとおりです:「ChangeType」が「Emergency」の場合、true。それ以外の場合はfalse。
例
truefalse
|
|||
|
緊急度
Urgency
|
変更の緊急度で、その実装の時間的感度を反映します。 | ||
|
説明
緊急度は、変更がどれだけ迅速に実装される必要があるかを示します。これは、インパクトとともに、変更要求の全体的な優先度を計算するために使用される主要な要素です。 緊急度は「変更リスクプロファイル分析」ダッシュボードにとって重要な属性であり、変更管理プロセスにかかる時間的プレッシャーに関する洞察を提供します。緊急度の傾向を分析することで、多くの時間制約のあるリクエストを引き起こしている可能性のある根本的な問題を特定するのに役立ちます。
その重要性
変更の時間的制約の性質を反映し、プロセスが異なる時間的感度レベルのリクエストを効果的に処理しているかを分析するのに役立ちます。
取得元
「CHG:Infrastructure Change」フォームの「Urgency」フィールドにあります。
例
1-Critical(緊急)2-High(高)3-Medium(中)4-Low(低)
|
|||
|
関連インシデント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
|
|||
|
変更クローズ済み
|
これは最終アクティビティであり、システムにおける変更要求の正式なクローズを示します。このイベントは、変更要求のステータスが「Closed」(クローズ済み)に設定されたときに記録されます。 | ||
|
その重要性
このアクティビティは、変更ライフサイクルの成功裏の終了を示します。エンドツーエンドのプロセス期間と全体的なスループットを測定するために不可欠です。
取得元
CHG:Changeフォームのステータス変更履歴において、ステータスが「Closed」に移行したときに推測されます。
取得
CHG:Changeフォームの「Status」フィールドが「Closed」に更新されたタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
変更スケジュール済み
|
このアクティビティは、承認された変更が正式に実装のためにスケジュールされた時点を示します。このイベントは、システム内のステータスが「Scheduled」(スケジュール済み)に変更されたときに記録されます。 | ||
|
その重要性
これは実装の準備ができたことを知らせる重要なマイルストーンです。変更実装サイクルタイムおよび平均実装待機時間KPIを測定するための出発点となります。
取得元
CHG:Changeフォームのステータス変更履歴において、ステータスが「Scheduled」に移行したときに推測されます。
取得
CHG:Changeフォームの「Status」フィールドが「Scheduled」に更新されたタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
変更リクエスト作成済み
|
このアクティビティは、システム内での変更要求レコードの初期作成を示します。このイベントは、CHG:Changeフォーム内の変更要求エントリの作成タイムスタンプから記録されます。 | ||
|
その重要性
これはすべての変更要求の開始点であり、総ライフサイクル期間の測定と、受信する変更のボリュームを分析するために不可欠です。
取得元
このイベントは、「Submit Date」またはCHG:Changeフォームの監査ログ(例:HPD:Help Desk Audit Log)にあるレコード作成タイムスタンプから記録されます。
取得
CHG:Changeフォームのレコード作成タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
変更リクエスト承認済み
|
これは、変更要求が続行するための正式な承認を受ける主要なマイルストーンです。このイベントは、通常、最終承認後にステータスが「Scheduled」(スケジュール済み)または「Planning In Progress」(計画進行中)に変更されたことから推測されます。 | ||
|
その重要性
これは承認フェーズの終了を示し、承認ボトルネックと平均変更承認時間KPIを測定するために重要です。プロセスにおける主要な意思決定ポイントとなります。
取得元
CHG:Changeフォームのステータス変更履歴、特にリクエストが「Request For Authorization」のような承認ステータスから移行したときに推測されます。
取得
CHG:Changeフォームの「Status」フィールドが最終承認フェーズを通過し、例えば「Scheduled」に遷移したタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
変更実装済み
|
このアクティビティは、変更実装作業の成功裏の完了を表します。通常、ステータスが「Completed」(完了)に更新され、成功を示す理由が付記されたときに記録されます。 | ||
|
その重要性
これは、展開フェーズの終了を示す主要なマイルストーンです。変更実装サイクルタイムの計算と、変更起因インシデントの分析に不可欠です。
取得元
CHG:Changeフォームにおいて「Status」が「Completed」に設定され、「Status Reason」が「Successful」である場合に推測されます。
取得
CHG:Changeフォームの「Status」フィールドが「Completed」に更新されたタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
変更キャンセル済み
|
変更要求が実装または完了する前のキャンセルを表します。これは、変更要求のステータスが「Cancelled」(キャンセル済み)に更新されたときに記録されます。 | ||
|
その重要性
キャンセルを追跡することで、変更が撤回される理由に関する洞察が得られます。これは、初期計画の不備、優先順位の変更、リソース制約などの問題を浮き彫りにする可能性があります。
取得元
CHG:Changeフォームのステータス変更履歴において、ステータスが「Cancelled」に移行したときに推測されます。
取得
CHG:Changeフォームの「Status」フィールドが「Cancelled」に更新されたタイムスタンプを特定します。
イベントタイプ
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
|
|||
|
変更検証済み
|
このアクティビティは、変更が実装とテストの後にステークホルダーによって正式に成功として検証されたことを示します。これはしばしば、最終的なクローズ前のステータス変更によって表されます。 | ||
|
その重要性
検証は、変更をクローズする前の最終品質ゲートです。変更が目的を達成し、意図しない悪影響を引き起こさなかったことを確認します。
取得元
CHG:Changeフォームのステータス変更、例えば「Completed」から「Verification」または「Closed」ステータスへの移行から推測されます。
取得
CHG:Changeフォームの「Status」フィールドが、実装アクティビティ後に「Closed」に遷移したタイムスタンプを特定します。
イベントタイプ
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
|
|||