インシデント管理 - quickcrmfriends@Wiki

インシデント管理の目的

インシデントとは、ＩＴサービスシステムが提供する様々なサービスの品質を下げたり機能を妨げたりする原因になる出来事全般のことを言います。回線にノイズが入る、システムが固まった、リセットがかかったなどの現象は、すべてインシデントとして扱われますが、障害までいかなくても、反応スピードが遅くなった、といった現象でも当初期待されていた性能を、著しく下まわり、業務の遂行に支障が出る場合はインシデントになります。

インシデント管理では、出来るだけ速やかにインシデントから復帰して正常なサービス運用が出来る様にすることを最大の目的とします。注意しなければならないのは、停止してしまったサービス運用を正常な形で再開する、という事であり、インシデントの原因の解明や解決ではありません。

インシデントの種類

インシデントの中には、原因が判っていて、発生したら後どういう対処をすれば良いか、あるいは発生させない為の制限事項などが決まっているものがあります。一方、原因が不明で防ぐ手立ても未確定なものを「問題(problem)」といい、こちらは問題管理で扱う事になります。

インシデント報告を受けたら

通常、インシデントの報告を受けるのは、サービスデスクです。サービスデスクは、インシデントの判定を行い、「問題」であったら問題管理が出来る部署にこの案件を回します。一方、停止してしまったサービスを再起動するなどして、お客様に正常にサービスを受けられる状態を作り出します。インシデント分析をすると、既に過去に対処済みの事象である事が判ったりします。こういう時は、どうすれば正常なサービスを受けられる様になるかわかっているはずなので、すみやかに対処する必要があります。

インシデント分析例

以下に単純ですが、インシデント分析にあたって、各要素をたどって原因を切り分けていく流れを掲げておきます。
ここではQuickCRMのインシデント発生～分析、という流れで説明しますが、保守やカスタマーサービス系の業務でも似たような流れになると思います。さて、この事例では、使用前の機器の接続確認、操作が正しかったかどうかの確認を行い、正しいにも関らず現象が発生した場合に「誤動作」であると認定します。「誤動作」には「ハード」要因と「ソフト」要因があり、「ハード」要因であればQuickCRMにはどうする事も出来ません。「ソフト」要因であったとしても、QuickCRM以外の原因である場合は、やはり範疇の外になってしまいます。

仮に「操作ミス」だったとしても、ミスを誘発するようなマニュアル、ＵＩだった場合には改善の余地があります。改善そのものまでインシデント管理で行なう事はありませんが、専門の窓口にこの結果をレポートする位は必要かもしれません。それをしないために改善が遅れると、操作ミスのインシデントが後を絶たない事になる恐れがあるからです。

原因がわからないとき

インシデントの分析を行なったものの、結局どこに原因があるのかわからない事もあります。こういうケースを「問題」として別途管理するようにします。問題になってしまったインシデントはもはや作ったところ（開発部門）もしくは面倒を見てくれるところ（メンテナンス部門）でなければ解明する事が出来ません。しかし、起きてしまった事はどう仕様もないので、現象発生手順を明確にした上で、そういう操作をしない様なガイダンスを周知しなければなりません。

このようにして、問題の所在を切り分けていく事は、責任の所在をはっきりさせるだけでなく、関係部署それぞれがお互いに効率良くそれぞれの役目を果たす為に効果があります。通常、ユーザーは、インシデントに出くわす事を望みませんが、万一事象が発生した場合はすみやかな復旧と、今後発生しない様にする方策の実施として、原因の解決、すぐに解決が出来ない場合は明確な回避方法の提示を望みます。そのどちらについてもスピーディに提供出来れば、ＣＳはそう下がりはしないはずです。むしろ、いくら素早く電話に出て丁寧な応対をしても、得られた情報がわかりにくかったり適切でなければＣＳは著しくダウンするでしょう。

- / -