「ISO20000の規格について（16）」

今回は、解決プロセスの「インシデント管理」についてお話したいと思います。

まず、「８．解決プロセス」について説明します。 「８．解決プロセス」は、 「８．１背景」、「８．２インシデント管理」、「８．３問題管理」と３つの要求事項で 構成されています。

「８．１背景」は、８．２と８．３を連携させる必要があるということを説明している ので、８．２と８．３を実現できれば、この項目は自動的に実現されます。

次に、「８．２インシデント管理」と「８．３問題管理」についてですが、用語の解説は、以下のとおりです。

【インシデント】
運用の中で対応しているアラートや障害、ミスなどの標準の運用に属 さないもの
【問題】
運用の中で、会議や連絡会などで挙げられる問題や懸念事項など、いわば、運用 において
解決や対策を用意しないと顧客やサービス提供に影響が出てしまうよう なもの

上記のようなことは、普段の運用の中で当たり前のように実施されていることかと思います。
だからこそ、この「８．解決プロセス」は、普段の運用をベースに実現しましょう。

では、本日の本題である「８．２インシデント管理」について話を進めます。

「８．２インシデント管理」は、発生したインシデントを迅速に処理し、サービスへの影響を最小限に抑え、
確実に管理するための要求事項です。
管理にあたっては、処理手順が要求され、記録からクローズまでの定義が必要になります。

実際の運用の中で実現する際には、具体的な事象（例えば、システム障害、オペレーションミスなど）を
定義する必要があります。
なぜなら、ここで事象を具体的に定義しないと、実際の運用時には、
担当者によって、発生した事象をインシデントと認識する人もいれば、認識しない人もでてきてしまい、
漏れ」や「ブレ」が生じてしまうからです。

発生したインシデントを確実に処理するために、具体的な事象をあげてインシデントの定義をする必要が あります。

この定義にあたっては、適用するサービスを対象に、
「サービス提供における標準の運用に属さない負の事象」を洗い出し、
それをインシデントとして定義してください。

インシデントを定義したら、次は、発生したインシデントを管理する手順です。
以下についての定義や実施の仕方を決めましょう。

インシデントの記録の残し方
インシデントに対する優先順位付け
インシデントに対する影響定義の仕方
インシデントの分類基準と分類方法
インシデントの更新方法
インシデントに対するエスカレーション方法
インシデントに対する解決の定義
インシデントに対する正式なクローズの定義
この要求事項の実現には、冒頭の説明にもある通り自社の普段の運用のやり方に基づいて、
規格の解釈と実現方法を決定していただければと思います。

イメージができない場合は、オーバコントロールになる可能性もありますが、ITILを参考にするのもよいでしょう。

「８．２インシデント管理」は以上です。次回は、問題管理についてお話します。