Redmine
インシデントを別の角度から定義する
ちょっと脇道に逸れますが、ITILは「サービスカタログ」を作っておくことを提案しています。「サービスカタログ」とは、現在運用しているすべての業務を記述した一覧のことです。特に書式は決まっていないのですが、「誰が」「誰に」「いつ」「何を」「どのくらい」「何を使って」「関係者は」「どれだけ重要か」といったことまで突っ込んで書いておくと、ビジネスの輪郭がはっきりします。また、サービスプロバイダと顧客の間で約束するサービスの提供レベルのことを「サービスレベル」と言い、これを文書化したものを「SLA」（サービスレベルアグリーメント）と言います。この「サービスカタログ」に載っており、かつ「SLA」で定義されたサービスは標準的な「要求実現」のプロセスとなります。簡単に言えば、「要求実現」は“確実に提供すべきサービス”のこと。当たり前のようにできなければビジネスが成り立たないものです。
では、「サービスカタログ」や「SLA」に載っていない標準外の案件はどうするか？ そういったものは、インシデントとして処理されることになるのです。
構成管理
構成管理とは、サービスを運営するために必要な構成要素（ヒト、モノ、ルールなど）を可視化して管理するプロセスです。サービスを構成する要素のことを、ITILではCI（Configuration Item）、構成アイテムと呼びます。「そんなもの、会社の業務が回っていれば必要ないんじゃないの？」と思われるかもしれませんが、例えば新規事業を立ち上げる時に、CIが抜けてしまい、必要な人員が足りなかったりしたら、どうなるでしょうか。恐らく、現場は大混乱に陥るでしょう。あるいは、何かトラブルがあった時、例えば特殊なプログラムを走らせることで急場をしのげるかもしれません（ワークアラウンド・暫定対応）。しかし、サービスの規模が大きい場合、そのプログラムを書ける人が一人しかいなかったら、やはり業務は滞ってしまうでしょう。ならばあらかじめそのプログラムをネットワークに上げておき、誰でも使えるようにしておく必要があるかもしれません。
このように、構成管理は何か新しいサービスを追加したり変更する時に、現状を把握する基盤となるのです。また、ソフトウェアライセンスの有効期限を一元管理したりするのも、構成管理の範疇になります。
構成管理については、Excelなどで管理簿を作れば事足ります。しかし、役割は非常に重要であると言えるでしょう。
・構成管理の活動
変更管理
ITILにおいて、新規サービス（業務）を追加したり、既存サービス（業務）の変更を行うプロセスを変更管理と言います。これはサービスそのものの変更だけでなく、サービスに必要なヒト・モノ・ルール・プロセスなどの構成アイテム（CI）を追加・変更・削除するためのプロセスでもあります。「インシデント」や「問題」を解決する、あるいは起こらないようにするための変更が、変更管理のトリガーになります（もちろん、サービスストラテジが要求してくる変更も扱います）。
・変更管理の活動
