ITチェンジマネジメントにおけるリスク軽減のための規律策定(後編)

先日の記事で、以下のテーマを紹介しました。 ITチェンジマネジメントの規律としてのリスク軽減.私たちは、リスクを評価するために、3つの次元を適用することを提案しました。リスクは 確率 問題が発生した場合、その可能性が高い インパクト その問題の、そしてその容易さ リカバリー が発生した場合。

これらの次元に加えて、リスクマネジメントは、提案された変更を3つの異なるレベルの範囲に従って見ることができます。

  • に伴うリスク。 規格変更これは、DevOpsで言うところの、日常的で予期された変更であり、全体的なリスクが非常に低いため、理想的には自動化されています。
  • 連続体のもう一方の端に 事業の評判を損なうような、重大で予期せぬリスク。例えば、データセンターがダウンした場合、顧客向けの重要なアプリケーションが故障した場合、あるいは重大なバグがあることが判明した場合などです。このようなリスクに対して、組織は複数の冗長性、シミュレーション、卓上演習、その他の高度なリスクマネジメントとIT継続性の手順を開発する。
  • 中間リスク - に伴うリスク 日次の運用変更 そのため、自動化することはできません。それは、一回限りであったり、バグフィックスであったり、深刻なトラブルや停止、ダウンタイムの延長、ユーザーや顧客の不満の原因になるような複雑なものであったり、新たな事故を引き起こす可能性のある変化です。

この中間カテゴリーのリスクは、ミッションクリティカルとは見なされず、自動化によって排除する明白な方法がないため、無視されたり、積極的に管理されないことがよくあります。IT 組織は、より重要なリスクの管理には比較的効果的であっても、こうした中間レベルのリスクの軽減に失敗することがよくあります。

これらの中間リスクは、チェンジマネージャーやCABが日々対処していることの大きな割合を占めています。実際、チェンジマネージャーは、一般に、自動化できる標準的な変更と、ビジネスを脅かす可能性のあるミッションクリティカルなリスクは、例外的なケースとみなしています。中間レベルの変更、つまり、CAB が扱う他のすべてのものは、組織がそもそも変更管理を採用した理由とし て受け入れられる。リスクは見え隠れする。それは、CABがリスクについて自己満足しているのではなく、チームが変化の計画と実施に忙殺され、実際にリスクを評価し管理する必要性がしばしば無視されるからです。

これは、将来の事故を回避するための重要な改善機会です。

改善には、これらの変化を3つの次元に関して中間レベルで評価し、原因および結果の両レベルで緩和策を特定し選択するための基礎として、明確な問題記述と根本原因を通じて実際のリスクを可視化することが含まれます。最終的には、この分析結果を明確な行動計画に落とし込みます。

この「プラクティス」を継続的なサービス改善の一環としてさらに強化するには、問題管理の取り組みに「修正を超えた思考」を適用し、RCAを拡張して修正を適用できる他の領域を探すだけでなく、修正とは別の変更に他ならないため、修正がもたらすリスクにも目を向ける必要があります。

ある金融サービス業のお客様は、この規律によって1万件以上の問題の発生を防ぐことができたと試算しています。

要するに、リスク軽減は芸術ではなく、まず何よりも業務上の規律なのです。

KTは、IT組織のためのリスク・ミティゲーションの1日ワークショップを開催しています。このワークショップでは、基本的なリスク・ミティゲーションをビジネスに導入するための有用で基本的な規律を学ぶことができます。

このワークショップの詳細はこちら

関連

ブログ画像1
ITチェンジマネジメントにおけるリスク軽減のための規律の策定(その1)
ブログ画像1
プロジェクト・リスクの管理:スペクター、ファースト・オーダー、反乱同盟が失敗した例

私たちは以下の専門家です:

お問い合わせ

お問い合わせ、ご意見、詳細確認はこちらから