ITIL活用〜インシデントの定義編〜

こんにちは。atomです。

今回も引き続いてインシデント管理の話をしたいと思います。

インシデント管理のプロセス設計をする上で一番最初に実施するのがインシデントの定義です。

ITILの定義上インシデントとは、「ITサービスの計画外の停止、または品質の低下。ユーザに影響は与えていない構成コンポーネントの障害」と定義されてます。

企業によっては、インシデントに作業依頼などのリクエストなども含めて管理しているケースがあります。

ちなみにITILでは、作業依頼などのユーザからの作業を伴うリクエストをサービス要求と定義しており、要求実現という管理プロセスを設けることを推奨しています。

企業内IT部門や余り大きな組織ではない場合は、管理が複雑になるのを防ぐため、必ずしもインシデント管理と要求実現を分けなくても良いです。

どう定義すべきか事例として以下を挙げます。

①問い合わせ

②障害

③サービス要求

④要望

⑤内部検知

彼らをインシデントの分類として分けて記録できると良いと思います。また、より細かい分析をする為にそれぞれにさらに詳細分類を設けることを推奨します。

上記分類のポイントは、内部検知された障害をインシデントとして扱うことが一つ挙げられます。

これらは定義をしておき、ツールなどに登録される様にしておかないと、実態がつかめなくなりがちな部分となります。

それぞれがどういった事象を表すかを定義して共通認識にする事がインシデント管理のプロセス設計の第一歩です。

次回はインシデント管理の体制の考え方についてお話ししていきます。