コンサル的思考実験と読書メモブログ

ITコンサルタントが身を持って学んだこと、フレームワークの使い方、書評などを挙げていきます。IT企業や企業内IT部門の管理者やリーダ層の方、ITコンサルタントを目指す方に参考になる情報発信できればと思います。

ITIL活用〜インシデント管理におけるエスカレーションルール〜

こんにちは。atomです。

 

平日はほぼ日刊ブログとなりつつあります。調子がいい時は日に2回くらい更新してます。

 

書くことが沢山あるというのは、自分が好きな仕事出来てるんだなと思います。

 

最近、天職の見つけ方という記事を見てふむふむと思いました。

https://www.kayac.com/news/2016/11/yanasawa_blog_vol18

 

昔サービスを拡販する部署にいて、マーケティングの一環としてブログを始めて当番制で書いてました。その頃は当番なんて2、3ヶ月に一回でも批判浴びてましたが、自分の興味あることはブログ書くのは苦になりませんね。

 

書きながら整理されて、より自分なりの理解やその表現の仕方が整理されていく気がします。

 

では今回のお題のエスカレーションルールについてです。

 

前回までの体制を円滑に機能させるためには、それぞれの役割の定義とともに、エスカレーションルールなるものが必要になります。

 

そもそもITILでは、エスカレーションを以下の通りで定義しています。

 

『サービスレベル目標値や顧客の期待を満たすために必要なときに、追加のリソースを入手する活動。』

 

また、エスカレーションの種類として機能的エスカレーションと階層的エスカレーションを挙げています。

 

覚え方として機能的エスカレーションは詳しい人に相談する、階層的エスカレーションは偉い人に相談するくらいに覚えてもらえればいいです。

 

ネットワークの専門的な質問はネットワークに詳しい人に聞くといった感じです。

 

エスカレーションにおいて重要なのは、どういう時にエスカレーションすべきかどう判断するかとなります。

 

ここでは一次対応スタッフと二次対応スタッフのエスカレーション基準について例をあげます。

 

ナレッジの有無が基準の一つとなります。一次対応スタッフがナレッジを検索しても対応できない場合は、二次対応スタッフにエスカレーションする。

 

更にサービスレベルに応じて、一次対応スタッフが保有できる時間などでもエスカレーションするか判断します。なるべく機械的に判断できる方が良いですね。

 

体制を決めたら、体制間を繋ぐエスカレーションルールも決める事を忘れずに。