■変更管理
　変更管理は、ITIL運用上のサービスからシステム全般に渡る、すべての「変更」に関する計画・申請・承認・実施・報告のプロセスの統制を目的にしている。インシデント管理、問題管理と連携してサービス・システム上の変更を安定的かつ確実に行うだけでなく、そのプロセスを管理し、効率化することによるコスト削減までをも視野に入れている。

　変更管理プロセスにおいて大切なことは、その実施の際に不具合が生じた場合、関連部署へ情報のフィードバックを行うことである。変更による「問題」が発生したときに、このフォローアップが組織的にできなければ、情報系統に混乱をきたす恐れがある。また、変更の重要度によって変更理由、変更効果、変更時間、変更手続きなどをあらかじめ明らかにしておけば、組織内での「変更」に対するアレルギーや不信も少なくなる。変更について認知させるには、たとえば以下のように分類すると把握されやすくなる。

１．発生した問題への対処
２．予想される障害への対処
３．新しい装備・ソフト・ハードの拡張・拡充または移設・撤去
４．使用されている設備、技術の改善
５．変更管理運用上の改善

　さらに、危険度別に分類すると、

このようになる。変更管理プロセスを的確にコントロールするためには、これらを把握できるようにしておく必要がある。

　変更による影響力は、ユーザ側とシステム側の両方から計ることが大切である。ユーザ側では接続のしやすさや画面の見やすさ、操作のしやすさなどのサービス面への配慮を、システム側ではシステム変更によるリスク、サービス停止あるいはサービス制限によるユーザへの影響を考慮しなければならない。

　変更管理プロセスにおいては、変更申請数、変更承認数、変更終了数、緊急変更数、変更失敗数など、定期的に蓄積されたデータを、効率、生産性、品質、満足度などの改善に役立てることが望ましい。

■リリース管理と変更管理
　リリース管理は、一般のIT運用環境とシステム開発・保守担当の運用環境を分離し、開発・保守担当者の役割分担や規則を明らかにすることで、ITサービス環境を保護することを目的にしている。この「分離」規則の定めがない場合、テストせずにITライブラリ変更が行われたり、ユーザサービス稼働中にテストが行われたりといったケースが頻繁に起こる危険性があり、ユーザサービス全般に支障が出る恐れがある。

　このような事態を招かないためには、ITサービス担当者がリリース担当者を管理し、開発・保守担当者によるリリース対象を、ユーザサービス環境に取り入れるための権限を持つことが重要になる。リリース管理に必要なことは、以下の2点である。

　ITIL運用上、実際のユーザサービス環境の変更は「変更管理」下におかれている。リリース管理は変更管理規則の承認がなければ、その業務を行うことはできない。まずは変更管理の許可のもとで、リリース管理規則に沿いながらリリース計画・テスト・再構築（手直し）の見通しを立て、テスト内容、実施状況、再構築計画に関して、変更管理の許諾を受ける。変更管理はリリース計画を実際のユーザサービス環境下でのスケジュールに照らし合わせ、調整し、その上でリリース管理におけるリリース計画をユーザサービス環境に適用しなければならない。