2014年8月6日水曜日

インシデントの分析ってどうすんの?


数週間ぶりのご無沙汰です。
BSPでITサービスマネジメントツールのサポートをしている森です。

暑い日が続きますが、皆様いかがお過ごしでしょうか?

前回、記事を投稿したときに次回はインシデント分析についてということで書いておりましたので、今回は「インシデント分析の進め方」について書いていきます。

↓↓前回の記事:インシデントはどうやったら減るのかな?
http://itsmbsp.blogspot.jp/2014/05/blog-post_29.html


インシデントの分析を進めるにあたってやるべきことは、
①インシデントの蓄積を行う
②インシデントの分析を行うチームを作る
③インシデントの区分わけを行う
だと思います。

①インシデントの蓄積を行う
インシデントの分析を行うために、まずは情報収集しないといけません。まずは情報の蓄積です。

②インシデントの分析を行うチームを作る
インシデントの分析を行うにあたり、どこの部署が責任をもってやるのか?を決めて取り組みましょう。

③インシデントの区分わけを行う
ある程度、インシデント情報が蓄積された段階でインシデント分析チームが「インシデント区分」を設定しましょう。もちろん、最初の蓄積の段階から区分を設定しても構いません。
ただ、そうなると問い合わせ情報を入れていくときに「この問わ合わせの区分はどれだろう?」となってしまい、問い合わせ情報を入れるのに時間がかかってしまう可能性があります。

まずは、分析のための情報収集です。なるべく、負担をかけない形で情報を集めるのがベストだと私は思います。もし区分を入れていくにしても「必須」とはせず、わかれば入れてほしい程度にとどめておけばよいと思います。

インシデント区分としては
例)
 ・トラブル
 ・Q&A
 ・要望
 ・その他
 等
で設定してみるとよいかもしれません。

インシデント区分で分類することで、どの区分で問い合わせが多いかが見えてきます。この区分がインシデント分析で大事なポイントになります。インシデントの範囲をどこまで広げるかによって分析の範囲が決まります。

例えば上記の区分例で分けてみると下記の様な分析ができます。

・トラブル
類似のトラブルがみえてきます。トラブルが見えてくれば、事前にどう対応するかで問い合わせを減らすかという事につなげることができるようになります。

・要望
ユーザの要望をちゃんとつかんでおくことも重要です。どういう類の要望が多いのか?要望を開発部門にフィードバックすることでシステムに対する不満など解消につなげることができるようになります。

・Q&A
頻繁にある問い合わせの傾向を分析することができます。同じような内容の問い合わせが多い場合はマニュアルやFAQで対応する事で問い合わせ件数を削減させることができるようになります。

・その他
上記いずれにも該当しない問い合わせがどれくらいあるのか?という事がわかります。

等など。

じゃぁ、もっと精度を上げてみるか!と区分の範囲を広げすぎても途中で終わって尻切れトンボになる可能性が高いです。なので3~4個くらいの区分を設定して、インシデント分析を行い、それぞれの区分の傾向を調べてみるのがよいのではと思います。

その結果、
「この区分はもう少し細分化してみた方がよいかも」
と言ったことも見えてくると思います。

例えば、トラブルだと
「何のトラブルが多いのか?」
ということで
 ・ハードウェア
 ・ソフトウェア
 ・インフラ
 ・ヒューマンエラー
 ・その他
と区分を分けてみて、さらにハードウェアについては
 ・サーバ
 ・PC
 ・プリンタ
などの区分を分けると、より詳細にトラブルの傾向が見えるようになります。

区分わけを行い、インシデント分析チームで分析することで問い合わせの傾向やトラブルの原因を特定でき、対応にかかる工数を減らす事が出来るようになると思います。まずは、どの対応でどれくらい工数がかかっているのかを把握してみましょう。

そこから、分析結果をを可視化し月次報告などで報告を行います。そうすることで各部門は「何をするべきか?」が見えてくるのではないでしょうか?

そこで、次回はインシデントの可視化について書いてみたいと思います。題して「インシデントの可視化の先に見えるもの(仮題)」

それでは、See You Next time!
(そこの人、グラフ化すれば一発やでとか言わない!)

0 件のコメント:

コメントを投稿