ITIL Change Management & the CAB
ITILフレームワークでは変更管理はサービス移行フェーズのメインプロセスの1つとなっています。 (最新版のITIL 4では、このプラクティスは変更許可と呼ばれています)。
- 変更評価
- 製品管理
- アプリケーション開発
- リリース管理
- サービスの検証およびテスト
- サービス資産および構成管理
- 知識管理
Download Now: ITIL 4 Best Practice e-Books
2020年に向けて新しくなったこれらのITIL e-booksは、ITIL 4のベストプラクティスの重要な要素をハイライトしています。
全体として、サービス移行フェーズはサービスと製品の提供を管理します。 このフェーズでは、変更管理はサービス移行に関わるすべてのプロセスにおいて、変更のライフサイクルをコントロールする役割を果たします。
設計上、ライフサイクルを管理することにより、チームはビジネスを中断させることなく、サービス提供モデルに肯定的な変更を加えることができます。 このチームはChange Advisory Board、略してCABとして知られています。
ITILでは、変更管理は、フレームワークの次の2つの目的が競合しているために生じるビジネスリスクを制限することに焦点を当てます:
- 目的1：顧客が信頼できる安定したサービスを提供することです。
- 目的2：顧客のニーズに合わせて迅速に変更できる柔軟なサービスの提供
変更諮問委員会の形式的なものに抵抗しようとする組織もあるかもしれませんが、これらの目的を両方とも満たすことは、ITIL変更管理プロセスをベストプラクティスとして採用することです。
CAB Members
CABはしばしば複数のハイレベルメンバーから構成されています。
サービスデスクアナリスト
サービスデスクアナリストは、サービスコールを受け、インシデントを文書化し、サービスデスクマネージャにエスカレーションします。 アナリストまたはマネージャーのいずれかが、CAB のメンバーとして参加できます。
運用マネージャー
組織の日々の運営に責任を持つ運用マネージャーは、CAB に含まれるかもしれません。
アプリケーションマネージャー/エンジニア
アプリケーションマネージャーは、アプリケーションの開発と展開を監督する責任があります。
情報セキュリティ担当
情報セキュリティ担当者は、ネットワーク セキュリティの日々の側面を管理し、アプリケーションやシステムに対する潜在的な脅威や脆弱性の知識を提供します。
シニア ネットワーク エンジニア
ネットワーク管理者は、組織のネットワークやクラウド インフラストラクチャを監督および管理します。
ビジネス リレーションシップ マネージャー
ビジネス リレーションシップ マネージャーは、通常 B2B の設定でクライアントと直接仕事をしますが、消費者への直接サービスも担当することができます。
(チェンジ マネジメントにおけるさまざまな役割の詳細)
CABチームの特徴
お分かりのように、CABチームは、組織全体のビジネス リーダーと高い権限を持つ個人の多様なグループによって構成されています。
- チーム内および組織全体で専門的な礼儀を育む
- グループに多様性を提供するために多くの異なる視点を提示する
- 変革という目標に向けて互いに関与しようとする強い意志を提供する
CABの目標
完璧なITILフレームワークでは、CABの最終目標は高品質のリリースを保証するので、生産中のすべての変更は、レビュー用にCABを通してもたらされます。
- アプリケーションのタイムラインが他のビジネス ニーズと競合しないことを保証する。
- 一貫した品質基準を顧客に提供する。
- 変更管理プロセスについてビジネスリーダーに助言する。
- レビューと承認プロセスをサポートする。
CABの機能
CABはしばしば上記のグループの目標に基づいて変更マネージャーに助言をします。 しかし、CAB にはレビューおよび承認委員会として機能する権限はないことに注意することが重要です。
- 要求された変更のリスクと結果を評価する
- 利用可能なリソースと潜在的な影響を考慮した変更要求 (RFC) のレビュー
- 最終決定者である変更マネージャをサポートする
- レビュー用の文書作成
- 組織全体で今後の変更に関するコミュニケーションを行う。
- 変更が確実に理解されるようにする
- 会社全体のリスクを減らすための提案をする
- 変更管理プロセスに対する継続的改善の取り組みに参加する
- 変更管理ソフトウェアを使い、必要に応じて変更マネージャに周知する
- 必要に応じて今後の変更のより深いレビューを依頼する
CABには会議の議事録を定期的に再確認する機能もある。
- 前の期間に実装されたすべての変更
- 失敗したすべての変更
- 成功したすべての変更
- チームが実装しなかったすべての変更
以前の会議の監査では、CAB は以下をレビューします。
CAB の運用
変更マネージャーは通常 CAB 会議の実施を担当し、組織の規模やリソースを考慮した定期スケジュールで開催されることがあります。
会議のアジェンダ
会議は通常、前のセクションで説明したように、以前の会議の議事録を確認することから始まります。
- 提案された変更要求 (RFC) を評価する
- リスクと全体的な影響をレビューする
：このようなアジェンダが考えられるでしょう。
緊急 CAB 会議
変更管理者は eCAB として知られる緊急の必要性に取り組むために緊急 CAB 会議をスケジュールすることができます。 これらは通常、サービス移行プロセスで発生したインシデントから生じます。
すべての CAB の介入と同様に、変更マネージャーだけが、緊急の状況であっても、変更の最終承認を行う権限を持っています。
(緊急の CAB である ECAB の詳細について)
CAB & ITSM
以前の投稿で、ITIL と ISO 20000 の類似点と相違点について説明しました。 どちらも、IT サービス管理 (ITSM) を強化するために連携するソリューションを提供しています。
注目すべきは、ISO 20000 を含むほとんどのフレームワークが、変更管理に関して満たさなければならない特定のガイドラインを提供していることです。
CAB: ITILフレームワークの必要な要素
この投稿では、変更諮問委員会について、またなぜそれがサービス移行フェーズにおいてITILフレームワークの重要な部分を形成するのかについて説明しました。
しかし、組織は、いくつかの理由から、CAB の作成に乗り出すのに苦労することがあります。
まず、ビジネスリーダーは、ガバナンスに対して警戒心を抱くことがあります。 人々はしばしば、CAB を承認と拒否を扱い、お役所仕事と障害物を引き起こす理事会だと誤解しています。 実際には、CAB は、すべてのリスクを評価した後で、最適なソリューションについてチェンジマネージャーに助言する立場にあるだけです。
次に、ITIL変更管理プロセス全体について悩んでいるために、CABを導入しない組織もあります。 彼らは、自分たちが適切と考える変更管理プロセスの1つまたは2つの部分のみを実施することがあります。 しかし、これでは、CABの作成など、変更をレビュー、監視、および実装するために必要なベストプラクティスが除外されてしまうことがあります。
CABの作成は、ITILの変更管理プロセス全体から見れば、非常に重要です。