変更管理とは?システム変更時に失敗しない目標設定とツールの選び方

ITIL®準拠 ITサービスマネジメント

変更管理とは?システム変更時に失敗しない目標設定とツールの選び方

baloon-red 変更とは

ITIL®における「変更」は、ITサービスに影響を及ぼす可能性のあるITインフラストラクチャ(ハードウェア、ソフトウェア、ネットワーク、人など)を、追加・修正・削除し、構成を改善することをいいます。たとえば、OSのアップデートや、セキュリティパッチの適用などが変更に含まれます。また、新しいプロセスや仕組みの導入、文書の適用、担当者・担当業務の変更、プロセスや手順の廃止もITIL®における「変更」に含まれます。

変更は、インシデント管理問題管理からも発生します。

一方、ITIL®における「変更」に含まれないのは、ITサービスに影響を及ぼす可能性の低いルーチン化された作業です。たとえば、プリンターの用紙切れを補充する作業は、変更には含まれません。

baloon-red 変更管理とは

ITIL®における変更管理プロセスは、すべての変更のライフサイクルをコントロールします。変更によるリスクの認識や、標準化された手順での変更の実施により、ITサービスの中断を最小限に抑えながら、有益な変更を実施できるようにすることです。

変更管理の目的は、大きく分けて3つあります。一つ目は、変更により障害が起きた際に特定をするため、変更履歴を残すことです。二つ目は、変更によるダウンタイムを最小限に抑えるためです。そして三つ目は、変更対象外のシステムをコントロールするためです。

変更が必要なのか、類似の変更がないか、変更による影響範囲の評価、変更の計画・実行は誰が行うのか、指揮系統が複数存在しないかなど、想定外の事態やリスク、混乱が発生しないようにすべての変更はきちんと管理する必要があります。

baloon-red 適切な目標設定の重要性と目的

システム上の変更はとてもシンプルだったとしても、運用現場の業務フローや慣習、人事情報など、様々な要因が組み合わさる事で、「小さな変更」が「大きな混乱」を招くことがあります。

少し遠回りのように思えても、

  • 変更を行うことで達成したい「目標」を明確に設定
  • 綿密な計画や関係者への徹底した通知
  • 承認やレビューのプロセスを整える
  • 変更履歴を残す

といったことは、インシデントの発生件数を抑制し、ビジネスの継続性を保つ(ビジネスインパクトをできる限り下げる)上で重要と言えるでしょう。

「変更」そのものは、組織が成長していく上で必要不可欠です。適切な目標設定と共にしっかり管理することで、改革や成長をスムーズにけん引してくれる動力源にもなります。

baloon-red 変更管理のポイント!ツールの選び方

変更管理を導入する際に、自社の環境に合わせて考慮すべきポイントは以下の通りです。

■ 変更管理のポイント!
  • 変更計画の正確な手順、失敗した場合の復旧手順を用意する
  • 各担当者ごとにそれぞれの役割を割り当てる(オーナーの明確化)
  • 影響のあるITサービスをすべて把握する
    - 変更により影響のある構成アイテム(CI)の把握(構成管理)※
  • 承認やレビューを行う
  • 変更計画を関係者全体に共有&通知する
  • 変更履歴を残し、必要に応じて再確認可能できる 

構成管理につきましては、こちらをご参照ください。

大規模な組織になってくると、メールや口頭で画一的なプロセス運用を行うことが難しい場合があります。
そんな時は、ツールの活用がお勧めです。

ツールによっては、ITIL®に則ったフロー機能が元から備わった状態で利用できますので、スクラッチから開発するよりもはるかに効率的なプロセス導入を行えます。

■参考資料:
「変更管理」はなぜ必要?組織に大量の「インシデント」をまき散らす怪物の正体とは

上記参考資料のケースを例に挙げると、例えば

  • 「電話機の取り換え」という変更計画を関係者全体に共有&通知する機能
  • それぞれの役割を担当者ごとに割り当てる機能
  • 変更計画をスケジュール表(カレンダー)で確認する機能
  • 承認やレビューを確実に行うための機能
  • 変更に伴って発生した「電話が使えない」などのお問合せを変更情報に紐づける機能

などを活用できます。

ServiceDesk Plus 変更管理ワークフロー

baloon-red ServiceDesk Plusで実現するITIL®変更管理プロセス

ServiceDesk Plusでは、ITIL®の変更管理プロセスに則った変更を実施できるよう、変更タイプ・CAB・変更の役割・変更ステージ・変更テンプレート・変更ワークフローなどの変更管理機能を提供します。

ServiceDesk Plusの変更ライフサイクルは次の6段階に分かれています。

変更要求は起票されてからクローズされるまでの間に、すべての/一部の段階(ステージ)を経ます。1つの段階から次の段階に移行するには、承認を得る必要があります。ServiceDesk Plusでは、変更プロセスの時間軸に沿って最大6つの段階の設定と、各段階内での活動を定義できます。

また、変更ライフサイクルの各段階を進行するにあたり、承認済み(Approved)、却下(Rejected)、情報の要求(Request for Information)などのステータスで進捗を把握します。関係者に変更のステータスを知らせる自動通知メール機能を備えています。

ステージ1:要求提起(Submission)

変更リクエスト(RFC)の作成します。
変更は、変更に伴うコストとリスク、変更の適用範囲、他の変更との関係に応じて種類分けされます。
ServiceDesk Plusでは、ITIL®で推奨されている3つ変更タイプ(標準的な変更、緊急の変更、 通常の変更)が用意されているほか、必要に応じて組織固有の変更タイプを追加できます。
さらに変更カレンダー上で識別しやすいよう、それぞれの変更タイプにはコードカラーを設定できます。

ステージ2:計画(Planning)

変更の計画とアセスメント(事前影響評価)を実施します。
ITサービスに与えるインパクト、変更実施プラン、万が一問題が発生してしまった場合の復旧プラン、変更作業により発生するダウンタイム時間などをここで検討します。

ステージ3:承認(Approval)

変更マネージャ、または、CAB(変更諮問委員会)メンバーに対して承認を依頼します。
承認者は、「変更の目的、内容、手順が妥当であるか」を評価、判断します。
CABは、変更承認者の意思決定を支援し、変更のアセスメントや優先度付において変更管理をサポートします。多くの場合、CABのメンバーは、変更におけるビジネス部門とIT部門の利害関係者のニーズ全般を明確に把握している人々で構成されます。

ステージ4:構築(Implementation)

スケジュールに合わせ、変更を実施します。
変更実装は、タスク単位で手順を管理・進捗を管理します。

ステージ5:レビュー(Review)

承認された内容で変更が正常に行われたか、レビューします。

ステージ6:クローズ(Closure)

クローズします。

詳細、参考画像につきましては、下記ページもご参照ください。

ServiceDesk Plusの変更管理機能

※ITIL(IT Infrastructure Library®)はAXELOS Limitedの登録商標です。