ITILのプロセス関連図

とある勉強会で、クレーム処理でITILの話が出てきたので、整理するためにメモ。
下記のプロセス関連図でITILは全て説明できる。

ITIL：Information Technology Infrastructure Library - Wikipedia

Itilプロセスフロー from akipii Oga

ITILのプロセスは、PDCAサイクルで覚えればいい。
但し、起点がPlanの変更管理とCheckのインシデント管理の2パターンがある。

RFC(変更要求)が来た場合、変更管理プロセスで、要求を実現するための計画を作る。
つまり、CAB(変更諮問委員会)がステークホルダーを集めて、例えば、実装方法やリリース作業、そしてレビューやテスト方法、評価などの方針を議論して、決定する。

次に、変更管理で作られた計画に従ってリリース管理で、作業者が対応を行う。
実際は、ソースを修正してテストして、リリースする。

他方、顧客からクレームが来た場合、サポートデスクでインシデントとして受け付ける。
サポートデスクは普通は、女性の事務オペレータだったりする。
インシデント管理では、クレームが障害なのか要望なのか単なる質問なのか、を整理する。
障害の場合、暫定対応を連絡する時もある。

次に、障害だと判明したら、問題管理に送られて、BTSへ登録し、根本原因の究明を行う。
問題管理では、原因調査と是正対策を取るのが目的であり、すぐに直すわけではない。

ここでよく出る言葉は、SLA(Service Level Agreement)、いわゆるサービス品質維持契約。
顧客とSIerで、運用するシステムの品質を契約にする。
インシデント管理におけるクレーム情報、問題管理における障害情報から、SLAを満たしているか評価するのに使われる時が多い。

そして、問題管理で作られた是正対策をインプットとして、変更管理で実装計画を立てて、リリース管理で実装・リリースを行う流れになる。

構成管理は、変更管理・リリース管理・インシデント管理・問題管理を支えるインフラであり、CMDB(構成管理データベース)で一括管理されている。
CMDBには、CI(構成アイテム)とCIの作業履歴が登録されている。
SVNリポジトリをもっと汎用化したもののようにとらえればいいだろう。

この流れを詳細化すればITILの用語や説明は分かる。
だからITILはそれほど難しくない。

でも、ITILの発想は、抽象的なPMBOKよりもSW開発の現場で非常に役立つと思う。
チケット駆動開発でも、ITILのプロセスフローを参考にした。
SW開発の現場リーダーは、ITILの考えに触れておくと、RedmineやTestLinkで何ができて何が利点なのか、よく分かるだろうと思う。

昨今、情報処理試験でも情報セキュリティとサービスマネージャ(ITIL)の資格が重視されていると聞いた。
ITILファウンデーションの資格は、このプロセスを詳細化したぐらいで簡単に合格できる。