変更管理とは、ITサービスを提供するITインフラストラクチャ（ソフトウェア、ハードウェア、ネットワーク等）の変更を効率的かつ効果的に実施するための活動です。高い変更率に対して効率的かつ効果的に対応するとともに、より優れたリスクおよびコスト評価を提供し、ITとビジネスの整合性の向上を目指します。
また、インシデント発生の50%以上が変更に起因するとされており、変更に必要な承認のプロセスを有効、確実にすることによって、変更が原因で発生するインシデントを最小限に抑える効果も期待できます。変更管理の活動は、以下の6つから成り立っています。
| 活動 | 内容 | |
| 登録とフィルタリング | 「インシデント解決のため」「サービスに対する不満を改善するため」などの理由で作成されたRFC（変更要求）を先のステップで検討できるようにするために1箇所にまとめる作業です。受理されたRFCは内容が登録されることになりますが、非現実的な要求は却下されます。 | |
| 優先度の割り当て | RFCの原因の影響度と、変更の緊急度に基づいて優先順位を明確化にさせる段階であり、問題を是正するためのRFCはその問題重要度コードに基づき決めることが望ましいとされています。 | |
| 変更のカテゴリ化 | 変更が組織に与えるインパクト、変更を達成するために必要なリソース、両方の観点からRFCを評価してカテゴリ分けを行います。軽微な影響のものは次のステップには進まず、関係者に権限が委譲され、変更管理プロセスはその結果などの記録を管理することになります。 | |
| インパクトとリソースの評価 | サービス提供者のマネージャーおよび技術者などから構成されるCAB（変更諮問委員会）を中心に「利用者のビジネスに与える影響」「システムに与える影響」「変更に実施に必要なリソース、コスト」などの観点から変更の実施について最終的な検討を実施します。 | |
| 変更の認可 | CABで認可が下りた変更の実施に向けて、組織から「財務上の認可」「技術上の認可」「事業場の認可」について最終的な認可をもらいます。 | |
| 変更のスケジュール化 テストおよび実装 |
認可の下りた変更は実施に向けスケジュールが組まれます。準備が整うと、「パフォーマンス」「セキュリティ」「保守性」「サポート性」「信頼性/可用性」の観点からテストを実施します。問題がないことが確認できたならば、次の「リリース管理」のプロセスでいよいよ実施段階に入ります。 | |
これらの変更管理プロセスを有効・確実にすることで、変更のプロセス全体が効率化されるため、ビジネスの拡大に対して迅速に対応することができます。同時に、不正な活動を防止して、日本版SOX法などのコンプライアンスを有効・確実にすることにも繋がります。