リスクスコアリングを使用した安全な変更の実行

一目でわかる使用事例

対象ユーザー: IT 変更の評価、承認、スケジュール、クローズを担当する変更マネージャー

目標: 提案された変更を実装しても安全かどうかを判断し、そのビジネスリスクと技術リスクに比例した管理を適用する

開始点: 影響を受けるサービスまたは設定項目、推定実装期間、説明責任のある所有者を含む変更要求の文書化

正常な結果: 変更が適切なウィンドウに実装され、検証条件を満たし、既知の競合を回避または解決し、結果とフォローアップアクションが文書化されている。

リスク情報を使用して、要請を続行するか、修正するか、再スケジュールするか、却下するかを決定します。関連するヘルプトピックを使用して、アンケートへの回答、スコアリングの設定、競合の解決、承認の管理、要請のクローズを行います。

レビュー可能な変更の確立

レビュー担当者が変更を評価できる十分な詳細から始めます。目的、範囲、影響を受けるサービスと設定項目 (CI)、実装ステップ、テスト計画、ロールバックアプローチ、所有者、推定開始時刻と推定終了時刻を確認します。組織のプロセスに従って、要請を標準、通常、緊急に分類します。

変更種別とその使用目的についての詳細は、「Change Request Management for IT Services (IT サービスの変更要求管理)」を参照してください。変更要求を作成、関連付け、スケジュール、クローズする手順については、「Work with Change Requests for IT Services (IT サービスの変更要求の操作)」を参照してください。

リスク情報を使用したレビューの絞り込み

2 種類のリスク情報が表示される可能性があります。ルールベースの変更リスク評価では、組織で設定されたレコード属性とアンケートへの回答が使用されます。リスクレベルは [低]、[中]、[高]、または [重大] で、スコアは 1 ～ 100 に正規化されます。 システム管理者が設定した質問と加重を使用します。

[リスクレベル] と正規化されたスコアを使用して、判断の代わりにレビューに焦点を絞ります。リスクレベルまたはスコアを高くすると、より強力な証拠、軽減、レビュー、承認が必要になります。リスクレベルまたはスコアが低いほど、不完全な計画や未解決の競合が安全になるわけではありません。評価とそのワークフローについての詳細は、「Change Risk Assessment for IT Services (IT サービスの変更リスク評価)」および「Conduct Change Risk Assessment for IT Services (IT サービスの変更リスク評価の実施)」を参照してください。

計算としきい値についての詳細は、「How Risk Score Is Calculated for Change Requests (変更要求のリスクスコアの計算方法)」を参照してください。組織でカスタマイズされた評価ロジックを使用している場合は、設定された動作をシステム管理者に確認してください。

ルールベースの評価は、省略可能な機械学習予測とは別にします。Change Risk Score (リスクスコアの変更) 予測カードでは、実装の失敗の可能性を 0 ～ 100 のスケールで推定します。ルールベースのリスクレベルを置き換えたり、新しいリスクスコアを変更要求に書き込んだりすることはありません。両方の種類のリスク情報が表示される場合は、承認または変更諮問委員会の決定をどちらに通知したかを記録します。

承認前の競合の解決

影響を受ける CI とその連動関係を確認し、推定実装期間を他のスケジュール済み作業と比較します。変更要求の競合検出が有効になっている場合、同じスケジュール期間に重複する変更要求が同じ設定項目に影響すると、競合レコードが作成されます。競合の検出では、影響を受ける CI を変更要求に関連付ける必要があります。また、変更マネージャーが凍結を回避して作業を再スケジュールできるように、変更要求、リリース、一時停止が IT サービスカレンダーに表示されます。

競合ごとに、要求を再スケジュールするか、その範囲を変更するか、作業を調整するか、競合が適用されない理由を文書化するかを決定します。競合数が空の場合は、IT サービスカレンダーが明確ではないため、個別にカレンダーを確認してください。競合検出によって実装が自動的にブロックされることはありません。競合条件と使用可能なアクションについての詳細は、「IT サービスの変更の競合の確認と解決」を参照してください。

変更の承認と実行

承認の強さを証拠とリスクと照合します。必要なレビュー担当者が影響、軽減、検証、ロールバック、コミュニケーション計画を理解していることを確認します。リスクの高い作業の場合、設定された承認または変更諮問委員会プロセスを介して申請を転送し、実装前に決定を記録します。

実装期間中に、変更履行者は承認済みステップを実行し、重大な偏差を記録し、結果をテストして、サービスの健全性を監視します。検証に失敗したり、リスクが許容範囲を超えた場合は、承認された計画に従って停止またはロールバックします。リスクスコアリングによって実装が自動的にブロックされることはありません。設定された承認ワークフローと変更管理ワークフローによって決定が適用されます。

Change Advisory Boardの概念とワークフローについての詳細は、「Manage Change Advisory Boards for IT Services (IT サービスの変更アドバイザリボードの管理)」を参照してください。

検証、学習、クローズ

クローズ前に、結果をテスト計画と比較し、サービスの健全性を確認し、実装結果を取得して、残りのリスクを特定します。完了コードと概要を記録し、関連ドキュメントを更新して、実装が部分的または失敗した場合の是正作業を割り当てます。

プロセスまたはリスクで必要な場合に実装後レビューを実施します。予想される影響とリスクを実際の結果と比較し、学んだことを使用してテンプレート、評価の回答、実装方法、ロールバック計画を改善します。このジャーニーは、リスクアンケートが完了したときだけでなく、決定と結果が追跡可能なときに成功します。

変更コントロールの準備ができたことを確認する

このジャーニーを使用して採用を評価する前に、変更要求管理、リスク評価、フェーズ管理、変更要求の競合検出、ITサービス カレンダーへのアクセス、必要な承認が変更プロセスに設定されていることを確認します。競合検出が使用されている場合、影響を受ける CI が変更要求に関連付けられていることを確認し、変更マネージャー、履行者、評価者、承認者に必要な権限があることを確認します。