変更もやりっぱなしではいけません。変更を行なった結果、別の問題が起きてしまった場合には、なぜそうなったかを分析する必要があります。ITILではこれを「PIR（Post Implementation Review：導入後のレビュー）」と呼んでおり、変更後には必ずPIRを実施し、変更がCABで承認した通り実施されたか、その結果問題は起きなかったかなどを確認することを推奨しています。事例のようにケースでは、変更後に問題が発生していた場合になるので、Mさんはユーザーの立場からそれを指摘することもが重要です。さらに発生した問題をRFCのPIR欄に記入しておき、次回以降同様の変更を行なう場合には、必ず過去のRFPをチェックすることを求めましょう。そうすれば、過去に起きた問題を知ることができ、必要な対策を事前に立てることができます。
今回の変更管理に関するプロセスをまとめると、以下のようになります。
最近の運用管理ツールでは、RFCを電子的に入力し、それをワークフローでCABメンバーに回付して承認をとるような機能を持ったものもあります。RFCの量が膨大になる大規模な企業では、それらのツールを導入して効率化を図るのも重要です。
協力：ネットワークマガジン
 |
|---|
 |
||||
 |
 |
 |
|
 |
 |
||||
「ITILでシステムの効率化を目指そう」トップへ
【アスキービジネス 新刊ムック】
【ASCII.jp SaaS・ASP】