ITIL 的目标

ITIL の目標

変更管理目標

第 3 章

ITIL変更管理に詳しくない場合は、ITIL変更管理とITIL変更コントロールのとの差異を理解する必要があります。この差異を理解することだけで、ITIL変更管理を正当化するための議論の内容を深めることができます。

ITILでは、変更コントロールは以下のように定義されています。

変更の提案、分析、決定、承認、実施、および実施後など、全ての変更を確実にコントロールするための手順。

一方変更管理は、ITILでは以下のように説明されています。

インフラストラクチャあるいはサービス全般に行われた変更をコントロールし、それにより中断を最小限に抑えながら承認された変更を実施することを可能にするプロセス。

変更管理と変更コントロールの根本的な差異は、それぞれの説明文の始めに示されています。変更コントロールは手続ですが、変更管理は総合的なプロセスです。言い換えれば、変更管理プロセスの下で多くの変更がコントロールされることがあるということです。各変更には有効な変更コントロールが必要であり、また変更管理プロセスは全ての変更を統括しています。

正しい変更コントロールを行うことは可能ですが、しかるべきところに有効な変更管理が存在しなければうまくいきません。例えば、2つの異なるITチームが、各自同じサーバへ別々に変更を加えようとしているとします。両チームは効果的に各自の変更をコントロールしていますが、チーム間にコミュニケーションが全くなく一方の変更がもう片方の変更に有害な影響を引き起こしたため、実行段階で問題が発生しました。正しい変更管理があれば、2つのチームが同じサーバの状態を変更させる予定であるという事実が通知され、そしてその変更が失敗しないように各チームが共同するよう依頼があったはずです。変更コントロールは変更管理の構成要素ですから、変更管理は同時に、コントロールされた多くの変更のライフサイクルとステータスを管理しているということになります。

変更管理の範囲が広いため、そのITIL目標自体が広範的であっても驚くことではありません。

変更管理プロセスの目標は、変更に関連したインシデントがサービスの質に与える影響を最小にし、それにより組織の日常業務を改善するために、全ての変更の効率的かつ迅速な処理のために標準化された方法および手続を使用することを確実にすることです。

適切に変更要求に応じるには、リスクとビジネスの継続、変更の影響、リソースの要件、および変更の承認を見積もる計画的な方法が必要です。この計画的アプローチは、変更の必要性と影響との適切なバランスを維持するのに不可欠です。

変更が行われた際、スムーズに移行するためは変更管理プロセスが高い可視性とオープンな伝達経路を持つことが重要です。

ITIL導入の正当性を示す際の助けとなるものが得られるように、冗長とも言える上記の目標の基本的な構成要素を検討し、その目標をさらに徹底的に分析してみましょう。

「変更に関連したインシデントがサービスの質に与える影響を最小にする」これは、変更管理の大きな職責を定量化している明確な説明です。ここで質問です。「変更が失敗した、あるいは「機能した」ものの他のITインフラ・コンポーネントに新たにインシデントまたは問題が生まれた結果として、何か新たなインシデントまたは問題を抱えていますか?」例えば、新しいソフトウェア・アプリケーションが加わってもメモリが不十分であると、パフォーマンスは低下します。上記の質問にどう答えたらよいかわからない場合、自分のインシデントや問題のデータベースを分析し、変更の失敗を示唆する証拠が存在しているかどうか確認してください。変更管理目標が欠けていることを示すには、このデータを使用してください。サービスデスクスタッフに例を求めるのがいいでしょう。変更が失敗しているのであれば、サービスデスクのスタッフは喜んであなたを助けてくれるはずです。

「全ての変更の効率的かつ迅速な処理」次に、変更のスケジューリングとタイミングを考えてみましょう。主要目的が変更要求の登録・管理にある場合は、さまざまな変更要求を調べ、遅いあるいは延期されている変更の割合を調べる必要があります。

これにより、あなたが変更管理目標におけるこの要素を満たしているかどうか決定するためのデータが得られるでしょう。現在しかるべき所に変更管理がない場合、この項目を定量化するのは難しいかもしれません。顧客に対しインタビューなどの方法で調査を行うことにより、現在どれほど効果的に変更管理が行われているかに関する彼らの意見を手に入れることもできますし、あるいは他のIT部門で現在生じている変更要求を収集し分析することもできます。データ収集方法に関わらず、変更のスケジューリングとタイミングが 変更管理の成功の鍵であるため、これは重要な話題です。

どのインフラ項目を変更するか、あるいはいつ変更するかが分からないと効果的に変更管理を行うことができないため、変更要求の登録・管理の中心となるポイントがないこと自体、変更管理の必要性を証明するものとなります。

「標準化された方法および手続を使用することを確実にする」IT部門はそれぞれ、その活動領域での変更の周期を制御するための独自の手法を使用してきました。しかし、異なる部門が共同して同じ変更を管理する場合は、これは良い方法とは言えません。変更にかかわる最も難しい課題の1つは、変更を行うことを成功させることだけではなく、変更をめぐる環境がうまく変更を受け入れることができるのを確実にすることです。例えば、ネットワークブラウザへの変更は、インフラストラクチャ・コンポーネントに対するソフトウェアやメモリのアップグレード、そしてユーザのトレーニングを必要とするかもしれません。これらすべての項目が変更時に達成されない場合は、変更は失敗あるいは問題を引き起こすことになるでしょう。それが方法と手順の標準化が重要である理由です。標準化された方法と手順がないなら、異なるチームが同じ変更に取り組む場合標準化された方法と手順に従わないと失敗の可能性がはるかに高いという根拠を示さなければなりません。それを示さないのであれば、同じ変更に取り組んでいる他のチームが標準化された方法と手順に従わない場合、変更が失敗に終わる可能性が高いということを示さなければなりません。失敗した変更データを使用することで、このポイントを証明することができるかもしれません。

「リスクとビジネスの継続を見積もる計画的な方法」この部分で伝えたいことは、組織において変更を行う孤立したグループがビジネスに極めて大きな影響を持つ可能性があるということです。影響を受けた当事者からの意見を全て踏まえた上で、IT基盤の全ての変更は中心的に決定されなければなりません。変更に対する投資効率（ROI）は、変更へ貢献する他のITチームからの要素を含んでいないため、不明確であることがほとんどです。変更の実質的なコストを知らずに、ITは予算と投資を見積もることができるでしょうか？

変更に取り組むスタッフの数を知らずに、ITは必要なスタッフレベルを決定することができるでしょうか？ITが共同で変更の影響を見積らない限り、サービスデスクへの問い合わせは増える一方でしょう。些細な変更でも、失敗した場合は組織に重大な影響を与える可能性があり、またこの影響は業績に直結することもあります。したがって、この目標に関しては、それは失敗を証明するために証拠を作るというより、これらの項目を間違えることによって起こり得る潜在的なビジネスへの影響を述べているのです。

「変更の必要性と変更による影響との適切なバランスを維持する」変更による潜在的影響・利点・成果とその変更を実行するコストの間は、バランスがとれていなくてはなりません。例えば、サービスデスクへ1日3回の問い合わせを発生させてはいるがビジネスへの影響はほとんどない問題を除去するため変更要求があったとします。初めは、変更を実行するのは名案であるように思えます。しかし、その変更の実行に20万ドルを要するとしたらどうでしょうか?これは大袈裟な例ですが、影響とコスト、どちらをとるかの判断には慎重な考慮が必要であることを強調しているのです。あなたの主張を証明するための信頼性のあるデータを得るのが難しいため、これは達成するのが難しい目標です。ここでも変更要求の管理の論拠を中心的に考えなければなりません。あなたは変更に取り組む全てのチームから意見を集め、またITと顧客という異なる側面を総合した視野から変更を見直すことができるため、このように本当のコストを特定することができます。

「高い可視性とオープンな伝達経路を持つ」簡単に言えば、ITとビジネスを含む関係者一同から定期的に変更の状態のフィードバックを求めるのです。これは行っているかいないかのどちらかであるため、容易に評価することができる目標です。それを行っていないなら、それ自体が変更管理の根拠となります。

変更管理は組織内でのIT成功への一つの鍵です。現在、ITはビジネスプロセスの重要な部分であり、通常のビジネス活動のシステムに完全に統合しています。失敗した変更、遅れた変更、予算オーバーの変更、資金不足の変更、コミュニケーションの悪い変更、孤立した変更、管理不充分の変更は許されません。また、変更コントロールと変更管理の違いを必ず頭に入れておいてください。

> > 第 4 章 - 構成管理目標